Do you suggest me using IDE when I'm learning JAVA
in [Java Help]
|
Prev: call jni function dynamically without getting a JNIEnv handleas an argument.
Next: Encoding issue on my jsp page
From: Martin Gregorie on 3 May 2010 13:01 On Mon, 03 May 2010 07:46:01 -0700, cr88192 wrote: > GIMP is often regularly used on Windows though, whereas xfig is not > (although AFAIK it comes with Cygwin along with its special X > server...). > I intended to say rather the opposite: Windows is quite well supplied with graphics tools that can draw vector shapes by rubberbanding or marking vertices: MS Paint, Visio, Paintbox Pro, and (IIRC) L-View Pro all come to mind but these seem to be pretty thin on the ground for Linux and other X11 based systems: xfig is the only one I've found so far. I find it much easier to make clean-looking icons with vector graphics type drawing tools so I was suggesting it as a useful companion to the GIMP for this sort of task on X11 systems. If you know of better equivalents to xfig, especially any with a more Gnome-like UI, I'd be interested to try them out. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Jim Janney on 3 May 2010 14:37 "Mike Schilling" <mscottschilling(a)hotmail.com> writes: > Jim Janney wrote: >> 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). > > True, but the class file format is simple enough that one would whip up a > (say) C++ version of Java reflection in at most a few weeks. I know less > about JPDA, but I suspect the same is true. Yes. On further reflection I think it's probably a minor factor. Languages that support introspection may be easier in general to write IDEs for, but other factors probably dominate. Eclipse wouldn't be what it is today without IBM's backing, for example. As a test case I did a quick search on IDEs for Python, and plugins for NetBeans and Eclipse seem to be competitive with the ones written specifically for Python. -- Jim Janney
From: Lew on 3 May 2010 19:49 On 05/03/2010 08:46 AM, > On Mon, 3 May 2010, Arved Sandstrom wrote: > Arne Vajhøj wrote: >> 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. Tom Anderson wrote: > I find what i [sic] assume to be Arne's point shocking. The ideal software > process would spend *100%* of its time writing code, because it would That's ridiculous. > 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. So you completely discount planning, designing, testing, filling out time cards, taking a whiz, coffee, conversations with team mates and management, meetings, training, and all the other ancillary activities that make up a work day. All of which contribute to the output. What utter irredeemable nonsense. You think like the worst kind of software-development manager. -- Lew
From: Arne Vajhøj on 3 May 2010 22:00 On 02-05-2010 23:53, Lew wrote: > On 05/02/2010 09:56 PM, Arne Vajhøj wrote: >> On 02-05-2010 16:11, Lew wrote: >>> On 05/02/2010 03:18 PM, Eric Sosman wrote: >>>> On 5/2/2010 2:27 PM, Lew wrote: >>>>> Arved Sandstrom wrote: >>>>>> Fortunately "may not" is one of the modal negatives that has a fairly >>>>>> unambiguous meaning, as in, "not allowed". That doesn't mean that a >>>>>> lot >>>>>> of people don't use it incorrectly, though. >>>>> >>>>> "Correctly" according to you. I've heard "may not" to mean "might not" >>>>> my entire life. >>>> >>>> "Mom, can I use the car?" >>>> >>>> "You mean `may'." >>>> >>>> "Sorry. Mom, may I use the car?" >>>> >>>> "No, you may not." >>> >>> Your point may not have been clear here. What are you trying to say? >> >> That "may not" can have a meaning as "absolutely not". > > That is a pointless point since it never was in dispute. Well, if you agree that it can have that meaning and that meaning makes more sense in the context and is similar to the meaning in which it is used in other language definitions, then don't you think it starts to indicate something? Arne
From: Arne Vajhøj on 3 May 2010 22:02
On 03-05-2010 07:08, 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. > > 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. Sure - but no matter if he is creating UML, Java LOC's or running JUnit tests, then I would expect thinking to dominate over typing. And thinking is a process that unfortunatetly does not benefit from better tools. Arne |