Summary
In a recent blog post, Steve Yegge writes that the next dominant programming language, or the Next Big Language (NBL), may already be here, it just that not all of us recognize it yet. Yegge gives a few hints about what features this language has that make it the NBL.
Advertisement
As the saying goes, the future may already be here, only it's not evenly distributed. Or it may be staring us in the eye, we just fail to recognize it. Steve Yegge seems to think that the Next Big Programming Language, or NBL, is already here, ready to emerge as the next language that everyone will want to—and have to—learn.
In a recent blog post, The Next Big Language, Yegge points out that a language does not have to be beautiful, or even concise, to become popular, noting that "the features I've outlined are basically the minimal set of requirements for not sucking:"
Beauty is one of the obstacles to adoption... If your goal... is to design a language that meets your own personal sense of aesthetics, then you're an artist, and I salute you. For my part, I'm looking for the middle ground between hard-nosed I-don't-care pragmatism... and idealistic better-world optimism. And I think a lot of other people are too...
NBL isn't about winning beauty contests... I'm not claiming that NBL is a great language; I'm just saying it doesn't suck. In practice it's actually quite good, and it will be very, very popular...
Instead, Yegge points to the following characteristics a language must have in order to become the NBL:
C-like syntax C(++)-like syntax is the standard. Your language's popularity will fall off as a direct function of how far you deviate from it.
Dynamic typing with optional static types
When you make a static language, you will be forced to add dynamism to it, because otherwise it's like programming in a straitjacket... The other way to design a language is to make it dynamic, and then you'll be forced to add static checks in later...
Adding in optional static types is the ideal solution. It helps with performance, it helps with code reliability and (possibly) readability, it helps IDEs navigate your code, and most importantly, it helps combat the incredible FUD that dynamic languages inspire in people who come from static backgrounds.
Performance NBL will perform about as well as Java. That means if it's one of the big existing dynamic languages out there, something major is going to have to happen with performance.
It turns out that eval() is one of the key things that gets in the way of performance optimizations. It can easily invalidate all sorts of otherwise reasonable assumptions about variable bindings, stack addresses and so on. It's also pretty important, so you can't just get rid of it... So NBL will have to do something clever about eval.
Tools NBL will have great tools. They might not be Java-great on Day One of NBL's reign, but they'll be a lot better than the options available for Perl/Python/Ruby/Tcl and the rest of the popular dynamic languages out there today.
Multi-Platform NBL will run, at a minimum, both standalone and on the JVM. I'm not sure about plans for .NET, but it seems like that will have to happen as well... And there are two other platforms that NBL will run on which, more than anything else, are responsible for its upcoming dominance...
Yegge also lists a series of language features that NBL has to have in order to become the NBL, such as object-literal syntax for arrays and hashes, intelligent collection operators, Perl 5-compatible regular expressions, function literals and first-class closures, and standard OOP with classes, instances, interfaces, and polymorphism. Yegge also includes a cross-platform GUI as a requirement.
Can you guess what language Yegge is talking about?
Can you guess what language Yegge is talking about?
He's talking about some future version of ECMAScript, which isn't surpising considering he works at Google. You can expect Google to start using Flash more and more once WPF/E gets some penetration. It's obviously all about the browser from the Google perspective.
Now if I'm right and he is talking about ECMAScript, I find it pretty amusing because Adobe seems to want to make ECMAScript more and more Java-like. Are we talking devolution here?
In any case, I don't think the NBL speculation is particularly interesting, except for everybody to pull for their favorite language. It seems to be more about VMs and portable bytecode these days.
D covers most of his article's requirements. Tools it is a bit weak but there is type inference, a gnu frontend, C syntax, very powerful mixin and template system, delegates, etc.
The only language I know of which meets his criteria is Groovy, but its not en-vogue so that can't be it.
I wrote a web framework using groovy and it was simply a pleasure to use-definitely on par with the feeling I get using python.
I expect more of a continuation of new techniques or patterns.
A multiplatform language?
How about the platform is the language?
I used to program in C++, then Java, then web applications with C#, and currently web applications with VB.NET.
C# and VB.NET are somewhat different, but there was no big deal in passing from one language to the other because it's the same libraries behind. It does not make much difference using an ArrayList, for example, in C# or VB.
Traditionnaly, my biggest hurdle in changing from one language to the next has been more about learning the libraries or standard practices than the language itself.
So I find it quite practical that I can use the same libraries or set of tools using one language or the other and it makes almost no difference. You can even use a framework developped in VB (Like DotNetNuke), and extent it in C#. My C# class can have a VB base class or vice-versa.
I expect the same can be done (or is already been done) with the JVM. You can have different languages all running on the JVM and you can use the same basic libraries.
I'm not saying all languages are the same, but it's damn convenient to be able to use the same libraries accross languages.
Once you're using a language that you like, you can focus on the techniques, like unit tests or agile development or what-have-you, and these techniques can propagate accross the different languages anyhow.
When I got into Java, I learned about unit tests. Later I went to C#, and I found there were unit test frameworks for it too.
Same thing with refactoring. I discovered refactoring using IntelliJ IDEA and Eclipse (And I know know refactoring is even older than that). I went to visual studio, suffered withdrawal, then installed ReSharper, a refactoring add-in. And voila, refactoring continues.
Over time there might be migratory movement from one language to another, but is it really important?
Maybe the NBL is nothing more than a language that will be more popular for a while.
This isn't an exercise in predicting the future. It's just a selective list of some current trends. To borrow a phrase used against similar exercises elsewhere, he's "predicting the present".
(I posted the following comment to Steve's blog, as well, and most of it is in response to that blog)
Personally, I'm waiting for a more fundamental change: A language-generating language (or meta-language, if you will) - something like "Intentional Programming" (http://www.intentsoft.com), where new abstractions can be added to a language, and the code itself can be rendered in a multiple representations, text being only one of them (with selectable formatting - an end to the "style wars"!).
In the mean time, I'm not terribly excited about yet another C-type language, and that also goes for much else that is apparently considered "cool" today, such as Java, C#, Python, Perl and Ruby. Even with cool new stuff like lambda, closures, coroutines, and what-have-you.
Thinking about features and abstractions can be useful in itself, but we shouldn't stop there. We need to see much farther than this - beyond syntax, individual languages, features and abstractions.
We also need to be able to work on a much higher level of abstraction. The idea of "Intentional Programming" is to create one or more DSLs that allows you to design the system more or less directly in the application domain.
I also take objection to that C++ is a bad or ugly language. As far as I'm concerned, it's one of the best languages we have (and, yes, pretty. These things are very subjective). Before you object, be aware that deciding what is "best" depends on a lot of factors, but let me list a couple of important ones for me:
1) Large user base, and consequently a large body of knowledge, books, libraries, job opportunities, and so on.
2) It doesn't remove features that "can be misused", because it's more important that they are available for the situations where they _are_ useful (such as multiple inheritance, operator overloading, and so on).
If you make a moron-proof language, you'll likely end up with only morons using it.
3) Facilities for resource management (such as RAII and smart pointers), beyond the one-size-fits-all garbage collection way (which can also be used, with a library).
If you think you need garbage collection for a system, you may not have thought deeply enough about ownership issues. Note that GC only handles memory allocation, no other resources, and it doesn't handle lifetime management at all.
First of all, I strongly believe that Java will not be replaced by another language. Also, I dont believe that there will be "the one" Next big Language. Instad, will see several JVM based Languages,which will be strong in particular fields.
The language choice will depend from the individual project: requirements, team size, budget, time shedule, etc. etc. There will never be a perfect language, which can fit in every possible situation.
Also there will never be developers, who will choose the best language for every case (even if they are allowed to). Because languages will always be a matter of taste.
I will now mention some languages, which [Im using] / [will be using] / [will maybe using after further evaluations] to solve problems. the following list is my "personal" language mix:
1) Java as (rather) low-level, highly efficient language, required to implement complex and highly optimized imperative algorithms
3) JRuby and Groovy for glue and businesscode in small size projects, without too complex businesslogic. Maintaining complex and frequently changing code in a dynamic language is no fun.
4) Scala for glue and businesscode in midsize and complex usecases. Because Scala is a static infered and functional JVM Language, supports Native XML, supports Mixins, functional parameters (like closusres / blocks), you can write DomainSpecLanguages easily, is highly concurrent and much more (http://www.scala-lang.org/)
- The next big language will depart from C syntax, but its syntax will be simple, intuitive and consistent.
- The next big language will have a small and highly capable core, with 99% of functionality accomplished by libraries.
- The NBL will come with a huge library that will do everything you want (pretty much no need for 3rd party libraries).
- The NBL will be free software/open source in its entirety: libraries, core, tooling
- The NBL will be platform neutral, but will integrate nicely and have some small amount of "native" doodads.
- The NBL will either by dynamic or static with inferred types. I don't see optional typing as a good solution. Every time something is made optional it also becomes inconsistent in practical use (a necessary side-effect of "optional nature" of it)
- The NBL will run equally well in stand alone mode and as an extension language. Small and elegant core will take care of that.
- The NBL will be at least as fast as Java (which is pretty fast today).
- The NBL will have great tools.
- The NBL will have first-class database library (like JDBC in Java or better).
- The NBL will allow one to build slick distributables for all platforms (unlike Java/Python/Ruby/Your favorite language other than C/C++, which is a little ugly when it comes to making distributables)
- The NBL will have clean and easy to understand internals. Because its internals are clean, simple and easy to understand, it will always be small and elegant, well developed and in tip-top shape. This goal will be in harmony with free software/open source nature of NBL.
The general flavor will be a highly capable and practical language that supports the same level of abstraction as Scheme or better, with the small core (also like Scheme) but with many other qualities that Scheme lacks, such as well defined IO, huge standard library that does everything (like Java), great tools (like Java), etc. Maybe even better syntax than Scheme, although program as data syntax is seductive. Most definitely it will not have the ugly syntax of ocaml.
> First of all, I strongly believe that Java will not be > replaced by another language. > Also, I dont believe that there will be "the one" Next big > Language. Instad, will see several JVM based > Languages,which will be strong in particular fields. > > The language choice will depend from the individual > project: requirements, team size, budget, time shedule, > etc. etc. There will never be a perfect language, which > can fit in every possible situation. > > Also there will never be developers, who will choose the > best language for every case (even if they are allowed > to). Because languages will always be a matter of taste. > > I will now mention some languages, which [Im using] / > [will be using] / [will maybe using after further > evaluations] to solve problems. the following list is my > "personal" language mix: > > 1) Java as (rather) low-level, highly efficient language, > required to implement complex and highly optimized > imperative algorithms > > 2) F3 for Swing > (http://blogs.sun.com/chrisoliver/resource/f3.html) > > 3) JRuby and Groovy for glue and businesscode in small > size projects, without too complex businesslogic. > Maintaining complex and frequently changing code in a > dynamic language is no fun. > > 4) Scala for glue and businesscode in midsize and complex > usecases. Because Scala is a static infered and functional > JVM Language, supports Native XML, supports Mixins, > functional parameters (like closusres / blocks), you can > write DomainSpecLanguages easily, is highly concurrent and > much more (http://www.scala-lang.org/) > > cheers, > Andreas
The same thing for .NET, but .NET is ahead in relevant languages.
It seems to follow many of the principles I mentioned for NBL.
The trouble with languages like Io is that they are not geared to provide a rich library, and other creature comforts. When I say "not geared" I don't mean there is some technical impediment. I mean the community doesn't seem interested. Want mod_io? It's on some weird website. Want something else? Again you have to find it in some strange place. I don't like that kind of stuff. Development can be decentralized, but not the resource acquisition. I don't want to browse the whole network to find some library.
I nice example of centralized-decentralized library support is Perl's CPAN. So if your language can't be like Java and just give it all to you, then at least it should have something like CPAN.
> 1) Java as (rather) low-level, highly efficient language,
Riiiight. Look if you need efficiency - use C. Java has so much overhead it totally does not scale down.
> Maintaining complex and frequently changing code in a > dynamic language is no fun.
This is no fun generally, but I find it more fun than in the static calicified languages. I mean - dude - dynamic implies motion - static implies the lack of - ya know?
> > - The NBL will come with a huge library that will do > everything you want (pretty much no need for 3rd party > libraries).
Creating a huge standard library from scratch will also prove to be a huge barrier-to-entry for any new language. and any budding NBL will have to grapple with this problem. One solution is to allow language interoperability and wrap some of the existing libraries written in another language such as Java. Achieving this while, at the same time, departing significantly from C language syntax/semantics would require quite a bit of work. Work which requires: financing.
The two current major players (Microsoft, Sun) would appear to have no reason to finance any NBL, being too busy promoting their current best language. And therefore, I'd like to add another feature that I feel the NBL would have to (unfortunately) have: backing from major players with vested interests in its success. The merits of the language itself may prove to be comparatively immaterial.
Nuwan, you pretty much hit the nail on the head. It's just a different ballgame these days than it was twenty years ago. Twenty years ago you could have a relatively small team that could bang out a new language with a library that wasn't expected to be gargantuan and all-encompassing.
So do you deal with the limitations that the CLR or JVM and the interop in those systems imposes on you, and just go ahead and develop a language to play nicely in those systems. Or does some group(s) have the resources to bite the bullet, start afresh, and develop a whole new system to compete with .NET and Java.
Frankly, I'm not optimistic about the latter. It's a herculean effort with dubious payoffs. I'm not a VM expert, but it seems that .NET and the JVM just aren't conducive to languages that don't fit into their respective models - especially when it comes to interop. Straight C libraries still seem to be the most flexible when it comes to leverage.
> This is no fun generally, but I find it more fun than in > the static calicified languages. I mean - dude - dynamic > implies motion - static implies the lack of - ya know?
Careful with terminology here. What do we mean by 'dynamic language'? Are we talking about dynamic typing, or some other indefinable sexiness? Just because a language is statically typed doesn't mean it has to be a calcified language. Just because a language is dynamically typed doesn't mean it's more fun if the price you have to pay is getting bogged down in more runtime/unit testing. There's a danger that we shake off the shackles of Java only to rush headlong over a cliff shouting the new mantra.
Flat View: This topic has 63 replies
on 5 pages
[
12345
|
»
]
Previous Topic
