Do you suggest me using IDE when I'm learning JAVA
in [Java Programming]
|
Prev: call jni function dynamically without getting a JNIEnv handleas an argument.
Next: Telnetting to diff IP with same port number
From: Lew on 3 May 2010 07:48 Arved Sandstrom wrote: > 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. Similarly with the Java IDEs, which are written in Java. -- Lew
From: Lew on 3 May 2010 07:56 Arved Sandstrom wrote: > 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, You know you can change that, right? -- Lew
From: Tom Anderson on 3 May 2010 08:46 On Mon, 3 May 2010, Arved Sandstrom wrote: > 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. > > 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. I find what i assume to be Arne's point shocking. The ideal software process would spend *100%* of its time writing code, because it would have optimised all the supporting activities to the point where all working time could be put into the one activity that actually produces the output. tom -- Science is the outcome of being prepared to live without certainty and therefore a mark of maturity. -- AC Grayling
From: Martin Gregorie on 3 May 2010 09:05 On Sun, 02 May 2010 19:42:11 -0700, BGB / cr88192 wrote: > this would seem to be all of them, and I suspect CR is falling into > oblivion (since OSX switched to LF...). > I didn't know that OSX used CR. Presumably that was for OS9 and earlier? Since OSX is based on BSD I's jus assumed it would use LF. The only place I've seen CR linefeeds at all recently was in Microware's OS-9 OS - which, by coincidence runs on MC6809 and MC68xxx hardware. Speaking of MC6809 kit, I don't remember what TSC's Flex-09 used despite owning a still-functional system. Possibly that was CR as well. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Martin Gregorie on 3 May 2010 09:09
On Sun, 02 May 2010 19:36:53 -0700, BGB / cr88192 wrote: > OTOH, one can also use a different editor (I have little idea why MS > never really bothered with LF-only line-ending support, as I wouldn't > think this would be much more than maybe a few lines of code, but oh > well, whatever...). > Most people who deal with this regularly have command line, and hence scriptable, tools to deal with it, e.g. unix2dos and dos2unix in the UNIX world or you can always use tr, which has been ported to about as many OSen as grep has. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | |