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-07 19:42
Unless you are actually complaining about weak typing, errors like these are dead obvious. So you are either a retard or a double agent rooting for Haskell. That's not an exclusive OR.
Name:
Anonymous2014-07-07 19:50
>>2 Dead obvious? Not when your eyes are red from lack of sleep because of hours in front of a computer and you've read every fucking line of code several times and haven't noticed it.
Name:
Anonymous2014-07-07 20:17
>>3 Dead obvious as in ``even the shittiest language will tell you immediately what went wrong and where it went wrong''. Unless you are using weak typing, but everyone knows weak typing is the shittest of the shit.
Name:
Anonymous2014-07-07 20:35
>>4 But it didn't go wrong, it ran all the calculations as if it's alright to stick a fucking 3-vector in place of a scalar.
>>1 It's your standard PEBCAK error. Some people design their software on paper to ensure the logic is sound BEFORE touching a keyboard. This way, trivial errors like variable type mismatching do not happen because the programmer is not designing new logic, the programmer is only translating the pseudocode logic into the syntax that the compiler will expect.
Most people want to reuse arithmetic functions for vectors. Especially in graphics. So you are alone here.
Name:
Anonymous2014-07-09 16:53
>>11 It wasn't an arithmetic operation, it was a call like
foo(x, otherArg, anotherArg)
and x was supposed to be a scalar but I accidentally put a vector like {x, 0, 0} there so the call became
foo(x, 0, 0, ...)
so the fucking thing just ignored my other args without a single warning, making a perfectly wrong calculation and feeling good about it.
Name:
Anonymous2014-07-09 17:09
>>12 Protip: Dynamic typing has nothing to do with this. It's caused by a mixture of weak typing and retarded language semantics.
Name:
Anonymous2014-07-09 17:09
Unlike math, physics has static typing
Name:
Anonymous2014-07-09 17:26
>>13 Weak typing, dynamic typing, homotyping - I don't care. If the compiler doesn't warn me about pushing a square peg in a round hole, then it's shit. SHIT I TELL YA!
Name:
Anonymous2014-07-09 17:30
>>15 Don't blame dynamic typing then, Haskell nigger. You'd expect type fetishists to know the difference between type systems.
Name:
Anonymous2014-07-09 17:34
>>16 I do blame and will forever blame anything that isn't STRONGLY STRICTLY STATICALLY VERIFIABLY RIGIDLY RIGOROUSLY typed. For all the pain I've endured and all the time I've lost, I will forever hate everything that has even the slightest tinge of untypedness.
You'd expect type fetishists to know the difference between type systems.
There is no useful difference between two pieces of degenerate shit. Calling "weak typing" a "type system" is like calling a chimp a novel writer. You're basically saying that a literary critic should know the difference between gibberish typed by monkey A and gibberish typed by monkey B.
Name:
Anonymous2014-07-09 17:55
chimp nigger
Name:
Anonymous2014-07-09 18:00
>>17 Typing is aptly named since it involves lots of typing.
Name:
Anonymous2014-07-09 18:13
>>20 Typing is anything but a bottleneck in software development.
Name:
Anonymous2014-07-09 18:20
>>17 Make a static typing preprocessor for every dynamic typing language you are using
I'm a fucking retard. scheme/common lisp is too hard for me.
Name:
Anonymous2014-07-09 20:46
It always felt like Haskell faggots have a problem with Lisp because they try to play Haskell with Sexprs™ when using it. Of course this doesn't work, so they get upset, think it's shit and the reason for this has got to be the biggest difference between the two: Type systems.
they try to play Haskell with Sexprs™ when using it.
Actually, nothing stops you from typing Lisp code. The only major requirement for Lisp is garbage collection. Everything else is optional, including dynamic typing.
Name:
Anonymous2014-07-09 20:56
>>31 That's playing semantic games about what constitutes a Lisp.
A function from (Atom or List of Atoms) to (Atom or List of Atoms)
Name:
Anonymous2014-07-09 21:00
>>32 Macros only need types insofar as the AST needs types (it doesn't). Which is to say, even though the expanded code must be correctly typed, the method of producing it (whether expanding it from a macro or typing it in by hand) does not.
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.