From owner-freebsd-questions@FreeBSD.ORG Mon Dec 22 02:06:29 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 70170873 for ; Mon, 22 Dec 2014 02:06:29 +0000 (UTC) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 206DE303D for ; Mon, 22 Dec 2014 02:06:28 +0000 (UTC) Received: from mfilter20-d.gandi.net (mfilter20-d.gandi.net [217.70.178.148]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id BA7CF172070; Mon, 22 Dec 2014 03:06:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter20-d.gandi.net Received: from relay4-d.mail.gandi.net ([217.70.183.196]) by mfilter20-d.gandi.net (mfilter20-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id P4H5RjzoaUU7; Mon, 22 Dec 2014 03:01:26 +0100 (CET) X-Originating-IP: 120.60.157.47 Received: from localhost (triband-mum-120.60.157.47.mtnl.net.in [120.60.157.47]) (Authenticated sender: mayuresh@kathe.in) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 10855172077; Mon, 22 Dec 2014 03:01:24 +0100 (CET) Date: Mon, 22 Dec 2014 07:31:22 +0530 From: Mayuresh Kathe To: Polytropon Subject: Re: posix has been rendered useless, isn't it? Message-ID: <20141222020121.GA848@aio> References: <20141221155635.GA1388@aio> <20141221175658.3d574a88.freebsd@edvax.de> <549705CE.1050108@hiwaay.net> <20141221182108.GA860@aio> <20141221194937.aebe7233.freebsd@edvax.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141221194937.aebe7233.freebsd@edvax.de> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "William A. Mahaffey III" , freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 02:06:29 -0000 On Sun, Dec 21, 2014 at 07:49:37PM +0100, Polytropon wrote: > 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. would you be in a position to suggest ways in which one could have a c++ program follow unix principles? yeah, you could just write a set of tools and utilities which can communicate via a text stream and hence can be toolchained, but then, c++ ends up becoming nothing more than a better c (which is what it was originally designed for), i.e. without using a object hierarchy. > 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. ;-) this has to be funniest quote i have read. so very true. :) > 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. yes, i agree, posix does bring in those advantages. > > 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. actually, i have been working to solve this problem for the past 2 years. been studying various systems approaches including the tiny virtual machine one (as in java), but it's only now that i have started to gain clarity about a possible, native components based solution. should take me another 18 months to get ready to present my ideas (coherently) to a wider audience. then, would this be the right forum? > > 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). i am looking to eliminate exactly those things like; shell, toolkits and library derived from the posix specification. i don't have any personal animosity towards posix, just that i find it to be either an overkill, or unnecessity for my kind of design. my biggest problem was in trying to find a compiler infrastructure, but i believe, 'llvm' does give me all that, and that too in a way i expected to get. best, ~mayuresh