3 ms·
I also don't get it. I've literally never seen a job ad in my area a single time that needs lisp or lisp-based languages, and the only time I ever see it mentio
by moonshinefe 10y ago
I also don't get it. I've literally never seen a job ad in my area a single time that needs lisp or lisp-based languages, and the only time I ever see it mentioned is by insanely devoted people who love spending dozens of hours learning a bizarre language that nobody else uses.
It reminds me of Esperanto a bit, it might have some nice ideas but it will never take off. I've yet to hear a succinct, practical argument as ot why I should take the dozens of hours to learn lisp or any of its derivatives as someone working as a non-academic.
- sklogic 10y ago> practical argument If you want to increase your productivity in orders of magnitude, if you want to be able to complete projects on your own that otherwise large teams would struggle to do, you must learn Lisp or any other meta-language suitable for DSL construction. Luckily, now there is quite a few of them, so if you don't like Lisp in particular there is a number of alternatives available.
- forgetsusername 10y ago>If you want to increase your productivity in orders of magnitude, if you want to be able to complete projects on your own that otherwise large teams would struggle to do I've seen this claim a few times in this thread. What makes this possible? If you can increase productivity so drastically, why isn't everyone using it all the time? It seems utterly irrational not to.
- 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 agoHow 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).
- jjawssd 10y agoThis sounds way too good to be true
- sklogic 10y agoYet it is something I know firsthand. I also know how hard it is to convince people to try this approach. There is a lot of lies people believe in: that compiler construction is hard, that macros are hard to debug, that DSLs are only suitable for large and "smart" projects, and so on.