Emacs is a bunch older than common lisp.

One of its more idiosyncratic design decisions was using dynamic scope, rather than lexical scope. They did add in per-file lexical scope, though.

It also just doesn’t implement a lot of common lisp’s standard library.

Emacs unfortunately uses Emacs lisp, not common lisp or scheme.

Yeah, projects also exist in the real world and practical considerations matter.

The legacy C/C++ code base might slowly and strategically have components refactored into rust, or you might leave it.

The C/C++ team might be interested in trying Rust, but have to code urgent projects in C/C++.

In the same way that if you have a perfectly good felling axe and someone just invented the chain saw, you’re better off felling that tree with your axe than going into town, buying a chainsaw and figuring out how to use it. The axe isn’t really the right tool for the job anymore, but it still works.

C is not how a computer truly works.

If you want to know how computers work, learn assembly and circuit design. You can learn C without ever thinking about registers, register allocation, the program counter, etc.

Although you can learn assembly without ever learning about e.g. branch prediction. There’s tons of levels of abstraction in computers, and many of the lower level ones try to pretend you’ve still got a computer from the 80s even though CPUs are a lot more complex than they used to be.

As an aside, I’ve anecdotally heard of some schools teaching Rust instead of C as a systems language in courses. Rust has a different model than C, but will still teach you about static memory vs the stack vs the heap, pointers, etc.

Honestly, if I had to write some systems software, I’d be way more confident in any Rust code I wrote than C/C++ code. Nasal demons scare me.

Right tool for the job, sure, but that evolves over time.

Like, years back carpenters didn’t have access to table saws that didn’t have safety features that prevent you from cutting off your fingers by stopping the blade as soon as it touches them. Now we do. Are old table saws still the “right tool for the job”, or are they just a dangerous version of a modern tool that results in needless accidents?

Is C still the right tool for the job in places where Rust is a good option?

MicroSD cards are better, here. They’re 250mg; a pigeon can transport 75g. That’s 300 microSD cards, ignoring the weight of the SD card enclosure.

It’s a real quote, from the 80s, published in a networking textbook.

It’s amusing, but it’s always been a serious and occasionally practical observation.

IPoAC is a joke about printing actual IP packets, sending them by pigeon, then scanning them.

You do the whole usual TCP ACK/SYN thing, but with pigeons.

It’s not the same as ‘sneakernet, but strapping microsd cards to a pigeon’. It’s way, way sillier.

I’ve never actually used PHP.

Does it still have random Hebrew in error messages like ‘unexpected T_PAAMAYIM_NEKUDOTAYIM’?

Prescriptivism is mostly just an unprincipled mishmash of shibboleths someone pulled out of their rear end hundreds of years ago, classism, and knee-jerk reactions against language change.

For example - why do people distinguish less vs fewer to refer to countable vs uncountable nouns? Because someone wrote in 1770 that they thought that distinction was elegant, despite not actually reflecting the way English at the time was spoken.

Why is ain’t “not a word”? Because it originated in the speech of poor people, and was used less commonly by rich people. People roll their eyes at new business-speak because it comes from rich, powerful people, but look down their nose at language innovations from poor hillbillies and other disfavored groups.

And you can find writings from old prescriptivists complaining about literally every change in the language, such as hating the new ambigious use of singular ‘you’ when ‘thou’ was perfectly good and unambiguous or hating phrases like ‘very pleased’.

The old joke is that C++ is an octopus made by nailing legs to a dog.

So it should probably be a rifle-chaku made by connecting two Garands with a chain.

C# vs Java is also really weird since C# started out as basically a Java clone.

Would you really rather see <\Foo> than )?

There’s a reason why most popular languages use } rather than end if or fi. The added verbosity doesn’t actually help people read your code more than e.g. indentation or editors with paren matching or rainbow parens.

Python virtual environments feel really archaic. It’s by far the worst user experience I’ve had with any kind of modern build system.

Even a decade ago in Haskell, you only had to type cabal sandbox init only once, rather than source virtualenv/bin/activate.sh every time you cd to the project dir.

I’m not really a python guy, but having to start touching a python project at work was a really unpleasant surprise.

Are you using sealed hierarchies and records in your code base? Then pattern matching is appealing.

I’m reminded of the quip that “You can’t justify a bridge by counting the number of people swimming across a river”.

Syntax and language support makes a huge difference in how people write code. People generally take the path of least resistance in a language.

Being a much better language than Java isn’t exactly a high bar.

What kind of runtime tag corresponds to generics, exactly?

Python handles generics essentially the same way that Java 1.0 handles generics: it just kinda punts on it. In Java 1.0, list is a heterogenous collection of Objects. Object, in Java 1.0, allows you to write polymorphic code. But it’s not really the same sort of thing; that’s why they added generics.

It’s compile-time that has limitations on what it can do, runtime has none.

Ish.

There’s typing a la Curry, where semantics don’t depend on static types and typing a la Church, where semantics can depend on static types.

Haskell’s typeclasses, Scala’s implicits and Rust’s traits are a great example of something that inherently requires Church style typing.

One of the nice things typeclasses let you do is to write functions that are polymorphic on the return type, and the language will automagically pick the right one based on type inference. For example, in Haskell, the result of the expression fromInteger 1 depends on type ascribed to it. Use it somewhere that expects a double? It’ll generate a double. Use it somewhere you expect a complex number? You’ll get a complex number. Use it somewhere you’re using an automatic differentiation library? You’ll get whatever type that AD library defined.

That’s fundamentally not something you can do in python. You have to go with the manual implementation passing approach, which is incredibly painful so people do it very sparingly.

More to the point, though, limitations have both costs and befits. There’s a reason python doesn’t have goto and that strings are immutable, even though those are limitations. The question is always if the costs outweigh the benefits or not.

Bob Harper uses ‘unityped’ in his post about how dynamic typing is a static type system with a single type in disguise. I’ve literally never heard “monotyped” used as a term in a dynamic context.

In Types and Programming Languages, Ben Pierce says “Terms like ‘dynamically typed’ are arguably misnomers and should probably be replaced by ‘dynamically checked’, but the usage is standard”. Generally, you’ll see ‘tag’ used by type theorists to distinguish what dynamic languages are doing from what a static language considers a type.

Type systems have existed as a field in math for over a century and predate programming languages by decades. They do a slightly different sort of thing vs dynamic checking, and many type system features like generics or algebraic data types make sense in a static context but not in a dynamic one.

Basic stuff like maps aren’t easy to implement either.

This is mostly due to a preference for immutable data structures. That said, the standard library has a balanced tree-based map that’s not too complex.

If you want a good immutable data structure with O(1) find and update, you’re unfortunately looking at something like a hash array mapped trie, but that’s the same in e.g. clojure or Scala.

Haskell started out as an academic language.

The problem Haskell was trying to solve was that in the late 80s, there was a bunch of interest in lazy functional programming but all the research groups had to write their own lazy language before writing a paper on whatever new feature they were interested in. So they banded together to create Haskell as a common research program that they could collectively use.

It’s been remarkably successful for a research language, and has become more practical over the years in many ways. But it’s always had the motto “avoid (success at all costs)”.

There’s a bunch of companies that use Haskell.

Off the top of my head, Mercury is an online bank built on Haskell, Tsuru capitol is a hedge fund built on it, Standard Chartered bank has a big Haskell team in Singapore, and Facebook’s automated rule-based spam detection software is built in Haskell.

There’s also cardano, in the crypto space.

And various other companies might have a project or two written in Haskell by a small team.