For anyone interested in Racket, excellent book/online tutorials
http://beautifulracket.com/
Why I haven't jumped ship from Common Lisp to Racket just yet
61–70 of 101 posts
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#62Anyone using Racket in the wild? (Besides the Racket team)
John Carmack is pushing for Racket at Facebook/Oculus
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#63The 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…
"How to make Lisp go faster than C" (2006) http://www.iaeng.org/IJCS/issues_v32/issue_4/IJCS_32_4_19.pd...
Reading that a bit, it makes me think about the current "push" in Python to add types whenever necessary...
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#64Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#65Racket 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.
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#66Earlier quoted context omitted.
> is that the standard is stuck in time, lacking stuff like database providers, a common FFI or threading. You don't need database providers to be integrated in the language spec. Not in CL and not in many other successful languages. We already have a de facto common, portable FFI: CFFI. We already have more than one library to do threading in a portable way. Also, threading has been left out of the CL standard on pu…
> 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 cannot guarantee portable semantics across implementations.
There does not exist a single, one-size-fits-all, valid-for-all-use-cases approach to concurrent programming.
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#67Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#68Earlier quoted context omitted.
> is that the standard is stuck in time, lacking stuff like database providers, a common FFI or threading. You don't need database providers to be integrated in the language spec. Not in CL and not in many other successful languages. We already have a de facto common, portable FFI: CFFI. We already have more than one library to do threading in a portable way. Also, threading has been left out of the CL standard on pu…
> 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…
Note that bordeaux-threads, like CLIM-SYS or CFFI-sys, is not only a portability layer, but also a standard:
BORDEAUX-THREADS is a proposed standard for a minimal MP/Threading interface. It is similar to the CLIM-SYS threading and lock support, but for the following broad differences:
Some behaviours are defined in additional detail: attention has been given to special variable interaction, whether and when cleanup forms are run. Some behaviours are defined in less detail: an implementation that does not support multiple threads is not required to use a new list (nil) for a lock, for example.
Many functions which would be difficult, dangerous or inefficient to provide on some implementations have been removed. Chiefly these are functions such as thread-wait which expect for efficiency that the thread scheduler is written in Lisp and 'hookable', which can't sensibly be done if the scheduler is external to the Lisp image, or the system has more than one CPU.
Unbalanced ACQUIRE-LOCK and RELEASE-LOCK functions have been added.
Posix-style condition variables have been added, as it's not otherwise possible to implement them correctly using the other operations that are specified.
Threads may be implemented using whatever applicable techniques are provided by the operating system: user-space scheduling, kernel-based LWPs or anything else that does the job.
Some parts of this specification can also be implemented in a Lisp that does not support multiple threads. Thread creation and some thread inspection operations will not work, but the locking functions are still present (though they may do nothing) so that thread-safe code can be compiled on both multithread and single-thread implementations without need of conditionals.
To avoid conflict with existing MP/threading interfaces in implementations, these symbols live in the BORDEAUX-THREADS package. Implementations and/or users may also make them visible or exported in other more traditionally named packages.")
From a practical point of view, I consider portability layers to be sufficient; but having those additional standards offer stronger guarantees across implementations.
https://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocume...
https://common-lisp.net/project/cffi/spec/cffi-sys-spec.html...
Re: Why I haven't jumped ship from Common Lisp to Racket just yet
#69Earlier 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…
Note that bordeaux-threads, like CLIM-SYS or CFFI-sys, is not only a portability layer, but also a standard: BORDEAUX-THREADS is a proposed standard for a minimal MP/Threading interface. It is similar to the CLIM-SYS threading and lock support, but for the following broad differences: Some behaviours are defined in additional detail: attention has been given to special variable interaction, whether and when cleanup f…
Just for showing how Bordeaux-Threads can be considered almost universally portable. This is the list of Lisp implementations supported by Bordeaux Threads:
- Armed Bear Common Lisp (ABCL)
- Allegro Common Lisp (ACL)
- CLISP
- Clozure CL
- CMUCL
- Corman Lisp
- Embeddable Common Lisp (ECL)
- LispWorks
- MCL
- MKCL
- Steel Bank Common Lisp (SBCL)
- Scieneer CLRe: Why I haven't jumped ship from Common Lisp to Racket just yet
#70Earlier quoted context omitted.
> is that the standard is stuck in time, lacking stuff like database providers, a common FFI or threading. You don't need database providers to be integrated in the language spec. Not in CL and not in many other successful languages. We already have a de facto common, portable FFI: CFFI. We already have more than one library to do threading in a portable way. Also, threading has been left out of the CL standard on pu…
> 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…
> Which is why, in spite of all design flaws, even Go has a database interface defined on their core library.
It is useful, but Go is less standardized than CL. If we compare features that implementations provide, then we can cite LispWorks's Common SQL (http://www.lispworks.com/documentation/sql-tutorial/index.ht...).