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."
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.
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 !
It lets you throw something together quickly for a proof of concept
the thing about type safety ... even if you use a non-type safe language, you still have to get it right or your crap will crash, or worse, run and do something unexpected. you still need to be type safe, it's just that you have to find all your bugs at runtime in stead of compile time. do we need to discuss why it's better to catch bugs at compile time?
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++.