SitePoint Sponsor

User Tag List

Page 3 of 3 FirstFirst 123
Results 51 to 59 of 59
  1. #51
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    I've been with you all along until that last statement, which I feel is more general than it should be. ...I do not agree that in general type safety results in less agility.
    Maybe. I feel that it does, and there are some big names in OOP that agree with me.

    EDIT:

    Upon further thought and research, I realise my use of the term "type safety" is improper, as I really just meant static typing; dynamically typed languages can have as much type safety as statically typed ones.

  2. #52
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    Maybe. I feel that it does, and there are some big names in OOP that agree with me.
    Yeah, I've read those before. And I'm certainly not going to claim that I'm as qualified as those people to make a value judgement. And the thing is, I read what they write, and it makes perfect sense to me. I feel like I should find dynamically typed languages more agile, but my (admittedly limited) experience leads me towards the opposite opinion.

    First of all, I think it's interesting to note that all of the above people were strong static-typing advocates initially. Only after they "discovered" dynamic typing did they change their minds. As for me, I came at it in the exact opposite direction. I've been programming Perl and PHP for about 6 years now, and in Java for the past 9 months or so. So, you'd expect that when moving to Java I'd find the static typing requirement to be constricting. However, the exact opposite has happened for me. I've found it to be a breath of fresh air for two main reasons. The first is the point that I've already made about tool support. The second is the value that static typing declaration adds for documentation purposes, and unlike comments, the type information is something that cannot be wrong or misleading. If static typing as documentation gets out of date, the program will not compile. Yes, unit tests (especially those done in BDD style) are wonderful for that too, but not everyone writes them. In Java, the static typing information isn't optional, which means it's something that I can rely on.

    Notice that in Martin's article he mentions these two points as well...

    Quote Originally Posted by Martin Fowler
    One day I found myself trying to follow some well-written Ruby code. I found the lack of type information on parameters made life difficult - I kept saying to myself 'what exactly do I have here?'
    I also find it interesting that the benefits of static typing that he lists are pretty concrete, while the benefits to dynamic typing he mentions are more nebulous. He metions tool support and documentation in favor of static typing. For dynamic typing his terms are more emotional: "satisfying", "things just seem to flow better", etc. He says it's "more fun programming - even with an inferior environment". I'm not claiming that these more abstract advantages are any less real than the concrete ones. However, I wonder if these people had the experience I'm having in reverse... perhaps with all of us converts (no matter which direction) it's not that we've found something that is "better"... maybe we've found something that is just different, and that difference is enough to make the new thing seem more compelling.

    One last point I'd like to make. Regardless of what Bruce Eckel and Martin Fowler have written, neither of them have abandoned strongly typed languages. Bruce just recently finished the 4th edition of Thinking in Java, and Martin Fowler recently announced ThoughtWorks's release of Buildix, which is the continuous integration setup that they use internally. Arguably the most important piece of that package is Cruise Control, which is geared pretty heavily if not exclusively towards Java, so I think it's a pretty safe bet to say that neither Bruce nor Martin have given Java up in favor of the increased agility of dynamic typing. It seems to me that these guys may have flings with their dynamically-typed mistresses, but they haven't divorced their statically-typed wives yet.

  3. #53
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    Really, unless you've got experience with a modern refactoring IDE, you should consider whether there is something you're missing. I know, at least for me, that I'm far more merciless with my refactoring when there are tools to automate some of it for me than I am when I have to do it all by hand.
    Good point. Not something I've used before. One of several personal projects I never have time for is to explore a refactoring tool for php.

  4. #54
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by McGruff
    Good point. Not something I've used before. One of several personal projects I never have time for is to explore a refactoring tool for php.
    I've sometimes wondered if the php devs (i.e. Zend) added type hinting in order to make it easier for future tools to be written that support things like autocompletion of method names, and other things that tools common to statically-typed languages are able to do. Since they sell an IDE it seems to make sense. I know if I was a tool creator the type hints would be a welcome feature to help me out. But then again it's not possible to specify a "type hint" for return values from functions/methods, and that seems like something that would be needed to make that work. (I feel that types of local variables could possibly be inferred, but I could be wrong about that...)

  5. #55
    Web-coding NINJA! silver trophy beetle's Avatar
    Join Date
    Jul 2002
    Location
    Dallas, TX
    Posts
    2,900
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Zend Studio already supports auto-completion for user-written code, including argument signatures, and even tooltips driven by phpdoc blocks if you cared to write them.

    However, there are no refactoring tools in Zend Studio, but Eclipse with one of the PHP plugins might have some.
    beetle a.k.a. Peter Bailey
    blogs: php | prophp | security | design | zen | software
    refs: dhtml | gecko | prototype | phpdocs | unicode | charsets
    tools: ide | ftp | regex | ffdev




  6. #56
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    Yeah, I've read those before. And I'm certainly not going to claim that I'm as qualified as those people to make a value judgement. And the thing is, I read what they write, and it makes perfect sense to me. I feel like I should find dynamically typed languages more agile, but my (admittedly limited) experience leads me towards the opposite opinion.
    Fair enough. In the end, there's no language or paradigm that is best for everyone in every situation; what's important is what makes you the most productive.

    Quote Originally Posted by DerelictMan
    First of all, I think it's interesting to note that all of the above people were strong static-typing advocates initially. Only after they "discovered" dynamic typing did they change their minds.
    In the case of many ex static-typing zealots, what lead them to dynamic typing was, in big part, unit testing and TDD; the general consensus seems to be that the safety of static typing isn't (as) neccesary when you're unit testing, and it makes the disadvantages of static typing a lot more apparent and harder to justify.

    Quote Originally Posted by DerelictMan
    As for me, I came at it in the exact opposite direction. I've been programming Perl and PHP for about 6 years now, and in Java for the past 9 months or so. So, you'd expect that when moving to Java I'd find the static typing requirement to be constricting. However, the exact opposite has happened for me.
    See, personally, Java drives me up to wall. I feel I have to type so much code to do anything. I'm not surprised that so many java development tools are out there, working without them is a pretty laborious process. Which brings me to another point; although a killer IDE is great for writing code, it doesn't help at all with reading code, which is an activity we end up spending quite a bit of time doing....

    Quote Originally Posted by DerelictMan
    I also find it interesting that the benefits of static typing that he lists are pretty concrete, while the benefits to dynamic typing he mentions are more nebulous. He metions tool support and documentation in favor of static typing. For dynamic typing his terms are more emotional: "satisfying", "things just seem to flow better", etc. He says it's "more fun programming - even with an inferior environment". I'm not claiming that these more abstract advantages are any less real than the concrete ones. However, I wonder if these people had the experience I'm having in reverse... perhaps with all of us converts (no matter which direction) it's not that we've found something that is "better"... maybe we've found something that is just different, and that difference is enough to make the new thing seem more compelling.
    The benefits may seem nebulous, but I think they stem from the increased signal to noise ratio found in dynamic languages; less time writing types/casts/getter setters etc. means more time actually solving problems, and that's the fun part.


    Quote Originally Posted by DerelictMan
    One last point I'd like to make. Regardless of what Bruce Eckel and Martin Fowler have written, neither of them have abandoned strongly typed languages.
    That's true, but I get the impression that given the choice, both would rather work in dynamic languages.

  7. #57
    SitePoint Zealot DerelictMan's Avatar
    Join Date
    Oct 2005
    Posts
    123
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    See, personally, Java drives me up to wall. I feel I have to type so much code to do anything. I'm not surprised that so many java development tools are out there, working without them is a pretty laborious process.
    That's fair. There is no doubt that Java can be very verbose. I actually think that static typing is a small part of that, though. Many of the more complicated Java APIs could be simplified a great deal without discarding the static typing information. And there's nothing about static typing that forces one to rely heavily on XML... configuration could just as easily be done in code (as it is in PicoContainer vs. something like Spring) or in something like YAML. Nevertheless, with the way things currently are I wouldn't dream of writing Java without the IDE. If forced to do without one I imagine I'd adopt Ruby pretty quickly.

    Quote Originally Posted by 33degrees
    Which brings me to another point; although a killer IDE is great for writing code, it doesn't help at all with reading code, which is an activity we end up spending quite a bit of time doing....
    [...]
    The benefits may seem nebulous, but I think they stem from the increased signal to noise ratio found in dynamic languages
    I doubt we'd ever convince each other, but as previously mentioned I find that type information makes reading code easier, not harder. I don't find static typing information to be noise; to me it is part of the signal. Self-documenting names for methods, classes, and variables definitely helps, but sometimes there's still a gap in understanding. Normally I'd hunt for comments, but IME the static type information is sometimes enough to bridge that gap so that I don't have to look for (frequently outdated) comments. But, this is highly subjective so I understand if you don't agree.

    Quote Originally Posted by 33degrees
    ...less time writing types/casts/getter setters etc. means more time actually solving problems, and that's the fun part.
    A couple of slight nitpicks... firstly I've found that I very rarely use explicit casts in my Java code. With Java 5's generics it's just not as necessary as it used to be. Sure, it still has to be done from time to time, but generic types make it much less frequent.

    Secondly, the need to write getters and setters is orthogonal to the presence of static typing. If you have to write them it's because your language is one that doesn't include support for properties, and both PHP and Java belong to that category. __get() and __set() are not the same thing, since they are handlers for missing properties. (Selkirk wrote a good explanation of the difference in this post on the PHP internals list.) I certainly wish that Java had language level support for properties, just like I wish PHP did...

  8. #58
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by DerelictMan
    That's fair. There is no doubt that Java can be very verbose. I actually think that static typing is a small part of that, though. Many of the more complicated Java APIs could be simplified a great deal without discarding the static typing information. And there's nothing about static typing that forces one to rely heavily on XML... configuration could just as easily be done in code (as it is in PicoContainer vs. something like Spring) or in something like YAML. Nevertheless, with the way things currently are I wouldn't dream of writing Java without the IDE. If forced to do without one I imagine I'd adopt Ruby pretty quickly.
    This is getting off topic, but... IMO Java definitely has problems other than static typing, some of them being rigidity elsewhere in the language, and some of them in the culture that surrounds the language (although that's not to say that other languages have less problems).

  9. #59
    SitePoint Wizard
    Join Date
    Jan 2005
    Location
    Denmark
    Posts
    1,222
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    IDEs are where refactorings are exposed. I believe that it is important to distinguish between refactorings and code-generation, which is another typical task for IDEs. Typically refactorings will alter the code to something that you would have written in the first place, had you realized at the time what now prompted you to refactor your code. All of the typical refactorings fall in this category, like renaming, changing method signatures, pulling members up / pushing down, extracting interfaces etc.

    Refactorings lead to better code. It is so easy to twitch it every time you realize something new. Often this makes the difference between actually refactoring it or not.

    It is theoretically impossible to automate refactorings with dynamically typed languages to the same degree as with statically typed languages. This is due to the fact that the type of any variable is simply not known in advance of the actual execution. Even the simplest of refactorings (renaming a member) can not be performed in a robust way.

    This is interesting because it seems to me that the typical developer using a dynamically typed language will *still* reserve variables for specific types (and derivatives). Only under specific circumstances will the developer write code which will work with any type, and typically he/she will then introduce some other kind of requirement, e.g. conventions for named members. ActiveRecord and SimpleXML are good examples of this type of coding. But for the bread-and-butter coding such coding style can actually make the code harder to read, simply because you have to imagine all of the types a variable can hold when you read the code.

    As I see it, the dynamically typed languages certainly adds freedom to coders. But in a lot of common cases this very property also allows for some unsafe code and it generally defeat tool support for refactorings etc. This is recognized by many developers, who will typically counter by adopting conventions.

    On the other hand statically typed languages enable more correct code and refactoring tool support. But in a lot of common cases, like database access, xml parsing/generation this very property can easily get in the way and require some comparatively more cumbersome coding. The typical way to respond to this will be (even more) tools that generate (statically typed) code.

    Seems to be that both camps have something to learn from eachother.
    /mouse


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •