Date: Sun, 21 Dec 2014 19:49:37 +0100 From: Polytropon <freebsd@edvax.de> To: Mayuresh Kathe <mayuresh@kathe.in> Cc: "William A. Mahaffey III" <wam@hiwaay.net>, freebsd-questions@freebsd.org Subject: Re: posix has been rendered useless, isn't it? Message-ID: <20141221194937.aebe7233.freebsd@edvax.de> In-Reply-To: <20141221182108.GA860@aio> References: <20141221155635.GA1388@aio> <20141221175658.3d574a88.freebsd@edvax.de> <549705CE.1050108@hiwaay.net> <20141221182108.GA860@aio>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Dec 2014 23:51:09 +0530, Mayuresh Kathe wrote: > On Sun, Dec 21, 2014 at 11:39:26AM -0600, William A. Mahaffey III wrote: > > On 12/21/14 10:56, Polytropon wrote: > > > On Sun, 21 Dec 2014 21:26:37 +0530, Mayuresh Kathe wrote: > > >> i have been studying the unix way of doing things, > > >> i.e. tool-chaining to combine small programs for > > >> accomplishing a solution. > > > A noble goal. > > > > > > > > > > > >> but, almost none of today's servers built for any > > >> of today's unix-like systems adhere to the unix > > >> philosophy. most of them instead, are large > > >> applications. > > > The creation of monolithic applications can be a > > > problem sometimes. It's often being accellerated > > > by GUI paradigms where "one big program" is, often > > > on the basic of object oriented programming (and > > > the typical misunderstandings and misconceptions > > > of that orientation), being "required" - you simply > > > cannot easily apply the UNIX principles here. > > > > > > > Correctly applied OOP is (kinda) an extension of the UNIX philosophy > > .... Well designed/documented/implemented objects can be assembled into > > useful (compiled) programs readily & quickly. Incorrectly applied, or > > crappy objects & you have a mess .... > > > > somehow, tightly coupled 'oop' implementations, eg. c++, ada, etc. > don't feel like an extension of the unix philosophy, infact, they > give a feel of being at the opposite end, the 'vms' philosophy. > on the other hand, loosely coupled 'oop' implementations, eg. obj-c, > java, etc. are quite in tune with the unix philosophy, of having > each object doing it's job and doing it well, and communicating with > other objects by passing messages. > > in that case, would you say that tightly coupled 'oop' systems > exhibit incorrect application of 'oop'? I would not insist on attributing that to a specific OO language. As with most languages, which are tools, they can be used properly (solving a problem and reaching a goal), as well as improperly (creating a mess, bloat, incorrect programs, equivalents of spaghetti code and so on). Especially in the realm of "enterprise software", you often see all the downsides of OO crammed into one "business solution", traditionally written in Java or C#. Some OO languages seem to encourage bad programming behaviour as well as wrong design decisions which then have to be carried out by code monkeys. Luckily, you can still follow UNIX principles with well-written OO programs and wise design decisions - you just don't find them in the "enterprise world" very often. Another problem that's not just resticted to OO, but often found in programs implemented in a OO language, is the accumulation of layers of abstraction, the recursive relying on libraries. If you're not familiar with what I try to show as an example of "how not to do it", visit "The Daily WTF" and see the "Code Snippet of the Day": http://thedailywtf.com/series/code-sod There, where less brain is involved, often is where the big money is. ;-) However, I didn't want to say that OO is something bad per se. It has its places and advantages, but like all tools, there's no "one size fits all" kind of solution. In my opinion, the language for implementation does not matter so much, but the implementation itself does. Of course, Java requires a specific bytecode interpreter as an additional layer, whereas programs that compile to native machine code do not need this. The problem that the resulting machine code is machine and OS dependent can be fought with POSIX - compilation is possible on other POSIX systems. > apologies about veering off the list topic, but, i am working through > the design for a combination of compiled, loosely coupled objects using > any language, working across architectures and over heterogenous > networks. and yes, that system is a far cry from being called 'oop'. You're aiming very high - but don't understand this as a try of saying "you're doing something impossible". I whish more programmers would try to write programs and modules that can be easily combined and connected, and being _used_ on many platforms without source code alteration. > would such a system, in theory, be made to run atop the freebsd kernel > and do away with the 'posix' layer? yes, but the question is whether > it would get accepted by the community at large. POSIX isn't a layer, it's a set of specifications which is implemented in certain parts of the system, for example, the shell ("POSIX shell") or the system's standard C library ("POSIX library"). Getting rid of them would make interoperation and compatibility very complicated. A partial re-implementation of POSIX requirements is, in my opinion, worse than no imple- mentation at all, stating "this system is not POSIX- compatible" instead of claiming it is (or for the programmer, assuming it was). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141221194937.aebe7233.freebsd>