Hi, > > I differ, If you consider Gentoo is a modern distro, then your statement > is wrong. Gentoo as well as its childs still use openRC, not > systemd/upstart.
I used the word "Most"; not "All". Gentoo, Slackware and a couple of other distros do not use systemd or upstart yet. Having said that, on Gentoo today, systemd is just an 'emerge' away. > I still differ, People who want performance don't consider Python/Ruby. > A careful design can make scalability easier by writing it in C and do a > glue-scripting, rather than Ruby/Python. Wrong. People who want performance prefer Perl/Python/Ruby or the likes in comparison to C programs + Shell. It is obvious that you have no first hand exposure at maintaining a 25,000+ line shell script (which I did in the late 90s) - so you have no clue on what I'm talking about. As an exercise, try writing a Linux installer and package manager with features and capability of Redhat's installer (anaconda) and their package manager (RPM/YUM) using just shell scripts and existing bare-bones Linux tools (tar, cpio, bzip2, etc). You'll understand immediately why people chose Python/Ruby over shell :-) > > I'm not an architect who can talk about scalability/performance of a big > or enterprise level application, just an amateur programmer, but in my > opinion, whatever complex the problem, a well defined split-up and > writing tools for each split can scale whatever level we want. I am a technology mentor - and I train architects on how software must not be built in the first place. I can talk at length about scalability modelling. In the 80s and early 90s, traditional UNIX paradigms emphasized on splitting complex problems into smaller problem sets that could be addressed by carefully written tools and utilities in C and then glued-up together using the shell (just like LEGO(tm) building blocks). This worked well during at that time. But the problem with shell is in its architectural design - it was never meant for solving complex problems - the overhead of forking multiple process (to run different programs), its lack of built-in functions for rich data-types (hashes, objects, resizable vector-based arrays) and algorithms (map, reduce, sort, search), and its extensive dependency on external tools and commands (like cut, grep, sed, etc) for trivial tasks makes it slower, unintuitive and unattractive for solving "complex" problems. Today, we have a better design - rather can creating hundreds and thousands of binary programs using C, we have most performance-critical and low-level functions written in C and bundled into libraries. And we use smart programming languages like Python/Ruby/Perl that wrap these libraries as extension modules. That's how Python/Ruby/Perl perform better and are more scalable. For example, a python program made up of Python + C library extension is a lot faster than a shell script made up of Shell + C program binary (as there is no fork-dup-exec involved in the former). > Want a proof? just look at git. It doesn't suck!! Git doesn't suck as long as you are happy with what it provides. There's very little scope for customizability here. Every time I tried implementing a workflow radically different from what git provides, I end up yelling out what Git really meant - "Goddamn IdioT" (as per Linus Torvalds, the creator) and move on to mercurial. > because it was not > written in Python/Ruby, its a bunch of C programs which can be used as > commands in bash (as well as in any language). And that's why it is rigid, non-flexible and expects you to learn umpteen commands to manage your source code eventually. > what you say about this? with your so called Python/Ruby scalability? Mercurial is written fully on Python and it is way more scalable and fully customizable than Git. For example, writing trigger rules for mercurial expects you to only know python and mercurial library interface. In comparison, git expects you to know umpteen commands, shell and a plethora of not-so-portable utilities like inotify on Linux - that's not what you call scalable. Mercurial has proven to be much faster than git for large-scale commits and I have personally benchmarked both myself on server deployments. For your reference, look up the following link: http://draketo.de/proj/hg-vs-git-server/test-results.html Ubuntu community folks will tell you how bazaar is as fast as (or better than) git - and that's written in Python too. The beauty of well-designed software lies in its extensibility to solve problems pertaining to the user domain. Lesson for you: merely writing an "application" in C does not make it any faster. In most cases, it is counter-productive as it does not emphasize reusability. Good software design principles revolve around using C/C++ to address problems related to system domain - that could be extended as libraries by programs written in Python/Ruby/Perl/Haskell/Java or any high-level language that allows application developers to focus on problems related to user domain. And yes, get this out of your mind that C is all about "high performance". Performance, Scalability, Maturity and Maintainability depends *not* on your choice of programming language - but rather the software design and architecture. > > Just my opinion, it doesn't mean, all applications in the world should > be written in C. but, I'm saying beautiful applications are all written > in C. Beautiful applications can be written in any language - Ksh, C, C++, Java, Python, LISP, Ruby, anything. Right design and right tools for the right job is what matters. As another exercise for you, try solving the algorithm problems on http://projecteuler.net/problems using C (with standard C libraries of course). Then, try looking up solutions for the same problems solved using Python, Haskell, Ruby, Perl (and more languages if you wish) and now prove to us that C programs are beautiful than Python/Ruby/Haskell programs ;-) In return don't ask us to demonstrate an OS kernel developed using Python/Ruby. That's not what high-level languages are meant for, BTW. -- Chandrashekar Babu. http://www.chandrashekar.info/ _______________________________________________ ILUGC Mailing List: http://www.ae.iitm.ac.in/mailman/listinfo/ilugc
