101–110 of 168 posts
Don't waste your time with lisp. Learn lambda calculus and then see how these ideas are applied in actually useful imperative programming languages.
As someone who thinks Lisp is pretty cool and uses Emacs to study it and is about 100 pages into SICP: I still don't get it. Common Lisp macros went entirely over my head too. A programmable programming language? Aren't all languages like that? I've only been programming for a couple years so I'm afraid I might not recognize the value of Lisp until I use more of the "less powerful" alternatives.
As someone who thinks Lisp is pretty cool and uses Emacs to study it and is about 100 pages into SICP: I still don't get it. Common Lisp macros went entirely over my head too. A programmable programming language? Aren't all languages like that? I've only been programming for a couple years so I'm afraid I might not recognize the value of Lisp until I use more of the "less powerful" alternatives.
Yes, all programming languages are programmable. But Lisp tends to be unlimited in its programmability, in almost the same way that Unix is: if you have root, you can change anything. I'm pretty sure that in most Common Lisp systems, you can redefine large parts of the compiler at runtime. And so on.
Syntactic macros are just one part. They can be extremely handy. Lots of Lisp systems use them well. Random examples: the DEFSYSTEM macro of ASDF; the DEFINE-EASY-HANDLER macro of Hunchentoot (a Common Lisp web server); the (controversial) LOOP and ITERATE macros; etc.
Another somewhat random example: Movitz was (is?) a project to write an x86 kernel in Common Lisp. It actually included its own compiler. It defines a lot of macros for instruction definition [0] and uses them in code that I don't understand anything of [1] but is probably very clear to someone versed in assembly.
Recently I've been trying to add some nice logging to a JavaScript program, and it's a typical scenario where the normal syntax is just annoying enough to make the code ugly and hard to scan—if I had macros, I could invent some other syntax.
How to use macros is a tradeoff that I guess comes with Lisp experience, but they can be a powerful escape when the standard syntax is annoying, and a way to define your own DSLs without restriction.
[0]: https://common-lisp.net/viewvc/movitz/ia-x86/def-instr.lisp?...
[1]: https://common-lisp.net/viewvc/movitz/ia-x86/instr-add.lisp?...
Java on the other hand, now that's a horrible language ;) ;)
Previous discussion can be found here: https://news.ycombinator.com/item?id=8206038 Have noticed quite a bit more buzz about Racket and Lisp very recently around here. It's always been something I mean to explore.
We seem to be on a Racket buzz lately, and I like it. I feel more inspired to dig further into Racket. I'm already pretty good with Clojure, so can anyone who knows both languages well comment on the ups and downs of learning Racket after learning Clojure?
Earlier quoted context omitted.
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…
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 think the hardest thing for people to get for programming in Lisp is the immutability. Once you get over that hump, everything is downhill. From the outside, the parenthesis seem pedantic but it's completely superficial. You will stop noticing them in a few hours, if not days.
There's setf and setq for assigning; nconc, nsubst, and the destructive list operations; rplaca and rplacd; etc.
It's easy to write Lisp that doesn't mutate (let), or use constructs that hide it (dolist, dotimes, etc.), but mutable data has been in Lisp since the beginning.
That said, there are languages in the family that don't allows mutation, but they're a small minority.
Earlier quoted context omitted.
Many people agree with you but I have the opposite view. Of course you can write any program in any Turing complete language, but the programs people do write in a given language tend to have a family resemblance to one another. Therefore if we want different kinds of programs we should have different languages. A given language makes certain ideas easier or harder to formulate, and thus easier or harder to have in t…
Some have also said that the human language you speak has an effect on how you think, but that's pretty controversial among linguists if not altogether discredited. I have no doubt the difference among human languages and programming languages could be completely different, but is there any concrete example you could give of an idea that is easier to express in one programming language than in another?
In the SICP lectures, when Sussman teaches the class the word "predicate", he mentions that knowing the names of these things is important because "As any sorcerer will tell you, if you know the name of a spirit, you have power over it".[1]
If you only know C, you're unlikely to think in terms of map/filter/reduce. If you don't know Haskell, you're unlikely to think in terms of functors and monads. You may be vaguely aware of repeated patterns, but knowing you're looking at a monad gives you a lot more power to reason about it.
I find all his digs at javascript funny since, at least the way I use it, javascript is basically an ugly-looking scheme. Javascript is responsible for my 'lisp enlightenment' with the language using first-class functions and closures, and the wide variety of precompilers. It strikes me as fashionable to hate on javascript. Java on the other hand, now that's a horrible language ;) ;)
Earlier quoted context omitted.
Good discussion of the advantages of Arc versus Racket. http://stackoverflow.com/questions/8555440/the-advantage-of-... "I wish they had implemented Arc as a Racket module language since then you could actually develop in DRracket, debug, and make executables."
That discussion doesn't seem very good to me, though there are some nice examples of Arc's notation at the bottom. Our own kogir actually worked for a while on implementing Arc as a Racket language. It would have some advantages, especially around tooling. However, like all such platforms, Racket has a sweet spot (what's easy to build on top of it), and the further your semantics are from there, the harder it quickly…
However, just because Arc can't be a layer of macros on top of Racket, that doesn't mean that the language can't be implemented as a Racket language. There are Racket language implementations of Algol 60, Python, and JavaScript, all of which are very different from Racket, more so than Arc is. And those implementations get the tooling benefits that Arc today misses.
It's easier to write a simple interpreter than a compiler, and Arc's current implementation seems to be working well for you, so far be it from me to tell you how to run your project. But certainly it could be implemented as a Racket language, no matter how far away it is.