Sorry if this a bit off subject, but im curious to what you guys think of dynamic types?

Quote:Original post by Falling Sky
Sorry if this a bit off subject, but im curious to what you guys think of dynamic types?

Err. I think they're dynamic? What kind of answer are you looking for? And what do you think "dynamic type" means, since there are several possible definitions?

What do you think of dynamic type such as in Python, Lisp, Perl, Ruby, and ect over a strict type system such as C's? Do you prefer dynamic, do you think the future lies in dynamic or strict or both?

Quote:Original post by Falling Sky
What do you think of dynamic type such as in Python, Lisp, Perl, Ruby, and ect over a strict type system such as C's? Do you prefer dynamic, do you think the future lies in dynamic or strict or both?

They're useful in rapid development, and in idealised languages like Smalltalk. Smalltalk/Self/IO wouldn't fit together as well with static typing. But we're talking about a language for building very large, safe software components with. We want to go the other way in this case, having very strong static typing (stronger than C's), introducing dependent types, contracts, etc.

Scripting languages should probably stick with dynamic typing as their default, they get a lot of their power from it.

There was some talk that using a combination is the best approach, but I haven't looked into it. To me it seems strong static typing is the best solution here.

Quote:Original post by Rebooted
But we're talking about a language for building very large, safe software components with.

Such things have been built with dynamically typed languages as well. Automated (unit) tests do the trick of enabling greater safety than plain static typing is able to.

Quote:There was some talk that using a combination is the best approach, but I haven't looked into it. To me it seems strong static typing is the best solution here.

Specify "here".

Quote:Original post by Falling Sky
What do you think of dynamic type such as in Python, Lisp, Perl, Ruby, and ect over a strict type system such as C's? Do you prefer dynamic, do you think the future lies in dynamic or strict or both?

Users of those languages like to distinguish type systems by two criteria:

strong vs. weak: This relates to the types of objects. The system is strong if you cannot change an object of one type into an object of another, otherwise it's weak.

static vs. dynamic: This relates to the types of variables. The system is static if a variable can only name an object of a certain type, otherwise it's dynamic.

Is this the distinction you're making?

I think the future of programming languages is static typing, but possibly purely by inference (See Haskell). This is because "programs" tend to be more "set in stone" (thus more error checking in the compiler is helpful).

I think the future of scripting languages is dynamic typing. This is because scripts are more malleable (allowing errors to be changed more easily, though type errors are somewhat rare in these languages) and because they need to be malleable (that's why we use scripts, and dynamic typing aids malleability).

As far as desktops go, I think more and more tasks will be handled by applications written in scripting languages. Thus, I think the future of desktop programming is dynamic typing. I think the underlying system, microcontrollers, etc. etc. etc. will still all be done with programming languages due to lower overheads, so I think the future of their programming is static typing.

Quote:Specify "here".

The language that is supposed to be the solution to the problems Tim Sweeney brought up.

Do you have an argument for using dynamic typing here? I'd be interested in hearing it. It just seems that static typing, dependent types, contracts, all helping ensure safety is the way to go.

We'd sacrifice the speed of initially writing code in return for less debugging time later.

Quote:Original post by Rebooted
Do you have an argument for using dynamic typing here? I'd be interested in hearing it. It just seems that static typing, dependent types, contracts, all helping ensure safety is the way to go.

We'd sacrifice the speed of initially writing code in return for less debugging time later.

Ahh, but what of initial speed of writing allows us to write more thorough unit tests (similarly faster in writing) in the same amount of time? Would the benifits of static checks offset the cost of fewer unit tests?

I'm unsure myself, I'm relatively inexperienced with dynamically typed languages - if I had to hazard a mostly uneducated guess, I would suggest that it would depend on the programmer. The better they (or their project lead) can plan an application, the less structural changes they'll need to make, and by extension, the less benifit a more maleable system has over something more static.

The worse they can, or if they are dealing with changes beyond their own control, the more benifits the more dynamic system brings to the table, to the point where it might offset the fewer static checks.



And since I really suck at planning, this would explain my draw to more dynamic languages!

Quote:Original post by Rebooted
The language that is supposed to be the solution to the problems Tim Sweeney brought up.

Do you have an argument for using dynamic typing here? I'd be interested in hearing it.

As I said, automated tests. Sweeney even himself proposes that functional programming style is the correct default in a concurrent world, and such code is usually easy to test. His proposed additional statical tests don't come for free. Why not use the time wasted in extra annotation on writing tests instead? In my experience, even very simple tests catch the bugs that statically typed languages would normally complain about in the compile phase, and almost certainly those tests will also catch other bugs.