481–490 of 504 posts
Earlier quoted context omitted.
Circle my_circle = new Circle(); I have to type the word circle 3 times to define a circle. It gets boring. This gets worse if you are trying to do any kind of user input. BufferedReader my_reader = new BufferedReader(new InputStreamReader(System.in)); Had to type reader 4 times. :(
Dart doesn't require the type. var c = new Circle();
Earlier quoted context omitted.
Circle my_circle = new Circle(); I have to type the word circle 3 times to define a circle. It gets boring. This gets worse if you are trying to do any kind of user input. BufferedReader my_reader = new BufferedReader(new InputStreamReader(System.in)); Had to type reader 4 times. :(
Dart doesn't require the type. var c = new Circle();
Earlier quoted context omitted.
I'm curious what you thought a JavaScript replacement would look like. Apparently you thought it /wouldn't/ look like GWT.
JavaScript - the ugly + OO + update to the standard library. That's it. Essentially what frameworks like MooTools try to make it into.
Earlier quoted context omitted.
I read a bit more into Dart, its optional typing is very interesting. I might even like that if it were a change to Javascript itself. Of course Javascript has problems, every language has problems associated with it. They all have strengths and they all have weaknesses. From what I've seen, projects like GWT, Dart, and Coffeescript come out of communities of developers other then the web development community. GWT a…
People also used to program computers with punch-cards. Everyday. Of course they can use Javascript. You didn't address any of his points though. Where are the great Javascript tools and IDEs? There are tons of them for languages with static typing and classical inheritance. Here's just one tiny example: Compare how you go about refactoring code (renaming classes, functions, etc) in Javascript with the many ways that…
It's a valid one though, the Javascript IDE's out there aren't very good. However, that's a function of community support, not language quality. Personally, I don't use an IDE for javascript or RoR programming, I just use Textmate.
I use Eclipse for Java programming, and I don't think I would want to program in Java without it. Maybe it says something about the languages themselves that they require an IDE to develop in.
Earlier quoted context omitted.
Not true, look at Objective-C for an example of how it's done. Broken up into two methods, the first of which is a static method which creates an uninitialized instance, and the second which is a plain method which initializes the instance and returns self (or rarely, nil): + alloc // reserves memory and creates an instance - init // initializes the instance - initWithSomething: // can have multiple inits
I go back and forth on whether I like this. On the one hand, the clean split makes it conceptually simple what's going on. On the other hand, you can have allocated, uninitialized code, which makes me uneasy.
This is completely the wrong thing to do. Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript. That is something I could see Mozilla and Apple getting behind. Only once they have actively campaigned for this should they be adding new languages to the browser which fracture the web. I had hoped that Dart would su…
> Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript. > That is something I could see Mozilla and Apple getting behind. Why would you expect either Mozilla or Apple to get behind such a proposal? Apple has a powerful self-interest in making sure the Web remains a second-best app platform behind iOS and desktop…
Mozilla "conspires" to do almost exactly the opposite of what you suggest. Having lots of decent browsers available was our old success condition. Now the mobile world is starting to look locked up, so breaking that open to competition and free choice is our new success condition.
This is completely the wrong thing to do. Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript. That is something I could see Mozilla and Apple getting behind. Only once they have actively campaigned for this should they be adding new languages to the browser which fracture the web. I had hoped that Dart would su…
> Google should be proposing a standard, open, byte-code compatible, Intermediate Language standard that can run Javascript and in the interim run on Javascript. > That is something I could see Mozilla and Apple getting behind. Why would you expect either Mozilla or Apple to get behind such a proposal? Apple has a powerful self-interest in making sure the Web remains a second-best app platform behind iOS and desktop…
Certainly, VM byte code languages are often simpler than silicon processors' machine languages; perhaps they offer safety guarantees; and perhaps they provide garbage collection. These are all big wins for language implementers targeting such VMs.
But what no virtual machine will ever do is make modules written in different source languages work together transparently. Any time one module calls another module written in a different language, at least one side of that boundary needs to be written with a detailed understanding of both languages' semantics.
Tiny details of the semantics influence the idioms people settle on in that language --- and interfaces are designed around those idioms. For example, JavaScript conditionals treat the empty array and the empty object as true, while Python conditionals treat them as false. Each of these facts shapes what people expect of a "natural" API in that language --- and that ensures that modules written in other languages will always "speak with an accent", or seem unnatural, at best.
You can define a common data world, as the .NET CLR does, and extend each source language to cover that world, but the effect is to change each participant language into a gloss on the common data world. This is why CoffeeScript fits seamlessly into the JavaScript world: JavaScript's and CoffeeScript's data worlds are exactly the same. CoffeeScript cannot deviate from JavaScript's types and objects.
Each programming language is like a city occupying an island: commerce within the city is much less expensive than commerce between islands. Although it's sometimes worth it, dealing with "foreigners" is confusing and risky. No VM will change that.
From whatever little I see, I am already hating it :-) This looks like Java for Javascript, if that makes any kind of sense. We are in the year 2011, PL design has progressed so much since 1990 that such an anachronism is unpardonable. I sincerely wish that companies like Google focus on hiring the right kind of person for designing programming languages. What is frustrating is that there are so many people who can d…
> This looks like Java for Javascript, if that makes any kind of sense. It completely does. And I love that it manages to be completely incoherent with Go, the other "Google Language". That's so symptomatic of what google does on that front.
From whatever little I see, I am already hating it :-) This looks like Java for Javascript, if that makes any kind of sense. We are in the year 2011, PL design has progressed so much since 1990 that such an anachronism is unpardonable. I sincerely wish that companies like Google focus on hiring the right kind of person for designing programming languages. What is frustrating is that there are so many people who can d…
Agree with parent comment. My opinion, so far: Overall: uninspired. Below what I was expecting. Probably good for Google goals (tooling, migrating developers, etc) The language is somewhat interesting, but unfortunately saddened by an incredibly boring syntax. At this point, I am thinking that they would have been better off just going with the Go language for this. Looks like something good to migrate fleets of java…
- Incredibly uninspired, boring Java-like syntax.
Earlier quoted context omitted.
The language isn't done yet. Now is the time to let us know if you want semicolons to go away. I know some of us on the team do too, but public interest will help a lot.
Please make semicolons and braces optional. Unless they are explicitly required for marking blocks and endlines they are just wasted characters to people from prettier languages :-) For those people who come from "ugly" languages like Java you could have a feature in the IDE which auto-inserted (and of course auto-removed) the braces/semicolons so that they felt at home too.