If one of the bins has criteria like 'performance' and 'complexity, how do Java and Python both end up in it? This seems in the 'not even wrong' category to me but perhaps I wasn't able to follow the argument.
Yeah but you tie it to performance which, other than in specialized cases, is not really a limiting factor - i.e. the performance spectrum of python, js, go, Java. And why aren't js and go in that category? Having read the comments here, was this post intended as some kind of veiled bit of Rust advocacy? Not that there is anything wrong with that per se, I'm just trying to understand what you're on about to better inform you how you are wrong on the internet :)
Not advocacy per se, but undeserved bashing (and not just Rust - you may replace it anything that's non trivial for beginners). This is some response for posts saying "Rust is bad because I'cant get past compiler errors, while some other language will not complain at all, and that should be fixed".
I don't have a lot of experience with a ton of different languages. But it seems bizarre to me that he lists Javascript as an example of a language that is restricted and unable to do various things.
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.
> it seems bizarre to me that he lists Javascript as an example of a language that is restricted and unable to do various things.
* 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".
I think Promises cover the first two nicely; they are an abstraction that gets you back exceptions. Also interestingly enough, one that would be impossible to write in Go.
Not sure what you mean by "no concurrency". Perhaps you meant "no parallelism"?
Maybe he means that JS is a language where core language development is greatly outpaced by library development? The transition to ES6 is still underway (and has been for awhile), but javascript has had tons of more "advanced" language features added both on the 3rd-party library side (jquery, underscore, lodash) and the transpiling side (coffeescript, typescript) for ages now.
Why can't we accept that programming languages are just tools and we should pick the best one for the job?
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?
> 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.
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.
> Google and other big cloud shops care a lot about energy usage actually,
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.
Often times energy converts directly CPU, and therefore to $$$. I think I heard a quote that a 1% CPU utilization change in search was a $100M+ spending change. While the specifics are lost to me, in general, I'm not at all surprised.
Latency a major contributor as well. Sometimes, you're just up against CPU, and latency can be closely tied with revenue.
> Most mature, high level ("easy") languages are relatively bug free for most use cases.
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.
> 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.)
The reason this is political is that it's a group decision. As a solo hobbyist you can choose whatever you like. But once you write code someone else will read or maintain (at least potentially), then it becomes a political decision within a community of maintainers.
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.
Yeah, I can see how being in a team would make the decision different; I'm still a student and haven't had the chance to work on production projects.
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).
So the author has a great point, that languages are suited to different things. I like this.
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.
The problem with choosing between them is, you can't switch between them within a language - either the language has pointer-support or it doesn't. You commit to a language (and thus language-level features) at the start of a project and then you stick with it (unless you go polyglot or rewrite it, but whatever).
...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.
Pointer use is rare in Fortran, too. I only really see it used to create views into arrays. But Fortran has a ton of features that aren't used much, e.g. the OOP stuff (which I've never seen used seriously and I'm moderately experienced with Fortran in several flavors).
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.
> What I don't like is the implied "only people doing stuff that I think is hard are real programmers.
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.
> It comes across as a slightly more colorful way of putting down people who use other languages as not "real" programmers
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.
What are your thoughts on languages like Haskell? It certainly isn't simple or easy by any means, but it also isn't anything like nuts-and-bolts systems languages like C or C++. It gives you a lot of strong guarantees of correctness, but it's also pretty far removed from the mechanics of the machine. Lisp is another possible example, though in a different way.
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.
> What are your thoughts on languages like Haskell?
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.
> Compiler are way more likely to be correct then people who use them.
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.
> 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.
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.
Yeah, kind of my intent. IMO, the real job of an engineer is selecting compromises to stay within a budget, be it a financial budget, safety etc.
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.
The problem is that for small projects you want a permissive language. For big projects you want a restrictive one. Since projects are generally written according to the "worse is better" school of thought it's better for a language to make it quick to get going with a small project than easy to maintain a huge one.
> The problem is that for small projects you want a permissive language. For big projects you want a restrictive one.
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.
I didn't have much expectations, as I am doing it first time. But yes, I was hoping for a bit more hand-holding from asm utils. I've set wrong asm dialect and nothing detected that. Not the kind of friendliness I like.
It wasn't different then the one I was running on, it was different then I had code for. And it compiled. So either asm dialects have subtle differences that change semantics but not form, or asm silently ignores errors.
What is it with all the language picking and language wars? Maybe I just grew up in a good learning environment because I had to, computers were simply not fast and had very little memory; on my first home computer it only had built-in Basic so I started with that, but it was slow, so went to assembly but that was annoying for anything but games so went to Pascal and later C but that was annoying for business software, so I went to DBase/Clipper etc etc. I would say that 'a good programmer' is not that bothered by switching languages when it is the right thing to do for the job at hand. Whatever language that is, easy or hard is not very interesting in my opinion and experience.
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).
> 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).
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.
How am I trading those? The user has hardly ever anything to do with whatever it is built with? How would they care if the end result for them is the same? If I build a SaaS in C# because my clients will work on the sourcecode and only have C# employees while, for another SaaS project I feel I need a lot of JVM libs and no one will use the source code so I use Clojure as I have a lot of experience there; how is that trading quality for convenience? In that case it is a better tool for the job.
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.
I agree with what you say. I do not see the relation between working hard or picking difficult languages or frameworks and the points you make. But generally I agree with you here.
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.
> if you did not provide proof for your code and I am pretty sure you do not.
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.
So we agree largely again :) Basically it makes no sense to go far beyond what users ever want to pay; you will have to balance that. For projects that might end up there, I prove things (with Coq). Never 100% because it is really a lot of work to provide even proofs for small parts of the code base. But vital parts yes, for fun and profit. In that order.
If you are using Coq at all my post is not directed to you :-)
Right now I'm perfectly happy if software I rely on doesn't have trivial security vulnerabilities, does not fail silently and does not damage my data, anything above that is a bonus. It may not be much, but it still far above industry standards in many areas.
But users almost never care about the underlying technology. In my experience they care about usability above all else. Most the time they have no clue what's powering the other side and that's by design.
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.
> But users almost never care about the underlying technology.
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.
> 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.
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.
> If you actually wanted quality, you'd pay them for it with your time and/or money.
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.
> 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.
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.
> That's not even remotely comparable because that would be fraud or some other crime.
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.
Really? This isn't a post about the English language - the author is putting his thoughts down and sharing them. If it's written well enough you can understand it without trouble, then that should be good enough.
Proofreading is important. I get annoyed each time that I read a spelling error, so I operate by the 3 strikes and you're out method. If I had kept reading only to find even more errors, it would have been too distracting for me to pay attention to what the author was trying to say anyways.
I understand that proofreading and spelling are important, but there's a time and place for everything. In this context, this isn't one of those times. What do you really contribute by rejecting an article after 3 spelling mistakes that has nothing to do with grammar in the first place?
Please don't post rude, unsubstantive comments to HN.
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?
Programming languages are hard based on how many independent concerns they want the programmer to juggle in their communication with the compiler.
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.
> 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. And if I am working on ensuring high reliability, I will choose tools that provide as much guarantees as possible, artificial simplicity be damned.
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.
> he's saying any software written in C is not worth using, which is patently absurd.
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.
> 1. Restrict what language can do. Without pointers, you won't have to explain what pointers are and won't have to introduce complex mechanism to deal with them.
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.
> Pointers are not complex, and pointer operations are not complicated.
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).
71 comments
[ 2.8 ms ] story [ 139 ms ] threadI 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"?
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).
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.
https://news.ycombinator.com/item?id=7958194
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.
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 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?
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.
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?
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 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.
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).