Indy9000

This article and the magazine seems to be well designed and put together. Nice!

Let the kids have their childhood. Monads can wait.

So it's.... V9 now? . . . I'll get my coat

That whole article could have been just two sentences.

If anyone is wondering, this is not a Go project. It's built with C.

Awesome work nonetheless.

What would be good is to have the value prop in a 3,4 sentences up top.

I've gone through 3/4 the post but still I'm not sure what it does concretely.

Also back up your claims that X is better than Y.

Implement Lisp parser and a repl in your fav language. It's not difficult.

I made a series of videos how to do it in typescript. That was fun!

Here's the link if you're interested: https://youtube.com/playlist?list=PLP_fzAt_4T3QVlW_7Zr3CYLmV...

No but, Ruby makes it trivial. No decompilations, no assembly, no debuggers necessary. Drop into an irb in a running process, change stuff and get out in seconds

What makes Ruby so irreplaceable? Why struggle to make it something it's not when you could pick an existing statically typed language and build your system? Also how is Ruby a safe language for financial transactions when an engineer can hijack a running process and change memory without leaving a trace

F# Is a good choice for cloud orchestration. MBrace was doing something similar to this atleast about 5yrs ago. I've written a ml pipeline entirely in F# with deployment.

My 2p re: Dark Rather than creating a completely new language, Dark could just provide an API or a framework and use F# as the deployment scripting lang.

F# is succinct and easy to learn and work with for the customers (DevOps). Beats yaml anyday.

Writing a new language that is production ready is no small task.. takes years to get the syntax, stdlibs, and tooling right. By that time cloud computing may evolve into something else entirely..

I love this article because it is well written and clear.

What you say is that our actions even without explicit names, etc. can be used to identify the actual person. This is kind of missing the point. Because, that sort of reverse lookup can't scale, and in a very large number of cases it won't be. [Edge case: only person in a village or a post code].

By removing the directly identifiable info, the damage done in a breach would be less. Where as now, a single breach contains all the data that could identify a person and every person in that breach, without having to do any/much reverse look up.

Now, the orgs that collect this data does not have a certification standard and verification that they have to obtain before going operational. Even a restaurant kitchen has that.

On that note, I'd say that there should be a severity grading for the data items. Even Eggs have a grading system. Our personal data is a tad more valuable.

I think a third party or minimum number of parties can be included in this trust network for exchange of information. Where as now (if the data gets public) there's no restriction.

This may not be the status quo of the medical system. But I'm willing to bet it wasn't conceived and put in place when breaches like this could happen frequently and the consequences were damning. Overhaul of the process is required. Just keep paying the Ransom/Hackers is not the only and meaningful solution.

Medical history has to be only meaningful between doctor and patient. Doctor can keep records under a unique ID which patient is given at the start of sessions and the patient presents it at each session to validate the relationship. In the event of a breach, even when all data is exposed, without tracking the unique ID back to a person (which would be difficult or impossible) the harm is little.. (Imagine reading a story of a person but you don't know who that person is..)

You might say that there would be other person names and places in mentioned in the records and from that network and timeline you may be able to deduce the identity.. but these PII can in turn be depersonalised. And also this is not scalable for widespread damage.

It just need a bit of thinking when designing a system. Frankly any org that ask for PII and doesn't have a well thought out way to store them should be heavily penalised.

That's what the law should do standardised methods of storing sensitive data.

Medical records can be stored without personally identifiable information (PII). And they should be. That's what I'm proposing.

There's no good reason to have personally identifiable information stored in the system. They could easily issue each patient an alphanumeric ID which is not tied to personal information yet uniquely distinguishable..

This is a system design failure to begin with. Design sensitive systems with only minimum required information. The alternative is to have a massive framework to make sure PII hadn't leaked. And then a legal and financial frameworks on top of that..

after all if a leak happens it can't be undone. Damage to the people will be long standing and cascading.

Best is to have a system that have no or minimum PII.

Looks great!

I've read a lot about mindfulness and the benefits of it recently. So being an engineer, I had to build an app. Minimalist way to get started in mindfulness https://sanebrain.app

I've create this app for my own use so that I don't have to expose my data to countless third parties. It's a combination of a journal, notes, todo list and fitness, fasting tracker. This gives the ability to run analytics on all of these in combination to get a better understanding and in the future encourage myself to keep on track to achieve my goals. The data is stored locally. Some usage stats sent to backend so I can improve features.

Opening it up for others who might find this useful. Appreciate your feedback. Ta!

Plato also knew Javascript and the rise of the robots. (I don't have to cite because ¯\_(ツ)_/¯