When not working in a research group at Research In Motion, Steve likes to study new topics in Computer Science, and create unique web applications that apply them. Steve is a DZone MVB and is not an employee of DZone and has posted 5 posts at DZone. You can read more from them at their website. View Full User Profile

My Thoughts on Various Programming Languages

07.08.2014
| 3672 views |
  • submit to reddit

I hate all the languages. Once, I tried to make my own language, but I couldn't figure out what language to do it in, so I never started.

Most of the time, you don't have any choice of what language to work in. Whatever language I'm using, I've learned to appreciate both its strengths and weaknesses.

Java

People who like Java like typing. I mean: actually hitting keys on the keyboard. You have to keep repeating yourself over and over.

The whole java system was designed by an insane person whose answer to everything is to use a Design Pattern. If you see design patterns as a way of working around problems in the language, you will see that Java has many.

On the other hand, the folks at Sun really put the work in to make Java a specification that works on embedded platforms, so we're stuck with it there. I wouldn't really trust Python or C to run my desktop on my phone.

Also, what's with all those folders? I have to use Eclipse, against my will, because it knows how to jump around all those 1000 character path names. Would it really hurt anybody if I kept the 10 objects in my application in the same folder?

C

C is precise. When I write something in C, and it is done, I know that it will work. It's like painting a masterpiece with a single-hair brush. Having to code in that level of detail is a different mindset. When you sit down to write something in C, you have to plan it out before you start. Otherwise it's a lot of work to change it later.

If you have enough experience, memory leaks are rare. It's second nature -- malloc/free come in pairs. You can't forget one. It would be like forgetting to flush or turn off the lights. You just do it.

That being said, if you're going to paint a house, you don't want to be using a fine brush. You want huge rollers. If I'm writing a whole application, or a system, I would avoid C if I can.

It is difficult to make large changes to a C program. When I'm working on an algorithm, and I know that the first cut won't be right, often I will code in python first and then translate it into C by hand when it's done.

C++

It's C with a string class. And arrays and lists and heaps of queues to implement whatever you desire. A word for the wise: don't try to make your own templates. It's too hard. Aside from that, C++ makes C better, and you can write some very nice software in C++. The extra features make it scale up to larger systems with only moderate difficulty, as long as everyone follows the same conventions.

Javascript

This is the language that nobody loves. But javascript loves you. When you were first learning it, you might have written some very bad code that used an object as a dictionary, with other objects as keys, but it's totally okay, because that code is still running flawlessly and will continue to run as along as browsers run javascript.

Javascript lacks a linker, so all the code shares the same namespace, but everyone knows that, so everything still works together.

coffeescript

Coffeescript is a translator that takes a strange ruby-like language and turns it into Javascript, line by line. It is javascript with all extraneous syntax -- braces, brackets, extra keyswords removed. Only the essential meaning of the code remains.

Coffeescript is nice. When you have to write tonnes of code, coffeescript will make you at least 25% faster. You can see that many more lines on the screen at once.

When you code in coffeescript you have to be very aware of what Javascript is going to be generated. That's the problem. You have to know Javascript first. Anyone new coming to your project has to first learn Javascript, and only then learn coffeescript, and then learn your codebase.

node.js

I wanted to like it. I think I gave it a good go. It's the callbacks that got me. I just knowthat someday, for whatever reason, one of those callbacks isn't going to happen and then my app is going to be stalled waiting forever. That's no way to live.

Also, nearly nothing is built in. But if you have to do X, there are always a dozen modules to choose from that do the same thing. Which do you choose? Which will get support if you have problems?

Scala

Scala is a functional, typed language that compiles to JVM code.

I learned Scala on the job. Yup, a startup was actually using it for their production system, and I joined them fairly late.

This allowed me to see the ugly side of Scala: Type inference. Types are inferred to the extreme. Everything has a type, but figuring out what that type is means checking different files several levels back. And Scala inherits Java's folder insanity, so it means delving into several levels of folders to find the right file to lookup the type.

In short, Scala was great -- for the original developers. Newcomers had a long learning curve to learn the existing code.

Erlang

Erlang is also one that I wanted to love. I really tried. It is a beautiful functional language that lets you make wonderful little modules that communicate in precise ways, and your system can run for 10 years because it can deal with unexpected problems, restart what's needed, and keep going.

Unfortunately it's baroque. Development seems to have stopped at about the time that Berkeley invented sockets. Almost nothing needed in the modern era is included. Why is it so much work to make a simple web service?

Go

Go is easy to learn, even for newcomers. It uses language concepts from 40 years ago to build a robust, asynchronous system, and lets you code it as if it were synchronous. You can write 1000 threads that work together safely in Go without your brain hurting.

It still needs some work in library support. When I want to do X, which library should I use -- the one on github from 2011 or the one from 2013 that is half finished? One is linked to from the official pages, but it the official pages don't seem all that up to date. Sigh, I guess I'll have to write my own...

Also why is it so difficult to append to an array?

Python

There's a library for everything in python, and if you use Linux it's usually clear which is the top one, because it's installable with one command.

If you have to do some number crunching or scientific computing you will be well-served by choosing Python.

Strings can be both text and data in python, so you have to learn about text encodings early on.

Python 3

Python 3 shares many characteristics with python, though it is a different language. Since it's newer its not supported as much. I want to use it, but there's always that one library I need that only has python 2 support.

Published at DZone with permission of Steve Hanov, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Robert Saulnier replied on Tue, 2014/07/08 - 8:19am

The Java compiler doesn't care if you toss all your source files in the same folder, but IDEs do care.

Andries Spies replied on Tue, 2014/07/08 - 9:43am in response to: Robert Saulnier

C++, where everybody seems to have the need to invent yet another string class. where everybody hates "garbage collection", but still you have some genius which  feel the need to:  re implement malloc(), free() and hide the default constructor because the factory pattern in C++ is way cooler than on any other language.   

Jan Gaspar replied on Tue, 2014/07/08 - 4:32pm

 "Scala inherits Java's folder insanity" - not true. Scala package doesn't have to reflect the folder structure. And figuring out the type of a value in Scala ... just do Alt+Enter in IntelliJ.

Jeremy Pulcifer replied on Wed, 2014/07/16 - 12:17pm in response to: Robert Saulnier

Since when? I mean, it's less optimal to put all 500+ class definitions in the same package/file folder, but if that's your game, knock yourself out. Eclipse ain't gonna complain. Defaults are not the enemy.

Robert Saulnier replied on Wed, 2014/07/16 - 12:37pm in response to: Jeremy Pulcifer

Read my comment again.

You can toss all your source files in the same folder, but these sources can represent classes from multiple packages. The compiler will compile them without a problem.

IDEs require that a source file is located in a folder that matches the class' package.

If you have a source file in the wrong folder (folder doesn't match package), the IDE will complain.

Tom Fillmore replied on Wed, 2014/07/16 - 2:12pm

Nice read, I liked your commentary...

 What are your thoughts on Groovy?

Joao Bispo replied on Sun, 2014/07/20 - 9:49pm in response to: Robert Saulnier

I've always felt that's a plus and not a minus, and never had a problem with it.

If I have to share code, it's usually a JAR and that becomes irrelevant. If I really need to share the code, I just copy the "src" folder (with the folder structure).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.