5 ms·

What makes programming languages easy and why you want one that isn't

29 points by fiedzia 10y ago

pvg 10y ago
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.
- fiedzia 10y ago
  Both hide memory management from you. Which works great until it doesn't.
  - pvg 10y ago
    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 :)
    - fiedzia 10y ago
      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".
BigJono 10y ago
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.
- fiedzia 10y ago
  > 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".
  - inimino 10y ago
    If you think JavaScript didn't have ways of providing abstractions until classes were added, you don't know JavaScript.
  - spion 10y ago
    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"?
- chillacy 10y ago
  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.
  - fiedzia 10y ago
    Pretty much this. I should have made this clearer.
- spion 10y ago
  Yeah. I wonder if JavaScript is the only language where you can tell a non-user from a mile away...
tylerhou 10y ago
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?
- slavapestov 10y ago
  > 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.
  - fiedzia 10y ago
    > 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.
  - sargun 10y ago
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.
tormeh 10y ago
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.
- fiedzia 10y ago
  > 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.
drtz 10y ago
> 3. Give the developers ultimate freedom and let them do whatever they want. If the compiler never complains, beginners are happy... Example: C. This leaves me wondering how the author would classify assembly or machine code.
- fiedzia 10y ago
  > 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).
  - thinkpad20 10y ago
    > I actually am writing some assembly. So far I've found it very permissive Were you expecting otherwise?
    - fiedzia 10y ago
      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.
      - lowmagnet 10y ago
        I think assemblers won't have that sort of protection because they don't assume you're going to run on the same arch as your build.
        fiedzia 10y ago
        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.
tluyben2 10y ago
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).
- fiedzia 10y ago
  > 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.
  - tluyben2 10y ago
ekvintroj 10y ago
Just one thing: consistency. It's a shame that the author didn't mention Smalltalk.
- fiedzia 10y ago
  I don't have experience with it. I see a point in consistency as an important factor here though.
novia 10y ago
Your post had three spelling errors in it before the end of #1, so that's where I stopped reading.
- SmooL 10y ago
  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.
  - novia 10y ago
    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.
    - SmooL 10y ago
      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?
- dang 10y ago
  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?
  - novia 10y ago
    My apologies to fiedzia. I did not realize you were a non-native English speaker.
threatofrain 10y ago
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.
thinkpad20 10y ago
> 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.
- jeffdavis 10y ago
  You are ignoring the security implications of using buggy software; and the risks that users of C code are taking.
- fiedzia 10y ago
  > 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.
xiaq 10y ago
> 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.
- fiedzia 10y ago
  > 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).

29 points by fiedzia 10y ago

pvg 10y ago

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.

fiedzia 10y ago
Both hide memory management from you. Which works great until it doesn't.
- pvg 10y ago
  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 :)
  - fiedzia 10y ago
    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".

BigJono 10y ago

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.

fiedzia 10y ago
> 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".
- inimino 10y ago
  If you think JavaScript didn't have ways of providing abstractions until classes were added, you don't know JavaScript.
- spion 10y ago
  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"?
chillacy 10y ago
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.
- fiedzia 10y ago
  Pretty much this. I should have made this clearer.
spion 10y ago
Yeah. I wonder if JavaScript is the only language where you can tell a non-user from a mile away...

tylerhou 10y ago

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?

slavapestov 10y ago
> 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.
- fiedzia 10y ago
  > 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.
- sargun 10y ago

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.

tormeh 10y ago

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.

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

drtz 10y ago

> 3. Give the developers ultimate freedom and let them do whatever they want. If the compiler never complains, beginners are happy... Example: C. This leaves me wondering how the author would classify assembly or machine code.

fiedzia 10y ago
> 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).
- thinkpad20 10y ago
  > I actually am writing some assembly. So far I've found it very permissive Were you expecting otherwise?
  - fiedzia 10y ago
    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.
    - lowmagnet 10y ago
      I think assemblers won't have that sort of protection because they don't assume you're going to run on the same arch as your build.
      - fiedzia 10y ago
        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.

tluyben2 10y ago

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

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

ekvintroj 10y ago

Just one thing: consistency. It's a shame that the author didn't mention Smalltalk.

fiedzia 10y ago
I don't have experience with it. I see a point in consistency as an important factor here though.

novia 10y ago

Your post had three spelling errors in it before the end of #1, so that's where I stopped reading.

SmooL 10y ago
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.
- novia 10y ago
  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.
  - SmooL 10y ago
    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?
dang 10y ago
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?
- novia 10y ago
  My apologies to fiedzia. I did not realize you were a non-native English speaker.

threatofrain 10y ago

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.

thinkpad20 10y ago

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

jeffdavis 10y ago
You are ignoring the security implications of using buggy software; and the risks that users of C code are taking.
fiedzia 10y ago
> 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.

xiaq 10y ago

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

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