In any case, those guys (Imendio) produce some excellent Free Software (Gossip, Planner, that I am familiar with) for that platform (Gnome). I'm happy to see them get a bit of publicity.
Apart from the fact that these bindings are for KDE, of course.
The point being that the existence GTK/Gnome bindings for ages have failed to change the primary language for building Gnome apps, so there's little chance that these Qt/KDE bindings will usher in a new era of anything, either.
There needs to be some consensus in the community about such things and given we can't even agree on the One True text editor, it is unlikely we're going to agree on a next-generation application development language.
I think you're blowing stuff right out of proportion.
First, if you have such a contrained machine (64Mb), you need to accept that it doesn't have the resources to run a bunch of heavyweight applications concurrently. You can still run these apps, but either not at the same time or you need to put up with the swap thrashing.
Second, right now I'm running all those apps you state and more: OOo, Epiphany (effectively the same as Firefox), Evo, Emacs and a bunch of Gnome terminals. This is on my workstation where I have Apache and a bunch of other developer-oriented daemons running and my memory usage is clocking in at 231Mb physical, 1.1Mb swap. This machine is an aging P3 700 and everything running feels positively snappy.
Adding up the resident memory sizes of OOo, Epiphany and Evo, I get 142Mb (which admittedly *is* a lot) but on a 128Mb machine shouldn't be too much of a strain. I don't know where you get your "XP + blah is snappy on 128Mb" metric, I've seen XP thrash on such a machine with no apps running at all.
Lastly, I'd like to make the standard observation that if half of the above was running at ring 0 like it does in Windows, it would probably be a lot snappier and a lot crashier, just like Windows.
"On Windows it does look and feel like a Windows app... Well, as much as any Windows app really. Same for Linux. For Mac there's more tweaking to make it more Mac-like."
Not at all. Under Linux it doesn't integrate at all with Gnome, so it is a non-starter for me: It is not a GTK app (hence ignores system theme, no native file chooser, etc.), it has an MDI and absolutely does not follow the Gnome Human Interface Guidelines.
On Windows: It uses a theme that by default does not mimic the standard Windows look and feel. It does weird things like popup a context menu when double clicking on a word. It has some crazy icon before the file menu in the menu bar. It doesn't use Windows' standard help system and the menus (especially the Window menu) are on serious crack. It's got an MDI (which is bad in itself) but is inconsistent with how every other MDI I have seen on Windows works.
"And you know for a fact that it doesn't do all or some these things? Or are you just assuming?"
I know for a fact.
"A sweeping statement with little contact with reality."
A sweeping statement, sure, but 100% accurate for Gnome desktops, mostly accurate for Windows and Mac desktops and I'd guess that it is mostly accurate for KDE and every other Linux desktop as well.
"Uh, yes, it is great actually."
For you, sure. For people in general it's not, because the theme doesn't look like a standard application.
"Look, you keep making these misguided statements about what Opera supposedly does or doesn't do... Have you actually tried it?!:)"
Yep. Don't get me wrong: Opera is my default browser on my SE P800 phone, and I use it almost every day, it works really well. I also keep the latest version for Linux and Windows for testing websites, but because of the stuff I outlined above I find using Opera a horrible browser to use on the desktop.
"Nope. Opera has an internal cross-platform toolkit. The UI is mostly the same on all platforms, except Mac where some parts have been "Macified"."
Okay, I didn't know that. I stand corrected.
"It looks exactly the same on Windows and Linux, and the Linux version only uses Qt for a couple of things like font handling."
Which is a big problem. On Windows it should look and feel like a Windows app. On Linux it should look and feel like a Gnome or KDE app. By default.
It should use platform-specific features: external protocol handlers, file choosers, session management, native VFS, proxy settings, etc. It should also conform to the platform's usability guidelines: Menu structure, preferences windows, widget usage and spacing, button order, system font, system colours, etc.
Opera does use some of the features - but not all and completely ignores the usability guidelines. This is a big problem.
"Opera 7.5 has a great default skin."
No it doesn't. You may like it, but it is not great. A great skin would be one that causes it to look and behave like it conforms to the native usability guidelines of the platform. It should by default look exactly like every other sane Windows/Mac/Gnome/KDE program when run on that platform. If you wish to then screw up that consistency by using some other skin, fine, but it shouldn't be infliced on users by default.
BTW, most of Mozilla's products have the same problem (the notable exception being Camino), which is why I use Epiphany instead. But at least Mozilla is working *towards* platform consistency. Opera seems to be working away from it.
It's a funny thing. Mozilla has a cross platform toolkit and do their hardest to make sure that their apps look and feel like a native app. Opera starts with a native toolkit on each platform and do their hardest to make their app look and feel like no other app out there.
Crazyness.
On Windows it looks like some 13 year old put it together as a l33t shareware app and on Linux it uses Qt (aside from being non-free) so it's a non-starter for me.
"Almost nobody needs an XUL interface to their browser."
For Moz, Firefox and others, that's not true. They need XUL in the same way that Gnome apps need GTK.
"That's why there are so many smaller, faster, better Gecko-based browsers that work just fine--and what's missing from them is a mystery to the casual user."
Like XUL-based Firefox, that is at best a 4.7M download?
The Debian Firefox package is 10M. Compare to Epiphany, which is about 2.5M. That's only a difference of 7.5M which in the scheme of things is hardly significant, but Ephiphany doesn't even come with Gecko, NSS, NSPR and all of the other (essential) components that are included with Firefox and are essential for it to run. It takes more space to install Epiphany on my Debian machine that it does Firefox.
XUL is not heavyweight. It's just another markup language that Gecko can render.
"They wanted to built a suite. People didn't want one."
Many people do. Some of them complain bitterly everyday on Mozillazine about the suite being the poor cousin. In terms of footprint and convenience it does make some sense.
"They wanted to make Mozilla a platform for writing cross platform, network apps. People didn't want it to be one."
No, the Mozilla developers wanted a platform so they could write cross-platform apps, namely the suite, then later Firefox and othe others. But don't forget all of the extensions and developer tools that are also written for the platform and hence are all available on Windows, MacOS and Linux because of that.
"They wanted to use it to eventually make productivity apps. That's just stupid."
I don't know if that's the case or not, but why is it stupid? Their approach isn't any different to how OpenOffice works.
"They've been turning it around, but they still have a while to go."
I think they're there already. They have many kickarse products, which I use on a daily basis.
JWZ once said about Mozilla bloat: "Mozilla is big because your needs are big."
People demand a lot from their desktop these days, so their desktop does a lot of things. It can take a lot of code to do it all. Sure, you may get smaller binary sizes and no library dependencies writing everything in assembly, but a) it's infeasible and b) the desktop would lack most of the features people want.
But you're missing the point. Ever done an ldd on X or an Xserver? That's what Gosling is talking about.
Using this new windowing scheme with have little/no effect on existing clients because they will still use some toolkit like GTK to do their windowing and widgets. It's not like that client developers would have to write their own widget set for each client, they will still use GTK or Qt or whatever, just like they do today.
What will need to change is the toolkits themselves.
If you had actually RTFP you would see that he was advocating a windowing system that was even more simple what you suggest.
"But, basically, a 10% hit on someone who's 10 times more productive than average hurts a lot more than a 10% hit on someone who's average."
That may or may not be the case, but that 10% hit will diminish as you get used to the standard format. Eventually it will be 0%. Also, the more styles you use the faster you adapt to a newer one. I'm pretty comfortable slipping into a new style these days. But if you're contantly reformatting, you're constantly going to be taking a performance hit over the entire length of a project. It's just not worth it.
"However, the shops I've experienced with the most draconian formatting and layout rules also forbid the use of automated tools to support them!"
Well that's just completely insane. Did they also forbit the use of compilers and have you enter machine-code directly? I assume you got the hell out of there.
"It doesn't sound like you have been part of a team working on a product, or part of a team working on a component that gets used by other developers."
Sigh. Of course I have. Of those projects you listed, you're telling me that someone handed a design down from on high, it was perfect, and each of you shut themselves in your office and worked on your own code and at the end, it was all put together and it all worked? I don't believe it.
Using XP *demands* that everyone use a common formatting style. From the low-level concepts: Because one half of the pair actually writes the code, the other provides commentary and ideas for a while, then they swap. To the high: No-one "owns" some code: Anyone can come in a fix it. Constant integration and unit testing means you'll be getting and finding bugs all the time, rather than whenever the tree actually builds - so you'll be communicating with other developers *all* the time.
"The work should be defined and deliniated well enough so that one can work in isolation 80-90% of the time"
No, I disagree. Developers should know what they are writing and a provided with the support so that they can work on their part 100% of their time.
But regardless of the actualy percentage spent working on some code it doesn't mean they won't be interacting with other developers during the time you are working on somthing. Especially if you are using code produced by other developers, or vice-versa.
"What I usually find is that often I have to go back and correct someone else's work."
Which is annoying, but what does that have to do with source code formatting?
"See: you have to accomodate multiple styles, even if you have an internal one."
Yes, thanks for proving my point: You need to accomodate multiple styles. So you may as well get used to working in multiple styles.
The first rule of any useful sorce code convention is something like: "Use whatever style is currently in use in the source file you are working on". The second is "All new projects must commit source files conforming to these conventions".
"Most of the people I've enjoyed working with. Are they that rare? Anyone, who's had to adapt a popular open source code base within a project with a different house style."
I'm sorry, but I simply don't belive you. Very few open source projects run any sort of tool checking for correct formatting upon commit. Thus most of the codebase conforms to the convention in place, but never strictly so. If someone takes a random source file, converts it to their style of choice and makes a change, the diff is going to contain a *lot* of spurious deltas. It just doesn't work. This problem also exists for companies that don't use a tool to check formatting upon commit.
"How? If anything, the cost is bounded to be fixed and not a function of implementation time in excess of estimate."
Yes, so your project is going to cost $n and take m hours to complete. So you got paid $n/m per hour. You are "doing hours". This is especially the case when on a salary because you aren't salaried per project. If you aren't working on a projec
I think a lot of the changes in 1.5 are a response to C#. But I don't think this is a bad thing, and if you don't use the new constructs and APIs and provided you don't tell the compliler to target 1.5 only, then any code you write in 1.5 will be backwards compatible.
Also, I think annotations do belong with the class/method/field rather than in the comment. XDoclet is an excellent product but the only reason they overloaded the use of @tags in comments is because they couldn't put them in the actual source without breaking every Java tool out there. The JCP/can/ make this change and so they did. It would be great to see XDoclet supporting 1.5-style annotations, because that's where they belong.
I think you need to keep in mind that Sun is a commercial entity, they need to make money and so they need to keep up with the competition. The EJB3 spec is a response to the competition they are getting from various groups, including Microsoft. It's not about control, it's about competition.
No one is making you use v3 EJBs, so if you prefer using XDoclet and Hibernate, go for it! I personly only use the web-tier whenever possible because there usually isn't much need for the middle tier. But please don't complain about competition, it's a good thing. The EJB3 spec will only drive XDoclet and Hibernate guys to make their products better!
"Hey, this's suppose to be professional programming right? Why does this ejb3 way of programming looks so much like a hack and is not backward compatible?"
It's a new major version. EJB 3.x vs EJB 2.x. Most professional people consider this is the only time where it is acceptable to break backwards comaptibility.
If Sun needs to break backwards comaptibility to simpify EJBs, I'm all for it.
"Disbilief of my assertions might be one thing, and understandable, but to ignore the proof when the pudding has been presented, is moronic."
I'm looking, but so far I haven't seen any such evidence in your argument. Maybe I am a bit dense, can you summarise it for me?
"I am not arguing that it is impossible to deal with a foreign formatting standard. I am arguing however that this (a) slows down implementation (counting spaces and looking up style rules just to open a new basic block), and (b) enough to have a noticible effect on productivity."
*This* is where tool support is useful. Set up Emacs/vim/whatever so that it implements in-house style rules. When you commit, checkstyle (or similar) runs and prompts you to fix formatting errors before the changes are accepted in the repo.
Then, if you are producing a new line of code every thirty seconds over an eight-hour period (which I in no way whatsoever buy into), that means would be producing a new C-style block maybe every few minutes. You would be writing tens of if-then-else per hour, hundreds per day. You would get used to it, quickly. If the project was less than a week, sure that would suck, but for the next week-long project you would be fine.
Before I continue here, from the arguments you make, it has become clear you have worked on few projects where you had to interact with other people. In essense, it sounds like you would normally start working on a project and stop only when you feel like you have done enough for the day/night/whatever. It sounds like you work in an room, by yourself, without any communication with anyone else except at the start and end of the project.
It doesn't sound like you have been part of a team working on a product, or part of a team working on a component that gets used by other developers. When doing so, especially when working in parallel and when your code it going to be use by others (or vice-versa) efficient communication is essential. In such projects, over time, it is quicker to get used to a common formatting/style convention then it is to constantly convert beack and forth. Even if you don't use the standard, you will soon get used to it because you'll be constantly reading it and interpreting it.
If you are not working on such projects, then sure, use whatever style you want. If there is a code convention (many smaller companies/businesses don't have them) then set up your tools to reformat on checkout/diff/commit. Go for it.
I find it is interesting to note that most open source and free software projects have their own coding conventions and won't accept patches against the codebase unless they are formatted correctly. All of the big ones (Apache, the BSDs, the Linux kernel, GNU, Mozilla) require this. I think you'll find that few, in fact none of the contributors reformat as you suggest. No, I do not have any evidence to back this up, suffice to say I have never heard of anyone actually doing what you suggest. Not once. Never.
Show me two people who work with a coding style that is different from whatever the standard is and who reformat back and forth, as you suggest. Please. I'd love to talk to them.
Why do you think it is that, in reality, such people don't exist?
"No. It specifies what is to be done, and when it is to be delivered. If that means 10, 20, 40, 80, or 120 hours a week of work, so be it."
I have never seen such a contract, certainly not in Australia, although I conceed that it may be different in other countries. This would suprise me greatly, however because it makes poor business sense. Leaving such things unbounded leaves the employer open to cost blowouts. A devious person could easily pad developement time out by a significant, costly amount.
"You don't get it, do you?"
Yes, I do. Hacking is what I do. In my spare time, I hack on my own projects and have contributed to many free software and open source projects (Gnome, Mozilla, Apache, others). I have been lucky enough to have always be
"When developing, you reformat to your preference, and all debug information matches what you've got -- about the only time this breaks is if you've got external references to precompiled components with a different layout."
Here's some more areas where it breaks: - talking to other staff - sending a diff to someone else - receiving a diff from someone else - generating diffs from non-local sources like ViewCVS - debug line numbers from other staff/customers
"But, even then, if that code requires your attention during a debug cycle, it's not hard to reformat and recompile"
Ah, that would be you who is smoking crack. Nice numbers, BTW. Did the magical productivity fairies leave them under your pillow last night? Wait, wait, you also believe IQ tests are a reasonable measure of intelligence, don't you?
"Furthermore I don't "work hours". I am either salaried or work on contract."
Right, so your contract doesn't specify how many hours you are expected to show up and do work? Here's a hint, your salary is determined by your hourly rate multiplied by the number of hours you are expected to work per day/week/whatever. In fact as a salaryman, if you are in the tech industry you're probably going to be required to work overtime without remuneration.
You know, the last half of your rant makes you sound like some pimple-faced school boy.
I said "Crack induced" because that's how you sounded, and that's how you are sounding now.
"if reformatting to one's style of choice can not be automated, then it is likely quite odd"
The problem being you need to reformat from your personal choice to whatever is the standard whenever you aren't just editing the code locally - when compiling, committing, diffing, whatever, so that all other interactions with your code match the standard. The first case makes your life difficult because line numbers on debugging symbols stop matching what is in your codebase and what others see, as does the latter because your diffs won't match your code.
In any case, I would suggest that it is quicker to adapt to the standard style (not that hard) than modifying your complete toolchain (if at all possible) and working around the differences whenever you compare your code with that of other's (for all eternity).
"By the same token, I hate to work with a selfish mob that naively thinks that a common style in which to edit is necessary any better than any other reasonably structured one and that is likely to match what they inherit."
Gee, and the selfish mob expect you to do work for the hours they pay you for. How naive.
a) it's in your own interest b) it's in the company's interest b) welcome to capitalism, where the good of the Man comes before the good of the you.
Slashdot Mirror
But Ruby is new and hip and cool! Anyway, you can't tell me that Smalltalk-80 has good support for Unicode. Wouldn't Squeak be a better option anyway?
Apparently there are Gnome bindings for Smalltalk-80. If so, what are you waiting for, get hacking!
Was it an ad for Gnome, Imendio, or OSNews?
In any case, those guys (Imendio) produce some excellent Free Software (Gossip, Planner, that I am familiar with) for that platform (Gnome). I'm happy to see them get a bit of publicity.
Oh come on, you don't actually expect me to RTFA, do you?
Besides I did, saw static and came back here. I wonder if it has erupted already.
Which is great, but where on earth (quite literally) is Mt St Helens?
I can't seem to see it out my window.
Apart from the fact that these bindings are for KDE, of course.
The point being that the existence GTK/Gnome bindings for ages have failed to change the primary language for building Gnome apps, so there's little chance that these Qt/KDE bindings will usher in a new era of anything, either.
There needs to be some consensus in the community about such things and given we can't even agree on the One True text editor, it is unlikely we're going to agree on a next-generation application development language.
Solution: Use whatever you feel like.
So how is this different to the GTK/Gnome bindings for Ruby that have been out for years?
Personally, I'd love to see Ruby used as the next-gen language for Free Software application development. It rocks!
I think you're blowing stuff right out of proportion.
First, if you have such a contrained machine (64Mb), you need to accept that it doesn't have the resources to run a bunch of heavyweight applications concurrently. You can still run these apps, but either not at the same time or you need to put up with the swap thrashing.
Second, right now I'm running all those apps you state and more: OOo, Epiphany (effectively the same as Firefox), Evo, Emacs and a bunch of Gnome terminals. This is on my workstation where I have Apache and a bunch of other developer-oriented daemons running and my memory usage is clocking in at 231Mb physical, 1.1Mb swap. This machine is an aging P3 700 and everything running feels positively snappy.
Adding up the resident memory sizes of OOo, Epiphany and Evo, I get 142Mb (which admittedly *is* a lot) but on a 128Mb machine shouldn't be too much of a strain. I don't know where you get your "XP + blah is snappy on 128Mb" metric, I've seen XP thrash on such a machine with no apps running at all.
Lastly, I'd like to make the standard observation that if half of the above was running at ring 0 like it does in Windows, it would probably be a lot snappier and a lot crashier, just like Windows.
"On Windows it does look and feel like a Windows app... Well, as much as any Windows app really. Same for Linux. For Mac there's more tweaking to make it more Mac-like."
:)"
Not at all. Under Linux it doesn't integrate at all with Gnome, so it is a non-starter for me: It is not a GTK app (hence ignores system theme, no native file chooser, etc.), it has an MDI and absolutely does not follow the Gnome Human Interface Guidelines.
On Windows: It uses a theme that by default does not mimic the standard Windows look and feel. It does weird things like popup a context menu when double clicking on a word. It has some crazy icon before the file menu in the menu bar. It doesn't use Windows' standard help system and the menus (especially the Window menu) are on serious crack. It's got an MDI (which is bad in itself) but is inconsistent with how every other MDI I have seen on Windows works.
"And you know for a fact that it doesn't do all or some these things? Or are you just assuming?"
I know for a fact.
"A sweeping statement with little contact with reality."
A sweeping statement, sure, but 100% accurate for Gnome desktops, mostly accurate for Windows and Mac desktops and I'd guess that it is mostly accurate for KDE and every other Linux desktop as well.
"Uh, yes, it is great actually."
For you, sure. For people in general it's not, because the theme doesn't look like a standard application.
"Look, you keep making these misguided statements about what Opera supposedly does or doesn't do... Have you actually tried it?!
Yep. Don't get me wrong: Opera is my default browser on my SE P800 phone, and I use it almost every day, it works really well. I also keep the latest version for Linux and Windows for testing websites, but because of the stuff I outlined above I find using Opera a horrible browser to use on the desktop.
"Nope. Opera has an internal cross-platform toolkit. The UI is mostly the same on all platforms, except Mac where some parts have been "Macified"."
Okay, I didn't know that. I stand corrected.
"It looks exactly the same on Windows and Linux, and the Linux version only uses Qt for a couple of things like font handling."
Which is a big problem. On Windows it should look and feel like a Windows app. On Linux it should look and feel like a Gnome or KDE app. By default.
It should use platform-specific features: external protocol handlers, file choosers, session management, native VFS, proxy settings, etc. It should also conform to the platform's usability guidelines: Menu structure, preferences windows, widget usage and spacing, button order, system font, system colours, etc.
Opera does use some of the features - but not all and completely ignores the usability guidelines. This is a big problem.
"Opera 7.5 has a great default skin."
No it doesn't. You may like it, but it is not great. A great skin would be one that causes it to look and behave like it conforms to the native usability guidelines of the platform. It should by default look exactly like every other sane Windows/Mac/Gnome/KDE program when run on that platform. If you wish to then screw up that consistency by using some other skin, fine, but it shouldn't be infliced on users by default.
BTW, most of Mozilla's products have the same problem (the notable exception being Camino), which is why I use Epiphany instead. But at least Mozilla is working *towards* platform consistency. Opera seems to be working away from it.
Hard day at work, huh?
Sure sure.
It's a funny thing. Mozilla has a cross platform toolkit and do their hardest to make sure that their apps look and feel like a native app. Opera starts with a native toolkit on each platform and do their hardest to make their app look and feel like no other app out there.
Crazyness.
On Windows it looks like some 13 year old put it together as a l33t shareware app and on Linux it uses Qt (aside from being non-free) so it's a non-starter for me.
So, the clean install that flushed all of the worms, viruses and sypyware really helped, hey?
And now that you have SP2 installed, it will take longer than evar!11! to get bogged down again.
Yay111!1
Dude, have you seen Opera's default UI? What those guys do to platform consistency is scary!
These days, the ANZAC spirit revolves around sport, cars, bending over for George Bush and illegally, immorally putting refugees in prision.
I have been ashamed to call myself Australian for years.
I think Howard can be called a dipshit for pretty much everything he has done.
"My needs aren't that big."
No, but other's are.
"Almost nobody needs an XUL interface to their browser."
For Moz, Firefox and others, that's not true. They need XUL in the same way that Gnome apps need GTK.
"That's why there are so many smaller, faster, better Gecko-based browsers that work just fine--and what's missing from them is a mystery to the casual user."
Like XUL-based Firefox, that is at best a 4.7M download?
The Debian Firefox package is 10M. Compare to Epiphany, which is about 2.5M. That's only a difference of 7.5M which in the scheme of things is hardly significant, but Ephiphany doesn't even come with Gecko, NSS, NSPR and all of the other (essential) components that are included with Firefox and are essential for it to run. It takes more space to install Epiphany on my Debian machine that it does Firefox.
XUL is not heavyweight. It's just another markup language that Gecko can render.
"They wanted to built a suite. People didn't want one."
Many people do. Some of them complain bitterly everyday on Mozillazine about the suite being the poor cousin. In terms of footprint and convenience it does make some sense.
"They wanted to make Mozilla a platform for writing cross platform, network apps. People didn't want it to be one."
No, the Mozilla developers wanted a platform so they could write cross-platform apps, namely the suite, then later Firefox and othe others. But don't forget all of the extensions and developer tools that are also written for the platform and hence are all available on Windows, MacOS and Linux because of that.
"They wanted to use it to eventually make productivity apps. That's just stupid."
I don't know if that's the case or not, but why is it stupid? Their approach isn't any different to how OpenOffice works.
"They've been turning it around, but they still have a while to go."
I think they're there already. They have many kickarse products, which I use on a daily basis.
JWZ once said about Mozilla bloat: "Mozilla is big because your needs are big."
People demand a lot from their desktop these days, so their desktop does a lot of things. It can take a lot of code to do it all. Sure, you may get smaller binary sizes and no library dependencies writing everything in assembly, but a) it's infeasible and b) the desktop would lack most of the features people want.
But you're missing the point. Ever done an ldd on X or an Xserver? That's what Gosling is talking about.
Using this new windowing scheme with have little/no effect on existing clients because they will still use some toolkit like GTK to do their windowing and widgets. It's not like that client developers would have to write their own widget set for each client, they will still use GTK or Qt or whatever, just like they do today.
What will need to change is the toolkits themselves.
If you had actually RTFP you would see that he was advocating a windowing system that was even more simple what you suggest.
"But, basically, a 10% hit on someone who's 10 times more productive than average hurts a lot more than a 10% hit on someone who's average."
That may or may not be the case, but that 10% hit will diminish as you get used to the standard format. Eventually it will be 0%. Also, the more styles you use the faster you adapt to a newer one. I'm pretty comfortable slipping into a new style these days. But if you're contantly reformatting, you're constantly going to be taking a performance hit over the entire length of a project. It's just not worth it.
"However, the shops I've experienced with the most draconian formatting and layout rules also forbid the use of automated tools to support them!"
Well that's just completely insane. Did they also forbit the use of compilers and have you enter machine-code directly? I assume you got the hell out of there.
"It doesn't sound like you have been part of a team working on a product, or part of a team working on a component that gets used by other developers."
Sigh. Of course I have. Of those projects you listed, you're telling me that someone handed a design down from on high, it was perfect, and each of you shut themselves in your office and worked on your own code and at the end, it was all put together and it all worked? I don't believe it.
Using XP *demands* that everyone use a common formatting style. From the low-level concepts: Because one half of the pair actually writes the code, the other provides commentary and ideas for a while, then they swap. To the high: No-one "owns" some code: Anyone can come in a fix it. Constant integration and unit testing means you'll be getting and finding bugs all the time, rather than whenever the tree actually builds - so you'll be communicating with other developers *all* the time.
"The work should be defined and deliniated well enough so that one can work in isolation 80-90% of the time"
No, I disagree. Developers should know what they are writing and a provided with the support so that they can work on their part 100% of their time.
But regardless of the actualy percentage spent working on some code it doesn't mean they won't be interacting with other developers during the time you are working on somthing. Especially if you are using code produced by other developers, or vice-versa.
"What I usually find is that often I have to go back and correct someone else's work."
Which is annoying, but what does that have to do with source code formatting?
"See: you have to accomodate multiple styles, even if you have an internal one."
Yes, thanks for proving my point: You need to accomodate multiple styles. So you may as well get used to working in multiple styles.
The first rule of any useful sorce code convention is something like: "Use whatever style is currently in use in the source file you are working on". The second is "All new projects must commit source files conforming to these conventions".
"Most of the people I've enjoyed working with. Are they that rare? Anyone, who's had to adapt a popular open source code base within a project with a different house style."
I'm sorry, but I simply don't belive you. Very few open source projects run any sort of tool checking for correct formatting upon commit. Thus most of the codebase conforms to the convention in place, but never strictly so. If someone takes a random source file, converts it to their style of choice and makes a change, the diff is going to contain a *lot* of spurious deltas. It just doesn't work. This problem also exists for companies that don't use a tool to check formatting upon commit.
"How? If anything, the cost is bounded to be fixed and not a function of implementation time in excess of estimate."
Yes, so your project is going to cost $n and take m hours to complete. So you got paid $n/m per hour. You are "doing hours". This is especially the case when on a salary because you aren't salaried per project. If you aren't working on a projec
I think a lot of the changes in 1.5 are a response to C#. But I don't think this is a bad thing, and if you don't use the new constructs and APIs and provided you don't tell the compliler to target 1.5 only, then any code you write in 1.5 will be backwards compatible.
/can/ make this change and so they did. It would be great to see XDoclet supporting 1.5-style annotations, because that's where they belong.
Also, I think annotations do belong with the class/method/field rather than in the comment. XDoclet is an excellent product but the only reason they overloaded the use of @tags in comments is because they couldn't put them in the actual source without breaking every Java tool out there. The JCP
I think you need to keep in mind that Sun is a commercial entity, they need to make money and so they need to keep up with the competition. The EJB3 spec is a response to the competition they are getting from various groups, including Microsoft. It's not about control, it's about competition.
No one is making you use v3 EJBs, so if you prefer using XDoclet and Hibernate, go for it! I personly only use the web-tier whenever possible because there usually isn't much need for the middle tier. But please don't complain about competition, it's a good thing. The EJB3 spec will only drive XDoclet and Hibernate guys to make their products better!
"Hey, this's suppose to be professional programming right? Why does this ejb3 way of programming looks so much like a hack and is not backward compatible?"
It's a new major version. EJB 3.x vs EJB 2.x. Most professional people consider this is the only time where it is acceptable to break backwards comaptibility.
If Sun needs to break backwards comaptibility to simpify EJBs, I'm all for it.
"Disbilief of my assertions might be one thing, and understandable, but to ignore the proof when the pudding has been presented, is moronic."
I'm looking, but so far I haven't seen any such evidence in your argument. Maybe I am a bit dense, can you summarise it for me?
"I am not arguing that it is impossible to deal with a foreign formatting standard. I am arguing however that this (a) slows down implementation (counting spaces and looking up style rules just to open a new basic block), and (b) enough to have a noticible effect on productivity."
*This* is where tool support is useful. Set up Emacs/vim/whatever so that it implements in-house style rules. When you commit, checkstyle (or similar) runs and prompts you to fix formatting errors before the changes are accepted in the repo.
Then, if you are producing a new line of code every thirty seconds over an eight-hour period (which I in no way whatsoever buy into), that means would be producing a new C-style block maybe every few minutes. You would be writing tens of if-then-else per hour, hundreds per day. You would get used to it, quickly. If the project was less than a week, sure that would suck, but for the next week-long project you would be fine.
Before I continue here, from the arguments you make, it has become clear you have worked on few projects where you had to interact with other people. In essense, it sounds like you would normally start working on a project and stop only when you feel like you have done enough for the day/night/whatever. It sounds like you work in an room, by yourself, without any communication with anyone else except at the start and end of the project.
It doesn't sound like you have been part of a team working on a product, or part of a team working on a component that gets used by other developers. When doing so, especially when working in parallel and when your code it going to be use by others (or vice-versa) efficient communication is essential. In such projects, over time, it is quicker to get used to a common formatting/style convention then it is to constantly convert beack and forth. Even if you don't use the standard, you will soon get used to it because you'll be constantly reading it and interpreting it.
If you are not working on such projects, then sure, use whatever style you want. If there is a code convention (many smaller companies/businesses don't have them) then set up your tools to reformat on checkout/diff/commit. Go for it.
I find it is interesting to note that most open source and free software projects have their own coding conventions and won't accept patches against the codebase unless they are formatted correctly. All of the big ones (Apache, the BSDs, the Linux kernel, GNU, Mozilla) require this. I think you'll find that few, in fact none of the contributors reformat as you suggest. No, I do not have any evidence to back this up, suffice to say I have never heard of anyone actually doing what you suggest. Not once. Never.
Show me two people who work with a coding style that is different from whatever the standard is and who reformat back and forth, as you suggest. Please. I'd love to talk to them.
Why do you think it is that, in reality, such people don't exist?
"No. It specifies what is to be done, and when it is to be delivered. If that means 10, 20, 40, 80, or 120 hours a week of work, so be it."
I have never seen such a contract, certainly not in Australia, although I conceed that it may be different in other countries. This would suprise me greatly, however because it makes poor business sense. Leaving such things unbounded leaves the employer open to cost blowouts. A devious person could easily pad developement time out by a significant, costly amount.
"You don't get it, do you?"
Yes, I do. Hacking is what I do. In my spare time, I hack on my own projects and have contributed to many free software and open source projects (Gnome, Mozilla, Apache, others). I have been lucky enough to have always be
"When developing, you reformat to your preference, and all debug information matches what you've got -- about the only time this breaks is if you've got external references to precompiled components with a different layout."
Here's some more areas where it breaks:
- talking to other staff
- sending a diff to someone else
- receiving a diff from someone else
- generating diffs from non-local sources like ViewCVS
- debug line numbers from other staff/customers
"But, even then, if that code requires your attention during a debug cycle, it's not hard to reformat and recompile"
Ah, that would be you who is smoking crack. Nice numbers, BTW. Did the magical productivity fairies leave them under your pillow last night? Wait, wait, you also believe IQ tests are a reasonable measure of intelligence, don't you?
"Furthermore I don't "work hours". I am either salaried or work on contract."
Right, so your contract doesn't specify how many hours you are expected to show up and do work? Here's a hint, your salary is determined by your hourly rate multiplied by the number of hours you are expected to work per day/week/whatever. In fact as a salaryman, if you are in the tech industry you're probably going to be required to work overtime without remuneration.
You know, the last half of your rant makes you sound like some pimple-faced school boy.
Yes, but the K&R/GNU (?) style braces of the second example pushes bar() down by one line, so bar() is still on a different line.
I said "Crack induced" because that's how you sounded, and that's how you are sounding now.
"if reformatting to one's style of choice can not be automated, then it is likely quite odd"
The problem being you need to reformat from your personal choice to whatever is the standard whenever you aren't just editing the code locally - when compiling, committing, diffing, whatever, so that all other interactions with your code match the standard. The first case makes your life difficult because line numbers on debugging symbols stop matching what is in your codebase and what others see, as does the latter because your diffs won't match your code.
In any case, I would suggest that it is quicker to adapt to the standard style (not that hard) than modifying your complete toolchain (if at all possible) and working around the differences whenever you compare your code with that of other's (for all eternity).
"By the same token, I hate to work with a selfish mob that naively thinks that a common style in which to edit is necessary any better than any other reasonably structured one and that is likely to match what they inherit."
Gee, and the selfish mob expect you to do work for the hours they pay you for. How naive.
a) it's in your own interest
b) it's in the company's interest
b) welcome to capitalism, where the good of the Man comes before the good of the you.
Even if they are 60 lines long, they'll fall off the bottom of my 80x40 emacs windows. :)