5 ms·

How big are the projects you are working on though? For instance I work an a 2 year old Angular project and static typing is something we are trying to introduc

by adamors 10y ago

How big are the projects you are working on though? For instance I work an a 2 year old Angular project and static typing is something we are trying to introduce because the codebase is large and challenging to work with, mostly because Javascript. There's only so much you can do with best practices and code organisation.

chvid 10y ago
I work on / have worked on fairly big projects. Plenty of them have been "a challenge to work with". Always because of the code that had been written (+ other things). Never because of the language. For me the trick to big projects is strong modularisation and well-defined interfaces which you can do regardless if you have static type checks or not.
- cgag 10y ago
  Yeah, but when you have static typing, you can't avoid well-defined interfaces.
  - chvid 10y ago
    Let's pick an example: function renderMarkdownToHtml(text) And with static types: function renderMarkdownToHtml(text : String) : String Well-defined interfaces is mostly not about types.
    - glibgil 10y ago
      When you want function render(markdown : Markdown) : Html then you will see the reason for types (and lots of them)
      - chvid 10y ago
        Yep. And there you have it. Two different approaches to buidling software. Which is more productive, which yields higher quality? I have build plenty of software both ways. And my answer is a confident "it depends". But I will tell you this: A fine-grained type hierarchy over either Markdown or HTML opens up a very big can of worms. All this reminds me of SOAP vs. HTTP/JSON: I have seen plenty of SOAP webservices seriously stuffed up regardless of/because of strong typing whereas developers seem to do much better with HTTP/JSON because of the simplicity and directness of the approach.
    - deleted 10y ago
      [deleted]
    - chii 10y ago
      does renderMarkdownToHtml return a string or does it return a DOM element?
- chvid 10y ago
  Plus. I think that there is a bit of developer-psychology-101 here. Most developers would rather go: This project sucks. This shitty language has not got a proper type system. Let's build a compiler/type-checker/use-this-cool-alpha-from-bingo-banana-I-found-last-night. Rather than: This project sucks. I cannot believe how much bad, disorganised code we have written. Let's sit down and look at our mess to see if we can improve the way we write code, work together and in general develop way we make software.
  - plgs 10y ago
    I don't see these as mutually exclusive. Introducing a compiler/type-checker can be (depending on your situation) a very concrete way of improving the way code is written.
    - chvid 10y ago
      They are not. But the pscyhology is that people will much rather talk about introducing a new tool rather than what they have done wrong.
shados 10y ago
I've worked in multi-million lines mono-repo Javascript projects built with Backbone and old school ES3 (supporting IE6, etc). Types would have helped, a little. But really, architectural soundness, proper unit tests, and frequent refactoring (using the tests) kept things under control fine. The biggest trick is that 99% of the community has never seen/worked with a properly unit tested code base. Even though who think they did, often didn't (they have 80-95% test coverage with bad tests, overlapping tests, or integration tests...and that's blah if that's all you have). The current JS type systems only take you so far, too: since typing is optional (for good reasons), and type definitions of 3rd party libs are often out of sync, or wrong, etc, a small error, or a missing definition, and your right click -> rename ends up breaking something subtle. It helps, but it's not enough to have full confidence in a large system. In a small app it's not really needed, and in a massive app you have the above issue, so it's mainly in the mid range people find the most benefits For a type system to really save your butt in a large app, you need an advanced type system, like Elm/Haskell/Scala/whatever. Otherwise, the tool you actually need is proper unit tests. Types will help, a little. But they're not the panacea. Especially optional ones.

by adamors 10y ago

chvid 10y ago

I work on / have worked on fairly big projects. Plenty of them have been "a challenge to work with". Always because of the code that had been written (+ other things). Never because of the language. For me the trick to big projects is strong modularisation and well-defined interfaces which you can do regardless if you have static type checks or not.

cgag 10y ago
Yeah, but when you have static typing, you can't avoid well-defined interfaces.
- chvid 10y ago
  Let's pick an example: function renderMarkdownToHtml(text) And with static types: function renderMarkdownToHtml(text : String) : String Well-defined interfaces is mostly not about types.
  - glibgil 10y ago
    When you want function render(markdown : Markdown) : Html then you will see the reason for types (and lots of them)
    - chvid 10y ago
      Yep. And there you have it. Two different approaches to buidling software. Which is more productive, which yields higher quality? I have build plenty of software both ways. And my answer is a confident "it depends". But I will tell you this: A fine-grained type hierarchy over either Markdown or HTML opens up a very big can of worms. All this reminds me of SOAP vs. HTTP/JSON: I have seen plenty of SOAP webservices seriously stuffed up regardless of/because of strong typing whereas developers seem to do much better with HTTP/JSON because of the simplicity and directness of the approach.
  - deleted 10y ago
    [deleted]
  - chii 10y ago
    does renderMarkdownToHtml return a string or does it return a DOM element?
chvid 10y ago
Plus. I think that there is a bit of developer-psychology-101 here. Most developers would rather go: This project sucks. This shitty language has not got a proper type system. Let's build a compiler/type-checker/use-this-cool-alpha-from-bingo-banana-I-found-last-night. Rather than: This project sucks. I cannot believe how much bad, disorganised code we have written. Let's sit down and look at our mess to see if we can improve the way we write code, work together and in general develop way we make software.
- plgs 10y ago
  I don't see these as mutually exclusive. Introducing a compiler/type-checker can be (depending on your situation) a very concrete way of improving the way code is written.
  - chvid 10y ago
    They are not. But the pscyhology is that people will much rather talk about introducing a new tool rather than what they have done wrong.

shados 10y ago

I've worked in multi-million lines mono-repo Javascript projects built with Backbone and old school ES3 (supporting IE6, etc). Types would have helped, a little. But really, architectural soundness, proper unit tests, and frequent refactoring (using the tests) kept things under control fine. The biggest trick is that 99% of the community has never seen/worked with a properly unit tested code base. Even though who think they did, often didn't (they have 80-95% test coverage with bad tests, overlapping tests, or integration tests...and that's blah if that's all you have). The current JS type systems only take you so far, too: since typing is optional (for good reasons), and type definitions of 3rd party libs are often out of sync, or wrong, etc, a small error, or a missing definition, and your right click -> rename ends up breaking something subtle. It helps, but it's not enough to have full confidence in a large system. In a small app it's not really needed, and in a massive app you have the above issue, so it's mainly in the mid range people find the most benefits For a type system to really save your butt in a large app, you need an advanced type system, like Elm/Haskell/Scala/whatever. Otherwise, the tool you actually need is proper unit tests. Types will help, a little. But they're not the panacea. Especially optional ones.