Thankfully there are two different words with very separate meanings that people nonetheless tend to conflate [1]. "Simple" means "not many features", and "easy" means "good to get things done with".
[1] Maybe because we have lots of people speaking English as a second language? In my mother tongue, German, there is no distinction in vocabulary between "simple" and "easy". Both translate as "einfach".
Though if we want to make the clear distinction, like in the Clojure talk below, for the programming domain that’s fine.
I'm not sure about this. What utility is a language with only simple constructs that is hard to use.
Not quite a counterpoint, but a thought in that direction is:
There can be features that make it easy to implement something which some find hard to understand.
I suppose I question the value of simplicity for it's own sake in a language and would rather defer to how simple and understandable the resulting code is.
I frequently consider the added complexity cost of a more complex compiler inherent complexity because I find the simplicity of use dwarfs compiler simplicity or simplicity "just cuz".
Sure, you may not be touching those during your web development, but that’s because you don’t know how to have fun and outsourced it all.
> it would be a tad slower
a tad? I'll use C++ as an example, but the last time I profiled a hash map in C++ vs C#, the C++ lookup took 1 nanosecond[0] and the C# version took 1ms (1000x slower) (I don't have these metrics anymore but I believe it was one ms or slower, and Google seems to confirm that).
Now, if the difference between C++, a machine compiled language, and C#, a runtime compiled language, is 1000x for a very common operation, how much slower will an interpreted language that is running at an even higher level be??
The reason 90% of our apps are such slow trash these days is because programmers think that there is no difference in a couple milliseconds when it is a huge difference if that couple milliseconds is being run thousands of times through hundreds of thousands of lines of code! Take a look at how fast the Jai compiler is compared to a modern C++ compiler. Or even a C compiler vs a C++ compiler. It's night and day because of how much cruft slowly gets added on.
So I find your claim that most of the Unix utilities are only written in C because that was mainstream in the day highly dubious. If anything, they would be written in something like Rust today, but definitely not JS or Python.
Edit: I would also like to point out how much of a pain it would be to write low level network code, like what's necessary in curl, in a language like Python. When you're writing low level net code you want as little interference between the bytes and the programming language. Because if your bytes have some hidden padding, or the endianess is swapped, or a data structure is aligned a byte off, it means the difference between between correct transfer over the net, and sending garbage over the net. Python is not conducive at all to understanding how an object will be transformed into q series of bytes, whereas C is almost a direct translation from a struct to a series of bytes.
[0]: https://gist.github.com/ambrosiogabe/66a6e2fdc77e6a600e570f4...
Regardless, the benefit of not using C++ is and always has been: Not having to use C++.
C# benchmarks on my machine. FastFindRecipe just does a hash set lookup, it looks like this:
private static readonly HashSet<CraftingRecipe> FastList = new HashSet<CraftingRecipe>(new CraftingComparer());
public static CraftingRecipe? FastFind(CraftingRecipe r) => FastList.TryGetValue(r, out var res) ? res : null;
| Method | Mean | Error | StdDev | Min | Max |
|--------------- |---------:|--------:|--------:|---------:|---------:|
| FindRecipe | 315.2 ns | 1.17 ns | 1.09 ns | 313.6 ns | 317.4 ns |
| FastFindRecipe | 124.5 ns | 0.23 ns | 0.21 ns | 124.1 ns | 124.9 ns |Two orders of magnitude.
If you have to have multiple structures that need to be precisely laid out in binary, python is the wrong tool for the job. Delivering content using Tcp or Udp packets requires very explicit binary definitions of the data your sending. Sure you can use a wrapper on top of a library that deals with the low level stuff, and that's what Python is all about.
Use the proper tools for the proper jobs. If you're using C to write one off scripts or simple data manipulation like analyzing csv contents or something, then you should probably use a higher level language instead. If though, like curl, you have to be very explicit about the binary description of objects to accurately send and receive those objects between a network, then use a low level language.
> runtime isn't the constraint that we're hitting anymore
If you're sending data over the network you're absolutely hitting this constraint. Reading some data from RAM is on the order of like nanoseconds, sending data over the network is on the order of hundreds of milliseconds depending on the size and location you're sending that data. When it comes to sending data over the network, literally every byte does matter.
It seems like you were advocating using a higher level language for low level, systems programs. If that's the case I disagree. My original argument was about Unix utilities. Unix utilities contain everything from "list the files in a directory" to "compile this C program". The original poster was talking about how Curl would probably be written in Python if it was written today. This is just incorrect. From the author of curl[0]:
>> If I would start the project today, would I’ve picked another language? Maybe. Maybe not. If memory safety and related issues was the primary concern I had, then sure. But as I’ve mentioned above there are several others concerns too so it would really depend on my priorities.
> If you're talking low level microcontroller stuff, or bit banging, sure, do it in C if you like.
This is the argument I'm making. Unix utilities are usually dealing with low level bit banging stuff. Unix utilities are also meant to be extremely portable. C is the glue that holds all programming languages together, whether we like that or not. So programming a library in C automatically ensures that the library can be used in practically any higher level language.
The ratio between 1 ns and 1 ms is a million.
https://floooh.github.io/tiny8bit/
https://floooh.github.io/sokol-html5/
https://floooh.github.io/visual6502remix/
The common pattern is though that both the C and C++ stdlib are mostly useless for this type of project, you need cross-platform libraries where 'cross-platform' also includes peculiarities of the web browser runtime, specific language features are (mostly) irrelevant in this case - except maybe for the bit twiddling thing in the emulators where C is clearly superior to JS (plus you get lean native versions "for free" without requiring a heavy Electron runtime).
For example, I consider most multi paradigm languages complex because in them functions, variables, objects, control flow, etc. are fundamentally different concepts.
But something like LISP, smalltalk or Haskell are simple in my eyes, due to almost everything being the same concept on a fundamental level and the other stuff being built on top of that concept.
Conway's game of life has an incredibly simple definition, and is Turing Complete. The Brainfuck language has a minimal number of language concepts and barely any syntax. And yet, programming in these languages is very hard.
Humans need a certain level of language complexity to be able to express themselves. When you simplify things it's not always clear if you're removing superfluous complexity, or removing tools needed to deal with inherent complexity of the problems you need to tackle.
I don't think there's even any single objectively appropriate level of complexity, because it depends on the complexity of the problem the language tackles. By analogy to human languages: scientific language has its own jargon (sometimes overused!), but it needs an extended vocabulary to precisely describe the things and problems it works with. Without the added complexity it'd be unproductive due to being verbose and sometimes ambiguous, like the amusing example of Up Goer Five: https://xkcd.com/1133
Specifically what I wanted to express, is that, for me, the turtles all the way down is what I understand as simplicity.
And yeah, simplicity alone can't be used as a value judgement.