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

151–160 of 295 posts

Re: Why Racket? Why Lisp?

#151

Post by doorhammer »

rrradical wrote: post #138
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 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 e…

This has generally been my experience as well when I'm working with almost any reasonable type system. Every time I've focussed on leaning on the type system, it's made refactoring much quicker for me and left me feeling way more confident.

Every time I encounter a bug I think "is there a way I could have encoded this into the type system so it would have never compiled with the bug?" The thing I like about Haskell is how often I can say "yes" to that question and implement it. From what I understand, that question would would "yes" even more often with dependent types, though I've yet to really learn much about them.

I really dig lisp (especially clojure) but the thing I miss when I'm using lisp is a really solid type system.

Re: Why Racket? Why Lisp?

#152

Post by smeyer »

ColinDabritz wrote: post #123

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

Thanks for the link (it's one of PG's I hadn't read yet.) That being said, I really didn't like the part where he implied that if 1 line of Lisp can replace 20 lines of C that it also means that a feature can be developed 20 times faster in Lisp than C. Are you a Lisp programmer? I've only used it a bit, but I didn't get the impression things would scale that way for feature development.

Re: Why Racket? Why Lisp?

#153

Post by masklinn »

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…

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

That dates back to the 70s: http://en.wikipedia.org/wiki/ML_(programming_language)

Re: Why Racket? Why Lisp?

#154

Post by dllthomas »

wes-exp wrote: post #147
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…

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…

"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 construct that doesn't really mean much other than giving you easy ways to prove that certain questions about the system can't always be answered. One significant reason for this is that "Turing Complete" merely means that you can embed any computation in the system in some encoding - with something like a macro system, the encoding you generate is the whole point.

Re: Why Racket? Why Lisp?

#155

Post by hyp0 »

Re 1. everything is an expression benefit, condition example:

C-like languages often have the ternary operator, cond?exp1:exp2, that is exactly this. I feel clever using it, but I consider it a hack, because it's (usually) less clear. A microcosm of lisp, clever but unclear.

Re: Why Racket? Why Lisp?

#156

Post by lmm »

wes-exp wrote: post #147
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…

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…

Java/C++ are not the world. Your list is not the "features I think are new or cool or advanced about my programming language".

Re: Why Racket? Why Lisp?

#157

Post by bad_user »

fnbr wrote: post #131
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 f…

You can get started with Clojure without Leiningen. You can get started with Scala without SBT. These are build tools for serious projects, with lots of options and lots of things they do for you. Some people recommend them to beginners and while that's not necessarily wise, it goes to show that they are mature and OK enough that some beginners cope with it.

Yes, you can get started easily with Haskell - but then Cabal is such a complete piece of shit that people felt the need for a Haskell distribution with batteries included. And it is my feeling that you're mixing the cause and the effect here.

Re: Why Racket? Why Lisp?

#158

Post by dragonwriter »

progman wrote: post #140
dragonwriter wrote: post #126

Earlier quoted context omitted.

> 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 really like Haskell but I wonder if the type system is actually too strong for the real world.

Given the amount of "real world" programming that's been done with Haskell, I suspect not.

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

I don't see a real problem with Cabal with sandboxes.

> Perl has CPAN, Ruby has Gems, Lisp has ASDF and Quicklisp but Haskell is still stuck with buggy Cabal.

Cabal doesn't seem to be buggy, and is about on the same level as Ruby Gems (I think the difference is that the version bounds conflicts that manifest at package install time in cabal occur at runtime with gems, because rubygems installs multiple versions in the local repository but needs to import a single version at runtime (bundler, which is separate from gems, addresses this, among other practical issues with gems.)

Dependency hell is common to package systems that don't have a single version of every package that is curated to work with all other packages in the set -- CPAN isn't immune to it either, at least from what I've seen on the web (I haven't used Perl at all in many years, and only very little then.)

Cabal now that is has sandboxes available, seems at least on par with gems.

> FPcomplete is already working on a new solution with snapshots.

Its really an intermediate stage between what package repositories/managers like cabal/gems/cpan provide and what Haskell Platform provides. Its not really a "new solution" for the same issue. [1]

[1] See the discussion here: http://www.yesodweb.com/blog/2012/11/solving-cabal-hell Cabal (and gems, etc.) operate at level 2, the new Stackage from FP Complete is at level 3, Haskell Platform is at level 4.

Re: Why Racket? Why Lisp?

#159

Post by bad_user »

wcummings wrote: post #134
bjourne wrote: post #94

Earlier quoted context omitted.

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.

I would say that immutable data is a prerequisite for doing functional composition and languages that don't have immutable data-structures in their standard libraries are not used as FP languages.

Re: Why Racket? Why Lisp?

#160

Post by codygman »

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…

Disagree about Haskell being even remotely useless for every day real world applications. Haskell is good for reducing complexity and being able to rely on guarantees. A couple months ago I wrote a screen scraper/web interface that was basically an expired domain purchasing application in Haskell.
Post reply on HN