4 ms·

I could write a multi-paragraph comment explaining why statically typed languages are better, but I’ll just say that I always see projects that were written in

I could write a multi-paragraph comment explaining why statically typed languages are better, but I’ll just say that I always see projects that were written in dynamic languages being rewritten in static languages, and never the other way around, fwiw. I never heard anyone say “let’s rewrite this in Node” unironically.

omegalulw 5y ago
This. And I would go so far as to argue that the up from cost of adding types is not as big as people make it out to be. If I don't specify a type in the input, I have to check in the method body that what was passed in was something usable. Skip this is very bad, the best case scenario is something your code will error out on wrong input, the worst case is it computes the wrong result with no errors.
- radicalbyte 5y ago
  I can spend a day coding* in a typed language without compiling, and my code more often compile than not work first time with the tests all green. The exact same thing happens with dynamic languages - as long as I skip the tests (or write bad tests).
- paiute 5y ago
  have you ever seen a Java app log? you still got to check and handle on public facing functions.
paiute 5y ago
I've seen it go both ways for various reasons. typically nothing to do with types.
didibus 5y ago
At my work we've rewritten a few things to Clojure from Java and Scala. So at least now you've got one known data-point to the contrary.
- booleandilemma 5y ago
  Thank you :) I’ve been meaning to try Clojure out.
  - jmkr 5y ago
    You might be interested in reading about spec[0] and as always, a Rich Hickey video on it[1]. [0] https://clojure.org/guides/spec https://clojure.org/guides/spec [1] https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk
    - didibus 5y ago
      We do use Spec heavily, we use it to define our domain data model for all data which crosses the application boundary (data which we will persist to disk, database, or data which we send/receive from other services (over APIs), or data which we take from the user or return to the user. What we've found happens to us, is that because Clojure is dynamically typed, we actually spend more time focusing on making sure we have well specified and properly designed our data model for data which enters/leaves the application boundary, and that we use runtime validation everytime the data is about to leave the app boundary or enter it from a non-trusted source. When we used Java and Scala, we did not spend quite as much time here, because you've already got your internal types, and you kind of take them as your data model, and rely on them for validation and specification. The issue is the types only go so far to perform validation, and you've often designed them in terms of the implementation needs, and not the domain model. A dynamically typed language like Clojure teaches you to be extra careful with data to make sure you don't mess it up, and it gives you really powerful tools for it, such as Spec and the REPL. This turns out to help I've found in an enterprise context, because even with a statically typed language, when data enters/leaves the boundary of the application it is no longer within the purview of the type checker. So with Clojure, we end up spending way more time thinking through our domain model and validating it. Which worked pretty well for us. You also need to learn how to properly design an app in Clojure, and it's very different than other languages, so it's possible to overcomplicate things and shoot yourself in the foot. But if you do it right, it makes for very simple code bases that are way smaller in LOC. Generally, we have one module that specifies our data model for the bounded context of our app. Another module to construct, validate, convert, and manipulate entities from our data model. And then we have a main module with all our APIs, each API implementation lives in its own module. Shared logic exist in a shared module. And shared state exist in another shared module. It takes a bit of a different mindset, like knowing to ski and then trying to learn to snowboard, but for me I ended up liking it much better, and the lack of static types didn't bother me, the strong functional immutable leaning of Clojure, along with the help of the interactive REPL development style makes up for it.
laumars 5y ago
Likewise, you never see anyone suggesting the removal of type annotations in Python. But you often see people comment that they should have been used in the production Python code.
hitekker 5y ago
My team is currently removing Flow types in our JS code base.
- _ZeD_ 5y ago
  what is the reason?
danmaz74 5y ago
When it comes time to rewrite, it's usually because you've got an application which was successful in satisfying the users/customers needs, and which most often reached that point going through lots of iterations, changes, trials and errors - accumulating technical debt in the process. At that point you've got pretty clear specs: what the original application does. Rewriting in a language which makes exploration slower, but long term maintainability easier, makes a lot of sense. This doesn't imply that using the latter language during the exploratory phase would have gotten better - or even the same - results.
codeflo 5y ago
I fully agree about static types, I just want to mention that TypeScript works well with Node, and can be quite nice.
vanusa 5y ago
I always see projects that were written in dynamic languages being rewritten in static languages, and never the other way around, fwiw. Actually it was (and is) quite common to see crufty old (but statically typed) C++, Java, what-you-have-you re-written in Perl and/or Python (well before the introduction of type annotations, in the latter case). Reason: there are multiple factors involved in choosing a suitable language, and static typing is just one of them (and by no means a universal deal-breaker). I never heard anyone say “let’s rewrite this in Node” unironically. Good for you (and I would never say that other than as a tired, old joke). But unfortunately "respect" for Node runs quite high in some circles, and not a few developers consider to be not just occasionally acceptable server-side language, but (from the way they talk about it) to be the bees knees basically. Why? TypeScript of course.

omegalulw 5y ago

This. And I would go so far as to argue that the up from cost of adding types is not as big as people make it out to be. If I don't specify a type in the input, I have to check in the method body that what was passed in was something usable. Skip this is very bad, the best case scenario is something your code will error out on wrong input, the worst case is it computes the wrong result with no errors.

radicalbyte 5y ago
I can spend a day coding* in a typed language without compiling, and my code more often compile than not work first time with the tests all green. The exact same thing happens with dynamic languages - as long as I skip the tests (or write bad tests).
paiute 5y ago
have you ever seen a Java app log? you still got to check and handle on public facing functions.

paiute 5y ago

I've seen it go both ways for various reasons. typically nothing to do with types.

didibus 5y ago

At my work we've rewritten a few things to Clojure from Java and Scala. So at least now you've got one known data-point to the contrary.

booleandilemma 5y ago
Thank you :) I’ve been meaning to try Clojure out.
- jmkr 5y ago
  You might be interested in reading about spec[0] and as always, a Rich Hickey video on it[1]. [0] https://clojure.org/guides/spec https://clojure.org/guides/spec [1] https://www.youtube.com/watch?v=oyLBGkS5ICk https://www.youtube.com/watch?v=oyLBGkS5ICk
  - didibus 5y ago
    We do use Spec heavily, we use it to define our domain data model for all data which crosses the application boundary (data which we will persist to disk, database, or data which we send/receive from other services (over APIs), or data which we take from the user or return to the user. What we've found happens to us, is that because Clojure is dynamically typed, we actually spend more time focusing on making sure we have well specified and properly designed our data model for data which enters/leaves the application boundary, and that we use runtime validation everytime the data is about to leave the app boundary or enter it from a non-trusted source. When we used Java and Scala, we did not spend quite as much time here, because you've already got your internal types, and you kind of take them as your data model, and rely on them for validation and specification. The issue is the types only go so far to perform validation, and you've often designed them in terms of the implementation needs, and not the domain model. A dynamically typed language like Clojure teaches you to be extra careful with data to make sure you don't mess it up, and it gives you really powerful tools for it, such as Spec and the REPL. This turns out to help I've found in an enterprise context, because even with a statically typed language, when data enters/leaves the boundary of the application it is no longer within the purview of the type checker. So with Clojure, we end up spending way more time thinking through our domain model and validating it. Which worked pretty well for us. You also need to learn how to properly design an app in Clojure, and it's very different than other languages, so it's possible to overcomplicate things and shoot yourself in the foot. But if you do it right, it makes for very simple code bases that are way smaller in LOC. Generally, we have one module that specifies our data model for the bounded context of our app. Another module to construct, validate, convert, and manipulate entities from our data model. And then we have a main module with all our APIs, each API implementation lives in its own module. Shared logic exist in a shared module. And shared state exist in another shared module. It takes a bit of a different mindset, like knowing to ski and then trying to learn to snowboard, but for me I ended up liking it much better, and the lack of static types didn't bother me, the strong functional immutable leaning of Clojure, along with the help of the interactive REPL development style makes up for it.

laumars 5y ago

Likewise, you never see anyone suggesting the removal of type annotations in Python. But you often see people comment that they should have been used in the production Python code.

hitekker 5y ago

My team is currently removing Flow types in our JS code base.

_ZeD_ 5y ago
what is the reason?

danmaz74 5y ago

When it comes time to rewrite, it's usually because you've got an application which was successful in satisfying the users/customers needs, and which most often reached that point going through lots of iterations, changes, trials and errors - accumulating technical debt in the process. At that point you've got pretty clear specs: what the original application does. Rewriting in a language which makes exploration slower, but long term maintainability easier, makes a lot of sense. This doesn't imply that using the latter language during the exploratory phase would have gotten better - or even the same - results.

codeflo 5y ago

I fully agree about static types, I just want to mention that TypeScript works well with Node, and can be quite nice.

vanusa 5y ago

I always see projects that were written in dynamic languages being rewritten in static languages, and never the other way around, fwiw. Actually it was (and is) quite common to see crufty old (but statically typed) C++, Java, what-you-have-you re-written in Perl and/or Python (well before the introduction of type annotations, in the latter case). Reason: there are multiple factors involved in choosing a suitable language, and static typing is just one of them (and by no means a universal deal-breaker). I never heard anyone say “let’s rewrite this in Node” unironically. Good for you (and I would never say that other than as a tired, old joke). But unfortunately "respect" for Node runs quite high in some circles, and not a few developers consider to be not just occasionally acceptable server-side language, but (from the way they talk about it) to be the bees knees basically. Why? TypeScript of course.