|
Posts: 409 / Nickname: bv / Registered: January 17, 2002 4:28 PM
The Next Big JVM Language
September 22, 2010 9:00 PM
|
|
At the JavaOne 2010 conference in San Francisco, Stephen Colebourne, member of technical staff at OpenGamma and project lead of the Joda Time open source API, gave a talk entitled "The Next Big JVM Language." In this short interview, he reveals what he thinks the next big language could be.
http://www.artima.com/lejava/articles/javaone_2010_the_next_big_jvm_lang_stephen_colebourne.html What do you think the next big JVM language will be, and what do you think of Stephen's idea? |
|
Posts: 35 / Nickname: seanl / Registered: March 8, 2002 5:57 AM
Re: The Next Big JVM Language
September 23, 2010 2:11 PM
|
|
> But maybe rather than us going out there and saying to
> Oracle, "Let's add closures to the language; let's add > properties to the language," what if we made a backwardly >incompatible version of Java? Who is "we?" If you mean Oracle, it won't happen. Not in their interests. If you mean the Java open source community, then ask Google how it feels to mutate the JVM. This sounds like an appealing idea: Java 2010. I just don't see how it can happen practically or legally. FWIW, in some alternate reality where this proposal could happen, I doubt the resulting language would be significantly less complex than Scala. These are very interesting times. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: The Next Big JVM Language
September 24, 2010 2:19 AM
|
|
I don't think there is going to be a big JVM language in the following years. I also don't think that there is going to be a big language generally. In my humble opinion, things have become stale in the programming languages domain, with new languages being only small variations of the languages of the previous generation.
I think the programming language community is trying to find the best balance between ease of use for the libraries developer and the end user. Which is not bad, I think there is a lot to be done in this domain. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: The Next Big JVM Language
September 24, 2010 9:16 AM
|
|
> I don't think there is going to be a big JVM language in
> the following years. I agree. Java is going to get some new features, hopefully not tooo many and hopefully without breaking backward compatibility (I can't stress this point enough). In short, I pretty much agree with Stephen's analysis: Clojure is too different, Scala is too complicated, don't know about Factor or Groovy. But as I said, preserving backward compatibility is critical and that's where I disagree with Stephan. |
|
Posts: 35 / Nickname: seanl / Registered: March 8, 2002 5:57 AM
Re: The Next Big JVM Language
September 24, 2010 10:41 AM
|
|
> But as I said, preserving
> backward compatibility is critical and that's where I > disagree with Stephan. If I understand the article correctly, those who require backward compatibility would stick with "Java Classic" which would continue on its current trajectory. The forked version (Java NG) would be a different language. There would be initial compatibility breakage but it would be wise to continue the backward compatibility guarantee from that point on. |
|
Posts: 1 / Nickname: staksi / Registered: September 25, 2010 3:53 AM
Re: The Next Big JVM Language
September 25, 2010 9:10 AM
|
|
I think most production languages developed in the past 20 years or so made a big step backwards from C++. That's why there are so many of them - every new language is trying to correct something in a previous language because all of them suffer from some fundamental flaws (some more than others). Just look at the generics in Java and C# - it's ridiculous! This industry wastes too much time and effort in designing new languages instead of developing problem-solving techniques.
What I'm trying to say is that we should stick with C++, especially C++0x, and forget about the rest. |
|
Posts: 1 / Nickname: salient1 / Registered: March 9, 2007 8:05 AM
Re: The Next Big JVM Language
September 25, 2010 3:40 PM
|
|
"What I'm trying to say is that we should stick with C++, especially C++0x, and forget about the rest."
C++ is one of the worst languages ever designed. I'll pass. Java has plenty of flaws to be sure but C++ is a flat out abomination. In fact, I can't think of any language of note that got OO worse than C++. It's that bad. It's practically designed to encourage horrible coding practices. |
|
Posts: 8 / Nickname: channing / Registered: May 14, 2003 11:45 PM
Re: The Next Big JVM Language
September 23, 2010 1:06 PM
|
|
I couldn't disagree more about Scala being too complicated. If Java has taught us anything its that people will find a way to hang themselves whilst shooting themselves in the foot no matter how simple the language.
My personal experience over the last couple of years with scala is that it results in much simpler, easier to read and easier to maintain code. You can use very sophisticated techniques (eg scalaz) but the average programmer needn't go that far to greatly simplify their work. We really shouldn't be afraid of using sophisticated languages and tools. |
|
Posts: 7 / Nickname: cbeust / Registered: February 27, 2004 3:21 AM
Re: The Next Big JVM Language
September 23, 2010 9:10 PM
|
|
Scala advocates don't like to hear that Scala is too complicated, but it's a fact that this perception is widespread.
For example, on Artima itself just a few days ago (second comment): http://www.artima.com/forums/flat.jsp?forum=226&thread=305560 Or this thread on reddit: http://www.reddit.com/r/programming/comments/dhtor/leaving_net/c10bnmu |
|
Posts: 8 / Nickname: channing / Registered: May 14, 2003 11:45 PM
Re: The Next Big JVM Language
September 24, 2010 1:46 AM
|
|
> Scala advocates don't like to hear that Scala is too complicated, but it's a fact that this perception is widespread.
If simplicity in the language is the goal then we should all be using 6502 assembler: 1 accumulator and a couple of registers if I recall. Very simple. All the ports from Java to Scala I've seen, and all the solutions I've seen written in Scala, are simpler than the equivalent Java. One could probably say the same of ruby and clojure but I don't know enough about them to make a judgement. |
|
Posts: 11 / Nickname: johnyboyd / Registered: April 26, 2007 3:17 AM
Re: The Next Big JVM Language
September 24, 2010 1:35 PM
|
|
>Or this thread on reddit:
> http://www.reddit.com/r/programming/comments/dhtor/leaving_net/c10bnmu Oh please ... some chap relates a secondhand Scala horror story, possible to get a rise out of the group. Pls don't take that as a representative sample .. -jb |
|
Posts: 9 / Nickname: eengbrec / Registered: April 15, 2006 2:07 AM
Re: The Next Big JVM Language
September 25, 2010 9:10 AM
|
|
I think that Scala has a ton of features that interact in powerful ways, and people haven't really figured out the right way to use them yet. The result is a lot of code that leverages more magical features unnecessarily, and that tries to make everything look like a DSL.
A good example, I think, the Dispatch library mentioned in the Reddit thread. It's a wonder library once you get the hang of it, but ironically I think it's orientation as a DSL makes it much harder to learn that if it was just a library with plain old method names and much more limited use of implicits. I think there's a certain coolness factor right now in using all these features and making everything a DSL that will fade, and when it fades Scala code will start looking a lot more approachable. |
|
Posts: 4 / Nickname: terkans / Registered: January 5, 2005 2:30 AM
Re: The Next Big JVM Language
September 23, 2010 9:30 PM
|
|
> Scala advocates don't like to hear that Scala is too
> complicated, but it's a fact that this perception is > widespread. And depending on the programmer this can be true or not. With the greater flexibility of the Scala syntax, it is possible to build solutions that look significantly more complex and harder to understand. Equally, a good developer can build a solution that looks less complex and is easier to understand than an equivalent Java solution. As a more capable language, Scala does place a greater responsibility on the individual developer. At that point you need to ask the question "do I want better developers or more developers?" That is where the interests of a business that uses development tools start to diverge from those of a business that makes those tools. |
|
Posts: 7 / Nickname: garibaldi / Registered: March 3, 2008 1:14 AM
Re: The Next Big JVM Language
September 23, 2010 11:44 PM
|
|
Is the JVM itself beyond critical analysis? To paraphrase the article, I think it is useful to think about what we've learned from the JVM. What did the JVM wrong? What did the JVM get right? Could we build a better base for 'the next big language(s)'?
|
|
Posts: 1 / Nickname: gloeffler / Registered: November 30, 2008 8:48 PM
Re: The Next Big JVM Language
September 24, 2010 3:20 AM
|
|
> Is the JVM itself beyond critical analysis?
i second this - the JVM has been widely praised for enabling the current plethora of JVM-based languages, and without the JVM these languages couldn't claim production-readiness and Java interoperability to the extent they rightfully do (with many differences between languages). On the other hand, the CLR has arguably got a few decisions "more correct" than the JVM: generics and the handling of primitive types and true objects immediately spring to mind, as they cause a lot of grief on the JVM and need to be addressed by JVM language designers (e.g., see optimisations in Scala 2.8 for making primitives appear as true objects without losing performance). |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: The Next Big JVM Language
September 24, 2010 3:02 PM
|
|
> At that point you need to ask the question "do I want
> better developers or more developers?" I've worked in small, medium, large, and very large development organizations. In all cases, managers vote for more bodies. |
|
Posts: 12 / Nickname: ianr / Registered: April 20, 2007 6:37 AM
Re: The Next Big JVM Language
September 25, 2010 11:46 AM
|
|
> > At that point you need to ask the question "do I want
> > better developers or more developers?" > > I've worked in small, medium, large, and very large > development organizations. In all cases, managers vote > for more bodies. It takes education to convince managers that greater productivity, quality and efficiency can be achieved through hiring a smaller number of strong developers. It's not an overnight task, but it is doable. We've had great success in this at my current company. |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: The Next Big JVM Language
September 26, 2010 4:06 PM
|
|
> > > At that point you need to ask the question "do I want
> > > better developers or more developers?" > > > > I've worked in small, medium, large, and very large > > development organizations. In all cases, managers vote > > for more bodies. > > It takes education to convince managers that greater > productivity, quality and efficiency can be achieved > through hiring a smaller number of strong developers. > It's not an overnight task, but it is doable. > We've had > great success in this at my current company. You're very lucky; bureaucracy sets in quickly. Is your current company hiring? :) |
|
Posts: 12 / Nickname: ianr / Registered: April 20, 2007 6:37 AM
Re: The Next Big JVM Language
September 27, 2010 8:16 AM
|
|
> You're very lucky; bureaucracy sets in quickly. Is your
> current company hiring? :) Always :). http://www.overstock.com/careers |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: The Next Big JVM Language
September 27, 2010 8:20 AM
|
|
> > You're very lucky; bureaucracy sets in quickly. Is
> your > > current company hiring? :) > > Always :). http://www.overstock.com/careers touche' |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: The Next Big JVM Language
September 27, 2010 7:09 AM
|
|
> It takes education to convince managers that greater
> productivity, quality and efficiency can be achieved > through hiring a smaller number of strong developers. > It's not an overnight task, but it is doable. We've had > d great success in this at my current company. Are there enough strong developers to go around? Raise the requirement a bit further to very strong and I think the answer is almost certainly no. So perhaps there is a real business case for tools and systems which can be used effectively by mere average developers. |
|
Posts: 12 / Nickname: ianr / Registered: April 20, 2007 6:37 AM
Re: The Next Big JVM Language
September 27, 2010 8:22 AM
|
|
> Are there enough strong developers to go around? Raise the
> requirement a bit further to very strong and I > think the answer is almost certainly no. There's definitely not an overabundance. This might not be a bad thing, though. It keeps us from growing too quickly, and it gives the company an additional incentive to pay close attention to the quality of life for our staff to ensure that we don't loose the developers we already have :). > So perhaps there is a real business case for tools and systems which can be > used effectively by mere average developers. I think there's always a strong business case to be made for better tools, even when talking about very strong developers. The IDE is one such tool, but so is the language you program in. One thing I like about Scala is some of the things it does (such as case classes) to reduce reliance on tools in the first place. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: The Next Big JVM Language
September 27, 2010 8:22 AM
|
|
> Are there enough strong developers to go around? Raise the
> requirement a bit further to very strong and I > think the answer is almost certainly no. So perhaps there > is a real business case for tools and systems which can be > used effectively by mere average developers. I think a static view of developers is incorrect. The mistake I see is that management will take you logic above and decide they only want average developers. This means there is no room for growth. The better developers will have lots of reasons to leave as soon as they have passed the average mark (e.g. money and job satisfaction.) This tends to leave you people who don't really know what they are doing or care to learn i.e. a sub-standard developers. This usual symptoms of this are hiring expensive senior technical people to micromanage the developers. In other words you end up with the same strong developers you decided you didn't want but force them to develop in Word. The upshot is higher cost, lower productivity, and lower quality. I've also seen a lot of confusion about tools that increase productivity and tools that make things easier. These are two different concepts and they are often at odds with each other often they are assumed to go together. It's strange that this is the case because we don't think this way about physical tools. You don't get purchase a backhoe because you think your employees are too dumb to use shovels. This isn't to say that there are not tools (or processes) that both increase productivity and simplify work. These kinds of tools are what cause revolutionary change. But these tend to be the exception, not the rule. As a rule of thumb, if you want to maximize productivity, you will usually have to give up on some simplicity. |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: The Next Big JVM Language
September 27, 2010 9:19 AM
|
|
> This isn't to say that there are not tools (or processes)
> that both increase productivity and simplify work. These > kinds of tools are what cause revolutionary change. But > these tend to be the exception, not the rule. As a rule > of thumb, if you want to maximize productivity, you will > usually have to give up on some simplicity. I argue that the Great Leap Forward is paradigm shift. Some, not all, think that OO was such. Others, not so much; particularly if one looks underneath the covers of major java web frameworks. Not much OO there; in the classic sense of data/method seamlessly embroidered together. See: Graham. Two shifts: the graphics rendering engine and the relational database. No game developer would not use an engine, but many coders ignore the RDBMS in favor of continuing to write file based approaches. The difference: the rendering engine doesn't replace coding with something else (rather it swaps low level syntax with something "higher"), while the RDBMS does. It can also be argued (I sure do) that there was such a revolution in the 80's-90's, and it had a name: 4GL languages (yeah, I know what L stands for). Didn't work out so well. All but a couple (if that many) went away. Coders decided they didn't want to be constrained to the semantic choices of the 4GL authors, by and large. Just look at java web development. I wrote servlets as shown in Hunter's first edition, as did many others. No one does that any longer. Are the web apps any better? Who knows? They aren't written in java, they're written in "Struts" or whatever. You're beholden on the choices made by them. Same for RoR. Same for web frameworks in all other languages. The number of them grows like bedbugs, because some group doesn't like the choices made. These are all code generators, to a first approximation. That level of tool goes back to the 1960's; COBOL (already assumed to be very high level language) code generation was au courant for a long time; still is some places. There's always more boilerplate than meat, it seems. Shouldn't we all be writing assembler or C (the portable assembler)? Where does boilerplate stop and meat start? Yet, the suggestion that code can and should be generated from the data it's supposed to interact with is still heretical (well, unless the input to the generator is some mammoth xml file :) ) most places. This still baffles me. In the end, it's the data which is important to the (human) client, not the code. Moreover, the data will outlast the code; moving mainframe applications (in COBOL or PL/1 mostly) to java on "servers" is a thriving sub-industry. If these applications had been built from the start on a standardized (sql) database engine, swapping the client code from ABC to XYZ is a matter of running the catalog through a different generator. If the goal of "increasing productivity" is eliminating "busy work", "boilerplate code", and such, then why not embrace UML and build our systems from diagrams? And so on. The line between increasing productivity of all developers and job killing for me and mine is ever present. If I had a nickel for every time I argued with my java brethren over whether to put a constraint once in the catalog, or strewn throughout their source files; I'd be rich. And if I'd won, the codebase would be a fraction the size, and agnostic about the language/style/framework/team which built the client. Oops. |
|
Posts: 37 / Nickname: miata71 / Registered: March 29, 2006 6:09 AM
A practical point I think will be important
September 28, 2010 5:11 PM
|
|
I commented about this over at http://www.artima.com/weblogs/viewpost.jsp?thread=306337
I think the "beauty" or "efficiency" of a language, while important, (and fun to debate here) will not be the key for the next big language, especially a functional style graft onto Java or the JVM, like Scala (and others) attempt. The big interest in FP is to take advantage of multiple cores and processors. And the big bang for the buck in cores/$ is in GPU computing. The language that not only adds neat academics love them closures, but also says "I'll take your closure over a Collection and run it on thousands of threads and processors on that $100 GPU card, and I'll even do most of the ugly legwork setting it up" will be the one to beat. |
|
Posts: 7 / Nickname: cbeust / Registered: February 27, 2004 3:21 AM
Re: A practical point I think will be important
September 28, 2010 7:45 PM
|
|
> The big interest in FP is to take advantage of multiple cores and processors.
I keep seeing this claim left and right but I have yet to see some concrete evidence. Has anyone ever attempted to compare a program written in traditional OO and in FP style, then launch it on several cores/machines and compare the results? Immutable collections are usually slower than mutable ones so I'm really beginning to wonder if the claim that FP improves performance in the presence of multiple cores has any substance. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: A practical point I think will be important
September 28, 2010 11:25 PM
|
|
> Immutable collections are usually slower than mutable ones
Unless you have to keep lots of near identical copies. This is quite common in my work (combinatorial optimization). |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
September 28, 2010 7:28 PM
|
|
> The big interest in FP is to take advantage of multiple
> cores and processors. And the big bang for the buck in > cores/$ is in GPU computing. I still wonder how this enthusiasm comports with Amdahl's Law? Outside of servers, how many truly parallel/concurrent problems are there in client/standalone applications? Or will we see applications be invented to fit the multi-core machine, in other words, we just write server code everywhere? |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: A practical point I think will be important
September 28, 2010 11:30 PM
|
|
> > The big interest in FP is to take advantage of multiple
> > cores and processors. And the big bang for the buck in > > cores/$ is in GPU computing. > > I still wonder how this enthusiasm comports with Amdahl's > Law? Outside of servers, how many truly > parallel/concurrent problems are there in > client/standalone applications? My day job is vehicle routing /combinatorial optimization, and one of my hobbies is photography. Both involve some embarassingly parallel problems, and others which scale to at least modest numbers of processors. Currently the heavy lifting in both cases is done on the client machine, although that might change. |
|
Posts: 4 / Nickname: terkans / Registered: January 5, 2005 2:30 AM
Re: A practical point I think will be important
September 29, 2010 2:57 AM
|
|
> I still wonder how this enthusiasm comports with Amdahl's
> Law? Outside of servers, how many truly > parallel/concurrent problems are there in > client/standalone applications? Actually there are lots of parallel tasks in client or standalone applications. You need to keep your UI responsive, so that should have a dedicated thread. Longer running work items started from the UI should run in another thread. Network interaction/downloads should also be on a background threads, as should interaction with local storage (which might very well be networked itself). So even there you get a lot of benefit from immutability and other functional properties to avoid one task corrupting another tasks data. Communication between the thread might be realized through Software Transactional Memory, where updates may be run multiple times if a conflict occurs. That can only be done if your update functions are purely functional (no side-effects). I'm sure there are more benefits that could be listed. The problem here is that these things require a change in how developers think, and making that change is quite a bit harder than changing software itself. |
|
Posts: 98 / Nickname: achilleas / Registered: February 3, 2005 2:57 AM
Re: A practical point I think will be important
September 29, 2010 3:43 AM
|
|
> > I still wonder how this enthusiasm comports with
> Amdahl's > > Law? Outside of servers, how many truly > > parallel/concurrent problems are there in > > client/standalone applications? > > Actually there are lots of parallel tasks in client or > standalone applications. > > You need to keep your UI responsive, so that should have a > dedicated thread. > Longer running work items started from the UI should run > in another thread. > Network interaction/downloads should also be on a > background threads, as should interaction with local > storage (which might very well be networked itself). > > So even there you get a lot of benefit from immutability > and other functional properties to avoid one task > corrupting another tasks data. > > Communication between the thread might be realized through > Software Transactional Memory, where updates may be run > multiple times if a conflict occurs. That can only be done > if your update functions are purely functional (no > side-effects). > > I'm sure there are more benefits that could be listed. > > The problem here is that these things require a change in > how developers think, and making that change is quite a > bit harder than changing software itself. Another way to do concurrency/parallelism is to use the Active Object pattern. This pattern also fits will with object-oriented designs. |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
September 29, 2010 11:17 AM
|
|
> > I still wonder how this enthusiasm comports with
> Amdahl's > > Law? Outside of servers, how many truly > > parallel/concurrent problems are there in > > client/standalone applications? > > Actually there are lots of parallel tasks in client or > standalone applications. > > You need to keep your UI responsive, so that should have a > dedicated thread. > Longer running work items started from the UI should run > in another thread. > Network interaction/downloads should also be on a > background threads, as should interaction with local > storage (which might very well be networked itself). In real life, I don't see that happening with applications. Asking for a download, OK, I'll buy that. But having tasks which are run at the behest of the user, but which the user is indifferent to when the task is completed, not so much. That indifference is key. With servers, each thread is run to satisfy (approximately) a user request, independent of other users; so there's no violation of Amdahl. With a true client/standalone application, either the user is working linearly (it's been found that humans are not all that adept at multi-tasking) in which case s/he'll want to know the result of step A before going on to step B, or s/he's running something like a VB/Access application; printing a G/L report while posting AR. But that's just a server, albeit single user. > > So even there you get a lot of benefit from immutability > and other functional properties to avoid one task > corrupting another tasks data. > > Communication between the thread might be realized through > Software Transactional Memory, where updates may be run > multiple times if a conflict occurs. That can only be done > if your update functions are purely functional (no > side-effects). > > I'm sure there are more benefits that could be listed. > > The problem here is that these things require a change in > how developers think, and making that change is quite a > bit harder than changing software itself. I argue that it's much more about how humans think. Again, we don't really multi-task efficiently. Expecting that we'll all of a sudden multi-task while interacting with applications smacks of Commander Data. Highly parallel/concurrent machines have existed in recent memory (well, for some of us), for not obscene amounts of money, and they failed simply because no one could figure out problems for them to solve. The web doesn't really change that, and the web is the only meaningful change to the world since those machines. Still seems to me to be a solution in search of a problem. The simple way to provide an answer is to sketch how Word would be made better if it were written in an FP. Do that, and people will be convinced. |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
September 29, 2010 11:46 AM
|
|
> The big interest in FP is to take advantage of multiple
> cores and processors. Just to be clear; it's not an advantage. Stable or decreasing clocks (which hasn't quite happened yet, really) on a core are seen as a problem for existing client/standalone apps. They'll just run slower than they used to. The Gates-ian motto "write for the next generation of processor, it'll be fast enough" no longer worked (well, that's been the assumption). It's a lemon that has to be turned into lemonade. Much the same as the birth of the Wintel monopoly: M$ and Intel have been symbiotic (or parasitic, depending on one's point of view), M$ creating ever more bloated software to suck up the cycles that Intel was putting into each new processor. Linux made this quite clear, by not playing that game. So, Intel/AMD/ARM/etc. need to create a class of applications which can suck up all those concurrent cycles; the old way doesn't work. One way, for commercial type applications of course, is to reduce the client machine to a pixelated VT-100 (which is happy with a 6502), and put those fabulous multi-core/processor machines to work as database servers. But that won't move enough units. Hmmm. What we'll likely end up with doing is ignore Amdahl, move to the FP of the month for a while until the java/FP emerges, slice up our inherently linear code (because it serves an inherently linear human brain: see the writings of Nick Carr, for example) into bits and pieces to fit the new hardware. The resulting applications won't be any better or faster, but shinier. At least to the coders, anyway. |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: A practical point I think will be important
September 29, 2010 0:04 PM
|
|
I don't seem to have many inherently linear tasks which are CPU bound and where the time taken on current processors is long enough to notice.
All the slow CPU bound tasks I have are capable of at least some use of concurrency. Some may not scale well beyond perhaps 4 cores, while others easily scale to hundreds. The rest of my slow tasks are either disk or network bound. |
|
Posts: 7 / Nickname: cbeust / Registered: February 27, 2004 3:21 AM
Re: A practical point I think will be important
September 29, 2010 0:04 PM
|
|
> M$ creating ever more bloated software to suck up the cycles that Intel was putting into each new processor.
Do you seriously believe that Microsoft is intentionally bloating their software to force people to keep buying more powerful Intel chips? -- Cédric |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: A practical point I think will be important
September 29, 2010 0:10 PM
|
|
> > M$ creating ever more bloated software to suck up the
> cycles that Intel was putting into each new processor. > > Do you seriously believe that Microsoft is intentionally > bloating their software to force people to keep buying > more powerful Intel chips? > They used to believe that most software was bought with new machines; software that would run on older hardware was more likely to be 'borrowed' rather than paid for. So designing for the net generation of hardware was an early, crude form of copy restriction. I heard this explained by a senior Microsoftee from the the platform at a public conference (mid '90s). |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
September 29, 2010 4:58 PM
|
|
> > M$ creating ever more bloated software to suck up the
> cycles that Intel was putting into each new processor. > > Do you seriously believe that Microsoft is intentionally > bloating their software to force people to keep buying > more powerful Intel chips? > > -- > Cédric Umm. Yes. And I was hardly the first one to see that. |
|
Posts: 7 / Nickname: cbeust / Registered: February 27, 2004 3:21 AM
Re: A practical point I think will be important
September 29, 2010 5:07 PM
|
|
> Umm. Yes. And I was hardly the first one to see that.
You mean you saw the source code and you found sleep loops there or you just like to believe conspiracy theories? -- Cédric |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
September 30, 2010 10:19 AM
|
|
http://www.google.com/url?sa=t&source=web&cd=15&ved=0CB0QFjAEOAo&url=http%3A%2F%2Fpublic.kenan-flagler.unc.edu%2Fcourses%2Fmba%2Fmba260e%2FFontenot_and_Hyman.pdf&rct=j&q=evidence%20wintel%20monopoly&ei=tNOkTP27HIL48Abb6cz4CQ&usg=AFQjCNFXKltDhe1Cq9x7nbl2BhXaKM2Pcg&cad=rja
search for wintel, or just go to page 1213. there are a host of references from there. |
|
Posts: 9 / Nickname: eengbrec / Registered: April 15, 2006 2:07 AM
Re: A practical point I think will be important
September 29, 2010 5:33 PM
|
|
> > > M$ creating ever more bloated software to suck up the
> > cycles that Intel was putting into each new processor. > > > > Do you seriously believe that Microsoft is > intentionally > > bloating their software to force people to keep buying > > more powerful Intel chips? > > > > -- > > Cédric > > Umm. Yes. And I was hardly the first one to see that. Seems to me that if MS was trying to make it's products bloated, they would be a lot more bloated than they are. Bloating is one of those things you have to constantly fight and resist. It doesn't take effort. |
|
Posts: 37 / Nickname: miata71 / Registered: March 29, 2006 6:09 AM
Responding to an earlier comment
September 29, 2010 7:30 PM
|
|
"What I'm trying to say is that we should stick with C++, especially C++0x, and forget about the rest."
Interesting. I programmed a fair bit in C++ last century. Today I did my first serious coding in C++ in this century, writing a class, after years of Java. Wow. Suddenly you have to worry about .h files, #IFDEF, #INCLUDE for the header files, declaring functions, in effect, in two different places (the header and the .cpp file). And if you mess up some closing semicolon or }, the preprocessor goes nuts and you get weird errors in some .h file (the next one) that you haven't even looked at. Not to mention whether to use foo.bar or foo->bar or where to put the * on a declaration. The only thing I liked was the shortcut for ints if (!error) which is handy in chains of lots of function calls that return negative numbers on failures, e.g. int error = call_1();
if (!error)
error = call_2();
...
if (!error)
error = call_N();
return error;
Of course, functions returning funny ints on errors are non-ideal, an exception is better, as well as some form of finally... :-( Not to mention all the *real* faults of C++. Now, maybe C++0x fixes some of this, I don't know much about it. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: Responding to an earlier comment
October 1, 2010 7:29 AM
|
|
> Of course, functions returning funny ints on errors are
> non-ideal, an exception is better, C++ has had exceptions since the ARM days. >as well as some form of > finally... :-( finally is needed in languages that do not have deterministic object destruction. C++ deterministic destructors are a far superior method for cleaning up resources: http://calculist.blogspot.com/2010/06/raii-vs-finally.html |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: Responding to an earlier comment
October 1, 2010 7:49 AM
|
|
> > Of course, functions returning funny ints on errors are
> > non-ideal, an exception is better, > > C++ has had exceptions since the ARM days. But as they weren't used by any of the standard libraries of the day, little was gained from them. There were also implementation restrictions (like not being able to use them in DLLs). |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: Responding to an earlier comment
October 1, 2010 8:04 AM
|
|
> > C++ has had exceptions since the ARM days.
> > But as they weren't used by any of the standard libraries > of the day, little was gained from them. There were also > implementation restrictions (like not being able to use > them in DLLs). You mean you couldn't pass them safely accross dll boundaries? Yep, C++ exceptions have their share of problems (I even wrote an article on that subject: http://www.codeproject.com/KB/cpp/cppexceptionsproetcontra.aspx ), and as with many other C++ features if you don't learn how to use them properly better stay away from them. The point of my post is that many people complain about minor (pointer syntax, etc) or non-existing (finally, lack of GC) problems with C++, while there are a plenty of real ones to bitch about: hard to parse (resulting in fewer and less perfect tools), takes long to compile, has many wrong defaults, etc, etc. Anyway, this is all off topic - I don't think anybody seriously believes C++ is the next big JVM language :) |
|
Posts: 37 / Nickname: miata71 / Registered: March 29, 2006 6:09 AM
Re: Responding to an earlier comment
October 1, 2010 11:03 AM
|
|
> The point of my post is that many people complain about
> minor (pointer syntax, etc) or non-existing (finally, lack > of GC) problems with C++, while there are a plenty of real > ones to bitch about Maybe it didn't come through in my original post, but the things I complained about were intended to be minor, "humorous newbie" nits, cause at the end I said something like "not to mention the real problems..." Agree that C++ is not the next big JVM language! |
|
Posts: 48 / Nickname: mthornton / Registered: October 16, 2005 11:22 PM
Re: A practical point I think will be important
September 29, 2010 11:44 PM
|
|
> Seems to me that if MS was trying to make it's products
> bloated, they would be a lot more bloated than they are. > Bloating is one of those things you have to constantly > y fight and resist. It doesn't take effort. Their view was that fighting bloat wasn't money well spent. So it wasn't a matter of adding bloat deliberately, merely not bothering to fight the natural bloat. |
|
Posts: 128 / Nickname: watson / Registered: September 7, 2005 3:37 AM
Re: A practical point I think will be important
September 30, 2010 8:55 AM
|
|
> Their view was that fighting bloat wasn't money well
> spent. So it wasn't a matter of adding bloat deliberately, > merely not bothering to fight the natural bloat. My understanding is that this changed for Windows 7. After Vista, they realized they couldn't continue that way forever. |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
September 30, 2010 10:20 AM
|
|
> > Seems to me that if MS was trying to make it's products
> > bloated, they would be a lot more bloated than they > are. > > Bloating is one of those things you have to constantly > > y fight and resist. It doesn't take effort. > > Their view was that fighting bloat wasn't money well > spent. So it wasn't a matter of adding bloat deliberately, > merely not bothering to fight the natural bloat. I'll grant the distinction, but maintain, from the Wintel point of view, it makes no difference. |
|
Posts: 37 / Nickname: miata71 / Registered: March 29, 2006 6:09 AM
Re: A practical point I think will be important
September 30, 2010 7:11 PM
|
|
Robert- maybe I missed it in my perusal, but the article you cite has zero information about MS deliberately bloating their SW to help Intel.
Please support your claim. |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
October 1, 2010 11:09 AM
|
|
> Robert- maybe I missed it in my perusal, but the article
> you cite has zero information about MS deliberately > bloating their SW to help Intel. > > Please support your claim. And here's some hard numbers (another minute or 2 of letting my fingers doing the searching, it's not that tough): http://exo-blog.blogspot.com/2007/09/what-intel-giveth-microsoft-taketh-away.html "As I stated in the beginning, the conventional wisdom regarding PC evolution could be summed up in this way: “What Intel giveth, Microsoft taketh away.” The testing I conducted here shows that the wisdom continues to hold true right up through the current generation of Windows Vista + Office 2007. What’s shocking, however, is the way that the IT community as a whole has grown to accept the status quo." |
|
Posts: 37 / Nickname: miata71 / Registered: March 29, 2006 6:09 AM
Re: A practical point I think will be important
October 1, 2010 11:41 AM
|
|
> http://exo-blog.blogspot.com/2007/09/what-intel-giveth-microsoft-taketh-away.html
Thanks, this 3rd article has some stats on things getting slower. Good. (Though I couldn't get his interactive table to work) I'm not sure what they did in Office 2007 to make it so slow. But, until them, for 7 years, things were either stable, or getting slower due to virus issues. "the development team was being sidetracked by a string of security breaches in the Windows XP code base. The resulting fix, Windows XP Service Pack 2, was more of a re-launch than a mere update. Whole sections of the OS core were either replaced or rewritten, and new technologies – like Windows Defender and a revamped firewall – added layers of code to a rapidly bloating platform." So, according to this, it wasn't MS who was plotting with Intel, arguably, it's the Virus and Anti-Virus writers who are. (And I find that fairly believable) Office 2007 made the mess. They did add a lot of new file formats and used XML. And the super-cool GUI I mentioned before. My take-home message is that the continued rampant misuse of XML has ruined programming. I've seen it used to hold binary results data as text, expanding file sizes by more than 100X. It's ironic that we are in a forum discussing future languages that run interpreted on a virtual machine, and likely will do away with primitives and raw arrays to be "pure OO", and discussing raw speed and code bloat. |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
October 1, 2010 0:01 PM
|
|
> >
> http://exo-blog.blogspot.com/2007/09/what-intel-giveth-micr > osoft-taketh-away.html > > Thanks, this 3rd article has some stats on things getting > slower. Good. (Though I couldn't get his interactive > table to work) > > I'm not sure what they did in Office 2007 to make it so > slow. But, until them, for 7 years, things were either > stable, or getting slower due to virus issues. > > "the development team was being sidetracked by a string of > security breaches in the Windows XP code base. The > resulting fix, Windows XP Service Pack 2, was more of a > re-launch than a mere update. Whole sections of the OS > core were either replaced or rewritten, and new > technologies – like Windows Defender and a revamped > firewall – added layers of code to a rapidly bloating > platform." > > > So, according to this, it wasn't MS who was plotting with > Intel, arguably, it's the Virus and Anti-Virus writers who > are. (And I find that fairly believable) Starting with Win95, M$ issued edicts that the new version couldn't be run on current machines; go buy a new one. Memory upgrades, when possible, might allow Win/Office to function, but run substantially slower than the previous versions. Computerworld's archive will have all the history one would need. That Windoze *needs* anti-virus is *not* due to 95% monopoly (or whatever the %-age). That's a bit gas passed by M$ fanboys. The reason is that DOS (which M$ did not write, but stole), and Windoze following, was built to allow applications to fiddle the hardware. The first program to need that ability (and the program, killer app, which made M$ viable) was 1-2-3. DOS was a control program, not an operating system. It was largely a clone of CP/M for the 8086/8. That mindset was built into the foundation of all the M$ folks did, and remains. *nix in general, and linux in particular, is an operating system; applications don't get to fiddle the hardware. linux is parsimonious of memory and cycles. The M$ folk have been backfilling against viruses ever since. You can only patch so much. Vista was supposed to be the blank sheet of paper answer. We all know how well that worked out. > > > Office 2007 made the mess. They did add a lot of new file > formats and used XML. And the super-cool GUI I mentioned > before. My take-home message is that the continued > rampant misuse of XML has ruined programming. I've seen > it used to hold binary results data as text, expanding > file sizes by more than 100X. They didn't use xml, another prevarication out of Redmond. They tried, and sort of got away with it, to subvert xml. I have no use for xml, either. What M$ did was take a simplistic syntax specification, and slip in proprietary binary bits which make their files unusable by any other program. As bad as xml is, having a clear-text (sharable) document is a laudable goal. Not that I would chose xml for that role. > > > It's ironic that we are in a forum discussing future > languages that run interpreted on a virtual machine, and > likely will do away with primitives and raw arrays to be > "pure OO", and discussing raw speed and code bloat. Yeah, how did that happen? :) |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
October 1, 2010 11:03 AM
|
|
> Robert- maybe I missed it in my perusal, but the article
> you cite has zero information about MS deliberately > bloating their SW to help Intel. > > Please support your claim. That article describes the Wintel term. Here's one on the symbiosis: http://news.cnet.com/8301-10787_3-10141326-60.html " Intel built its business model around the need for constantly increasing performance." A reasonable person would see that as "Windoze keeps sucking up more cycles". Here's another: http://www.mayin.org/ajayshah/MEDIA/1998/wintel.html "In order to use PCs, there was no alternative but OSes from Microsoft. Microsoft kept releasing slower software, forcing users to require faster CPUs. As long as Windows worked only on Intel processors, Intel had an interest in supporting Microsoft. As long as non-Microsoft OSes did not run on Intel CPUs, Microsoft had an interest in supporting Intel." About 2 minutes of letting my fingers doing the searching. OTOH, I've been doing this since before there as an IBM/PC, so it's sitting a few centimeters above my lower brain stem. |
|
Posts: 37 / Nickname: miata71 / Registered: March 29, 2006 6:09 AM
Re: A practical point I think will be important
October 1, 2010 11:16 AM
|
|
> http://news.cnet.com/8301-10787_3-10141326-60.html
> > " Intel built its business model around the need for > constantly increasing performance." > > A reasonable person would see that as "Windoze keeps > sucking up more cycles". No. A reasonable person would see that as "apps keep doing more stuff like automatically recompiling on the fly, autoformatting your code, Flash videos instead of simple workable HTML text links, supercool semi-transparent color-gradient GUIs that popup Bing links instead of a rectangular black and white button, downloading from YouTube, tweet your facebook to your android, hmm, even autocompiling to a database schema". These eat cycles. The second article presents no data showing that Windows versions became slower, (which is probably true and easy to obtain) let alone data that Windows was deliberately made slower. |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
October 1, 2010 11:37 AM
|
|
> > http://news.cnet.com/8301-10787_3-10141326-60.html
> > > > " Intel built its business model around the need for > > constantly increasing performance." > > > > A reasonable person would see that as "Windoze keeps > > sucking up more cycles". > > No. A reasonable person would see that as "apps keep > doing more stuff like automatically recompiling on the > fly, autoformatting your code, Flash videos instead of > simple workable HTML text links, supercool > semi-transparent color-gradient GUIs that popup Bing links > instead of a rectangular black and white button, > downloading from YouTube, tweet your facebook to your > android, hmm, even autocompiling to a database schema". > > These eat cycles. > > The second article presents no data showing that Windows > versions became slower, (which is probably true and easy > to obtain) let alone data that Windows was deliberately > made slower. Did you read this part? The net result is that, surprise, Vista + Office 2007 + state of the art hardware delivers throughput that’s nearly on par (~22% slower) with the previous generation of Windows XP + Office 2003 + the previous state of the art hardware. In other words, the hardware gets faster, the code base gets fatter and the user experience, as measured in terms of application response times and overall execution throughput, remains relatively constant. The Great Moore’s Law Compensator is vindicated. |
|
Posts: 7 / Nickname: cbeust / Registered: February 27, 2004 3:21 AM
Re: A practical point I think will be important
October 1, 2010 11:29 AM
|
|
> " Intel built its business model around the need for
> constantly increasing performance." > > A reasonable person would see that as "Windoze keeps > sucking up more cycles". Actually, no, only an unreasonable person would make a logical connection between these two statements. I should have seen this coming when I saw you spell Microsoft "M$" and Windows "Windoze". > Here's another: > > http://www.mayin.org/ajayshah/MEDIA/1998/wintel.html A twelve year old link from a random blogger. Very convincing, indeed. -- Cédric |
|
Posts: 9 / Nickname: roybatty / Registered: September 15, 2003 4:57 PM
Re: A practical point I think will be important
October 3, 2010 10:34 AM
|
|
> > " Intel built its business model around the need for
> > constantly increasing performance." > > > > A reasonable person would see that as "Windoze keeps > > sucking up more cycles". > > Actually, no, only an unreasonable person would make a > logical connection between these two statements. > > I should have seen this coming when I saw you spell > Microsoft "M$" and Windows "Windoze". > > > Here's another: > > > > http://www.mayin.org/ajayshah/MEDIA/1998/wintel.html > > A twelve year old link from a random blogger. Very > convincing, indeed. > > -- > Cédric Yes, the "M$" and the Windoze are the cues that you can't take anything that Robert says seriously. He's a one trick pony that still hasn't waken up from his Slashdweeb coma circa 1999 or so. |
|
Posts: 40 / Nickname: ntrif / Registered: June 30, 2004 1:10 AM
Re: A practical point I think will be important
October 4, 2010 5:35 AM
|
|
>
> Yes, the "M$" and the Windoze are the cues that you can't > take anything that Robert says seriously. > > He's a one trick pony that still hasn't waken up from his > Slashdweeb coma circa 1999 or so. I find it almost amusing. Facebook is getting most heat for being "evil" these days, and before Facebook there was Google. Microsoft is really a "day before yesterday" story - even EU is not after it any more. Just waiting to see some old timer who still hates IBM or DEC :) But in all seriousness, I would really prefer to see Artima discussions keeping on topic and professional. It is probably not possible without some kind of moderation, though. |
|
Posts: 2 / Nickname: andydent / Registered: November 24, 2005 6:04 PM
Re: A practical point I think will be important
October 7, 2010 1:52 PM
|
|
Is there an equivalent in the Linux distro world to requiring much better hardware to just run a similar GUI, to the wearying argument above?
I don't install new Linux systems very often but it seems to me that they have fairly slavishly followed the more shiny UI approach and similarly the hardware demand has increased. That is surely an existence proof against an MS conspiracy? Similarly, OS/X required drastically bigger machines to add its GUI advances. As a cross-platform developer of more than twenty years experience, I have some terrifyingly old Macs that start and run snappily, but the experience looks really flat! |
|
Posts: 35 / Nickname: funbunny / Registered: September 23, 2003 5:08 AM
Re: A practical point I think will be important
October 7, 2010 4:18 PM
|
|
> Is there an equivalent in the Linux distro world to
> requiring much better hardware to just run a similar GUI, > to the wearying argument above? > > I don't install new Linux systems very often but it seems > to me that they have fairly slavishly followed the more > shiny UI approach and similarly the hardware demand > has increased. > > That is surely an existence proof against an MS > conspiracy? > > Similarly, OS/X required drastically bigger machines to > add its GUI advances. As a cross-platform developer of > more than twenty years experience, I have some > terrifyingly old Macs that start and run snappily, but the > experience looks really flat! Not even remotely true. Yes, if you take the default Gnome or KDE they are a bit shiny. OTOH, I went from ubuntu 8.10 to 10.04, and the latest Gnome is snappier than the previous, on the same machine, of course. Moreover, if you don't like Gnome or KDE, any number of window managers are available, including fvwm, which has been around since the early 1990's and was what I used when I installed Slackware back then. Do the boys from Redmond offer such? |
|
Posts: 5 / Nickname: fredgarvin / Registered: January 4, 2008 3:43 PM
Re: A practical point I think will be important
November 15, 2010 10:16 AM
|
|
Perhaps Gosu is the next Big JVM Language?
http://gosu-lang.org - Syntax is similar enough to Java - Far simpler than Scala (Java programmers will have no trouble transitioning) - Wide range of modern features (properties, closures, composition, type inference, type enhancements, etc.) - The type system is apparently open (!) they're going to deliver XML types etc. (they have a Dynamic type example that seems too good to be true) - Advanced IDE support with their Eclipse plugin, and they bundled a script editor that is quite capable - They claim the language is already being used by multi-billion dollar companies Seems to have all the ingredients. |
|
Posts: 1 / Nickname: mbrylant / Registered: June 8, 2011 6:16 PM
Re: The Next Big JVM Language
June 8, 2011 11:21 PM
|
|
>> Groovy has a distinct niche with its ability to fill in Java's need for a scripting language. Groovy will have a role in build scripts, particularly with Gradle. It will perhaps have an important role in web apps as well.
Can not agree that scripting is a primarily application of groovy. Many, including myself and my team, choose groovy over java because of its conciseness and productivity gains. The kind of of apps you can build with groovy is pretty much everything you can build with Java SE/EE. |
|
Posts: 1 / Nickname: samsulla / Registered: September 24, 2011 5:32 AM
Re: The Next Big JVM Language
September 24, 2011 10:36 AM
|
|
cala advocates don't like to hear that Scala is too complicated, but it's a fact that this perception is widespread.On the other hand, the CLR has arguably got a few decisions "more correct" than the JVM:
|