5 ms·

> - if people enter or leave your team frequently: yes Interesting, I would put that one as a no, since introducing TS to you project means longer time train n

by Hurtak 10y ago

> - if people enter or leave your team frequently: yes Interesting, I would put that one as a no, since introducing TS to you project means longer time train new employees. On the other hand it will make sure their commits break something less often, so not so sure about this one

yuchi 10y ago
But you’ll end with more self-documenting code and more clear internal APIs. It’s a fair tradeoff IMHO.
cageface 10y ago
The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project. I wish I had something similar for all the Ruby code I write.
- RX14 10y ago
  It's not exactly what you want, but if you want a statically typed ruby-like you should check out crystal (http://crystal-lang.org/ http://crystal-lang.org/)
  - cageface 10y ago
    Crystal looks interesting but I can't really migrate to a new language. Something that compiles down to plain Ruby would be great though.
- chris_st 10y ago
  You might want to check out rubocop[1]. It does static checking, and we're pretty happy with it. 1: https://github.com/bbatsov/rubocop https://github.com/bbatsov/rubocop
  - RussianCow 10y ago
    Does it actually do static type checking? Because I don't see anything about types in the documentation. It looks like just a more sophisticated linter, which is very different from what TypeScript and Flow bring to the table.
    - chris_st 10y ago
      Ah, you're right. It's "just" a linter... but a pretty good one.
  - cageface 10y ago
    I started using rubocop earlier this year and I've become a huge fan. It's done a lot to improve the quality of my code and the consistency of code on projects with multiple developers.
- mendelk 10y ago
  Not sure if this will do, but there's Contracts for Ruby: https://github.com/egonSchiele/contracts.ruby https://github.com/egonSchiele/contracts.ruby
rubber_duck 10y ago
Learning time of the actual type system is nothing compared to learning/getting in to the code base if it's anything non-trivial. At the very least type annotations are compiler verified documentation which is a huge time saver, along with better tooling that lets you navigate trough the code more efficiently.
eyko 10y ago
> since introducing TS to you project means longer time train new employees. From my experience, even developers who have never used statically typed languages are able top pick up the Flow / TypeScript in a matter of hours. Not everything, but enough to barely have an impact on productivity. The main hurdles in the learning process as far as I can tell have been nullable types (smaller hurdle) and declaring types for external modules (big hurdle, many of them still don't fully grasp it). I've found Flow to have a much, much lower barrier to entry than TypeScript, and I believe it's because it's quite strict / sound as the author very well pointed out (slide 12 for example).
s_kilk 10y ago
> since introducing TS to you project means longer time train new employees Does it though? I mean, we're talking about intelligent beings who can drive cars and program computers, how hard can it be for them to spend an hour reading the typescript docs? I suppose it depends on ones definition of a long time.
- shados 10y ago
  Learning TS itself takes minutes. Probably -seconds- if you're familiar with Java/C#. The real learning curve is in the edge cases, of which there are plenty. Fighting with a 3rd party lib with incorrect type defs, dealing with cases common to JS that are hard to properly type (such as certain functional constructs), dealing with things missing from the TS compiler that are present in ES6/babel, etc. Those things are quickly going away and may eventually be a non-ssue, but as of today, they're very real. That's in contract with languages that have the type system baked in from the get go, where it wouldn't be an issue.
  - DJCordhose 10y ago
    IMHO the type system of flow and typescript are pretty different from Java/C#. Structural typing to name one and maybe the most important.
    - shados 10y ago
      they're very different if you take them in a vacuum, but they're nearly clones when compared to ML/Haskell/Scala-style type systems. Don't forget C# has some structural typing for some features (such as delegates)
whatever_dude 10y ago
Training is not a problem. Anyone who knows the basic of OOP can learn TypeScript in a day. On the other hand, giving them constraints (because of the type system) ensures their work is not breaking stuff along the way as they learn the ropes of the code base. From my perspective, setting up a build flow (dependencies, etc) is the biggest problem with TypeScript projects. If you assume that's already done in a given project, then the negative impact is gone and TypeScript only makes it easier.

by Hurtak 10y ago

yuchi 10y ago

But you’ll end with more self-documenting code and more clear internal APIs. It’s a fair tradeoff IMHO.

cageface 10y ago

The learning curve on something like TS for people already conversant in JS is pretty shallow. I think the time invested learning it will pay for itself very quickly on any non-trival project. I wish I had something similar for all the Ruby code I write.

RX14 10y ago
It's not exactly what you want, but if you want a statically typed ruby-like you should check out crystal (http://crystal-lang.org/ http://crystal-lang.org/)
- cageface 10y ago
  Crystal looks interesting but I can't really migrate to a new language. Something that compiles down to plain Ruby would be great though.
chris_st 10y ago
You might want to check out rubocop[1]. It does static checking, and we're pretty happy with it. 1: https://github.com/bbatsov/rubocop https://github.com/bbatsov/rubocop
- RussianCow 10y ago
  Does it actually do static type checking? Because I don't see anything about types in the documentation. It looks like just a more sophisticated linter, which is very different from what TypeScript and Flow bring to the table.
  - chris_st 10y ago
    Ah, you're right. It's "just" a linter... but a pretty good one.
- cageface 10y ago
  I started using rubocop earlier this year and I've become a huge fan. It's done a lot to improve the quality of my code and the consistency of code on projects with multiple developers.
mendelk 10y ago
Not sure if this will do, but there's Contracts for Ruby: https://github.com/egonSchiele/contracts.ruby https://github.com/egonSchiele/contracts.ruby

rubber_duck 10y ago

Learning time of the actual type system is nothing compared to learning/getting in to the code base if it's anything non-trivial. At the very least type annotations are compiler verified documentation which is a huge time saver, along with better tooling that lets you navigate trough the code more efficiently.

eyko 10y ago

> since introducing TS to you project means longer time train new employees. From my experience, even developers who have never used statically typed languages are able top pick up the Flow / TypeScript in a matter of hours. Not everything, but enough to barely have an impact on productivity. The main hurdles in the learning process as far as I can tell have been nullable types (smaller hurdle) and declaring types for external modules (big hurdle, many of them still don't fully grasp it). I've found Flow to have a much, much lower barrier to entry than TypeScript, and I believe it's because it's quite strict / sound as the author very well pointed out (slide 12 for example).

s_kilk 10y ago

> since introducing TS to you project means longer time train new employees Does it though? I mean, we're talking about intelligent beings who can drive cars and program computers, how hard can it be for them to spend an hour reading the typescript docs? I suppose it depends on ones definition of a long time.

shados 10y ago
Learning TS itself takes minutes. Probably -seconds- if you're familiar with Java/C#. The real learning curve is in the edge cases, of which there are plenty. Fighting with a 3rd party lib with incorrect type defs, dealing with cases common to JS that are hard to properly type (such as certain functional constructs), dealing with things missing from the TS compiler that are present in ES6/babel, etc. Those things are quickly going away and may eventually be a non-ssue, but as of today, they're very real. That's in contract with languages that have the type system baked in from the get go, where it wouldn't be an issue.
- DJCordhose 10y ago
  IMHO the type system of flow and typescript are pretty different from Java/C#. Structural typing to name one and maybe the most important.
  - shados 10y ago
    they're very different if you take them in a vacuum, but they're nearly clones when compared to ML/Haskell/Scala-style type systems. Don't forget C# has some structural typing for some features (such as delegates)

whatever_dude 10y ago

Training is not a problem. Anyone who knows the basic of OOP can learn TypeScript in a day. On the other hand, giving them constraints (because of the type system) ensures their work is not breaking stuff along the way as they learn the ropes of the code base. From my perspective, setting up a build flow (dependencies, etc) is the biggest problem with TypeScript projects. If you assume that's already done in a given project, then the negative impact is gone and TypeScript only makes it easier.