My problem with Haskell is that it is not pragmatic and the reason I stopped using it. The philosophy of separating pure and impure code – and to enforce it – does more harm than good. Often its difficult to understand what your "forth level of abstraction code" above the usual abstraction levels really does. Haskell is fun to learn. Haskell has a lot of interesting concepts to explore and it will make you a better programmer. Haskell code can be really dense. And Haskell code can be totally unreadable, using concepts which take weeks to learn – which is... not so great.
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.
The ability to come up with new syntax in LISP is in my opinion vastly overrated.
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.
> Haskell code can be totally unreadable, using concepts which take weeks to learn – which is... not so great.
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.
I learned Haskell and then moved to OCaml and found it to be a much more practical language. Haven’t tried Lisp yet, but it’s quickly moving to the top of my list.
>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.
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?
> My problem with Haskell is that it is not pragmatic and the reason I stopped using it.
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 everysingle 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 find that haskell is great to learn about functional programming and programming ideas, but to get things done, I stick to imperative or OO languages. Could be that I learned CS with C/C++/Java and work with C#/C++. So I just stick to what I'm familiar with.
So I put his example into a lisp file and compiled it under SLIME/sbcl, which is how I typically develop:
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.
It's also patently false that quicklisp has no tests; it has no unit tests, but it is tested as a whole thoroughly, both the code and the set of systems it provides.
There is no magic in Haskell's strong typing. Axiom, a computer algebra system with extremely strong typing, is written in common lisp. Axiom's language is essentially a domain specific language on top of lisp.
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.
You have the choice to move as much or as little to the type system in Haskell as you deem beneficial. You do not have to "type it to the max", as is commonly offered as a stereotype.
I have worked on fairly large Common Lisp project (around 500k lines of actively managed code). That was the most pleasant experience in my professional life. The refactoring was easy, introduction of new features was simple and clear. I attribute it partially to language itself and partially to the team culture. We had a lot of tests BTW. After this I had quite bad experience with a Clojure project in a different company, so I am not dogmatic about lisp supremacy anymore. Still, Common Lisp definitely can be extremely successful in production given proper environment.
I’ve been programming lisp for a few years now (Scheme then CL) and write Clojure daily for my current job. I initially described Clojure as: the worst dialect of lisp I’ve used, but the only one I’ve been paid to write in. It’s grown a lot on me over the past few months, but I still end up missing CL every now and then at work (I think I mainly like CL’s Slime more than Clojure’s Cider).
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.
Second that. I did write production Common Lisp code and loved it. I've used various languages over the years, including Perl, C, C++, C#, JavaScript and Python (and Pascal, Basic and x86 assembly to some degree, too), and I mostly write Go code nowadays (Kubernetes-related stuff). Still, none of these languages or their environments matched the Common Lisp coding experience with plain Emacs and SLIME.
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.
For what it's worth, on a fairly recent SBCL, here's what the compiler/interpreter prints when you enter the author's function:
~> 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
*
Thus, it identifies the exact problem the author describes at the end.
Also: why would padding be an optional keyword parameter (defaulting to nil!) when it's required to be a non-negative integer for the function to work correctly?
Since it is required, it wants to be a required parameter.
Totally agreed... I wish I had her talent ;-)
Hackett actually inspired me to start a project that goes in the opposite direction, i.e. from LISP to Haskell rather than Haskell to LISP. I'm a PL amateur, so it's been really interesting to implement a macro system on top of an existing language, without it being difficult to use or seeming like a hack.
Common Lisp as hackish vs protective is nice way to describe it.
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.
One of the points the author touches is documentation. I just couldn't get why then he gave advantage to Haskell, since the documentation of Haskell libraries famously consists of a few definitions of types. So, you know that there is an abstractly named monadic function, you know it takes a foo and returns monad foo. What more guidance would you ever need?
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.
I enjoyed reading this article, fun read, even though I don’t agree with much of it.
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).
>Speaking of tests, recently I discovered that Zach Beane AKA Xach, an über-level Common Lisp hacker doesn’t usually write tests. FYI, he is the author of Quicklisp, that is something like (but not quite) Cabal or Stack. Quicklisp is de-facto the only widely used library manager in Common Lisp world, and so it’s written in Common Lisp and doesn’t have any tests. It’s a wonder for me how it’s not breaking!
Why is it "a wonder"? We could, and did, write robust code, for decades before testing and TDD became a thing.
I think the bigger problem, conceptually, is the assumption that tests are necessarily something you write and not something you do. There's nothing wrong with having automated tests, but they're a supplement to hands-on testing, not a replacement for it.
Informal and manual testing was a thing back then, though. Building a large project is usually a good, nearly exhaustive test suite for a build system.
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.
The distinction between "hacking" and "protective" languages is a good one. If you want to be balanced as a programmer, you need to deeply understand at least one language in both categories. Protective languages are wonderful for large-scale projects (true "software engineering"), but they tend to lack the whimsy that drew so many of us to programming in the first place.
Can you elaborate? What languages would fall in either category (I’m assuming python would be hacking and haskell would be protective)? Does static vs dynamic typing play a role?
The older I get, the more I realize that the ultimate factor in programming productivity is how readable the language is, or how readable the typical idioms and usage of that language are. There are a lot of really awesome languages, but they are tremendously difficult to read your own code, let alone someone else’s. You can find languages that are very expressive while you’re writing the code, but that code will be read much more often than the time you spent writing it, both by yourself and likely by other people.
For this reason alone, I can really see why python has been so enormously runaway successful.
But he did get a runtime failure. Imagine this wasn't about adding a function, but changing an existing function that is being called from 23 different locations in a 100kloc codebase, and that it contains some tricky condition logic so that a bug might only be triggered in 5% of the calls. Without exhaustive unit tests, a type error potentially would not show up until all those call sites had been executed with the specific arguments required to trigger the bug. His point was that in a statically typed language, this would all be detected at compile time.
The error was just bad, it could have been more explicit, and by now SBCL even issues a compile-time error for this problem. But you have a very valid point: the error was shown on the first testing of the function. And it is a very underappreciated feature of Common Lisp, that you can test almost every function by itself, you don't have to build and run an executable, you can, as the blog author did, test the single function and very quickly get to the problem.
> Quicklisp is de-facto the only widely used library manager in Common Lisp world, and so it’s written in Common Lisp and doesn’t have any tests. It’s a wonder for me how it’s not breaking!
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"
Note how (mkstring n) makes a string of n spaces by default; if you want a different character, specify it as a second argument.
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
upd implicitly uses the syntax of the partial application operator op to create a pipeline of partial applications. To get such a pipeline by itself as a function, opip can be used; upd is simply the result of wanting a place-mutating operator that takes a place's value through an opip pipe and then writes the result back in.
TXR Lisp also has a well-featured command line option parsing library built-in:
One other key difference between lisp and haskell... Common Lisp has a standard definition. My code from the last century still compiles and runs as does code from all of the books.
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.
I have to say, this is a very bad blog post. There are things to critisize in Common Lisp. And of course there is a valid discussion about static vs. dynamic typing. But the author gets a lot wrong and that kills the validity of his criticism. What is left, is a very negative article, which might discourage people to check out Common Lisp, which would be a pity. Even if you do not end out as a permanent Lisp programmer, learning Lisp can teach you a lot about programming.
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.
I was introduced to Lisp in my CS320 Programming Languages class and fell in love.
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.
[+] [-] thibran|7 years ago|reply
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.
[+] [-] bad_user|7 years ago|reply
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.
[+] [-] Buttons840|7 years ago|reply
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.
[+] [-] donut2d|7 years ago|reply
[+] [-] ainar-g|7 years ago|reply
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?
[+] [-] lomnakkus|7 years ago|reply
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.
[+] [-] rs86|7 years ago|reply
[+] [-] paidleaf|7 years ago|reply
[+] [-] aidenn0|7 years ago|reply
[+] [-] jose_zap|7 years ago|reply
[+] [-] daly|7 years ago|reply
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.
[+] [-] platz|7 years ago|reply
[+] [-] rusabd|7 years ago|reply
[+] [-] sahil-kang|7 years ago|reply
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.
[+] [-] ivan4th|7 years ago|reply
[+] [-] suprfnk|7 years ago|reply
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.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] agumonkey|7 years ago|reply
[+] [-] waterhouse|7 years ago|reply
[+] [-] fiddlerwoaroof|7 years ago|reply
What was most eye-opening for me about CL was just how helpful the compiler of a dynamically typed programming language can be.
[+] [-] kazinator|7 years ago|reply
Since it is required, it wants to be a required parameter.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] moomin|7 years ago|reply
Whilst not “finished”, what she’s done here is incredible. It’s an implementation of Haskell semantics as Racket macros.
[+] [-] BalinKing|7 years ago|reply
[+] [-] nabla9|7 years ago|reply
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.
[+] [-] dragandj|7 years ago|reply
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?).
[+] [-] forkerenok|7 years ago|reply
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
[+] [-] mark_l_watson|7 years ago|reply
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).
[+] [-] coldtea|7 years ago|reply
Why is it "a wonder"? We could, and did, write robust code, for decades before testing and TDD became a thing.
[+] [-] 0xcde4c3db|7 years ago|reply
[+] [-] nine_k|7 years ago|reply
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.
[+] [-] lvh|7 years ago|reply
[+] [-] nemo1618|7 years ago|reply
[+] [-] undecidabot|7 years ago|reply
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...
[+] [-] robax|7 years ago|reply
[+] [-] hellofunk|7 years ago|reply
For this reason alone, I can really see why python has been so enormously runaway successful.
[+] [-] didibus|7 years ago|reply
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?
[+] [-] atombender|7 years ago|reply
[+] [-] _ph_|7 years ago|reply
[+] [-] YouAreGreat|7 years ago|reply
> 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!
[+] [-] symtos|7 years ago|reply
Quicklisp also downloads and executes code over plain HTTP with no integrity checks whatsoever.
[+] [-] sigjuice|7 years ago|reply
[+] [-] kazinator|7 years ago|reply
I've never heard of trivial-update, but TXR has something like it built-in that I independently invented called upd:
upd implicitly uses the syntax of the partial application operator op to create a pipeline of partial applications. To get such a pipeline by itself as a function, opip can be used; upd is simply the result of wanting a place-mutating operator that takes a place's value through an opip pipe and then writes the result back in.TXR Lisp also has a well-featured command line option parsing library built-in:
http://nongnu.org/txr/txr-manpage.html#N-02C70C38
[+] [-] daly|7 years ago|reply
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.
[+] [-] the_why_of_y|7 years ago|reply
If you want to get legacy code to run with a current version of GHC, try "ghc -XHaskell98".
[+] [-] _ph_|7 years ago|reply
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.
[+] [-] unknown|7 years ago|reply
[deleted]
[+] [-] willio58|7 years ago|reply
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.
[+] [-] pmarreck|7 years ago|reply
[+] [-] avodonosov|7 years ago|reply
Look at the stack trace first, what funtion signals that.