101–110 of 129 posts
I put this question also on Stackoverflow: http://stackoverflow.com/questions/3584945/non-technical-ben...
Earlier quoted context omitted.
About point 2: the author is probably ignorant of ast module ( http://docs.python.org/library/ast.html ), which allows the programmer to take any ast and recompile it to anything he/she wants (in runtime, unlike Lisp macros, but alike parse tree and ruby2ruby in ruby). This feature allows you to transform things like "1, minute" into "Minute(1)", enabling dsls, and "wrecking havoc" all over. In ruby, you don't have t…
So "the author" is Alex Martelli, a long -time Python user, contributor, and winner of the 2006 Frank Willison award which is given each year for outstanding contribution to the Python community. I highly doubt he's "ignorant" of anything when it comes to Python... A better theory is this article is from 2003, but the ast module was added in Python 2.6, which was released in 2008. (I agree with everything you've said…
I seriously did not want to imply (the incorrect fact) that the author was ignorant in general, but of a single matter (which is kinda unknown, so I'd expect most be to be oblivious to it).
I am equaly sorry for the bad choice of words...
Earlier quoted context omitted.
It's the inconsistency that bothers me. In Python, you can make anything callable by providing a __call__() method, and the parentheses will work as expected. This makes functions fungible with anything , including any object or anonymous function. In Ruby, only methods are callable, and everything else must be called with the call() method, which means you can't use one in a place where the other might be expected.…
You can also make anything callable in Ruby: just provide a call method. The parenthesis will still work as may be expected in Ruby, but, as several folks said before: in Ruby parenthesis are not used to call anything. A method is called simply be mentioning it. Anything that follows is an argument and sometimes parameters are needed for disambiguation of the parameters. This is counterintuitive, only because it diff…
In that sense, I see why it's not so bad; the difference between methods and anonymous functions is very explicit, and when you want to pass things around, it's likely that you will have target code which expects a Proc object and source code that generates it. Perhaps it's not so bad because there are few legitimate use cases, if any, for transporting a method when an arbitrary block is expected.
Earlier quoted context omitted.
Because () doesn't call a method, it's simply used where a method call occurs. To call a callable object, you use #call or (as mentioned by epochwolf) #[], the latter of which I personally detest. It's fun to contrast this with Lua, by the way.
It's the inconsistency that bothers me. In Python, you can make anything callable by providing a __call__() method, and the parentheses will work as expected. This makes functions fungible with anything , including any object or anonymous function. In Ruby, only methods are callable, and everything else must be called with the call() method, which means you can't use one in a place where the other might be expected.…
As wycats pointed out in a post earlier this year (http://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-orie...), the reason you don't need to explicitly call #call on methods is that Ruby is designed for the common case of calling methods. In addition, it's uncommon to even explicitly use #call or #[] on Procs since calling them is built into the language via yield.
Earlier quoted context omitted.
Are you actually passing around methods in Ruby and, if so, why? As I've pointing out in the past ( http://news.ycombinator.com/item?id=1141245 ), passing around methods is very rare in Ruby due to the flexibility of Procs.
Interesting! I am a half-breed; I write Python at my day job and Ruby in my personal projects. You seem to be suggesting that I am sort of making a mountain out of a molehill. Can you perhaps elaborate on this? I have definitely felt this pain before; I'm not just complaining about it because I "like the Python way more." But if I'm not using Ruby "as intended," I would like to know how I should be using it instead!…
Also, see wycats post: http://yehudakatz.com/2010/02/21/ruby-is-not-a-callable-orie...
The title made me nervous that this would be run-of-the-mill fanboy garbage. But I trust the author (Alex Martelli), so I read it, and I'm glad I did. It's reasonable and sane. My two big take-away points: 1) It's very nearly a wash. Ruby and Python are so close together (beneath any superficial differences) that distinguishing is almost an exercise in futility. 2) The key thing about Ruby he doesn't like is its "TOT…
We run probably one of the largest Ruby production systems that has ever been made and the dynamism and "monkey patching" are used daily to skillfully make the language better and better over time for the tasks that we solve. It's absolutely crucial to teams that internalize it's power and pitfalls.
The more dynamic (powerful?) the language the more leverage good, experienced developers have. They can achieve results in 10 lines of code that are hard/impossible in more static languages (closures, meta-classes etc.). The other edge of the sword is that one dud developer can bring your whole stack down by being too smart for their own good. The more dynamic the system the greater the risk. In Ruby as is pointed out you can have a developer on the other side of your code base royally screw you because he wants feature X of sequences to act differently.
As with all things it's a balancing act, how smart are your devs, how much time can you spend testing and how strict are your coding standards.
Earlier quoted context omitted.
My impression of the Ruby community, especially the OSS part of it, was that they were explicitly more about tinkering than enterprise. Certainly characters like _why were in that camp. I don't entirely disagree with the larger sentiments, but I worry about the tone of the word 'tinker'. That is, the Ruby world is full of playful characters, and often displays a spirit that is far from corporate. However, many Ruby (…
I agree completely. I tend to dislike the phrase "enterprise development" anyway, because it implies that somehow our programming is suddenly different just because a company uses it. But, I try to write for my audience.
Most of it makes sense, or seems obvious, but your SAAS companies don't typically offer Active Directory (or LDAP) integration, as most companies aren't willing to expose their directories outside of their firewalls.
Auditing levels tend to be more paranoid, and need to be structured so that they can be fed into (or are at least sane enough to be read by) the industry-standard log analysis tools.
Admin accounts are typically transitioned to in-house users, or employees of the company, instead of being managed by the man behind the curtain (you).
So, perhaps it's that my experience is different than the majority of HN here, but to me, 'enterprise development' is a dramatically different process than what those guys at 37Signals do, for example.
Earlier quoted context omitted.
Both languages offer the unvigilant programmer plenty of opportuities to shoot off his foot. If you're really concerned about this you should take a look at scala. I'm amazed at how much easier it is for me to maintain my own scala code than either ruby or python.
and so much harder for me to maintain someone else's scala code. It feels like statically typed perl, but that's just mho.
What other "someone else's" Scala code have you actually had to look at and maintain that you had problems with? In my experience, I only have a hard time understanding Scala code when it is doing something I'm conceptually unfamiliar with, usually something in the functional world that I know little or nothing about.
The title made me nervous that this would be run-of-the-mill fanboy garbage. But I trust the author (Alex Martelli), so I read it, and I'm glad I did. It's reasonable and sane. My two big take-away points: 1) It's very nearly a wash. Ruby and Python are so close together (beneath any superficial differences) that distinguishing is almost an exercise in futility. 2) The key thing about Ruby he doesn't like is its "TOT…
It's just that Python hasn't ever had an ethos of monkey-patching.
Ruby and Python are so similar, in fact, that I'm really surprised that there is no ongoing effort to merge them together. They could really use one another's libraries and various VM implementations, for example; even the parsers are almost identical. The only things that are really "different" between Python and Ruby are topical features of the grammars of each, that mostly disappear once the code has been AST-tran…
I have been successful at learning a variety of languages. Ruby was difficult for me because it is so similar to Python and yet so different. You have almost the same syntax getting very different results. So if you come from Python you get the exact opposite experience to the principle of least surprise. On the other hand, if you move from OCaml or Erlang there are no surprises because the syntax is different enough that there are no pre-expectations.
Also, metaprogramming in Python and Ruby are quite distinct. The way Python went about it using metaclasses and decorators is very different to the monkeypatching you get in Ruby, so I don't expect the AST results to be that similar for idiomatic code in both languages.