Slashdot Mirror

← Back to Stories (view on slashdot.org)

Dao, a New Programming Language Supporting Advanced Features With Small Runtime

Posted by Soulskill on from the not-to-be-confused-with-the-chinese-sword dept.

New submitter NeoHermit writes "This language (Dao) has never been mentioned on Slashdot before, but it might be interesting to many people here. As it has recently become feature-complete and just made its first beta release, it may be the right time to mention it here. Dao is an optionally-typed programming language that supports many advanced features with a small runtime. The feature list is probably as long as that of Python, but they are supported by a much smaller runtime (somewhere between Lua and Python, but closer to Lua). Besides optional typing, the other major features that worth mentioning include: built-in support for concurrent programming for multicore computers, very friendly C programming interfaces for embedding and extending, a LLVM-based JIT compiler, a Clang-based module for embedding C/C++ codes in Dao, and a Clang-based tool for automatic binding generation from C/C++ header files. You can also see many familiar features from other languages."

1 of 404 comments (clear)

  1. Re:There's a reason nobody talks about it by Anonymous Coward · · Score: 5, Interesting

    Dao (and Go) do not solve programming problems better than other mainstream alternative languages. Seriously, I looked through the list and asked myself what Dao could do that (say) C, C++, Java, Groovy, Scala, Clojure, or Haskell couldn't do, and I couldn't come up with anything.

    If someone is really interested in solving programming problems using language design, I need a language that satisfies the following:

    a) Object-oriented, when I want it. Not the C++ bullshit of multiple inheritance, but Java's OO model isn't bad as a start; maybe add Scala's mixins and traits as well to that.
    b) Functional, when I want it. But not Scala-functional: more like Haskell or Clojure functional.
    c) Strongly-typed, most of the time. When I'm solving specific domain problems, I want the type system to ensure I'm not jamming a Foo into a Bar.
    d) Optionally- or non-typed, once in awhile. Sometimes I'm just writing an algorithm that should be able to deal with any sort of object and don't care what the underlying object is. Java's generics are ok, but sometimes they just get in the way.
    e) Reasonable concurrency model - message passing, threads, actors, producers, consumers, event buses, etc.
    f) Garbage-collected. I used to do malloc()/free() and new/delete, but I'd rather have the underlying language handle objects for me. (That isn't to say that I don't care about memory pressures - I'm ok with allocating objects once and tracking their state instead of allocate/release/garbage-collect thrashing.)
    g) Proper closures and exception handling in the OO part. (Closures and monads should be part of the functional part of the language).

    Note to Scala crazies: the above may LOOK like Scala, but it sure as hell isn't Scala. No one in their right mind would develop something that had to be maintained in Scala, because part (h) that I don't want is this: arbitrary operator definition and overloading. That right there makes Scala a total disaster. For an example of this, see the Lift examples.