dawidloubser

Yes

Often the answer to "some very clever language" is a lazy functional language like Haskell, where it's quite common to express problems naturally on infinite or near-infinite lists (of numbers, users, whatever...) in this way - and the language's lazy evaluation semantics effectively turning it into an efficient streaming data pipeline of sorts.

But even if not, the example from the article is just hypothetical. `db.getUsers()` could be something that just retrieves rather efficient `[UserEmail, ExpiryTime]` pairs, and then you'd have to have a pretty enormous user base for it to not scale (a couple of million string/date pairs in memory should be no problem).

It was taken on a wet plate camera (capturing images on sensitised glass pates), which has remarkable resolution, typically far beyond most smaller cameras even today.

The photo was artificially lit, most likely with flash powder or magnesium ribbon. Those create incredible amounts of light - obnoxiously so, which is why they were replaced by safer flash bulbs and later on electronic flash in subsequent decades.

The light would have been more than enough to illuminate the people standing and posing for the photograph in that enclosed room.

I wonder how different things would have been if we were not able to capture the past 100-150 years so well on monochrome film. What a remarkable time to be alive, and to have been able to look back on the past using a mostly-reliable and truthful medium - now long since lost with the advent of digital imaging.

And hydraulic power back seats, and a hydraulic sun roof (!!) and hydraulic power aerial, and hydraulic controls for the air suspension. Some models even had a hydraulic glass partition between driver and passengers.

Absolute nuts. But the high point of dead-silent, powerful, smooth conveniences no matter the maintenance cost.

I've always been into vintage Mercedes-Benz cars.

A talented and wonderfully jovial mechanic ran a specialist workshop east of Johannesburg, in Brakpan (South Africa).

For a long time he had a Mercedes 600 - similar to the linked video but with the M100 engine naturally-aspirated as standard - in the shop.

That particular car, finished in a cream colour, belonged to Ian Smith (1919-2007), the last colonial prime minister of Rhodesia before it became Zimbabwe.

I got to spend a lot of time with the car, including several drives in it, and especially seeing the mechanical bits exposed including the ridiculously cool (silent, powerful) hydraulics that operated every convenience of this car, from power windows to power back seat.

While a Mercedes 600 indeed screams "head of state" or "pope" it gets my vote for the all-time, no-holds-barred, most opulent and classy car of all time with absolutely nothing kitsch or gangsta about it.

A true high point of what Mercedes-Benz once was.

And don't get me started on it's little brother, the W109 300SEL 6.3, of which there was a lovely example in the shop for a few months as well. It drove and operated perfectly, I had the most amazing solo test drive in that car, taking it to 200km/h.

This was in 2003, and the 300SEL 6.3 was for sale for $3,000 and Ian Smith's 600 was about $12,000.

God if only I had the money then! I wonder where both of those rarities, sitting in a small workshop in the East Rand in South Africa, ended up at. Probably exported to Europe or the USA.

Anyway, just wanted to share that small anecdote.

P.S. The Chrome, Leather, and craftsmanship of a Mercedes 600 is far beyond any Rolls or Bentley, of that or any other period. And Mercedes vehicles of that era were made to last decades and hundreds of thousands of miles down to every detail including all the rubber parts. The disposable garbage churned out in the 21st century simply fuel man's insane behaviour to constantly buy, consume, discard.

There was a time when cars were made for a different modality.

But surely you can see that the economy does not serve us. Who is "us", anyway?

The economy, and the worldwide technological system that it fuels, behaves like its own organism with its own ultimate goal unbeknownst to us.

By looking around you, is it not perfectly clear to you too that it does not have anything to do with the well-being of people?

I guess the more succinct the code, the more the reliance on understanding what a function actually does - either through experience, or by reading the docs. The words function is simply:

  words :: String -> [String]

So that

  words "foo bar baz"
  -- Produces: ["foo","bar","baz"]

In my experience, both the blessing and the curse of Haskell's incredible succinct expressiveness is that, like other specialised languages - for example using latin for succinctly-expressed legal terms - you need a strong understanding of the language and its standard library - similar to the library of commonly used "legal terms" in law circles - to participate meaningfully.

Haskell, and languages like Go (which anybody with a bit of programming experience can easily follow) have very different goals.

Like many in this discussion, I too have developed a love/hate thing with Haskell. But boy, are the good parts good ...

I like to idealistically think that in a capitalistic (free market) society we absolutely have the option to not use things that we think are wrong or don't like.

Change your search engine to one that doesn't include AI-generated answers. If none exist any more, all of Google's customers could write to them telling them that they don't want this feature and are switching away from them because of it, etc.

I know that internet-scale search is perhaps a bad example because it's so extremely difficult and expensive to build and run, but ultimately the choice is in the consumers' hands.

If the market makes it clear that there is a need for a search engine without LLM-generated answers at the top, somebody will provide one! It's complacency and acceptance that leads apparently-delusional companies to just push features and technologies that nobody wants.

I feel much the same way about the ridiculous things happening with cars and the automotive sector in general.

Provided that we ignore the ridiculous waste of energy entailed by calling an online LLM every time you type a word in your editor - I agree that the utility of LLM-assisted programming as "autocomplete on steriods" can be very useful. It's awfully close to that of a good editor using the type system of a good programming language providing suggestions.

I too love functional programming, and I'm talking about Haskell-levels of programming efficiency and expressiveness here, BTW.

This is quite a different use case than those presented by the post I was replying to though.

The Go programming language has this mantra of "a little bit of copy and paste is better than a little bit of dependency on other code". I find that LLM-derived source code takes this mantra to an absurd extreme, and furthermore that it encourages a though pattern that never leads you to discover, specify, and use adequate abstractions in your code. All higher-level meaning and context is lost in the end product (your committed source code) unless you already think like a programmer _not_ being guided by an LLM ;-)

We do digress though - the original topic is that of LLM-assisted writing, not coding. But much of the same argument probably applies.

I think that anybody who finds the process of clumsily describing the above examples to an LLM in some text box using english and waiting for it to spit out some code which you hope is suitable for your given programming context and codebase more efficient than just expressing the logic directly in your programming language in an efficient editor, probably suffers from multiple weaknesses:

- Poor editor / editing setup

- Poor programming language and knowledge thereof

- Poor APIs and/or knowledge thereof

Mankind has worked for decades to develop elegant and succinct programming languages within which to express problems and solutions, and compilers with deterministic behaviour to "do the work for us".

I am surprised that so many people in the software engineering field are prepared to just throw all of this away (never mind develop it further) in exchange for using a poor "programming language" (say, english) to express problems clumsily in a roudabout way, and then throw away the "source code" (the LLM prompt) entirely such to simply paste the "compiler output" (code the LLM spewed out which may or may not be suitable or correct) into some heterogenous mess of multiple different LLM outputs pasted together in a codebase held together by nothing more than the law of averages, and hope.

Then there's the fun fact that every single LLM prompt interaction consumes a ridiculous amount of energy - I heard figures such as the total amount required to recharge a smartphone battery - in an era where mankind is racing towards an energy cliff. Vast, remote data centres filled with GPUs spewing tonnes of CO₂ and massive amounts of heat to power your "programming experience".

In my opinion, LLMs are a momentous achievement with some very interesting use-cases, but they are just about the most ass-backwards and illogical way of advancing the field of programming possible.

Based on my experience of building several payment gateways, it is my opinion that it's pretty much always "3 lines of code" (which isn't true about this library - more like "3 steps") to post a payment, even to the nastiest acquiring or banking API.

The remaining 675,000 lines of code are to:

- Perform Risk / Fraud scoring to decide whether you want to, indeed, process this payment.

- Deal with the myriad of failure scenarios - including mapping them to your own system's error semantics - in a way that your customers can understand to reduce support calls.

- Refund, void or reverse previous payments.

- Create the necessary accounting entries in order to do settlements / settlement reports for your customers.

- Etcetera

Payments systems are perplexing to me: Nothing is a more obvious candidate for an absolute, standardised, commoditised piece of software in the same way that the global IP network routes packets - only in payments we are routing "promises" and our routes, and routing decisions, are in many ways much simpler.

Yet there are very few industries where this particular wheel gets reinvented as often as it does; each organisation convinced that it has its own unique approach to doing this absolutely standard, regulated "thing" - which, reductio ad absurdum, is just an expensive buffer in a network of pipes.

Hopefully open-source software will pave the way: TigerBeetle is an amazing start (distributed ledgers), and it's hopefully only a matter of time until the other components of a payments switch are freely available as open-source components with high-quality APIs.

Excellent example clearly from a fellow soldier from the trenches!

As somebody who has built several instances of both payments- and travel booking systems, I have seen things in systems that "adhere to published schemas" (often because the schemas were beastly, design-by-committee hellscapes of extensibility) that defy belief.

While there is a strong argument to be made that strict type systems in programming langues like Haskell and Rust make it very difficult to play outside of the rules, this is unfortunately not the case in practice when it comes to APIs - both at present where you have a JSON Schema or Open API spec if you are lucky, and in the past (XML Schema, SOAP).

I wish that the ability to express a tight, fit-for-purpose schema or API actually resulted in this commonly being done. But look at the average API of any number of card payment gateways, hotels, or airlines, and you enter into a world where each integration with a new provider is a significant engineering undertaking to map the semantics - and the errors, oh the weird and wonderful errors... to the semantics of your system.

I am glad to work in the space-adjacent industry now, where things are ever so slightly better.

(Note the lack of sarcastic emphasis - it really is only _slightly_ better!)

Another shout-out for Jellyfin. Somewhat unusual in that it's build with .NET technologies and runs on Linux, but it's proven to be an excellent media server for many years now.