I've spent hours trying to figure out what's wrong and it was because this shit silently accepted a vector in place of a scalar. FUUUUCK FUCKETY FUUUUCK. Static typing should be everywhere, even in math software, even in fucking Python, I want ALL programming to always be strictly and statically typed. Fucking idiots, ARRGGH.
Name:
Anonymous2014-07-09 21:01
>>29 Nope. The biggest reason Lishp is shit is because it's just another run-of-the-mill imperative language (or group of languages, whatever) with the usual cancerous set of disadvantages: everything's mutable, concurrency is shit, everything depends on everything and can launch missiles, everything's bug-ridden, there's no type inference, etc. So since Lithp is so unoriginal, we take the one thing in it that's remotely original, and that's Sexprs™. And we test if at least that one thing could be useful in improving Haskell. And it's not, Sexps are overrated and not really useful for Haskell (goodbye Liskell!). And that leaves nil, nada, Nothing that could be useful about Lishp. Therefore, Lithp is shit through and through, and when someone asks why Lighthp is shit, you could name any one of the reasons and the type system often comes off the top of the head. But that doesn't mean Lithp and Scheme are shit only because of their type systems, that's just the tip of the fecal iceberg of Lithp. It is true that Lishshp is shit because of its type system, but it's also shit for a myriad other reasons and one can enumerate any subset of them really.
Name:
Anonymous2014-07-09 21:07
>>35 C and Lisp are still the only two languages you need and still both better than haskell.
Name:
Anonymous2014-07-09 21:09
NASA uses LISP. NASA doesn't use huskel.
If huskel is so good then why didn't the SICP authors use it instead of Scheme? Even academics think huskel is shit for theory.
Name:
Anonymous2014-07-09 21:10
>>33 Defeats the point of the type system because you introduce a type (atom) that requires either casts or automatic conversion. One defeats the point of macros, the other one is complete shit and might even be unsafe.
You basically introduced Java's Object, try again. But please don't try as hard as >>35-kun, that would be ridiculous.
Name:
Anonymous2014-07-09 21:11
It is funny that the major drawback of Haskell (lazy evaluation) has nothing to do with typing, static or dynamic. You can add lazy evaluation to Lisp and it will become useless too! IIRC, SICP has an exercise for that.
Name:
Anonymous2014-07-09 21:12
If huskel was so good then the SICP authors would of used its parent (ML) instead of Scheme but even its parent is too shit. LISP is seen as a highly abstract intellectually demanding language built by and used by Wizards. And NASA uses it for mission critical space robots. Who built huskel, who uses it, and what about it again?
If huskel is so good then why didn't the SICP authors
Because SICP is a book for freshmen.
>>39 Just because you can't use demand-driven data structures doesn't mean lazy evaluation is shit.
>>40 ML is not Haskell's parent, and SICP authors are not an authority on programming languages.
Name:
Anonymous2014-07-09 21:21
>>36 Speak for yourself, I need neither C nor Lithp.
Name:
Anonymous2014-07-09 21:23
>>34 But in Lisp, macros aren't necessarily expanded at compile time, so how can you guarantee that the resulting code is well typed? There doesn't even need to be a compile time, and thanks to reader macros, both read time and run time are blurred, too. Static typing won't cut it for a fullblood Lisp.
Name:
Anonymous2014-07-09 21:52
>>43 Read time and run time are blurred because in Lisp the whole fucking compiler is embedded into the runtime. You could do that in any language and compile code at runtime, it's just that it's not really useful and not safe.
Name:
Anonymous2014-07-09 22:03
>>44 Being able to modify running systems by default is not useful? My biggest gripe with Haskell is exactly that I can't do that without implementing it for every program, it's amazing to be able to do such things while testing or fixing server software. Haskell code is always dead, and ghci barely changes anything about that.
Name:
Anonymous2014-07-09 22:05
>>45 Just include GHC and the core lib in your executable and you'll be able to modify running systems. It's nothing special.
Name:
Anonymous2014-07-09 22:06
I tried Haskell before CL. Most of the programming I do is the application/implementation of numerical methods for solving economic models.
Even though I recognize the `elegance' of certain Haskell constructs, the language was a straitjacket for me because of two things: the type system and the functional purity.
The type system required a lot of scaffolding (Either, Maybe, ...) when I wanted to do something non-trivial. Indeed, Haskell makes the construction of this scaffolding really easy, but in CL, I just find that I don't have to do it and I can spend time writing more relevant code instead.
Also, sometimes I had difficulty rewriting my algorithms in purely functional ways. I agree that it can always be done, but I had to spend a lot of time fighting Haskell.
What attracted me to Haskell initially was the elegance found in toy examples (eg the Fibonacci series). It took me a lot of time to realize that toy examples are, well, toy examples, and whether a language handles them well is not relevant to problems of a larger scale. For example, pattern matching looked fascinating, until I realized that I am not using it that often.
Also, when I tried Haskell I didn't know about macros, which give Lisp a lot of extra power. Now of course I would not ever use a language without CL-like macros.
>>60 Lisp is in an eternal "could be done" state. Haskell just works. You take any library from hackage, look at the type of a function, plug it into your code, and if it typechecks, then it works.
>>59 I'm sorry to break it down to you, but you're totally wrong.
Name:
Anonymous2014-07-10 2:28
>>64 In the ``burrito analorgy'' you need to substitute ``diarrhea dependencies.'' This is required and implied by the ``arrows'' (in CT), a.k.a. ``stink-lines'' in the burrito theory ``morphism'' (CT; again,``analorgy'' in burrito.)
>>67 The part you cherry-picked is neither here nor there. What makes programming respectable is writing types. >>65 pertains to that practice and in that context plugging things in is perfectly respectable because it can be done correctly with near certainty. After all, its the types that matter most.