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 5 May 2010 20:38 On 05-05-2010 17:53, Jim Janney wrote: > "BGB / cr88192"<cr88192(a)hotmail.com> writes: >> sadly though, C / C++ and Java are like water and oil... > > JNI isn't exactly pretty, is it? It is not easy. Some consider that an advantage, because it is part of why it is not used much! Arne
From: Arne Vajhøj on 5 May 2010 20:57 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. >>> 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. ? >>> 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. And with a little careful packaging then a GTK# app should also run with MS .NET CLR. >>> 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. Arne
From: Arne Vajhøj on 5 May 2010 20:58 On 05-05-2010 02:58, 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. Nope. I am too young. Arne
From: Arne Vajhøj on 5 May 2010 20:59 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. Arne
From: Arne Vajhøj on 5 May 2010 21:43
On 04-05-2010 22:33, BGB / cr88192 wrote: > "Arne Vajh�j"<arne(a)vajhoej.dk> wrote in message > news:4bdf807c$0$285$14726298(a)news.sunsite.dk... >> On 03-05-2010 08:46, Tom Anderson wrote: >>> On Mon, 3 May 2010, Arved Sandstrom 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. >>> >>> I find what i assume to be Arne's point shocking. The ideal software >>> process would spend *100%* of its time writing code, because it would >>> 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. >> >> You think it is shocking that software engineers should spend more time >> thinking about the problems instead of typing full speed in their IDE? >> >> I think the definition of engineering is to think more than type. > > I think I think more than type, but practically this is a massive > time-waster relative to actually getting code written... > > it is like spending time speculating about the future: > this is wasting time, since the future is has not happened yet. The difference between good code and bad code can be rather significant in cost. It may cost more to produce good code, but over the life cycle of a typical application bad code will turn out to be a lot more expensive. Arne |