Hacker News Reader

Comment by dschiptsov | Hacker News Reader

Everything has been said by Richard Gabriel long ago - Lisp is too good, and "packers" don't need or even appreciate refinement and excellence, like most of folks don't appreciate beauty of DNA and related machinery.

For them PHP or Java are tools for getting shit done. There are huge piles they have produced, like Hadoop or whatever it is.

The last great Lisp was ZetaLisp from Symbolics (just read the docs!). Common Lisp is already a bloatware suffered from the kitchen sink syndrome, nevertheless it is way better than anything else (multi-paradigm, mostly functional, strongly-typed (type-safe enough) meta-language that compiles to native code with pattern-matching, OO and other fancies as DSLs).

But who cares if one is satisfied with writing

   RepetitiveStupidityFactory myStupidityFactory = new RepetiriveStupidityFactory;

for living.

View on HN

> RepetitiveStupidityFactory myStupidityFactory = new RepetiriveStupidityFactory;

Yeah because

    (let v (make-instance 'RepetitiveStupidFactory))

is so obviously superior, right?

Obviously. Less repetitive, less verbose. And, most importantly, one could hide all the irrelevant details inside a macro which is equivalent to extending a language with a new control structure.

The Lisp version is less verbose because it's dynamically typed (in other words, it's less verbose because it contains less information that would allow this code to be proven correct).

By the way, these days, we write things like

    val l = ArrayList<String>()

If verbosity is your number one criterion to write your code, just skip all error checking and your code will become super concise.

I'd suggest the last great Lisp wasn't ZetaLisp, but (prefix-syntax) Dylan, which was designed by many of the same people. It's essentially a Scheme plus CLOS "all the way down," with a cleaned up subset of the core of Common Lisp. Find the book from 1991-1992, it's worth reading.

In that case it is PLOT3 by David Moon (Google it).

Nope. Moon apparently bought into the "people don't like Lisp because of the parentheses, so we should make a Lisp that looks more like ALGOL and people will like it" line like the rest of the Dylan core team.

IMO if it doesn't have homoiconicity, it's not a Lisp, and macros will be much more difficult.

> For them PHP or Java are tools for getting shit done.

... as opposed to Lisp?

Yes, Lisp is a distinct, different culture (think of Aryans versus tribes in ancient India). The difference is as it is between craftsmen (who are artists) and assembly-line workers.

Look, read Gabriel or Graham or early Norvig (his Lisp style and anti-design-patterns essay), not me. There is something behind their insights.

> The difference is as it is between craftsmen (who are artists) and assembly-line workers.

It's a bit harsh to call Lisp programmers assembly-line workers. I think the language has value and pioneered some language concepts that we find across a lot of languages today, but Lisp is very dated by 21st century standards.

> It's a bit harsh to call Lisp programmers assembly-line workers.

I think GP meant it the other way around.

I know.

Yea, understanding macros and writing your own DSLs doesn't make you some sort of aryan ubermensch programming craftsman. Macros really aren't that hard to get, and mostly not necessary when you have more coherent constructs at your disposal.

Yes, macros are not hard to get - they're far simpler than anything else imaginable.

No, they are necessary. There is no better way of doing things than macros.

> There is no better way of doing things than macros.

We have invented plenty of better ways since Lisp. Much better ones.

Mind naming a single one?

I do not believe such a thing exist. Macros are the ultimate solution.

There is much that can be done with regular, bog-standard functions. Yes, macros can be useful in certain cases, but it's often more straightforward to use the Lisp language as it comes. As always, it's important to use the right tool for the job.

> There is much that can be done with regular, bog-standard functions.

You cannot implement simple, modular, debuggable, composable DSLs with functions alone. And you cannot tackle complexity without DSLs.

> Yes, macros can be useful in certain cases

In most cases. Cannot think of anything beyond "Hello, world" that does not deserve a DSL implementation.

> You cannot implement simple, modular, debuggable, composable DSLs with functions alone.

We've been doing this for at least ten years. Example: [1]

For someone who's convinced that DSL's are the silver bullet that everybody should be using, you don't seem to have kept up with the state of the art of the field much.

[1] https://github.com/Kotlin/anko

No, this has nothing to do with anything simple. It is awfully overengineered. It is definitely not a way do implement DSLs.

These are functions, it doesn't get any simpler than that and it doesn't require learning anything new once you know the language.

Macros are over engineered in comparison since they force the developer to learn a whole new section of the language with its own rules and own compilation lifecycle.

This is why hardly anyone uses macros these days and why most language are embracing the Groovy/Kotlin approach to writing DSL's.

I moved from Apache Groovy to Clojure for writing tests for my own software about 5 years ago. A single limited-range macro can cut out a lot of repetitive syntax of the sort found in repetitive test cases. A one-line Clojure macro can easily do the same as what it takes 50 lines of Java defining a Groovy annotation.

The small amount of time it takes to learn Clojure and get used to its syntax is well worth it. Too bad not many workplaces are willing to similarly switch from Groovy to Clojure for writing tests. They even stick with the older Groovy version 1.8. Once something works, they won't upgrade.

> These are functions, it doesn't get any simpler than that

Simplicity of the building blocks does not affect complexity of the resulting mess of code.

Look, Brainfuck have only 8 operators. It cannot get much simpler than that. Once you learn all 8 operators no new constructs require any learning. Does it help at all? No. You're stuck at a pathetic abstraction level.

Same with your functions. They're limiting your abstraction level, therefore making it impossible to make things simple. And your DSL example shows it in quite a dramatic way - it is a horrible mess and nothing but a horrible mess. It can be somewhat handy for the users, but the implementation is plain awful.

Show us what you think is a nice DSL then, because you keep waving your hands about DSL but you're not showing a single line of code to prove your point.

I did it many times elsewhere in this thread already.

For example, this one: http://www.moserware.com/2008/04/towards-moores-law-software...

Or Nanopass itself, not just as a tool for building DSLs, but as an example of a nice and clean DSL (of course, if it could bootstrap itself it would have been even better):

https://github.com/akeep/nanopass-framework

Or everything you can find in my github repositories (username: combinatorylogic).

Free monads would like to have a word with you about simple, modular, debuggable, composable DSLs. On the other hand macros are anything but composable or modular. Debuggable for some far off definition of debuggable, maybe.

Monadic interpreters? Composable? Are you kidding? It is a joke, not a composability. You cannot take a type system of one DSL, modules from another and only the expressions syntax from a third one and then mix them all together into a new DSL.

And, anyway, interpreters. Who in a sane mind can ever consider an interpreter?

Also, you obviously do not realise that macro-based DSLs are by far more debuggable than any monadic interpreter would ever be.

Before we continue, post a link to a free monad DSL you have written; I do not intend to waste my time in a discussion with a zealot.

(I can send you examples of macros I've had to write, if you desire.)

@sklogic (can't reply directly): I know how to use macros, I've used them and I have come to the conclusion that there are much better tools.

Seeing you know what a logical phallacy is, here is one more for you: "if you don't like macros you don't know how to use them". Can you guess the name?

My question was not ad hominem. I wanted to see whether you have actually used the thing you are arguing against or instead just blindly praising something as the ultimate solution and thereby determine whether I should continue this discussion with you.

Why would you be interested in my pitiful attempts if even the best examples of the monadic DSLs people keep pointing too are all thoroughly horrible, convoluted and unmaintainable? Likewise, why should I look at your macros if you already admitted that you do not know how to use them?

Can you comment constructively about the composability issue without resorting to ad hominem?

Do you even understand the idea if the macro-based DSL design methodology?

I guess you can have something as horrible as the CL LOOP macro in mind, instead of any properly designed DSLs.

Drop me a mail, p<dot>kamenarsky, gmail.com.

(cannot answer there too, weird...)

No, I conculded that you have no idea how to implement macro-based DSLs from your remarks about composability and debugging. You cannot be so out of touch and still know something about the macros.

And, no, you did not point to a viable alternative. Monadic interpreters are complex, convoluted and very inefficient. This is an objective fact, not a matter of a taste.

Do not agree? Show me a definitive example of such a DSL and I will demonstrate how much simpler a macro-based version is.

P.S.: and the free monad part is not what I'm calling convoluted and unmaintainable. It's ok to assemble an AST this way (yet, a custom parser is better). The problem here is in the interpreter part.

Interpreters are inherently bad and there is almost nothing you can do about it. The only sane way of keeping an interpreter complexity under control is to use a single common trivial VM interpreter, write it once, never touch it again, and lower all your monadic DSL ASTs down to it.

Which makes this solution quite similar to the macro-based one (it would actually reek of Greenspun Tenth), but still much less efficient.

I gave you my mail in the other reply, HN is really annoying for longer discusssions.

> Mind naming a single one?

We no longer need macros to create intuitive DSL's any more.

This is not an answer to my question. What are you proposing instead of macros?

Reply on news.ycombinator.com