The Facebook story is an old one. Times have changed. Facebook and Instagram teams have been working with HTML5 for a while. They even open sourced the libraries they work with. http://facebook.github.io/react/
Zuckers is a twit anyway. When we started out with the HTML5, webgl, and streaming data over websockets thing two years ago it was understood to be all very new and an experiment that I was pretty much sure would not work. For that reason we had a FLASH development going on in parallel. I was happily proved wrong. The HTML5 worked, the FLASH thing was never working properly and eventually abandoned. Not bad for starting from zero knowledge of "web technology" and getting a prototype demonstrator live in 6 weeks!
I should not cast aspersions about your team. I'm sure they are very competent and productive with the twenty year old tools they use. I know a bunch of clever guys that are still working in FORTRAN. Others are still getting on with COBOL. It's all good stuff. (Well except the Java thing which a language with no purpose and no interesting features that should never have been allowed to live).
I don't want to work nights and weekends working around obscure IE bugs.
Not me either. So I don't do it. I don't care if my code does not work in IE. A user is free to get a Firefox or a Chrome. Or even a new version of IE that works with the standards or can at least be made to work with minimal effort. Life is too short to be supporting the Microsofts of this world for free.
Actually IE10 and IE11 are doing pretty well with JavaScript. Nobody is supporting Netscape anymore and supporting IE6 is out of question too. Guys IE6 is about 10 years old?
It is not just FORTRAN. COBOL is well alive and there are Billions of lines of COBOL out there. The current compiler I am working with is GNU COBOL. It basically compiles COBOL source to C source and runs it thru GCC.
Them programmers in the 60's where very productive. And the C in COBOL stands for common. Big COBOL Programs are quite easy ported from one architecture to another. It was build for that from the beginning. At the time COBOL was envisioned by the later Rear Admiral Grace Hopper (what a women. google her if you don't know about her) there was no common Operating System and no common assembly language. Every company made there own stuff.
That was the reason for the raise of COBOL. It was working everywhere. And still is. You might be surprised if you dig into it. It is all about the cost. Everybody thought the Y2K thing will kill COBOL. But it didn't. It was cheaper to fix the date issue then to rewrite hundreds and thousands of man hours of code.
I did check this with the guys from GNU COBOL and it is supposed to run with CLANG also. But me, myself and I never learned that C language and that Linux stuff. Yes I doodled around with both. Yes I can steal take some C code from Catalina, change it to do what I want and compile it for my FriendlyArm from whatever years ago. But I never worked with that language in any paid job. So I never got fluent in it.
Now I need to convince @Heater. to help me with another adventure. I did install all that stuff to run emscripten on Windows. But I can not really grook it. To much Linux for me. I am better in JCL as in Bash...
But it should be possible to compile COBOL to JavaScript now. Cool, isn't it?
I just do not know how to bribe @Heater. to take that on. Some sort of challenge is needed here and I still can not figure out one....
But JavaScript has matured from being a simple Scripting language for the browser (like vb-script) to a VERY interesting language. As more you do with it as more nice things you find. @Heater talked me into it and I haven't had so much fun programming since I discovered the Propeller some years ago. Somehow SPIN and JavaScript have something in common. Easy to start with but the devil is in the details. Both languages behave sometimes quite different from your usual way of thinking. And in both languages this has a reason. Them are doing things different because it is another way to attack old problems.
Not me either. So I don't do it. I don't care if my code does not work in IE. A user is free to get a Firefox or a Chrome. Or even a new version of IE that works with the standards or can at least be made to work with minimal effort. Life is too short to be supporting the Microsofts of this world for free.
I don't have the luxury to say no. We produce a retail customer facing application, and the customer is always right. So we support:
Microsoft Internet Explorer 8.0, 9.0, 10.0, and 11.0
Firefox
Safari
Google Chrome
In practice this means we can't use any technology that won't work in IE 8. These sort of support matrices are normal in my industry.
[QUOTE=Martin_H;1259940... In practice this means we can't use any technology that won't work in IE 8. These sort of support matrices are normal in my industry.[/QUOTE]
But win XP is phasing out now and win7 is doing quite well in replacing it. So you may be able to cut down on IE8 and IE9 soon. The rest is OK.
Them programmers in the 60's where very productive.
I have been wondering about that recently. Back in the 60's people started measuring programmer productivity so as try and figure out if various languages or tools were helping or not. They did it in the crudest way possible by counting lines of code written per day, not including comments and white space etc.
The surprising result was when looking at finished working products, designed, written, tested, debugged, documented, produces about 10 lines of code per day.
Turns out this pretty much a constant across assembler programmers and high level language programmers. Of course users of HLL are hopefully getting more functionality from their ten lines than the assembler guys.
The other day I found out something about a Google project, a lot of programmers, a lot of code, project going on for four years or so. I can't recall the numbers now but it turned out they had produced about 12 lines of code per day altogether. And that's if you count the thousands of lines of test harness code, not just what runs in the product.
So programmer productivity has not changed much since the 1960's.
Funny, as soon as you turned up and mentioned COBOL I imagined COBOL programs transpiled to JS and running in the browser. Given the loathing some people have for COBOL and JS this is the perfect combination
If you can supply me with a "Hello World" COBOL program and instructions on how to compile it with GNU COBOL we could see about that JS conversion.
Man you are about thirty years behind the prevailing marketing wisdom
Customers today are known as consumers. They are to be twisted, coerced, brainwashed, conned, into accepting whatever worthless junk you can make in return for cash. They are just the buffer where junk wait's a bit whilst it's on its way to the landfill.
But win XP is phasing out now and win7 is doing quite well in replacing it. So you may be able to cut down on IE8 and IE9 soon. The rest is OK.
Mike
XP still has 27 percent of the market which means that it dwarfs OSX, and will likely remain relevant for years. Later versions of IE include an Enterprise mode which makes them act like earlier versions of IE, so that legacy Intranet sites will still work. In practice this means we need to support IE 8 for these customers well after the real IE 8 is dead and buried.
I honestly don't see this getting any better for 3-5 years. By then who knows what will be the hot technology.
JavaScript, CCS, and Browsers have been a pain in the butt since the beginning of time... It's part of the job. Remember when PC monitors jumped in size?
What about the code base? I also support a very large complex customer facing application. JavaScript is the least of my troubles. Reading the code is like counting tree trunk rings. It's oblivious when the code was written as it follows the hot pattern (or widget) at that time. Do we rewrite it - No. Why? because it works and who will pay for it - the customer??? We just deal with it like we deal with browser versions and CSS implementation. Rip goes the duct tape.
My point is the most efficient language since sliced bead (if one exists) can bring a system to its knees given the right programmer.
Poor old JavaScript, the language, gets a lot of stick for all the troubles caused by browser differences, HTML, CSS, HTTP. the DOM API, a billion crappy libraries and frame works that are supposed to fix all that, and so on.
JS, the language, has been faithfully performing in all that chaos almost unchanged since the beginning. It has been the most dependable language across browsers and across time. MS did a very good job of reverse engineering JS back in the day, and reimplementing it warts and all. They even insisted that the warts get baked into the ECMA standard when Netscape wanted to clean up the language for standardization.
For a long while nobody quite realized how sophisticated JS is and it got the blame for all the browser environment woes.
How come JS gets all this grief when, for example, a language like C++ is totally non-portable. A Windows program in C++ is nothing like a C++ program that uses Qt for example.
I'd say JS, the language, has been doing a great job here where other languages have failed us.
What about the code base? I also support a very large complex customer facing application. JavaScript is the least of my troubles. Reading the code is like counting tree trunk rings. It's oblivious when the code was written as it follows the hot pattern (or widget) at that time. Do we rewrite it - No. Why? because it works and who will pay for it - the customer??? We just deal with it like we deal with browser versions and CSS implementation. Rip goes the duct tape.
This is so true. Javascript frameworks come and go. Five years ago Dojo was hot, now its jQuery. There's also a plethora of application frameworks like AngularJS, Backbone.JS, and Ember.js, But wait there's mustache.js or handlebars.js for templates.
Poor old JavaScript, the language, gets a lot of stick for all the troubles caused by browser differences, HTML, CSS, HTTP. the DOM API, a billion crappy libraries and frame works that are supposed to fix all that, and so on.
This is a distinction without a difference if your use case is building browser applications.
But that's always been my point. JS is not restricted to browsers.
Most of my JS lives on the server. Now it's starting to live in my micro-controllers.
Then there is the JS used in Qt applications. Google QML. They finally realized that writing Qt apps in C++ is a pain so better provide a way to drive the whole thing from JS.
I have to agree that all those JS frame works and libraries are enough to drive you nuts. God I hate "frame works".
You forgot the latest one react.js from the FaceBook guys.
Outside of the browser Javascript is Yet Another Fine Language. Sure I could use it, but I already know C/C++, Forth, Java, PHP, Python, and others. This covers a huge amount of ground to solve different sorts of problems.
I also know Javascript pretty well from the client side browser work I've done, as it's the only game in town. But I really don't want to look at a single line of Javascript in any other context. It's irretrievably tainted by the ugliness that is client side browser programming.
Yep, a JAFL. With the emphasis on "Fine" here. As opposed the other JAFLs you mention which have a different "F" word.
C - Great stuff. About the lowest level high level language you can have. Not what I want to be using for big and complicated stuff. Not unless it's something that really needs to get low down a dirty and/or needs the performance. Like say an OS kernel. Or real-time micro-controller work.
C++ - I love it. I love the new C++11 standard enhancements which make it much easier, and prettier, to create reliable programs with. Strangely enough by adding some JS features like lambdas and closures and smart pointers to make garbage collection more robust. But C++ is still hard work to write, and hard work to maintain. Compared to getting the same functionality in, say, JS or Python. It's not necessarily much faster at run time than working in JS. C++ is a vast fractal of complexity that no single person can ever understand.
Forth - Is not a high level language. It's not portable. It's not possible to write maintainable code in it.
Java - A language that has no reason to exist. Given that we already had the far superior C++ for applications and JS is demonstrably better for web apps. Demands that you do everything in an OOP way with classes. Is verbose. Slow to run and bloated.
PHP - Bin there done that. God what a nightmare. A language that was never designed, just thrown together.
Python - Love it. Not so happy about the white space syntax requirements but I can live with that. Slow.
It's [JS] irretrievably tainted by the ugliness that is client side browser programming.
So this is just an emotional issue for you then. It is associated in your mind with a traumatic experience actually caused by something else and hence evokes the same feelings of fear and loathing. I suspect therapy for this is possible but it's a long road to recovery:)
Java - A language that has no reason to exist. Given that we already had the far superior C++ for applications and JS is demonstrably better for web apps. Demands that you do everything in an OOP way with classes. Is verbose. Slow to run and bloated.
I like Javascript, but the speed comparison hasn't been my experience. I wrote the same algorithm in both languages, and the Javascript version was 50% slower. This was an algorithm to iterate over 100K 223K 15 dimensional points and do some averaging.
In addition, how would you go about processing binary data in Javascript? To me, that seems like a big hassle that Java (or C/C++) can handle pretty well.
Edit: I found my speed tests. Java completed the task in an average of 15.47 seconds, Node.js completed the task in 23.42 seconds.
Forth - Is not a high level language. It's not portable. It's not possible to write maintainable code in it.
Well it could be portable for Forths with the same cells size, except Forth programmers tend to go off and build their own rather than adhere to standards. But I was able to get code to work on both gforth and propforth with some careful coding.
You might want to say "it's not possible for me to write maintainable code in it." I was able to grab some code from PropForth, figure out how it worked, and build both the Drawbot and Scara arm.
I might agree that if you are going to write some serious number crunching code it's likely to faster in a compiled language like C or C++.
In which case why would I do it in Java?
The fact that the Java byte codes were only 50% faster tells me that JS interpreters are doing pretty damn well. Well enough not to have to bother with Java in most cases.
But consider this. Let's say yo were doing some serious number crunching involving FFT or arbitrarily large integers or some such. Quite likely you would use a library that does what you want. That library will have been written in C or C++. At that point the overheads of using an interpreted language to drive it become negligible.
I found this when doing a lot of XML parsing server side. The C++ code and the JS code both used the same library to do that. End result is that performance is almost identical. But JS has the advantage of being much easier to work with.
What is the problem with binary data in JS?
var x = 0x12345678;
var y = ((x & 0x0000f000) >> 12) ^ 0x04;
console.log(y); // Prints 1
But wait, it should be 0x2000000000000000, right? Since 2.0 is 0x4000000000000000. But why would anybody do that? I don't know, but I did tell it I wanted a float value and not an integer. Since all numbers in Javascript are 64 bit floats (right?), it means that you have to be very careful about where numbers are. This seems like a weakness of the Javascript dynamic typing system. Java and C/C++ don't have that issue. To me, that seems like a pain to program that in Javascript.
In any case, the biggest binary challenge that I come across is encoding/decoding 32/64 bit floats and ints. It appears that Javascript does have a module for that, though:
In general terms I would say that if you are going to use a language you should at least try to learn the language first. All programming languages have a different ideas about variables, types and operators.
In this specific case I would say that the whole idea of a shift operator on a number, is up for grabs. I could argue that 1234 >> 1 should be 123. We are working with decimal integers right?
Especially I would argue that a shift operator on a floating point number makes no sense. Again I could argue that 1234.5 >> 1 should be 123.45. We are talking decimal fractions right?
You are assuming that JS should do what C does. Just because JS looks a bit like C or Java does not mean it is C or Java. It behaves differently.
Anyway never mind. Your premise is wrong and I quote: "This seems like a weakness of the Javascript dynamic typing system. Java and C/C++ don't have that issue."
Yes they do have these issues, and worse. And your example indicates you don't know what C or Java actually do.
Well, the proof is in the pudding so let's see. In the C language first:
$ cat float.c
#include "stdio.h"
int main (int argc, char* argv[])
{
double x = 2.0;
int y = x >> 1;
return(y);
}
$ gcc -o float float.c
float.c: In function ‘main’:
float.c:6:12: error: invalid operands to binary >> (have ‘double’ and ‘int’)
Clearly C agrees with me that >> on a floating point number is silly.
In python:
>>> x = 2.0
>>> y = x >> 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for >>: 'float' and 'int'
Python also agrees that this is a silly thing to do.
What about that JS result?
> x = 2.0
2
> x >> 1
1
Actually. As a programmer who has been around the block with binary and hex this is a correct answer, given that you want a dynamic type system.
When applying a shift to a number, make it an integer first, then shift it's binary representation.
Which by the way is the same answer you get from C or Java if you apply the correct casting to int first.
What's the problem?
As for type systems. There is none so flawed as those of C and Java. For example:
int a = 3830432279;
int b = 1329234923;
int c = a + b;
Ends up with silently assigning the wrong answer of 864699906 to C.
What Smile is that?
At least JS and Python get this right, 5159667202. Python will continue to give correct integer results for much bigger numbers. JS will be a bit lazy and give you a correct floating point approximation.
In short, learn the languages first then compare them.
I just read you last post again. A now fully appreciate how misguided it is:
Since 2.0 is 0x4000000000000000.
In what world crazy should this be true?
The decimal number "2.0" can be written as "2" with no loss of information or precision.
Decimal 2 in hex is 2 and in binary is 10.
Shift that by one place in the normal meaning of shift in the binary computer world and we get 1
JS gets this right and you are complaining about it!
C will do the same thing given the casts to int.
You are clearly alluding to the IEE floating point standard binary representation. If you want to be shifting that as bits in C or JS you have to do some extra work.
Of course if you do this is Spin you get another wrong answer!
Ohhhh boy, you had to go there, the big hammer of JS criticism. That's a tough one.
Not only that but it doesn't have a concept of threading in the browser or node.js.
I love this kind of argument because it implies a fact which is wrong and then uses that non-fact to bash the opposition.
In this case. The concept of threading.
Forgive me if I'm wrong but Java, C, C++ etc do not have the concept of threading built into the language syntax and semantics. Rather it is bolted on with external libraries and classes. In a very crude and ugly way I might add.
The only languages I know that do have threading and parallelism "built in" are OCCAM as used in the old Transputers, XC as use in modern XMOS devices and perhaps Google's Go language.
So yes, JS does not have threading, neither does any one else much.
It's all event callbacks which makes code ugly fast
Again we have a false assumption that call backs are some how more ugly than threaded code.
The situation with JS is no different than using C++ or Java to create a GUI. In a GUI there is an event loop sucking up mouse and keyboard events and firing off handler functions in you app.
The last thing you want to do is hang up the GUI in one of those handlers by having it compute for a long time or wait for a network transfer or database query etc.
That brings you into the ugly world of threads. In most languages anyway. Now you have a lot of verbose code and all kind of problems with resource sharing mutual exclusion and so on.
Or you can use call backs as in JS. Or as in the signals/slots of the Qt GUI tool kit. (A feature that is not in your basic C++) Nice and easy.
Now admittedly this can get out of hand. The so called "callback hell"
I claim that in most cases one does not reach callback hell. If you do it can be resolved by using promises and such. All of which is easier than managing threads.
Threads are of course also very costly in terms of time and memory space. So when you need many of them in a hurry you are doomed.
That leaves the issue of long winded calculations holding things up. Again the false premise that the browser or node cannot do this. For example browsers have "web workers", processes that can run in parallel to the GUI thread to be farmed out with big jobs to do. The openspin compiler in the browser shows how well this works.
Without having numeric types like long or byte you're sort of insulated from the binary representations of numbers. But this raises the question "Does Javascript have a notion of the underlying byte order of numbers?" I looked in "JavaScript: The Good Parts" and it had nothing on the topic.
C/C++ use host byte order which is efficient, but require conversion functions (e.g. htonl, htons, ntohl, and ntohs) when building or parsing network packets. But to C/C++ programmers this is second nature.
Java always uses network byte order which has obvious performance penalties, but makes building network apps straight forward for people who don't understand big/little endian.
Now in Javascript you aren't usually building network protocols, just sending JSON or text messages over the wire. But if the language has aspirations of being more useful this would be a bridge to cross.
Forgive me if I'm wrong but Java, C, C++ etc do not have the concept of threading built into the language syntax and semantics. Rather it is bolted on with external libraries and classes. In a very crude and ugly way I might add.
It's not a crude and ugly way. The design philosophy of C/C++ is a minimal language with everything else (including I/O) added on via library calls. Java inherited this design philosophy and its standard library included a thread package.
Maybe you can add on a library to Javascript that supports threading, but none exists at the present time to my knowledge.
I claim that in most cases one does not reach callback hell. If you do it can be resolved by using promises and such. All of which is easier than managing threads.
Threads are of course also very costly in terms of time and memory space. So when you need many of them in a hurry you are doomed.
This sounds like Stockholm syndrome. Javascript doesn't have threads, but I'm better off without them. Thread context switches are not costly on a modern multicore machines running a modern OS. They're often not even expensive to create because the OS caches them in a thread pool.
Also threading isn't hard, it is coordinated reads/writes to shared storage that's hard, so the complexity depends upon the use case. But we have the same problem with Propeller programs that use multiple cogs on shared Hub RAM, but we seem to manage this fine.
I've seen the video and love it. "All the complexities of assembler with all the efficiency of Javascript." "It was You, you are the reason science was set back 1000 years."
Yep, JS insulates you from the binary representation of numbers in the underlying hardware. Which is all good, that is what we want high level languages for. So the idea of byte order does not arise.
Except when it does of course.
One major case is exchanging data with GPU's for webgl to work.
A new feature of JS is "typed arrays". Briefly this allows for the creation of arrays that can be viewed as arrays of signed or unsigned 8, 16, 32, 64 bit quantities.
Typed arrays were motivated by webgl but turn out to be very useful for other things. For example when transpiling C++ to JS it is a great optimization to be able to use typed arrays to represent the memory space in which the transpiled code keeps all it's data. An image of the memory as the C++ would see it.
Now, I have no used this much but if I understand correctly these typed arrays end up being in the endianness of the machine they are running on. So we are back into the word of architecture dependence and having to worry about endianness when reading files or network data into a typed array.
This is of course an inconvenience imposed for pragmatic performance reasons.
I have yet to figure out what hassle it causes in practice.
...in Javascript you aren't usually building network protocols, if the language has aspirations of being more useful this would be a bridge to cross.
I don't think this is an issue. JavaScript is implemented in C++ normally. All the dirty little details like implementing those hash tables that are JS objects, or string handling, etc etc are done in C++.
And so are the underlying interfaces, like HTTP requests and file reading and text encoding and keyboard/mouse input etc etc. If an important binary protocol arises it will be implemented down there in C++.
In node.js it's easy to write a module that wraps a C++ interface/protocol.
In the browser that might take time to become a standard feature, if ever.
One case I was wondering about recently was the binary encoding used in Google's protobuffers. How do I get those up and down the line to a browser, how do I decode them? We will see.
SEQ
PAR
a = getSometing()
b = getSomethingElse()
z = a + b
Which means, first I want to get a and b. which may take a long time, can be done in parallel and may not complete in any special order. So do them in PARallel.
Then, when that's done. calculate z from a and b. This latter part must be done SEQuencially after the first part.
Now that is simple, elegant and beautiful. Whatever happens in C, C++, Java is horrendously hideous by comparison.
As you rightly point out threading is in the libraries of C/C++/Java, it's NOT in the syntax and semantics of the language definition. By contrast to OCCAM above.
I sincerely hope that threads, as you know them, are never introduced to JS. That's even if it is possible without wrecking all that is good about the language.
What I would like is threads in the manner of OCCAM parallelism. That is to say:
a) Be able to write a blob of code that can be run in parallel.
b) Be able to run that blob of code.
c) There is NO shared memory, global vars or anything, between the two running threads.
d) One communicates with the parallel code my message passing.
Now, in fact we can already do that in the browser with "web workers" or in node by firing up a process and talking to it's standard in and standard out.
Perhaps it would be nice to see that done in lightweight threads rather than OS processes.
Glad you like the video. I love it too!
However, experiment shows the little guy being belittled by the old timer has a very good point.
Esthetic are in the eye of the beholder, and that is an emotional argument, much like my DOM traumatized dislike of Javascript. Personally, I like the simplicity of C with everything being added on via libraries.
The other area where Javascript is lacking is making it self-hosted. As you pointed out, it is ultimately written C++ which places ultimate limits on what you can do with it.
Meanwhile C++ is already self hosted, and so is Forth for all its warts. So you could write an OS in either one of them.
But what about C# and Java? It turns out that several people have written C# compilers in C#, and there are Java compilers (e. g. http://gcc.gnu.org/java/) that can target native code. So in theory it is possible to make either of these language self-hosted as well.
Do get a chance to watch the vids some of them are classics.
Don't get me wrong, I was not suggesting we start piling all kinds of features into languages. I too like the demarkation between what is "language" and what is "library".
However the threads/parallelism is a clear case of something that should be in the language. It's more than just a case of "good looking" syntax. Here is why:
In programming, no matter which language, there are only three things we can do from a control flow point of view: sequence, selection and repetition.
Sequence - statements happen one after the other in the order they are written.
Selection - Do some something or do something else depending on some condition. Selection is normally indicated by some language keywords like "IF".
Iteration - Do something over and over until some condition is met. Repetition is normally indicated in a language by some language keywords like "REPEAT".
With these we can compose any program we can imagine.
Well, except for one thing: "Do something and do something else at the same time". I.e. threads/parallel execution. So the indicates a "Parallel" language construct. Perhaps with a language representation like "PAR".
Note that "Sequence" normally has no language keyword. We are so used to sequential being the only way to do things that we forgot to give it a language construct. We could call it "SEQ".
This brings us to the OCCAM syntax which expresses the four things we can do in programming: Sequence, Parallel, Selection, Iteration.
REPEAT
PRINT "Starting"
IF doParallel
PAR
doSomething
doSomethingElse
ELSE
SEQ
doSomething
doSomethingElse
PRINT "Done"
This is only a sad approximation to OCCAM as I don't recall the syntax in detail
The Google Go language also has the idea of threading built into the language definition rather than having it hacked into the system as a library.
The other area where JavaScript is lacking is making it self-hosted... which in my opinion separates the real languages from the toys.
I too used to have these naive ideas about "real" and "toy" languages. And I too had notions of "self hosting" as the differentiator. It turns out to be totally misguided.
For example, as you point out, C++ was not self hosted originally. It depended on C compilers and a C++ preprocessor. Now C++ compilers are written in C++. Would you say that "C++ was a 'toy' language but now it's a 'real' language." Clearly that is absurd, the language is the same only the implementation has changed.
Going back in time we could imagine that even C was not self hosted. It depended on having a assembler or other language to compile the source of the C compiler itself. Eventually a C compiler could be written in C. Again, did C, the language, suddenly change from "toy" to "real"? No, the language did not change only the implementation.
Your other example is Java, same story it seems.
What about JS? Can that ever become self hosting?
I see no logical reason why not.
In short, changing a languages implementation does not change it from "toy" to "real". it's still the same language. Ergo JS is not a toy language. (Unless you can prove that achieving self hosting is impossible for JS).
Is worth the effort to make JS self hosting? Probably not. But I can imagine one day there is a C++ compiler written in JS that can be used to build the JS engine which can be used to run the C++ compiler and so round and round. The whole loop of JS to C++ to JS would be self hosting!
There is a difference between all of my examples and Javascript. They all include a compilation phase to produce native code, while Javascript is interpreted. The compilation phase is the key because it is when the compiler compiles the compiler. So that step was present in all of those languages, even before they became self-hosted.
To make Javascript self-hosted you would need to add a compilation step. Writing a C++ compiler in JavaScript to compile the C++ compiler to compile Javascript doesnt get at the core of the problem. Including a compilation step would fix some of my criticism because the compiler would have to ensure that code was syntactically correct, and that there were no unresolved dependencies. It could also produce bytecode or native code which could be referenced in HTML via object tags (much like applets). In short Javascript could become like Java and be made better.
Quite so. We generally have compiled languages, ALGOL, FORTRAN, C, C++ etc and we have interpreted languages, Lisp, Scheme, PHP, Python, JS.
Of course things are not so cut and dry for example Java is generally compiled to byte code and that in turn needs an interpreter. On the other hand there are interpreters for C.
What you are suggesting is that there should be a compiler for JS that produces native code in the same manner as C++. Or perhaps produces byte code like Java. Further you are suggesting that having such a compiler would some how make JS "better".
I'm not totally sure but I have a feeling that statically compiling JS to native is not actually possible. What we have is a very dynamic language where a function can be passed parameters of any type and any time. Likewise it can return anything it likes. An array may be all floats one minute and contain a mixture of floats, integers, strings and objects the next. Given that you don't know ahead of time what types are where you cannot statically compile it.
For this reason engines like V8 compile to native code at run time when they have a clue about types. This gives almost the speed of compiled C++. BUT they have to be prepared to throw that optimized compiled code away if all of a sudden an array that looked like it contained only numbers is suddenly filled with other objects.
So your suggestion to make JS statically compilable is basically suggesting cutting off it's balls, and arms and legs, making it almost useless and the rebuilding it to look like C++ or Java.
All of which is totally pointless as we already have C++ and Java. All the power of JS would be removed.
Including a compilation step would fix some of my criticism because the compiler would have to ensure that code was syntactically correct...
No compilation to native is required to do this. My editor highlights all syntax errors and "suspicious" looking code as I type it. Or I can syntax check from the command line.
...and that there were no unresolved dependencies.
This is not possible unless you make the language as crippled and limited as C++ or Java.
It could also produce byte code or native code which could be referenced in HTML via object tags (much like applets)
We don't need native or byte code compilation to do this. We can do better than applets already.
Appet tags look like this:
According to Heater's profile, he actually reached 7.04 posts per day.... whereas I come in at less than 3 per day. I just wonder what that might imply... maybe nothing, maybe something ;-0
Comments
The Facebook story is an old one. Times have changed. Facebook and Instagram teams have been working with HTML5 for a while. They even open sourced the libraries they work with. http://facebook.github.io/react/
Zuckers is a twit anyway. When we started out with the HTML5, webgl, and streaming data over websockets thing two years ago it was understood to be all very new and an experiment that I was pretty much sure would not work. For that reason we had a FLASH development going on in parallel. I was happily proved wrong. The HTML5 worked, the FLASH thing was never working properly and eventually abandoned. Not bad for starting from zero knowledge of "web technology" and getting a prototype demonstrator live in 6 weeks!
I should not cast aspersions about your team. I'm sure they are very competent and productive with the twenty year old tools they use. I know a bunch of clever guys that are still working in FORTRAN. Others are still getting on with COBOL. It's all good stuff. (Well except the Java thing which a language with no purpose and no interesting features that should never have been allowed to live). Not me either. So I don't do it. I don't care if my code does not work in IE. A user is free to get a Firefox or a Chrome. Or even a new version of IE that works with the standards or can at least be made to work with minimal effort. Life is too short to be supporting the Microsofts of this world for free.
It is not just FORTRAN. COBOL is well alive and there are Billions of lines of COBOL out there. The current compiler I am working with is GNU COBOL. It basically compiles COBOL source to C source and runs it thru GCC.
Them programmers in the 60's where very productive. And the C in COBOL stands for common. Big COBOL Programs are quite easy ported from one architecture to another. It was build for that from the beginning. At the time COBOL was envisioned by the later Rear Admiral Grace Hopper (what a women. google her if you don't know about her) there was no common Operating System and no common assembly language. Every company made there own stuff.
That was the reason for the raise of COBOL. It was working everywhere. And still is. You might be surprised if you dig into it. It is all about the cost. Everybody thought the Y2K thing will kill COBOL. But it didn't. It was cheaper to fix the date issue then to rewrite hundreds and thousands of man hours of code.
I did check this with the guys from GNU COBOL and it is supposed to run with CLANG also. But me, myself and I never learned that C language and that Linux stuff. Yes I doodled around with both. Yes I can steal take some C code from Catalina, change it to do what I want and compile it for my FriendlyArm from whatever years ago. But I never worked with that language in any paid job. So I never got fluent in it.
Now I need to convince @Heater. to help me with another adventure. I did install all that stuff to run emscripten on Windows. But I can not really grook it. To much Linux for me. I am better in JCL as in Bash...
But it should be possible to compile COBOL to JavaScript now. Cool, isn't it?
I just do not know how to bribe @Heater. to take that on. Some sort of challenge is needed here and I still can not figure out one....
But JavaScript has matured from being a simple Scripting language for the browser (like vb-script) to a VERY interesting language. As more you do with it as more nice things you find. @Heater talked me into it and I haven't had so much fun programming since I discovered the Propeller some years ago. Somehow SPIN and JavaScript have something in common. Easy to start with but the devil is in the details. Both languages behave sometimes quite different from your usual way of thinking. And in both languages this has a reason. Them are doing things different because it is another way to attack old problems.
Enjoy!
Mike
I don't have the luxury to say no. We produce a retail customer facing application, and the customer is always right. So we support:
Microsoft Internet Explorer 8.0, 9.0, 10.0, and 11.0
Firefox
Safari
Google Chrome
In practice this means we can't use any technology that won't work in IE 8. These sort of support matrices are normal in my industry.
that hurts a lot.
[QUOTE=Martin_H;1259940... In practice this means we can't use any technology that won't work in IE 8. These sort of support matrices are normal in my industry.[/QUOTE]
But win XP is phasing out now and win7 is doing quite well in replacing it. So you may be able to cut down on IE8 and IE9 soon. The rest is OK.
Enjoy!
Mike
The surprising result was when looking at finished working products, designed, written, tested, debugged, documented, produces about 10 lines of code per day.
Turns out this pretty much a constant across assembler programmers and high level language programmers. Of course users of HLL are hopefully getting more functionality from their ten lines than the assembler guys.
The other day I found out something about a Google project, a lot of programmers, a lot of code, project going on for four years or so. I can't recall the numbers now but it turned out they had produced about 12 lines of code per day altogether. And that's if you count the thousands of lines of test harness code, not just what runs in the product.
So programmer productivity has not changed much since the 1960's.
Funny, as soon as you turned up and mentioned COBOL I imagined COBOL programs transpiled to JS and running in the browser. Given the loathing some people have for COBOL and JS this is the perfect combination
If you can supply me with a "Hello World" COBOL program and instructions on how to compile it with GNU COBOL we could see about that JS conversion.
But wait...someone has done a COBOL to JS already https://github.com/ajlopez/CobolScript
Customers today are known as consumers. They are to be twisted, coerced, brainwashed, conned, into accepting whatever worthless junk you can make in return for cash. They are just the buffer where junk wait's a bit whilst it's on its way to the landfill.
XP still has 27 percent of the market which means that it dwarfs OSX, and will likely remain relevant for years. Later versions of IE include an Enterprise mode which makes them act like earlier versions of IE, so that legacy Intranet sites will still work. In practice this means we need to support IE 8 for these customers well after the real IE 8 is dead and buried.
I honestly don't see this getting any better for 3-5 years. By then who knows what will be the hot technology.
What about the code base? I also support a very large complex customer facing application. JavaScript is the least of my troubles. Reading the code is like counting tree trunk rings. It's oblivious when the code was written as it follows the hot pattern (or widget) at that time. Do we rewrite it - No. Why? because it works and who will pay for it - the customer??? We just deal with it like we deal with browser versions and CSS implementation. Rip goes the duct tape.
My point is the most efficient language since sliced bead (if one exists) can bring a system to its knees given the right programmer.
JS, the language, has been faithfully performing in all that chaos almost unchanged since the beginning. It has been the most dependable language across browsers and across time. MS did a very good job of reverse engineering JS back in the day, and reimplementing it warts and all. They even insisted that the warts get baked into the ECMA standard when Netscape wanted to clean up the language for standardization.
For a long while nobody quite realized how sophisticated JS is and it got the blame for all the browser environment woes.
How come JS gets all this grief when, for example, a language like C++ is totally non-portable. A Windows program in C++ is nothing like a C++ program that uses Qt for example.
I'd say JS, the language, has been doing a great job here where other languages have failed us.
This is so true. Javascript frameworks come and go. Five years ago Dojo was hot, now its jQuery. There's also a plethora of application frameworks like AngularJS, Backbone.JS, and Ember.js, But wait there's mustache.js or handlebars.js for templates.
This is a distinction without a difference if your use case is building browser applications.
Most of my JS lives on the server. Now it's starting to live in my micro-controllers.
Then there is the JS used in Qt applications. Google QML. They finally realized that writing Qt apps in C++ is a pain so better provide a way to drive the whole thing from JS.
I have to agree that all those JS frame works and libraries are enough to drive you nuts. God I hate "frame works".
You forgot the latest one react.js from the FaceBook guys.
I also know Javascript pretty well from the client side browser work I've done, as it's the only game in town. But I really don't want to look at a single line of Javascript in any other context. It's irretrievably tainted by the ugliness that is client side browser programming.
Yep, a JAFL. With the emphasis on "Fine" here. As opposed the other JAFLs you mention which have a different "F" word.
C - Great stuff. About the lowest level high level language you can have. Not what I want to be using for big and complicated stuff. Not unless it's something that really needs to get low down a dirty and/or needs the performance. Like say an OS kernel. Or real-time micro-controller work.
C++ - I love it. I love the new C++11 standard enhancements which make it much easier, and prettier, to create reliable programs with. Strangely enough by adding some JS features like lambdas and closures and smart pointers to make garbage collection more robust. But C++ is still hard work to write, and hard work to maintain. Compared to getting the same functionality in, say, JS or Python. It's not necessarily much faster at run time than working in JS. C++ is a vast fractal of complexity that no single person can ever understand.
Forth - Is not a high level language. It's not portable. It's not possible to write maintainable code in it.
Java - A language that has no reason to exist. Given that we already had the far superior C++ for applications and JS is demonstrably better for web apps. Demands that you do everything in an OOP way with classes. Is verbose. Slow to run and bloated.
PHP - Bin there done that. God what a nightmare. A language that was never designed, just thrown together.
Python - Love it. Not so happy about the white space syntax requirements but I can live with that. Slow.
So this is just an emotional issue for you then. It is associated in your mind with a traumatic experience actually caused by something else and hence evokes the same feelings of fear and loathing. I suspect therapy for this is possible but it's a long road to recovery:)
I like Javascript, but the speed comparison hasn't been my experience. I wrote the same algorithm in both languages, and the Javascript version was 50% slower. This was an algorithm to iterate over 100K 223K 15 dimensional points and do some averaging.
In addition, how would you go about processing binary data in Javascript? To me, that seems like a big hassle that Java (or C/C++) can handle pretty well.
Edit: I found my speed tests. Java completed the task in an average of 15.47 seconds, Node.js completed the task in 23.42 seconds.
Well it could be portable for Forths with the same cells size, except Forth programmers tend to go off and build their own rather than adhere to standards. But I was able to get code to work on both gforth and propforth with some careful coding.
You might want to say "it's not possible for me to write maintainable code in it." I was able to grab some code from PropForth, figure out how it worked, and build both the Drawbot and Scara arm.
I might agree that if you are going to write some serious number crunching code it's likely to faster in a compiled language like C or C++.
In which case why would I do it in Java?
The fact that the Java byte codes were only 50% faster tells me that JS interpreters are doing pretty damn well. Well enough not to have to bother with Java in most cases.
But consider this. Let's say yo were doing some serious number crunching involving FFT or arbitrarily large integers or some such. Quite likely you would use a library that does what you want. That library will have been written in C or C++. At that point the overheads of using an interpreted language to drive it become negligible.
I found this when doing a lot of XML parsing server side. The C++ code and the JS code both used the same library to do that. End result is that performance is almost identical. But JS has the advantage of being much easier to work with.
What is the problem with binary data in JS?
But wait, it should be 0x2000000000000000, right? Since 2.0 is 0x4000000000000000. But why would anybody do that? I don't know, but I did tell it I wanted a float value and not an integer. Since all numbers in Javascript are 64 bit floats (right?), it means that you have to be very careful about where numbers are. This seems like a weakness of the Javascript dynamic typing system. Java and C/C++ don't have that issue. To me, that seems like a pain to program that in Javascript.
In any case, the biggest binary challenge that I come across is encoding/decoding 32/64 bit floats and ints. It appears that Javascript does have a module for that, though:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays
In general terms I would say that if you are going to use a language you should at least try to learn the language first. All programming languages have a different ideas about variables, types and operators.
In this specific case I would say that the whole idea of a shift operator on a number, is up for grabs. I could argue that 1234 >> 1 should be 123. We are working with decimal integers right?
Especially I would argue that a shift operator on a floating point number makes no sense. Again I could argue that 1234.5 >> 1 should be 123.45. We are talking decimal fractions right?
You are assuming that JS should do what C does. Just because JS looks a bit like C or Java does not mean it is C or Java. It behaves differently.
Anyway never mind. Your premise is wrong and I quote: "This seems like a weakness of the Javascript dynamic typing system. Java and C/C++ don't have that issue."
Yes they do have these issues, and worse. And your example indicates you don't know what C or Java actually do.
Well, the proof is in the pudding so let's see. In the C language first:
$ cat float.c #include "stdio.h" int main (int argc, char* argv[]) { double x = 2.0; int y = x >> 1; return(y); } $ gcc -o float float.c float.c: In function ‘main’: float.c:6:12: error: invalid operands to binary >> (have ‘double’ and ‘int’)Clearly C agrees with me that >> on a floating point number is silly.In python: Python also agrees that this is a silly thing to do.
What about that JS result? Actually. As a programmer who has been around the block with binary and hex this is a correct answer, given that you want a dynamic type system.
When applying a shift to a number, make it an integer first, then shift it's binary representation.
Which by the way is the same answer you get from C or Java if you apply the correct casting to int first.
What's the problem?
As for type systems. There is none so flawed as those of C and Java. For example:
int a = 3830432279; int b = 1329234923; int c = a + b;Ends up with silently assigning the wrong answer of 864699906 to C.What Smile is that?
At least JS and Python get this right, 5159667202. Python will continue to give correct integer results for much bigger numbers. JS will be a bit lazy and give you a correct floating point approximation.
In short, learn the languages first then compare them.
I just read you last post again. A now fully appreciate how misguided it is: In what world crazy should this be true?
The decimal number "2.0" can be written as "2" with no loss of information or precision.
Decimal 2 in hex is 2 and in binary is 10.
Shift that by one place in the normal meaning of shift in the binary computer world and we get 1
JS gets this right and you are complaining about it!
C will do the same thing given the casts to int.
You are clearly alluding to the IEE floating point standard binary representation. If you want to be shifting that as bits in C or JS you have to do some extra work.
Of course if you do this is Spin you get another wrong answer!
Ohhhh boy, you had to go there, the big hammer of JS criticism. That's a tough one. I love this kind of argument because it implies a fact which is wrong and then uses that non-fact to bash the opposition.
In this case. The concept of threading.
Forgive me if I'm wrong but Java, C, C++ etc do not have the concept of threading built into the language syntax and semantics. Rather it is bolted on with external libraries and classes. In a very crude and ugly way I might add.
The only languages I know that do have threading and parallelism "built in" are OCCAM as used in the old Transputers, XC as use in modern XMOS devices and perhaps Google's Go language.
So yes, JS does not have threading, neither does any one else much. Again we have a false assumption that call backs are some how more ugly than threaded code.
The situation with JS is no different than using C++ or Java to create a GUI. In a GUI there is an event loop sucking up mouse and keyboard events and firing off handler functions in you app.
The last thing you want to do is hang up the GUI in one of those handlers by having it compute for a long time or wait for a network transfer or database query etc.
That brings you into the ugly world of threads. In most languages anyway. Now you have a lot of verbose code and all kind of problems with resource sharing mutual exclusion and so on.
Or you can use call backs as in JS. Or as in the signals/slots of the Qt GUI tool kit. (A feature that is not in your basic C++) Nice and easy.
Now admittedly this can get out of hand. The so called "callback hell"
I claim that in most cases one does not reach callback hell. If you do it can be resolved by using promises and such. All of which is easier than managing threads.
Threads are of course also very costly in terms of time and memory space. So when you need many of them in a hurry you are doomed.
For more information on this I refer you to this short, humorous and educational video about node.js
http://www.youtube.com/watch?v=bzkRVzciAZg
That leaves the issue of long winded calculations holding things up. Again the false premise that the browser or node cannot do this. For example browsers have "web workers", processes that can run in parallel to the GUI thread to be farmed out with big jobs to do. The openspin compiler in the browser shows how well this works.
C/C++ use host byte order which is efficient, but require conversion functions (e.g. htonl, htons, ntohl, and ntohs) when building or parsing network packets. But to C/C++ programmers this is second nature.
Java always uses network byte order which has obvious performance penalties, but makes building network apps straight forward for people who don't understand big/little endian.
Now in Javascript you aren't usually building network protocols, just sending JSON or text messages over the wire. But if the language has aspirations of being more useful this would be a bridge to cross.
It's not a crude and ugly way. The design philosophy of C/C++ is a minimal language with everything else (including I/O) added on via library calls. Java inherited this design philosophy and its standard library included a thread package.
Maybe you can add on a library to Javascript that supports threading, but none exists at the present time to my knowledge.
This sounds like Stockholm syndrome. Javascript doesn't have threads, but I'm better off without them. Thread context switches are not costly on a modern multicore machines running a modern OS. They're often not even expensive to create because the OS caches them in a thread pool.
Also threading isn't hard, it is coordinated reads/writes to shared storage that's hard, so the complexity depends upon the use case. But we have the same problem with Propeller programs that use multiple cogs on shared Hub RAM, but we seem to manage this fine.
I've seen the video and love it. "All the complexities of assembler with all the efficiency of Javascript." "It was You, you are the reason science was set back 1000 years."
You raise an interesting point re: endianness.
Yep, JS insulates you from the binary representation of numbers in the underlying hardware. Which is all good, that is what we want high level languages for. So the idea of byte order does not arise.
Except when it does of course.
One major case is exchanging data with GPU's for webgl to work.
A new feature of JS is "typed arrays". Briefly this allows for the creation of arrays that can be viewed as arrays of signed or unsigned 8, 16, 32, 64 bit quantities.
Typed arrays were motivated by webgl but turn out to be very useful for other things. For example when transpiling C++ to JS it is a great optimization to be able to use typed arrays to represent the memory space in which the transpiled code keeps all it's data. An image of the memory as the C++ would see it.
Now, I have no used this much but if I understand correctly these typed arrays end up being in the endianness of the machine they are running on. So we are back into the word of architecture dependence and having to worry about endianness when reading files or network data into a typed array.
This is of course an inconvenience imposed for pragmatic performance reasons.
I have yet to figure out what hassle it causes in practice. I don't think this is an issue. JavaScript is implemented in C++ normally. All the dirty little details like implementing those hash tables that are JS objects, or string handling, etc etc are done in C++.
And so are the underlying interfaces, like HTTP requests and file reading and text encoding and keyboard/mouse input etc etc. If an important binary protocol arises it will be implemented down there in C++.
In node.js it's easy to write a module that wraps a C++ interface/protocol.
In the browser that might take time to become a standard feature, if ever.
One case I was wondering about recently was the binary encoding used in Google's protobuffers. How do I get those up and down the line to a browser, how do I decode them? We will see.
Re threads: Yes it is. In OCCAM I can write code like this:
SEQ PAR a = getSometing() b = getSomethingElse() z = a + bWhich means, first I want to get a and b. which may take a long time, can be done in parallel and may not complete in any special order. So do them in PARallel.Then, when that's done. calculate z from a and b. This latter part must be done SEQuencially after the first part.
Now that is simple, elegant and beautiful. Whatever happens in C, C++, Java is horrendously hideous by comparison.
As you rightly point out threading is in the libraries of C/C++/Java, it's NOT in the syntax and semantics of the language definition. By contrast to OCCAM above.
I sincerely hope that threads, as you know them, are never introduced to JS. That's even if it is possible without wrecking all that is good about the language.
What I would like is threads in the manner of OCCAM parallelism. That is to say:
a) Be able to write a blob of code that can be run in parallel.
b) Be able to run that blob of code.
c) There is NO shared memory, global vars or anything, between the two running threads.
d) One communicates with the parallel code my message passing.
Now, in fact we can already do that in the browser with "web workers" or in node by firing up a process and talking to it's standard in and standard out.
Perhaps it would be nice to see that done in lightweight threads rather than OS processes.
Glad you like the video. I love it too!
However, experiment shows the little guy being belittled by the old timer has a very good point.
Whist we are at it you might also like this little video re: Microsoft:
http://www.youtube.com/watch?v=KkQlgdn1MuU
And this one re: Python:
http://www.youtube.com/watch?v=FJ7QsEytQq4
Let's not forget the poor C programmer:
http://www.youtube.com/watch?v=i2fhNVQPb5I
Or the JavaScript programmer:
http://www.youtube.com/watch?v=_AYyKAOdnSM
Or the Erlang gentleman:
http://www.youtube.com/watch?v=xEJ1n13soWU
Or the C++ programmer:
http://www.youtube.com/watch?v=x1TsOHyJPpw
And the famous "webscale" database debate
http://www.youtube.com/watch?v=URJeuxI7kHo
And a new one to me, Monkey Boy selling Windows 1.0
http://www.youtube.com/watch?v=tGvHNNOLnCk
Esthetic are in the eye of the beholder, and that is an emotional argument, much like my DOM traumatized dislike of Javascript. Personally, I like the simplicity of C with everything being added on via libraries.
The other area where Javascript is lacking is making it self-hosted. As you pointed out, it is ultimately written C++ which places ultimate limits on what you can do with it.
Meanwhile C++ is already self hosted, and so is Forth for all its warts. So you could write an OS in either one of them.
But what about C# and Java? It turns out that several people have written C# compilers in C#, and there are Java compilers (e. g. http://gcc.gnu.org/java/) that can target native code. So in theory it is possible to make either of these language self-hosted as well.
Update: it turns out that at least one JVM already exists that is written in Java:
https://kenai.com/projects/maxine/sources/maxine/show
Now I don't know how good it is, but it shows self-hosting is possible, which in my opinion separates the real languages from the toys.
Do get a chance to watch the vids some of them are classics.
Don't get me wrong, I was not suggesting we start piling all kinds of features into languages. I too like the demarkation between what is "language" and what is "library".
However the threads/parallelism is a clear case of something that should be in the language. It's more than just a case of "good looking" syntax. Here is why:
In programming, no matter which language, there are only three things we can do from a control flow point of view: sequence, selection and repetition.
Sequence - statements happen one after the other in the order they are written.
Selection - Do some something or do something else depending on some condition. Selection is normally indicated by some language keywords like "IF".
Iteration - Do something over and over until some condition is met. Repetition is normally indicated in a language by some language keywords like "REPEAT".
With these we can compose any program we can imagine.
Well, except for one thing: "Do something and do something else at the same time". I.e. threads/parallel execution. So the indicates a "Parallel" language construct. Perhaps with a language representation like "PAR".
Note that "Sequence" normally has no language keyword. We are so used to sequential being the only way to do things that we forgot to give it a language construct. We could call it "SEQ".
This brings us to the OCCAM syntax which expresses the four things we can do in programming: Sequence, Parallel, Selection, Iteration.
REPEAT PRINT "Starting" IF doParallel PAR doSomething doSomethingElse ELSE SEQ doSomething doSomethingElse PRINT "Done"This is only a sad approximation to OCCAM as I don't recall the syntax in detailThe Google Go language also has the idea of threading built into the language definition rather than having it hacked into the system as a library.
For example, as you point out, C++ was not self hosted originally. It depended on C compilers and a C++ preprocessor. Now C++ compilers are written in C++. Would you say that "C++ was a 'toy' language but now it's a 'real' language." Clearly that is absurd, the language is the same only the implementation has changed.
Going back in time we could imagine that even C was not self hosted. It depended on having a assembler or other language to compile the source of the C compiler itself. Eventually a C compiler could be written in C. Again, did C, the language, suddenly change from "toy" to "real"? No, the language did not change only the implementation.
Your other example is Java, same story it seems.
What about JS? Can that ever become self hosting?
I see no logical reason why not.
In short, changing a languages implementation does not change it from "toy" to "real". it's still the same language. Ergo JS is not a toy language. (Unless you can prove that achieving self hosting is impossible for JS).
Is worth the effort to make JS self hosting? Probably not. But I can imagine one day there is a C++ compiler written in JS that can be used to build the JS engine which can be used to run the C++ compiler and so round and round. The whole loop of JS to C++ to JS would be self hosting!
To make Javascript self-hosted you would need to add a compilation step. Writing a C++ compiler in JavaScript to compile the C++ compiler to compile Javascript doesnt get at the core of the problem. Including a compilation step would fix some of my criticism because the compiler would have to ensure that code was syntactically correct, and that there were no unresolved dependencies. It could also produce bytecode or native code which could be referenced in HTML via object tags (much like applets). In short Javascript could become like Java and be made better.
Quite so. We generally have compiled languages, ALGOL, FORTRAN, C, C++ etc and we have interpreted languages, Lisp, Scheme, PHP, Python, JS.
Of course things are not so cut and dry for example Java is generally compiled to byte code and that in turn needs an interpreter. On the other hand there are interpreters for C.
What you are suggesting is that there should be a compiler for JS that produces native code in the same manner as C++. Or perhaps produces byte code like Java. Further you are suggesting that having such a compiler would some how make JS "better".
I'm not totally sure but I have a feeling that statically compiling JS to native is not actually possible. What we have is a very dynamic language where a function can be passed parameters of any type and any time. Likewise it can return anything it likes. An array may be all floats one minute and contain a mixture of floats, integers, strings and objects the next. Given that you don't know ahead of time what types are where you cannot statically compile it.
For this reason engines like V8 compile to native code at run time when they have a clue about types. This gives almost the speed of compiled C++. BUT they have to be prepared to throw that optimized compiled code away if all of a sudden an array that looked like it contained only numbers is suddenly filled with other objects.
So your suggestion to make JS statically compilable is basically suggesting cutting off it's balls, and arms and legs, making it almost useless and the rebuilding it to look like C++ or Java.
All of which is totally pointless as we already have C++ and Java. All the power of JS would be removed. No compilation to native is required to do this. My editor highlights all syntax errors and "suspicious" looking code as I type it. Or I can syntax check from the command line. This is not possible unless you make the language as crippled and limited as C++ or Java. We don't need native or byte code compilation to do this. We can do better than applets already.
Appet tags look like this:
<applet code = 'appletComponentArch.DynamicTreeApplet' archive = 'DynamicTreeDemo.jar' width = 300 height = 300> <param name="permissions" value="sandbox" /> </applet>I can create my own JS code in an object, call it "MyComponent". And use it from an HTML tag like so:<my-component items="{window.someArray}"></my-component>