It was built by nerds but optimized on the data of everyone, so it ended up appealing mostly to the average person.
Maybe that's also the solution to a question I've had for years. The ads I see on diverse social platforms are terrible, but if they are matched with algorithms that try to fit me in as an average person, then it makes sense that, as a huge nerd, they miss the mark.
It isn't, the haters are the ones that don't get that there are many OOP flavours, mostly they only learnt one way and naturally everything is like that.
The original VB and Self are two other well known examples where there is no inheritance support.
Also most Lisp systems inspired in The Art of Metaobject Protocol tend to focus on multi-methods, instead of inheritance, to change current behaviours attached to structs.
Some prototype based languages use delegation instead of inheritance, so people assume that is the case for Self as well. The difference is subtle. But as you pointed out and Mario Wolczko said: "Self is like Smalltalk, only more so". There were also languages with neither inheritance nor delegation but that still included some scheme for sharing.
I sometimes "hate", exactly because of people having learned one flavour of OOP, usually the Java flavor of "everthing must be a class" and trying to shoehorn everything into that style of programming, insisting that inheritance must be had, even though many people have already learned the lesson of composition over inheritance, and even though one of the most popular newer languages, Rust, doesn't even have inheritance or classes. Also the "mutate everything from everywhere, as long as I have a setter"-style.
That dogmatic Java-flavor-OOP and their ideas of translating design patterns 1-to-1 to other languages like Python, disregarding the language specifics and language design choices ... ugh, such a PITA.
That's where my guards are going up, and I start observing very closely, what that person's understanding of OOP is, and whether they merely throw out buzzwords, or actually know something about what they are talking about.
When using so called OOP languages I specifically avoid inheritance, and in fact I think it's the worst aspect of it. In any case, I tend not to include inheritance into the definition of object orientation.
The problem was he exposed too much of the implementation into the language itself, destroying its ability to be a simple reference implementation that others could re-implement.
That's at best a partial fix for the API side. Python side CPython sill exposes a LOT of implementation details, and as a result occasionally projects will choose to rely on some of these details. Then other implementations need to decide whether to also pick the same implementations details and expose them, or use different details, and lack compatibility with any library that depended upon them.
The python documentation has historically also not been especially clear at distinguishing between what the language guarantees, vs what is just implementation details of the cPython implementation. So even if libraries wanted to try to avoid depending on implementation specifics, it isn't always clear what those are.
The net result is that for the end user python the language is effectively: whatever cpython does. This really, really discourages creating alternate implementations, as the only way to be an alternative implementation with good compatibility is to be a living fork of cpython, constantly merging in all the changes from it, while also maintaining your improvements.
Last release on Oct 14. Beta support for 3.12. It's not that bad really and 1/10 of the people who complain about it did something then the situation would be better.
On Margaret Hamilton from Chapter 5 of Hackers by Steven Levy
"She was well aware of the hackers’ playfulness around the ninth floor, and she was moderately friendly with some of them, even though they would eventually blend into one collective personality in her memory: one unkempt, though polite, young male whose love for the computer had made him lose all reason."
> I'd rather my language surface problems at compile time (via type errors) for all possible code paths rather than a particular codepath at runtime.
The kind of problems caught by compile time type checking are less fine grained than those that can be caught at run time. For more exploratory programming, one would prefer the latter.
At compile time, one checks that they are passing around correct types, at run time, the actual logic of the program is exercised.
People tend to underestimate to what extent pre-LLM programming experience contributes to their ability to steer LLMs in the right direction and produce decent results.
In 5 to 10 years, we'll see what kind of engineer is produced from pure LLM steering without years of hand coding experience. Even many of the more experienced ones would have some of this skill atrophied.
Presumably a DSL would allow you to do more heavy lifting in your specific domain with less tokens.
Let's way you wanted to do a web application using LLMs. Using a web framework would cost less tokens than using the vanilla underlying language (Python, PHP, whatever..), which is again way less tokens than building up from assembly (an LLM should be able to do this given enough time and compute).
I hadn't thought of that! Writing a program in fewer tokens* has been Lisp's advantage all along. If, because of token economics, the same advantage accrued at the LLM level, I dare say certain people would be pleased (as would I):
I came to the same conclusion over the last year. The Lisp family, especially used with a CL REPL, present a lot of inherent advantages for agentic coding.
Ironically, this comment of mine from a few days ago touches on a lot of the points from this article and was flagged to death:
But writing good DSLs requires one to be great at going up the ladder of abstraction. Not that LLMs can't do it, but they stuggle and choose the path of least resistance. That's easier even if it results in more code.
Depending on the shell, `somedir/*` excludes files whose names start with "." and may expand to a literal "*" if there are no file names to expand to. Basically, globbing has more edge cases to deal with.
reply