4 ms·
> If you build something that’s too difficult to learn, but very productive you’ll turn a lot of people off. Counterexample: C++. To a lesser degree, perhaps a
by MaxBarraclough 6y ago
> If you build something that’s too difficult to learn, but very productive you’ll turn a lot of people off.
Counterexample: C++. To a lesser degree, perhaps also Rust? (Disclaimer: I don't know Rust.)
> The problem is, within a few weeks of using any paradigm developers usually have built a repository of habits that keep them from making mistakes.
No, developers constantly make mistakes. Even after all these decades, C programmers are still writing code with buffer overflows. The way to solve that is to have better tools: use a safe language, or formally verify the C code. At this point, we know that it's not enough to hire brilliant C programmers and have them exercise care.
> Things have been getting better. The growth has just been in the ecosystems and not the paradigms themselves.
I don't think there's a bright line between these two.
Good progress is being made in making formal verification more approachable, for instance. This is no small thing, it takes hard work in computer science, but doing so lowers the barrier to the paradigm, making it more practical for more developers and for more problems.
Merely thinking up the paradigm, it would be neat to have tooling to verify that our code matches our formal model, is only the first step. In a sense the paradigm only really exists after the hard work has been done.
In a similar vein, recent advances in low-pause concurrent garbage-collection might broaden the scope of the problems that can be solved with garbage-collected languages.
> The legacy is the value, it can’t be thrown out.
I broadly agree. See the classic blog post from Spolsky, Things You Should Never Do, Part I, on how throwing out working code is very often a mistake:
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- WJW 6y ago> Counterexample: C++. To a lesser degree, perhaps also Rust? Are these actually counterexamples? While in absolute terms there may be a fair number of people using them, in relative terms the amount of people who know C++ and/or Rust is absolutely dwarfed by the amount of people who know "easier" languages like JS, Python and PHP. In this case "easier" refers to the amount of effort needed to pick it up and get some result on screen, not to the amount of effort to be a guru. I think for a lot of beginners productivity and even (memory) safety is completely irrelevant. They are not very productive anyway and their code crashes all the time because by definition they make beginner mistakes. What is more important for beginners is to keep up momentum and get through the initial hurdle of "I don't understand this" to the point where you start thinking "this is fun, I can make cool stuff". Rust and C++ solve professional problems, not beginner problems.
- Silhouette 6y agoWhile in absolute terms there may be a fair number of people using them, in relative terms the amount of people who know C++ and/or Rust is absolutely dwarfed by the amount of people who know "easier" languages like JS, Python and Ruby. Are you sure? JS is huge today, not least because it's the only game in town on what is currently the most popular easily accessible platform. However, I've never seen anything to suggest a huge difference between the number of programmers who know C++ and the number who know Python, for example. Both are very popular languages with at least a few million developers who know them. At that scale there's no reliable way to get an exact count and the difference doesn't really matter anyway.
- batty_alex 6y ago> However, I've never seen anything to suggest a huge difference between the number of programmers who know C++ and the number who know Python Anecdotal evidence here but, I hire for both and it’s definitely easier to find developers that actually know Python and what Pythonic code looks like.
- carlmr 6y ago>At this point, we know that it's not enough to hire brilliant C programmers and have them exercise care. I mostly agree with your points. In my experience (never worked at FAANG), the brilliant C programmer hypothesis is almost untested, since most companies hire mostly average C programmers. It's only logical that non-brilliant programmers will be working somewhere. Even if a company has a few brilliant C programmers on staff, they won't be able to find all the issues the mediocre programmers produce. This is why I think it's about time that any safety critical industry should think of retiring C in favor of safer alternatives. Rust would personally be my favorite since it solves most of the really terrible issues around memory management in C and C++ (mediocre programmers not being able to compile due to the borrow checker is a feature). Of course Rust doesn't have the necessary certifications yet, but industry would be wise to contribute. Such efforts are underway (Sealed Rust by Ferrous Systems), but I don't see big aerospace, automotive and industry sponsorship here, i.e. those who would benefit the most. There is a safer language that is certified that is often ignored, which is ADA. It's actually quite modern in terms of features since the 2012 release. It has some other concepts than Rust for safety, but that doesn't mean it's worse. The heavy lifting in terms of design and certification here has been paid for by the DoD and aerospace companies, so there's no reason other industries couldn't use it.
- MaxBarraclough 6y ago> the brilliant C programmer hypothesis is almost untested, since most companies hire mostly average C programmers. It's only logical that non-brilliant programmers will be working somewhere. Chromium has suffered from buffer-overflow issues, and that's a high-profile security-sensitive C++ codebase run by Google. > Rust doesn't have the necessary certifications yet, but industry would be wise to contribute I'd rather avionics code be written in verified SPARK than in Rust, but if they can build a rock-solid Rust compiler it would be good to have it compete in that space. I imagine it could be a nice alternative to MISRA C++, for instance. As you've probably gathered from my mention of SPARK, I agree with you that Ada is sadly overlooked. Turns out that the basic idea of an imperative language that's much like C/C++ but is much safer and better suited to automatic runtime checks, isn't a new one. Ada does this, it's existed since around 1980, it's mature, there are various compilers for it approved for life-critical work, and its performance matches that of C if runtime checks are disabled. It's comparable to Zig and Rust in that regard, but those languages aren't the first to aim for C performance with far superior safety properties. > there's no reason other industries couldn't use it. Right, especially considering the fine work done by AdaCore, who make their tooling available as Free and Open Source software. Perhaps Ada's reputation for being boring is its greatest vice, as well as its greatest virtue?