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: BGB / cr88192 on 4 May 2010 00:01 "Martin Gregorie" <martin(a)address-in-sig.invalid> wrote in message news:hrmubf$r83$1(a)localhost.localdomain... > On Mon, 03 May 2010 07:50:28 -0700, cr88192 wrote: > >>>> this would seem to be all of them, and I suspect CR is falling into >>>> oblivion (since OSX switched to LF...). >>>> >> I think you misread what I wrote... >> > Yup. > > Since I've never seen "OSX" used to refer to OS9 and its ancestors I took > the above to mean that early OS X versions used CR before changing to LF > in midstream. > nope, I see OSX as part of the same continuity (MacOS), and thus coming after OS9. given OS9 used CR and OSX used LF, by this reasoning OSX switched to LF. it would be the same as if, by some chance, MS abandoned PE/COFF for, say, "Windows 8" (say, in favor of... ELF), one would say "Windows 8" switched to ELF. (admitted this is an unlikely example...).
From: BGB / cr88192 on 4 May 2010 00:57 "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: >> 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. >> >> 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). > > 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. for example, for a Java IDE, one doesn't actually need access to the Java runtime or reflection mechanisms, but could instead only have access to the classes and class-libraries (as data), or even only info about the classes and libraries, and still get by fairly well. > 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... 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). 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... 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... 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. admitted, the integration issue is not likely to be as bad for a pure-Java project, so this remains an open possibility as well...
From: Arved Sandstrom on 4 May 2010 05:17 Arne Vajh�j wrote: > On 03-05-2010 07:08, Arved Sandstrom wrote: [ SNIP ] >> 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 If (taken from Wikipedia) thought/thinking is "an intellectual exertion aimed at finding an answer to a question or the solution of a practical problem", which is a good definition for our purposes, then how could something which is designed to help us create and organize and present information _not_ contribute to better thought/thinking? AHS
From: Jim Janney on 4 May 2010 10:56 "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: >>> 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. >>> >>> 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). >> >> 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. > > for example, for a Java IDE, one doesn't actually need access to the Java > runtime or reflection mechanisms, but could instead only have access to the > classes and class-libraries (as data), or even only info about the classes > and libraries, and still get by fairly well. 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. 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. -- Jim Janney
From: cr88192 on 4 May 2010 15:42
"Jim Janney" <jjanney(a)shell.xmission.com> wrote in message news:2phbmnaf6p.fsf(a)shell.xmission.com... > "BGB / cr88192" <cr88192(a)hotmail.com> writes: > <snip> >> >> 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. >> >> for example, for a Java IDE, one doesn't actually need access to the Java >> runtime or reflection mechanisms, but could instead only have access to >> the >> classes and class-libraries (as data), or even only info about the >> classes >> and libraries, and still get by fairly well. > > 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. 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. > yeah. this would more matter for a debugger though I think, whereas for an IDE (in general) one can work based on the static/lexical visibility of types and declarations. any self-modification then can be assumed to be a non-issue (as in, outside the effective scope of an IDE, but within the scope of a debugger...). now for something like Lisp (or Scheme, JavaScript, ...) this would be a much bigger issue, since the exact visibility and types can't be reliably statically determined (type-inference is possible, but is of less utility given that the code is not required to have statically-known types). now, as for self-modification and self-extension: it IS possible in C (I have done this). however, if one were to ask if it were clean or simple, I would have to fairly solidly answer: NO. technically, it can't actually be done within the confines of the C standard, but actually requires side-stepping the language and compiler, and going fairly solidly into the lands of the low-level instruction set, ASM, ABI's, and code-generation / compiler writing, ... the key to making it all workable though is function pointers: without function pointers, very possibly it would not actually be possible. in Java, classes and interfaces can serve a similar role (as noted, in combination with the class-loader). with other hackery, one can add dynamic typing to both languages, although Java is much closer to providing native dynamic typing, but poses the problem that it would likely be a lot more difficult to do so as efficiently (the JVM isn't really designed to allow the needed facilities). however, some people at Sun have been working to address some of these issues in the JVM. at least going by the ECMA standard, the .NET CLR would likely have some similar issues WRT efficient dynamic typing, although these could be addressed by either: using unsafe code to implement the type facilities; possibly implementation-specific extensions. C has it a little easier as the language is "unsafe" by default, and so the main issue is more just doing everything in a way which is agreeable with the underlying system... or such... |