From: RedGrittyBrick on
On 03/05/2010 06:44, BGB / cr88192 wrote:
> "Lew" wrote
>> BGB / cr88192 wrote:
>>> personally, IMHO, I find that Emacs is just horrid and prefer to stay
>>> well clear of it...
>>
>> <http://en.wikipedia.org/wiki/Editor_war>
>>
>
> yep.
> Notepad is the one true editor...
>
> and, when not Notepad, something sort of like Notepad:

That would be Cream!
http://cream.sourceforge.net/
;-)

--
RGB
From: Arved Sandstrom on
Arne Vajh�j wrote:
> On 02-05-2010 15:49, Arved Sandstrom wrote:
>> Arne Vajh�j wrote:
>>> On 02-05-2010 08:46, Arved Sandstrom wrote:
>>>> Arne Vajh�j wrote:
>>>>> On 01-05-2010 20:53, Arved Sandstrom wrote:
>>>>>> What GUI tools?
>>>>>
>>>>> It seems to be the entire development suite.
>>>>
>>>> What it looks like, if we're examining Table 8-5 in that document, is
>>>> that "Very High Level of Automation (circa 2000+)" gets a tool
>>>> rating of
>>>> 0.83 as compared to 0.91 for "High Level of Automation (circa 1980+)".
>>>>
>>>> So yes, approximately 10 percent better for 2000+.
>>>>
>>>> But look at what they are including for even 1980+:
>>>>
>>>> CASE tools
>>>> Basic graphical design aids
>>>> Word processor
>>>> Implementation standards enforcer
>>>> Static source code analyzer
>>>> Program flow and test case analyzer
>>>> Full program support library with configuration management (CM) aids
>>>> Full integrated documentation system
>>>> Automated requirement specification and analysis
>>>> General purpose system simulators
>>>> Extended design tools and graphics support
>>>> Automated verification system
>>>> Special purpose design support tools
>>>>
>>>> When was the last time you ever saw - let alone worked in - a shop that
>>>> did even a substantial fraction of all of that? Particularly back in
>>>> the
>>>> '80s? It would have taken a very good operation indeed to be using most
>>>> of those tools back in, say, 1985. Whereas if we examine the 2000+
>>>> list:
>>>>
>>>> Integrated application development environment
>>>> Integrated project support
>>>> Visual programming tools
>>>> Automated code structuring
>>>> Automated metric tools
>>>> GUI development and testing tools
>>>> Fourth Generation Languages (4GLs)
>>>> Code generators
>>>> Screen generators
>>>>
>>>> there is a much better chance, IMHO, that a larger fraction of that
>>>> list
>>>> is in play for even moderately good organizations.
>>>>
>>>> Worst case (and a fairly common one) we're really comparing text editor
>>>> (1980+) to IDE (2000+). Good case (and also a reasonably common one)
>>>> we're comparing most of the 2000+ list to very little of the 1980+
>>>> list.
>>>>
>>>> So I think in reality the productivity gains for most organizations,
>>>> based on tools, have been considerably greater.
>>>
>>> I believe a lot of their input is DoD projects. They tend to
>>> spend a lot on quality - the cost of launching a nuclear missile
>>> due to a software bug is a bit high.
>>>
>>> The 10% sound very reasonable to me.
>>>
>>> If we just compare text editor to IDE and we assume that
>>> an IDE is 10 times faster than a text editor and that
>>> a developer on complex projects only spend 5% of the time
>>> actually writing the code, then that part can only contribute
>>> 4.5%. And 10 times faster is a rather aggressive assumption.
>>
>> Rightly or wrongly, with the state of software engineering being what it
>> is I'd guess, based on observation, that many (if not most) developers
>> spend more like 50 percent of their time - time which can be directly
>> tracked against a software project - buried in their IDEs. Often it's
>> higher than that. I've seen any number of junior and intermediate
>> programmers over the years who are not tasked with anything but coding,
>> in which case they are north of 75%.
>>
>> With those numbers then just a 2x speedup in using a IDE over a text
>> editor is significant.
>
> Yes.
>
> But please don't use the term software ENGINEERING about a
> process that spends 50-75% of the time in the IDE.
>
> Arne

I think it would depend on the role of the developer and the particular
methodology in use - 50%+ time spent in the IDE might not be indicative
of a low state of software process, or it might be.

And after all, IDE does mean _Integrated_ Development _Environment_. In
theory a developer could be knocking out everything from requirements
analysis through design and coding to running/analyzing tests in one of
those puppies.

AHS
From: Arved Sandstrom on
Jim Janney wrote:
> Arved Sandstrom <dcest61(a)hotmail.com> writes:
>
>> Lew wrote:
>>> Arved Sandstrom wrote:
>>>>> A lot depends on exactly what it is that people are writing. If I was
>>>>> writing a Linux device driver in C I'd be cool with vim. But these days,
>>>>> where I have to deal with .NET or J2EE web apps with thousands of source
>>>>> files, I'd be an imbecile to try and do that with emacs.
>>> Arne Vajhøj wrote:
>>>> Emacs is pretty close to an IDE.
>>>>
>>>> But I don't know how good its Java and C# support is though.
>>> For C and C++, given that emacs integrates source editing,
>>> compilation, linking and debugging (synchronized with source
>>> listings), "close" isn't accurate - emacs is an IDE.
>>>
>>> I have not found it as useful for Java.
>>>
>> I agree, for some languages like C or C++ emacs _is_ an IDE. A prof of
>> mine wrote a fairly large C++ tool
>> (http://gri.sourceforge.net/index.php) using emacs, and he would have
>> been doing everything from within emacs. Depending on how much a
>> person's emacs has been tooled up it's a mistake to call it a text
>> editor.
>>
>> This is a fairly representative discussion regarding emacs vs Eclipse
>> for Java:
>> http://stackoverflow.com/questions/689544/is-emacs-useful-compared-to-eclipse-programming-java.
>>
>>
>> I don't doubt that there are some very good Java developers out there
>> who use nothing but emacs. If I used nothing but emacs, had it
>> thoroughly tooled up, knew all my shell mantras and had shell scripts
>> available to duplicate what a lot of Eclipse commands do, and had an
>> encyclopedic knowledge of the Java APIs for the areas that I'm working
>> in, I'd be just as fast as if I were using Eclipse.
>>
>> AHS
>
> At one time I did a lot of coding in Emacs Lisp, using Emacs of
> course, and for that Emacs was a very good IDE indeed, as good as
> anything I've used. Which leads me to speculate that for reasonably
> dynamic languages (Java and Lisp and C# but not C or C++) the best IDE
> is one written in the target language. For example, I really expect
> any Java IDE to take advantage of the reflection API, and that's
> easiest done from Java (or at least some JVM-based language).
>
Interesting observation. My favourite IDE for Haskell is Leksah (quite a
nice piece of work in its 0.8 incarnation), and that's written in
Haskell. If nothing else the developers writing the IDE are developing
in the target language, so they are constantly immersed in doing exactly
what they want the IDE ultimately to help with.

AHS
From: Arved Sandstrom on
Lew wrote:
[ SNIP ]

> Personally I use NetBeans when allowed, Eclipse and its offspring quite
> frequently, and am interested in this new Brown University "Code
> Bubbles" editor.
> <http://www.cs.brown.edu/people/acb/codebubbles_site.htm>

Nice find on Code Bubbles...I'll have to try that out too. :-)

> I plan to look into JDeveloper, and I drop into emacs for quite a few
> things, even the occasional Java source file.

Interestingly enough JDeveloper's parent, JBuilder (which I used back in
the day), is still available from Embarcadero (CodeGear). That's gotten
so far off my radar screen that I can't say I've run across anyone that
uses it in years. But surely some people do.

My most frequent use of emacs is when I forget to supply a comment when
doing a command line Subversion commit; my EDITOR on my UNIXes is emacs,
so I have to write my comments using that. :-) I don't have anything
against emacs in particular, but if I need a text editor I'll use vi or
gedit normally.

AHS
From: Lew on
Arved Sandstrom wrote:
> And after all, IDE does mean _Integrated_ Development _Environment_. In
> theory a developer could be knocking out everything from requirements
> analysis through design and coding to running/analyzing tests in one of
> those puppies.

And in practice.

The top Java IDEs have varying degrees of support for design-time activities,
e.g., UML tools. They all intrinsically support JUnit. They all act as
really great control panels for database systems and app servers. They handle
deployment descriptors as such, and other XML quite niftily. They tightly
integrate with the major version-control systems. They capture the output of
these processes for perusal, storage on disk, diff comparison and the like.

I love that they control app servers and database systems.

--
Lew