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

20 of 404 comments (clear)

  1. There's a reason nobody talks about it by antifoidulus · · Score: 4, Funny

    It's basically Go with fewer features, next!

    --
    Monstar L
    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.

    2. Re:There's a reason nobody talks about it by Anonymous Coward · · Score: 3, Insightful

      Lisp?

    3. Re:There's a reason nobody talks about it by White+Flame · · Score: 4, Informative

      That's an assumption that hasn't been true since the 1950s. Common Lisp has full structures, OO classes & objects (and meta classes for defining the OO system itself and extending it), multimethod dispatch, complex & rational numbers, full Unicode strings, etc.

    4. Re:There's a reason nobody talks about it by cyborg_zx · · Score: 5, Insightful

      That is what comments are for.

      No it isn't.

      Seriously I see stuff like this in legacy code all the time:

      // Add one to the iterator
      i--

      Comments lie, code doesn't. Someone is going to update the code and not bother with the comments.

    5. Re:There's a reason nobody talks about it by cyborg_zx · · Score: 3, Insightful

      True - there are many crap programmers around; but that is what things like code reviews should be for.

      Absolutely but I don't get to review every line (although I certainly try because I often wonder WTF is being check in other people's code reviews) and I can't do much about the code that was written years ago that has been left to bitrot.

      If you find a programmer who does that sort of thing do you want to continue to employ him ?

      No, not really. But fucked if it's my choice or if I know where the hell the programmers are who don't do this stuff.

  2. Re:you had me at... by Anonymous Coward · · Score: 5, Funny

    Someone better go dig Strousoup out because he ain't dead, yet.

  3. Optionally typed by ThePeices · · Score: 5, Funny

    So if Dao is optionally typed, what are the other programming input options? Voice input? Graphical point n click input?

    1. Re:Optionally typed by Pseudonym · · Score: 5, Funny

      Surely I'd die of insanity before my conscience kicked in. Besides, "bind shoggoth" requires an import.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  4. Re:Do they have tail-recursion or lazy evaluation? by NeoHermit · · Score: 3, Interesting

    Tail-recursion: yes; Lazy evaluation: no. It does support some functional programming styles, at least as much as python or ruby supports. It's just that it is not branded that way. But if you are looking for a programming language that supports functional programming as its major programming paradigm, this is not the language you want. But certainly this is not the reason to dismiss it as failure.

  5. Re:you had me at... by dbraden · · Score: 5, Funny

    Sttroustrup ( you know youm could have gotten the name right )

    You sure you wanna be correcting folks?

  6. Re:you had me at... by girlintraining · · Score: 3, Interesting

    Way to fight the chauvanistic stereotype of girl geeks as dilettantes.

    I fail to see how making an educated assessment of the value of a new programming language meets the definition of a dilettante. I know of many geek girls (yes, girl comes second, we are geeks first and foremost -- pay attention Anonymous Coward, there will be a test) who know nothing of programming yet nobody would question their overall geekiness. Perhaps you're unaware that there's more than one kind of geek? I have one friend who's an art geek. She spends her days painting, sketching, and is a consumate book worm. I enjoy her company and her passion quite a bit. She has about as much computer sense though as a door mat and I have to fix or reimage her system on a seasonal basis. I don't begrudge her not knowing computers though; Not everyone can be a computer geek.

    --
    #fuckbeta #iamslashdot #dicemustdie
  7. Re:Feature complete with a small runtime? by Pseudonym · · Score: 5, Funny

    The Dao that is feature-complete is not the true Dao.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  8. Re:Do they have tail-recursion or lazy evaluation? by Greyfox · · Score: 5, Insightful
    Optional typing is not highly desirable. Everyone got all starry-eyed when they talked about how object oriented programming would allow you to have a container of objects and you could just put any arbitrary object into the container. Which is a great idea as long as you don't really think about it. Eventually you have to know what kind of object you're holding and you actually to use it to do some real work. The same thing goes for functional programming. Eventually you need to know what kind of data you're operating on, and you actually have to operate on it to do some real work. When the time comes to do some real work, you quickly realize just how much of a mess optional typing makes of your program.

    I've looked at a lot of code over the years that pushes the actual work to be done around like a two-year-old pushes peas around a plate. I've gotten to the point where I can read the mind of the programmer through the code he's written. He's thinking "If I push this over here maybe it will magically go away and I won't have to deal with it." Most of the time this is because he doesn't actually understand the business logic behind the code he's writing. He's writing to a series of requirements but he has no understanding of why the requirements exist or how they drive the business. So he tries to keep his code abstract as possible and hopes that no one notices.

    Sadly no one has yet written a language that forces you to actually understand the problem domain that you're coding. I'm sure it wouldn't be very popular if anyone ever did. Neither has anyone actually managed to write a language that allows you to write useful code without understanding the problem domain, and no one ever will. Now if someone could write a language that a non-programmer who understands why he needs code written to describe what needs to be done directly to the computer, that might fundamentally change my job description. Given that most of those people obviously can't even express this to another human being (Judging from their requirements docs,) I'm not losing any sleep over it.

    What the people who flit from language to language or framework to framework like bees are looking for is a tool that allows them to write code without understanding a problem. Someone who actually understands the problem will always outperform them in any given language. In other words, just because your language has an expressive syntax or any specific feature doesn't mean you can hire chimpanzees to code your application.

    --

    I'm trying to teach myself to set people on fire with my mind... Is it hot in here?

  9. Re:you had me at... by phantomfive · · Score: 4, Funny

    "concurrent programming" to me could even mean using two keyboards.

    Best misdefinition ever.

    --
    "First they came for the slanderers and i said nothing."
  10. Re:you had me at... by mwvdlee · · Score: 3, Insightful

    Strousoup doesn't exists, Stroustrup is still alive.
    "Optionally-typed" does not exclude type casting.
    Compiled languages have runtimes too.
    I think with "concurrent programming" they mean the widly accepted term "concurrent programming" http://en.wikipedia.org/wiki/Concurrent_programming
    Most popular programming languages have a C programming interfaces, including the ones you'd probably call "complete".

    --
    Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  11. Re:you had me at... by Pseudonym · · Score: 5, Funny

    That's called "agile".

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  12. Re:you had me at... by NeoHermit · · Score: 3, Interesting
    I was seriously trying to reply to your comment, but the more I read it, the less sense it makes. Where I start? Let's see:

    Dao is an optionally-typed programming language

    ARRRRGH! Comeon guys, type casting is so important even answers.com has a bloody writeup on it. Strousoup is right now spinning in his grave so furiously I'm sure it's causing a small earthquake right now on some pacific island...

    Do you really know what is optional typing (and type inference)? Otherwise you wouldn't be using the tiny example in that link as an argument against optional typing.

    that supports many advanced features with a small runtime.

    Runtime? So it's like Java then... it's interpreted. Ooookay, well, I suppose runtime languages have their place amongst the honored...

    As others already pointed it out, runtime is not just for interpreted language.

    The feature list is probably as long as that of Python

    And already we have our first example of why type casting is important: The programmer/submitter here isn't sure what the feature list of the language is, because everything is represented as an abstract object. /snark

    I don't see your logic here.

    Built-in support for concurrent programming for multicore computers,

    I'm not entirely sure what that even means. Does it support threading? Is it stackless? Are you talking about the ability to set processor affinity for a given thread or process? "concurrent programming" to me could even mean using two keyboards.

    Seriously, what do you expect? "set processor affinity for a given thread or process"??? Maybe "on" is a better preposition than "for" here, but anyone know about concurrent programming should understand what it really means immediately regardless the preposition.

    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.

    So basically, your language is incomplete so you're giving people the ability to link in stuff to makeup for it. Okay, that's cool... I guess.

    So in your opinion, any language that has interface to C or another language is incomplete. Do you also think any language that has external libraries is also incomplete?

    It's understandable that people like to bash new languages, but if you do, please make some more solid points.

  13. Re:you had me at... by Pseudonym · · Score: 4, Informative

    It seems that way because on a typical platform the C virtual machine is a very thin layer on top of the operating system and CPU. Its implementation is almost all initialisation and shutdown, and even then there's usually very little to do.

    If you don't believe me, I suggest you try it. Even if you don't use the standard entry point (avoiding the need to process argc/argc/envp) or exit point (avoiding the need for atexit), at the very least you'll need to set up a stack before you transfer control to C code for the first time. That is initialising a virtual machine.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  14. My opinion and some free unsolicited advice ;-) by aaaaaaargh! · · Score: 4, Interesting

    Okay, so here is my uninformed opinion and some free unsolicited advice ;-)

    First of all, some people here are just too defeatist. Yes, it looks a lot like Go and has only few exceptional features, but it's certainly not the worst programming language I've ever seen and e.g. seems to be overall better than Python - if we ignore, for the time being, the external library support which makes Python so great. I agree with others that optional typing is a bad idea, though. Many optimizations will be hard to implement in future and loose typing should be explicit (as e.g. in polymorphic types).

    Since I'm sort of a hobby programming language enthusiast, working on my own toy language in my spare time, there is one annoying thing I must mention, though. Why do so many contemporary language designers choose C-style syntax and not Algol/Pascal/Ada style? Just because they know C best? All of these C-clones, each of them with their own little quirks and specialities, don't really make the syntax more compelling or easier to read. (It would be okay if they behaved exactly like C, I guess, but then they wouldn't be languages on their own.) Why not go for block-style syntax or the Python wite space route instead?

    Take a look at Ada, for example. Yes, I know, the syntax is verbose and has to many double-uses of keywords. It is a bit archaic. However, on the bright side, Ada programs really are extremely readable. You can easily scan through GNAT's source code and understand how the packages work without looking at additional documentation! I'm not saying, "Hey, let's all switch to Algol-style syntax", and not everybody likes the way Python deals with white space either, but a little bit more variation would be nice.

    Which brings me to another issue. If you invent a new language, please make sure twice already in the design phase that it can be optimized later. Nothing is more annoying than an overall nice language that also becomes popular, only to turn out to be basically unoptimizable later. If a function has no side effects, if a data structure is immutable, if instructions or data structure traversals can be executed in parallel, please give us a way to indicate that within the language unless it can be inferred automatically. At least in theory, a new programming language ought to be capable of being as fast as C[1], Fortran, or Ada. Otherwise you could just save yourself lots of trouble and translate it to C++ or SBCL right from the start...

    Footnote [1]: To be taken with a grain of salt. Arguably, C is the the first in the list only because of extensive compiler optimizations not because of its language features.