ive been supplementing with sicp,k+r, lots of assembly/scheme hacking and am learning so much by myself while in class the teacher drones on about UML diagrams. i feel so bad for my classmates rofl
Name:
Anonymous2011-10-03 21:09
java is master race
Name:
Anonymous2011-10-04 0:07
>>4
I have to endure the same bullshit. The entire thing is crap. The learning process is hindered by the OOP fog. And then what do you get for your efforts? You get to go compete for a java programming job in a field that is dominated by java monkeys. Some who are experienced programmers and others who are smarter than you will ever be.
>>4,6
CS is not a course in programming; CS is a course in applied mathematics. CS can be taught using any turing complete language.
The UML diagram is one way of modelling a software system. Software models are used to facilitate communication and understanding between all the designers and programmers of the system.
Name:
Anonymous2011-10-04 1:43
>>8
Not >>4,6 but it's the order in which they teach CS that's irritating. Those who learn OOP after they already have the basics of procedural programming find that it comes naturally --- objects are just collections of data with operations defined on them, and OOP facilities are a way to simplify the structures-and-functions that you'd use otherwise. Those who learn OOP first will create classes upon classes, but are then mystified as to what goes in method bodies.
Name:
Anonymous2011-10-04 2:15
>>9
I was taught that OO design is a system design that involves self-contained objects that would pass messages to other self-contained objects. You would use it because you decide if your problem is easily molded into such a pattern. It sounds to me that these students (and/or teachers) fail to understand this basic concept of self-contained objects that pass messages to each other. These students ought to learn other software modelling tools that'll focus on other details of the system, such as the Data Flow Diagram and the Heirarchy Chart.
Only thing appealing to me about OOP is dependency injection.
Name:
Anonymous2011-10-04 5:59
>>6
Static typing introduces a lot of complexity: inference, type classes, algebraic data types, existential types, phantom types, etc. That's a lot of scary words and complexity for a newcomer, and static typing has nothing to do with learning the functional paradigm. While dynamic typing doesn't catch type mismatch problems before accepting to compile your program, it's very simple to use and has a very low mental requirement - ideal for doing something other than type systems research. The error messages given at run-time on type errors are much simpler than Haskell's cryptic compile-time error messages.
Haskell has a very painful syntax, it's a far more complex one than Lisp's. You need to be wary of operator precedence, layout rules (Haskell can be indentation-dependant) and other syntactic sugars, which can be a stumbling block when using the language. Scheme has the simplest syntax of any other practical programming language. The rules can be explained in minutes. The syntax is unlike what most people are used to, especially if they come from a C-syntax background, but it’s easy to pick up and use.
Inspired by mathematics, Haskell uses lazy evaluation, meaning it is harder to understand when something will happen or write efficient software. Lisp has intuitive eager evaluation, which is what most human beings are used to.
The "REPL" of Haskell does not expose the entire language, it is very limitated: you can't modify every aspect of your program as you would in Lisp, so it impedes testing things interactively in GHCi. Haskell also can't efficiently load code at run-time, meaning you can't use Haskell for CLI or scripting as you can use Lisp in interpreter mode.
There are no easily accessible books for Haskell. Some of the newbie-oriented tutorials are actually quite daunting, making it hard to suggest reading material to somebody who has no background in mathematics.
>>13
Haskell, OCaml and their ilk are part of a 45-year-old static-typing movement within academia to try to force people to model everything. Programmers hate that. These languages will never, ever enjoy any substantial commercial success, for the exact same reason the Semantic Web is a failure. You can't force people to provide metadata for everything they do. They'll hate you.
An important theoretical idea behind type systems is "soundness". Researchers love to go on about whether a type system is "sound" or not, and "unsound" type systems are considered bad. C++ and Java have "unsound" type systems. To date, the more "sound" a type system is, the more often it's wrong when you try to use it. This is half the reason that C++ and Java are so successful: they let you stop using the type system whenever it gets in your way. The other half of their success stems from the ability to create user-defined static types. The reason C++ and Java (particularly Java) have been so successful is that their type systems form a "let's not get any work done" playground for n00bs to spend time modeling things and telling themselves stories. You can't actually model everything; it's formally impossible and pragmatically a dead-end. But they try. And they tell their peers that you have to model everything or you're a Bad Citizen.
One very real technical problem with the forced-modeling approaches that static type systems are often "wrong". It may be hard to imagine, because by a certain definition they can't be "wrong": the code (or data) is programmatically checked to conform to whatever constraints are imposed by the type system. So the code or data always matches the type model. But the type system is "wrong" whenever it cannot match the intended computational model. Every time want to use multiple inheritance or mixins in Java's type system, Java is "wrong", because it can't do what you want. You have to take the most natural design and corrupt it to fit Java's view of the world.
Name:
Anonymous2011-10-04 6:21
I decided to stop torturing myself and part with Haskell. Why I did that?
1. I don't give a damn about its type system and Haskell was putting it in my throat.
2. I didn't learned anything new. Well beside bunch of tricks, and I wasn't looking for tricks. I expected new paradigm, novel idea or an elegant combination of existing ones but there was nothing of those to inspire me to continue wrestling with the static typing.
The best description of static typing came from Aatu Koskensilta: One of the reasons to prefer a powerful type system is precisely the ability to encode some such conditions and information in the types. The usefulness of a type system depends on which conditions are expressible in it, and with what amount of effort. In any case, if one does not use the type system for anything useful, it obviously will be nothing but a burden.
Learning to program in languages such as Haskell involves learning how to use its type system to do useful thing, just as one would learn to use macros etc. when learning Common Lisp or Scheme. Don't think of the type system as a straight-jacket, think of it as something to hack, a tool -- or just continue writing your code in a dynamically typed language if that's your thing.
And static typing is definitely not my thing. But if I decide to get in those waters someday I will look no further than Qi, it has the most powerful type system, it's optional and I could even hope that it'll be ASDF packaged.
It may interest you to know that most of my development time for that was spent typing: paging through the library, trying things out at the REPL, tweaking, debugging, iterating. It's a style I find much easier than staring at a blank screen and thinking very hard, and one for which I find forgiving languages like Perl and Lisp are much better than Haskell.
Farewell Haskell, you're joining the company of languages that didn't taught me much about programming nor changed the way I'm thinking. As Alan Perlis once said: "A language that doesn't affect the way you think about programming, is not worth knowing". The rest of the crew consists of pascal, basic, delphi, php, c#, ocaml, python and sql.
>>10
More ABSTRACT BULLSHITE isn't the answer, because nothing in your post addresses the parts of OOP that are inherently procedural --- like loops and conditionals, which students learning programming for the first time should be taught before even hearing about what an object/class is.
>>14 This is half the reason that C++ and Java are so successful: they let you stop using the type system whenever it gets in your way.
Bullshit. Java doesn't offer that.
>>22
Greeks were students of jewish and egiptian clerics. They even used same Aleph, Beth letters for calculation (jews also used letters, instead of numbers).
>>15
how did monads not affect the way you think about programming? The idea that your program only needs n mutable things where n is the number of outputs and inputs, is, I think, really mind-shifting and important.
To be honest, I struggle to think of a dynamically typed language which is as idiomatically functional as Haskell or OCaml. Scheme perhaps. I think the reason for this is that functional programming as a style, require vigilance and strength. It always benefits your program in the end to reduce inessential side-effects, but we are all human and we all er. Haskell and OCaml don't let you.
Maybe that's a bad thing or a good thing. I'm not sayan. My point is that the essential reason these languages don't take off is not the static typing per se, but that functional programming is hard.
Name:
Anonymous2011-10-04 12:01
>>25
how did classes not affect the way you think about programming? The idea that your program only needs n mutable objects where n is the template of IFactories of IFactories, is, I think, really mind-shifting and important.
To be honest, I struggle to think of a dynamically typed language which is as idiomatically functional as C++ or Java. Dylan perhaps. I think the reason for this is that object oriented programming as a style, require vigilance and strength. It always benefits your program in the end to reduce inessential simplicity, but we are all human and we all er. C++ and Java don't let you.
Maybe that's a bad thing or a good thing. I'm not sayan. My point is that the essential reason these languages don't take off is not the static typing per se, but that object oriented programming is hard.
Name:
Anonymous2011-10-04 12:03
Benefits of dynamic typing:
1. Easier to run and test since there are practically no compile-time or link-time errors
2. Programs are not limited by the expressiveness of the type system of the language — e.g. heterogeneous data structures w/o explicit tagging
3. Allows for implicit open recursion, late binding, dynamic scope, and duck typing
4. Programs are simpler since I don’t have to worry about types. Things are often coerced implicitly making my programs more concise, and I don’t have to use really abstract things like type variables and higher-order types. In other words, they have been abstracted away by being pushed down to a place I don’t have to think about.
5. Faster prototyping due to not having to write down types which change often during prototyping
Open recursion and late binding are just special cases of dynamic scope. They can definitely be useful though since they allow you to do things that can’t be done easily without the features. And although you can implement open recursion in a statically typed language, you can’t implement dynamic scope in general (and be type-safe) without converting your entire program to use tagged values, which would be implementing the entirety of dynamic typing. So in this respect, dynamic typing is actually more flexible.
Myth: Type-checking is a substitute for testing.
---
Again, absolutely not true. Although some people may use type-checking (static in particular) for testing program correctness, this is neither its intended purpose nor its limit of use. Type-checking is more about ensuring meaningful, well-defined execution than ensuring correctness. 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 errors, it is not the same as testing. Thus, it is not a suitable substitute for testing.
Name:
Anonymous2011-10-04 12:05
1. Static typing reminds me of the dark ages of programming in the c family of languages. Inference engine saves me from writing the boring type declarations but it's far from perfect. I have nothing against static typing if it's optional. One of the coolest features of lisp that I found when I started learning it coming from c++ was that I could put anything into lisp containers. And I don't want going back.
2. No rapid development. Don't get me wrong, developing in Haskell is faster than in c++ or c# but compared with ultimate RAD vehicles like lisp or prolog, haskell looks like a family caravan against full blood racers. Haskell doesn't allows me to experiment. It doesn't allows me to create modulus with some functions undefined or defined wrong. Bundle this together with loading file to redefine a module, the cruppiest feature they took from Prolog and you'll start to value your lisp listeners.
3. Hogs a lot of brain resources. It's syntax is complex, and together with static typing it forces me to spend more resources on dealing with language than with dealing with the problem.
4. Inflexible- Remember the Alan Kay quote - Lisp isn't a language it's a building material. Not so with Haskell. You can not wrap the Haskell around the problem as you can do with Lisp. Haskell forces you to work the other way around.
5. Spartan development enviroment. Compared with lisp offerings WinHugs looks poor man's IDE. There are so much things that are missing that I don't know where to start. Beside I had to write Haskell code in notepad, best editor available under windows, after Crimson failing to start after I switched to Haskell mode. And don't even dare to mention Emacs, a lot of people don't like it.It's 2008 and creating a simple Haskell editor is not an rocket science. I need an integrated editor with syntax coloring and intellisense kind of reminding me how many and what type of arguments function takes. That's it. Another option is Visual Haskell, used as editor together with winhugs, for interactivity. Also there is no debugger, so forgeth about stepping, functional style of Haskell, helps here but it's just a hassle debugging by hand.
6. Lacks reflexive abilities. Oh silly me of course it lack them. In Haskell everything is carved in stone. Programming in Haskell is like proving a mathematical theorem. There is no screwing around. It's like life in a monastery, full of fasting, praying and compassion under the all seeing eye of the abbot, punishing you for every mistake. So if this kind of life is for you, you'll end up in heaven, but if you want playing around and can't (don't) want life without women, parties, drinking and good food than Haskell is definately wrong choice.
7. Case sensitive - why does types has to start with uppercase and functions with lowercase. To make it easier for the implementation writers? Or to enhance readibilty. The latter has other way to be achieved. Any syntax coloring editor is smart enough to gave you visual clues what the hell some name means.
8. Indentation matters.
Name:
Anonymous2011-10-04 12:12
>>26
are you implying that inessential side effects make your program simpler? I think not. The more I have to think about the state of the program at runtime, the less simple my program is.
Name:
Anonymous2011-10-04 12:14
Sometimes, you’re on a team, and you’re busy banging out the code, and somebody comes up to your desk, coffee mug in hand, and starts rattling on about how if you use zigomorphic monoidal types, your app will be 34% sparklier, and it’s not even that hard, because he’s written a bunch of monads, and all you have to do is recursive subtype from 17 of his typeclasses, each taking an average of 4 type constructors, and you barely even have to write the body of the function. It’s just a gigantic list of multiple-inference from different polytypes and hey, presto, polymorphic monoidal type. And your eyes are swimming, and you have no friggin’ idea what this frigtard is talking about, but he just won’t go away, and even if he does go away, he’s just going back into his office to write more of his clever types constructed entirely from multiple differential polytypes, without a single line of concrete code at all, and it’s going to crash like crazy and you’re going to get paged at night to come in and try to figure it out because he’ll be at some goddamn “Functi-anal Programmin” meetup.
Name:
Anonymous2011-10-04 12:15
>>29
The more I have to think about zigamorphic monoidal polytypes, the less simple my program is.
Name:
Anonymous2011-10-04 12:18
>>29
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. -- Simon Peyton-Jones, a major contributor to the functional programming language Haskell. http://oscon.blip.tv/file/324976
>>29
Years ago, I wanted to write something in Haskell that worked like Clojure's memoize (which is implemented in a half-dozen or so lines of code in Clojure's core), and asked about it on the Haskell mailing list. I was pointed to a PhD dissertation on the topic of how to write memoize in Haskell. All I could think was, "Do I really want to be using a language where memoize is a PhD-level topic?"
>>30
but in practice the more functional your code is, the fewer bugs it has. How have you written a lot of software and not noticed this? The original quote is about C++ design patterns and template metaprogramming, which are overly complex and retarded and cause bugs. Reducing side-effects simplifies your code (almost invariably.)
You can find-replace this comment too. It won't change the reality that you can go out and measure yourself. Functional style always reduces complexity and bugs. I'm actually confident in using the word "always" here.
>>31
Fine. You can still use monads in a dynamically typed language. They're just lambdas that take and return lambdas. (which is what everything is.) You can even write a nice macro to reinvent the "do" syntax from Haskell. You can write a bunch of macros to reinvent the useful bits of Haskell, actually, and call it Qi.
I think that Haskell's attitude toward IO and side-effects is one of those useful things that is interesting and worth learning the language for further insight on. Haskell has something interesting to say, is all I'm saying.
>>32
The point is that IO of whatever sort can be sectioned away. A large part of your program is unconcerned with it and only transforms I to O. Those parts don't need side-effects, and when you get right down to it, implementing those parts with side-effects isn't even particularly easier. In fact, it's entirely an optimization concern.
Fine. You can still use monads in a dynamically typed language.
There is no reason to use them, except for obfuscation. They are like C++ templates - useless for serious work, produce cryptic errors and nobody gets them.
They're just lambdas that take and return lambdas.
They are continuations. Continuations are gotos, which leads to notoriously obfuscated code, if used without knowledge.
The point is that IO of whatever sort can be sectioned away.
I.e. obfuscated under a pile of abstractions - just like jews love.
Name:
Anonymous2011-10-04 13:24
First there was plain and simple `write` procedure, every OS had it as syscall. Idiots combined it with `format`, to produce fprintf monster, instead of allowing write(format(format_string, args...))
Then some retarded mathematician invented `cunt << dick << endl;` "streams", which take some abstract types, to produce more abstract types, finally, through long sequence of complicated abstractions, expanding into fprintf.
But it was not enough! Now evil followers of this retarded mathematician invented these `monadic transformers` - all to hide semantics of good old `write` function.
Name:
Anonymous2011-10-04 13:39
>>39
C/C++:
char *S;
again:
S = readline("Insert your new password:");
if (!isValid(S)) goto again;
printf("Storing in database...");
instance Monad m => Monad (MaybeT m) where
return = MaybeT . return . Just
instance Monad m => MonadPlus (MaybeT m) where
mzero = MaybeT $ return Nothing
mplus x y = MaybeT $ do maybe_value <- runMaybeT x
case maybe_value of
Nothing -> runMaybeT y
Just value -> runMaybeT x
instance MonadTrans MaybeT where
lift = MaybeT . (liftM Just)
getValidPassword :: MaybeT IO String
getValidPassword = do s <- lift getLine
guard (isValid s)
return s
askPassword :: MaybeT IO ()
askPassword = do lift $ putStrLn "Insert your new password:"
value <- getValidPassword
lift $ putStrLn "Storing in database..."
Name:
Anonymous2011-10-04 13:46
>>20
Definitely, when they have no idea how the machine actually works.
>>40
askPassword = do putStrLn "pass:"
pass <- getLine
if (isValid pass)
then storeInDatabase
else askPassword
where storeInDatabase = do putStrLn "storing"
...
Monad transformers are for completely different SET of problems, ``faggot''
>>4
Assembly, why? You're learning computing science, for which you need a high level, preferrably functional language (algorithms and abstract bullshite), not ZOMG I SAVED ONE CPU CYCLE LOLOLOL FAPFAPFAP.
So set theory cannot be Jewish. How does that make you feel?
Name:
Anonymous2013-09-01 13:47
It was about Hikikomori as long as Misaki didn't show up.
Name:
Anonymous2013-09-01 15:19
Hey. I'm an american and i want to get news. I know CNN and FOX and all the crap that american's typicaly get is biased garbage. I dont trust BBC that much. What are some realiable new sources that i can look too.