Computer Science

I might be taking a course in Computer Science at a Uni soon, what languages are commonly used @ Computer Science?

Java
C++

Prolog
Haskell

Java is too slow and won't teach you how it works inside (copy, references, pointers...), try C++ instead.

And get one functional programming language to understand recursion and stuff (Scheme, Common Lisp, OCaml or Haskell).

>>3
OMG you are fucking stupid.

It's not Java's speed what bothers me. In fact it's reasonably fast. It's that it's just the worst OO language ever, with the worst API ever. It's all a stinking pile of enterprise shit.

C++ is an ugly, insane language, and sucks for OO as well. I fact, statically typed languages will always suck for OO.

"Recursion and stuff" can be and should be understood regardless of language.

My recommendation is to start with traditional programming in a simple language such as Pascal; once you get the idea you quickly jump into something decent and useful, i.e. C, and start abstracting from bottom up, so you get a good understanding of the internals but then move on to something more interesting and productive. After C you learn Python or Ruby, discover what's OO and how is it done right, and start dealing with lists and dictionaries like you say hello world. Then you progress through learning more advanced programming techniques, and at last, you try Scheme or another functional language. Not that much to do with them, as more general purpose, multiparadigm languages such as Python are better to get things done, but it's an enlightening experience you need to become a really, really good programmer. So once you've climbed up the ladder, you walk down until you find a job. Try Python or Ruby. If that fails, walk down a few steps and depending on your taste and what you can endure try PHP or Java, while you write Python for fun at home. If that fails, or you don't want to do it, try C, then C++--, then C++ in that order.

>>4
You seem to be pretty fucking stupid too, let me answer to your stupid message:

| It's not Java's speed what bothers me.

Well, Java's speed do bothers me, I write financial applications for a banking group and I do need the speed that only C++ can give me, nothing else.

| start with traditional programming in a simple language such as Pascal

HAHAHAHAHAHAHAHAHA

| and at last, you try Scheme

Nope, you can learn Scheme right from the start for the functional part, it's a very easy and simple language for this.

| multiparadigm

Buzzword.

You guys suck really hard.

JAVA's API is enterprise because it gets the job done.
C++ is the fucking MESS, HEY LOOK IT IS 2000 WOW LETS ADD DATASTRUCTURES WOW.

I write financial applications for a banking group
Really?

I hate Java too, you know, but unless you're writing client-side software, using C++ is idiotic. Java is popular in the banking industry for a good reason. OMG SPEED is one of the lowest criteria I can think of for financial software.

Of course, I think they should use functional languages.

Java's STDLIB wants to TAKE OVER THE WORLD.

Seriously.

There'll be Toaster::Controller.pop(); in the next version.

Of course, I think they should use functional languages.
Not to sound like a jackass, but why?

Oh and if the answer to that question is an explanation of the whole paradigm, I'm sorry. I just started learning Haskell a couple of days ago, so other then strict typing, everything being an expression, and how imperative languages can be sometimes better if memory is an issue, idk.

zomg, did I answer my own question?

>>9
Not the poster you're replying to, but here's my 0.02€...

Side-effectless operations are far easier to re-use than ones that do have side effects. They are also somewhat easier to validate, test and prove correct than their side-effectful counterparts, given that their scope is limited to their definition and the definitions of their leaves instead of that and the state of the system as in an imperative language. This latter bit I suppose would be plenty important to a financial organization, but see the cons at the bottom of this reply...

Components of a program written in a functional language are also easier to reason about, given that the nature of a function (is it a simple function? a map? a fold? an unfold? an accumulating map? etc) is generally apparent right away, just from its documentation and type signature. They also tend to be virtually busywork- and housekeeping-free due to memory management being implicit, in contrast to e.g. Java or C where a major operation generally consists of "1. acquire resources; 2. perform operations; 3. release resources".

Really, the only cons I can think of for functional programming is that first, it's mostly unsuitable for system-level programming (not much of a big deal since the gigahertz line was broken) and second, that J. Random Code Monkeys aren't educated in it. Used to be that universities and even some colleges had a mandatory Scheme course for CS/SE people, but these days it's all Java and anything else is optional, even C is optional these days. One could make the argument that Java programmers aren't that suited for financial-type things either, given that most aren't taught (or don't remember) the reason why using "double" instead of "float" is _not_ good enough for doing computations on money, but they're the people who are available. For better or worse, I suppose.

Java is popular in the banking industry for a good reason
Yes, because the banking industry is stupid. Just the way Sun and Oracle like it.

>>5
Seriously, got anything better to start than Pascal? You need to teach the basic imperative statements and simple data types without any bother coming from anal syntax (i.e. no Perl, Basic), pointers (i.e. no C), references and gotchas (i.e. no Python, Ruby), OO crap (i.e. no Java), and you definitely want strict, if not static, typing for this (i.e. no PHP, Perl, and probably no Python or Ruby either). C would be ok if it weren't for pointers, which will quickly get in the way of teaching, especially with strings. Either that or teach no strings.

Like I said, once the basics are mastered, they're to move into C and forget Pascal, but as a basic, first-steps learning tool I think it can be useful.

>>6
it gets work done (in an order of magnitude more time than any decent API)
Fixed.

>>7
Java is popular in the banking industry for a good reason.
Yes, and this reason is the people who have to take decisions are the least qualified ones to do so; no longer engineers or not engineers at all. Managers. They just circle-jerk with their fellow managers around their idiotic Sun-paid magazines that explain how they will maximize profits and increase productivity with Java-based enterprise scalable solutions, as well as a myriad of buzzwords they will never understand because managers are fucking stupid and useless.

>>9
http://www.janestcapital.com/ocaml.html

ANTI-ENTERPRISE == TOTAL IDIOT

/prog/ is full of idiots who don't know what they are doing and stuck writing 100 line php scripts.

>>14
Yay, "ML lite" and you get no bignum support without resorting to gay-ass special operator syntax. Fuckin' A, man, fuckin' A.

/prog/ is full of idiots who don't know what they are doing and stuck writing 100 line php scripts.
Which do more than the 1000 line java program, are completed and tested sooner, take less resources, run faster, easier to upgrade and surprise, surprise, more maintainable.

>>15
Lol, I don't know what are you doing here. But I'll tell you what sir. I actually appreciate you. You'll be doing what I don't want to do myself, so I won't be forced to cover such positions. Now please go back to your Java JNDI-based Web 2.0 XML-enabled professional scalable enterprise business solution using XSLT, XML, J2EE, LDAP and RSS. It helps your wise manager to convert visitors into customers, optimizing cash flows and maximizing profits, with a low total cost of ownership and a great control of your enterprise.

P.S.: This forum is about programming, i.e. languages, lambdas, algorithms, etc., not business shit and Java enterprise bloatware.

>>18
Heaven forbid writing software which works!

>>17
You've obviously never used PHP ever in your life.

>>9
Everything >>10 said, with one addition: since functional languages (usually) don't have side-effects, they're easy to parallelize. Since we're all heading the direction of many processors and many more processes or threads, this is a boon. It's really easy to throw hardware at a problem.

So functional languages give you robust and scalable systems that are easier to reason about. zOMG ENTERPRISE SCALABLE, they're a perfect fit for things like the financial domain.

>>13
Sorry man, but having visited several companies that write applications for banks, I can tell you it's the engineers who made that decision. Maybe the Swiss are just weird, or maybe these people are more qualified to decide what best fits their needs compared to some random anonymous on 4chan.

I loathe Java with a passion, but I also realise that it probably has its place. I learned that the hard way when speaking to the people above.

>>1
If your going to uni soon, chances are it'll be C++ or Java that they'll teach regardless, you won't have time to go up the 'chain' before then really. Pick up any of the major languages before hand if you want and then read it, understand the concepts mainly, then use that to help you in uni but using new syntax.
If you're not great at math, it might be a better choice to work on that rather than the programming. Math will be universal, programming syntax and various programming styles aren't always. Either way is fine though as you'll get what you need in the university to pass, your free time can go to studying anything extra you care to.

Pick up a cheap college textbook used online and read it. Perhaps email the school's computer science department head and ask what they use for the course or what they will be using if they plan on restructuring the course so that you may have get an early start.

>>10
>>20
Thank you for taking the time to answer my question.

>>19
| Heaven forbid writing software which works!

You mean bloated badly chosen libraries which have been over-engineered because companies wanted to make cash out of it?

I "think" before I choose a piece of technology, and J2EE is never a right choice.

The interesting thing is that if you ignore most of Java's ghastly library, you're left with a half-decent (albeit limited) language, and an interesting security model that is enforced down to VM bytecode.

That library though... holy cracker on a shit stick, it's pure evil.

(albeit limited)
limited? completely useless is more like it...

>>19
Heaven forbid writing software which works!
You haven't worked with moderate to large Java codebases, have you?

You've obviously never used PHP ever in your life.
I'm not >>17 but I deal with PHP at work and I've seen both good and shitty code. It's indeed 10 times more productive than Java (and probably more), despite the big and inconsistent global namespace of functions. It has a pretty bad community of clueless people writing ugly hacks for it. It can also be done right, and proved a good tool for small to medium web applications.

>>20
since functional languages (usually) don't have side-effects, they're easy to parallelize
Bingo, and this is one very good reason why we should care. We (as in "the whole industry") are getting pretty close to certain limits we can't fix by raising the clock speed, stuffing more ALUs or making wider buses, and as a result, we're already seeing multiprocessor desktop PCs. Eventually, multiprocessing will be the only way to increase performance, and for that we need something better than just threads. Threads are a pain in the ass to work with; I've been working in three successful projects involving threads, and I would have appreciated a smarter and more transparent way to take advantage of it.

maybe these people are more qualified to decide what best fits their needs compared to some random anonymous on 4chan.
Maybe most engineers are random people who got out of university without being able of installing their own operating system, let alone know jack shit about the real thing, and when asked, went for the most popular solution; one they knew they could do stuff with, though ignoring more productive and maintainable alternatives.

I know people who have been working for years for banks, writing COBOL and Java, and they won't be able to tell the difference between a byte and a character, what's a pure function, or what's a closure, to name three random examples. How can these people take any optimal decision on tools?

>>24
Even as a language, Java sucks sure it offers a C-like syntax, but it has crappy special non-object types, no operator overloading, unfunny string, list and dictionary handling syntax, and it's STATICALLY TYPED, which means it's a PAIN IN THE ARSE to work with.

Even as a language, Java sucks sure it offers a C-like syntax, but it has crappy special non-object types, no operator overloading, unfunny string, list and dictionary handling syntax, and it's STATICALLY TYPED, which means it's a PAIN IN THE ARSE to work with.

Plus it has no higher order functions, and after learning Python, Ruby, Common Lisp, Scheme, Smalltalk and Haskell I just can't go back to working with langauges that don't support FP even a little bit. Hell even in C you can do some kludgery with function pointers if you have to, but Java doesn't give you anything.

>>27
Anonymous inner classes can substitute to some degree, but even they lose out to C in terms of convenience (i.e. I'd rather not bang out loads of crap just to have a couple of mutable instance variables, thank you very much). C# v2 did it pretty well with anonymous, implicitly typed delegates; shame about the rest of the language and its standard libraries though.

>>27
>>28

When do you guys ever use this advanced language stuff? Could you give me an example please as I don't see the practical point.

>>29
Functional programming, eh?

For example, if you want to change every element in an array:
array.map! do |elem|
    elem * 10
end
If you want to summarize every element in an array:
sum = array.shurg_dunno_lol(memory => 0) do |elem, memory|
    memory += elem
end

>>30

    ??????
   ?????????
  ???????????
 ???    ?????
 ???     ????
  ?      ????
        ????
       ?????
    ??????
    ????
    ????
    ????
  
    ????
    ????
    ????

>>31
What >>30 did was create an anonymous function (aka block) and pass it to a method that modified every element in the array using the block.

I know that doesn't sound interesting, but it's seriously powerful shit that can drastically cut code size. It's a killer feature of Ruby IMHO.

People rarely see the point in features offered by more powerful languages until they've learned the language themselves and can think in new ways. This phenomenon is known as the Blub Paradox.

http://www.paulgraham.com/avg.html

>>32

But you can do that in C using function pointers, what's the difference here?

>>34
You can do anything in C, with enough effort.

Try implementing it in C. Compare. QED

Of course, C doesn't even have anonymous functions, and the moment you start emulating closures you'll begin to feel the pain.

Sorry, I still don't really get why it makes a difference if your function has a name or not.

>>36 see >>33

>>36
Try implementing it in C. Compare. QED
I didn't mean that facetiously. I was serious.

And the funny thing is, that if you did it the superficial way, which would only be about 3x longer (that's a lot!), you'd be missing out on the true power of blocks, since they're closures.

Emulating that in C would not only be a hideously ugly hack, it'd double the length of C code yet again. And since C doesn't have a GC, which is just kinda necessary for closures, uh... you'll probably end up doing reference counting with explicit free somewhere in the call hierarchy of every function that makes use of the closure. Yeach.

Not very readable any more, is it?

>>34
The more verbose, the higher the chance for a programmer error.

In a C solution, you'd iterate the array by either using a counter or ... incrementing the array's pointer or some magic.  If you mess one of them up, it's over -- you've got a bug.

The Ruby solution, on the other hand, only has to worry about the actual operation on the data, nothing else.

>>38
>>39

After reading your posts and applying some thought, I think I understand now. Thanks for the help