6 ms·
CS also saves keystrokes and makes code more readable by offering things such as: Reducing boilerplate for loop code: CS: for el, index in arr e
by lowboy 13y ago
CS also saves keystrokes and makes code more readable by offering things such as:
Reducing boilerplate for loop code:
CS:
for el, index in arr
el.doThing(index)
JS:
for(var index=0; index < arr.length; index++) {
var el = arr[index];
el.doThing(index);
}
Better iteration over objects:
CS:
for own k, v of obj
console.log "#{k} is #{v}"
JS:
for(k in obj) {
if(!obj.hasOwnProperty(k))
continue;
console.log(k + " is " + obj[k]);
}
Default function params:
CS:
foobar = (foo = "default", bar = "shmefault") ->
# Go on...
JS:
function foobar(foo,bar) {
if(foo === null)
foo = "default"
if(bar === null)
bar = "shmefault";
// Go on...
}
String interpolation:
CS:
str = "There are #{num} #{item}s available for $#{price} each"
JS:
str = "There are " + num + " " + item + "s available for $" + price + " each";
Existential checks, soaking nulls:
CS:
if obj?.prop?.exists?
console.log "obj.prop.exists"
JS:
if(typeof obj !== "undefined" && obj != null && obj.prop != null && obj.prop.exists != null)
console.log("obj.prop.exists")
- ahoge 13y agoYes, but that's just some syntactic sugar. That stuff doesn't help with tooling/scaling. By the way, Dart also has optional named/positioned arguments, sane for-in loops, and string interpolation. It also offers proper lexical scoping (oh, yeah!) and even operator overloading.
- luikore 13y agoLanguage is part of the tooling. For example, if you have a language that compiles to js which always passes JSLint, then you don't need JSLint any more. Removing the need of a tool is even better than developing a tool. CoffeeScript generates less code than Dart, it runs faster thus has its strength in scaling. In fact, you can already do operator overloading in Javascript using valueOf and side effects. It's a bit tricky though. The Dart approach of operator overloading works more sanely. If two languages compile to the same runtime (Javascript). Syntax is the only thing we can compare. Many so called "syntactic sugar" do fix design problems of Javascript, please don't ignore them.
- ahoge 13y ago> [JS generated from CS] runs faster [than JS generated from Dart] There are cases where output from dart2js outperforms handwritten JS. Nowadays, the performance of the generated JS is generally pretty good. > it runs faster thus has its strength in scaling "Scaling" as in: more developers, more files, more lines of code. Bigger projects. CS doesn't help with that one bit. It's just as difficult to handle as JS. This is why Google came up with stuff like the Closure Compiler, GWT, and now Dart. > Syntax is the only thing we can compare. There are also semantics and the whole environment. Syntax is a small fairly unimportant detail.
- lowboy 13y ago> "Scaling" as in: more developers, more files, more lines of code. Bigger projects. CS doesn't help with that one bit. It's just as difficult to handle as JS. Right, and that's why we have modular design patterns that use the single responsibility principle, and AMDs like Require.js or CommonJS. It's testable, maintainable, can support a large codebase with multiple developers, and doesn't need static typing or other features from TS/Dart.
- ahoge 13y ago> AMDs like Require.js or CommonJS That stuff is terrible to use. There is quite a bit of boiler plate involved and there is lots of overhead in general. Secondly, there are about 10 somewhat popular module formats and they aren't compatible which each other. I rather do this stuff declaratively. If it's baked into the language, your tools will understand what's going on and there also won't be any compatibility issues. Naturally, it's also way more convenient to use. You just import something. Done. > doesn't need static typing or other features from TS/Dart You also don't need a seat belt or airbags. If you don't make any mistakes, you'll be fine. However, from a pragmatic point of view, these static checks are very handy. If you rewrite some parts of your code, the analyzer will tell you if you screwed something obviously up. It catches all the stupid mistakes, which means you can fully focus on the logical ones. With JavaScript/Python/etc you have to run the code and actually hit that particular branch to trigger some sort of error/exception which will eventually help you to identify the actual issue. You should just give it a try. Try any language/IDE combination which offers good tooling. Tooling can remove a lot of friction. There really is a point to all of this.
- lowboy 13y agoIt's a bit more than syntactic sugar - as luikore said, eliminating the need for a tool like jslint is a win. Not having to worry about trailing commas, hasOwnProperty checks, semicolons, etc. is a big win. Getting rid of a shit-ton of symbols and boilerplate code also makes the code more readable, in addition to the saved keystrokes. That's awesome that Dart includes those features, and I wish that I had lexical scoping in CS. But closures are a pretty easy workaround. > TS and Dart also reduce the number of keystrokes though. They allow you to auto-complete pretty much everything. That sounds like an IDE/editor feature, not a language feature. Setting up macros/snippets/etc in an IDE/editor will save keystrokes for most any language.
- ahoge 13y ago> That sounds like an IDE/editor feature, not a language feature. Being toolable is a language feature. You can't do these things with JS or CS, because your tools don't have a clue what's going on. You can only do some guessing.
- lowboy 13y agoBy "autocomplete" you mean when you're writing code in an editor and you can type "fu", hit <tab> and it'll complete to "function() {}", for example? If that's the case, autocompletion exists for JS and CS for most of the editors that I've used (Notepad++, Vim, SublimeText, TextMate). CS is a better JS, but doesn't enforce any design decisions like static typing, or OOP (with interfaces apparently?). I like CS, because I like JS, and I like that it doesn't try to shoehorn in concepts foreign to JS. It's possible to build scalable systems in JS/CS without what TS/Dart offers. You might not be able to do so from your experience, but that doesn't mean it's not possible.
- ahoge 13y ago> By "autocomplete" you mean [...] All the fields and methods are known. If I write "someObject.", then I'll get a calltip which lists all fields/methods from this particular class and I can auto complete them. You can conveniently browse around like this to find the right method. If I write "foo.bar" and "foo" as no "bar" field, I'll get a squiggly line (and of course I also wouldn't have been able to auto-complete "bar"). It's similar to writing C#, AS3, or Java with a good IDE. If you have never experience any of that, maybe you should give it a try. > It's possible to build scalable systems in JS/CS without what TS/Dart offers. Sure. It just requires more time and money. You can, for example, also chop down a tree by using an axe instead of a chainsaw. There is always a more difficult more time consuming way to do something.
- deleted 13y ago[deleted]
- munificent 13y agoFor kicks, here's Dart versions of those: Reducing boilerplate for loop code: var index = 0; for (var el in arr) { el.doThing(index++); } Dart hasn't really optimizing for iterating over a collection with indices since we don't find that very common in real-world code. Better iteration over objects: obj.forEach((k, v) => print("$k is $v")); Here, obj is a map data structure, not a random object since Dart distinguishes objects and data structures. Default function params: foobar([foo = "default", bar = "shmefault") { // Go on... } String interpolation: str = "There are $num ${item}s available for \$$price each"
- lowboy 13y agoDoes Dart compile that for loop down to a regular for loop instead of the JS for..in loop? Or are there any safeguards against someone adding a property to an array (not that they should)? a = [1,2,3]; a.prop = "oops"; for(el in a) console.log(el); // > 0 // > 1 // > 2 // > oops