...in an attempt to create a manageable Github repository of government-banned Chinese keywords in internet search terms and which may appear in Chinese websites.
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)...
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.
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...
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.
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.
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.
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.
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)?
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.
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.
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.
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.
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.
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.
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.
A few hours ago, I was just thinking this might happen someday, and wondering if I should use sourceforge for the downloads of my next software releases in the coming days. Never thought that someday might be today!
Slashdot Mirror
I wonder if they are aware of this possibility.
Right. I forgot you were simply trying to answer that flamebait question, my bad :)
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)...
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.
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.
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
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.
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.
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.
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)?
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.
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.
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.
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!
Thanks for pointing it out.
Please don't forget the "not vice versa" part, Dao has many features that Go does NOT have.
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.
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.
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.
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.
A few hours ago, I was just thinking this might happen someday, and wondering if I should use sourceforge for the downloads of my next software releases in the coming days. Never thought that someday might be today!