Home

News: Can Dynamic Languages Scale?

  1. Can Dynamic Languages Scale? (143 messages)

    With the apparent failure of the much hyped Chandler project, folks over at manageability.org have some questions about the scalability of dynamic languages. Most conversations that start with this question typically center around the runtime characteristics of different languages, but this one actually discusses developer and code base scalability. Using the Eclipse project as its baseline and Plone for comparison, the author begins to lay the foundations for discussions on issues projects face as they grow: code evolution, modularization, refactoring, etc. Also, unlike many similar conversations, this conversation doesn't devolve into the all too common "ruby is a toy, java is the answer" trollfest that often confounds any attempts to find any usable conclusion. It presents a reasonably evenhanded attempt to isolate causes of failures in projects such as Chandler while the Eclipse platform (and OSGi) have seen such stellar successes. Apart from language choices, the discussions in the comment sections also question many of the structural and governance decisions of the project. So how do you manage a project as it grows well beyond its original scope, codebase, and even development team? What kind of decisions are you making as engineers to ensure that your own projects can evolve successfully to meet its goals in a reasonable time while maintaining the flexibility to meet future demands?

    Threaded Messages (143)

  2. Mercurial[ Go to top ]

    Python seems to be working fine for the Mercurial project. http://www.selenic.com/mercurial/wiki/ I am not sure thought if Mercurial qualifies as a large project.
  3. Mercurial[ Go to top ]

    No, mercurial is not a large project. The last time I looked, Python code was less than 1Mb.
  4. What constitutes a large project?[ Go to top ]

    No, mercurial is not a large project. The last time I looked, Python code was less than 1Mb.
    I'm not disagreeing with you Alex, but I think that your post highlights a key point of the issue. You immediately jump to code size (LOC / MB) to define "large". A dynamic language enthusiast might say that this is a very poor metric where dynamic languages are concerned. Part of what makes dynamic languages great is that a system doesn't have to be large (code) to be large (function).
  5. Can USArmy scale?[ Go to top ]

    With the apparent failure of the much hyped WarOnTerror project, folks over at shutupikillyou.org have some questions about the scalability of USArmy. Most conversations that start with this question typically center around the runtime characteristics of different think tanks, but this one actually discusses politicians and militarians scalability. Using the WarInTheGulf project as its baseline and Afghanistan for comparison, the author begins to lay the foundations for discussions on issues projects face as they grow: accurate vote count, estimated budget evolution, scalable offshore bank accounts, etc. Also, unlike many similar conversations, this conversation doesn't devolve into the all too common "M16 is a toy, AK47 is the answer" trollfest that often confounds any attempts to find any usable conclusion. Apart from civilization choices, the discussions in the comment sections also question many of the structural and governance decisions of the project. So how do you manage a project as it grows well beyond its original scope, codebase, and even development team? What kind of decisions are you making as republicans to ensure that your own projects can evolve successfully to meet its goals in a reasonable time while maintaining the flexibility to meet future demands?
  6. Re: Can USArmy scale?[ Go to top ]

    With the apparent failure of the much hyped WarOnTerror project, folks over at shutupikillyou.org have some questions about the scalability of USArmy.
    Assassination target acquired. Prepare to die. -- Jack Bauer CTU Los Angeles, CA
  7. Re: Can Dynamic Languages Scale?[ Go to top ]

    I think the answer is hitting a perfect balance. going too much into one side is always going to be trouble. A similar argumwnt can be made when people start using every available thing on source forge for their project. compatibilities, maintenance and support are goign to kill such a project. With all jokes aside, in this case microsoft platform (.Net) is a bit better(Dont get me wrong here, understand the argument and context). The compatibility problems with microsoft are few and also their MSDN network has plenty examples and great documentation. Sorry to say but besides may be spring, tangosol( now oracle), apache etc, only a few open source projects are worth using in a critical project. There is no support or documentation. So everyday when i read headlines like tom dick released version 1.9 of harry, i just ignore it. :)
  8. Re: Can Dynamic Languages Scale?[ Go to top ]

    Yes, they can scale. The question is that when you use a methodology for scalable development using a dynamic language, do you then get any actual productivity benefit from using the dynamic language. This simply boils down to extensive code testing. In Java, we focus on units tests for select functionality, but in truth we can get by without have 100% code coverage. With dynamic languages, that's not the case. With static languages like Java, we get a select subset of code tests, with 100% code coverage, every time we compile. We get those tests for "free". The price we pay for those "free" tests is static typing, which certainly has hidden costs. Dynamic languages thrive and are very successful with small, core teams. In code sets where one module doesn't creep away from the others, only to be found out at the last minute. Not every aspect of a project needs something like static typing, but then not every project needs the flexibility of dynamic typing. All projects can probably benefit from a mixture of both. When you have large code bases being developed by large teams, changes ripple throughout the code base constantly. Some are small, others are like tidal waves. Static typed systems tend to absorb those ripples more reliably than dynamic systems. Static system creak and groan under the changes, and those creaks stand out and can easily be found. Dynamic system absorb those changes more readily, and silently. That's a key benefit. You can make a local change, that may well have far reaching effects, in a dynamic language and still be able to work on your change without having to "fix" the entire system just to get it to start up for a test. You can fix the rest of the system later. When that's done intentionally, that's a great feature. When it's done unintentionally, it can be really problematic and raises the importance of having a lot of tests with good coverage so that those kinds of error don't creep in. With static systems, it's difficult for those kinds of wide spread things to happen; the system simply won't build. This slows down development (we've all been there: "I just want to test this little thing!"). But when you've passed that threshold, there's an intrinsic reliability assured by the compiler. With discipline, dynamic languages can certainly work. But they take work, and most folks going in to a dynamic language may not be willing to put forth the extra effort necessary to make them work.
  9. IDE support[ Go to top ]

    I'd be curious to hear people's experience with Intellij or Netbeans Ruby/Rails support. Is it as good a Java's? The type system + IDE support leads me to believe that Java would be far superior for a large project, but I have yet to have time to experiment. -- Bill Burke http://bill.burkecentral.com
  10. Re: IDE support[ Go to top ]

    I'd be curious to hear people's experience with Intellij or Netbeans Ruby/Rails support. Is it as good a Java's? The type system + IDE support leads me to believe that Java would be far superior for a large project, but I have yet to have time to experiment.

    --
    Bill Burke
    http://bill.burkecentral.com
    Hi Bill, There is more than one way to skin a cat. Type errors are only one amongst many type of errors possible in code. For safety and scalability I fine that TDD/BDD is the most powerful tool I've got in my armory. If you've ever done a massive refactor changing code all over the place with the luxury of runnning your Tests/Specs to get that comforting green bar you would know what I mean. Without Tests/Specs, I would never consider a big refactor even when it was needed, and entropy would soon kick in and limit the size/functionality of my code (I am assuming this is what people mean by scalability here). With Tests/Specs anything is possible. If you believe in a test first programming style, then the only difference between dynamic versus static, is that dynamic requires less code, and static gives you code completion. With the latest IDEs that you mention, you can get code completion with a dynamic language too. In my experience if you use TDD/BDD you get a lot more functionality for a lot less code with a dynamic language and around the same number of bugs as you would get using TDD/BDD with a static language (which is usually very few). Paul.
  11. Re: IDE support[ Go to top ]

    Hi Paul,
    There is more than one way to skin a cat. Type errors are only one amongst many type of errors possible in code. For safety and scalability I fine that TDD/BDD is the most powerful tool I've got in my armory. If you've ever done a massive refactor changing code all over the place with the luxury of runnning your Tests/Specs to get that comforting green bar you would know what I mean.

    Without Tests/Specs, I would never consider a big refactor even when it was needed, and entropy would soon kick in and limit the size/functionality of my code (I am assuming this is what people mean by scalability here).

    With Tests/Specs anything is possible. If you believe in a test first programming style, then the only difference between dynamic versus static, is that dynamic requires less code, and static gives you code completion. With the latest IDEs that you mention, you can get code completion with a dynamic language too.

    In my experience if you use TDD/BDD you get a lot more functionality for a lot less code with a dynamic language and around the same number of bugs as you would get using TDD/BDD with a static language (which is usually very few).

    Paul.
    You forget an important point: with dynamically typed languages, you lose a lot of automatic refactorings. Tests will guarantee that your refactorings didn't break anything, but the fact that you have to perform most of these manually is one of the reasons why a lot of people don't believe that dynamically typed languages are a good fit for large scale software. -- Cedric
  12. Re: IDE support[ Go to top ]

    Tests will guarantee that your refactorings didn't break anything, but the fact that you have to perform most of these manually is one of the reasons why a lot of people don't believe that dynamically typed languages are a good fit for large scale software.

    --
    Cedric
    Hi Cedric, The proof of the pudding is in the eating. Take a look at open croquet. I know of nothing this ambitious written in a static language. The first refactoring IDE (called The Refactoring) was written for Smalltalk and has plenty of refactors available , along with SUnit the first unit test harness. Static and dynamic languages require a different programming style. If you try to use a static style with a dynamic language you will run into trouble. If you adopt dynamic programming idioms and patterns though they serve as well (or better) then the static equivalents IMO (see Kent Becks Smalltalk Best Practice Patterns) and they tend to require less key strokes and less boiler plate code. Also new tools are possible such as the code rewriter and code critic you get with VW Smalltalk and the Refactoring Browser. So the issue is whether you are willing to adjust your style, and the most important factor as always is the person driving the keyboard. Paul.
  13. Re: IDE support[ Go to top ]


    The proof of the pudding is in the eating. Take a look at open croquet. I know of nothing this ambitious written in a static language.

    The first refactoring IDE (called The Refactoring) was written for Smalltalk and has plenty of refactors available , along with SUnit the first unit test harness. Static and dynamic languages require a different programming style. If you try to use a static style with a dynamic language you will run into trouble. If you adopt dynamic programming idioms and patterns though they serve as well (or better) then the static equivalents IMO (see Kent Becks Smalltalk Best Practice Patterns) and they tend to require less key strokes and less boiler plate code. Also new tools are possible such as the code rewriter and code critic you get with VW Smalltalk and the Refactoring Browser.

    So the issue is whether you are willing to adjust your style, and the most important factor as always is the person driving the keyboard.

    Paul.
    Paul, I know that the dynamic community is investigating several avenues to enable automatic refactoring (the attempts I've seen so far were very academic, such as running the code millions of times to guess the code paths in order to identify all the possible call sites), but at the end of the day, the fact remains that most dynamically typed code simply *cannot* be automatically refactored without the intervention of humans. -- Cedric
  14. Re: IDE support[ Go to top ]

    Cedric, Did you look at the list of refactors for the Refactoring Browser:
    Refactoring Browser - Refactorings The refactorings in the Refactoring Browser can be classified into three sections: class based refactorings, method based refactorings, and code based refactorings. The class based refactorings operate on classes, instance variables, and class variables and are defined off the class menu. The method based refactorings are defined off the selector menu. Finally the code based refactorings operate on individual statements and are available through the context sensitive menus in the code tool. Many of the class based refactorings are also available in the context sensitive menus in the code tools. Class Refactorings 1. Create subclass: This refactoring allows you to insert a new class into an existing hierarchy. For example, you can insert a new class between object and all of its subclasses by using the refactoring (although I wouldn't recommend it). To use the refactoring, simple select the superclass for the new class and then execute the create subclass refactoring. 2. Rename: This refactoring renames a class and also renames every reference to the class in the code. Even symbols with the same name as the class will also be renamed so that "Smalltalk at: ..." will work. However, if you are constructing class names using the asSymbol message, then those strings will not be renamed. In ENVY the renamed class will also contain all the stored ENVY attributes that the original class contained, including the classes part builder records in VA. However, currently the browser does not rename class references in these stored attributes. 3. Safe Remove: This refactoring checks for references to a class, and if there are no references, it will remove the class. If you reference the class by using constructed symbols and "Smalltalk at: ...", it may remove your class even though your code still uses it. 4. Convert to Sibling: ... 5. Add instance/class variable: Add a variable to the class. In ENVY it will check that the variable is not already defined as a temporary in one of the class' methods. 6. Rename instance/class variable: Renames a variable and all references to the variable. If you are using instVarAt:'s, then this might break your code, since currently the new variable's name is always at the end. 7. Remove instance/class variable: Removes a variable only if it is not referenced. Again, if you are using instVarAt:'s, this refactoring can remove a variable that is actually used. 8. Push Down instance/class variable: Moves a variable definition from the currently selected class to only those subclasses that use the variable (removing the variable if no subclass has a reference to the variable). This will only be allowed, if the selected class contains no references to the variable. For class variables, it can only push the variable down into one subclass. Otherwise, it will have split the one class variable into two and possibly broken the code. As will the other variable refactorings, this refactoring will not work with instVarAt:'s. 9. Pull Up instance/class variable: Move a variable definition from a subclass of the currently selected class into the currently selected class. 10. Create instance/class variable Accessors: Creates getter and setter methods for a variable. The methods are named with the name of the variable. If a method with that name already exists, then it will add a number to the name, until it no longer conflicts. 11. Abstract instance/class variable: Performs the create accessors refactoring and then converts all direct variable to use the accessor methods. 12. Protect/Concrete instance variable: Converts all variable accessor sends to direct variable references. If the accessor is no longer used then it will be removed. 13. Convert to ValueHolder: This refactoring is only available for VW. It will convert a variable into a ValueHolder. This was more useful for converting old interfaces used in OW4.1 to the new VW style. Method Refactorings 1. Move to Component: Moves a method to another object (defined by an argument or instance variable). 2. Rename: Renames all implementors of a method, all senders, and all symbols references. In addition to strict renaming, it also allows you to rearrange the parameters. However, when rearranging the parameters, it cannot permute any symbols that are performed. 3. Safe Remove: Removes a method if there are no senders of the method or there are no symbol that reference the method name. Also, it will remove a method if it is equivalent to the superclass' definition. 4. Add Parameter: Adds a default parameter to all implementors of the method. 5. Inline all Self Sends: Inlines all senders within the class of the method. If there are no more senders after all inlines have been performed, then it will remove the method. 6. Push Up: Pushes a method up into the superclass. If the superclass is abstract and already defines the method, then the superclass' method will be copied down into the other subclasses (assuming they don't already define the method). 7. Push Down: Pushes a method down into all subclasses that don't implement the method. This can only be allowed if the class is abstract. Code Refactorings 1. Extract Method: Extracts the selected code as a separate method. This refactoring determines what temporary variables are needed in the new method, and prompts for a selector that takes these arguments. 2. Inline Temporary: Removes the assignment of a variable and replaces all references to the variable with the right hand side of the assignment. 3. Convert to Instance Variable: Converts a temporary into an instance variable. 4. Remove Parameter: Removes an unused parameter from all implementors of the method, and removes it from the message sends. 5. Inline Parameter: Remove a parameter from the method, and adds an assignment at the beginning of the method. This can only be performed if all senders of the method have the same value for the parameter. 6. Rename Temporary: Renames a temporary variable. 7. Move to Inner Scope: Moves a temporary variable definition into the tightest scope that contains both the variable assignment and references. This is useful for converting unoptimized blocks into optimized ones. 8. Extract to Temporary: Extracts a message into an assignment statement. For example, if you have something like self someMessage anotherMessage foo: 1 bar: 2 You can extract "self someMessage" to a temporary named, "temp", and get: | temp | temp := self someMessage. temp anotherMessage foo: 1 bar: 2 9. Inline Message: Inlines a message send. If there are multiple implementors of the message, it will prompt for the implementation that should be inlined.
    I do no know how best to say this. But static and dynamic languages are different. People have used both to write large programs. Focusing on one narrow issue (refactoring tool support) misses the point. My advice to anyone out there is to ignore the FUD and try it for yourself. Paul
  15. Re: IDE support[ Go to top ]

    I do no know how best to say this. But static and dynamic languages are different. People have used both to write large programs. Focusing on one narrow issue (refactoring tool support) misses the point. My advice to anyone out there is to ignore the FUD and try it for yourself.
    Refactoring support is far from a narrow issue. It is a HUGE issue and far from FUD. If you want to talk about campaigns if misinformation, the biggest culprit is the dynamic language crowd. I find it funny whenever an issue comes up with a dynamic language, the dynamic crowd tries to rationalize things away with bizarre comments like: * Green threads are good enough * You'll have half the lines of code so half the bugs * Large teams suck. Only have small teams and small projects * Language productivity negates refactoring productivity. * IDE's are useless Don't believe me? Just search the web dude. I did a little research on Ruby a few weeks ago and found tons of hilarious stuff. -- Bill Burke http://bill.burkecentral.com
  16. Re: IDE support[ Go to top ]

    I do no know how best to say this. But static and dynamic languages are different. People have used both to write large programs. Focusing on one narrow issue (refactoring tool support) misses the point. My advice to anyone out there is to ignore the FUD and try it for yourself.


    Refactoring support is far from a narrow issue. It is a HUGE issue and far from FUD.

    If you want to talk about campaigns if misinformation, the biggest culprit is the dynamic language crowd. I find it funny whenever an issue comes up with a dynamic language, the dynamic crowd tries to rationalize things away with bizarre comments like:

    * Green threads are good enough
    * You'll have half the lines of code so half the bugs
    * Large teams suck. Only have small teams and small projects
    * Language productivity negates refactoring productivity.
    * IDE's are useless

    Don't believe me? Just search the web dude. I did a little research on Ruby a few weeks ago and found tons of hilarious stuff.

    --
    Bill Burke
    http://bill.burkecentral.com
    Hi Bill, I don't have to take your word for it. I have written large programs in both Smalltalk and Ruby myself, so I have first hand experience. Stick with what you know, but don't knock what you don't! Paul.
  17. Re: IDE support[ Go to top ]

    Refactoring support is far from a narrow issue. It is a HUGE issue and far from FUD.
    I agree, refactoring is a huge issue. Best I can tell NetBeans has the best refactoring support for Ruby, so I'd give it a try and see what you think. I've been doing more Groovy these days so I haven't tried it. I can't see anyway that the refactoring support could be as good for ruby as it is for java.... I'm guessing it could get maybe 50-75% of the way there... That being said, Java gives up a lot of the benefits of static typing with the universal XML obsession shown in just about every java framework. Spring, Ant, Hibernate, etc. Refactoring doesn't deal well with XML (only IntelliJ even tries), and you end up with the same problems as the dynamic languages. I just had a failure doing a java refactoring, I never could nail down what I did wrong except there was something wrong in one of the approximately 500 XML files in the project I'm working on. I ended up deciding to re-attempt the entire refactoring instead of hacking and hacking....
    * Green threads are good enough
    They aren't :) I agree that green threads suck ass.
    * You'll have half the lines of code so half the bugs
    Well I think that less code complexity leads to fewer bugs. Number of lines is one issue, but they can't be hairy "write only" lines of code. In general pretty much every language is more expressive than Java though.
    * Large teams suck. Only have small teams and small projects
    If I were running a project it would be small team, I think large teams are ineffective. but of course we don't all pick our team size.
    * Language productivity negates refactoring productivity.
    To an extent. But refactoring once in awhile is critical. So it's definitely a negative against dynamic languages.
    * IDE's are useless
    Anyone who says this hasn't used a good IDE. IntelliJ is the only thing that makes Java coding tolerable! And I've coded in Ruby in a text editor.... it sucks. IMO using just a text editor for ruby completely negates any productivity gains. But you don't have to - IntelliJ, NetBeans, and Eclipse all have pretty decent ruby support. phil http://philswenson.com
  18. Re: IDE support[ Go to top ]

    Refactoring doesn't deal well with XML (only IntelliJ even tries), and you end up with the same problems as the dynamic languages. I just had a failure doing a java refactoring, I never could nail down what I did wrong except there was something wrong in one of the approximately 500 XML files in the project I'm working on. I ended up deciding to re-attempt the entire refactoring instead of hacking and hacking....
    What you're describing is only partially Java's fault. IMO, its mostly a framework problem. J2EE, Spring, and WS-* are the biggest culprits. This is why, IMO, frameworks like Guice, Seam, JPA, and Web Beans are a breath of fresh air. Closures and structural initalization syntax would greatly improve the Java language. BTW, I'd be curious to hear people's experiences with Intellij's XML support. I think its cool that Hibernate, web.xml, and even spring files can be a part of the refactoring/compilation process.
  19. Re: IDE support[ Go to top ]

    Refactoring doesn't deal well with XML (only IntelliJ even tries), and you end up with the same problems as the dynamic languages. I just had a failure doing a java refactoring, I never could nail down what I did wrong except there was something wrong in one of the approximately 500 XML files in the project I'm working on. I ended up deciding to re-attempt the entire refactoring instead of hacking and hacking....


    What you're describing is only partially Java's fault. IMO, its mostly a framework problem. J2EE, Spring, and WS-* are the biggest culprits. This is why, IMO, frameworks like Guice, Seam, JPA, and Web Beans are a breath of fresh air.

    Closures and structural initalization syntax would greatly improve the Java language.

    BTW, I'd be curious to hear people's experiences with Intellij's XML support. I think its cool that Hibernate, web.xml, and even spring files can be a part of the refactoring/compilation process.
    I never had that much problem with Spring's XML. Most IDEs can refactor down to the XML level for renaming properties and class names (Eclipse has the Spring plugin called Spring IDE). Having worked on many large Spring projects... it is just not a problem. (IntelliJ also has good support for Spring XML files.) That said Spring 2.5 allows annotation based injection and the Spring Java configuration is another Java-only way to define a Spring application context (one I like a lot) without XML. So if you do think it is a problem you can write a Spring based app with very little XML....
  20. Re: IDE support[ Go to top ]

    IMO, its mostly a framework problem. J2EE, Spring, and WS-* are the biggest culprits. This is why, IMO, frameworks like Guice, Seam, JPA, and Web Beans are a breath of fresh air.
    Ok, but you can remove Spring from this list. Latest release allow a strong use of annotations.
  21. Re: IDE support[ Go to top ]

    Refactoring doesn't deal well with XML (only IntelliJ even tries)
    Guess it depends on what the XML is. Refactor my Eclipse RCP code all the time and Eclipse refactors my plugin.xml quite nicely.
  22. Re: IDE support[ Go to top ]

    Cedric,

    Did you look at the list of refactors for the Refactoring
    Yes, I did, and most of these refactorings are not safe in a dynamically typed language, so you can configure the browser to either do all of them automatically (dangerous) or to ask you every time (tedious). It's not hard to see why. Consider the following code (Ruby): def f1(o) o.init end def f2(o) o.init end class C def init ... end end If I rename C.init to C.init2, how do you know which o.init must be renamed in f1 and f2? There is no way for an IDE to determine this answer. -- Cedric
  23. Re: IDE support[ Go to top ]

    Cedric,

    Did you look at the list of refactors for the Refactoring

    Yes, I did, and most of these refactorings are not safe in a dynamically typed language, so you can configure the browser to either do all of them automatica
    Having tried both. I much prefer the tedium of my IDE prompting me every now and again when I do a refactor then the tedium of having to always repeat myself twice every time In declare a variable. You pay your money and you take your choice. I still don't see what this has to do with large programs though, and you haven't addressed why OpenCroquet or Gemstone Application Server or AutoCAD or a number of other large programs written in dynamic languages don't count. Paul.
  24. Re: IDE support[ Go to top ]

    Cedric,

    Did you look at the list of refactors for the Refactoring

    Yes, I did, and most of these refactorings are not safe in a dynamically typed language, so you can configure the browser to either do all of them automatica


    Having tried both. I much prefer the tedium of my IDE prompting me every now and again when I do a refactor then the tedium of having to always repeat myself twice every time In declare a variable.
    No arguments there, I definitely prefer to be asked by the IDE if it can perform the refactoring than doing it myself. Of course, it's even better when I don't need to be asked, which is what happens with statically typed languages. And *this* was the point of this discussion: IDE's for dynamically typed languages will *never* be able to perform automatic refactorings, so they will always be less productive in that area.
    You pay your money and you take your choice. I still don't see what this has to do with large programs though
    Since automatic refactorings are not possible in dynamically typed languages, they are less fit for large scale projects than statically typed languages and are more prone to encourage bit rot since programmers will become hesitant performing refactorings as the size of the code grows. I have certainly experienced this fear even in my personal small projects written in Ruby, PHP and Javascript.
    you haven't addressed why OpenCroquet or Gemstone Application Server or AutoCAD or a number of other large programs written in dynamic languages don't count.
    The existence of these projects doesn't invalidate my point since there is no way of knowing the amount of pain it took to get there, nor can we know for sure it the current code base is in a decent shape or a big mess that developers are afraid to touch. I'm guessing the latter :-) -- Cedric
  25. Re: IDE support[ Go to top ]

    The existence of these projects doesn't invalidate my point since there is no way of knowing the amount of pain it took to get there, nor can we know for sure it the current code base is in a decent shape or a big mess that developers are afraid to touch.

    I'm guessing the latter :-)

    --
    Cedric
    This is the problem. Everything you say is one big guess, based on ignorance. Fortunately, people are ignoring the FUD, and taking the wise step of trying things out for themselves. Paul.
  26. Re: IDE support[ Go to top ]

    This is the problem. Everything you say is one big guess, based on ignorance.

    Fortunately, people are ignoring the FUD, and taking the wise step of trying things out for themselves.

    Paul.
    I'm sad to see you resort to ad hominem attacks. Not only have I "tried it out for myself", as my previous messages show, but I am also giving some very concrete examples proving my point. These examples must have been convincing since you ended up agreeing with me on the fact that IDE's for dynamically typed languages will never be able to refactor code automatically. Not sure why this discovery upsets you so much. -- Cedric
  27. Re: IDE support[ Go to top ]

    This is the problem. Everything you say is one big guess, based on ignorance.

    Fortunately, people are ignoring the FUD, and taking the wise step of trying things out for themselves.

    Paul.

    I'm sad to see you resort to ad hominem attacks.

    Not only have I "tried it out for myself", as my previous messages show, but I am also giving some very concrete examples proving my point. These examples must have been convincing since you ended up agreeing with me on the fact that IDE's for dynamically typed languages will never be able to refactor code automatically.

    Not sure why this discovery upsets you so much.

    --
    Cedric
    No attack, You said you are guessing. So you are admitting ignorance (check your dictionary). Your concrete examples are irrelevant to the subject at hand. Can you write large programs (scale) in dynamic languages? Is the question. To which the answer is yes. This is a plain fact, and I've provided several examples. You choose to speculate, rather then check these facts for yourself. Sounds like ignorance to me. Paul.
  28. Re: IDE support[ Go to top ]

    This is the problem. Everything you say is one big guess, based on ignorance. Fortunately, people are ignoring the FUD, and taking the wise step of trying things out for themselves.

    Paul.
    Just imagined an ad from a drug cartel: This is the problem. Everything you say about drugs is one big guess, based on ignorance. Fortunately, people are ignoring the FUD, and taking the wise step of trying things out for themselves. IMO: Trying things personally just for the heck of it is not the wisest use of time and usually does not make sense because things to try require mastering for a long time to really understand and appreciate. Dear zealots: please explain WHY should I try your thing and WHY should I give up things I like
  29. Choice and Competence[ Go to top ]

    This is the problem. Everything you say is one big guess, based on ignorance.
    Fortunately, people are ignoring the FUD, and taking the wise step of trying things out for themselves.

    Paul.


    Just imagined an ad from a drug cartel:
    This is the problem. Everything you say about drugs is one big guess, based on ignorance.
    Fortunately, people are ignoring the FUD, and taking the wise step of trying things out for themselves.



    IMO: Trying things personally just for the heck of it is not the wisest use of time and usually does not make sense because things to try require mastering for a long time to really understand and appreciate.

    Dear zealots: please explain WHY should I try your thing and WHY should I give up things I like
    Hi Konstantini, I wouldn't describe myself as a zealot. I am not advocating anything here. What I have done is call out FUD. The reason? Mud sticks. With that out the way, you ask a fair question. The real issue is about teams. What is right for a given team depends on their skills and their needs. People will have lots of reasons for wanting to try a dynamic language. It is up to them to decide WHY. It is great news that they now have a choice. I would not advise a Java team jump straight into a big Ruby project. First they could decide to use Ruby for testing (WATIR is good for this). As their experience and confidence with dynamic languages grow, they may want to attempt a small pilot project. They will learn from their mistakes. This is just common sense. Given their experiences, they may choose to change their working practices to better suite their new tool (or not to adopt a dynamic language at all, it is their choice). Eventually they will become as competent with Ruby as they are with Java. At this stage they are free to choose the right tool for the job and take on larger Ruby projects if they choose. It is not about switching, it is about adding new tools to your tool box, and developing competence with those tools if you want to. If you haven't the required competence and you don't want to learn then stick to with what you know. Good teams succeed, poor teams fail. It is really that simple. Success comes down to people not compilers. Paul.
  30. IMO: Trying things personally just for the heck of it is not the wisest use of time and usually does not make sense because things to try require mastering for a long time to really understand and appreciate.
    Personally I wouldn't hire anyone with an attitude like yours. Instead I want people that are creative and innovative. It doesn't matter whether it's experimenting with a new language, API, development practice etc. and it doesn't have take weeks, just a few hours is usually enough to know whether something is worth progressing. Unless you a bit of time to find what tools are available you'll never be able to pick the right one for the job. Your productivity and code quality will suffer as a result.
  31. IMO: Trying things personally just for the heck of it is not the wisest use of time and usually does not make sense because things to try require mastering for a long time to really understand and appreciate.

    Personally I wouldn't hire anyone with an attitude like yours. Instead I want people that are creative and innovative. It doesn't matter whether it's experimenting with a new language, API, development practice etc. and it doesn't have take weeks, just a few hours is usually enough to know whether something is worth progressing.

    Unless you a bit of time to find what tools are available you'll never be able to pick the right one for the job. Your productivity and code quality will suffer as a result.
    I don't think you understand his point. Last I checked, there are only 24 hours in a day. We have to eat, sleep, bath, get(or keep chicks), work, socialize(family, friends), hobbies(all work and no play)etc, and to be frank, who has the time or inclination to try EVERYTHING. There has to be a compelling reason to engage something and I agree that doing "just for the heck" is a waste of time and money. Personally, I've had far more success getting buy-in when I can make a business case for something. And what makes sense for one may not make sense for another. I don't think his being mindful of what he tries makes him any less creative or innovative than anyone else. I wouldn't want to work for a place with such a lack of focus that they either 1)have time to try everything(where's the paying work?) or 2)Expect me to constantly devote my "me" time to work related items.
  32. I don't think you understand his point. Last I checked, there are only 24 hours in a day. We have to eat, sleep, bath, get(or keep chicks), work, socialize(family, friends), hobbies(all work and no play)etc, and to be frank, who has the time or inclination to try EVERYTHING.
    This is how I interpret his statement: let other people put in the work necessary to understand and learn from new technology then expect to be spoonfed information once all the dust has settled. With an attitude like this we'd still be stuck with Struts 1.x, Tiles and EJB 2.x. It's obviously impossible to try EVERYTHING, but all the professional developers I know keep their eye on the currently "talked about" tools and look forward to investigating them as their personal time allows. e.g. I'm already skilled up in Spring MVC, but my next personal project will be based on Wicket purely because most of the posts about it are positive and it offers a different way of working. I already know how to write junit tests, however I've started using TestNG instead in case it offers a better way of working. It was behaviour like this that lead me to try JodaTime around two years ago and I haven't new'd up a java.util.Date since.
    2)Expect me to constantly devote my "me" time to work related items.
    And this is why I wouldn't hire you either. It's not that you should HAVE to dedicate "me" time to improving your technical awareness, it's that I'm only interesting in working with people who WANT to, because it's what they enjoy doing.
  33. 2)Expect me to constantly devote my "me" time to work related items.

    And this is why I wouldn't hire you either. It's not that you should HAVE to dedicate "me" time to improving your technical awareness, it's that I'm only interesting in working with people who WANT to, because it's what they enjoy doing.
    +1 Ilya
  34. Don't worry, I would never work *for* you. If you knew as much as you thought, you would never question my enjoyment for my work. You are arrogant and not worth working with,let alone for. Anyone with such distorted priorities surely is no joy to be around.
  35. Don't worry, I would never work *for* you. If you knew as much as you thought, you would never question my enjoyment for my work.

    You are arrogant and not worth working with,let alone for.

    Anyone with such distorted priorities surely is no joy to be around.
    David, you're taking it to personally. I agree with Steve in regard to hiring someone who doesn't look at it as if he/she is going to work every day, rather this is something they enjoy doing (their hobby, social life, etc...). I love software development and the challenges it entails. Being awake for 48 hours because we're trying to resolve some issue doesn't feel like "Oh this job's taking a lot out of me, I need some time to enjoy myself", because I'm enjoying myself already doing it. That's what Steve is mostly referring too. If you go to work for your 9-5 and to just put food on the table, then as Steve mentioned, you're probably not the best person for the job. I work for a startup. We're constantly hiring. Well, we're trying to hire. We rarely see anyone even worth pursuing beyond reading the resume, let alone interviewing. The ones that make it to the interview don't have the passion to work in our environment, because programming is a 9-5 job for them and then they go home to do things they really "enjoy". Ilya
  36. Re: And how is Cobol working out for you?[ Go to top ]

    I work for a startup. We're constantly hiring. Well, we're trying to hire. We rarely see anyone even worth pursuing beyond reading the resume, let alone interviewing. The ones that make it to the interview don't have the passion to work in our environment, because programming is a 9-5 job for them and then they go home to do things they really "enjoy".
    The issue - The people you want (and should want) for employees don't want to be someone else's employee.
  37. Re: And how is Cobol working out for you?[ Go to top ]

    I work for a startup. We're constantly hiring. Well, we're trying to hire. We rarely see anyone even worth pursuing beyond reading the resume, let alone interviewing. The ones that make it to the interview don't have the passion to work in our environment, because programming is a 9-5 job for them and then they go home to do things they really "enjoy".

    The issue - The people you want (and should want) for employees don't want to be someone else's employee.
    That's a very good point.
  38. Don't worry, I would never work *for* you. If you knew as much as you thought, you would never question my enjoyment for my work.

    You are arrogant and not worth working with,let alone for.

    Anyone with such distorted priorities surely is no joy to be around.


    David, you're taking it to personally. I agree with Steve in regard to hiring someone who doesn't look at it as if he/she is going to work every day, rather this is something they enjoy doing (their hobby, social life, etc...). I love software development and the challenges it entails. Being awake for 48 hours because we're trying to resolve some issue doesn't feel like "Oh this job's taking a lot out of me, I need some time to enjoy myself", because I'm enjoying myself already doing it. That's what Steve is mostly referring too. If you go to work for your 9-5 and to just put food on the table, then as Steve mentioned, you're probably not the best person for the job.

    I work for a startup. We're constantly hiring. Well, we're trying to hire. We rarely see anyone even worth pursuing beyond reading the resume, let alone interviewing. The ones that make it to the interview don't have the passion to work in our environment, because programming is a 9-5 job for them and then they go home to do things they really "enjoy".

    Ilya
    Acknowlege. Calling me ignorant is one thing, but say I don't like learning new stuff and now its war!! :-) Seriously, I changed jobs a few months ago. One of the first questions I was asked was "Have I ever missed lunch?" "Of course," I answered. "Who doesn't? Who gets hungry when they are right in the middle of problem." You can have passion, but you have to have balance. I used to work some pretty sick hours back in the day. I'd like to think that as I've grown more experienced, that I've gotten smarter and don't need to work quite so hard. I have a 4yr old daughter. I can't get a thing done when you sits in my lap when I work at home on my THREE FLAT MONITORS ;-), btw, but at that moment, I don't care. That's the balance. Left too our own devices, we would do nothing but hole up and program, but that detracts from the other aspects of life no matter how much we enjoy it.
  39. One other thing, I started with Spring year ago and I too learned of Joda time. I've bypassed Spring MVC and Wicket and instead am pursuing the GWT side. I moved my entire previous company from JSP and EJBs to Struts/Spring/Hibernate and then our newest devlopment, a pretty decent sized project to GWT. This was nearly single-handledly because of the work I put in. I've convinced customers why they should allow such tools, not "for the heck of it", not "because it offered a different way of working", but because it GWT and Spring, offered REAL benefits and made sense and in Spring's case(and certainly GWT), this was years before it took the mainstream hold that it currently enjoyed. Where's your AOP? I don't see it listed. You must not be innovative and clearly expect to be spoonfed. You need not apply.
  40. I've convinced customers why they should allow such tools, not "for the heck of it", not "because it offered a different way of working", but because it GWT and Spring, offered REAL benefits and made sense and in Spring's case(and certainly GWT), this was years before it took the mainstream hold that it currently enjoyed.
    At some point before you recommended GWT/Spring to your customers I assume you spent some personal or company time investigating them, and you did so because something you'd heard or read about them tweaked your interest - they sounded promising enough that you suspected the effort would be worthwhile. This is exactly the type of behavour Paul B and I are advocating and Konstantin Ignatyev was objecting too. As for the rest of your response, you are now my hero. Snaps for you.
  41. I've convinced customers why they should allow such tools, not "for the heck of it", not "because it offered a different way of working", but because it GWT and Spring, offered REAL benefits and made sense and in Spring's case(and certainly GWT), this was years before it took the mainstream hold that it currently enjoyed.

    At some point before you recommended GWT/Spring to your customers I assume you spent some personal or company time investigating them, and you did so because something you'd heard or read about them tweaked your interest - they sounded promising enough that you suspected the effort would be worthwhile. This is exactly the type of behavour Paul B and I are advocating and Konstantin Ignatyev was objecting too.

    As for the rest of your response, you are now my hero. Snaps for you.
    I never objected to using my own time. It was only about "trying everything." My original interpretation was that, say Ruby and GWT are out there. I only have time to try one. Which one? I read this site so faithfully because you find out what's out there. This site has given me Idea, Spring,Hibernate, Jodatime, Dozer, OSCache, I cannot even list them all!
  42. It's not that you should HAVE to dedicate "me" time to improving your technical awareness, it's that I'm only interesting in working with people who WANT to, because it's what they enjoy doing.
    When workaholics/geeks/microserfs turn 40+ and get more free time (perhaps they enter more managerial positions with no "crunch time" and not this rush of Framework-of-the-month technologies to keep abreast on), they discover that the free time they now have is not the free time they could have had back when they were 25. It's too late to spend tine with kids now grown up, you no longer have the energy needed for sports, and so on and so forth. Basically you do not get to delay your youth, you either spend it working or you spend it living. Or you find a healthy mixture of the two. (Do you really want to work with people with no life?) But to address something you seem to have missed: Even if developers take the time to learn FOTM technology, do you really want them to start using them - new and relatively unknown - in mission-critical systems instead of tried and tested technology they have more experience in? (When .Net was introduced, Microsoft pushed the "50 languages" thing as a counter to Java's "one language" - never mind that many of the languages had their arms twisted to fit in the CLS/CLR. But is having 50 languages for your platform a good thing? What if developer A implements a module in Haskell and developer B implements theirs in Eiffel; should developer C, who prefers C# have to learn these two languages as well if he ends up maintaining their code?)
  43. When workaholics/geeks/microserfs turn 40+ and get more free time (perhaps they enter more managerial positions with no "crunch time" and not this rush of Framework-of-the-month technologies to keep abreast on), they discover that the free time they now have is not the free time they could have had back when they were 25. It's too late to spend tine with kids now grown up, you no longer have the energy needed for sports, and so on and so forth. Basically you do not get to delay your youth, you either spend it working or you spend it living. Or you find a healthy mixture of the two.

    (Do you really want to work with people with no life?)
    Yeah, I don't think you're getting it, mostly probably because you're not that person. What do you consider as "life". You might enjoy going outdoor, fishing, etc..., when one "can" actually enjoy programming. Einstein, Edison, Feynman, etc..., weren't per say workaholics. Science, invention, etc... was their life. They would rather be doing that then fishing. I think that's the point we're trying to make here. I don't feel like I have a job at this point, nor had one for years. I do what I would rather be doing. Yes, I still find time for family and sports (basketball, which I enjoy very much), but to define life as spending time with friends, fishing, etc... in general is a mistake. Each person has his/her own definition of what they'd rather be doing. And we're trying to hire someone who's if not completely in love with solving complex computing issues, at least enjoys it quite a bit. Ilya
  44. Re: "Me" time, new technologies[ Go to top ]

    When workaholics/geeks/microserfs turn 40+ and get more free time (perhaps they enter more managerial positions with no "crunch time" and not this rush of Framework-of-the-month technologies to keep abreast on), they discover that the free time they now have is not the free time they could have had back when they were 25. It's too late to spend tine with kids now grown up, you no longer have the energy needed for sports, and so on and so forth. Basically you do not get to delay your youth, you either spend it working or you spend it living. Or you find a healthy mixture of the two.

    (Do you really want to work with people with no life?)


    Yeah, I don't think you're getting it, mostly probably because you're not that person. What do you consider as "life". You might enjoy going outdoor, fishing, etc..., when one "can" actually enjoy programming. Einstein, Edison, Feynman, etc..., weren't per say workaholics. Science, invention, etc... was their life. They would rather be doing that then fishing. I think that's the point we're trying to make here. I don't feel like I have a job at this point, nor had one for years. I do what I would rather be doing. Yes, I still find time for family and sports (basketball, which I enjoy very much), but to define life as spending time with friends, fishing, etc... in general is a mistake. Each person has his/her own definition of what they'd rather be doing. And we're trying to hire someone who's if not completely in love with solving complex computing issues, at least enjoys it quite a bit.

    Ilya
    Well, we are close enough. When I first started learning GWT, I would be on my laptop that could only do 1024x800, a far cry from the 1600x1200 that I run on my 3 monitors, in my family playing with the girl, talking to the wife(about GWT). Saturday morning about 2:00am, I was too buzzed to sleep. GWT is THAT cool, that profound. I haven't buzzed like that since first playing with Spring(DI,AOP), and before that Dynamic proxies. That buzz is one of the reasons I do this stuff.
  45. I really don't want to be responsible dragging this thread off topic any further (especially after Artem and Paul have done such a good job of bringing it back on track), but I feel that a couple of your comments are too important to go unaddressed.
    Even if developers take the time to learn FOTM technology, do you really want them to start using them - new and relatively unknown - in mission-critical systems instead of tried and tested technology they have more experience in?... What if developer A implements a module in Haskell and developer B implements theirs in Eiffel; should developer C, who prefers C# have to learn these two languages as well if he ends up maintaining their code?)
    The problem here is lack of peer review. I choose to work in agile teams that practice pair programming. This ensures that every decision that's made has been reviewed by at least one colleague. Medium level decisions are usually aired in the daily stand-up, bigger decisions discussed in a timeout and unknown quantities de-risked through a research task known as a spike, so the situation you describe shouldn't arise unless the team thought that it was most efficient for multiple languages to be used, and if this is what the team thinks is best they should be trusted with the decision, it's their area of expertise after all. The inverse of this approach is to mandate which technologies are allowed. Unfortunately whenever I've worked in this kind of environment the “allowed technologies” list is always out of date and enforcing it leads to devalued, unempowered, frustrated developers with lower productivity and ultimately competative disadvantage.
  46. Off topic ?[ Go to top ]

    I really don't want to be responsible dragging this thread off topic any further (especially after Artem and Paul have done such a good job of bringing it back on track), but I feel that a couple of your comments are too important to go unaddressed.

    Even if developers take the time to learn FOTM technology, do you really want them to start using them - new and relatively unknown - in mission-critical systems instead of tried and tested technology they have more experience in?...

    What if developer A implements a module in Haskell and developer B implements theirs in Eiffel; should developer C, who prefers C# have to learn these two languages as well if he ends up maintaining their code?)

    The problem here is lack of peer review. I choose to work in agile teams that practice pair programming. This ensures that every decision that's made has been reviewed by at least one colleague. Medium level decisions are usually aired in the daily stand-up, bigger decisions discussed in a timeout and unknown quantities de-risked through a research task known as a spike, so the situation you describe shouldn't arise unless the team thought that it was most efficient for multiple languages to be used, and if this is what the team thinks is best they should be trusted with the decision, it's their area of expertise after all. The inverse of this approach is to mandate which technologies are allowed. Unfortunately whenever I've worked in this kind of environment the “allowed technologies” list is always out of date and enforcing it leads to devalued, unempowered, frustrated developers with lower productivity and ultimately competative disadvantage.
    ... if this is what the team thinks is best they should be trusted with the decision, it's their area of expertise after all ... What is their area of expertise ? Programming languages ? If that were the only important factor I would agree with this statement - but it's not the only important factor. What OTHER teams in the organization think is also important, wouldn't you agree ? After all, they will have to maintain the work ouf your team some day. And what the organization as a whole needs is definitely not the area of expertise of a software development team, as we have demonstrated over and over again. This isn't a nit - it's about the essential questions of this thread. Large companies cannot afford to let each developer follow his own path and introduce his own preferred technologies.
  47. Refactoring in dynamic languages[ Go to top ]

    To correctly refactor this code in you need to know if the functions f1 and f2 are called with instances of class C. Since the IDE can see the code base, the IDE can try to infer the type of the o parameter from the usages of f1. Exposing this information to developers would be useful, apart from use in refactoring. If the IDE does this well, then the dynamic language would save typing and still get the benefits. What are refactoring tools in Haskell like? Haskell code mostly, seems to uses inferred types. (I am not a professional Haskell programmer)
  48. Re: IDE support[ Go to top ]

    You forget an important point: with dynamically typed languages, you lose a lot of automatic refactorings.
    What I immediately miss when coding in a language without great IDE support is a way to quickly navigate through code and discover APIs. Google is not the greatest replacement for documentation hovers, jumping to implementations, viewing hierarchy trees, etc. And the fact that programmers like to be terse and implement their own quasi DSLs when using dynamic languages is as often a hindrance as it helps understanding code quickly. A lot can probably be done by developing smart IDEs for dynamic languages, but the dynamic nature limits the possibilities. Also, the gung-ho attitude towards IDEs in the dynamic languages camp (IDEs are for losers) doesn't help much. I'm not putting this down as a general case, but I had the funniest experience a while back when I talked to a dynamic language fan, who swore by emacs. A couple of hours after our meeting I realized that he typed everything with two fingers. Incredible :-)
  49. Re: IDE support[ Go to top ]

    With Tests/Specs anything is possible. If you believe in a test first programming style, then the only difference between dynamic versus static, is that dynamic requires less code, and static gives you code completion. With the latest IDEs that you mention, you can get code completion with a dynamic language too.
    If all an IDE could do was code completion, I'd still be using vi/emacs. I was doing TDD way before I ever even considered using an IDE. I found IDE's pretty much useless until Intellij came out with its refactoring capabilities way back in 2002. My productivity rose 5-10 times once I had the power of modern IDEs. Using Intellij + refactoring allows me to easily rename classes, move methods around. Delete fields, methods, classes, etc. etc. etc. I just never saw how Ruby + an IDE could ever refactor as *reliably* as Java + an IDE. Thus, IMO, any productivity gains you gained initially with Ruby (or Python or whatever) would be lost over the software lifecycle. *Reliably* is the key word here. Sure, a RubyIDE could guess where to refactor, but without the type system, could it reliably refactor? So, I'll rephrase my question: how does Ruby/Rails + Intellij or netbeans refactoring capabilities compare with their Java equivalents? -- Bill Burke http://bill.burkecentral.com
  50. Re: IDE support[ Go to top ]

    I just never saw how Ruby + an IDE could ever refactor as *reliably* as Java + an IDE.
    It's simply not possible, by definition. Once the type information is lost, an automated tool loses its ability to guarantee changes that preserve behavior, so they have to ask the user. For small cases, I can possibly tolerate the IDE asking me 'Rename "name" to "firstName"?' a few times, but I can't even imagine how painful (let alone dangerous) it must be when your project is several hundreds of thousands of lines big... -- Cedric
  51. Java can be dynamic[ Go to top ]

    For small cases, I can possibly tolerate the IDE asking me 'Rename "name" to "firstName"?' a few times, but I can't even imagine how painful (let alone dangerous) it must be when your project is several hundreds of thousands of lines big...

    --
    Cedric
    I agreed totally. Strong type + IDE even helps me if I'm the only one working on a small project. Why? Because I have to deal with large number of external APIs and I don't see any language can get away from that. I can easily learn a new API framework because I just need to understand its architecture and design but not boiling down too much into the detail. And even for my own code, I don't want to memorize all the exact names I have created. I don't want to take a spelling test every time I write codes. Unit tests are nice but they are actually much harder to write correctly than the code itself because of the need to set up correct data and consequently nobody/team I have met actually spend any serious efforts on writing good unit tests; most unit tests were never actually runnable again after a month or two and nobody bothered to fix the tests either. Just remember the human nature: if you don't enjoy doing it and don't have to do it, then it won't be done (correctly.) Java is quite dynamic already in the sense for supporting meta programming with its reflection, bean, annotation and APT facilities. In fact, people started abusing the dynamic features of Java in the last decade since XML has become popular. And now there is the surge attempting to add pure dynamic/scripting language. These efforts will only destroy the quality and integrity of the Java-based software down the road.
  52. Re: IDE support[ Go to top ]

    If you've ever done a massive refactor changing code all over the place with the luxury of runnning your Tests/Specs to get that comforting green bar you would know what I mean.
    After a massive refactory your tests become completely useless. You need to put your hand also in your tests, loosing your sense of security. Massive refactory doesn't only refactor internal state of your software layers..but also interfaces between components of your application. In this situation tests become to fail, because the contracts are changed. If not, unit tests are the best choice. Otherwise maybe they are still the best choice but there isn't any luxury on running them. Some other minor refactoring like changing method names, or moving a method into another class, etc...are much better if you IDE can help you in such boring task. Sometimes heppens that I change tons of file with a simple click thanks to Eclipse. I don't think I would have changed that public method name If I have to put my hands on a lot of files and its test cases. Thanks to god I can use IDE.
  53. Re: IDE support[ Go to top ]

    After a massive refactory your tests become completely useless
    Sorry, I should say: many tests need to be refactored etc....they are not completely useless ;)
  54. Re: IDE support[ Go to top ]


    If you've ever done a massive refactor changing code all over the place with the luxury of runnning your Tests/Specs to get that comforting green bar you would know what I mean.


    After a massive refactory your tests become completely useless. You need to put your hand also in your tests, loosing your sense of security.
    Massive refactory doesn't only refactor internal state of your software layers..but also interfaces between components of your application. In this situation tests become to fail, because the contracts are changed.
    If not, unit tests are the best choice. Otherwise maybe they are still the best choice but there isn't any luxury on running them.

    Some other minor refactoring like changing method names, or moving a method into another class, etc...are much better if you IDE can help you in such boring task.

    Sometimes heppens that I change tons of file with a simple click thanks to Eclipse. I don't think I would have changed that public method name If I have to put my hands on a lot of files and its test cases.

    Thanks to god I can use IDE.
    You do a big refactor in small steps, one small refactor at a time, running your tests as you go. No one is telling you to give up your Eclipse or Java. I was responding to a post from some one who was interested in knowing about something else. Paul
  55. Re: IDE support[ Go to top ]

    You do a big refactor in small steps, one small refactor at a time, running your tests as you go.

    No one is telling you to give up your Eclipse or Java. I was responding to a post from some one who was interested in knowing about something else.

    Paul
    That's ok, step by step. There is no big refactor that can be done with a click throught Eclipse. Anyway, also as a dynamic language supporter, you can't say that IDEs are useless. Some refactors simply are much and much better done if you have a good IDE. They are simple refactors, but can interest tons of file and lines of source code. In this condition who can prefer runningf unit tests + fix bugs, instead of a simple click? Too ofter dynamic language fans think that if something can't be done for their language (a good IDE) then it is clearly useless. This is ridicolous.
  56. Re: IDE support[ Go to top ]


    You do a big refactor in small steps, one small refactor at a time, running your tests as you go.

    No one is telling you to give up your Eclipse or Java. I was responding to a post from some one who was interested in knowing about something else.

    Paul


    That's ok, step by step. There is no big refactor that can be done with a click throught Eclipse.

    Anyway, also as a dynamic language supporter, you can't say that IDEs are useless. Some refactors simply are much and much better done if you have a good IDE.
    They are simple refactors, but can interest tons of file and lines of source code. In this condition who can prefer runningf unit tests + fix bugs, instead of a simple click?

    Too ofter dynamic language fans think that if something can't be done for their language (a good IDE) then it is clearly useless. This is ridicolous.
    Alberto, Where are you going with this? Languages are just tools. Saying that dynamic languages can be used for large programs, doesn't mean that IDEs aren't valuable also. Do you know that your Eclipse IDE is based on Smalltalk? The guys who wrote VisualAge for Smalltalk took the Smalltalk IDE and applied the same ideas to Java. FUD, and ignorance, when will it end? Paul.
  57. Re: IDE support[ Go to top ]

    Do you know that your Eclipse IDE is based on Smalltalk? The guys who wrote VisualAge for Smalltalk took the Smalltalk IDE and applied the same ideas to Java.

    FUD, and ignorance, when will it end?
    But that does not prove the Smalltalk implementation was successful. The idea of content assist could well be invented in the smalltalk environment, just like the first editor may be written in assembly or Visual J++ was written in C/C++ did not prove C++ being better. If anything, it proved you need content assist in smalltalk too. The fact that they had to re-implement the same idea in Java may indicate that the original one was not that good. (Though I would not jump the gun to say it is the proof as someone may.) For me, my question is that whether of not the content assist/refactoring support in this and other Smalltalk IDE, regardless what it is written at, can be as accurate as Java? I used Aptana Eclipse plugin for JavaScript; while they have done a good job with content assist, it is just not as precise as I want and I have to look up my JS reference all the time. (For JS, I have no choice because HTML uses JS and GWT is not popular yet in most projects. I found GWT make JS programming much easier; I do not to deal with small subtle spelling/naming errors.)
  58. Re: IDE support[ Go to top ]

    Type errors are only one amongst many type of errors possible in code. For safety and scalability I fine that TDD/BDD is the most powerful tool I've got in my armory. If you've ever done a massive refactor changing code all over the place with the luxury of runnning your Tests/Specs to get that comforting green bar you would know what I mean.

    Without Tests/Specs, I would never consider a big refactor even when it was needed, and entropy would soon kick in and limit the size/functionality of my code (I am assuming this is what people mean by scalability here).
    TDD is great and should be practiced in most projects, but I disagree that it takes care of all type related issues. Error detection with TDD is only as good as your tests. Compilers and types are there to enforce most type related issues and guarantee that they won't effect you at runtime (most, of course if you're explicitly casting, there could be issues). With that, I think that it's ridiculous to write comprehensive test suites to test type safety, if it comes for free with a strong type compiler. I think dynamic languages have their place, but they'll never replace strongly typed languages. I think the best balance can be reached through languages like Scala, AS3, etc... These languages allow you to use and mix dynamic and static types when appropriate. A good developer can always make a tradeoff while developing and use dynamic typing sparingly when beneficial. Ilya
  59. Re: IDE support[ Go to top ]

    Type errors are only one amongst many type of errors possible in code. For safety and scalability I fine that TDD/BDD is the most powerful tool I've got in my armory. If you've ever done a massive refactor changing code all over the place with the luxury of runnning your Tests/Specs to get that comforting green bar you would know what I mean.

    Without Tests/Specs, I would never consider a big refactor even when it was needed, and entropy would soon kick in and limit the size/functionality of my code (I am assuming this is what people mean by scalability here).


    TDD is great and should be practiced in most projects, but I disagree that it takes care of all type related issues. Error detection with TDD is only as good as your tests. Compilers and types are there to enforce most type related issues and guarantee that they won't effect you at runtime (most, of course if you're explicitly casting, there could be issues). With that, I think that it's ridiculous to write comprehensive test suites to test type safety, if it comes for free with a strong type compiler.

    I think dynamic languages have their place, but they'll never replace strongly typed languages. I think the best balance can be reached through languages like Scala, AS3, etc... These languages allow you to use and mix dynamic and static types when appropriate. A good developer can always make a tradeoff while developing and use dynamic typing sparingly when beneficial.

    Ilya
    IIya, I understand your point of view, but have you written a large program in a dynamic language? Do you know how to program well in a dynamic language. If the answer is no, then I don't think you are qualified to comment. People who have programmed in both like Dave Thomas, say pretty much the same as me. They are different, yes, but sweeping statements like yours are just false. I gave a link to Open Croquet above that proves this. Paul.
  60. Re: IDE support[ Go to top ]

    Paul yes I have. I've programmed in Perl for many years before coming over to Java, so I think I'm more than qualified. If your argument is that ruby as a language is cleaner and better than perl, I must agree. But the dynamic nature and limitations of the language still stands. What you should be asking, is what large enterprise systems Dave Thomas has developed, other than writing pretty decent books. You know that I'm usually very defensive of dynamic languages on TSS. I hate when people discount them as viable platforms for software development. But I must agree that in various circumstances they just don't provide the facilities that we're enjoy in static typed systems. We have developed and maintained a relatively large EDC application for biotech for years and I can't recount the amount of times we've been bitten in the ass by lack of type safety. I also must admit that we haven't practiced test driven development as good as we probably should have, but again that doesn't discount the fact that you must write type safety tests which come for free with a statically typed language. Here is a good article about dynamic vs. static type language debates... http://www.hacknot.info/hacknot/action/showEntry?eid=93 Ilya
  61. Re: IDE support[ Go to top ]

    Paul yes I have. I've programmed in Perl for many years before coming over to Java, so I think I'm more than qualified. If your argument is that ruby as a language is cleaner and better than perl, I must agree. But the dynamic nature and limitations of the language still stands. What you should be asking, is what large enterprise systems Dave Thomas has developed, other than writing pretty decent books.

    You know that I'm usually very defensive of dynamic languages on TSS. I hate when people discount them as viable platforms for software development. But I must agree that in various circumstances they just don't provide the facilities that we're enjoy in static typed systems. We have developed and maintained a relatively large EDC application for biotech for years and I can't recount the amount of times we've been bitten in the ass by lack of type safety. I also must admit that we haven't practiced test driven development as good as we probably should have, but again that doesn't discount the fact that you must write type safety tests which come for free with a statically typed language.

    Here is a good article about dynamic vs. static type language debates...

    http://www.hacknot.info/hacknot/action/showEntry?eid=93

    Ilya
    Hi IIya, My views are based on hands-on experience, working with people who are skilled with both dynamic and static languages. TDD is more important with a dynamic language, so it is no surprise that TDD was invented for Smalltalk by Kent Beck. In the TDD community there are many programmers who come from a dynamic programming background, and for them a dynamic language is no handicap when it comes to large systems. In many ways a dynamic language is a bonus. Think of the world wide web, this is a late bound system where the code and interfaces are changing all the time. I think the web has been totally re-written at least once with no down time. This is impossible with a static system. To focus on the tool and ignore the workman is the mistake that is being made here. For a team with the right skills, a dynamic language is perfectly safe and applicable for large systems. Just ask anyone who has worked on a large system in a language like Lisp, Smalltalk, etc. Paul.
  62. Re: IDE support[ Go to top ]

    Think of the world wide web, this is a late bound system where the code and interfaces are changing all the time.
    A lot of the web has been built and written with statically typed languages (Java, C++ and C#). It's not clear to me that the portion of the web written with dynamically typed languages dwarfs the other part.
    I think the web has been totally re-written at least once with no down time. This is impossible with a static system.
    Plenty of systems built on statically typed languages are restarted every day with zero downtime, this has nothing to do with the programming language.
    Just ask anyone who has worked on a large system in a language like Lisp, Smalltalk, etc.
    Aren't they all dead by now? :-) -- Cedric
  63. Re: IDE support[ Go to top ]

    Well put, I can't disagree that a good programmer can do wonders in dynamic or static type system. I just think there are tradeoffs to both. There are times I'm programming in java and wish I could rewrite code on the fly and use the late binding techniques for dynamic code/type generation. There are other times when I'm doing something in perl or ruby and wish I had static types so I can define interfaces that others can use without having to read documentation and pass in hash structures. In dynamic languages, although object oriented, the benefit of class structures become moot especially for type safety, so you might as well use hashes as parameters/types. I find that more tedious to work with. Say if my method requires particular parameters, there is no way to communicate this without having to check their type validity for each method. This comes for free with static typed languages. Of course, static typing is not a replacement for good documentation and test suites, I just feel more comfortable working with it and although many say this about dynamic languages, static types tend to more naturally express what my intentions are. Ilya
  64. Re: IDE support[ Go to top ]

    Well put, I can't disagree that a good programmer can do wonders in dynamic or static type system. I just think there are tradeoffs to both. There are times I'm programming in java and wish I could rewrite code on the fly and use the late binding techniques for dynamic code/type generation. There are other times when I'm doing something in perl or ruby and wish I had static types so I can define interfaces that others can use without having to read documentation and pass in hash structures. In dynamic languages, although object oriented, the benefit of class structures become moot especially for type safety, so you might as well use hashes as parameters/types. I find that more tedious to work with. Say if my method requires particular parameters, there is no way to communicate this without having to check their type validity for each method. This comes for free with static typed languages. Of course, static typing is not a replacement for good documentation and test suites, I just feel more comfortable working with it and although many say this about dynamic languages, static types tend to more naturally express what my intentions are.

    Ilya
    Hi Ilya, You mention a number of the difficulties faced by static programmers coming to grips with dynamic languages. You will feel more comfortable with a static language because I guess it suites your programming style (you started out on static languages first right?). With a dynamic language you need a lot more feedback, you need to run your code a lot more often and take smaller steps. This is the price you pay. The upside is a massive reduction in coupling, less code, and a much shorter compile/deploy cycle. Coupling and cohesion are massive concepts in software design. By reducing coupling by not needing to know the implementation (Type) of objects you can massively improve the flexibility of your system. This is why generics which expose implementation details don't work well in OO/polymorphic systems where the purpose is to hide as much information as possible. In a dynamic language Objects communicate only through messages, hiding all implementation. There is a good article on this on InfoQ (using C# to make the point) explaining why Generics don't work well with OO. You mention the need for documentation. There are a number of dynamic programming idioms that mitigate the need for manifest typing as a documentation technique. For example, naming parameters after their type is a common practice. The use of keyword messages as used in Smalltalk is useful here too (you can fake keyword messages with a hashmap in Ruby) There are pluses and minuses with both static and dynamic approaches. Type inference is an approach to static typing that tries to offer the best of both worlds. Take a look at the language Boo, where type inference is used, and duck typing is optional. Claiming that you can't write large programs with a dynamic language though, as other have claimed, is a nonsense. Paul.
  65. Re: IDE support[ Go to top ]

    The upside is a massive reduction in coupling, less code, and a much shorter compile/deploy cycle.
    Java IDEs like Eclipse hilight your error as you go and compile instantly when you save. Debuggers pick up change instantly in many cases. Of course, JVM still needs to be a bit more flexible. Even C++ IDE and debugger can do some of these on-the-fly compile now.
    Coupling and cohesion are massive concepts in software design. By reducing coupling by not needing to know the implementation (Type) of objects you can massively improve the flexibility of your system.
    Right, it is and it remains a massive concepts still.
    There are a number of dynamic programming idioms that mitigate the need for manifest typing as a documentation technique. For example, naming parameters after their type is a common practice.
    That's known as the Hungarian notation and even Microsoft is abandoning it in C#. A good duct-tape solution for dynamic language and I used it in my JS codes. It just proves that (1) parameters and vars have types (2) you do need to communicate the types (3) once you stick an 'i' in front of it, you'd better make sure you don't change its meaning to an 'f' or confusion and errors abound.
  66. Re: IDE support[ Go to top ]

    still.

    There are a number of dynamic programming idioms that mitigate the need for manifest typing as a documentation technique. For example, naming parameters after their type is a common practice.


    That's known as the Hungarian notation and even Microsoft is abandoning it in C#. A good duct-tape solution for dynamic language and I used it in my JS codes.

    It just proves that (1) parameters and vars have types (2) you do need to communicate the types (3) once you stick an 'i' in front of it, you'd better make sure you don't change its meaning to an 'f' or confusion and errors abound.
    I am not talking hungaring notation. Is "aBook" to indicate a parameter that satisfies the "Book" protocol hungarian notation? This is the problem with debating this stuff with (some) Java people. They just stick to what they know and they refuse to come out their safety zone. Paul.
  67. Re: IDE support[ Go to top ]

    I am not talking hungaring notation. Is "aBook" to indicate a parameter that satisfies the "Book" protocol hungarian notation?
    Yes, that's exactly the definition of Hungarian notation. Using this kind of convention is basically trying to emulate static typing except that the compiler is no longer there to help you.
    This is the problem with debating this stuff with (some) Java people. They just stick to what they know and they refuse to come out their safety zone.
    Paul, can you please stop with the name calling and stick to the technical stuff? Thanks. -- Cedric
  68. Re: IDE support[ Go to top ]

    This is the problem with debating this stuff with (some) Java people. They just stick to what they know and they refuse to come out their safety zone.

    Paul, can you please stop with the name calling and stick to the technical stuff?

    Thanks.

    --
    Cedric
    Hi Cedric, No names here, merely an observation. Are you really interested in technical insight? I find it incredulous that you choose to right of a whole programming paradigm where you have no experience and little understanding, based on nothing more than your own speculation. There is more than one way to skin a cat and manifest typing is not the only way. I have identified a number of large dynamic language programs, all of which have been successfully maintained over a large number of years by a large number of programmers. Examples like AutoCAD and Emacs just to name a couple. Please state you examples of large software projects that have failed because they were written in a dynamic language. If you have no evidence and no direct experience then you are spreading FUD. And it is this that I object to. Paul.
  69. Re: IDE support[ Go to top ]

    This is the problem with debating this stuff with (some) Java people. They just stick to what they know and they refuse to come out their safety zone.

    Paul, can you please stop with the name calling and stick to the technical stuff?

    Thanks.

    --
    Cedric

    Hi Cedric,

    No names here, merely an observation. Are you really interested in technical insight? I find it incredulous that you choose to right of a whole programming paradigm where you have no experience and little understanding, based on nothing more than your own speculation.

    There is more than one way to skin a cat and manifest typing is not the only way. I have identified a number of large dynamic language programs, all of which have been successfully maintained over a large number of years by a large number of programmers. Examples like AutoCAD and Emacs just to name a couple.

    Please state you examples of large software projects that have failed because they were written in a dynamic language. If you have no evidence and no direct experience then you are spreading FUD. And it is this that I object to.

    Paul.
    I have worked on large projects with dynamic languages and Java. Generally, I find the Java projects to be more maintainable because of the strong typing. That said I have seen crappy Java projects and really well written dynamic language projects so it is more of a trend than a rule. Am I spreading FUD? Does everyone that has a different opinion than yours spreading FUD?
  70. Re: IDE support[ Go to top ]

    Probably a grossly inaccurate statement but it seems most people that like dynamic languages think they are more productive because they skip some typing by ommitting type declarations. Just like some of the new java constructs like import static, or for each loops, they are only there to save people who are too lazy to type a few extra characters.
  71. Number of characters to type[ Go to top ]

    Probably a grossly inaccurate statement but it seems most people that like dynamic languages think they are more productive because they skip some typing by ommitting type declarations.

    Just like some of the new java constructs like import static, or for each loops, they are only there to save people who are too lazy to type a few extra characters.
    I agree that if the point was the number of characters to write it would be stupid. Therefore, it isn't the number of characters to write. Instead, it is the amount of noise in the program, and how that get in the way of reading and maintaining the program *in the small*, ie inside each module. (To my mind, the best tradeoff in programming would probably be some sort explicit declarations at the edge of a reasonably large scale module, and implicit/inferred/dynamic typing on the inside of the module. I haven't seen this implemented anywhere, though.)
    Eivind.
  72. Re: Number of characters to type[ Go to top ]

    (To my mind, the best tradeoff in programming would probably be some sort explicit declarations at the edge of a reasonably large scale module, and implicit/inferred/dynamic typing on the inside of the module. I haven't seen this implemented anywhere, though.)


    Eivind.
    I think what you mean is a pluggable type system with optional manifest type annotations. If so it's been done: http://www.strongtalk.org/ Paul.
  73. Re: Number of characters to type[ Go to top ]

    (To my mind, the best tradeoff in programming would probably be some sort explicit declarations at the edge of a reasonably large scale module, and implicit/inferred/dynamic typing on the inside of the module. I haven't seen this implemented anywhere, though.)


    Eivind.
    Agreed, and you're actually talking about Groovy, which has two great features: - It lets me declare a type for my variables if I want to (most of the time, I do). - It uses type inference wherever possible. To me, this is the best of both worlds, and it's a pity that neither Ruby nor Python will let me do either of these things. -- Cedric
  74. Re: IDE support[ Go to top ]

    I have worked on large projects with dynamic languages and Java. Generally, I find the Java projects to be more maintainable because of the strong typing. That said I have seen crappy Java projects and really well written dynamic language projects so it is more of a trend than a rule.

    Am I spreading FUD? Does everyone that has a different opinion than yours spreading FUD?
    No, this is a valid opinion, and a long way from saying that dynamic languages don't scale. As I said in one of my previous posts, the most important issue is the team. Good teams can deliver large projects with most languages (poor teams will fail). The real discussion is where and when a given language is most appropriate. But given that this is TSS we never get there... Paul.
  75. Re: IDE support[ Go to top ]

    As I said in one of my previous posts, the most important issue is the team. Good teams can deliver large projects with most languages (poor teams will fail).
    Absolutely right! I also know of teams writing complex and successful programs in assembly language -- after all it is the most efficient as well as the most dynamic language out there. So let's just stick with assembly and hire the right team. Yeah, at the dawn of computer age, all programmers had a Ph.D. in math or physics. I shouldn't be qualified working in this field, so I will submit a job application to McDonald's tomorrow.
  76. Re: IDE support[ Go to top ]

    The real discussion is where and when a given language is most appropriate. But given that this is TSS we never get there...
    That's an easy escape... Originally the questions was if DL scale with large projects... Simply said: yes as you quote several projects. But by looking more in details and if you consider large projects with third parties extensions and large community (in terms of developers and plugins), I'm not so sure. Maybe AutoCAD has a large community but I doubt about Emacs. There is not doubt that you can write a large project with *any* language but do you have examples of evolving a project and maintaining APIs for third parties? I'd say that DL are fine until you need to introduce "outside world" APIs... That's still a large chunck of software today though... Erik.
  77. Re: IDE support[ Go to top ]

    The real discussion is where and when a given language is most appropriate. But given that this is TSS we never get there...


    That's an easy escape... Originally the questions was if DL scale with large projects... Simply said: yes as you quote several projects. But by looking more in details and if you consider large projects with third parties extensions and large community (in terms of developers and plugins), I'm not so sure. Maybe AutoCAD has a large community but I doubt about Emacs.
    There is not doubt that you can write a large project with *any* language but do you have examples of evolving a project and maintaining APIs for third parties?
    I'd say that DL are fine until you need to introduce "outside world" APIs... That's still a large chunck of software today though...

    Erik.
    Let me elaborate more. With a dynamic language you loose the compiler as a friend. So you may want to change your coding practices and get familiar with some new friends. Test driven development or behaviour driven development are two new friends. Some would argue that these things are important anyway, but with a DL I would say even more so. No compiler, no manifest types may also require cleaner self documenting code as a friend, how do you get there? Well many eyes over the code help. Common code ownership where the code is read several times by several people, all who have the right to clean it up helps, so many real friends checking your code is something you can do. Programming in pairs so that you have continuous code review helps too, so your programming partner becomes your best friend. You can do this too. With intelligent friends like these you are likely to write very clean code. I have worked with Smalltlakers in the past and they tend to write very clean code, because they are use to not relying on the compiler. Some would argue that a compiler is a pretty dumb friend and can end up being a straight jacket especially if you want to write expressive OO code. This is why DI framework like Spring are used to loosen the straight jacket of the compiler. I would not suggest a team of weak programmers writing mediocre code switch to a DL. But for teams who strive for excellence and produce good clean code, and have good QA practices, then a DL opens the door to more flexible systems, increased productivity and potentially competitive advantage, and this is what it is all about. Paul.
  78. Re: IDE support[ Go to top ]

    I would not suggest a team of weak programmers writing mediocre code switch to a DL. But for teams who strive for excellence and produce good clean code, and have good QA practices, then a DL opens the door to more flexible systems, increased productivity and potentially competitive advantage, and this is what it is all about.
    +1
  79. Test coverage[ Go to top ]

    Paul, Obviously, compiler affords us 100% code coverage. Based on your experience, what level of coverage do you recommend as a substitution for this with respect to the following types of coverage? Statement coverage Condition coverage Path coverage From my personal experience all of the above have to be very close to 100% in order to assure that a program in dynamic language is correct with respect to object types. With regard to achieving the levels of coverage that you recommend, what impact would you think they will have on the team productivity both directly (time spent writing tests)/(complete time to implement a feature) and indirectly time maintaining the tests versus time saved by not having regressions. Artem
  80. Re: Test coverage[ Go to top ]

    Paul,

    Obviously, compiler affords us 100% code coverage.

    Based on your experience, what level of coverage do you recommend as a substitution for this with respect to the following types of coverage?

    Statement coverage
    Condition coverage
    Path coverage
    ...
    Hi Artem, Good question, well almost. The most important thing to cover with your tests is the design requirements. TDD says that your tests should read like a complete design specification. So I would say you need 100% design specification coverage. This is not the same as 100% code coverage however. Test first patterns like triangulation means that in most situations 100% code coverage isn't necessary (triangulation is where you take three data points test for those and assume everything in between is linear). In terms of code coverage I've never bothered to use a code coverage tool with dynamic code. With static code I have found that 70-80% code coverage is normally adequate, and I find that I don't write anymore tests for dynamic code then I do for static code. If you look at BDD it takes the idea of "behaviour specification" even further. Tools like RBehave allow you to specify user requirements in a way that can be directly validated as well. Then we have the whole area of functional tests like WATIR and Fitness. When you start thinking this way (testing for correct behaviour and not relying on the compiler) you begin to realise that using the compiler to test for type errors is rather limited and doesn't provide much safety at all. Incidents like the Ariane 5 rocket that blew up on launch disastrously despite being written in the extremely "type safe" language Ada goes to make the point (IMO). A type safe program is not the same as a correct program (incidentally no programming language is completely statically type safe). The real bugs that are likely to lurk in your code will have more to do with flaws and gaps in your thinking, not type errors and your compiler will not catch these. Behaviour verification testing like TDD/BDD and Functional testing (RBehave, WATIR, Fitness etc) should (well most of the time). Your experience is interesting. Are you programming test first? Or writing the tests after writing the code? Paul.
  81. Re: Test coverage[ Go to top ]

    Paul, The project on which I worked with dynamic language was not using any type of test driven development and has suffered from poor design and development practices. It had QA done via manual testing based on the test scenarios derived from the use cases. The use cases were medium complexity but the application had to deal with a large variation in input data and parameters. It would have benefited most from pairwise or exhaustive testing. At the end there were very many type problems that would have been caught by a compiler. You are stating that 70% to 80% statement coverage by behavior driven tests would identify most of the type issues. This is a very interesting statement since 80% statement coverage usually translates in a much lower condition and path coverage. Does anybody else have an experience with this and can comment? Can somebody else support or disprove this statement? Artem
  82. Re: Test coverage[ Go to top ]

    Paul,

    The project on which I worked with dynamic language was not using any type of test driven development... You are stating that 70% to 80% statement coverage by behavior driven tests would identify most of the type issues
    No I am saying that 70-80% code coverage is sufficient to ensure correct behavior (dynamic or static language). For type errors I would say that all you need to do is run the code. Dynamic code with type errors and typos tends to blow up just by running the "happy path" in my experience, and all you need to do is walk through the stack trace to find where, it is usually obvious. I guessed that your code wasn't written using TDD/BDD. Like you I am interested in the experiences of others. Paul.
  83. Re: Test coverage[ Go to top ]

    No I am saying that 70-80% code coverage is sufficient to ensure correct behavior (dynamic or static language).
    % of methods? % of statements? % of code paths? If code paths, does that include exceptions?
  84. Re: Test coverage[ Go to top ]

    No I am saying that 70-80% code coverage is sufficient to ensure correct behavior (dynamic or static language).


    % of methods?

    % of statements?

    % of code paths?

    If code paths, does that include exceptions?
    Hi Erik, 100% of the design specification. The next question is what is the design specification? Here is a Ruby example for a Stack object using Rspec:
    equire File.join(File.dirname(__FILE__), *%w[spec_helper]) shared_examples_for "non-empty Stack" do it { @stack.should_not be_empty } it "should return the top item when sent #peek" do @stack.peek.should == @last_item_added end it "should NOT remove the top item when sent #peek" do @stack.peek.should == @last_item_added @stack.peek.should == @last_item_added end it "should return the top item when sent #pop" do @stack.pop.should == @last_item_added end it "should remove the top item when sent #pop" do @stack.pop.should == @last_item_added unless @stack.empty? @stack.pop.should_not == @last_item_added end end end shared_examples_for "non-full Stack" do it { @stack.should_not be_full } it "should add to the top when sent #push" do @stack.push "newly added top item" @stack.peek.should == "newly added top item" end end
    This still begs the question, how do we know that the specification is adequate or complete? Well this is where tools take a back seat and TDD/BDD competence and experience kicks in. Ron Jefferies has implemented his bowling game example in a number of programing languages using TDD. You can find them all on his website. As you can see the tests for both dynamic and static languages (and functional languages) are very much the same. Paul.
  85. Re: Test coverage[ Go to top ]

    This still begs the question, how do we know that the specification is adequate or complete? Well this is where tools take a back seat and TDD/BDD competence and experience kicks in.
    It also begs the question of "how much unspecified behavior is contained in the code?" and "when do objective, quantitative measures end and subjective trust begin?" Basically what you're saying is that objective measures do not matter. In many cases, I agree, or that they are more trouble than they are worth. But I would not agree for a system with stringent safety or security requirements.
  86. Re: Test coverage[ Go to top ]

    But I would not agree for a system with stringent safety or security requirements.
    Yes I forgot - Formal Methods. What fun, Predicate Calculus and pure functional programming with no side effects :) This is the fallacy of relying on tools. In the end it is all subjective and open to interpretation. All except the most simplest systems have requirements that are subjective. All designs of any complexity are subjective. The whole idea of "correctness" is subjective and open to interpretation IMO. I guess thats why their will always be jobs for human programmers and why we won't ever be able to write programs to replace ourselves :^). Paul.
  87. Re: Test coverage[ Go to top ]

    Yes I forgot - Formal Methods. What fun, Predicate Calculus and pure functional programming with no side effects :)
    "Fun" is subjective. I think predicate calculus and pure functional programming are fun. I've personally found the core of predicate calculus simpler, more elegant, and easier to explain to non-software people than any programming language. Besides, weren't you the one advocating opening your mind and trying new things? I think there are a lot of people on both sides of this debate who could use to open their minds to the mathematical side of programming.
    This is the fallacy of relying on tools. In the end it is all subjective and open to interpretation. All except the most simplest systems have requirements that are subjective. All designs of any complexity are subjective. The whole idea of "correctness" is subjective and open to interpretation IMO.
    So we should all adopt the George W. Bush school of mathematics, because it's all subjective anyway? ;-) Pushing pieces of a problem out of the subjective realm and into an objective one that tools can handle frees your mind to focus on the remaining essence of the problem.
  88. Re: Test coverage[ Go to top ]

    Yes I forgot - Formal Methods. What fun, Predicate Calculus and pure functional programming with no side effects :)


    "Fun" is subjective. I think predicate calculus and pure functional programming are fun. I've personally found the core of predicate calculus simpler, more elegant, and easier to explain to non-software people than any programming language.

    Besides, weren't you the one advocating opening your mind and trying new things?

    I think there are a lot of people on both sides of this debate who could use to open their minds to the mathematical side of programming.

    This is the fallacy of relying on tools. In the end it is all subjective and open to interpretation. All except the most simplest systems have requirements that are subjective. All designs of any complexity are subjective. The whole idea of "correctness" is subjective and open to interpretation IMO.


    So we should all adopt the George W. Bush school of mathematics, because it's all subjective anyway? ;-)

    Pushing pieces of a problem out of the subjective realm and into an objective one that tools can handle frees your mind to focus on the remaining essence of the problem.
    Hi Erik, I was only joking! All I remember about Predicate Calculus at school is that an imperative program can not be proven correct. I'm open to most things including formal methods. The thing is though is that AFAIK Formal Methods are terribly difficult to do and very expensive in terms of time. Also most business problems are people related and have very little to do with logic (Is your customer logical?). I tend to agree with what is said on wikipedia. I don't think Formal Methods are or will ever be a Silver Bullet. Happy for others to do the research though :^). Paul.
  89. Re: Test coverage[ Go to top ]

    I was only joking! All I remember about Predicate Calculus at school is that an imperative program can not be proven correct. I'm open to most things including formal methods.
    I figured you might be...it's hard to tell over the internet. You are right, most imperative programs cannot be proven correct, although some can. Functional programs are better, but still generally unprovable...and even if they weren't you get into the issue of defining "correct." Also I think you are confusing predicate calculus with computational theory. What's more interesting is proving traits of programs. Static type checking proves type safety, and therefore eliminates a certain class of errors. The size of that class relative to to all the other classes of errors is situation dependent.
    The thing is though is that AFAIK Formal Methods are terribly difficult to do and very expensive in terms of time
    If we widen the definition of "formal methods" to its lay meaning, the question is "how formal?" Proving my program correct is infeasible. But proving traits of it is not. Personally, I find static type checking to be less work than tests, so if I want a piece of code to be very robust I prefer static typing. It's an engineering problem. You are pushing the complexity around until you find a place where it doesn't hurt too much.
    Also most business problems are people related and have very little to do with logic (Is your customer logical?).
    The more logical a process is, the more it can be automated. The more a process can be automated, the more efficient it can be. Just because an entire process can rarely be formalized (in the lay or mathematical sense), usually pieces of it can. Pushing on piece into logical formalism advances the frontier, exposing other pieces that can be formalized.
  90. Re: IDE support[ Go to top ]

    I would not suggest a team of weak programmers writing mediocre code switch to a DL. But for teams who strive for excellence and produce good clean code, and have good QA practices, then a DL opens the door to more flexible systems, increased productivity and potentially competitive advantage, and this is what it is all about.
    So, then you're saying that DLs per se will scale, but they won't scale in the real world. Because the real world is crammed to the rafters with weak programmers writing mediocre code. And if DLs only work for the best of the best teams, then they're not really applicable to the reality of the industry at large. I haven't seen anyone arguing that the programmer base is "getting smarter". The benefit of tooling and frameworks is that they capture practices and architecture and make them available to the weaker and less experienced programmers, thereby lifting their ability and productivity. Sometimes that knowledge transfer inherently limits the base platform, but the cost of that limitation is worthwhile because the higher level of utilization by more junior people is an overall benefit, despite the limitations. Protecting the developers from themselves HAS VALUE in the large. DLs tend to rely on developers not needing that safety net, and from that they gain extra power. So, with a core, senior team, a DL can dance on the head of a pin. But most teams are not like that, and that's just the plain truth of it.
  91. Re: IDE support[ Go to top ]

    I would not suggest a team of weak programmers writing mediocre code switch to a DL. But for teams who strive for excellence and produce good clean code, and have good QA practices, then a DL opens the door to more flexible systems, increased productivity and potentially competitive advantage, and this is what it is all about.


    So, then you're saying that DLs per se will scale, but they won't scale in the real world. Because the real world is crammed
    That might be the case were you work. Its not the case where I am. I guess thats why choice is a good thing :^). Paul.
  92. Re: IDE support[ Go to top ]

    I would not suggest a team of weak programmers writing mediocre code switch to a DL. But for teams who strive for excellence and produce good clean code, and have good QA practices, then a DL opens the door to more flexible systems, increased productivity and potentially competitive advantage, and this is what it is all about.


    So, then you're saying that DLs per se will scale, but they won't scale in the real world. Because the real world is crammed


    That might be the case were you work. Its not the case where I am. I guess thats why choice is a good thing :^).

    Paul.
    Quit hogging all the good people.
  93. Re: IDE support[ Go to top ]

    I would not suggest a team of weak programmers writing mediocre code switch to a DL. But for teams who strive for excellence and produce good clean code, and have good QA practices, then a DL opens the door to more flexible systems, increased productivity and potentially competitive advantage, and this is what it is all about.


    So, then you're saying that DLs per se will scale, but they won't scale in the real world. Because the real world is crammed


    That might be the case were you work. Its not the case where I am. I guess thats why choice is a good thing :^).

    Paul.

    Quit hogging all the good people.
    I'm not. Over the years we have had our fair share of graduates. Mediocre and crappy management leads to crappy programers IMO. If you value your people and focus on building their skills then most developers have the potential to be good developers. If you rather trust in vendors and their latest tools paying through the nose for licenses. Whilst at the same time hiring the cheapest people you can find and spend nothing on their development then you will end up with mediocrity. Crap programmers are made not born, but we are way of subject :^). Paul.
  94. Re: IDE support[ Go to top ]

    Quit hogging all the good people.


    I'm not.
    Oh, I know you are not. The comment was a mixture of humor, irony, criticism and whatever else.
    Over the years we have had our fair share of graduates.
    Not sure what that has to do with it. I have had graduates who are better, day one, that 20+ developers.
    Mediocre and crappy management leads to crappy programers
    Sometimes.
    IMO.
    Definitely YO.
    If you value your people and focus on building their skills then most developers have the potential to be good developers.
    I agree this is what you should do. I don't agree that it is most. I believe that most have the potential to be, at best, "average". But we should still try to build skills and then weed out the weak.
    If you rather trust in vendors and their latest tools paying through the nose for licenses. Whilst at the same time hiring the cheapest people you can find and spend nothing on their development then you will end up with mediocrity.
    Not sure what one has to do with the other. "Depending" on tools is not wise. Using them to your advantage is wise. Trusting humans not to be human is not wise.
    Crap programmers are made not born
    Yeah, I have never seen a baby program before. But I bet they are pretty crappy at it. :) But i think you are saying , based on your previous comments, that crappy programmers are crappy because they just don't know the right way. I would say there is some truth to that. But, as was said before, the "real world" - meaning all the people coding everywhere - is crammed full of people who shouldn't be.
    , but we are way of subject :^)
    If you are saying, we are way off the subject of this thread, I would beg to differ. And just so you don't think i am saying 100% No to DLs. I am not. They have a place. But i have been bitten horribly by late binding and so i am very hesitant to use it.
  95. Re: IDE support[ Go to top ]

    So, then you're saying that DLs per se will scale, but they won't scale in the real world. Because the real world is crammed


    That might be the case were you work. Its not the case where I am. I guess thats why choice is a good thing :^).

    Paul.
    Unless you are currently located on a different planet than Earth, we all live in the same real world. In this real world, as Will correctly points out, a big proportion of developers are, by definition, average. And since you admitted in your post earlier that DL's could only really be leveraged by very good developers, the conclusion is that DL's cannot really work in the real world. Very simple logic, should be easy to grasp for a functional guy like yourself :-) -- Cedric
  96. Re: IDE support[ Go to top ]

    Let me elaborate more. With a dynamic language you loose the compiler as a friend. So you may want to change your coding practices and get familiar with some new friends. Test driven development or behaviour driven development are two new friends. Some would argue that these things are important anyway, but with a DL I would say even more so. No compiler, no manifest types may also require cleaner self documenting code as a friend, how do you get there? Well many eyes over the code help. Common code ownership where the code is read several times by several people, all who have the right to clean it up helps, so many real friends checking your code is something you can do. Programming in pairs so that you have continuous code review helps too, so your programming partner becomes your best friend.
    What I find fascinating about this (accurate) description is that you are basically recommending to replace the compiler (an automated tool) with more humans (who are, by definition, much more prone to making mistakes than an automated tool). This doesn't seem like a very good proposition to me. As for your claim that working without types forces people to write cleaner code, I find it highly questionable. Code quality depends first and foremost on the programmer, not on the language, operating system, tool, IDE or framework used. -- Cedric
  97. Re: IDE support[ Go to top ]

    Code quality depends first and foremost on the programmer, not on the language, operating system, tool, IDE or framework used.

    --
    Cedric
    Hi Cedric, We agree on one thing at least :) Mark Nuttall, We basically agree too (although I tend to have a more optimistic view of the potential of people as they enter the work place). Where myself and you guys disagree is on how best to manage software development and how much to trust your people. I work as an Agile Coach, and Steve Cresswell who as responded earlier in this thread worked once on one of my teams. We both choose to work on Agile teams because the Agile tenet of valuing people over processes and tools really works. When I first met Steve he was skeptical. In fact on my first Agile project I was skeptical too. Once you see it working in practice though you start to question all your assumptions about people and their potential. I remember as a junior programmer being escorted to a booth and left on my own to produce my 100K lines of code by myself. A number of questions came to mind: 1. How will I improve? 2. Are the other guys here better than me? 3. Who will read my code other than me? 4. What do the others think about the quality of my work? 5. Am I working fast enough? 6. Am I good enough? 7. etc. In an Agile team all these anxieties go, and are replaced by support and hands-on mentorship from the rest of the team. It is not a new idea. In a law firm a junior lawyer will always work as an understudy to a team of senior lawyers. We learn by example and by doing. We "follow the master". By pairing with different people we learn different things. After a while your enthusiasm for learning takes off and you want to learn even more, so you go to Agile clubs and conferences and learn from (pair with) other people there. You become part of a learning culture. I have worked in companies in the past where the strategy department wouldn't bat an eye lid at buying in the latest buzz-whiz MQ messaging hub at the cost of thousands, but where managers would snare if they saw two programmers working at the same terminal learning from each other. I have also seen old members of staff hide information on how systems work and purposely hinder new/junior members of staff. Why? I believe this comes down to organisational culture. Don't get me wrong. The organisationals culture where I am isn't that different, but we have developed a team culture, which is supportive, trusting and believes in empowerment. Our team is the most successful in our organisation. I work in an "Agile bubble", where Agile values and principals prevail. Differences, and people. This is what this whole debate is about. If you feel you can trust your people then your tool choices change. I do not hope to convince you. I just wanted to point out that we are discussing a people issue not a technical one, and because of this different teams will make different choices. What is right for you and your team may not be right for me and mine. Paul.
  98. Re: IDE support[ Go to top ]

    Where myself and you guys disagree is on how best to manage software development and how much to trust your people.

    ...
    (I cut out the rest of the quote.) Paul, I don't think I disagree with what you said. I say the same thing. We should spend less on software and hardware [where we can and should] and spend more on people. Everything you said can be true even if one uses Java. I don't know how this differs if you use a DL. I trust people that have shown they can be trusted. Isn't that part of what mentoring is about? What do you do with people that, at some point, you realize they don't know what they are doing and never will? It seems you are saying (by your replies, comments, digs and etc here and on other threads) that if we are not using a DL, we are not trusting our people. And that somehow we are less as developers. And are not wise or good. Sure, I could [mainly] use a DL , but I would rather get a product out and have a reasonable chance of supporting it. And funding it. And spending more on good people. Funny how I have this same argument with others. But in those, I am in your shoes, and they mine. :)
  99. Re: IDE support[ Go to top ]

    Where myself and you guys disagree is on how best to manage software development and how much to trust your people.

    ...
    (I cut out the rest of the quote.)

    Paul, I don't think I disagree with what you said. I say the same thing. We should spend less on software and hardware [where we can and should] and spend more on people. Everything you said can be true even if one uses Java. I don't know how this differs if you use a DL.

    I trust people that have shown they can be trusted. Isn't that part of what mentoring is about? What do you do with people that, at some point, you realize they don't know what they are doing and never will?

    It seems you are saying (by your replies, comments, digs and etc here and on other threads) that if we are not using a DL, we are not trusting our people. And that somehow we are less as developers. And are not wise or good. Sure, I could [mainly] use a DL , but I would rather get a product out and have a reasonable chance of supporting it. And funding it. And spending more on good people.

    Funny how I have this same argument with others. But in those, I am in your shoes, and they mine. :)
    Hi Mark, I agree with everything you say here. I'm not pro DL or pro SL or pro any specific tool. I am pro people. What started me going was the idea that some how the compiler is more intelligent and trust worthy then the programmer. What do I do with programmers that don't make the cut, despite support and mentoring? Well I suggest that perhaps this isn't the right team for them and that we should go our separate ways. I haven't got that responsibility at the moment, but when I was a Manager this is what I did. Very often by the time we got to this stage they had worked out the same for themselves and where already looking for something new. I agree that everyone is not cut out to be a programmer in which case that individual should do themselves and their team a favour and move on. Regards, Paul.
  100. Re: IDE support[ Go to top ]

    What started me going was the idea that some how the compiler is more intelligent and trust worthy then the programmer.
    It isn't anymore than the programmer who wrote it. It can be considered "test" code. But that test code has been "tested" by many others. Who tests the test code you (me, them, etc) write(s)? Just something to think about. ;) Something to laugh about: I have the current VS.Net Magazine. One of the articles is about new features in VS.Net 2008. One of the features is that it will generate your test code. LOL.
  101. Re: IDE support[ Go to top ]

    Something to laugh about: I have the current VS.Net Magazine. One of the articles is about new features in VS.Net 2008. One of the features is that it will generate your test code. LOL.
    Hey, exactly like Rails! This has to be a good thing, right? -- Cedric
  102. Re: IDE support[ Go to top ]

    Something to laugh about: I have the current VS.Net Magazine. One of the articles is about new features in VS.Net 2008. One of the features is that it will generate your test code. LOL.

    Hey, exactly like Rails!

    This has to be a good thing, right?

    --
    Cedric
    Hi Cedric, I thought we were reaching agreement. I take it that you don't like Rails. Well great don't use it. Another fallacy about static typing that is worth debunking. Manifest (static) types in themselves don't provide much safety. I was a C programmer for many years and I remember the K&R and White Smiths Compilers. The fact that your code compiled and checked out statically meant very little. When you ran your program you were still likely to get a "segmentation fault - core dump", with little trace of where or what the problem was. With C++ came runtime type safety (Strongly typed with no loopholes). You still had pointers, still the ability to cast to what ever you liked, but now the runtime would catch illegal casts and memory accesses for you. You would get a stack trace telling exactly where the violation occurred and why. This was a massive step forward. Java came along and removed pointers all together and removed the need to manage memory yourself, which was another large source of bugs (ideas that they borrowed from Smalltalk incidentally). Dynamic languages are strongly typed and just the same as C++ and Java in regards to dynamic type safety. Unlike C which is weakly typed and has no runtime protection at all. The difference with a dynamic language is that type checking occurs at runtime only. Paul.
  103. Re: IDE support[ Go to top ]

    I take it that you don't like Rails.
    I like Rails a lot, see this article that I wrote a while ago.
    Manifest (static) types in themselves don't provide much safety.
    This is not the reason why I believe statically typed languages are more adapted to large scale software, but you don't seem to be listening.
    Java came along and removed pointers all together
    Java never removed any pointers, it removed pointer arithmetic. -- Cedric
  104. Re: IDE support[ Go to top ]


    I take it that you don't like Rails.

    I like Rails a lot, see this article that I wrote a while ago.


    Manifest (static) types in themselves don't provide much safety.

    This is not the reason why I believe statically typed languages are more adapted to large scale software, but you don't seem to be listening.


    Java came along and removed pointers all together

    Java never removed any pointers, it removed pointer arithmetic.

    --
    Cedric
    Hi Cedric, Sorry. I mistook what you said for sarcasm. Thanks for clarifying what I said on Java and pointers. I guess you understand the issues, but not everyone does. I've learnt something today. I didn't know that you like Rails. I'll take a look at your article. Thanks for the debate. Paul.
  105. Re: IDE support[ Go to top ]

    I like Rails a lot, see this article that I wrote a while ago.
    You probably could have written that today and not changed a line. Comments will. Keith needs to update his 2008 prediction. :) I looked at Ruby about 5(?) years ago and thought it was pretty kewl (built in spaces, etc). Then I remembered how I use an IDE (one can only cram so much in their head before something gets evicted from the cache). And then I put the book back on the shelf.
  106. Re: IDE support[ Go to top ]

    Something to laugh about: I have the current VS.Net Magazine. One of the articles is about new features in VS.Net 2008. One of the features is that it will generate your test code. LOL.

    Hey, exactly like Rails!

    This has to be a good thing, right?

    --
    Cedric
    It is if your goal is to have the "Test Code" checkbox checked. :)
  107. Re: IDE support[ Go to top ]

    Something to laugh about: I have the current VS.Net Magazine. One of the articles is about new features in VS.Net 2008. One of the features is that it will generate your test code. LOL.
    Hi Mark, Why doesn't VS.Net 2008 just go right ahead a write the code too LOL! Thirty years after Fred Brooks paper, many are still looking for "The Silver Bullet" and vendors are more than happy to exploit this as a business opportunity :). With the internet, blogs, open source, etc, more people are getting wise to the fact that their is no "magical answer to everything", just people who know what they are doing and people who don't. Paul.
  108. Re: IDE support[ Go to top ]

    Why doesn't VS.Net 2008 just go right ahead a write the code too LOL!
    It "does" that too. :) Oh well, I guess we better not get that fire started here.
  109. Re: IDE support[ Go to top ]

    No names here, merely an observation. Are you really interested in technical insight? I find it incredulous that you choose to right of a whole programming paradigm where you have no experience and little understanding
    There you go again... -- Cedric
  110. Re: IDE support[ Go to top ]

    I've known a few people who have suffered through AutoCAD. ;) I think that you are mis-interpreting what Cedric may be trying to say. My perception is that he may very well like some of these dynamic languages as much as you do - but there are pragmatic engineering concerns that are valid and deserve careful thought when making choices. I am personally very excited about all of the dynamic language buzz but also happy to see people like Cedric pointing out some of the warts involved - if only to put more pressure on language/tool designers to improve things and (hopefully) someday provide an answer to some of these issues. You can't improve something without knowing what the problems are. It certainly feels like everyone is ready for something new. Exciting times.
    Examples like AutoCAD and Emacs just to name a couple.

    Please state you examples of large software projects that have failed because they were written in a dynamic language. If you have no evidence and no direct experience then you are spreading FUD. And it is this that I object to.

    Paul.
  111. There are a number of dynamic programming idioms that mitigate the need for manifest typing as a documentation technique. For example, naming parameters after their type is a common practice.


    That's known as the Hungarian notation and even Microsoft is abandoning it in C#. A good duct-tape solution for dynamic language and I used it in my JS codes.

    It just proves that (1) parameters and vars have types (2) you do need to communicate the types (3) once you stick an 'i' in front of it, you'd better make sure you don't change its meaning to an 'f' or confusion and errors abound.
    (A) The dynamic programming idioms aren't Hungarian notation. (B) Original Hungarian notation is different what you describe above; what you describe above is a form of "perverted Hungarian notation" lately used on Windows. The idea of Hungarian notation is to extend the type information with more context, not repeating the standard in the parameter name. (It is also intended to make variable names canonical without losing readability). (C) Switching between floats and ints will usually be a lesser problem in dynamic languages, and you'd tend to encode as something like aNumber if you could take either of them, and code it explictly (as integer or float) only if this is truly significant.
    Eivind.
  112. Re: IDE support[ Go to top ]

    Claiming that you can't write large programs with a dynamic language though, as other have claimed, is a nonsense.
    The claim isn't that you can't write large programs in a dynamic language. There was a blog post the other day, I forget where or who, about a person who wrote a very large Java program that just Got To Big. 500K LOC or so. His solution was to rewrite it in Javascript, and he knocked it down to 300K LOC or so. I may be misremembering, but that's not important. The issue isn't how many KLOC can be written in any language. The question is how well do projects in dynamic languages (DLs) scale in terms of team size and developer base. All of your examples have a bulk of their work being done by a core group. Not only a core group, but a pretty senior group as well. How well do large DL projects work with a bunch of junior programmers working on them? When you have different sections of the code advancing at different rates, there can be problems. With a static system, you may end up with a system that doesn't build. With a dynamic system, you may end up with a system that doesn't run (or one that runs intermittently, better in some areas than in others). So, that's the question posed here. On large teams how well do DLs perform, and, at the end of the day, are the advantages of the DL shown on the bottom line, or are those advantages consumed in tooling and testing required to make up for its disadvantages. At the end of the day, is there a benefit or is it a wash. Note also, I'm not saying that large teams can not use a DL. So, fundamentally, I think it comes down to whether the benefits of a DL are lost as the team grows. If they are lost, then it's fair to argue that a DL does not scale with the team. Now you could argue that DLs don't need a large team. That a small DL team == a large SL team. But that's not the point. Just because you may not have to scale a DL team as large as a SL team doesn't make a DL scalable. A single box with 2 2GHz processors will most like out perform 4 separate boxes with 1 1GHz each. But the 2Ghz box scales vertically, while the 1Ghz boxes scale horizontally. And most folks will agree that the 1GHz horizontal scaling will be able to go farther than a vertical machine with 2Ghz processors, even if initially the 2Ghz box out performs the equal of the 1GHz boxes. So, to me, that's what this is about.
  113. Re: IDE support[ Go to top ]

    Claiming that you can't write large programs with a dynamic language though, as other have claimed, is a nonsense.


    The claim isn't that you can't write large programs in a dynamic language.

    There was a blog post the other day, I forget where or who, about a person who wrote a very large Java program that just Got To Big. 500K LOC or so.

    His solution was to rewrite it in Javascript, and he knocked it down to 300K LOC or so.

    I may be misremembering, but that's not important.

    The issue isn't how many KLOC can be written in any language. The question is how well do projects in dynamic languages (DLs) scale in terms of team size and developer base.

    All of your examples have a bulk of their work being done by a core group. Not only a core group, but a pretty senior group as well.

    How well do large DL projects work with a bunch of junior programmers working on them? When you have different sections of the code advancing at different rates, there can be problems. With a static system, you may end up with a system that doesn't build. With a dynamic system, you may end up with a system that doesn't run (or one that runs intermittently, better in some areas than in others).

    So, that's the question posed here. On large teams how well do DLs perform, and, at the end of the day, are the advantages of the DL shown on the bottom line, or are those advantages consumed in tooling and testing required to make up for its disadvantages. At the end of the day, is there a benefit or is it a wash.

    Note also, I'm not saying that large teams can not use a DL.

    So, fundamentally, I think it comes down to whether the benefits of a DL are lost as the team grows. If they are lost, then it's fair to argue that a DL does not scale with the team.

    Now you could argue that DLs don't need a large team. That a small DL team == a large SL team. But that's not the point. Just because you may not have to scale a DL team as large as a SL team doesn't make a DL scalable.

    A single box with 2 2GHz processors will most like out perform 4 separate boxes with 1 1GHz each. But the 2Ghz box scales vertically, while the 1Ghz boxes scale horizontally. And most folks will agree that the 1GHz horizontal scaling will be able to go farther than a vertical machine with 2Ghz processors, even if initially the 2Ghz box out performs the equal of the 1GHz boxes.

    So, to me, that's what this is about.
    I understand this view, but it is based on a number assumptions, and these assumptions may represent the way you work. But there are other ways of working. I am not trying to convince the world that dynamic languages are the answer to everything, but that claims that they don't scale are just plain FUD. With a dynamic language you need a different approach. Ideas like common code ownership and TDD were developed in a dynamic language environment, and they work. They also cut across a number of the assumptions you make here. Paul.
  114. Static vs dynamic and research[ Go to top ]

    I also must admit that we haven't practiced test driven development as good as we probably should have, but again that doesn't discount the fact that you must write type safety tests which come for free with a statically typed language.
    Not free. Comes for the cost of making the core codebase somewhat in excess of 3x larger in a statically typed language[1].
    This 3x size increase may be worth it on really large projects, for keeping things possible to work with even in that large scale. I at least would feel a bit uncomfortable trying to use a purely dynamic language in a large project - I'd be thinking of "What if TDD discipline fails?" and "What if we end up hitting that large scale where we really DO need the rough type checks that Java or similar gives us?"
    However, 3x the size - that's about 5x the programmers, assuming the normal research based metrics I've seen (the research indicate that one programmer will be able to handle about the same number of lines of code no matter the language, and about the same number of bugs per line of code, and a scaling in communication overhead going up with the number of people in the project.) I'd be scared shitless by that.
    Perhaps there are newer productivity studies invalidating the research I've read - I've not seen new research coming in these areas for well over a decade, and there's been things happening on the tools side.
    But without new numbers, I can't see this winning easily in either direction - the "we need types to scale development" almost certainly wins for really large development (which HAS to be scaled, anyway) - and the "we'll end up with larger costs" seems to end up winning for fairly large systems, assuming that the old research still holds. I'd go find new research on software productivity before I made any commitment - so far, I've not seen any of that show up in this thread...
    Eivind.
    [1] That's my rough experience of size between Ruby and Java; Ruby is about .5-.7 the size again of Perl code, in direct translation. I've not done direct translations back and forth between Ruby and Java; I've just worked with both.
  115. Re: Static vs dynamic and research[ Go to top ]

    Not free. Comes for the cost of making the core codebase somewhat in excess of 3x larger in a statically typed language[1]. [1] That's my rough experience of size between Ruby and Java; Ruby is about .5-.7 the size again of Perl code, in direct translation. I've not done direct translations back and forth between Ruby and Java; I've just worked with both.
    That's not an accurate comparison, since the difference in size is certainly due to other syntactic differences between the two languages (such as closures or concise declarations of properties) and not to dynamic typing. The only difference in code size between a dynamic and a static language should be the declaration of types, which makes it really negligible, even without type inference. -- Cedric
  116. Re: Static vs dynamic and research[ Go to top ]

    Not free. Comes for the cost of making the core codebase somewhat in excess of 3x larger in a statically typed language[1].
    [1] That's my rough experience of size between Ruby and Java; Ruby is about .5-.7 the size again of Perl code, in direct translation. I've not done direct translations back and forth between Ruby and Java; I've just worked with both.

    That's not an accurate comparison, since the difference in size is certainly due to other syntactic differences between the two languages (such as closures or concise declarations of properties) and not to dynamic typing.

    The only difference in code size between a dynamic and a static language should be the declaration of types, which makes it really negligible, even without type inference.

    --
    Cedric
    Hi Cedric, I beg to differ. Try doing "open classes" in a static language or "mixins" or "closures" or "polymorphic message sends". Dynamic languages lend themselves to these things, which is why almost all dynamic OO languages have these for free. Try building a late-bound component model in a static language, you need tonnes of code. This why EJBs were invented :). Again in a dynamic language you get late-binding for free. I concur with a 1:3 ratio DL:SL for code size. Bruce Tate as stated a 5 times increase in productivity using Rails over Spring/Hibernate. That sounds about right to me too. Paul.
  117. I beg to differ. Try doing "open classes" in a static language or "mixins" or "closures" or "polymorphic message sends". Dynamic languages lend themselves to these things, which is why almost all dynamic OO languages have these for free.
    Mixins and closures both work extremely well in statically typed languages. They just aren't part of Java.
    I concur with a 1:3 ratio DL:SL for code size. Bruce Tate as stated a 5 times increase in productivity using Rails over Spring/Hibernate. That sounds about right to me too.
    I think calling this a DL vs SL comparison is pure FUD. This is primarily a Java vs Ruby comparison, assuming a framework or library in Ruby that is laden with metaprogramming. C++ can be similarly concise with template metaprogramming, assuming you have someone smart enough to make it work (these people are admittedly very rare). Scala can with a combination of functional programming and mixin composition. Haskell and the ML family with purely functional techniques. Static typing and binding are pretty much orthogonal to conciseness and productivity. I think you are making false generalizations.
  118. Re: Static vs dynamic and research[ Go to top ]

    I beg to differ. Try doing "open classes" in a static language or "mixins" or "closures" or "polymorphic message sends". Dynamic languages lend themselves to these things, which is why almost all dynamic OO languages have these for free.

    Try building a late-bound component model in a static language, you need tonnes of code.
    I don't think you read my response. I was just saying that the difference between a language where you declare types and one where you don't is negligible in code size. As for "open classes", it's a neat trick that makes for great one liners in blogs, but I would highly question their use in enterprise software since they are very hard to maintain and, by definition, very hard to refactor.
    I concur with a 1:3 ratio DL:SL for code size. Bruce Tate as stated a 5 times increase in productivity using Rails over Spring/Hibernate. That sounds about right to me too.
    I don't find productivity gains at the scale of one person very meaningful. Did Bruce Tate's team see this five time increase in productivity for the rest of his team as well? How big is that team? What is their background? (actually, I suspect that most people who praise dynamic languages tend to work alone on short term projects, but that's just a guess). -- Cedric
  119. Re: Static vs dynamic and research[ Go to top ]

    Did Bruce Tate's team see this five time increase in productivity for the rest of his team as well? How big is that team? What is their background? (actually, I suspect that most people who praise dynamic languages tend to work alone on short term projects, but that's just a guess).
    Just so I have given the background for the scale of the projects I'm working on (which are fairly small, in the big scheme of things): 5 year old, about 200kloc, team size has varied from 1 to 4 programmers (2 at the moment), mostly very experienced programmers (for instance, both I and the other programmer at the moment have over 25 years of experience.)

    So, this project says very little about scalability overall - and the only large project I've worked on has been FreeBSD, which means I've never worked in large systems with "average" programmers.

    Eivind.
  120. Re: Static vs dynamic and research[ Go to top ]

    Not free. Comes for the cost of making the core codebase somewhat in excess of 3x larger in a statically typed language[1].
    [1] That's my rough experience of size between Ruby and Java; Ruby is about .5-.7 the size again of Perl code, in direct translation. I've not done direct translations back and forth between Ruby and Java; I've just worked with both.

    That's not an accurate comparison, since the difference in size is certainly due to other syntactic differences between the two languages (such as closures or concise declarations of properties) and not to dynamic typing.

    The only difference in code size between a dynamic and a static language should be the declaration of types, which makes it really negligible, even without type inference.
    I agree that there are other syntactic features that definitively are part of the picture, and probably are more important than the static typing per se. A statically typed language could have them - it's just that Java doesn't.

    There is at least one significant issue beyond the type declarations that's directly due to type declarations: Type declarations tend to lock you into a more restrictive type than necessary. When all you need is "something that can have .to_s called on it", it's very convenient to be able to actually do that.
    Also, maybe we're writing different kinds of code? For quite a bit of the code I write, type declarations and variable declarations are a signification amount of the screen real estate, and a significant source of "noise" in my code, especially if I write the style of code I do when I'm programming Ruby - lots of very short, "sharp" methods, and lots of continuation use.

    Eivind.
  121. Re: IDE support[ Go to top ]

    I understand your point of view, but have you written a large program in a dynamic language? Do you know how to program well in a dynamic language.

    If the answer is no, then I don't think you are qualified to comment.
    Also, before completely disqualifying me from commenting on dynamic languages, search my name on google. That should give you some insight of whether I'm more qualified to talk about dynamic language than most people that tend to :-) Ilya
  122. Off the topic[ Go to top ]

    I don't know Chandler, but I'm a ThinkingRock GTD user. Seems like they managed to find a niche in the PIM area.
  123. my useless 2 bits[ Go to top ]

    I don't get why Ruby fans feel like they need to convert the masses to ruby. I like LISP and s-expression languages, but I don't try to convert the world. It's silly and pointless. The biggest road block I see with ruby is the syntax. Most developers out there aren't going to like it. Even though prolog and smalltalk are superior to java in C# in many ways, it has never been a mainstream language. A good developer will try to learn many languages, but when you get down to it. People will use a language because it feels familiar. All the ruby fanboys screaming isn't doing ruby any good. Not that anyone asked or cares what I think, but trying to convert people is a waste of time.
  124. Re: Can Dynamic Languages Scale?[ Go to top ]

    I don't think benefits of dynamic languages are limited to dynamic types. I also think that refactoring is a little bess less required in dynamic languages than it is in strongly typed languages. For sure, there are examples of large applications written with dynamic languages. Sometimes the problem is with their performance. That's why Groovy could be an interesting compromise, allowing compilation. With Groovy you can choose your level of "dynamicity": if you want, you can type variables and attributes and if you don't want you can just define them. And you can also mix both styles e.g use the one most relevant in each case. Best Regards, Eric Samson, Xcalia.
  125. Re: Can Dynamic Languages Scale?[ Go to top ]

    With Groovy you can choose your level of "dynamicity": if you want, you can type variables and attributes and if you don't want you can just define them. And you can also mix both styles e.g use the one most relevant in each case.
    Unfortunately, unmaintainable code is rarely written by yourself, but alway by that lazy lousy coder who left the company half a year ago :-)
  126. Re: Can Dynamic Languages Scale?[ Go to top ]

    Is Wikipedia a small project?
  127. Actual Research[ Go to top ]

    From LtU: http://lambda-the-ultimate.org/node/2622 ...and a recent blog of my own: http://erikengbrecht.blogspot.com/2008/01/programming-language-continuum.html ...attempting to better frame the debate about different types of languages.
  128. Re: Can Dynamic Languages Scale?[ Go to top ]

    Few things to dynamic language proponents… 1. Any experienced software developers absolutely DOES NOT have to write a large project in a language to acquire a strongly rooter opinion about said language. Reading a book or documentation is sufficient enough. It is a cheap shot used by newcomers saying “Hey, if you haven’t written millions lines of code – you have no credible point of view”. C’mon, guys, we are past kindergarten by now… 2. I have experience working with past Smalltalk and Lisp developers and I can say that most of them had an extremely warped understanding of OOP concepts and were pretty useless (*all* of them that I met). I’ve learned to practically ignore their opinions. In my experience people with heavy Visual Basic or Smalltalk experience are usually equally damaged. 3. Refactoring tramps practically anything that dynamic languages can bring. Ask MS how they lost almost entire server-side development market to Java in just 3-5 years before they upgraded Visual Studio in emergency mode. 4. Expressiveness of dynamic languages? I haven’t seen this mess since Forth was in vogue. Anyone remembers those “expressive” one-liners? :) Just look at Scala to see how “expressive” something can be. Just for that “feature” alone Scala should be forgotten as a horrible nightmare. Very few people really understand how much work went into Java language design to make it and maintain it in such a simple and elegant form (thanks to original C syntax and design in many parts). Regards, Nikita Ivanov. GridGain – Grid Computing Made Simple
  129. Re: Can Dynamic Languages Scale?[ Go to top ]

    4. Expressiveness of dynamic languages? I haven’t seen this mess since Forth was in vogue. Anyone remembers those “expressive” one-liners? :) Just look at Scala to see how “expressive” something can be. Just for that “feature” alone Scala should be forgotten as a horrible nightmare.
    I'd like to point out that Scala is not a dynamic language. It is compiled to fairly normal Java classes and has a stronger static type system than Java. Also, I'm afraid people can write Perl in any language. You shouldn't discount a language simply because some people choose to write obfuscated code in it.
  130. Re: Can Dynamic Languages Scale?[ Go to top ]

    I'd like to point out that Scala is not a dynamic language. It is compiled to fairly normal Java classes and has a stronger static type system than Java.
    Thanks for correction. I mentally lumped together languages w/o static typing and functional languages (to which Scala belongs the most). Nevertheless, Scala strikes me with its often bizarre syntax that often looks like “Look, ma, no hands!” exercise. Popular example is this code snippet:
    def sum(l: List[int]): int = (0/:l){_+_}
    To defense of Scala and Groovy I can say that they both provide solid interoperability with Java (and .NET in case of Scala) and that goes a long, long way towards something like Grails that is gaining momentum on the daily basis… Thanks, Nikita Ivanov. GridGain - Grid Computing Made Simple
  131. Re: Can Dynamic Languages Scale?[ Go to top ]

    def sum(l: List[int]): int = (0/:l)(_+_)
    Yeah, that one has received a far amount of attention on the mailing list. It combines one functional concept (folds) that is relatively straightforward but generally foreign to the imperative world with two very terse syntactic shortcuts. If I rewrote it:
    def sum(l : List[Int]): Int = l.foldRight(0)((a, b) => a + b))
    then IMHO it is much more readable, and once one becomes familiar with folds it feels quite natural.
  132. Language is not rubbish heap[ Go to top ]

    def sum(l: List[int]): int = (0/:l)(_+_)

    Yeah, that one has received a far amount of attention on the mailing list. It combines one functional concept (folds) that is relatively straightforward but generally foreign to the imperative world with two very terse syntactic shortcuts.

    If I rewrote it:

    def sum(l : List[Int]): Int = l.foldRight(0)((a, b) => a + b))

    then IMHO it is much more readable, and once one becomes familiar with folds it feels quite natural.
    When i read this "one-line code", i was remembered damn old perl "one-liner" : cat "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|`{;;y; -/:-@[-`{-};`-{/" -;;s;;$_;see' Why we nead such monster constructions in programming? The purpose of language is expressiveness. When we have new team member we delegate him business problems not language problems. But if we have such beast codebase, we must maintain close contact with some guru programmer who wrote this. Just my 2 copeck.
  133. Re: Language is not rubbish heap[ Go to top ]

    Why we nead such monster constructions in programming? The purpose of language is expressiveness. When we have new team member we delegate him business problems not language problems. But if we have such beast codebase, we must maintain close contact with some guru programmer who wrote this.
    If you knew a little more than basic functional programming then the example would be very straightforward, basic code. Not guru code. The question is whether or not you can reasonably expect your programmers to know functional programming. That being said, I understand the concern. I would not select Scala for a new project yet unless I had apriori knowledge of the team or would be given considerable latitude in assembling it. There is a significant amount of effort required to learn the functional paradigms. I would compare it to going from Pascal and C to C++, or maybe C to Java. It's easier than learning metaprogramming in a dynamic language. So it all boils down to education and expectations.
  134. Re: Language is not rubbish heap[ Go to top ]

    If you knew a little more than basic functional programming then the example would be very straightforward, basic code. Not guru code.
    Yes and no. Even to someone new to functional programming, it's much easier to read "eval(foo)" than `foo`. And Perl is plagued with dozens of these syntactic warts that seem to have no other purposes than to make sure that the set of people who can actually be comfortable with this language is selected from a pool of UNIX hackers from the early 80's.
    The question is whether or not you can reasonably expect your programmers to know functional programming.

    That being said, I understand the concern. I would not select Scala for a new project yet unless I had apriori knowledge of the team or would be given considerable latitude in assembling it.
    The concern is not just about the present team, but about the future also. It's very likely that your team will grow and that you will be hiring more people to help out, so even if I had Mc Carthy and five more people who defined Lisp on my team, I would still not start a project in Lisp because its future would be very uncertain. On the other hand, I would love to work with someone who knows functional programming very well but doesn't mind working in any language and using different paradigms. As for people who think that there is no other way to program than using X (replace X with your language or your paradigm of choice), thanks but no thanks. -- Cedric
  135. Re: Language is not rubbish heap[ Go to top ]

    If you knew a little more than basic functional programming then the example would be very straightforward, basic code. Not guru code.

    Yes and no.

    Even to someone new to functional programming, it's much easier to read "eval(foo)" than `foo`.
    I agree. I was refering to the version were the method was spelled out, rather than being a right-associative operator with currying so the method arguments are actually split between the left and right hand sides of the object.

    The question is whether or not you can reasonably expect your programmers to know functional programming.

    That being said, I understand the concern. I would not select Scala for a new project yet unless I had apriori knowledge of the team or would be given considerable latitude in assembling it.

    The concern is not just about the present team, but about the future also. It's very likely that your team will grow and that you will be hiring more people to help out, so even if I had Mc Carthy and five more people who defined Lisp on my team, I would still not start a project in Lisp because its future would be very uncertain.
    It still boils down to expectations and education, it's just farther in the future. I was being insensitive to the manager of the maintenance team.
  136. Re: Can Dynamic Languages Scale?[ Go to top ]

    Few things to dynamic language proponents…

    I have experience working with past Smalltalk and Lisp developers and I can say that most of them had an extremely warped understanding of OOP concepts and were pretty useless (*all* of them that I met). I’ve learned to practically ignore their opinions. In my experience people with heavy Visual Basic or Smalltalk experience are usually equally damaged. Wow, after that uniformed rant, a lot of developers will be ignoring everything you have to say.
    After that nonsense jibberish, a lot of developers should be ignoring your opinions.
  137. Re: Can Dynamic Languages Scale?[ Go to top ]

    After that nonsense jibberish, a lot of developers should be ignoring your opinions.
    There we go again, Frank... :) It' s actually spelled "gibberish", btw. Tough opinions are sometime hard to swallow - get used to it. Regards, Nikita Ivanov. GridGain - Grid Computing Made Simple
  138. Re: Can Dynamic Languages Scale?[ Go to top ]

    After that nonsense jibberish, a lot of developers should be ignoring your opinions.
    Sorry, but i have seen this to be mostly true, at least from a VB standpoint. There are some exceptions (I believe I am one of them) as I hinted in my other post. So it isn't nonsense nor jibberish nor gibberish nor giblets. To be honest, it isn't so much the problem of VB (or language x) but people. Most people have trouble learning let alone learning new things. Yes, they can learn, but the effort is great. People also have trouble breaking habits and have trouble with change pretty much in general.
  139. Re: Can Dynamic Languages Scale?[ Go to top ]

    In my experience people with heavy Visual Basic ... experience are usually equally damaged.
    Hey, don't discount us all. :) Some of us learn how not to do things by using VB. By some I probably mean 1 or 2.
  140. You need theory AND practice.[ Go to top ]

    Few things to dynamic language proponents…

    1. Any experienced software developers absolutely DOES NOT have to write a large project in a language to acquire a strongly rooter opinion about said language. Reading a book or documentation is sufficient enough.
    Here's 25 years of programming experience calling the opposite viewpoint - reading documentation or a book will never give you anything approaching the same feel for how a language works in practice as actually working with it, and the opinions of people lacking either theory or practice will usually be worth fairly little.

    Eivind.

  141. Re: You need theory AND practice.[ Go to top ]

    Few things to dynamic language proponents…

    1. Any experienced software developers absolutely DOES NOT have to write a large project in a language to acquire a strongly rooter opinion about said language. Reading a book or documentation is sufficient enough.


    Here's 25 years of programming experience calling the opposite viewpoint - reading documentation or a book will never give you anything approaching the same feel for how a language works in practice as actually working with it, and the opinions of people lacking either theory or practice will usually be worth fairly little.


    Eivind.

    +1
  142. Re: Can Dynamic Languages Scale?[ Go to top ]

    Doesn't Objective-C provide examples of successful large-scale projects on OS X?
  143. A bit offtopic question[ Go to top ]

    If I may i would like to ask if anybody could refer to a book or something that would help on getting more familiar to development in dynamic languages. I am a young developer who has mostly written software in static languages. The preferred language would be python, but isn't that important. Sorry if it is inappropriate to ask this here but reading about dynamic languages on the net, I found this thread to contain the most people who actually have argumented opinions about that. Thanks.
  144. Re: Can Dynamic Languages Scale?[ Go to top ]

    I work on projects delivering real-time carrier retail billing solutions that are implemented with a dynamic language engine as one of the critical components used to maintain flexibility and deliver customisations rapidly. The dynamic language is only a part of the story, but it is relevant to note that the entire system relies on a balance of core framework (traditional compiled components) and customisation (dynamic language and some other components designed to provide data model flexibility). Finding the sweet spot in this balance is key to the flexibility, scalability and time-to-market that has been delivered to customers so far. Does it scale? The project that I am currently working on scales to real-time authorisation of around 900 calls per second on a mobile network with a subscriber base of around 10-12 million subscribers, while simultaneously dealing with all OLTP requests to the system for CRM activity, as well as triggering provisioning. Not huge, but big enough to back up the statement that "dynamic languages can scale". It has been interesting to note that enterprises still struggle to understand how dynamic languages are re-writing the rules for delivering business functionality.