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: Jim Janney on 5 May 2010 11:16 Tom Anderson <twic(a)urchin.earth.li> writes: > 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. Um, OK. >> 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*? That's more like a finger in the door... -- Jim Janney
From: Mike Schilling on 5 May 2010 11:20 Arved Sandstrom wrote: > Mike Schilling wrote: >> Arne Vajh�j wrote: >>> 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. >> >> Fortran 4, you mean. Non-arithmetic IF statements are for sissies, >> and God intended character processing to be done by stuffing bytes >> into parallel arrays of INTEGERs. > > All humour aside, the significant FORTRAN for many of us must have > been either FORTRAN 66 or FORTRAN 77. My start to programming was > actually FORTRAN 66...now that I look carefully at what FORTRAN 77 > added, it appears that I was also able to get away with not having a > CHARACTER data type. > > As near as I can tell FORTRAN IV did have a logical IF. Full FORTRAN IV did, but there was a subset of it called "Standard Basic FORTRAN", which is I used both in college and at my first job (IBM 1130 and 1800 respectively), that did not. The 1130/1800 dialect also had a strict ordering of declaration statements: Type (INTEGER, REAL) EXTERNAL DIMENSION COMMON EQUIVALENCE DATA which I still remember with the aid of of the menmonic "places getting further away from California" (TEXas, Washington DC, EcuaDor.)
From: BGB / cr88192 on 5 May 2010 16:18 "Jim Janney" <jjanney(a)shell.xmission.com> wrote in message news:2pvdb28jlw.fsf(a)shell.xmission.com... > Tom Anderson <twic(a)urchin.earth.li> writes: > >> 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. > > Um, OK. > >>> 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*? > > That's more like a finger in the door... > be careful not to underestimate the sheer hackery power made available by these seemingly trivial pointers... plain pointers allow the likes of custom memory management, garbage collection, and the implementation of dynamic typing. function pointers make possible the creation of self-modifying programs (among other things), as well as custom code-loading, JIT compilers, and adding "eval" and other features to C, ... this is part of what makes C hard to learn, but also what makes it difficult for C and C++ programmers to commit to using only Java... sadly though, C / C++ and Java are like water and oil...
From: Jim Janney on 5 May 2010 17:53 "BGB / cr88192" <cr88192(a)hotmail.com> writes: > "Jim Janney" <jjanney(a)shell.xmission.com> wrote in message > news:2pvdb28jlw.fsf(a)shell.xmission.com... >> Tom Anderson <twic(a)urchin.earth.li> writes: >> >>> 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. >> >> Um, OK. >> >>>> 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*? >> >> That's more like a finger in the door... >> > > be careful not to underestimate the sheer hackery power made available by > these seemingly trivial pointers... > > plain pointers allow the likes of custom memory management, garbage > collection, and the implementation of dynamic typing. > > function pointers make possible the creation of self-modifying programs > (among other things), as well as custom code-loading, JIT compilers, and > adding "eval" and other features to C, ... > > > this is part of what makes C hard to learn, but also what makes it difficult > for C and C++ programmers to commit to using only Java... > > sadly though, C / C++ and Java are like water and oil... JNI isn't exactly pretty, is it? The last time I needed to do that I ended up using SWIG, which handles it pretty well. -- Jim Janney
From: Tom Anderson on 5 May 2010 19:42
On Wed, 5 May 2010, Stefan Ram wrote: > Tom Anderson <twic(a)urchin.earth.li> writes: >> 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 > > But then, we also think by deleting, which might result in a > negative LOC number, while still indicating an advancement > toward project goals. Yes! You are absolutely right! Deletion is the developer's most powerful tool. I always think of Michelangelo's possibly apocryphal approach to sculpting his famous statue of David: just chip away all the parts of the block of stone that aren't part of the statue. > See also: > > http://www.developerdotstar.com/mag/articles/reeves_design_main.html Aha. I came across this idea of programming being a design rather than a manufacturing activity, and thus of source code being a design rather than a product, a while ago, but forgot who originated it - thanks for reminding me. He's spot on. tom -- Once you notice that something doesn't seem to have all the necessary parts to enable its functions, it is going to mildly bug you until you figure it out. -- John Rowland |