Date: Mon, 22 Dec 2014 07:31:22 +0530 From: Mayuresh Kathe <mayuresh@kathe.in> To: Polytropon <freebsd@edvax.de> Cc: "William A. Mahaffey III" <wam@hiwaay.net>, freebsd-questions@freebsd.org Subject: Re: posix has been rendered useless, isn't it? Message-ID: <20141222020121.GA848@aio> In-Reply-To: <20141221194937.aebe7233.freebsd@edvax.de> References: <20141221155635.GA1388@aio> <20141221175658.3d574a88.freebsd@edvax.de> <549705CE.1050108@hiwaay.net> <20141221182108.GA860@aio> <20141221194937.aebe7233.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141222020121.GA848>