|
|
Re: The departure of the hyper-enthusiasts
|
Posted: Dec 28, 2005 5:27 PM
|
|
I see Ford can't do sarcasm or irony any better than he can do "raving lunatic". Ah well, sad -- pathetic, really -- but, his problem, not mine. Let's still try to address some issues:
> If you say it's all
> a matter of syntax, I should just accept it.
I understamd that reading comes very, very hard to you, poor dear, but DO try harder, please. My first mention of syntax on this thread was in the phrase "almost all the syntax choices". See that little, innocuous word *ALMOST*, baby? It *modifies* the meaning of the following "all", asserting that there ARE one or more counterexamples. Here, I was discussing my preferences, rather than the nature of differences (syntax) vs otherwise; specific examples I gave in the same paragraph covered both syntax cases in which I preferred Ruby's choices (more rigid capitalization, dollar stropping for globals, "open classes" syntax of which more later) and non-just-syntax ones (the flexibility of blocks).
Other posters have argued that blocks are also just a syntax issue, but there ARE also non-just-syntax differences, e.g what code is allowed to rebind which variables. Admittedly, this isn't a big practical problem; to quote Ian Bicking, "Syntactically Ruby is better in this respect; Python's functions are not as convenient as Ruby's blocks, though they are mostly equivalent in functionality". Again, note the word MOSTLY; it IS important.
Just as when I use the same word in another post of mine to this thread: "the difference is mostly one of syntax sugar". Get it? MOSTLY, not ENTIRELY.
So, if from among your many favorite lies you might be so exceedingly courteous as to remove this particular idiocy, that I ever said that it's ALL (as opposed to MOSTLY0 a matter of syntax, that would be a big, bold step forward for you; why, a few thousand big steps like that, and the kind people in the white smocks might even start consider taking you off a few of your meds, and wouldn't that be swell?
> > This implies that "mere mention" means something
> utterly
> > different for a method versus other attributes.
>
> I was wondering, could you clarify something: is it, or is
> it not syntax when you have to juxtapose parenthesis to
> call a function? On the one hand, you say it is, on the
Yep. Essentially, a statement such as "x = y" in Python always parses to "bind name 'x' to the same object to which 'y'" is now bound. In Ruby, it can parse to that OR to "call method y without arguments and bind name 'x' to the object that is the result of that call"; you cannot tell without looking more widely beyond that statement, in order to learn whether y is a method or a variable. Similarly, in Ruby you cannot know, without looking more widely, if 'x=y' or 'x=y()' mean the same thing or not; if y is both a local variable and the name of a method, then both syntax forms are correct, and mean different things -- if y is just a variable, the second form is incorrect -- if y is just a method, both forms are correct and mean the same thing.
> other, you say that Python looks at all the attributes the
> same, regardless of whether the attribute is a callable.
> If Ruby looks at them differently, is this only a matter
> of syntax. Just want to understand your view on it.
When syntax is context-sensitive (you need to look around more widely than just the local statement in order to parse something correctly), it can be handled by many tricks that may not _feel_ like they properly belong in a parser, because ordinary parsing techniques are best at handling context-free grammars, and often stumble on context sensitive constructs. A classic bad example is in good old humble C, where you cannot possibly tell "locally" (i.e., in a context-free way) whether 'x*y;' is to be parsed as "multiply value x by value y and ignore the result', or 'define y as a pointer to a value of type x'... it all depends on whether a 'typedef' for 'x' is in scope; a C compiler typically kludges around that by incrementally maintaining a symbol table during parsing and having the parser (indeed even the lexical scanner!) rely on that. Similarly, you could use an incrementally maintained symbol table to deal with Ruby grammar's context-sensitivity (and there may be other good approaches, such as compiling "lookup name y" to different operations/bytecodes depending on whether y is allowed to be either variable or method, must be a method, or must be a variable).
Still, even though some parsing kludge or other can almost always be found to work around parsing problems with context-sensitive syntax, one good thing about context-free syntax is that it makes things easier for a human reader: an expression or statement can be parsed by the reader WITHOUT needing to study potentially-unbound amounts of context. Being able to parse the code unit may of course not tell the reader all they'd like to know -- e.g., even if one knows that "x=y" syntactically means "bind a reference &c", it may still be useful to know what, *semantically*, y is expected to refer to at this point. Still, the ability to parse the code is a good start, and sticking to context-free grammar helps with that;-).
> BTW, I did not say there is no reason I like Ruby that is,
> essentially, a syntactic difference with Python. Of
And I never said you didn't: on the contrary, most examples you gave ARE such syntax differences.
> course, some things reduce to syntax, but all
> hardly do.
Bingo! That's exactly why I said MOSTLY instead of saying ENTIRELY. I understand that you have no personal experience with something known as "common sense", but I earnestly assure you that anybody with even the slightest touch of it would not feel a need to keep repeating the very point I make even while trying to attack me (be it with ferocity, as previously, or with attempted sarcasm, as here).
> Is single versus multiple inheritance a matter
> of syntax?
No, of course: this is an actual semantic restriction of Ruby when compared to Python. Most people program in Python, most of the time, with single inheritance and maybe a touch of mixins, as you can have in Ruby; but when some rare situation really calls for "full" multiple inheritance, it's right there -- not just in syntax, but in semantics -- like in Lisp, Eiffel, or C++. I do understand somebody preferring a language which lacks a powerful tool that is rarely required, of course.
> Are closed versus open classes a matter of
> syntax?
Of course, what else? I explained the Python syntax you need to use in order to add a method to an existing class in my very first post to this thread, and I quote: "you have to 'def' the method's function and then assign it to TheClass.methodname" (I did that in the context of explaining that this is one of the few cases where I like Ruby's syntax choice over Python's).
For example, consider the example at http://www.rubygarden.org/ruby?AdaptorPattern where a radius method is added to existing class SquarePeg:
class SquarePeg
def radius
Math.sqrt( ((width/2) ** 2) * 2 )
end
end
I think this syntax is wrong and they mean @width, but, hey, THEY are the Ruby experts, I'm just copying and pasting;-).
The normal Python syntax for this would be:
def radius(self):
return math.sqrt(self.width**2/2)
SquarePeg.radius = radius
Some would prefer a different syntax in Python:
SquarePeg.radius=lambda self:math.sqrt(self.width**2/2)
but I find the normal def+assignment more readable.
What else are we seeing here, except for syntax differences and variations, pray?
> You are the one who said it's pretty much a matter
> of syntax,
If you're referring specifically to the two languages' different approaches to "how do I add a method to an existing class", I did in fact say it's JUST a matter of syntax, and I have just shown an example.
> among other things, of course. My argument is
> that saying it's a matter of syntax obscures some
> important points.
What "important points" does it obscure to mention that Ruby's "open classes" vs Python's "assign function to class attribute" IS indeed a matter of syntax?
If you're referring to the overall language difference between Ruby and Python, saying it's JUST a matter of syntax would be a tad too strong, but saying it's MOSTLY syntax, or NOT MUCH MORE than syntax, which are exactly the phrases I used, is smack on target. In my posts in this thread, and otherwise, I have repeatedly mentioned some other minor differences, for example that [Ruby's] "inheritance is single (most will hate this, some will love it)", and also the "philosophical difference" as well as my hope that pragmatism by sensible people on both sides makes the latter nearly irrelevant.
> I think you should be careful about saying it.
Considering your over-the-top hostile reactions, and the sarcasm you so unsuccessfully you attempt now, it's obviously useles, where YOU are concerned, for me to use my habitual large amount of care in expression (saying ALMOST all, *not* ALL; saying MOSTLY, not ENTIRELY; saying NOT MUCH MORE, *not* NOTHING MORE; and so on, and so forth): I am describing exactly and precisely my observations, preferences, and opinions, and yet you take fire like a short-fuse ballistic rocket. Clearly, thus, you are a hopeless case, and your recommendations are just as useless as the rest of your rants or your feeble attempts at irony.
> And, lest we forget, you were responding to Bruce, who I
> think should be taken to task for labeling a broad group
> of people as hyper-enthusiasts in a derogatory fashion.
I think he is quite accurate in his characterization of some people who show over-enthusiasm for some "new" technology or other, yet are quite prone to jump from one to the next. He never said nor implied that the characterization applies to ALL who like Ruby -- and I'm sure, for example, that he holds Andrew Hunt in just as much esteem as I do -- it really takes a warped brain like yours to misread Bruce's well-expressed words in such a distorted way.
> For whatever reason, you don't feel compelled to castigate
> Bruce for what he says,
What about the fact that he's said things I may agree with, and has expressed them with his usual precision and elegance, in any case?
> but you are no-holds-barred in
> your over-wrought, emotional, egoist tirade against me. Am
Well, YOU are the one who attacked me personally, insulted me, and even claimed I deserved being slapped, a claim for which you have now ``apologized'' only in a context of weak, sadly misfiring irony and sarcasm. Does it surprise you that personal attacks like this can easily make the people you're assaulting, and their friends, into sworn enemies of yours, *most particularly* when they are so utterly baseless and unjustified as I've carefully them to be, over and over again, not least in this reply...?
> Ruby. I'd like to point out something about blocks: with
> Python, you either have to nest definitions of functions,
> or pass some number of args to get the value of the
> "closure" that you get with Ruby blocks. To me, this can
You can equally well pass args to Ruby blocks as to Python functions, that's a wash. Instead of writing the "block's" code in braces or do/end right after the call to which you want to pass the block, you write the code in a def just BEFORE the call, then pass it in the call. E.g., it's:
j=23
zip.zop(1,2,3) do |i|
i+j
end
versus
j=23
def _block(i):
return i+j
zip.zop(1,2,3,_block)
or, as lambda-lovers would have it (not me...),
zip.zop(1,2,3, lambda i:i+j)
The "closure" effect is the same in both cases -- variable 'j' defined "outside" the block is visible "inside" it. The one non-syntax difference (that doesn't show in this case) is that if the block assigns something to j this directly affects the "outside" variable, while in Python it would HIDE it and define a new local variable. One more example of the fact that Ruby's not "afraid" of context-sensitivity: inside a block, "j=55" means "j is a local variable bound to value 55" *IF* there is no OUTER variable named j, but if there is it means "rebind outer variable j to 55". Inside a Python function, "j=55" defines a local variable, period, no need to look at surrounding context ((save for the deuced "global" statement, which I've often mentioned as the worst aspect of Python;-)).
> become significant. One, the value of an anonymous bit of
> code is high. I don't have to worry about naming it, or
I never could understand this obsession with anonimity, though it's shared by a highly vocal minority of Pythonistas currently fighting to make "lambda" remain in the language.
Naming a "throwaway" object, such as a local function or a loop control variable, never caused ME any worry in my life...
> how that might impact my interface, because the real focus
> is on what the code does, not the function identifier.
Use a function-name starting with underscore ("private" by Python convention) and nobody will FOCUS on it at all;-).
> It seems that you realize this, from what you wrote. So,
> while you may be able to accomplish the same thing in
> Python, it's definitely not as simple. This is a
It's TRIVIAL, except for the ability to rebind local variables of the surrounding scope, and that of having anonymous blocks that aren't just expressions -- which aren't "make-or-break" language features.
> difference that may be huge or small, depending on the
> context. It's a difference that is important and
It's TINY, therefore it's NOT important at all.
Anybody so crazy as to base their language choice, EITHER WAY, solely on "X lets my block be anonymous, Y requires me to name them", instead of pragmatics (richness and availability of libraries, tools, ports -- performance characteristics -- etc etc), as I've been advocating in this thread, would be making a really weirdly-based choice.
If a specific guy know he's so utterly idiosyncratic that such minutiae, rather than pragmatic considerations, are going to drive his choices, he really has no alternative to studying every single minute, obscure, microscopic language detail (and specific language versions, too, because such things may well change in minor versions) -- who else but such a weirdo could possibly predict that, say, he's liable to fall so madly in love with Python's 3-argument 'pow' (i..e, pow(a,b,c) meaning the same as (a**b)%c) that they will refuse to use any other language evermore?-) To most people, it's a tiny thing, relevant only if you do a LOT of modulo-arithmetic [it allows super-fast implementation of "raising to power" even when b is huge, as long as c is reasonably small -- hardly an issue most programmers CARE at all about...]. Minutiae such as the ability to keep blocks anonymous, rebind outer-level local-variables, or even having full multiple inheritance, are roughly at the same "most people, quite sensibly, care microscopically much" level of importance, i.e., close to nothing.
This is completely different from comparisons between, say, Java and Python (or Java and Ruby, or C# and Python, etc). Here, the dynamic versus static typing makes the choice much more important (and, unless you have strong opinions on this specific issue, difficult); syntax considerations are the least of your worries (and in many cases, funny enough, so are pragmatics, since if it's the pragmatics of running on JVM or CLR that you crave, Jython or IronPython [and, I imagine, the Ruby equivalents to those] let you have those pragmatics while using Python as the _language_...!-).
> shouldn't be obscured by someone saying it's all a matter
> of syntax. I'm pleased to see that Python will be
> implementing "blocks" of the type Ruby has. I think Python
> will be a better language because of it.
I'm not sure where you got this impression, not even of what exactly you mean by this "Python will be implementing blocks of the type Ruby has", but I'm pretty certain you're most likely entirely wrong in this matter.
> I'm glad Guido won't be removing map or filter. I
Again, I fear you've been misinformed; for the current plans, see <http://www.python.org/peps/pep-3000.html#built-in-namespace>
(of course, what will happen is that they'll be moved away froM *built-ins*, since LCs and genexps do essentially the same jobs; they may well move into a suitable 'functional' module in the standard library).
> regular expressions are first-class objects, and variables
They are first-class objects in Python, too -- assign them to any variable, pass them as arguments, put them in containers, return them from functions, and so on, and so forth. You use re.compile to *build* re objects, just like, say, you use array.array to build array objects, set to build set objects, etc, etc.
Maybe you mean that what you appreciate is that in Ruby regular expressions are *built-in*, so you don't need to import anything, and may use global variables such as $~ and $& and $' (etc) to study a match.
Of course, though this enrages you, this IS a syntax level distinction, you know;-).
> a difference that could be highlighted because it could be
> important to someone.
Everything could be important to someone, if that someone is enough of a weird fanatic; therefore, by your reasoning, any comparison between two languages must consist in posting the entire reference manuals for both languages, and presumably their libraries too. *PUH-LEEZE*.
Alex
|
|
Previous Topic
