Recent advocacy from Havoc Pennington and Miguel de Icaza may disagree on the exact high-level language to use for GNOME, but they both agree that a change needs to be made. However, Edd Dumbill thinks the debate so far has been taking a rather introspective view. To focus purely on language choice is to miss the biggest part of the picture, he says.
GNOME’s Next Step Must Be a Big One
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
>these [potential new gnome] developers:
>Will not tolerate autoconf and automake.
>Will not teach themselves by searching through the GNOME CVS to see how an API is used. They’ll need documentation and examples.
>Will need fast results and not want to use C. They’ll want a high-level language like Visual Basic, Java, Python or C# [and proper RAD tools]
He is dead on IMHO.
I second! I am pretty agreed with everything what he has said. Great article, I like it!
Edd’s probably on the money. Now that Scott McNealy has
rejected open source Java and with Mono’s Microsoft
handicap they’ll have to stand on their own two feet.
Frankly. I think GNU/Linux is big enough to design and
construct an original platform.
Indeed but this changes should have been done with 2.0 that is proper planning before the first steps with 2.0 got started. It’s not just sticking to one language, it’s also taking care that the work that makes it into GNOME is from good quality.
I have been criticising for quite a few years now that the roadmap that GNOME has chosen wasn’t the best, since there wasn’t any such thing as a roadmap at all. A lot of different languages (C, C++, Python, Perl etc.) for the core elements, a lot of stuff that is simply broken or not reliable enough for daily work. Programs that start working reliable got changed over again while the bits that are really broken in other parts have been left untouched. No clear roadmap where GNOME really wants to move and focus. Good documentation for people to port their stuff and documentation telling them what bits of GNOME they should use and which one to avoid (e.g. Deprecated stuff) are missing too. A lot of old remaining bits from former GNOME 1.x days like different ways to create a Window, rapid changing API with a lot of deprecated stuff etc. And a huge amount of time for developers to fix their stuff due to all this. Yes there are changes from 2.0 – 2.6 and programs written for GNOME 2.0 can easily require huge changes to get run on 2.6 specially when using deprecated functions that you want to get rid of.
A lot of the points I have raised which I with my experience believed in to be problematic within GNOME that always got ignored and where I have been falsely being attacked for.
What GNOME seriously needs:
– True professionals who repeadly do usability tests. With this I mean true professionals and not semi professionals or people who read a ‘UI for dummies’ book or people who became usabilty expert over night. I do mean professionals who have a solid education on theoretical thing as well as practical thing (during user feedback). We do have a lot of usability nonsense in GNOME these days. While we had the best things in mind like fixing the Usability issues – some developers started to overdo this and made things became unusable again. Or usable in a different way.
– True integration of things within GNOME. That is when someone fixes dialogs of applications that this application will have ALL dialogs fixed properly rather than just half of them. Same goes when using technology such as GStreamer which still feels like it’s added half.
– Getting rid of old API stuff that should seriously NOT be used anymore (document them and make that document available to developers) so they at least get a clue where to go, what to use etc.
– Make sure that the entire GNOME framework is being written in one development language.
– Make sure that the GNOME libraries won’t get changed every 2 days with new technology stuff. This only keeps developers fixing their programs rather than concentrating on improving them.
– Make sure that the applications stay usable. Only fix the bits that are required e.g. change from deprecated stuff to proper API stuff but keep the philosophy of the program in tact. Make it stable, make it not crashing, make it work and keep it working. It makes no sense getting an program to a level of usability and then make drastical changes to it again so it gets not usable anymore.
With usable I mean the way a USER can use it in a practical way not the theoretical way as written by some expert in a book.
The so called ‘Big Step’ was happening from 2.0 to 2.6 over and over again, a lot of huge changes in the GNOME API while it still keeps compatibility to old stuff it on the otherhand added a lot of new stuff as well and older stuff is marked deprecated. This is only a clear sign that they still aren’t finished with a proper solid API. A few little changes in a library can be a huge change that a developer has to do for his program.
The next Big Step how should this look like ? Yet another ride on a road with no end ? Huge programming language change ? Switching from C to C# ? This requires that everything needs to be re-written again, this means that we (those who work on separate GNOME stuff) need to do huge changes again and this is a never ending story.
As it looks at the moment GNOME is permanently circling in adding stuff, marking things deprecated, a bit coding here and there. Bit new icons here and there, a bit polish here and there. But it’s not reaching a point where it can be declared (It’s ok as it is now, let’s seriously FIX the stuff, make it damn stable, make it work for people) and keep people work on extra GNOME apps without them to worry that huge changes happen again.
That’s why it’s fair to eye over to the KDE community and see them having solved these issues properly during the 2.0 and 3.0 movement. They entirely stabilized their API and kept the stuff in a way that doesn’t change drastically (so it requires huge changes to be done for the developer). They wrote the entire architecture in C++, they have one way of designing GUI’s, they have properly documented guides and documents, they kept improving their applications and fixing things rather than doing huge changes. GNOME needs that stuff and it needs it urgently. But these things should be decided properly before a development process and not in the middle of it. Hope they take these things in account before making yet another huge change that affects hundrets of applications again. Otherwise we never ‘end’ as in (getting apps to a state that they can be useful and really practical).
Which is faster mono or java? I know java has made recent significant improvements concerning speed but for something as massive as a whole enviornment can it handle the task?
Anyway, the guy was spot on, especially w/ documentation to me. This is lacking in all areas of OSS where recently I had to go into kernel source to find out what a /proc/sys/ entry did. Red Hat is the only distro I use and thier documentation is very professional and informative but its only for the OS, if things were written that well everywhere including API’s I might start writing GUI apps instead of perl scripts.
Hi, great article! What about adding C++ to the list of the higher level languages? This language is standard ISO
and probably a natural evolution from the C language developers. Also it would help interoperability with our friends, the KDErs. Compliments again, chris
GNOME has always being a development platform, and its core underpinnings are relatively well documented. Unfortunately, because its core technology is written in C, it scares away a lot (new)(young)(modern?) programmers who have been brainwashed, or taught, to believe that developing desktop related components or applications in C is atrocious, painstaking and virtually impossible. Of course, this notion is false to say the least.
I do agree, however, that coding on Linux, and GNOME in particular, should be made easier and fun for potential developers. Mono seems to be moving in the right direction. It is a language agnostic development platform that provide developers with rich application programming interfaces for developing software applications easily and in a rapid manner. It is also relatively well documented.
The fuel of open source are hackers, or developers. Yet, of late, we seem to pay way too much attention to average Joe and aunt Tille. I think more focus should be directed at equipping open source hackers with advanced, easy-to-use, entertaining and rapid development tools and environment, if at all open source is to prosper. Average Joe or Aunt Tille won’t right the next killer application. But the young geek locked up in her room for days fascinated by the wonders of Python and Linux might, if you provide her with powerful tools.
Well that’s all fine as long as the quality doesn’t suffer.
I don’t think that anyone of us wants to be here ten years from now. Moaning about all the bad practices, and bad code that results from them.
I believe this is oGALAXYo’s homepage, see for yourself: http://www.akcaagac.com/
Umm…let’s see if I got you straight. Basically new programmers have a false notion of “C”, and we should genuflect to this? Wouldn’t it be better to get that straight first, then see what would be best?
Other than that I agree with equipping developers properly. The fun part of the discussions come from figuring out what tools those might be.
In theory i believe C# has the capability to be faster. C# is basically identical to java, with a slight twist. when you JIT compile C# code, rather than getting tossed to the bit bucket every time you run the program (like java does) that JIT compiled code sticks around in the executable. This allows you to get the cross platformness of java (bytecode) and the speed increase of precompiled code. It’s not perfect however. It is still somewhere inbetween java and C++ in terms of raw speed. I wouldn’t, for example, recommend C# for scientific programming or game development.
Hi DrLinux,
Hi, great article! What about adding C++ to the list of the higher level languages?
here you go http://www.gtkmm.org
Thanks, but I knew already about gtkmm and the other *mm libraries: the point I was trying to make is that in the upcoming Gnome3.0 (or whatever the name will be) C++ should not be excluded.
Talking about the present, I’d like to encourage people and see the good sides of the developing situation of Gnome:
(1) we have a GREAT C API (can I say the GREATEST ever created?)
(2) we have a GREAT C++ API, that is continuously kept up to date and refined (the coverage of the *mm librariues is pratically 100% of the C API of Gnome)
(3) we have a GREAT Python API, that is fairly usable, even if not up to date to the latest C API, it is currently under active developement (and you don’t need the ‘latest’ to make good apps, anyway)
My point is: what do you want more? You have the low level tool with C, you have the high level tool with Python, and you have the all-levels tool with C++
Ciao,
chris
“what do you want more?”
Well, that is what the article was about: IDE’s and documentation.
Documentation is a huge thing that is missing for the open source developer newbie. You’ve got some 30 year old guy who works 9-5 and might want to do some Gnome stuff but is in no way inclined to trudge through header files. KDE is much better at developer docs than Gnome is. There should be lots of examples, and preferably in different languages(MSDN). You need a good IDE(Monodevelop anyone) and for christsake can the autotools die already. There has to be a better way.
@OGalaxyO – You don’t have to rewrite everything in C#. Those apps that are already in C should stay that way. Maybe do a Mono plugin system for your app. The great thing about C # is that it’s trivial to call native code from with in C# code unlike Java’s JNI.
> (1) we have a GREAT C API (can I say the GREATEST ever created?)
Well you can say that the API is there and get’s improved but I for my own won’t call it ‘the GREATEST ever created API’ since it’s simply not true. A great API implies that the functions are working properly, reliable and correctly. When I peek over in the brokenes of gnome-vfs here then I would call it anything else than GREAT. But I am not itching here since it’s just how you see it.
You should also look over the table corners and peek over to other solutions such as QNX or MorphOS (AmigaOS) for example. They do offer a great API too even if their ideology are different than the ones from GNOME. Starting from the Kernels core till the Desktop solutions. Also look at BeOS or MacOSX here and all the other projects people have stomped out of the ground within the past ~30 years of computer business.
When I see things like HAL then it may have a nice API but I do publicly questionize if the concepts are that great. A HAL as we know from ~30 years of computer science is always something you put between the Hardware and the Kernel and not between the Kernel and the Desktop. Even if the API is nice it still trashes the philosophy and concepts of proper computer science as professors and lecturers teached us in all the years. If I’d came up with such a HAL solution for my computer sciences exam then my professors would probably have dropped me because of insane ideas or they would tell me that I haven’t understood the concepts of HAL properly. This is just an example.
There is no such thing as ‘the GREATEST or BEST’ there are always solutions that get improved with each iteration of version. You can try to make things better in one way and improve it but there aren’t any ultimative solutions. If the solutions would have been ULTIMATIVE then we wouldn’t read this article on OSNews.com.
Umm…let’s see if I got you straight. Basically new programmers have a false notion of “C”, and we should genuflect to this? Wouldn’t it be better to get that straight first, then see what would be best?
I can’t count the number of times I’ve heard misconceptions about C being bad for desktop application development just because it is not an object oriented language. It makes a lot more sense if people express their disgust for an API because it is poorly written, undocumented and cryptic to decipher and use. After all, it is the APIs we use to develop applications not the procedural C language.
And again, this has nothing to do with procedural versus object oriented languages. Good development platforms have rich APIs that are well documented and are easy and intuitive to use. If most developers can guess how an API works without reading the documentation, and their guess is correct, then the programming interface is intuitive, irrespective of whether the language they are using is procedural or not.
One way we can avoid language wars or preferences is by providing a development framework that is language independent which has access to the same rich set of APIs irrespective of the language the developer uses. This is where Mono enters the equation. Mono combats several issues. Language wars are irrelevant with respect to Mono. Chances are that you can use your favorite language in Mono. A rich set of APIs are provided. Mono provides all sorts of APIs for developing desktop applications, to web sites, to web services, to database applications, to a combination of all of them and more. And most of them are well documented and free. Free Unix doesn’t lack good APIs. The problem is that all these APIs aren’t provided in single coherent environment to developers. I think Mono aims to rectify that.
Free Unix also has great tools all scattered about. Integrating these tools intelligently into one environment will do great good to developers. We don’t have a Visual Studio.NET for open source developers. If you want to attract your Window developers to open source, then you need to provide the equivalent of Visual Studio.NET or better for them to play with. Yes, emacs and vim are powerful, but I doubt Windows developers want to learn how to use them, or want to manage their projects with automake or autoconf.
Modern developers want decent IDEs. Only a few of the ones available for open source, like Eclipse, match the power of those on Windows. But again, this issue is being addressed.
So I’m over at the Gnome’s User’s Board to see what people are saying about Mono over there since I knew there would be discussion with the recent Havoc and Miguel blogs. Surprise, surprise – I would say from what I’ve seen Mono is being very well received and will only get stronger support. I see the patent issue, slowly but surely dying. As Nat Friedman once said, “If you write a thousand lines of code, chances are someone, somewhere has a patent on it”.
Monodevelop is coming along fast, and since Anjuta has issues, I see it as becoming Gnome’s answer to Kdevelop. There’s nothing wrong with people writing core apis/libs in c, but if you want to compete, then regular apps have to be written in something other than straight c. KDE has the edge there with the use of C++. Mono could leapfrog KDE’s productivity advantage. Gtkmm is cool, but it’s still C++(with all its warts).
Gnome embracing Mono is the way to compete with KDE. Believe it or not, a lot of people that use Linux also care about windows too, and if using Mono means that all you have to do is write a different front-end or maybe no port at all then that’s a big win. Let’s face it, Java is officially dead on the desktop as a platform. Notice I didn’t say as a language, I said as a platform. Mono is the platform. For those that want to write with Java, then they have IKVM which translates java bytecode to CIL.
With Longhorn being pushed back, this is a critical time for Gnome. Either they embrace change now, or risk falling further behind KDE and Windows.
I would not call “high-level” a language that contains the archaic concept of pointers.
>> Will not tolerate autoconf and automake. They’ll need IDEs.
Right on. And these IDE’s should NOT, I repeat: NOT use autoconf and automake for the tasks these 2 programs take care of either.
See what happens when using KDevelop(3), if something breaks you’ll have to fix it on your own.
Fixing (and/or creating) some autoconf, automake or libtool script is like a walk through hell.
Same goes for other programs too, by the way.. ie. graphical burning programs shouldn’t wrap the cdrecord command.
Rather, both the cdrecord and graphical burning programs should use a common burning library so things like errors are handled properly (more than by reading/hacking cli output).
“I see the patent issue, slowly but surely dying.”
And what exactly has been “dying”? Have laws, or terms been rewritten? Has Novell found something relevant? Or am I to hazzard a guess is that people simply got tired of talking about it? Which unfortunately is the worst way to approach any legal issue.
“As Nat Friedman once said, “If you write a thousand lines of code, chances are someone, somewhere has a patent on it”. ”
That unfortunately doesn’t mean that the situation has gone away, or died as it were.
“Gnome embracing Mono is the way to compete with KDE.”
Not everyone shares that opinion.
[root ]
True. However my point is that using other people’s “misunderstandings” as a foundation for making a not inconsequential decision isn’t necessarily wise.
“And again, this has nothing to do with procedural versus object oriented languages. Good development platforms have rich APIs that are well documented and are easy and intuitive to use. If most developers can guess how an API works without reading the documentation, and their guess is correct, then the programming interface is intuitive, irrespective of whether the language they are using is procedural or not. ”
To a point true. However remember we’re talking about software developers, not Joe and Jane cupholder here. It’s not unreasonable to have our expectations a bit higher in the knowledge tree.
First you write:
“Indeed but this changes should have been done with 2.0 that is proper planning before the first steps with 2.0 got started.”
Let’s ignore the fact that Mono was far from a usable state when GNOME 2.0 was released, and it still hasn’t reached v1.0. You appear to mean that a design needs to be perfect before implementation even starts, but then you write this:
“There is no such thing as ‘the GREATEST or BEST’ there are always solutions that get improved with each iteration of version. You can try to make things better in one way and improve it but there aren’t any ultimative solutions.”
Which completely contradicts your earlier statements. You’re just an armchair developer who whines about GNOME all day. It’s no wonder your posts get modded down.
I think that people are forgetting why things are done in Linux/Unix the way they are. Remember the tinker-toy, individual parts doing one thing well. A CD-burning program can function equally well in either a GUI or CLI environment, remotely or right at the machine. Expanded in ways the designer never thought of. I like GUI’s as much as the next person, but one should never let that obscure our strengths.
C is most definately an archaic language for any sort of development, except perhaps some very specific types. I wrote a couple of hundred lines of Python code today in the amount of time it took me to watch Survivor and The OC. I’ve never been able to do that with C or C++. The great thing about Python is that the code usually works on the first try. Even if it doesn’t, given the highly dynamic nature of the language, the problem often takes a minute or two to fix. Plus, since its interactive, you can test as little as a function or statement at a time. When ESR gushed about how he could write working Python code as fast as he could type, he wasn’t overstating the facts.
>> Will not tolerate autoconf and automake. They’ll need IDEs.
Right on target. An IDE that the Joe 9to5-worker can use that make development as easy as Delphi/VB is *the* key to success. (where had MS been today without VB?)
Provide an IDE, and you’ll see that the other big issue with Linux/OSS (ie, lack of apps) will solve itself.
Mediocre programmers don’t start coding the core components
C is most definately an archaic language for any sort of development, except perhaps some very specific types. I wrote a couple of hundred lines of Python code today in the amount of time it took me to watch Survivor and The OC. I’ve never been able to do that with C or C++. The great thing about Python is that the code usually works on the first try. Even if it doesn’t, given the highly dynamic nature of the language, the problem often takes a minute or two to fix. Plus, since its interactive, you can test as little as a function or statement at a time. When ESR gushed about how he could write working Python code as fast as he could type, he wasn’t overstating the facts.
But that says little or nothing about the design, quality, robustness, scalability, functionality, efficiency, security of the application you wrote. Writing applications is not just about easy syntax, time and lines of code, except of course you are in the commercial software development sphere. I think there is a lot more perspective to writing applications for public consumption other that line of code, time and easy syntax.
I do agree, Python is a great language, but I doubt it makes C archaic for any sort of development. Take a look at embedded devices, bios, drivers, APIs, graphics engines, game engines, operating systems, database applications, games, to mention a few, how many of these are written in Python as compared to C? Majority of the application you will or have come across are probably C or C++, at least of Windows.
C is a versatile language, Python isn’t. When you have a language that can do anything on a multitude of platforms, it’s hard for it to become archaic.
Seems as Novell as decided to use QT to unify their distribution.
http://www.heise.de/newsticker/meldung/45991
Schließlich sickerte im Verlauf des Tages die Nachricht durch, dass Novell sich bei der Entwicklungsumgebung und -bibliothek für Qt entschieden hat, womit praktisch KDE das Rennen machte.
root, if you’re unable to see why there are languages better suited then C for desktop environments, then you’re either blinding yourself to reality, or just don’t understand C very well.
writing your program in m4 is insane. Everything should be moved to Scons or jam or whatever.
sure C is easy, make some insane overhead of marshallers and typedef structs to simulate an object orientation, that would take half the code in C++ or any other object oriented language. additionally it’s just plain messy. look at mozilla, is it written in C? imagine it was written in C and the disaster contributors had, if they want to look up or fix stuff in its sourcecode.
C is nothing but a toy for good coders, sure they have no problems using it, but if you want many people to write apps you have to use something else – either or have many tutorials, and howto’s handy. in gnome/gtk/themyriadofgnomelibs this is obviously NOT the case.
at some point you feel like being fooled browsing through the gtk docs and yet having to return to the irc channel and mailinglists to ask people patiently for help about what function X/y really does
root, if you’re unable to see why there are languages better suited then C for desktop environments, then you’re either blinding yourself to reality, or just don’t understand C very well.
The availability of rich APIs dictate how well or easy it is to develop desktop application, not C, C++ or Python. Perhaps, you don’t understand the message I’ve been trying to get accross all day.
> Right on. And these IDE’s should NOT, I repeat: NOT use autoconf and automake for the tasks these 2 programs take care of either.
> See what happens when using KDevelop(3), if something breaks you’ll have to fix it on your own.
> Fixing (and/or creating) some autoconf, automake or libtool script is like a walk through hell.
And you think a home-brewn build & configuration system wouldn’t be “walking through hell”?
autoconf and automake do their job well, and most users are comfortable with them and expect projects to be built that way.
Users will reject any home-brewn build system that doesn’t work like autoconf. See for example boost, helix.
Furthermore I don’t think that any other build system will get as wide acceptance as autoconf/automake as they are what 99% of the projects are using.
sure C is easy, make some insane overhead of marshallers and typedef structs to simulate an object orientation, that would take half the code in C++ or any other object oriented language. additionally it’s just plain messy. look at mozilla, is it written in C? imagine it was written in C and the disaster contributors had, if they want to look up or fix stuff in its sourcecode.
Some parts of Mozilla is written in C. I still don’t see how writing Mozilla is C is any messier than doing so in C++. Galeon and Epiphany which are browsers based on gecko are written in C. In fact, I just don’t understand your agitation.
Perhaps, I will understand your horror better if you showed me an example of a large messy C project and its cleaner C++, or object oriented counterpart, then I’ll comprehend.
You should give ruby (http://ruby-lang.org) a try. Much better language than python, and the syntax is quite similar.
Graphical representation of objects (windows, buttons, etc.) is one of the classical examples of why you should use OOP. I would agree that c++ wouldn’t be the best OOP language for this, eiffel is IMHO better (especially because it makes multiple inheritance less awkward than c++) but unfortunately eiffel compilers aren’t very good.
Ruby seems to be a well suited language for this matter:
– Extremely easy to learn
– Object Oriented
– Rapid prototyping using Glade and Libglade
– no make, autoconf, etc…
OK, it’s slow. But I think the way is an interpreted language
be it Ruby, Tcl/Gnocl, [put your favorite IL here with gnome bindings],…
Comments?
omnivector: indeed.
I invite anyone to take a look at Ruby and Ruby-GNOME2 anytime… much simpler syntax, yet very powerful.
I can’t stand Python’s syntax. lambda this, self that. Not for me. But Python does have lots of libs that help the pragmatics. 🙂
next time they may need to put
“Display Until” and “Expiry Date”
for each of method/function/APIs
..just kidding
>GNOME has always being a development platform, and its core
>underpinnings are relatively well documented. Unfortunately,
>because its core technology is written in C, it scares away a
>lot
In my experience, C is NOT what scares them away. I’ve been
trying to get some of the Windows developers here do do
some linux programming(some of them are ancient *nix programmers as well, 10-15 years back..).
What makes them just try, but always pass the load to me
is:
*No sensible IDE, Anjuta/KDevelop/XEmacs just puts them off,
its not good for them. Memeber/parameter insight, code
completion is needed. As is a USABLE gui designer if one
needs to do gui apps, and NOT editing makefiles or worse.
*Autotools/makefiles etc. Noone wants to write a
configure.in or a Makefile.am. Its scary, complex,
laughable in the 21 centurey to edit suck beasts.
*Bad/scattered documentation. For people used to MSDN
Library(its not just msdn.microsoft.com, but also a
standalone app, big brother version of those windows help
things.) where you hit F1 on a variable,function etc. Get
instant access to ALL supported APIs,articles, guides etc.
the current non intergrated collection of docs is frustrating.
Some docs are PDF/PS’s in /usr/share/doc/* some in /usr/share/gtk-doc/
some in man pages etc.
I recently discovered Visual Slickedit though. Got better reponses from the windows developers here than anything else. I’ll try that some more later on …
Key point in Slickedit was: a few clicks to make a project.
Add/edit files, push a button to compile and run.
“C is nothing but a toy for good coders, sure they have no problems using it, but if you want many people to write apps you have to use something else – either or have many tutorials, and howto’s handy. in gnome/gtk/themyriadofgnomelibs this is obviously NOT the case.”
C is not a toy, not even for demi-god programmers. If you’d like to have many people writting apps why not give them a proper education, instead of teething them on RAD’s.
I think the last page and a half or so of comments pretty much prove root’s initial point:
The most important thing is getting a good, well-documented, language-independant API for programming software (GUI and otherwise) on Linux.
In Windows, you get a lot of conversation and flames over VB, C#, J#, Java, C++, and once in a while C and a handful of scripting languages. In just the last page of discussion on Linux programming, we’ve gotten Ruby, Python, TCL, Eiffel, C++, and C, and the same can be said many times over in many other threads, with some Perl and shell scripts and of course Java thrown in for good measure. What language you use to create an application shouldn’t matter. No one cares that I wrote a C# wrapper to make a C++ dll accessable from a VB.Net front-end with a Managed C++ dll to handle some routines that were a little too slow in either VB or C#, and no one cares that the Managed C++ dll drops into unmanaged code for many of the speed-sensitive portions. What they care about is that it works to solve the problem they had. If someone else needs to look at the code, it’s commented, the C# code doesn’t do anything more than manage the calls to the library that was documented by it’s original vendor (and there are more comments to clarify sticking points), and the C++ code is seperately documented (beyond the comments) simply because most of the people that will look at the code for the program are VB coders that will have enough trouble getting up to date on the .Net changes to that language, let alone figuring out C# and C++.
In the end, though, I also know that I can remove the C# wrapper and rewrite the GUI for whatever toolkit I want, then only have to worry about the C++ library I wrote. This has been a concern throughout the development, which is why I made the managed portion of the library as minimal as possible, so a rewrite in straight C++ should take very little time. The other alternative was to write the library in straight C++ and write another wrapper, and that’s still a consideration for long-term maintenance.
The important part, though, is that the languages were all chosen for a reason. The VB code was used because of the combination of speed of development of the GUI and the fact that the people here are familiar with VB. C# was used because it’s the language I’m most familiar with for wrapping unmanaged libraries for managed use, and because maintenance of that code should be minimal (thereby side-stepping the need for VB). C++ was used because I needed to drop out of managed code for some functions to gain some speed, even though the joints between the managed and unmanaged code would be a bit on the slow side, and again the maintenance of that code should be minimal.
If I wanted to use Eiffel, Perl, Python, or Java, I could get (or already have) compilers and IDE extensions that will allow them to work in the .Net runtime, and even (in most cases) interact with other languages just as the code I have already written does. Most of the APIs in the .Net runtime also work fine from any of those languages.
Most importantly, though, before .Net even came around, the Win32 API was always at least somewhat accessable from multiple languages. Sometimes that particular language needed a runtime that interpreted the calls, sometimes you needed (occasionally archaic and ugly) frameworks and classes built for that purpose, but in the end Windows didn’t care if you used VB or C++ (and eventually Java, but Sun didnt like that).
Almost every developer I know has used at least a couple of languages in his/her lifetime, and prefers one or two over others for certain purposes. What desktop environment you’re using shouldn’t dictate what language you use, otherwise developers will choose the desktop environment that supports bindings for their language. If side-projects are working on making Qt and GTK work from other languages, than desktop environments like KDE and Gnome that depend on these toolkits should probably work on letting developers know these projects are out there. APIs and documentation should be as language-agnostic as possible, and sample code should be written in as many known-supported languages as possible. When I go through MSDN documentation I can select the language at the top of the page and the page shows the relevant information; on the web site the code samples are simply available in each language and labelled appropriately.
Languages used at the low-level of these types of frameworks are of little concern to me, or most other developers. They’ll be determined by a set of criteria that includes efficiency and the preference of the developers implementing the framework. What matters is that their choice should not limit my own choices when I want to write an application that works in their desktop environment. Instead of all of this argument over whether people should write GUI code in Eiffel, Python, C++, or C, people should simply be writing code in all of these languages.
*No sensible IDE, Anjuta/KDevelop/XEmacs just puts them off,
its not good for them. Memeber/parameter insight, code
completion is needed. As is a USABLE gui designer if one
needs to do gui apps, and NOT editing makefiles or worse.
Anjuta has code completion and Member/parameter insight. I think Kdevelop has those features too. Not sure about emacs. KDE and GNOME have GUI designers. Gnome has an application called Glade. After reading some documentation, using it is very productive.
*Autotools/makefiles etc. Noone wants to write a
configure.in or a Makefile.am. Its scary, complex,
laughable in the 21 centurey to edit suck beasts.
Someone correct me if I’m wrong, but the most common way of installing applications in Unix/Linux is ./configure; make; make install. So they have little choice but to learn how to use the Autotools. Automake and Autoconf aren’t as bad as people exagerate them to be. Developers are lazy, they don’t want to learn how to use tools. To be a Unix developer you need to learn how to use your tools effectively.
I also understand there are alternatives to Autotools which people claim to be better.
*Bad/scattered documentation. For people used to MSDN
Library(its not just msdn.microsoft.com, but also a
standalone app, big brother version of those windows help
things.) where you hit F1 on a variable,function etc. Get
instant access to ALL supported APIs,articles, guides etc.
the current non intergrated collection of docs is frustrating.
Some docs are PDF/PS’s in /usr/share/doc/* some in /usr/share/gtk-doc/
some in man pages etc.
Most well known projects like GNOME and KDE have documentation pages or documentation applications. GNOME, for example, has an application called devhelp that contains documentation to all the GNOME/GTK/GLIB/GIMP/etc core APIs. However, I do agree that the documentation issue can be improved upon. It used to be that before you even began coding, a programmer had to write extensive documentations, white papers, specifications, revisions, design blueprints, prototypes etc. Unfortunately, a lazy generation of coders is evolving with horrific coding attitudes and etiquettes .
On Unix, all developers should at least know how to use the terminal, a file manager and a simple text editor to write and manage code.:-) They are Unix hackers best friend. But of course for extremely large projects, an IDE might be convinient for Windows converts or commercial software developers.
> Someone correct me if I’m wrong, but the most common way
> of installing applications in Unix/Linux is ./configure;
> make; make install. So they have little choice but to
> learn how to use the Autotools.
And this is exactly the problem. 🙂
> On Unix, all developers should at least know how to use
> the terminal, a file manager and a simple text editor to
> write and manage code.
The point is: you don’t need it under Windows. So there is no excuse to require this under linux/unix/gnu.
Eh. I dunno. I didn’t really see anything in Ruby I like more than Python. Python has more libraries, too.
>Anjuta has code completion and Member/parameter insight.
Seems so. But it still has autotools.
What a hassle to have a project/workspace that makes
more than one binary..
Do you honestly think your arguments will “convert” the deveoplers I’ve tried this on. They have already tried the
tools and found them not to fit their needs. Its about
tool fitting people, not people fitting the tools.
>someone correct me if I’m wrong, but the most common way of
>installing applications in Unix/Linux is ./configure; make; make install.
Its common, yes. Though most prefer to e.g. apt-get install .. (or whatever package tool that’s used.)
Anyway, who says everyone
must develop opensource apps or cross platform ones ?
Ideally people would install binaries that works with no hazzle(opensource or not), not have an entire development environment on their box to install apps.
I’m very sure my father would rather point’n’ click to install an application rather than ./configure ..
>On Unix, all developers should at least know how to use the
>terminal, a file manager and a simple text editor to write
>and manage code.:-)
Why ?
And what if they don’t want to learn/work that way ?
They should just be excluded ?
Developers will have their own opinion on what fits
their needs and how they are most productive. Other
than hardcore *nix developers ought to have options as well.
But that says little or nothing about the design, quality, robustness, scalability, functionality, efficiency, security of the application you wrote.
Eh? Let’s just say that its a lot more robust, functional, and secure than if I had written the same thing in C in the same amount of time.
Writing applications is not just about easy syntax, time and lines of code
Um, that *is* generally what writing applications is about? Besides, the more time you save doing drudge work, the more time you can spend adding features, improving performance, etc.
I do agree, Python is a great language, but I doubt it makes C archaic for any sort of development.
It makes C archaic for a whole lot of development. Pretty much everything that doesn’t need to run fast.
Take a look at embedded devices, bios, drivers, APIs, graphics engines, game engines, operating systems, database applications, games, to mention a few, how many of these are written in Python as compared to C?
These types of applications represent a very small part of the overall applications market. 90% of software is not this sort of “shrink-wrapped” stuff, but instead custom code for specific situations.
C is a versatile language, Python isn’t. When you have a language that can do anything on a multitude of platforms, it’s hard for it to become archaic.
C is a very limiting language. High-level assembler and nothing more. Now, there is a place for high-level assemblers, but let’s just say that even the last embedded machine I worked on had enough power to at least run C++ properly…
The point is: you don’t need it under Windows. So there is no excuse to require this under linux/unix/gnu.
Windows programming != Unix programming
The philosophies exhibited by Unix coders are extremely different from what your Windows programmer considers traditions.
I’ll give two conspicuous example. In Unix, many/most applications are developed using the client-server model. As a result, applications can have several user interfaces. In fact, most applications can be used in command line mode and also have a GUI interfaces.
In Windows, application are primarily designed to be GUIs with no command line interface. Unix hackers store their configuration files in human readable form. So that users can configure their applications via text editors or via a graphic user interface. In Windows, configuration files are usually stored in binary format that is changeable by the users only via a GUI or the running app.
In Unix hackers believe users should be able to compile, build and install an application from source code(hence the reason for Autotools). Windows programmers do not expect users to install programs from source code, but via an installer, and source code is usually never provided, but instead precompile binaries are provided.
There are also several other fundamental differences in culture between the Unix and Windows school of software programming, which I have not mentioned, but surely, because Autotools isn’t required on Windows doesn’t automatically mean it doesn’t have to be required on Unix. How on earth do you expect millions of users to install apps from source code then?
Unix and Windows are different in the way approach software programming and development.
I agree with seguso. Autotools is a hideous, horrible, eye-gougingly-painful hackity-hack. scons is greatly superior.
You and I know that Python can’t and won’t replace C for countless amount of tasks. Python is good for scripting, web site stuff, prototyping and very little applications, perhaps even GUIs.
Unfortunately, Python is sluggish, memory carefree and resource irresponsible which makes it useless for the majority of computing needs that I know off, which aren’t desktop related.
Many stuff needs to run fast and not all machinery is equiped with 3GHz CPUs with more than 512MB of RAM. There are a lot more embedded device code than there are desktop application code, and all of the embbeded device code I’ve come accross are written in C and assembly. Yes, assembly isn’t dead either.
I personally, wouldn’t use Python to develop large applications because I think that will be unfair to a lot of users who don’t have powerful processors and RAM to spare. It is especially pathetic when a small gdesklet applet is consuming 40% of your CPU cycles and unreasonable amount of RAM for doing relatively nothing.
Python and C have their places, but C remains the more versatile, the most used and the more portable and will be for a good while. I’d be the first to switch to python if I could use it for the type of work I do because it is my favorite language. But today, that is just unrealistic.
The philosophies exhibited by Unix coders are extremely different from what your Windows programmer considers traditions.
Strangely enough, I think the difference is that Windows programmers don’t consider much of anything to be “traditions”, nor do they consider “philosophies” a necessary part of coding. All they’re looking for is an environment that makes their job easier.
I’ll give two conspicuous example. In Unix, many/most applications are developed using the client-server model. As a result, applications can have several user interfaces. In fact, most applications can be used in command line mode and also have a GUI interfaces.
In Windows, we have this little thing called the n-Tier architecture, usually with n = 2 or 3. Your GUI is 1, your CLI can replace it if you desire, though most CLI tiers never leave the developer’s machine, because they’re easy to implement and sometimes hard to use. Everything else is what generally makes up the “server” in the client-server model, though the n in n-Tier allows for further levels that can be on either the client or the server.
In Windows, application are primarily designed to be GUIs with no command line interface.
This is true, as I mentioned above, command line versions rarely leave the developer’s machine because they’re easy to build and rarely used by end-users. If your application is built properly, the interface and implementation are seperate, so a CLI can easily be written to do everything the GUI does.
Unix hackers store their configuration files in human readable form. So that users can configure their applications via text editors or via a graphic user interface. In Windows, configuration files are usually stored in binary format that is changeable by the users only via a GUI or the running app.
There are 2 common configuration methods in Windows at the moment. The first is the oldest, and that is the registry, which seems like what you’re referring to. The second is XML configuration files, which are a big part of the .Net push, and meet the same criteria that “Unix hackers” would consider for their configuration files. Of course, if we wanted to go further back, Windows previously had ini files, which are text and human-readable, and many developers have used their own configuration files in text formats.
In Unix hackers believe users should be able to compile, build and install an application from source code(hence the reason for Autotools). Windows programmers do not expect users to install programs from source code, but via an installer, and source code is usually never provided, but instead precompile binaries are provided.
The reason for this goes beyond philosophies: Windows programmers CAN distribute applications as compiled binaries (usually with installers). Unix developers rarely can do this unless they distribute many different binaries. It’s easier, unless you’re building for one platform only, to distribute source under Unix than binaries. When source code is distributed for Windows applications, your primary concern is what compiler and environment it was built for, and frankly I think the Windows environment sucks at source distribution primarily because it’s so good at binary distribution that no one has developed the tools to make it easy.
There are also several other fundamental differences in culture between the Unix and Windows school of software programming, which I have not mentioned, but surely, because Autotools isn’t required on Windows doesn’t automatically mean it doesn’t have to be required on Unix. How on earth do you expect millions of users to install apps from source code then?
I believe his point was that they shouldn’t have to install from source code, they should simply click on whatever file they downloaded and it should install. It shouldn’t matter whether it’s a source download or not. Complicated installers on Windows can be a pain in the ass as well, but even a simple installer is a pain on Linux.
Unix and Windows are different in the way approach software programming and development.
Yes, and the point was, in the beginning, that in order to get Windows developers to develop applications for Linux, certain things need to be in place, even if Linux developers don’t flock to those things in droves. This is the most common problem with open source software: nothing gets built if it’s purpose is to bring in people from other environments, because the current environment doesn’t like it for one reason or another, has no inherent need for it.
Fortunately for Windows developers that would like to code for Linux, the developer base that has been exposed to the types of tools that Windows developers like and expect is growing, and the projects that address those problems are improving.
Rayiner Hashem said:
>I agree with seguso. Autotools is a hideous, horrible, >eye-gougingly-painful hackity-hack. scons is greatly >superior.
However, I think root is mostly refering to the comments from windows developers.
I am no expert on windows programming. But as I remember, there the IDEs do not provide any dependence checking at all. If you are using VB or VC, there is no easy way for youto make sure that some random library you are depending on is actually there.
I believe this is also the reason why KDevelop still uses auto-tools.
I agree that auto- tools are hideous, but if one is doing unix programming, chances are he/she already knows it. So supporting the most popular tool is not a minus.
But again, I do think KDevelop should support more configuration packages.
There are 2 common configuration methods in Windows at the moment. The first is the oldest, and that is the registry, which seems like what you’re referring to.
No, the Windows registry is cyrptic. I wouldn’t describe it as human readable. By human readable, I mean configuration information is usually stored in text files that can be read, altered and understood by average users.
I believe his point was that they shouldn’t have to install from source code, they should simply click on whatever file they downloaded and it should install. It shouldn’t matter whether it’s a source download or not. Complicated installers on Windows can be a pain in the ass as well, but even a simple installer is a pain on Linux.
Linux is predominantly an open source platform and so I’m approaching issues from an open source perspective. I don’t think you can get away without providing source code for your application. In fact, source code is usually the first thing you provide the public before thinking about redistribution in pre-compiled form.
Contrary, to popular misconception, installing software on mordern Linux system is radically easier than on any other platform including Windows. The Linux installers are far more sophisticated than anything you will see on windows. The installers automatically download the required package and its dependencies, compile and build them if they are source code and installs them with little to no user input.
Yes, and the point was, in the beginning, that in order to get Windows developers to develop applications for Linux, certain things need to be in place, even if Linux developers don’t flock to those things in droves. This is the most common problem with open source software: nothing gets built if it’s purpose is to bring in people from other environments, because the current environment doesn’t like it for one reason or another, has no inherent need for it.
Fortunately for Windows developers that would like to code for Linux, the developer base that has been exposed to the types of tools that Windows developers like and expect is growing, and the projects that address those problems are improving.
The problem is that Windows developers come to Linux with Windows mentality. Logically, Windows isn’t Linux and vice versa. So when they come developing for Linux thinking you will be embraced by free and open versions of powerful tools like Visual Studio.NET, but instead what they see is Anjuta or Kdevelop, they become dissappointed.
I don’t go the Mac OS X thinking the tools I use on Linux will be same as those I use on OS X. I need to change my frame of mind and adapt a little. I don’t think Linux developers should make open source development easier for Windows developers.
I think they should make open source development easy to anyone including tom, dick and harry. And that doesn’t entail replicating a Windows development environment in Linux.
“Strangely enough, I think the difference is that Windows programmers don’t consider much of anything to be “traditions”, nor do they consider “philosophies” a necessary part of coding. All they’re looking for is an environment that makes their job easier. ”
Nevertheless they are there, even if no one speaks up about them, or calls them by name.
“I believe his point was that they shouldn’t have to install from source code, they should simply click on whatever file they downloaded and it should install. It shouldn’t matter whether it’s a source download or not. Complicated installers on Windows can be a pain in the ass as well, but even a simple installer is a pain on Linux. ”
Already addressed. Gentoo for example.
“This is the most common problem with open source software: nothing gets built if it’s purpose is to bring in people from other environments, because the current environment doesn’t like it for one reason or another, has no inherent need for it. ”
I believe the phrase your searching for is “scratching an itch” It’s been that way since the beginning. Shame that it’s now seen as a “problem”.
“Fortunately for Windows developers that would like to code for Linux, the developer base that has been exposed to the types of tools that Windows developers like and expect is growing, and the projects that address those problems are improving.”
Sounds like we don’t need to have this conversation then, if the “problem” is being addressed.
I’ve used it, it’s not the “Gold standard”. In fact, it never helped me when using VC++ 6.0. And quite frankly, g++ has a lot more user friendly errors (it checks for things that VC++ doesn’t check for until linking). Link errors are awful to figure out. For example, open VC++ and put in
#include <iostream>
int Main(void)
{
return 0;
}
The error is the “Main”, the capital M specifically. A friend of mine who was new to c++ spent a good half hour staring at a link error. I didn’t even look at his code, but tried compiling it on g++. I got a compile error, it was descriptive enough for me to go “oh duh.”
Seems so. But it still has autotools.
Yes, as I have pointed out autotools is almost the defacto standard of installing applications on Linux.
What a hassle to have a project/workspace that makes
more than one binary..
I don’t understand that statement.
Do you honestly think your arguments will “convert” the deveoplers I’ve tried this on. They have already tried the
tools and found them not to fit their needs. Its about
tool fitting people, not people fitting the tools.
Developers learn how to use tools. Tools to fit people and vice-versa. Did the window development tools magically fit their needs, or did they learn how to use them?
Its common, yes. Though most prefer to e.g. apt-get install .. (or whatever package tool that’s used.)
Anyway, who says everyone
must develop opensource apps or cross platform ones ?
Linux is an open source platform. By its very nature, Unix hackers design their application to be portable to many platforms and open.
Ideally people would install binaries that works with no hazzle(opensource or not), not have an entire development environment on their box to install apps.
You don’t need an entire development environment to install source code. You just need a tool called a package manager. That takes care of installing all your applications, be it source code or binary.
Many people prefer to install software from source code for security reasons. For example, as I security measure, I pacth all my binaries with PaX enabled features, which are not provided via binaries. My whole system is PaX enabled to prevent popular buffer overflow attacks and other memory corruption. I also enjoy optimizing my code for size. Binaries usually do not do that, so my only alternative is to compile from source. Lastly, I don’t trust people making binaries for me, again as a default security caution.
I’m very sure my father would rather point’n’ click to install an application rather than ./configure ..
Your father would point ‘n’ click to install software in Linux. Read my comment above about how sophisticated Linux installers have become.
Why ?
And what if they don’t want to learn/work that way ?
They should just be excluded ?
Developers will have their own opinion on what fits
their needs and how they are most productive. Other
than hardcore *nix developers ought to have options as well.
There is an adage that says, “When in Rome, you behave like the Romans.” Unix programming philosophies believe in simple tools that accomplish specific tasks properly and no more. So in Linux you are likely to encounter numerous, but unfortunately, scattered development tools that do one task and only one task, but that do it properly. These tools although seperate interact very well with each other. We call this modularity as opposed on monolithism.
A monolith system is when an application is designed to perform multiple functions as one unit, as opposed to seperate small tools doing one thing and doing them well. That is why the concept of IDEs will be a little different than what you have been accustomed to on Windows.
In my view python would be the greatest choice. Many still think that it is slow but projects like pyrex and pypy whose aim is to better python and help make it faster could bring python’s performance on the same performance level as java ( I might be dreaming) but there is one thing I know it is possible to port the sluggish parts of the python app to C or C++ using SWIG. So speed is no issue.
Also the AnyGUI project will make questions like having X or a CLI moot since this lib can dynamically adapt to the users environment (one app one gui just different visual representations)
Any how! I think that a proper language should be dynamic and allow fast prototyping. so I vote python, but would not mind losing to the likes of Ruby. That, might I add, are Open Source.
No, the Windows registry is cyrptic. I wouldn’t describe it as human readable. By human readable, I mean configuration information is usually stored in text files that can be read, altered and understood by average users.
I was referring to binary formats, which is what you stated Windows developers store configuration information in. As I stated, it’s the older form of doing things, and Windows developers have been developing their own text formats for configuration information before, since, and after the Windows registry. The current method being pushed by Microsoft is XML configuration files, which are human readable, at least to the extent of most configuration files used in Unix and Linux.
Linux is predominantly an open source platform and so I’m approaching issues from an open source perspective. I don’t think you can get away without providing source code for your application. In fact, source code is usually the first thing you provide the public before thinking about redistribution in pre-compiled form.
There are many applications distributed for Linux without source code, though they are far outnumbered by those distributed with source. That becomes primarily an ideological debate, and again I believe that it should be possible to distribute installation files that include the source without the mess of the autoconf and automake tools.
Contrary, to popular misconception, installing software on mordern Linux system is radically easier than on any other platform including Windows. The Linux installers are far more sophisticated than anything you will see on windows. The installers automatically download the required package and its dependencies, compile and build them if they are source code and installs them with little to no user input.
This is all dependant on the installation systems used by the individual user, and the packaging of software for those installation systems. They have gotten better since I first touched Linux 8 years ago, but they are still scattered across numerous distributions with varying levels of support. In the end, I would say that, at best, it is equivalent to the current system on Windows. Windows installers don’t always handle dependencies well (part of the problem with .Net and the latest MSI being distributed after the latest version of Windows), and you rarely know what kind of installer you’re going to get. On the other hand, in Linux you face the same problems from one application to the next, it’s just that in the worst case a Linux application’s installation can be significantly worse, and the developer has a rather heavy burden if he/she wants the application to install on multiple distributions. On the Windows side the best installations can be equivalent to the best Linux installations (and vice versa), and installing on multiple versions of Windows properly is rarely something a developer worries about.
The problem is that Windows developers come to Linux with Windows mentality. Logically, Windows isn’t Linux and vice versa. So when they come developing for Linux thinking you will be embraced by free and open versions of powerful tools like Visual Studio.NET, but instead what they see is Anjuta or Kdevelop, they become dissappointed.
I don’t go the Mac OS X thinking the tools I use on Linux will be same as those I use on OS X. I need to change my frame of mind and adapt a little. I don’t think Linux developers should make open source development easier for Windows developers.
On the other hand, the tools for OS X are very strong, and while Windows developers will complain about this or that (especially language choices), they can usually become comfortable with them. Additionally, as a Linux developer going to OS X, you’d eventually find that you can have most of the Linux development tools on OS X. Personally, going from a Linux environment to Visual Studio was at first information overload, and left me with no clue where to start. Over time, it becomes hard to go back, and I often find myself using Visual Studio to edit code even if the code will never run on Windows. Still, it leaves a lot to be desired for multi-platform development, and I end up back in the old toolset to compile and debug.
I don’t think that Linux developers will necessarily be the ones making open source development easier for Windows developers. I think that more and more Linux developers are looking to make it easier for themselves, especially as more and more of them are coming from other environments with strong IDEs, whether they come from Windows, Mac OS, or other Unix platforms. Eventually this will simply lead to it being easier for Windows developers.
I think they should make open source development easy to anyone including tom, dick and harry. And that doesn’t entail replicating a Windows development environment in Linux.
It’s not a matter of replicating the IDE, it’s a matter of building a strong development environment that fulfills the needs of the wider user base, rather than just depending on the diverse toolchain that already exists. It could be as simple as someone extending (or building onto) applications in the existing toolchain, adding a few more tools that are definitely missing from the existing set, and integrating things in a looser fashion than is found in the Visual Studio environment. Context-sensitive help, GUI design and code generation, project management, code completion, and so on don’t necessarily mean building one new environment, but could possibly be done by taking existing code and applications, including allowances for swapping out one application for another (such as the editor, compilers, debuggers, etc) in various parts of the environment.
“C sucks! Use Java!” “No, Java sucks! Use Python!” “No, Python sucks! Use Ruby!” “No, Ruby sucks! Use Delphi!” “No, Delphi sucks! Use C++!” “No, C++ sucks! Use D!” “No, D sucks! Use C#!” “No, C# sucks! Use Dylan!” “No, Dylan sucks! Use Scheme!” “No, Scheme sucks! Use Smalltalk!” “No, Smalltalk sucks! Use Oberon!” “No, Oberon sucks! Use Lisp!” “No, Lisp sucks! Use O’Caml!”
Funny thing to see in an article which stresses “To focus purely on language choice is to miss the biggest part of the picture“…
“A monolith system is when an application is designed to perform multiple functions as one unit, as opposed to seperate small tools doing one thing and doing them well. That is why the concept of IDEs will be a little different than what you have been accustomed to on Windows.”
I actually disagree with that a whole lot. its one thing for general application design, but the whole point of an IDE is to have an *integrated* developement environment. The whole point of an IDE is to have editor, compiler, and debugger all in one so you dont have to be alwas switching from one to the other. thats not to say that pure editors, debuggers, or compilers dont have their place, the definately do. While i tend to perfer the minimalistic approach to application design in UNIX, i definately want the “Kitchen Sink” approach in my IDE.
The job of an IDE is to take care of the repetitive/mundane/boring aspects of putting together an application. If anyone wants an example of how to do this properly, look at IDEa from intellij. It gives you powerful tools allowing you to automate things that any code monkey can do, allowing you to focus on the logic, the core of what you are trying to write.
Like it or not, a good IDE will improve both the efficiency and the enjoyment level of programming. While VS.NET is far from perfect, its lightyears ahead of almost everything on the UNIX side of things. Ignoring issues of technology, philosophy, style, etc, it simply makes it easier and more enjoyable to code in, which in and of itself makes windows a more attractive development platform for your average young programmer.
One last note, because people like me are at the core of this discussion. I went to a technical collage that taught java, but not c/c++. (look at the job market before making any disparaging remarks, please. for junior devs, java is the way to get a job) I have been working in java for a good two years now. Im at the point where work is sucking the enjoyment out of programming for me, and i would like nothing else then to start or contribute to an open project. Whats available to me? next to nothing. I learned C# awhile back without too much difficulty, but honestly, when you are used to java syntax, C++ is very hard to appreciate, or even learn. C is about a hundred times worse. Nevertheless, ive been slogging through it for about a month now, and all thats really left is to learn the STL better, and the various UNIX APIs.
The points to this little story:
C++ is not attractive to people in my position.
C is worse.
The odd person who has the perservearence to “take a step backwards” faces the additional barrier of learning the APIs which quite honestly could use quite a bit of work in the documentation department.
From a usability standpoint, application development tools are roughly in the poor to mediocre range of their windows equivilents.
I really want to code in linux. Most wont have the drive that I do. Personally, I love gnome. But the barriers for new gnome devs are much greater then even the equivilent in KDE.
the lesson in this story? without change, I will be the only kind of person willing to do the work to get into gnome development. People willing to get past the linux barrier but no preference in DE, will be faced with anjuta/glade/C vs KDevelop/Qt Designer/C++, and I will tell you right now, that isnt even a choice.
To assure quality it is not enough that APIs are stable but they need also to be tested and documented. To be allowed to be branded as a Gnome application, there should be unit tests and coverage tests. That way a developer that better way to implement a certain functionality can assure that his fixes doesn’t break anything.
Gnome also needs to embrace modern object and aspect oriented programming techniques, no matter what language they decide to use.
Since you are a Java developer, a nice IDE to use on Linux, GNOME, will be Eclipse. Give it a try, I think you will be impressed. Fortunately, of late, you really don’t need to know C or C++ to write GNOME applications. You have experience in Java and know a little C#, all you need to do is install Mono, MonoDevelop, GTK# on your system, and you can begin hacking away GNOME applications in Java and C#.
I think all these applications are also available on Windows. Finally, you’d be a better programmer if you learnt lower level languages like assembly and C in addition to the object oriented languages you know. Since you know Java and C#, I don’t think it is worth in learning C++, as both Java and C# are better object oriented languages. Well, just my suggestion.
You should also look into python bindings for GTK+, they are very well documented and I did see ample examples of applications written in PyGTK when last I checked. With regards to IDEs VS scattered tools, I prefer scattered tools. IDEs have a steep learning curve and are complex to master and sometimes difficult to learn, except of course you stick to one IDE for a long while. I gave up on IDEs when I figured on IDE has one feature the other lacked and vice-versa. I also believe individual tools provide more functions and flexibility than when such tools are integrated into an IDE.
When I compare GCC for example to VS.NET compiler, I think GCC provides me with a lot more options/flags and flexibility than VS.NET compiler can dream of. The same thing applies to debuggers and profilers. However, Linux is an open platform that encourages choice, I think IDEs and individual developments tools can both exist. For C projects, I find Anjuta to be the best IDE I have used on Linux. For C++, Kdevelop is king. For Java, Eclipse is almighty. I haven’t done much C# development, but I’ve heard nothing both praises about MonoDevelop, a port of SharpDevelop on Windows, for C# development.
When I have to edit source code as opposed to coding, gedit or vim does it for me. 🙂 But I’d be writing my own C “only” code editor soon, because I’m not satisfied with the available GUI text editors on Linux. 🙂 The tools are their in Unix, they are just scattered and peculiar to the Windows developer. And as with all tools, it takes time to learn and master them.
a few things. first off, i have tried eclipse. its better then anything for java other then idea (of which theres a linux port) you mentioned a few mono things too. ive actually looked at all of that, i think i didnt really make myself clear in my last post.
first off, C# is the issue that started this whole debate. whether its valid or not. c#/sharpDevelope, imho, is the future for young blood in gnome.
the thing is, i would like to join a project. my language of expertise is java. while java projects do exist, they are few and far between.
What i want to do is start with helping with something small, and work up to a full gnome app of my own. again, that is the drive of this debate, whether C# will become the “core” language of gnome.
the ide vs scattered tools thing, i would highly suggest yout try out idea (if you know java). just download the demo and play with it for half an hour or so and you will see where i am comming from. apart from being a memory hog, there isnt much not to like about idea 😉
You mention the pros of gcc vs. the VS compiler. now, say it that way and you will win hands down. but i wasnt talking about technology-wise, im talking about usability wise. gcc beats VS.net hands down. not even a fight. but VS.net beats gcc/emacs hands down, once again, not even a fight. your arguing the former, im arguing the latter, so we are talking about two different things.
gedit/vim/emacs/etc + gcc is really amazingly good for what it is, and puts most windows equivilents to shame. but again, i think i miscommunicated what i was trying to say. there are IDEs, and there are compilers/debuggers/editors. different situations call for different things, if its a 500 line app, an IDE is a waste of time and resources. if its a 5, 000, 000 line app, an IDE makes things astronomically easier to manage.
Dear Edd:
Although your article hits some right notes there are some jarring omissions … particularly your reference to languages such as VB, python, C# and not C++ … I have a feeling its because KDE has so successfully used C++ and QT to do most of what Edd is saying… look at KDevelop, to cite an example, its probably the best open-source IDE I am working with.
There are lots of other things which point to a general “hostility” towards KDE … or else why leave out a highly successful project such as that?
Just better documentation and C++.
C and C++ are in the same class of languages. What Edd is arguing GNOME needs is higher level languages and his choices: VB, python, C# are exactly the ones that fit in that category. It’s time to give developers a good solution for RAD. Developers in the Windows world are moving heavily and quickly to VB.NET/C# and we need to compete. C++ is not a solution to this problem. We have bindings for those wishing to develop in C++, but moving the whole project to C++ is not only unrealistic but also rather pointless. Edd’s article is spot on.