|
Re: The departure of the hyper-enthusiasts
|
Posted: Dec 23, 2005 11:22 AM
|
|
Re: thinking outside of the box:
> 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?
Now I feel real silly. You took my meandering tirade and gave it a much better articulation in only one simple sentence. Man, what a bravado! I feel so stupid, having to resort to all those politicisms and bullshit language.
Thank you for showing me how to think more clearly (less muddled, I suppose:-)
The only thing I'd change in your sentence above is replace the word 'sometimes' with 'always'.
> And it has nothing at all to do > with programming languages.
This is where we disagree. My thinking is that it has all to do with programming language.
Two people, two differing worldviews, what's new, eh?
> > 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?
Ever heard of Model Driven Architecture? Ever heard of Bangor?
Ever heard of Ruby?
> 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.
The above is the best thing I've read in a long time! I hope you won't mind if I borrow your brilliant analogies and make a habit of using them in my teaching engagements from now on?
I will make sure that I always attribute them to Alexander Jerusalem (that is, of course, if these analogies are, indeed, yours and not borrowed from another source?)
> 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.
But the machine may get stumped by the ambiguities. Common sense specializes in quickly resolving ambiguities, which is something machines are sorely lacking.
> 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.
Absolutely correct. The saving grace, for Ruby, is that this bloat you talk about is ridiculously small (and hence 'bloat' is a misnomer) -- a couple of synonymous methods in a vast sea of straightforward ones. Hardly a scenario where quantity gets a chance to produce new unanticipated quality, wouldn't you agree?
> I'm glad that you recognise that.
I'm sure everyone recognizes that. Formal thinking is one of the basic characteristics that makes us human (it would be hard to argue that animals posses the ability to think in a strict formal sense).
> 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.
I was using that example (a rather quirky and gimmicky one, I must admit) in order to try to illustrate the fundamental difference in Ruby's philosophy. It's a nice showcase for Ruby's leanings toward the human programmer, and away from the dictatorship of the underlying machinery.
But if that particular incident (which is rather isolated in Ruby's API) does not sit well with you, I suggest we forget about it and move on. There are numerous other, much more brilliant (but also much more involved) aspects of Ruby's philosophy that makes it a completely different beast from other programming languages.
> > 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.
It has to do with the kind of thinking the tool encourages in its user. For example, if I'm using a hammer, that tool encourages me to view everything around me as if it is a nail. If hammer is my favourite tool, I'll spend most of my working hours feeling like nailing something.
If I then switch the tool, and fall in love with a saw, then this newly found fascination will encourage me to view pliable things around me as something that could, and should, be cut in half.
It is the tool that has the power to shape our imagination, the way we think about the problems we encounter. I think it would be foolish to ignore this power, as it directly influence what we perceive as being a problem in the first place.
Ruby is a tool. It is a very, very peculiar tool, and it possesses tremendous power to completely change the way we, its users, look at reality. That's why it's so intoxicating.
> > 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?
In the way I've described above. Staying with the simplest possible examples, both the hammer and the saw are formal tools. But depending on which one we side with, our choice will lead us in different direction. With the hammer, our direction will be toward nailing things, hitting them on the head. With the saw, our direction will be toward cutting things in half (we won't feel any urge to start hitting things on the head with a saw).
I know this is almost insultingly simplistic illustration, but please bear with me.
In the world of software, the choice of tools also influences how we perceive and think of problems.
> > 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.
I do have extensive experience in the area of cognitive sciences study. I could write tomes about these issues. If interested, I invite you to peruse my blog, where I'm keeping an ongoing stream of consciousness exposing these and similar matters:
http://jooto.com/blog/
|
|