On Fri, 2010-10-22 at 17:08 -0400, Andrew Henderson wrote: > > Be careful. Those pennies come at the expense of dollars spent > developing, debugging, and maintaining. Being clever always has its > price. There are times when your hand is forced to develop for > performance, scalability, and/or minimal resource usage.
Unfortunately the opposite is the case. Developers saved time, at the expense of every Gentoo Java users, or Gentoo user in general in some cases. Much less the green factor, cpu cycles wasted, system memory, users time wasted, etc. Case in point, several former Gentoo developers have started their own distro called Exherbo[1]. The official package manager for Exherbo is Paludis[2]. Also available on Gentoo, but not the default or official Gentoo Developer maintained package manager. Paludis is written in C++, and uses a big fat bloated library I hate called boost. However I do have to commend them for using C++ and not Python. Which Gentoo's official package manager, emerge and related tools are all written in Python. Paludis does scream in comparison to emerge, and has tons of features not available else where. Though since most all ebuilds invoke other command like java-config written in Python. Even with Paludis as the package manager, you still have other delays, and inefficiencies. Only reason Paludis ended up as C++ and not C was manpower. http://paludis.pioto.org/faq/general.html#cplusplus I wouldn't dare bother asking them why Paludis is not in Python, like emerge ;) > Often though, it comes down to deadlines, functionality, and > maintainability instead. There is also the lazy factor. Or this is what I know and am proficient in. Or this is the latest and greatest new thing/language, despite others being around for decades. Or the machines are so fast, so many resources to spare, the developers do not care about waste. Keep in mind this is FOSS, deadlines have no relevance really. Functionally, you can do just about anything via any language these days because of wrappers. However wrappers must be kept in sync, and can break when things that they wrap change. Not to mention wrappers add layers to things. Even if layers do not effect performance, they rarely come with reduced overhead, as they are a layer above another. Maintainability, is some what logical. However you can end up with an easier to maintain mess, a nice oxymoron. Its easy for people to learn, code, and therefore create and leave a mess behind for others to maintain. Which is what I am finding and dealing with all over the place. More times than not it seems things must be rewritten from scratch, rather than trying to maintain what exists. But it all depends on the application, size, use, etc. > But if you can make something faster or more efficient and you can spare > the time, energy, and resources to make it happen, go for it! Well I am using this in part as a learning process for me to get more familiar with C, and GNU standards for application development. As for spare time, and resources, not really but one must do what is required to push themselves forward. If I can push other things forward, like improve Gentoo's Java tools in the process, all the more better :) If nothing else will save me time, as I do not plan on migrating from Gentoo to another distro any time soon. I still mostly code in Java, so end of day, will save me time. Not to mention address a pet peeve of mine. Slowness of things has been bugging me for some time. 1. http://www.exherbo.org/ 2. http://paludis.pioto.org -- William L. Thomson Jr. Obsidian-Studios, Inc. http://www.obsidian-studios.com This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. --------------------------------------------------------------------- Archive http://marc.info/?l=jaxlug-list&r=1&w=2 RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml Unsubscribe [email protected]
