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.

That's a nice thought, but unfortunately the environmental cost of "storing" all of this material - i.e. all the billions of tonnes of plastic pollution already out there, and in there (inside you in the form of microplastics) - doesn't come for free.

It's a current problem, and we don't seem to have the technology or even the political will to solve it currently.

That's a great use-case! But what about when GPT hallucinates - gets it wrong. What happens when you have sent a (potentially legally-binding) quote to your customers, and you have to back out of it?

Humans make mistakes - whether directly, or indirectly through the software that we craft. But when the mistake happens, we can reason about it, understand why it happened, and fix the problem.

Wouldn't it be embarrassing to not be in a position to reason about / explain a mistake to your customers caused by this "thing" we use that's been trained on all the random information available on the internet? Would that not reduce the value and standing of your business (which is ultimately about the people and expertise contained within) in the eyes of customers?

As an engineer, technologist, and CTO I absolutely love what I've been able to craft using generative AI under direct supervision.

But I cannot imagine a world where we give our carefully thought-through, easily changeable, algorithms and processes for a black box that cannot be reasoned about, no matter how good the output _sometimes_ is.

I have to think many people feel this way.

You make a very good point in general, but at this point cars are already so absurdly over-regulated, it's basically impossible for the "new guy" to break into the market at all.

| "...a blow to auto manufacturers who have spent millions lobbying against similar legislation and fighting against it in the courts."

Does anybody know which car manufacturers? I'd like to make sure I never support them directly or indirectly.

This is hilariously brilliant. Thank you for almost killing a fellow engineer through laughter.

I find it interesting that the article and paper which it summarises takes the analogy of representing steam locomotives as a species with a "driving force of survival" that far.

Steam Locomotives are simply a *product* in a competitive market, and that market changed.

If one wants to imbue them with all these biological properties, one can surely do that with any failed product? The Blackberry? 3D Televisions?

(Full disclosure: I'm a lifelong fan and studyer of steam locomotives)

One of the first incantations of this idea that I encountered, when I had just started working at my first corporate job back in the day, was Robocode ( https://robocode.sourceforge.io/ ) - it was great fun, and I see it's still going.

I guess this will push more and more bloggers to start looking at static site generators like Hugo ( https://gohugo.io/ ) and either hosting themselves, or on one of the many "built in" cloud hosting providers that it supports.

I have been focusing on film-based photography for 15+ years - mostly printing in the darkroom, but also often scanning - and can wholeheartedly recommend Vuescan on Linux.

About 6 years ago, however, I switched exclusively to the open-source XSane [1] and it operates my old scanner(s) beautifully, with all features including the transparency unit.

Try it out if you don't have a highly unusual scanner with driver issues. My workflow involves:

1. XSane for scanning (to 16bit TIFF)

2. exiftool [2] to tag my images with full metadata from my notes: camera, lens, aperture, film, datetime etc just like your digital camera would

3. Darktable [3] to manage my library, cropping, sharpening, adjustments, and tagging

It's a little bit of work - but nowhere near as much as taking and processing 4x5in photographs, and the "digital end results" are very satisfactory.

If I may, an example image: https://www.flickr.com/photos/dawidloubser/35944112383

[1] http://www.sane-project.org/ [2] https://exiftool.org/ [3] https://www.darktable.org/

PlayVS | Senior engineers (front-end, back-end, full-stack) | Santa Monica, CS | Full-time | Onsite

The official high school esports league platform -

We work with game publishers and high school governing bodies to build and operate sanctioned leagues across the country. The challenges we solve on a daily basis are exciting and relevant. We’re looking for top talent to help us create the world’s first full-stack sports platform.

React, Redux, Ramda, Node.js, Web sockets, Redis.

https://www.playvs.com/careers or send your resume and examples of your work to: careers@playvs.com

For anybody else excited when they hear "open" and "AGI" in the same sentence, if you don't know the OpenCog project, the wiki (especially if downloaded in book form) makes for fascinating reading:

https://wiki.opencog.org/w/The_Open_Cognition_Project

I don't quite think so. There are specific laws governing the use of of, say, photographic equipment within a private property.

If a web server, on other other hand, willingly serves content to both a browser being operated by a human, as well as screen-scraping software, then it shouldn't try to prescribe how the screen-scraper uses that information.

It would be the equivalent to, every time, asking somebody that works in the museum if you can take a picture, and them saying "yes", and then wanting to complain (or sue) afterwards.

Actually, it's not. In your analogy, the storefront is completely passive and unaffected.

What is actually happening, is that somebody is walking into the store, asks a question about the stock or the price of the products on sale, which the store employee willingly answers.

Then, all of the sudden, the store wishes to control what you do with the answer that was willingly given to you.

This is clearly absurd - and so too is wanting to control what people do with publically-available HTTP data. If it's public, it's public.

I personally do feel that LinkedIn is within their full rights to attempt to detect and restrict content being served to screen-scraping agents, but they must then accept that screen-scraping agents must be allowed to use any means necessary to impersonate a "normal" user browsing the (public) information that they publish.

This can't be a one-sided freedom.

Well... for some of us, when you say "functional programming", you say "Haskell". And it certainly had all of those features, and much more, more than 20 years ago.

I really like another poster's recommendation that it be called "combinator-oriented programming". Because, while ES, Java, and even Rust, supports rich combinator-oriented programming, I wouldn't dare call any of them functional programming languages.

Though, one has to admit, with ES6 now even supporting elegant currying, coupled with a good functional programming library like Ramda, and immutable data structures (Immutable JS), ECMAScript comes pretty close if you really want it to.

The difference is, any code anywhere can "drop out of" the functional world, whereas a functional language like Haskell enforces functional purity throughout.

Good times to be a software engineer, nevertheless!

As long as Ethereum apps are powered by a deeply-flawed programming language (Solidity) and VM (EVM), this will happen over and over again.

Writing provable, secure software is difficult, and highly unlikely if your environment doesn't force the correct mindset. Solidity (poorly named) was made with the primary goal of being easy for JavaScript / Node hackers to use.

The cost of this is now illustrated through the repeat 'hacks' of bad 'smart contracts'.

Agreed. As a photographer, I use and love Guetzli, and it offers a bona fide size reduction of more than 30% over typical JPEG compression algorithms at a similar visual quality level.

But it's extremely computationally-intensive, taking over a minute to compress a single web-resolution image on my i7 laptop.

I can't see it being practical in a high-volume server scenario.

Ever since reading this essay 14 years ago (has it really been that long?!) I have always thought:

Haskell. He's talking about something like Haskell - but with whatever additional powers of abstraction and simplification mankind manages to dream up.

I say this, because I have yet to find such an elegant way of expressing computation. But, on the other hand, I have yet to find a "serious" language with as many performance land-mines, which possibly might just not matter given orders of magnitude more memory and computing power.

Given a couple of orders of magnitude, who cares that String = [Char]. It's damned elegant.

For everything else, I'll bet we will use the "C" of the 21st century - Rust :-)

JavaScript will probably continue tracking functional languages like Haskell for many years, albeit remaining without the type system that make them truly useful.

Thank you for re-posting this long-forgotten essay, and taking me down memory lane...