> There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims.
And this idea can be applied to so many things.
Seriously, very often things have enough downsides that you don't need to exaggerate things that are not downsides. You're actually weakening your side by doing so because if people cannot trust even that bit of honesty, why would they trust anything you say?
be trustworthy is the first rule in convincing others.
>The reality is which almost everyone can see is that memory safe languages are pretty much always what you want to be using for new code.
Not everybody is writing security-critical code. For some things productivity and time-to-market is more important and security is not enough of a concern to justify dealing with a language with horrible compile times and a self-righteous, dogmatic community.
> 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:
> the programming language used to represent a computer program has nothing fundamentally to do with whether it can be verified
That's not true. The design of a language can make it easier to verify with respect to certain properties. For example, it is much easier to verify that a typical Python program does not dereference dangling pointers than a typical C program.
It is true that open source does not help as much as some of its adherents like to think. But that doesn't mean that it doesn't help at all, and it is certainly not true that it cannot help substantially in principle even if it does not help much in current practice.
And yet, Go is a huge success in the industry, and one of the main reasons often given for chosing Go over a competing language, is how easy it is to get things started, how easy it makes the onboarding process, and how accessible and maintainable the code is.
> the type checking seriously helps you out when you are changing existing code
If you have Algebraic Datatypes in your codebase, which is not a given. Having a simple, easy to read language helps me out ALL THE TIME.
> But nothing is forcing you to use every feature of it.
And nothing forces C developers to use so many macros that their libraries resemble a completely different language where everything I thought I learned about C flies out the window. Nothing forces Python devs to use nested dictionary-comprehensions, that are, ironically, completely incomprehensible. Nothing forces C++ developers to use generics everywhere, regardless of whether they are actually needed or not.
And yet, that is, unfortunately, what is often happening in the wild.
The point here is; If a language offers X, then X will be used. And it will be used in smart ways, it will be used in unnecessary ways, and it will be used in not-so-smart ways. It will be used when it makes sense, and when it absolutely doesn't.
The thing the developers of Go figured out, and which, in hindsight, is surprisingly obvious, is that there is exactly one, and only one, foolproof way to prevent that from happening: By not having X in the language.
> Of course I could be dealing with a bias because as a novice programmer I worked on simpler programs and now I work on more complex / powerful programs.
The software techniques you've listed are among the reasons why it's even possible to build more complex and powerful programs. Forward progress in software is always resisted by the contemporary programmers of the day who are deeply fond of their chosen anachronism and don't like it when they perceive the feeling that it is threatened by a newcomer. This is an ancient law of software that few seem to accept, but c is to assembly as python is to c and javascript is to python. Software developers tend to be thoughtful people, these tools exist for a reason.
I agree with that regarding learning them, but I disagree strongly when it comes to the end result.
I make a lot of my money fixing/replacing PHP projects. As has been pointed out many times before, there are issues with PHP that are guaranteed to cause bugs. The same is true of many languages.
But there is a spectrum! Some compilers/interpreters scream at you and terminate if you contradict yourself. Some of them even recognize security vulnerabilities.
I agree that people skills, domain knowledge, and architecture are hugely important, but great teams are still less effective when they use slow or confusing tools.
You might be the greatest contractor in the world, but if someone asks you to build a skyscraper with plywood and super glue, you're going to end up with something dangerous, fragile, and guaranteed to fall apart as soon as someone tries to use it.
>I am involved in scientific programming, and it's getting kind of crazy. This is a domain where programming is purely utilitarian, and what you are programming is more important.
In my experience this leads to a lot of bad programming by people who only care about the utilitarian aspect, not about maintainability, user experience or failure modes.
Scientific programming would benefit the most from a stricter language that catches errors early on. Especially because most of the participants are usually not software engineers that have some semblance of a chance to catch errors in C++. Even they make a lot of mistakes.
> From my point of view, all languages which don't add anything new and improved are a drag on our collective computing experience.
I couldn't disagree more. The more people writing languages and implementing standard libraries the better.
Are these minor languages going to be used in production? An even smaller minority of them, sure.
For the majority of them it's a chance for developers to relearn data structures and algorithms and compilers. Real, hands-on practice that is hard to beat with any other method. I only got decent at algorithms and data structures by implementing languages and standard libraries.
I'd rather every developer built their own language.
>This is not a good thing. The shorter the learning curve, the quicker you run out of ways to improve your work.
I disagree with this. There are many languages that are perfectly productive which are reducible to a very small core: Haskell, Standard ML, OCaml, Modula-2/3. The size of the ecosystem is an extrinsic property to the language.
Simple languages are easier to learn, easier to implement, and it's easier to understand code written in that language, since the semantics are simpler. Very rarely does language complexity buy you anything except painful surprises or obfuscated code contest entries.
For example: Rust is a much simpler language than C++ and you can use it to do essentially anything reasonable you'd want to do in C++.
> So yes, just because you use a functional programming language won't help you sell your widgets or make a great product. And you can spend lots of time fucking around with it for its own sake and still not sell widgets or make a great product.
It comes down to trust. You're either fucking with your code in a powerful programming language that lets you do everything, or your fucking with the language restrictions to get your code to compile in the first place.
You can either go eat at McD's which sells pre-cooked burgers from minimum wage employees which kills the flavor and the taste of the meat being served but is extremely safe, or you can go to an upscale burger joint where artisans grind their meat in house and cook it to a perfect medium rare.
> And simplicity is a core tenet of the language design. To sacrifice that would be to admit defeat entirely. We could have just been using C++ all along.
Well that was my point it. Turning Go into something like Java or C++ will make it not Go any more.
> We didn't build Go in order to have arguments on a mailing list.
Not sure many popular languages were built for that. But arguments on mailing lists is what you get. Quite often the smarter people are, the better they are able to veil things like disappointments, personal dislikes, and others in technical arguments. I have seen it in private meetings and public discussion forums. The inertia of defending something vigorously and then having to back-pedals is unpleasant.
> I need something that […] has interoperability with decades worth of C, C++ and Fortran code.
Assuming you meant more than having a good FFI…
When I judge the suitability of a language for a task in the abstract, I systematically ignore 2 very important factors: legacy code, and skill availability. I do as if everyone know every language, and we start from a mostly blank slate.
If I didn't ignore those factors, I wouldn't be judging the languages, I would be judging whole ecosystems, introducing a huge status-quo bias in the process.
---
The C+ you look for is probably possible. I bet it could be implemented a la CFront.
>Anyone else agree with this view ? Programming languages should be choosen based on technical merits, rather than who is behind it.
Absolutely not. Technical merits are only part of the considerations.
Big companies, for example, where the stakes are higher, never chose languages on their technical merits alone. The also look at the owner/stewardship of the language, and in many case, roll their own languages, to avoid being at their mercy.
> It's very interesting that people form such a personal bond with programming languages, to the point where they will refuse to see how they could be perceived as bad, or cumbersome.
From what I've seen and personally experienced, this happens most often when someone is only strong in that one language. If you've only ever used that language to build applications and someone comes along telling you it sucks, it feels like a personal attack because it would mean you've been doing things wrong or your code/applications suck. It's part of an identity. As people learn new languages and actually gain professional experience with them, that original language is no longer what defines them as a programmer so they no longer need to defend its legitimacy.
And this idea can be applied to so many things.
Seriously, very often things have enough downsides that you don't need to exaggerate things that are not downsides. You're actually weakening your side by doing so because if people cannot trust even that bit of honesty, why would they trust anything you say?
be trustworthy is the first rule in convincing others.
reply