posix has been rendered useless, isn't it?

[Polytropon]

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, ...