14 ms·

Man, I feel like the only one here who doesn't really like static types. I like dynamic typing just fine (it's crazy, I know: it must be the lisp influence). An

Man, I feel like the only one here who doesn't really like static types. I like dynamic typing just fine (it's crazy, I know: it must be the lisp influence). And if I want static typing, TS feels a bit intrusive. Flow is much better in this respect. I also don't think JS is the root of all evil, and I use Emacs rather than an IDE (although we do have really good integration with regular JS, in the form of the famous js2-mode, and flycheck's linter integration). I, mean, do you really need your IDE checking your types as you type? It's not that slow, and us Emacs users have M-x compile, so we can run our code, and than jump back to the problematic line when an error occurs, and I know IDEs have similar functionality. Don't get me wrong: static typing can be good at times, and option static typing and compile-time type analysis are useful tools, and I'm glad TS, Flow, and the like exist. But I always see a flock of comments saying that they couldn't possible live without static types, and thanking TS for taking them out of the hell of dynamism, and wishing there was something similar in Ruby/Python/whatever. I don't really get that.

edoloughlin 10y ago
Another Emacs JS dev here. I find Emacs + Tern works very well for me.
- qwertyuiop924 10y ago
  Cool. Is it better than JS2?
moloch 10y ago
Well TypeScript is sort of "optionally typed" (variables can have a type of `any`) it's also superset of JavaScript so any valid js is valid ts.
mschulze 10y ago
My experience: I don't get how in a project with several developers and maybe even teams dynamic types work at all. If a colleague writes a function/method that returns something, in JS, how do I know what it is? I have to read the function or its tests. With a statically typed language I immediately know the structure of the returned "thing" (don't want to say object) and can infer how to work on it.
- jshen 10y ago
  I've worked on a lot of big projects with both dynamic and static languages. I think what a lot of people that are used to static languages don't realize is that dynamic langauge users typically live inside of some kind of repl. The repl gives you immediate access to the thing returned and lets you inspect it and play with it. This serves the same purpose, albeit in a different way, as the IDE for a langauge like java or c#.
  - mschulze 10y ago
    That's a good explanation, thank you. My experience in big projects with dynamic languages boils down to Angular which I didn't find very REPL friendly. BTW, with IntelliJ and its debug mode for Java we almost have some sort of weird REPL. By pressing Alt+F8 one can, during a breakpoint evaluate an arbitrary Java expression while accessing the values in scope. I use it a lot, despite having my types.
    - jshen 10y ago
      I use that in Intellij all the time, but it's very limited to something like pry in ruby.
    - qwertyuiop924 10y ago
      Angular was a Bad Idea. For so many reasons. I'm barely acquainted with it, but I could already go on about all the problems I had, which other, more experienced people also had. And I do a lot of Lisp programming in Emacs, where the support for REPLs and livecoding is ungodly. Really, really good.
    - Roboprog 10y ago
      Install Batarang in Chrome. the "$scope" objects are attached to the browser DOM, and the tool adds another tab to element inspection that shows you the data attached to each level, as well as references back up to enclosing levels.
- jeremiep 10y ago
  I feel this is just a myth. I'm constantly looking at the source even with static types. Unless you're having a Haskell-like type-system the function's signature will still miss most of what the function is actually doing. How do I know if a function does a network call? Saves a file? Changes the DOM? These are really important things to know when calling code and the type-system is completely oblivious about them. What I usually see however is that projects using static types frequently have at least twice the team size as the equivalent projects using dynamic types. Communication overhead follows, ownership fades and debt creeps in quickly. After a few month they usually have no traces of agility left.
johnfn 10y ago
Statically typed languages have a few large advantages over dynamic languages. These include: - Refactoring. Refactoring a large JavaScript codebase (> 100k loc) is nearly impossible and at best incredibly painful, error prone and time consuming. With static types, it becomes a trivial and straightforward process. - Your code is now more discoverable. You can easily find definitons, and discovering all methods and properties on an object is as simple as triggering an autocomplete pop up. - Code is now more readable. Objects are never opaque. You never have to dig through multiple calls just to see what the shape of an object is. It's all right there. For me, the killer app is refactoring. Writing huge amounts of JS is very painful to me because I refactor almost constantly as I add more code. Most dynamic languages have this problem. Static typing changes that completely.
- jshen 10y ago
  I just want to point out there is very little emporical data on this front which makes almost every statement along the lines of "static is better because ..." or "dynamic is better because ..." to be pure opinion.
- jeremiep 10y ago
  I don't get this. Most of the known refactorings can't be easily implemented by IDEs so you're left with the trivial ones like renaming or moving things. Static types won't help you refactor a monster class into a structure of arrays. It won't refactor your callback hell into coroutines. It won't refactor your "one-at-a-time" algorithm into batches. Yet these all yield more agility and performance. The thing is, I usually have so much less code when throwing static types out the window that refactorings become a non-issue. I get away with basic Emacs macros and unix tools.
  - bsimpson 10y ago
    Or in a GUI: Apple-Shift-F Find: <old name> Replace: <new name> …continue working.
    - shados 10y ago
rihegher 10y ago
You're not alone, I'm fine with dynamic typing. And I'm sure lots of people were fine before TS came.
jeremiep 10y ago
Same here, I hate it when I land in a TypeScript codebase where they followed "clean code" and "best practices" and have nice OOP abstractions everywhere.. its always a kludgy monstrosity that yields everything but actual agility or performance. The whole "lets use classes in JavaScript" movement makes me very sad. Its as if today's web developers are now rediscovering the 90's and all the mistakes that were made back when OOP was the new shiny thing. I get WAY more annoyed fighting with TypeScript's type-system than fixing the rare runtime type error, which is usually trivial to find anyways. This all feels like a very superficial and inefficient way to achieve correctness. The real hard to find bugs come from state and complexity, both of which are completely ignored by static type systems. Instead I see the exact opposite: the new shiny typed abstractions introduce so much state and complexity that any advantage gained by having static types is lost there. I probably sound very pessimistic here; the older I grow the more I appreciate Alan Kay's quote about the internet and the web for being so damn spot-on.
- TAForObvReasons 10y ago
  The computer industry is the only industry that is more fashion-driven than women's fashion. -- Larry Ellison These cycles come and go. Sometimes static typing is hot, sometimes dynamic typing is hot. Best bet for pragmatic people is to figure out what works for you and run with it.
  - qwertyuiop924 10y ago
    Indeed. But I'd quote Kay, not Ellison, myself. Personally, I wouldn't trust Ellison further than I can throw him.
- RyanCavanaugh 10y ago
  It's important to not conflate static typing with OOP. If you think about static typing only in terms of OOP, of course you're not going to like it - classes are not the right abstraction for many problems. The TypeScript compiler (which is written in TS) itself uses zero classes. There's no need to use classes to get static typing. If you're writing TS the "right way", you write the JavaScript you would have written anyway, and add type annotations to create contracts and descriptions of behavior.
niieani 10y ago
For me, it's not even about "typing" or even "checking for errors as you type". The killer feature is: almost never having to read library documentation. You type the code, and get suggestions for all the properties and methods available, along with all the possible arguments you are supposed to pass. Saves you a TON of time and context switching, so you can focus better on the task at hand. That alone makes TypeScript worth the trouble IMHO.
- lloyd-christmas 10y ago
  > You type the code, and get suggestions for all the properties and methods available, along with all the possible arguments you are supposed to pass. Only if the library itself is written in Typescript or the ambient definitions are perfect. Not necessarily a detractor from the language, but still a practical time sink given the current state of external typings. It's definitely getting better, but it's still quite far from a minimal nuisance.
- Roboprog 10y ago
  The "intellisense" crowd always kills me with this: I don't really know what this does, but the IDE suggested it and I'm just going to run with it! What could possibly go wrong? This is of course less ridiculous if some documentation about each routine is displayed as you up and down arrow through the choices.
nimish 10y ago
TS's typing is opt-in and it'll infer any (i.e. whatever) if you don't specify a type or it can't be inferred easily. Gradual typing is the best of both worlds here: you can quickly code up something and then later add types as you wish. Personally, I like types because entire classes of errors and bugs no longer apply without me having to think.
clavalle 10y ago
It's not about developer convenience, it is about performance. There are limits to the black magic that can be done with dynamic types to eke out performance that can be blown past with static types.
- rbanffy 10y ago
  JITs help a lot with that.
  - vardump 10y ago
    You got it exactly the opposite way. Because JITs do type inference and compile specialized code with an assumption type doesn't change, they stop working when type(s) change(s) dynamically. When that happens, JITs need to deoptimize code, which leads to a dramatic slowdown. In other words, changing type is the case where JITs don't help and their performance nosedives, because it breaks the underlying assumptions on type stability. Type stability is needed to generate compiled binary (x86, ARM, etc.) code.
    - rbanffy 10y ago
      No. Perhaps I wasn't clear. The code running under a JIT will behave like the static typed code when the code (and data) allows it while the programmer didn't have the additional burden of doing the type analysis for the computer. You may be confusing dynamic typing with weak types. Also, it's perfectly fine for the JIT to generate multiple code paths that are invoked depending on runtime types even when the source code declares a single one that acts on multiple types.
- qwertyuiop924 10y ago
  That has nothing to do with TS, which compiles to JS, which cannot make any of those assumptions.
discreteevent 10y ago
Do you tend to work alone? I don't really mind not having types in my own code because I know what and where everything is (at least until I have to come back to some old code). But I definitely want static types with tools that navigate quickly in other people's code because I really don't have the patience to manually reverse engineer it.
- qwertyuiop924 10y ago
  I do, but when I read others' (typed) code, I don't often find the types helpful... (Although that's usually C code, so that might have something to do with it)
rbanffy 10y ago
You are not alone. /me taps your shoulder.
pixie_ 10y ago
On the other hand I don't understand how anyone can work with a code base that is dynamically typed. I'm looking at a function parameter in a random file. How do I even begin to work with it? Unless you wrote the code yourself you pretty much have to run the program first and then REPL to see what the type actually is and the properties it exposes Slow, arduous, unnecessary. Also especially in the early stages of any development project I am refactoring like crazy as things come together. Static typing enables refactoring operations that are lightning fast with almost zero chance of error. Refactoring in any dynamic language is super error prone and leaves open the possibility for bugs that often show up unexpectedly at runtime. Do people who prefer dynamic languages actually use the benefits of dynamic typing in the first place? Changing variables from one type to another mid-stream. Dynamically adding properties to objects, using == instead of === etc.. Those things are a recipe for bugs, inconsistency, and unmaintainability right from the get go. Static typing doesn't feel intrusive, it feels like a flashlight. I don't like coding in the dark, feeling around for what everything is or is not.
- stcredzero 10y ago
  Unless you wrote the code yourself you pretty much have to run the program first and then REPL to see what the type actually is and the properties it exposes Slow, arduous, unnecessary. If the code is well written, then no, to seeing what the type actually is. In a good environment like you have in many Smalltalks, you should be able to compose some implementors searches, then quickly know what you're dealing with. Then you quickly and easily debug the system just to be rigorous. In environments set up by smart people, these actions can be surprisingly quick and easy. (In the same way that git allows for using certain information much more quickly, quantity can become a different quality.) Do people who prefer dynamic languages actually use the benefits of dynamic typing in the first place? Changing variables from one type to another mid-stream. Dynamically adding properties to objects, using == instead of === etc.. Those things are a recipe for bugs, inconsistency, and unmaintainability right from the get go. None of those things are the benefits of a dynamic language, except maybe as super debugging tricks. No one who really knows how to write in a dynamic language puts stuff like that in typical code! That you say this makes me think you don't know what you're talking about, or your main exposure to dynamic langs has been through the code of yahoos.
hota_mazi 10y ago
You're like this guy who doesn't like seat belts because he finds them uncomfortable :-)
KirinDave 10y ago
I don't really get why flow is okay when TS isn't? TS is gradually typed, you can work with unknown objects just fine and you don't have to dive fully in on your code. Flow and Typescript actually have very similar approaches. So why is Flow better? Have you used Typescript and Flow recently and done a comparison? > But I always see a flock of comments saying that they couldn't possible live without static types, and thanking TS for taking them out of the hell of dynamism, and wishing there was something similar in Ruby/Python/whatever. > I don't really get that. Because we're really tired of writing the same errors over and over. If it's just me, I can burn through a bunch of clojure code and I'm fine. But the instant I and someone else start to collaborate, subtle problems start to creep in. What's more, so much of my job these days is about serialization, deserialization, data validation, and error handling. None of my customers have any patience for buggy software and sites. And quite frankly, they shouldn't be. Static typing just makes these tasks easier. It makes them easier because it reminds you when forget. It forces you to think about every edge case that it's aware of, and it forces you to say something you mean and if you change that opinion, you need to make sure the code reflects that change. You talk about static typing like Java and C++ are your experience. Using Typescript (or flow) or a modern FP like Typed Racket, Ocaml, F# or Haskell where the type systems enable new means of expressing yourself is wonderful and refreshing, to me.
- qwertyuiop924 10y ago
  Fair enough. The reason I like Flow better is that it's better integrated into the rest of the JS/Babel ecosystem, so it gets out of your way to a greater degree than TS when you're either not using it or want JS ecosystem integration with JSX/whatever.
  - KirinDave 10y ago
    > JS/Babel ecosystem I mean, sure. In that when you use typescript you probably don't need/want Babel, as most of the ES6 features you want are part of TS already. > JS ecosystem integration with JSX/whatever. Typescript supports both react and non-react JSX natively, so perhaps this isn't a pain point anymore? Also: you get types. Good types are great.
stcredzero 10y ago
Man, I feel like the only one here who doesn't really like static types. I like dynamic typing just fine (it's crazy, I know: it must be the lisp influence). I was a Smalltalker professionally for almost 15 years. Let me say this about that: You don't absolutely need type annotations. That said, the information clearly has value in large projects, especially when they've been modified in production for a decade or longer. There were a couple of times when we really wished we could do certain refactorings, but we were blocked because we couldn't be 100% sure of what would end up in certain instance slots. Keeping your types straight by clear thinking and convention in Smalltalk is about the same cognitive load as wrangling the type system of C++ and avoiding the gotchas there. The difference is that the consequences in the former case are exceptions that show up in production, while in the case of C++, these become coding/dev-testing/debugging gotchas. In exchange for that, you could move considerably faster while breaking things in Smalltalk. There are also ways to have your cake and eat it too, in 2016, with regards to both type annotation and dynamic environments.
- jskulski 10y ago
  A bit off-topic, but I'm curious what your experience with Smalltalk was professionally. I've always viewed it with rose color glasses. It looks like a wonderful environment to work in, but I'm sure I'm missing something. It seems like Smalltalk was lightyears ahead with it's tooling. What do you work in now, do you find lack of tooling to be challenging?
  - stcredzero 10y ago
    There's clearly a set of lower expectations when it comes to tooling. Some of the menu-activated refactorings in VisualStudio 2015 amount to: We'll move text around for you, but you're kind of on your own. Whereas in VisualWorks Smalltalk, all of those came with iron-clad guarantees. I could whip up a custom SQL-query-like query of my loaded code, then have that pop up in a browser. Then I could compose that with another search or another custom query, then maybe even write a syntax-driven automated rewrite of the resulting browser contents. I currently work in C++ using Visual Studio. It's not that I lack certain tools. It's that those tools are themselves lacking. They are slower, less useful, less nimble, and less dependable than what I'm used to. Mostly, they are slower. When refactoring, it's like I'm using a Dremel, a hand-saw, and cheap bench grinder, where I really should have a full shop with a full set of tools, CNC machine, a lathe, and a 3D printer. Refactoring is literally 10X slower, due in large part to the higher cost of entry to hacking on programming tools.
duaneb 10y ago
Dynamic typing is fine until you have to maintain someone else's code. Then it's like pulling nails to get any certainty about how the code runs and productivity tanks.

edoloughlin 10y ago

Another Emacs JS dev here. I find Emacs + Tern works very well for me.

qwertyuiop924 10y ago
Cool. Is it better than JS2?

moloch 10y ago

Well TypeScript is sort of "optionally typed" (variables can have a type of `any`) it's also superset of JavaScript so any valid js is valid ts.

mschulze 10y ago

My experience: I don't get how in a project with several developers and maybe even teams dynamic types work at all. If a colleague writes a function/method that returns something, in JS, how do I know what it is? I have to read the function or its tests. With a statically typed language I immediately know the structure of the returned "thing" (don't want to say object) and can infer how to work on it.

jshen 10y ago
I've worked on a lot of big projects with both dynamic and static languages. I think what a lot of people that are used to static languages don't realize is that dynamic langauge users typically live inside of some kind of repl. The repl gives you immediate access to the thing returned and lets you inspect it and play with it. This serves the same purpose, albeit in a different way, as the IDE for a langauge like java or c#.
- mschulze 10y ago
  That's a good explanation, thank you. My experience in big projects with dynamic languages boils down to Angular which I didn't find very REPL friendly. BTW, with IntelliJ and its debug mode for Java we almost have some sort of weird REPL. By pressing Alt+F8 one can, during a breakpoint evaluate an arbitrary Java expression while accessing the values in scope. I use it a lot, despite having my types.
  - jshen 10y ago
    I use that in Intellij all the time, but it's very limited to something like pry in ruby.
  - qwertyuiop924 10y ago
    Angular was a Bad Idea. For so many reasons. I'm barely acquainted with it, but I could already go on about all the problems I had, which other, more experienced people also had. And I do a lot of Lisp programming in Emacs, where the support for REPLs and livecoding is ungodly. Really, really good.
  - Roboprog 10y ago
    Install Batarang in Chrome. the "$scope" objects are attached to the browser DOM, and the tool adds another tab to element inspection that shows you the data attached to each level, as well as references back up to enclosing levels.
jeremiep 10y ago
I feel this is just a myth. I'm constantly looking at the source even with static types. Unless you're having a Haskell-like type-system the function's signature will still miss most of what the function is actually doing. How do I know if a function does a network call? Saves a file? Changes the DOM? These are really important things to know when calling code and the type-system is completely oblivious about them. What I usually see however is that projects using static types frequently have at least twice the team size as the equivalent projects using dynamic types. Communication overhead follows, ownership fades and debt creeps in quickly. After a few month they usually have no traces of agility left.

johnfn 10y ago

Statically typed languages have a few large advantages over dynamic languages. These include: - Refactoring. Refactoring a large JavaScript codebase (> 100k loc) is nearly impossible and at best incredibly painful, error prone and time consuming. With static types, it becomes a trivial and straightforward process. - Your code is now more discoverable. You can easily find definitons, and discovering all methods and properties on an object is as simple as triggering an autocomplete pop up. - Code is now more readable. Objects are never opaque. You never have to dig through multiple calls just to see what the shape of an object is. It's all right there. For me, the killer app is refactoring. Writing huge amounts of JS is very painful to me because I refactor almost constantly as I add more code. Most dynamic languages have this problem. Static typing changes that completely.

jshen 10y ago
I just want to point out there is very little emporical data on this front which makes almost every statement along the lines of "static is better because ..." or "dynamic is better because ..." to be pure opinion.
jeremiep 10y ago
I don't get this. Most of the known refactorings can't be easily implemented by IDEs so you're left with the trivial ones like renaming or moving things. Static types won't help you refactor a monster class into a structure of arrays. It won't refactor your callback hell into coroutines. It won't refactor your "one-at-a-time" algorithm into batches. Yet these all yield more agility and performance. The thing is, I usually have so much less code when throwing static types out the window that refactorings become a non-issue. I get away with basic Emacs macros and unix tools.
- bsimpson 10y ago
  Or in a GUI: Apple-Shift-F Find: <old name> Replace: <new name> …continue working.
  - shados 10y ago

rihegher 10y ago

You're not alone, I'm fine with dynamic typing. And I'm sure lots of people were fine before TS came.

jeremiep 10y ago

Same here, I hate it when I land in a TypeScript codebase where they followed "clean code" and "best practices" and have nice OOP abstractions everywhere.. its always a kludgy monstrosity that yields everything but actual agility or performance. The whole "lets use classes in JavaScript" movement makes me very sad. Its as if today's web developers are now rediscovering the 90's and all the mistakes that were made back when OOP was the new shiny thing. I get WAY more annoyed fighting with TypeScript's type-system than fixing the rare runtime type error, which is usually trivial to find anyways. This all feels like a very superficial and inefficient way to achieve correctness. The real hard to find bugs come from state and complexity, both of which are completely ignored by static type systems. Instead I see the exact opposite: the new shiny typed abstractions introduce so much state and complexity that any advantage gained by having static types is lost there. I probably sound very pessimistic here; the older I grow the more I appreciate Alan Kay's quote about the internet and the web for being so damn spot-on.

TAForObvReasons 10y ago
The computer industry is the only industry that is more fashion-driven than women's fashion. -- Larry Ellison These cycles come and go. Sometimes static typing is hot, sometimes dynamic typing is hot. Best bet for pragmatic people is to figure out what works for you and run with it.
- qwertyuiop924 10y ago
  Indeed. But I'd quote Kay, not Ellison, myself. Personally, I wouldn't trust Ellison further than I can throw him.
RyanCavanaugh 10y ago
It's important to not conflate static typing with OOP. If you think about static typing only in terms of OOP, of course you're not going to like it - classes are not the right abstraction for many problems. The TypeScript compiler (which is written in TS) itself uses zero classes. There's no need to use classes to get static typing. If you're writing TS the "right way", you write the JavaScript you would have written anyway, and add type annotations to create contracts and descriptions of behavior.

niieani 10y ago

For me, it's not even about "typing" or even "checking for errors as you type". The killer feature is: almost never having to read library documentation. You type the code, and get suggestions for all the properties and methods available, along with all the possible arguments you are supposed to pass. Saves you a TON of time and context switching, so you can focus better on the task at hand. That alone makes TypeScript worth the trouble IMHO.

lloyd-christmas 10y ago
> You type the code, and get suggestions for all the properties and methods available, along with all the possible arguments you are supposed to pass. Only if the library itself is written in Typescript or the ambient definitions are perfect. Not necessarily a detractor from the language, but still a practical time sink given the current state of external typings. It's definitely getting better, but it's still quite far from a minimal nuisance.
Roboprog 10y ago
The "intellisense" crowd always kills me with this: I don't really know what this does, but the IDE suggested it and I'm just going to run with it! What could possibly go wrong? This is of course less ridiculous if some documentation about each routine is displayed as you up and down arrow through the choices.

nimish 10y ago

TS's typing is opt-in and it'll infer any (i.e. whatever) if you don't specify a type or it can't be inferred easily. Gradual typing is the best of both worlds here: you can quickly code up something and then later add types as you wish. Personally, I like types because entire classes of errors and bugs no longer apply without me having to think.

clavalle 10y ago

It's not about developer convenience, it is about performance. There are limits to the black magic that can be done with dynamic types to eke out performance that can be blown past with static types.

rbanffy 10y ago
JITs help a lot with that.
- vardump 10y ago
  You got it exactly the opposite way. Because JITs do type inference and compile specialized code with an assumption type doesn't change, they stop working when type(s) change(s) dynamically. When that happens, JITs need to deoptimize code, which leads to a dramatic slowdown. In other words, changing type is the case where JITs don't help and their performance nosedives, because it breaks the underlying assumptions on type stability. Type stability is needed to generate compiled binary (x86, ARM, etc.) code.
  - rbanffy 10y ago
    No. Perhaps I wasn't clear. The code running under a JIT will behave like the static typed code when the code (and data) allows it while the programmer didn't have the additional burden of doing the type analysis for the computer. You may be confusing dynamic typing with weak types. Also, it's perfectly fine for the JIT to generate multiple code paths that are invoked depending on runtime types even when the source code declares a single one that acts on multiple types.
qwertyuiop924 10y ago
That has nothing to do with TS, which compiles to JS, which cannot make any of those assumptions.

discreteevent 10y ago

Do you tend to work alone? I don't really mind not having types in my own code because I know what and where everything is (at least until I have to come back to some old code). But I definitely want static types with tools that navigate quickly in other people's code because I really don't have the patience to manually reverse engineer it.

qwertyuiop924 10y ago
I do, but when I read others' (typed) code, I don't often find the types helpful... (Although that's usually C code, so that might have something to do with it)

rbanffy 10y ago

You are not alone. /me taps your shoulder.

pixie_ 10y ago

On the other hand I don't understand how anyone can work with a code base that is dynamically typed. I'm looking at a function parameter in a random file. How do I even begin to work with it? Unless you wrote the code yourself you pretty much have to run the program first and then REPL to see what the type actually is and the properties it exposes Slow, arduous, unnecessary. Also especially in the early stages of any development project I am refactoring like crazy as things come together. Static typing enables refactoring operations that are lightning fast with almost zero chance of error. Refactoring in any dynamic language is super error prone and leaves open the possibility for bugs that often show up unexpectedly at runtime. Do people who prefer dynamic languages actually use the benefits of dynamic typing in the first place? Changing variables from one type to another mid-stream. Dynamically adding properties to objects, using == instead of === etc.. Those things are a recipe for bugs, inconsistency, and unmaintainability right from the get go. Static typing doesn't feel intrusive, it feels like a flashlight. I don't like coding in the dark, feeling around for what everything is or is not.

stcredzero 10y ago
Unless you wrote the code yourself you pretty much have to run the program first and then REPL to see what the type actually is and the properties it exposes Slow, arduous, unnecessary. If the code is well written, then no, to seeing what the type actually is. In a good environment like you have in many Smalltalks, you should be able to compose some implementors searches, then quickly know what you're dealing with. Then you quickly and easily debug the system just to be rigorous. In environments set up by smart people, these actions can be surprisingly quick and easy. (In the same way that git allows for using certain information much more quickly, quantity can become a different quality.) Do people who prefer dynamic languages actually use the benefits of dynamic typing in the first place? Changing variables from one type to another mid-stream. Dynamically adding properties to objects, using == instead of === etc.. Those things are a recipe for bugs, inconsistency, and unmaintainability right from the get go. None of those things are the benefits of a dynamic language, except maybe as super debugging tricks. No one who really knows how to write in a dynamic language puts stuff like that in typical code! That you say this makes me think you don't know what you're talking about, or your main exposure to dynamic langs has been through the code of yahoos.

hota_mazi 10y ago

You're like this guy who doesn't like seat belts because he finds them uncomfortable :-)

KirinDave 10y ago

I don't really get why flow is okay when TS isn't? TS is gradually typed, you can work with unknown objects just fine and you don't have to dive fully in on your code. Flow and Typescript actually have very similar approaches. So why is Flow better? Have you used Typescript and Flow recently and done a comparison? > But I always see a flock of comments saying that they couldn't possible live without static types, and thanking TS for taking them out of the hell of dynamism, and wishing there was something similar in Ruby/Python/whatever. > I don't really get that. Because we're really tired of writing the same errors over and over. If it's just me, I can burn through a bunch of clojure code and I'm fine. But the instant I and someone else start to collaborate, subtle problems start to creep in. What's more, so much of my job these days is about serialization, deserialization, data validation, and error handling. None of my customers have any patience for buggy software and sites. And quite frankly, they shouldn't be. Static typing just makes these tasks easier. It makes them easier because it reminds you when forget. It forces you to think about every edge case that it's aware of, and it forces you to say something you mean and if you change that opinion, you need to make sure the code reflects that change. You talk about static typing like Java and C++ are your experience. Using Typescript (or flow) or a modern FP like Typed Racket, Ocaml, F# or Haskell where the type systems enable new means of expressing yourself is wonderful and refreshing, to me.

qwertyuiop924 10y ago
Fair enough. The reason I like Flow better is that it's better integrated into the rest of the JS/Babel ecosystem, so it gets out of your way to a greater degree than TS when you're either not using it or want JS ecosystem integration with JSX/whatever.
- KirinDave 10y ago
  > JS/Babel ecosystem I mean, sure. In that when you use typescript you probably don't need/want Babel, as most of the ES6 features you want are part of TS already. > JS ecosystem integration with JSX/whatever. Typescript supports both react and non-react JSX natively, so perhaps this isn't a pain point anymore? Also: you get types. Good types are great.

stcredzero 10y ago

Man, I feel like the only one here who doesn't really like static types. I like dynamic typing just fine (it's crazy, I know: it must be the lisp influence). I was a Smalltalker professionally for almost 15 years. Let me say this about that: You don't absolutely need type annotations. That said, the information clearly has value in large projects, especially when they've been modified in production for a decade or longer. There were a couple of times when we really wished we could do certain refactorings, but we were blocked because we couldn't be 100% sure of what would end up in certain instance slots. Keeping your types straight by clear thinking and convention in Smalltalk is about the same cognitive load as wrangling the type system of C++ and avoiding the gotchas there. The difference is that the consequences in the former case are exceptions that show up in production, while in the case of C++, these become coding/dev-testing/debugging gotchas. In exchange for that, you could move considerably faster while breaking things in Smalltalk. There are also ways to have your cake and eat it too, in 2016, with regards to both type annotation and dynamic environments.

jskulski 10y ago
A bit off-topic, but I'm curious what your experience with Smalltalk was professionally. I've always viewed it with rose color glasses. It looks like a wonderful environment to work in, but I'm sure I'm missing something. It seems like Smalltalk was lightyears ahead with it's tooling. What do you work in now, do you find lack of tooling to be challenging?
- stcredzero 10y ago
  There's clearly a set of lower expectations when it comes to tooling. Some of the menu-activated refactorings in VisualStudio 2015 amount to: We'll move text around for you, but you're kind of on your own. Whereas in VisualWorks Smalltalk, all of those came with iron-clad guarantees. I could whip up a custom SQL-query-like query of my loaded code, then have that pop up in a browser. Then I could compose that with another search or another custom query, then maybe even write a syntax-driven automated rewrite of the resulting browser contents. I currently work in C++ using Visual Studio. It's not that I lack certain tools. It's that those tools are themselves lacking. They are slower, less useful, less nimble, and less dependable than what I'm used to. Mostly, they are slower. When refactoring, it's like I'm using a Dremel, a hand-saw, and cheap bench grinder, where I really should have a full shop with a full set of tools, CNC machine, a lathe, and a 3D printer. Refactoring is literally 10X slower, due in large part to the higher cost of entry to hacking on programming tools.

duaneb 10y ago

Dynamic typing is fine until you have to maintain someone else's code. Then it's like pulling nails to get any certainty about how the code runs and productivity tanks.