aeonfox

loosely typed

Minor nitpick: I believe Elixir and Erlang are strongly typed languages, but for a long time they have both been dynamically typed. With v1.20, Elixir is well on its way to transitioning to a gradually static typed language, and to-date has done so almost purely through inference (except for guards which can explicitly specify type information)

Game recognises game

Debug yourself of the AI hype^. Besides config, SQL implementations have a very limited textual API surface of accepting queries. Putting whole layers of UI and agents around it is really inefficient way of finding edge cases. I wouldn't call that basic, nor the most comprehensive option. Fuzzing at the query layer is far more computationally efficient and effective.

A truly stochastic method is more likely to hit against edge cases, rather than an agent that tends to towards idiomatic solutions and that is trained against a corpus of existing software, and burns millions of tokens/watts spinning its wheels.

^ There's plenty of business value to be found in agentic AI without reaching for it for every solution. I'd even posit agentic AI is even better when paired with focused old-fashioned squishy-brained software engineering in the loop.

This is where fuzzing would be useful. We have an at-least-parity-bug-level oracle with the reference PostgreSQL implementation. Just build a generator of queries (both invalid and valid) and ensure the output matches. The yardstick is how many log10(queries) it can go on average before a discrepancy is found.

Or gosh, just read my comment! I said in somewhat gloomy places. Sometimes people are working when the 10 minutes of sunlight comes out. Often that's not enough time to get down the elevator and get outside before the sun hides behinds the clouds again, even if you can take the daytime break.

The article cites another study by Richard Weller:

Sure enough, when he exposed volunteers to the equivalent of 30 minutes of summer sunlight without sunscreen, their nitric oxide levels went up and their blood pressure went down.

I can't find information on the methods for this particular study. So I'm curious if he just set up UV lights on a timer and sat his subjects under them. That's something anyone can set up in their home office if they live somewhere gloomy. Instead of taking a vitamin D pill, turn the timer switch on for 30 minutes of a properly calibrated and positioned low-dose UV light (and out of direct line of sight to anyone not under it)

Or just take a nitric oxide supplement :)

Elixir is not just expressive, it's highly conventional. I've found best practice code usually converges on the same idiomatic patterns, and well written codebases look very similar to each other in style

I feel like most would just pay for the thing that is already setup and ready for them

Nothing stopping turnkey OSS AI hardware being productised, including niceties like opt-in automated updates. If the trend continues of models becoming smaller and more capable for everyday use, it also derisks against obsolescence.

philosophically insulated

As an outsider, I'm curious on how?

A better example are sodium ion batteries, which are about to take off in a big way

https://www.catl.com/en/news/6812.html

The difference with biological brains is that the 'weights' (or synaptic action potentials) are updated with greater frequency. If one were reaching to make some kind of analogy to consciousness, this update frequency could be considered the 'resolution' of consciousness.

I've definitely found LLM code to be syntactically/semantically correct in one-shot pretty much all the time. It's usually the functional specification/behaviour that's found wanting.

Typing probably makes sense where memory-correctness needs to be enforced (e.g. Rust), and inferring those semantics require a much wider context. But memory-correctness isn't really something that afflicts BEAM languages.

How did you score freelance Elixir work?

OP might be referring to Jose Valim's 2023 ElixirConf talk where he's explaining why Elixir should go down the path of types.

He gives a lot more nuanced take than 'types are useless', which is more like 'types are less useful than people think in the context of Elixir development'. (Which makes sense because he's in the middle of implementing a type system for Elixir.)

https://youtu.be/giYbq4HmfGA?t=571

?

Separate to the self-host/datacentre argument, it would be interesting to see a speed/performance/watts-per-token leaderboard between leading models. Which model is the most watt-efficient?

Using mouse motion as a control scheme is particularly genius - how did no one think of this before?

Point-and-click adventure games and the golden age of Macromedia Flash might be before your time? This really reminds me of novelty sites built in Flash which was all point and click and vector animation. A lot of those sites are lost to time, or perhaps hidden in some deep crevice of the web archive.

I particularly like the points where the mouse control is taken away from you

One thing Flash couldn't do. But it had plenty of RCE exploits, so maybe it could.

the user doesn't really care all that much

They do. But not in the way that you think.

I recently switched from Spotify (well known Electron-based app) to Apple Music (well known native app). The move was mostly an ethical one, but I must say, the UI functionality and app features are basically poverty in comparison. One tiny example, navigating from playlist entry to artist requires multiple interactions. This is just one of many frustrations I've had with the app. But hey, it has beautiful liquid glass effects!

In short: iteration time matters. Times from design to implementation, to internal review, to real user feedback, and back to design from each phase should be as fast as possible. You don't get the same velocity as you do in native. Add to that you have to design and implement in quadruplicate, iOS design for iOS, Android for Android, MacOS for Mac, Windows design for windows. All that is why people use Electon.

really bad at native

Yikes. I spent 15 years developing native on both mobile and desktop. If you think that native has the same design flexibility as HTML/CSS, you're objectively wrong.

By design, each operation system limits you to their particular design language, and styling of components is hidden by the API making forward-compatible customisation impossible. There's no escaping that. And if you acknowledge that fact, you can't then claim native has the same design flexibility as HTML/CSS. If you don't acknowledge that fact, you're unhinged from reality.

There's pros and cons to the two approaches, of course. But that's not what's being debated here.

Who said anything about mockups? Design goes all the way from concept to real-world. If a designer can specify declaratively how that will look, feel, and animate, that's far better than a developer taking a mockup and trying their hardest to approximate some storyboards. Even as a developer working against mockups, I can move much faster with HTML/CSS than I can with native, and I'm well experienced at both (yes, that includes every tech I mentioned). With native, I either have to compromise on the vision, or I have to spend a long time fighting the system to make it happen (...and even then)

And HTML/CSS/JS are far more powerful for designing than any of SwiftUI/IB on Apple, Jetpack/XML on Android, or WPF/WinUI on Windows, leaving aside that this is what designers, design platforms and AI models already work best with. Even if all the major OSes converged on one solution, it still wouldn't compete on ergonomics or declarative power for designing.

unlikely to ever be competitive

Bold claim to say these challenges will never be surmounted. Either a more-economic technology would have to mature first, or civilisation halt progress for that to be true. If scientific advances could yield miniaturised photonics that offer a significant cost/benefit over any contemporary technology the concept will still be pursued. Unless you are suggesting that it is theoretically and physically impossible?

Are there any polls (or any educated guesses) gauging what proportion of people who identify as Zionists want equal status with all Palestinians (particularly democratic rights) within the bounds of what was once Mandatory Palestine?

Who's the 'non-zionist' choice in the US?

A) Wasn't the article suggesting that would be 4-bits end-to-end in this hypothetical photonic matrix multiplication co-processor? ie. the weights are 4-bits

B) Power consumption and speed. Essentially chips are limited by the high resistance (hence heat loss) of the semiconductor. Photonics can encode multidimensionally, and data processing is as fast as the input light signal can be modulated and the output light signal can be interpreted. I guess this would favour heavy computations that require small inputs and outputs, because eventually you're bottlenecked by conventional chips.

I was thinking more if you write a prompt into an IDE that has first-party integration with an LLM platform (e.g. VS Code with Github Copilot), it would make sense on their end to reduce and remove redundant input before ingesting the token into their models, just to increase throughput (increase customers) and decrease latency (reduce costs). They would be foolish not to do this kind of optimisation, so surely they must be doing it. Whether they would pass on those token savings to the user, I couldn't say.

Do the larger LLM platforms just do this for you? Or perhaps they do this behinds the scenes, and charge you for the same amount of tokens?

Except for the times you do want it to run the CI.

LLM issues can often be solved by being more and more specific, but at some point being specific enough is just as time consuming as jumping in and doing it yourself.

Looking at their misrepresentations and over-exaggerations regarding Erlang it now seems like a long lead-up to a sales pitch. Their motivation to exaggerate deficiencies in existing approaches is to lend chapter 7 more rhetorical punch. All the same, I'm keen to hear what they have to say.

True. And that the subtle bugs were then picked up by static analysis makes the safety proposition of Erlang even better.

Bugs that happen regularly in prod

It depends on how regular and reproducible they are. Timing bugs are notoriously difficult to pin down. Pair that with let-it-crash philosophy, and it's maybe not worth tracking down. OTOH, Erlang has been used for critical systems for a very long time – plenty long enough for such bugs to be tracked down if they posed real problems in practice.