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

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

Comments

There's a reason nobody talks about it

[antifoidulus]

It's basically Go with fewer features, next!

Re:There's a reason nobody talks about it

[NeoHermit]

You must be joking! Dao has almost all the major features that Go has, not vice versa. Just mention a few: tasklet (goroutine in a different form), channel, defer, defer-recover, interface etc.

Re:There's a reason nobody talks about it

[Anonymous Coward]

It's basically Go with fewer features, next!

Yeah Next is an awesome language

Re:There's a reason nobody talks about it

[complete loony]

FYI, your Documentation link in the beta release announcement just jumps back to the beta announcement.

Re:There's a reason nobody talks about it

[Anonymous Coward]

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.

Re:There's a reason nobody talks about it

[Anonymous Coward]

It's basically Go with fewer features, next!

You must be joking! Dao has almost all the major features that Go has, not vice versa.

Do you need to use the features of Dao to get output like this from a given input?

Re:There's a reason nobody talks about it

[__aasqbs9791]

You must be joking! Dao has almost all the major features that Go has...

Maybe this is a Whoosh! moment for me (it is late and I'm getting sleepy), but isn't your comment the same thing the OP said, just in another format? Yet you seem to be disagreeing with him?

Re:There's a reason nobody talks about it

[Anonymous Coward]

Lisp?

Re:There's a reason nobody talks about it

[rthille]

NeXT wasn't a language, it was a computer. Objective-C was the language...

Re:There's a reason nobody talks about it

[NeoHermit]

Please don't forget the "not vice versa" part, Dao has many features that Go does NOT have.

Re:There's a reason nobody talks about it

[NeoHermit]

Thanks for pointing it out.

Re:There's a reason nobody talks about it

[NeoHermit]

Just in case you still cannot deduce what I mean from my comments, I will just say it plainly:

Dao has a lot MORE features than Go does!

Re:There's a reason nobody talks about it

[Anonymous Coward]

He's the submitter.

Re:There's a reason nobody talks about it

[Anonymous Coward]

*woosh*

Re:There's a reason nobody talks about it

[Anonymous Coward]

Please implement a propper sandboxing and I dump C# and Python for Dao as my weapon of choice.

Re:There's a reason nobody talks about it

[Anonymous Coward]

That's not what you said.

I mean - You've got to be joking! You didn't say that!

As was pointed out - you just rephrased what you were supposedly denying.

Given it's an optionally typed language with a small run time - it must be similar to VB3 then. Right?

Re:There's a reason nobody talks about it

[Anonymous Coward]

For the most part, your wish list sounds like Perl. I don't know of a way to get automatic compile-time type checking on objects, but you can use the isa() object method to explicitly check the type of any object.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Scala's biggest problem is that it's OO and has subtyping. Records as seen in Haskell and Clojure and parametric polymorphism get you practically all of the benefits of OO without most of the drawbacks.

Re: There's a reason nobody talks about it

[Anonymous Coward]

You've just described D.

Re:There's a reason nobody talks about it

[Anonymous Coward]

> Java's OO model isn't bad as a start;

Yes it is. There is absolutely no reason to use interfaces as your primary multiple inheritance model. Saying "traits are optional, interfaces are sufficient" is the same as saying "closures are optional, functions are sufficient". Yes, you can do most things with one over the other, but it always boils down to crazy workarounds (via manual process or boilerplate) to trick the compiler into something it should have already been able to do.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Not exactly known for its strong typing, unless you consider that 'everything is an atom or a list' is strong enough for anybody.

Re:There's a reason nobody talks about it

[White Flame]

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.

Re:There's a reason nobody talks about it

[Pseudonym]

I suspect you might want O'Caml semantics with a more modern syntax.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Visualbasic?

Re:There's a reason nobody talks about it

[NeoHermit]

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 you sum the features of C, C++, Java, Groovy, Scala, Clojure, and Haskell, I am pretty sure they can do everything Dao can. But individually, Dao can do something they cannot (at least not as conveniently) do, for example, do they have parallelized code section methods (http://daovm.net/help/en/dao.tutorial.concurrent.html)?

Re:There's a reason nobody talks about it

[gigaherz]

Check C# 5.0, it meets most of the requirements in some form or another. Lambdas, Linq's meta-expressions and dynamic runtime allow for something rather close to functional and untyped code, the Generics are much nicer than java's and THe major feature of C# 5.0 is the async keyword for concurrency.

Re:There's a reason nobody talks about it

[chris.alex.thomas]

he should have added h) readability, I need to read it back to myself in 6 months time and understand it.

Re:There's a reason nobody talks about it

[Alain Williams]

That is what comments are for.

Re:There's a reason nobody talks about it

[devent]

You should look more in Groovy because that is basically the feature set of Groovy.

Re:There's a reason nobody talks about it

[cyborg_zx]

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.

Re:There's a reason nobody talks about it

[Alain Williams]

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

True - there are many crap programmers around; but that is what things like code reviews should be for. If you find a programmer who does that sort of thing do you want to continue to employ him ?

Re:There's a reason nobody talks about it

[stjobe]

he should have added h) readability, I need to read it back to myself in 6 months time and understand it.

Perl is only as (un)readable as you make it; if you write readable Perl code, you won't have any problems reading and understanding it 6 months later.

But yeah, you can write unreadable Perl code - but then again, is there any language in which you can't?

Re:There's a reason nobody talks about it

[Anonymous Coward]

Perl: the expressive power of gibberish combined with the readability of gibberish!

Seriously, you CAN write maintainable code in just about anything, but why would anyone want to write in a language which makes that so difficult?

Re:There's a reason nobody talks about it

[Anonymous Coward]

But yeah, you can write unreadable Perl code - but then again, is there any language in which you can't?

Whitespace. I've never seen unreadable Whitespace code.

Re:There's a reason nobody talks about it

[serviscope_minor]

f) Garbage-collected. I used to do malloc()/free() and new/delete, but I'd rather have the underlying language handle objects for me.

What is this language of which you speak that requires new/delete use and does not manage memory for you. It sounds suspiciously like C++ circa 1995, but I can't see why anyone would be doing that in 2013.

BTW: C and C++ actually can work with a garbage collector, it's just that support is not built into the language. GCC, for instance was a very large C program using the Bohem collector and is now a very large C++ program using the Bohem collector. It has more false positives of course, but it certainly does work.

Re:There's a reason nobody talks about it

[Antique Geekmeister]

And comments can be true while code is completely wrong. I've found, far too often that developers who say "read the code" have written complete nonsense. If the code is at complete variance with the comments, then it's a helpful warning that _both_ are wrong.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Look man, nobody fuckin cares about your crap toy language du jour.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Check out Fantom: http://fantom.org/ I think it covers almost all your bases.

Re:There's a reason nobody talks about it

[TheDarkMaster]

I would add the ability to be able to deallocate memory in a exact moment where you considered necessary. Garbage collection is ok, but in some situations I needed more control over when to release memory.

Re:There's a reason nobody talks about it

[Kielistic]

Well if the criteria is "I can do whatever I want whenever I want" I would think readability would be impacted without a lot of care.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Gotta back this up, C# does a lot of what you've asked for.

Re:There's a reason nobody talks about it

[T.E.D.]

The Dao that can be talked about is not the True Dao.

Re:There's a reason nobody talks about it

[jbolden]

Functional, when I want it. But not Scala-functional: more like Haskell or Clojure functional.

Haskell's functional model requires absolute purity to work. The compiler and runtime has to know what functions can be executed in arbitrary order and which must be executed in order. You can't have that when you want it, it is either on by default or doesn't work at all. Clojure's model is nothing like Haskell's. It just wraps Java calls in LISP syntax plus gives you access to powerful LISP constructions.

Scala does precisely what you are asking for. Includes some neat functions from Functional Programming that don't require you buy into the paradigm.

Re:There's a reason nobody talks about it

[cyborg_zx]

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.

Re:There's a reason nobody talks about it

[cyborg_zx]

And comments can be true while code is completely wrong.

Well... no. Code is always going to do what it's going to do. If someone failed to do what was actually intended for the program that's a whole other set of problems where you're asking who checked the implementation and why it passed testing (assuming it went into production).

I've found, far too often that developers who say "read the code" have written complete nonsense.

You have to be able to read code though at some point - you really can't know what is going on for sure unless you do. If someone is producing an unpenetrable mess of code with no documentation under the idea that documentation is not necessary because the code is there then they have two problems. I only tend to comment code itself when something unintuitive is being done that I wouldn't expect anyone to really be able to see at first. Commenting simple loops and such - the stuff that should be the bread and butter of much development - shouldn't be necessary. If it looks complex decompose it into separate functions as much as you can and give them a name invocative of their function. You might even generate an opportunity for code re-use! Documenting an API is a different matter -and that doesn't have to mean you write libraries for drivers or something, just that you're producing something that you expect other people to be able to use without having to modify what you've provided.

If the code is at complete variance with the comments, then it's a helpful warning that _both_ are wrong.

And that someone is hankering for a spankering.

Re:There's a reason nobody talks about it

[tolkienfan]

Wouldn't it be better to write in a language where simple things DON'T need commenting?
Otherwise you're coding twice, once in Perl and once in English (probably).

Re:There's a reason nobody talks about it

[Hognoxious]

Ok, it's what good comments are for.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Discipline and well-thought comments do that.

Re:There's a reason nobody talks about it

[drinkypoo]

Seriously, you CAN write maintainable code in just about anything, but why would anyone want to write in a language which makes that so difficult?

Your comment will have merit as soon as you demonstrate why perl makes writing maintainable code more difficult than any other typical language.

Re:There's a reason nobody talks about it

[PmanAce]

Yes, even my old game company was doing some game engines using it.

Re:There's a reason nobody talks about it

[Alain Williams]

No. We are not talking about the same thing. You are talking about line by line comments that say what actions the code is doing; in general someone competent in the language should be able to read/understand the actions[**]. The more important comments are about why the code is doing something, ie the purpose - you need comments like that in whatever language you use.

[**]: but there will sometimes be occasions where a complicated RegEx, or something, needs explaining.

Re:There's a reason nobody talks about it

[DickBreath]

> I would add the ability to be able to deallocate memory in a exact moment where you considered necessary.
> Garbage collection is ok, but in some situations I needed more control over when to release memory.

In Java, the closest thing I find to immediate deallocation is to be sure that one function, or even one inner set of curly braces has a variable which is the only reference to some large structure, and then set that variable to null to make the structure unreachable. At that point, it is in the hands of the GC. If memory pressure is not high enough to cause the GC to deallocate the structure, then it didn't matter anyway. Otherwise, the GC will reclaim the memory.

It is indirect "deallocation" at best. You must be sure you have only one reference to the structure you want to deallocate. I find it helpful to confine the only reference to the structure to be a single variable within the scope of some pair of curly braces. Either the curly braces of the function it is within, or some inner set of curly braces within the function.

I have often wondered when using an inner set of curly braces within a function if simply letting the variable go out of scope when the closing curly brace is reached is enough to make the structure unreachable. It might not be. Depending upon how the compiler, and the JVM behave (and the JVM is amazingly sophisticated) the variable may or may not continue to exist within the stack frame, but simply not be visible to other code within the function but outside of the curly braces where the variable was defined. So I expressly set the variable to null before the closing curly brace to ensure that my only reference to the structure disappears. It is important to pay attention that you did not inadvertently make some other reference to the root or other internal part of the structure you want "deallocated".

Re:There's a reason nobody talks about it

[DuckDodgers]

For your part h), see also SBT, the Simple Build Tool for Scala, with operators
Items I think you're missing:
i) REPL for rapid exploration of language features.
j) If the language is compiled, fast compilation times. This to me is a massive reason to prefer Go and D to C++ when you're building something that has to be near C++ for speed but does not need to hook deeply into existing C++ code.

I also disagree on your need for strong static typing. Let's say you have some kind of object with functions doX and doY and some functions that manipulate those objects. Then you interface with a third party library that happens to have objects that also have doX and doY you should be able to use interchangeably with your functions and objects. In the world of Java and C#, you need to make a common interface and recompile the whole set, including the third party library, to get that to work. With Scala, you can work around it by using implicit conversions but it's still an added layer of complexity. In Python, Ruby, Perl, PHP, or Clojure, it just works. Sure you can screw up and have type errors - but you're three days into writing your unit tests when the Java/C#/C++/Scala guy is still defining his damn interfaces.

Re:There's a reason nobody talks about it

[DuckDodgers]

Dammit, Slashdot scrubbed out all of the overloaded operators in SBT. They include percent, percent-percent, less than less than equals, colon equals, less than colon equals, less than plus equals, and probably others - those are only the ones I've encountered so far. You can write a tremendous amount of build configuration with a very tiny SBT build file, but I think it starts to look like intentionally obfuscated Perl.

I think operator overloading is generally a good thing, it allows things like defining natural syntax for complex numbers or the quaternion group or matrix libraries or whatever. I think languages should allow it, or something roughly similar. But it's easy to overuse the feature, and in my humble opinion the Scala Lift project and SBT do. It's especially a problem because most search engines don't work well with characters outside of alphanumeric. You have to remember to use SymbolHound or something similar to figure out what the hell all the fancy characters mean.

Re:There's a reason nobody talks about it

[DuckDodgers]

That's not strong typing, though. Is it? You can do Object Oriented things with Common Lisp, but my understanding is that Lisp will just crash at execution time if you pass the wrong kind of reference into a function. You also can't do, as far as I know, one aspect of Object Oriented programming: information hiding. At least, as far as I know. Now I have read that most Lisp gurus would argue that information hiding is overrated and that if you can't trust the people calling your code to use it properly, that's a human resource problem and not a programming language problem.

Re:There's a reason nobody talks about it

[Anonymous Coward]

"mainstream alternative languages ... Groovy, Scala, Clojure, or Haskell"

excuse me?

Re:There's a reason nobody talks about it

[Anonymous Coward]

Wouldn't it be better to write in a language where simple things DON'T need commenting?
Otherwise you're coding twice, once in Perl and once in English (probably).

Clearly you never learned how to properly comment code. Code commenting should complement the code with information that it is not obvious to get from the code.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Perl6

Re:There's a reason nobody talks about it

[chris.alex.thomas]

I agree with this, you need to write code which is not a impenetrable mess, I don't mind lack of comments, what I mind is lack of structure, that hurts much much more, because sometimes I want to understand the algorithm and the comments are fine, but doesnt help me understand the actual code in the file, line by line.

which sometimes, is important.

Re:There's a reason nobody talks about it

[chris.alex.thomas]

of course, you should avoid writing code which is not obvious, but sometimes this is impossible, so comments are useful.

something I've been doing, is writing code notes about thoughts i've had in relation to the code which generates the thought, so I can write things like // NOTE: this function looks easy, but internally it's doing too much work, I need to break it into chunks

then over time, they can accumulate, get deleted, add more and become a sort of meta-layer allowing people to understand things I've thought in relation to the code written, it's working out quite well so far....would be better if I didnt need to do it, but well, whatever....

Re:There's a reason nobody talks about it

[chris.alex.thomas]

I think due to perls nature, it skews people in the direction of writing unreadable code, easier than other languages, so even though it's not perls fault, people learn bad habits, combine them with shortcuts, sidestep techniques, workarounds and ways to reduce the code length and before you know it, you're the only one which can understand the code.

thats my experience from reading other peoples perl code. the language is so flexible, it allows you enough rope to hang you with...

Re:There's a reason nobody talks about it

[Anonymous Coward]

So, C# then?

Re: There's a reason nobody talks about it

[Anonymous Coward]

So basically: Objective-C 2.0

Re:There's a reason nobody talks about it

[tolkienfan]

That's exactly my point. Perl is unreabable IMO.

I avoid commenting. Most code is obvious without comments - except in Perl.

Re:There's a reason nobody talks about it

[Frederic54]

Eiffel maybe?

Re:There's a reason nobody talks about it

[rawler]

Tried D 1.0? I reasoned the same way, and spent a lot of time coding D. In the end, I had to admit that a staggering percentage of bugs in my code came from just this. Deleting objects where a reference had leaked somewhere, deleting objects from the GC-called destructor of an object, mixing manage and non-managed objects a bit too freely ...

For D 2.0 I think most of that is rewritten, but I haven't bothered due to some sour experiences in D 1.0, and a slight dislike for some Phobos API:s and project management.

Basically IMHO for non-GC, simple memory management, I think language features for tracking ownership and the mindset that comes with it is necessary. For example, just like you have argument-modifiers for immutable arguments in some languages (C++ const), so I think you should have an argument modifier saying "you do not own this referenced object, and you are obliged to not remember the reference after return;".

Rust seems to have some interesting ideas regarding this, but I haven't really tried it for anything non-trivial.

In the end, I do most of my systems-level coding in C++ again. It's far from ideal, but it works, and with the smart-ptr classes available now, it's lack of GC is mostly a non-issue.

An interesting side-effect of the C++ helpers for deterministic object lifetimes, is the ability to tie resources (more scare than RAM) to the lifetimes of the objects. For example, keeping a file-struct as a member in a class will hold the file open for the lifetime of the class, but automatically ensure it is closed when the class is. In for example Java, you may very well run out of file-handles before the GC even kicks in and looks for objects to kill.

Re:There's a reason nobody talks about it

[m6ack]

Perl is only as (un)readable as you make it; if you write readable Perl code, you won't have any problems reading and understanding it 6 months later.

But yeah, you can write unreadable Perl code - but then again, is there any language in which you can't?

I for one am certain I can write unreadable code in Perl better than any other language I know... I am "fully enabled" -- encouragingly so -- in the language for the illegible to the limit that such is inevitable.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Also nice: Optional implicit typing. Not the ridiculous var/auto-way but more like Haskell.
Optional, because type notations are good documentation in some cases.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Exactly. Groovy (and, by extension, Grails) meet those needs extremely well.

Re:There's a reason nobody talks about it

[Anonymous Coward]

True, but programming in Lisp is like programming in an XML based language: Same shit, different brackets.
That is, if lt and gt count as brackets.

Re:There's a reason nobody talks about it

[Anonymous Coward]

If that's your standard, with Java Reflection is more like "Information Forgetfulness" than "information hiding".

Re:There's a reason nobody talks about it

[TheDarkMaster]

you may very well run out of file-handles before the GC even kicks in and looks for objects to kill

Is precisely such situations that make me want to have the means to decide the time that an object should be removed immediately from memory, rather than wait for the GC take care of it at some point. Normally the GC is acceptable (although I actually do not like the idea), but there are times when I have to perform some task that consumes huge amounts of RAM and where I know exactly when this memory can be released. And if I left under the care of the CG, the system memory would be devoured in seconds before he had a chance to act

Re:There's a reason nobody talks about it

[Anonymous Coward]

C#?

Re:There's a reason nobody talks about it

[Anonymous Coward]

...Dao has many features...

Features Go intentionally doesn't have. Go takes the less is more approach. If you can get the job done comfortably, with or without a big team, and with as little pain as possible, then you shouldn't add to it.

Maybe I'm just not leet enough for you, but I feel mastering a language properly takes many years and I just don't want a huge language with a million features I only need for job interviews.
If it means writing an extra loop instead of that momentary head-scratching pause when reading generics, I'm fine.
If it means copy-pasting a half-dozen lines today instead of inheriting a class that breaks a method tomorrow, I'm fine.
If it means writing in a fixed style format instead of fighting the syntax wars over and over again, I'm fine.

That's what Go feels to me. It's not a great language. It's not terrible one. Sometimes I miss some shiny bit from C++ or Java, but then I look at my code and guess what ? Overall, I'm fine.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Wrong, comments are for explaining WHY the code is doing what it is doing, the code should speak for itself as to what it is doing.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Ah, I get it. You want a programming language for morons. You already have these. They are called Java and C#.

Re:There's a reason nobody talks about it

[Bill, Shooter of Bul]

The point that is being discussed here, is that it takes a lot longer to understand the particular actions with perl than most other programing languages. The general purpose of what comments should be used for is a different discussion.

Re:There's a reason nobody talks about it

[Bill, Shooter of Bul]

My first professional job was in perl. And I knew how to write readable perl, so I did. And the lead dev marked the hell out of it, and required that I re write it in the cannonical unreadable form. I think with the true perl beleivers, the more illegibile the code is, the better it is. ( well not really, but their is a zen of perl, which gave rise to the perl monks. And that zen is almost indistinguishable from garbage.)

Re:There's a reason nobody talks about it

[maxwell demon]

Comments are for the stuff you can't read from the code.

Bad comment:

// calculate the square root of E/m
v = sqrt(2*E/m);

Good comment:

// calculate the (absolute) velocity of the particle
v = sqrt(2*E/m);

Re:There's a reason nobody talks about it

[maxwell demon]

Perl6

So how many years remain until it's ready? ;-)

Re:There's a reason nobody talks about it

[angel'o'sphere]

Setting a local variable to null "to help the gc" is complete nonsense.
The GC will claim the object regardless ...
Best case you only waste time by having unnecessary assignments, worst case you anoy your co-workers who stumble over that nonsense.

Re:There's a reason nobody talks about it

[ultranova]

Depending upon how the compiler, and the JVM behave (and the JVM is amazingly sophisticated) the variable may or may not continue to exist within the stack frame, but simply not be visible to other code within the function but outside of the curly braces where the variable was defined. So I expressly set the variable to null before the closing curly brace to ensure that my only reference to the structure disappears.

But even a relatively dumb compiler would simply optimize that assignment out, since it has no consquences - the variable goes out of scope, so it can never be accessed again. And for that matter, a sophisticated compiler could and probably should realize that the variable is never used past its last occurrence, so the space should be reused.

But why would you even bother? If the object holds some external resources, use try-finally to ensure they're released in a timely manner; if not, if it's just memory, let the JVM manage it. The JVM is, after all, "amazingly sophisticated", so any attempt to second guess it will likely just slow things down, especially since you don't - according to yourself - really know its inner workings that well.

Re:There's a reason nobody talks about it

[angel'o'sphere]

I know plenty of programmers who used to be perl hackers and now stopped using the language for new projects.

I don't work with perl anymore either ... much to many obscure behaviour, in fact you need to know to much to use it efficient.

Re:There's a reason nobody talks about it

[angel'o'sphere]

Objective-C is the language.

Re:There's a reason nobody talks about it

[DuckDodgers]

Yes, reflection lets you get around private/protected/default visibility in Java. But it's a bit more work than in Lisp, when you can muck with the innards of whatever it is you're using directly.

Re:There's a reason nobody talks about it

[DickBreath]

First, I agree it is generally not a good idea. I thought I mentioned that I only did this rarely. But I think I failed to say that. I only do this null assignment rarely (I think only once, maybe twice, in a project I've been on for years) when there is a large structure, and I mean large, and I want to get rid of it before entering some other significant operation where it is no longer needed.

Your statement that the GC will claim it regardless would depend upon the implementation of a lot of things. It would be necessary for the JVM to know that this local variable, which holds a pointer to a large structure, is actually no longer referenced in the rest of the current method, even though the variable is in scope and non null. Then the GC would need to know that and consider that this actual reference from the stack is really no longer part of the root set because the local variable won't be used in the rest of its current method. While I know that Sun/Oracle's JVM might do this, as it already does many other amazing things, I didn't want to assume that all possible implementations might do it. I didn't even want to assume that the non hotspot "client" JVM might do it.

Re:There's a reason nobody talks about it

[DickBreath]

I know the JVM is amazingly sophisticated. The JIT. The inlining. The re-compiling of inlined functions if the class they came from is changed on the fly. And other amazing things the JVM does.

The object does not hold external resources. It simply is large. I do generally let the JVM manage the memory. That's what GC is for. But there are a lot of optimizations that have to line up right for this particular case to happen automatically. A local variable holds a reference to a large structure. At some point, the last reference to the local variable has been made, and the structure it points to is no longer needed. But the GC can see that the local variable is on the stack and part of the root set. Now the compiler and/or JIT compiler might recognize when there are no more references to a local, or it falls out of scope, and thus arrange things so that the GC could recognize that this structure is now garbage. But I didn't want to assume that all implementations might.

Also see a sibling post I replied to right near yours. I should have mentioned that I do a null assignment like this very rarely.

Re:There's a reason nobody talks about it

[dkf]

my understanding is that Lisp will just crash at execution time if you pass the wrong kind of reference into a function

Not true, since the type of a reference is introspectable and the errors that are thrown can be trapped. It's up to the compiler to prove that it can omit the checks on a reference; a good reason for omitting a check would be when you know for sure that the check has already been done earlier in the function.

Re:There's a reason nobody talks about it

[dkf]

Ok, it's what good comments are for.

The GP's comment is a good comment; it proves for sure that a moron has been loose on the code in the past.

Re:There's a reason nobody talks about it

[angel'o'sphere]

You are mixing up a few things.

When the GC starts to reclaim memory, the GC knows all objects. Hence the GC easily can follow all references to those objects. Especially that there are only two kinds of references: objects referencing each other and references from the stack to those objects. (The root is the main method).

If you assign null to a variable on the stack, nothing happens. The GC is not called! The object still claims all the memory it had before. So your idea that you free memory here is wrong.

Finally there are GC optimizations where the runtime tracks if a local variable that got assigned to, is passed around or not. If the compiler can decide it is only used localy it generates information for the GC (don't remember how it is exactly called) to clean up those objects before the method returns. (And for that you don't need to assign them a null).

With some prints in a finalizer you can simply check this yourself.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Type system != strong typing at compile time

Re:There's a reason nobody talks about it

[Darinbob]

Yes there is information hiding. You have that even with non-OO Lisp (just stick stuff into atoms). Information hiding is such a tiny feature really, C++ doesn't really have it and still gets the nod as being an OO language. Sure, you can always go behind the scenes and access the data in ways that you should not, but that's true some other OO languages. The low level accessor functions are there for debugging and convenience, their existence does not magically prevent things from being object oriented anymore than a typecast that lets you read private data in C++ means C++ is not object oriented. And issues of information hiding really have more to do with Abstract Data Types than Object Oriented programming.

There was some solid object oriented Lisp before it was really a common programming paradigm. And the earlliest object oriented languages were strongly typed but w/o explicity typing, as in Smalltalk. Common Lisp of course has explicit typing, and it's strong typing. Yes, if you call a method for types that do not support that method, you get an exception or error (NOT a crash); same in Smalltalk, same in most dynamic OO languages. It's not required to have a compile-time error before a language can be called strongly typed.

You seem a few decades behind the times with Lisp, and also seem to be basing your definition of object oriented upon your favorite language's features.

Re:There's a reason nobody talks about it

[DuckDodgers]

I wrote poorly, I did know that Lisp has error-trapping. I meant in the case when an error is not trapped.

Re:There's a reason nobody talks about it

[Darinbob]

It's idealism versus reality/pragmatism. I suspect there are some people who do manage to work in the idealistic environment because I see people too old to be recent graduates say such things. Maybe they're independently wealthy and really do thing everyone can just leave a job where things are don't perfectly?

In practice, code reviews are superficial. No one has the time to spend more time reviewing code than it took to write it, and there's immense time pressure to resolve the issues and release the code. Yes there are some high profile places that do manage this, but places like Google are the exception and not the norm (and even there from my inside contacts, the corporate policies aren't actually being followed correctly).

Re:There's a reason nobody talks about it

[DuckDodgers]

I apologize for my errors. I had forgotten that you can work around the "private" access modifier in C++ with casts and in Java by using the Reflection APIs.

I should have clarified that your Lisp program will crash on calling a method on an inappropriate input only if you do not handle the error - no different than failing to check for exceptions in C++ or Java. My point was that the error happens at runtime, not a separate compilation step before running the program.

I'm a Lisp newbie, still trying to fill in the gaps in my knowledge.

Re:There's a reason nobody talks about it

[DickBreath]

I understand how GC works.

By root I meant "the root set". The set from which all reachable objects are traced by the GC.

If a variable in the stack references a large structure of objects, then those objects are inherently reachable. If that local variable is the only reference to those objects, then setting it to null suddenly makes those objects unreachable. As you say, it does not automatically call the GC. But that does not matter. If the next operations in the method eat up more memory, and memory pressure is great enough, then the GC will be called and those unreachable objects will be reclaimed. If the GC is not called, then it didn't matter to set that variable to null. But I am talking about making some large amount of data unreachable long before the current method is about to end. It is possible that the GC may be called and reclaim that data before the current method ends.

The local variable is passed to subroutines, but those do not make any other references to the large structure other than through the passed parameter. Then they return. So the local variable is used.

As I said, I have only have a situation like this very rarely. So the closest thing I could do to "dispose" of the data structure was to simply make it unreachable -- and hence eligible for GC. If I did not set that local variable to null, then those objects are not eligible for GC because they are still reachable via the stack. I hope all that makes sense.

I know that there are all kinds of optimizations built in. But I am not aware of any that take care of this particular case. I do know about the optimization you mention of a local that is not passed around and the compiler can prove becomes garbage immediately when the method exits. But again the definition of the problem here is that the method is far from exiting, but I want to make a large structure unreachable so it is a candidate for GC, if the GC needs to be called. (More likely GC is running as a thread.)

Finalizers won't help. There is plenty of documentation that finalizers may never even be run.

I have, and still to this day, consider whether the time I did this null assignment is a form of premature optimization. After all, what if the system never runs out of memory. But in this particular case, I did know that this large structure was no longer needed, so I assigned null to the local variable that pointed to it. Not a big deal. And not a common practice.

Re:There's a reason nobody talks about it

[White Flame]

I didn't say that it was strong typing. I was just countering the claim that Lisp is just atoms & lists.

Many decent Lisps do some form of compile-time type inference to give warnings about passing the wrong types as function parameters. This information propagates very well internally, especially with Lisp's super-rich declarative type system and run-time compiler.

Hiding fields in objects is typically done via package exports. If something isn't exported, you don't get the accessor by default. It's still there, and you can punch in package-private full names if you need from outside the package, but the effect of the public API having hidden those accessors is accomplished while not barring you from having good debugging access.

"Real" information hiding in Lisp can be accomplished through closures. If you use a form such as (let ((x 0) (y 0)) (defun ....) (defun ...)), then those functions can access x and y but there is no way from the outside, besides low level implementation-specific debugging tools, to gain access to them at all. There are OO systems in Lisp built on top of this "Let Over Lambda" style, but that's more a novelty that isn't very optimized.

Re:There's a reason nobody talks about it

[psithurism]

// Add one to the iterator i--

That's nothing. I see stuff like this in my...er...legacy code all the time:

// Add one to the iterator
if (!tested && c == find[0]) tested = true;

Re:There's a reason nobody talks about it

[Anonymous Coward]

Disclaimer: I'm a C++ zealot at my day job (mostly high-performance stuff) but much prefer Lisp where I can use it.

In Common Lisp, as in most Lisps, you have to try hard in order to invoke a crash. (basically turn off type checking and enable optimizations comparable to the C computation model) CL is strongly typed, and it is dynamically typed; so it is quite easy for a function to "throw an exception" when a parameter is of an unexpected type. While there are ways of statically typing code, the compilers don't bother with any real type checking across function calls; its not a priority because of low use, and use will stay low without the support...

The "Typed Racket" variant of Scheme does have static type checking, as do some other Lisp variants.

As for information hiding, CL makes it fairly easy to locate uses of internal fields, but it generally doesn't raise a fuss if you do. There are some ways of making them truly hard to leak (e.g. wrap variables in a lexical environment that is only visible to the internal functions). This is actually very similar to Python's self._foo and self.__bar convention.

For the major languages of today, I'd argue that any programmer who doesn't know how to easily bypass their language's "protections" isn't very good yet. (hint: edit a header here, use reflection there, etc.) This ability is an important skill for debugging and also for fixing "binary blobs" outside your control.

If you want something of a proper permissions model, take a look at Ada and Modula.

There are many aspects of OOP that aren't properly supported by C++, Java, etc. Instead, the user is expected to use "design patterns" to roll their own behavior. Look up Stroustrup's multiple dispatch paper for a classic example.

Re:There's a reason nobody talks about it

[cyborg_zx]

In practice, code reviews are superficial. No one has the time to spend more time reviewing code than it took to write it, and there's immense time pressure to resolve the issues and release the code.

I'd really be surprised if that were the case and I'd have to say you'd be doing it wrong - taking 8 hours to implement something doesn't mean you have 4 times as much code as something that took 2 hours to do - that would be the classic KLOC analytical approach to programming mistake. Also nothing says a code review is a one way thing - generally I'm looking for obvious deficiencies: can I read this code and actually understand it, and if I can't after spending a little time penetrating it can it be explained to me in understandably? If not it probably requires more work. Have you applied the style guidelines and if not why not (the Brown M&Ms test). Does this code do exactly the same thing I know something else is already doing? And as these are all questions not statements it implies that the person whose code I am reviewing should have good answers if they expect it to pass my review.

You may see it as a waste of time that could be spent coding more stuff to fix more stuff - I see it as time spent not having to analyse code later when some piece of crap that wasn't properly reviewed causes a production issue and then suddenly everone has a real interest in the quality of the code. And given the frequency at which I see stuff that would have obviously caused problems down the line I think I've come to the right conclusion.

Re:There's a reason nobody talks about it

[DuckDodgers]

Thank you for the information.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Wouldn't it be better to write in a language where simple things DON'T need commenting?

You mean, like COBOL?

Re:There's a reason nobody talks about it

[Anonymous Coward]

Dao (and Go) do not solve programming problems better than other mainstream alternative languages.

What's a "mainstream alternative" language?

Re:There's a reason nobody talks about it

[Darinbob]

I'm not saying code reviews are a waste of time. I'm just saying that in real life in the corporate world they will often get rushed and short changed or even ignored.

Re:There's a reason nobody talks about it

[foreverdisillusioned]

Common Lisp has strong typing, it just isn't turned on by default.

The list of features Common Lisp lacks that other commonly used languages have is very short indeed, it's just that they aren't commonly needed. Full blown OO, for instance, is rarely needed if you understand how to use a closure, but if you do need it CLOS is more powerful than the vast majority of OO schemes: generic functions are strictly more powerful than message passing paradigm while also being more intuitive... they're just regular functions with pattern matching on the arguments. Also, new methods can be built on top of, underneath or around inherited methods (instead of simply overriding them.)

Re:There's a reason nobody talks about it

[cyborg_zx]

I'm just saying that in real life in the corporate world they will often get rushed and short changed or even ignored.

I can't help the companies I'm not part of to not do stupid things. I have my work cut out for me here.

Re:There's a reason nobody talks about it

[DuckDodgers]

Interesting. I had to read the wikipedia page on generic functions, because coming from a Java background I first interpreted "generic function" to mean "function that takes inputs that have parameterized types". That's nothing special, and clearly not what you mean.

I guess the interesting but sad question is why Lisp hasn't become the dominant programming language for any application that doesn't require C or Assembler performance. Still, maybe there's hope. Clojure is a relatively new but stable Lisp dialect that ties into the JVM ecosystem and it's gaining adoption. There's also an alpha-stage project to make a Lisp dialect "Hy" that runs as Python and ties into the Python ecosystem: http://gethy.org/. Maybe if pure Lisp can't take the world by storm, one of its children can. I would rather be working in Lisp, Clojure, or Hy than most other programming languages I know.

Re:There's a reason nobody talks about it

[foreverdisillusioned]

The best thing about Lisp IMO is the way it exposes the underlying mechanisms. This is most evident in its syntax and macro system, which makes you really think about scope and binding order and the full implications/uses/interactions between multiple lexical environments, but generic functions is another good example. Prior to Lisp I'd tinkered in C++ and Java and I'd always thought of methods as these vaguely functionlike things that were nonetheless quite different and inseparably tied to certain common OO paradigms. CLOS made me realize that a method is just a function that:

1. Is designed to always accept one object as an argument (silly and arbitrary limitation.)

2. Examines the type of its arguments to determine which version of the function to use. This is usually determined via a very rigid inheritence scheme, whereas CLOS treats everything as an object and allows you to specify completely arbitrary patterns to match, with the default behavior being to use the most "specific" (to the arguments' types) method available. Also, as I said before, you can chain together parent methods in arbitrary ways instead of having to choose to either overwrite or keep the parent method.

Regarding your question about the lack of Lisp dominance, the answer is both simple and sad. Programming language popularity is driven by a combination of novel coolness and the marketing powers that be, not merit. Also, "good enough" syndrome prevents many programming languages (and applications for that matter) from absorbing very minor, taken-for-granted features that newcomers will expect, so the learning curve becomes a lot steeper than it should be. In Lisp this takes the most obvious form of not giving noobs an easier sub-language that doesn't require constant use of parens. Lisp veterans recognize that explicit scoping is highly desirable in most cases and have trained themselves to read and type it easily, but this isn't of much consolation to a newcomer, especially if they are attempting to use an editor without proper paren matching or auto intendation.

You're probably right in Clojure being the future of Lisp, but this is a perfect (and very depressing) example of what I just explained. Clojure is inferior in every way to Scheme or Common Lisp except it runs on JVM and it has a few native concurrency features. The latter sounds nice but who the hell cares about native concurrency if your language is several orders of magnitude slower? Common Lisp has concurrency libraries. It is also a true compiled language and with proper declarations can made to run at around 50% the speed of well written C. The problem is, Lisp wasn't always so fast. It took decades to reach that point during a period when computers were really, really slow. (People actually needed hardware acceleration to run it at acceptable speeds: see "Lisp Machine") By the time it became fast enough, the cool kids had moved on, so the Lisp crowd had to sit back and watch the new generation painfully re-discover all of those amazing features like garbage collection, weak/optional strong typing, closures, etc. And they're still nowhere near where Lisp was a quarter century ago.

If you want to hear some more CL cheerleading and get a small taste of some of its powers that modern languages still can't touch, check out Paul Graham. His book On Lisp is available online now: http://www.paulgraham.com/onlisptext.html . If you find that interesting, Let Over Lambda is a very smug little book almost guaranteed to blow your mind: http://letoverlambda.com/index.cl/toc . Some of Hoyte's ideas seem demented, but others (especially regarding the role of syntax, referential transparency being overrated, and the right way to use lexical environments) are quite profound.

Re:There's a reason nobody talks about it

[Anonymous Coward]

As far as your list of "needs" goes, you are an idiot! Who is modding that up?!

Re:There's a reason nobody talks about it

[jonadab]

I think you just described Perl6.

At the current rate things are going, it may be just about finished in time for your grandchildren to use it.

Re:There's a reason nobody talks about it

[DuckDodgers]

I'll check out the books, thank you. I have read some of Paul Graham's blog posts before.

I think a point which you allude to is that most developers aren't willing to travel very far outside their comfort zone to learn something new. I believe James Gosling (the father of Java) said something to the effect that they were trying to pull C++ developers towards Common Lisp, and Java was as far as they could safely go.

Clojure has the practical advantage that it plugs into the JVM ecosystem. That's good for using existing libraries, but it's great for getting Java developers who wouldn't look at Common Lisp to give Clojure a try. Most of the tools in their arsenal (IDEs, Maven, Java Servlet Containers, etc...) are still relevant, so instead of learning a new ecosystem and a new syntax it's just some new syntax. But also, Clojure has immutability by default which you can work around as-needed - which I think is a good default to adapt, and seems to be a nice compromise between Scheme (which if I remember right has immutability everywhere) and Lisp. This could be the thing that pulls enough people into Lisp territory that many developers might get comfortable with Clojure and then decide the next step is Common Lisp. At least that's my hope for me. :)

I also don't think Clojure is "several orders of magnitude slower". If you look at benchmarks between a warm Java Virtual Machine (i.e. one that has executed a program long enough for the just-in-time compilation and optimization to kick in), it often uses dramatically more memory than an equivalent C++ program but generally executes within 2x of the time. ( e.g. http://benchmarksgame.alioth.debian.org/u64q/java.php ) Clojure isn't too far behind Java for performance, so I suspect against most equivalent Lisp applications Clojure is well within one order of magnitude for performance. Since that's nicely ahead of PHP, Python, Ruby, and Perl, and those four seem to dominate the internet, I'd say Clojure's performance is adequate.

Thanks for responding to me.

Re:There's a reason nobody talks about it

[foreverdisillusioned]

It depends on whether you're fully using Clojure's expressiveness. I'm not an expert on how JVM internals work but I'd be astonished if something with heavy use of first class functions or CLOS (assuming Clojure has a CLOS equivalent) ended up running within an order of magnitude of Common Lisp's performance.

I do know that Clojure's performance is not yet adequate on Android. Or at least it wasn't a year ago.

Re:There's a reason nobody talks about it

[Anonymous Coward]

The best part of Lisp is that if it does not have a needed feature built-in you can add it to the language in a first class way. In other words, you can add anything and it is indistinguishable from the language.

Re:There's a reason nobody talks about it

[Anonymous Coward]

A C++ or Java file will have more parens than a Lisp file of the same size.

Re:There's a reason nobody talks about it

[Anonymous Coward]

At the cost of being locked into a platform. Fuck that shit.

Anyone who shackles themselves into a proprietary platform are retarded.

Don't mention mono, because its .NET implementation is buggy and incomplete and it will be a long time when C# 5.0 is supported.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Groovy is a shitty language that targets the Java audience: aka mediocre programmers.

Re:There's a reason nobody talks about it

[Anonymous Coward]

"almost all"=="fewer features"

Re:There's a reason nobody talks about it

[Anonymous Coward]

Strong typing or static typing?

Hint: Ruby and Python are strongly typed, arguably more so than Java's shitty fucking verbose, nasty, broken type system.

It sounds like you need the crutch that static typing creates for subpar programmers. Note, that does not mean that only shitty programmers love static typing it means that shitty programmers like you use it as a crutch.

Re:There's a reason nobody talks about it

[Anonymous Coward]

Among other things, the biggest problem with Groovy and Grails is performance. Any site that gets more than 'noise' traffic levels will see the infrastructure cost growth rapidly approach the rate at which the U.S. National Debt has grown the last few years.

Wow, another programming language?

[Anonymous Coward]

Just what we need, yet another beta language with subset n of the hot new features de jour. wait up man, I haven't finished python, scala, groovy, golang, dart, the new C++ spec, and oh yeah C, since its now back in style, yet...

Re:Wow, another programming language?

[cgt]

No one is forcing you to use it.

Re:Wow, another programming language?

[Anonymous Coward]

And there is no reason not to comment on a "new" language. Especially when someone makes it out to be "the next big thing" and it obviously is not.

Re:Wow, another programming language?

[Pseudonym]

Especially when someone makes it out to be "the next big thing" and it obviously is not.

Who are you quoting?

Re:Wow, another programming language?

[davester666]

Well, hurry up and master Ruby. By that time, Dao might be close to being 1.0

Re:Wow, another programming language?

[socode]

and no-one is forcing anyone to read, respond to, or act on, comments

Re:Wow, another programming language?

[Anonymous Coward]

I'm put off by the documentation alone. Who thought it would be a good idea to format the docs in the style of FORTRAN?

Re:Wow, another programming language?

[Anonymous Coward]

How do you know that?

Re:Wow, another programming language?

[maxwell demon]

He's quoting Mr. Scare, I think.

Do they have tail-recursion or lazy evaluation?

[gweihir]

If not, then it is just another fail, as functional programming styles are not supported. From the web-page, it seems it is indeed just another failure.

If they had either, it would be a significant step in the right direction. Optional typing is definitely highly desirable.

Re:Do they have tail-recursion or lazy evaluation?

[NeoHermit]

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.

Re:Do they have tail-recursion or lazy evaluation?

[Greyfox]

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.

Re:Do they have tail-recursion or lazy evaluation?

[Pseudonym]

Optional typing is not highly desirable.

Maybe.

Strict typing a la Algol requires you to write more code (in the form of type declarations). Strict typic a la ML requires someone to write more compiler, which isn't a problem if you're shipping compiled code, but in a typical scripting scenario it requires there to be more compiler in your runtime and (more importantly) slows load time.

Dynamic/optional typing requires you to write more tests (unless you want less robust code, of course), but tests typically don't impose a cost at run-time. If you only need a thin layer of scripting glue, then the tradeoff may be acceptable.

I agree that it's not "highly desirable" as a general rule, but I can see the use case.

Re:Do they have tail-recursion or lazy evaluation?

[Austerity Empowers]

Two people who understand the problem, one with five tools in his belt, the other with one. The first guy is going to get the most return on his investment, the second guy will always have work.

Let's not waste time on the chimpanzees.

Re:Do they have tail-recursion or lazy evaluation?

[serviscope_minor]

ventually you have to know what kind of object you're holding and you actually to use it to do some real work.

I agree.

Fundementally all a computer does is manipulate data. The type of the data is the only thing that defines which maniuplations are possible and meaningful. If you aren't thinking about the types, then there is nothing you can do.

Of course, no one wants to be caught up in irritationg games to satisfy the compiler. This is why I really *really* like the look of concepts (and C++ templating which uses ad-hoc concepts).

Types become exactly defined by the semantics of their operations, i.e. if it's addable, it's a number. If it's dereferencable and incrementable, it's a pointer like thing, and so on.

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

Have you seen the size of Algorithm W (almost all of the ML type inference/checking system)? It's tiny!

Some things you are probably not aware of:
- type inference fixes the Algol problem of verbose type decorations;
- type inference is a fraction of the processing time of a compiler;
- you can save "proof carrying code" if you want to really speed up the checking process on load;
- type checks exclude WHOLE CLASSES of bugs for which you would otherwise have to write unit tests;
- strong, static typing allows compilers to emit vastly better code (seriously, .NET and JVM and whatever else are quite a bit slower because of inherent problems with the underlying OO type system, and they're strongly typed!).

Cheers!

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

"Sadly no one has yet written a language that forces you to actually understand the problem domain that you're coding."
Lisp?

"I'm sure it wouldn't be very popular if anyone ever did."
See, you knew it all along...

Re:Do they have tail-recursion or lazy evaluation?

[davide marney]

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.

Isn't that what COBOL claimed to be?

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

Types become exactly defined by the semantics of their operations, i.e. if it's addable, it's a number. If it's dereferencable and incrementable, it's a pointer like thing, and so on.

It's OOP as implemented by SmallTalk, where objects are meant to be thought of as computers that you send messages to, and they decide how to handle those messages. If an object responds to a message, then it's the correct type.

Re:Do they have tail-recursion or lazy evaluation?

[itsdapead]

"Sadly no one has yet written a language that forces you to actually understand the problem domain that you're coding."

Lisp?

True as long as the "problem domain" is lambda calculus.

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

That does depend on which tools are on each belt.

The guy who straps a screwdriver to his belt will win out the "unscrewing things" contest vs the guy with a chainsaw, a jackhammer, a multimeter, a soldering iron, and a vise. He'll also look less ridiculous and be in less mortal danger.

Re:Do they have tail-recursion or lazy evaluation?

[SpinyNorman]

I don't know what the case is with Dao, but optionally typed doesn't necessarily mean no type checking. For example, in Google's Dart, variables are optionally typed in the sense that if you choose not to statically declare their type then the type is determined dynamically by assignment - but they are stll typed.

Re:Do they have tail-recursion or lazy evaluation?

[Greyfox]

Learning Lisp is really what changed my thinking in this regard. Lisp is another one of those languages where you can store arbitrary objects (more parentheses) in lists. Objects in Lisp don't have a type, they're just lists. If you want to store different types of data in the lists you're storing, you have to write some code to look at the list and figure out what type of data each component of the list is. You can further break those components down, if you're so inclined.

Doing all this really is a huge pain in the ass, kind of like maintaining your own objects in C using structs and pointers to functions. You can do it, but it takes a fair bit of discipline. And most of the programmers I know don't have that kind of discipline.

Re:Do they have tail-recursion or lazy evaluation?

[Greyfox]

It tried to be, but it largely failed. People who don't program are't that great at breaking instructions down to that level. Not that they didn't try. There are still billions of lines of craptastic COBOL code out there. The difference in COBOL is that after it's written, trying to read it makes your eyes bleed whether it was written by a fantastic structural programmer or some manager somewhere.

Re:Do they have tail-recursion or lazy evaluation?

[Pseudonym]

I've been using Haskell for 20 years, and have written my own Hindley-Milner type inference systems. Believe me, I know this stuff.

What you may have missed is that I was talking in the context of a scripting layer for a larger system, which it seems clear from the writeup is an intended use for Dao. We're talking about Python or JavaScript rather than .NET or JVM.

Some reasonable assumptions of a scripting layer are:

• Scripts are shipped as source code and compiled at load time.
• Scripts are typically small compared to the system that they are scripting.
• Script load time must be as fast as possible.
• The memory footprint of the system as a whole must be as small as possible.
• Most of the time will not be spent executing scripts, but executing libraries or application subsystems called by scripts.

In a typical scripting system, execution speed is important, but not as important as keeping the load time and memory footprint low. It's difficult to see how Hindley-Milner type inference would be the right tradeoff in such an environment, at least most of the time.

Incidentally, don't forget the memory used by type inference, which can often rival that of the size of the AST of the program. (It's a reliable rule of thumb that in intuitionistic logic, the size of the proof and the size of the theorem which it proves differ by about a constant factor, and under the Curry-Howard correspondence, program is to type as proof is to theorem.)

The memory cost is well worth paying in an optimising compiler, since you're going to pay it one way or another. After all, modern optimising compilers, use theorem provers to verify the preconditions for performing optimisations. But it's not necessarily a price you want to pay in a scripting layer.

Re:Do they have tail-recursion or lazy evaluation?

[Hognoxious]

Optional typing is not highly desirable.

Yes it is. It means you can be strict where you need to be but lax where it's irrelevant - avoiding unnecessary casts and other cruft.

Re:Do they have tail-recursion or lazy evaluation?

[DickBreath]

I am not disagreeing with you. Just offering a comment.

While static typing does require that you write more "code" or write more text into your program, you are getting something very valuable in exchange for that minor effort.

Back in about 1982 I remember this argument about strongly typed languages. It was asked by the presenter (don't remember who) "What if I could wave my magic wand so that if you typed your program into the computer three times, it would be free of bugs. Would you do it?" Most people agreed that they would. Static typing is a small form of that. It doesn't make your program bug free, but it does catch a significantly large set of problems at compile time for a very minor cost in human effort.

You mention that Dynamic typing requires you to write more tests. Viewed another way, the compiler's type system is the first line of unit testing. If it compiles, then you have just passed a large set of unit tests that you did not have to write -- or maybe that you did write in the form of type declarations.

Another large benefit of strong typing is that it improves the "toolability" of the language. The compiler can be strongly integrated into the editor and can then offer a lot of assistance right in the editor. (Eclipse, Visual Studio, etc) This is a productivity booster. Also you no longer have to wait for a compile because compile problems are spotted almost as soon as you type in a complete statement in the editor. The toolability also extends to refactoring operations. If you rename a variable or function it precisely renames all references to it from anywhere else in the entire program. Try that with a dynamic language. You IDE can also precisely show you all references to a variable or function from anywhere else in the project.

Dynamic typing means that when you get to the point of doing actual work on a value (eg, Math.min(), Math.cos(), String.substring() etc) then those deepest functions must always test the type of the argument -- at runtime. Every time. Within loops, etc. unless you have a very sophisticated implementation

Now, all that said, I also agree with you that dynamically typed languages are very useful and productive. Especially for prototyping, or projects small in scope. Or projects where the data in the problem domain may be mostly untyped (example: a computer algebra system (CAS)). In a CAS, the matrix multiply, for example, just needs to add and multiply values from elements in the matricies. It doesn't care what types they are. It just needs the add and multiply functions to be able to operate upon those values. But God have mercy on the maintainer of a gigantic system written in a dynamic language.

Re:Do they have tail-recursion or lazy evaluation?

[serviscope_minor]

It's OOP as implemented by SmallTalk, where objects are meant to be thought of as computers that you send messages to, and they decide how to handle those messages. If an object responds to a message, then it's the correct type.

Not quite.

With concepts, the binding is much earlier. The way it's proposed that it will work is that you define (e.g.) a number concept, which encapuslates the idea that +,-,*,/ and perhaps exp and log are implemented.

You then write the code, and it checks the code against the concept: i.e. if you try to use a feature which is not in the concept, compilation will fail. Note that concepts-lite does not implement this part.

At instantiation time, the type is checked against the concept (i.e. does float have +,-,*,/,exp,log) and the compiler will only pass it if it does match. Concepts-lite does implement this part.

Note that with concepts-lite you get late compile-time binding, os you can still get errors if (for example) your algorithm then tries to use ^ which isn't defined for floats. That's more like the message passing version (though at compile time---which means at runtime for the template program), where errors happen if you try an invalid operation on an object.

With concepts, the checking happens earlier.

Re:Do they have tail-recursion or lazy evaluation?

[gweihir]

Nice. One of the two is enough. And, yes, I am looking for mixed languages that can do functional as well. Otherwise I would just use Haskell/ Now I will have a closer look. Thanks!

Re:Do they have tail-recursion or lazy evaluation?

[gweihir]

Optional typing is highly desirable only if you know what you are doing. It makes prototyping so much easier, but there are cases where you need to have static type-safety or go crazy. Example: A Friend of mine wrote something in Erlang lately, but then had to port it to Haskell, because he could not figure out the typing to his satisfaction.

Re:Do they have tail-recursion or lazy evaluation?

[gweihir]

Optional typing just means you can either have static type safety or dynamic type safety at your per-variable choice. You still have type safety.

Static type safety constrains you a lot more and is bad for prototyping, but nice for production code. It can however cause the need for a lot of complex and hard to maintain code without benefit in some case. The nice thing is that you do not get type-errors at run-time.

Dynamic type-safety is nice because you can experiment easily and do a lot of stuff very fast. It comes with the drawback of possible type errors at run-time.

Now, there are also "no type safety" languages, like assembler or C (if you ignore warnings). Nobody uses them today unless there is a dire need. "Optional typing" revers to variable types, not values. Values have a type and dynamic type-safety is ensured.

Re:Do they have tail-recursion or lazy evaluation?

[gweihir]

Indeed, just my point. It is not a beginners game though.

Re:Do they have tail-recursion or lazy evaluation?

[NeoHermit]

This is also the case in Dao. Optional typing merely means optionally writing the type names. Behind the scene, there is type inference and checking. Variables are always typed, unless their types are explicitly declared as "any", or their types cannot be inferred at compiling time.

Re:Do they have tail-recursion or lazy evaluation?

[NeoHermit]

You don't really need to do Hindley-Milner type inference. In a high level scripting language, the virtual instructions are often high level and carry a lot more information than low level instructions. So inference done instruction-wise works quite well, doing instruction-wise type inference is very cheap and efficient. This is what is done in Dao. I don't know how to call this kind of inference, it is a lot more local than local inference people usually talk about.

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

Lisp isn't lambda calculus. That would be Prolog. You probably heard, "Lisp is used for AI" then started talking out your ass.

Re:Do they have tail-recursion or lazy evaluation?

[NeoHermit]

Finally a comment on optional typing by someone knows exactly what optional typing is about!

Optional typing just means you can either have static type safety or dynamic type safety at your per-variable choice. You still have type safety.

Exactly. In optional typing, static type safety is often guaranteed for variables with explicitly declared or implicitly inferred types. And in other case, dynamic type safety is still guaranteed when a variable has no declared type and its type cannot be inferred at compiling time.

Static type safety constrains you a lot more and is bad for prototyping, but nice for production code. It can however cause the need for a lot of complex and hard to maintain code without benefit in some case. The nice thing is that you do not get type-errors at run-time.

Dynamic type-safety is nice because you can experiment easily and do a lot of stuff very fast. It comes with the drawback of possible type errors at run-time.

That's why optional typing can be very useful.

"Optional typing" revers to variable types, not values. Values have a type and dynamic type-safety is ensured.

Exactly.

Re:Do they have tail-recursion or lazy evaluation?

[steelfood]

Basically:

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.

1) Most people are idiots, irrespective of fields.

just because your language has an expressive syntax or any specific feature doesn't mean you can hire chimpanzees to code your application.

2) Employers like to hire idiots because they cost less.

Oh, and here's this gem:

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.

3) Few people realize, and nobody likes to admit that they're a member of the idiots.

Over-engineering and over-simplification are both signs of idiocy. The usual "maintenance nightmare" excuse assumes #2 at its base. Of course, due to #1, it's usually accurate.

Re:Do they have tail-recursion or lazy evaluation?

[angel'o'sphere]

They type is not optional. Declaring the type is.
a = 1.45;

Obviously 'a' is a float (or double), so declaring that it is a 'double a = 1.45' is not necessary.

Re:Do they have tail-recursion or lazy evaluation?

[ultranova]

Scripts are typically small compared to the system that they are scripting.[...]Most of the time will not be spent executing scripts, but executing libraries or application subsystems called by scripts.[...]It's difficult to see how Hindley-Milner type inference would be the right tradeoff in such an environment, at least most of the time.

It's also difficult to see how it matters, since a small script is going to start pretty much instantly and consume very little resources, no matter how complex its type system might be, especially when compared to the rest of the (much larger) system. And this is also ignoring the possibility of having separate development and production runtimes.

If anything, one would think that robustness over speed would be the exact right tradeoff for a critical, but not performance-critical piece of the system.

Re:Do they have tail-recursion or lazy evaluation?

[Jmc23]

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.

.

Have you met Lisp? There's a reason it's unpopular, you actually have to understand things.

Re:Do they have tail-recursion or lazy evaluation?

[Jmc23]

I'm not quite sure you learned Lisp.

Re:Do they have tail-recursion or lazy evaluation?

[Darinbob]

That's how object oriented languages work; you don't need to know the original type as a programmer, the language will figure out what to do. This is exactly how Smalltalk worked which was the granddaddy of object oriented languages. You call a method on the object and it either responds with the method for that object's type or else it throws an exception that the method is not defined. If you do need to know the class then you can query it explicitly (class and type are the same thing).

Explicitly naming the types is usually only necessary for optimization.

Re:Do they have tail-recursion or lazy evaluation?

[Greyfox]

Possible. I wrote a resume generator in it, which stored my resume as a giant list with regularly occurring structures. I wrote some code to break this structure down and output chunks of text encoded within. It was very easy to change the output type to any markup language I cared to write an emitter for. I also wrote a database analyzer which read a database and looked columns with the same name in different tables. It would recursively find all the relationships between one table and another one, with a top bound on recursion so it didn't get out of hand. I didn't really use the language to its fullest, but I am pretty comfortable with how it stores its data, how to build useful lists and how to break lists down to process them.

I go through these phases where I look at LISP and think to myself that it's a wonderfully elegant language and I should try to write something in it. Then I realize I'd have to write all my libraries for sockets and low level machine access myself, which doesn't sound like much fun.

Re:Do they have tail-recursion or lazy evaluation?

[gweihir]

Finally a comment on optional typing by someone knows exactly what optional typing is about!

Thank you!

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

You are assuming that Python and Ruby support functional programming equally well.

Hint: They don't. Ruby's support is head and shoulders above Python

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

You seem to be using static and strong typing interchangeably which makes everything you say about programming languages suspect.

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

Lisp is directly derived from the lambda calculus.

WTF does AI have to do with LC?

Fun fact: Alonzo Church(creator of LC) never learned anything about computers even though he lived until the mid-1990's.

Like Turing's imaginary machines, LC was also created to solve the issue of decidability of first-order logic.

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

Really no type errors at run-time in statically typed languages?

Java would like to have a word with you.

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

In other words, your friend is an idiot who doesn't understand his own code.

Re:Do they have tail-recursion or lazy evaluation?

[Anonymous Coward]

Actually a is not a float, but it references a float object.

you had me at...

[girlintraining]

This language (Dao) has never been mentioned on Slashdot before, but it might be interesting to many people here.

A pretentious name? (ears perk up) Go on...

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

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

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

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.

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.

Well kid, I'm sorry your parents named you Dao. Like all parents, I'm sure they expect great things from you. Unfortunately, it seems you're suffering from a rare birth defect where half your brain is missing and you're a midget. You're also cojoined to your twin, who they named 'C'. Now they're going to try surgery soon to separate you from your twin bro, but I'm gonna be honest here: You're probably not going to make it. Sorry kid, tough break.

Re:you had me at...

[Anonymous Coward]

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

Re:you had me at...

[megrims]

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

While I don't disagree with your assessment of the language, FWIW, all languages have runtimes, not just interpreted languages.

Re:you had me at...

[MouseTheLuckyDog]

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

Sttroustrup ( you know youm could have gotten the name right ) is still alive.

Re:you had me at...

[Anonymous Coward]

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

Re:you had me at...

[Anonymous Coward]

+1 funny, +1 interresting, -1 flamebait... tought choice!

Re:you had me at...

[girlintraining]

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

Ack, I meant Dennis Ritchie, the inventor of the C programming language, not Stroustrup, who invented C++. My bad...

Re:you had me at...

[Anonymous Coward]

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

Please don't put him on the cart! He's not dead!

Re:you had me at...

[dbraden]

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

You sure you wanna be correcting folks?

Re:you had me at...

[PPH]

Well, this will kill him.

If everyone misspelling his name hasn't done so already.

Re:you had me at...

[girlintraining]

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.

Re:you had me at...

[Anonymous Coward]

I fail to see how this is an educated assessment, when you don't even know that "has runtime" is completely orthogonal to language being interpreted or compiled (libc.so/msvcrt.dll is C runtime - latter even says so in properties. C is interpreted!)

All I see is trying to look like smartass. Just look at your quip about "ease of binding = your language is incomplete!". Just think how little a simple GUI application in C does itself and how much of it is binding and calling underlying libraries.

Re:you had me at...

[Samantha Wright]

Whaddaya mean? Stroostrip's fine!

Re:you had me at...

[girlintraining]

Mistaken identity. Can we please stop jumping on my slightly embarassing mistake? :)

Re:you had me at...

[Samantha Wright]

I swear I'm not—this is entirely about how to spell Stirstrap at this point. really, denmark, what were you thinking

Re:you had me at...

[Pseudonym]

No, libc is not C runtime; libc is the C standard library. The C runtime is crt.o (or crt1.o) on Unix-esque platforms, msvcrt.dll on Windows.

C is not interpreted, but it does run on a virtual machine. The C runtime is the implementation of that virtual machine.

Re:you had me at...

[phantomfive]

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

Best misdefinition ever.

Re:you had me at...

[Anonymous Coward]

No need to go into a rant. Just look at the credentials of the author. Absolutely none. Why should I use this language over another?

Next.

Re:you had me at...

[girlintraining]

I swear I'm notâ"this is entirely about how to spell Stirstrap at this point. really, denmark, what were you thinking

This being Denmark, they probably named him as such so nobody could find him on the internet, thus fulfilling the secret dream of every Danish person: To not be noticed. :D

Re:you had me at...

[Anonymous Coward]

That's not true, assembler does not have a runtime, though there are many basic libraries equivalent to libc and crt that could be considered runtimes (if you use them). Also not all C compilers have a crt, and most C compilers can generate freestanding code which doesn't link against libc but will generally link crt unless that particular compiler doesn't have a crt.

Re:you had me at...

[mwvdlee]

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

Re:you had me at...

[Anonymous Coward]

But what about two people hacking on same keyboard, then?

Re:you had me at...

[Pseudonym]

After all, it worked so well for Lars Ulrich.

Re:you had me at...

[Anonymous Coward]

I think it would be better if we left him there.

Re:you had me at...

[girlintraining]

After all, it worked so well for Lars Ulrich.

Unfortunately, even being Danish isn't enough to conceal such a concentrated amount of asshattery.

Re:you had me at...

[Pseudonym]

That's called "agile".

Re:you had me at...

[jones_supa]

C is not interpreted, but it does run on a virtual machine. The C runtime is the implementation of that virtual machine.

I wouldn't call it a virtual machine either. The C runtime library is just implementation of various system functions, making it look more like a shared object.

And all compiled C code, including the runtime library, run on bare metal.

Re:you had me at...

[Anonymous Coward]

Way to fight the stereotype of guy geeks as sexist assholes.

Re:you had me at...

[aliquis]

Mistaken identify.

girlintraining.

Slashdot.

I get it!

Re:you had me at...

[NeoHermit]

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.

Re:you had me at...

[Pseudonym]

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.

Re:you had me at...

[lurcher]

I can only assume you have not done any embedded coding. But I guess if you want to define "virtual machine" in such a way that even simple assembler that starts at the reset vector fits the definition...

Re:you had me at...

[EETech1]

I always thought this was a NERD hangout!

Now we got GEEKS on our lawn!

Wai...Wha... girls too! /. != Stagparty

Re:you had me at...

[Pseudonym]

I can only assume you have not done any embedded coding.

Not very much, admittedly; only two years paid work on 8-bit microcontrollers. I'm sure you have more and wider professional experience in the area than I do.

However, I came from a background in compilers, so the source file of the "simple assembler that starts at the reset vector" that I had to write was named crt0.s.

Re:you had me at...

[Anonymous Coward]

all languages have runtimes

Non-hosted C does not.

Re:you had me at...

[XcepticZP]

You must be new here. Stackoverflow moderaton has a sort of friend-system going for it. Friends moderate eachother's posts up. The more popular posters regularly get upvoted for mindless nonsense and regurgitation of the obvious. You stumbled on a particularly popular poster. You probably won't even get a response from her/him, as she/he doesn't see an opportunity to get more upvotes from a response to you.

They found a way to gain the system, and they love it. That's why you see so many regular posters posting content with common themes and getting upvotes for them, meanwhile giving the rest of us a WTF-level through the roof.

Personally, I think they derive some sort of pleasure out of it because they have confirmation addiction. But yeah, we can't deny that downvotes make us feel sad, and that upvotes make us feel good in a very basic way. Me, I just come here to possibly get some good debate, and to vent.

Re:you had me at...

[serviscope_minor]

Dao is an optionally-typed programming language

By far the nicest "optional typing" I've seen is C++ concepts. The others I do not like. Af far as I see, a computer manipulates data and the type defines the semantics of maniuplation. Without types then there is no manipulation to even think about.

Concepts is the best thing I've seen for optional typing since it allows you to specify the required semantics instead of the concrete type, which is what you want. (type classes are somewhat similar)

The other ones just let you plug in any old crap and hope for the best

Runtime? So it's like Java then... it's interpreted.

I have not read TFA, but "runtime" doesn't necessarily imply interpreted.

For example even hosted [in the standardede meaning of the term] C programs have a runtime, which generally just consists of a bunch of entry points for stdlib functions, and of course the startup code which initialises main. The latter in fact resides in crt1.o (C Run Time.o).

Hosted C++ has (optionally) larger runtime requirements. As well as having a larger standard library (of course, since it subsumes the C one), it also needs vtables (if you have virtual functions), exception tables (if you use those) and RTTI names and stuff (if that's on).

Those are definitely part of the runtime, and the tricky thing about a C++ kernel it seems is making sure all that stuff is set up correctly before starting the full execution, since you can't rely on the OS to do it for you...

But yes, they have gon and implemented their own VM, so it is what one would generally consider "intrepreted". However, with LLVM's ability to interpret or bitcode, that distinction has almost gone now given that it's now much easier to do both.

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.

That's a little harsh. Even in a complete language, it's probably worth simply linking against a C library, rather than (for example) trying to reimplement things like libPNG or (much much worse) ffmpeg yourself.

That said, it's "just another language", and apart from a few "quite neat" bits, there is nothing substantially new that greatly increases efficiency or expressiveness or etc over existing languages.

Re:you had me at...

[Anonymous Coward]

Everybody with "credentials" (whatever that really means) has started without credential... You are not born "credentialed".

Look at Linus before 1991: unknown, then look at him now.

Re:you had me at...

[Anonymous Coward]

What you talk about seems much more like a language support library than an actual virtual machine.
For me the difference between a virtual machine and language support libraries is that with a virtual machine the code is re-interpreted (often in real time) from some abstract machine language (the virtual machine) to the actual instruction set of the machine it is supposed to run on. The machine code for the virtual machine cannot be executed by the actual hardware and needs to be translated.

This is in contrast to the output of a c chain. The machine code generated by the toolchain is designed to execute directly on some target hardware.
In this case there is no need to translate between instructon sets on runtime but there is still a requirement for a specific environment for the code to execute correctly.

Re:you had me at...

[ath1901]

I for one like the idea of an optionally typed language. I work with hybrid C++/Python programming so I have experienced the pros and cons of typed vs untyped languages.

In general, I much prefer Python to C++ because of the ease and speed of implementing stuff. But, Pythons performance is lacking so I need C++ for that. My perfect language would have the speed of C++ but the ease and implementation speed of Python. Cython is one such language which is basically compiled Python with optional types. The optional types allows for a lot of extra compiler optimisations and it gives a huge performance boost. I haven't used it for anything "real" though because it uses language extensions and is thus incompatible with pure Python. Once I've converted something to Cython, I'm stuck with the much slower debug/compile/run cycle and I've lost some of Pythons speed and ease. Ideally, Python would some day add optional type info so I could run cython code in the (slow) Python interpretor and compile it once I'm ready to release it. For the moment, I prefer the approach of Shedskin but that's another story.

So, my perfect language would have optional typing and optional compiling when maximum performance was needed. I have no idea if Dao is such a language though.

Re:you had me at...

[TheDarkMaster]

In short: "Yet another incomplete language". The new fun "game" this days is creating programming languages.

Re:you had me at...

[Anonymous Coward]

To be honest I believe that you are who failed to see the logic of what she wrote. Because you stopped exactly where she ends each point, rather than extend yourself to understand why she got such conclusions. That to me, what she said made perfect sense.

Re:you had me at...

[Pseudonym]

There are plenty of examples of virtual machines where the instruction sets of the virtual machine and of the physical machine are identical, and VM instruction execution is handled by executing instructions on the physical machine. VMWare-like virtualisation is one example, but an even more common example is an application in a modern operating system. The OS provides the illusion that the application has a CPU all to itself, and a flat address space.

Re:you had me at...

[Anonymous Coward]

I'm pretty sure with "optionally typed" he didn't mean that you normally have an untyped blob of data. Rather, that you have the option whether to use static typing or rely solely on dynamic typing. Note that even dynamic typing is generally strong typing, and you certainly can implement typecasts on dynamically typed objects (and with optional typing, I guess the typecast would result in a statically typed value).

Having said that, I'm also firmly in the static typing camp (I prefer to get my errors as early as possible). But the point is, your type cast argument doesn't hold water.

And BTW, you hopefully don't consider that answers.com entry a good one. The code example (a) doesn't contain a typecast, but an implicit conversion, and (b) is broken anyway because that conversion happens only after the damage has already been done (contrary to what the text implied, c won't get a decimal value). In short, whoever wrote that entry was completely clueless, and certainly not someone whose advice I'd take seriously.

Re:you had me at...

[Anonymous Coward]

All languages? Where's the assembly language runtime?

Re:you had me at...

[PmanAce]

Since when is code review part of agile?

Re:you had me at...

[Anonymous Coward]

...the secret dream of every Danish person: To not be noticed. :D

Thank goodness this doesn't apply to Gry Bay. That is all.

Re:you had me at...

[Pseudonym]

I don't know. All I remember from the expensive five-day training session is that you're supposed to sit at the same keyboard as someone else, and that you stop coding and genuflect when a Scrum Master enters the room.

Re:you had me at...

[Anonymous Coward]

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

"She" doesn't conform to several stereotypes. Like the one about girls not having moustaches, for example.

Re:you had me at...

[hendrikboom]

Two keyboards. As in most pipe organs.

Re:you had me at...

[benhattman]

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.

No it's not. A virtual machine does...you know...virtual things. A stack is not a virtual thing, it's just a call stack. If your C malloc call gives you a direct buffer of memory on the actual hardware, that's a non-virtual call. If your A + B operation does an add in the ALU, that's a nonvirtual call. If the calls to the underlying assembly are all done at compile time, you are using a nonvirtual language. If the calls to the underlying machine are done by a virtual machine at runtime, then you're using a virtual machine.

Java uses a virtual machine. C does not. It's really that simple.

Re:you had me at...

[Anonymous Coward]

Yeah, Barney is just angry that you didn't spell his name right the first time ;-)

Re:you had me at...

[gr8_phk]

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.

That wasn't fair. You need to be able to link existing libraries to run on anything.

Re:you had me at...

[theshowmecanuck]

Strou soup is delicious. Tastes like pork.

Re:you had me at...

[Anonymous Coward]

Sure gives new meaning to "done done".

Re:you had me at...

[Xyrus]

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

You keep using that word. I do not think it means what you think it means.

The process of virtualization allows an entity to function regardless of what the underlying real environment is. The compiled C language is not virtualized in any respect. The generated executables are comprised of native opcodes, which in some cases even contain opcodes specific to the CPU it was compiled for, not to mention OS specific libraries and such.

If the compiled C code was truly virtualized, then I would be able to take an executable compiled on some random Linux box and run it on some random Windows box (which, of course, you can't). In fact, you'd be lucky if you could bring over the original code and get it to compile on Windows.

Real VM backed languages do not have these limitations. They're compiled to an intermediary bytecode which is machine agnostic. The VM (which is a native application) then runs the bytecode and handles any machine specific interactions. Any platform that has the VM will be capable of running the bytecode, regardless of hardware or software.

By your definition, anything that isn't writing out binary by hand could be considered "virtualization", which doesn't make a whole lot of sense. The C language and other such languages provide a higher level abstraction to make programming easier, but they are not providing virtualization.

Re:you had me at...

[TheDarkMaster]

People these days are so accustomed with the buzzword "virtual machine" and to program in managed environments, that they have forgotten what is really a "real machine"

Re:you had me at...

[Anonymous Coward]

So can C++. Both languages address freestanding implementations in their respective standards.

Re:you had me at...

[Half-pint HAL]

All languages? Where's the assembly language runtime?

It's often implemented in hardware....

Re:you had me at...

[NeoHermit]

So, my perfect language would have optional typing and optional compiling when maximum performance was needed. I have no idea if Dao is such a language though.

Maybe. You might be interested on these tests: http://att.newsmth.net/att.php?p.109.67650.504.png

Re:you had me at...

[Half-pint HAL]

If the OS runs the program as a VM, then why would I need the C runtime to operate as a VM too? A VM that is the only thing running on a VM? My sandbox would hold more sand if it wasn't inside another sandbox....

Re:you had me at...

[steelfood]

By your definition, as every program has its own stack and heap and maybe access to some shared memory space, every program runs in its own virtual machine.

I think the more common name for that is a process.

Re:you had me at...

[PmanAce]

Well that is not how one does agile in a team environment. The scrum master changes all the time, all he does is ensure the scrum meetings are smooth and concise.

Re:you had me at...

[Anonymous Coward]

And for you kids out there, girlintraining just pointed out why typechecking is important.

Passing LiveProgrammer to a function that deals with DeadProgrammers in this case required a backbreaking amount of digging to fix the error.

Re:you had me at...

[angel'o'sphere]

You may call this a virtual machine.
The rest of the world calls it a runtime. Or a bootstrap or whatever.
A virtual machine as in interpreter and not as in virtual system emulator is something completely different than a bit of start up code linked to a C program.

Re:you had me at...

[angel'o'sphere]

Usually doing code reviews is mandatorry in agile methods.
Nothing is considered done (definition of done, DoD) unless it is checked into the revision system, has a successful running test *and* is reviewed by another developer. But this is usually no formal review as in "Code walk through" or as in "inspection".

Re:you had me at...

[angel'o'sphere]

Well, 'bash' is a language, too ;)

Re:you had me at...

[Anonymous Coward]

Poseurs need ridicule no matter what sex they are.

Re:you had me at...

[Anonymous Coward]

Ack, I meant Dennis Ritchie, the inventor of the C programming language, not Stroustrup, who invented C++. My bad...

It's ok, Richie is a subset of Stroustrup.

Re:you had me at...

[Pseudonym]

You keep using that word. I do not think it means what you think it means.

I know how programming language theorists use the term. How marketeers use the term depends on what they're trying to sell you.

Re:you had me at...

[Pseudonym]

...and your program would be quicker if you implemented it in raw silicon, but it's more cost-effective to implement it on commodity hardware.

If you're on IA32 or x86-64, by the way, that commodity hardware provides the illusion of a CISC instruction set implemented by a RISC core. Turtles all the way down, I tell you.

Re:you had me at...

[Pseudonym]

A user-space process on a modern operating system is running on a virtual machine. The OS provides an abstraction of the underlying hardware. That's why you can write your code as if you have a CPU all to yourself, even though there are usually fewer physical CPUs than processes.

Re:you had me at...

[Anonymous Coward]

at the very least you'll need to set up a stack before you transfer control to C code for the first time.

No, this is not needed.

Re:you had me at...

[Anonymous Coward]

Not really. C code compiles to machine code. It runs on the real machine. There is a C runtime, but as you noted all it really takes care of is basic setup and teardown, including setting up the stack, sure. But once the code is running, it's compiled machine code running on the actual CPU. It's not virtual by any definition, unless you're calling multi-tasking a sort of virtualization, since the CPU is swapping around sets of saved registers and memory mappings per task and all that jazz...

Re:you had me at...

[Half-pint HAL]

I still don't get why the C runtime is being called a "VM" rather than a "runtime library". Is every Windows DLL that abstracts out a piece of functionality that could conceivably be implemented in hardware now a virtual machine? Or just things that are commonly implemented in hardware? For example, 3D graphics (remember when that was all software? It still is on many cheap Android devices) and MP3 decoding (most portable devices have on-chip MP3 decoding, not sure whether PC soundchips do now or not).

Re:you had me at...

[jones_supa]

Still not buying it. There are operating systems and hardware abstraction layers, but it's still too far-fetched to say that there is a virtual machine running in the scenario which you described.

You seem to be thinking that every time when a program is working from within any form of abstraction, it means it is running in a virtual machine.

Re:you had me at...

[Pseudonym]

I still don't get why the C runtime is being called a "VM" rather than a "runtime library".

OK, I think we have some confusion here.

The abstract machine which C presents to the programmer is typically realised using several different techniques. There is no hardware in existence which runs C source code directly, so ultimately, instructions in a high-level language must be translated to run on something lower-level. The translation could be dynamic (in which case we'd call it "interpreted") or static (in which case we'd call it "compiled") or somewhere on a continuum between the two.

C is such a low-level language that for the most part, the operations of the C machine map to instructions on modern ISAs. On a typical platform, there are at least three cases where this is not the case.

1. Some of the standard libraries can't be implemented directly in C, because on a modern platform they require trapping into the operating system. However, this is presented to the programmer as a call to a library function. As far as the programmer is concerned, this is a library call, so it is correct to think of this as "library".

2. There are some parts of the startup and shutdown procedure which can't be implemented directly in C, because when the OS gives control to the program, you are not yet "in" C. Some parts of the startup and shutdown procedure can be implemented in C, but are still not presented to the programmer as a library; for example, there's no library that you call to perform argv/envp parsing. Because this is presented as an operation of the machine, rather than a library call, it is more properly thought of as "runtime".

3. You occasionally run into the situation where you have a C operations which does not map directly to instructions on the ISA. For example, 16-bit CPUs may provide facilities for performing double-register arithmetic, thus effectively giving you 32-bit arithmetic for all of the basic operations except division (and modulus). Some CPUs don't have a floating point unit. In these cases, the C implementation generates threaded code for those operations, calling out to a software implementation.

Note that this is different from a "library", because we're talking about operations which aren't presented as library calls. The C compiler generates calls from source code which doesn't call anything. This is more properly thought of as "runtime".

Did that help?

Re:you had me at...

[Half-pint HAL]

Did that help?

It might have done if you hadn't shown yourself unaware of the existence of such thing as a "runtime library". You outright denied that it existed, so while you have demonstrated a deeper understanding of the workings of C than me, you've also demonstrated that your usage of terminology is somewhat... nonstandard....

2. Would be your main justification for calling the C runtime a VM — that it is called before the program itself. Surely the defining feature of a virtual machine would be that it mediates all control flow, and you have so far only talked about the C runtime manages the call stack for C's procedural features. Relatively complex procedures built on basic operations could in theory be carried out with no interaction between the program and the runtime.p>

3. If an instruction doesn't exist in hardware, it has to be implemented in software. Now, so are you saying that the C object file includes a "virtual instruction" that is interpreted on the fly by the VM, or is it instead not usually compiled into a library call? I mean, if I compile C to an 8-bit microcontroller based on the 6502 chipset, then all FP operations must necessarily be done in software. Are you calling that a virtual machine? Because that sounds a bit of a stretch.

You've convinced me that the "runtime" is not a "runtime library", but if you're calling it a VM, then the term VM has lost all meaning.

Re:you had me at...

[Pseudonym]

Yes, we do have some confusion here.

It might have done if you hadn't shown yourself unaware of the existence of such thing as a "runtime library".

You appear to think I was saying that the C runtime (which is indeed almost always implemented as a library, though there are notable exceptions) was the C virtual machine. I didn't say that at all. The C virtual machine is, in a compiled implementation, implemented by the compiler and the runtime working together.

Now, so are you saying that the C object file includes a "virtual instruction" that is interpreted on the fly by the VM, or is it instead not usually compiled into a library call?

I am saying that the abstract machine presented to a C programmer includes a bunch of basic operations (you can think of them as virtual instructions if you like), presented as the abstract syntax of the language. It's up to the implementation as to how these basic operations are realised on a specific platform. Some of them may be translated into the native language of the target machine, some may be implemented by threaded code, and so on.

The programmer will not see this as a library call. It's often unavailable to the C programmer as a library call; those bits of the runtime often don't adhere to the ABI of the platform.

I think that the cause of the misunderstanding is that programming language theorists and compiler writers use the term "virtual machine" to mean something more general than people who don't work in that space. That's okay, but but it might get confusing if you need to read the original research.

Re:you had me at...

[Anonymous Coward]

If you think python is untyped then you are as stupid as the moron you are responding to.

Re:you had me at...

[Anonymous Coward]

Your "educated" assessment was a pile of fail.

Where did you get educated at? The Rasmus Lerdorf School for Morons? Did you ride the short bus to it every day?

I begrudge you for being clueless.

how do i connect to a database?

[Anonymous Coward]

if it can't then its 2/3 useless

Re:how do i connect to a database?

[Anonymous Coward]

even BASIC has DATA, READ, RESTORE. You don't necessarily need SQL do you?

Re:how do i connect to a database?

[Anonymous Coward]

Clang-based tool for automatic binding generation from C/C++ header files.

Looks like you can do everything that you have C libraries for. So basically everything.

Re:how do i connect to a database?

[Anonymous Coward]

Tell ya what. How about I continue writing C and pretend I'm just writing extremely optimized Dao programs.

Re:how do i connect to a database?

[NeoHermit]

There is actually a module for SQL databases (https://github.com/daokoder/DaoSQL), though it currently only has backends for MySQL (MariaDB) and SQLite. There are a number of non-standard modules for Dao here: http://daovm.net/projects. But they are not tested for this release.

end the lambda idolotry!

[Anonymous Coward]

Have fun designing programs that manipulate massive amounts of state with functional programming style. Given that nobody has figured out how to do a first person shooter with a functional langauge, makes me suspect that they aren't the one answer to every problem. In fact even a relatively simple game is quite awkward in a functional style.

I guess you can't solve every problem with lambda calculus and retain your sanity.

Re:end the lambda idolotry!

[j1m 5n0w]

There actually is a Haskell FPS. State manipulation is a little awkward in some ways, in part because there isn't a universally agreed-on way to do it, but the tools are getting better. With lenses on top of a State monad, things start to look pretty similar to an imperative language, except that you get the benefits of functional programming as well (for instance, error handling is a lot easier when you don't have to back out a bunch of changes because you still have your original state lying around).

Re:end the lambda idolotry!

[ultranova]

Given that nobody has figured out how to do a first person shooter with a functional langauge, makes me suspect that they aren't the one answer to every problem. In fact even a relatively simple game is quite awkward in a functional style.

Suppose your gameworld is represented by a list of objects. For each tick, go through the list for the previous tick and call newState(oldlist) for every object. This function returns zero or more objects, which get added to the new list - done by functional-style recursion, of course. In imperative programming, spider kills a fly, in functional one, fly is killed by a spider. It basically just reverses the subject-object relationship - entities react to other entities, rather than acting on them.

Whether this provides any advantages is another matter.

Re:end the lambda idolotry!

[Anonymous Coward]

I guess John Carmack isn't re-implementing Wolf3D in it, or considering using it for future games, oh wait, he is.

Optionally typed

[ThePeices]

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

Re:Optionally typed

[Anonymous Coward]

Think JavaScript with optional typing.

Re:Optionally typed

[Pseudonym]

That settles it, then. I don't want to use a language if it encourages JavaScript-style code.

Re:Optionally typed

[Samantha Wright]

What, you'd rather write code like in your sig?

Re:Optionally typed

[Pseudonym]

Are you kidding? I'd love to write one-liners for a living!

Re:Optionally typed

[Samantha Wright]

But it's in perl! You might summon Cthulhu. Do you really want that on your conscience?

Re:Optionally typed

[Pseudonym]

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

Re:Optionally typed

[Anonymous Coward]

Maybe it's a scripting language? But be sure to dot your i's

Re:Optionally typed

[Anonymous Coward]

Didn't you get the clue? Calligraphy on huge blankets, plus optional flying swords, arrows and warriors.

Re:Optionally typed

[Noughmad]

Something like the OMG OCR Calculator?

Re:Optionally typed

[Anonymous Coward]

Copy&Paste.

Re:Optionally typed

[Anonymous Coward]

That parser... wow. I'm impressed.

Re:Optionally typed

[Xyrus]

Cthulu can only be summoned using the BrainFuck programming language. And don't call me Shirley.

Feature complete with a small runtime?

[Anonymous Coward]

It won't be feature complete until the runtime is a bloated mess of 15 year old code. Any 'new' language is most certainly feature incomplete until it's been around the block long enough for people to have a clear understanding of what's missing.

Re:Feature complete with a small runtime?

[Pseudonym]

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

Re:Feature complete with a small runtime?

[Samantha Wright]

Technically, it's cheating; all of the bloat you'd get in such a history can be imported from existing C and C++ libraries.

Why?

[Tony Isaac]

Why would someone want to use this language instead of an established language? So there is a feature list. Is there something there that is compelling enough to leave an established language community?

A language alone has little value. It's the community / ecosystem that makes it worthwhile.

Re:Why?

[Pseudonym]

New languages are the proving ground for new programming language features and implementation technologies. Right now, Dao doesn't nee people to make it mainstream, it needs people to see how that feature set and implementation technology works in practice.

Re:Why?

[jones_supa]

You have to start somewhere.

Re:Why?

[White Flame]

So what's so standout about the feature set and/or implementation technology? TFS and a quick read of the linked feature list doesn't make anything jump out at me.

Re:Why?

[Pseudonym]

I have no idea. I was speaking generally about why we need new languages even if they're never adopted for serious project.

Re:Why?

[pmontra]

I'm back from a trip on my time machine. I was in the 60's and I heard someone at Bell Labs arguing "why would someone want to use this C language instead of what we already have?" Don't worry, I didn't tell him what was about to happen.

On a less funny note, people experiment and throw languages at us. Java, JavaScript, Perl, Python, Ruby were not established 20 years ago. Actually only two of them already existed at that time. Countless other languages came and died but nobody was able to predict which ones would form a community and be the winners. IMHO it's not only a matter of technical merit but also how it is marketed (even for non proprietary not for profit languages).

Re:Why?

[Anonymous Coward]

Java, JavaScript, Perl, Python, Ruby were not established 20 years ago.

And things have been going downhill ever since..

Small runtime?

[Tony Isaac]

How about zero!

WTL is an open-source C++ framework for creating Windows applications that typically require no installation, no runtime whatsoever, and generally compile to an exe less than 100K in size!

Re:Small runtime?

[Anonymous Coward]

Dude. WTL is a replacement for MFC that Microsoft decided not to back with developer support because it came way too late (even Charles Petzold had moved to C#/Windows Forms by the mid-00's).

It is a dustbin technology.

Re:Small runtime?

[Pseudonym]

Even C doesn't have a zero-sized runtime.

$ ls -l /usr/lib/crt1.o
-rw-r--r-- 1 root wheel 10104 22 Mar 17:44 /usr/lib/crt1.o

Re:Small runtime?

[Anonymous Coward]

Just crt?.o? You're not going to go very far without libc.a/libc.so getting linked to your executable, that's actual C runtime.

Re:Small runtime?

[Tony Isaac]

You are, of course, correct. WTL, however, does not require any runtime library beyond what is included in the OS.

Re:Small runtime?

[Pseudonym]

In programming language parlance, "runtime" refers to the implementation of the virtual machine. In compiled C, there's very little "virtual machine"; basically it's just startup and shutdown.

The standard library is not the runtime. Indeed, many programs (e.g. OS kernels, firmware) don't bother with a standard library, though they also typically implement a custom runtime.

Re:Small runtime?

[Anonymous Coward]

You're just wrong here. The runtime is a piece of code that's required for the execution of programs written in the language, whether or not they use the standard library. The C runtime basically just does OS-specific initialization work that every program must do and then calls main. But it's still called a runtime.

Likewise, GHC compiles to native code, but the native code that gets linked with your code that manages things like threading is also called the runtime.

Re:Small runtime?

[Pseudonym]

I'm pretty sure that's what I said in slightly different words.

Re:Small runtime?

[Anonymous Coward]

I'm guessing that is gcc. Not all C compilers have a crt, though the equivalent code is still placed in the linkage when used. Moreover the C "runtime" is a misnomer, it is not a piece of code that runs the C program, it's a linkage of intrinsic functions that are not implemented by the target architecture but necessary to implement the C standard and are too large to be emitted inline with each usage. In other words, if they had called it intrinsic.o or primitives.o, you would not be saying C has a runtime, because crt is not a runtime.

On the other hand libc or the OS kernel could be considered a runtime, though neither of which is needed to create a working C program see: -ffreestanding.

Re:Small runtime?

[AuMatar]

Wow, you mean the firmware program I wrote least week that went on bare metal had a runtime?

Try again.

Re:Small runtime?

[AuMatar]

Not every C program requires OS initialization. I've written firmware, OSes, DOS apps, and even unix apps that did nothing- just jumped straight into main. C does not have a runtime. You can add one in, but by language default there is none. Nor have I ever heard of anyone calling library initialization a runtime before- I don't think you understand the term.

Re:Small runtime?

[Pseudonym]

Unless the CPU transferred control directly to C code at boot time, without passing through any lower-level initialisation first, then it had a runtime.

But even that is no guarantee. Some implementations of C provide enough support for low-level hackery that they allow you (or the vendor) to write the runtime in C itself, including setting up the stack pointer. I've certainly done that before. It's possible, but it's rare.

Re:Small runtime?

[AuMatar]

Yes, it did. Thats the way most firmware works. Even those projects with an embedded OS end up working like that, unless you want to redefine runtime to mean an OS itself.

Re:Small runtime?

[Pseudonym]

Not every C program needs every part of the standard C runtime, but I'd wager that every C program in existence needs the stack (which is why I keep talking about it). So the key question you need to ask is: Who sets up the stack?

If it's the operating system (there are "linkable" operating systems, and operating systems which ), then the OS implements the runtime. If it's a piece of assembly code which then transfers control to C, then that is the runtime. If it's C code, then the runtime is (at least partly) implemented in C.

Of course, if your code doesn't use a stack, then you're extremely clever, but you're not talking about "most firmware".

Incidentally, I don't believe there is such a thing as "most firmware"; what's in a BIOS is very different from what's in a bluetooth mouse which is very different from what's in a pacemaker. Nonetheless, to a first approximation, every high-level language needs a stack. Asking who sets up the stack usually answers the question of where you'll find the runtime.

Re:Small runtime?

[lisaparratt]

The problem is you keep using the phrase "virtual machine", and an exceptionally pedantic and niche definition of it that is not commonly understood. Most people will think system virtual machines or managed system emulators - setting a few registers, calling a few init/constructor routines, and jumping to main will hardly conform to that concept.

If you just said the C runtime consists of startup/shutdown code and a few utility functions, I'm sure you'd find fewer people arguing with you.

Re:Small runtime?

[lisaparratt]

And how to you get to main?

"main" is not the entry point, some variant of "start" typically is. The C runtime is the exceptionally thin veneer of code that constructs the first activation record for main and calls it through it.

Re:Small runtime?

[lisaparratt]

I wish I had mod points, this is a lovely explanation of the concept.

Re:Small runtime?

[Pseudonym]

What you call "pedantic and niche", I call "more general". Each to their own, I guess.

Re:Small runtime?

[Anonymous Coward]

No you didn't. You keep on insisting C runs on a "virtual" machine. What is "virtual" about setting up the stack of the (real) machine ?

Re:Small runtime?

[Pseudonym]

The C language standard (we'll ignore the standard libraries) specifies a virtual machine. That machine is implemented on physical hardware by the combination of the compiler and some run-time support code. In the case of C, that amount of run-time support code is typically very small, and it basically only covers startup, shutdown and stubs for any virtual instructions which the CPU doesn't support natively.

(That last point, by the way is something that people who only use modern medium-to-high-end CPUs don't always appreciate. Today you almost always implement everything that C needs in the form of native instructions, but this isn't always the case and hasn't always been the case as anyone who needed to do a 32-bit division on a 80286 or an older SPARC can tell you.)

Re:Small runtime?

[wiredlogic]

You don't have to link the standard runtime in if you are willing to do the init and shutdown chores yourself (or just the subset that you really need).

Re:Small runtime?

[Anonymous Coward]

NO it doesn't. The C Standard defined an ABSTRACT machine, used to explain the way a conforming program should behave.

Re:Small runtime?

[maxwell demon]

You mean, WTL programs run without MSVCRT.DLL?

Re:Small runtime?

[maxwell demon]

"main" is not the entry point

That's completely up to the implementation.

Re:Small runtime?

[Tony Isaac]

Yes, I've already been called on that. Of course. What I should have said was, it doesn't require any runtime beyond what is included in the operating system.

Re:Small runtime?

[Pseudonym]

I thought about mentioning that, but I realised that introducing the phrase "abstract machine" at this point may sound like a weasel term.

Nonetheless, since you brought it up, a virtual machine is a realised abstract machine.

Re:Small runtime?

[tibit]

Say you run on a platform where a (possibly fixed-depth) PC stack is implemented in hardware and is not directly accessible as data. Say that your code has only non-recursive functions where the frames are statically allocated and overlaid by the linker. Say you're running on a low-end PIC, SX48, the Picoblaze core, and so on. Say that C compilers existed for those - well, they do. :)

For non-recursive code you don't need stack for anything but the PC, as the frames can be statically allocated and overlaid based on the call tree. So the stack you use is a very limited one, and can be subject to strict isolation should you wish to provide one.

Re:Small runtime?

[Pseudonym]

We need to add a few more assumptions, for example that you're not using any C operations that don't have corresponding instructions on the physical hardware which would likely be implemented in the runtime on that kind of low-end hardware, such as floating point or larger-word-size division.

We're not really talking about "C" any more. We're talking about a very cut-down language, but that's okay. Even under all those assumptions, then all the C runtime probably has to do is transfer control to C code, and the rest of the abstract machine can be implemented using static translation alone.

Re:Small runtime?

[tibit]

Huh? The existence of an explicit data stack got nothing to do with the existence of a runtime library!

Obviously it can do list insertion

[Anonymous Coward]

Slashdot.insertathead(slashvertisement)

or whatever the syntax is.

The YAPPing language is for dogs

[petteyg359]

"Yet Another Pissant Programming language". Can we quit pretending that "new is better" and just use the stuff that actually works?

Re:The YAPPing language is for dogs

[Anonymous Coward]

This.

It makes me very happy to see others like myself, who avoid almost all programming languages post-1994, simply because they just seem to be rehashing existing shit in different ways, rather than fixing. Fixing means "repairing what is broke". Broke means busted, does not work, or cannot be accomplished (that's a binary condition BTW (either yes it can or no it cannot)).

For whatever reason there's multiple generations of computing folks who have jumped on on the "I'm jacking off over a new programming language because the Old Ones(tm) don't let me write AFC (Ambiguous Fuckwit Code) and refer to things in abstract/stupid ways in which actual processors themselves do not understand/operate on" train. I often get the impression these are CS graduates who went through schools focused on object-oriented crap (C++ and Java mainly), all due to corporate sponsorship/donations (I'm looking at you, Sun (R.I.P.) and Microsoft).

Less abstraction == less bullshit == almost always better when it comes to computing. It's often surprising how many people writing these languages do not actually understand how a CPU works (meaning no familiarity with assembly language or general CPU design); so many CPU cycles are wasted due to all the abstraction...

The only programming language I have seen come out since Perl that has been even remotely revolutionary in the above regards, while retaining KISS principle, is Lua. But I still can't get over Lua's not-equals conditional operator being ~=. And while I truly understand syntactically why this is, there's just really no true advantage to it or major speed gain (parser-wise), nor why != could not be used (or offered as an alias/alternate syntax). Lua also didn't really become a viable candidate until I would say maybe 2004 (games like World of Warcraft using Lua greatly spread knowledge of its existence), but it's at least the best of the bunch.

PHP. Python. Ruby. D. C#. F#. Go. Rust. Dart. Doa. Just stop the fucking madness.

Re:The YAPPing language is for dogs

[VortexCortex]

I would. If only the stuff you say actually works did. Know why we have malware? Single Stack for code and data. x86 even has a damn CALL and RET operations to hard-code this C-ish brain damage directly into everything. Anything doing it differently suffers.

There are lots of things that are broken in languages today, and only using "stuff that actually works" means they never get fixed. Protip: COBOL and Fortran and FORTH actually worked too.... Hell, at least FORTH has separate code and data stacks -- You actually had to ignore the correct design to create an inherent stack-smashing vulnerability in all programs. Yep, "actually works", well, sort of.

Re:The YAPPing language is for dogs

[phantomfive]

Know why we have malware? Single Stack for code and data.

Wow, welcome to the new millennium where any sane OS/CPU supports the NX bit. It's been there for a while. Compile your code with gcc -z noexecstack , or rather, just don't turn the noexecstack option off. It's on by default. Your problem isn't a problem of programming languages, and it's been solved.

Also, you're making my sig really hard right now.

Re:The YAPPing language is for dogs

[Anonymous Coward]

How does it help when temporary buffer on stack overflows and smashes the return address?

Re:The YAPPing language is for dogs

[EETech1]

The name is to attract a certain type of Programmer.

It's pronounced
Duh... Ohhh?!?

Re:The YAPPing language is for dogs

[ChunderDownunder]

Haskell's not on your list and came out in 1990, it's still hunky-dory, no? :-)

Re:The YAPPing language is for dogs

[Anonymous Coward]

X86 was mostly designed for PASCAL/ALGOL type languages and not C or it's predecessors. The only thing CALL/RET things that are close to any language is automatic removal of stack resident variables that, again, is designed towards PASCAL and not C.
Reading the rest of your post I don't think you know as much as you apparently think as a standard call/return mechanism have nothing to do with security and nothing inherently to do with C languages...

Re:The YAPPing language is for dogs

[Anonymous Coward]

Non-executable stack does NOT solve the buffer overflow problem. It makes it more difficult to exploit, but does not really solve it, because it can't be solved at that level.

It used to be that buffer overflow exploits, while overwriting the return address on the stack frame, would also drop their executable payload into the stack while filling it up. This was greatly convenient for attackers, because they could deliver a nice payload and get it executed in one step. The NX bit stops this, because the stack is not executable.

However, return addresses are still on the stack, and can still be overwritten, and can still change program flow in ways that are potentially advantageous to an attacker. NX does not prevent this. Read up on "return into libc" for the first example. Address space randomization makes "return into libc" more difficult, but again, that is just the most convenient attack.

So long as it is possible for user-supplied data to overwrite return addresses, it will be possible to cause results not intended by the developers, some of which will be advantagous to attackers.

Re:The YAPPing language is for dogs

[biodata]

This is wrong. We have malware because criminals will crim. A new programming language will have zero effect on this.

Re:The YAPPing language is for dogs

[Anonymous Coward]

If you blame x86 for single stack, then not for CALL/RET. You do need a call stack if you want to do subroutines. Blame PUSH/POP and SS-relative addressing, because those are what allows to put data on the call stack.

Re:The YAPPing language is for dogs

[Anonymous Coward]

NX prevents you from writing code into the stack. It doesn't prevent you from modifying return addresses on the stack, which may cause code which is present to be executed at a time where it should not be. For example, it may bypass a password check.

Yes, it's certainly harder to exploit than when you can just write arbitrary code on the stack. But it doesn't mean you cannot exploit it.

Re:The YAPPing language is for dogs

[tibit]

Just use a base pointer that's decoupled from the stack pointer, and use it as a hybrid base/stack pointer. There's no performance penalty for that on modern architectures. The modern implementations of push/pop are really just syntactic sugar implemented at hardware level. I bet it'd be a small patch to LLVM to add such an ABI.

Re:The YAPPing language is for dogs

[tibit]

When both PC and data are passed through the stack that's subject to overruns, you can have perfectly good exploits that don't need executable stack. Only decoupling of the PC and data stacks can fix that. Ideally the PC stack would be protected by the MMU and only modifiable by CALL/RET, but so far no hardware supports that.

Yet another trendy language

[Anonymous Coward]

A Chinese ripoff of Go.

Cool.

Re:Yet another trendy language

[NeoHermit]

Funny, the world didn't start with Go. Much of Dao was developed before Go came out. Only recently Dao borrowed a few features (channel, defer and defer-recover) from Go, every other features that look like from Go actually existed well before Go even came out.

Re:Yet another trendy language

[Anonymous Coward]

Cheap shot, and wrong with it.

Whats Dao good for?

[Anonymous Coward]

I don't have any numbers, but I'm pretty sure anything with an LLVM JIT shouldn't have a "small runtime" as its headline feature. LLVM is a fantastic tool, and a minimal use of it isn't huge (or even big) by most standards, but using an off the shelf JIT compiler really shouldn't make you celebrated for a small runtime.

Anyway, looks like it has some implicit type conversions (I saw a float to int in an example), and optional typing. I prefer explicit conversions and explicit typing (like Go has for example). I also prefer statically compile languages.

As for the feature set, I don't see anything about generics, templates or meta-programming, but at least theres some something that looks like Java generics on one of the build in map classes in an example.

It seems to have good closure support, and looks good at wrapping/calling C and C++.

Does anyone know of an example generic collection in Dao? That is the one thing I'd like from Go thats its not very good at, so I'm always on the lookout for how languages solve that.

Anyway, it seems like a usable language, which I have no reason to use, and several reasons not to (JIT, lower readability than Go among other things). Their promotion fails to provide anything I miss in Go, or Python.

Sure, it might be better at some things than C++ (it can call C++, and has closures, and other nice things in a garbage collected environment), but I don't use C++ because its a good language: I use it because I have to.

I think I'll learn Rust and Haskell before bothering with Dao (AKA, most likely I won't get to it). They look interesting but I see nothing in Dao, except perhaps for being good at calling into C, that interest me, and I can call into C great from C, Go, Python, C++, and Rust if I learned it, and apparently as of 2010, Haskell.

New language: big feature, not too bloated JIT, and can call C and C++ code easily. So? Why should I care?

Apparently it has an extensible syntax (I generally see that as a bad thing) and garbage collection, and nice scripting language like syntax. Perhaps it would be good for creating domain specific languages to control your C++ code? Thats the only real use case I see, but its competing with exiting python tool chains for that, as well as Lua. Not to mention I'm not really sure if thats something worth doing.

Go is good for servers. Whats Dao good for?

Re:Whats Dao good for?

[NeoHermit]

I don't have any numbers, but I'm pretty sure anything with an LLVM JIT shouldn't have a "small runtime" as its headline feature. LLVM is a fantastic tool, and a minimal use of it isn't huge (or even big) by most standards, but using an off the shelf JIT compiler really shouldn't make you celebrated for a small runtime.

The JIT compiler was implemented as a loadable module, which is not counted as part of the core.

As for the feature set, I don't see anything about generics, templates or meta-programming, but at least theres some something that looks like Java generics on one of the build in map classes in an example.

It does have generics, for built-in array, list, map and tuple types etc., it is also supported for C data type. Not well documented yet.

Does anyone know of an example generic collection in Dao? That is the one thing I'd like from Go thats its not very good at, so I'm always on the lookout for how languages solve that.

See above.

Anyway, it seems like a usable language, which I have no reason to use, and several reasons not to (JIT, lower readability than Go among other things). Their promotion fails to provide anything I miss in Go, or Python.

There are a few main things not available in Go or Python such as optional typing, syntax macro, code block method, parallelized code methods, but you already stated you don't like optional typing, not sure about the others. There are several other major features that are either not available in Go or not available in Python.

Go is good for servers. Whats Dao good for?

I can count game scripting as one due to its simple C interfaces and small runtime (without all the optional stuffs), and numeric computing as another since its JIT compiler is optimized for numeric computation. It is probable also good for server because of its concurrent programming features, but probably not as good as Go, since Go is statically compiled. You already mentioned domain specific language, I think this count as well. It also must be good for being used as a glue language due to its simple C interfaces and the automatic binding tool based on Clang.

Re:Whats Dao good for?

[Anonymous Coward]

So it seems to aim for the same niche as Lua/LuaJIT.

Game scripting - check, basically _the_ game scripting language
Simple interfaces, small runtime - check, ~500kb for all of LuaJIT on x64.
Numeric computing - check, LuaJIT does very good job optimizing numerics. Also check GSL Shell - LuaJIT + some extensions + bindings to GNU Scientific Library.
For servers - no concurrency, but being extremely lightweight does a good job on servers as multiple processes.
DSL and glue language - check, metatables and userdata really help there. Look at LPeg, for example
Simple C interfaces and automatic binding - LuaJIT's FFI does a pretty good job. While not automatic, copy-pasting from preprocessed C headers is usually all you need.

Re:Whats Dao good for?

[tibit]

The syntax macro is a bit silly. You really want arbitrary computation in macros, not just an AST-ified regex search-and-replace. LISP got it right.

Re:Whats Dao good for?

[tibit]

Oh, you must be the author, or inspired by the author, then, due to your chronic overuse of the plural. It's not stuffs, it's stuff. It's not C interfaces, it's the C interface. It's not codes, it's code. Hint: don't learn English from forum posts where people ask for teh codes. It would also help if the web-based documentation didn't use a fixed width font and was presented in a slightly more neutral color scheme.

All I could think of ...

[PPH]

... is a programming language named D'oh!

YAPL

[whargoul]

Yet Another Programming Language

Re:YAPL

[mchnz]

It's not like the ones we have are so fantastic, the more experimentation the better.

Interesting

[Anonymous Coward]

Looking at sample code, Dao looks very similar to Matlab, especially with lists/cells, vectors, matrices, and loops. The biggest differences are: a closing brace instead of "end" and routine instead of function.

They're going to need a new name though, because searching for anything returns the Microsoft Data Access Object.

TFA got the name wrong - should be DOA

[Anonymous Coward]

It should be called DOA, not Dao.

Please let Pascal die

[functor0]

I was at first intrigued by the summary, but then it got worst and worst as I saw the examples. Semi-colon statement rules in the Pascal tradition? Ugh.

Hmmm

[geezer nerd]

I thought the word that is pronounced "Dao" is spelled as "Tao", meaning "the Way". So, what is a "Dao"?

Re:Hmmm

[Anonymous Coward]

Chinese has many dialects and many englishizations. There is no one 'spelling' in english characters.

One man's dofu is another mans tofu.

Re:Hmmm

[NeoHermit]

This language was once named as "Tao", but then renamed to "Dao", because of a name conflict with another programming language named Tao. The meaning of the name remain the same.

Re:Hmmm

[ChunderDownunder]

dao used to be a common coding acronym for Data Access Object, viz a wrapper around sql.

(Then they came up with POJO)

No, what you mean is...

[Anonymous Coward]

CREMATE HIM!

As the dustmen say: 'It's the only way to ensure he meets the Final Death.'

This is a first

[Anonymous Coward]

First time I've seen Chinese contributing to an open source project without being chased by the FSF. Instead of contributing to an existing open source language they are creating a new one with a ... Actually the guy is in a US university. Oh well. I'll keep waiting.

Banned IP

[phil31753]

Its going to get a lot of traction in the Philippines as my IP (assigned by a major local telco) is banned from the site

optional typing?

[stenvar]

Dao doesn't seem to have "optional typing", it seems to have a choice between static and dynamic typing.

Re:optional typing?

[Anonymous Coward]

Optional explicit typing is it, then?
On the other hand, every programming language has a type.
Even if everything is stored as string and gets converted for about every operation. It's a one type weakly typed language.

Redundant summary is redundant

[MikeTheGreat]

Could we have someone, maybe an editor, tighten up the summary a bit? Here's what I see:
idea : # times it occurs
"Let's mention this on /." : 3
"It's done" : 2
small runtime : 2
features : 3 (plus that laundry list of actual features)

Instead, let's try this:
"The Dao language has recently made its first beta release, and we think you Slashdotters will Eff'ing love it. Dao is an optionally-typed programming language that supports many advanced features (probably as many as Python ) with a small runtime (closer to Lua than Python). Besides optional typing, Dao also has built-in support for concurrent programming for multicore computers, very friendly C programming interfaces for embedding and extending, an 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."

See? That wasn't so tough, probably took 5 minutes, and is much more readable....

This is getting boring

[vikingpower]

Is a new language really what we were waiting for ? I seriously doubt it. Existing languages already do, or are capable to do, the most exotic things for us. I look at it from a software architect's viewpoint: what we need is not yet another language, we need new design and programming paradigms. Like, for example, people in the place I currently work for reacted enthusiastically upon the BDD ( Behaviour-Driven Design ) idea; most of the somewhat older engineers had never heard of it. We need new ways and schools of thought, resulting into what already happened and has been happening in other engineering domains for a long time: the hiding of complexity. IMHO, Dao does not contribute toward this goal. Certainly, as in intellectual and engineering exercise, the creation of a new programming language is interesting. Nowadays, such compiler- / interpreter-construction exercises are within the reach of any graduate student. It does not, however, reach into the heart of many of the "wicked problems" with which engineers in real life are confronted.

Re:This is getting boring

[mchnz]

The nuts are bolts are still important. Java framework hell is partially a result of the language's shortcomings. Clearly some languages and tools can do some jobs in hours/days when it takes days/months using others, but then seemly productive tools fall to bits when used for other kinds of jobs. There is much to look at this level, it cannot be dismissed so lightly.

Re:This is getting boring

[Anonymous Coward]

I am totally sure one of your 10^17 Java Frameworks and pseudo-science approaches will help you Java Programmers to Count The Beans in one more way.

Meanwhile other people are doing real work with real languages. Please stay in your beancounting corner and leave the adults alone.

Re:This is getting boring

[tibit]

Well, your language better supported those new paradigms in the sense that it should be flexible enough to let you express those in code, without resorting to a stack of external preprocessors. That's IMHO the feature that makes LISP so great. Myself I'd treat LISP as an archaic artifact if it weren't for its macro system. The closest approximation we have in scripting languages is eval, but that really has bad code smell, never mind that you lose any capacity for compile-time checking of the generated code.

It's the beginning of a song..

[Anonymous Coward]

Daylight come and me wanna go home.

My opinion and some free unsolicited advice ;-)

[aaaaaaargh!]

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.

Re:My opinion and some free unsolicited advice ;-)

[msobkow]

Because {..} takes a lot less typing than begin..end.

If people wanted to type excess verbiage, they'd stick with COBOL.

Re:My opinion and some free unsolicited advice ;-)

[Anonymous Coward]

I can't even get my friends to keep line endings the same in one file when they use different editors, and you expect them to handle python-style white space around code blocks correctly? Pretty soon someone will remove a loop here or insert an if-statement there and suddenly the whole code is a mess and it will be impossible to decipher where one block ends and another begins... unless you start to put comments on every start and end of a block, which becomes incredibly verbose and annoying fast, much like begin and end keywords.

These are the reasons why c-style braces are popular for code blocks. Go ahead and try something else if you like... as long as it's a single, easy to type ASCII character and visible clearly bounding the block. You'll notice the braces are one of the few characters that make sense for this purpose.

Re:My opinion and some free unsolicited advice ;-)

[Anonymous Coward]

I've used a language called Suneido www.suneido.com, It has a C-Style syntax, but without the "garbage" , I mean no semicolons not forced parenthesis , It's internal structure is a cross breeding betwen Javascript and SmallTalk... you have a workspace for evaluations, a Class Browser, all in all a beutiful language, BUT it is not a general purpouse language, it includes it's own Database system and is a language deemed for "Business Applications".
If you are a language Hobbist, take a look on it, it's creator, Andrew McKinlay is a nice guy allways willing to answer questions, and a very talented programmer.
I really think Suneido deserves much more attention that it gets.

Re:My opinion and some free unsolicited advice ;-)

[Rockoon]

...and the semicolons that are nearly universally found right before newlines? Thats less typing?

Tell me sir, how good are most compilers for languages that use semicolons at figuring out what the problem is when a semicolon is missing?

This is the major flaw of the C-style syntax, not the curly braced blocks. If A often comes before B, then the semantics of A are clearly less than ideal, especially when B is then always treated as not existing at all.

Re:My opinion and some free unsolicited advice ;-)

[Anonymous Coward]

Because {..} takes a lot less typing than begin..end.

If people wanted to type excess verbiage, they'd stick with COBOL.

There is a lot between COBOL and nice Lua end token.

Re:My opinion and some free unsolicited advice ;-)

[Anonymous Coward]

Also, the brackets have uncomfortable positions at the keyboard.

Re:My opinion and some free unsolicited advice ;-)

[Xyrus]

I say we create a language that uses emoticons to indicate the nature of objects,methods, etc. For example: :D || :O methodName( .|. ||| arg1) ( Exception

Means: public parallel void methodName(final int arg1) throws Exception

Re:My opinion and some free unsolicited advice ;-)

[mdmkolbe]

Why do so many contemporary language designers choose C-style syntax and not Algol/Pascal/Ada style?

As long as we're talking about better syntaxes, don't forget the ISWIM/Miranda/Haskell style which IMHO is one of the best.

Re:My opinion and some free unsolicited advice ;-)

[angel'o'sphere]

That depends.
Actually on a german keyboard on a Mac as well as under windows 'begin' and 'end' is faster to type than { and } because you need a weird alt / number combination to type it. Luckily the IDE places a closing } automatically when you type the {. Otoh I have remapped the german umlauts and the {} [] keys to the position they have on an american keyboard. So now I can nearly type 10 finger style when programming.

Re:My opinion and some free unsolicited advice ;-)

[NeoHermit]

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

Probably "optional typing" was a confusing term to use. In Dao, optional typing is about omitting explicit type names when they can be inferred, to free programmers from typing tedious type names. Dao does type inference for variables declared without explicit types. There is static type checking at compiling time for any variable with explicit or inferred types, and dynamic type checking at running time otherwise. This is a good way to combine the flexibility of dynamic typing and the safety of static typing. Unfortunately, it seems many people misunderstood the whole point of optional typing (if the term can cause confusions, I wonder which term is better).

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

The problem with Pascal style of blocks is that it is more verbose to type begin/do-end, and it requires better IDE support to do syntax highlighting and code auto-indentation etc. As for readability, it's mainly an issue of personal preference.

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.

You have a good point here. One way to make a language highly optimizable is to restrict the dynamic features of the language.

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

If you mean a system language, I agree.

Re:My opinion and some free unsolicited advice ;-)

[tibit]

Why do so many contemporary language designers choose C-style syntax and not Algol/Pascal/Ada style?

There are two sides to the Pascal style. One is the block delimiters. That's really a matter of preference and doesn't change how the AST looks, so let's not dwell on it. The other side is about the declarations forced into "neat" little blocks. That arguably has some downsides. For one, the declarations may be far from the point of use. Another issue is that Pascal really doesn't have block-local variables at all. Local variables are local to a function. C-style local declarations can be very handy in making the code readable. Locality of reference is good for humans too! I'd take for (auto i = 0; i < 100; ++i) over var i: int; {mucho variables} begin {mucho code} for i:=0; i<100; i:=i+1;... any day. Pushing the Pascal-style to a modern type-inferring language makes the var block look silly: var i,j,k,l,m:auto; {and so on} That's one of the things that IMHO modern C++ got right. Type inference and explicit variable declaration at point of use. Keeps the code readable due to locality of reference and terseness.

Re:My opinion and some free unsolicited advice ;-)

[NeoHermit]

var block look silly: var i,j,k,l,m:auto;

This does looks silly. I don't know which language do it this way, ":auto" is clearly redundant. "auto" is needed in C++, because type names are required to appear before variable names, so for type-inferred variables, a keyword such as "auto" is required for the code being parsed correctly.

But in Pascal style variable declaration, you don't need "auto" or any other keyword for type inferred variables. Because it is simple, a missing ":type_name" clearly means the variable is declared without explicit type, so it should be a type-inferred variable.

Re:My opinion and some free unsolicited advice ;-)

[tibit]

Even without the :auto, relegating the declarations to a block that's far removed from where the variables are used makes no sense today. Historically it was an idea that made Pascal easy to parse and compile with a single-pass and low memory consumption. It should be treated like what it is: a historical artifact of no further use.

Re:My opinion and some free unsolicited advice ;-)

[NeoHermit]

Even without the :auto, relegating the declarations to a block that's far removed from where the variables are used makes no sense today. Historically it was an idea that made Pascal easy to parse and compile with a single-pass and low memory consumption. It should be treated like what it is: a historical artifact of no further use.

Well, no argument against this. But I doubt many new languages are following or will follow Pascal on this. Variable declaration by "var name" or "var name : type" can be placed in exactly the same way as in C++, at least this is the case in Dao. For example, in Dao you can do: for(var i=0; i<10; ++i)...

Re:My opinion and some free unsolicited advice ;-)

[tibit]

Sigh, the whole thread was started by a flamebait question "why no Pascal-style syntax". You kinda missed that subtle point :)

Re:My opinion and some free unsolicited advice ;-)

[NeoHermit]

Right. I forgot you were simply trying to answer that flamebait question, my bad :)

YABL

[iliketrash]

YABL. Come on, people, really?

Unsafe arrays.

Forced-indexing into arrays.

Not interested.

Yay - another language! NOT!

[Anonymous Coward]

The scourge of software development is the number of languages, and the Balkanization of an industry that used to have standards. I think that we have enough languages with C, C++, Java, C#, Objective-C, Perl, Python, Ruby, PHP, JavaScript, REXX, LISP, Haskell, Clojure, Lua, R, Ruby, Dart, Go, etc (the full list would go on for days) and all the reinvented wheels in each language for database access, MVC, etc. Being a software developer these days is cognitively difficult because these languages are all the same, but different. They share superficial syntax similarities, but they all do the same thing in a different way. (As an exercise, list the different ways to get the length of a string in different languages.) I often know exactly what I want to do, but have trouble remembering how to do it in any specific language.

There are 2 problems: Each vendor wants to Balkanize the world with their own languages. (Microsoft=C#, IBM=Java, Apple=Objective-C, etc.) And, everyone in open source wants to be the next Larry Wall or Guido and start a new language rather than work to improve existing ones.

i worked on a t-16 back home

[decora]

and let me assure you, when we were bullseyeing wamprats, there wasn't no goddamn virtual machine. just you and the trigger and beggar's canyon. that was it. and if you bought the farm? well, we poured out a 40 at your funeral, but we didn't put any flowers on your grave.

holy christ someone call the ghostvysters

[decora]

this is worse than dogs and cats living together.

One question

[Anonymous Coward]

Is the code cromulent? Does it have a cromulator?

And may it die it's well deserved death...

[gestalt_n_pepper]

Not because it's a bad language. It may be great. The fact is that nobody... I mean *nobody* needs one more obscure little language whose wondrous new features would just be another add-in library in C++. This is a mental masturbation tool for the Mom's basement crowd. Nothing more.

Re:And may it die it's well deserved death...

[dkf]

The fact is that nobody... I mean *nobody* needs one more obscure little language whose wondrous new features would just be another add-in library in C++.

Some programming languages have been sold into strict C-only shops on the basis that the implementation is just a "C library" and the script files were just "soft configuration definitions". You know that's silly, and I know that's silly, but it's happened for sure. (Also, being a nice add-in library can be a nice ambition: that's a real niche, even if an occupied one.)

You're right that the USP is unclear though. Why would anyone bother with it as opposed to the plethora of other very similar languages that exist and have existing user communities?

Re:And may it die it's well deserved death...

[tibit]

Well, at least it gave - hopefully - some fun and satisfaction to the author, so your statement that nobody needs this language is false on its face. I'd also tend to think that mental masturbation may be sometimes more productive than genital masturbation, unless you need to be working on your arm strength, that is. I'd also be a bit careful with the implication that living in one's mom's basement is always undesirable. Some moms are very good cooks :)

And Go is miserable enough.

[toby]

n/t

Agree and Disagree

[gr8_phk]

I agree with your conclusion that too many people don't know what they need code to do. I disagree on optional typing. For large applications I think typing is necessary, but for small things it really can get in the way and slow things down.

For simple data processing apps I like Python because a=5 is automatically an integer and b=2.5 is automatically a float, I don't need or want to include type information on every variable - particularly temporaries with intermediate results (cause it looks like shit inline and I don't want to go back to top and declare them). I totally agree that this is lazy programming practice, but again I think it's appropriate for small throw-away programs or prototypes. OTOH in those cases a compiler could infer the type of an expression if the types used in that expression are already known. Why isn't this done?

Types of elements in a matrix multiplication

[tepples]

In a CAS, the matrix multiply, for example, just needs to add and multiply values from elements in the matricies. It doesn't care what types they are.

Of course it cares. All elements of each matrix need to have types such that the operations A * B = C and C + C = D are defined. The common case is that all the elements are of the same type, and this type is a ring. Otherwise, should the entire matrix multiplication fail, or should individual elements be undefined? But you're right that these types don't necessarily have to be explicit. This looks like a good application for inferred static typing, as in ML-family languages.

Re:Types of elements in a matrix multiplication

[DickBreath]

In matrix multiply, the types of elements do not have to be the same. They only have to be types the add and multiply functions can accept and return values for. Those returned values must also be acceptable as subsequent inputs for some operations like matrix inversion.

Examples of matrix element types that would commonly be expected to work: integers (fixnums such as int or long), floats (such as double), unlimited integers (like BigInteger) or unlimited fixed point (like BigDecimal), or fractions (ratio of two integers).

In a CAS, values might even be symbols (PI, e, i) or symbolic expressions (3a+b^2). As long as the multiply function can accept a ratio (1/2) and a symbolic expression (3a+b^2) and return a new value ((3a+b^2)/2). Then matrix multiply doesn't much care what the underlying types are.

But some function does. Ultimately in this case, the add and multiply functions. This is where the cost of dynamic languages often bites (depending on implementation). For most everyday (non CAS) cases, it is a huge waste to have to check the types of arguments for addition. The compiler should have known and hardcoded the call to the correct type promotions and addition subroutine.

I know Lisp, and am starting to use Clojure. But I do not know ML. I've wanted to look deeper at it for years. Unfortunately, I am unable to understand your reference to inferred static typing until I look deeper. Thank you.


Your sig: APK? You mean an Android application file with the ".apk" extension. :-)

Multiplication of types; Java interfaces

[tepples]

The way it's proposed that it will work is that you define (e.g.) a number concept, which encapuslates the idea that +,-,*,/ and perhaps exp and log are implemented.

By "number" do you mean "element of a field"? Matrices of appropriate size support +, -, and *, but generally not / without (expensively) computing an inverse. Vectors support + and - with vectors of like size, and * and / with a scalar on the right side. But there are several different interpretations for vector * vector: "scaling", which is elementwise multiplication; "dot product", or sum of scaling; and "cross product", used for finding an orthogonal vector, which isn't binary unless the vectors are of length 3.

You then write the code, and it checks the code against the concept

What's the difference between a concept and what Java calls an interface?

Re:Multiplication of types; Java interfaces

[serviscope_minor]

By "number" do you mean "element of a field"?

No, not necessarily. Signed integers in C++ do not, for example form a field due to undefined overflow. Floats are closer, but are not perfect fields and also have out of field elelemts like Inf and NaN.

Also, technically fields support +, *, additive inverse and multiplicitave inverse, rather than - and divide. In the case of matrices, this is apparent where one generally writes inv(A) not I/A.

What's the difference between a concept and what Java calls an interface?

There are small and large differences. The small differences are:

They are related but there are difference. Concepts are early (compile time) rather than late (run-time) binding.

Concepts generally make heavy use of overloading, so, for example, numeric algorithms all look like numeric algorithms.

Crucially, concepts provide retroactive modelling, so that anything which fits the right concept is an example of the concept: there is no need to go and make sure the type is derived from the right interface. In this sense, the object orientation in Go is much more like concepts.

The big difference however is that a concept is more than just a list of methods that a type supports. You can essentially include a much more detailed list of predicates, for instance that it must be incrementable, must be dereferencable, the derference type must be addable to any numeric type, things like that.

In other words, concepts allow you to describe a much more nuanced concept than just the list of method calls supported.

Re:Multiplication of types; Java interfaces

[maxwell demon]

One important difference is that you can write a concept after a class that is a model of that concept is already written, and don't have to rewrite that class to refer to that concept. You just have to tell the compiler that the class fulfils the concept, and the compiler then checks whatever it can check (like existence of certain members). Of course the correct semantics cannot be checked by the compiler (nor can it be with Java interfaces). Indeed, you can even tell the compiler that a certain built-in type fulfils the requirements. Optionally you also can tell the compiler that any type fulfilling the structural requirements shall automatically considered a model (that's especially meaningful for concepts like CopyAssignable, where the semantics of the corresponding function is more or less required by the language).

Another important difference is that it is checked at compile time during template instantiation, and therefore the full type information is available. Therefore you don't get type erasure as with interfaces. Consider the poster child of generic programming, but this time with using concepts:

template<Comparable T> T max(T a, T b) { ... }

On first view, this seems equivalent to the Java code

IComparable max(IComparable a, IComparable b) { ... }

Bot check that the arguments are actually comparable.

However imagine you have two types which model Comparable, say Length and Velocity, and consider the following code:

Length l = ...;
Velocity v = ...;
return max(l,v).toDouble();

With Java interfaces, you'd derive both types from IComparable. At the call to max, the compiler would convert both values to IComparable, and therefore won't complain. Whether this fails at runtime depends on the details of how the types are implemented (with some bad luck, ultimately toDouble() for both types is compared, and the nonsensical comparison is not caught at all).

With concepts, you'd declare that each type models the concept Comparable. However since there's no conversion involved, the compiler will notice that the two arguments are not the same, as required by the definition, and therefore will reject the call, despite both being a model of Comparable. On the other hand, if both types are the same, the call will succeed.

Of course if you explicitly want to allow different types, you can do that, too:

template<Comparable T, comparable U> foo(T a, U b) { ... }

Predicates other than implementing a method

[tepples]

Concepts generally make heavy use of overloading, so, for example, numeric algorithms all look like numeric algorithms.

Even though Java doesn't translate operators into method calls, a lot of other languages do, such as C++ and Python. Those could be included in a concept/interface.

Crucially, concepts provide retroactive modelling, so that anything which fits the right concept is an example of the concept: there is no need to go and make sure the type is derived from the right interface.

Is this supposed to be analogous to the difference between nominative typing and duck typing?

The big difference however is that a concept is more than just a list of methods that a type supports. You can essentially include a much more detailed list of predicates

I'm still not understanding what sort of predicate cannot be expressed as implementing a particular method.

for instance that it must be incrementable

A type that supports the "increment" method is incrementable.

must be dereferencable, the derference type must be addable to any numeric type

A type that supports a "dereference" method that returns an object whose type implements the appropriate "numeric" concept/interface would satisfy this predicate.

Re:Predicates other than implementing a method

[serviscope_minor]

Is this supposed to be analogous to the difference between nominative typing and duck typing?

Concepts are duck typing, where you get to specify the definition of a duck in detail, and the compiler checks it early.

I'm still not understanding what sort of predicate cannot be expressed as implementing a particular method.

So, one example void operator++() on an iterator can be satisfied depending on whether or not it conforms to an interface.

Requiring that Iterator::operator*() returns type T would require the interface being parameterised.

Requiring that Iterator::operator*() is convertible to type const T& is beyond the capabilities of interfaces.

Other examples are that one can (at least in the current implementation) switch on and off methods of a template class depending on properties of the class. For example you might provide operator== for std::vector, if and only if operator==(T, T) is convertible to bool.

A good read about concepts-lite (only part of the overall idea of concepts)

https://groups.google.com/a/isocpp.org/group/concepts/attach/df9a57cb574ae9f9/concepts-lite.pdf?part=4&authuser=0

A type that supports a "dereference" method that returns an object whose type implements the appropriate "numeric" concept/interface would satisfy this predicate.

It is not obvious to me that interfaces are as general.

For example take the example of a determinant function. If the the matrix argument must be over a field type, so clearly determinant must return a Field.

With the Java style of interfaces this would return an object for which would look something like:

Field.add(Field);

which encapsulates some of the ideas behind a field.

At this point, however the type of field has been lost, and you could at compile time attempt to add any Field to any Field, even though adding GF(2) to complex is not possible.

Re:Predicates other than implementing a method

[tepples]

Requiring that Iterator::operator*() returns type T would require the interface being parameterised.

I thought existing type inference tools could handle what amount to parameterized interfaces. And C++ already handles the concept of "is convertible to" through the One Implicit Conversion Rule. But you make a good point about the duck typing aspect.

Re:Predicates other than implementing a method

[serviscope_minor]

I thought existing type inference tools could handle what amount to parameterized interfaces.

In general, though I do not know if that's possible in Java---it's not given my knowledge of Java, but that is admittedly very incomplete.

Certainly that kind of thing is possible in general with type classes. My knowledge of those is also a bit limited.

And C++ already handles the concept of "is convertible to" through the One Implicit Conversion Rule.

Indeed, but this allows the return type to be anything that's convertible to T, rather than T explicitly. This is making it into some of the current STL concept specifications, for example there are predicate concepts which merely require the return type to be convertible to bool, but places no other restrictions on it.

That's certainly within the realm of type classes, because it is more or less equivalent to specifing a .toBool() method, or in C++ese operator(bool)().

For interfaces it would require everything to be derived from ConvertibleToBool, which requires everyone to agree in advance which interfaces to use.

One interesting thing which has been proposed in concepts which is very much not part of type classes is axioms: for instance you can assert to the compiler that certain things are equivalent. This can be used to tell the compiler that things are assosciative and distributive for example, without the compiler having to prove it (it often cannot). This will allow the compiler to perform a wider range of optimizations.

Another interesting thing which is different from type classes is concept maps. This allows you to take a class which has the correct concept from a high level point of view, but the wrong interface and automatically present it as one of the specified concepts.

For example, std::stack has the push() and pop() methods.

std::vector has push_back(), pop_back() etc methods.

Those methods are equivalent, but in the stack case, you don't care *where* they are pushing. Nevertheless, the same concept is being represented. Maps would allow you to use a vector as a stack without writing and using a wrapper class.

Chinese Connection

[Anonymous Coward]

Um, it seems to me that the reason why Dao exists is because it has better support in the Chinese-speaking community than any other language; i.e. it solves the "not invented here" syndrome. Given things like the DragonChip project and the focus on making China more independent of the outside world, if anything I'm surprised it took so long for a major language to come from that region.

Am I the only one to notice this, or does everyone things languages just appear, and aren't developed by real people with various affinities and psychological motivations?

Clearing BSS first

[tepples]

Even if you're referring to a "freestanding" implementation of C without most of the standard library, the runtime still needs to clear uninitialized statically allocated variables to 0 (for numeric types) or (void *)0 (for pointer types) before calling main().

embedding/extending

[smcdow]

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

I don't know the first thing about Dao, but I'm always interested in any environment that makes embedding/extending easier. When you're working with a 15 year old code base, it's a lot cheaper to embed existing libraries into a new system than it is to re-write them. (Or, add new capabilities to a old system via extending).

Alas, there has never been a language where this capability doesn't end up being an absolute CM nightmare.

What is in a name?

[manu0601]

dao means knife in Chinese, but why the name? Is it because it is cutting edge?

The documentation makes me go "aargh"

[tibit]

Every time I see the word "codes" in the documentation, I throw up a little. It's an otherwise decent documentation, but man, does it have to reuse the language wart that makes us laugh and cry so hard at the clueless "show me teh codes" posts on the forums?

Wrapper classes as concept maps

[tepples]

For interfaces it would require everything to be derived from ConvertibleToBool, which requires everyone to agree in advance which interfaces to use.

In C++, this would be "implements operator bool()"; in Python 2, this would be "implements __len__() or __nonzero__()". Again, the difference is that concepts can be imposed on existing third-party code.

Maps would allow you to use a vector as a stack without writing and using a wrapper class.

Then what would be the practical difference between a concept map and a (templated) wrapper class that either extends or contains the type being wrapped? I'm just trying to figure out how concepts could be implemented in existing languages.

Re:Wrapper classes as concept maps

[serviscope_minor]

Oh sure.

Concepts are for duck typing, so they can indeed be applied to third party code. The main thing is that they apply statically, and early. Actually, templates and python duck typing are cut from the same cloth. The templates are programs which run at C++ compile time.

An error in either can yeild a stack trace. In c++ this manifests the compiler dumping the entire template stack. Obviously in Python you can catch the exception.

Concepts apply to the compile time of the templates (i.e. parse/definition time), not their runtime (the C++ compile time).

For concept maps, I'd imagine in python it would be something like a dictionary which maps class names to a dictionary. The second dictionary maps maps method names to method names.

So, when you call a method, if there's no dictionary entry, you just use the name expected. Otherwise, you look up the mapping and use that to determine which method to really call.

Obviously concepts make this automatic and transparent. I imagine with Python's reflection capabilities you might be able to make something similar work. Of course the concept map in python would be a global: the maps in C++ are effectively global, like the definiton of a class.

 

Re:Wrapper classes as concept maps

[tepples]

For concept maps, I'd imagine in python it would be something like a dictionary which maps class names to a dictionary. The second dictionary maps maps method names to method names.

So, when you call a method, if there's no dictionary entry, you just use the name expected. Otherwise, you look up the mapping and use that to determine which method to really call.

Unless the number and order of arguments differs. Then the concept map would have to become what amounts to a class with inline methods.

Re:Wrapper classes as concept maps

[serviscope_minor]

Unless the number and order of arguments differs. Then the concept map would have to become what amounts to a class with inline methods.

Actually, re-reading the paper, that seems to be what they are. They are at one point described as "mini classes". They are of course used automaitically.

So, I guess you could do the same with a dictionary mapping strings to classes.

No. Optional ANYTHING is highly desirable

[foreverdisillusioned]

I understand that when working on large projects, especially with mediocre programmers, you may want to restrict the number of tools available. That's fine; but that belongs in your firm's coding guidelines, not the language spec. If they can't or won't follow those guidelines, then either fire them or write a tool to automatically catch disallowed constructs.

Forcing all programmers to do extra work to minimize the damage done by incompetents is a horrible, horrible paradigm and keeps us locked into the vicious cycle of minimalistic==>expressive==>minimalistic-again programming languages.

Waiting for the book ...

[Dabido]

The Tao of Dao!