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 ... 9 10 11 12 13 14 15 16 17 ... 18  | » ]
Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 9:35 AM
Reply to this message Reply
Advertisement
> > I still don't understand why self was made mandatory,
...
> I think it's because of the "explicit is better than
> implicit" philosophy. As I've said, I'm probably more
> ambivalent about this issue than anything else.

The idea came right out of Modula 3: you define a FUNCTION (which like any other function has all of its parameters explicit, of course), you may set that function for use as a METHOD of one or more classes. Even the word "self" comes to Python from Modula 3 (exactly in the same usage).


> > Also, I'm still bothered by the fact that you declare a
> > method with n arguments (self being the first one) but
> > invoke it with n-1 arguments.
>
> Yes. Slightly non-implicit, that.

Indeed: totally explicit, thus the very reverse of implicit. When you GET a method from an object (that's BEFORE you "invoke" it, possibly long before), the "getting" operation may pre-bind some arguments (a concept also known as "currying", though there's endless debate on whether that name is appropriate or "partial binding" should be used instead) in the resulting callable. This mechanism is exposed through the concept of a descriptor and the special-method __get__ of descriptors; functions are descriptors.

Ruby, like Smalltalk, strongly separates methods from other attributes; just mentioning a method calls it (if you need to get "an object wrapping the method" you'll have to go the long way 'round). Python, like C/C++, does not: just mentioning a function or method does not implicitly call it, it just gets a reference to the callable object, like for any other object. You may call a callable object by applying the call-operator, spelled 'parentheses'. So, say, building a sequence of callables can be as simple as:
fs = a, b.c, d(), e.f()
where some callables are obtained by simple reference to a name, others by attribute lookup, others yet are returned by calls to higher-order functions such as d or other higher-order functions such as e.f. Some of the callables may have bound arguments while other don't -- it doesn't matter. When you want to call each callable in the sequence, in turn, that's as simple as:
for f in fs: f()

If you take a callable with N arguments and bind one of them, you obviously end up with a callable with N-1 arguments -- you'll have to supply N-1 more arguments each time you call it. In the example, I'm assuming that any arguments that the callables in fs might have had have been bound, so that each callable in fs can be called without arguments.

This rasonably strong connection with functional programming ideas is part of what makes Python multiparadigm -- not to the same extent as, say, Lisp, or even more Mozart (which almost looks DESIGNED to teach multiparadigm programming) -- but it may be part of why many Lisp experts, such as Norvig, Graham, or the reddit folks, appear to find Python reasonably comfortable and usable; or why EuroHaskell was held the day after EuroPython and in the same venue (at least in 2004 -- dunno 'bout 2005 as I was unable to attend).


> > I also dislike how crowded the code becomes when you
> read
> > "self" everywhere, which is very non-pythonic. I like

Personally, I don't see much difference in readability between, say,
@attribute = 23
and
self.attribute = 23

The former (Ruby) is more compact, but also more visually invasive. Leaving the scope locally ambiguous by omitting both markers, of course, is wisely eschewed in both Ruby and Python (and most coding-style guides for, say, c++, which require you to spell the name as, say, 'my_attribute' to make it clear it's an instance attribute). The advantage of the 'self.' form is conceptual: it does not require adding one more rule, it totally follows from the general rules defining the meaning of anyobject.attribute ...


> Yes, implicit "this" could be said to gain more than
> explicit "end" does. It will be interesting to see what
> happens in Python 3000.

My prediction is that 'self' is here to stay, just like, say, blocking by indentation.


Alex

mike bayer

Posts: 22
Nickname: zzzeek
Registered: Jan, 2005

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

hey if I were tasked with deploying a ROR site to a large-scale envionroment with ~.5 million TPD, I would most certainly be fearful, uncertain, and doubtful. You'd be just fine ?

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 11:46 AM
Reply to this message Reply
> > The person I want to hear from is the core Python
> expert,
> > someone who knows that language incredibly well ...
>
> Ok Bruce(s). I'm not sure I qualify as your "core Python
> expert". I'm a core Python developer, though:

My qualifications are roughly similar to Neal's -- for example, the knowledge of Python's "nooks and crannies" embedded in his pychecker is somewhat similar to the kind embedded in my "Python in a Nutshell". We're both Python committers, PSF members, Google employees, etc, etc. I think I'm more of a "gadget lover" by nature, which may explain why I keenly look into lots of programming languages -- e.g., for Ruby, I got a Andrew Hunt tutorial, read through the first edition of their book -- basically, "dived into" the language, over five years ago, even though I had no specific _reason_ to do so. OTOH, I haven't looked that deeply into Rails.

Anyway, you can find a lot of posts of mine comparing Ruby and Python, although I don't necessarily agree now with all I wrote then -- for example, the (theoretical) mutability of builtin types doesn't feel to me like a big problem any more, just one small extra trap for the unwary (and both Ruby and Python have other such small traps, anyway -- they byte less in practice than you would expect them to in theory;-). But essentially, I would still say "it's a wash" -- the two languages have more similarities than differences, when compared to other widespread languages. When it comes to differences, there are a lot of small things I prefer about Python, such as almost all the syntax choices, keeping REs in their own module, treating callable attributes like any other rather than having a chasm between attributes and methods, etc; and a few I prefer about Ruby, such as the more rigid capitalization conventions, the flexibility of blocks, the idea of marking globals with the $ of infamy;-) [much better than Python's "global" statement], the ability to "reopen" an existing class to add a method with more "obvious" syntax [you can get the same effect in Python but not in an equally obvious way - you have to 'def' the method's function and then assign it to TheClass.methodname]. I don't think any of these are "make or break" issues, and neither are the "legacy" issues of each language (the horrid implicit $_ in Ruby, the many Python builtins which should be in some separate module if they must keep existing at all, etc etc).

In terms of language philosophy, Python's push towards simplicity (only one obvious way to perform a task, etc etc) is far closer to my preference than Ruby's "not quite perlesque but almost" reveling in richness -- it can certainly happen, for legacy reason, to have two approaches ('x in d' vs 'd.has_key(x)"), but Python *sees* these as legacy baggage and yearns for the 3.0 "allowed to be backwards incompatible" release to drop the old way; the fact that Ruby advocates intensely DEFEND their synonyms (length/size, for example) makes my skin crawl with horror, to the point that it may impede me from ever being a card-carrying member of the Ruby community. But in the end, beyond the fanatics on either side, PRAGMATIC is the key word for the philosophies of both languages -- neither, despite the excesses of some of the fans in their respective communities, are "ideological" in foundation.

Which leads me to conclude that pragmatics is a great basis for language choice. When Ruby 2.0 increases performance dramatically, making Ruby way faster than Python rather than slower, or pypy meets its ambitious goals, that may be ample reason to "switch" -- or similarly, if Jython has a better JVM integration than the Ruby equivalent (I assume there must be one, and that I just haven't heard about it), or IronPython for dotNet fans, or Python's scipy.core makes for better numerical programming, or Ruby's Rails for better web apps, or there are Python but not Ruby ports to your cellphone or iPod, or PIL lets you treat images better in Python, or gmpy proves ideal for your number-theoretical manipulations, etc, etc, any of these may be a great reason for choosing one language, more sensibly than it would be to base your choice on "@foobar=23" vs "self.foobar=23" one way or the other;-)


Alex

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 3:08 PM
Reply to this message Reply
Thanks, Alex -- nicely put. Could you give the URL(s) where you talk about Ruby and Python. I would certainly be interested in your analysis.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 4:14 PM
Reply to this message Reply
Ruby supports multiparadigm also. I like OOP for the backend and I'm deciding if I go with DSL (functional) like "plugins" for the frontend; so far, I'm enjoying it a lot, though I still have 3 days of programming to make it work fully like I want. Basically, I want as a clean programming for the frontend as I can get, and it's becoming very neat due to the flexibility allowed by Ruby.

Example:

---file[ db_table.rb ]------
require 'cgr/cgr'
start(:GTK){|w|
w.pack button('database login'){ start_file('db_login.rb') }
}

---file[ db_login.rb ]------
require 'cgr/cgr'
start(:GTK){|w|
w.pack 'DB path: ', [tf_path = textfield, true, true]
w.pack 'DB interface: ', [tf_interface = textfield, true, true]
w.pack 'DB login: ', [tf_login = textfield, true, true]
w.pack 'DB password: ', [tf_password = textfield, true, true]
w.pack [1, true, true], button('connect'), ' ', button('cancel')
tf_path.text = '/home/dewd/t_/fb/aaa.fdb'
tf_interface.text = 'Firebird'
tf_login.text = 'SYSDBA'
}

------
So, the first file calls the second file with the "start_file" method. Both files can be run independently on of the other. Both files create GTK+ Windows and show them to the user. Next on my todo list:
1. create a callback so the events can be returned from the second window to the first one. # I like this approach because it keeps the code where it belongs, rather than allowing spaghetti programming;
2. support modal windows;
3. support deletion and recreation of windows;
4. ...

The above code works similarly for Fox-Toolkit and wxWidgets, I just need to change from "start(:GTK)" to "start(:FOX)" or "start(:WX)", respectively.

The code above is only the tip of the iceberg, though it's rather pretty for a frontend programming.

PS. even though I have worked a lot on it, I still have a lot of work ahead; I still am not sure about when it will be open sourced, though I hope to be able to open source it in the future.

That's Ruby to me. :-)

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 7:32 PM
Reply to this message Reply
> Thanks, Alex -- nicely put. Could you give the URL(s)
> where you talk about Ruby and Python. I would certainly be
> interested in your analysis.

There are many, such as:

<http://groups.google.com/group/comp.lang.python/msg/f9c570e9376c7cf3?hl=en&>

<http://groups.google.com/group/comp.lang.python/msg/7256adbbc7f79afe?hl=en&>


Alex

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 24, 2005 7:40 PM
Reply to this message Reply
> 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.

What most Java developers fail to realize is that it doesn't have to be deadly. What you have to understand is that any long lived thread should be protected by a try {}catch block that makes sure that RuntimeException doesn't kill the thread. This is the first rule of Java Threading in my book.

The Java language lets you protect the software from the programmer in this way. If you don't take advantage of it then you will experience some dismay and amazement at how
quickly things come to a screeching halt when RuntimeExceptions are not caught to protect the main threads from untimily death. Depending on the depth of the call tree that the thread is used for and the complexity of the task, you may find it important to Thread.sleep() for a
second or so before the next task to keep a runaway situation from developing.

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

Yes, and that implies a contract which should be checked and validated as early in the runtime of the application as possible. Compile time static type checking is just an earlier validation of the contract that makes it easier to feel comfortable about what will happen at runtime.

> 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?

The primary reason I use Java is that interfaces in concert with mobile code let me create real services whose implementations are distributed at runtime, rather than in a deployment task. This is the "the power" of Java. If you aren't using this feature, then you probably have a wide choices of languages that will solve the problems you are solving.

> 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.

The only fair comparison compared all of this amazingly biased dialog would be to have two equaly capable teams with equal experience in each langauge to be given the same application to develop, and then microscopically track every single task, thought and subsequent action. Time them all, and then correlate the data back to some "cost". That would be pretty much impossible!

Every language has features. Every language has warts. What you have to decide is that if a particular feature enables your application, then that is why you might choose that language. If you fail to recognize the other benefits of another language which might provide some other feature, down the road, then you'll be stuck without that feature, perhaps, forever.

The Jini platform is a specification that can interact with a wide range of transports and languages because it has a large number of service provider style mechanisms. All the things in Java that deal with the humdrum programming of add/subtract/multiply/divide, class hierarchies, packaging etc are not the power of Java. The power of Java comes at the point that you really understand the power of mobile code. The smart proxy concept is paramount improvement on remote procedure call mechanisms. The abilty to change how the client uses the servers, on the fly, without the client being changed is extremely powerful.

If all you're doing is building web servers that ship out web pages, then you may not need mobile code. But, look at the Jini usage in Orbitz's platform, and you'll see how they take a core set of services and dynamically and continuously evolve the service platform using dynamic code downloading and classloader mechanisms for version management.

Version management through the change in class implementation is interesting. But, it still is not up to par with the use of classloader based changes. With classloaders, you can put the same interfaces into a piece of software and use multiple versions, with the same names inside of the same software. You don't have to change everything, everywhere to get one thing to work in one place.

> 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.

Any language comparison, when aimed at the right features can make one look better than the other, right?

> 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.

The question is what is the best way to test type compatibilty. When is it easiest to do and what is the most return on investment. Compile time type checking is a built in test. I don't have to write it over and over for each class/object. I don't have to understand flow control through a method/function/module to correctly implement all possible tests that will prove that I have compatible objects.

Further, new users/uses of the same code get to use this free testing. They don't have to implement it either. Thus, my test construction is limited to tests that cover semantic behaviors where I cover the vast majority of issues that a human constructed test should have to deal with.

> 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?

I think it is impossible for everyone to know everything about every language. Such knowledge is not free, and in the grand scale of software development progress, adds little value! What developers need to know if whether a particular problem is being solved by their language of choice or not. If the problem is being solved, that's the end need. Effeciency (time, space etc.) of the solution is part of the "is solved" answer, if that is part of the solution space.

What is most necessary in this day and age is to stop solving the same problems over and over with a new language that does one particular thing different than the others with no added value in other forms. That type of progress is extremely expensive. Look at the vast number of developers who have contributed the vast array of python and ruby software we have to date. I think that's productivity focused on many things that are just recreations of what we already have.

To some degree, it's the ignorance of some of those developers that are causing them to recreate existing solutions, in much the same way as there is allusion that Java developers are ignorant of Ruby and Python. For most developers, the ignorance of another language and platform is expected because they are solving problems that their language of choice handles for them.

For some, they've learned how to use the features of their language of choice to create new domain specific APIs that make their software simple to create and maintain.

> 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.

I guess I'd have to have a language based platform, such as Jini, which provides distributed leasing and distributed transactions, plus a language built in security model, mobile code and method overides "int max(int,int)" vs "double max(double,double)" and finally binary data serialization between instances of the language runtime, over the network to consider a language enterprise worthy.

I don't do web services and I don't create web sites. Those are the features that I use the most often in Java and which I don't see available in Ruby, Python or many of the other non-statically typed languages which I've looked at.

Point me to these kinds of solutions for Ruby and/or Python.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 6:25 AM
Reply to this message Reply
Java is: "Jack of all trades, master of none."

Or, master of the "Enterprise", though 99% of the financing for Java development comes from the boring day-to-day common software creation.

Yes, I need "day-to-day common software creation". Maybe most people need that! :-) I don't need a cluster of Java servers and clients, though I would like Ruby in little appliances so I could create user interfaces and exchange of data in Ruby itself.

I don't think it's a waste of time to want to use alternatives to Java, because Java isn't even available in most operating systems out of the box. Why is that? Why is that that Java's Swing had problems accented characters on Linux and I couldn't even use Java Swing editors because they had problem with my Portuguese? Yes, Java did support unicode, though its Swing interface didn't work very well on Linux. Maybe to help Java we only needed to use Windows and Solaris...

Well... I'm thankful that there are alternatives to Java. I'm thankful to all the people who have helped to create the open source alternatives to Java. Without them I would be using Windows right now...

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 6:36 PM
Reply to this message Reply
> > Just so we're clear, a type to me is a set of values
> and
> > operations on those values.
>
> Yes, and that implies a contract which should be checked
> and validated as early in the runtime of the application
> as possible. Compile time static type checking is just an
> earlier validation of the contract that makes it easier to
> feel comfortable about what will happen at runtime.

If you don't already know this, you won't likely benefit from me explaining it in depth: the type-checking the compiler can do is extremely limited. Therefore, the onus is on you again to demonstrate why the baggage that comes with static typing is outweighed by this very limited benefit.

> > 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.
>
> Any language comparison, when aimed at the right features
> can make one look better than the other, right?

See, you can put an advanced cerebral cortex in a monkey, but you can't make him use it. Did you read the slides? No, you didn't because Jim put one whole big slide in there to assure you he wasn't going to tell you Ruby is better than Java. All he did was point out important things that a Java programmer should now about Ruby.

> The question is what is the best way to test type
> compatibilty. When is it easiest to do and what is the
> most return on investment. Compile time type checking is
> a built in test. I don't have to write it over and over
> for each class/object. I don't have to understand flow
> control through a method/function/module to correctly
> implement all possible tests that will prove that I have
> compatible objects.
>
> Further, new users/uses of the same code get to use this
> free testing. They don't have to implement it either.
> Thus, my test construction is limited to tests that cover
> r semantic behaviors where I cover the vast majority of
> issues that a human constructed test should have to deal
> with.

All the compiler can do is ensure that you are executing a well defined operation on a set of values (a type). That's it. Guess what, that is just as automatic if you write tests for your code. There is no extra work required. If you were just writing tests to mimic a compiler doing type checking, that would be stupid. When you test semantic things, boundary conditions, etc. you get that compiler-like 'type' testing for free. Oops, there I went and explained it in more depth. You do know how to write tests, yes?

> I guess I'd have to have a language based platform, such
> as Jini, which provides distributed leasing and
> distributed transactions, plus a language built in
> security model, mobile code and method overides "int
> max(int,int)" vs "double max(double,double)" and finally
> binary data serialization between instances of the
> language runtime, over the network to consider a language
> enterprise worthy.

Um, the only reason why you need int max(int, int) and double max(double, double) is because of types. It's a lot of baggage for nothing gained (unless you don't test your code anyway). And of course, you have to have a cast operator so you don't need a separate double/int(?) max(double, int), and on and on. Now, what happens when you get happy with that cast operator?

And you still haven't, or perhaps didn't intend to, answer why static typing makes communicating about the program more clear.

> I don't do web services and I don't create web sites.
> Those are the features that I use the most often in Java
> a and which I don't see available in Ruby, Python or many
> of the other non-statically typed languages which I've
> looked at.
>
> Point me to these kinds of solutions for Ruby and/or
> Python.

Hmm, you're kidding, right? Okay, probably not considering this post: check out druby and pyro. Service locators are trivial (as are the rest of distributed objects) when you have a dynamic language like Ruby and Python.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 6:40 PM
Reply to this message Reply
> > Thanks, Alex -- nicely put. Could you give the URL(s)
> > where you talk about Ruby and Python. I would certainly
> be
> > interested in your analysis.
>
> There are many, such as:
>
> <http://groups.google.com/group/comp.lang.python/msg/f9c570
> e9376c7cf3?hl=en&>
>
> <http://groups.google.com/group/comp.lang.python/msg/7256ad
> bbc7f79afe?hl=en&>
>

Ah, yes, much more important to look smart to those who don't know better.

Cool is much different than 'cool'. And if the depth of your investigation extends to a bit of example code, then those who listen to your 'knowlegable' evaluation of Rudy deserve the consequences.

Alex Martelli

Posts: 8
Nickname: aleaxit
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:02 PM
Reply to this message Reply
> > > Thanks, Alex -- nicely put. Could you give the URL(s)
> > > where you talk about Ruby and Python. I would
> certainly
> > be
> > > interested in your analysis.
> >
> > There are many, such as:
...
> Ah, yes, much more important to look smart to those who
> don't know better.

Uh? More important than, what other goals? And why would Bruce Eckel (who here was thanking me and asking for the URLs) be one of "those who don't know better" (better than whom? about what?). I must admit I have no idea what you're talking about.


> Cool is much different than 'cool'. And if the depth of
> your investigation extends to a bit of example code, then
> those who listen to your 'knowlegable' evaluation of Rudy
> deserve the consequences.

One of the relevant URLs is <http://groups.google.com/group/comp.lang.python/msg/73c9aff4f29cbbdf?hl=en&> which does give some small snippets such as:
"""
you 'send a block of code to a method' -- but the difference here is really not much more than syntax sugar, Ruby's
array.each{|item| print item, "\n"}
vs Python's
for item in array: print item
or Ruby's
array.sort{|a,b| a <=> b}
vs Python's
array.sort(lambda a, b: cmp(a,b))
"""
I hope this isn't misread as meaning you need to actually SEND that (silly and) dummy lambda do the array.sort example in Python, any more than you need to send that dummy block to the array.sort in Ruby -- I hope it's obvious to the readers that, even if that cmp is a special function and not the builtin of that name, 'array.sort(cmp)' is a vastly superior approach in the Python case, etc, etc. My point was just that "sending the block of code into the method" should not frighten nor excite anyone compared to the Python way, where you loop extracting items (and apply code to them in the loop's body) or "send in" one or more callables (functions, lambdas, whatever); i.e., as I put it, the difference is mostly one of syntax sugar.

Of course, that was a post from over 5 years ago, and as I already mentioned I don't necessarily still agree 100% with what I wrote then, particularly considering the changes happened in both languages since. In particular, 3 years later I gave it a rather in-depth try, some modest fraction of which is recorded at <http://groups.google.com/group/comp.lang.ruby/msg/6ca81cbd796a5ad5?hl=en&>and the very, very numerous followups -- would the fact that it's comp.lang.ruby exempt it from your fierce strails about "those who don't know better"? Unfortunately much of the discussion turned around performance issues (which I hope are resolved in today's Ruby, or are going to be in 2.0) so it may not be as illuminating as one might hope regarding stylistic issues. However, it did strongly confirm my impression that there's little to choose, stylistically, one way or another, so pragmatic reasons (which may well include performance, depending on what implementations and extensions you have around or can consider making) may be the best grounds for choice.

Why all of this should have provoked your response, so apparently full of hate and spite, is quite beyond me, though. My best guess is that some people are so rabidly fanatical that any attempts at injecting moderation or commonsense in the discussion drive them wild, and that I've just witnessed a manifestation of this mindless, "nuclear-option" hostility.


Alex

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:16 PM
Reply to this message Reply
> Thanks, Alex -- nicely put. Could you give the URL(s)
> where you talk about Ruby and Python. I would certainly be
> interested in your analysis.

Bruce,

I'm really curious, why do you only engage those who are outspoken supporters of Python or Java? There have been numerous interesting posts by folks who profess, at least, to be knowlegable about Ruby.

Which reminds me everyone, I forgot to mention, you're right, nothing special going on here: Ruby is just a cheap knockoff of Python or Perl and Rails is nothing special. Please do not do any of your own investigating. People much more intelligent than you have already told you, nothing to see here.

Please do yourself a favor, go back to your temples, mosques, shrines. Worship those who tell you there is one right way. You might not know what to do if presented with a choice. Don't learn Ruby and find out for yourself whether you think differently when using it. Python is simple and clear (tell that to anyone who has tried to do simple metaclass programming, C embedding, or cringes at the pasted-on feeling of the objected-oriented features). Java is for enterprise apps because it has types and libraries. Continue to believe these things without question. To tell you differently would be the proverbial casting rubies before snakes, or into cups of coffee.

Whatever you do, please don't think for yourself. Stick with the pat answers, be distracted by the folks that tell you method synonyms are bloat, believe those who tell you Python is all about the one right way, and watch while PEP after PEP adds features that weren't really that special in Ruby.

It's safer this way; really; for everyone. The last thing I'd want is for you to come over and start programming Ruby libraries thinking the way you do in Python and Java. Ruby and Rails are nothing, just a blip on the screen, only visible to the hyper-enthusiasts. Please, for everyone's sake, do not learn Ruby.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:42 PM
Reply to this message Reply
> Why all of this should have provoked your response, so
> apparently full of hate and spite, is quite beyond me,
> though.

Alex,

Really, you have misunderstood me. I have neither hate nor spite for you. I've read your some of your posts. I know both Ruby and Python pretty well. I know that for many things, for me, there is a big difference between Python and Ruby.

When I read you talking about a Ruby feature being 'cool', and Bruce calling people who like Ruby hyper-enthusiasts, I feel a need to set straight some misconceptions. Quotes usually indicate that a word is being used euphemistically, and here that there's not much significance to a Ruby feature other than looking 'cool', i.e. no substance, just superficial ego stuff. You don't say that Python is 'simple' because it professes to be and yet has numerous features that make it much less than simple. See, your treatment isn't really unbiased, but for someone who doesn't know Ruby, like Bruce, you probably sound pretty smart.

Rest assured, I'm not telling anyone not to listen to you. I'm sure you're a good programmer. I generally find my work with Python to be rewarding and I'm impressed by the quality of many of the libraries. But don't expect me to be tolerant with Python and Java folks who 'investigate' Ruby and come back to say, ahh, it's a wash, not much interesting, syntactic sugar, blah, blah. If it was all simply equivalence and syntactic sugar, then Python wouldn't be chasing down features that are very useful in Ruby.

And if you insist on treating people who find compelling reasons to use a different language as if they lack substance or are just misguided or just wanting to be 'cool', then don't whine when you receive a figurative slap in the face; you asked for it.

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:46 PM
Reply to this message Reply
<quote from="http://paulgraham.com/hamming.html">
I have now come down to a topic which is very distasteful; it is not sufficient to do a job, you have to sell it. `Selling' to a scientist is an awkward thing to do. It's very ugly; you shouldn't have to do it. The world is supposed to be waiting, and when you do something great, they should rush out and welcome it. But the fact is everyone is busy with their own work. You must present it so well that they will set aside what they are doing, look at what you've done, read it, and come back and say, ``Yes, that was good.''
</quote>

Well. Thanks for the space and for the patience, all. Sorry about my excesses.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 25, 2005 8:55 PM
Reply to this message Reply
> I don't think it's a waste of time to want to use
> alternatives to Java, because Java isn't even available in
> most operating systems out of the box. Why is that? Why is
> that that Java's Swing had problems accented characters on
> Linux and I couldn't even use Java Swing editors because
> they had problem with my Portuguese? Yes, Java did support
> unicode, though its Swing interface didn't work very well
> on Linux. Maybe to help Java we only needed to use Windows
> and Solaris...
>
> Well... I'm thankful that there are alternatives to Java.
> I'm thankful to all the people who have helped to create
> the open source alternatives to Java. Without them I would
> be using Windows right now...

Is it a waste of time to spend 10 times longer to recreate something just because you don't want to spend the time to make it work/port it?

This is strangely close to the not-invented-here syndrome.

Flat View: This topic has 262 replies on 18 pages [ « | 9  10  11  12  13  14  15  16  17 | » ]
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