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

101–110 of 295 posts

Re: Why Racket? Why Lisp?

#101

Post by mjn »

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

I don't think everyone uses that definition of declarative, though it is one of them. A very common different definition is that declarative programs specify "what", not "how", i.e. desired outcomes are explicit, while algorithms for computing them are implicit. From that perspective, Prolog, SQL, constraint solvers, answer-set programming, etc. are declarative paradigms (albeit sometimes with non-declarative escape hatches, like Prolog's "cut"). But languages in which you write algorithms, whether C or SML, are something other than declarative, and instead are oriented towards explicitly specifying computations rather than the desired results of computations.

Re: Why Racket? Why Lisp?

#103

Post by [deleted] »

pivo wrote: post #98
[deleted] wrote: post #96

Earlier quoted context omitted.

[deleted]

> More generally Common Lisp lacks a coherent web based module repository infrastructure like those of other dynamic languages such as CPAN or RubyGem. What about ASDF and/or Quicklisp ( http://www.quicklisp.org ). They work well for me.

[deleted]

Re: Why Racket? Why Lisp?

#104

Post by eudox »

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…

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

Re: Why Racket? Why Lisp?

#105

Post by klibertp »

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?

One path you could take is to start using a lisp for the platform you're already familiar with. There is Hy for Python, LispyScript (and others) for JavaScript, LFE for Erlang and more. These are "lisps" to varying degrees - they all are written with sexps, but they typically preserve the semantics of underlying language, which makes it really easy to pick up and get over the initial hurdle of "ZOMG parens!!!".

I had good experience with Chicken Scheme, which is both much simpler system than Racket, but also quite rich in features and add-on packages and it also produces fast native executables. I suppose you could make it your first Scheme.

Of course, Emacs users should just hack in Elisp for a couple of months, then switch to Common Lisp. I wouldn't recommend going straight for CL, unless you're going to follow some really good book (like pg's "On Lisp" or maybe "Land of Lisp"), because it's very easy to drown in CL capabilities.

You should decide what you want to build - don't learn a lisp just for the sake of learning, build something with it! - and then choose the best lisp for this particular project. I'm sure lispers everywhere will be happy to help you choose (just before the thread evolves into massive flame-war, again... ;)).

Re: Why Racket? Why Lisp?

#106

Post by hvs »

mrottenkolber wrote: post #86

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…

I would take issue with the OOP in CL being better implemented than other languages. Don't get me wrong, the Metaobject Protocol is a feat of modern engineering, but the actual result is an OOP that feels tacked on after the fact. CLOS is very powerful, but when it comes to OOP, other languages are syntactically cleaner in their implementations.

Also, it's a bigger debate, but the lack of hygenic macros in CL is often seen as a negative. Again, this is a larger debate, but certainly a case can be made that CL doesn't have everything designed so well.

I love CL, but it's helpful to remember its limitations.

Re: Why Racket? Why Lisp?

#107

Post by eudox »

[deleted] wrote: post #103
pivo wrote: post #98

Earlier quoted context omitted.

> More generally Common Lisp lacks a coherent web based module repository infrastructure like those of other dynamic languages such as CPAN or RubyGem. What about ASDF and/or Quicklisp ( http://www.quicklisp.org ). They work well for me.

[deleted]

ASDF is the build system, Quicklisp the package manager. QL depends on ASDF.

Re: Why Racket? Why Lisp?

#108

Post by lmm »

eudox wrote: post #104
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…

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

Re: Why Racket? Why Lisp?

#109

Post by tel »

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…

To be clear, they were far ahead of lisp in the 90s too.

The major innovation is probably more societal in these languages. We discovered that they really are much better for writing reusable abstractions on the level of the whole community. We also ran into some issues with scaling those abstractions at the level of 10s of thousands of packages and are slowly coming to solve them.

Re: Why Racket? Why Lisp?

#110

Post by barrkel »

andreasvc wrote: post #95
bad_user wrote: post #82

Earlier quoted context omitted.

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…

Can you please explain to me what's important about these functions being anonymous? Why, specifically, they shouldn't be given a name? How do you define working "efficiently with higher-order functions"? Given that Python fully supports higher-order functions, I am really curious what you could mean. I didn't downvote you, but it may have to do with your pointed assertion here, without anything in the way of an argu…

    some_collection.where(x -> x.name == 'foo').sort_by(x -> x.age)
These functions are tiny and trivial. They don't need names, and if you were to give them names, the extra weight becomes burdensome. Not just in syntax duplication, but the redundancy of the name as a comment on the trivial function body.

    nameIsFoo = x -> x.name == 'foo'
    getAge = x -> x.age
    some_collection.where(nameIsFoo).sort_by(getAge)
Note that giving the functions names has also changed the source order of the function bodies. Now you need to do a mental cross-reference to follow, instead of being able to read the definitions inline.
Post reply on HN