>>12
You go back to /g/.
IF U WERE FLAMED FOR USING LISP TOMORROW, I WOULDNT GO 2 UR SUICIDE CUZ ID B N DAT CUNTS HOUSE N SHOVE SICP DOWN HIS THROAT!
//`'''```,
o //LISP `.,
,....OOo. .c;.',,,.'``.,,.`
.' ____.,'.//
/ _____ \___/.'
| / || \\---\|
|| || \\ ||
co co co coWE TRUE SMUG LISP WEENIES
WE READ SICP TOGETHER
WE COUNT PARENTHESES TOGETHER
send this SUAVE SPACE TOAD to every thread you care about including this one if you care. C how many times you get this, if you get 6001 your A TRUE SMUG LISP WEENIE
lisp is the most flexible programming language. lisp becomes whatever you want it to be. you can't dislike lisp, what you are really disliking the lisp you have in front of you, and it's deficiencies are your deficiencies.
>>23
Nice try but score's only 1 out of 10 for Raw Troll Power
Name:
FrozenVoid2011-11-02 1:05
>>23
what if i want C syntax and manual memory allocation?
Name:
Anonymous2011-11-02 1:37
>>25
you can emulate malloc and free quite easily.
And your syntax can be whatever, so long as you start it with:
(C
printf ("this is valid lisp syntax");
int x = 7;
if (x % 2 == 1)
{
printf ("still technically s-expressions");
}
)
Name:
Anonymous2011-11-02 2:15
- Just like C++, Haskell is very hard to learn, and takes years to master. Things like Monads, Functors, Monoids, Higher-Order Types and a myriad of morphisms are hard to understand, especially without mathematical background. So most programmers probably don't have the ability or will to learn Haskell. Learning Haskell's syntax, libraries, functional programming techniques won't bring you closer to understanding: the true path to understand Haskell lies through Monoid-Functor-Applicative-Arrow-Monad. And even if you mange to learn Haskell, programming it still hogs a lot of brain resources, which could have been put to something more useful than just showing off about how clever you can be. "Zygohistomorphic prepromorphism: Zygo implements semi-mutual recursion like a zygomorphism. Para gives you access to your result à la paramorphism." -- HaskellWiki
- Haskel is slow and leaks memory. GHC's inefficient stop-the-world GC does not scale. A good understanding of evaluation order is very important for writing practical programs. People using Haskell often have no idea how evaluation affects the efficiency. It is no coincidence that Haskell programmers end up floundering around with space leaks that they do not understand. "The next Haskell will be strict." -- Simon Peyton-Jones
- Haskell's API lacks higher levels of abstraction, due to absence of variadic functions, optional arguments and keywords. Macros aren't possible either, due to overly complex syntax of Haskell. API documentation is very lacking: if you want to use regexes, you start at Text.Regex.Posix, seeing that =~ and =~~ are the high level API, and the hyperlinks for those functions go to Text.Regex.Posix.Wrap, where the main functions are not actually documented at all, so you look at the type signatures, trying to understand them and they are rather intimidating (class RegexOptions regex compOpt execOpt => RegexMaker regex compOpt execOpt source | regex -> compOpt execOpt, compOpt -> regex execOpt, execOpt -> regex compOpt where). They are using multi-parameter type classes and functional dependencies. The signature really wont give you any clue to how to actually use this API, which is a science in itself. Haskell is a language where memoization is a PhD-level topic.
- Haskell programming relies on mathematical modelling with type system (a version of mathematical Set Theory). If one does not use the type system for anything useful, it obviously will be nothing but a burden. Programs are limited by the expressiveness of the type system of the language - e.g. heterogeneous data structures aren't possible w/o reinventing explicit tagging. All that makes Haskell bad for prototyping or anything new, due to need of having design document with all types beforehand, which changes often during prototyping. Any complex project have to reinvent dynamic typing. For instance, Grempa uses dynamic typing because the semantic action functions are put in an array indexing rule and production numbers (Ints) to functions, and they all have different types and so can not be put in an ordinary array expecting the same type for each element.
- The IDE options cannot be as good as those of dynamic programming languages, due to absence of run-time information and access to running program's state. Haskell's necrophilia forces you to work with "dead" code. Like other static languages, Haskell isn't well-known for its "reload on the fly" productivity. No eval or self-modifying code. Haskell code can't be changed without recompiling half of application and restarting the process. GHCI - is the best Haskell's interactivity can get, and still wont allow you to change types during runtime, while the single assignment semantics prevents redefinition of functions. As said Simon Peyton-Jones, "In the end, any program must manipulate state. A program that has no side effects whatsoever is a kind of black box. All you can tell is that the box gets hotter."
- Type system produced compile-time and link-time errors are distracting and make it harder to run and test your code, while type-checking isn't a substitute for testing, it is about correspondence to mathematical model, which has nothing to do with correctness - i.e. two numbers can be integers, but their quotient can still result into division by zero. Even though you may hear strong static-typing advocates say, "When your program type-checks, you'll often find that it just works", this is simply not true for large, intricate programs. Although type-checking may help you find model-related errors, it is not the same as testing.
- Absence of dynamic scope, implicit open recursion, late binding, and duck typing severely limits Haskell, since there are things that can't be done easily without these features: you can't implement dynamic scope in general (and be type-safe) without converting your entire program to use tagged values. So in this respect, Haskell is inferior to dynamic typing languages.
- Haskell makes it easy to write cryptic programs that no-one understands, not even yourself a few days later. Rich, baroque syntax, lazy evaluation and a tradition defining an operator for every function - all help obfuscation a lot. As a general rule, Haskell syntax is incredibly impenetrable: who in their right mind thought up the operators named .&., <|> and >>=?
Of course there are multiple solutions that all mean something different:
Name:
Anonymous2013-08-31 8:21
If my rather charismatic Bard rolls 1d20+8 for a gather information check, it takes 1d4+1 HOURS to complete. So does that mean I can't do anything else for christ knows how many turns?! Surely by that time the party would have moved on!
Name:
Anonymous2013-08-31 9:07
There is now a 1.54 patch. Also there is a patch to update from 1.50 to 1.54 (and from 1.52 to 1.54 if you have the DL version).
This update adds a third version of the "Secret Basement", the dungeon that generates random items in your inventory each floor.