It's 2015 and there are still people using Common Lisp left
Name:
Chris Done2015-05-09 10:57
I switched from Common Lisp to Haskell.
I got interested in Haskell because of its purity and functional programming. I held my nose when dealing with its horrible syntax (which I still do to this day, but I was really distraught back then at the Perl code I had seemingly been creating and nearly gave up), and then got roped into liking the type system, and a deeper appreciation of laziness beyond tricks came much later.
Haskell also has much better set of standard classes; it has equality as a class, instead of the 5 or so functions and one for every data type that you have in Lisp, same for ordering, numerics, etc.
Partial evaluation makes for pretty predictable argument order, argument order in Common Lisp is hard to predict.
Most CL codebases I've worked on were not maintainable due to arbitrary side effects and no type system to support refactoring. CL is just a bad language for code that matters. Back when CL was my goto-language I found libraries and implementations lacking, but these days with Quicklisp and SBCL I think the situation is better.
GHCi is pretty poor in comparison to SLIME, there's no comparison. Lisp suffers from ugly macros, Haskell suffers from operator line noise. Where Haskell makes code hard to read by trying to abstract everything with types, CL programmers make up for it with macros and abstractions without any static enforcement. Lisp also suffers from selfishness on the part of the programmer because of how the language is setup, Haskell code comparatively is made to be shared.
Lisp functions like to be kitchen sinks with all the bells and whistles (the pathological case is the LOOP macro), Haskell functions like to do one thing like UNIX commands and lazily be glued together.
Community-wise CL's has generally always been unfriendly and bitter in my experience. In Haskell you basically write assuming GHC. Lispers try to write "portable" code, where portable means that this code will behave the same on different compilers with preprocessors for each compiler, or by using dumber libraries with fewer dependencies. I consider this a waste of mental effort.
In the end I care above all about maintainability and re-usability. For that Haskell is an obvious choice and has been since 2007.
Name:
Long time Schemer here2015-05-09 11:00
Getting used to Haskell's syntax was tedious and annoying. For all the crap that gets thrown at Lisp for the parens, when you live in a world of Lisp long enough other languages with conventional syntaxes, infix operators and precedences just look overly complicated. In Lisp it's generally completely obvious what goes with what, even in unfamiliar code. (You can write macros that break this, but the problem with that is you'll make people like me frown at you.) EDIT: One thing I'd add is that even for conventional math, Lisp-style prefix notation just scales up much better to complex expressions. Going to infix was an exercise in ranting on about "why the heck do people insist on a notation that puts the outermost operator deep in middle of an expression?"
Another thing is all the funky operators. In Lisps everything tends to have nice, long, readable names like call-with-current-continuation.
Scheme is a painfully fragmented language that traditionally hasn't had nearly enough library support; Haskell's much better in that regard. The Haskell community is also much friendlier... and just as intimidating, but in a different way—you get hit with a lot of abstract math much sooner.
The type system is a big deal. Haskell wins there, period.
There's a very vocal subset of Lispers who adopt the (in)famous "everything is a list" mantra, and will use lists everywhere. The others ones like me who disagree with this spend a lot of time fixing their crap. The Haskell counterpart does exist (using [] instead of Vector, ByteString or Text), but it's not nearly as bad.
Another other big difference is that Lisp and Haskell gurus have different programming philosophies, and the difference doesn't get articulated very often in a way that newcomers will grasp. Lisp gurus stress metaprogramming of a very syntactic flavor (s-exps, and the big emphasis on interpreters and macros), while Haskell gurus stress algebraic laws and denotational semantics. The crown jewels of Lisp hacking tend to be sexp-based EDSLs that get macro-expanded into efficient code; in Haskell the crown jewels are denotational EDSLs built around opaque combinators stated in terms of the semantics, and equational rewrite rules for turning them into efficient code. Put very coarsely, in Lisp you metaprogram with expressions, in Haskell you metaprogram with meanings. (This is exaggerated because both styles exist in both communities—it's a matter of emphasis.)
Name:
Anonymous2015-05-09 12:04
In Clojure there is the same problem than in most languages. To have a readable, maintainable code you have to make some efforts in being a good coder.
In Haskell, even beginner are kind of forced to do the right thing. Furthermore refactoring is quite easier.
Another input: when I read code from libraries in Clojure it can be from unreadable and really hard to understand, hidden behind macros, etc... To really readable as in a book.
When I read code from Haskell libraries, it is 99% of time the same quality of readability.
Concerning maintainability:
The type system give a clear advantage to Haskell here. It is harder to break things in Haskell. A lot of details in the syntax give also an advantage to Haskell here. For example, I often have to deal with shadowing variables in Clojure while in Haskell this is almost never the case. Plus Clojure "macros" are a hell to reason about.
Name:
Anonymous2015-05-09 12:05
Now of course, I realize that I missed something and Lisp is much much more powerful than I though, and I could probably apply every concept from Haskell to Lisp but there is nothing to enforce it: therefore you can struggle doing imperative style in Lisp without seeing the light.
In Haskell, you don't have the choice. What I really like about Haskell (and it comes mainly from purity I think) is the fact that you have "hard contraints" and can design things so that some mistake can't be made.
Example, you can design a DB system so that every call to the database HAS to be done within a transaction, (I've done similar things in Ruby using block: it makes it harder from developper to call things outside of a transaction but it's still doable). Another example is design an OpenGL library so that, calls can't be done outside of a GL context : in Haskell it's how it works naturally, but I would say it's nearly impossible to guarantee in any other language.
Name:
Anonymous2015-05-09 12:47
In Clojure there is the same problem than in most languages. To have a readable, maintainable code you have to make some efforts in being a good coder.
The problem is right in front of your eyes. Clojure niggers are nothing more than coders.
Name:
Anonymous2015-05-09 13:08
Projects: Haskell is a much more well-designed language, so I find myself using it for pretty much everything.
Templating: Lisp wins in this department. Haskell doesn't really have anything equivalent to macros. There is TemplateHaskell, but that's not very fun.
Debugging: Haskell wins by a long shot. Haskell's strong type system means that most bugs are caught at compile-time. You'll spend much less time hunting down bugs, and more time coding.
Haskell's REPL, GHCi, is pretty nice. There's apparently a nice debugger, although I've never felt the need to use it.
Libraries: Not significant.
Community: Meh, both are pretty good.
I like the Haskell community a lot. #haskell on FreeNode is one of the highest-quality IRC channels you'll happen upon.
Workflow: I spend a lot less time debugging in Haskell, because of the aforementioned "once it compiles, it probably works" thing.
Haskell's Emacs support is pretty good, although not as good as Lisp's. There's structured-haskell-mode and hindent, which try to mimic paredit's functionality. Things like [projectile][3] and [Helm][4] will help you more than anything else.
Haskell's packaging tool, cabal, is very poorly written, but supports sandboxing and integration with the REPL. A lot of your Haskell time will be spent fighting with cabal, until someone gets around to writing a replacement.
Readability: Haskell is great, provided you stay away from infix operators. Most people use infix operators, so reading other people's code sometimes isn't fun. Lisp wins in this department, but not by much.
Collaboration: They are both pretty good.
Haskell intrinsically values "code correctness" a lot more than Lisp. This is reflected in collaboration. Lisp programmers seem to rely on common sense, where Haskell programmers rely on math.
For instance, a while ago, I sent a PR to Haskell's time library. As it stood, you couldn't take two ZonedTime objects, and order them. The first PR I sent was rejected because I made a dumb logical error. I fixed that and sent back a second one, and it was rejected.
8:00 Pacific time is 9:00 mountain time. Common sense would indicate that if compare these ZonedTime objects, you'll get back Eq. However, algebra would indicate that you would get back NotEq, because both the time and the time zone are different.
My PR included the common-sense definition of equality, and was rejected in favor of the algebraic definition. A lisper would probably say those are the same time. A Haskeller would not.
Although, in lisp, you would probably get back different answers for all 8 definitions of equality.
Debugging: Haskell wins by a long shot. Haskell's strong type system means that most bugs are caught at compile-time. You'll spend much less time hunting down bugs, and more time coding.
JUMBO WHALES
Also, saying that you spend less time debugging and more time apping is dishonest. You spend more time fighting the compiler instead of a debugger, there is no goddamn difference when it comes to time.
Name:
Anonymous2015-05-09 13:29
>>7 More egregiously, fighting the compiler generally means the programmer hasn't even stated the program correctly yet.
As for whether using a debugger or a hard-ass language leads to not having to use the former, or not noticing the latter, I cannot say.
What's that? The compiler is the programmer's friend, not an enemy. You probably just couldn't learn Haskell and ran away like a cry-baby. Guess what, just because you're inept doesn't mean everyone is.
>>9 Stick to the point, fixing type errors all day long is having more time available for apping in exactly the same way usage of any linting tool is, i.e. hardly any.
Name:
Anonymous2015-05-09 16:07
>>10 Yes, it is. Except that it can never prove the absence of errors, only their presence.
>>11 That doesn't even make sense, how can you have time for other things if you're ``fixing type errors all day long''?
Name:
Anonymous2015-05-09 17:36
If you can just up and completely switch languages, you either haven't written enough programs to actually call yourself a programmer, or all you've written is tiny, shitty toys that will take no effort to replace.
Name:
Anonymous2015-05-09 19:31
>>11 Ah, the usual stupidity that in unityped languages one can somehow avoid fixing type errors.
all day long
Having a real type system greatly speeds this process up because it happens even before compilation. Compare that to having to
- write a test suite - compile your code - run it - hope your test coverage is good enough to find errors
Name:
Anonymous2015-05-09 20:30
Chrith Done: go away
You are a bad bad perthon. That's what Mommy thaid. And I alwayth lithen to my Mommy and she sayth LITHP is good and you are a bad, bad perthon!!!
Name:
Anonymous2015-05-09 23:45
Stop copy pasting stupid comments onto this site. If I wanted to read stupid comments, I could easily just read the stupid sites that you visit. But I don't. Why? Because I don't like reading stupid comments. It's a waste of my time. I search through this text that you've presented me with, and I look through it. I search for a trace of meaningful thought. Something that I can actually get something from. And after searching through the hay stack of stupid remarks, over simplifications, and errors in logical quantifiers, the only thing I find is absense. Nothing. There is nothing in these posts. Nothing but wise words from idiots.
Name:
Anonymous2015-05-10 0:14
>>16 You're arguing with someone who would rather have type errors than spend any amount of time fixing them.
>>19 Not every type error is an error. The program simply steps beyond what the language is capable of expressing.
Name:
Anonymous2015-05-10 2:53
>>21 That is only true of a small fraction of programs. The way most people write OCaml or Haskell (for example) would not produce working programs if they were able to disable type checking. Most of them wouldn't even present with logic errors and simply crash instead.
But you probably mean that *dynamic* typing saves you the trouble of doing conversions and so on. You can do that in static languages. Nobody does because they're unneeded.
>>22 I would like an array where a[i] is a string if i is prime, and an integer otherwise. Can you give me a type for that?
Name:
Anonymous2015-05-10 4:45
>>24 Such a type exists, and it's about as usable as the need for it is realistic. However I am confident that 1. your need for it is genuine and 2. you are smart enough to work it out. Not really, just use a monad.
I know you're trying to be one of those shits who comes up with an arbitrary impossible and irrelevant strawman, but if you want to earn a bit of renown you might consider bringing this type up with the dependent typing crowd. They might even name the type after you. On the other hand they may have already defined it for the purposes of showing off.
Name:
Anonymous2015-05-10 4:53
>>25 Does the monad enforce the rule at compile time, or does it catch it at runtime? If it is caught at runtime, then it's not the same.
>>26 Not the same as what? Use the monad: your problem probably can't express the constraint any better than the monad. If you want the actual type, maybe read the rest of the comment.
>>27 I try not to reply to you but you keep making these posts and it's wearing me down.
that you have to in order to supplies is already Vikings together with printed the ebay affiliate network that is player jordan shoes for men on and also likewise grown-up the particular ,any time a for the Air Jordan Shoes is usually not merely with th