6 ms·

I built a service (~10mm users at peak) which was designed from the ground up to scale, around 2002. When the numbers did grow we just sat back and watched it p

by qume 10y ago

I built a service (~10mm users at peak) which was designed from the ground up to scale, around 2002. When the numbers did grow we just sat back and watched it pretty much. Even given this, I completely agree with you. That's why I now develop in ruby. I'll take developer productivity over performance any day. It's the old saying - 'nice problem to have'.

logicallee 10y ago
>I built a service (~10mm users at peak) which was designed from the ground up to scale, around 2002. When the numbers did grow we just sat back and watched it pretty much. >Even given this, I completely agree with you. That's why I now develop in ruby. Ouch that is a pretty big burn.
hasenj 10y ago
> That's why I now develop in ruby. I'll take developer productivity over performance any day. In my experience, dynamically typed languages don't do well for developer productivity.
- petters 10y ago
  They do well for single-person code bases, but velocity scales badly with the number of developers in my experience.
- abritinthebay 10y ago
  And in my experience the exact opposite is true. That's why it's called an anecdote; not data.
  - luord 10y ago
    Exactly, I never understand the static vs dynamic flamewars. Most of the issues usually presented stem from poor developers or poor development processes/environments/tools. Poor code written in JavaScript won't become pretty just by translating to Java, and vice versa. That I've seen anyway.
    - sidlls 10y ago
      Many of the "poor development processes/environments/tools" issues are related to choosing dynamic languages in a "ship first, design later (maybe)" paradigm, though.
      - luord 10y ago
        "Ship first, design later" is completely orthogonal to what language one's using. Using a language that forces one to write int or str before the variables isn't preventing anyone to write software without having a design. It's not even part of the "static vs dynamic" argument; one can rush things in Java or in C++ just as easily. The only difference is that Java might allow doing it slightly faster.
    - abritinthebay 10y ago
      As someone smarter than me put it: "Bad code is language agnostic" Yes, catching type errors eliminates one category of error but, generally, the type of programmers that make that kind of error frequently will not constrain themselves to just one category of error.
- simonh 10y ago
  Having worked on corporate Python platform with tens of thousands of developers and hundreds of applications running hubdress of thousands of instances on a many million line common core code base, I beg to differ. We were sometimes able to go from concept to deployed application in a single day.
  - user5994461 10y ago
    Having worked on corporate Python platform with tens of thousands of developers and thousands of applications running on thousands of instances on millions of lines common core code base, I beg to differ. It is easy to ship any proof of concept. Is it hard to maintain, it is rigged with performance issues and it is almost impossible to refactor because python has zero refactoring support and no compiler to help you catch any error. What you save on the initial rollout, you loose ten folds on the long term.
    - franciscop 10y ago
      But that is basically the point of the whole article and this thread, that it's great for proof of concept that morphs into production when needed. If you can deploy in one day that means you can test 5 ideas/week until one catches on (hopefully not that long). Once one catches on, you can actually put more effort into it and optimize it as needed and not the other way around.
      - user5994461 10y ago
        You can't try 5 products or features a week on real users. They don't keep up.
        nickpsecurity 10y ago
        Facebook deploys thousands a week: https://swreflections.blogspot.com/2013/09/this-is-how-facebook-develops-and.html https://swreflections.blogspot.com/2013/09/this-is-how-faceb...
- spamizbad 10y ago
  > In my experience, dynamically typed languages don't do well for developer productivity. At least one empirical study suggests static typing does not improve programmer productivity. Source: http://courses.cs.washington.edu/courses/cse590n/10au/hanenberg-oopsla2010.pdf http://courses.cs.washington.edu/courses/cse590n/10au/hanenb... This is just one of the many common industry "wisdoms" that collapse under scientific scrutiny.
  - emcq 10y ago
    That's a cool experiment, but from a quick read they are creating a compiler which is a bit different than web development. Looking at the related work all seem to contradict this finding and suggest preference to statically typed languages, such as one that looked at API development. From my own experience with dynamic types it's not the dev time that increases but maintenance time. When you have a team working on an evolving codebase with data types distributed in caches, databases, and code it seems inevitable that you will have an error if you don't do any type checks. Even good linters can miss something that would have been easy to catch with static type checks.
    - nickpsecurity 10y ago
      "That's a cool experiment, but from a quick read they are creating a compiler which is a bit different than web development." They're doing a lot of things wrong. See my reply.
  - deleted 10y ago
    [deleted]
  - nickpsecurity 10y ago
    This study looks bad across the board. For one, they're writing a parser for a context-free grammar. That's not a good test for the benefits of static typing which often happen with very different types of data mixing, modifying large programs with less breakage, and so on. Contrary to your statement, there's a lot of reports and articles out there where switching to formal specs or a stronger type system reduced the number of defects. The first were in high-assurance where formal specs caught inconsistencies left and right. Later on, military and safety-critical firms looked at defect rates of C, C++, and Ada to find Ada's type system knocked them to half. This counter-example is about something so straight-forward there's many tools that can automate it with one formally-verified for correctness (w/ strongly typed language). Next, I look at the languages themselves. Java's type system is so weak to barely have any benefit. Terrible choice to test static typing. The control language is then a language based on Smalltalk... the original, great language for dynamic, OOP, and complex programs... that's even simpler than Java & could possibly boost productivity just due to easier review/revision. A proper comparison would be with something like Ocaml, Haskell, Ada/SPARK, or Rust that really uses a type-system with the high-level & composition benefits of something like Smalltalk. Makes me lean toward Ocaml or Haskell than others which slow productivity fighting with compiler. This paper doesn't prove anything for or against the topic. It's quite weak. The authors should do their next one on the kind of program that others in the field reported benefited from static, strong typing. Then, attempt an experiment on same type of software between a productive language with powerful, type system and a productive, dynamic language of similar complexity. Alternatively, try to modify similarly large applications in parts that touch a lot of the code base without breakage for both static and dynamic languages. Then, we might learn something.
- jondubois 10y ago
  I have the opposite experience and I did a lot of back and forth between statically typed and dynamically typed languages over the past decade so I'm not biased in either direction.
kodablah 10y ago
In many situations these days, I'd argue you don't have to trade one for the other.

by qume 10y ago

logicallee 10y ago

>I built a service (~10mm users at peak) which was designed from the ground up to scale, around 2002. When the numbers did grow we just sat back and watched it pretty much. >Even given this, I completely agree with you. That's why I now develop in ruby. Ouch that is a pretty big burn.

hasenj 10y ago

> That's why I now develop in ruby. I'll take developer productivity over performance any day. In my experience, dynamically typed languages don't do well for developer productivity.

petters 10y ago
They do well for single-person code bases, but velocity scales badly with the number of developers in my experience.
abritinthebay 10y ago
And in my experience the exact opposite is true. That's why it's called an anecdote; not data.
- luord 10y ago
  Exactly, I never understand the static vs dynamic flamewars. Most of the issues usually presented stem from poor developers or poor development processes/environments/tools. Poor code written in JavaScript won't become pretty just by translating to Java, and vice versa. That I've seen anyway.
  - sidlls 10y ago
    Many of the "poor development processes/environments/tools" issues are related to choosing dynamic languages in a "ship first, design later (maybe)" paradigm, though.
    - luord 10y ago
      "Ship first, design later" is completely orthogonal to what language one's using. Using a language that forces one to write int or str before the variables isn't preventing anyone to write software without having a design. It's not even part of the "static vs dynamic" argument; one can rush things in Java or in C++ just as easily. The only difference is that Java might allow doing it slightly faster.
  - abritinthebay 10y ago
    As someone smarter than me put it: "Bad code is language agnostic" Yes, catching type errors eliminates one category of error but, generally, the type of programmers that make that kind of error frequently will not constrain themselves to just one category of error.
simonh 10y ago
Having worked on corporate Python platform with tens of thousands of developers and hundreds of applications running hubdress of thousands of instances on a many million line common core code base, I beg to differ. We were sometimes able to go from concept to deployed application in a single day.
- user5994461 10y ago
  Having worked on corporate Python platform with tens of thousands of developers and thousands of applications running on thousands of instances on millions of lines common core code base, I beg to differ. It is easy to ship any proof of concept. Is it hard to maintain, it is rigged with performance issues and it is almost impossible to refactor because python has zero refactoring support and no compiler to help you catch any error. What you save on the initial rollout, you loose ten folds on the long term.
  - franciscop 10y ago
    But that is basically the point of the whole article and this thread, that it's great for proof of concept that morphs into production when needed. If you can deploy in one day that means you can test 5 ideas/week until one catches on (hopefully not that long). Once one catches on, you can actually put more effort into it and optimize it as needed and not the other way around.
    - user5994461 10y ago
      You can't try 5 products or features a week on real users. They don't keep up.
      - nickpsecurity 10y ago
        Facebook deploys thousands a week: https://swreflections.blogspot.com/2013/09/this-is-how-facebook-develops-and.html https://swreflections.blogspot.com/2013/09/this-is-how-faceb...
spamizbad 10y ago
> In my experience, dynamically typed languages don't do well for developer productivity. At least one empirical study suggests static typing does not improve programmer productivity. Source: http://courses.cs.washington.edu/courses/cse590n/10au/hanenberg-oopsla2010.pdf http://courses.cs.washington.edu/courses/cse590n/10au/hanenb... This is just one of the many common industry "wisdoms" that collapse under scientific scrutiny.
- emcq 10y ago
  That's a cool experiment, but from a quick read they are creating a compiler which is a bit different than web development. Looking at the related work all seem to contradict this finding and suggest preference to statically typed languages, such as one that looked at API development. From my own experience with dynamic types it's not the dev time that increases but maintenance time. When you have a team working on an evolving codebase with data types distributed in caches, databases, and code it seems inevitable that you will have an error if you don't do any type checks. Even good linters can miss something that would have been easy to catch with static type checks.
  - nickpsecurity 10y ago
    "That's a cool experiment, but from a quick read they are creating a compiler which is a bit different than web development." They're doing a lot of things wrong. See my reply.
- deleted 10y ago
  [deleted]
- nickpsecurity 10y ago
  This study looks bad across the board. For one, they're writing a parser for a context-free grammar. That's not a good test for the benefits of static typing which often happen with very different types of data mixing, modifying large programs with less breakage, and so on. Contrary to your statement, there's a lot of reports and articles out there where switching to formal specs or a stronger type system reduced the number of defects. The first were in high-assurance where formal specs caught inconsistencies left and right. Later on, military and safety-critical firms looked at defect rates of C, C++, and Ada to find Ada's type system knocked them to half. This counter-example is about something so straight-forward there's many tools that can automate it with one formally-verified for correctness (w/ strongly typed language). Next, I look at the languages themselves. Java's type system is so weak to barely have any benefit. Terrible choice to test static typing. The control language is then a language based on Smalltalk... the original, great language for dynamic, OOP, and complex programs... that's even simpler than Java & could possibly boost productivity just due to easier review/revision. A proper comparison would be with something like Ocaml, Haskell, Ada/SPARK, or Rust that really uses a type-system with the high-level & composition benefits of something like Smalltalk. Makes me lean toward Ocaml or Haskell than others which slow productivity fighting with compiler. This paper doesn't prove anything for or against the topic. It's quite weak. The authors should do their next one on the kind of program that others in the field reported benefited from static, strong typing. Then, attempt an experiment on same type of software between a productive language with powerful, type system and a productive, dynamic language of similar complexity. Alternatively, try to modify similarly large applications in parts that touch a lot of the code base without breakage for both static and dynamic languages. Then, we might learn something.
jondubois 10y ago
I have the opposite experience and I did a lot of back and forth between statically typed and dynamically typed languages over the past decade so I'm not biased in either direction.

kodablah 10y ago

In many situations these days, I'd argue you don't have to trade one for the other.