Hacker News new | comments | ask | show | jobs | submit login

> Most “scripting” languages don't support annotations for checking parameters and return values

I coded in Java for many years and Ruby for the last several, the lack of explicit type checking in method signatures or via annotations built into Ruby has not gotten in the way enough where I felt I needed to add something to decorate methods to do some generic form of type checking in Ruby. When I really need to check the type of an object sent into a method, it is typically a method that can handle different types, and in that case, I'll use respond_to?(...) to see that an object passed in as an argument responds to a method, use a case statement, is_a?(...), etc. but that is certainly not on every method- probably more like 1 in 20-30 methods.

Also, in the comparison section of the doc, OCaml and Python were represented, but not Ruby. As of late 2013, there are more jobs containing "Ruby" in the job description than "OCaml": http://www.indeed.com/jobtrends?q=ocaml%2C+ruby&l= So, imo it should give Ruby some love with a comparison.




As you wish! We now have two Ruby examples on the home page. You may not call it love. <-:


Thanks, but may want to correct:

method_as_fun = o.my-method

which should be:

method_as_fun = o.my_method

and the examples themselves just look a little crazy, imo. Not crazy because of what you are trying to do, but in how you are trying to do it. What was the intent of calling a method that defines an argument without an argument? That's not a problem of the language; that's just an error in coding. There are all kinds of things in Ruby to handle method definition. Arguments can have defaults. You can use splat and unsplat to handle unspecified arguments and composing arguments of various # on the fly. You can pass in blocks specifically (&something) or optionally (yield, etc.). Procs allow argument sillyness and returning the parent method by explicit return in the proc body, lambdas don't, etc. Ruby is a great language, and you should give it a college try for several months to get the hang of it.

By the same token, I have no clue what you are trying to do here:

def f(x); def g(y); x + y; end; g(2); end; f(2) # undefined local variable or method `x'

You can define methods on object instances, if that is what you are getting at (define_method/class_eval/etc.), and getting familiar with blocks, procs/lambdas might help. It isn't JavaScript, but I can't think of that much that I couldn't do in Ruby (barring high performance, compile-time type checking, etc.)


I appreciate the examples may not be working for you. We'll try to improve them.

However: Some of our programming environment's server infrastructure is built in Ruby (mainly because it has great git support, and we commit all edits to repos). One of Pyret's lead developers spent over a year on a widely-used RoR system. We've given it far more than the old collegiate try. Some of us have lived in it.

If you're happy with Ruby, great! We're not trying to convert you. But there are people who would find the Ruby code we've written "natural" and the resulting behavior thus unnatural.

We've had the same conversation with lots of JavaScript and Python users based on our semantics work (http://cs.brown.edu/~sk/Publications/Papers/Published/gsk-es..., http://cs.brown.edu/~sk/Publications/Papers/Published/pclpk-..., http://cs.brown.edu/~sk/Publications/Papers/Published/pmmwpl...). Some people are appalled, others don't get the point. [This may be correlated with their reaction to Gary Bernhardt's WAT talk.]

But you also don't get partial static type-checking, etc. Again, those are features that don't appeal to you, and that's perfectly cool.


Thanks for the feedback. I think I responded to another comment that gave very similar feedback as you, so I'm just going to link to it here:

https://news.ycombinator.com/item?id=6708420




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: