|
|
Re: Sun's JRuby Move
|
Posted: Sep 13, 2006 4:31 PM
|
|
> > Well, by momentum I meant ecosystem momentum. Because a
> > lot of people are involved in Java right now
>
> And yet - a lot of luminaries are moving on. Like Bruce
> Eckel.
>
Bruce writes books, not code. I'm talking about people like Terrence Parr, who writes ANTLR in Java, or Doug Cutting, who wrote Lucene in Java, or IBM and Sun and IntelliJ, who have poured money into creating nice IDEs for Java, IBM and Sun and BEA, who have poured money into optimizing runtimes for Java. To me, the most compelling reason to use Java is that, its ecosystem.
Although, I'm wrong about that. Bruce is actually a good example, because books are part of the ecosystem. Even though Bruce really loves programming in Python, he's spent most of his time that past few years updating Thinking in Java. That adds value to the Java ecosystem, and he did it because of the momentum of the Java ecosystem. It was a business decision based on his perception that he'll get the best return from investing in his Java book at that time. (I can't say what books he'll be working on in the future, but this was recent past he was still doing the Java book.)
> > > I mean, why is there int? You don't need it. Make it
> an object and
> > let me extend it.
>
> > The reason there's an int, as I understand
> > it, is for runtime performance.
>
> False God. I have a GIGA Hz machine on my lap just now.
> When I started in this game 8MHz was wicked fast. So
> o this is over a HUNDRED times faster and you mean to tell
> me the cost of the extra bit shift on add matters?
>
> In the 70's they figured out how to have unlimited
> precision arithmetic using objects through and through by
> cleverly bit tagging ints in the VM and doing a tiny bit
> of extra work. The Smalltalk VM cheats in very subtle
> ways with 16 special classes- and I can still add methods
> to int. In the 90's this knowledge was thrown aside to do
> the naive thing and make all of our lives more
> complicated.
>
Well I think it matters sometimes, but not most of the time. The usual thing is that 80% to 90% of a program's time is spent in 10% to 20% of the code. So certainly for that non-critical 80% or 90% of your code, you really don't need that speed. But for the 10% to 20%, you just might. It depends on the situation.
I think that this usual 80/20 split for performance critical code is another justification for the liquid center, hard outside approach of which you speak. It would be nice if you could use whatever technique or language helps you maximize productivity for the 80% of code that doesn't matter to performance. One way to do that is to write the whole thing in a dynamic language, then run it. If there's a performance problem, profile it, identify slow spots, and replace them with static code that is more amenable to optimization.
I think the question is really about cost. It costs money to pay programmers to write programs, and it costs money to buy and manage sytems to run programs. Sometimes it will be cheaper to buy and manage more systems. Sometimes it will be cheaper to spend more money on programming.
> > They do not scale.
> > >
> > Could you elaborate on the actual problems with scaling
> > these architectures?
>
> Rigidty has quite a bit to do with it. We shoot for zero
> downtime. Tricky if you've got a big rigid system that
> has to be fully verified/type checked at build time.
> Loose coupling is VERY important. A site like my
> y employers requires massive parallelism to do its thing
> and we really do require maximum performance code.
>
Could you elaborate on that one? I'm asking because I'd really like to understand the difference.
If I'm building a scalable architecture, then surely I'll have multiple servers serving up the same application. Can't I design it such that I upgrade one batch of servers while the other batch is running the application, then tell the load balancer to send new requests to the new batch, and finish old requests to the old one? Once the old requests have all finished, I can upgrade the other batch of servers?
Is what you're saying that it is easier with a non-compiled language because you can just replace a source file on the deployment machine, and it gets used (interpretted) the next time someone hits that area of the code?
> > I haven't seen it a dozen times. Which good long lived
> > apps are built this way? Can you elaborate with some
> > examples?
>
> Really? So people aren't embedding Groovy/Beanshell in
> their Java apps?
>
I'm sure they are. I just haven't seen it. I was just asking because I'd like to know some examples, so thanks for those. I'll continue thinking about these tradeoffs. My main reason for using Java is the ecosystem, which is just wonderful. But I want more productivity and more fun, so I'm still trying to figure out how to get that.
|
|
Previous Topic
