4 ms·

There’s two things that the article mentions that your omni-language has massive problems with: 1.) Performance. For example a run-time for a user-friendly lit

There’s two things that the article mentions that your omni-language has massive problems with: 1.) Performance. For example a run-time for a user-friendly little language that maps HTTP requests to SQL queries can be much faster than a language that does the same thing by plugging user-friendly APIs together. A custom run-time can parse an HTTP request string directly into SQLite op code while the JS developer is writing glue code that takes orders of magnitude more memory and CPU time. 2.) Static analysis. This means tools that are better at finding bugs, finding optimizations, visualizing structure, etc.

BiteCode_dev 4y ago
In your story, the small language fits local optimum, and becomes popular in its niche where it's good at. So small languages are not the future, which is what the article suggests. They are either niche (bash), dead (tcl), or gets big (sql).
- williamcotton 4y ago
  1.) Bash is not niche. 2.) SQL is not a general purpose programming language and is used as an example of a little language by the author. I can clearly imagine a future where instead of a few large general purpose languages we have a multitude of niche languages that have better performance characteristics, better tooling and smaller individual learning curves.
  - BiteCode_dev 4y ago
    I won't repeat the other comments I made, but in summary, yes bash is niche, stuck in a local optimum, no sql is not small anymore.
lolinder 4y ago
Both of these things are theoretically true, but only if the little language has enough resources behind it to optimize and build enough tooling. A big language is much more likely to have those resources because the target market is big enough to justify it. A niche little language will likely never get that kind of mass behind it, so the tools will be lacking and the runtime won't be optimized.
- williamcotton 4y ago
  Big general purpose languages don’t have the capability for certain kinds of performance improvements or static analysis so the market size isn’t a factor.
  - hinkley 4y ago
    I don’t want to spend all day playing human debugger because your little language doesn’t support debugging. I’m not here to tell you how very clever you are for reinventing the wheel. I have my own shot to get done and that’s easier when we make a smaller language out of our general purpose language by agreeing to style guidelines, instead of avoiding solving social problems with technology by creating your own game to change the rules. When everyone in your group expects the rest of the team to commit 10% of our attention to their tool or module, that doesn’t scale. If we go more than 50% total our capacity to solve problems becomes hamstrung. If you work someplace where new devs are useless for a year, you’ve likely already got the snowflake disease.
    - williamcotton 4y ago
      What does any of what you’ve written have to do with the concerns raised by the author of the article?
      - hinkley 4y ago
        > People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. From the top level comment. It’s also the primary failure mode for DSLs. There’s never any thought for tracing and debugging, and so it becomes a peaen to the primary author(‘s ego). Once you no longer have impostor syndrome it gets much harder to play along with these ego trips. It’s not that I’m too dumb to understand your DSL, it’s that you’re a fool who thinks writing your own language is the pinnacle of success. It’s very rare for it to better than a decent API and you’re thinking about yourself, not your coworkers. That’s why everyone always mentions SQL. It’s the exception to the rule, not an example of when DSLs can be good. Remember XSLT. Remember a dozen other failed DSLs. Per decade. Forever and ever.

BiteCode_dev 4y ago

In your story, the small language fits local optimum, and becomes popular in its niche where it's good at. So small languages are not the future, which is what the article suggests. They are either niche (bash), dead (tcl), or gets big (sql).

williamcotton 4y ago
1.) Bash is not niche. 2.) SQL is not a general purpose programming language and is used as an example of a little language by the author. I can clearly imagine a future where instead of a few large general purpose languages we have a multitude of niche languages that have better performance characteristics, better tooling and smaller individual learning curves.
- BiteCode_dev 4y ago
  I won't repeat the other comments I made, but in summary, yes bash is niche, stuck in a local optimum, no sql is not small anymore.

lolinder 4y ago

Both of these things are theoretically true, but only if the little language has enough resources behind it to optimize and build enough tooling. A big language is much more likely to have those resources because the target market is big enough to justify it. A niche little language will likely never get that kind of mass behind it, so the tools will be lacking and the runtime won't be optimized.

williamcotton 4y ago
Big general purpose languages don’t have the capability for certain kinds of performance improvements or static analysis so the market size isn’t a factor.
- hinkley 4y ago
  I don’t want to spend all day playing human debugger because your little language doesn’t support debugging. I’m not here to tell you how very clever you are for reinventing the wheel. I have my own shot to get done and that’s easier when we make a smaller language out of our general purpose language by agreeing to style guidelines, instead of avoiding solving social problems with technology by creating your own game to change the rules. When everyone in your group expects the rest of the team to commit 10% of our attention to their tool or module, that doesn’t scale. If we go more than 50% total our capacity to solve problems becomes hamstrung. If you work someplace where new devs are useless for a year, you’ve likely already got the snowflake disease.
  - williamcotton 4y ago
    What does any of what you’ve written have to do with the concerns raised by the author of the article?
    - hinkley 4y ago
      > People have been making this argument since the 80s and possibly even earlier. My experience is often the opposite. Little languages are usually far, far harder than (mis-)using "big" languages for small tasks. From the top level comment. It’s also the primary failure mode for DSLs. There’s never any thought for tracing and debugging, and so it becomes a peaen to the primary author(‘s ego). Once you no longer have impostor syndrome it gets much harder to play along with these ego trips. It’s not that I’m too dumb to understand your DSL, it’s that you’re a fool who thinks writing your own language is the pinnacle of success. It’s very rare for it to better than a decent API and you’re thinking about yourself, not your coworkers. That’s why everyone always mentions SQL. It’s the exception to the rule, not an example of when DSLs can be good. Remember XSLT. Remember a dozen other failed DSLs. Per decade. Forever and ever.