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 22:04 "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: >> "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. > > :-) > yeah. some newer Fortran varieties add OO, function pointers, and a lot of the stuff from C and C++... >> 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... >> 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...). but, I like OpenGL because it can do nearly anything I need (from simple GUI's and consoles to more elaborate 3D scenes), without having to really modify or port much code (usually just a few kloc is needed to manage OS-specific matters). also, my main widget toolkit is based on OpenGL. interfacing with platform GUI facilities tends to be much more painful to make work well (since damn near every OS has its own local GUI API, and often it is not particularly a 1:1 mapping between them). however, in the past I had done some basic GUI's using some design ideas from HTML forms as a means of abstraction. granted, portable GUI is much easier in Java, since Java includes AWT and Swing, which work regardless of the target OS. >> 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. > And you do not even need to use mixed mode C++ to access > C code - p/invoke will do fine for that. > granted. however, there is some merrit in being able to write mixed-mode code, since it can serve as an essentially bidirectional interface with both languages, and thus avoid much of the "harsh edge" effect from using P/Invoke. granted, I have not used it much in any large scale, but I would imagine it to be a nicer experience... and as well before I essentially used it to more-or-less coerce a bunch of plain C code to run on .NET... >> 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++... similar, there is also the uncertainty of one having to quite possibly abandon much of their legacy codebase, essentially "starting over" as far as programming goes...
From: Mike Schilling on 5 May 2010 02:58 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.
From: Arved Sandstrom on 5 May 2010 05:34 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. AHS
From: Lars Enderin on 5 May 2010 05:55 On 2010-05-05 11: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. It had. It was one of its improvements over FORTRAN II. There was no FORTRAN III, at least not widely available. I started real programming with Algol 60 in 1962, just one project, then began programming in FORTRAN II in 1963. FORTRAN IV was a great improvement, but it was the last FORTRAN I used.
From: Jim Janney on 5 May 2010 11:12
galen_boyer(a)yahoo.com writes: > 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. There are lots and lots and lots of editors written in Lisp. It's a very common pattern, and most serious Lisp implementations, for example LispWorks, include a complete programming environment written in Lisp. Stallman wrote GNU Emacs not for technical reasons but for legal ones: he wanted something he could place under the GPL. And the larger part of GNU Emacs is written in Emacs Lisp. > 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 claiming that every language should have an IDE written in that language. I'm speculating that there exists a class of languages for which this holds, and trying to identify the properties of that class. >> 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. > I agree with all of this. -- Jim Janney |