Question

Is the UNIX way of problem solving (combining small, simple (but robust) programs to perform complex things) still relevant these days, where we do most of our things in monolithic IDEs and GUI applications? The UNIX tools themselves have become quite complex themselves :(

Answer 1

In many ways, they've simply been internalized. Where we used to have simple programs, we now try to have simple modules in our software. They're tightly coupled into one program, but ideally designed to be reused outside of that program. Is this better or worse? Who knows.

Additionally, it's worth mentioning that there are a lot of people who are advocating a similar approach to web development: creating simple services that talk to each other, where the UI presented to the user talks to all of these services in the background, typically via the same HTTP or something more efficient.

Answer 2

If you haven't already I suggest you read "The Art of UNIX Programming" by Eric S Raymond.

The philosophy of programming for UNIX which Raymond espouses and many programmers have tended to follow is that one should write small, robust programs that do one thing really well then link these together to achieve the desired end result. There are a number of advantages to this approach, key ones being that you don't find yourself having to re-invent the wheel (if someone else has already written something to do one step of your process then you can just use their program and slot it into the sequence) and if a better programme comes along to do a step you can swap out the old on and slot in the new one.

If you looked 'under the hood' of many modern 'monolithic' programs you would find that in reality this philosophy still continues. Quite often the GUI will simply assemble the command line to use the existing small, robust programs that do one thing really well, run that command line behind the scenes, capture the results and present them to the user.

As shadowfiend indicated even if all the code for a programme is contained within it there is a good chance that it will be designed for use outside that programme. Often the bulk of the code for a programme will be in reusable libraries, which may be internal or external to the main executable. Presuming your dealing with some sort of open source (or can buy a source code license) you can obtain a library that someone else has written that does something you need and call it as part of your processing. A key tenet of Object Oriented Progamming good practice is reusing code, by packaging it into libraries of high level classes that other classes can inherit from the basic philosophy of writing something small that does one thing very well and linking it with other similar programs (classes in this case) to achieve the desired result (albeit in a quite different way).

This cxan vbe seen in even more graphically based programming environment where controls are dragged and dropped onto forms. The programmer can buy or download for free controls that do the function they want (e.g. why bother to write a calendar control when there plenty of reallyh fgood ones out there), drop them onto a form, hook them up to other controls and their own code then hit compile and there's their program. If they find a better control to do what they want they can often just remove the old control, drop in the new, recreate the links and hit compile again without havign to go back and rewrite their entire program.

Answer 3

I guess the UNIX way is still alive and beating :-D