3 ms·

> What makes this possible? Take a look at what kind of power DSLs can give you: http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html

by sklogic 10y ago

> What makes this possible? Take a look at what kind of power DSLs can give you: http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html http://www.moserware.com/2008/04/towards-moores-law-software... If you use this methodology consistently, all of your code (including the DSL compilers themselves) is just as readable as this. Imagine, all your code reads as just an English specification of a problem you're solving, with some tables and diagrams where needed. > why isn't everyone using it all the time? I do not have an answer to this question. Yet, given that I never managed to convince anyone who was not already doing this stuff that macro-based DSLs are a way to go, apparently, there is a huge cultural problem and a huge stigma attached to macros (likely because of the C preprocessor and some really bad Lisp examples - think of the stuff like LOOP macro). I personally use this approach exclusively, and I cannot understand those who prefer to write 1000x more code.

incepted 10y ago
> I personally use this approach exclusively, In my experience, most people who are so in love with macros/DSL's work on solo projects. Are you working on a team? If yes, ask your coworkers what they think about your macros and it should be more obvious to you why macros/DSL's should be used much more sparingly than what you recommend. > I cannot understand those who prefer to write 1000x more code. You're setting up a false dichotomy. It's possible to not use macros and still keep the amount of code down to a reasonable level.
- sklogic 10y ago
  > In my experience, most people who are so in love with macros/DSL's work on solo projects. Yes, but not because it's hard to cooperate when you use DSLs (it's in fact far easier to work in a team this way). It's more because scale of the projects shrink to such an extend that you don't need a team. One person can do with macros an equivalent of what a team of many people would do in a much longer time without macros. > If yes, ask your coworkers what they think about your macros and it should be more obvious to you why macros/DSL's should be used much more sparingly than what you recommend. Yes, I work in a team, and most often worked in teams. Yes, DSLs were always the greatest performance boost available. No, your beliefs about DSLs being somehow incompatible with team work are entirely wrong and unfounded. > It's possible to not use macros and still keep the amount of code down to a reasonable level. Mind naming a single viable alternative?
Styx- 10y ago
How would you suggest a typical run-of-the-mill object-oriented programmer go about learning such a methodology? Most of the links in that article are dead.
- sklogic 10y ago
  > How would you suggest a typical run-of-the-mill object-oriented programmer go about learning such a methodology? That's exactly what's wrong with this thoroughly broken industry. They should not have learned this awful religion in the first place. Now it's much harder to unlearn and re-learn from scratch than learn it without ever being exposed to the wrong ways. This methodology is far, far easier than anything OOP (the latter cannot even be defined comprehensively), and if you learn it first you can become productive much quicker than if you go the typical OO way. And the most important feature of this methodology is that it's far more accessible. You don't need to be smart to use it. No need to memorise dozens of "design patterns" and all that. No need to invent complex twisted designs, trying to cram as many patterns as possible into a trivial task. DSL-based approach is very straightforward and mechanical, and can be executed by practically anyone who managed to learn how to read and write (i.e., around 95% of the population).
  - klibertp 10y ago
    > DSL-based approach is very straightforward and mechanical, and can be executed by practically anyone who managed to learn how to read and write (i.e., around 95% of the population). I mostly agree with your comments, but here I think you're underestimating the difficulty of creating a good DSL way too much. It's like saying that anyone who managed to learn to read and write can create Esperanto. Also, being able to read and write does not guarantee the ability of clearly expressing one's thoughts. Without this crucial skill inventing a DSL is an exercise in frustration, both for the original author and later for the poor users of such a DSL. And one more thing: you can create (internal) DSLs in almost all existing languages, by (ab)using their syntax and semantics. Smalltalk and Ruby are quite happy with their many DSLs, despite being an OO language. As for GP: > How would you suggest a typical run-of-the-mill object-oriented programmer go about learning such a methodology? See Avail: https://klibert.pl/output/avail-and-articulate-programming.html https://klibert.pl/output/avail-and-articulate-programming.h... Then learn Scala, Ruby, Elixir, Racket, Smalltalk, F#, Elm, Haskell. They all make use of DSLs and contain many examples of well-designed eDSLs. After that, go read a bit on language design and compiler construction and you're done.

by sklogic 10y ago

incepted 10y ago

> I personally use this approach exclusively, In my experience, most people who are so in love with macros/DSL's work on solo projects. Are you working on a team? If yes, ask your coworkers what they think about your macros and it should be more obvious to you why macros/DSL's should be used much more sparingly than what you recommend. > I cannot understand those who prefer to write 1000x more code. You're setting up a false dichotomy. It's possible to not use macros and still keep the amount of code down to a reasonable level.

sklogic 10y ago
> In my experience, most people who are so in love with macros/DSL's work on solo projects. Yes, but not because it's hard to cooperate when you use DSLs (it's in fact far easier to work in a team this way). It's more because scale of the projects shrink to such an extend that you don't need a team. One person can do with macros an equivalent of what a team of many people would do in a much longer time without macros. > If yes, ask your coworkers what they think about your macros and it should be more obvious to you why macros/DSL's should be used much more sparingly than what you recommend. Yes, I work in a team, and most often worked in teams. Yes, DSLs were always the greatest performance boost available. No, your beliefs about DSLs being somehow incompatible with team work are entirely wrong and unfounded. > It's possible to not use macros and still keep the amount of code down to a reasonable level. Mind naming a single viable alternative?

Styx- 10y ago

How would you suggest a typical run-of-the-mill object-oriented programmer go about learning such a methodology? Most of the links in that article are dead.

sklogic 10y ago
> How would you suggest a typical run-of-the-mill object-oriented programmer go about learning such a methodology? That's exactly what's wrong with this thoroughly broken industry. They should not have learned this awful religion in the first place. Now it's much harder to unlearn and re-learn from scratch than learn it without ever being exposed to the wrong ways. This methodology is far, far easier than anything OOP (the latter cannot even be defined comprehensively), and if you learn it first you can become productive much quicker than if you go the typical OO way. And the most important feature of this methodology is that it's far more accessible. You don't need to be smart to use it. No need to memorise dozens of "design patterns" and all that. No need to invent complex twisted designs, trying to cram as many patterns as possible into a trivial task. DSL-based approach is very straightforward and mechanical, and can be executed by practically anyone who managed to learn how to read and write (i.e., around 95% of the population).
- klibertp 10y ago
  > DSL-based approach is very straightforward and mechanical, and can be executed by practically anyone who managed to learn how to read and write (i.e., around 95% of the population). I mostly agree with your comments, but here I think you're underestimating the difficulty of creating a good DSL way too much. It's like saying that anyone who managed to learn to read and write can create Esperanto. Also, being able to read and write does not guarantee the ability of clearly expressing one's thoughts. Without this crucial skill inventing a DSL is an exercise in frustration, both for the original author and later for the poor users of such a DSL. And one more thing: you can create (internal) DSLs in almost all existing languages, by (ab)using their syntax and semantics. Smalltalk and Ruby are quite happy with their many DSLs, despite being an OO language. As for GP: > How would you suggest a typical run-of-the-mill object-oriented programmer go about learning such a methodology? See Avail: https://klibert.pl/output/avail-and-articulate-programming.html https://klibert.pl/output/avail-and-articulate-programming.h... Then learn Scala, Ruby, Elixir, Racket, Smalltalk, F#, Elm, Haskell. They all make use of DSLs and contain many examples of well-designed eDSLs. After that, go read a bit on language design and compiler construction and you're done.