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 2:11 PM 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 ... 7 8 9 10 11 12 13 14 15 ... 18  | » ]
Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 4:25 PM
Reply to this message Reply
Advertisement
Sam Gendler, you've certainly got a lot of experience. Unfortunately, just like Bruce, you tend to speak on a topic you apparently do not know.

Does it scale? Hmm, according to this, http://www.oreillynet.com/pub/wlg/8274, "the second largest online record store in the world ( second only to Amazon)" is being rewritten to run on Rails. (But, you might want to double-check that as it's asserted by a Ruby-friendly guy; he might not be a source for accurate information.) Keep an eye out for scalability issues. And, have you seen http://www.basecamphq.com et al? The authors might be able to answer some questions about scalability.

BTW, Rails is a framework written in Ruby (http://www.ruby-lang.org). You write Ruby by putting Ruby code in files. You can put files in a CVS. In fact, it appears they use subversion for the framework.

Now when you get to actually using the framework, you, uh, write some more Ruby and some SQL and stuff. You put that into some weird objects called, uh, files. And of course, you can put those into, uh, a CVS. I use subversion, but I thing monotone and darcs look interesting, too. So, why exactly can a big team not work on a Rails project?

I too have written apps in Zope. Zope is unfriendly to CVS if you use ZODB. There is little merit in drawing more than the broadest comparisons between Rails and Zope.

I realize I'm being extremely sarcastic, but really, why not study up on a topic before talking trash discounting it. You might unduly misguide someone who mistakes your 'knowledge' and 'experience' for something of merit, although, you have apparently not learned much from them.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 4:57 PM
Reply to this message Reply
> Now when you get to actually using the framework, you, uh,
> write some more Ruby and some SQL and stuff. You put that
> into some weird objects called, uh, files. And of course,
> you can put those into, uh, a CVS. I use subversion, but I
> thing monotone and darcs look interesting, too. So, why
> exactly can a big team not work on a Rails project?

Not to speak for Sam but in general I would be apprehensive about devloping in any dynamically-typed language with a large team. I suppose you can avoid serious issues with lots of testing but it just seems very sketchy. I doubt that he thinking about source control. That's just a neccesary condition for team development. In no way is it a sufficient one.

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 6:06 PM
Reply to this message Reply
James:

> Not to speak for Sam ...

I was specifically referring to this in Sam's post:

> Not just execution scalability, but development team
> scalability, too. At least with raw code, you can have
> as many programmers as you want on the project, you can
> use source code control, track revisions and bugs, and
> you can find talent in the labour pool that is familiar
> with your technology platform. Zope has never allowed
> easy (or any) integration with revision control, and it
> was a pain in the neck to work in for teams of
> developers, even when the bulk of the work was built as
> a pure python 'Product.' Ruby looks to have similar
> issues.

which, arguably I guess, was referring to the lack of versioning control with Ruby apps. Again, I assert Sam should know what he's talking about.

But you raise a good point: Could you tell me what makes you apprehensive about a team developing in a language that is not statically typed? In particular, for which errors introduced by lack of static typing would your behavior driven development fail to test?

Brian Ford

Posts: 153
Nickname: brixen
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 6:29 PM
Reply to this message Reply
James:

An additional point, just because the tone of arrogance of your previous posts regarding Java is plain annoying:

Recently I had the great experience of interacting with Chase's newly redesigned credit card website. Can anyone guess in which language this 'enterprise' app is written? Upon logging in, I was greeted with a Java traceback at least 100 calls deep.

The error?--A method call on a null object. Now I realize that is different than a incorrect method call on a static type, but it was no less of a catastrophe for that enterprise Java app that could not render the page, not to mention the great embarrassment for those enterprise Java engineers as I looked at interesting details of the system revealed in that traceback.

The great benefits of statically typed languages and 'compile-time' errors are over-rated. Use good behavior driven development and learn about duck typing, then show me how your enterprise apps fail because your language doesn't support static types.

Jan Ploski

Posts: 8
Nickname: jploski
Registered: Aug, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 7:01 PM
Reply to this message Reply
> Ruby simply says: "Hay, 'length', 'size', same difference.
> I hear you. And I know what you mean!"

And then, one wonderful day, your code goes kaboom.
You still have some time to write a best-selling book
about Intuition-Oriented Programming (IOP) before it
happens! Or read up on why software makers more commonly
aspire to engineering than poetry. Good luck.

nikolaus heger

Posts: 1
Nickname: orthorim
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 9:48 PM
Reply to this message Reply
"It may be true that Ruby's metaclasses are easier to grasp and use than Python's, but Python has had the capability for many years."

This is not an argument that you can make when comparing languages. Anything is possible to do in any language - what is insteresting is how easy to use and grasp the feature is. It's all about how easy to grasp and use something is.

In this respect, I see the main weakness of Python: OO programming is awkward and full of exceptions and strange constructs like 'self'. Python is perfectly fine for OO programming - but awkward.

You can also see it this way: We hyper-enthusiasts move on when we see something better. Java was great when it came out, then Sun failed to improve it in any significant way. IMHO they have hit rock-bottom with the new syntax in version 5.
c# is tainted by de-facto MS ownership and really only an option for people who either believe in Mono or who are windows-only.
Python was amazing and clearly showed in great detail just how flawed Java was. Ruby then clearly showed Python's weaknesses.

If tomorrow something better comes out, I will be enthusiastic about it too. In the meantime, Ruby is it.

Marcelo Barbero

Posts: 5
Nickname: mbarbero
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 11:49 PM
Reply to this message Reply
> > But maybe this is my problem (or fault... are they
> exact
> > sinonymous?) because of my lack of understanding on a
> > foreign language (mine is Spanish).
>
> Thanks for bringing this up. I apologize for not being
> sufficiently sensitive to consider your arguments
> seriously enough the first time around. Now I think I see
> where your bafflement is coming from.

Thank you.

>
> If that's how we see it, what would be the 'length' of a
> collection of customers? Their sum total, or their average
> 'length'?
>
> Let's now look at the other side of our example, 'size'.
> What would the 'size' of a collection of customers
> indicate? Is it referring to their collective shoe size?
>
> I bring these elaborations to illustrate how
> non-nonsensical purely machine-centric way of thinking
> would be in this context. Of course it doesn't make any
> sense to talk about 'length' or 'size' of 'customers' in
> any other terms but in terms of how many items (i.e. how
> many individual customers) there are in the collection
> called 'customers'.

Would you think that customers.length or customers.size is not a machine-centric way of thinking?

If I have customers, and if I don´t misunderstand the meaning of the word, I would prefer "count()" or choose something better. It's the quantity of customers, not the lenght (or size) of an array or list.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 12:12 AM
Reply to this message Reply
> Its simple: As wonderful as Java is, it has grown to
> violate the 80/20 rule, or the "normal programs should be
> easy and hard ones possible" rule.

I still use the same java language features I always have. I still just write J2SE only code, don't touch J2EE. I wrote my own broker back in 1998, before there was a JMS or J2EE. It's a container based system that I can plug things into to solve problems that don't involved brokering. I created my own status monitoring and control software before there was a JMX.

The problems with J2EE are not indicative of any problems with J2SE. There are things that I don't like. But, I chose to change the language of programming in Java be recasting APIs into domain specific language. I fail to understand how come people think that Java or any other language should solve all their problems out of the box.

It's kinda like the stereotypical democrat vs republican in the U.S. The stereotype is that democrats think that the government should do everything for them. They depend on people looking out for them, and just can't manage to make a decision on their own. Whereas, republicans think that you should be able to plan and act for yourself. Again, that's the stereotype.

Having those kinds of skill is invaluable in sitations like natural disasters where you need to know to LEAVE!

I sense this kind of difference in software developers. Some just don't know how to decide that they need to take action. Others are like lemmings. They get into whatever line is moving the fastest, and smack their face against the wall with everyone else when that line reaches the end of the road. They don't look ahead and they don't look back.

They are just in line yammering about today...

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 1:53 AM
Reply to this message Reply
> Would you think that customers.length or customers.size is
> not a machine-centric way of thinking?

That's a damned good question, Marcelo. Again, context is king. The machine-obsessed engineers would jump head first into treating customers.size() in a machine-centric way. We already saw an example of that in this thread earlier today, when one participant insisted that, for him, customers.size() plainly means size of the customers collection expressed in bytes. Could anyone be more machine-like?

But people have been using concepts such as 'size' and 'length' long before they ever made those first primitive machines. So, no, I would not think that a concept such as customers.size() is a machine-centric way of thinking (unless you insist that it's exclusively about the size, expressed in bytes, of the computer memory occupied by the instantiated customers).

> If I have customers, and if I don´t misunderstand the
> meaning of the word, I would prefer "count()" or choose
> something better. It's the quantity of customers, not the
> lenght (or size) of an array or list.

I tend to agree with you, although I'd argue that 'count()' could be very misleading. To me, 'count()' indicates a command, as in 'go ahead and do something, like count things and maybe even report your findings somewhere'.

A syntax like 'customers.how_many()' would make more sense. Such method implies that nothing, aside from merely reporting back to the client how many customers there are in the collection, will take place upon sending the message.

A propos feeling antsy about sending a message whose consequences we might not fully understand, another thing that Ruby brings to the table and where it really shines is in supplying us with an exclamation point ('!') appended to the end of the message, if that message is not idempotent.

For example, in Ruby a message such as customers.triage! signals that the state of the customers collection is going to most likely change upon the receipt of the message. It could be that the triage! message is going to inactivate all the customers that haven't made any orders in the past year or so, or maybe some other, undisclosed business logic is going to take over.

So, if anything, we've been alerted by Ruby that we're about to attempt to do something potentially destructive if we go ahead and send the message with a '!' appended to it.

Getting back to the imperfections of the 'size' and 'length' messages, Ruby retains those slightly contentious terms simply as a concession to the inertia of typical programming community. The thing is, we've been using these concepts ('size' and 'length') for generations. By now, they are ingrained, warts and all. It would be utterly arrogant of Ruby to ignore the customs.

Peter Bowyer

Posts: 1
Nickname: reywob
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 5:20 AM
Reply to this message Reply
> in RoR, there is the concept/implementation called
> Scaffolds, in which the engine generates soup to nuts from
> the database schema. if you think about Model Driven
> Architecture or Database Driven Design, then RoR looks
> like a lightweight way to get there. Then you later find
> that the developer team view Scaffold as a throwaway.

That's what I can never understand. I spend a heck of a lot of time having to write forms to do CRUD (usually using PHP). This is what makes Django look so nice - a presentable, autogenerated admin area.

The hype of rails put me off, but I keep meaning to get back and have a proper look. However, lack of presentable CRUD forms will I think put me off, no matter how great the rest is - just because this is something every website I code needs!

Marcelo Barbero

Posts: 5
Nickname: mbarbero
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 5:44 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.

Alexander Jerusalem

Posts: 36
Nickname: ajeru
Registered: Mar, 2003

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

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 9:28 AM
Reply to this message Reply
> James:
>
> An additional point, just because the tone of arrogance of
> your previous posts regarding Java is plain annoying:

I didn't mean to be arrogant. I don't think Java is neccesarily 'better' than Java. I'm just not a big fan of plethoras of syntax. For example Perl is the worst language that I've ever used.

> Recently I had the great experience of interacting with
> Chase's newly redesigned credit card website. Can anyone
> guess in which language this 'enterprise' app is written?
> Upon logging in, I was greeted with a Java traceback at
> least 100 calls deep.

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?

> The error?--A method call on a null object. Now I realize
> that is different than a incorrect method call on a static
> type, but it was no less of a catastrophe for that
> enterprise Java app that could not render the page, not to
> mention the great embarrassment for those enterprise Java
> engineers as I looked at interesting details of the system
> revealed in that traceback.

Bad development is bad development regardless of the language. Do you not have stacktraces in Ruby?

> The great benefits of statically typed languages and
> 'compile-time' errors are over-rated. Use good behavior
> driven development and learn about duck typing, then show
> me how your enterprise apps fail because your language
> doesn't support static types.

I'm not saying it can't be done. I just have a hard time imagining how we would support a team of a dozen or so full-time developers in three time-zones with the periodic introduction of dozens more in a fourth for short times all adding and modifying code and deploying changes concurrently wiithout clearly defined types. We have lots of code that is used in many different processes that are constantly expandaing as we interact with hundreds of distinct extenal entities.

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. I understand that you can define types but you don't have to. The point is we are always going to want to and I don't see the point of not enforcing what we require. Perhaps I am missing something. If you feel that you have something to provide me that will educate me, please do. I am always open to new ideas.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 9:31 AM
Reply to this message Reply
> I didn't mean to be arrogant. I don't think Java is
> neccesarily 'better' than Java.

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

Rinie Kervel

Posts: 26
Nickname: rinie
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 23, 2005 9:36 AM
Reply to this message Reply
>Smalltalk's
> the most pure, Python the most approachable, and Lisp the
> most powerful. It's just that as a consultant at
> conservative Java accounts, I need to also consider market
> penetration.
Well nobody seems to like PHP in this discussion (although the original post mentions it once). But for market penetration PHP is liked by Oracle (http://www.zend.com/core/oracle/) and IBM (http://www.zend.com/core/ibm/).

But then again I like curly braces: PHP on server, javascript on the client (and SQL for storage although I don't like the syntax)

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


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us