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: Arne Vajhøj on 6 May 2010 21:48 On 06-05-2010 02:11, Mike Schilling wrote: > Arne Vajh�j wrote: >> On 05-05-2010 05:34, 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. >> >> Yes. But no END IF. > > no THEN or ELSE either, just the single-line > > IF (logical-expr) statement > > F77 added > > IF (logical-expr) THEN > ... > ELSE IF (logical-expr) THEN > ... > ELSE > ... > END IF END IF should be read as "block if". :-) Arne
From: BGB / cr88192 on 7 May 2010 01:40 "Arne Vajh�j" <arne(a)vajhoej.dk> wrote in message news:4be213f5$0$274$14726298(a)news.sunsite.dk... > On 04-05-2010 22:04, BGB / cr88192 wrote: >> "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message >> news:4be0b58f$0$275$14726298(a)news.sunsite.dk... >>> On 04-05-2010 00:57, BGB / cr88192 wrote: >>>> 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. >> >> well, in my case, a lot has to do with familiarity... >> >> C# raises the issue of differences between MS's implementation and Mono, >> and >> the lack of good alternatives... >> >> Java leaves one in a world of primarily Java-only... > > Why. > > Probably 99.9% of Java code does work with Java code. IDE's > written in Java are very widely used in the PHP, Python, Ruby world. > fair enough, but committing to loss of pointers, and ones' pre-existing code, is a bit of a leap... granted, there is no universal reason here, mostly personal ones... a mixed codebase is easier to deal-with. >>>> 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. >>> >> >> true, but in my case, OpenGL is the most convinient way (in C and C++) to >> pull off portable GUI code (the main other alternative being to maintain >> local bitmaps and draw into these...). > > What is wrong with GTK, Qt, wxWidgets etc. ? > GTK: GPL, doesn't work well on Windows, doesn't build with MSVC, ... Qt: well, previously it was proprietary and non-free on Windows, but I think things have changed, but I have not looked into it. IIRC, Qt also requires C++, and doesn't allow one to write their GUI code in plain C. wxWidgets: no personal experience with this. typically, I prefer to avoid any options which depend on uncontrolled 3rd-party libraries, instead preferring to stick to options known to exist on a given arch. this would mean, for example, GTK is safe to use on Linux, and DirectX is safe to use on Windows, for example, but trying to use GTK on Windows or DX on Linux is asking for problems... the issue though is that glossing over GUI toolkits is a little ugly, hence my laziness and tendency to roll my own rather than deal with the native widgets issue (where in my case, my widgets are typically mostly inspired by the "Windows Classic" style...). >>>> 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. >>> >> >> but, the issue with GTK# is that AFAIK it is not available for MS's .NET >> implementation... >> >> providing redundant GUI between WinForms and GTK#, or demanding use of >> Mono >> on Windows, would also be lame... >> >> possibly it would leave one needing to find some way to gloss over the >> differences. > > Mono works fine on Windows. > > A Mono installation is rather non-intrusive. It would not > break anything installing it as part of an install. > this is a bit to drag along though... > And with a little careful packaging then a GTK# app should > also run with MS .NET CLR. > well, dunno, I would have to look into if anyone has pulled this off well... at least at this time though, AFAIK, Windows Forms also works on Mono... >>>> 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. >> >> but, this is only if one is willing to write the whole thing in Java, >> which >> granted, seems like a little bit of a strain for someone far more used to >> (the relative anarchy of) C and C++... > > If there are nothing you really need C for, then learning Java > may be a better option than to create a monster mix of Java and C. > well, it is a matter of familiarity: one has to "take a dive off the deep end" to willingly abandon their existing codebase, and for this there needs to be good reason. a mixed codebase minimizes code loss, but admitted does add its share of issues... granted, this is a subjective answer... I guess the problem in my case is that my personal Java experience is FAR less than my C and C++ experience, and I am not sure if I can get done anywhere near the same level of stuff... but, JNI is also hideous (I have had this experience some amount already, writing inter-language boilerplate generally being an less-than-preferable experience...). admittedly, I may know of a few hacks I could use... public class GlueNative { public native Object apply(String name, Object[] args); //apply arbitrary C function to args public native Object apply(Object ref, Object[] args); //apply function-object to args public native Object getVar(String name); //get reference to object public native Object eval(String expr); //eval expr and provide result .... } where I would likely just reuse some of my stuff for gluing ECMAScript to C (patch Java into a custom ECMAScript implementation, which is in turn capable of accessing most of C land, via more internal hackery...). then with a slight bit of fudging, the API can be improved (mostly adding lots of type-specific calls, ...). or such...
From: BGB / cr88192 on 7 May 2010 10:10 "Jim Janney" <jjanney(a)shell.xmission.com> wrote in message news:2pr5lq8183.fsf(a)shell.xmission.com... > "BGB / cr88192" <cr88192(a)hotmail.com> writes: > <snip> >> >> 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. > fair enough... I haven't used SWIG much personally... in my case though, it is possible I could write an alternative to javah, which could maybe generate a more elaborate wrapper (like, actually generate much of the C-side code as well). JNI's Java-side interface, with a fairly direct C-side interface, would be much better than the present situation, where JNI allows a fairly powerful interface, but is akin to mucking around in pure evil, and JNA moves most of the mess to the Java side. however, I am left to think some that part of the problem is how Java and the JVM are designed, where the design itself impedes having a particularly transparent interface (essentially, between Java and pretty much anything not Java / built-on Java...). hacking around the core issues would essentially put one at odds with the pre-existing architecture (in one way or another). but, granted, it may well be possible to tool-up or hack around these issues in any number of ways, but I have yet to see or hear any particularly good way to do so (or, at least within the context of an "orthodox" JVM architecture, for example, some of the stuff done in GCJ or similar being excluded here...). also goes for the possibility of compiling the language for a different VM architecture, VM-specific hacks (I can imagine a few if this is allowed), .... many other languages have different binding semantics, and so don't present this particular issue... for example, it is far easier to transparently glue ECMAScript onto an underlying C-based implementation. for example, I created a magic object which "contains" the entire C toplevel, and so I can just fetch, say, "printf", "strdup", ... from this object, and call them as if they were ECMAScript functions. the implementation then uses a whole lot of internal hackery to glue together the typesystems. but, in all it has worked fairly well (much better than expected considering the level of mismatch and internal hackery used, where often it just "guesses" how to best marshall some data...). admitted, the thing currently still has a few unresolved issues: it can't currently deal with C-side structures or complex pointer-based types (the logic is not yet in place for this), ... sadly, this issue has swayed some of my effort from using Java, to using ECMAScript (even though Java is a bit more solid language for building code). admittedly, if I could get my own Java implementation into working order, I could also try gluing Java and ECMAScript (probably via interfaces), but this will not work with a stock JVM, and my own implementation is far from being usably complete... admittedly, there IS the considered option of using JNI and giving an API into this custom ECMAScript VM, and using this to access C land, but admittedly this is an ugly and inefficient way to do this... admittedly, the .NET CLR can interface with a lot of my stuff with relatively little issue (I have tested, the mechanics would seem to all be in working order...). just, I have a few of my own reservations regarding the .NET CLR... but, oh well...
From: Mike Schilling on 7 May 2010 20:29 Arne Vajh�j wrote: > On 06-05-2010 02:11, Mike Schilling wrote: >> Arne Vajh�j wrote: >>> On 05-05-2010 05:34, 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. >>> >>> Yes. But no END IF. >> >> no THEN or ELSE either, just the single-line >> >> IF (logical-expr) statement >> >> F77 added >> >> IF (logical-expr) THEN >> ... >> ELSE IF (logical-expr) THEN >> ... >> ELSE >> ... >> END IF > > END IF should be read as "block if". > > :-) Oh, I knew what you meant, but posting about this stuff is addictive :-)
From: Thufir on 9 May 2010 19:17
On Sun, 02 May 2010 18:59:41 -0700, BGB / cr88192 wrote: >>> That's entirely possible, that some people will have barely any grasp >>> of how to work outside the IDE. If we discount developers leaving the >>> IDE fro time to time to use a word processor or web browser, and also >>> include the ability of the IDE to call up server consoles and what >>> not, then these days with the latest IDEs a person can likely get away >>> with using the IDE for everything and not suffer. >> >> Oh - the developer may not suffer, but all the people that has to do >> the final packaging, QA support and production support that the >> developer can not help with because the does not understand how the >> output of his development is used will suffer. >> >> > (irony / joke...): > simple: just send the IDE with the product and tell the end users the > magic ritual to invoke the program from the IDE... > Err, the IDE should deliver a JAR/etc. I don't see how that's a problem. -Thufir |