Slashdot Mirror

← Back to Stories (view on slashdot.org)

Dart Is Not the Language You Think It Is

Posted by Soulskill on from the it's-actually-cobol-in-a-funny-hat dept.

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

7 of 312 comments (clear)

  1. There are two kinds of programming languages.... by Anonymous Coward · · Score: 5, Interesting

    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.

  2. Unadvantages! by Shaiku · · Score: 5, Interesting

    Once the idea is tested and youâ(TM)re comfortable with the design, you can add type annotations.

    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?

    1. Re:Unadvantages! by farble1670 · · Score: 5, Insightful

      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?

    2. Re:Unadvantages! by dreadway · · Score: 5, Interesting

      IMO the thing which crippled large Smalltalk projects was the corporate IT market embracing programming technologies which looked more like C. You had to fight hard to make Smalltalk code look like a procedural language, which a larger body of programmers were already used to. Java, C++, and C# look more like C, so I guess they have that going for them.

      Smalltalk is a strongly-typed, late-binding language. Smalltalk's Object>>#doesNotUnderstand behavior is a hindrance for production-quality code only to the extent that your programmers are unwilling or unable to read and use someone else's API. Oh, and maybe your system design should not suck, no matter what programming technology is involved.

      I worked for years as a Smalltalk programmer on big, corporate IT systems involving hundreds of programmers and handling hundreds of millions of $$$ per day in production, but corporate IT has had a mood swing and now our systems mostly use the early-binding programming technologies. I like being gainfully employed, but am not persuaded the tradeoffs of the extra code, convoluted syntax constructions, and tool paradigms actually represent any improvements. And finally, believe it or not, but the less senior programmers apparently have difficulty reading and understanding the code (even with its early-binding features) written by far more experienced programmers than myself, which in turn results in numerous and varied production defects. Who would have thunk it, eh?

  3. Since I think nothing of Dart by Spy+Handler · · Score: 5, Funny

    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!

  4. Re:There are two kinds of programming languages... by Anonymous Coward · · Score: 5, Insightful

    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.

  5. Re: What can't you do in C? by j1m+5n0w · · Score: 5, Insightful

    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.