socialdemocrat

Apple should have made a modern Smalltalk on top of the Objective-C object model as a replacement for Objective-C instead of Swift.

I want to love Swift, but the funny thing is that as they solve more problem with Swift they also add so much complexity that you wonder if all the problems they solved just added new problems.

Think you are a bit quick to judge what people in Europe think. Juries have also been widely used in Europe. They are not unknown. It depends entirely on where you are.

Britain famously use juries. That is where the US gets it system from. In. All Nordic countries have had them. In Norway we phased it out years ago, but it isn’t one judge but several. Some are picked by citizens others are professionals. They determine guilt together.

In Norway we long had two systems to determine guilt. One was a jury system. A careful examination of the performance of both systems over many years concluded that the jury system was the worst. All serious miscarriages of justice we have had happened in a jury system.

A key reason identified was that juries don’t have written statements giving the reasoning for their judgment.

The jury system ended several years ago and nobody miss it. A panel of judges professional and selected among citizens akin to jury duty determines guilt.

I have long been skeptical of AI/AR because I also don’t feel like being strapped in like that. But I can see this as being useful for dedicated tasks: surgeons, building or repairing a PC, inspecting a buildings. It will be more of a professional tool than consumer tool I think.

People are increasingly running out of reasons to not use Julia. It really is the future for data science and machine learning. No let me correct that. It really could replace anything R, Python, Perl, Ruby etc is used for today.

Not right now as packages, larger communities etc need to be developed. But long term solutions the potential is obvious. A friendly, powerful and high performance dynamic language ought to have a very broad appeal.

That is not really true. People think that because they have spent time with Java which is excessively GC dependent. More modern GC languages such as Go and Julia have opted to use GCs in a far more conservative manner. They don't produce the exorbitant amount of garbage that Java produces. I've talked to NASA guys using Go for real time systems. They say it works great. GC doesn't need to be a problem if you do it right.

A clear complexity cost difficulty in extending these libraries. This separation force libraries to become huge complex monoliths. In Julia the equivalent is done with absolutely hilariously tiny libraries. In fact they are so small that many Python guys exploring Julia decide to not explore further thinking most of the Julia ML libraries aren't done or have barely started.

They are just not accustomed to seeing libraries being that small. That is possible in Julia because it is all native Julia code which means interfacing with other Julia code works seamless and allows you to mix and match many small libraries very easily. You can reuse much more functionality which means individual libraries can be kept very small.

For PyTorch and TensorFlow e.g. activation functions have to be coded specifically into each library. In Julia these can just be reused for any library. Each ML library doesn't need to reimplement activation functions.

That is why you get these bloated monoliths. They have to reinvent the wheel over and over again. So yeah there is a cost which is constantly paid.

Every time you need to extend these libraries with some functionality you are paying a much higher price than when you do the same with Julia.

Julia 1.0 was released in 2018. That is just 5 years ago. I would say that is very young. Especially since a language today needs more than in the past. Julia has package manager, virtual environments, version management. Stuff that tends to be bolted on much later.

You needed much less stuff supported out of the box when Python first came on the scene. Today expectations have gotten much bigger. A minimal viable language has far more requirements.

Not sure why you restrict this observation to UK and commonwealth countries. This is reality for many of us in Europe. Legal documents in Norway also refer to the king as the one deciding stuff. But that doesn’t literally mean the king. It is more of the institution of monarchy and the ceremony in which the king signs government actions presented to him by “his” government.

But this is of little practical consequence. What I find more bizarre is how conservative the US is around its constitution and political system. Norway may be a Monarchy but has gone through far more modernization in terms of how the political system works, elections and government than the US for instance.

I look at how voting and representation works in the US today and it is basically Norway in the 1880s or something. Back when we also had a two party system of liberals and conservatives. When there was a winner take all system. Censuses had to be done semi regularly as citizens were not fully and completely registered and kept up to date on a continuous fashion.

I would bet Britain in quite a number of ways is more modern in its constitution than the US. E.g. they don’t have å gerrymandering problem. That got reformed and fixed long ago.

You can just look at a map over the US and see quickly how the grid pattern exists at almost any zoom level. You also notice it in how people think about directions. As a European I found it tricky to deal with but I saw the opposite when Americans drive in Europe. They really struggle with a system not built around thinking east-west and north-south.

I think generally in Europe people think in terms of landmarks rather than fixed directions.

Extensive comparison of engines, design of shape, choice of materials, performance and strategies for reuse.

So Rust force you to do waterfall design? Sorry just had to tease about that as a dynamic language fan. I am much more in the LISP school of thought, believing in growing software through iteration and exploration, for much the same reason I think lean project development has been more successful.

The problem is that so much of the time when you are building something you don't really have a clear idea of what you are doing, but you build and understanding as you experiment and iterate.

I do writing professionally now and have much the same experience. It is hard to plan exactly what you will write in detail. So much of the greatest ideas materialize as you write. Both writing and coding is IMHO a thinking process.

On the other hand I fully accept that us developers are all different in how our brains work. But I have seen when working with people much smarter than me how much they get stuff wrong and waste time by trying to excessively plan before fully understanding the problem. Stuff I notice I solve easily by taking an experimental and iterative approach.

One small concession: I think JavaScript is awful and Ruby projects tend to end up as a mess. I am mostly a Julia, Lua and Go fan. So I kind of learn towards languages which are a bit in between dynamic and static.

Not at all. Nobody doubted this could be done. So there is no countdown as that would imply we didn’t know if fusion can be done. We do know. The problem is primarily engineering a working fusion power plant and this milestone didn’t advance that goal one iota.

It will never be cheap and limitless though. Is solar power isn’t free even if you don’t have to pay for the sunshine. It is the capital costs which gets you and those will very much apply to something as complex as fusion.