6 ms·

Static typing has it's place, but it's been massively oversold. I'm interested in static languages that have excellent type inference or like dart with it's opt

Static typing has it's place, but it's been massively oversold. I'm interested in static languages that have excellent type inference or like dart with it's optional static types,however 90% of the time in strictly static languages like C# and Java it gets in the way more than it ever helps. Complaints like "refactoring" or compiler error checking however are the oldest FUD in the book. > Until real software engineering is developed, the next best practice is to develop with a dynamic system that has extreme late binding in all aspects. > --Alan Kay

chi_h 15y ago
static typing does NOT mean C# and java - there are far better statically typed languages out there.
- lucisferre 15y ago
  Agreed. But they do embody the strict static typing philosophy which I do acknowledge is clearly a straw man of the authors point of view.
  - bunderbunder 15y ago
    C# has supported dynamic typing since version 4.0. At this point it doesn't make much sense to say that C# is strictly anything. It's perhaps the most obsessively multi-paradigm language out there.
    - lucisferre 15y ago
      Ugh, `dynamic` doesn't provide the benefits of a dynamically typed language by long, long way, and yes I've used it extensively. But thanks for the downvote all the same. http://wekeroad.com/2010/08/09/csharps-new-clothes/ http://wekeroad.com/2010/08/09/csharps-new-clothes/ In case you plan on skimming that and missing the details the tl;dr is that Rob, pushes `dynamic` as far as he can and it still comes up far short of the extensibility and expressiveness of Ruby constructs.
      - bwarp 15y ago
        Upvoted. Spot on. It's nowhere near as dynamic as a basic dynamic language. So much so that I just don't bother with dynamic in C# (I also don't bother with nullable types and a load of other features as well but that's another story). However, I don't find that a problem. I tend to prefer the correctness of statically typed languages these days.
wpietri 15y ago
> Complaints like "refactoring" or compiler error checking however are the oldest FUD in the book. What makes you say that? First, I happen to have worked with this fellow before [Hi, John! Long time no see. Fun to come across your post here.] and I'm sure he's quite sincere. Second, having spent a bunch of time lately in dynamic languages (Ruby and JS mostly), I do indeed miss the automated refactoring tools that existed for Java. It's really nice to be able to rename a method everywhere across the code base without worrying that something else got mangled. I also miss the magic documentation that a type-aware IDE can provide; I spend a lot more time digging through layers of code to figure out what a particular parameter is expected to be. Not that I want to switch back; I agree that a language with strong type inference is the way to go. But man, I miss the tools.
- lucisferre 15y ago
  Not saying he isn't sincere I'm saying it's a common misunderstanding that the improved refactoring and compiler errors are that valuable, that they alone can support a strong argument for static vs. dynamic. There are generally very few situations where you have a single method from a single class sprinkled across an entire codebase for a good reason. That always indicates high coupling and design problems. There are even fewer reasons to rename a well designed method. Constant renaming and high-coupling are bad habits that seem to be commonplace when working in strictly static languages and yet they are known to be bad habits even there. At least dynamic languages discourage these anti-patterns. Not to belittle your friend, I found myself falling into these traps constantly when working in C#. Honestly, what I'm saying is that these problems just are not nearly as significant in say, Ruby, as they are often made out to be by static typing proponents. It's a bit disingenuous to point to these trivialities as reasons why static > dynamic. If it were true then there would be little benefit in dynamic languages. Clearly there is.
  - cageface 15y ago
    After 10 years of programming almost exclusively in dynamic languages I'm very much enjoying the refactoring abilities of modern IDEs when I'm doing native mobile development. I rarely have to change a method across an entire code base, but the ability to rename a method or package name in half a dozen files with a single key press is indisputably not only a productivity boost but an encouragement to more extensive refactoring. More generally, the ability of modern IDEs to manipulate code structurally, and not just texturally, has been eye opening for me.
bunderbunder 15y ago
For the sake of context, the original source of that quote is essentially an advertisement for Squeak. It raises some interesting ideas, and Smalltalk is definitely a system to know. http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeringAnOxymoron.pdf http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeri... But as an argument for one paradigm vs. another it doesn't really stand up, because the essay takes its own conclusion (that large systems would be easier to maintain if they were more like Squeak) as a major premise. Him being one of the inventors of the platform, I don't think we can just take his word for it. At a minimum, what we'd really want to see is a large successful enterprise system built on Smalltalk to serve as an instructive example. To my knowledge no such system exists, so we can't really take the paper, insightful as it is, as much more than hopeful musing. That said, the "bind really late" approach has seen a lot of success. Just not quite so pervasively as the "in all aspects" that Kay advocates in the paper. Nowadays, the standard way to build large systems is to build completely independent modules and couple them on fluid interfaces. Text streams in Unix, REST APIs, and even SOAP are clear examples. What we don't see, though, is a whole lot of reason to think that the languages and run-times on which these modules run must also support late binding and hot-swapping of code at the micro scale, or that we're really suffering for lack of it.
- lucisferre 15y ago
  You've started with a fallacy here. No one is getting paid to push smalltalk. Even if that was the case, my association with a thing, doesn't make my support of it wrong by definition. Smalltalk obviously should be expected to embodies Alan's opinion on this. That it does, should come as no surprise, and one can safely assume he would have the same opinion regardless of having written a language based on it or not. To be honest it doesn't seem that you are arguing against this concept that strongly, you're just not overly sold on it. I agree it's good to be sceptical, just as I'm sceptical there is all that much value in static typing in most cases. Having used a statically typed language for years, I've personally found the value to be little and the cognitive friction to be high.
  - bunderbunder 15y ago
    > You've started with a fallacy here. No one is getting paid to push smalltalk. I wasn't using the word 'advertise' to suggest he was getting paid to push it. I was using it in very much the same sense in which you use the word 'sell' here: > To be honest it doesn't seem that you are arguing against this concept that strongly, you're just not overly sold on it. To which I respond: Correct. I'd even go so far as to say I'm not arguing against the concept at all. Considering that all sorts of approaches to software development continue to be extremely popular, including among very smart people, it just seems crazy to me that people get so acrimonious about such issues. Programming is a very wide and varied field. If two developers try something and come away with differing opinions of it, isn't it just possible that those different opinions are both informed, but informed by different experience resulting from working in different problem domains? I'd submit that developers don't give each other nearly enough credit when they offhandedly dismiss each other's sharing of their own practical experience as "FUD". To bring it back to Kay's paper: He's got some very interesting ideas, but the specific examples he talks about are problems that just don't cause me any stress in my day job. Yet he implies that people in my problem domain are suffering for not using his preferred programming paradigm. Now I don't want to accuse him of attacking me, and I certainly don't want to attack him because I believe that paper represents learned speculation and not a stake in the ground. But it remains true that he's not necessarily coming from the same place that everyone else is, and his experience of what works well does not necessarily translate into a universal best practice.

chi_h 15y ago

static typing does NOT mean C# and java - there are far better statically typed languages out there.

lucisferre 15y ago
Agreed. But they do embody the strict static typing philosophy which I do acknowledge is clearly a straw man of the authors point of view.
- bunderbunder 15y ago
  C# has supported dynamic typing since version 4.0. At this point it doesn't make much sense to say that C# is strictly anything. It's perhaps the most obsessively multi-paradigm language out there.
  - lucisferre 15y ago
    Ugh, `dynamic` doesn't provide the benefits of a dynamically typed language by long, long way, and yes I've used it extensively. But thanks for the downvote all the same. http://wekeroad.com/2010/08/09/csharps-new-clothes/ http://wekeroad.com/2010/08/09/csharps-new-clothes/ In case you plan on skimming that and missing the details the tl;dr is that Rob, pushes `dynamic` as far as he can and it still comes up far short of the extensibility and expressiveness of Ruby constructs.
    - bwarp 15y ago
      Upvoted. Spot on. It's nowhere near as dynamic as a basic dynamic language. So much so that I just don't bother with dynamic in C# (I also don't bother with nullable types and a load of other features as well but that's another story). However, I don't find that a problem. I tend to prefer the correctness of statically typed languages these days.

wpietri 15y ago

> Complaints like "refactoring" or compiler error checking however are the oldest FUD in the book. What makes you say that? First, I happen to have worked with this fellow before [Hi, John! Long time no see. Fun to come across your post here.] and I'm sure he's quite sincere. Second, having spent a bunch of time lately in dynamic languages (Ruby and JS mostly), I do indeed miss the automated refactoring tools that existed for Java. It's really nice to be able to rename a method everywhere across the code base without worrying that something else got mangled. I also miss the magic documentation that a type-aware IDE can provide; I spend a lot more time digging through layers of code to figure out what a particular parameter is expected to be. Not that I want to switch back; I agree that a language with strong type inference is the way to go. But man, I miss the tools.

lucisferre 15y ago
Not saying he isn't sincere I'm saying it's a common misunderstanding that the improved refactoring and compiler errors are that valuable, that they alone can support a strong argument for static vs. dynamic. There are generally very few situations where you have a single method from a single class sprinkled across an entire codebase for a good reason. That always indicates high coupling and design problems. There are even fewer reasons to rename a well designed method. Constant renaming and high-coupling are bad habits that seem to be commonplace when working in strictly static languages and yet they are known to be bad habits even there. At least dynamic languages discourage these anti-patterns. Not to belittle your friend, I found myself falling into these traps constantly when working in C#. Honestly, what I'm saying is that these problems just are not nearly as significant in say, Ruby, as they are often made out to be by static typing proponents. It's a bit disingenuous to point to these trivialities as reasons why static > dynamic. If it were true then there would be little benefit in dynamic languages. Clearly there is.
- cageface 15y ago
  After 10 years of programming almost exclusively in dynamic languages I'm very much enjoying the refactoring abilities of modern IDEs when I'm doing native mobile development. I rarely have to change a method across an entire code base, but the ability to rename a method or package name in half a dozen files with a single key press is indisputably not only a productivity boost but an encouragement to more extensive refactoring. More generally, the ability of modern IDEs to manipulate code structurally, and not just texturally, has been eye opening for me.

bunderbunder 15y ago

For the sake of context, the original source of that quote is essentially an advertisement for Squeak. It raises some interesting ideas, and Smalltalk is definitely a system to know. http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeringAnOxymoron.pdf http://squab.no-ip.com/collab/uploads/61/IsSoftwareEngineeri... But as an argument for one paradigm vs. another it doesn't really stand up, because the essay takes its own conclusion (that large systems would be easier to maintain if they were more like Squeak) as a major premise. Him being one of the inventors of the platform, I don't think we can just take his word for it. At a minimum, what we'd really want to see is a large successful enterprise system built on Smalltalk to serve as an instructive example. To my knowledge no such system exists, so we can't really take the paper, insightful as it is, as much more than hopeful musing. That said, the "bind really late" approach has seen a lot of success. Just not quite so pervasively as the "in all aspects" that Kay advocates in the paper. Nowadays, the standard way to build large systems is to build completely independent modules and couple them on fluid interfaces. Text streams in Unix, REST APIs, and even SOAP are clear examples. What we don't see, though, is a whole lot of reason to think that the languages and run-times on which these modules run must also support late binding and hot-swapping of code at the micro scale, or that we're really suffering for lack of it.

lucisferre 15y ago
You've started with a fallacy here. No one is getting paid to push smalltalk. Even if that was the case, my association with a thing, doesn't make my support of it wrong by definition. Smalltalk obviously should be expected to embodies Alan's opinion on this. That it does, should come as no surprise, and one can safely assume he would have the same opinion regardless of having written a language based on it or not. To be honest it doesn't seem that you are arguing against this concept that strongly, you're just not overly sold on it. I agree it's good to be sceptical, just as I'm sceptical there is all that much value in static typing in most cases. Having used a statically typed language for years, I've personally found the value to be little and the cognitive friction to be high.
- bunderbunder 15y ago
  > You've started with a fallacy here. No one is getting paid to push smalltalk. I wasn't using the word 'advertise' to suggest he was getting paid to push it. I was using it in very much the same sense in which you use the word 'sell' here: > To be honest it doesn't seem that you are arguing against this concept that strongly, you're just not overly sold on it. To which I respond: Correct. I'd even go so far as to say I'm not arguing against the concept at all. Considering that all sorts of approaches to software development continue to be extremely popular, including among very smart people, it just seems crazy to me that people get so acrimonious about such issues. Programming is a very wide and varied field. If two developers try something and come away with differing opinions of it, isn't it just possible that those different opinions are both informed, but informed by different experience resulting from working in different problem domains? I'd submit that developers don't give each other nearly enough credit when they offhandedly dismiss each other's sharing of their own practical experience as "FUD". To bring it back to Kay's paper: He's got some very interesting ideas, but the specific examples he talks about are problems that just don't cause me any stress in my day job. Yet he implies that people in my problem domain are suffering for not using his preferred programming paradigm. Now I don't want to accuse him of attacking me, and I certainly don't want to attack him because I believe that paper represents learned speculation and not a stake in the ground. But it remains true that he's not necessarily coming from the same place that everyone else is, and his experience of what works well does not necessarily translate into a universal best practice.