5 ms·

The idea of attempting to refactor a 100k+ loc codebase, without static typing and a compiler that can identify issues at compile-time versus runtime is equival

The idea of attempting to refactor a 100k+ loc codebase, without static typing and a compiler that can identify issues at compile-time versus runtime is equivalent to asking to be punished. If you must, consider that the role of a type-checking compiler is simply to perform a first round of automatic unit-tests, tests that are conveniently available after providing some typing annotations. To escape static typing - if there is a demonstratable and exceptional need (loose coupling), simply wrap the required events up as objects and switch and downcast on them with enums or use a visitor pattern. Unfortunately associating dynamic languages like ruby, python and javascipt with some narrative of hacker agility and contrasting against a clumsy slow-moving 'enterprise' culture is confounding the issues. This is not to say that there aren't plenty of vendors/consultants selling FUD and over-hyped and over-complicated 'solutions' in 'enterprise' but it's a non-technical issue.

rbanffy 15y ago
First, lets assume your 100k+ loc codebase would be about 10k+ loc if coded in most of the "overhyped" languages. That's the primary reason there are not that many huge codebases in them - huge codebases aren't needed. That's also a reason no multi-year development is done with them - it just doesn't last that long. Next, remember not having to upcast and downcast objects considerably simplifies the code, simplifying the tests you need to write. Less code means less places a bug can hide. And, finally, understand that, while not passing compilation proves your program is wrong, passing it doesn't make it any closer to correct. Trust me. I've seen enough "enterprise" codebases in my life. They aren't that special.
- hello_moto 15y ago
  Hm... Assumption #1: 100k+ loc codebase in X == 10k+ loc in Y (somehow... magic) Assumption #2: Assumption #1 is the primary reason not many huge codebases in Y Assumption #3: Static type implies upcast/downcast objects (despite the presence of generics...) == simplifies code == simplifies tests. Fact: Less code == less places a bug can hide Fact: BTW! we all are using tried-and-tested libraries to cut down code to be written Fact: FindBugs (or static code analysis) does actually find bugs to eliminate most technical bugs and leave you with business logic (and quite possibly race condition bugs). Argument: Compiler isn't special, see, I just show you it doesn't proved your code to be correct, there's the logic bug in your Business Logic. (Except that happens as well in dynamic language, AND on top of that you gotta work a little bit extra since you ain't got no compiler). I think this has become your typical nerd holy war between static vs dynamic with no end. Here's my biggest problem with Ruby or Python community: your libraries tend to have short-lived (i.e.: orphaned). When I looked at Java community, they're quite stable and rock solid since 2004-2005 (Apache Commons, Maven, Ant, FindBugs, Eclipse, EclEmma, Spring Framework family, JUnit, Hibernate). Newer libraries tend to have good internal codebases (GWT, Google Guava, Mockito). Most APIs are stable and solid. The stupid ones tend to get kicked out of the crowd (i.e.: Struts, JSF) This is what I'm looking for. I can focus on writing code that matters, instead of refactoring my code once every 4 months because things changed and I have to keep up.
  - fckin 15y ago
    True, Rails is such a terrible and unsupported framework.
  - rbanffy 15y ago
    > Assumption #1: 100k+ loc codebase in X == 10k+ loc in Y (somehow... magic) Have you ever worked with any significantly complex (as in "does a lot of stuff") in Ruby, Python or Smalltalk? Do you sincerely think you could express that same level of functionality with C, C++, C# or Java? > Assumption #3: Static type implies upcast/downcast objects (despite the presence of generics...) == simplifies code == simplifies tests. Generics are nice until you have to implement something that accepts them. I gave up once. > Fact: BTW! we all are using tried-and-tested libraries to cut down code to be written And language features that do just that (see Assumption #1) > ... static code analysis) does actually find bugs Actually, they are one step above syntax errors. > Except that happens as well in dynamic language No. Not really. Of course, I may pass a list to something that expects a file but, provided I embraced the idea of duck typing, that would probably work just fine. And yield correct results. And avoid implementing a similar function that receives a string instead of a file. > AND on top of that you gotta work a little bit extra since you ain't got no compiler Most errors a compiler catches are traditionally caught in tests with dynamic languages. But having compilers doesn't allow one to skip writing proper tests with statically typed languages. In fact, considering you'll have to deal with more situations, you'll have to write more tests to go with your less concise code. > I think this has become your typical nerd holy war between static vs dynamic with no end. I think statically typed languages have their place. I have written tons of C and Java (and a bit of C#). I just admit my ST code was not significantly better than my DT code and was considerably more complicated, with more functions, classes, interfaces, configurations, indirections, and much more verbose. The 10x loc difference is very real. In the end they were all, ST and DT, correct. > Here's my biggest problem with Ruby or Python community: your libraries tend to have short-lived (i.e.: orphaned). I'm nos as familiar with Ruby (the language mentioned in the article) but I can tell you Rails (the framework mentioned) is very solid and very well maintained. Compatibility can be broken from time to time, mostly for good reasons. And you don't need to rush to update your code - you can be perfectly happy using older libraries. I can tell you, however, Python libraries are remarkably stable. The impending move to Python 3 is the only significant example of code breakage, but, again, it's for great reasons. > they're quite stable and rock solid since 2004-2005 (Apache Commons, Maven, Ant, FindBugs, Eclipse, EclEmma, Spring Framework family, JUnit, Hibernate). A couple of them gained significant functionality in the past couple years. If you want to use the new functionality, you'll have to refactor your code, often extensively. > I can focus on writing code that matters, Ditto here. I just write less code (in less time) for the same amount of "matters" > instead of refactoring my code once every 4 months because things changed and I have to keep up. With the extra time you get by writing less code in less time, you certainly have the time to refactor. With good tests, you have the certainty the refactoring was successful. Besides, nothing is compelling you to switch to incompatible versions every 4 months (I don't even think that's possible unless you are doing so deliberately). What is the problem here?
- radicalbyte 15y ago
  If 90k of your 100k codebase is generated code - and there's a good chance that it is - then the size of the codebase is no reason to switch to an interpreted language.
  - rbanffy 15y ago
    Are you sure generated code is a good thing? Isn't it just support for limited expression power, something you shouldn't be able to get away with in your language of choice that your tools help you with by writing lots of code that are required to express what you intended? Wouldn't it just be nice if you could get away with just the code you wrote?

rbanffy 15y ago

First, lets assume your 100k+ loc codebase would be about 10k+ loc if coded in most of the "overhyped" languages. That's the primary reason there are not that many huge codebases in them - huge codebases aren't needed. That's also a reason no multi-year development is done with them - it just doesn't last that long. Next, remember not having to upcast and downcast objects considerably simplifies the code, simplifying the tests you need to write. Less code means less places a bug can hide. And, finally, understand that, while not passing compilation proves your program is wrong, passing it doesn't make it any closer to correct. Trust me. I've seen enough "enterprise" codebases in my life. They aren't that special.

hello_moto 15y ago
Hm... Assumption #1: 100k+ loc codebase in X == 10k+ loc in Y (somehow... magic) Assumption #2: Assumption #1 is the primary reason not many huge codebases in Y Assumption #3: Static type implies upcast/downcast objects (despite the presence of generics...) == simplifies code == simplifies tests. Fact: Less code == less places a bug can hide Fact: BTW! we all are using tried-and-tested libraries to cut down code to be written Fact: FindBugs (or static code analysis) does actually find bugs to eliminate most technical bugs and leave you with business logic (and quite possibly race condition bugs). Argument: Compiler isn't special, see, I just show you it doesn't proved your code to be correct, there's the logic bug in your Business Logic. (Except that happens as well in dynamic language, AND on top of that you gotta work a little bit extra since you ain't got no compiler). I think this has become your typical nerd holy war between static vs dynamic with no end. Here's my biggest problem with Ruby or Python community: your libraries tend to have short-lived (i.e.: orphaned). When I looked at Java community, they're quite stable and rock solid since 2004-2005 (Apache Commons, Maven, Ant, FindBugs, Eclipse, EclEmma, Spring Framework family, JUnit, Hibernate). Newer libraries tend to have good internal codebases (GWT, Google Guava, Mockito). Most APIs are stable and solid. The stupid ones tend to get kicked out of the crowd (i.e.: Struts, JSF) This is what I'm looking for. I can focus on writing code that matters, instead of refactoring my code once every 4 months because things changed and I have to keep up.
- fckin 15y ago
  True, Rails is such a terrible and unsupported framework.
- rbanffy 15y ago
  > Assumption #1: 100k+ loc codebase in X == 10k+ loc in Y (somehow... magic) Have you ever worked with any significantly complex (as in "does a lot of stuff") in Ruby, Python or Smalltalk? Do you sincerely think you could express that same level of functionality with C, C++, C# or Java? > Assumption #3: Static type implies upcast/downcast objects (despite the presence of generics...) == simplifies code == simplifies tests. Generics are nice until you have to implement something that accepts them. I gave up once. > Fact: BTW! we all are using tried-and-tested libraries to cut down code to be written And language features that do just that (see Assumption #1) > ... static code analysis) does actually find bugs Actually, they are one step above syntax errors. > Except that happens as well in dynamic language No. Not really. Of course, I may pass a list to something that expects a file but, provided I embraced the idea of duck typing, that would probably work just fine. And yield correct results. And avoid implementing a similar function that receives a string instead of a file. > AND on top of that you gotta work a little bit extra since you ain't got no compiler Most errors a compiler catches are traditionally caught in tests with dynamic languages. But having compilers doesn't allow one to skip writing proper tests with statically typed languages. In fact, considering you'll have to deal with more situations, you'll have to write more tests to go with your less concise code. > I think this has become your typical nerd holy war between static vs dynamic with no end. I think statically typed languages have their place. I have written tons of C and Java (and a bit of C#). I just admit my ST code was not significantly better than my DT code and was considerably more complicated, with more functions, classes, interfaces, configurations, indirections, and much more verbose. The 10x loc difference is very real. In the end they were all, ST and DT, correct. > Here's my biggest problem with Ruby or Python community: your libraries tend to have short-lived (i.e.: orphaned). I'm nos as familiar with Ruby (the language mentioned in the article) but I can tell you Rails (the framework mentioned) is very solid and very well maintained. Compatibility can be broken from time to time, mostly for good reasons. And you don't need to rush to update your code - you can be perfectly happy using older libraries. I can tell you, however, Python libraries are remarkably stable. The impending move to Python 3 is the only significant example of code breakage, but, again, it's for great reasons. > they're quite stable and rock solid since 2004-2005 (Apache Commons, Maven, Ant, FindBugs, Eclipse, EclEmma, Spring Framework family, JUnit, Hibernate). A couple of them gained significant functionality in the past couple years. If you want to use the new functionality, you'll have to refactor your code, often extensively. > I can focus on writing code that matters, Ditto here. I just write less code (in less time) for the same amount of "matters" > instead of refactoring my code once every 4 months because things changed and I have to keep up. With the extra time you get by writing less code in less time, you certainly have the time to refactor. With good tests, you have the certainty the refactoring was successful. Besides, nothing is compelling you to switch to incompatible versions every 4 months (I don't even think that's possible unless you are doing so deliberately). What is the problem here?
radicalbyte 15y ago
If 90k of your 100k codebase is generated code - and there's a good chance that it is - then the size of the codebase is no reason to switch to an interpreted language.
- rbanffy 15y ago
  Are you sure generated code is a good thing? Isn't it just support for limited expression power, something you shouldn't be able to get away with in your language of choice that your tools help you with by writing lots of code that are required to express what you intended? Wouldn't it just be nice if you could get away with just the code you wrote?