81–90 of 155 posts
Wait, what happens if you want keyword arguments?
`def greet(name: String, greeting: String = "Hello"): String`
will work for kwargs with default values — https://type-ruby.github.io/docs/getting-started/understandi...
Earlier quoted context omitted.
Type free languages like Lisp, Python and Ruby have faster software development times than languages that use types. The developers who are using the statically typed languages, which are slower to develop in, with are being pushed to use the faster languages. But those developers don't know how to code in type free languages. So they attempt to add the types back in. This of course reduces the software development s…
This is junk. Writing a type annotation takes basically zero time, then saves you time by preventing the runtime error because you forgot which variable was which, then saves you more time by autocompleting the correct list of valid methods when you hit dot. Acting like Go is comparable to JS is ridiculous; Go's type system is the only kind of type system needed in Ruby. Rust is a staggering outlier in complexity. An…
Stating that A is an integer isn't much of a issue but once you get a reasonably complex program and A now has a compound type made of 5 parts, it really does slow you down and it really does make you write considerably worse programs for the sake of passing a type checker.
Any commercial code will need to be unit tested so there is no time saving from finding runtime errors earlier and an any good IDE will detect the same errors and provide you with the same auto complete automatically for free without any type annotations at all. These are problems which exist solely in your head.
1 developer vs a whole team of developers. I think you need to face the facts.
There are studies comparing old dynamically types languages against statically type languages. They always show approximately 1/3 of the lines of code being used with 3x faster development times in the dynamically types languages. This isn't some new discovery.
Well even Python is strongly typed but for the sake of this we are discussing type complexity.
Honest question: I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context. But what is the point of the recent wave of types for python, Ruby, and similar languages? If it’s type safety you want there, there’s a bajillion other languages you can use right?
You could use an entirely different language of course, but that involves other changes and compromises.
Earlier quoted context omitted.
I’d love to hear from you or someone in your shoes: what are some patterns or examples of tests that are made redundant by types? “It has a field of type X” has never been a useful test for me, my tests are always more like: “if I send message X I get return value or action Y” … with my admittedly limited experience of types I don’t see how they replicate this. Therefore it looks like I’d only be “replacing” tests th…
One of the big advantages of types is documenting what is *not* allowed. This brings a clarity to the developers and additionally ensure what is not allowed does not happen. Unit tests typically test for behaviours. This could be both positive and negative tests. But we often test only a subset of possibilities just because how people generally think (more positive cases than negative cases). Theoretically we can do…
Honest question: I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context. But what is the point of the recent wave of types for python, Ruby, and similar languages? If it’s type safety you want there, there’s a bajillion other languages you can use right?
At least for Python (since I'm more familiar with Python code and the Python ecosystem): progressive typing lets you incrementally add typing to an existing Python codebase. So you can have at least some of the benefits of typing for new or updated code without needing to re-write in a new language.
You get the complexity and slower development times of using statically typed languages along with the bad performance of using dynamically typed languages.
Earlier quoted context omitted.
I agree somewhat, but I'd rather call it their brain adjustment than a religion though. I think about 99% of people who suggest to slap down types onto dynamic languages have already been using types since decades, or many years, in another language. Now they switch to a new language and want to have types because their brain is used to.
Nah. 99.9% of the people who wanted the addition of DryStructs to a codebase I worked on wanted it because they'd been bit, repeatedly, by someone sending one kind of object into a function rather than what the function accepted and it just not getting caught. A robust type system allows you to make "compiler errors" out of runtime errors. One of these takes *way more tests to catch* than the other. I'll let you gues…
Worth mentioning is Crystal lang: Ruby, with types!
How alike actually are Ruby and Crystal? I’ve heard the similarity is only skin-deep: similar syntax but quite different semantics. In other words, isn’t describing Crystal as “Ruby with types” similar to describing C++ as “JavaScript with types”?
So, you extremely rarely can run Ruby code in Crystal. But simple scripts are trivial to annotate. Larger apps won't require huge changes, but you're likely to run into dependencies you also need to port.
Earlier quoted context omitted.
keyword arguments are, internally, syntactic sugar over a hash. It probably doesn't easily work with typing the explicit values of a raw hash
This hasn’t been true since Ruby 3.0. Keyword arguments are a core language feature with their own semantics.
Honest question: I like typescript and I think it makes sense:, the web makes you married to JavaScript, so it’s the reasonable path forward if you want types in that context. But what is the point of the recent wave of types for python, Ruby, and similar languages? If it’s type safety you want there, there’s a bajillion other languages you can use right?
In large - and honestly even medium - and honestly-honestly even _not-small_ python projects, you often end up losing track of what stuff is. At one of my jobs, i was often plagued by not knowing if "f" - short for file, naturally, that part is fine tbh - was a string, an io-like thing, a path object, a file object, or what-have-you. Sure sure, some argue this is the magic of python - just try to do whatever you want…
But yes, there are multiple ways to solve communication problems.