I wonder if they are aware of this possibility.
Even without the
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.
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)?
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.
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.
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!
It's currently a problem of access to gigabits through punybaud. -- J. C. R. Licklider
