SCJP 5 | SCWCD 5
[How to ask questions] [Twitter]
Pat Farrell wrote:Not one to argue a lot with our author, but I think (all IMHO) both Java and C++ are way too complicated to use for parallel applications by some huge percentage of commercial professional developers.
The efficiency argument has been used for every step forward since Von Neuman started programming. Are assembly languages too far from the hardware? Can you right a real operating system in a higher level language (as defined at the time) or must you use machine code/assembly.
The "high level languages" of the time were Bliss, C, and PL/1. While PL/1 was used for Multics, which brought many critical concepts into the world, Multics was considered to big and too resource intensive (speed, memory, etc.) to be useful in the real world. Bliss and C were used in their time-frames for DEC's VMS and AT&T's Unix. Both of these systems were extremely successful.
I have been using Java for 12 or 13 years, and bought Henry's threads book first edition. While the newer libraries, and better books and documentation, its more approachable, but its not easy.
Which is why my biases say that a language like Scala, that is inherently parallel, built on the JVM engine and libraries, will be the future. I have no idea if Scala will be the one, but I think that long term, we will look back at programming applications in Java for 64 processor CPUs and think "how quaint" as we do about programming operating systems in assembly.
Sergey Babkin wrote:Why not argue? All the forum fun is in the arguing! :-)
Sergey Babkin wrote:I haven't looked at Scala, so I can't say for sure. Isn't it something from the department of the functional programming? Personally I find the functional programming very difficult. The logic of the functional programs is very hard for me to track: they're hard to read, hard to write, and horribly difficult to debug.
But the reality is that solid parallel programming is hard to (read/write/debug) no matter how you do it. Its just a complex topic, and as I'm sure your book points out, sloppy code that works fine single threaded or at modest levels of parallelism breaks in really ugly and subtle ways in massively parallel world. Which is why Dijkstra, Hoare, et all spent so much of the 60s building a solid set of tools and theory.
Richard Golebiowski wrote:I don't get why people say it's difficult. I did a very complicated web app that has to do thousands of calculations, reading, calculating, and then writing data back out to a database without any problems.
Pretend you are implementing Facebook. You want to report who are the users who have most "friends". The naive appoach is to write a bit of code that looks like:
Find all users
Setup array of ten objects/structure with user information, and number of friends
For all users,
if this user's friend.size() > existing
put this user in list, bump someone else out
Find all users
Setup array of ten objects/structure with user information, and number of friends
For all users,
if this user's friend.size() > existing
put this user in list, bump someone else out
Richard Golebiowski wrote: select top 10 name from user order by numberOfFreinds desc
However, most applications are stand alone apps that run on a single system. With a stand alone application things are simpler and so is using multiple threads to do calculations.
I've been professionally writing Java for 13+ years and have never written a stand alone app for a single system. Everything has been web implementations for large scale commercial websites. I've never been paid to write code using things like AWT or Swing
Richard Golebiowski wrote: there ar other things on the web besides large scale commercial sites.
Richard Golebiowski wrote:smaller applications that can possibly benefit from multi-threading and that in these instances doing something that is multi-threaded probably wouldn't be hard to do.
Pat Farrell wrote:
But the reality is that solid parallel programming is hard to (read/write/debug) no matter how you do it. Its just a complex topic, and as I'm sure your book points out, sloppy code that works fine single threaded or at modest levels of parallelism breaks in really ugly and subtle ways in massively parallel world. Which is why Dijkstra, Hoare, et all spent so much of the 60s building a solid set of tools and theory.
I'm not too worried about the next year or two. There are six core CPUs for sale for $300 now, I don't expect we will exceed 16 for a while at least one year. But its inevitable that the numbers will get huge. And I don't think any sequential programming language is going to work.
Scala is pretty foreign looking. They didn't fall into the same trap that the C folks did going to C++, where they tried to hard to go from traditional systems language to OO, and ended up with something that was not very OO and not very traditional.
The strength of Scala is to remove the sequential steps, you make the algorithm and apply it to a wad of data. The whole functional space reminds me a lot of Iverson's APL (A programming language) of the late 60s/early 70s. That was simply too much of a leap at the time, but with it, you could say "take this matrix M and invert it, take the eigenvectors and do this with them", it works at a much higher level of abstraction, just as well written Java handles internationalization in ways that a C programmer with strcpy simply can never do.
As a transition device, all of the Java libraries, any Java library works with Scala, but I see this as temporary and expedient, not fundamental. What is fundamental is to build on the JVM and its performance, and then bring folks to think at a higher level. When I was a young programmer, it was way before the whole WIMP (windows, icons, mouse and pointers) idea was invented, we did command line services and thought that was very user friendly.
The whole WIMP world was considered to slow and inefficient to use for real work well into the 1990s for PCs, While windows 3.0 allowed folks to think about windows, corporate America was using DOS and Wordperfect well past Windows 95.
Sergey Babkin wrote:Interesting, APL is also what comes to my mind when I look at the functional programming. Only I think that APL is pretty much the most nightmarish language possible.
Don't get me started about those stupid light bulbs. |