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: Tom Anderson on 4 May 2010 19:32 On Mon, 3 May 2010, Lew wrote: > 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. Nope. >> 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, Yep. It's a good idea, but the less time you can spend doing it, the better. > designing, Part of programming, done in the IDE. > testing, Part of programming, done in the IDE. > filling out time cards, Yep. > taking a whiz, coffee, conversations with team mates and management, Essential, but not part of the denominator of that 100%. > meetings, SUPER YEP. > training, I've yet to come across any training worth anything that wasn't done by sitting at a machine and actually doing something. > and all the other ancillary activities that make up a work day. All of > which contribute to the output. Nope. > What utter irredeemable nonsense. Nope. > You think like the worst kind of software-development manager. Nope. I think you'll find that the worst managers are the ones who want everyone to spend *less* time programming, because they want them to spend *more* time in meetings, preparing documents, etc. Our goal is to build things out of software. Time we spend not building things out of software is, from a professional point of view, wasted. We should minimise waste. tom -- My goal wasn't to make a ton of money. It was to build good computers. -- Woz
From: Tom Anderson on 4 May 2010 19:40 On Mon, 3 May 2010, Arne Vajh?j wrote: > On 03-05-2010 07:08, Arved Sandstrom wrote: >> Arne Vajh?j wrote: >>> 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. No, this is rubbish. Programmers don't spend ages sitting there thinking, and then do a bit of typing. This is pure fiction. We think as we type - we think *by* typing, by putting our ideas down, working through the details, trying things out, seeing what works and what doesn't. Masses of thinking goes on, but it's not like some caricature of a mathematician, staring at a ceiling for days on end and then jotting down a complete theorem at the end of it. To do the thinking, you have to work through it - and better tools let you work through it faster. If by the use of autocomplete and type inference and whatnot i can flesh out a for-loop over the entries of a map in which i filter the keys with such-and-such a test and transform the corresponding values with this-or-that function in thirty seconds rather than three minutes, then that's two minutes and thirty seconds less that's taken me to learn if my idea for the loop works or not. That's the kind of thing i spend my time doing when i program, and an IDE does help me to do that faster. tom -- My goal wasn't to make a ton of money. It was to build good computers. -- Woz
From: Tom Anderson on 4 May 2010 19:44 On Tue, 4 May 2010, Jim Janney wrote: > "BGB / cr88192" <cr88192(a)hotmail.com> writes: > >> "Arne Vajh?j" <arne(a)vajhoej.dk> wrote in message >> news:4bdf80e8$0$285$14726298(a)news.sunsite.dk... >>> On 02-05-2010 22:49, Jim Janney wrote: >>> >>>> 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). >>> >>> I think that is more about eating ones own dog food paradigm. >>> >>> The technical problems of doing IDE for language A in language B are >>> solvable. >> >> the technical differences between languages should be relatively >> trivial WRT writing an IDE. pretty much any sufficiently capable >> language should be able to write an IDE for pretty much any other >> sufficiently capable language. > > This is where the bit about "for reasonably dynamic languages" comes > into play. A Lisp program can easily modify itself at runtime, using > the mechanisms of the language in a very natural way; this makes it an > obvious choice for writing a Lisp IDE. The word you're looking for is 'homoiconic' - meaning that running programs are represented by the same means as the data manipulated by those programs. > I'm not sure, now that I think about it, whether Java fits into this > category or not. It doesn't. > You can load new classes at runtime; you can even assemble byte code in > memory and then load it as a class, but it's not what I'd consider a > natural part of the language. And languages like C and Fortran don't > even have a foot in the door. C doesn't? You never heard of void*? tom -- My goal wasn't to make a ton of money. It was to build good computers. -- Woz
From: Arne Vajhøj on 4 May 2010 20:02 On 04-05-2010 00:57, BGB / cr88192 wrote: > "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message >> Some languages may not even be that suited for writing IDE's. I am >> not sure that writing a Fortran IDE in Fortran would be optimal. > > depends on the variety of Fortran, but admittedly I would not likely do > this... The last real Fortran was 77. :-) > if I were to pick a language for the task of writing an IDE, personally I > would likely pick either a mix of C and C++ (my typical major-use > languages). Java or C# seems more obvious to me. > the big downside of C and C++ is that there is no really good and portable > ways to do GUIs, leading to issues here no matter which route is chosen. > typically I have done GUIs via OpenGL, but admitted there are a few > drawbacks here as well... An IDE does not need the OpenGL capabilities. > maybe C#, the big downside here being portability, the main upsides here > being easy access to C land (via C++/CLR, ...) and ability to use Windows > Forms... C# with Mono for *nix and GTK# instead of WinForms could work fine. And you do not even need to use mixed mode C++ to access C code - p/invoke will do fine for that. > I might consider Java, but I am not certain that the language design is that > optimal for this sort of tool (and integration between C and Java code is > typically not, exactly, pleasant...). not that it is difficult to integrate > them, mostly it is just unpleasant. Java should do fine for IDE. There are lot sof IDE's written in Java. JNI is a bit cumbersome, but I don't think an IDE need JNI at all. Arne
From: galen_boyer on 4 May 2010 21:00
Jim Janney <jjanney(a)shell.xmission.com> writes: > This is where the bit about "for reasonably dynamic languages" comes > into play. A Lisp program can easily modify itself at runtime, using > the mechanisms of the language in a very natural way; this makes it an > obvious choice for writing a Lisp IDE. Lisp sort of does, but doesn't, so your point doesn't really hold. I don't think there is an editor written in lisp (is there?). Stallman had to create Elisp (Emacs Lisp) which supports GUI features to allow an editor to take advantage of a lisp virtual machine's power, which is what Emacs does. Allowing you to modify its behaviour by interacting with the Elisp VM. Truly, your main point just isn't really valid. I certainly wouldn't want to try and write an IDE for shell code using a shell language. > I'm not sure, now that I think about it, whether Java fits into this > category or not. You can load new classes at runtime; you can even > assemble byte code in memory and then load it as a class, but it's not > what I'd consider a natural part of the language. And languages like > C and Fortran don't even have a foot in the door. Java's big boon is the idea of a virtual machine combined with reflection. I believe that reflection came about for the exact reason of adoption of the language. The IDE's available allow a huge level of adoption for java, and I'm pretty sure this wasn't just a coincidence. The reflection calls allowed tons of IDEs to come to life. I would bet java wouldn't have close to the level of adoption without the IDEs being available. -- Galen Boyer --- news://freenews.netfront.net/ - complaints: news(a)netfront.net --- |