|
|
Re: The departure of the hyper-enthusiasts
|
Posted: Dec 23, 2005 3:08 AM
|
|
>
> This is a very nice description of what I would describe
> as a typical "thinking inside the box" attitude. Taking
> for granted that things are 100% already boxed-in for us
> and then rolling up our sleeves and tackling the given
> problem is indeed an activity that does not require
> sophisticated tools. In that light, all languages are,
> indeed, created equal.
>
> Luckily, there are also other breed of developers, people
> who I'd like to call "thinking outside of the box" guys.
> These are the people who question the boxiness. They don't
> take things at a face value that easily.
>
> Instead of taking the given problem and then working on
> solving it, the outside-of-the-box thinkers are more
> interested in examining the problem itself. Pick the
> problem apart. See if you can transform it into something
> else. Maybe in the process you'll discover that the
> problem is actually not there, that it was a false alarm,
> that somebody cried wolf in vain.
>
> Or, by examining the given problem, maybe you'll discover
> some new, way more interesting and way more important
> problems. Then your solution will be that much more
> valuable.
>
> Now, the big issue with the thinking-outside-of-the-box
> approach is that it really requires sophisticated tools.
Not at all. It doesn't require any tools at all. That is, if you are willing to attribute any real meaning to "thinking outside the box" other than just recognising that it is one of those phrases frequently used by politicians and marketing people as a rethoric means to put themselves on the right side of an argument without actually saying something. You know, like "one size doesn't fit all" or "unleashing the power of xyz" or "following international best practices".
Anyway, if all you want to say is that one should not blindly solve a problem as presented but sometimes question the problem and why it is a problem in the first place, then I completely agree with you. This is pretty self-evident, isn't it? And it has nothing at all to do with programming languages.
> > The value of our work lies in
> > our ability to translate between these two worlds, so
> we
> > have to be able to "think like machines" and think like
> > those humans who are domain experts in a particular
> field.
>
> Why not use the 'middle men' who will think like machines
> on our behalf?
I'm afraid we are these middle men. If not, who are they?
> > I would argue that the productivity of using formal
> > languages is not increased by introducing more
> redundancy
> > and that introducing redundancy doesn't necessarily
> make
> > these languages more human. As you yourself argue, our
> > ability to cope with large amounts of information is
> very
> > limited, so I don't see how redundancy helps if it
> doesn't
> > reduce information overload elsewhere.
>
> You seem to be confusing qualitative aspects with
> quantitative aspects.
If you think about it long enough, you will come to a point where you will not be able to draw a clear line between quality and quantity. In general, that's probably a philosophical question. But with regard to languages and APIs, it's pretty obvious that quantities and quantitative distributions of syntactic and semantic language elements together constitute qualities of that language or API.
Quantitative differences can "leap" into qualitative differences. Just think about sound frequencies. If the wave length is too short or too long, we can't hear them any longer. To hear or not to hear is a qualitative difference caused by a quantitative difference. Equally, if company grows beyond a certain size, its processes will have to change qualitatively to cope with that growth. It's the same with the speed of growth, the speed of change, and so on. You get what I mean. So the amount of bloat in a language and its APIs, syntactic or semantic, does have a severe effect on quality.
> > Using both size and length for the same thing makes it
> > easier to guess but I for one would not rely on such a
> > guess. I would try to find out what the difference is
> > before I use it, and that would cost me a lot of time
> if
> > this kind of useless redundancy was a predominant
> > principle in a programming language (which it is not in
> > Ruby as far as I can tell).
>
> This is because you've already been formally trained to
> think a la machine. What you've described above is exactly
> how a machine would approach the problem space.
No, the urge to find out how things work is distinctly human. A machine would typically be perfectly happy to "know" that size() does what it wants. A machine would not start to wonder what it means that there is another method with a similar meaning of the word and why it's there.
> > It's important not to confuse this kind of redundancy
> with
> > the redundancy introduced by utility methods. This is
> not
> > the debate about minimal interfaces. Utility methods
> are
> > there to cover the most frequent cases. That is, they
> do
> > something many people would have to write anyway. But I
> > don't have to write length whenever I use size or vice
> > versa. This is not utility, this is just bloat. It
> > suggests a difference where there is identity.
>
> Again, blurring quality with quantity.
Whether or not an API contains methods with different names but identical semantics is a qualitative feature of that API. How many such methods there are is a quantitative measure. If there are a lot and we get bogged down by the bloat, it slips back to a qualitative issue at some point. As I pointed out above, quality and quantity are related in rather complex ways and connot be kept strictly apart.
> > We could have a discussion about programming languages
> > that adapt to human language if Ruby would collect
> > statistics about natural language use and automatically
> > infer methods (names and semantics) according to those
> > statistics. A programming language that tries to
> translate
> > natural language into machine language. People have
> been
> > trying these things for decades, without much progress.
> > It's still worth doing further research in this
> direction.
> > But this is a wholly different matter than having a
> plain
> > old programming language pretending to be more human by
> > duplicating methods under different names.
>
> You don't cure the disease by removing the symptoms. You
> cure it by removing the causes.
>
> The problem is not in trying to force formal systems to
> behave informally. That would be ludicrous. Formal systems
> are cool, they are incredibly useful, they have their
> place, and there isn't anything dehumanizing about them. I
> would never argue that a great mathematician who thinks in
> strictly abstract, formal terms is thinking and behaving
> like a machine.
I'm glad that you recognise that.
> I don't know where you got this wrongheaded idea that Ruby
> is focused on trying to emulate natural languages?
I never said that Ruby tries to do that. What I take issue with, is your rather blurry concept of thinking like a machine or outside the box or whatever. You seem to consider it more human for an API to have two methods with identical semantics. I think that's misguided.
> What I was talking about is not the language, but the
> fundamental bias in thinking. You can choose to lean
> toward machine-centric world-view in your thinking, or
> toward human-centric world view.
Sorry, I still don't know what that means with regard to APIs or formal languages.
> In both cases, you will
> remain confined to a strictly formal world of constraints,
> but your underlying bias would lead you in completely
> different directions.
I what way?
> Thus, a machine-oriented developer would naturally prefer
> using Java, C, C#, Assembler, because these languages
> reflect how the machines work. A human-oriented developer
> would prefer Ruby, because it reflects the way humans
> think (the way humans formally think, of course).
I'm honestly interested in understanding what you mean there. Maybe you could reveal the science that is the basis for your assertions about human nature, Java, C# and Ruby. Or is it just your personal feeling? Maybe my brain was taken over by machines so I'm unable to feel the same dispite the fact that I used to be human as well.
|
|
Previous Topic
