The Artima Developer Community
Sponsored Link

Weblogs Forum
Static Versus Dynamic Attitude

22 replies on 2 pages. Most recent reply: Feb 21, 2005 9:45 PM by Steven Shaw

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 22 replies on 2 pages [ « | 1 2 ]
Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Static Versus Dynamic Attitude Posted: Feb 9, 2005 9:35 PM
Reply to this message Reply
Advertisement
-snip-
> The cart that follows the philosophy
> horse is the language itself, which is naturally designed
> to make it easy to program in the manner suggested by the
> philosophy.

Sure, folk who think static type safety is a good thing will be inclined to create languages that use static type checking. And they will choose one from many different type systems - we grapple with the specific type system they chose, not some generic notion of static type checking.


-snip-
> The point I attempt to make in the blog post is that it
> was prmarily Java's philosophy that was speaking
> to me ... not the language.

imo I understand your point, I just don't agree with it ;-)


> Certain things are considered good practice, others bad.
> The question is to what extent is the static versus
> dynamic language debate about these competing notions of
> right and wrong that come from the differing philosophies?

If the static versus dynamic language debate is about anything more than how difficult it is to get beyond a narrow expertise, then the debate is not about the desirability of static type safety in principle but about how much we value static type safety over other qualities in a particular language - economics not philosophy ;-)


> > Whenever you start to think of some Java problem as a
> > general problem with static type checking, maybe
> > rewrite it in Nice.
> >
> I haven't tried Nice. I did try Groovy...

Well, Nice tries to do more static checking than Java, and Groovy tries to do less.

So if you start to think of some Java problem as a general problem with static type checking; rewriting it in Nice might suggest that it's really a Java problem.

Curt Sampson

Posts: 21
Nickname: cjs
Registered: Mar, 2004

Static Typing is Not the Problem Here Posted: Feb 9, 2005 9:54 PM
Reply to this message Reply
I've never found a dynamic-typing proponent who thought it was better not to hear about errors at compile time. They just want to avoid the hassle and typing of having to explicitly declare types. I understand that; your poor man's struts is a perfect example of something I've also experienced many times in Java: spending more time typing type declarations than code that does anything. It cost you time instead of saving it.

But it wasn't the static type checking that cost you the time: it was typing all of the declarations. Java's implementation of static typing is back in the stone age with C's memory management: do it all by hand.

Statically typed langages with type inference, such as Haskell, give you better type checking without having to type all of those declarations. (And not having those declarations sure makes refactoring easier!) In fact, you even solved your problem by writing what is effectively a very limited type inference engine.

I'm just hoping that one day decent type inference will become as common--and as demanded--a tools as garbage collection is today.

Robert Konigsberg

Posts: 6
Nickname: konigsberg
Registered: Feb, 2005

Re: Static Versus Dynamic Attitude Posted: Feb 11, 2005 12:37 AM
Reply to this message Reply
You have made some good observations. It explains why I choose Python or Perl for small, easily-contained packages, where the meaning of a tuple, list, hash, dictionary, or whatever, are fundamentally clear. It also explains why I dislike J2EE's use of Maps for storing and retrieving intermediate values.

It is a conscious choice which a language designer makes: if I want a language which one can use to write software quickly, I'll allow for dynamic typing. If I want a language which has reliable typing to begin with, I'll make a language more like C++ or Java.

Kevin Greer

Posts: 2
Nickname: kgr
Registered: Apr, 2003

Re: Static Versus Dynamic Attitude Posted: Feb 11, 2005 10:07 AM
Reply to this message Reply
Static-typing is the best of servants but the worst of masters.

Isaac Gouy

Posts: 527
Nickname: igouy
Registered: Jul, 2003

Re: Static Versus Dynamic Attitude Posted: Feb 11, 2005 10:23 AM
Reply to this message Reply
> Static-typing is the best of servants but the worst of
> masters.

Skilled software developer exhibit mastery of their tools? :-)

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Static Versus Dynamic Attitude Posted: Feb 11, 2005 8:58 PM
Reply to this message Reply
I have to agree with Berco Beute about looking for the path of least resistance. However, I approach this two ways. One is looking at how fast I can get it done. This speaks directly to library support, language features, etc. as Berco points out. The other is who else will be working with this, what will they be expecting and what can they handle? Maintainability is a key thing to look at for long term projects that gets overlooked until you've been burned by it a few times. Sometimes that means creating the more verbose C, C++, Java, etc. version.

On average I've had an easier time reading other people's code when written in a strongly typed static language. Maybe this speaks more to the quality of the people writing the code than to anything inherent in the language, but that is my experience. Given some of the heated viewpoints that have come out of various Static vs. Dynamic threads, I know I am not alone with that experience.

To touch on skilled developers exhibiting mastery of their tools, what does that mean exactly? I know many people who are pretty good developers who put no qualifier on their resumes, etc. about their knowledge of a language or platform. All the job ads ask for experts in this, that or the other thing. Unless you're Linus Torvals, Bjarne Stroustrup, etc., how people can claim 'expert' is beyond me. Heck, where I work I think I'm the only one that does any Python at all, so that makes me the 'expert' there, although I know I pale in comparison to most people that are actual Python developers.

I think in a way that is another manifestation of Static vs. Dynamic attitude. Dynamic implies ever-changing and it is hard to master something that won't stand still. The idea of static, on the other hand, lends itself easier to the idea of mastery, I think. I know once I've learned an efficient idiom or algorithm in C or C++ or C# or even VB, I tend to stick with it most of the time. Some people may call that a rut. I call it proven.

When I am working in Python or PHP I am much more apt to experiment. The feedback in either one of those environments is almost instantaneous, which gets to be addicitive. I find it kind of ironic that one of Python's tenets is that there is usually one best obvious way to do something, yet the language itself makes it so easy to try so many different permutations to solve a given non-trivial problem.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Static Versus Dynamic Attitude Posted: Feb 15, 2005 9:44 AM
Reply to this message Reply
> The way I felt this fit into the static
> versus dynamic debate is that I noticed that Java culture
> leads me in directions that required more time and code,
> whereas Python culture leads me in directions where things
> take less code and time. So I got to wondering how much
> the static versus dynamic debate about languages was
> really a debate about different cultures, and the mindsets
> they engender.

Bill, for anything that you've used python for, are the same APIs available in Java? Is the less typing and less time argument more about the tools expressed in the language, or is it really about the language semantics, syntax and operator expressivity?

Steven Shaw

Posts: 15
Nickname: sshaw
Registered: Apr, 2003

Re: Static Versus Dynamic Attitude Posted: Feb 21, 2005 9:45 PM
Reply to this message Reply
Bill, I think you're dead-on-the-money with the different-language, different-mindset thing. Java can make you feel guilty alright :-). Even when you can get over your own guilt, there's the struggle with the other Java developers who may not have a more dynamic mindset.

I've been programming in JavaScript (actually ActionScript 2.0 , but I prefer the JavaScript/ActionScript-1.0 style). You'd probably return a single object there rather than multiple:

var context = ExamplePage.process();

followed by code using context.formumID, context.reply, context.subject and context.body.

Single objects are constructed easily in JavaScript:

function process() {
// Do some processing...
return {
formumID: ...,
reply: "a reply",
subject: "a subject",
context: "a context"
}
}

This is a very lightweight approach. Another poster had a similar solution in Python. There must be a similar way of doing this in Ruby or Groovy.

It would be great to use JavaScript, Groovy, JRuby, Jython or whatever on the Java platform. What's needed for mass adoption is buy in by vendors like Sun and IBM (so that project managers and other developers don't have a fit if something without the .java or .xml extension is checked into the repository). It would be nice to have support for these languages in Eclipse (say) with all the usual bells-and-whistes Java programmers have come to rely on to get stuff done - code completion, Javadoc lookup, hyperlinking, refactoring etc. Groovy seems to have alot of momentum including a JSR thing - so may something along these lines is not too far away.

I blogged this here:
http://ljjccc.blogspot.com/2005/02/static-versus-dynamic-attitude.html

Flat View: This topic has 22 replies on 2 pages [ « | 1  2 ]
Topic: The Sensible Trend of ScreenCasting Previous Topic   Next Topic Topic: The Diggins Friday Digest

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use