 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2006A language-agnostic language
An unGooglable. Reading recent Eclipse posts, and hearing the contention between those using Java 1.4 and 1.5, let alone between Java and C++, I'd have thought that we'd have, by now, another layer of source code, beneath that which we construct in our editors, yet above any machine-executable. It shouldn't be impossible define an object-oriented language entirely in XML (for example). Thus, when your favourite editor opens a source code file, it could ask how you want this XML language human-interpretted (as opposed to machine-interpretted). You could, for example, have the editor display the code as Java. You'd then edit and update the code as Java, and compile it, and run the byte-code. Then later, a C++-fanatic colleague, could open the same XML file, but chose to view it as C++. The editor would take care of the translation (actually, "Translation," is a better word that, "Interpretted"), and present the code to him as pure C++, which he can then edit and update as C++, and he could think he's running and executing the native code, though the editor (having previously been configured so) would actually compile to byte code and run in a JVM (or vice-versa, a Javaer could update Java code which is then compiled to native from the ensuing XML). But that's not important to our C++er, he just wants to edit the code and run the results, and that's what he sees. Yes, there'd be library issues. Of course, java.util doesn't exist in C++; but there's no reason why an intelligent translation-editor couldn't be told the C++ library equivalents, so that they appear as normal to a Javaer. An specifically, there's no translation that couldn't be fully specified in XML. Essentially: your choice of source-code need not limit that of others working on the same code. Does anyone know if such an experiment/undertaking/instanity has been investigated? .ed (listening to Coldplay's, "Yellow") -- www.EdmundKirwan.com - Home of The Fractal Class Composition This is somewhat similar yo .NET, in which several langauges (C#, VB.NET, managed C++, J#, etc.) are compiled into the same intermediate language (MSIL), and could in principle be decompiled into a different language than the original source. In practice, of course, it's somewhat trickier than that, since not all languages provide the same set of types and constructs. For example, what happens when your C++ buddy uses destructors, operation overloading, automatic objects, unions, etc. and now you want to display his code as Java? > This is somewhat similar yo .NET, in which several langauges (C#, VB.NET, > managed C++, J#, etc.) are compiled into the same intermediate language Someone once described the .NET MSIL as the world's first skinnable language. Technically that's not quite true (as you noted), but it's a good picture of what's inadequate about the idea of plugging different surface syntaxes onto the same semantics -- you /still/ have only the one semantics, and so you /still/ can only express things in one way, so having a choice of syntax doesn't actually buy you anything. Consider the mess that MS have inflicted on ECMAScript for instance. It doesn't and shouldn't have classes or protection, but because bloody .NET has these things, and is limited to working in those terms, they ended up grafted onto JScript. -- chris Chris Uppal sez: >> This is somewhat similar yo .NET, in which several langauges (C#, VB.NET, >> managed C++, J#, etc.) are compiled into the same intermediate language > > Someone once described the .NET MSIL as the world's first skinnable language. Someone must have a very short memory span: ISTR several msdos compiler products back in the nineties that compiled different languages into the same intermediate language first. TopSpeed was one. I suspect Borland does that with Delphi/C++ Builder, too. There is, of course, any number of products that generate code (in various languages) from UML class diagrams or SQL DDL statements from ERDs. In other news, water was recently found to be wet. Dima  SignatureQ276304 - Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords -- RISKS 21.37 > Chris Uppal sez: >> [quoted text clipped - 9 lines] > same intermediate language first. TopSpeed was one. I suspect Borland > does that with Delphi/C++ Builder, too. There was a time at which many of the popular VMS language compilers shared a back-end, so there's a sense in which they shared a common intermediate representation (though it wasn't a language per se.) But .NET is also designed such that the MSIL-based languages are interoperable and share a common class library. That's not true of your other examples, so far as I know. (Actually, it was largely true of VMS, but with VAX assembler in the place of an IL.) Mike Schilling sez: >> Chris Uppal sez: >>> [quoted text clipped - 17 lines] > know. (Actually, it was largely true of VMS, but with VAX assembler in the > place of an IL.) It is true of Borland's products: Deplhi and C++ Builder share a common class library and are interoperable. Or they were back when I last used them. Common representation is presumably happening at object code level. They had to add a bunch of keywords to C++ to make things compatible at high level, and I strongly doubt things like templates are supported by Object Pascal front-end, so they aren't 100% interoperable. Dima SignatureI have not been able to think of any way of describing Perl to [person] "Hello, blind man? This is color." -- DPM Mike Schilling schrieb: > This is somewhat similar yo .NET, in which several langauges (C#, VB.NET, > managed C++, J#, etc.) are compiled into the same intermediate language > (MSIL), What's the difference to the JVM? The following is a list of programming languages for the Java virtual machine aside of Java itself: http://www.robert-tolksdorf.de/vmlanguages.html There are even products that translate MSIL into standard java byte code. > and could in principle be decompiled into a different language than > the original source. In practice, of course, it's somewhat trickier than > that, since not all languages provide the same set of types and constructs. > For example, what happens when your C++ buddy uses destructors, operation > overloading, automatic objects, unions, etc. and now you want to display his > code as Java? I doubt that it has any practical value. Timo > Mike Schilling schrieb: >> This is somewhat similar yo .NET, in which several langauges (C#, VB.NET, >> managed C++, J#, etc.) are compiled into the same intermediate language >> (MSIL), > > What's the difference to the JVM? That 90% (at least) of code run by JVMs is compiled Java, and you've never see changes made to the JVM standard to support any other languages, where VB.NET and C# are (roughly) equally popular, and MSIL was explicitly designed to support both of them as well as C++. Mike Schilling schrieb: >> Mike Schilling schrieb: >>> This is somewhat similar yo .NET, in which several langauges (C#, VB.NET, [quoted text clipped - 4 lines] > That 90% (at least) of code run by JVMs is compiled Java, and you've never > see changes made to the JVM standard to support any other languages Yes, the JVM is java-centric. It would be very nice to see some support for other languages. Maybe sun is afraid of other languages taking over :) Timo Timo Stamm sez: > Mike Schilling schrieb: >> This is somewhat similar yo .NET, in which several langauges (C#, VB.NET, [quoted text clipped - 7 lines] > > I doubt that it has any practical value. Which part: destructors and overloaded operators, or decompiling them into Java? Dima SignatureQ276304 - Error Message: Your Password Must Be at Least 18770 Characters and Cannot Repeat Any of Your Previous 30689 Passwords -- RISKS 21.37 Dimitri Maziuk schrieb: > Timo Stamm sez: >> Mike Schilling schrieb: [quoted text clipped - 10 lines] > Which part: destructors and overloaded operators, or decompiling them > into Java? Decompiling SMIL into Java/C++/J#/C#/VB. >Does anyone know if such an experiment/undertaking/instanity has been >investigated? see http://mindprod.com/projects/scid.html I see the future of language evolution more off as display rather than ASCII representation as a stream of characters. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. >>Does anyone know if such an experiment/undertaking/instanity has been >>investigated? [quoted text clipped - 3 lines] > I see the future of language evolution more off as display rather than > ASCII representation as a stream of characters. You mean like Labview? -- LTP :) On Fri, 24 Mar 2006 18:12:36 -0700, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >> I see the future of language evolution more off as display rather than >> ASCII representation as a stream of characters. > >You mean like Labview? I am not familiar with LabView. I see programming in future more like filling in dialog boxes and ticking things off. I also see people heavily customising the way they view the code, using dozens of different ways of looking at the same code depending on the current task, lots of ways of filtering out what is temporarily irrelevant or highlighting what is, making it easy to compare things that in current code are not adjacent.. The code becomes a structured graph of nodes in a database, not an ascii text string. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. People have been anticipating that for a long time, though. Problem is, most businesses have really particular ways of doing things different from other businesses, requiring clever thought on the part of the implementor. I don't think outsourcing will go wholly overseas because of that: you almost have to coexist iwth a customer (or have a really good resident expert) to understand the unique aspects of business. (but I digress...) > On Fri, 24 Mar 2006 18:12:36 -0700, "Luc The Perverse" > <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly [quoted text clipped - 13 lines] > code are not adjacent.. The code becomes a structured graph of nodes > in a database, not an ascii text string. Ah - yes that is not quite like labview. I can't actually see where you are going with that any more than I can understand Aspect-Oriented Programming. I would just need to see it working. It would have to be very well done though. Most tools meant to simplify tasks merely hide information that I consider relevant. I am constantly peeved by windows and other microsoft programs doing this in its default options. If they could make innovations that didn't get in the way I wouldn't be opposed. But I've installed several GDE's that had "smart tabbing" which I think should be renamed to random tabbing - I have no idea where there cursor is going if I push tab. Labview on the other hand is a completely visual programming language in which data lines are represented as wires. (So your program is essentially a schematic.) Everything not directly defined as sequential is multithreaded. Labview is used for hardware integration - and it is an effective tool for many purposes. I had a data collection card in the computer, and I was able to make a program which turned it on, and graphed multiple data points in a matter of minutes. While the speed at which applications can be drafted up is amazing, it is virtually impossible to write a conventional algorithm using wires, and "LEDs" as booleans etc. I think the true power is in the device drivers and attention that has been put into easy hardware integration. They have a self branded "C-like" language which uses the same libraries - but I have no experience with that. -- LTP :) On Fri, 24 Mar 2006 21:21:21 -0700, "Luc The Perverse" <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly quoted someone who said : >I can't actually see where you are going with that any more than I can >understand Aspect-Oriented Programming. I would just need to see it >working. I have done a few simulations at http://mindprod.com/projects/scid.html IDEs such as Eclipse and IntelliJ are now doing many of the things I imagined SCIDs doing, like global rename, though they don't do it as accurately as a true SCID could. SignatureCanadian Mind Products, Roedy Green. http://mindprod.com Java custom programming, consulting and coaching. Roedy Green schrieb: > On Fri, 24 Mar 2006 18:12:36 -0700, "Luc The Perverse" > <sll_noSpamlicious_z_XXX_m@cc.usu.edu> wrote, quoted or indirectly [quoted text clipped - 6 lines] > I am not familiar with LabView. I see programming in future more like > filling in dialog boxes and ticking things off. There are a lot of products working this way. You could program in Flash 4 using a graphical interface. AFAIK, Excel allows to do complex reports using dialog boxes. Automator lets you control Applications and Files using a GUI. But for me, x and y coordinates and three buttons simply can't beat a keyboard. This might only be true because I spend a lot of time in front of it. For casual users, a simple GUI interface is more convenient. > I also see people > heavily customising the way they view the code, using dozens of > different ways of looking at the same code depending on the current > task, "Debug perspective" vs. other "perspectives" in Eclipse. > lots of ways of filtering out what is temporarily irrelevant or > highlighting what is, There certainly are tons of ways to filter information in Eclipse. > making it easy to compare things that in current > code are not adjacent.. Not sure what you mean, but the compare views of Eclipse are very useful. Organizing source into coherent domains is up to the programmer. > The code becomes a structured graph of nodes It already becomes a structured graph of nodes in Eclipse. The source text is parsed into an Abstract Source Tree. You can browse the tree of a class and you can browse entire inheritance and call hierachies. > in a database, not an ascii text string. This would be possible. But compilers, build tools, repositories, etc. would have to support it. Text is the common denominator. (I know that Eclipse is not the only IDE to do all that.) Timo something like a XAML or XUL XSLT transform script to language-of-choice? That would only handle the UI, though... but would you really want to write logic in XML? Data structures are a little more palatable, and mapping languages in Castor/JAXB/JIBX etc. do something like this already. But logic statements in XML? Yuck! Holy crap! It's been done: <canvas> <simplelayout spacing="5"/> <class name="box" height="100" width="100" bgcolor="red"/> <class name="borderedbox" extends="box" onmouseover="this.changeSize(50)" onmouseout="this.changeSize(-50)"> <attribute name="bordersize" value="3"/> <view bgcolor="yellow" x="${parent.bordersize}" y="${parent.bordersize}" width="${parent.width - parent.bordersize*2}" height="${parent.height - parent.bordersize*2}"/> <method name="changeSize" args="pixels"> this.animate("width", pixels, 500, true); this.animate("height", pixels, 500, true); </method> </class> from OpenLaszlo. Although to my mind it's more of a language embedded in XML, not so much a language in XML syntax. So, how would this go? Lex/Yacc programming language X to agnostic XML representation Y using mapping M in XML mapping language Z (sub X)? There's no problem can't be solved by adding another layer of indirection. > something like a XAML or XUL XSLT transform script to > language-of-choice? That would only handle the UI, though... but would > you really want to write logic in XML? My experince with Ant suggests that the answer is "NO!!!!". I actually like ANT, but I have no explaination as to why. Maybe because I've stared too long a make files in the past. > something like a XAML or XUL XSLT transform script to > language-of-choice? That would only handle the UI, though... but would [quoted text clipped - 3 lines] > > But logic statements in XML? Yuck! Each to his own. I find the notion of having a full language expressed in the form of structured data appealing. This part of the idea has indeed been done (started anyway) in XML. See http://www.o-xml.org/. It has not been used as the basis for translation to other OO languages that I know of, but there are people doing transforms between o:XML code and XMI formatted UML. >Essentially: your choice of source-code need not limit that of others >working on the same code. And when you have completed this project it is just a small step to a word processor that works in a human language-agnostic language so one person can edit the document in French and the next can use Italian. >>Essentially: your choice of source-code need not limit that of others >>working on the same code. >> > And when you have completed this project it is just a small step to a > word processor that works in a human language-agnostic language so one > person can edit the document in French and the next can use Italian. Oui. I mean, si. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.