5 ms·

Something that is often very hard to understand (it took me years to do so). Is that maintaining a language is insanely hard. Everything has a cost. Let me give

Something that is often very hard to understand (it took me years to do so). Is that maintaining a language is insanely hard. Everything has a cost. Let me give a good example: A few years back someone submitted a patch that improved the error messages in Clojure. Worked great, just a single extra "if" and a message. It was committed to master. Then people's code got way slower. Why? Well this was a often used function and that single if blew the JVM inline budget causing that function to never be inlined. And that improvement had to he yanked out. When we talk about patches for a language, we have to realize that if we don't want constantly breaking APIs we have to test that a patch doesn't break existing code, that it also doesn't slow down existing code (or at least not enough that users would care), that in all sorts of cases the JVM won't freak out and do something bad. Then we also have to make sure that the change doesn't restrict the language in the future. Does making some interface public mean it will always be public? Are we happy to keep it that way for all time? Taking all that into consideration, I have to sit back and say , yeah, maybe I'll just remember to only hand sets to the functions in `clojure.set`. Or maybe I'll help out by adding clojure.spec annotations for these functions so I can turn them on during testing. In the end, I'd much rather have a rough-around-the-edges language that takes a garbage-in-garbage-out approach, than one that breaks the API at every turn. Perhaps they aren't mutually exclusive, but it certainly takes a heroic effort, and a lot of prioritization.

lawpoop 10y ago
Sounds like there might be a potential for a dev and production codebase?
- msbarnett 10y ago
  This is in a sense what the clojure.spec work would allow -- dev time exceptions when you violate a function's contract that have no impact on production speed. For some reason the blog's author dismisses spec as irrelevant greenfield development, when it would quite neatly solve many of his complaints
- puredanger 10y ago
  That is one of the things we've been considering for a couple years and it's increasingly likely we will do so.
calibraxis 10y ago
Critiques from Clojure users should really try tradeoff analysis, as Hickey advocates. Which means I should analyze the costs of what I advocate, not just the benefits. For clojure.set/intersection (CLJ-1682?), Alex Miller clearly mentioned the speed consideration — one all users would have to bear. Not to mention spending time on this versus other things. Also, it was ironic to read elsewhere in the article, "Even more obnoxious, it was closed as wontfix. Apparently a single sentence in the docs is good enough for the Clojure team..." Then in the next paragraph: "I was treated pretty shabbily by..." (One can go on. Take the headline, "Ignorance or Apathy of Underlying Principles") Calling hardworking people (who do free work for one's own company) "obnoxious" and ignorant/apathetic seems shabby too. While demanding "fixes" from them, and putting down their "big highlights from the past year or so" (Transit, Transducers, Spec) with a backhanded "These are okay, I guess." I'd never tolerate a client/manager with that attitude about my hard work, and that's someone paying me. No wonder free software maintainers burn out.
- pdimitar 10y ago
  You're right and make a very good point. But that doesn't change the fact that there are bugs from 2009 which barely have comments or even a reasonable explanation. Me being a pretty average typer (~95 WPM) I could type 2-3 paragraphs detailing why I am against fixing anything, in no more than 6-8 minutes. So for 7 years such bugs to never even get a proper explanation is showing the maintainers as douchebags, not victims.
  - weavejester 10y ago
    You'd be maybe be right, if that was the only thing that the maintainers were doing. Speaking as a maintainer of several projects myself, it's all too easy for some issues to slip through the cracks.
    - pdimitar 10y ago
      I agree. I am a maintainer myself of a closed-source & commercial project. It's indeed extremely easy to miss out on a crucial piece of info. I am not gonna teach anyone how to organize information. For the time being I am writing absolutely everything that comes to my mind (or is raised by customers and teammates) in a private Trello board. Even if I close everything in it 3 years from now, I would have some peace of mind knowing that I tried my damnest to never miss anything. And that's it's written down somewhere and that I am aware that it's waiting my input or work. I was somewhat offensive simply because bugs 7 years old marked as "wontfix" without a tangible explanation is absolutely not OK for language maintaners. The jobs of the senior devs are usually very hairy because we're good in fixing messes and repairing things. I stand behind my opinion that you have to go back and fix your past mistakes every once in a while. You can't pretend you're 18-20 years old and only sprint ahead and be blinded by the glamour of the new and shiny features. Stuff periodically needs repairing, it's how it is.
Scarbutt 10y ago
You probably should have stated that you work for Cognitect.
pmarreck 10y ago
it's too bad the JVM inlining budget isn't configurable or hintable, that seems like a poor design decision to have to work around. Then again, the JVM probably wasn't originally intended to be the foundation for a dozen other languages
- ianopolous 10y ago
  It is with -XX:MaxInlineSize=35 (that's the default number of bytecodes to consider inlining)
  - jgalt212 10y ago
    OK, so can you develop with better error messages, and then ship to production a jar a faster version with the spartan error messages?
    - puredanger 10y ago
      We have been working on this off an on for a while and that's definitely an option.
  - pmarreck 10y ago
    So why couldn't they simply include the extra debug code and use that config for Clojure compiles?
    - twoodfin 10y ago
      HotSpot is a JIT, so that's a runtime option. You'd be asking anyone deploying a .jar containing some Clojure to add fiddly configuration. Not impossible, but one of the heavily advertised virtues of Clojure is that it can be deployed alongside Java code without anyone having to be the wiser.
    - puredanger 10y ago
      We general try to assume that the user has applied no special JVM options. Planning with that as a baseline is much better than requiring people supply a big soup of options.
platz 10y ago
It's also what happens when the implementation becomes the specification that others depend on, rather than having the implementation depend on a specification. In the former, any deviation, including bugfixes, from the existing implementation is a breaking change. Indeed, without a specification, it's debatable whether any behavior is actually a bug or not.
slantedview 10y ago
You seem to be sidestepping some of the points made by the OP, particularly where certain bugs defy conventions laid down in other parts of the language. Garbage-in-garbage-out is fine so long as it's done in a consistent, well-understood way across the language (ie: throwing IllegalArgumentException). It seems to me that instead of being a strategic approach for dealing with such issues in a consistent way across the language (clearly this is not the case), your arguments are just an excuse for not fixing the damn issues (if that's what you're getting at). And that is truly bizarre.
- kevinwang 10y ago
  But it seems to me that throwing an exception would be the opposite of a garbage-in-garbage-out philosophy.
  - jgalt212 10y ago
    The extreme version of this is PHP. Seemingly everything computes in that language with often very unexpected results (a least from what as my then PHP amateur status--coming from C).
pmarreck 10y ago
Why couldn't they just bump up -XX:MaxInlineSize=35 ?

lawpoop 10y ago

Sounds like there might be a potential for a dev and production codebase?

msbarnett 10y ago
This is in a sense what the clojure.spec work would allow -- dev time exceptions when you violate a function's contract that have no impact on production speed. For some reason the blog's author dismisses spec as irrelevant greenfield development, when it would quite neatly solve many of his complaints
puredanger 10y ago
That is one of the things we've been considering for a couple years and it's increasingly likely we will do so.

calibraxis 10y ago

Critiques from Clojure users should really try tradeoff analysis, as Hickey advocates. Which means I should analyze the costs of what I advocate, not just the benefits. For clojure.set/intersection (CLJ-1682?), Alex Miller clearly mentioned the speed consideration — one all users would have to bear. Not to mention spending time on this versus other things. Also, it was ironic to read elsewhere in the article, "Even more obnoxious, it was closed as wontfix. Apparently a single sentence in the docs is good enough for the Clojure team..." Then in the next paragraph: "I was treated pretty shabbily by..." (One can go on. Take the headline, "Ignorance or Apathy of Underlying Principles") Calling hardworking people (who do free work for one's own company) "obnoxious" and ignorant/apathetic seems shabby too. While demanding "fixes" from them, and putting down their "big highlights from the past year or so" (Transit, Transducers, Spec) with a backhanded "These are okay, I guess." I'd never tolerate a client/manager with that attitude about my hard work, and that's someone paying me. No wonder free software maintainers burn out.

pdimitar 10y ago
You're right and make a very good point. But that doesn't change the fact that there are bugs from 2009 which barely have comments or even a reasonable explanation. Me being a pretty average typer (~95 WPM) I could type 2-3 paragraphs detailing why I am against fixing anything, in no more than 6-8 minutes. So for 7 years such bugs to never even get a proper explanation is showing the maintainers as douchebags, not victims.
- weavejester 10y ago
  You'd be maybe be right, if that was the only thing that the maintainers were doing. Speaking as a maintainer of several projects myself, it's all too easy for some issues to slip through the cracks.
  - pdimitar 10y ago
    I agree. I am a maintainer myself of a closed-source & commercial project. It's indeed extremely easy to miss out on a crucial piece of info. I am not gonna teach anyone how to organize information. For the time being I am writing absolutely everything that comes to my mind (or is raised by customers and teammates) in a private Trello board. Even if I close everything in it 3 years from now, I would have some peace of mind knowing that I tried my damnest to never miss anything. And that's it's written down somewhere and that I am aware that it's waiting my input or work. I was somewhat offensive simply because bugs 7 years old marked as "wontfix" without a tangible explanation is absolutely not OK for language maintaners. The jobs of the senior devs are usually very hairy because we're good in fixing messes and repairing things. I stand behind my opinion that you have to go back and fix your past mistakes every once in a while. You can't pretend you're 18-20 years old and only sprint ahead and be blinded by the glamour of the new and shiny features. Stuff periodically needs repairing, it's how it is.

Scarbutt 10y ago

You probably should have stated that you work for Cognitect.

pmarreck 10y ago

it's too bad the JVM inlining budget isn't configurable or hintable, that seems like a poor design decision to have to work around. Then again, the JVM probably wasn't originally intended to be the foundation for a dozen other languages

ianopolous 10y ago
It is with -XX:MaxInlineSize=35 (that's the default number of bytecodes to consider inlining)
- jgalt212 10y ago
  OK, so can you develop with better error messages, and then ship to production a jar a faster version with the spartan error messages?
  - puredanger 10y ago
    We have been working on this off an on for a while and that's definitely an option.
- pmarreck 10y ago
  So why couldn't they simply include the extra debug code and use that config for Clojure compiles?
  - twoodfin 10y ago
    HotSpot is a JIT, so that's a runtime option. You'd be asking anyone deploying a .jar containing some Clojure to add fiddly configuration. Not impossible, but one of the heavily advertised virtues of Clojure is that it can be deployed alongside Java code without anyone having to be the wiser.
  - puredanger 10y ago
    We general try to assume that the user has applied no special JVM options. Planning with that as a baseline is much better than requiring people supply a big soup of options.

platz 10y ago

It's also what happens when the implementation becomes the specification that others depend on, rather than having the implementation depend on a specification. In the former, any deviation, including bugfixes, from the existing implementation is a breaking change. Indeed, without a specification, it's debatable whether any behavior is actually a bug or not.

slantedview 10y ago

You seem to be sidestepping some of the points made by the OP, particularly where certain bugs defy conventions laid down in other parts of the language. Garbage-in-garbage-out is fine so long as it's done in a consistent, well-understood way across the language (ie: throwing IllegalArgumentException). It seems to me that instead of being a strategic approach for dealing with such issues in a consistent way across the language (clearly this is not the case), your arguments are just an excuse for not fixing the damn issues (if that's what you're getting at). And that is truly bizarre.

kevinwang 10y ago
But it seems to me that throwing an exception would be the opposite of a garbage-in-garbage-out philosophy.
- jgalt212 10y ago
  The extreme version of this is PHP. Seemingly everything computes in that language with often very unexpected results (a least from what as my then PHP amateur status--coming from C).

pmarreck 10y ago

Why couldn't they just bump up -XX:MaxInlineSize=35 ?