Op dinsdag 14 juni 2011 22:17:42 UTC+2 schreef phil swenson het volgende:
>
> so what do you think would trigger the next language to become
> ubiquitous (a successful java.next)?
>
>
>
Well, that's the million dollar question, isn't it?
I'm fairly sure that java.next needs to have something compelling. A
relatively small evolutionary step is not going to do the trick. If the C to
java exodus is any indication, we should NOT actually be looking at language
features / syntax, interestingly enough. What java had to offer at the
language level was virtually nothing. It was explicitly designed to be like
C, warts and all (that's the only explanation for postfix array brackets and
the switch statement), but it did offer things C just couldn't offer at the
time: Garbage Collection, a far more complete (and far more standard)
standard library, write once run anywhere, and the promise of sandboxing
(which I admit never quite panned out, but the promise was there). None of
these things are language syntax related.
So then the question becomes: What features are compelling that java does
not have? It also suggests that java.next may not actually run on the JVM,
as many of the limitations in this 'features, not syntax' dimension are
caused by the VM and not java-the-language, but what's left. I can't think
of all that many things:
- Modularization (in all dimensions), built right into the language. A mix
of OSGi (runtime modularization) and ivy/maven (build-time modularization),
coupled with *NO* standard library (everything is a module available on the
web, including the core libraries), and a central (per machine) distributed
module management system, the upshot of which is: Type "import
com.google.guava.*;" into any source file and your IDE / compiler / whatever
tool you're using will 'just work', because is offloads the duty of figuring
out what that means and what must be downloaded to make it work to that
central module management system. This could be pretty compelling. Comparing
such a thing to kludging it together with maven and OSGi in vanilla java is
like java's GC vs. ref-counting kludges in C.
- A fully pluggable compiler. A regex library would simply ship at least a
syntax checker + compile-time path builder, and perhaps even, if the idea of
a n IDE is fully embraced, a regex editing widget, in addition to the code
used at runtime to actually execute the regex. This is an alternate and IMO
far more powerful take on the 'scalable language' concept of scala, which
tries to accomplish this by effectively letting a library author make just
about any stream of characters one can write technically legal scala.
- Some sort of built-from-the-ground-up-for-massively-multicore model which
looks almost nothing like java. However, this feature is highly unlikely to
work well with a java/C-esque syntax (I guess you could have loops
parallel-by-default, but that's not all that interesting), and I'm not sure
this is actually all that compelling. Even on a 128-core machine, getting
more than a real-life ~20x speedup by having your app 'magically' be
multicore ready is highly unlikely (memory reads cross-core slow down any
attempt at fine-grained parallelism, most apps run so fast that they feel
instant anyway, 20x speedup or no, and the majority of speed-sensitive apps
are trivially parallelised in the large, such as a web server. There may
also be other bottlenecks such as a lock on a db table). I very much doubt a
potential future java.next can bank on this one. Maybe by inflating this
issue they could run a decent PR campaign but it would be a bad reason for
the programming world to switch.
- Yes, no doubt this new language will have some form of code blocks
('closures') and perhaps other nice-to-haves such as list comprehensions, as
a second generation that goes 'lets introduce new features and keep the
syntax near 100% equal to java/C' is a bit much, but I doubt this part is
what will compel a massive switch. It'll mostly serve to shut down
naysayers.
That's a relatively small list, much smaller than what java had to offer.
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/javaposse/-/2DkMRLdMLHUJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
