7 ms·

I sometimes find myself torn between dynamic typing (great for rapid prototyping) and static typing (great for tooling and compile-time error checks). I'm a bi

by sdevlin 13y ago

I sometimes find myself torn between dynamic typing (great for rapid prototyping) and static typing (great for tooling and compile-time error checks). I'm a big fan of TypeScript's approach, which gives you the best of both worlds. Start with fully dynamic code to explore the problem space, then add more static guarantees as you firm up your design. I haven't had occasion to write a big web app recently, but I'm itching to find one so I can put TypeScript through its paces.

marshray 13y ago
Did I just hear someone say they were looking for a web app to write? I think he may even know something about software engineering ... Don't everybody mob him at once :-)
harrytuttle 13y ago
I was in the same position for literally years regarding static vs dynamic. I've concluded that C gets it spot on i.e. it's mostly static with associated guarantees but you can use a void* if you need it.
- mahmud 13y ago
  Probably the single worst conclusion someone can arrive at regarding typing.
  - harrytuttle 13y ago
    Rather than slate me, some constructive discussion would be nice. I'll go from my side: 1. Static type compiler verification saves tonnes of problems. Try managing a 2MLOC dynamically typed solution and you'll get what I mean. 2. Static typed languages are way easier to refactor as more metadata is available to the tooling. 3. Static typed code is easier to test. The type contract is available over the boundary between the implementation and the test cases. 4. Defined interfaces without leaky abstractions are easier to produce when you have static types. 5. Static types allow the compiler to infer more information about how to compiler your code resulting in faster, more efficient code and lower memory usage plus you don't have to compile an instance of a function with every possible type consideration at runtime. 6. Statically typed data serialises more reliably i.e. goes over the wire easier without behemoth contracts and parsers at each end. 7. Statically typed languages tend to have better numeric accuracy as differences between decimal, floats and integers are always deterministic and there are defined casts and conversions between each during operations. I could go on...
    - mahmud 13y ago
      Your heart is in the right place, but you're stuck with a bad example still. C is hardly a good representative for an statically typed language. Read Luca Cardelli's "Typeful Programming"[1] to get an overview of what typed programming is all about, and see for yourself how brain-dead C and C++ are in comparison. After that go to Benjamin Pierce's canon, "Types and Programming Languages". [1]http://www.daimi.au.dk/~madst/tool/papers/typeful.pdf http://www.daimi.au.dk/~madst/tool/papers/typeful.pdf
      - nly 13y ago
        I don't think it's fair to call C++s type system 'brain-dead' when it was developed pragmatically to be largely source compatible with C. It introduced stronger array types, eliminated Cs automatic void* -> T* conversion and, most importantly, put higher-order functions and types on the table. It might be a warty syntactical abomination, but it can still hold its own against some of the languages of type extremism.
      - marshray 13y ago
        So what would you consider to be the "good representatives for an statically typed language"?
        mahmud 13y ago
        A language with a statically enforced type system? Anything in the ML family for starters, but more popularly, Java, C#, the Pascal family, etc.
    - lucian1900 13y ago
      5 is not entirely correct. 6 is not true, serialisation in dynamic languages is correctly done with type definitions. 7 is not true at all, mainstream statically typed languages (like C) much more commonly overflow silently. Look at Python, there's no way to lose precision through arithmetic, as types get promoted on overflow correctly. In general, C's type system is so weak as to be both useless and a hindrance.
delambo 13y ago
I think the greatest advantage to static typing is the IDE support. Compile-time error checking is overrated, and in my several years of writing JavaScript, I've never seen a bug in production that could have been prevented with static analysis. That might be because I know the language well, but it's not a feature I need. "What's true of all bugs? They passed a type checker and they passed the tests!" - Rich Hickey
- sdevlin 13y ago
  Your point is well taken, but I think it has value. Compile-time error checking is useful because it gives you flexibility to make changes in a big program. It's kind of like a big suite of automatic tests that make sure all the parts of your program talk to each other correctly. Does it catch everything? Can you stop thinking critically? No, but it's still nice to have. This sort of goes hand in hand with IDE tools (e.g. "change method name" sorts of things), so I don't think we necessarily disagree. > I've never seen a bug in production that could have been prevented with static analysis. That seems unlikely to me. I do application penetration testing for a living, and I'll often use static analysis tools in my work. (Both robust, established tools and ad hoc scripts.) For example, check out Brakeman for Rails apps. These tools find actual bugs in actual production software. Do they find everything? No, you can't rely on them completely. But they're still nice to have.
- Fistandantilus 13y ago
  >...I've never seen a bug in production that could have been prevented with static analysis That's because they're hidden by the lack of static analysis. They're just waiting for the wrong code path to be taken, then BAM. The whole system crashes. You need static analysis to find bugs that can be prevented with static analysis. What a strange concept!

by sdevlin 13y ago

marshray 13y ago

Did I just hear someone say they were looking for a web app to write? I think he may even know something about software engineering ... Don't everybody mob him at once :-)

harrytuttle 13y ago

I was in the same position for literally years regarding static vs dynamic. I've concluded that C gets it spot on i.e. it's mostly static with associated guarantees but you can use a void* if you need it.

mahmud 13y ago
Probably the single worst conclusion someone can arrive at regarding typing.
- harrytuttle 13y ago
  Rather than slate me, some constructive discussion would be nice. I'll go from my side: 1. Static type compiler verification saves tonnes of problems. Try managing a 2MLOC dynamically typed solution and you'll get what I mean. 2. Static typed languages are way easier to refactor as more metadata is available to the tooling. 3. Static typed code is easier to test. The type contract is available over the boundary between the implementation and the test cases. 4. Defined interfaces without leaky abstractions are easier to produce when you have static types. 5. Static types allow the compiler to infer more information about how to compiler your code resulting in faster, more efficient code and lower memory usage plus you don't have to compile an instance of a function with every possible type consideration at runtime. 6. Statically typed data serialises more reliably i.e. goes over the wire easier without behemoth contracts and parsers at each end. 7. Statically typed languages tend to have better numeric accuracy as differences between decimal, floats and integers are always deterministic and there are defined casts and conversions between each during operations. I could go on...
  - mahmud 13y ago
    Your heart is in the right place, but you're stuck with a bad example still. C is hardly a good representative for an statically typed language. Read Luca Cardelli's "Typeful Programming"[1] to get an overview of what typed programming is all about, and see for yourself how brain-dead C and C++ are in comparison. After that go to Benjamin Pierce's canon, "Types and Programming Languages". [1]http://www.daimi.au.dk/~madst/tool/papers/typeful.pdf http://www.daimi.au.dk/~madst/tool/papers/typeful.pdf
    - nly 13y ago
      I don't think it's fair to call C++s type system 'brain-dead' when it was developed pragmatically to be largely source compatible with C. It introduced stronger array types, eliminated Cs automatic void* -> T* conversion and, most importantly, put higher-order functions and types on the table. It might be a warty syntactical abomination, but it can still hold its own against some of the languages of type extremism.
    - marshray 13y ago
      So what would you consider to be the "good representatives for an statically typed language"?
      - mahmud 13y ago
        A language with a statically enforced type system? Anything in the ML family for starters, but more popularly, Java, C#, the Pascal family, etc.
  - lucian1900 13y ago
    5 is not entirely correct. 6 is not true, serialisation in dynamic languages is correctly done with type definitions. 7 is not true at all, mainstream statically typed languages (like C) much more commonly overflow silently. Look at Python, there's no way to lose precision through arithmetic, as types get promoted on overflow correctly. In general, C's type system is so weak as to be both useless and a hindrance.

delambo 13y ago

I think the greatest advantage to static typing is the IDE support. Compile-time error checking is overrated, and in my several years of writing JavaScript, I've never seen a bug in production that could have been prevented with static analysis. That might be because I know the language well, but it's not a feature I need. "What's true of all bugs? They passed a type checker and they passed the tests!" - Rich Hickey

sdevlin 13y ago
Your point is well taken, but I think it has value. Compile-time error checking is useful because it gives you flexibility to make changes in a big program. It's kind of like a big suite of automatic tests that make sure all the parts of your program talk to each other correctly. Does it catch everything? Can you stop thinking critically? No, but it's still nice to have. This sort of goes hand in hand with IDE tools (e.g. "change method name" sorts of things), so I don't think we necessarily disagree. > I've never seen a bug in production that could have been prevented with static analysis. That seems unlikely to me. I do application penetration testing for a living, and I'll often use static analysis tools in my work. (Both robust, established tools and ad hoc scripts.) For example, check out Brakeman for Rails apps. These tools find actual bugs in actual production software. Do they find everything? No, you can't rely on them completely. But they're still nice to have.
Fistandantilus 13y ago
>...I've never seen a bug in production that could have been prevented with static analysis That's because they're hidden by the lack of static analysis. They're just waiting for the wrong code path to be taken, then BAM. The whole system crashes. You need static analysis to find bugs that can be prevented with static analysis. What a strange concept!