Lisp and Haskell (2017)
markkarpov.com
markkarpov.com
Lisp (Common Lisp) is what you get when you reduce the rules and syntax to a minimum and try at the same time to be a maximal flexible programming language. This simplicity and applied pragmatism is what makes it so great. Like the authors in the Lisp books warned, after learning Lisp, coding won't be the same. Now I see everywhere code that could easily be written in Lisp, but is not so great in language XYZ. All those SDL's and stringified API's and code-generators they need to do real things and data formats like JSON... all obsolete, if they would have chosen Lisp (or a language with brackets and Lisp like evaluation rules).
The other thing that is often overlooked regarding Lisp is, that in a Lisp like language there is no need to wait for a new version of the programming language to be released to get new syntax – you can simply add it yourself (or have a library doing it for you). E.g. a lot of the JavaScript mess could be fixed by code transformation, if they would have chosen a Lisp like syntax in the first place.
I don't see Haskell as uber language. If I want super correct code, speed and I'm okay with using a more complex language, then there is Rust – which is probably more correct than Haskell and faster, too.
Haskell, Lisp and C++ would really benefit form a std library 2.0 and a default package manager... one can dream.
Yes, LISP code can be easily parsed for as long as you stick to lists. However the ability to do anything complicated with LISP code is simply not there because LISP code loses type info, which is extremely important for anything you’d want to do with code, like all kinds of non-superficial transformations and refactorings.
So here are some facts given as examples:
(1) LISP code does not make the job of IDE authors easier; just ask the authors themselves
(2) in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach; for example .NET’s LINQ cannot be expressed in LISP, not unless you add a static type system, but at that point you’re no longer talking about LISP ;-)
In my opinion LISP has been vastly romanticized, yet it doesn’t live up to expectations. It falls short in every department, from functional programming, to available tooling, to the great enlightenment people are supposed to experience once they learn it.
Whereas Haskell really does live up to expectations, being one of those very few ecosystems that does make developers better, at this point being the lingua franca of FP.
> (2) in terms of macros, anything more complicated than lazy evaluation of thunks and kiddie examples is out of reach
I've seen and built tons of exotic stuff with macros. On Lisp builds a Prolog compiler if you want a specific example.
Your point about types makes me curious about LINQ. Brings to mind Julia's generated functions.
I wrote a compile-time test framework in 7 lines of Gambit Scheme code https://github.com/billsix/bug/blob/master/README.md
Doesn't that imply that Lisp, sans-static typing, is not Turing-Complete? Surely that is not the case.
Good luck expressing LINQ syntax, or Lisp syntax, or even Basic-80 syntax on it.
Syntax is important, it's a tool of thought.
Surely you can write LINQ in any Turing-complete language.
Turing completeness doesn't describe expressivity of source code, as far as I understand it - it describes the ability to produce a desired outcome. So yes, you can perform the same operations LINQ allows, in Lisp or any other Turing-complete language. But can you do it while giving the programmer the same (or a similar enough) experience? From the .NET docs:
> Language-integrated query allows query expressions to benefit from the rich metadata, compile-time syntax checking, static typing and IntelliSense that was previously available only to imperative code. Language-integrated query also allows a single general purpose declarative query facility to be applied to all in-memory information, not just information from external sources.
Now, to be fair, I'm not sure you can express all that in Haskell either. And it could be reasonable to argue that a few of those benefits (e.g. intellisense) just _haven't_ been done for Lisp, not necessarily that they _can't_ be done.
It's lambda complete. Which has been famously proven to be the same as turing complete.
Also type checking is basically more or less putting restrictions on your code. If there is a language that doesn't have the syntax to compute certain things, how would restricting that language via type checking suddenly cause it to be able to compute everything and be turing complete? Makes no sense. To make a language change from not turing complete to turing complete you have to expand.. not restrict ... but expand it's computational ability. Again Type checking serves to restrict.
Type checking is essentially just pre runtime special syntax for:
define add (x,y)
if type(x) != 'int' or type(y) != 'int':
throw TypeError
return x+2
(define (int) (x)
(if (equal? type(x) 'int') (x) (error 'Type Error'))
(define add (x y))
(+ int(x) int(y)))
He doesn't know what he's talking about.
The point of static type systems isn't that they add power -- it's that they take power away. Thus empowering the programmer to reason in a restricted subset of "all the possible things".
[1] I'm ignoring the detail of there actually being a way to interface with the actual physical hardware, but I think we can assume that in any remotely practical TC language.
That's an extraordinary claim. Do you have extraordinary evidence to back it up?
Then the provider can decide how it wants to do it, based on the types and operations involved. A SQL DB based provider can’t safely push any work to the database if it doesn’t know the structure or types of the objects and properties in the expression tree. It would have to return whole tables and perform all evaluation in the app where types could be handled dynamically.
I think something like typed racket or clojure may support it, but many lisps would not.
Isn't that the exact definition of the "unquote" and "unquote-splicing" operators inside a quasiquote?
Honestly asking since I'm not past the "makes my head hurt" stage of scheme macros, probably doesn't help that the quasiquote macro is buggy in my minischeme sandbox.
But it doesn't even have Higher Kinded Types! What a disgrace. /s
I do wonder, what would OP, or any seasoned Haskell programmer, think about Rust. Would they consider it strange? Primitive? Too mainstream?
The combination of type classes (traits in Rust) and HKTs in Haskell mean that you can quite easily restrict a function to only be able to do a subset of what's possible in "the world".
A trivial example would be
foo :: Logger m => Int -> m ()
The thing is that given the restrictions of parametric polymorphism that function 'foo' has to work for any Logger instance we give it, so it absolutely cannot do anything other than pure computation or invoking the "log" method. It cannot do any other side effects at all. So, it's not "pure", but it's also much more restricted than "impure".
That's a very powerful tool for modeling highly effectful systems.
Syntax isn’t as nice as Haskell as well. A Haskell programmer fed up with purity would just move to Ocaml or F# tbh.
Only inside the echo bubble of Haskell.
Rust can be put to use in any place, without advertising it for it even -- and already powers widely used code across the world (and not just in Mozilla).
Haskell use mostly concerns a few financial institutions...
...who somehow have more resources to employ programmers than the organizations using Rust. Funny, that...
It's not like all the financial sector runs on Haskell or something -- the majority uses the usual culprits. The stories behind these organisations that I've read of is of some opinionated PM going in and making Haskell or OcamL and the like the officially supported language -- in Jane Street and Standard Chartered and the like. Which is the definition of being an outlier choice.
So, yeah, they are "more programmers" wanted for those 20+ and 30+ year languages, compared to a merely 3 year old language (Rust 1.0 was released in 2015).
But nowhere near the momentum.
Rust has been used already by Dropbox, Canonical, Cloudflare, Atlassian, Microsoft (Azure), Chef, Mozzila (of course), and tons of others in backend and client code. And that's in 3 years, and while the language is changing and core libs are still being built.
And it's silly to judge by job postings, as those places don't need to advertise for specific Rust roles (they can get regular systems programmers or use their own existing devs and have them do Rust). It's not a huge paradigm shift like with Haskell where you'll need people with that kind of training already. Besides, Rust is so new, there would be little point asking for Rust devs explicitly.
Regardless, having the flexibility to program in the most appropriate style is nice.
When I write applications, I don't need a systems language, and Haskell is easier to use.
Also, Rust is a great imperative language, it's not as great as a functional language, and you can't reap the benefits of pure functional programming.
Rust is currently in the process of baking asynchronous I/O into the language, and their implementation cannot do this: http://blog.sigfpe.com/2008/12/mother-of-all-monads.html.
I found Haskell much more practical because it makes refactoring truly easy, but I'm very "programmer-centric". I mean 'refactoring' in the strict sense of preserving absolutely all the existing behavior, including side effects. That is extremely difficult if you can have side effects all over the place. (Strictness obviously helps a lot, but it also has downsides.)
Btw, given your experience and if you want to try Lisp seriously I'd probably recommend Racket, Typed Racket and their Turnstile experiment(?).
I’ll look into Racket and friends. Thanks
I find it extremely pragmatic, but perhaps not in the way most people use the word. It's pragmatic about the abilities of programmers to get every single detail right all of the time, i.e. it discards that notion entirely. We will not get things right enough of the time and so the language must support and help you. This goes all the way from simple static typing to enforcing Purity of Essence, I mean, Functions.
If you don't care about managing side effects you can always just write everything in IO and slap a "pure" here or there. Haskell's actually also a pretty good imperative programming language, IME.
I don't think it's fair to say something is "not so great" because it takes more than a few weeks to learn. That logic leads to a sad place. You suggest using Lisp and maybe Rust, but both of those languages would probably take more than a few weeks to learn.
Also, you could just use the IO type on every function in Haskell, and thus eliminate the separation between pure and impure code. You'd only have to a type a few extra characters here and there, which isn't ideal, but is acceptable while being pragmatic.
Haskell has had a default package manager, called "cabal", for many (15+ ?) years.
1 compiler notes:
scratch.lisp:10:7:
warning:
The function (LAMBDA (X) :IN ADD-TEXT-PADDING) called by MAP-INTO returns NULL but CHARACTER is expected
See also:
SBCL Manual, Handling of Types [:node]
--> TRULY-THE SB-KERNEL:%MAP
==>
(MAP-INTO (MAKE-SEQUENCE SB-C::RESULT-TYPE (MIN (LENGTH #:G51))) SB-C::FUN
#:G51)
Compilation failed.
The key difference is "impedence matching". An impedence mismatch occurs when you hook a soda straw to a firehose. There is a lot of friction and lossage. In programming terms, there is an impedence mismatch between your problem and the computer. You use a programming language to bring them together.
In assembler, you have to move your problem all the way to the machine. In Haskell, you have to move your problem all the way to the type system. In lisp you can write at the machine level (e.g. (car x) which is just a pointer fetch) or your can write at the problem leve (e.g. (integrate (sin x)))... or you can do both in the same statement (car (integrate (sin x))).
In other words, lisp allows you to craft a solution that is close to the machine and close to the problem at the same time, in the same language.
What were some unsettling points about the Clojure project you worked on? One thing I’ve noticed is that since Clojure is a relatively new language, a lot of newer lispers will start off with it, and I imagine that companies are more likely to try Clojure than CL as a first lisp. Consequently, the Clojure code you run into on the job may be of lower quality.
But the main failure in my opinion was absence of good development patterns which leverage strengths of the language and mitigate weaknesses. Dynamic languages such as lisp absolutely need REPL as primary development mode, conventions has to be strictly enforced and consistency is much more important than in languages with rich static typing. Clojure can be and is successful in many projects. But if your team is trying write Java with parenthesis everything is hard.
I think a lot of languages will give a pleasant experience in a proper environment. The question then becomes, does a strict language like Haskell require less of a 'proper' environment?
That would be interesting to research -- though the amount of variables (team member's experience, team culture & hierarchy, company culture, financial interests, deadlines, project size, software development process, etc. etc.) would probably be hard to account for. All of them can have a very big impact on how software gets written.
Most influential was pair programming which I personally hated but had to admit it works.
~> sbcl
This is SBCL 1.4.7, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
* (defun add-text-padding (str &key padding newline)
"Add padding to text STR. Every line except for the first one, will be
prefixed with PADDING spaces. If NEWLINE is non-NIL, newline character will
be prepended to the text making it start on the next line with padding
applied to every single line."
(let ((str (if newline
(concatenate 'string (string #\Newline) str)
str)))
(with-output-to-string (s)
(map 'string
(lambda (x)
(princ x s)
(when (char= x #\Newline)
(dotimes (i padding)
(princ #\Space s))))
str))))
; in: DEFUN ADD-TEXT-PADDING
; (MAP 'STRING
; (LAMBDA (X)
; (PRINC X S)
; (WHEN (CHAR= X #\Newline) (DOTIMES (I PADDING) (PRINC #\ S))))
; STR)
; --> TRULY-THE SB-KERNEL:%MAP
; ==>
; (MAP-INTO (MAKE-SEQUENCE SB-C::RESULT-TYPE (MIN (LENGTH #:G51))) SB-C::FUN
; #:G51)
;
; caught WARNING:
; The function (LAMBDA (X) :IN ADD-TEXT-PADDING) called by MAP-INTO returns NULL but CHARACTER is expected
; See also:
; The SBCL Manual, Node "Handling of Types"
;
; compilation unit finished
; caught 1 WARNING condition
ADD-TEXT-PADDING
*
What was most eye-opening for me about CL was just how helpful the compiler of a dynamically typed programming language can be.
(Also, type inference is orthogonal to static vs dynamic typing.)
By your logic, Common Lisp is both dynamically and statically typed, because compile-time type checks are done by the compiler and warnings/errors are signaled whenever proper.
More, if you declare (OPTIMIZE SPEED), the compiler is going to print a list of all places where it was unable to infer types on its own and where it expects help from the programmer in form of type declarations for individual variables.
Since it is required, it wants to be a required parameter.
Whilst not “finished”, what she’s done here is incredible. It’s an implementation of Haskell semantics as Racket macros.
Another way to describe it exploratory vs implementatory.
In some ways Common Lisp is like Mathematica for programming. It's a language for a computer architect to develop and explore high level concept. It's not a accident that early Javascript prototype was done in common lisp or that metaobject protocols, aspect-oriented programming, etc. were first implemented and experimented with Common Lisp.
>Dalinian: Lisp. Java. Which one sounds sexier?
>RevAaron: Definitely Lisp. Lisp conjures up images of hippy coders, drugs, sex, and rock & roll. Late nights at Berkeley, coding in Lisp fueled by LSD. Java evokes a vision of a stereotypical nerd, with no life or social skills.
But when it comes to CL, he has expectations:
>I’ve opened an issue on GitHub of one quite popular library, asking the maintainer to write documentation, but after 6 months it’s still not written (strange, right?).
That said, and not defending the author, I would add, that as an advanced beginner in Haskell, I find types to be sufficient documentation.
Very often if I look for something in Hoogle, I would be just skimming through type signatures looking for what I want. If I look for something specific I would just put the type I want into the search field.
On the contrary, f.x. with Java I tend to either google the operation I want to do using queries like "How to do blah" or read javadoc in advance to mentally index what a given library has. And there you really need to read into the text trying to figure out why a method is overloaded multiple times with some obscure extra boolean flags.
edit: grammar
I have to disagree, types are not sufficient as documentation and this is what kept me from making the jump to Haskell actually.
But types are better than nothing, or better than outdated documentation. I can’t imagine anything worse than code written in a dynamic language and without any documentation.
This is the same discussion as with types vs tests. Types give you certain proofs for free, freeing you from writing certain types of tests. And they make property based testing easier. But the ideal is to have types + tests, types + good documentation, etc.
My problem with Haskell: I use a subset of Haskell and when using Emacs/Intero/etc. I feel like I am productive and I enjoy myself. But, reading and understanding/modifying other people’s code is like running through mud. BTW, I wrote a Haskel book that just uses the small subset of the language that I use.
I very much enjoy working on my own projects in Haskel and using Emacs and a repl feels a lot like my 30 years experience using Lisp languages.
I also use Common Lisp, but now mostly just for paid projects, not as often for side projects. (I wrote a Common Lisp book for Springer Verlag in the 1980s, which is probably why I still get occasional CL consulting work).
Why is it "a wonder"? We could, and did, write robust code, for decades before testing and TDD became a thing.
So? Tons of the software of the 70s and 80s exists today too. In COBOL form, it powers some of the more critical banking, government, etc, systems. In C form, it powers just about everything else.
>Are you suggesting testing is unnecessary or ineffective?
Of course it's ineffective. It can only prove the present of errors, not their absence.
>If it is effective, why wouldn't Quicklisp use it?
Because the need for testing also depends on how often you refactor and change your code, and how many bugs you're likely to put in it in the first place (based on the complexity of the domain, your skills, etc). I'd say both of those things are no issues for Quicklisp.
So, if having no tests works for Quicklist, and the program doesn't have many bugs people complain about, then that's it.
If a codebase works, is used, and doesn't seem to have bugs people complain about, we should also consult with reality when deciding if it's worth our time to write tests for it, not just some a priori ideology that they're necessary.
Also, if memory serves, things that I had to deal with in late 1980s and early 1990s were vastly simpler than what is normal today. Manual testing was more feasible.
At any rate Rust and Swift are both good examples of efficient languages that can easily make use of low-level system and processor features and which offer a good C FFI.
Another similar idea is Fowler's software development attitude [3]. He uses the terms "enabling" and "directing" instead.
[1] https://plus.google.com/110981030061712822816/posts/KaSKeg4v...
[2] https://news.ycombinator.com/item?id=4365255
[3] https://www.martinfowler.com/bliki/SoftwareDevelopmentAttitu...
For this reason alone, I can really see why python has been so enormously runaway successful.
The only difference in a static world would be the error would have showed up a few seconds earlier, before he needed to run it in the repl.
I mean, the error was definitly vague from CL, but is that really because it lacks static typing that the error is vague?
I thought he was trying to allure to something more.
> Complex definitions tend to be wrong when first written down. In fact, not only wrong but nonsensical. Most programming errors are not subtle!
Static type systems will tend to find those bugs. They're not subtle!
Running the code—just once—will also tend to find those bugs. They're not subtle!
And of course naming things is a huge part of this, not just the raw syntax.
Maybe it's time to reconcile with reality: there is more than one way to operate; there is value in more than one paradigm.
In my experience, with large projects, you get to pick 2:
Dynamic typing Development velocity Reliability
I've seen multiple large projects grind to a near halt in their development speed, and I've seen some retain development speed, but unreliably crash after various changes.
UT coverage is expensive. System tests don't catch everything. Either you fear changes, and the system rots, or you work very slowly with coverage for everything.
Quicklisp also downloads and executes code over plain HTTP with no integrity checks whatsoever.
This is the TXR Lisp interactive listener of TXR 197.
Quit with :quit or Ctrl-D on empty line. Ctrl-X ? for cheatsheet.
1> (defun add-text-padding (str nspaces : newline-p)
(let ((padding `\n@(mkstring nspaces)`))
(when newline-p
(set str `\n@str`))
(regsub #/\n/ padding str)))
add-text-padding
2> (add-text-padding "hello\nworld")
** (expr-2:1) add-text-padding: too few arguments
3> (add-text-padding "hello\nworld" 3)
"hello\n world"
4> (add-text-padding "hello\nworld" 3 t)
"\n hello\n world"
I've never heard of trivial-update, but TXR has something like it built-in that I independently invented called upd:
1> (defvar a 0)
a
2> (upd a (+ 2) (* 3))
6
3> a
6
TXR Lisp also has a well-featured command line option parsing library built-in:
On the other hand, haskell seems to be a struggle. I recently downloaded the book "Write yourself a scheme in 48 hours" written in 2007. Page 18 tries to "import Monad", which fails. I tried surfing for that string and only see "Control.Monad". I tried installing the lastest Haskell and the workbench. Still no luck. So, 18 pages into a book written 11 years ago and the trivial examples don't work.
If you want to get legacy code to run with a current version of GHC, try "ghc -XHaskell98".
I understand the benefit of using the same name as you can trade on the prior mindset. But if old code won't compile then it isn't the same language.
If you're going to change a language with a standard (e.g. Haskell98), change the name. Call it Peyton or something. Otherwise there will be a Haskell20 that is refactored for dependent types that won't compile under Haskell10. Then when people claim to "know haskell" the question becomes ... which language?
The "current standard" game leads into "library hell".
How likely this is going to bite you in practice, though, is a different question, and one where the specifics of the language are important.
C++ is a language without a module system; instead, the preprocessor resolves #include directives by textual substitution, which is of course extremely fragile wrt. compatibility, particularly considering idiomatic "header-only libraries" of the boost variety.
Haskell doesn't use #include but has a module system, which avoids a lot of the C++ standard incompatibility issues, because you can compile each module independently with its required language standard.
Also note that there is a pragma you can put into modules to specify the version directly inline, e.g., "{-# LANGUAGE Haskell2010 #-}" or "{-# LANGUAGE Haskell98 #-}" .
Before I comment about some aspects of the blog, about my background: I am a professional Lisp programmer, in the recent years I used Common Lisp less (working more with Scheme-style Lisps as they are provided by my work environment), but I have implemented (and sometimes still have to maintain) reasonably sized productive applications in Common Lisp.
The blog starts with the remark that coming back to his code after months took an hour - I consider this quite a reasonable time. You might be lucky and look at a function which can be modified without the consideration for its environment, but often you have to spend quite some time before you can do changes - this has very little to do with the language.
Then the example he basis his blog post on - I think it has several issues, some already pointed out by other posters. Padding should be a required unsigned integer, not a keyword param - if you omit it (it then becomes NIL), the function will error. While current SBCL compilers even warn about the map function is called, older ones don't give a good warning and not a great error message at run time. But the main issue here is: map is the wrong function to use in this context. Map, as he used it, builds up a string from the return results of the functions it calls in the iteration, but this string is not used by the algorithm, because it writes to the string output stream s instead. Directly looping over the characters in s with "loop" would have been the better way to do it here. Interestingly, I don't think I have ever used map in my Lisp programming career so far.
The rest of the post focusses on two things, that Common Lisp doesn't have enough libraries, and static vs. dynamic typing. Funny though, that he praises Python, where the availability of libraries certainly is great, without acknowledging, that Python is way more dynamically typed than Common Lisp. The side comment "Macros are missing, but you can live without macros after all." is hand-wavingly dismissing one of the strongest features of Common Lisp. They should be used with care, but macros are what puts Common Lisp ahead of most other languages - you can, inside your project, make careful adjustments and extensions to the language itself.
So, yes, the amount of libraries has some point, but attacking the one guy, who did most to give all Common Lispers easy access to lots of libraries, for "not writing tests" is not strengthening the argument. And while the Common Lisp community indeed could use more active contributers and more libraries, blog posts like this rather deter people. It would have been more productive to call for contributers. And from my own practical experience: yes libraries are very valueable and sometimes essential to start a project. But once you become a maintainer of production software, they can be also quite a liability, as you depend on a piece of software you don't maintain.
This leaves the critique of the lack of static typing in Common Lisp. First of all, yes, Common Lisp is not a statically typed language. If that is a blocker, use a static typed language, but then don't praise Python. There are many reasons which speak for static typing - and that is also a reason I have added Go to the programming languages I use. A proper static type checker can be quite a help developing. Interestingly in this context, Go uses a very limited type-inferencing, so that usually the type declaration of the function parameters is enough so that you don't have to explicitly type local variables. Which brings us back to what Common Lisp offers, especially SBCL: optional static typing. You can declare the type of any function parameter and the return results of functions. You can declare the type of any local variable. Depending on your "optimize" settings (speed/safety), SBCL will insert the necessary type checks and use the type information in its type inferencing engine, and create type errors, wherever it can detect them. With fully-typed code, SBCL can generate code which matches and occasionally even exceeds the output of gcc. So, Common Lisp has a lot to offer, which the author had not tapped into.
Common Lisp offers optionally unsound static typing.
(SBCL doesn't change that, that's why it inserts runtime checks.)
SBCL does offer optional static typing as it goes beyond Common Lisp and can perform static type checking across compilation units.
If you have a lisp file like:
(defun foo (x) (declare (fixnum x)) (* x 2))
(defun bar () (foo 3.5))
; file: foo.lisp
; in: DEFUN BAR
; (FOO 3.5)
;
; note: deleting unreachable code
;
; caught WARNING:
; Asserted type FIXNUM conflicts with derived type
; (VALUES (SINGLE-FLOAT 3.5 3.5) &OPTIONAL).
; See also:
; The SBCL Manual, Node "Handling of Types"If some part of your program extracts values from a heterogeneous list and calls foo on one of them, SBCL will not be able to statically guarantee that it is a FIXNUM at runtime. It can't reject the program either, that would require seriously subsetting the language.
In that case, everything extracted from a list is T and you'd have to get that warning you mentioned above.
Such warnings would very likely be false-positive, unless Common Lisp programs are buggy as hell most of the time—assuming that would be the real FUD, no? Therefore, the non-FUD conclusion is to expect a high rate of false-positive warnings in typical list-using programs.
TBH, I suspect those false-positive warnings you mentioned aren't bona fide warnings, but some kind optimizer stream-of-consciousness log stream.
(defun sum (lst)
(let ((acc 0))
(dolist (x lst)
(setq acc (+ x acc)))
acc))
(sum '("a" "b" "c"))
Common Lisp has a (CONS α β) type for cons cells with member types α and β, but its LIST type is defined as (OR (CONS T T) NULL), basically more of a binary tree type, where T is the Common Lisp "any" union of all types.
A useable (LIST α) type would be something like μβ.(OR (CONS α β) NULL), but that's not expressible within standard Common Lisp. I expect it to very hard to infer too, especially with CONS cells being mutable.
The sad thing is I've never really used it in any "productive" way. Never for a freelance gig, and absolutely never in my job as a web developer. That being said, I have learned to appreciate languages that I don't necessarily use to directly make money.
I've learned a lot of programming concepts from Lisp that will be with me forever. Thinking about problems in a functional way has been beneficial to a lot of my work.
Look at the stack trace first, what funtion signals that.
What can you even do given such a value?
Either each element has some "handler" that does the right thing for that data type.
Or you have a set of cases that each data can be, and you handle them all.
Neither is just "any type". And static types are very suitable to describe either.
Haskell and OCaml are both functional programming languages (well OCaml has OO support as well) that have a REPL, interpreter, and native code compiler. They have decently sized communities considering that they are mainly academic languages although Haskell is starting to see industry use at some big name companies like Facebook. OCaml is maintained by the French national lab INRIA and is extremely popular at the fintech firm Jane Street. OCaml inspired much of the syntax of F# (.NET functional programming language). Haskell takes functional programming to the extreme and has a lot of academic jargon (Monads) that can turn off beginners. Scala is like OCaml in that it has support for both OO & FP, but it runs on the JVM and you can use Java libraries. I think both Haskell and Scala have excellent concurrency support. I forget which one uses STM. OCaml has been supposed to be getting multi-core functionality for a long time I think. These three languages are all pretty standard business languages that you could build a business out of. The fact that Scala can use the JVM is super super nice as a lot of Haskell and OCaml libraries are not something I would trust in production. FPComplete is a consultancy for helping firms use Haskell commercially.
Nim is a language with Python like syntax that transpiles (or compiles) its source code to C or JavaScript and then uses those compilers to get really fast code and an executable to distribute. It is still pre 1.0, but it has the option to use or not use garbage collection. A pretty cool language. It can be used for fairly high level projects where Python might normally be used, all the way to OS and video game work with some effort. Rust is mainly meant to replace C++ (closer to D than Nim, but they do overlap some). Rust uses the LLVM compiler and is being used at Mozilla. It currently has had a lot of hype for awhile. It is supposed to be a really safe language. The syntax is a mix of imperative, OO, and FP in my opinion. It is quite fast. Lastly Shen is a research language from Mark Tarver (wrote the bipolar lisp programmer essay). Last time I looked it focused on theorem proving and ran on top of another lisp (can't remember, but maybe Racket or Common Lisp). It used to have a pretty odd license, but I think it's been fixed for awhile. It has built in support for prolog functionality like some other lisps which is cool. He also has taken time to write some libraries which let you use Tk for GUI, which is also neat. I wish I had time to check it out.
Lisps are kind of like the ultimate dynamic languages, while Haskell is like the ultimate static language. Lisp has more flexibility, but the Haskell compiler will catch a lot of bugs.
Can you give Some compare on their type system detail? Thanks.
The type system is quite similar to C++'s one, just that the language has better support for meta-programming, modules, packages and explicit notion of unsafe code (system in D speak).
Code generation at compile time is done via compile time code execution, templates or plain replacement.
It has a GC, but like all GC enabled systems programming languages, has mechanisms to control its execution, forbid its use in performance critical sections (@nogc attribute) or just manually allocate memory via stack, globals or plain OS calls.
I don’t know if I’d describe JS as a fintech. Their technology is not their product that you can buy, it exists to power their real business, which is prop trading.
Most banks don't have lots of people writing complex algorithms for their day to day job.
[1] Some of these features can be emulated in Haskell, but AFAIK it's kinda clumsy at the moment. There's an ongoing initiative called DependentHaskell that aims to improve that.
It's compiled with C compiler or to JavaScript currently, no JVM implementation. You might be confused with Scala.
Clearly the author has yet to encounter HOtMEfSPRIbNG!