7 ms·

Confessions of a Used Programming Language Salesman (2007)

49 points by alokrai 7y ago

tannhaeuser 7y ago
> To appreciate the difficulties of XML, let’s make a short excursion to the world of XML schema [...], which must be one of the most complex artifacts invented by mankind. The complexity of XSD is especially baffling since the existing solution, DTDs, is already a perfectly fine solution. Ah, the period where it was attempted to integrate XML as first-class type/literal into programming languages. I guess the conclusion can only be that what SGML/XML is designed to represent (namely, semistructured text documents with regular content models) was fundamentally misunderstood by folks wanting to represent (relatively benign) business records-like structures for service-oriented apps. The complexity results for statically type-checking programming languages having XML as literals were disappointing, and the whole thing got out of fashion. Then, shortly after Mozilla dropped E4X (XML literals in JavaScript), JSX and React happened. I honestly don't know what conclusion should be drawn here :)
- lmm 7y ago
  My conclusions would be: usability in the small matters. Overengineering is the natural fate of standards and must be fought at every turn. Insist ruthlessly on conciseness at the cost of virtually anything else (but not consistency; remember Perl).
  - tannhaeuser 7y ago
    Yes, and it's all the more ironic that XML started out as a simplified subset of SGML - only to turn into a monstrosity shortly after with W3C's XML Schema and WS-* "death star" series of standards.
- throwaway_pdp09 7y ago
  Tried to read the article but "We use cookies to ensure that we give you the best experience on our website. It seems your browser doesn't support them and this affects the site functionality." Yes indeed, no cookies = no article, displaying text apparently being 'functionality'. Anwyay, going from your quoted extract, I agree XML schemas are one of the most revoltingly complex and awful things I've ever seen, and badly at that, but to claim DTDs as being "a perfectly fine solution" is just ridiculous. DTDs give an overall structure, not any kind of typing that XSDs give. DTDs are a crude start, not an endpoint. Lord how I got to hate XSDs and XSLT. XML by itself is fine (in the right place) and I like it but it seemed to become the core of a everyone-lost-your-sanity frenzy. It was mad, very wasteful and I'm glad it's all over. Edit: only XSLT could be so godawful as to require a new mechanism to pass parameters. https://www.xml.com/pub/a/2004/03/24/tr.html https://www.xml.com/pub/a/2004/03/24/tr.html
- michaelcampbell 7y ago
  Early Scala's inclusion of XML as a thing baffled me from the start.
clarry 7y ago
Speaking of Haskell and laziness.. I found myself wondering last night, what was the issue with laziness again? I think it was that it's making it difficult to parallelize things. Why would that be? Is it just an implementation artefact, or are the rules of lazy evaluation actually disallowing the compiler/runtime from batching things appropriately for parallel computation? EDIT: Guess I was thinking of this: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.3806 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.3... > we have shown that lazy languages, even when implemented using a framework well-suited for parallelism, can generate only small amount of parallelism. [..] this result, when combined with the result concerning the low parallelism for really lazy programs, can also be interpreted as saying that there is not much hope for lazy languages as far as parallelism is concerned: in effect, they are saying that we can hope to obtain parallelism from programs written in a lazy language only when the programs do not need to be written in a lazy language! That's a really old paper though (1995), if there are more recent relevant studies or results, I'd be interested..
- lmm 7y ago
  The big problem with laziness is that it becomes impossible to reason about performance, because performance becomes noncompositional. If y = g(x) then we expect the computation time of f(g(x)) to be the computation time of g(x) plus the computation time of f(y), but in the presence of laziness that's no longer true. Any sufficiently large codebase hits a performance problem (usually a trivial one that ought to be easily resolved) eventually, and at that point you lose the ability to refactor fearlessly that's the great advantage of Haskell-like languages.
  - tome 7y ago
    Hmm, I'm not sure that's quite right. The time taken by f(g(x)) under lazy evaluation is known to be no more than the time taken under strict evaluation. It's the space usage that can be hard to predict.
    - reitzensteinm 7y ago
      It's not more operations, but that extra space usage can mean the difference between creating and freeing objects with bump allocation in Eden that fits in cache, and walking over the heap doing a full GC so you don't run out of memory. There's a very real difference between what a simplified model of time complexity says should happen, and what actually happens when the layer of abstraction underlying the ivory tower start to spring a leak.
Rochus 7y ago
The author compares himself with the prophet and apparently believes that the acceptance of functional programming languages requires intensive missionary work - just like with an ideology or religion. However, the history of science shows that the right knowledge always prevails in the end. If it is so difficult to get functional programming languages to market, either the time is not yet ripe, or there are better solutions.
- j-pb 7y ago
  Even though I kinda want to agree with that sentiment, there are plenty of examples where this is not true. Betamax vs VHS, IPV4 vs IPV6, Windows vs. Unix vs. Linux vs. BSD vs. Microkernels, fuzzy logic (of which we kinda inherited neural networks) vs symbolic systems. There are a lot of outside factors that inhibit the dissemination of even good ideas, social stagnation, networking effects, or sometimes even cultural preferences to flavour.
  - Rochus 7y ago
    It's not always immediately obvious - even in retrospect - why one technology was preferred over another. Perhaps the price was the decisive factor, or perhaps the additional effort required to achieve minimal benefits was considered too high and convenience triumphed. Paradigm shifts are not necessarily rational, but if you make the area of investigation large enough, the overall advantage will be evident in hindsight. You may know these ideas: https://en.wikipedia.org/wiki/Wisdom_of_the_crowd https://en.wikipedia.org/wiki/Wisdom_of_the_crowd
    - flir 7y ago
      What you've got there is a circular argument. You're defining "the right choice" as "the choice that was made".
      - Rochus 7y ago
        No, you cannot make this conclusion from my statement.
okareaman 7y ago
Orthogonal to the topic but Erik Meijer is hilarious
Bellamy 7y ago
That is a one misleading title.

49 points by alokrai 7y ago

> To appreciate the difficulties of XML, let’s make a short excursion to the world of XML schema [...], which must be one of the most complex artifacts invented by mankind. The complexity of XSD is especially baffling since the existing solution, DTDs, is already a perfectly fine solution. Ah, the period where it was attempted to integrate XML as first-class type/literal into programming languages. I guess the conclusion can only be that what SGML/XML is designed to represent (namely, semistructured text documents with regular content models) was fundamentally misunderstood by folks wanting to represent (relatively benign) business records-like structures for service-oriented apps. The complexity results for statically type-checking programming languages having XML as literals were disappointing, and the whole thing got out of fashion. Then, shortly after Mozilla dropped E4X (XML literals in JavaScript), JSX and React happened. I honestly don't know what conclusion should be drawn here :)

lmm 7y ago
My conclusions would be: usability in the small matters. Overengineering is the natural fate of standards and must be fought at every turn. Insist ruthlessly on conciseness at the cost of virtually anything else (but not consistency; remember Perl).
- tannhaeuser 7y ago
  Yes, and it's all the more ironic that XML started out as a simplified subset of SGML - only to turn into a monstrosity shortly after with W3C's XML Schema and WS-* "death star" series of standards.
throwaway_pdp09 7y ago
Tried to read the article but "We use cookies to ensure that we give you the best experience on our website. It seems your browser doesn't support them and this affects the site functionality." Yes indeed, no cookies = no article, displaying text apparently being 'functionality'. Anwyay, going from your quoted extract, I agree XML schemas are one of the most revoltingly complex and awful things I've ever seen, and badly at that, but to claim DTDs as being "a perfectly fine solution" is just ridiculous. DTDs give an overall structure, not any kind of typing that XSDs give. DTDs are a crude start, not an endpoint. Lord how I got to hate XSDs and XSLT. XML by itself is fine (in the right place) and I like it but it seemed to become the core of a everyone-lost-your-sanity frenzy. It was mad, very wasteful and I'm glad it's all over. Edit: only XSLT could be so godawful as to require a new mechanism to pass parameters. https://www.xml.com/pub/a/2004/03/24/tr.html https://www.xml.com/pub/a/2004/03/24/tr.html
michaelcampbell 7y ago
Early Scala's inclusion of XML as a thing baffled me from the start.

clarry 7y ago

Speaking of Haskell and laziness.. I found myself wondering last night, what was the issue with laziness again? I think it was that it's making it difficult to parallelize things. Why would that be? Is it just an implementation artefact, or are the rules of lazy evaluation actually disallowing the compiler/runtime from batching things appropriately for parallel computation? EDIT: Guess I was thinking of this: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.3806 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.3... > we have shown that lazy languages, even when implemented using a framework well-suited for parallelism, can generate only small amount of parallelism. [..] this result, when combined with the result concerning the low parallelism for really lazy programs, can also be interpreted as saying that there is not much hope for lazy languages as far as parallelism is concerned: in effect, they are saying that we can hope to obtain parallelism from programs written in a lazy language only when the programs do not need to be written in a lazy language! That's a really old paper though (1995), if there are more recent relevant studies or results, I'd be interested..

lmm 7y ago
The big problem with laziness is that it becomes impossible to reason about performance, because performance becomes noncompositional. If y = g(x) then we expect the computation time of f(g(x)) to be the computation time of g(x) plus the computation time of f(y), but in the presence of laziness that's no longer true. Any sufficiently large codebase hits a performance problem (usually a trivial one that ought to be easily resolved) eventually, and at that point you lose the ability to refactor fearlessly that's the great advantage of Haskell-like languages.
- tome 7y ago
  Hmm, I'm not sure that's quite right. The time taken by f(g(x)) under lazy evaluation is known to be no more than the time taken under strict evaluation. It's the space usage that can be hard to predict.
  - reitzensteinm 7y ago
    It's not more operations, but that extra space usage can mean the difference between creating and freeing objects with bump allocation in Eden that fits in cache, and walking over the heap doing a full GC so you don't run out of memory. There's a very real difference between what a simplified model of time complexity says should happen, and what actually happens when the layer of abstraction underlying the ivory tower start to spring a leak.

Rochus 7y ago

The author compares himself with the prophet and apparently believes that the acceptance of functional programming languages requires intensive missionary work - just like with an ideology or religion. However, the history of science shows that the right knowledge always prevails in the end. If it is so difficult to get functional programming languages to market, either the time is not yet ripe, or there are better solutions.

j-pb 7y ago
Even though I kinda want to agree with that sentiment, there are plenty of examples where this is not true. Betamax vs VHS, IPV4 vs IPV6, Windows vs. Unix vs. Linux vs. BSD vs. Microkernels, fuzzy logic (of which we kinda inherited neural networks) vs symbolic systems. There are a lot of outside factors that inhibit the dissemination of even good ideas, social stagnation, networking effects, or sometimes even cultural preferences to flavour.
- Rochus 7y ago
  It's not always immediately obvious - even in retrospect - why one technology was preferred over another. Perhaps the price was the decisive factor, or perhaps the additional effort required to achieve minimal benefits was considered too high and convenience triumphed. Paradigm shifts are not necessarily rational, but if you make the area of investigation large enough, the overall advantage will be evident in hindsight. You may know these ideas: https://en.wikipedia.org/wiki/Wisdom_of_the_crowd https://en.wikipedia.org/wiki/Wisdom_of_the_crowd
  - flir 7y ago
    What you've got there is a circular argument. You're defining "the right choice" as "the choice that was made".
    - Rochus 7y ago
      No, you cannot make this conclusion from my statement.

okareaman 7y ago

Orthogonal to the topic but Erik Meijer is hilarious

Bellamy 7y ago

That is a one misleading title.