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

Why I haven't jumped ship from Common Lisp to Racket just yet

fare.livejournal.com

Post reply on HN
Print view View original

71–80 of 101 posts

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#71

Post by _delirium »

flavio81 wrote: post #67
farray wrote: post #57

Earlier quoted context omitted.

And what is Arc in?

The CPython JIT/compiler is written in C. Does this mean that a Python program is then a C program? Arc is not Racket.

I suppose the original poster could clarify whether they were interested primarily in examples of the Scheme-derivative language "Racket" being used in production, or in the system/VM/runtime "Racket" being used in production. Since Racket (the system) now makes it very easy to define new languages on top of it with the #lang keyword, it might be nice to get more clearly distinct terms for these. The way the Java world uses JVM vs. Java, e.g. you'd say that a Clojure app runs "on the JVM", but it's not in Java.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#72

Post by KirinDave »

jackdaniel wrote: post #36
pjmlp wrote: post #35

Earlier quoted context omitted.

The biggest issue I see with Common Lisp is that the standard is stuck in time, lacking stuff like database providers, a common FFI or threading. It needs a review of the CL environments that survived to modern days and adopt the common extensions.

I think it is a pretty shallow view at standard. CL implementations grow and have agreed interfaces (or portability layers). A few examples: - sockets via usocket - threading via bordeaux-threads - metaobject protocol via closer-mop - foreign function interface via cffi all these are not mentioned in the standard at all, but are implemented and used in production environment. Having base standard and extensions which…

> Having base standard and extensions which may be used portably (via portability layers) is better situation than having no standard (for instance python or ruby) and a reference implementation.

Is it though?

I agree CL has (after slightly over 2 decades) worked out a standardization path for some core features that you simply cannot live without (e.g., usocket).

But all these variants are noticeably dated abstractions and in many cases the more modern expressions (e.g., threading vs more modern concurrency tooling) can't (or don't) use the compat libraries.

I'd rather have one good, crossplatform reference implementation than many competing but slightly incompatible implementations that only agree on very old standards. In that sense, I'd rather use Racket than CL.

It's true, letting go of some CL features is painful and you'll never get them back. CL's condition-restarts are an especially poignant loss in this modern era of Golang's almost comically regressive error handling schemes.

I'd like to think that if CL'er start to disperse more into other language communities that their gentle pressure and eloquent examples can help motivate other communities to adopt these features.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#73

Post by KirinDave »

flavio81 wrote: post #66
pjmlp wrote: post #60

Earlier quoted context omitted.

> You don't need database providers to be integrated in the language spec. Not in CL and not in many other successful languages. Many people underestimate how useful Perl DBI, JDBC, ODBC, Python DB-API, ADO.NET are. Which is why, in spite of all design flaws, even Go has a database interface defined on their core library. > Lisp is still pretty much one of the most modern and advanced languages around I agree with th…

> Many people underestimate how useful Perl DBI, JDBC, ODBC, Python DB-API, ADO.NET JDBC, ODBC, ADO.NET are not part of the language spec ; they are separate specifications. Your initial argument was that the language spec ("the standard") is "stuck in time". And on the other hand, database access is not really an issue on CL. > Yet using threading as an example, since it is left for each implementation, it means one…

> There does not exist a single, one-size-fits-all, valid-for-all-use-cases approach to concurrent programming.

And in CL there does not exist a common platform to efficiently build better abstractions in CL. TBF, this is only marginally worse than many other popular languages. Still, it's undeniably worse.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#74

Post by KirinDave »

flavio81 wrote: post #58
lottin wrote: post #30

> trivial utilities for interactive use from the shell command-line with an "instantaneous" feel Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers.

> Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers. You need to consider that Common Lisp includes a runtime, and this is a essential part of the goods of Common Lisp. Whenever you create a Common Lisp program, you also "embed" the runtime, and the runtime allows you to do wonderful stuff within the running code, like for example, comp…

> You need to consider that Common Lisp includes a runtime, and this is a essential part of the goods of Common Lisp. Whenever you create a Common Lisp program, you also "embed" the runtime, and the runtime allows you to do wonderful stuff within the running code, like for example, compile code on the fly, replace function with new version (while the program is running), replace class instances with new versions of the class (while the program is running), all sorts of enforcements of the required data type for actual data* (while the program is running),

Lots of other people do this without massive executables to distribute, though. CLs are inconsistent on how they can distribute base images and executables. For example, Java's compiler is a code segment you an link in if you want to carry it with you.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#75

Post by rkallos »

bjoli wrote: post #25

One thing that makes racket shine is it's macro facilities. Syntax case is nice and all that, but Jesus Christ in a chicken basket I wish scheme would have standardised on syntax-parse. Syntax case vs. syntax parse isn't and will never be close to a fair comparison. Not only is it more powerful, it also provides the users of your macros with proper error messages. It blows both unhygienic and other hygienic macro sys…

100% agreed. After using syntax-parse, it pains me to use anything else. It's a gem.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#76

Post by systems »

flavio81 wrote: post #14

The author, a famous and well-liked lisper, is not consider ing portability features. CL is an ANSI standard and code often runs with no changes in many distinct CL implementations/compilers/interpreters. Also, related to that point: There are many different CL implementations out there that satisfy different use cases, like for example JVM deployment (ABCL), embedded systems (ECL), speed(SBCL), fast compile times (C…

one of the perceived (by outsiders) CL drawbacks, is the eco system

if CL have a lot of libraries, it is not because CL have a large or active community, it is more because it existed for a long time

so, what is honestly the reality of CL ecosystem, is quicklisp a solid part of this ecosystem, is it easy to find and install packaged compared to perl and python for example?

do you think racket have a more reliable ecosystem?

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#77

Post by junke »

KirinDave wrote: post #73
flavio81 wrote: post #66

Earlier quoted context omitted.

> Many people underestimate how useful Perl DBI, JDBC, ODBC, Python DB-API, ADO.NET JDBC, ODBC, ADO.NET are not part of the language spec ; they are separate specifications. Your initial argument was that the language spec ("the standard") is "stuck in time". And on the other hand, database access is not really an issue on CL. > Yet using threading as an example, since it is left for each implementation, it means one…

> There does not exist a single, one-size-fits-all, valid-for-all-use-cases approach to concurrent programming. And in CL there does not exist a common platform to efficiently build better abstractions in CL. TBF, this is only marginally worse than many other popular languages. Still, it's undeniably worse.

Looking at Python:

https://wiki.python.org/moin/PythonImplementations

There is a reference implementation, no standard, and a bunch of implementations and/or extensions. Is it really better? What guarantees do you have? If you need to provide an extension, you have to discuss about extensions and push patches to CPython, just like you could push patches to SBCL or ABCL.

But at least (which I do not consider "undeniably worse"), CL is its own platform and offers a standard extension mechanism (e.g. compiler-macros), and implementations offer more specific extensions mechanisms (sb-vm, ...), as well as a standard way of building portability layers across implementations. Those features are used to define and implement new standards. How is that "undeniably worse"?

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#78

Post by pera »

maxiepoo wrote: post #65
mjmein wrote: post #3

Racket is a really exciting language, especially with its focus on building small languages to solve problems. However, where it fails for me is in its lack of interactive development. When I investigated it, there seemed to be no way to actually connect a repl to a running program. Unlike with common lisp or clojure, with racket if you make changes to your code you have to restart the REPL, which destroys your state…

I believe this is a design decision, because relying on some enormous implicit repl state and updating the code in place is a good way to get yourself into states that are impossible to reach in an actual running program. Racket is a functional language and it is their belief that you should just make predictable ways to startup your interactive development than rely on the entire state of some repl image.

I'm not sure if this is exactly what you are talking about, but with racket-mode in Emacs you can write some program, run it (C-c C-k), then add some s-expr and evaluate only that (C-x C-e) in the current context.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#79

Post by KirinDave »

junke wrote: post #77
KirinDave wrote: post #73

Earlier quoted context omitted.

> There does not exist a single, one-size-fits-all, valid-for-all-use-cases approach to concurrent programming. And in CL there does not exist a common platform to efficiently build better abstractions in CL. TBF, this is only marginally worse than many other popular languages. Still, it's undeniably worse.

Looking at Python: https://wiki.python.org/moin/PythonImplementations There is a reference implementation, no standard, and a bunch of implementations and/or extensions. Is it really better? What guarantees do you have? If you need to provide an extension, you have to discuss about extensions and push patches to CPython, just like you could push patches to SBCL or ABCL. But at least (which I do not consider "undeniab…

You can't use compiler-macros to build cross-platform higher order abstractions, so I don't get why they come up. They're exactly as useful as any indirection facility.

So why are they relevant here?

Not that I like Python, mind you. I miss CL, but I wouldn't go back to it. My experience is that way too many of these beloved libraries have an audience of 1 or 2, sometimes a single company. If I'm going to engage with an environment like that, I'd rather do so to access the leading edge of research and compilation results like w/ Haskell. Even Racket is more desirable than CL on this scale.

EDIT: I just wanna repeat I loathe python and carry no water for that standing wave of bad design decisions. Really. Seriously. Worst.

Re: Why I haven't jumped ship from Common Lisp to Racket just yet

#80

Post by flavio81 »

KirinDave wrote: post #74
flavio81 wrote: post #58

Earlier quoted context omitted.

> Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers. You need to consider that Common Lisp includes a runtime, and this is a essential part of the goods of Common Lisp. Whenever you create a Common Lisp program, you also "embed" the runtime, and the runtime allows you to do wonderful stuff within the running code, like for example, comp…

> You need to consider that Common Lisp includes a runtime, and this is a essential part of the goods of Common Lisp. Whenever you create a Common Lisp program, you also "embed" the runtime, and the runtime allows you to do wonderful stuff within the running code, like for example, compile code on the fly, replace function with new version (while the program is running), replace class instances with new versions of t…

> though. CLs are inconsistent on how they can distribute base images and executables

There is only one Common Lisp, the 1994 ANSI Standard.

There are many implementations and they give you diverse options of delivering. For example if you want good options to package an executable, I think LispWorks has lots of options for specifically this need.

Post reply on HN