Live data from Hacker News

Why Racket? Why Lisp?

practicaltypography.com

181–190 of 295 posts

Re: Why Racket? Why Lisp?

#181
post #36

Many of the last items in the list should be in the category "Scheme". Racket is a dialect from Scheme, but it still is a Scheme. The syntax-case macro transformations are available in most Scheme systems.

> Many of the last items in the list should be in the category "Scheme". Racket is a dialect from Scheme, but it still is a Scheme. The name was changed to Racket from a name with "Scheme" in it because its not a Scheme in the strict sense; Racket does not conform to any of the Scheme reports (though its bundled with language definitions that do, as well as lots of others, but the Racket language, while near Scheme,…

> but the Racket language, while near Scheme, is not.

You've described 99% of Scheme systems. The only exception I know of is Scheme48, which is pretty much the Third Reich of Scheme systems.

Portability between Scheme systems is tedious and, in some cases, close to impossible. Even moreso when you start using some combination of SRFIs.

Re: Why Racket? Why Lisp?

#182

Earlier quoted context omitted.

> Python is the only language I know that added for comprehensions before proper support for anonymous functions. All the other languages I worked with (including Clojure, to be on topic) had anonymous functions before the syntactic sugar built on top. Clearly Python has a problem here. Wait, first you claimed that Python wouldn't need comprehensions if it had better anon function support, and now you've claimed that…

The 2 statements are consistent. You can live without for comprehensions if you have good anonymous functions support. If Python adds better anonymous functions support, its for comprehensions will be conflicting and much less useful than in languages that had good anonymous functions support from the beginning. Either way, Python will never get multi-line anonymous functions support, since it's first of all consider…

> You can live without for comprehensions if you have good anonymous functions support.

You can live without either, as decades of C programmers have demonstrated. Both are beneficial, as theeir widespread popularity in newer language attests. Neither is a perfect substitute for the other, as the fact that they tend to be both present in many newer languages, rather than being exclusive.

> its for comprehensions will be conflicting and much less useful than in languages that had good anonymous functions support from the beginning.

I don't see the "conflict" asserted here. I've used Ruby fairly heavily -- which has, in the relevant sense, far better anonymous function support than Python (even though it has different quirks) -- and certainly as nice as Ruby blocks are, a clean comprehension syntax is pretty much the main thing I find myself wishing I had sometimes in Ruby that Python has.

And, sure, Python's comprehensions may be less general than, e.g., Scala's, but switching them to be monadic rather than iterator based doesn't require better anonymous function support, it just requires changing which protocol they depend on.

Re: Why Racket? Why Lisp?

#183
post #87

Earlier quoted context omitted.

Nonsense. We've figured out how to do type systems. We can even fully infer types if you're willing to accept some quite reasonable restrictions on how polymorphic your code is. We have a bunch of reasonable approaches to effect tracking, which Lisp folk used to have to do by hand (that story about the T garbage collector sounds like the most unmaintainable piece of code I've ever heard of). We know how to solve the…

> OTOH modern "researchey" languages, like Coq or even Haskell, are far far ahead of Lisp. I know Common Lisp well, and I honestly tried to learn and to use Haskell. I realized that Haskell has the advantage of a strong type system but it seems only to be useful for language research (compiler writing) and mathematical applications. Haskell is (in my case) almost useless for every day real world applications. It is a…

"In the Lisp world I can develop prototypes very quickly."

In my experience, this is almost entirely due to familiarity, and not due to any specific or general language features.

"...I can use Shen (shenlanguage.org) which has a strong rule based type system on top of Lisp..."

I really, really need to bump Shen up on my list of things to play with.

Re: Why Racket? Why Lisp?

#184

Earlier quoted context omitted.

I developed in Python for several years and I disliked whitespace, because sometimes I want the flexibility to format code in a way that makes more sense given the right context and the whitespace was always in my way. Plus, its whitespace-based syntax was used as an argument to not evolve the language, being one reason for why they haven't added proper anonymous functions. I can't comment on LISP's parens much, for…

Python has proper lexical closures in the form of inner functions. Can some please enlighten me why one would still insist on multi-line anonymous functions? For documentation purposes it's a) better to give something a name, b) have a multi-line function in a separate place instead of inline in the form of a lambda. Concerning whitespace, serious (large) projects have a very specific style guide, which includes pres…

> Can some please enlighten me why one would still insist on multi-line anonymous functions?

Reduced visual clutter and better flow in reading code.

> For documentation purposes it's a) better to give something a name, b) have a multi-line function in a separate place instead of inline in the form of a lambda.

I disagree: if the only place its ever used is in a particular call to a higher order function, it reduces the difficulty of reading the code -- if its not a large multiline function -- for it to be directly in the call as a lambda. Having it named is useful (1) if it needs to be referenced more than once (DRY), or (2) if it is large enough that it breaks up the flow too much for it to be included in one place (which is a somewhat subjective cut-off, but for me 1 line is far below it.)

EDIT: That being said, I'm mostly fine with Python the way it is -- while I sometimes wish a way to fit multi-line lambdas without disrupting the rest of the language could be found, I'm not sure I can see a good way for it to work, and its not really essential.

Re: Why Racket? Why Lisp?

#185

Earlier quoted context omitted.

"Turing-complete macro system - I've heard C++ is moving in this direction (not sure to be honest) but Lisp is still ahead on this" 1) Turing-complete is a bug, not a feature. 2) C++ template metaprogramming has been Turing Complete for ages. 3) There are nonetheless significant limitations on what you can do with templates in C++, compared to what you can do with macros in Lisp. "Turing Complete" is a theoretical co…

I understand what you're saying. What I mean is not the trivial "nand is turing complete" sense, which I agree is harmful and silly, but full eval capabilities. Lisp macros can fully evaluate Lisp code, and I consider this a great feature, but I don't know how else to describe them. "Full evaluation macros"?

> What I mean is not the trivial "nand is turing complete" sense, which I agree is harmful and silly, but full eval capabilities.

The two are equivalent (provided that the target language that can be evaluated is itself turing complete) -- that's rather the nature of turing completeness. If you have the former, you can make the latter with it and nothing else; if you have the latter, you necessarily also have the former.

Re: Why Racket? Why Lisp?

#186
post #108

Earlier quoted context omitted.

Sure, but is there a one-stop framework that lets you write a CRUD web application as fast as you can with Rails? Was there such a thing in the '90s?

No, CL has like 10 different web frameworks or so. I never used any of them, not a big fan of Rails either though. Talking about the 90s, there was no Ruby. But I guess we could have had Lisp on Lanes in the 90s, if there had been demand.

Common Lisp has about 10 different anything frameworks, which nobody in particular uses in favor of writing their own, mostly because they can. Many of the ten are in fact written into the standard.

Common Lisp isn't so much a "language for writing languages" as a giant bag of everything.

Re: Why Racket? Why Lisp?

#187

Can not resist... This article is fairly misguided. I find it painful that everybody who writes about a Lisp offshoot (Scheme, Clojure, ...) ends up misrepresenting Common Lisp. To sum up "Why Lisp?" from a CL perspective: CL has pretty much every feature of every programming language around, only that its better designed, implemented and generally more powerful. It's just a poweruser language. Its not just macros, s…

[deleted]

Re: Why Racket? Why Lisp?

#188

Can not resist... This article is fairly misguided. I find it painful that everybody who writes about a Lisp offshoot (Scheme, Clojure, ...) ends up misrepresenting Common Lisp. To sum up "Why Lisp?" from a CL perspective: CL has pretty much every feature of every programming language around, only that its better designed, implemented and generally more powerful. It's just a poweruser language. Its not just macros, s…

[deleted]

Re: Why Racket? Why Lisp?

#189

Earlier quoted context omitted.

I understand what you're saying. What I mean is not the trivial "nand is turing complete" sense, which I agree is harmful and silly, but full eval capabilities. Lisp macros can fully evaluate Lisp code, and I consider this a great feature, but I don't know how else to describe them. "Full evaluation macros"?

> What I mean is not the trivial "nand is turing complete" sense, which I agree is harmful and silly, but full eval capabilities. The two are equivalent (provided that the target language that can be evaluated is itself turing complete) -- that's rather the nature of turing completeness. If you have the former, you can make the latter with it and nothing else; if you have the latter, you necessarily also have the for…

Yes, it was a poor choice of terms. To be clear, eval isn't equivalent except within the narrow theoretical notion of turing completeness: it can do I/O, for instance file I/O. And it accepts high-level language code directly which is very important in a practical sense compared to, say, accepting nand instructions only.

Re: Why Racket? Why Lisp?

#190
post #22
post #9

Earlier quoted context omitted.

As someone who writes Lisp (well, Clojure) every day and does not particularly enjoy it, I find the common complaint about parentheses to be a non-issue. In fact, I'm not sure I've heard of anyone who wrote any significant amount of lisp code and came away talking about parentheses. This seems to be mostly a reaction from people who've read a bit of Lisp without using it. Then again, I just noticed that I type ( and…

If you write Lisp every day why not remap the ( and ) to a non-shifted position? I use the [ and ] keys but I use Common Lisp, not Clojure.

I find it odd that people use their pinky to type parens. When my fingers are on the home row, '(' is above my middle finger, and ')' is above my ring finger. Typing them with my pinky would require me to contort my hand.
Post reply on HN