Fed-up with strongly typing
-
Strongly typing has one big advantage: it will force you to grow from a jerk to a proficient programmer. Yes, many programmers never get proficient but then strongly typing is not the cause :-) But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... It only multiplies by X (I am curious here... anyone? ) the number of reserved keywords you have to type to get to an equivalent result that you would get with a dynamic language. What do you guys think?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Strong typing allows the compiler to catch errors, which is the cheapest way. If you ride without training wheels, you should know how to ride or expect to fall. Preferably both. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
sorry, if that's a joke I did not get it... C# is the name for a language and your compiler is most probably csc.exe then. this compiler is far (far = 'years away' but that is not further than any other compiler I am aware of) from being able to analyse all possible code paths....
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
The C# compiler, and any other compiler for a strongly- and statically-typed language, certainly will check the data type of variables through every possible code path. It may not know the value of a variable at a particular point or evaluate all possible paths through the code (that is impossible for anything which takes external input, after all), but it can check the type, and if you make a type related mistake anywhere in your code, it will be caught.
-
Marc Clifton wrote:
If you don't like typing, you shouldn't be a programmer.
I am a programmer cause I never liked repetitive tasks, I believe that typing .net/java code is highly repetitive... You might think differently: fair enough. But with all respect I am not judging what you should or should not be or do.
Marc Clifton wrote:
Not to mention that I wouldn't write anything that requires performance in a dynamic language
Many dynamic languages outperform statically typed languages... just have a go with LUA you should not be disappointed. And code is not all... the environment has a lot to do: run some compiled C# in IIS and compare performance with interpreted JS in node or run PHP within ligthy and you might end-up handling more than 3000 requests/sec http://redmine.lighttpd.net/projects/lighttpd/wiki/PoweredByLighttpd[^]... Drop me a note when you achieve the same with csharp :-D
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Guirec Le Bars wrote:
Drop me a note when you achieve the same with csharp
Easy. Asp.net has had asyncronous handlers for years, plus the http caching layer runs partialy at the driver level. You are writing async code and aren't using any drag and drop junk at that point, but the asp.net platform has way more performance than the web forms libraries.
Curvature of the Mind now with 3D
-
The C# compiler, and any other compiler for a strongly- and statically-typed language, certainly will check the data type of variables through every possible code path. It may not know the value of a variable at a particular point or evaluate all possible paths through the code (that is impossible for anything which takes external input, after all), but it can check the type, and if you make a type related mistake anywhere in your code, it will be caught.
Great. The compiler help me in making sure I don't mix-up class Person with class Country or int with Toto. Awesome... Do you really need a compiler for this? I mean, can't you just concentrate when writing code? Or adopt Hungarian Apps style which is definitely every programmer's friend? Anyway you are not answering the vey valid point of Freak30
Freak30 wrote:
And what if the proficient programmer misses one of the code paths during his tests
Answer: I don't know! But I am sure that csc does not help in any way for that! The .net platform gives too many facilities which make the posiible code paths just too numerous (infinite? at least overflowing...)
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
-
Guirec Le Bars wrote:
Drop me a note when you achieve the same with csharp
Easy. Asp.net has had asyncronous handlers for years, plus the http caching layer runs partialy at the driver level. You are writing async code and aren't using any drag and drop junk at that point, but the asp.net platform has way more performance than the web forms libraries.
Curvature of the Mind now with 3D
Easy? if you say so... IMHO, asp.net can't handle 3000 requests per second. Even if you remove every single HttpModule and just stick to a very basic HttpHandler....
Andy Brummer wrote:
Asp.net has had asyncronous handlers for years
hopefully... at OS level everything is asynchronous by nature. Synchronicity has been brought to developpers to facilitate their lives but that is not the norm for any Win or posix computer.
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
-
that is definitely not the case. but a proficient programmer is anyway testing is code and just don't rely on compilation, right?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
always testing your code is a good thing. it doesn't remove the benefit of compile time checking provided by strongly typed languages though. i.e. regardless of how much runtime testing you do, and/or how proficient you are, there's still a benefit to be had from also having compile time checking.
-
Strongly typing has one big advantage: it will force you to grow from a jerk to a proficient programmer. Yes, many programmers never get proficient but then strongly typing is not the cause :-) But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... It only multiplies by X (I am curious here... anyone? ) the number of reserved keywords you have to type to get to an equivalent result that you would get with a dynamic language. What do you guys think?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Strongly typing is the rubber treading that stops you sliding down that slippery slope of laziness. A more accurate comment is actually: Typing is a tool and needs to be used appropriately. It can save man-hours in finding bugs, and can cost man-hours in hacky work-arounds. We're moving more and more to web services for communication between our systems and to allow loose coupling we're relying extensively on JSON and C# dynamics. Untyped development makes the code simple, elegant and fast to write as well as robust to changes (as long as we catch exceptions), but it means an awful lot of referring to external documentation or external code to check properties and data types, so we lose the instant feedback that is intellisense.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Strongly typing has one big advantage: it will force you to grow from a jerk to a proficient programmer. Yes, many programmers never get proficient but then strongly typing is not the cause :-) But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... It only multiplies by X (I am curious here... anyone? ) the number of reserved keywords you have to type to get to an equivalent result that you would get with a dynamic language. What do you guys think?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
I like my typing like I like my drinks: strong. :cool: But seriously, I think the only insufficiently-typed languages I've used I'd classify as "scripting languages" -- Perl and DCL come to mind. Such languages have their domain, but I would hesitate to write an actual system in one.
-
Strongly typing is the rubber treading that stops you sliding down that slippery slope of laziness. A more accurate comment is actually: Typing is a tool and needs to be used appropriately. It can save man-hours in finding bugs, and can cost man-hours in hacky work-arounds. We're moving more and more to web services for communication between our systems and to allow loose coupling we're relying extensively on JSON and C# dynamics. Untyped development makes the code simple, elegant and fast to write as well as robust to changes (as long as we catch exceptions), but it means an awful lot of referring to external documentation or external code to check properties and data types, so we lose the instant feedback that is intellisense.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Chris Maunder wrote:
it means an awful lot of referring to external documentation or external code
1. it looks like an interesting feature to have devs reading some documentation 2. they will read it once or twice and then they will remember. At that point in time you will end-up with "the code simple, elegant and fast to write as well as robust to changes". Isn't it the point?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
-
always testing your code is a good thing. it doesn't remove the benefit of compile time checking provided by strongly typed languages though. i.e. regardless of how much runtime testing you do, and/or how proficient you are, there's still a benefit to be had from also having compile time checking.
I do agree with you but I am at a point where I don't think the benefit outweight the cost....
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
-
Marc Clifton wrote:
If you don't like typing, you shouldn't be a programmer.
I am a programmer cause I never liked repetitive tasks, I believe that typing .net/java code is highly repetitive... You might think differently: fair enough. But with all respect I am not judging what you should or should not be or do.
Marc Clifton wrote:
Not to mention that I wouldn't write anything that requires performance in a dynamic language
Many dynamic languages outperform statically typed languages... just have a go with LUA you should not be disappointed. And code is not all... the environment has a lot to do: run some compiled C# in IIS and compare performance with interpreted JS in node or run PHP within ligthy and you might end-up handling more than 3000 requests/sec http://redmine.lighttpd.net/projects/lighttpd/wiki/PoweredByLighttpd[^]... Drop me a note when you achieve the same with csharp :-D
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Guirec Le Bars wrote:
Drop me a note when you achieve the same with csharp :-D
Here I am, dropping you a note. C# typically has about 3x the performance of nodejs. But to get >3000 requests/sec you will need to tune both IIS and your ASP.NET settings - or drop to the bare metal like nodejs does anyway. I personally tested this using HttpListener and C#'s async features, but there are libraries out there as well to do this. I got over 10,000 requests per second on a good server machine.
-
Matthew Faithfull wrote:
the stability/lifetime/readability
stability : hhmmmm... what's that? as soon as you change a line of code somewhere some sort of instability appears right? and if you don't change anything then dynamic is as stable as strongly typed... lifetime: with a new version of the .net framework every year which, each time, brings more syntactic sugar (anonymous delegate, initializers, linq, etc...) then the code written today is extremely different from the one wrote a few years ago. It seems to me that there is less of a trend/fashion style for dynamic languages devs. readability: once again this is related to your seniority level I think. It is pretty easy to write unredable code in .Net/Java.
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Guirec Le Bars wrote:
if you don't change anything then dynamic is as stable as strongly typed
No because you don't need to change anything for a new version of Python to break your code because they tidied up vague rules for under the hood type conversion that you can't control through the language itself. As to .Net and Java what you say is true which is why I'll stick with a strong and statically typed language like C++ given the choice.
"The secret of happiness is freedom, and the secret of freedom, courage." Thucydides (B.C. 460-400)
-
-
Guirec Le Bars wrote:
Drop me a note when you achieve the same with csharp :-D
Here I am, dropping you a note. C# typically has about 3x the performance of nodejs. But to get >3000 requests/sec you will need to tune both IIS and your ASP.NET settings - or drop to the bare metal like nodejs does anyway. I personally tested this using HttpListener and C#'s async features, but there are libraries out there as well to do this. I got over 10,000 requests per second on a good server machine.
Was that a test which was 'really' doing something like generate some content and write it to the response stream or was it just returning a ok/200 ? I might actually be interested in your codebase if you want to share. The 3000 req/sec I am talking about are real dynamic websites running on production, so they obviously have content.
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
-
Easy? if you say so... IMHO, asp.net can't handle 3000 requests per second. Even if you remove every single HttpModule and just stick to a very basic HttpHandler....
Andy Brummer wrote:
Asp.net has had asyncronous handlers for years
hopefully... at OS level everything is asynchronous by nature. Synchronicity has been brought to developpers to facilitate their lives but that is not the norm for any Win or posix computer.
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Anyway, it's the architectural change in node and nginx that lets it scale to really high levels. Any of the platforms these days can get that kind of performance if you know what you are doing. It's more about developer experience and knowing how to take advantage of the platform than the platform itself. If you wanted to, you could drop back down to straight C++ and hook into the same low level http apis that IIS uses and crush the performance of just about anything else out there. Or you could do the same in Linux and beat the pants off node. Anyway I've worked on a web service that saturated the network at 6000-7000 req/sec and used 18Gigs of memory to predict fraud in advertising clickstreams. The cut off response time was 200ms, the service averaged under 1ms even when it was getting hammered. That was over 3 years ago on a relatively low end 2 proc VM. I never really got to the point of really tuning it, but I'm sure there was a lot more it could have done.
Curvature of the Mind now with 3D
-
Strongly typing has one big advantage: it will force you to grow from a jerk to a proficient programmer. Yes, many programmers never get proficient but then strongly typing is not the cause :-) But here we are: when you are proficient in your domain of expertise (eg: embedded, gaming, LOB apps, multi-million users websites or whatever is your mod) then strongly typing is just a pain... It only multiplies by X (I am curious here... anyone? ) the number of reserved keywords you have to type to get to an equivalent result that you would get with a dynamic language. What do you guys think?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
-
And what if the proficient programmer misses one of the code paths during his tests? The compiler will surely check them all.
-
The C# compiler, and any other compiler for a strongly- and statically-typed language, certainly will check the data type of variables through every possible code path. It may not know the value of a variable at a particular point or evaluate all possible paths through the code (that is impossible for anything which takes external input, after all), but it can check the type, and if you make a type related mistake anywhere in your code, it will be caught.
BobJanova wrote:
The C# compiler, and any other compiler for a strongly- and statically-typed language, certainly will check the data type of variables through every possible code path
Neither C# or any other compiler in that category will check dynamically loaded code paths. Where as unit testing would check that.
-
Guirec Le Bars wrote:
you have to type
I often hear complaints about how much typing someone has to do. If you don't like typing, you shouldn't be a programmer. As to dynamic typing, while it's cool and fun, in the long run, the number of problems that I've had to fix that simply wouldn't be there in a strongly typed language all but eliminates for me the benefits. Not to mention that I wouldn't write anything that requires performance in a dynamic language, as these usually cannot be compiled into native assembly code but are either interpreted or are run in a VM. So I'll say it again, but this time metaphorically: If you don't like typing, you shouldn't be a programmer. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
Chris Maunder wrote:
it means an awful lot of referring to external documentation or external code
1. it looks like an interesting feature to have devs reading some documentation 2. they will read it once or twice and then they will remember. At that point in time you will end-up with "the code simple, elegant and fast to write as well as robust to changes". Isn't it the point?
Seulement, dans certains cas, n'est-ce pas, on n'entend guère que ce qu'on désire entendre et ce qui vous arrange le mieux... [^] Joe never complained of anything but ever did his duty in his way of life, with a strong hand, a quiet tongue, and a gentle heart [^]
Guirec Le Bars wrote:
At that point in time you will end-up with "the code simple, elegant and fast to write as well as robust to changes".
You must either program by yourself or work with a very extraordinary group of programmers and an extraordinary company. The rest of us must work in the real world where the average programmer, by definition, is average. And some are below average. Thus over time larger systems are neither "robust" nor "elegant". And that even presumes that the business requirements and delivery times allowed for that in the first place.
Guirec Le Bars wrote:
Isn't it the point?
Might be the intent but that isn't what happens. What happens over time is that there is little to no documentation. One must look to the code to find out what is going on and one must often delve through multiple layers to understand it. Which becomes even more true when someone, previously, decided that some generic, meta data, multi-layered solution was appropriate to solve what would have been a trivially simple bit of code.