We don't program in assembly language because it is very tedious and error prone. Higher level languages absolutely do eliminate classes of errors that are only possible at the assembly language level (accidentally altering the stack and affecting the jump return address for example). Another example would be garbage collection making it impossible to create a certain class of errors.
Another example would be doing long division with roman numerals instead of Arabic. The human brain can only process so much before it becomes overloaded. By "compressing" thoughts using new vocabulary concepts you can reason about ideas that are beyond your normal cognitive limits.
For example, after learning ML, I started writing much more functional code even when writing Python. I also started using abstract types more, even in C.
This can be refuted in one.
if(a = b)
Other languages just don't allow assignment in 'if' statements.
In regards to floating point support, a language could default overload equality checks so that they are configurably fuzzy when comparing floats.
And of course, languages already prevent stupid mistakes. Even the humble C compiler properly arranges the stack for us when exiting a function, putting all return values in the appropriate place based on the platform's ABI and restoring registers that are supposed to be preserved.
In my 15 years of programming experience of programming every single day, I have made this kind of typo maybe 2 or 3 times in total and it took me less than a minute to identify and fix the problem each time.
On the other hand, the amount of time that it would have taken me to type out that extra ':' a few million times would have been much more costly.
Addressing this specific example, historically, running a linter all the time wasn't always practical, and `if(a = b)` was used intentionally a lot, e.g. to inline a check for a null pointer with an assignment.
Pardon my french, but that is some straight-up horseshit.
Even if you were the best programmer in the world, I would be skeptical at you saying that you make that kind of typo less than two or three times a year or per project, much less over the course of fifteen whole years.
I would agree that having equals-assignments as valid expressions is bad, I just don't think it's such a big deal. If you are using such a language, you should be using a linter anyway.
Using := would be very annoying for me, even though I can see the argument and would favor it in theory.
Or going back and forth between languages that use '==' and JavaScript?
Let's say over all of history there have been a million C/C++ programmers, and each of them has made that mistake ~5 times, in total.
And let's be generous and say that 95% of the time it was found before it got anywhere near production.
That is still 250,000 bugs introduced.
Not to mention how much time is spent tracking down the bug once it has been in the code base for awhile. If it goes unnoticed for a couple of weeks debugging becomes non-linearly harder.
That's a mistake I make often, but it's exactly because Javascript is different here from all other languages that I use.
Let's say I had to use a language with ':=' as assignment, I would still accidently type '=' all the time.
> Let's say over all of history there have been a million C/C++ programmers, and each of them has made that mistake ~5 times, in total.
> And let's be generous and say that 95% of the time it was found before it got anywhere near production.
> That is still 250,000 bugs introduced.
Well, so what? That's 250,000 out of maybe a hundred million bugs. I'm not saying it's good language design to have this behavior, quite the opposite. I'm saying it's not a big deal, especially considering all the other footguns in these languages. It's also not like these languages are going change it.
> A language cannot prevent someone from making stupid mistakes.
A very expressive language may have that ”:=” overhead while also providing many robust and useful operators too.
Yes, the product may look like line noise, but it was Uber efficient to create in basic cost terms
(let [x 1]
(if (= x 1)
...))Then I have a thought experiment. If language cannot determine the quality of your work, I would request that you write pong in brainfuck, and I will write pong in, let's say, javascript. Then we'll compare the quality of each implementation, and switch languages. Whoever wins in terms of quality in the first round would be expected to be the better developer, and so would win the second round handily.
Now that we've established that the quality of your work does in fact depend on the tools used to implement it, can we please reframe your original point in less absolute terms? Perhaps the programming language is not as important as people claim, and that given two projects in two languages of similar quality, the output should also be of similar quality?
How do we define similar quality? Is incremental improvement a worthwhile goal? Do different tasks require different features? I would much rather write a shader in HLSL than in BASIC.
https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
It tries to measure the defect rates between programming languages. To say it doesn't matter is too simplistic, in my opinion. I think matching the tool to the task is somewhat important, but often, as you suggest, you can get by with suboptimal choices and choose based on familiarity or esthetics. People would probably do better by spending their time learning how to think critically about code rather than learn a new language every year.
A language without strong types might make tooling more difficult, not catch certain errors at compile time, make refactoring harder, and make working in teams harder. Or it might have little impact on you.
A language without a GC will be more complicated for certain tasks as now you have to manage the memory. It's harder for beginners, and doesnt make sense in many environments. Then again a lack of GC may be necessary if you do embedded work.
A language might let you write in one line of code, while another would take 20 lines for it. Is that more expressive? Maybe it's harder to maintain?
Do you like white space? Maybe you do, maybe you don't.
Many interpreted languages are slower then their native counter parts. Then again if your application doesn't need much compute performance, maybe it's worth it? Or maybe not.
It's all pros and cons. You don't want to make a "hello web!" web application In assembly when ruby/python/etc can do it in a few easy to read and understand lines.
Completely prevent all possible mistakes? Of course not.
However, it certainly can make many mistakes either impossible or much rarer.
I do love Elixir, but for the kind of work I am doing currently, I'd have a hard time selling the benefits of it over just about any other language. But I dislike Java's verbosity, so unless Java brings something other options lack, I feel like pushing back on too much code being a legit reason to avoid Java.
Yes, there are still other types of bugs that are language-agnostic, but a language definitely can reduce the chance of creating a certain set of bugs in the first place.
This is false, unless I misunderstand you.
I track ~10,000 programming languages. Are you willing to bet that I can pick one of these languages at random, give you a task, and your output won't be affected by the language I pick?
The main inpediment in my opinion is:
- knowing the standard library
- knowing the available libraries
- syntax quirks
in that order.
The main advantages you gain from using a language is familiarity with a language and the three points above.
I will be much more productive in JS or Python than in Haskell just because I’m already familiar with thise two and I’m not familiar with Haskell.
The rest of advantages come from the ability of a language to express a programmer’s thoughts rwadably, concisely and in a maintainable manner (where “maintainable” means “a new colleague coming in to the project six months later”).
Many other languages are gendered and or structured, both of which do impact the work, both good and bad.
Great English can be written right along with crazy expression borrowed bits here and there, even words made up on the spot.
Do we need crazy expression in programming?
Technically, no. But many want it and practice it in creative ways not unlike writers do with form, structure and style.
With a story, did readers get value, even with poor understanding, or a reread or two making sense seems to be the bar.
With a program, does it do the job and doe it do so in a consistent way, secure, etc..
A look at things like COBOL, FORTRAN shows us design can impact quality. It is baked in.
Skill matters too.
An inexperienced programmer may produce higher quality earlier and more easily given such an environment. Adept ones can use most anything and do the same.
But, they may also be size coding, played ng in the demoscene as much as they are cranking out business logic and computation.
TL;DR; Language absolutely does impact quality, but so can experience and process. No easy outs, no one size fits all.
I don't buy into fads either but this is not a fad. It is common sense. The quality of your own skill and the tools you use affect the overall quality of your work. To say that one has no affect is illogical.
Just look at the extremes of your statement. If it was true, I should be able to write a triple A game in assembly language because assembly language affects the quality of my work. Obviously this is not true. If I tried to do one in assembly language the quality would be subpar.
> A language cannot prevent someone from making stupid mistakes.
In Elm it is not possible to have runtime errors. The program cannot crash period. The only type of error you can have in elm is a compile error or logic error.
This is an example of a program preventing stupid mistakes.
If novelists followed the same approach as programmers and they kept trying to find the perfect language to write their books in, they wouldn't manage to publish a single interesting novel.
A language cannot prevent someone from making stupid mistakes. At best, it solves one set of familiar problems and replaces them with a new set of unfamiliar (but equally bad) problems; then you have to learn to cope with those new problems until the next hyped-up language fad comes along claiming to solve those new problems and then you repeat the cycle.