On 29 Nov 2010, at 04:40, Tim R. wrote:
crap reproduces like a virus.
A toolbox certainly OUGHT to tell me off if I try to unscrew a slotted head
screw with a Philips screwdriver, if that saves me from taking a chunk out
of my hand as I do it.
I wouldn’t claim to be a good programmer, but I’m certainly a
knowledgable one and that in large part because I’ve worked with
languages which did their best not to get in my way. That has certainly
resulted in some hideous abominations at various times but each of these
has been deeply instructive and subsequent reflection has helped advance
my knowledge and improve my instincts. Had I pursued the safer course
and languages which insist on particular orthodoxies my coding life
would have definitely been much poorer.
Or to stick with your analogy: whilst it’s true that a philips
screwdriver happens to be a very good fit for a philips head screw, in
the absence of that screwdriver it’s better to know how to use another
tool to achieve the same effect than to sit there worrying about how
inappropriate your tools are. After all no toolbox can ever have every
tool you might need, and the more tools contained in the toolbox the
more knowledge is required before you can start using any of them
competently.
Ellie
Eleanor McHugh
Games With Brains
twitter: @feyeleanor
raise ArgumentError unless @reality.responds_to? :reason
Eleanor McHugh wrote in post #965090:
…the more tools contained in the toolbox the
more knowledge is required before you can start using any of them
competently.
I don’t think that is logically correct. As long as you can use some
tools, it is irrelevant whether there are others in the box, as long as
when you want to use your tools nobody else has removed them.
The analogy however is fundamentally flawed. Programming is different to
other areas of human endeavour. You can botch things with entirely the
wrong tool and the magic of computer chips covers the whole thing up.
You may just notice slower performance, more memory usage etc but
chances are you won’t.
If Ruby gives you more tools, so that two different artisans appear to
be doing quite different things when they are actually trying to achieve
the same ends, the impacts are only likely to arise when other people
start to look at the code later. That problem however started many
decades before Ruby and Python arrived on the scene.
A better analaogy is when you buy a box of assorted chocolates because
there are a couple that you really love but can’t buy by the bag.
Normally you can’t afford to buy confectionary and waste it but Ruby is
free. So all that matters is whether you get the items you’re after.
Thank you everyone for taking the time to reply to my question. This has
been a very enlightening experience for me.
On 29 Nov 2010, at 22:21, Michal S. wrote:
The python zen does not work for me at least. Take a small example:
itself but the length can still be determined (possibly to be 1 or or
0 on scalars).
Funnily enough this “special case” style is one of my single greatest
annoyances with OO in Go, and yet to the Python programmers who
constitute a large part of that community it’s considered a plus point.
Sure, in Python you can’t just monkey-patch a len to something that
could have it determined but does not implement it so to have only one
true way you need a procedural len() which goes against OO.
Technically this doesn’t break OO per se, rather it’s a special form
known to the compiler/interpreter which mirrors object manipulations as
the application of functions rather than the sending of messages.
Instead of asking if a particular object can respond to a particular
method this styles asks whether that object is the right “shape” to be
passed to a given function. From what I recall of Python it doesn’t do a
huge amount with this concept, but Go really runs with it thanks to its
combination of interfaces and type inference.
This is great for a statically typed language that wants to feel like a
dynamic language, but the downside is that a programmer needs to keep
that model in their head as well as any others that the language
supports. As both Python and Go allow message passing syntax as well
that means supporting two world views where in Ruby or Smalltalk we’d
only need the message passing model.
In Ruby you have “string”.length and you can always write procedural
len() if it makes your code look nicer and you can also add length to
any object you want (well, except for integers but you could use some
voodoo if you really insisted).
One of the great strengths of Ruby is that it exposes the interpretation
infrastructure to programs in a very clean and manipulable manner which
is why it’s so DSL friendl. We pay a certain performance and memory
footprint cost for this flexibility but it puts more constrained
languages at a great disadvantage for real-world problems. And of course
we need to put that bit more care into how code if we want it to be
maintainable.
Ellie
Eleanor McHugh
Games With Brains
twitter: @feyeleanor
raise ArgumentError unless @reality.responds_to? :reason