4 ms·

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 t

by gh02t 10y ago

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.

Qwertious 10y ago
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.
- greglindahl 10y ago
  Fortran is an example of a language that has pointer support, and few Fortran programs need to use pointers. Contrast that with C/C++.
  - gh02t 10y ago
    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.
    - fiedzia 10y ago
      I've been told that pointers in Fortran provide some guarantees that C does not (was it no aliasing?), and that makes big difference for compilers.
- fiedzia 10y ago
  > So, maybe the real underlying point is that Rust is cool and you should use it. 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).
ReverseCold 10y ago
Kernel in JS? Yup. https://news.ycombinator.com/item?id=7958194 https://news.ycombinator.com/item?id=7958194
fiedzia 10y ago
> 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)
- skybrian 10y ago
  > You may not see a point in becoming a soldier 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.
  - fiedzia 10y ago
    > 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.
manyxcxi 10y ago
> 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.
- gh02t 10y ago
  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.

by gh02t 10y ago

Qwertious 10y ago

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.

greglindahl 10y ago
Fortran is an example of a language that has pointer support, and few Fortran programs need to use pointers. Contrast that with C/C++.
- gh02t 10y ago
  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.
  - fiedzia 10y ago
    I've been told that pointers in Fortran provide some guarantees that C does not (was it no aliasing?), and that makes big difference for compilers.
fiedzia 10y ago
> So, maybe the real underlying point is that Rust is cool and you should use it. 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).

ReverseCold 10y ago

Kernel in JS? Yup. https://news.ycombinator.com/item?id=7958194 https://news.ycombinator.com/item?id=7958194

fiedzia 10y ago

> 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)

skybrian 10y ago
> You may not see a point in becoming a soldier 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.
- fiedzia 10y ago
  > 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.

manyxcxi 10y ago

> 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.

gh02t 10y ago
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.