secondary programming language (graduati

Java probably. Or C, but Java would probably get more use. But then again, if you know C++ picking up Java should be no issue.

I wouldn't recommend VB to anyone, but that's just my personal distaste for it. Kind of weird that those are your only options.

Kind of weird that those are your only options.

Ah, I meant that those are the only options I can choose from that will fit in my class schedule. My bad.

Classes in C#, FORTRAN, and Lisp are also offered. However, Lisp is scheduled at the same time as a math class I have to take, FORTRAN just seems silly, and IDK about C#. AFAIK, C# is very similar to Java, just not as portable.

From what I hear, .NET is kind of a hot thing right now. So C# wouldn't be bad. LISP would be best IMO. Shows employers you have the ability to pick up very different languages.

chrisname (7395)

C# if you want a job, LISP if you want a brain (if they don't get you to read SICP, ask them why; it's pretty much the definitive book for learning CS with LISP (Scheme dialect)).

FORTRAN

There are a few companies out here that are still running FORTRAN and COBOL based mainframes and are willing to pay out the wazoo for anyone who can maintain them... Probably because everyone who's ever actually worked with either of those languages in the real world are retiring :P

chrisname (7395)

Retiring, or brain damaged.

closed account (1yR4jE8b)

From what I hear, .NET is kind of a hot thing right now

Maybe 5 years ago. Now the JVM is in full swing and Microsoft is gearing up to ditch .NET to start pushing Metro.

Thanks for the replies.

I guess I'll take the Java courses, since it's highly portable and, as darkestfright pointed out, JVM is the new black.

I spent a little time reading up on LISP/Scheme and the book that was mentioned. I think I'll try learning it on my own at first and see how that goes.

And as for this:

They may pay well, but it's still FORTRAN :P

Last edited on

Cubbi (4774)

atropos wrote:
They may pay well, but it's still FORTRAN

Modern Fortran (especially after 2003) is a fairly interesting language actually, and it hasn't been ALL CAPS since the 80s. There's active demand in finance, but it is, indeed, trending down since new code is usually written in C++.

chrisname wrote:
LISP if you want a brain

+1!

I was unaware that a modern version of ~~FORTRAN~~ Fortran existed. In my course catalogue, it's written FORTRAN. If that version is as old as you say, I would hope it was just an oversight by the admissions department.

I think Cubbi meant the CODE hasn't been all caps in some time :P

BOY DO I FEEL STUPID NOW

For some reason, I thought he meant that FORTRAN was a relic from the 80's and Fortran was a modern update of the older version.

rapidcoder (1010)

But then again, if you know C++ picking up Java should be no issue.

I've seen too many C++ coders that thought this and wrote terribly crappy code in Java, to believe it to be true.
They are very different languages. Don't get fooled by similar syntax and similar basic stuff.

They are very different languages. Don't get fooled by similar syntax and similar basic stuff.

Those similarities should definitely be enough to simply pick up the language. Now actually being any good at it should require more time and effort in learning how to use it properly.

Last edited on

I didn't say a master of C++ will be a master of Java, but I had no problems just picking up the language and getting things up and running after switching from C++ to Java. Now, it took some time to start diving into the amount of built in functions/headers(not sure what you call the imports in java, as I dont use it much) just because there is a lot more there than what C++ offers right out of the box, so to speak

closed account (3hM2Nwbp)

Now actually being any good at it should require more time and effort in learning how to use it properly.

From my experience, the biggest problem people have with Java (apart from large-scale design issues) is that they know that "there's a class for that!"...but then go on to pick the wrong one! For example, say someone needs an executor service for something. There's not a feature in the standard library for that...there are nearly a dozen! The whole Java library is a lot to absorb all at once.

ExecutorService 	newCachedThreadPool()
ExecutorService 	newCachedThreadPool(ThreadFactory threadFactory)
ExecutorService 	newFixedThreadPool(int nThreads)
ExecutorService 	newFixedThreadPool(int nThreads, ThreadFactory threadFactory)
ScheduledExecutorService 	newScheduledThreadPool(int corePoolSize)
ScheduledExecutorService 	newScheduledThreadPool(int corePoolSize, ThreadFactory threadFactory)
ExecutorService 	newSingleThreadExecutor()
ExecutorService 	newSingleThreadExecutor(ThreadFactory threadFactory)
ScheduledExecutorService 	newSingleThreadScheduledExecutor()
ScheduledExecutorService 	newSingleThreadScheduledExecutor(ThreadFactory threadFactory)

terribly crappy code in Java

I've seen this said much more often regarding Java than C++. When I ask exactly what they mean about "crappy code" - I get all sorts of different responses (some even contradicting others). Any examples of what you feel is crappy code?

Last edited on

Luc Lieber wrote:
When I ask exactly what they mean about "crappy code" - I get all sorts of different responses

That might have something to do with the word 'crappy' being subjective :P

chrisname (7395)

I'd say things like this qualify:

switch (integer) {
case 0: return 0;
case 1: return 1;
// etc.
}

as well as using the wrong algorithm (although it's fair not to know when to use merge, insertion or quicksort, using bubblesort in performance-intensive code is an indicator that someone doesn't know what they're doing), premature micro-optimisations (which don't work, especially when the algorithm chosen is slow), code with poor structure (misuse/abuse of goto), reimplementing standard library functions (because of ignorance, not lack of availability or portability), generally untidy/unstructured/unreadable code, code that doesn't perform well, code that doesn't scale well (within reason), etc.

Mostly, it's things you would possibly expect to see in someone's code if they'd recently started programming.