What makes programming languages easy and why you want one that isn't
fiedzia.blogspot.com
fiedzia.blogspot.com
What I don't like is the implied "only people doing stuff that I think is hard are real programmers." The author seems to believe that people chose "easy" languages because they are less skilled as a programmer (see the bit at the end). Which is forgetting the original point, which is that languages all have their strong points.
While it's true that I wouldn't trust someone trying to write an OS kernel in Javascript, I also wouldn't trust someone writing a web page in Fortran. There's a difference between hiding complexity when you need access to it (what the post is complaining about) and unnecessarily inviting complexity. Being able to understand when to choose between them is the real desirable trait.
Edit: I'm also not sure how relying on the language to guarantee safety is much different from relying on a complex beastie like a c++ compiler to be correct.
...or, the language has separate modes where you can or can't use the feature. Which is an argument for Rust's 'unsafe mode', actually. But nonetheless, the "modes" are still additional complexity compared to 'simpler' languages like C.
So, maybe the real underlying point is that Rust is cool and you should use it. Not that I would know, I haven't actually used it.
I'd attribute it to Fortran having become a very specialized language, with most of its users basically indifferent to a lot of the shinier new features because they just don't add much for that niche.
The point would be that Rust complexity pays off, even if it is not cool to deal with it (I do love it for that, others may not).
Yup.
That's not exactly my what I want to say. My point is more like "You may not see a point in becoming a soldier and its not a career for you, but be glad that those who defend you have big guns, so stop complaining that they are heavy".
> I'm also not sure how relying on the language to guarantee safety is much different from relying on a complex beastie like a c++ compiler to be correct.
Compiler are way more likely to be correct then people who use them. Problem with C++ (that Rust is trying to solve) is that the correctness of the compiler does not translate to correctness of compiled code, just as correctness of your text editor does not guarantee that you won't make typos, if it doesn't provide spellchecker. (I really like this analogy)
You might want to try saying that a different way; this metaphor is a problem.
It comes across as a slightly more colorful way of putting down people who use other languages as not "real" programmers - you're saying they should find another career. Or at best, maybe they are real programmers but they should be using harder languages?
In practice, most of the important code that everyone relies on to defend us (assuming here you mean security-critical or safety-critical code) is not written in Rust. So who are the real "soldiers"?
There's certainly a case to be made for using safer languages for critical code. On the other hand, using stricter static analysis for existing languages (and other kinds of testing like fuzz testing) will find bugs quicker and avoids boiling a few oceans.
This is not my intention.
> In practice, most of the important code that everyone relies on to defend us (assuming here you mean security-critical or safety-critical code) is not written in Rust. So who are the real "soldiers"?
Rust is relatively new. The real soldiers who use C bravely fight with of-by-one errors and buffer overruns and I really don't want them to do that.
> There's certainly a case to be made for using safer languages for critical code.
We can afford using safer languages for a lot of code.
> On the other hand, using stricter static analysis for existing languages (and other kinds of testing like fuzz testing) will find bugs quicker and avoids boiling a few oceans.
No, it will not. It may find few bugs here and there, but will leave whole classes of problems untouched. You can't bolt security onto a language. And we do not want to find few bugs, we want to be sure they are not there.
Though, I agree with the sentiment that we need languages like C or Rust etc. People who are dismissive of the value of systems languages are as silly as people who dismiss "easy" languages. I will say, which I bet you'll agree with, that I think dismissing the value of languages like C is the worse of the two mistakes to make.
I'm planning learn some functional language this year. There is a lot of Haskell developers in Rust community who came for performance and some ties to functional programming. I've just seen presentation about patterns in functional languages (https://www.youtube.com/watch?v=E8I19uA-wGY - strongly recommended) and I like it so far. Getting hardware mechanics out of your way is amazing boost for productivity (I know that from using python).
> dismissing the value of languages like C is the worse of the two mistakes to make
I have Rust now for things that must be fast and low-level, so I do not need C anymore. It served us well, but a lot has changed since it was invented.
Yes! This is why I prefer languages with stronger type systems. The more classes of errors a compiler can pick up, the fewer tests I have to spend time writing & maintaining, and I feel so much more confident about running that code in production.
I pretty much agree with this sentiment except for when someone is able to explain WHY they did it in such and such language that seems completely ill suited (in my mind) for the task at hand. I'm generally okay if someone's reason is as simple as "Because no one else is and I wanted to see if I could." To me, that shows curiousity, which I'm always okay with.
I've gotten to what I'd consider 'expert'* level with four languages. I've gotten to the point where I feel like without studying or too much brushing up I could go get hired as a senior in another 4 or 5. At the end of the day, I really don't care if X or Y language is my favorite or strongest if I know they're particularly ill-suited for the task at hand. If it's a coin-flip, well, then my biases win.
If it's an internal tool that just needs to do something small and I've got about two days to proof the concept, I may very well throw it down in PHP. Mostly because my Python is slower than my PHP. The core of our 'real' applications are written in Java.
I use a lot of Node.js to replace what I used Perl for back in the day. Then I actually started getting okay (as good as a mortal human can be) at awk and sed because Node can require more boiler plate than I want and I didn't want to go back to Perl.
I've always believed that the language your building in is a means to an end. Either you're simply doing it just to learn and explore, or you're trying to feed yourself. There's no right or wrong in either. But if you're paying the bills you owe it to everyone involved to pragmatically solve the problem- forego the beautiful and elegant and arcane for efficient, stable, and supportable. Unless you're getting paid for arcane, then go full Hogwarts.
*
In my mind expert is how confident I feel about my skills with that language. The small likelihood of me running into a language (not to be confused with framework) issue I've never even tangentially heard of, and my ability to rapidly get from idea to shipped. As well as my ability to know, as I'm putting down code, where I'm going to need to optimize or be protective because of how the language works. Not premature optimizations, but that my style has evolved to come out in a more optimal way just to begin with.
If hypothetically you have a legitimate reason to write a Javascript OS kernel then go for it. I'm struggling to imagine what those might be, but hey if you can justify it after weighing other options seriously then that's good engineering.
Fun and educational value are different though. Those are ends unto themselves and not just a tool to achieve a goal. I think pretty much anything goes there.
If I'm only going to run a script every few months and high performance isn't necessary, why should I pick a "hard" language like C rather than a scripting language like Python? The same holds true conversely; I don't want to use Python for code that has to run close to the metal.
Furthermore, if I need to iterate quickly, I wouldn't use something like C where there are too few abstractions for me to program at a quick-enough rate. If I work at a company like Google I presumably have enough money to buy all the computing power I should need, so performance of the code isn't as important as developer time. Or, if I'm prototyping some software and I want to work out the kinks in the architecture, why should I spend more time programming in C than just throwing together a quick solution in Python?
Something else:
>If you do anything I am relying on, I do not want to hear that you use such "easy" language, period. If you are careless enough to rely on people not making mistakes, I do not want to deal with you.
Most mature, high level ("easy") languages are relatively bug free for most use cases. Even if you're using a "hard" language, you're still relying on other people not making mistakes---whoever made your compiler, whoever made the processor and hardware your machine code is running on. Are you to say that you don't even want to deal with yourself?
Google and other big cloud shops care a lot about energy usage actually, and contrary to popular belief many server-side applications are CPU and memory-usage bound.
Energy consumption is important on mobile as well.
Indeed they do. If you have one server, or a 100, doubling that is not a problem. If you are Google, doubling your energy use requires finding new country to provide it.
Latency a major contributor as well. Sometimes, you're just up against CPU, and latency can be closely tied with revenue.
Languages and their libraries - yes. That's because they were battle-tested by users for a long time (and failed them many times). New programs written in those languages do not inherit those properties. However I referred to C here. Consequences of mistakes there are serious, modern high level languages (probably most, if not of them) do not have such problem.
> Even if you're using a "hard" language, you're still relying on other people not making mistakes---whoever made your compiler, whoever made the processor and hardware your machine code is running on. Are you to say that you don't even want to deal with yourself?
I'd rather not rely on a compiler written in C, if that is what you ask me. Of course I do due to vast amount of existing code, but for new things we have better languages now. Modern compiler and hardware authors do use languages providing strong guarantees (even mathematical proofs) and do not expect you to write millions of loops by hand perfectly. I will not trust unaided human to do a good job at implementing hardware or compiler and there is a lot examples of things getting horribly wrong when they try.
What if those proofs have a mistake, or the program you use to verify those proofs has a bug in it? What if the machine you're using has a bug in its processor, or somewhere else?
You said that you won't deal with anyone who relies on other people. Your criterion of "anyone" also implies "yourself". By your own argument, unless you yourself personally have verified that every single line of code in your program, every single assembly instruction in your machine code, every single molecule in your computer is correct, you cannot even "deal with" yourself. Have you verified those things yet?
It's simply not feasible to trust nobody when nowadays there are so many layers of abstraction. (Not to mention that your original comment was somewhat pretentious.)
Successful languages create their own ecosystems. It's odd to focus on syntax or concepts when the ecosystem built around the language (tools and libraries) is usually just as important.
Yet I don't agree with OP that higher level => harder to maintain. I guess my reasoning comes from your second point: Good ecosystems create ways for programs written in high level languages to maintain maintainability (see Flow.js).
I'd say that the important factor is the cost of a bug, not project size. There are many small project that absolutely crucial to get right, as well as some large ones that are not. I do not have a problem with people choosing what they need, only with the fact that (sometimes superficial) simplicity becomes the only factor in this decision.
This to me is a bit absurd. First of all, the "easy" language he's referring to here is C, and if I read this correctly it sounds like he's saying any software written in C is not worth using, which is patently absurd.
Regardless of whether that's actually his viewpoint, programs and libraries which are well-written, in any language, are simply tools which one can use without needing to worry about what language they're implemented in or whether or not the author used generics or pointers or whatever. Language matters if you're writing the code, reading it, or linking against it, and otherwise it's not worth worrying about (as a general rule). Of course, if the tool or library in question is slow or resource intensive, this might be due to language choice, but poorly written, buggy, and underfeatured code can be written in any language. Choose the language that suits you, suits your team, and suits your project.
I'm saying that choosing C guarantees a lot of problems for users. You will have such amount of bugs, that as a user, I refuse to be your beta-tester.
> programs and libraries which are well-written, in any language, are simply tools
Some languages make creating well-written program much harder than others. There is strong correlation between "its written in C" and "it exposes your ssh keys".
> Language matters if you're writing the code, reading it, or linking against it, and otherwise it's not worth worrying about
It also matters when you estimate code quality and likelihood of your data being exposed or corrupted or a time from "it compiles" to "we feel safe to use it in production". Its not the only factor, and perhaps not the most important one in many cases, but I believe in value of formal verification more then I believe in humans ability to get millions of malloc/free pairs right.
> poorly written, buggy, and underfeatured code can be written in any language
Again, in theory yes, in practice some languages make it much easier than others.
Like I said in another thread; I picked C# for a project because the software needs to run in banks and deal with bank IT departments. That's Java/.NET and, because we needed apps as well and we were already proficient in Xamarin, we chose C#.NET. Not because I like the language (I do, especially for later versions) or think it is hard or easy, but because it fitted.
We wrote a prototype in Python before that and the first bank we worked with had the CTO looking very puzzled and then, after some research on their side, said they cannot have that in their infrastructure; Windows servers with Java/.NET they had. And the IT staff to manage that, not other 'esoteric' stuff. However, already before that, we started rewriting that prototype to C#, this was just an extra sign we did the right thing.
I do a lot of coding in PHP ; not because I particularly like it, but my clients ask for it, I have 100s of 1000s of lines of legacy code in it going back the end 90s. For my embedded work I would not (and cannot) use either C#/PHP so I would not try; assembly or C/C++ (or a Java subset).
Programming languages are tools; they are fun to play around with, but when doing real work (which includes side project), just pick something you can get shit done with the fastest/best (some balance between those) (that can be Haskell, Coq or Prolog as well; they do not have to be 'traditional' languages).
This is where I disagree. If you do that, you are trading quality for your convenience, and as (potentially) your user, I do want you to work harder.
Also: why do you want me to work 'harder'? That is a weird remark in this context potentially... I am very good at different assembly languages (mainly very restricted embedded ones like 8-bit with 16 kb etc); I would work really hard if I implement a SaaS for you in that but you really would not want me to.
If you choose the easiest thing for you instead of the one that provides some guarantees of quality for me, I may be the one who loses something here.
> How would they care if the end result for them is the same?
There is no issue if that's the case, problem is that it often isn't.
> I use Clojure as I have a lot of experience there; how is that trading quality for convenience?
I am not talking about this situation. You are clearly making well informed choice (and sufficiently good one for me). Functional languages do not fall into the "easy" scope I had in mind.
> Also: why do you want me to work 'harder'?
So that I am not left with never ending bug chasing or exposed customer data. I expect you to adhere to certain quality standards, not to bash some code as fast at possible for your convenience. Just that.
That was also the reason I mentioned the word balance in my comment; I was raised by a Dijkstra student (my father) and proofs were mentioned a lot; I studied under students of Dijkstra at the TUE when I went to uni. These people all would say you do not work 'hard enough' if you did not provide proof for your code and I am pretty sure you do not. Which means you balance your, in that respect (!), very sloppy code which you write very fast compared to when you add proofs, with stability and security which you and your users value? So why do you not work harder and provide 100% covering formal verification of your code? Because that would make little sense in most cases. So you balance.
I am not entirely there yet, but it is where I am aiming. I may not prove total correctness, but I already am close to proving (or make very likely) absence of certain types of bugs that comes from my compiler and language guarantees.
> So why do you not work harder and provide 100% covering formal verification of your code? Because that would make little sense in most cases.
I'd like to, but its not practical yet for me. And I balance. But every now and then we are getting tools that shift the balance a bit further, and the boundary of what's practical and acceptable moves too.
I think the GP and yourself have different values. I don't want to speak for him/her but I think I can relate: don't allow perfect to be the enemy of good.
I guess it heavily depends on who are you working with. If your users don't understand and don't require security, it will not be provided. My users often have customers who care about those things, so it goes back to me.
If you actually wanted quality, you'd pay them for it with your time and/or money. Otherwise, I congratulate you on the overwhelming display of a self entitlement that is entirely undeserved.
To large extent, its true. But still I expect that the mechanic servicing my car for some reasonable price will not disconnect breaks and I will not have to pay extra for not being killed. Whatever cost is required for that should be included in the base price, as I cannot imagine someone not willing to pay for it.
That's not even remotely comparable because that would be fraud or some other crime. You can safely assume that your open source software are not malware. That's all you get for "free."
In fact, you explicitly agree to use software all the time that has this in its license:
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
I consider work of substandard quality to fall into the same category. Maybe not to the same extent, but still. If I am using software you created for me (that I paid for) and it has a flaw that exposes my data that you could have prevent with proper quality standards, its a fraud for me (in the "unjustifiably claiming or being credited with accomplishments or qualities" part of definition).
> You can safely assume that your open source software are not malware. That's all you get for "free."
You get nothing for free obviously. But I assume we all here are getting paid, open source or not.
I have never once run into a problem that isn't easily solvable with Javascript. If anything I find it has the opposite problem, there's too many different ways to do particular things and unless others are using the same "subset" of the language that you are, their code becomes extraordinarily difficult to grok.
* No exceptions (practically) * no built-on ways of providing abstractions * No concurrency at all for a very long time * No way of dealing with binary data
Those things were added later (classes, webworkers, arrays) when they became absolutely necessary. But it started and lived for a very long time as very minimal language.
> I have never once run into a problem that isn't easily solvable with Javascript.
Swallowing errors. Code quality. Solvable with typescript and others, but I wouldn't call it "easily sovlable".
Not sure what you mean by "no concurrency". Perhaps you meant "no parallelism"?
Pointers are not complex, and pointer operations are not complicated. They are difficult for human to understand, but pointers are a most basic thing to CPU.
If your language doesn't have pointers, it almost certainly has references. At least for machines, pointers are simpler.
That's the understanding of simplicity I am fighting with. Yes, concept is simple. Getting it right in any non-trivial code is nearly impossible (without some form of verification).
Hopefully every single burden the language has its user juggle is one which provides good tradeoff, but generally people value performance, safety, ergonomics, and maintainability.
This leaves me wondering how the author would classify assembly or machine code.
If you want to go in this direction, I'd suggest writing 1's and 0's. Can't go wrong there :-)
Btw, I actually am writing some assembly. So far I've found it very permissive (and that bit me hard).
Were you expecting otherwise?
This is an international site. We're fortunate that non-native English speakers take the trouble to share their thoughts with us here. How many of us could read them if they didn't?