5 ms·
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,
by j2438 12y ago
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.
- innguest 12y agoI 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.
- mbrock 12y agoIt 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.
- innguest 12y agoI 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.
- informatimago 12y agoTell 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
- AnimalMuppet 12y agoSure. 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...
- innguest 12y agoImagine 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.
- thro1237 12y agoThis. 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.
- thro1237 12y agoThis. 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.
- davexunit 12y ago>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.
- technomancy 12y agoHash 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.
- davexunit 12y agoI 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.
- technomancy 12y agoSounds 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.
- innguest 12y agoThis 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.
- technomancy 12y agoMost people are OK taking a small performance hit for the simplicity of working with immutable data.