3 ms·

If you ignore the clickbait use of the word 'reasonable', then there are some valid points made here. The question is – what's the benefit? There are definite

If you ignore the clickbait use of the word 'reasonable', then there are some valid points made here. The question is – what's the benefit? There are definite benefits to using a language that it's easy to reason about. In most cases, there's also a cost. That's fine – it means we've got the ability to trade off one against the other as the situation requires. I'm unlikely to write tiny, single-use scripts in a strict, statically-typed language – mostly because the overhead isn't worth it. Similarly, systems that require higher levels of correctness can benefit from the guarantees that are offered by stricter languages. We have to bear in mind that the entire field of programming languages is still very much evolving, as we gain experience of what works and what doesn't. Type inference, for example, can drastically reduce the overhead of type checking. Or option types, which eliminate a class of errors by providing support for common patterns. No doubt as the field evolves, we'll see that languages emerge which deal with the pain points of both 'reasonable' and 'unreasonable' languages.

klibertp 12y ago
> We have to bear in mind that the entire field of programming languages is still very much evolving, as we gain experience of what works and what doesn't. Type inference, for example, can drastically reduce the overhead of type checking. I'm sorry, it's just too much for me. Yes, PL theory advances and yes, there are many new, interesting ideas being presented each year. That's true. But your example, "type inference", dates back to the sixties. Similarly for "option types". Using these as an example of "evolution of entire field of programming languages" would suggest this evolution happens at a glacial pace. Which is indeed true for the so-called mainstream languages, but "the entire field" is much, much larger than those, moves far quicker and comes up with much more interesting ideas every year.
- matthewmacleod 12y ago
  Yes, it does. But you're totally ignoring the practical ramifications of this – the fact that ideas that are only now making it into mainstream programming languages is a strong indication that the entire endeavour is more complex than you're admitting. We don't just pull language features out of our collective arses and start using them. Evolution does happen at a glacial pace – we stick features into minority-appeal languages; they kick around a bit; people rediscover these features later, and maybe they eventually end up in popular languages. But there's a huge amount more involved in that process than simply coming up with the feature - testing, maintainability, long-term implications, unforeseen complexity, programmer acceptance, performance constraints… the list goes on.
  - klibertp 12y ago
    > testing, maintainability, long-term implications, unforeseen complexity, programmer acceptance, performance constraints… the list goes on. No, it's actually just "programmer acceptance" and secondary reasons like amount of money poured into marketing or language being tied to an OS. I'm not very pleased with this. In this talk: https://thestrangeloop.com/sessions/the-sociology-of-programming-languages https://thestrangeloop.com/sessions/the-sociology-of-program... it's said that probability of language being used is "potential gains/pain of adoption" ratio. That's true. Language designers, at least the ones who want their languages to succeed, constrain themselves to make it as painless as possible for "normal programmers" to pick up. Nobody seems to notice that there's another option of making denominator smaller: all you need is to become better at adopting new technologies. But this somehow doesn't work, because... Probably because of long-term implications or performance constraints, right.
stcredzero 12y ago
If the past 30 years of coding tells us something, one of those things should be that the line between statically typed and dynamic languages is blurring. Boundaries between scripts, the application, the programming language, and the OS are blurring as well. Future languages should have highly flexible deployment, and be able to "feel" like both a "scripting" language and an "enterprise" language. There is a big problem with this, however. The entrenched infrastructure and toolset reinforce the "separate" mindset. A useful analogy with which to think about this: The level of granularity we inherited for computer security from the 60's and 70's was to protect one user from another on the same machine. Now, we know we need much finer levels of control, which is why mainstream OS now have "capabilities" or their functional equivalent. However, this took a long time and met much resistance, because the industry as a whole couldn't mentally move beyond a security model developed for timeshare users on a 60's "mainframe."

klibertp 12y ago

> We have to bear in mind that the entire field of programming languages is still very much evolving, as we gain experience of what works and what doesn't. Type inference, for example, can drastically reduce the overhead of type checking. I'm sorry, it's just too much for me. Yes, PL theory advances and yes, there are many new, interesting ideas being presented each year. That's true. But your example, "type inference", dates back to the sixties. Similarly for "option types". Using these as an example of "evolution of entire field of programming languages" would suggest this evolution happens at a glacial pace. Which is indeed true for the so-called mainstream languages, but "the entire field" is much, much larger than those, moves far quicker and comes up with much more interesting ideas every year.

matthewmacleod 12y ago
Yes, it does. But you're totally ignoring the practical ramifications of this – the fact that ideas that are only now making it into mainstream programming languages is a strong indication that the entire endeavour is more complex than you're admitting. We don't just pull language features out of our collective arses and start using them. Evolution does happen at a glacial pace – we stick features into minority-appeal languages; they kick around a bit; people rediscover these features later, and maybe they eventually end up in popular languages. But there's a huge amount more involved in that process than simply coming up with the feature - testing, maintainability, long-term implications, unforeseen complexity, programmer acceptance, performance constraints… the list goes on.
- klibertp 12y ago
  > testing, maintainability, long-term implications, unforeseen complexity, programmer acceptance, performance constraints… the list goes on. No, it's actually just "programmer acceptance" and secondary reasons like amount of money poured into marketing or language being tied to an OS. I'm not very pleased with this. In this talk: https://thestrangeloop.com/sessions/the-sociology-of-programming-languages https://thestrangeloop.com/sessions/the-sociology-of-program... it's said that probability of language being used is "potential gains/pain of adoption" ratio. That's true. Language designers, at least the ones who want their languages to succeed, constrain themselves to make it as painless as possible for "normal programmers" to pick up. Nobody seems to notice that there's another option of making denominator smaller: all you need is to become better at adopting new technologies. But this somehow doesn't work, because... Probably because of long-term implications or performance constraints, right.

stcredzero 12y ago

If the past 30 years of coding tells us something, one of those things should be that the line between statically typed and dynamic languages is blurring. Boundaries between scripts, the application, the programming language, and the OS are blurring as well. Future languages should have highly flexible deployment, and be able to "feel" like both a "scripting" language and an "enterprise" language. There is a big problem with this, however. The entrenched infrastructure and toolset reinforce the "separate" mindset. A useful analogy with which to think about this: The level of granularity we inherited for computer security from the 60's and 70's was to protect one user from another on the same machine. Now, we know we need much finer levels of control, which is why mainstream OS now have "capabilities" or their functional equivalent. However, this took a long time and met much resistance, because the industry as a whole couldn't mentally move beyond a security model developed for timeshare users on a 60's "mainframe."