Live data from Hacker News

Why Racket? Why Lisp?

practicaltypography.com

201–210 of 295 posts

Re: Why Racket? Why Lisp?

#201

Earlier quoted context omitted.

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.

to quote an old quip: you have a problem. common lisp has a clunky solution that's built into the standard, and scheme has a beautiful one that doesn't work in your dialect.

Re: Why Racket? Why Lisp?

#202

Earlier quoted context omitted.

> truly functional programming languages (which includes Clojure and the other Lisps) This is wrong. I don't know how to say this... Lisps do usually support functional programming paradigms, but most Lisps are indeed anything but functional (in the ML sense).

Lisp was considered a functional programming language before ML existed. Lisps generally don't have as strong and exclusive support for the functional paradigm as some newer languages (and pretty much anything else still in use is newer than lisp), but then C++ is known as an OOPL despite having less strong and exclusive support for the OO paradigm than many older languages, so there's that.

Lisp was considered a functional programming language before ML existed.

That was then and this is now. Today, functional programming means side-effect-free with a strong type system, and efficient use of higher-order abstractions over functions, including things like typeclasses to define entire morphisms given a few functions which establish relationships between objects. Lisp doesn't really support this effectively. Arguably, with concepts C++14 is more functional than Lisp.

Re: Why Racket? Why Lisp?

#203
post #6

I sure hope the giant, hideous, obtrusive diamonds inserted into the text to denote a hyperlink doesn't catch on as a trend. It's a great way to break the flow of the text and irritate your readers. As for the idea of Lisps, well, it sure seems neat. But I've literally never run across a situation where I needed my code to edit itself. I've never run across a situation where the lack of an everything-is-an-expression…

> As for the idea of Lisps, well, it sure seems neat. But I've literally never run across a situation where I needed my code to edit itself. I've never run across a situation where the lack of an everything-is-an-expression-is-a-list feature prevented me from doing what I wanted to do. This is classic Blub paradox. You don't feel like you need a feature until you start using it, at which point you start wondering how…

OK, but I've been aware of Lisp macros for a while, and still never seen a situation where I needed them.

A couple weeks ago, though, I found myself in a situation where the user needed to be able to specify a filter, and the filter was going to be a tree of expressions, and the program had to take what the user specified and turn it into something the program could execute... and the filter tree looks a lot like an S-expression... hmm...

So I'm seeing something that could be done much easier in Lisp. It's still not a need for a macro, though (unless you're going to suggest that I use a macro to turn some user-writeable DSL into Lisp, and sure, it could be done that way.)

Re: Why Racket? Why Lisp?

#204
It seems most people here have never used (and not tried) racket.

I decided to use racket for my little sides projects, as replacement for scala and clojure.

I choose it because it was clear for me i can't stand limitations other language impose to me in way of style and boilerplate, the racket macro (aka syntax transformer) system is the most advanced i know to reduce the boilerplate to a minimum and so just write what i want to express. In facts i rarely write macro because writing a good macro demand you take care of errors syntax, i am lazy in the bad meaning of the term.

I choose it because it's dynamic typed and i get more convinced that type go on your way most of the time (expect complex algorithms)(i write little projects, so refactoring argument is out). It enable me to write code and eval it on the fly with geiser (using enter! on the back), after eval the new function i test it in the repl, hack until the function meet the requirement copy paste from repl and boom i get a unit test. Because it as eval and it will become handy one time in your programmer life for sure.

I choose it because of it's sexpr syntax, as a heavy user of emacs i know that other syntax is a pity.

Also because it has (and i use):

1. llar parser (implemented through a macro).

2. A pattern matching nothing to envy scala or clojure deconstructs.

3. An optional type system.

4. A contract system.

What i find hard as a new comer (to racket, not as a programmer already now scala, clojure, half of c++ :), php) is

1. The broadness of the features the language offer, which feature to use e.g.: class or generics.

2. The documentation is rich but lack of examples for the common cases, so you need to read the doc of the function (sometime it's huge).

3. Understanding how racket module works is quite hard and you have the documentation, if you don't plan to play with the macro expander (the stuff that run your macro) and some dynamic features you don't really need to.

4. You need to 'register' the errortrace library if you want a stacktrace, quite a surprising behaviours for me.

My opinionated conclusion:

Racket is the best language design i ever see, it's hard to learn but make you feel learning an other language will just become to learn a new sub-optimal syntax. Sadly the ecosystem is lacking libraries and peoples and i am not helping in this way.

Re: Why Racket? Why Lisp?

#205
post #170

Earlier quoted context omitted.

No, the article is correct. Hygienic macros give you strictly more information to work with, enabling them to be more expressive. It's possible to implement unhygienic macros, either at an individual macro level or a whole new macro syso, using Racket's macro system.

I'm thinking you're right in the theoretical sense, but I'm right in the practical sense. Every time I've looked at hygienic macro systems, it just seems like now I'm jumping through extra hoops to overcome a more restrictive way of doing things. Is that extra information you cite typically useful for anything besides safety? Can you give an example?

Yes, the information is useful for lots of things. For example, tracking the binding information in the data is how DrRacket manages renaming, how Scribble (the Racket docs tool) hyperlinks every identifier in every example to the correct documentation for the identifier, how Typed Racket tracks type metadata for identifiers, ...

Re: Why Racket? Why Lisp?

#206

It seems most people here have never used (and not tried) racket. I decided to use racket for my little sides projects, as replacement for scala and clojure. I choose it because it was clear for me i can't stand limitations other language impose to me in way of style and boilerplate, the racket macro (aka syntax transformer) system is the most advanced i know to reduce the boilerplate to a minimum and so just write w…

I'm glad you like Racket, and you're right about some of the weaknesses, especially in providing guidance and examples for how to do things.

I have questions about points 3 and 4. For 3, do you mean it's hard to figure out how the implementation of something works, especially when that something is a complex macro? If so, I can't disagree.

For 4, if you just run Racket programs at the command line, you should get stack traces (although less nice than the ones errortrace provides). Do you not get those?

Re: Why Racket? Why Lisp?

#207

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…

The number of bindings you can add to a symbol in CL is irrelevant to the macro system. In CL, you run into somewhat fewer instances of specific kinds of bugs that Racket's macro system prevents entirely.

The Racket macro system is more powerful, having more information and more control over the system, than the CL system. This additional expressiveness is what enables systems as sophisticated as the Racket contract, class, unit, and type systems to be built entirely with macros.

Re: Why Racket? Why Lisp?

#208
post #87

If you took a Common Lisp programmer from the early to mid 90s in a time machine to today, very little about current programming languages would seem novel or an advance over what he or she was using then. I think this is a reason for much of the smugness of Lisp programmers. Whatever features you think are new or cool or advanced about your programming language, Lisp probably got there first.

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…

But you only have to infer types because you insisted on removing them from the run-time information.

Sure, you're clearing the road of fallen logs, but they fell there by your own axe.

Having the type there at run time is smarter than working up a lather prior to run time to avoid having it there.

Also, real systems don't have a well-defined "compile" and "run time": the two are intertwined. Compile time is just the compiler's run time, and we need access to the language at that time, and has to be type-safe also, and we would like that comile-time code to itself be compiled (and to have access to the language during that code's compilation ...).

Re: Why Racket? Why Lisp?

#209

Some practical features I enjoy in CL: 1. Conditions and restarts : As far as error handling in programs go this is the most rock-solid system I've encountered. You can tell the system which bits of code, called restarts, are able to handle a given error condition in your code. The nice thing about that is you can choose the appropriate restart based on what you know at a higher-level in the program and continue that…

"CLOS allows me to dispatch based on the types of all of the arguments." But can it dispatch based on the return value?

That sounds like a feature that would both be awesome, and annoy the crap out of me.

Are there examples where this actually leads to clearer code in the wild?

Re: Why Racket? Why Lisp?

#210

Earlier quoted context omitted.

Type systems are the one exception, but it still remains broadly true that Lisp was way ahead of everybody. There are many things we could talk about besides type systems: Lambda expressions - just now reaching Java and C++, been in Lisp forever Garbage collection – (obviously) Turing-complete (edit: fully evaluating) macro systems – I've heard C++ is moving in this direction (not sure to be honest) but Lisp is still…

A couple of quibbles with your list: > Multiple inheritance – I think this is coming to Java finally But it's been in C++ for a very long time. > Functional programming techniques (map, reduce, etc.) – Still ahead Still ahead of who? Haskell? How so?

Still ahead of mainstream programming languages, which are typically imperative by design, and usually overly "noun" focused compared to the "verb"-friendly nature of Lisp. Adding map/reduce/etc. to the noun languages is a bolt-on that is not exactly ideal.

Take Java 8 which now has map: sure, you can pass a lambda expression with a custom function body, but is using functions (particularly side-effect-free ones) as arguments idiomatic otherwise? I can only imagine the amount of ceremony code that ensues when trying to merge those worlds. Don't get me wrong, having map/reduce/etc. is an improvement to Java for sure, but Lisp is still well ahead on the overall cohesion and utility of such things within the context of the rest of the language.

Post reply on HN