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

91–100 of 295 posts

Re: Why Racket? Why Lisp?

#91

Post by Symmetry »

andreasvc wrote: post #70
jahnu wrote: post #27

Earlier quoted context omitted.

I find it a pain and error prone when having to change indentation in python code. E.g. when adding an 'if' in front of a block of code. So easy to miss a line or mess up the indentation in the block itself and then you might not spot an error until run time.

It's not a pain if you use an editor which lets you indent a whole block of code at once; e.g., in vim, use shift-V to select lines of code, then >> or << to in- or dedent. This is handy for all programming languages, of course.

Having groups of lines with the same indentation act as text objects helps too.

http://vim.wikia.com/wiki/Indent_text_object

Re: Why Racket? Why Lisp?

#92

Post by Tyr42 »

LesZedCB wrote: post #76
eru wrote: post #72

Earlier quoted context omitted.

> Actually, I think even Haskell still qualifies as imperative. How so?

Technically, if a language can produce side effects, it's considered imperative. However, nobody really is going to say that Haskell is imperative.

Though there are some claiming that Haskell is the best imperative language because of having to state upfront what effects each bit of code can have. Since evaluation order is not very straight forward in Haskell, effectful code has to be explicitly ordered, which makes is very clear.

Re: Why Racket? Why Lisp?

#93

Post by scardine »

aaron-lebo wrote: post #63
swah wrote: post #54

Earlier quoted context omitted.

I didn't mind but note that he wrote http://practicaltypography.com . As for not missing stuff from Lisps, I think opportunities start appearing once you start using it more. But I agree, it doesn't prevent you from getting things done.. I don't see any Lisp in the Go space (native compilation, great networking features), so I find Go more pragmatic at this time.

I think Gambit Scheme has both of those features. Granted, it doesn't have the community or momentum of Go, but it exists.

Add Chicken Scheme (http://www.call-cc.org/) to the list.

Re: Why Racket? Why Lisp?

#94

Post by bjourne »

pron wrote: post #58
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/…

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

Re: Why Racket? Why Lisp?

#95

Post by andreasvc »

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…

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

As to "ordering matters"; sure, but as the functions a nontrivial program calls are inevitably described as a graph, they must necessarily be defined in some arbitrary linear order anyway.

Re: Why Racket? Why Lisp?

#96

Post by [deleted] »

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…

[deleted]

Re: Why Racket? Why Lisp?

#97

Post by calibraxis »

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.

Re: Why Racket? Why Lisp?

#98

Post by pivo »

[deleted] wrote: post #96
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…

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

Re: Why Racket? Why Lisp?

#99

Post by innguest »

LesZedCB wrote: post #76
eru wrote: post #72

Earlier quoted context omitted.

> Actually, I think even Haskell still qualifies as imperative. How so?

Technically, if a language can produce side effects, it's considered imperative. However, nobody really is going to say that Haskell is imperative.

The language called Haskell cannot produce side-effects. You see the side-effects when you execute a program. That is, you cannot create side-effects within the language (except for escape hatches for FFI purposes).

This is different from other languages in that saying "what to print" is an actual command (hence, imperative) and not a value, as it is in Haskell (things that "will be commands when the program is run" are values in Haskell, as numbers and strings are).

Re: Why Racket? Why Lisp?

#100

Post by dragonwriter »

mrottenkolber wrote: post #80
LesZedCB wrote: post #74

Earlier quoted context omitted.

>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

> truly functional programming languages (which includes Clojure and the other Lisps) This is wrong. I don't know how to say this... Lisps do usually support functional programming paradigms, but most Lisps are indeed anything but functional (in the ML sense).

Lisp was considered a functional programming language before ML existed. Lisps generally don't have as strong and exclusive support for the functional paradigm as some newer languages (and pretty much anything else still in use is newer than lisp), but then C++ is known as an OOPL despite having less strong and exclusive support for the OO paradigm than many older languages, so there's that.
Post reply on HN