I have so far stuck with Clojure instead of a Scheme primarily because of the nice literal syntax for maps, sets, vectors, and regexes that Clojure supports. I don't want to give that up and just use cons/car/cdr.
And also, last time I looked at Racket, it seemed very focused on academics. I just wanted to write some simple Scheme in a .scm file and try it out (a script), but I think I had to choose a language first (maybe a line at the top of the file? Don't recall) --- the Racket ecosystem seemed off-putting.
There are also some practical reasons to favour Clojure over Racket, specifically if you work in Java shop. The inertia to move to Clojure but remain on the JVM is going to be considerably lower than moving to whole new infrastructure as would be the case with Racket (indeed the language interoperability offered by the JVM was probably one reason why Scala gained such ground). However, even with Clojure I'm going to get some damn funny looks at the next code review.
Yes, I think one reason for Clojure's popularity is that it allows you to escape Java while still remaining on the JVM and being able to interoperate with your existing Java codebase.
That said, for a variety of reasons, I would actually prefer to not be tied to the JVM.
Yes, but they don't always have convenient literal notation or a consistent sequence abstraction that encompasses all collection types. For instance, I love Racket, but the hash literals are very noisy and apply implicit quoting, so they almost never get used. (Though Racket does a good job in most places of having a unified collection interface.) Emacs Lisp has the same problem but nothing coming anywhere close to a collection interface.
I'd encourage you to give it a longer try. When selecting a language, just pick R(5,6,7)RS and you're set.
Liking syntax sugar is hardly a reason not to use the language with the most powerful macros around. You can write macros to provide nice literal syntax for whatever you want - this is part of the fun.
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.
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...
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.
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.
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.
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.
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.
And also, last time I looked at Racket, it seemed very focused on academics. I just wanted to write some simple Scheme in a .scm file and try it out (a script), but I think I had to choose a language first (maybe a line at the top of the file? Don't recall) --- the Racket ecosystem seemed off-putting.