Live data from Hacker News

Why Racket? Why Lisp?

practicaltypography.com

41–50 of 295 posts

Re: Why Racket? Why Lisp?

#41
post #35

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

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.

What kind of compromises are you talking about?

My impression (based on limited exposure) is that Common Lisp suffers from a lack of clear guidance on how to do things. It's common in Clojure for example to use immutable data-structures and in case of mutation to use atoms and STM. Compromising on issues is seen as reasonable, but not a best practice and often there's a clear path you can take for certain problems. It's an opinionated language without being obnoxious.

To me the attitude exposed by Clojure (and Scala) is a breath of fresh air. Some people tend to focus on how pieces of code look, or on using certain abstractions and optimizations, forgetting that the most important thing for users is a working app. For example, surely things like TCO and continuations have value, but that value is being trumped by a huge ecosystem of libraries and tools that, while not beautiful, are decent.

Re: Why Racket? Why Lisp?

#42
post #9

Earlier quoted context omitted.

As someone who writes Lisp (well, Clojure) every day and does not particularly enjoy it, I find the common complaint about parentheses to be a non-issue. In fact, I'm not sure I've heard of anyone who wrote any significant amount of lisp code and came away talking about parentheses. This seems to be mostly a reaction from people who've read a bit of Lisp without using it. Then again, I just noticed that I type ( and…

I would assume it'd be the same as people complaining about significant whitespace in python. No one who actually programs in python complains about the whitespace.

I developed in Python for several years and I disliked whitespace, because sometimes I want the flexibility to format code in a way that makes more sense given the right context and the whitespace was always in my way.

Plus, its whitespace-based syntax was used as an argument to not evolve the language, being one reason for why they haven't added proper anonymous functions.

I can't comment on LISP's parens much, for now it doesn't bother me, but Python's whitespace did and I tried liking it for about 3 years.

Re: Why Racket? Why Lisp?

#43
post #9

Earlier quoted context omitted.

As someone who writes Lisp (well, Clojure) every day and does not particularly enjoy it, I find the common complaint about parentheses to be a non-issue. In fact, I'm not sure I've heard of anyone who wrote any significant amount of lisp code and came away talking about parentheses. This seems to be mostly a reaction from people who've read a bit of Lisp without using it. Then again, I just noticed that I type ( and…

I would assume it'd be the same as people complaining about significant whitespace in python. No one who actually programs in python complains about the whitespace.

[deleted]

Re: Why Racket? Why Lisp?

#44
post #37
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.

I was under the impression that Python emits an error about inconsistent indentation at compile time (the initial parsing and interpretation of a script file), not runtime (+x time units later, after the program has started). Is that incorrect?

I'm talking about something like this..

    def foo():
        do_this()
        and_this()
    
later I change it..

    def foo():
        if something():
            do_this()
        and_this()

oops... and_this() should have been in the if block and I won't find out till I run it.

(imagine a much bigger more complex example of the above function)

In large pieces of code this can be easy do. If you are forced to use parenthesis it's much more difficult to make this error. One could argue that experience prevents you from doing this but I have sadly found this not to be the case in practice.

Re: Why Racket? Why Lisp?

#45
Why Lisp? That is understood.

Why Racket? From an ignorant outsider's perspective, all Lisps seem to be more or less interchangeable when it comes to the language. They only differ in the details, and each seems to be about as difficult to learn as the other. Although this article does make somewhat of a case for specifically Racket, it seems to be a rather weak one - tools are nice and some language details are nice. But the same general arguments can be made for other Lisps, most notably Clojure. It seems to me that Clojure is a lot more practical: it has many good libraries in both Clojure and Java, it has some great tools, there's a lot of momentum, and it can be deployed everywhere (including the browser).

So, being an ignorant outsider, is there any reason the Lisp I should learn isn't Clojure?

Re: Why Racket? Why Lisp?

#46
post #44
post #37

Earlier quoted context omitted.

I was under the impression that Python emits an error about inconsistent indentation at compile time (the initial parsing and interpretation of a script file), not runtime (+x time units later, after the program has started). Is that incorrect?

I'm talking about something like this.. def foo(): do_this() and_this() later I change it.. def foo(): if something(): do_this() and_this() oops... and_this() should have been in the if block and I won't find out till I run it. (imagine a much bigger more complex example of the above function) In large pieces of code this can be easy do. If you are forced to use parenthesis it's much more difficult to make this error…

> If you are forced to use parenthesis it's much more difficult to make this error.

By "parentheses" you mean delimiters, which create visible boundaries to defined areas in code. Parentheses are an example of delimiters, but not all delimiters are parentheses.

Bash has if ... then ... else ... fi

Ruby has if ... else ... end

C/C++/Java have (logical test) { controlled area }, nested to any practical depth.

And so forth. Python doesn't.

> One could argue that experience prevents you from doing this but I have sadly found this not to be the case in practice.

This is an argument against complex functions that do a lot, as opposed to breaking program logic up into smaller blocks that are easier to understand and control. The old argument against this practice was that a large function that did everything was faster than the same logic broken into smaller blocks. A modern compiler will generally prevent this from happening.

Re: Why Racket? Why Lisp?

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

I mainly develop software in C# and Python at work, and I sure do miss some of the convenience that lisp-inspired languages offer. I'm responsible for the overall architecture of quite some large-ish enterprise apps. There's a reason why many Java and C# business applications have tons of MySuperAbstractFactoryProvider classes and use reflection-based look-up of metadata attributes obsessively. There's just no other way to provide a flexible framework that meets the changing and often arcane demands of our customers.

About macros, in the case of C#, what, if not a kind of macro, is the 'using' statement that works with IDisposables? If it's useful here, why not in other places?

Re: Why Racket? Why Lisp?

#48
post #45

Why Lisp? That is understood. Why Racket? From an ignorant outsider's perspective, all Lisps seem to be more or less interchangeable when it comes to the language. They only differ in the details, and each seems to be about as difficult to learn as the other. Although this article does make somewhat of a case for specifically Racket, it seems to be a rather weak one - tools are nice and some language details are nice…

SICP

Re: Why Racket? Why Lisp?

#49
post #9
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…

As someone who writes Lisp (well, Clojure) every day and does not particularly enjoy it, I find the common complaint about parentheses to be a non-issue. In fact, I'm not sure I've heard of anyone who wrote any significant amount of lisp code and came away talking about parentheses. This seems to be mostly a reaction from people who've read a bit of Lisp without using it. Then again, I just noticed that I type ( and…

I was looking for a way to summarize lisp syntax benefits. Most BNF-heavy languages are statically appealing. They have layout and differentiators that makes it nice to look at.

Lisp is a building material, the expressions are objects, the syntax is object. You don't want to look at it, you want to model with it, live. And with the "metacircular" (sorry for the sophisticated looking lingo) mindset, you can program how you interact with it (protorefactoring ala paredit/redshank etc).

Most people can't judge s-exp properly because they're not playing with it only looking at dead printouts; and the few who does are using a textbuffer[1], avoiding one important programming rule : automate everything. Lisp syntax has a simple and potent programmable API giving you a lot of power for free.

[1] I even watched a lisper using emacs without paredit at a meetup and it was painful.

Re: Why Racket? Why Lisp?

#50
My personal experience with Clojure has been that it 'bends' the brain - in a good way, and it forever changes the way you program. It is extremely difficult to go back to the style of coding I did before my exposure to Clojure. I guess other Lisps would provide a similar experience.
Post reply on HN