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."
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.
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?
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.