Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Idea of Lisp

dev.to

Post reply on HN
Print view View original

331–340 of 348 posts

Re: The Idea of Lisp

#331

Post by samth »

qwertyuiop924 wrote: post #322
dTal wrote: post #319

Earlier quoted context omitted.

Wow, pedantic much? It started out as a pure Scheme, then "took a practical turn" as the parent said. You can still make it act like a pure Scheme with a #lang directive. It's also kind of funny that a handful of major, practical implementations is considered a low amount. Number of Python implementations? Between one and three, depending on definition. Number of Javas? 2 or 3 again. Number of Clojure implementations…

>pedantic much? Not at all. >It started out as a pure Scheme, then "took a practical turn" as the parent said. False. PLT Scheme, like all serious schemes, started out as Scheme extended for practical use. Racket, what PLT Scheme became, isn't an extended Scheme: it is a different language with its own semantics. That's not good, bad, or pedantic, but it is true. >You can still make it act like a pure Scheme with a #…

I think the truth is somewhere between what you and dTal said. First, Racket isn't much more different from "Scheme" now than when we changed the name in 2010. Second, if you copy-and-paste a random portable Scheme program into #lang racket, it will probably work. This is somewhat less likely than with most systems that call themselves Scheme, but way more likely than with Scheme's closest relatives (Arc, Clojure, etc), and similarly with Java vs C.

Ultimately, Scheme is a language family, and Racket is further away than most or all of the other members, but there's considerable distance between Guile and Gambit as well (to pick some other examples).

Full disclosure: I'm a core developer of Racket, but not all of us have the same perspective on this question.

Re: The Idea of Lisp

#332

Post by samth »

Blackthorn wrote: post #36
erik14th wrote: post #18

I wonder why lisp isn't as popular as say python for AI, ML, and stuff. I see these fields as having a strong academic tone, and it feels like racket or clojure could be bigger when it comes to that.

Well, it was. Specifically, Common Lisp was. But that language's standard was etched in stone in 1994 whereas languages like Python (where most deep learning user-facing code is done) continue to evolve. I think Python really took off for that because it already had quality and widely-used libraries for writing the code in Python and doing the work in a more efficient place (numpy, scipy). Clojure has one of those fo…

Racket doesn't have simple interfaces to things like BLAS, but it does have quite good natively written libraries for matrix operations and other math-related things: http://docs.racket-lang.org/math/

Re: The Idea of Lisp

#333

Post by samth »

omaranto wrote: post #234
samth wrote: post #56

Earlier quoted context omitted.

Matthew Butterick (the author of Beautiful Racket linked in another reply) is solving this year's Advent of Code, all as DSLs: https://github.com/mbutterick/aoc-racket

That repository has last year's challenge and the six days I checked did not involve writing a DSL.

Check out the 2016 branch.

Re: The Idea of Lisp

#334

Post by samth »

nilved wrote: post #231
thinkmoore wrote: post #216

Earlier quoted context omitted.

In a Typed Racket program that does not import any untyped racket code, there is no runtime enforcement. Runtime contracts are only introduced at the boundary between typed and untyped code. This allows programs to be soundly transitioned from untyped to partially typed to fully typed.

That sounds pretty rad. Do you know what the status is of dependent types in Racket? I have always been interested in that.

We're working on it! See the work by my student, Andrew Kent, coming soon to Typed Racket: https://pnwamk.github.io/

Re: The Idea of Lisp

#335

Post by kazinator »

anoctopus wrote: post #323
kazinator wrote: post #317

Earlier quoted context omitted.

All that immutability humbug, for starters. Traditional Lisps are "everything you can access is mutable". Lisp trusts the programmer to be responsible with mutability and not to abuse it. The trust is not misplaced; the sky doesn't fall.

Immutability was what I had in mind calling it opinionated, and it's an opinion I agree with. After learning Clojure, I now hate working in languages with mutability. It obviously isn't necessary to make working applications, but I like not having to think about where else I'm passing this particular data structure, and the language has enough escape hatches for places when it really would get in the way.

This is merely a psychological issue, because when you're programming in an "everything-mutable" Lisp dialect, you also don't worry about this. If you don't know where else you're passing that data structure and don't care to find out, then ... you don't mutate it. Libraries and API's simply don't mutate the inputs that you pass to them, unless loudly documented otherwise. Thus, mutation is applied in controlled ways whose scope is easy to ascertain and limit by inspection.

Re: The Idea of Lisp

#336

Post by lmm »

Nekorosu wrote: post #267
lmm wrote: post #95

Earlier quoted context omitted.

It's not clear to me whether the comment I replied to viewed this as a good or a bad thing (all it said was "funny how..."), so I can't say whether I approve or disapprove. Hopefully it's clear where I stand though.

True. The only clear thing is that nothing is clear in this particular discussion branch. I'm ok with this but can't extract any useful information.

I think there's information, we're just not taking sides for/against. Which is fine.

Re: The Idea of Lisp

#337

Post by stcredzero »

rntz wrote: post #328
Ericson2314 wrote: post #313

Earlier quoted context omitted.

This...is not possible?

No, it's possible. The key insight is that a "rational number of unlimited precision" can be used to store an arbitrarily large amount of data; it can emulate a Turing machine's unlimited working tape.

You win a stcredzero "no-prize!"

Re: The Idea of Lisp

#338

Post by shakna »

WhitneyLand wrote: post #97

I know their is an active community around Lisp and it's still used for development, but I apparently have not dug deep enough to appreciate when it's the best choice for a new project. Can someone mantion a few features or scenarios that make it the best choice for starting a new project?

There's two places where I find LISPs useful.

* Where I might prototype something in Python usually, I can build the Scheme equivalent just as fast, and thanks to Gambit or Chicken's speed and static compiling, it can grow to be bigger than just a prototype with few tradeoffs.

* Anytime I need a DSL, if it isn't LISP, I find myself either disappointed by slowness, or fighting with the language. Example: HTML templates. (x-expr are great!)

In short, speed and flexibility.

Re: The Idea of Lisp

#339

Post by bogomipz »

rntz wrote: post #327
bogomipz wrote: post #289

Earlier quoted context omitted.

I am confused by your comment, reference counting is a form of GC. Could you elaborate?

Often reference counting is considered distinct from GC; sometimes the term "tracing GC" is used to disambiguate. Refcounting & tracing GC have the same purpose, but different implementation techniques and performance implications; and perhaps more importantly, reference counting can't collect objects which cyclically reference one another.

That makes sense. I guess this is also why CPython uses reference counting as well as mark and sweep?

Re: The Idea of Lisp

#340

Post by bcherny »

Out of curiosity, what's the alternative to if/else? Assuming polymorphism wasn't around in the 50's, did people express the idea of conditional execution based on the result of evaluating some expression using and/or? Does this mean that lazy evaluation was around before conditionals?
Post reply on HN