5 ms·

Untyped languages are okay. Typed languages are also okay. Typed languages with inference are okay. Optionally typed is extremely strange.

by willlll 13y ago

dietrichepp 13y ago
I think it's rather natural. Look at Haskell. Static typing with type inference was recently extended to allow "holes" in the type system. It lets you run broken programs, and let's be honest, my programs are broken (in some sense) most of the time. C++ lets you use the "auto" keyword in many places. Maybe the only thing strange here is that Dart has more of the "dynamic by default" mentality, but that's not strange either if you look at languages like Common Lisp, which have optional type annotations. 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 Here it is in Lisp, which uses dynamic typing by default but lets you specify types with annotations. ; Dynamic +3 function (defun add3 (x) (+ x 3)) ; Static +3 function for integers (defun add3 (x) (declare (type integer x)) (+ x 3))
- jerf 13y ago
  Optionally specifying types which are otherwise inferred is not the same as optional typing. Haskell expressions always have a type. Often the compiler is smart enough to figure out what it is without you explicitly telling it, but it still has a type. Haskell typed holes still doesn't allow you to escape from the type system, it's more a way of saying "Here I am in the middle of an expression and I'm lost, could you tell me what fits here in your opinion Mr. Compiler?" It still has a type, it is not a way that you can just feed the compiler type-gibberish and move on. 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.)
  - ced 13y ago
    Common Lisp implementations have some latitude in what they do here, but the most popular one, SBCL, will fail at compile-time if sb-ext:derive-function-types is true (an SBCL-specific extension). Otherwise it will trigger a runtime error if compiled under high SAFETY, and a memory fault under low SAFETY.
  - dietrichepp 13y ago
    > Often the compiler is smart enough to figure out what it is without you explicitly telling it, but it still has a type. 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.
    - jerf 13y ago
      "This is just semantics," 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 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.
deleted 13y ago
[deleted]
ericssmith 13y ago
This video (at 26:13) gives a pretty good example of why these might be useful: "Dart: Google's evil plan to make it easier for you to build web apps" http://www.youtube.com/watch?v=9RCuW6K1afs http://www.youtube.com/watch?v=9RCuW6K1afs
dougk16 13y ago
I can definitely understand the sentiment if you haven't tried it. I knew optional typing existed in AS3 (which I use for prototyping certain ideas) for a long time before finally taking the plunge and using it here and there. It lets you blast through experimental code and remain nimble until such time as you want/need to add typing. Also a nice way to avoid long chains of method overloads, including overloading methods that only differ by return type, which is impossible to do in some (many?) languages.
- roryokane 13y ago
  Sorry, accidentally downvoted when I meant to upvote.
- tikhonj 13y ago
  See, this is where the philosophy of languages like Dart and Java differs significantly from Haskell and friends. In the former, it makes sense to write code first and then try to get it to typecheck afterwards. In Haskell, this does not really happen: the types are at the very core of your code. 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.
  - dougk16 13y ago
    Yea, as always, depends on what you're doing. I agree 100% with your points for when I'm writing mission-critical code from the start. But when I'm busting out UI at 2:00AM, it's all fast and loose. A lot of code I write is somewhere in the middle.
mythz 13y ago
Dart's optional typing is effectively a dynamic language that allows you to decorate your source with optional Type info that effectively just acts like documentation for other developers and automated tooling. 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.
- kvb 13y ago
  As long as you're adding a type system (optional or not) it does seem a bit odd to opt for an unsound one...
  - mythz 13y ago
    makes sense if you prefer dynamic languages since it adds least friction.
    - lucian1900 13y ago
      You can always have the Any type + a runtime tag on the box if you really need it.
      - mythz 13y ago
        That's just var (i.e. un-typed) in Dart.
- mark_l_watson 13y ago
  Do you just use Dart on the client side, or also do server side using Dart? I have been using Clojurescript and Clojure for client and server coding, but I might be interested in trying another "one language" stack.
derleth 13y ago
> Untyped Assembly language is untyped. Dynamic typing is not the same thing.
- gsg 13y ago
  If you accept the modern notion of types as proofs, dynamic languages are correctly described as untyped since they prove nothing about the code they run. Unfortunately the term "type" is also used to refer to the tags dynamic languages put on data to prevent illegal operations. Confusion inevitably results.
ahoge 13y ago
> Optionally typed is extremely strange. 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.
rayiner 13y ago
It's really not. It's the equivalent of adding "asserts" to your code.
- kvb 13y ago
  No, in Dart it's not like that at all - almost the opposite. Type annotations have absolutely no effect at runtime. As the Dart documentation[1] says, "Adding types will not prevent your program from compiling and running—even if your annotations are incomplete or plain wrong. Your program will have exactly the same semantics no matter what type annotations you add." [1] http://www.dartlang.org/articles/optional-types/ http://www.dartlang.org/articles/optional-types/
  - xxgreg 13y ago
    Dart can run in production mode where type annotations have no effect, or in checked checked mode where they will trigger a runtime error (i.e. behave like an assert). So you're both right ;)
  - rayiner 13y ago
    Types do cause runtime errors in checked mode (which is basically the default mode for other systems with optional types, like Common Lisp and Dylan).
  - shangaslammi 13y ago
    Wait what? "Adding types will not prevent your program from compiling" So even if you type-annotate everything, you will never get compile-type type errors? That makes the whole thing seem completely pointless.
    - gsg 13y ago
      You get warnings. I guess the aim is to allow people to run their code no matter how broken it is, while still giving a way to detect some errors. Seems pretty odd to me.
    - spankalee 13y ago
ternaryoperator 13y ago
Groovy has been using optional typing for years. Of course, to some folks, that might be proving your point ;-)
- vorg 13y ago
  The optional typing in Groovy 1.x was really an instruction to the runtime, not compile-time type checking or compilation. Groovy 2.x, with compile-time typing, only came out a year ago.

Untyped languages are okay. Typed languages are also okay. Typed languages with inference are okay. Optionally typed is extremely strange.

by willlll 13y ago

Untyped languages are okay. Typed languages are also okay. Typed languages with inference are okay. Optionally typed is extremely strange.

dietrichepp 13y ago

I think it's rather natural. Look at Haskell. Static typing with type inference was recently extended to allow "holes" in the type system. It lets you run broken programs, and let's be honest, my programs are broken (in some sense) most of the time. C++ lets you use the "auto" keyword in many places. Maybe the only thing strange here is that Dart has more of the "dynamic by default" mentality, but that's not strange either if you look at languages like Common Lisp, which have optional type annotations. 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 Here it is in Lisp, which uses dynamic typing by default but lets you specify types with annotations. ; Dynamic +3 function (defun add3 (x) (+ x 3)) ; Static +3 function for integers (defun add3 (x) (declare (type integer x)) (+ x 3))

jerf 13y ago
Optionally specifying types which are otherwise inferred is not the same as optional typing. Haskell expressions always have a type. Often the compiler is smart enough to figure out what it is without you explicitly telling it, but it still has a type. Haskell typed holes still doesn't allow you to escape from the type system, it's more a way of saying "Here I am in the middle of an expression and I'm lost, could you tell me what fits here in your opinion Mr. Compiler?" It still has a type, it is not a way that you can just feed the compiler type-gibberish and move on. 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.)
- ced 13y ago
  Common Lisp implementations have some latitude in what they do here, but the most popular one, SBCL, will fail at compile-time if sb-ext:derive-function-types is true (an SBCL-specific extension). Otherwise it will trigger a runtime error if compiled under high SAFETY, and a memory fault under low SAFETY.
- dietrichepp 13y ago
  > Often the compiler is smart enough to figure out what it is without you explicitly telling it, but it still has a type. 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.
  - jerf 13y ago
    "This is just semantics," 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 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.

deleted 13y ago

[deleted]

ericssmith 13y ago

This video (at 26:13) gives a pretty good example of why these might be useful: "Dart: Google's evil plan to make it easier for you to build web apps" http://www.youtube.com/watch?v=9RCuW6K1afs http://www.youtube.com/watch?v=9RCuW6K1afs

dougk16 13y ago

I can definitely understand the sentiment if you haven't tried it. I knew optional typing existed in AS3 (which I use for prototyping certain ideas) for a long time before finally taking the plunge and using it here and there. It lets you blast through experimental code and remain nimble until such time as you want/need to add typing. Also a nice way to avoid long chains of method overloads, including overloading methods that only differ by return type, which is impossible to do in some (many?) languages.

roryokane 13y ago
Sorry, accidentally downvoted when I meant to upvote.
tikhonj 13y ago
See, this is where the philosophy of languages like Dart and Java differs significantly from Haskell and friends. In the former, it makes sense to write code first and then try to get it to typecheck afterwards. In Haskell, this does not really happen: the types are at the very core of your code. 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.
- dougk16 13y ago
  Yea, as always, depends on what you're doing. I agree 100% with your points for when I'm writing mission-critical code from the start. But when I'm busting out UI at 2:00AM, it's all fast and loose. A lot of code I write is somewhere in the middle.

mythz 13y ago

Dart's optional typing is effectively a dynamic language that allows you to decorate your source with optional Type info that effectively just acts like documentation for other developers and automated tooling. 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.

kvb 13y ago
As long as you're adding a type system (optional or not) it does seem a bit odd to opt for an unsound one...
- mythz 13y ago
  makes sense if you prefer dynamic languages since it adds least friction.
  - lucian1900 13y ago
    You can always have the Any type + a runtime tag on the box if you really need it.
    - mythz 13y ago
      That's just var (i.e. un-typed) in Dart.
mark_l_watson 13y ago
Do you just use Dart on the client side, or also do server side using Dart? I have been using Clojurescript and Clojure for client and server coding, but I might be interested in trying another "one language" stack.

derleth 13y ago

> Untyped Assembly language is untyped. Dynamic typing is not the same thing.

gsg 13y ago
If you accept the modern notion of types as proofs, dynamic languages are correctly described as untyped since they prove nothing about the code they run. Unfortunately the term "type" is also used to refer to the tags dynamic languages put on data to prevent illegal operations. Confusion inevitably results.

ahoge 13y ago

> Optionally typed is extremely strange. 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.

rayiner 13y ago

It's really not. It's the equivalent of adding "asserts" to your code.

kvb 13y ago
No, in Dart it's not like that at all - almost the opposite. Type annotations have absolutely no effect at runtime. As the Dart documentation[1] says, "Adding types will not prevent your program from compiling and running—even if your annotations are incomplete or plain wrong. Your program will have exactly the same semantics no matter what type annotations you add." [1] http://www.dartlang.org/articles/optional-types/ http://www.dartlang.org/articles/optional-types/
- xxgreg 13y ago
  Dart can run in production mode where type annotations have no effect, or in checked checked mode where they will trigger a runtime error (i.e. behave like an assert). So you're both right ;)
- rayiner 13y ago
  Types do cause runtime errors in checked mode (which is basically the default mode for other systems with optional types, like Common Lisp and Dylan).
- shangaslammi 13y ago
  Wait what? "Adding types will not prevent your program from compiling" So even if you type-annotate everything, you will never get compile-type type errors? That makes the whole thing seem completely pointless.
  - gsg 13y ago
    You get warnings. I guess the aim is to allow people to run their code no matter how broken it is, while still giving a way to detect some errors. Seems pretty odd to me.
  - spankalee 13y ago

ternaryoperator 13y ago

Groovy has been using optional typing for years. Of course, to some folks, that might be proving your point ;-)

vorg 13y ago
The optional typing in Groovy 1.x was really an instruction to the runtime, not compile-time type checking or compilation. Groovy 2.x, with compile-time typing, only came out a year ago.