tag:blogger.com,1999:blog-9944221.post4632744733908528231..comments2023-11-03T06:15:55.087-05:00Comments on Meme Agora: Static Typing & Bureaucracy ReduxNeal Fordhttp://www.blogger.com/profile/12839796402858974817noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-9944221.post-41571129305669810032007-09-12T09:55:00.000-05:002007-09-12T09:55:00.000-05:00Trying to compare static vs. dynamic using Java or...Trying to compare static vs. dynamic using Java or C# as the pinnacle of static typing should using Basic as the pinnacle of dynamic. A better comparison should match Ruby against Scala, Python against Haskell, etc., so we at least have decent languages on both sides. Also your third point analogy is wrong, with static types you can't do incorrect operations (e.g. use a string where an integer is expected), traffic signs provide no guarantee, they're just conventions that people may follow. More like urging the caller to take certain locks before calling a function, calling some methods in a particular order, etc., things that (usually) can't be verified by the compiler. If we go through this particular analogy, tests also just show that particular drivers in a lab environment watched for the crossroads and never crashed, but don't say a thing about drivers in the real world.Daniel Yokomizohttps://www.blogger.com/profile/12528969103424062002noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-69962888223215693882007-05-14T09:20:00.000-05:002007-05-14T09:20:00.000-05:00Also, static analysis just means analysis done by ...Also, static analysis just means analysis done by looking at the source when it isn't running. Smalltalk has tools (sLint) for static analysis. As you point out, it is a system of trade offs. Static typing makes static analysis and refactoring easier, but it hurts readability and other things.Davidhttps://www.blogger.com/profile/14110604812109593844noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-74517280260206007992007-05-14T04:48:00.000-05:002007-05-14T04:48:00.000-05:00I'm not sure how .each is related to dynamic langu...I'm not sure how .each is related to dynamic languages. I believe, it is just a matter of syntax and we can have an argument about the syntax of Java, C# or Ruby but it has nothing to do with dynamic or static typing.<BR/><BR/><B>But, are you willing to give up the flexibility of a dynamically typed language just to get better tool support?</B><BR/>Will a blacksmith stop doing his job if he were not allowed to use a hammer? Would he stop hammering without a hammer?<BR/>I hope that most of people today understand how tools are important in a daily life. Obviously, we can make products just with our hands but how mature the products will be? Yes - tools determine our jobs in these days.<BR/><BR/>The analogy with the Dutch town - Drachten and the traffic experiment in its city centre reminds me the analogy of small (perhaps prototypes) projects and big, seriously taken projects. Yes, I agree, for protyping is not the static typing neccessary. For larger projects I doubt about it.Petr Panuškahttps://www.blogger.com/profile/17425204554328139974noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-13451527844408392872007-05-12T14:19:00.000-05:002007-05-12T14:19:00.000-05:00Tools make static languages palatable. I can buy ...Tools make static languages palatable. I can buy that. I'd also have to say that convention, language design, and library design in Ruby make dynamic typing palatable. .each is a good example. There is no reason such a thing could not be possible in a statically-typed language. C# is working in that direction with type inference, etc. The JCP is definitely holding Java back in this regard.<BR/><BR/>I agree with you that Java and C# are far too verbose at this time (and because of that evil backwards compatibility thing may never be able to fix this), but you phrase it as static vs. dynamic.<BR/><BR/>Obviously static typing requires the verbosity of declaring your types when creating classes, methods, etc. I'm not sure that the verbosity needs to extend beyond that, however. Since tools clearly benefit from having that type information, and programmers clearly benefit from having powerful tools, I'd settle for that small amount of extra declaration. <BR/><BR/>I think Ruby supports Graeme's statement beautifully as people are quite productive in Ruby without good tool support. However, 'need' is an extreme word. To say they wouldn't greatly benefit from good tool support is clearly ludicrous. You claim that the problem will be solved. I can't say that I've made the jump to sharing your confidence. On the one hand, Smalltalk solved it because it had a lot of smart people working on it. It also had everything stored in an image and thus much easier to manipulate without side effects. On the other, Smalltalk had the benefit of several well-funded corporations competing for mind share and a load of cash. The JetBrains tools (and even irb, I suppose) take some steps to realize the advantages of the Smalltalk image in other ways, so there is probably hope.<BR/><BR/>Static typing does not preclude tests, humane interfaces, or appropriate naming (this is even a problem in the verbosely_named_method_ruby_world!) It is a problem that can be addressed by training (talk to Fred George about that one).<BR/><BR/>I think removing props is a great experiment and may work well on a small scale in a tight community. Imagine removing all of the street signs and traffic lights in NYC (where people already take everything they can get), though. In Drachten, I may be able to count on others to do the right thing on the road more often than not. In NYC, that trust would soon lead to death.<BR/><BR/>The work going on the Ruby space is great, don't get me wrong. It is bringing back some of the ideals that were largely left behind with Smalltalk. Smalltalk shows a lot of what is possible in a dynamic language (probably even better than Ruby does in many ways), but where is our great static example? I don't think we've gotten there yet, though IntelliJ and other Java tools do provide a glimpse of what is possible. As a first exercise, now that the core Java libraries are mostly GPLd, a community of like-minded people could use those as a base to providing Java WITH humane interfaces. Later, a compatibility layer could be mapped by wrapping the humane interfaces with the current inhumane ones. This could only go so far without language enhancements, but if the JCP doesn't do what is necessary, the tools necessary to fix this are also largely available.Nate Austinhttps://www.blogger.com/profile/02707868714110998666noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-56344919690390186812007-05-12T13:50:00.000-05:002007-05-12T13:50:00.000-05:00Maybe you'd like to give a languagelike Haskell a ...Maybe you'd like to give a language<BR/>like <A HREF="http://haskell.org" REL="nofollow">Haskell</A> a try.Greg Buchholzhttps://www.blogger.com/profile/17033866007804954410noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-14578581362099936032007-05-11T15:04:00.000-05:002007-05-11T15:04:00.000-05:00Counter-argument 1 wasn't about static vs. dynamic...Counter-argument 1 wasn't about static vs. dynamic, but about humane vs. minimal. Static typing precludes humane interfaces as much as dynamic typing precludes tool support, maybe less. Closures, type inference, humane interfaces... all this are perfectly possible in static languages. Just because Java/C# weren't designed with them doesn't mean that another language (and another API) couldn't be.<BR/><BR/>Counter-argument 2 was pure opinion. You <I>prefer</I> dynamic typing's flexibility. Well, I don't usually use static analysis tools, so I can't say much on this...<BR/><BR/>Counter-argument 3 was limited in its view. It assumes that all developers are ThoughWorkers. It's a fact that any language, when in the mainstream, gets 'degenerated'. See VB. See PHP. See Java. Good developers will write good code in any language they are proficient at. Maybe Ruby code's average quality is better than Java's, but that is just because it has not hit the mainstream yet. The ones that use it are the ones who tend to be pioneers, who like learning by nature. Any language whose developers are like this in their majority, tend to produce better code. But, after some time, hypes produce much more lazy-noobs than specialists.<BR/><BR/>I'm not against testing in any way but, most code out there isn't tested. Much of it is tested only in production. Right or wrong is not the question, it's just reality. Most code isn't written by experienced developers, but by code-monkeys. Static typing at least forces a minimum 'implicit' testing (and doesn't preclude 'explicit' testing).Tetsuohttps://www.blogger.com/profile/10534840637169734177noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-26940393547469189022007-05-10T19:45:00.000-05:002007-05-10T19:45:00.000-05:00But I think you've helped my argument! Tools make ...But I think you've helped my argument! Tools make language palatable. But you still have to read all that stuff. 9 keystrokes? .each{ |e|} is 10. But to read the code, you still have to slog through multiple lines of code, vs. the simpler, more elegant .each on all types of collections (the semantics of which are all different in Java and C#). This is similar to the argument that you can fake closures in Java with anonymous inner classes. And many of the people who came from languages with closures tried, but the hideous syntax drove them away. Syntax is important not just to write, but to read as well.<BR/><BR/>Tools make all the difference in static languages. That's why I can't even use Visual Studio without ReSharper. But I don't find that I miss that class of tools as much as I thought I would in Ruby and Groovy.Neal Fordhttps://www.blogger.com/profile/12839796402858974817noreply@blogger.comtag:blogger.com,1999:blog-9944221.post-36218726208288209542007-05-10T16:13:00.000-05:002007-05-10T16:13:00.000-05:00I know I'm out-of-touch when it comes to modern dy...I know I'm out-of-touch when it comes to modern dynamically typed languages (although I used to use and love Perl back when it was a modern language). You're clearly out of touch when it comes to modern refactoring tools.<BR/><BR/><I>"Iterating over collections in Java or C# is ridiculously painful."</I><BR/><BR/>That's just wrong. With ReSharper, I can type "foreach", and hit the tab key it will automatically pick up all variables in the context that implement IEnumerable, selecting the most recently defined one first (which is usually the one I want). Hit enter to have it take care of the rest of the foreach statement, automatically generating a meaningful name for the variable to use in the loop.<BR/><BR/>Now I've got readable code for type-safe iteration over the collection which isn't coupled to the kind implementation of the collection. It took what, nine keystrokes? I don't think it's fair to call that "ridiculously painful".<BR/><BR/>But, I'll admit that the rest of the argument is compelling, and it renews my desire to try coding in Ruby to see why so many smart people like it so much.Martin Cronhttps://www.blogger.com/profile/17397277207087549738noreply@blogger.com