Slashdot Mirror
Linux IDE from Cygnus
An anonymous reader wrote in to tell us that
Cygnus is planning to ship an IDE for Linux this summer.
It's called Code Fusion and it'll have a lot of competition
with CodeWarrior and more already out there. But it will
support C/C++ and Java.
An IDE for Linux ? ..
I thought the whole of {Uni,Linu}x was an IDE
I think it's pretty obvious that Cygnus is going after the market of Windows programmers, not your typical Un*x types. I don't really know much about their IDE, but I'm guessing it's able to work with the same project formats used by Codewarrior or Visual C++, making migrating from one platform to another less painful. Of course, it had better output Makefiles also :)
Anyhow, I wish them the best of luck -- having done such a good job with egcs, maybe they'll be able to leverage their name well enough to make some real money from their IDE.
you don't need two xterms for development. Any emacs user will tell you (not me, I not one of THEM) how convenient it is to not have to switch windows to compile (or read news, rowser the internet, read mail, etc). It you use any decent vi clone (vim for example), you get a slightly larger program that does, in the case of Vim: Syntax Highlight (ooh, the colors!), GUI support, unlimited undo/redo, etc, plus, stuff to ease Edit-complie-debug cycle. In vim, you can type :make and it will run the make command, catch the output from the compilers, and properly bring you to the lines of the errors, including accounting for changes in line numbers when you make a change in the code.
Now _that_ sounds fun!
It might just be a typo, but it sounds funny.
Even funnier: Rowser the weasels!
Anyone w/ a brain that was nothing better to do than learn the "editor" which should be called a "shell environment."
Visual C++ user alter.
Here, here. Emacs' intergration with make and gdb (M-x compile and M-x gdbsrc respectivly) are incredibly powerful, and the ability to easily extend Emacs from Elisp is just a joy to use (I'm currently implementing a minor mode to emulate the text editor "wily" which has a very interesting mouse-based direct manipulation interface.) Emacs is the ultimate editor :-)
A few emacs hacks of mine
Why? They're different names?
-- Rastro :P
I agree that it's a pain to learn several different text editors. That's why I like CodeWarrior: the key bindings are the same as BBEdit.
Currently the line printed above will work for 99% of all Linux software. I really, really hope that Cygnus integrated the auto* tools into the system, and especially that the other IDEs that are popping up have some way to output at least standard (GNU) makefiles. Even that, though...whenever I untar a package that doesn't use autoconf I think, "oh, great. Here we go again..." :-)
Maybe I should go write a "GAutoCode" tool (or some such silly name..) that provides a graphical environment for editing Makefile.am and configure.ins..
But seriously..there are already too many broken build systems out there (SDL...Clone...Crystal Space...) I'm afraid that use of nonstandard IDEs will just promote this behavior.
Daniel
I thought that Emacs would support Ada. Doesn't it?
:-) ]
[ but then it doesn't support lex or yacc either so... -- vim has a lot more highlighting information than Emacs if that's what you need. Dunno about Ada
Daniel
i agree, i just started a winnt project using msdev. My first order of biz was to download
cygnus cygwin and vim for nt.
I then bought a book called "MFC Programming from the Ground Up" which goes though mfc basics with out any ide.
Its quite empowering developing mfc code using vi/bash and NOT using the "class lizard" to break/hack/comment up my code..and cripple my mind...and i know in the end ill have an intimate knowledge of mfc... for what its worth..that is...... because hopefully someday soon gtk/qt will be the primary gui toolkit for nt/unix/mac!!
-greg
I'd rather rowser the wrenches.
Perhaps I shouldn't have said that. Oh well.
Yes, emacs is a pain to learn. But you only have to go through the pain once. I started using it 15 years ago on a VAX, and have since used it on the Atari ST, DOS, SunSparc, OS/2, and of course, Linux. The same is true for the other Unix/GNU tools like make and gdb.
With IDE's, it's a new set of problems with every release. Borland's aren't too bad, but the one time I looked at an MS IDE, VisualJ++, I thought someone was playing a bad joke on me.
In my experience, bigger projects make IDE's even less useful. You'll want to split a large project into several libraries in different directories, and have a top-level "makefile" to build them all when you just type "make". At least, that's how you do things in Unix. You'll also use RCS or CVS (or ClearTools if you've got lots of money and people) to help keep track of the code and allow for more than one people to work on it.
How well can, say, VisualC++ do the above? (I'm really asking, as I haven't used it.)
Great I love ide's and we can really use them for linux. This will finally show those windoze weinees that linux isn't the same unix they took in college 15 years ago where everyone used grep in emacs to write reports and basical bussiness stuff.
h tml?chkpt=ad1qsfphttp://www.zdnet.com/an chordesk/story/story_3477.html?chkpt=ad1qsfp .
Anyway I found something that is a little off topic but have to show you guys from Jesse Berst. This is the bigest fud I have ever found at zdnet and its not even fud. Its quite hysterical and a great laugh. http://www.zdnet.com/anchordesk/story/story_3477.
If you read the talkback section you will notice that ever single comment that syas praise about microsoft uses ms buzzwords like positive and active and they are all written by the same author if you read the writing style.
Well I am done laughing and I think I am going to vommit after reading this. This man will do anythin for money. All I can say is sick sick sick sick.
Jesse Berst sure has alot of balls to write somehting like that. I know alot of /.ers are quite skeptical of jesse Berst but I was just fine with zdnet. After this I now know the truth.
I am going to email this to all my friends who use linux. This was a good laugh.
>GUI design: Look, creating dialogs is not going
>to be an intellectually stimulating programming
>task. So do it with a visual editor in 5 minutes,
>rather than tweaking around manually for hours.
>Then automatically generate the message handlers
>for the dialog and get started with real
>programming.
I do lots of Java work, and JBuilder, VCafe, VAB all generate poor code when you drag & drop components. Usually you get a great big pile of components in one method/module, unmaintainable and unfactorable.
Esp. with Java, I'm using an editor because:
1) I can create and use compound classes the IDE has no idea how to display;
2) I can factor and reuse my GUI design;
3) I'm using the LayoutManager classes that don't use absolute pixel addressing, and so nudging things isn't required.
Is this state of affairs also true in C/C++ IDEs? Never used them for that. I have used the Micros~1 VB environment which also creates the pile of components code, so I think that I'm justified in my criticisms.
That criticism and $1.00 buys a poor cup of coffee...
Ive been using IDE's sense i started programming using Turbo Pascal. Hence programming with an IDE just seems natural to me. Now ive moved on to c/c++ and Linux, and it sounds like IDEs arent so popular. I was wondering if anybody could reccommend a web site on programming using Linux as IDE.
*Writing* a decent UI is certainly hard.
But as for using one to code? Get real! I'd rather give up computing...
You are running gdb as a sub-process in emacs under comint? It will use your emacs buffers for source display. That will handle all your listed functionality.
The only thing emacs doesn't do out of the box is serious sytax analysis (e.g. inheritance tree, syntax sensitive completion, argument lists, etc.) You need to hook it into outside tools to get that stuff. And they suck too.
Anyone using Code Crusader/Code Medic?????
http://www.cco.caltech.edu/~jafl/jcc/
http://www.its.caltech.edu/~glenn/medic/
The problem wit that reasoning is that current c/c++ ide's are done in the 'windows' integration mold, but this is not the case, Visual C, Watcom (rip), and rhide for example are all wrappers around command line tools. Visual C is the least usable ide from the command line, but it still has nmake.
..
Most likely is that the ide will be in this mode, what it provides is a way to automate the
into:
- Factory
Yeah, maggots like that idiot John Carmack and those silly little Quake 3D games he keeps coming up with. Why don't you read some time about why he doesn't code on Linux himself? A large part of it is that he is interested in coding, not in hand-holding a set of command-line tools.
You may be quite happy with a pure command-line environment. But that doesn't make you some authority on what is most productive for every programmer.
Cygnus sells GNUpro, but it's still free software. The fact that they're selling it doesn't mean that it's proprietary.
Someone asked about a GUI IDE on a FreeBSD mailing list once, some answered w/ Code Crusader, which is a free IDE.
http://www.its.caltech.edu/~jafl/jcc/
take a gander.
I've never used it, because i've not much of a developer, but I thought I'd point it out so that people see it.
Is there some specific reason why CodeWarrior is redhat only? Does the program actually check to make sure it's on redhat, or does it make assumptions about file locations?
What would stop me from using it on my Debian installation?
I would suggest people to look at KDevelop - http://www.cs.uni-potsdam.de/~smeier/kdevelop/ - although it's for C++ and you'll need QT libraries..
Hetz (Heunique)
KDevelop 0.4 just came out the other day as well, obviously concentrating on Qt/KDE development. It looks very nice, though. I just haven't had anything to make yet. Somehow, I figure I'll just revert to vi anyway...
Since I code C++ on Linux all day long at work, naturally I have a strong interest in good development tools. When I first got started doing Linux programming professionally, I looked at all the tools availible.
When it comes to IDEs, there's only one good reason, in my mind, to use them: the integrated debugger. Being able to set breakpoints with a single keystroke, run the software, and then when you find the bug modifiy the code right in the same window is wonderful. Compare this to gdb (and this includes DDD, wonderful as it is), where you have to have your source editor up in a seperate window, and changes you make aren't instantaneous. It's also hard to preserve breakpoints across sessions.
So far, I've tried every IDE that's come out for Linux. That includes Code Warrior, Code Forge, Visual Slickedit, Xemacs, and some others. None have an integrated debugger! What's the point? Project management is the only other major feature these provide, and to someone handy with makefiles that's not really all that desirable.
So, I continue to use vim+gmake+egcs+gdb for all my work. This is fine, although the debugging does still leave something to be desired. I think an ideal solution would be either to build a very simple debugger front-end into vim (which should probably be a seperate project, to avoid emacs-like bloat in the editor core) which would allow you to set breakpoints and let it run.
Alternatively, DDD is *very* nice, and with a few interface tweaks (such as customatizable hotkeys for menu commmands - too bad it's not written with GTK) and the abililty to modify text on-the-fly, it could be everything I've ever wanted.
The big question here is whether or not this will be free software. The article didn't make it clear and I couldn't find out on Cygnus' web site. Does anyone know the details on licensing?
Because Ada is evil and bad.
I just consider any language that requires you to type "1.0" instead of "1" when assigning to a float terminally brain-damaged. Strong typing is a good thing (Perl's bitten me a couple of times because of its almost complete lack of typing), but typing _that_ strong is ridiculous.
Posted by the order of His Majesty:
Is there no one programming Pascal any longer?
If there were more people using more programming languages we might not have so many occurances of things like buffer overruns and other misc security breaches... IMHO
Honest questions here.
With emacs/XEmacs, can you:
Set breakpoints in the source editor?
When in a "break", can you query various variables, including members of structures? Get a list of the local variables? Cast pointers to other types and query them?
Mouse-select text for copying and pasting?
Grab the latest versions of files from source control programs?
Also:
Can you add conditions to a break, so it doesn't always trigger?
Can you syntax color matching parentheses/brackets?
(Note: I consider the answer yes if it could reasonably be programmed with elisp to do so.)
The first set are things I can do with IDEs like Visual C++, the second are things I can't get them to do. I find the former really useful, and wish I could do the latter.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
>GUI design: Look, creating dialogs is not going to be an intellectually stimulating programming task.
Ironically, GUI design really shouldn't be done visually at all.
Seriously. A good interface should allow for language differences and user preferences, each of which can screw up your carefully laid out dialogs. The ideal thing is to have the computer lay them out as needed for the user/interface settings, putting the proper spacing, border spacing, etc.
Ooh, a sarcasm detector. Oh, that's a real useful invention.
Hmm, funny you should mention Borland Turbo C. Although usually I just use an editor and the command line, my favorite IDE so far is RHIDE, which is built on Turbo Vision, so of course it looks just like Borland's old IDEs for DOS.
Also, you can have multiple windows, compile your code, debug, have lots of hilighting (in the console), jump to the lines that have compilation errors, etc. And it's all integrated, you have your watches, and your breakpoints, and all that fun stuff.
I guess I just liked Turbo Vision, it was always pretty intuitive for me, which I can't say about emacs. Too many bucky-bits spoil the broth, I guess.
pb Reply or e-mail; don't vaguely moderate.
Unix is certainly a DE, and a good one at that, but I'm not sure it qualifies for the I. Emacs does, though.
-GUI design: Look, creating dialogs is not going to be an intellectually stimulating
:-)
programming task. So do it with a visual editor in 5 minutes, rather than tweaking
around manually for hours. Then automatically generate the message handlers for
the dialog and get started with real programming.
Unfortunately, I generally include at least some element of programmatically generated stuff in my GUIs, and the stuff that I do this way generally is also the stuff that a visual editor would be useful for. For example, a preferences dialog in which items are registered by scripts that get run on startup. (think Emacs' Customize menu and you get the idea..) This doesn't map well into 'visual' design, unless you can show me a visual program that can predict every funky combination of widgets the user will come up with.
Besides..programming GUIs by hand was a nightmare in Windows but with a sane toolkit (GTK+ and Qt come to mind) I can make a good-looking dialog in a few minutes. That said, I wouldn't be averse to using something like Glade, it's just not worth the trouble. But even without a 'visual' editor, the 'GUI building' is so insignificant a proportion of the time spent on the program that it doesn't matter which I do. (it's not that I don't put thought into my GUIs, it's just that almost everything happens either in the backend or 'behind the scenes' in the GUI -- that is, in stuff that doesn't have anything to do with what widget goes where. Widget placement is the most visible part of an interface but the most trivial thing to do programmatically)
Daniel
Hurry up and jump on the individualist bandwagon!
I've noticed that generally UNIX users mean something very different from Windows users when they say "integration". Take mail as an example.
:-) It would seem at first glance that the second system is more complex. This is not true, or at least not in the way you implied -- that it requires lots of 'getting your hands dirty'. There is more obvious complexity in the second system, but it is carefully contained. Each program is internally complex, but communicates with the others through (relatively) simple and well-defined interfaces. The first program looks simpler because there's only one obvious thing to consider, but it is more difficult to design and less flexible (because one group probably wrote the whole bloody thing instead of multiple independent groups concentrating on discrete, small bits of code and because you can easily isolate each piece of the system..this works both conceptually -- I can understand how fetchmail works without caring about how the POP server or the local mail delivery agent work -- and from the point of view of actually doing things: any piece can be replaced with a better one or reconfigured in bizarre ways if necessary)
:-) But basically, my experience is that things people think are 'simpler' (like designing everything in one piece, or writing quick-and-dirty routines) generally turn out to be more complex (in the bad sense) in the long run. Witness the amount of time and effort spent designing defragmenters, disk checkers, virus scanners, memory protection libraries, etc for DOS [aka "Quick and Dirty Operating System"]. But as they say in these parts..YMMV.
Windows: You have one mail program. Well, probably one. Unless someone else wants to use a different program on the computer. But probably one. It does everything. It receives email, stores it on the system, and sends it via SMTP..and it works most of the time. If you've gotten a really good one, it might even deliver mail in the background and do odd things like Kerberos. If you ever want to switch to another mail client, kiss your messages goodbye unless you convert them to the new format and location; the same goes for any POP settings, mailing list filters, and so on.
This is an 'integrated' program; all functions are in one place.
UNIX: The mail system comes in pieces. There is a mail delivery program, which takes mail and sticks it somewhere, a mail getting program, which speaks POP and all its variants, a mail client which reads one of a few mailbox formats (mbox and mh), a mail editor, and a mail transfer program. [some clients pick up, eg, the editor, but they usually let you use a different one] other mail-processing utilities may be installed as well.
When you receive a message it is either sent directly to the delivery program via SMTP or gotten by fetchmail and then sent to the delivery program. The delivery program then either passes it to another mail-handler (procmail for example) or else delivers it directly to a mailbox. All (or most) mail clients read and write the mbox format, so any one can be used to access the messages. This means that changing mail clients does not require you to give up your history of correspondence, and since the mail client doesn't even handle POP and so on those naturally are also preserved. When you send mail, the mail client passes it to the mail-delivery software, which spools it for immediate or deferred delivery. The mail client need not be running while the mail is being delivered.
Each of these programs generally is highly specialized and most users will only touch from five to ten percent of the features (not, please note, the same 5-10%)
This is an integrated system: it has many pieces which work closely together to produce a finished result.
Ok. Back to complexity.
Hmm. I had a point here but I ate supper in the middle and lost my train of thought.
Daniel
Hurry up and jump on the individualist bandwagon!
What keeps it from being GPLed now? Not that I think it will be, but what about the fact they are charging money for it keeps it from being GPLed? Why continue the confusion between Gratis and Libre?
--
"First they ignore you.
Then they laugh at you.
Then they fight you.
All hail ERIS
Code Forge has Ada support. I use if all the time for Perl, PHP, and HTML.
http://www.codeforge.com/features.html
For *BSD you'd probably use the excellent *bsd
... I dunno.
linux emulation.
(I'm a linux user, but I was impressed)
Solaris
Sco... ibcs?
Why doesn't anyone make and IDE or code browser that supports ada!!!! Source Navigator from cygnus rules, but still doesn't support ada. Life is unfair.
/dev
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
I really want a ada code browser/IDE. Something that will let me click a symbol and see the definition, etc. Lots of editors support ada for syntax highlighting. (Although most don't run on VAX VMS ... so i'm still screwed. just gotta live with EDT and LSE I guess)
/dev
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
There is a reason that until now all DoD work was required to be done in ada. The strong typing and wanna be object orientation (in ada83 anyway, ada95 really is OO) make for some pretty stable software.
There is nothing inherantly (sp) better about ada, when compared to C for example, but the way it tends to work is that if your ada software makes it past that %$#@$#@* compiler it will more or less do what you wanted. usually. well sometimes anyway. Overindexing arrays and such is harher to do in ada. If you use a real ada run time it's really hard, but full blown run times are slow and eat eeprom like popcorn.
The catch is that it is easier to really tweak out your software in C. I'm fighting a problem right now at work where I could do something in C with extreme ease and effiency, but in ada it's very very hard to even come to the same elegant solution. Granted some of this is due to the DoD coding standards where I'm at being kinda strict. (read as kind of freaking brain dead is many ways!) But these do tend to lead to more reliable software, and lord knows when you creating a product that has destructive potential you want it to be reliable.
I'll shutup now. gotta go barf out some more ada code on my super duper VAXStation 4000-60. fun fun.
/dev
"There's no secret. You just press the accelerator to the floor and keep turning left." -- Bill Vukovich
Today's English Lesson: Oxymorons
Sanity.html - Error 404 not found
Hey, I would buy your IDE. So when does it come out? :-)
Honestly, VC6 is a pretty slick programming environment. I just wished that it wasn't that integrated, so you could exchange editor, debugger or compiler.
Sounds like Cold Fusion with bad sinus congestion... Is this a deliberate take on the Code Fusion name?
Not to start any flame wars (yes, multiple vi's in xterms works too), but emacs is my preferred IDE. I started off programming with the Borland TurboC IDE. It was OK, but when I got to college and had my first exposure to emacs, it was a marriage made in heaven. I can have multiple windows, compile my code, debug, have lots of hilighting (in X), jump to the lines that have compilation errors, etc. I've even gotten a lot of my coworkers using emacs (well, XEmacs), and they seem to like it a lot.
Yes, there ARE other ways to do it, but this works best for *me*. Everyone has a choice.
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
It seems to me that high quality IDE's seem to be geared to a very small subset of programming languages.
While this can be a good things, as to allow you to easily prototype a working program for testing using their visual components (VisualAge, JBuiler, VisualCafe, Visual Basic et cetera). I believe that it hinders one by having to use and install multiple IDE's in order to write in different languages.
From what I have been able to determine, even as a student, is that no language is perfectly suited for each and every task. PERL is excellent report extraction and analysis, and is extensively used in CGI, JAVA makes a nice powerful GUI, C/C++ are excellent for very large scale projects and low level programming (simply my views)...
This brings me to my point. Let us assume that one is pro efficient in PERL, Java, C/C++ and Python. Now VisualAge is a nice package for Java, so we install and learn that, then we install CodeWarrior for C and C++, and then one for PERL and another for Python.
Each and every single one of these have a different look and feel. Sure, it can be associated to it's object oriented nature, but VisualAge is considerably different from any other IDE that I have seen for handling classes and methods. This seems rather odd, that I have to learn how to use multiple interfaces, simply to gain quick prototyping and a nicer looking development environment.
I would find it very nice to have a complete development environment suite. Possibly in plug-in form that would allow us to programming multiple environments using the same IDE. Sure some of them would not allow for visual prototyping (even PERL could using the CGI mod), others may not have to be compiled simply executed and debugged, yet one interface to learn and to master is much better then two plus.
I know some will mention VI and Emacs... I have nothing against them, but I highly doubt that I can sit down, and write a JDBC enabled piece of software with everything linked visually. Either way those are my views.
I applaud Cygnus Solution's decision to release an IDE for Linux, and I hope it attracts new coders to the platform. However, I've always found IDE's an anti-climax on any platform. The amount of time I expended on learning the quirks of another editor, key bindings for compiling, etc. was never rewarded by increased productivity.
While an editor like vi or emacs, and a debugger like gdb may look daunting to new users, learning them is far more useful than learning an IDE. The IDE has one task - providing a frontend for development. A standard Unix editor (and this includes GUI ones like Nedit) is far more rewarding to learn, as it can be used for more general tasks than programming.
I've seen some IDE's that allow the user to specify which editor to use for code-editing. This really invalidates the IDE concept, as the while point of an IDE is to provide integrated tools, but they can't be relied on to support the features of vastly different editors.
Another gripe about IDE's is that they usually employ wrapper utilities for programs like make and gcc. This is fine until something breaks. Having done some of my programming on Windows NT 3.51, I can honestly say that those who learn programming in VC++ are stumped when the IDE 'breaks'. They are unable to grasp the fact the VC++ is just a frontend to a make utility, command line compiler and debugger. When VC++ failed to work on a project file, I simply edited the make file by hand and compiled from the command line. My co-workers didn't have the first idea about how to do this, having learnt to code on VC++ or Borland IDE's.
Chris Wareham
What are the odds of us seeing ports for FreeBSD, Solaris, and DEC UNIX/Tru64?
MIS
Simon
Maybe my projects just haven't been big enough to need an IDE. A couple of xterms (one for vi, the other for make) have always been enough for me. Being a starving student still, the $300 that the article mentions is just enough that it's hard to justify.
Obviously you haven't worked on any large programs... if you had, you can see why a graphical IDE is so much more valuable than using a text based editor... (for the record, I've been a developer for ten years and worked on a number of large projects... emacs does some great things, but it does hurt my eyes after about 12 hours of solid coding...)
However, I'm really looking forward to the development of gIDE which will allow easy building of GTK apps.
I don't see why anyone would really want a commercial ide for "at home" projects. There's too many good ones out there already, and quite honestly...not many people need all the extra features the commercial ide's have to offer. The commercial products might be much more useful for commercial multi-concurrent-developer projects and the like.
BZZZZZZZZZZZT!
Wrong!
Free(d) Software / Open Source != Freeware
hmmm....the article says $299 a "seat"...If I stand while I code, will they GPL it? :)
Juiced? Or Not?
When I started programming, it was with IDE's.
I couldn't imagine vanila text editors being
much fun. Then one day I decided I had to
use DOS instead of Windows for this Project.
My IDE was windows only.
So I found me a nice programmer's editor,
wrote and a makefile. And I found it no
less efficient. Now under linux I don't
even need a powerful editor.
I have been told that modern GUI's give
better milage than my old one (Borland 4.0).
But at the end of the day productivity
improments come from good code, good languages,
and most improtantly good APIs.
There are three valid uses for an ide:
-Class browser: See a tree with all the classes/members in your project and just hit one click to take you exactly to a method definition. Or view a graphical inheritance tree.
-Syntax completion: If you're just doing straight Unix C systems programming, no GUIs, and you have plenty of experience, sure you only need to look up the occasional command. But if you're programming against a massive GUI API (Windows, KDE, etc.) with a class library that you didn't write, syntax completion is key. Who the hell knows all three overloaded forms of some obscure command to manipulate a tree control? Who the hell really wants to? An IDE will pop up a parameter list for you instantly.
-GUI design: Look, creating dialogs is not going to be an intellectually stimulating programming task. So do it with a visual editor in 5 minutes, rather than tweaking around manually for hours. Then automatically generate the message handlers for the dialog and get started with real programming.
Good IDEs can make a serious productivity difference if they're used for the right tasks and if you KNOW HOW TO USE THEM. There is very much a mindset to each IDE, just as there is to Emacs, vi, etc. If you approach Visual C++ by thinking of it as just an even bigger, slower version of emacs with different keybindings, it will do you know good. But if you think in its visual terms, you'll get a lot more done.
I personally think that programmers should be comfortable with both text editor/make and visual/IDE programming. It sharpens your skills when you come at a problem from a different angle.
Done right, a UNIX IDE would consist of:
1. a replacable editor component, your choice of emacs, vi, etc. compatibility (or better yet, emacs or vi themselves seamlessly integrated)
2. a replacable DDD-ish debugger component with graphical and command-line capabilities
3. a project manager that maintains a human readable Makefile, possibily layered on automake
4. gcc
All of it tied together with CORBA component objects, like the GNOME or KDE COMs.
At least thats how I would do it.
An IDE is more than a build tool, it's a development tool. For example, in VC++ you can
easily visit all defintions/references of an identifier. You can approximate this functionality with grep, but it's not as convenient.
Personally, I don't use VC++ to manage builds of multiple projects; for that I use make. The idea is to use the most convenient tool for the job.
A UNIX DE is not a bad idea. I've been using emacs for years, but I don't use its debugger interface: I prefer DDD. If a tool helps me, I use it.
:) Hope remains that some people are going to start it as part of the GNOME project. Perhaps, we would have something if GNUSTEP was somehow complete. Until then, I have my terminal windows, emacs and ddd.
Likewise, it would be handy to get hold of a slim and capable editor, a gifted debugger, GUI builder, makefile manager, class/object browser, etc. as a suite of development tools. But that doesn't mean that you can write a single ugly application that makes kludgey auto generated code and doesn't give you full control, numbing you with silly conventions. They call that Visual C++, if you're fond of that join MS Developer Studio team and be shadowed under curses of a thousands developers every day.
I believe that there are a couple of guidelines to follow. For instance, the infrastructure is more important than the looks. In order for the tools to communicate, they should have CORBA (or an appropriate object model) interfaces. In other circumstances, they should be usable as standalone applications. So you can have your editor-of-choice that works with the rest. The compiler and debugger interfaces must be well defined, as well as binary format handling; I think the standard GNU tools will do.
The DE must not be focused on a single language, for instance the "type browser" must work equally well for both C++ and Scheme. No need to mention that support for a new language should be as simple as a plug-in.
If a tool is calling a command line program, it must supply a complete interface. That is, one that gives ultimate control over the tool: without omitting any options or functionality, and indicating the mapping clearly. So a front-end for gcc options must be pretty articulated. Of course, for makefile management, as an example, I think there might be multiple back-end choices. So the design can take that into account.
[Don't know, make it OO and derive subclasses.. Separate interface/implementation so that the framework is not tied to a single CLI]
There are many other things to worry about, but I'm out of ATP. After all, you'd like something that works and give you a good speed-up.
Unfortunately, there is no such thing in UNIX. I haven't seen it and I don't believe that it exists.
--exa--
"Obi-Wan has taught you well, but you are not a Jedi yet."
--- A Jesus Fish eating a Darwin Fish only proves Darwin's point.
--
There a team working on a Pascal IDE for Linux -- check it out at The Megido Project.
Being force to type 1.0 instead of 1 might be
annoying, but its nowhere near as bad as
searching for a bug in C code caused by eg.
float x = 5/2;
assigning the value 2.0 to x.
And believe me, a lot of people who think they know C do make this mistake.
C-Forge ( http://www.codeforge.com) is close. Not perfect, but close.
It does use it's own editor, tho.
-- -- The Dragon De Monsyne
Fearing you might be correct, I looked up the "I" word. Webster's Unabridged (1989) says "integrate" means to bring together or incorporate parts into a whole, which definition would tend to back you up. OTOH, "integratED", once you get past the religious/ethnic group thing, has to do with "combining or coordinating separate elements so as to provide a harmonious, interrelated whole", or "organized or structured so that constituent units function cooperatively", which I read as applying perfectly to the way unix tools talk to one another with pipes and structured text. OTGH, I suspect I'm preaching to the converted here :-P
...this looks out of place, but who am i to question goddess.
nmarshall
#include "standard_disclaimer.h"
R.U. SIRIUS: THE ONLY POSSIBLE RESPONSE
nmarshall
The law is that which it boldly asserted and plausibly maintained..
--Colonel Burr 1783
--
Well it's certainly about time that something like this came out from Cygnus...since the administration of our University seems set on the idea that we need something like Codewarrior to code, at least we can have something almost USEFUL.
Just yesterday, I was asked by a regular person, not even a kid, whether [random software] was `freeware, or just shareware'. See that? Here's a simple test. Go out and ask 20 teenagers whether free software (which they'll call freeware) ever costs anything, and you'll find that 100% of them say, `What, are you crazy?'
Let's face it. We've lost this battle. We have to stop hurting our own goals by beating a dead horse. We must instead use a real word in the way that everyone understands it. Of course gratis and libre are lovely distinctions, pero por desgracia, ocurre que todo el mundo no entiende castellano. :-)
Instead of gratis, perhaps we should say cost-free. See how clean and simple, how unambiguous that word is?
Instead of libre, we might say something more like hackable; that's my own original preference, but it has its own attendant difficulties. Less charged alternatives include changeable or mutable or legible or open source or as source code or in some cases, perhaps unrestricted. Historically, we used freely redistributable as distinct from public domain, but that's a problem term because it has the `free' bug, and doesn't specify source code.
I may not be certain about what the right word is, but I'm completely certain what the wrong word is. The wrong word is `free'. Please, please, PLEASE drop these teen-age word-games that only cause everyone on the outside to get confused just so that those on the inside get to gloat about how much smarter they are than the rest of the word. It's long past time to face the fact that we've lost the battle for this word, and perhaps time to realize that it was always the wrong word right from the get-go.
I totally agree. IDE's are not all that they are cracked up to be. However, I see this as good for Linux in three main ways:
1.) Linux will be taken more seriously as a developer plaform.
2.) If it takes off that way software(in theory) would cost less to develop b/c of Linux's free nature.
3.) As you stated, people that code with heavy assistance from IDEs can now develop in Linux meaning a larger programmer pool.
The last item is either good or bad. Perhaps it is better that only those that truly know how to program are writing code in Linux. After all, not just Win32 itself is responsible for apps crashing.
Conversely, it could be good. Think of it as a domino effect--People of all coding abilities could be drawn to Linux and create and contribute. Given Linux's community and software peers, we pressure to keep open source and as a result can better others' shotty code. Still, there is no excuse for writing bad code in the first place.
The bottom line is that IDEs can be really good for Linux. Granted, there is no excuse for getting addicted to anything, i.e.: IDEs and even HTML editors. People could write worse code but as long as Linux keeps the open source attitude, we can pressure them to get it right.
-Clump
I think writing a decent UI shows more ability than typing at a command promp circa 1981. Having the power of linux controlled from a consistant and easy to use frontend would be decent.
Yeah, them and those pesky high-level languages.