Google is developing programming techniques to simplify Web development(pixelstech.net)
pixelstech.net
Google is developing programming techniques to simplify Web development
http://pixelstech.net/article/index.php?id=1333102933
11 comments
After all the discussions about javascript here and anywhere javascript is mentioned you must realise by now that a lot of people disagree with you.
I'm not even going to go into why, it's been said a million times. Let's just agree that you've got an opinion that's not particularly compelling or common to a lot of experienced programmers. Your 'beauty' is many other people's bane. The very things you've picked out can cause such complexity and pain.
I'm not even going to go into why, it's been said a million times. Let's just agree that you've got an opinion that's not particularly compelling or common to a lot of experienced programmers. Your 'beauty' is many other people's bane. The very things you've picked out can cause such complexity and pain.
I'm not sure why you were downvoted. You make a good point. My main fear is that the big issue with the web development is incompatibility between browsers. We are just now starting to see some sanity. Browser teams are working together. I don't want to see more fragmentation by changing javascript and going through it all over again.
If you really want to program classical inheritance into Javascript, there are ways to do that today. Meanwhile, prototypal inheritance is already simple and powerful - so simple, perhaps, that programmers trained in classical inheritance tend to stumble on it.
I agree that prototypal inheritance is simple and powerful; JavaScript's version of it on the other hand… By introducing constructors you get this weird mix between classical and prototypical which isn't elegant at all :(
People do disagree. They also by and large agreed that all of the things that Java and friends brought to the table were supposed to lead to more maintainable software. So far, few software projects in any language approach the maintainability of the Linux kernel.
Having recently read "How We Decide", I can't help but think many of the traps described in that book are hit heavily by those trying to pick a programming language.
Having recently read "How We Decide", I can't help but think many of the traps described in that book are hit heavily by those trying to pick a programming language.
> So far, few software projects in any language approach the maintainability of the Linux kernel.
That may be true but is it really informative? Apples to apples: pick equivalent ultra-picky-with-membership team of talented programmers and then compare their artifacts' maintainability. C is a fine language but the point of Java is that it lowers the bar (by dealing with hard problems e.g. GC) and makes it more accessible (look ma, no pointers).
A possibly controversial (but arguably viable) measure of "Java and friends" success is the explosion of "complexity" in software written in these languages. My thesis is that IT league programmers would not have ventured to take spectacular architectural spacewalks in C or C++ but felt completely comfortable doing so in (say) Java.
That may be true but is it really informative? Apples to apples: pick equivalent ultra-picky-with-membership team of talented programmers and then compare their artifacts' maintainability. C is a fine language but the point of Java is that it lowers the bar (by dealing with hard problems e.g. GC) and makes it more accessible (look ma, no pointers).
A possibly controversial (but arguably viable) measure of "Java and friends" success is the explosion of "complexity" in software written in these languages. My thesis is that IT league programmers would not have ventured to take spectacular architectural spacewalks in C or C++ but felt completely comfortable doing so in (say) Java.
I think the subtext there was that maintenance of large code bases and the associated productivity is inherently a people (developers) problem, not a technical (language) problem. It's normally considered foolish to attempt to solve people problems with technology.
Indeed, that is exactly my belief at the moment. Thanks for saying it as I should have. :)
Much love for Alex Russell and for efforts to move the web forward as a serious development platform, but this was among the more content-free stories I've read in a long time. If you'd like to actually learn about "model-driven views," the component system the article mentions, head over to http://code.google.com/p/mdv/.
Reminds me of JSP (yep, its been that long). The theory of 'eternal return' in history certainly seems to hold true for software ...
A quote from the OP: "Russell said that Google engineers are also developing a proposal for the next version of JavaScript to add class concept. Class is a core element of object-oriented programming language, it is the basis of data and code reuse. JavaScript does not support class, the programmer can only use function calls to complete some of the features which is a waste of time to write the code that is not conducive to reuse."
I wonder if this portion of the Proposal is based on a thoughtful critique of javascript. Javascript's object-oriented paradigm, prototypal OOP, gives JS dynamic, class-free objects, and some would say that's a good thing--perhaps a great thing. In addition, the Prototypal paradigm was developed much later than Class-based OOP--nearly two decades later, and the developers of the former certainly knew of the latter, and learned from it. Given that, i wonder if this part of the Proposal isn't recommending retrograde techniques rather than improvements.
I wonder if this portion of the Proposal is based on a thoughtful critique of javascript. Javascript's object-oriented paradigm, prototypal OOP, gives JS dynamic, class-free objects, and some would say that's a good thing--perhaps a great thing. In addition, the Prototypal paradigm was developed much later than Class-based OOP--nearly two decades later, and the developers of the former certainly knew of the latter, and learned from it. Given that, i wonder if this part of the Proposal isn't recommending retrograde techniques rather than improvements.
I sometimes bang my head against the wall when I see stuff like this coming from Google, they should have higher standards.
The lack of class keyword in JavaScript is not the problem, if you want that so badly, because you can't code in anything but classes then just write a preprocessor for it, it would probably take a few hours or just use CoffeeScript. Google is helping here though with source maps, but it's kind of disappointing that they make statements like this along the way.
Don't want preprocessor? Use something like this: http://ejohn.org/blog/simple-javascript-inheritance/ Or this: https://github.com/shichuan/javascript-patterns/blob/master/...
There are a lot of problems not even related to JavaScript that are way worse than the lack of the class macro, just look at CSS.
The main thing I see here is that Google has a lot of Java people that are reluctant to learn anything besides Java constructs and they want to make web programming accessible to them so they can zerg rush development, GWT pretty much proves this, but the funny thing is that I think they didn't use GWT in G+ because it sucked.
Google should learn from Facebook, Facebook's front end JavaScript is mostly "hand coded" and not generated from another language.
The lack of class keyword in JavaScript is not the problem, if you want that so badly, because you can't code in anything but classes then just write a preprocessor for it, it would probably take a few hours or just use CoffeeScript. Google is helping here though with source maps, but it's kind of disappointing that they make statements like this along the way.
Don't want preprocessor? Use something like this: http://ejohn.org/blog/simple-javascript-inheritance/ Or this: https://github.com/shichuan/javascript-patterns/blob/master/...
There are a lot of problems not even related to JavaScript that are way worse than the lack of the class macro, just look at CSS.
The main thing I see here is that Google has a lot of Java people that are reluctant to learn anything besides Java constructs and they want to make web programming accessible to them so they can zerg rush development, GWT pretty much proves this, but the funny thing is that I think they didn't use GWT in G+ because it sucked.
Google should learn from Facebook, Facebook's front end JavaScript is mostly "hand coded" and not generated from another language.
The only problem with current OO in JavaScript is that it is different then what most people know, and they don't like learning new things.
When did a programming language became the core of solving scalability problems?
Does "creating a generic component model" remind anyone else of portlets?
"Next version of JavaScript to add class concept" = Lets make JavaScript sucks like Java/C#/<other class based> programming languages works. OOP is anyway a pathetic way to program and the "Class" based OOP is much more worse.
Nice trolling you did here. Though I wouldn't like JS becoming more Java-like.. Or Dart-like for that matter.
Thats what I said, we don't want Javascript to be Java like
Really poor story you don't have to do OO to do code reuse. At my fist job "hem hem " years ago we reused NAG algorithm libraries in FORTRAN IV.
When you relise the fact that you use the most apropriate tool for the job is when you start to become a professional programmer.
When you relise the fact that you use the most apropriate tool for the job is when you start to become a professional programmer.
"use the most apropriate tool for the job" is a hard place to get to, as it requires a combination of experience and critical thinking.
If they want to make something to make new programmers write better programs, by all means!
If they want to make something to make new programmers write better programs, by all means!
just inventing yet more OO languages is not going to help less fetizizing of CS theory and more real world experience might be a better idea.
The only thing needed to simplify web development is to have all browsers do the same thing with the same code. It's why jQuery has been so popular. Write code in jQuery and you have reasonable assurances that it will do the same in any (modern) browser.
Besides, if Google is developing programming techniques to simplify web development, then what the heck was Dart all about?
Besides, if Google is developing programming techniques to simplify web development, then what the heck was Dart all about?
Other than not having a 'Class' keyword in javascript, this is mostly a useless statement. The beauty of javascript lies in the balance between object and functional style. The prototypical model with first class functions is what makes javascript so powerful. I don't see the need to change it, and if you get into a situation where you need easy access to object oriented style, coffeescript is a fine choice.