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

231–240 of 295 posts

Re: Why Racket? Why Lisp?

#231

Post by samth »

bad_login wrote: post #230
samth wrote: post #206

Earlier quoted context omitted.

I'm glad you like Racket, and you're right about some of the weaknesses, especially in providing guidance and examples for how to do things. I have questions about points 3 and 4. For 3, do you mean it's hard to figure out how the implementation of something works, especially when that something is a complex macro? If so, I can't disagree. For 4, if you just run Racket programs at the command line, you should get sta…

For 4 if i run from the command line (racket 5.93) i just get the contract violation message, which don't provide positional informations, it's not usefull when you have a list contract error with dozen of uses in a file. For 3 i mean the words like 'visiting', 'instantiated', the phases, the syntax transformer there are many things to grasp. For instance i used to believe that phase 1 bindings where the functions ex…

Thanks for the feedback. Certainly there are lots of complicated concepts to learn in the macro system.

On 4, if I run this program: https://gist.github.com/8fbc12877e2639c5f94c I get a backtrace like this:

  [samth@huor:~] r ~/tmp/x.rkt
  /: contract violation
    expected: number?
    given: '(1 2 3 400 500 600)
    argument position: 2nd
   other arguments...:
    6
    context...:
     /home/samth/tmp/x.rkt: [running body]
There's no other stack frames because `average` is inlined, but if you have more complicated functions you should get more stack frames.

Re: Why Racket? Why Lisp?

#232

Post by sedachv »

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…

> We've figured out how to do type systems

This is probably the only valid point you have.

> a lisp programmer from the '90s would be amazed by CPAN, never mind maven

CPAN was started in 1997. A lot of Lisp programmers back then were also doing Perl, and a few people who were doing Perl then are doing Lisp now.

Whoever is "amazed" by Maven should go jump off a bridge.

> We have a bunch of reasonable approaches to effect tracking, which Lisp folk used to have to do by hand

I'm assuming you're talking about generalized arrows or something and not monads. Generalized arrows partly came out of work on linear types and parallelism done by Lisp people in the 80s and early 90s.

> We know how to solve the expression problem.

Thanks mostly to PLT/Racket people: http://en.wikipedia.org/wiki/Expression_problem

> blah blah blah Rails functionality

Rails doesn't have functionality, Rails has a bunch of shitty complicated ways of doing web programming, with a bunch of shitty poorly maintained Ruby libraries (most of the good ones are just FFI into C libraries).

If you're going to talk about modern "practical" languages, you could do better. Go is pretty great except it doesn't have exceptions. JavaScript solved code distribution and program-level virtualization. Those are much better comparisons.

Re: Why Racket? Why Lisp?

#234

Post by pmelendez »

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…

>> “Wait—I love state and data mu­ta­tion. Why would you take >them away?” Be­cause they’re false friends. >CL is NOT particularily functional. Just because we know how >to write good side-effect free code, doesn't mean its a >functional language.

He didn't claim that CL or even Lips were pure functional though:

"Yes, I know that other lan­guages of­fer func­tional-pro­gram­ming fea­tures, and that Lisps aren’t con­sid­ered pure func­tional lan­guages."

Re: Why Racket? Why Lisp?

#235

Post by taeric »

dllthomas wrote: post #226
taeric wrote: post #222

Earlier quoted context omitted.

Sadly, my own deficiencies in being able to read Haskel are keeping that from being a compelling argument. I do intend on visiting it more later. Just, right now, I prefer the dead simple to parse lisp over this.

Translating, with some minimal explanation: name :: constraints_for_type => type_of_name says "Thing named 'name' has type 'type_of_name' with constraints 'constraints_for_type'" So, minBound :: Bounded a => a maxBound :: Bounded a => a "minBound has type 'a' for any 'a', so long as 'a' is an instance of Bounded" These two are more values than functions, but the polymorphism happens the same way. If you use them wher…

I'm happy with myself for at least mostly getting what those were. I think I'd have to see more uses to really see the benefit, though.

I am curious on minBound and maxBound. They seem to be the same... What distinguishes them? Or, you are just saying these are two values that are defined. And they can only be given a value of a type that can be bounded?

Also, thanks for expanding!

Re: Why Racket? Why Lisp?

#236

Post by dragonwriter »

progman wrote: post #211
delluminatus wrote: post #149

Earlier quoted context omitted.

Wait, are you suggesting that the Haskell type system is too strong to write a package manager? That makes no sense. A much more valid reason that Cabal is annoying is that Haskell is a compiled language that uses static linking, unlike all the languages you mentioned, which are interpreted.

SBCL also uses static linking. It doesn't recompile every ASDF imported library whenever I compile my application. It just does so when it is actually necessary. Why doesn't it work so easily in Haskell? I think it's the strong type system because every small code change can break the whole fragile structure of a Haskell application. It's like wheels in an old clock. If you break one jag of a gear then the whole syst…

> SBCL also uses static linking. It doesn't recompile every ASDF imported library whenever I compile my application. It just does so when it is actually necessary. Why doesn't it work so easily in Haskell?

It does; in fact, in GHC -- the dominant Haskell implementation -- at least, its even easier: it doesn't recompile installed packages period. Packages are precompiled, and are merely linked when you compile an application that they depend on.

Aside from it being factually incorrect, I'm not sure why this is even relevant to the discussion here -- "dependency hell" doesn't come from recompiling libraries when you recompile applications, it comes from conflicts between version requirements for dependencies among packages installed in a single repository (which is why sandboxing is a tool for addressing it.) It manifests when you try to install a package with dependency conflicts with another app, not when you try to compile an app that depends on the conflicting packages.

> I think it's the strong type system because every small code change can break the whole fragile structure of a Haskell application.

I think before you try to explain why something happens, you should first be sure that the thing you are describing actually happens.

> Could that be the reason why there are (AFAIK) so many hackage projects aged or even unmaintained?

I suspect the reason is the same that there are so many Ruby Gems in the main repos that are aged or even unmaintained (and I'd be surprised if this was different in any similar package database that wasn't actively culled of non-current projects -- which would have its own downside) -- the repository system is, by design, low cost to enter, so lots of things that have no strong demand or lasting commitment get posted to it.

Re: Why Racket? Why Lisp?

#237

Post by kazinator »

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…

If it takes longer to refactor the program, that can kill the initiative to do so.

When you do get the program to run, but it turns out that the refactoring is not wanted for whatever external reason, then you just wasted more time than was necessary.

Without the bondage of static typing, you can just refactor a small enough fraction of the program, which can run now in some limited way. You can use that to motivate yourself, or to pitch the idea to other people.

It is helpful to be able to play "what if" without committing a lot of unnecessary time and effort.

Re: Why Racket? Why Lisp?

#238

Post by ColinDabritz »

smeyer wrote: post #152
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.

Interesting point. Particularly I believe that the 'coding' part isn't the real job, I'm not just an overpaid typist. So why is concise expression good?

For the record, I am NOT a day-to-day Lisp programmer, but I've played with it a little and read about it some.

I think it's because its about expressing your problem clearly. It's not "20 times less lines" so much as it is "20 times clearer expression". Not that it's exactly 20x, but it seems better. When you express things more clearly, and structure your code more like your problem, and less like your programming language, you shed a lot of accidental complexity ( See Out of the Tarpit - http://shaffner.us/cs/papers/tarpit.pdf ), so managing the complexity of your project is easier, which means fixing bugs and adding new features is also easier. I think this is the route being implied when they say you can develop features faster. I'm not so certain you'd see the benefit in a particular feature, but over time.

Note that a lot of the modern languages are picking up many of these expressive features, closing the gap there as well, which is wonderful.

Re: Why Racket? Why Lisp?

#239

Post by klibertp »

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…

There are other ways of making refactoring easy. I'm not trying to dismiss a powerful type system - which is a great help indeed - but pervasive unit tests and contracts work as well. Linters are a nice addition, and even gradual typing like in Erlang with Dialyzer is much better than nothing. The point being: problems solved by type systems are being solved with other tools, too. I don't want to argue about how well these tools work, because all of them (including static type systems) have relative strengths and weaknesses; it's just unfair to present refactorings or correctness guarantees as benefits reserved for type systems alone.

Re: Why Racket? Why Lisp?

#240

Post by klibertp »

Grue3 wrote: post #223
jsmeaton wrote: post #18

Earlier quoted context omitted.

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 program in Python for a living and I curse significant whitespace every single work day. Especially when I try to copy paste some code into the shell. It's one of the worst misfeatures of the language, and it wouldn't even be necessary if there was an "end" keyword.

Use IPython and %cpaste magic. Works well.
Post reply on HN