Dick Ford
Posts: 149
Nickname: roybatty
Registered: Sep, 2003
|
|
Re: Steve Yegge: What the Next Big Language Will Be
|
Posted: Feb 15, 2007 12:30 PM
|
|
> > I'm not sure what you mean by "isn't going to cut it" > > except for a post of yours referring to the JVM having > > poor integration with the OS - which I still don't > > understand. Do you mean Java (the language) not having > > something like C#'s pinvoke? > > I don't want to go into depth but one of the biggest > complaints about the JVM is that it only allows for a > subset of what an OS allows. A good example is how > difficult it is to write an interactive text based > application (e.g. vi) with Java. You have to add native > libraries which generally means compiling them. This > means you either don't do these things or you lose some of > the benefits of a generic VM. >
Are you sure that you don't mean the class libraries and not the VM. One of my criticisms of Java is that it doesn't have something like pinvoke. I want to be able to leverage native libraries and don't expect the standard class libraries to have everything under the sun.
> What I was suggesting is that instead of a new language > being the big thing, a new VM spec that was supported > almost universally so that languages don't have to be > targeted at the OS (or proprietary VMs) anymore. If this > spec was really well done, it might not even have to be > virtual. It could be natively supported in future > systems. >
I'm still not sure exactly what you're writing about. Are you talking about something that would be integrated into the OS itself? Or maybe something along the lines of http://lambda-the-ultimate.org/node/2021 is what you're referring to. > > Now there are limitations to what is reasonably > > implementable within the confines of the runtime you > are > > targetting. For example, some Smalltalk > implementations > > use self-modifying code to do their magic, would be > hard > > (or impossible) to do within the confines of the CLR or > > JVM. > > But that's a limitation of those standards not of machine > instruction sets in general. >
A big part of that is limitations imposed by the security model and also dealing with Java/C# style OO syntax.
> > But I'm not sure what you mean by standardization. It > > would be nice if there was some hypothetical, > > uber-flexible VM out there that could accommodate any > > language under the sun, but obviously there are > trade-offs > > that are made. > > I guess where I am coming from is that every machine has > an instruction set and every language compiles to an > instruction set. A big thing now is virtualization. It > seems more elegant and more effective to instead target > compilation at a standard instruction set. Then similar > to CLI and JVM, you can virtualize this instruction set > once on each platform and probably in the future address > it at a native level. > > I'm not sure it would eliminate the need for non-standard > instruction sets but it would definitely simplify language > selection and application delivery. >
Nobody is ever going to agree on some universal bytecode. Hell, a lot of people don't even see the point of compiling to bytecode.
> > Unfortunately, there seems to be a tendency in IT > forums > > of making statements that are presented to be some > > broad-sweeping consensus, but in reality are only > > applicable to someone's limited environment. > > Are they presented that way or is it that you are choosing > to interpret it that way. >
Fanboyism is rampant and they're are definitely presented in that way. > > The main thing is that until it becomes truly > standard > > across the majority of operating systems it's not > meeting > > the goal of a single standard to compile to. > > This is a tautology. I'm not sure what there is to say > about it. If CLI isn't (virtually) universally supported, > it doesn't meet the goal I have stated. It's actually the > odd platforms that need this kind of thing the most. > > > That may change but it's not even visible on the > > horizon at this point. > > Are there plans to support Mono on platforms like OS390, > OS400, zOS? If not then I stand by this statement. >
Mono is "supported" on the OS390 or at least runs on OS390. But the problem is that you are never going to have a runtime supported on every platform. Now in theory, Mono could be supported on almost every modern platform and if you want to pay Novell, they'll do the port to OS400 and zOS, but universally supported on every platform isn't reasonable. > > So maybe I misread the context in which you were making > > those statements, and if so then I apologize, but I > think > > it's good to be clear that one is referring to the > domain > > that they operate in. > > I think it's good not to assume things about what others > write or say. Blast first, ask questions later seems like > a poor strategy for reasoned discussions.
I'll probably continue to blast first at what I consider blatant fanboyism, but in your case I probably should have read your comments more closely within the context of your requirements.
But I still think it's unreasonable to call for some universally-supported platform. You're never going to have everyone agree on something like that, and if you're willing to pony up, then you can have Mono or Java or anything else ported to what you consider critical platforms.
|
|