3

Yes I know that it shouldn't be abused and that C# is primariy used as a static language. But seriously folks if you could just dirty up some code, in the python style, or create some dynamic do hicky, would you?

My mind is working overtime on this having spent a while loving the dynamics of python, is c# going over to the dark side through the back door?

Is the argument for static typing a dead one with this obvious addition?

Is the argument for less Unit testing a bit silly when we are all grown ups?

Or has the addition of dynamics ruined a strongly static typed and well designed language?

WeNeedAnswers
  • 4,620
  • 2
  • 32
  • 47
  • Can you give an example of some Python or C# "dynamic do hicky"? I have used Python a long time and only ever needed dynamic addition of properties for meta-programming, which is not the same as "dirtying up the code". – Nathan Shively-Sanders Mar 18 '10 at 13:43
  • yeah "do hicky" I think thats dynamic speak for "let your imagination go wild" :), After doing Meta Programming with c# in the days of net 1.1 and doing it in python, the static typing used to get in the way in c#. Spent most of my days working out Interfaces and abstract types when all I wanted to do was something a bit runtime. I found python to be so much nicer and I could concentrate on the tasks at hand as opposed to working around the type system. Coming from a staticlly typed language it did feel "dirty" :) – WeNeedAnswers Mar 18 '10 at 13:59
  • Sure C# is strongly typed; but I'm not sure I'd call it a "well designed language"... especially in its early days when it took all its leads from C++ and Java. – pblasucci Mar 18 '10 at 14:30
  • 1
    @pblasucci - What language would you consider to be well designed and why? – Andrew Hare Mar 18 '10 at 14:51
  • @Andrew Hare - No language is perfect; they all have idiosyncrasies which vex in one way or another. I was speaking more to the environment in which C# was designed, rather than the design itself. I really like ragging on things which have a tautological existence. – pblasucci Mar 18 '10 at 16:24
  • @pblasucci - Ah I see what you mean. So is it fair to say that you feel that C# was an unnecessary language to create rather than a poorly designed one? – Andrew Hare Mar 18 '10 at 16:38
  • c# was necessary, it has stood on the shoulders of the work done with Java. It was also diff from C++ in that it worked sandboxed from design. Why C++ on the CLR would be a good question. C# coming from a Delphi perpespective, is Delphi done with curely brackets. In fact when I switched from Delphi 5 to C#, it was home from home :), I would say that the heritage of C# is a cousin of C++ and Java, but a child of Delphi. – WeNeedAnswers Mar 18 '10 at 16:59
  • @WeNeedAnswers - That's a fair point about Delphi. – pblasucci Mar 18 '10 at 17:35
  • @Andrew Hare - I would say the desire to emulate so much of Java's syntax was unnecessary. Incidentally, that's also one of ECMAScript's principle short-comings. – pblasucci Mar 18 '10 at 17:36
  • Vote to close--or should be made community wiki. Extremely broad and subjective question. – Onorio Catenacci Mar 19 '10 at 00:34
  • @Onario certainly not subjective. Maybe doesn't comply to your if then else type structured thinking but hey, I like using computers, but wouldn't want to be one. :) – WeNeedAnswers Mar 23 '10 at 15:15
  • @Ontario, from this question I learned all about structural typing. Never even knew it existed before this question. Open question, oh yes. Informative, well I learned something new thanks to @Juliet. Was it relevant to the question, I think so. :) – WeNeedAnswers Mar 23 '10 at 15:27

7 Answers7

7

I lost the desire to use dynamic types when I started using type inference.

gradbot
  • 13,732
  • 5
  • 36
  • 69
  • Type inference is sugar coated goodness all the way, but you still got to fight the type system to get to the thing you would like to achieve, Duck typing is a nice thing, most times, but when it does go wrong, boy it goes wrong in a bad way :) – WeNeedAnswers Mar 18 '10 at 16:07
  • 5
    As far as "fighting the type system" goes, I think a lot of people have that experience when they first start out, but once you get used to it, the type checker becomes your best friend. I kind wish though that F# supported structural typing as easily as OCaml. – Juliet Mar 19 '10 at 01:23
  • 1
    +1, and I only agree that once you learn how to read what the type-checker says, it is fantastically useful. – Tomas Petricek Mar 19 '10 at 01:30
  • Something can have both, and be called hybrid, but structural? I am not buying into the method of structural at all, what is so structural about a philosophy of programming and a mechanism of operation? Inference is just sugar, in C# the type is not inferred at all but really declared once in the constructor. All the var keyword does is say "don't ask me what the type is look at the constructor". The dynamic keyword says, "ask away sunshine, but You will need to ask me at runtime, call me later". – WeNeedAnswers Mar 20 '10 at 01:12
  • @gradbot, @juliet and @Tomas: Just don't mention the dreaded "Value restriction" :) – Benjol Mar 20 '10 at 22:30
  • 1
    Combine type inference with C++ style templates and you have a lot of the advantage of dynamic types. Add in a dynamic dispatch routine (based on parameter type) with access to the compiler (to instantiate the template when it encounters a new type) and you *have* dynamic typing. Psyco (a python implementation) works this way, turning a lot of python's dynamic typing into type inference. – George Steel Jul 28 '10 at 17:55
6

C# has expanded to including some aspects of dynamic typing, yes, but that doesn't mean that static typing is dead. It simply means that C# has added some tools that allow developers of all persuasions to solve all kinds of problems in many different ways.

I have a problem with the concept of one type system being "better" than another. That is like saying a hammer is better than a screwdriver. Without know the context of the task at hand it is impossible to make that determination! Dynamic typing is better than static typing for certain problems and situations and vice-versa. The superiority of the approach is entirely conditional on the problem at hand.

So to stick with my tool analogy, it is best to have a toolbox that contains hammers and screwdrivers and know how to use each efficiently. This will make you a better developer as you will be best equipped to solve any problem you face. C#'s new dynamic typing additions are simply an effort to help you by providing these tools in a single, convenient package.

Andrew Hare
  • 344,730
  • 71
  • 640
  • 635
  • The problem with having a hammer though, it isn't subtle, and you can try and fix most problems with it. Dynamic is a hammer, and then some. I think the analogy I would use, Static is like mechano, whilst dynamic is lego bricks (not techo lego :)) – WeNeedAnswers Mar 18 '10 at 17:02
  • @WeNeedAnswers - I think you may be stretching the analogy a bit further than I intended :) – Andrew Hare Mar 18 '10 at 17:04
2

Is the argument for static typing a dead one with this obvious addition?

Is the argument for less Unit testing a bit silly when we are all grown ups?

Or has the addition of dynamics ruined a strongly static typed and well designed language?

For a while, languages have been moving more and more into the domain of "statically typed when possible, dynamically typed when necessary". And with structural typing (statically checked duck typing) starting to work its way into mainstream languages, we might see languages evolve to the point where they're basically statically checked Python.

For what its worth, dynamically typed code is just as mindful of types as statically typed code. Idiomatic C# is still statically typed, and will remain that way for a long time to come.

Community
  • 1
  • 1
Juliet
  • 80,494
  • 45
  • 196
  • 228
  • I read your piece in the link, and for the most I agree, although the bit about dynamic needing equal code, a bit far. I agree you don't save any time in the development, but the code is terser, requires less scaffolding, and the buildings are self supporting. C# requires an awful lot of this scaffolding to do the simplest of tasks, that is what I refer to when talking of "fighting the type system". Static for the most part of day to day programming works. But I think its had its day. How can duck typing be static, its chosen on runtime? – WeNeedAnswers Mar 20 '10 at 00:41
  • 'In duck typing, one is concerned with just those aspects of an object that are used, rather than with the type of the object itself.' - wikipedia I like duck typing a lot, it frees me from needing to know the taxonomy of objects. I love the idea and the usage pattern that something that is not a Duck may go quack if asked to do it at run time. Makes life interesting and in some instances a lot easier to work with. – WeNeedAnswers Mar 20 '10 at 00:57
  • @WeNeedAnswers: "How can duck typing be static, its chosen on runtime?" Answer: structural typing. See the wikipedia link above. Languages with a good type system, like OCaml, can constrain objects to expose particular methods -- similar to an interface, but defined on the fly. So I can write `let get_A x = x#A()`, where x is a generic type `'a` that exposes a property `val A : unit -> 'b`. Passing an object to the method which has a different method signature results in a compilation error. C# doesn't have structural typing, but F# does (although to a much lesser extent than OCaml). – Juliet Mar 20 '10 at 01:57
  • So the end result is duck typing which is verified by the type checker at compile time. In a statically typed language, this saves the programmer all the hassle of formally defining and implementing interfaces -- however, C# doesn't have the functionality yet. I'm hoping it'll be added in the next version. – Juliet Mar 20 '10 at 02:07
  • hmmm not quite getting you, must be my lack of knowledge of OCaml :) will need to look into it a lot more before comment. – WeNeedAnswers Mar 20 '10 at 12:53
  • Its not duck typing. Its done at compile time. I do like it though, pattern matched typing. I think it is a lot nicer than using Interfaces, the granularity is so fine. Thanks @Juliet would never have looked at OCaml without your input. Will C# get templating though.....I don't think that on the next C# run I will be using it, think I will be moving to the next big thing whatever that might be :) At the moment my two strong candidates for new development are F# or Python. F# would build on the C# stuff, although if they can solve the GIL and performance of Python, thats the language for me. – WeNeedAnswers Mar 20 '10 at 13:09
1

As I understand it, the dynamic keyword was introduced more to facilitate interop and method invocation on unknown types at runtime rather than the kind of dynamic typing you find in languages like python.

Essentially, where you would previously have to call InvokeMember to call a method on an unknown type, you would instead create a dynamic object and just call the method, which would be resolved at runtime. The code becomes a great deal easier to read. Why would you want to call a method (or access a property) on an unknown type? Well, WPF does it all the time when you use databinding.

You also use it when you want to use an interop dll using weak binding, such as for example, if you wanted to write code that used office interop, but you wanted to support more than one version of office. I've had to do this before, and the code for it is horrendous. The dynamic keyword would make such code far easier to read and understand.

See this article for more info:

http://www.hanselman.com/blog/C4AndTheDynamicKeywordWhirlwindTourAroundNET4AndVisualStudio2010Beta1.aspx

Jeremy Bell
  • 5,253
  • 5
  • 41
  • 63
  • Look at the expando Object or Dictionary, you can do some wild things with the dynamic stuff. For example, a Dictionary Object can now be treated as an object with public fields and methods, just add a delegate/lambda to dictionary entry and call it as if it was a public object: dict["callme"]("Ishmael"); – WeNeedAnswers Mar 18 '10 at 14:12
1

As far as i remember, type errors is about 5-10% of all found errors, so we have fewer errors for languages with static typing for free. Unit and regression tests is also a few smaller for static typing.

Dynamic typing is nice for OO languages. In case of FP language (and with HM type system especially) dynamic vs static typing don't impact your decisions of program design at large.

But there is moment where you want nice code performance and that moment will show dark side of dynamic types to you.

ssp
  • 1,702
  • 9
  • 11
  • Have you got any references with regard to your stats, I remember the stats done by some Uni. Bods, but can't remember who they were for the life of me. Since the CLR is strongly typed, I don't think that the stats will hold. In fact the errors would surface at run-time, so thank god for Unit Testing :) – WeNeedAnswers Mar 18 '10 at 16:47
  • @WeNeedAnswers - No, i have not such references. It seems, i found it while studied classifications of software defects. CLR has runtime casts and we should use them as we coding COM interop or got control from panel, ... – ssp Mar 18 '10 at 20:20
  • This certainly depends on the language - 5%-10% sounds reasonable for C#-like language, but I'm pretty sure that in F#, the portion of type errors is a lot larger. It would be very interesting to see some statistics. It is also a question whether it would still be only 5%-10% in C# if you had to write code without IntelliSense that is _made possible_ by the typing information. – Tomas Petricek Mar 19 '10 at 01:33
  • @Tomas - i don't collect statistics for errors by their types, but i have statistics for logical errors for my code base by languages. F#/OCaml -- 1-1.5 errors per 100 LOC; C/C++ -- 2.5-3 errors per 100 LOC; groovy and python -- 2-2.5 errors per 100 LOC; java/perl/LISP -- 4-5 errors per 100 LOC. This metric is very stable and does not changes for years. – ssp Mar 19 '10 at 06:49
  • @Tomas nice one. I hear that the stats on Haskell are even more astounding. – WeNeedAnswers Mar 20 '10 at 00:59
0

Yes.
No.
No.
Yes.
No.

Restore the Data Dumps
  • 38,967
  • 12
  • 96
  • 122
0

Strong typing is still the best way to go for large projects. Not only does it make code completion (IntelliSense) much better, but it can tell you obvious problems at compile time. For example, say socket.Write takes a string. In C# you won't be able to run your program if you try to pass it a number, while in Python you would only find out about your bug when your program crashes.

On the other hand, it's easy to imagine how useful it would be to have a JSON parser that acts like an expando object, automatically growing the properties specified in the JSON.

To elaborate my point a bit, I think C# will mostly stay safe from the evils of dynamic typing, while still reaping its benefits. This is because the system still encourages types on everything, as opposed to other dynamic languages where types are entirely optional (or even just advisory). In C# you will be able to just "git 'er done" with duck typing, expando properties, and other dynamic typing goodness, but it will be well-marked with the dynamic keyword which helps you to keep it self-contained.

Gabe
  • 84,912
  • 12
  • 139
  • 238
  • *Strong* typing and *Dynamic* typing are completely different things. Languages such as javascript and TCL are "weakly typed" - usually meaning all types are interpreted as strings at runtime, and you can do things such as `3.5 + 'hello'` yielding `3.5hello` Python, although dynamic, is strongly typed. You can't use strings in places where ints are required. – Joe Koberg Mar 18 '10 at 16:00
  • yup python rocks, if only they could sort out the GIL and the underlying performance issues. I was a firm beliver in static languages being the best for holding errors at bay until I realised what you mentioned above about Strong typing not being the same as static typing. A couple of projects using python has moved me into the dynamic camp a bit more, esp with Haskell. Although I do see the performance bens. of static over dynamic. I think that the dynamic thing is great in c#, but the point I am trying to get to is that it may be a bad thing if not educated properly. – WeNeedAnswers Mar 18 '10 at 16:42
  • Yeah, expando objects for parsing JSON and XML but also for interacting with schemaless db's like MongoDB and CouchDB. Or db's that have a schema but you don't know this schema at runtime. – TTT Apr 23 '10 at 16:44