Re: My views on Eclipse and Apple's decision on discontinuing all WO Dev tools

> A. Productivity

> For many people productivity is measured in terms lines of working  
> code per day, or speed of refactoring. We measured productivity in  
> work done for the last three years
I agree ... I think any quality development shop measures productivity  
in results and not kloc, and any quality development shop thinks in  
terms of reusable frameworks and not repeating yourself.  I think your  
comments like ".. and then write a few hundred lines of code and we're  
done" are a little misleading and your measurement of line counts must  
be leaving out shared frameworks or something (heck, Wonder's Ajax  
framework alone is like 9kloc and it's not like there's a lot of fluff  
in there), but that's beside the point.

> I would even go as far as saying that all the hundreds of Eclipse  
> vies, configuration parameters, etc. is actually very hindering. On  
> the other hand, I could install Xcode from a disk image, open a  
> project and compile and run it without all the fuss. All these  
> Eclipse bells & whistles are completely useless to me (even Xcode is  
> often too complex :) and they slow me down. They disturb my flow of  
> thoughts...
And this leads to my point in my previous email about this being  
relative.  For YOU Xcode is "just open my project compile and run",  
but this is not at ALL the experience I have with Xcode.  The  
experience I have with Xcode is "open a project ... try to compile ...  
how does classpath with in this #@$ thing ... how do i configure this  
deployment build ... " etc.  I find it to be a completely painful  
experience.  You find Xcode to be a natural workflow because you've  
been working with Project Builder et al for ten years and it fits your  
mental image of the workflow.  I find them all to be infuriating  
because they're completely dissonant with mine.  And I'm not religious  
about my tools either -- all I care about is whether the tools I'm  
using make me a better developer or not.  At the moment, Eclipse is  
the one that I'm most happy with, but the second something else comes  
along that brings a substantially better experience and power, I'm  
gone*.

> What I claim here, is that the typical for so many developers over- 
> reliance on complex tools and techniques does not lead to higher  
> productivity, and at the end of the day the number of happy  
> customers counts (to me at least) more then the number of buttons on  
> the toolbar of my IDE.
I agree.  This is a large part of why we contribute to Wonder as well  
-- I don't believe that everyone should have to resolve the same  
problems.  Multicast EOF stack synchronization is really hard to get  
right.  Why shouldn't everyone else be able to just turn it on and  
benefit from the experiences of people who came before them?  Why  
should EOF developers have to care about locking?  I don't think they  
should.  The frameworks and tools should make solving common problems  
easy.

However, I think you're glossing over realities of software  
development in the description of your world.  Refactoring, for  
instance, is a real topic. As much as you think think think  
beforehand, invariably three months in, when you have a better  
understanding of the problem, or when requirements change, you're  
going to have to make changes to your system and your designs.   
Capable tools dramatically improve problems like this and it allow  
developers to be much more agile (in the traditional sense, not  
necessarily the fancy-hot-and-new-methodology sense).  Whereas you  
find that the tools disturb your thoughts, I find that stupid problems  
that computers should be able to do for me disturb my thoughts.  I  
want to be able to focus on the development problems I'm working on  
and I want to be able to improve my code effectively.  Before Eclipse  
came along, refactoring code was just not even a tool in my toolbox,  
because the bang for the buck just isn't there.  With good tools, it  
opens up an entirely new set of capabilities to developers.   
Especially for your so-called "amateur programmers," who are even MORE  
likely to make bad decisions up-front.  To be able to give them the  
confidence to rethink and explore is powerful.  And with features like  
local change tracking, I have a huge amount of confidence in exploring  
the problem space, because my tools are backing me up.  My tools  
provide me _excellent_ integration with my version control system,  
which is a major workflow in any multi-person development shop (and  
should be even in single person shops, just with less merging and  
conflict resolution).  These aren't just "fancy gadgets" -- they're  
enormous benefits and address annoyances that constantly annoy  
developers.  It's like you said -- I don't want to disturb my thoughts  
-- I want to find the shortest path between thinking and running  
software, and good tools grease that process.

> B. Esthetics.
> In one word - Eclipse is harassment to even the most modest sense of  
> esthetics or beauty. It is a torture for the eyesight, it is ugly,  
> distasteful, painfully inconstant and repulsive! It might contain  
> countless smart and useful functions, but they a wrapped in dirt.  
> And this mess is not because it is complex (as some did claimed).  
> Only on that subject I could fill many pages, but I will skip it. I  
> will only ask you why are you all using Apple hardware and Mac OS?  
> Eclipse looks exactly as ugly on windows or Linux, yes? If you do  
> not care about esthetics, why are you buying Mac and not one of  
> these ugly cheap plastic bricks every computer shop around the  
> corner sells for $500?
I make choices of technology based on several criteria, of which  
aesthetics is certainly one, but overall it's "does this make it  
easier for me to do what I want to do."  For me, Mac OS X absolutely  
does.  Certainly a large component of this is user interface design,  
but also as a DEVELOPER on Mac OS X, I am very much compelled by the  
frameworks that OS X has to offer that let me think about the problems  
in my problem domain rather than a bunch of junk that I shouldn't have  
to care about.

And like Chuck said, give me actionable items here ... When I look at  
Eclipse, it's not like I think it's a thing of beauty.  I said as much  
earlier that if it were a Cocoa app, sure, it would be nicer and would  
probably look nicer.  But when it comes down to it, we're talking a  
fairly small distance ...

* It has 16x16 toolbar icons instead of Apple's HIG 32x32 (Entity  
Modeler.app uses the proper sizes, though I'm still working on getting  
the toolbar to lay them out better, but hell, until Leopard there  
wasn't even a proper reusable toolbar view anyway)
* It has ugly ass tabs, but in their defense, there really IS no real  
tab standard on OS X that also supports a close option (the aqua-ish  
tabs are very limited in their capabilities). If you look at Apple  
apps, they all do this in a different way.  Safari's definitely look  
nicer and would be worth ripping off.
* I think it goes toolbar crazy.  I actually turn off almost all my  
toolbar icons.  Also, I don't the vast majority of view toolbars -- I  
find them to mostly just crowd the view for features that are  
generally better executed as hotkeys anyway.
* I don't like the visual style of their icons -- I think they're sort  
of clowny, but not everyone has Apple icon designers on staff
* Any place that uses emulated widgets pisses me off.  Cell editors is  
a big one.  But I have spent a lot of time in Entity Modeler tweaking  
these emulated widgets to behave much more like OS X native  
equivalents, I have several open bugs with SWT on them, and several  
that I have straight up just fixed in SWT.
* It's MDI, which is definitely un-macish, but I find that I often  
context switch fully into Eclipse anyway.  And honestly, every time I  
use Xcode, the thing that pisses me off constantly is that I end up  
with 5000 windows open and I can't find anything.  Eclipse just  
addresses this in a different way -- it falls down also, just in  
different ways on this one.  I like that Eclipse can be setup with  
automatic tab management so I can tell it to only keep the last x  
editors open so it automatically cleans up after me -- again, just one  
less administrative task to think about while I work
* Little stuff like inconsistent triple-click support and double/ 
triple-click-drag-selection, but this is being actively worked on  
anyway.

... Those are the things I can think of offhand?  But man, most of  
these are pretty darn picky and most are also SOLVABLE in a relatively  
straightforward way (whether the SWT team would accept the patches is  
another issue).  I honestly think that if tabs looked like Safari's,  
toolbar icon resolution was jumped up, and the default toolbar set was  
pared down, all the people who think Eclipse is "hideous" would  
suddenly not think so quite as much.  But I'm sure there are lots of  
other things floating around ... Fundamentally SWT is a middle-man,  
and some widget have to be emulated, so it's never going to be perfect  
parity with the underlying OS.

> Pierre, if you are reading, why don't you make the following  
> experiment - open one project in Eclipse, go to Steve, tell him that  
> Apple customers have to cope with this and watch his face :)
And yes, if Apple can deliver an environment that can solve the  
problems that Eclipse solves AND make it look beautiful, I would  
switch in a second.  But Xcode doesn't even come close.

> C. New WO Developers
> In our team we have one guy that knows Eclipse inside-out and  
> defends it to some extend. Few days ago I asked him the following  
> question. Imagine a guy across the street reads about this fantastic  
> framework called WebObjects, how it makes you more productive, etc.  
> And he decides to be a WO developer. So he buys a Mac (with Leopard  
> on it), and tries to write and deploy a simple WO application with a  
> simple database of just one table. What is the chance of success?  
> After some thinking he looked at me and told me - yes, you are  
> right, the chance is close to zero.
> Do I need to go further and explain what does this mean for the  
> future of WO?
Well, the "deploy" part of the story is mostly unchanged and has  
always sucked for WO -- I think it's overly complicated and lacks good  
tool support.  As far as the "develop" part, I think that this is  
mostly solved with a single screencast or a tutorial that is updated  
with all the new screens.  It's not like with Xcode and WOB you just  
osmosed the knowledge of how to build a WO app when you launched it.   
When I started WO, I had no idea how to use EOModeler, and I got  
f***ed by MANY times with its stupid 10 year old bugs.  WOB was the  
same for me ... People who talk about how intuitive it is are only  
saying that because they went through the tutorials about how to use  
it.  It's not really all that intuitive.  If you skip the tutorials,  
it's pretty incomprehensible (I know this because I personally skipped  
its tutorials and tried to just use it and it's pretty annoying).  It  
also had some AWESOME features like when it just stopped working  
because I selfishly decided to not use .*  imports in my Java files.   
As I see it, the future of WO is far brighter than it was 2 years ago,  
which was that WO was stale.  All the other folks were doing slick  
Ajax web applications using modern web site construction techniques,  
and we have a bunch of half-assed tools that don't support things like  
CSS, and a framework where Ajax requires either dropping a huge amount  
the framework's power (i.e. DirectAction-only-time .. yay!) or writing  
some really complicated code.  The future of WO now is that we have  
some of the best tools around for developing web applications, and  
they're getting better every day (OK ... some days they get worse, but  
the next build they get better again :) ).  I think you're getting  
hung up on what I see as transient problems.  The state of the union  
_at this moment_ is in flux, with Leopard and a new WO release after  
years of quiet, but the trend line is onward and upward as far as I  
can see.

> Final word
> Day after day I go to the office and work on extremely complex  
> software systems that handle inter-banking transactions, mobile  
> phone calls, or control of some very complex instruments. This pays  
> the bills. In the evening I go home, have few hours with my family,  
> and after every one is sleeping I start working on yet another  
> complex software system that models the macro-molecular chemical  
> pathways in our bodies (my goal is to understand how muscular  
> dystrophies work, and hopefully help to find a cure... it is a hobby  
> for me). In all these activities I have to think about two-phase  
> commits, satellite links, chromatic aberration, or protein folding.  
> I do not want to think about classpaths, or if I installed the  
> version of WOLips from this afternoon.
> For me and countless other people the process of software  
> development is just the way to achieve our goals and not the goal  
> itself. We are professional economist, physicist, chemist, or  
> biologist first, and software developers second. IDE is a tool, and  
> as every tool in the hands of an amateur it must be first and  
> foremost simple! Therefore many of us hate Eclipse. And believe it  
> or not, people like me (amateur developers) are the majority of the  
> users (exactly as there are more weekend photographers using iPhoto  
> then professionals using Photoshop).
Again, I agree.  It's only because I happen to actually develop the  
tools also that I have a different perspective.  But the non-tools- 
developer side of me (which is 70% of my time -- 30% of my recorded  
time is open source tools and framework development) thinks tools are  
a facilitator.  I write applications that solve business problems.  We  
also have a remote-controlled robotic system app (microscope, not  
telescope) built on WO, WO software for police forensics, content  
management, task management, accounting, group organization and  
communication.  Like I said at the top, quality software developers  
care about results, and those results are delivering applications that  
customers are happy with.  You should not have to care about  
classpaths (well, this one you can't REALLY avoid, and you aren't  
avoiding it in any tool) and WOLips versions.  And if you were on  
Tiger, you could be on Eclipse 3.2 and WOLips stable with not-the- 
fanciest-tools-and-features like hundreds of other users who obviously  
don't care about versions because WOLips stable hasn't change in  
something like 3 months.  Eclipse 3.3/Leopard/5.4 will stabilize, but  
it will take some time to do so.  The biggest problem I have is that  
what you see as horrible problems, I see as relatively minor bugs.   
This is more of a PR problem than it is a technical one.  WOLips is  
open source, so you see the sausage being made.  It means that  
everyone sees the tantalizing new features and yearn to upgrade to get  
them even though they may not be production-ready.  WOLips has  
historically not been very good at managing stable vs nightly  
releases.  This is a procedural issue that we need to deal with so  
that weekend photographers can use the tools reliably.

We want the same things, Georg.  You bring large apps and experience  
developers to the table, and with those, you bring the the ability to  
provide us with (at the very least) recommendations on how to make  
your lives easier -- and by proxy, everyone else.  This is why I am  
excited that the iTunes guys are switching over to Entity  
Modeler.app.  They bring a scale of application that most people don't  
have, and the changes necessary to support them (as well as the  
funding they put up to do so) will make the apps better for all of us.

Aside from all of this discussion, it's unlikely Apple is going to  
change their collective mind on the deprecation issue any time soon.   
Given that, and given that we've looked at a lot of the alternatives  
to WO and they mostly all suck pretty badly, I don't think you're  
leaving us any time soon to go to the competition, so we might as well  
find a way to make this a positive relationship.

ms