Untyped languages are okay. Typed languages are also okay. Typed languages with inference are okay.
Optionally typed is extremely strange.
Optionally typed is extremely strange.
It's far more readable and concise having it embedded in the language rather than buried and disjointed in the comments. Not to mention it also allows for superior tooling support.
I've personally been extremely productive with Dart (most productive I've ever been with any language). It's effectively a more consistent JavaScript with less ceremony with the benefit of optional typing which has caught errors on a number of occasions, giving instant feedback and identifying errors before I've even run the code.
Although Dart on the server is still in its early stages so you might not find all the libraries you need, e.g. I ended up writing my own Redis Client (https://github.com/dartist/redis_client) since there were fewer mature options. All the server APIs are there for you to build a node-like server, it's just the web frameworks and view engines are currently lacking so you might find yourself having to write more frameworks/libraries than you would otherwise on node (which is a lot more mature atm).
I'm hoping after the Dart team finish the work on integrating the Dart VM into Chrome that they'll focus on the server-side of the "full stack" and provide support for App Engine, incidentally star this issue if you would like to see support for this sooner: https://code.google.com/p/googleappengine/issues/detail?id=6...
When I write a Haskell program, I start with the types and the code grows from there. The types are really the foundation for everything else. It doesn't really make sense to view the code without also thinking about types: after all, Haskell code is centered around functions, and functions are defined by their domain and codomain.
Among other things, this means that the types actually help me to prototype. Iterating on different types and seeing how that changes the sort of functions I can write is a very powerful technique. This is going to become even more apparent in the near future with features like type holes. The basic idea there is that you can leave parts of your code blank, and the compiler will tell you which type goes there! The type system can actually help you write the code.
Honestly, I think the difference between types in Java and Haskell is at least as large as the difference between types in Java and dynamically typed languages.
Basically, in Haskell, the types go well beyond correctness. I hope this clarifies what I mean.
Here's optional type annotations in Haskell, which uses type inference by default but lets you override types with annotations. Note that f and g have different types, but the same body.
-- Haskell
f = return 5
g :: IO Int
g = return 5
; Dynamic +3 function
(defun add3 (x) (+ x 3))
; Static +3 function for integers
(defun add3 (x)
(declare (type integer x))
(+ x 3))In Dart, the types appear to be little more than advisory documentation.
I don't know Lisp; what happens to your add3 if you pass a thing that can't be added to 3? Does it crash at some sort of 'type checking phase' (whenever that may be) or only when it finally discovers it can't do the addition, essentially ignoring the type declaration? (Or both and neither, depending on what exact Lisp and macro set you're using, which is my guess.)
I may be wrong, but I suspect you don't know how Haskell type inference works. (1) This is just semantics, but the compiler is not "smart" and does not "figure out" types. It uses a straightforward type unification algorithm (should feel natural to anyone who's programmed in Prolog) with a monomorphism restriction. (2) The type annotations you add may be different than the types that the compiler would deduce in their absence, and these annotations may in fact be necessary in order for the program to be correct.
Your question about Lisp has already been answered, but I will expand. The type checking can be done at runtime, at compile time, or at some combination of both—it is not always possible to deduce the type of function arguments at compile time in a language like Lisp. Obviously, (+ 1 "ABC") is an error, but not all situations are so obvious. The same is true in Python, Ruby, JavaScript, Objective C, Java, Haskell, and any other language which supports dynamic typing.
Yes, Haskell supports dynamic typing.
Yes, it is. That entire paragraph was... less than useful.
"Yes, Haskell supports dynamic typing."
Yes, it does, but not with any of the features you've discussed. It supports it with Data.Dynamic. Type holes are still as I described; they are not a way to escape the type system or make it compile something that does not have some sort of concrete type, they are a way of asking the compiler what type it thinks goes somewhere. Here, the first hit for "ghc type holes": http://www.haskell.org/haskellwiki/GHC/TypeHoles
"This is the purpose of a hole: it has similar semantics to undefined, in that evaluating it is an error (you can replace all holes with undefined, and vice versa, and nothing has changed: you may even say undefined is just a really crappy, useless hole!) But it's special in that when GHC encounters a hole during compilation it will tell you what type needs to be there in place of the hole, for the type-checker to be OK with the definition."
This is not dynamic typing. It may superficially look like it if you just gloss over the definition, but if you really understand it that's not what it is. There is still some sort of concrete answer (concrete to the type system, for which constraints aren't that big a deal).
I return fire: I suspect you don't understand how Haskell type inference works, since you're making false claims about these features.
It's like the kind of JSDoc annotations you need for the Closure Compiler.
The difference is that it's baked into the language, which enables a very terse syntax and, since it's standardized, it can be used by all of your tools.
You only need those annotations at the API boundaries (arguments and return values) to get most of the tooling benefits like call-tips, auto-complete, direct & inferred static checks, runtime checks, generated documentation, and things like that.
Groovy 2.x, with compile-time typing, only came out a year ago.
So even if you type-annotate everything, you will never get compile-type type errors? That makes the whole thing seem completely pointless.
Seems pretty odd to me.
Assembly language is untyped. Dynamic typing is not the same thing.
Unfortunately the term "type" is also used to refer to the tags dynamic languages put on data to prevent illegal operations. Confusion inevitably results.