The Artima Developer Community
Sponsored Link

Weblogs Forum
The departure of the hyper-enthusiasts

262 replies on 18 pages. Most recent reply: Dec 20, 2006 11:11 AM by Carlos Neves

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 262 replies on 18 pages [ « | 1 ... 8 9 10 11 12 13 14 15 16 ... 18  | » ]
D H

Posts: 13
Nickname: dug
Registered: Jul, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 7:40 AM
Reply to this message Reply
Advertisement
> Here is a quick question to make the case that Python is
> not really OO, then: why do I need to pass "this" (sorry,
> "self") to each method?

That's a good point.

D H

Posts: 13
Nickname: dug
Registered: Jul, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 7:54 AM
Reply to this message Reply
>> I also dislike how crowded the code becomes when you read
>> "self" everywhere, which is very non-pythonic. I like
>> significant space indenting for that reason (it saves you
>> from all these "end" keywords that I dislike in Ruby) but
>> the omnipresence of self ruins a lot for me.
>
> Yes, implicit "this" could be said to gain more than explicit "end" does.
> It will be interesting to see what happens in Python 3000.

Good luck waiting for that.

D H

Posts: 13
Nickname: dug
Registered: Jul, 2003

Kay Schluehr Posted: Dec 23, 2005 8:09 AM
Reply to this message Reply
Gotta love that python community, instead of shits and giggles it's FUD and flames:

mike bayer wrote:
> hey alex, you talk a lot about not being the "machine's
> bitch" and all, but once your Ruby site needs to handle half
> a million transactions a day, ohhh youll be that computer's > bitch again, just you wait.

Kay Schluehr wrote, after posting a personal flame:
> According to the legend of saint Matz it was Perl creator
> Larry Wall who was his personal hero and it is actually
> Larry Wall who never became tired to speak about the
> postmodernism of Perl, it's relationship to natural
> languages the many ways to express things etc.

mike bayer wrote:
> If we want to say, as someone mentioned, "well Ruby/Rails
> is not for big enterprise apps ! its just for all the
> little things I do all day", that would be consistent with
> my impression of it....and this fact should be more openly
> admitted.
> One additional note, the plethora of web frameworks in
> Python has granted us one fantastic thing that a tool with
> Rails' hype-machine would utterly obliterate: room for new
> approaches and architectures. The Ruby community has
> plenty of room for tons of new eager developers looking to
> write blogs and other small applications with Rails; but
> for people looking to build communities around
> architectural notions divergent from Rails, pretty much
> none.

Kay Schluehr wrote:
> What I still don't get is this strategy of immunisation
> against critiscism by mystification.
> ( isn't Matz Japanese? Wouldn't it be better if he taught
> average american children kanji to enlarge their cultural
> background? )
> It's a kind of conservative closure by introducing a
> little redundancy just if a language permitted using both
> "and" and "&&" to assign a boolean operator. A great leap
> for mankind? A step aside from rude Dijkstra towards the
> incredible wisdom of Yoda? Maybe, but it's also a little
> ridiculous to make a new age religion from this.

Mike Petry

Posts: 34
Nickname: mikepetry
Registered: Apr, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 9:03 AM
Reply to this message Reply
First of all, kudos to Bruce for hitting the collective nerve of the community. This is a compelling discussion because there is a huge difference between using the best tool for the job and enthusiasm.
Over the last couple of days, I have been helping somebody debug some C++ ATL/COM stuff and it has been challenging and a total blast!

I got into software development because it was so geeky cool. C was a language for wizards.

Java came along and it was a trade-off, it was a little less cool but it was easier to do networking and stuff and the applet concept was kind of neat. But, I had to cleanse myself with a little C/C++ after a while.
But we and our industry began to mature. Stuff like schedules, costs, maintainability, the lack of experienced developers and constant turnover became issues.

Web development became the thing and with it came a geeky cool language for wizards - Perl. Geeky cool and productive, and curly braces and semi-colons - Katie bare the door!

Perl made me lose patience with compilation. But I knew that Perl was like a sexy thing from the wrong side of the tracks. But with an open mind, I began to investigate the world of scripting languages.

First I checked out Python. Python would have to suck, there are no curlys or semis and it looks like pseudo-code. Lets face it - it seems like Basic (oops I can't believe I said that). However, it only took a short while before I was cranking out solutions that I felt good about. I knew that Python was for real when I realized that I was using Python syntax as psuedo-code on my UML diagrams at work. And Python made me realize that the minute or two spent every day to align curly braces was a total waste of time.

My restless and compulsive soul cannot rest so I continued to investigate - checking out Ruby. I coded up some stuff in Ruby and from 60,000 feet, it seems a lot like Python. Ruby has a tad cleaner OO approach and is more expressive however it takes a tad longer to learn.
Ruby brings enough Perlisms over to make it geeky cool and I think that is what makes it a winner by a nose.

We don't just care about the ilities and ivities. We want to be wizards casting incantations to the machine - and see it respond to its master.

Or we could agree to stop all this progress because eventually they won't need us anyway. Some technology will render us obselete. So lets just pick a spot and freeze advancement. I vote for turning the clock back to the C/C++ days.

Roy Pardee

Posts: 2
Nickname: rpardee
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 9:15 AM
Reply to this message Reply
> That said, I was struck early on by the oddness of
> accepting self in method declarations (you don't
> have to pass it; it is declared only in the def,
> not in the argument list of a method call) and python
> rightly passes self automatically when you call an object
> member function. Coming from oop via C++ I didn't
> understand why this wasn't just automatically
> available and googled for a reason. Very reasonably,
> somebody on a mailing list (see
> http://www.python.org/tim_one/000152.html) explains that
> methods of classes in python are just functions (that
> could be dynamically added) and so self is not a reserved
> word but just the convention that the first argument to a
> method is a reference to the instance. Methods are not any
> different than functions and this allows for easily adding
> functions to an object...

So do I read that post correctly to indicate that the reason you've got to pass a 'self' variable in as the first parm to method defs is that Guido doesn't like creating new reserved keywords?

It's a nitpick but... that seems like a bad compromise to me. Ruby has dynamic method 'injection' (is that the right term to use?) too (see the 'mix-ins' discussion here: http://www.rubycentral.com/book/tut_modules.html) and IMHO, knowing that 'self' will always refer to 'this here instance' makes the code way more readable.

But that's just one person's opinion of course...

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 9:31 AM
Reply to this message Reply
> Alex, finally we agree. And you read my mind (I also
> thought that how_many() was better than count() in the
> same sense you point).
>
> Thanks, you were very kind. I will take a look at Ruby.

My pleasure, Marcelo. A word of warning: make sure you think twice before looking at Ruby. For a person so obviously bright and intelligent as you are, looking into Ruby is like taking the red pill (remember the "Matrix" movie?) One look, and there is no going back! One bad side effect of that is that it'll make you positively hate your day job.

So don't say I haven't warned you.

Roy Pardee

Posts: 2
Nickname: rpardee
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 10:01 AM
Reply to this message Reply
> Actually, there is a good point in here -- my guess is
> that someone on the Java team wasn't communicating with
> someone else when array was given the read-only
> length "field" and all the containers use
> size(). I would have liked Java's array to use
> size() as well (the compiler could have optimized
> away the call to produce the same efficiency as length).
> That would give me fewer things to have to know about,
> which is what I prefer when programming.

I think that's the point--ruby's occasional synonyms give you fewer things you have to remember. The interpreter 'knows what you meant', even if you didn't say it in the exact right way.

I remember an unpleasant experience trying to learn oracle's pl/sql. This sort of thing wasn't working:

if <something> then
<do some stuff> ;
else if <some other condition>
<do some different stuff> ;
end if ;

That's not valid code--"else if" wouldn't compile (not that the error message I got was particularly helpful at pointing out that line of code, mind you). Nor is "elseif", which would be valid basic (and php?). No, in pl/sql, you've got to use "elsif", as I discovered after staring at my seemingly elementary code for like 20 minutes. Ooooh the bitterness. Oooh, the swearing. I've got to misspell "else" in this frickin' language!!??

In ruby, you can use either "else if" or "elsif" or "elseif". Aaaah--nice.

There's a place for precision in the definition of a word--but some concepts are just synonymous, and IMHO the language does not benefit from pedantic insistance on particular forms.

And sure--the newfangled IDEs mostly now have intellisense type features to take some of that burden off the programmer. But I still appreciate being unburdened if I choose to use a plain text editor.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 10:16 AM
Reply to this message Reply
From a Ruby user's point of view, trying to tag it with a Perl bad image is just lame.

The first time I saw Perl code I tried to read it. It was like a walk in the park, until I met one of the famous Perl's regular expressions. I gave up on it, because I said to myself and to my surrounding friends: "if I can't even understand what it's doing to a string...". And that was my first and last try at Perl.

In contrast, when I started programming in Ruby, I could understand everything, including the Ruby's approach to regular expression. Regular expression in Ruby gave me one of those "aha!" moments. In Ruby, it's rare to see truly huge regular expressions like you can see in Perl, and the reason is that Ruby provides many easy ways to do things that Perl people would use RE for, I think. That said, as Ruby is used for much more than text processing, we just rarely find regular expressions in people's code, and repeating, when we find them, they are generally short and easily comprehensible.

Ruby is a divine gift, indeed. It does not have any match, even in Python. But we are yet to find "the perfect language", which is way harder because we can't even agree on the "basic features" that the perfect language should have. That said, by delegating the responbilities of being a perfect language, to the tools, like IDEs, you just try to hide the imperfections of your languages. By adopting XML as a standard to programming languages, you just make the languages even worse.

Think about this: if you don't like coding solutions from scratch, it does not mean that it wouldn't be useful if you could code them. But your solutions would be way more useful if they could be easily reusable. So, if other people take the task of creating reusable components, they can choose any language, but they won't necessarily choose the language that the users prefer, like Python. Python can be THE scripting language, which is generally the way to "glue" programs and libraries, because it has a minimalist syntax and semantics. On the other hand, people need to create what you want to glue with Python; and people might choose more comfortable tools when creating their own tools, libraries, etc; if there are more comfortable tools, why not use them to "glue" the things instead of Python's minimalist approach?

Think about this: what if many of the Python's libraries were based on components which you could easily reuse in your own programs?

With Ruby you can do all that, today. So, in my opinion, Ruby wins by more than a nose. Maybe, by a whole body. :-) Too bad I can't write a thoroughly comparison between Ruby and Python, but maybe a book-writer could.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 11:22 AM
Reply to this message Reply
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/

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 11:42 AM
Reply to this message Reply
> > According to this Ruby doesn't scale well because it's
> > threads are not implemented at a hardware level:
>
> Make that, 'threads are implemented in the interpreter'.
> Assuming this is accurate (a quick Google search suggests
> s it is), it's a huge disadvantage vs. Java. Java's
> threads can be implemented in the VM, on the OS level or
> both without making the developer it's bitch, so to say.

James,

How thoroughly did you read the post that you quoted? It didn't state that Ruby doesn't scale well. It stated that Ruby used a very different model for scale out than Java, one that has weaknesses and strengths. You linked to an excellent article but seemed to misunderstand its subtleties.

If you consider concurrent distributed systems you'll see that the gap between state of the art and state of the practice is tremendous. State of the art is single processes handling greater than 10,000 clients (see http://www.kegel.com/c10k.html .) Java struggles to do this which is why BEA , for instance, use a native layer in their Weblogic server. With NIO or NBIO some Java systems can compete at this level. Far more systems use a product liek Weblogic server and either don't tune it or misconfigure it and get 100s of clients, or implement a thread per request model whose scalability is limited by choice of OS, version and configuration.

Ruby's use of fast CGI trades ease of development for lower theoretical scale. I say theoretical because the fact that Java *can* support 10k connections is no solace to a team that doesn't know how to do this. The fast CGI model is a dumber, simpler aproach that can, for naive users, sometimes scale *better* than the more flexible an dpowerful Java approach. How many Java developers understand that JVM threads map to OS threads through a NxM , Nx1, or 1x1 model depending on OS choice and OS configuration, and that "OS threads" (in some cases LWPs) will have a second mapping to kernel threads, and that discrete instructions will be pipelined, multiplexed on hyperthreaded CPUs, dual core CPUs and multiCPU hosts. Thesed are subtle, hard issues and understanding them is necessary to achieve the theoretical scalability that Java offers with correct behavior.

Scalability is an important issue and with Ruby the groundrules are different. This doesn't mean that Ruby apps will inherently be l;ess scalable than Java apps. Thinking that is similar to the "Java will always be slower than C++" or "C will always be slower than Assembler" oversimplifications. Tempting thought but wrong.

I agree that anyone planning to deply a Ruby on Rails app across thousands or hundreds of thousands of users would be smart to spike a "proof of architectural approach" test.

Peter Booth

Posts: 62
Nickname: alohashirt
Registered: Aug, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 11:48 AM
Reply to this message Reply
> > > I'm definitely trying to understand Ruby by putting in
>
> > > minimal effort and leveraging what I already know. My
>
> > > normal approach to learning a language, as you've
> > > observed, takes a huge amount of time and effort.
> >
> >
> > Bruce,
> >
> > It's too bad you're willing to make a lot of assertions
> > about Ruby without, apparently, understanding much of
> the
> > language. I'd almost go as far as to say that it's a
> bit
> > unethical for a person of your stature to behave this
> > way.
> >
> > I'd highly recommend this tutorial to anyone, even to
> all
> > those professional programmers with years of Java and
> > Python programming under their belt.
> > (http://pine.fm/LearnToProgram/ --soon to be a book
> from
> > those pragmatic guys:
> > http://www.pragmaticprogrammer.com/titles/fr_ltp/) You
> > will only learn well if you put yourself into the
> mindset
> > of an amateur (consider zen and the empty cup
> metaphor),
> > rather than bashing all the new concepts with your
> weighty
> > 'knowledge' and 'experience'.
>
> What I still don't get is this strategy of immunisation
> against critiscism by mystification. When I read that Ruby
> used length and size synonymous I didn't had the
> impression that this reflects the naturalness of english
> language ( isn't Matz Japanese? Wouldn't it be better if
> he taught average american children kanji to enlarge their
> cultural background? ) but the unification of conventions
> that are all around in the PL area. It's a kind of
> conservative closure by introducing a little redundancy
> just if a language permitted using both "and" and "&&" to
> assign a boolean operator. A great leap for mankind? A
> step aside from rude Dijkstra towards the incredible
> wisdom of Yoda? Maybe, but it's also a little ridiculous
> to make a new age religion from this. We are not alike and
> that's for sure.
>
> Kay

When I read this (I'm a Ruby nubie) I thought "OK that's a design error. I hope it's not the first in a long list." It doesn't seem typical but claiming it as a strength seems defensive to me. Maybe I'm still brainwashed by Java?

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 12:18 PM
Reply to this message Reply
"When I read this (I'm a Ruby nubie) I thought "OK that's a design error. I hope it's not the first in a long list." It doesn't seem typical but claiming it as a strength seems defensive to me. Maybe I'm still brainwashed by Java?"

Particularly, I only use "size". On the other hand, historically (in other languages), I needed to use size, length, len, count, etc. Please, understand that Ruby was not created to "please its users". Ruby was created as I would create a language: "to please me!" So, when people talk about language design, I view it as rather irrelevant as I already settled with Ruby and maybe C as a supporting language (RubyC is a specific layer which is great when you create C extensions for Ruby). On the other hand, when people discuss language design, it's like they can use anyone which does the job for them, so if the current one sucks, they will keep using it until a better one, which they can use for their jobs, comes around. So, for people discussing language design, it's like "everything sucks if I can't use it", be it because the language really sucks or because they can't use it for their jobs.

So, these synonyms that may appear in Ruby are rather irrelevant for people who don't even use Ruby and never will. So, obviously, these synonyms "sucks", for them. :-)

I particularly like the "and" which defaults to logical operations instead of bitwise operations. I like a lot the logical operations in Ruby, as "nil" is used like "false" for negation, and in Ruby it fits like a glove. That's part of the defaults that I like in Ruby. Basically, if I were to create a language for ME, I would create a language like Ruby, without forgetting the support of C, which is one of the things that make me "Choose" Ruby, as it lends to Ruby a future-proof shield.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 7:37 PM
Reply to this message Reply
James:

> Um, I also don't think Java is necessarily better than
> Ruby.

Well, you're arguing that enterprise apps can only be implemented in a statically typed language like Java. Better is relative. In this regard, you think Java is better. But you haven't justified your view, and I don't think you can.


> That's not really relevant. If a machine fails and it's
> made of steel, do you say all steel is at fault? I never
> said Java applications are bulletproof. I will note
> however that a large number of sites on the Web run with
> Java back-ends.
>
> If I can point out a Ruby site with an error, would that
> prove Ruby is not good?

This is your argument, not mine. I didn't say Java was no good because that production enterprise app from one of the world's largest financial companies barfed a stack trace on me because of a null object reference. Static typing in no way helped to prevent this error, nor could it.

Remember when Java was supposed to save all us C programmers because it didn't have pointers? We wouldn't be dereferencing NULL. Well, null is just as deadly for a Java app, static types and all.


> I'm not saying that it can't be done succesfully without
> static typing but it seems to me that without clearly
> defined types, it would be extremely difficult to pull off
> without constant communication between all the players
> which just isn't feasible in a large team that is spread
> out across time-zones that work days that just barely
> overlap.

Just so we're clear, a type to me is a set of values and operations on those values.

I simply don't understand how static typing will make these management and communication problems go away. Examples, please. And if static typing is all that, then why Java instead of Haskell, which has a far more sophisticated type system and referential transparency?

I'll give you a counter-example. Rails. This was developed, after a number of folks started contributing heavily, across at least 3 time zones and at least 2 languages (although David's English puts many native speakers to shame). I don't see how lack of static types hampered them. But you might ask them about it.

I'd recommend looking over these slides by Jim Weirich on 10 things every Java programmer should know about Ruby (http://onestepback.org/articles/10things/index.html), if you're really sincere about learning something here. He happens to know _both_ Java and Ruby very well.

It's important to understand that types are not prominent in Ruby. Ruby is about classes, which are objects themselves, and instances of classes. There is no 'documentation' provided by a type label that cannot be provided by the class and it's documentation. And lest you think that duck-typing somehow introduces confusion, every object is indeed strongly 'typed' (in a sense): ask it it's class (obj.class) and you'll get a definite answer. You can also ask it what it's like (e.g. obj.is_a?(String)). These are things that can be tested for using good behavior driven development in a way much more sophisticated than a compiler type-checking your code. And the tests themselves provide immeasurable assistance with communication.

I can't help but reiterate my main point in all my posts: people, especially self-professed experts, should know what they're talking about before shooting off at the mouth. I'm not trying to convert you, or yank away your little security blanket named Java, C#, Python, Lisp, or whatever. But if you are a programmer, and you value your intellectual capacity and problem solving skills, you do yourself a grave dis-service by discounting Ruby and spouting FUD about hype, scalability, maturity, enterprise app, or whatever other topic is popular. And the reason for that is simple: FUD propagates a hundred times faster and farther than the truth. We already live in a world where stupidity and stupid decisions abound. Why contribute to them?

So rather than all your 'apprehensions' and 'hard time imagining' and other hypothetical nonsense, why not learn Ruby and actually demonstrate, in particular, why it fails as an 'enterprise app' language. If you did that, you'd be quite famous, and popular with the Java and Python fanatics at least. Otherwise, you just sound stupid to someone who knows better. And I always think it's more important to not sound stupid to people who know better, than to sound smart to people who don't know better. But I could be wrong; after all, Bush did get 51% of the vote.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 10:08 PM
Reply to this message Reply
> We already live in a world
> where stupidity and stupid decisions abound. Why
> contribute to them?

Brian,

You cannot ask someone who is stupid not to be stupid. If such person could do that, he wouldn't be stupid to begin with.

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 9:02 AM
Reply to this message Reply
> > Generally, I go to
> > a professional if I want something done right. I don't
> > hire an amateur plumber or electrician, nor do I go to
> an
> > amateur doctor.
>
> You make a great point. Yeah, if you happen to have some
> extra money in the bank and it's posing you considerable
> problems so that you can't wait to dispose of it, there's
> hardly a better way to promptly get rid of it than hiring
> a professional. Be it a plumber, or an electrician, or a
> lawyer, an accountant, a dentist, a doctor, etc., all
> these professionals know how to relieve you of extra cash
> in no time flat. They are the real experts in that domain.

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." (Red Adair)


Alex

Flat View: This topic has 262 replies on 18 pages [ « | 8  9  10  11  12  13  14  15  16 | » ]
Topic: The departure of the hyper-enthusiasts Previous Topic   Next Topic Topic: Java Applets + Ajax = ?

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use