Hacker News Reader

Comment by tptacek | Hacker News Reader

Yes, and, just to keep this clear: that debugging (or unit-testing-for-typos) time is coming out of your prototyping budget. Your Ruby program will fail to run for stupid reasons the first time you run it, which is not the experience Java and Go and Rust programmers have. I just remember when I first picked up Go, after about 5 years writing Ruby exclusively, how amazing it was that all my Go programs "worked" the first time I ran them. Obviously, they had bugs. But they didn't blow up for stupid reasons.

I'd been a C/C++ programmer for about 10 years! I guess I just forgot that compilers can catch typos if you let them.

View on HN

> Your Ruby program will fail to run for stupid reasons the first time you run it, which is not the experience Java and Go and Rust programmers have.

I know exactly the feeling, but I don't think it's just the types that give it but that it's compiled. I similarly moved on from ruby after 5 years but to Elixir and was similarly surprised to (re-) learn that a simple compile step catches so many braindead typos, misnamed variables, not imported function calls, and the like.

Types go above and beyond this, but I think there's a huge step up just going from interpreted to compiled.

I know a lot of people in the Ruby community tend to believe in using text editors with limited (or no) semantic understanding of the code. I've found that using, for instance, JetBrains Rubymine tends to make typos and related bugs apparent as they happen. Not to mention providing autocomplete that usually feels like using a statically typed language.

New to Ruby, veteran Java/C++, while I'm liking what RubyMine adds, it's nowhere near what I get from a simple language with a simple type system like Java.

The ability to refactor, for one.

I think this is a Ruby thing more than a dynamic languages thing. (Not exclusively a Ruby thing mind; Javascript code is also always full of weird edge cases and gotchas.)

I wouldn’t necessarily recommend it, but I have written 500-line Python programs without executing/testing any functions along the way, that “just worked” the first time I ran them with no serious bugs. And not because I am especially clever or have an amazing memory or unusual attention to detail, but just because the code is easy to make clear and straightforward.

(But this was just with basic data types and a few standard library modules; dealing with other people’s poorly documented / confusing APIs makes this gets a lot harder.)

You never had a go program fail to compile, only to fix the problem then try to compile again? Replace 'run' with 'compile' and you could still type a bunch of go code and have to make changes before you deploy or no?

Tooling makes this argument moot. I use Ruby and TypeScript, both with VSCode. The experiences are vastly different. Ruby is slow and difficult to work with, and TypeScript is a breeze. I don’t have to wait for my TypeScript to compile before it tells me about the typo I have, the editor tells me immediately after typing the word.

It's odd to complain about the first run not working, when the first run is significantly earlier. I'd also say the interactivity of Pry and binding.pry more than compensates for anything lost by not having a compilation step.

I’d argue that type checking combined with editor auto completion leads to faster development.

The feedback loop is within your editor, that’s a step before the app console!

100% going from Java+IntelliJ to Ruby+VSCode was shocking. In regards to tooling, the developer experience is way behind with Ruby. Sure there’s a lot more boilerplate to look at, but with tolls you don’t actually end up writing much. And then you get refactoring tools that are actually super useful and robust.

Prototyping in Java is as fast as prototyping in Ruby once you understand how to use the tools equivalent to Pry in Java, and standard types instead of rolling your own types. JIT isso fast today the 20ms required to JIT what you type is immaterial.

More so now with better type inference and repl integration.

What REPL do you use on the JVM? I've added JRuby to Java projects in the past just to get a REPL.

The one that comes with it, starting with Java 9, jshell.

Before that, there was the Rhino and Nashorn ones, which although JavaScript based, did the job.

Not strictly Java, but Groovy is a great environment to prototype on the JVM. Prototyping was lightning fast and turning it into Java code was pretty quick too. There’s great IDE support for it too (IntelliJ’s Groovy scratches).

These days Kotlin is also pretty good. Perhaps not quite as fast to prototype but there’s little need for converting afterwards.

Yes, add an environment like BeakerX [1] (essentially, Jupyter notebooks) and it's quite amazingly good to figure out your approach even if you intend to write Java.

[1] http://beakerx.com/

Reply on news.ycombinator.com