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

131–140 of 295 posts

Re: Why Racket? Why Lisp?

#131

Post by fnbr »

aaronbrethorst wrote: post #2

From what I've seen out of the Clojure community over the past few years, it seems like they're far more likely (and able) to offer up concrete examples of how Clojure makes their businesses and products successful in a way that an imperative language could not. So, yay Clojure community, and boo on hand-wavy Lisp people. e.g.: http://www.kreuzwerker.de/en/blog/posts/why-clojure-rocks-2/ https://news.ycombinator.com/…

I tried Clojure, and I quite like it as a language (especially the thread-first & thread-last macros [1, 2]).

I don't, however, like the ecosystem surrounding it. I find Leiningen (while an excellent tool) far too heavy for the majority of my purposes. I much prefer other functional languages (e.g. OCaml, Haskell) that don't need such an intricate project structure.

With OCaml & Haskell, I can start with one source file in one directory and gradually build up to a more sophisticated layout as needed, rather than have a complicated layout imposed upon me by the project.

[1] http://clojuredocs.org/clojure_core/clojure.core/-%3E [2] http://clojuredocs.org/clojure_core/clojure.core/-%3E%3E

Re: Why Racket? Why Lisp?

#132

Post by runevault »

eudox wrote: post #114
pjmlp wrote: post #35

Earlier quoted context omitted.

That is also a sore point from the Lisp community in regard to Clojure. Clojure devs are willing to compromise a bit to allow a good integration within the JVM and other implementations, thus allowing some shops to buy into Clojure. Whereas many in the Common Lisp community will not, no matter what.

>Whereas many in the Common Lisp community will not, no matter what. Common Lisp on the JVM: http://abcl.org/ Common Lisp/Java bridge: http://foil.sourceforge.net/

Foil's by Rich so that isn't the best argument :).

Re: Why Racket? Why Lisp?

#133

Post by [deleted] »

wes-exp wrote: post #130

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.

[deleted]

Re: Why Racket? Why Lisp?

#134

Post by wcummings »

bjourne wrote: post #94
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…

Taken to the extreme like you are doing, no language could ever be considered "functional" because in the end, they all need to perform io and ordered execution to be of any use. Instead, the commonly understood meaning of the word "functional" is that the language's design emphasizes and encourages use of immutable data and Clojure fits that meaning.

>Instead, the commonly understood meaning of the word "functional" is that the language's design emphasizes and encourages use of immutable data and Clojure fits that meaning.

I would say a language which relies on functional composition as its primary abstraction is "functional." Immutable data is a side effect of that.

Re: Why Racket? Why Lisp?

#135

Post by GregBuchholz »

lostcolony wrote: post #77
_ofdw wrote: 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…

Good call on the diamonds. Echoing everyone else, basically, your other points are a bit shortsighted. You never need code that edits itself - completely true. Completely missing the point. Most programming features fall into this category; you don't -need- them, you could always use assembly instead. The point is that once you get them into your brain as an option, problems that might otherwise be tricky or time con…

hmm...

    c = sqrt(a*a + b*b)

    (setf c (sqrt (+ (* a a) (* b b))))

Re: Why Racket? Why Lisp?

#136

Post by cturner »

calibraxis wrote: post #97
cturner wrote: post #3

The top reason here could been written - lisp is more expressive. You can find ways to express an idea that make sense now, and which are readable. Macros is a different part of the same idea. -- Maybe I'm doing it wrong, but a problem I've had with racket is as you begin to build larger projects, when something breaks it can be quite difficult to find out exactly where the break happened. When you compile Java or ru…

Yes, that is very important. When I watch experienced programmers learn Lisp, they write a couple functions, then go through the pain of debugging that. They should unlearn that. And put tiny fragments in the REPL. (Or whatever interactive tool you have.) Playing with it.

Since lisp is homoiconic (refreshed on this, see downvotes below) it would be nice if you could type things into a repl and then run a function like this: (persist function-i-just-wrote). And then it would save to a text file. Then you wouldn't need to stuff around with the mouse copying from one buffer to another and the like.

(I expect something similar is possible in emacs, but emacs is not my thing.)

Hmm. I suppose I could just write the persist function myself. Watch this space.

Re: Why Racket? Why Lisp?

#137

Post by [deleted] »

eudox wrote: post #119
DCKing wrote: post #90

Earlier quoted context omitted.

Thanks for the clarification. Is it worth considering others besides Racket and Clojure as a first Lisp? Are there Lisp equivalents of Vim and Atom as well?

Yes, Common Lisp. Gradually-typed, fast, compiled, standarized, stable, and with multiple mature implementations.

[deleted]

Re: Why Racket? Why Lisp?

#138

Post by rrradical »

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 pain to align a whole Haskell project according to new requirements to make the whole system work again.

I'll quote a recent tweet by Chris Done: "I feel like 80% of Haskell advocacy should involve screencasts of people refactoring large codebases."

In my experience, refactoring is easier with a strongly typed compiler, not harder. It may take more time and work to get your program to "run" again, but the end result will be more likely correct, and more likely to be a better design.

Re: Why Racket? Why Lisp?

#139

Post by wcummings »

DCKing wrote: post #90
klibertp wrote: post #75

Earlier quoted context omitted.

> all Lisps seem to be more or less interchangeable when it comes to the language Definitely not true. It may be true to an extent for implementations of one particular lisp, like Common Lisp or Scheme, but even then there are very real, and significant differences. Simple and regular syntax makes it actually much easier to build many different semantics, and that's what lisps are about. Racket has less libraries tha…

Thanks for the clarification. Is it worth considering others besides Racket and Clojure as a first Lisp? Are there Lisp equivalents of Vim and Atom as well?

Emacs+SLIME, Common Lisp (I like SBCL).

Re: Why Racket? Why Lisp?

#140

Post by progman »

dragonwriter wrote: post #126
progman wrote: post #124

Earlier quoted context omitted.

> 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…

I understand that. I really like Haskell but I wonder if the type system is actually too strong for the real world.

Generalizing algorithms sounds nice but if Haskell is so powerful, why is the Haskell community still not able to provide a convenient working package manager? Perl has CPAN, Ruby has Gems, Lisp has ASDF and Quicklisp but Haskell is still stuck with buggy Cabal.

I have been in the Cabal hell many times. I know that there are sandboxes, and I considered to install Nix and NixOS just to use Haskell. It surprises me very much that a simple package manager is such a big issue in Haskell. This is a typical example for a real world application that causes strange difficulties in Haskell where other languages have no issues at all.

FPcomplete is already working on a new solution with snapshots. I am curious how convenient it will be.

https://www.fpcomplete.com/blog/2014/08/announcing-stackage-...

Post reply on HN