Hacker News Reader

This reminds me of the "Principle of Least Power" and variations [1, 2] in relation to the design of various languages of WWW. Although that is supposed to describe languages that are not programming languages. E.g. [1]:

> Computer Science in the 1960s to 80s spent a lot of effort making languages which were as powerful as possible. Nowadays we have to appreciate the reasons for picking not the most powerful solution but the least powerful. The reason for this is that the less powerful the language, the more you can do with the data stored in that language. If you write it in a simple declarative from, anyone can write a program to analyze it in many ways. The Semantic Web is an attempt, largely, to map large quantities of existing data onto a common language so that the data can be analyzed in ways never dreamed of by its creators. If, for example, a web page with weather data has RDF describing that data, a user can retrieve it as a table, perhaps average it, plot it, deduce things from it in combination with other information. At the other end of the scale is the weather information portrayed by the cunning Java applet. While this might allow a very cool user interface, it cannot be analyzed at all. The search engine finding the page will have no idea of what the data is or what it is about. This the only way to find out what a Java applet means is to set it running in front of a person.

[1] https://www.w3.org/DesignIssues/Principles.html#PLP

[2] https://www.w3.org/2001/tag/doc/leastPower.html

> imperative programming is easy to understand by humans

It's interesting that you choose C as an example because the absolutely immense numbers of bugs and security vulnerabilities directly due to C should, alone, lead us to question this. People might feel they understand C, but they're empirically wrong!

We can argue about why this is the case or whether it applies to other imperative languages, but it's pretty depressing we're still arguing about whether it is the case...

> the absolutely immense numbers of bugs and security vulnerabilities directly due to C

Isn't this simply a result of the absolutely immense amount of C being used in critical systems? Are functional languages empirically more secure?

The immense number of C bugs is not merely due to C's popularity. Other languages lead to less buggy and more secure code.

This is largely due to memory safety. However, immutability is also known to reduce bugs and be more secure (as many security related bugs are due to mutability). Lastly, superior concurrency constructs also have this bug-reducing effect.

That said I haven't looked into empirical studies. But I feel like it is just factually the case, at least for memory safety, that in most other languages you literally are unable to create entire classes of bugs that are possible in C. So just logically thinking about it, I don't even see why you'd need to see empirical studies. It should be quite obvious!

Although it'd be cool to see the empirical research too! Maybe someone else can reply with links to studies.

> But I feel like it is just factually the case,

Aka truthiness. [1]

Or when this is asserted for safety, safyness. [2]

[1] https://en.wikipedia.org/wiki/Truthiness

[2] https://blog.metaobject.com/2014/06/the-safyness-of-static-t...

Memory safety is literally the only relevant topic in this whole thread whose impact isn't "truthy" in that sense! We can measure how many bugs and security vulnerabilities in real projects are memory issues, and we know that a memory safe language would rule those bugs out by construction.

And we have! This blog post[1] is a good starting point, linking to a number of studies. Empirical evidence is never perfect, but that's much stronger evidence than we have for the impact of pretty much any other aspect of a programming languages!

[1]: https://alexgaynor.net/2020/may/27/science-on-memory-unsafet...

Your mistake was taking @chillpenguin at their word when they said "I feel". That was just a hedge, it is factually the case that memory safety eliminates an entire class of bugs. More accurately, it pushes them down to the garbage collector and runtime, where they can be epsilon close to eliminated, instead of rolling fresh ones in each and every program.

I’m a bit sad that people in functional programming circles seem to think this way, because to me, it feels like a pretty flagrant disregard for the obvious. No offense intended at all, but please consider: is it possible you are mentally comparing C with a language that is generally memory safe? Like Lisp or Haskell?

Understanding code and programming languages doesn’t prevent you from making mistakes. Advanced type systems can help, but you can put those in imperative languages too, and they do have their own pitfalls and limitations. Obviously, nothing is a panacea. But I think programming paradigms are neither here nor there...

Yes, it's a function of memory safety. The abstractions C provides for working with memory and the semantics of the language itself are both design choices it makes. Memory safety is one of the few places where we have robust empirical evidence on how it directly prevents bugs and security issues in practice. Robust empirical evidence is fundamentally hard to come by in software engineering research, so when we do have it, it's a strong signal.

The conclusion is that C is not simple and that the C model is not somehow "more natural" or a good fit for how people think. This was the core argument of the comment I was responding to and it is simply wrong, regardless of whether we're comparing C to functional languages or to something else. We should collectively not be drawing any conclusions by starting with C as an exemplar of how things should be.

Personally, I am certain that other aspects of C also contribute to extra bugs: implicit type coercion, undefined behavior, the C preprocessor and anything to do with concurrency all come to mind. I did not bring those up because we do not have the same kind of strong evidence for their impact and because just one problem of that magnitude should be enough to show that a language is neither simple nor natural.

I don't see how any of this is disregarding the obvious. Instead, I am making an obvious point that the original comment somehow disregarded. "Nothing is a panacea" might be true, but that does not mean that some things can't be better and other things can't be worse. C is one of the latter.

C does plenty of things badly - for another language in the same realm, consider Zig. It has sane metaprogramming and it can actually abstract over things without hacks like “we will always have this struct in another one with a pointer preceding it so we can decrement the object pointer” and macro magic (text based macros are simply the worst thing ever)

> hacks like “we will always have this struct in another one with a pointer preceding

A struct embedded within a different struct gives simply a bigger struct, which is something we have decided is a good idea (as opposed to e.g. attribute lookup in dynamic scripting languages).

The unfortunate thing is that there is no way to check statically that an inner struct that you hold in your hand is indeed embedded within a larger thing. But that is the kind of assertion that is incredibly hard to prove in a simple framework without complicating things, so the better idea seems to not do it. (Also it's the kind of assertions that seldom wrong once you've tested a tiny bit).

> (text based macros are simply the worst thing ever)

Are they?

Consider how many actual bugs were caused by text macros, and then consider how many useful things you can do with them that you simply cannot do with AST based macros.

What about dynamically replacing said inner or outer struct? You get absolutely no insight on the intent of the developer. That’s why actually joining a C project is really hard. C simply sucks at abstraction, and can only manage it through convention, without enforcement.

Please show me any IDE that can reliably refactor huge C projects. Compare it to eg. Java. The difference is night and day — what even is the point of text based macros? You have to parse the AST either way, why not manipulate that? And you can say that at the time memory constraint or whatever, but it is simply a terrible idea all around. You are basically running sed through your code.

> immense numbers of bugs and security vulnerabilities directly due to C

If K&R were here they might argue that it's perfectly possible to write a memory-safe C compiler, runtime, or abstract machine, and indeed there are multiple examples of same. Certainly memory-safe compilers and runtimes were (and still are) available for Pascal and Object Pascal/Delphi.

Unfortunately, from the 1970s to the 2000s memory safety (along with software reliability/security) was often considered much less important than speed and efficiency. Along with this, much C code depends on unreliable assumptions.

Of course the speed and efficiency vs. reliability and security trade-off was made in hardware design as well, with predictable results.

Ironically, one reason that Unisys keeps selling ClearPath MCP (nee Burroughs) it is not that a couple of companies are using a mainframe created in 1961, which anyway has had its evolution path anyway, rather there are security levels where a UNIX clone is just not desired at all.

Programming languages don't win because they are inherently better. Programming languages win because they fill a need better, or are more familiar.

There are better languages than other, that help people to write better code, have bugs be easier to find, push better paradigms. But thats not what decides a programming language winner. A winner helps someone do X faster or with less effort. If better languages want to win they need to both be better, and be first to tackle niche X before a worse / familiar language does. And do it sufficiently significantly better to overcome the "familiarity benefit" a worse language will get that enters the same space.

A not perfect example - typescript is almost the exact same language as JS and it took almost a decade for people to realize that unless you're writing small solo projects TS is better in just about every way. That is a best case scenario for comparison. Identical syntax, fully backwards compatible. On "language" a complete subset of the other (so no wars about losing a to gain be so is the trade off worth it), almost no new paradigm to learn and it still took our industry almost a decade to agree that it's universally better. If it takes that long to evaluate a clear cut case, its strong evidence that language benefit is not what primarilt drives language adoption.

I've been around since the arguments about how Python would never be adopted because "white space was significant and that's a terrible syntax choice." That its distracting and takes mental focus. I've seen all the arguments. When a syntax is different it slows adoption drastically. Not because its worse but people we're humans. People don't like change. Then Python solved a need bettet then everything else and it took off. And once you use Python regularly you see how absurd those whitespace arguments were.

JS and its approach took over because that's what the web was written in. If the language of the web had been chosen to be Lisp (as almost happened), everyone would be using Lisp right now without giving it a second thought.

> Well, I have. I want languages more like Go and Zig. People will always hate at least Go, but it didn't hit TIOBE top 10 out of sheer baseless hype and corporate sponsorship.

Given how succesfull Oberon-2 and Limbo have been in the market without someone like Google behind them, or having a biased Go advocate at the same company push for a project rewrite from Java into Go, yes it did.

I read about this notion often and the deeper truth behind it seems to be that abstractions are hard and they tend to be harmful if done wrong.

At the same time there are clear, obvious benefits of abstraction, which is why we don't typically write in machine code. This means that the goal is to create the right abstractions and not just throw our hands up in despair.

Using the popularity of Go as a metric is interesting, because it is a language that was designed in an environment with very large amounts of code and high fluctuation. It was targeted at the programmers that are replaceable cogs in a very large system, so it has to accommodate the lowest common denominator. One of the great features of the language is how easy it is to learn. (But they went too far, leaving out parametric polymorphism which is a feature they are now working on for years.)

Something that is easy to use and understand typically has a broader appeal. However, other environments want different things from programming languages. The appeal of a Lisp for example is its expressive power, programming expertise scales with the language more strongly. At the other end of the spectrum we have languages like Rust and statically typed functional languages that have very strong guardrails, stronger runtime guarantees can be made in exchange for agility. Again, certain types of programmers who face certain problems are drawn to these.

So creating good abstractions is both hard and desirable and programming languages are itself abstractions and facilitate the creation of abstractions. But what is a "good" abstraction depends entirely on perspective, which includes problems, domains and people. This is why languages like Lisp are not going away, languages like Go are popular and why there is plenty of diversity in language design.

But then again, C++ has been top 5 TIOBE since the index began. And C++ is the poster child for complexity.