Hacker News Reader

Comment by j2438 | Hacker News Reader

Have not yet learned to use or appreciate macros.

The idea of everyone having to come up with their own syntax for such commonly-needed things as, say, hashes, seems counter-productive to me. That would lead to everyone's code looking like a different language.

View on HN

Tell me you wouldn't want to avoid this boilerplate:

    public class HelloWorld {
        public static void main(String[] args) {
            System.out.println("Hello, World");
        }
    }

and instead write a nice little main macro, so you may just write:

    (main (print "Hello, World!"))

Do that a few times in an application, and instead of 10 million LoC, you can write it in 100,000 LoC. This becomes much more maintainable!

Also, see: Alan Kay "Programming and Scaling" 2011

    http://www.tele-task.de/archive/video/flash/14029/
    https://www.youtube.com/watch?v=gZmcmdsoAXU
    https://www.youtube.com/watch?v=-UOmItPa4iA
    https://www.youtube.com/watch?v=QlPavndhYxQ
    https://www.youtube.com/watch?v=y9xLi0iJg1g

Also have a look at:

    https://groups.google.com/forum/#!msg/comp.lang.lisp/gsQJOGKYUw4/oLLHW0f4Ce4J
    https://groups.google.com/forum/#!msg/comp.programming/FiNIiSm5cJE/JkF5wa6Ke54J

Sure. And then imagine that you have to take over someone else's 100,000 LoC written with their own, unique, macros, some of which may invoke other macros, and interact with them in surprising ways, depending on what's passed into them. Now you have to be able to keep in your head what all those macros do (including to each other) while you're trying to read those 100,000 LoC.

At that point, you may not find the macros to be so much of an improvement on the boilerplate...

Imagine you have to take over someone else's 1,000,000 LoC written with their own, unique, classes and methods, some of which may invoke other methods, and interact with instance variables in surprising ways, depending on which method gets called first. Now you have to be able to keep in your head the flow of data (because the methods need not explicitly pass instance variables around) while you're trying to read those 1,000,000 verbose LoC.

At that point, you may not find Objects (aka copyable global scopes where instance variables are globally available to all instance methods of a class) to be so much of an improvement over symbolic computation.

Honestly, what you said never happens in practice (no one is abusing macros like that) but what I said is literally taught by Sandi Metz in her book Practical OOP in Ruby.

Your (common) reaction is just your everyday fear of the unknown. Try it.

This. I used to do all my programming in clojure. Now I am going back to python -- because I am not able to figure out a month after writing some code, what these deep recursive, reduce, apply things do.. But it is a good exercise writing it.

>commonly-needed things as, say, hashes

Hash tables are commonly used in imperative programming, but they aren't needed so often in Scheme where we prefer to use a purely functional style. We usually use alists because they are persistent. When I reach for a mutable hash table, it's usually part of some imperative process where I start from an empty table.

Depending on the Scheme you use, there could also be a persistent hash table implementation. Guile has vhashes, and there's an alist->vhash procedure, so you can still use the alist syntax.

Hash tables have nothing to do with imperative programming. It's just a coincidence that some MLs or Schemes don't include purely functional hash tables; Clojure and Racket both include have them.

I mentioned that Guile also has one, called a vhash. I guess my point is that special read syntax for them isn't that useful when you can use an alist and convert.

Sounds like a bit of a turing tarpit if you ask me. Sure there are technically ways to work around the lack of read syntax (I mean, Java didn't have literal syntax for any non-array collections for ages) but that doesn't mean it's a good idea.

This is wrong. There are no purely functional data structures analogous to hash tables in terms of performance. Hash tables are inherently stateful and cannot be implemented without state.

Most people are OK taking a small performance hit for the simplicity of working with immutable data.

I never said "with lisp, everyone has to come up with their own syntax for commonly-needed things". But it sounds your mind is already made up by hypothetical prejudices.

You said you stick with Clojure over Scheme on account of some syntax. I said you can have that syntax in Scheme. You then said the non-sequitur "the idea I created in my mind of each individual user coming up with their own syntax is absurd", which I agree with. I don't know what to tell you but you seem confused. What you said is not a response to what I told you. I eliminated the difference you complained about, and you complained that in Scheme it's possible to solve the issue you have with it.

There's no pleasing some people.

It might work better to tell your own story about using Racket. How do you work with data structure literals? Perhaps you've found that Racket's built in functions are good enough. In that case, maybe show an example demonstrating that fear is unwarranted.

Trying to please everyone—or convince everyone—is not a fruitful method of language advocacy.

I don't mind if they choose not to pick the language I like, but I do mind that other people will fall for this faulty reasoning, and not give the language a chance. That's why I pointed out where the fault in the reasoning is.

Reply on news.ycombinator.com