Slashdot Mirror
Dart Is Not the Language You Think It Is
An anonymous reader writes "Seth Ladd has an excellent write-up of Dart: 'When Dart was originally launched, many developers mistook it for some sort of Java clone. In truth, Dart is inspired by a range of languages such as Smalltalk, Strongtalk, Erlang, C#, and JavaScript. Get past the semicolons and curly braces, and you'll see a terse language without ceremony. ... Dart understands that sometimes you just don’t feel like appeasing a ceremonial type checker. Dart’s inclusion of an optional type system means you can use type annotations when you want, or use dynamic when that’s easier. For example, you can explore a new idea without having to first think about type hierarchies. Just experiment and use var for your types. Once the idea is tested and you’re comfortable with the design, you can add type annotations."
Those people always bitch about and those no one uses.
Since I have yet to hear any complaints about Dart, I can only assume it's in the latter category and no one cares.
I've been doing this with comments since 1999 and it works great! Of course I still haven't gotten around to that final step of going back and adding all those comments but I love the flexibility!
Unless you like bugs, type-checking is a good thing. Lack of type enforcement encourages what -- lack of forethought?
not having heard of it, and thus never having any thoughts about it, and since you say it's NOT what I think it is (nothing), I guess Dart *is* something!
I've been following Dart on and off since it's announcement. I'm still a little skeptical of the language, but I'm a fan of what they want to do. Here are their basic goals:
There is a lot more to it than this, but it's sort of a beginning. The language still hasn't hit 1.0, so no one is seriously using it (as the language itself was seeing large changes up until recently). Google has not talked about anyone outside of the Dart team itself that is using Dart within Google (they are doing it, it's just not being talked about yet).
Since 1.0 is expected this summer, you probably won't see many people using it until that milestone is hit. Once 1.0 is hit, people will be more willing to create real products with it, so you can expect to see more about Dart after that. As well, once the DartVM makes its way into Chrome (which will happen sometime after 1.0), you'll probably see a lot of press about the first Google App that is written in Dart.
It's still early in Dart's life. The only people really seriously using it are people that like learning new languages. Companies and most developers won't touch an in-progress programming language out of fear that syntax and behavior changes will screw them up.
Its not what it is, its something else.
Get ready to hear some bitching about Dart on this thread, then review your assumption.
I vote for no one cares.
I for one never encountered a situation where I thought "gee, if only I could prototype without types!". Types matter. When solving even the most basic data processing problem there's "input" and "output". Specifications are very clear on the formatting and types. What happens in between is dictated by those types.
Typeless programming in shorthand for lazy markup.
Or so that was my first thought. Then I got to the end of the article
Dart compiles to JavaScript and runs across the modern web
And suddenly I find it potentially very useful. I have a NodeJS project to develop a Streaming Service later this week. While I was planning on writing it in Coffeescript, the classic OO nature of Dart with Type Checking and Interfaces(!) seems like a potentially better match since the NodeJS app will be a clustered streaming service -- just the sort of application whose architecture could greatly benefit from these language features. If that succeeds, I know of a large retailer wanting to create a NodeJS middleware as a REST API to legacy systems, who might find Dart as compelling as I do.
I haven't used DART yet, so I will not comment on the strength or the weakness of it
But, all through the decades that I've been in the scene, there have been so many programming languages invented, but so few of them being used
Some of the more widely used programming languages like C, for instance, are not perfect, but they are being used partly because of legacy, partly because of momentum, and partly because of the laziness of programmers to learn new, more useful languages
Talking about legacy, the other day there was a piece on Cobol, and that IBM is trying to extend Cobol to the cloudsphere
As for the languages that are not so-widely used, some of them are downright weird, but then, there are gems among them. The only downside for those few gems is that the ecology is not there to enable those few gems to become more widespread
I guess it's kinda Darwinian game plan --- not all surviving/thriving species are perfect, and not all the extinct species are bad, either
Muchas Gracias, Señor Edward Snowden !
Yeah, exactly. What the writeup calls "appeasing a ceremonial type checker" is more properly called "debugging".
Don't get me wrong, I like the thrill of the chase, the satisfaction of tracking down a really hard bug, as much as anyone. But I like programming even more. Using a well-designed type checker, I can find bugs in my program and convince myself that I'm programming rather than debugging.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
Return a list from a function. Sure, you can legally do it, there's nothing in the language inherently stopping you, but experienced C programmers will avoid returning a list at all costs, because suddenly you have to care about whether the caller frees the list properly, and what if the things in the list are used elsewhere and we need to do reference counting etc.. etc... I've worked on a C codebase that was a couple hundred thousand lines of code, and I can't think of anywhere that we ever returned a list from a function. I can't think of any Haskell program more sophisticated than "hello world" that I didn't use "map" and other list functions all the time.
Ultimately, the cost of manual memory allocation isn't just the extra work you have to do to make sure you aren't leaking or corrupting memory, it's the algorithms you won't allow yourself to even consider because the memory management would just be too hard.
I'm not saying C doesn't have it's place, I'm just saying that there are software engineering costs associated with using C as opposed to a higher-level language.
Return a list from a function. Sure, you can legally do it, there's nothing in the language inherently stopping you, but experienced C programmers will avoid returning a list at all costs.
Hmm, that's odd. So C has its place but it's avoided because it lacks garbage collection? My C code has automatic garbage collection and OOP facilities. It's got lists and maps, and a comprehensive collections library. It's just under 30 thousand lines of code, but then it's just a game engine. It only has to do everything the computer actually can. If you don't have these basic facilities in your C library, it's your own damn fault. Seems to me if I want I can always have it in C, there's no excuse for not having it.
My memory manager replaces the malloc / free facilities, so it can even be added to other C code-bases, hell, I use it in C++ code because it's faster than the GC in the standard library (for the way I use it). So it's not like I have to call reference counting functions; Just the GC_recycle() function, or enable it to run automatically, which blocks on malloc() / free(), and optionally gives each thread their own local GC rather than a unified approach such that part of the program can garbage collect while another keeps running.
However, when my testers bitch about stutter in Java / Android No matter how badly I want Java or JavaScript to give me control of the damn garbage collector, so it doesn't run in the middle of the rendering loop or intense action sequence, I can't have it. I have to implement an object cache atop Java and pre-allocate everything, try my hardest not to give the GC a chance to run, and if I slip up once and let that fucker have control, it's game over, literally, when the enemy attacks and the game lags for half a second.
I return lists from functions all the time you dumbass. I'm an "experienced C programmer". Stop painting with such a wide brush, you're getting the paint in you eyes.
An AC adds:
Or return a function from a function?
I throw Function pointers around like crazy, that's how efficient state machines, decision trees, or other flexible structures are formed. Hell, my Entity-like system allows Actors to composite sets of functionality as it transitions states to create efficient AI -- Just because it's fleeing doesn't mean it's still not searching for Health. It would be like if C++ let you pick which methods you inherited from multiple parents on the fly. I mean hell, returning and passing a function pointer is how I implemented multiple sorts:
// or
list->sort( list, list->getSortRoutine( SORT_MERGE ) );
myCustomRoutine = getCurrentSort();
list->sort( list, myCustomRoutine );
That first "list" being passed in the sort function pointer invocation is where your magic "this" pointer comes from in C++.