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

171–180 of 295 posts

Re: Why Racket? Why Lisp?

#171

Post by bad_user »

dragonwriter wrote: post #162
bad_user wrote: post #141

Earlier quoted context omitted.

Well, Scala and Haskell's comprehensions are monad comprehensions, mapping to operations such as map, filter and flatMap/bind. Python's for comprehensions only work on things that are iterable, which IMHO is a severe design limitation and makes them less useful than they should be. Think at Async I/O abstractions, like futures / observables / iteratees, which are not iterables. And yes, if Python makes it easier to w…

> Python is the only language I know that added for comprehensions before proper support for anonymous functions. All the other languages I worked with (including Clojure, to be on topic) had anonymous functions before the syntactic sugar built on top. Clearly Python has a problem here. Wait, first you claimed that Python wouldn't need comprehensions if it had better anon function support, and now you've claimed that…

The 2 statements are consistent.

You can live without for comprehensions if you have good anonymous functions support. If Python adds better anonymous functions support, its for comprehensions will be conflicting and much less useful than in languages that had good anonymous functions support from the beginning.

Either way, Python will never get multi-line anonymous functions support, since it's first of all considered to be un-pythonic. So we're having this discussion for nothing - I fell out of love with Python some time ago, if you still like it than good for you.

Re: Why Racket? Why Lisp?

#172

Post by leishulang »

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…

Leiningen prevents clojure from having the dependency hell problem from the beginning, which haskell was prone to but eventually fixed by sandboxing. Then would you say sandboxing is too heavy for haskell?

Now if by heavy, you mean the folders structure lein generates, then I disagree. Those folders actually keep the task of understanding any lein project easy.

If by heavy, you mean the JVM: You can compile the thing into a jar that runs on any jvm, or a js file using clojurescript. JVM, web browsers and Node.JS are very likable cross-platform layers, and I don't see why binary executable that are OS dependent compares.

Re: Why Racket? Why Lisp?

#173

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?

#174

Post by cipher0 »

klibertp wrote: post #84
pervycreeper wrote: post #48

Earlier quoted context omitted.

SICP

Structure and Interpretation of Computer Programs by Abelson and Sussman, for the uninitiated. It's one of the best introductions to basic and advanced (and then even more advanced) programming there is. This book, along with a series of "The Little Schemer", "The Seasoned Schemer" and "How to design programs" use Scheme as a language, and Racket makes it particularly easy to follow them by providing special environm…

Online interactive version of SICP http://xuanji.appspot.com/isicp/ for great win.

Re: Why Racket? Why Lisp?

#175

Post by leishulang »

bad_user wrote: post #157
fnbr wrote: post #131

Earlier quoted context omitted.

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

I agree. If Cabal was as good as Leiningen, then Haskell would has been way more popular than today.

Re: Why Racket? Why Lisp?

#176

Post by BugBrother »

andreasvc wrote: post #118
barrkel wrote: post #110

Earlier quoted context omitted.

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

Sure, but those are one-line functions, which Python supports through lambdas. (Incidentally, some of them could be done with the operator module, without defining a new function). I would argue that once you write a multi-line function, it makes sense to give it a name and define it separately, which makes the "no multi-line anonymous functions" complaint less pressing.

Let me give you an example from my experience.

I wrote an elegant parser definition library, used for parsing specialized output of ... never mind.

It had hierarchic specifications (regular expressions etc) of parsing states, along with anonymous functions which stored away parsed data and sent the parser among different states.

New juniors could after a few hours use this to quickly parse complex text documents.

I cursed a lot while trying to port this to Python. :-( A dozen named sub-ten lines functions specified by names and referenced inside a parser structure? Just didn't work.

Edit: The point is, there are use cases where real lambdas are useful (except from map etc). It is just weird to argue otherwise.

Re: Why Racket? Why Lisp?

#177

Post by pjmlp »

Stubb wrote: post #88
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.

Yeah, I think that most programming language developments since the '70s have involved putting some ideas from C and Lisp in a blender for a few minutes. The main advances IMO have come in the areas of IDEs, build systems, and language ecosystems. I'm a mediocre programmer at best who's done a bunch of Lisp in the past. I loved using it, but these days I rely on Ruby for getting things done because it gives me what I…

From the 70's I would rather wish that the mix would be Lisp, Smalltalk, Cedar and CLU. No need for C.

Re: Why Racket? Why Lisp?

#178

Post by wes-exp »

samth wrote: post #170
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.

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?

Re: Why Racket? Why Lisp?

#180

Post by pjmlp »

Avshalom wrote: post #89
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.

Sure but that can be said of half a dozen languages in the 70s. Unix taking over the world ended up convincing two generations that C was state of the art.

Sometimes I feel like a Roman after the Empire downfall.

So many choices for systems programming gone thanks to UNIX, and now kids think C is the only way.

Post reply on HN