Slashdot Mirror
Programming Languages You'll Need Next Year (and Beyond)
Nerval's Lobster writes: Over at Dice, there's a breakdown of the programming languages that could prove most popular over the next year or two, including Apple's Swift, JavaScript, CSS3, and PHP. But perhaps the most interesting entry on the list is Erlang, an older language invented in 1986 by engineers at Ericsson. It was originally intended to be used specifically for telecommunications needs, but has since evolved into a general-purpose language, and found a home in cloud-based, high-performance computing when concurrency is needed. "There aren't a lot of Erlang jobs out there," writes developer Jeff Cogswell. "However, if you do master it (and I mean master it, not just learn a bit about it), then you'll probably land a really good job. That's the trade-off: You'll have to devote a lot of energy into it. But if you do, the payoffs could be high." And while the rest of the featured languages are no-brainers with regard to popularity, it's an open question how long it might take Swift to become popular, given how hard Apple will push it as the language for developing on iOS.
Over at Dice
But we are at Dice, sir:
Pros: Today's article has more content than the usual Dice front page linkage. Great article if you're not a programmer but feel stymied by the wide assortment of languages out there. Although instead of hemming and hawing before making your first project you're better off listening to Winston Churchill and sticking your feet in the mud: "The maxim 'Nothing avails but perfection' may be spelt shorter -- 'Paralysis."
...
Cons: It barely scratches the surface of an incredibly deep topic with unlimited facets. And when one is considering investing potential technical debt into a technology, this probably wouldn't even suffice as an introduction let alone table of contents. Words spent on anecdotes ("In 2004, a coworker of mine referred to it as a 'toy language.'" like, lol no way bro!) could have been better spent on things like Lambdas in Java 8. Most interesting on the list is Erlang? Seems to be more of a random addition that could just as easily been Scala, Ruby, Groovy, Clojure, Dart -- whatever the cool hip thing it is we're playing with today but doesn't seem to quite pan out on a massive scale
My work here is dung.
CSS3 is not a programming language. No more then HTML is.
Visit the Arcade Restoration Workshop @ http://www.arcaderestoration.com
I am surprised that Scala isn't mentioned.
It is strongly typed, object-functional and compatible with java.
Swift syntax is basically a cut and paste from Scala, which benefits from being more mature (and having access to all the Java libraries)
Scala is also much faster than erlang, while also supporting the actor based model.
http://www.scala-lang.org/
Learn C++, Java or C# and get yourself a job at a big corporate.
But hey, if you want to be a hipster coder and dick about all day doing "groovy" websites at some here today gone tommorow startup and earning fuck all by all means go down the web development route along with every other 14 year old school kid.
Erlang? Nice language but too niche. Never really got momentum outside telecoms and its probably too late for it now.
Who cares about a fucking language. I know more that 20 different programming languages, I don't care about one more or less. What can it do, that I can't do already ? Can I program faster, or better? Or is it just an other syntax, for some obscure system ?
Please, no more Erlang world domination news.
I went through that 3 years ago already. We had a project that a fanatic asked us to rewrite in Erlang.
it took 9 months with 2.5 people.
Tons of issues, mostly with very lacking library support, tooling. Obnoxious stuck up community too.
In one case, I had a guy tell me online "hire me as an Erlang consultant and then I will help you".
In the end we set screw it (once the Erlang fanatic left).
We rewrote this 9 months of Erlang development in 3 weeks (!) using one senior Java developer.
it worked like a charm and still runs flawlessly in production today.
Erlang = HYPE
Everything is immutable is beautiful for fairy tales, but not for real-life software (trying building a DOM in a language which is 100% immutable).
All modern languages have learned from Erlang's mistake. They do immutable by default, but allow mutable if there is a need for it (e.g. Ceylon, Rust, etc)
Next year, the languages you'll need will still be C, C++ and Java. Maybe some C#, Python or Bash. The year after that, you'll still be using C, C++, and Java. Maybe some C#, Python or Bash.
By 2020, the main difference is that you'll be working with machine-learning DSLs and libraries to program/train memristor based devices. But you'll still be using C, C++, and Java. Maybe some C#, Python or Bash.
Or how about learn about the fundamentals of computer science. Actually learn what pointers are, pass by reference, multi-threading, type safety, and all of the things that implies. Then express those in whatever language you want. If you truly understand how computers and languages work, and what an enterprise system is composed of, you will likely have future proofed your career. If your language doesn't support many of those ( I am looking at you, JavaScript), then perhaps consider how much those jobs are likely to pay in the long run....
You might want to take a look at http://nimrod-lang.org, like a cross platform swift.
Swift is a strongly-typed language, that operates inside a runtime with garbage collection.
There is no GC in iOS. Also the GC in OS X is deprecated. Swift uses Automatic Reference Counting which is something... completely different.
Need? No. You can still use Objective C if you want to code iOS/OS X. Want? Yes.
And while the rest of the featured languages are no-brainers with regard to popularity, it's an open question how long it might take Swift to become popular, given how hard Apple will push it as the language for developing on iOS.
Apple does not have to push very hard. After looking at it and Objective C, it doesn't take a genius to see why programmers would prefer it over Objective C.
Well, there's spam egg sausage and spam, that's not got much spam in it.
The whole point of Swift is its ability to abstract Cocoa. Lots of Swift's specifics make no sense without Cocoa. Given that Swift in practice is going to be loaded with calls to Cocoa, it is going to be as portable as Visual Basic or Bash.
How do we even know it's going to be popular in the first place? Does it solve any problem I can't do with C# or Python and/or on more platforms?
Considering that you can't really use C# or Python for iOS or OS X development, I would say that's one major thing you can't do.
It'll be a language for little hipsters who hope to be the next Steve Jobs by releasing yet another crappy useless iOS app. I don't know anyone who still bothers with iOS apps.
Then you must not know anyone who uses an iPhone meaning you live in a rather small world.
Well, there's spam egg sausage and spam, that's not got much spam in it.
CSS/JavaScript/HTML5 is plainly obvious. Everything from Microsoft to mobile hybrid development relies on this these days.
C# is the standard language of the Microsoft stack --- in fact, the bulk of MS-stack training is in C#, with only a smattering in VB.NET.
Java is the COBOL of the early 21st Century. It isn't sexy anymore but it will always be around.
PHP is used in a lot of web applications. I wish it weren't. In fact, I'd really rather see Ruby on Rails take over this space.
If you're going to program native code, you could learn Swift, sure. You could also learn Rust (Mozilla's systems-level language with significant buy-in from Samsung) for device programming. If your goal is to write native apps, your best bet for Android is actually Java. By the way, one can also design native apps in Java (the code is Swing-like) and compile them to native apps for iOS or Android using Codename One, and I imagine a few shops will pick up that practice.
I like Erlang as an honorable mention. I'd also add two others: Python (especially for data analysis) and PowerShell (which will set the grown-up Microsoft sysadmins from the point-and-click kids).
Finding God in a Dog
C. Plain old C.
Entire Operating Systems are written in it. Userland tools for those operating systems are usually written in it. Any self-respecting developer knows at least C. The rest is just like fashion tips: next year they're outdated.
Although, as much as I hate to admit it, the same could be said for Java...
And on the Eighth Day, Man created God.
It is not. Strong typing can be implemented by attaching types to data. Static typing always attaches types to variables and they are fixed. But strong typing can also mean type-less variables, but no implicit conversion of values. For example, Perl is weakly typed, but that is because it will, for example, happily convert a string to a number all on its own. Python, on the other hand, is strongly typed, despite its variables not having types just like in Perl. The values assigned to the variables in Python have types and all type conversions have to be explicitly requested by the programmer.
With such a stupid article, it is really no surprise the author gets basic things wrong.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
You're correct. The terms "strong" and "weak" do not have formal definitions and really aren't related to static or dynamic (which do have specific definitions). The definitions used by the article for functional programming and dynamic type systems aren't accurate/complete either. Furthermore, C/C++ wouldn't be considered a "strongly-typed" language since the type system can be freely ignored by the programmer. In any event, this article is poorly written and can probably be safely ignored.
Heh, even if you have a variable that *IS* final, you can *STILL* change it's value at runtime.
Java doesn't enforce final at the bytecode level.... It's a compile-time hint and the values can still be modified at runtime.
It's one of the main differing qualities of C++ vs Java. Const is enforced much more than "Final" in Java.
Also C++ templates aren't by-default type-erased like Java's generics. But in C++ type-erasure is a pattern that I can choose to use or not.
Lately I do work that garbage collection simply doesn't work well for..... I much prefer manually handling unique/shared_ptrs myself and choosing when and where stuff gets freed and in what order. Big data type stuff with lots of CPUs and massively parallel algorithms using in-memory working sets over 1 TB.
The older I get, the more I realize that C and C++ were the only languages I really ever needed despite learning easier languages first. (BASIC/QBASIC/VB/Perl/Python/Java/C++/C)
Now I wished I started with C++. Seriously. It's all i really need.... Python for quick prototyping crap, C++11 for the rest.
I spent over two years working every day with Erlang on a project, and I still don't consider myself to be anywhere near an "expert" at the language. It's just too weird and special case for a lot of the functionality I was trying to code, so while certain tasks were easier than they would have been in Java or another procedural-object language, others were damned near impossible and took obscene amounts of time to get working at all -- never mind working efficiently.
Personally I'd avoid it like the plague unless you have some special case need for it's features. Even with regards to concurrency, it's not really any better than any other language's concurrency features. They aren't really baked into the language as the summary suggests, but provided by frameworks in the API libraries, much as they are by other languages.
The main difference with Erlang concurrency is that the concurrent models are the "normal" way to program Erlang, so you're likely to find a lot of good examples of how to do it. I've found the documentation for other language's concurrency features to be somewhat limited in comparison, and less "real world" in their examples.
The main thing that I found neat about the Erlang framework was the ability to specify auto-restarts of failed threads. It takes all of about 4 lines of configuration to get a thread to be persistent/self-starting. That's the densest code I've ever seen for achieving such a task.
The big downside to Erlang is that it's almost as bad as LISP -- everything is a list. Even "structures" are just lists of objects with tags that identify the list indices for accessing the members. Be prepared for a nightmare of tail recursion if you get into this field of programming.
That said, it can be a fun and entertaining language to work with. For the things it is good at, it can be a joy to use. Much as with any language.
I do not fail; I succeed at finding out what does not work.
As long as we are hyping Erlang, the Erlang community is getting some disruption from a language developed by a prominent Rubyist called Elixir. Clojure-inspired metaprogramming, a Ruby-ish syntax, and it all compiles down to the same VM code that Erlang compiles into.
While there is a need for strongly typed languages, that doesn't imply that all languages should be strongly typed. More to the point, however, Scala appears to be staticly typed (I'm believing documentation here, I've no experience). Many problems are addressed only with difficulty via a staticly typed language.
Compatible with Java. OK. So is Jython, so is JRuby. Object-functional? Not quite sure what you mean, but I would guess that so are Jython and JRuby. Also Groovy.
This isn't really a response to the article, but rather to your comment. Unless you are in love with the Scala syntax, you don't seem to justify your point. Even Clojure would meet all the benefits that you list. (As well as several other languages.)
Personally, I dislike intensely Java's 16-bit char system. I much prefer either utf-8 or utf-32. Perfferable either chosen as needed. Alternatively the Python3 opaque string type with conversions to the desired representation also has its benefits. (My real preference is uft-8, but then most of what I work with is ASCII, and I only need occasional double or triple byte characters. But for that to work the language MUST have appropriate library support. As Python, Vala, D, etc. have. Ruby has it via an add-in gem. Java doesn't seem to really have it, and as a result neither do any of the languages that are symbiotes. C and C++ are, admittedly, as bad as Java. You need a large and clumsy external library. Racket Scheme has this aspect handled well, but there are other reasons that it's less than desireable.)
So. Which languages will you need in 10 years? It's one that isn't popular yet. Vala is a possibility. So is D. And prehaps there will be applications for which Swift is desireable. I'm really dubious about Java. C will probably still be necessary, but I'm not sure about C++. Some successor of the current Scheme versions would be desireable, but it MUST implement IPC much better than any current Scheme does. Some dataflow language would be highly desireable, but I don't know of any decent conderes. (The one's I'm aware of are too specialized...though one of them could grow out of that.)
The language really needed hasn't yet been written. It will be designed to be easy to write multi-process programs in. And it will be easy for processes to submit messages to each other's read queues. Erlang is almost right, but it concentrates too much on immutability, which works quite well for a certain subset of problems, and is terrible for many others. The reall concept needed is isolated mutability, where mutability is all "thread confined" (except that I mean process confined). I don't think that it should be possible to pass pointers between processes, but perhaps it could be done if the pointer only pointed to totally immutable data and it's recursive equivalents.
As I said, this language doesn't seem to exist yet, but various languages have implemented pieces of it, so I don't see any intrinsic difficulty in creating the language.
I think we've pushed this "anyone can grow up to be president" thing too far.
the iOS development market is dried up for most developers, unless you can get a job at some company that wants an iOS app.
umm duh? i don't understand the point of this. the nurse market is pretty dried up except for some job in healthcare.
So much fail about Garbage Collection.
GC is not about forgetting to free memory. It's about higher level abstraction removing the need for the programmer to do the bookkeeping that the machine can do. Why don't we still program in assembler? Because it's less productive. It's about productivity. As data structures become extremely complex, and get modified over time, keeping track of the ownership responsibility of who is supposed to dispose of what becomes difficult to impossible, and is the source of memory leak bugs. In complex enough programs, you end up re-inventing a poor GC when you could have used one that is the product of decades of research.
The article fails to understand that you can also run out of memory in a program using GC. Just keep allocating stuff without and keeping references to everything you allocate.
Reference Counting is not real GC. Cyclical data structures will never get freed using reference counting.
One of the major, but under-recognized benefits of GC, which the article fails to mention, is that GC allows much simpler ''contracts' in APIs. No longer is memory management part of the 'contract' of an API. It doesn't matter which library or function created an object, nobody needs to worry about who is responsible for disposing of that object. When nobody references the object any more, the GC can gobble it up.
On the subject of Virtual Machines, the article could mention some of the highly aggressive compilation techniques used in JIT compilers. So every method in Java is a virtual call. But a JIT compiler knows when there is only one subclass that implements a particular method and makes all calls to the method non-virtual. If another subclass is loaded (or dynamically created on the fly) the JIT can recompile all methods that call the method such that they are now virtual calls. Yet still, the JIT may be able to prove that certain calls are always and only to a specific subclass, and so they can be non-virtual.
The JIT compiler in JVM can aggressively inline small functions. But if a class gets reloaded on the fly such an the body of an inlined method changed, the JIT will know to recompile every other method that inlined the changed method. Based on the changes to the method, it may or may not now make sense to inline it -- so the decision on whether to inline the method can change based on actual need.
The HotSpot JVM dynamically profiles code and doesn't waste time and memory compiling methods that do not have any significant effect on the system's overall performance. The profiling can vary depending on factors that vary from system to system, and could not be predicted in advance when using a static compiler. The JIT compiler can compile your method using instructions that happen to exist on the current microprocessor at runtime -- something that could not be determined in advance with a static compiler.
All of this may seem very complex. But it's why big Java systems run so darn fast. Not very many languages can have tens or even hundreds of gigabytes (yes GB) of heap with GC pause times of 10 ms. Yes, it may need six times the amount of memory, but for the overall benefits of speed, the cost of memory is cheap.
I'll see your senator, and I'll raise you two judges.
A functional language is one whereby the functions themselves can be stored in variables and passed around as parameters to other languages.
What in the actual fuck. That may be the worst definition of a functional language I've ever heard. Even if I try to interpret it as something that could make any sort of sense, I just get that storing functions in variables makes a language functional, which the author goes on to debunk by pointing out that C++ isn't a functional language. Why bother even trying to describe them if you have no idea what the hell they are?
Entire operating systems are written in C -- as they should be.
But C is a low level language. Not the best tool for writing applications.
Higher level languages and managed runtime systems have gained so much traction for a reason. They are very productive to use. They protect you from simple mistakes. The relieve the burden of memory management. GC simplifies library APIs by making the question of who should dispose of what become irrelevant. We could still be programming in assembly language instead of C. Why aren't we? Why aren't OSes written in assembly? Because C is more productive and higher level. Similarly, there are higher level languages than C, and they have their place. C is not the end all of abstraction.
I'll see your senator, and I'll raise you two judges.
Well a quick stat on indeed.com suggests that I am right in mentioning scala over what you suggest:
http://www.indeed.com/jobtrend...
Take a look at Akka. It mostly fits your description for the "language" you want. Scala is pretty extendable, so the libraries often end up looking more like language extensions than libraries.
Scala allows both mutable and immutable objects, but it favours immutable.
In Akka you have mutable state within your actors and pass immutable messages.
Since around 1986.
Need to type accents and special characters in Windows? Use FrKeys
So if you can do a calculation in HTML and CSS, then it is a programming language?
Ok, here: http://experiments.hertzen.com...
Ooops.