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 ... 6 7 8 9 10 11 12 13 14 ... 18  | » ]
Kondwani Mkandawire

Posts: 530
Nickname: spike
Registered: Aug, 2004

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 5:44 AM
Reply to this message Reply
Advertisement
Sorry man its X-mass kind of slow so I went over this post
again and when I read the above, some team members thought
I was nutts coz I burst into tears laughing (I hadn't
initially read the whole post.

Quote:
"> Again, I feel like I'm talking to a machine. Is there a
> human being at the other line?
>"

You talk to machines??!! Do you live anywhere near a
mental institution?

"Common kom laugh with me, this is hilarious
don't you understand that kom?" (sorry I was talking
to my desktop, he's called kom).

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 9:17 AM
Reply to this message Reply
> Yes, it would be, but maybe because I'm not an English
> native speaker. If I see two different words (or function
> names) I expect they do different jobs. I don´t know if
> they are EXACTLY sinonymous or not because I am not a
> native speaker. Do you see my point of view?
>
> 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.

Back to our example. If we see the concept called 'customers' associated with the concept 'length', what conclusion do we draw from it? That 'length' refers to something an undertaker would be interested in once each individual customer from the collection 'customers' is dead? Undertakers view dead people in terms of their 'length', so that they can organize appropriate coffins for the ensuing funeral.

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

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 9:19 AM
Reply to this message Reply
> I bring these elaborations to illustrate how
> non-nonsensical purely machine-centric way of thinking
> would be in this context.

Oops, my mistake, the above should read 'non-sensical' instead of the double negation 'non-nonsensical'.

Owen Densmore

Posts: 2
Nickname: backspaces
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 9:38 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.

Enumerations, as they currently stand, are now just plain silly! Those who care which of the myriad lists and maps should be able to manage them, but for the casual program, just List and Map should be fine.

I can go on as can all of us, but the attempts to tame Java (Groovy, JPython, JRuby, PNuts, etc) have taught us that its time for Java 3.0 .. a sensible Java with the goal of serving simplicity, not specialists. (As a friend once said: I could whittle you a more friendly language than Java!)

Owen

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:14 AM
Reply to this message Reply
> Yes, it would be, but maybe because I'm not an English
> native speaker. If I see two different words (or function
> names) I expect they do different jobs. I don´t know if
> they are EXACTLY sinonymous or not because I am not a
> native speaker. Do you see my point of view?
>
> 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).

No they are not synonymous. Size is a more general term with no specific dimension. Length is a type of size relating to a single dimension. Size can be volume, length, area, or even related to abstract concepts e.g. the size of a problem.

For an array, length is equivalent to size as an array has one dimension in Java. My best guess as to why length is not used in regard to Lists is that they wanted to keep it consistent with the Map interface (Vector and Hashtable orignally) where length isn't as clear. What's the length of a Map? That's up for interpretation. Yes, they probably should have used size for the array too but it's really not that big of a deal.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:38 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.

Which part of that rule do you think Java violates?

> Enumerations, as they currently stand, are now just plain
> silly!

How is that?

> Those who care which of the myriad lists and maps
> should be able to manage them, but for the casual program,
> just List and Map should be fine.

ArrayList and HashMap. All List and Maps are either Lists or Maps.

> I can go on as can all of us, but the attempts to tame
> Java (Groovy, JPython, JRuby, PNuts, etc) have taught us
> that its time for Java 3.0 ..

I agree but not because Java is untamed, rather, mistakes were made that can't be rectified without potentially breaking old code.

> a sensible Java with the
> goal of serving simplicity, not specialists. (As a friend
> once said: I could whittle you a more friendly language
> than Java!)

This I completely disagree with. How is Java unfriendly? It has a really narrow syntax. It may not be friendly to the hacker who expects the language to feel his meaning but it's friendly to those who have to work with other people's code.

This is the problem with the loosey-goosey syntax approach where everything goes. People will naturally fall into a subset of that syntax. If the rules are really wide-open, hardly anyone uses the same subset. This means there's effectively many dialects of the same language. I might understand your code with some concetration, but it's not like I understand my own code. For the most part, Java mitigates this problem greatly. When I look at a snippet of Java, I know what it does. I don't need to know what templates are used. I don't need to look for overloaded operators. I don't need to know what compiler is being used. It just read it and know what it means. That's simplicity.

Nicola Musatti

Posts: 2
Nickname: nmusatti
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:44 AM
Reply to this message Reply
[...]
> You talk like a machine when arguing the above point.
> Don't you realize that for all English speaking humans, it
> is obvious beyond a trace of a doubt that 'size' and
> 'length' of an array are equivalent? You should allow some
> meaning, some semantics to enter the picture when parsing
> a computing language statement. Allow yourself to go a bit
> beyond syntax.

No he does not, he simply has a different point of view from yours.

Moreover, it's not a given fact that 'size' and 'length' mean the same thing for a programming language's 'array'; they just mean what the language designer and/or library developer decided they should mean.

A reasonable interpretation could be:
- lenght is the number of items in the array
- size is the number of byte it occupies

So this redundancy comes at the expense of a little, but pointless effort from the part of the programmer. You call it beauty, I call it nuisance.

> This is exactly why we cannot compare Ruby with Perl,
> Java, C#, C++ et al. Those other languages are strictly
> formal. Ruby is common-sense oriented, and thus much less
> formal. Java, C# et al. are High Level Languages (HLL).
> Ruby is a Very High Level Language (VHLL). Comparing HLL
> with a VHLL is like comparing apples to oranges. It's like
> comparing Low Level Languages (an Assembler) to HLLs.

Just because it has two names for the same thing? You seem to forget that programming languages serve a different purpose than natural ones, and while this kind of redundancy may be fine in poetry, it is not so clearly advantageous in a programming language.

You like Ruby? That's absolutely fine with me, and although I don't know it I suspect there are more compelling reasons to appreciate it than it having two ways to find the number of elements in an array (in the C++ community the very same issue is considered an unfortunate case of bad design).

Pretending however that there are objective reasons to prefer Ruby to other languages only makes you appear as one of the hyper-enthusiasts (others would say zealots) Bruce wrote about in his original post.

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:53 AM
Reply to this message Reply
> You like Ruby? That's absolutely fine with me, and
> although I don't know it I suspect there are more
> compelling reasons to appreciate it than it having two
> ways to find the number of elements in an array

Exactly. I have seen much more compelling arguments from smart people that made Ruby sound very interesting. This 'I can call the same method with two different names' argument makes it sound like a joke.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 10:53 AM
Reply to this message Reply
> You keep repeating this but I don't think I know what it
> actually means. As developers we are tasked with solving
> real world problems by mapping them to formal
> representations that a machine can execute. Depending on
> the problem, there are different aspects of the way
> machines work that we have to take into account (of course
> it's very important to know which aspects are irrelevant
> in a particular context).

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. Java, C#, Perl, C, et al. won't be of much assistance there. These languages are not exploratory by their nature. They are run of the mill languages, for tackling run of the mill scenarios.

But that's not where our value as developers lies. Run of the mill stuff can be (and it already has been) solved by using run of the mill methods (such as code generators, be it the generators that run on local machines, or the generators that run on rupis in India).

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

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

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

> 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 don't know where you got this wrongheaded idea that Ruby is focused on trying to emulate natural languages? That was never the case, and never should be the case. I personally don't believe that mimicking natural languages would be a good approach to creating sophisticated programming tools. I firmly believe that programming is a strictly formal activity, and that it should forever stay that way.

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

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

> The one thing that has increased productivity most in the
> past 20 years or so has been the introduction of automatic
> memory management into mainstream programming platforms.
> It makes us more productive by taking something away, not
> by adding further names for it. Equally, relational
> databases take away the need for us to devise and manually
> optimize access paths, do index maintainance, make sure
> actions are atomic when they need to be, etc. Rule based
> systems infer facts so we don't have to express them.
> Dynamic method dispatch infers methods to call so we don't
> have to. I'm not aware of a single case where the
> introduction of additional names for the exact same thing
> has reduced complexity.

Quantity vs. quality?



Posts: 1
Nickname: rexpop
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 11:00 AM
Reply to this message Reply
Good article. A couple of points worth making though:

- Part of the reason that there is less enthusiasm about Java is that the enthusiasm isn't really needed anymore. Java has established itself as enterprise programming language de-jour for non Microsoft shops and will remain so for the forseeable future. Ruby and Python don't tend to play much in this space and so won't have too much impact.

- As you correctly point out, most of the hyper-enthusiasts you talk about were most likely the Smalltalk crowd who seem to embrace any OO language that they feel might re-capture the glory days of Smalltalk. Once the next great OO langague comes along, they'll be jumping ship again.

- I agree with the points made that simple is better. However neither Ruby or Python really satisfy this mantra. Ruby code (like Perl) while terse can get really nasty to understand if you are not 100% familiar with the syntax. This makes mantainablilty a worry as new developers are transitioned in. Python is better in this regard.

- Rails has some great ideas, but its still immature and like Java 1.0 its advocates are promising the moon and the stars and it remains to be seen if it will move out of the web development niche and into a wider area.

Sam Gendler

Posts: 1
Nickname: ideasculpt
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 12:02 PM
Reply to this message Reply
I try to buy into the hype of the latest and greatest, but it always fails me, usually sooner rather than later. I've been doing web programming since 1996 or so, and I've used just about every technology available for doing so (except for ASP.net). I've written raw cgi in C and perl and apache modules in C. I was a very early adopter of Zope. I've written entire web servers. I've written a dynamic content assembly language that was built on top of the python C library. I've done several web projects in raw python. And I've done a fair amount of java, using a multitude of frameworks, mostly struts, but now a Spring/Hibernate/Tapestry combination.

The thing that ALWAYS seems to fail me when I use frameworks in the interpreted languages is SCALABILITY. 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. And if you need a high performance web application that could scale across many hosts and databases reliably, forget it. Finding talented python developers, in general, can be a challenge, let alone finding ones with zope experience. The same issues are true of Ruby/Rails. It doesn't lend itself to team development, there is absolutely no scalability built into the system, and you will definitely find yourself writing a lot of buttress code yourself, as there is no ecosystem of available libraries and best practices in place. If you are at home building convenience apps for yourself, it isn't such a big deal to have to modify the development framework itself in order to get the job done. But when you are developing commercial software or services, the last thing I want to be doing is modifying my development environment to suit.

Rapid development platforms like Zope and Rails are great for workgroup apps that are developed by one or two people and which evolve slowly over time. They are a royal pain in the neck for robust enterprise wide or large public website development. Imagine building MySpace, or even my.yahoo in rails, for instance.

The same was certainly true of Java when it came out. I remember playing with Java in 1996 and being impressed with the language syntax and object orientation. Then i tried to write something that was fast in it and realized it was hopeless. It also didn't support functionality I needed, such as asynchronous I/O or Multicast until at least 2000. At the time, I was writing very high performance web and proxy servers for a fortune 500 company, and there was no way in hell that Java was up to the task. The same was true for a number of years. Even the whole J2EE thing didn't work that well for high performance apps initially, even if you didn't use EJBs.

Slowly but surely, however, the web development ecosystem was built up in Java (in large part by the efforts of open source developers. All the best java tools and frameworks are open source, in my opinion), and now, it is my platform of choice for large scale development, and nothing else comes close.

One of the early reponses mentioned Spring, and I have to say, the difference between web app development with and without Spring is extraordinary. Throw Hibernate into that mix and the Java platform is transformed. I can't imagine needing actual EJBs for the bulk of my projects. Not when Hibernate provides 90% of the EJB functionality, integrates will with J2EE features, and gives a whole lot more control over the mapping process than EJBs do. Sure, you still write a fair amount of code that you wouldn't have to in other languages, but it isn't an enormous difference (and I still code in vi, not with eclipse, so nothing is doing my typing for me), and it certainly isn't prohibitive. With Spring (and suporting frameworks) providing most of the connecting code for common patterns, DAO, transactions, logging via AOP, web service abstractions to the service layer, Hibernate providing ORM easily and effectively, and a clean ui framework (which I'm still waiting for. Tapestry gets the job done, but I'd rather see something like Wicket become fully mature. It's just not there yet), Java isn't lacking much over any other language. More importantly, it executes at least an order of magnitude faster than the interpreted solutions AND has very effective support for real clustering solutions.

Maybe eventually, something like Rails or a Python equivalent will catch up or even surpass Java's functionality for large scale development, but right now, they are no closer to being useful than Java was in 1998 or 1999.

So you talk about the hyper enthusiasts leaving, but the pragmatic programmers, who just want to get the job done as easily and effectively as possible are still relatively new converts to the language, as it is only recently that it has been worth getting enthused about. Prior to the first model 2 web frameworks (struts) becoming available, Java didn't offer enough functionality to make me leave the RAD environment of python or zope and it didn't offer enough performance to make me leave C/C++ programming behind for the high performance/scalable stuff. Now, the feature set is so much stronger than anything available in the C world that it is worth the very small execution efficiency disadvantage, which is irrelevant in any context I can think of, these days. That same feature set also makes it a great platform to jump to for rapid development. Sure, it isn't 100% as effective in that arena as something like Rails might become, but it is nearly there (with about the same margin there as Java has with C on the performance side), and it offers real scalability to boot. Right now, Java offers the absolute best of all worlds - developer efficiency, runtime efficiency, scalability, a large talent pool, and a ton of supporting software and I don't see that changing any time soon.

In late 1999, I thought Zope was going to revolutionize web development. It was so much better, faster, and easier to use than anything else out there - until you tried to solve a really hard problem with it, when it became a royal pain in the neck. The Z-shaped learning curve was no joke. I tried so hard to use it for several years and it almost always let me down eventually. At best, Rails is where Zope was in 1999 in terms of maturity, and it is not at all clear that it will ever have more of an impact than zope did. It's a really neat idea, but CAN IT SCALE???? I hope so, cause someday, I'd like to use it. For me, the last 2 years working mostly in Java have been revelatory, and I'm not going anywhere anytime soon.

--sam

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 12:16 PM
Reply to this message Reply
How about a more apt example. Suppose you have a String object that has both length and size. In this case it ambiguous. One may be the number of characters while the others is the number of bytes. There are many more variations, but the effect of having two methods is the impression that there is a reason for it, so one would imagain they are somehow different.

Alex Bunardzic

Posts: 546
Nickname: alexbunard
Registered: Oct, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 12:28 PM
Reply to this message Reply
> How about a more apt example. Suppose you have a String
> object that has both length and size. In this case it
> ambiguous. One may be the number of characters while the
> others is the number of bytes. There are many more
> variations, but the effect of having two methods is the
> impression that there is a reason for it, so one would
> imagain they are somehow different.

Sorry, the example is faulty. The size/length example is applicable only to array. Anywhere else it would be insane to shove it like that.

That's the thing -- avoid foolish consistency. Just because Rubyists like the size/length dubiosity in an array, doesn't automatically mean that now it should start popping up anywhere.

Now, if machines were designing the language, and if they came across this useful little thingy, they'd probably think in a linear fashion, similar to your way of thinking, and would insist that we enforce this size/length everywhere. That would ve a perfect example of maintaining foolish consistency.

Luckily, Ruby creator was a guy who didn't think like a machine.

Sriram Sunder Raman

Posts: 1
Nickname: srirams
Registered: Dec, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 1:03 PM
Reply to this message Reply
> Sure, we've been refining the development process
> over that time and development techniques like the
> 'Waterfall Model' and procedural programming' have slowly
> given way to newer versions of the same things such as TDD
> and 'functional programming'. Underlying this though is
> the fact the developing software still requires a geek, a
> keyboard and unfeasible amounts of coffee coding in the
> same old commands.


I agree with your point in your post, however, functional programming has been around for a long time and (maybe even) pre-dates any of the imperative programming languages. Lambda Calculus is considered to be a functional programming language and dates to the 1930's. (it required coffee back then as well ;) )

Sriram

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: The departure of the hyper-enthusiasts Posted: Dec 22, 2005 1:19 PM
Reply to this message Reply
> > How about a more apt example. Suppose you have a
> String
> > object that has both length and size. In this case
> it
> > ambiguous. One may be the number of characters while
> the
> > others is the number of bytes. There are many more
> > variations, but the effect of having two methods is the
> > impression that there is a reason for it, so one would
> > imagain they are somehow different.
>
> Sorry, the example is faulty. The
> size/length example is applicable
> only to array. Anywhere else it would be insane to
> shove it like that.

Instead of just making ad hominem attacks, why don't you explain when you make method synonyms and when you do? Calling it insane implies that there is some sort of logic behind when to do this. Though, it's interesting to note that 'insane' is a description that only applies to human (or animal) thinking. Machines can't be insance. So in your 'thinking like a human' strategy, insane thought shouldn't be excluded otherwise you are teetering towards machine like thought. I believe insane thought is very much a part of your approach.

> That's the thing -- avoid foolish consistency. Just
> because Rubyists like the size/length dubiosity in an
> array, doesn't automatically mean that now it should start
> popping up anywhere.

Ha ha! Dubiousity is a great word for your philosophy.

Dubiosity: (n.) The state of being doubtful; a doubtful statement or thing.

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