I found the typing system in Haskell sometimes got in the way. Likewise, although Haskell has some capacity to define new language constructs, Lisp's macros are more powerful, and this provides a further degree of flexibility. I also find Haskell to be harder to read than lisp, largely because of built-in syntax and lazy evaluation. I also seem to recall haskell being pretty slow. Lisp on the other hand can be as fast or faster than C. Furthermore, with good unit testing, the sorts of errors one would catch in haskell, also get caught early on in lisp.
Name:
Anonymous2011-06-08 18:47
With a dynamic model, you actually have more accurate autocomplete assistance in a real dynamic IDE, because the IDE itself has more information about the types of the objects, not less.
Refactoring in a dynamic IDE is streamlined and simplified, for the same reasons, but you'll find that you don't need to refactor much, if at all, if using a good dynamic language like Lisp.
In a dynamic world, you just ask the object what its capabilities are. You don't have to look up call sites in the source code. What dynamic language have you been using that does not have this capability?
Name:
Anonymous2011-06-08 19:08
Lisp has a million () everywhere. How can like that shit?
>>9
I don't think you understand what you're saying.
If my architecture provides tagged pointers, and basic operations do type check them at runtime (e.g., addition raises an exception on overflow), then my C implementation would have to generate exception-handling code to let the integer overflow for every addition, and that would be slow.
Fun fact: C had problems to run on LispMs because integers didn't overflow.
Name:
Anonymous2011-06-08 21:51
>>11
Then according to C99, you would have a non conforming C implementation.
>>14
Oh, yeah. http://en.wikipedia.org/wiki/Tagged_pointer
Alien concept indeed. Tagged architectures, such as the Lisp machines, often have hardware support for interpreting and processing tagged pointers.
Name:
Anonymous2011-06-09 6:10
>>13
You still have to close statements with ``;" in C. No difference.
>>14-15
Tagged pointers are used in some VMs actually, even some CL ones, at the cost of the diminished memory (and speed if typechecks are included) that results from using a few bits as tags. Not a huge problem on x64, but it can make the difference between 3GB and 1GB on 32-bit x86.
>>18
Not like Lisp implementations are the only one ``suffering'' from this, and in some implementations it doesn't actually have more of a memory penalty than the OS already imposes through its own rules.
Even OSes use bits to have special meanings, for example on NT Win32, kernel-mode means the upper bit is set (so 0x80000000) and user-mode means it's unset. This effectively cuts down the maximum memory that a user-mode application can use to 2GB (private) while the upper 2GB are used by the kernel and shared (mapped into) by each process. On x64, similar tag bits are used for a lot more ingenious tricks as nobody actually has nearly that much RAM to fit in a computer (or even a average variety supercomputer).
>>21
You don't truly need it as long as the registers are wide enough, the software can handle it. Lisp Machines handled it in hardware, but today general purpose CPUs do just as good of a job (if not faster).
>>23
Read the thread, we're not talking about what Lisp implementations do on x86 and if hardware support for tagged pointers is better than doing it in software.
On architectures with tagged pointers, C has problems, and ``as fast as C'' is meaningless.
>>26 godSay hi to the fairies and pink unicorns from me. DEADThey live on in many VMs which map closely to current CPUs and they live in emulators, oh and surely there are enough working machines actually having such architectures. You're just showing your ignorance, and one can recognize almost every post that you make. I'd send you back from where you came from, but I really don't understand what makes you want to stay here when you're so unwanted, unless you're just attempting to troll, but the attempts are so poor that the best you can hope is a reply like this one.
Name:
Anonymous2011-06-09 9:54
>>27
Militant atheist faggot detected. Oh but it just doesn't end there! It's also a militant lithper faggot. Huge one too.
Jeeze, what a combo. How can you look at yourself in the mirror every morning and resist the urge to smash your head against the toilet bowl?
>>31
Name-calling and ad-hominem's? Good job trying to side-track this discussion. Good bye[i]![i/]
Name:
Anonymous2011-06-09 10:14
Lisp machines also suffer from endianness problems, as there are two obvious ways to encode Lisp code. One is to encode ( as 0 and ) as 1 (big endian), and the other one is to encode ( as 1 and ) as 0 (little endian). This confusion and the resulting incompatibility among the various Lisp machines vendors greatly participated in the decline of Lisp machines; but the developers were much too busy to notice at that time as they were arguing much more important things, such as getting a new name for bytevector.