4 ms·

> 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

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

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.