Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Racket? Why Lisp?

practicaltypography.com

Post reply on HN
Print view View original

121–130 of 295 posts

Re: Why Racket? Why Lisp?

#121

Post by dragonwriter »

LesZedCB wrote: post #74
pron wrote: post #58

Earlier quoted context omitted.

> ... in a way that an imperative language could not Perhaps a nitpick, but sometimes nomenclature is important. Clojure (like all Lisps) is an imperative programming language. "Imperative" languages are contrasted with "declarative" languages[1]. Where does functional fit in and what is the name for "non-functional"? Well, that's not clear, as "functional" (in the PL sense) doesn't even have an agreed upon definitio…

>Clojure (like all Lisps) is an imperative programming language. "Imperative" languages are contrasted with "declarative" languages. Wikipedia, and probably everybody, defines truly functional programming languages (which includes Clojure and the other Lisps) to be declarative, not imperative. [1] [1] http://en.wikipedia.org/wiki/Declarative_programming

Its worth noting that declarative and imperative styles (and this is true of things like the functional and OO paradigms, as well), when applied as descriptors of languages, aren't binary categories. Lisp is a fairly early functional language (that is, one, compared to contemporary alternatives, focussed on the functional paradigm), and the functional paradigm is a declarative paradigm centered around the substitution model of computation.

OTOH, that doesn't mean it is impossible to have imperative code in Lisp.

Re: Why Racket? Why Lisp?

#122

Post by crististm »

DCKing wrote: post #45

Why Lisp? That is understood. Why Racket? From an ignorant outsider's perspective, all Lisps seem to be more or less interchangeable when it comes to the language. They only differ in the details, and each seems to be about as difficult to learn as the other. Although this article does make somewhat of a case for specifically Racket, it seems to be a rather weak one - tools are nice and some language details are nice…

Racket vs Scheme vs Common Lisp is like C# vs Java vs C++ vs ...

Re: Why Racket? Why Lisp?

#123

Post by ColinDabritz »

A good list of some interesting 'day to day' benefits of Lisp. Maybe that is something that would appeal to beginners especially.

From my perspective Lisp is a powerful language because of its genesis in research. The question wasn't "How do we make a tool to make this hardware do what want?" but rather for a research goal.

If you want to read the actual original Lisp paper look up: Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I John McCarthy April 1960

Paul Graham covers it nicely in this essay, especially the "What made Lisp different" list about 1/3 in http://www.paulgraham.com/icad.html

Lisp has had expressiveness we're only recently seeing in popular mainstream languages now. It has to do with the design, the simplicity, and how Lisp expresses problems. I've often heard it described as "the language gets out of your way." That's why Lisp.

Re: Why Racket? Why Lisp?

#124

Post by progman »

lmm wrote: post #87
jimbokun wrote: post #78

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…

> 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 very good choice if I know the algorithm and data structures exactly in advance. But real world applications often require changes which are not predictable. It is a pain to align a whole Haskell project according to new requirements to make the whole system work again. It takes far too much time, and I wonder where the benefits are if other weaker typed languages can do the same job as well, or even better.

In the Lisp world I can develop prototypes very quickly. And if I need a strong type system as in Haskell then I can use Shen (shenlanguage.org) which has a strong rule based type system on top of Lisp. That means that I can use both worlds -- the default dynamic system of Lisp, and the strong type system of Shen.

Lisp is still very powerful and yet small in comparison to the huge LLVM system of Haskell. It can be used on embedded systems (ECL for instance) which Haskell is not able to do (AFAIK).

I don't know what you exactly mean with "tracking". If that means tracing then Lisp even offers backtracking (debugging back in time), and I think almost every Lisp programmer knows Slime.

So the claim that Haskell is "far far ahead" of Lisp is not true at all. The only real weak point of Lisp is a good GUI library. I wish there were strong support of Qt and HTML5.

Another favorite language of me is Nimrod because it joins the best of several languages (Python, Perl, Lisp and C) together.

Re: Why Racket? Why Lisp?

#125

Post by dragonwriter »

bad_user wrote: post #82
andreasvc wrote: post #67

Earlier quoted context omitted.

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…

Only by not working with anonymous functions can anybody come up with such an impression. Python has at least 3 features that are not needed in languages that have proper support for anonymous functions and that are more expression oriented: 1. for comprehensions 2. the with statement 3. decorators You cannot work efficiently with higher-order functions until you have anonymous multi-line functions, period - also, Py…

> Python has at least 3 features that are not needed in languages that have proper support for anonymous functions and that are more expression oriented:

> 1. for comprehensions

Off the top of my head Scala, Erlang, and Haskell -- all of which are "more expression oriented" than Python (and all of which have robust support for anonymous functions including multiline anonymous functions -- the latter despite, like Python, having indentation-sensitive syntax), all have comprehension syntaxes like Python's for comprehensions.

So, I'm not entirely buying the idea either that "being more expression oriented" or "having proper support for anonymous functions" eliminates the utility of comprehension syntax.

Re: Why Racket? Why Lisp?

#126

Post by dragonwriter »

progman wrote: post #124
lmm wrote: 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…

> It is a very good choice if I know the algorithm and data structures exactly in advance.

I'd say the exact opposite: the great strength of Haskell lies in its powerful support for abstracting things out so that these things can easily evolve independently. The hard part of taking advantage of this seems to me to be that we're used as programmers to not having those tools, so it is hard to get used to thinking about doing that kind of abstraction.

Re: Why Racket? Why Lisp?

#127

Post by eudox »

lmm wrote: post #108
eudox wrote: post #104

Earlier quoted context omitted.

>a lisp programmer might eventually put together a collection of idiosyncratic macros with much of the functionality of Rails, but that wouldn't be a project you could hire someone else to maintain There is, in fact, such a thing as Common Lisp libraries . See https://github.com/quicklisp/quicklisp-projects 1034 projects with ~48 waiting to be added.

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?

Framework: Caveman2[0] or Ningle[1], which run on Clack[2] (like Rack/WSGI), which supports five backend servers.

Templates: Djula[3], closure-template[4].

ORM: Crane[5], Postmodern[6].

[0] https://github.com/fukamachi/caveman

[1] https://github.com/fukamachi/ningle

[2] https://github.com/fukamachi/clack

[3] https://github.com/mmontone/djula

[4] https://github.com/archimag/cl-closure-template

[5] https://github.com/eudoxia0/crane

[6] http://marijnhaverbeke.nl/postmodern/

Re: Why Racket? Why Lisp?

#128

Post by dragonwriter »

alvatar wrote: 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, is not.)

Re: Why Racket? Why Lisp?

#129

Post by kd0amg »

lmm wrote: post #87
jimbokun wrote: post #78

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…

We can even fully infer types if you're willing to accept some quite reasonable restrictions on how polymorphic your code is.

Personally, I don't consider "don't pass a polymorphic function to another polymorphic function" and "don't demand a polymorphic function as an argument" to be all that reasonable.

Re: Why Racket? Why Lisp?

#130

Post by wes-exp »

Author is wrong about hygienic macros – they are not more powerful. They are less powerful, and more complicated, in order to enforce safety. Whether this is preferable or not is a matter of debate.
Post reply on HN