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.
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.
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?
Many small tools is the Unix Way. Why lump everything into a bunch of huge, bloated applications that each try to do everything in a very narrow field, when you can have a bunch of small, efficient utilities that each do one thing well, and can operate on a wide range of data?
Integration leads to limitation and redundancy. De-integration leads to flexibility and efficiency.
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.
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!
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
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
Why don't you be a man and just use those switches on the front of your computer.
--
Business. Numbers. Money. People. Computer World.
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.
Don't forget cscope.
Because they like to screw with people's minds. "Free" quite simply means gratis in virtually everyone's minds, and everyone knows this. The word you want for libre is "hackable". Until they figure this out, they'll continue to hurt themselves.
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