[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Recent positings to c.l.o
I'm not sure how many of the people of this mailing list also check
the comp.lang.oberon newsgroup. Since my recent posting there are of
interest for this mailing list, too, I also mailing them here.
Discussion of the 4 statements should happen in the newsgroup, if
possible.
-- mva
------------------------------------------------------------------------
Subject: Re: Target audience (was Beyond Multi...)
Date: Fri, 17 Apr 1998 05:34:06 -0600
Wojtek Skulski <skulski@nsrl.rochester.edu> wrote:
> [...] OOC is just a compiler [...], but I am myself voting for an
> integrated development IDE.
This is not correct. OOC is much more than that. It is
o a compiler,
o a number of tools,
o a set of library modules,
o and a reference manual.
Each of these tasks has a much higher priority than an IDE: OOC would
be useless without even one of the said categories, while it _can_ be
used without an IDE. And people _are_ using oo2c for real life work.
We, the people working on OOC, have to set priorities, where to spent
our time and efforts. There is no point to divert our scarce
resources to such a flimsy thing as an IDE, as long as there is still
work to do in the above-mentioned categories. I'm not arguing against
an IDE; it would be a nice addition on top of that what is currently
OOC. But I do not see how such a thing can materialize out of thin
air, without people setting forth to implement their own priorities.
One might also argue that GNU Emacs, together with OOC's oberon2 mode,
is a highly usable development environment. It has all the necessary
features to make the edit/compile/debug cycle efficient. Any IDE is
hard pressed to provide the comforts it offers.
Addendum:
> More seriously, like you said OOC would greatly benefit
> [...] from a runtime system, maybe similar to Oberon System and
> Gadgets.
This is true. But the amount of work to actually implement this
simple statement is currently beyond the scope of the OOC developers.
-- Michael van Acken
------------------------------------------------------------------------
Subject: Re: Target audience (was Beyond Multi...)
Date: Fri, 17 Apr 1998 05:15:16 -0600
Wojtek Skulski <skulski@nsrl.rochester.edu> wrote:
> [...] I am trying to understand why certain projects do not
> win a market share they deserve.
> [snip]
> One rather needs to identify an unoccupied ecological niche, or the
> one occupied by a sub-standard product, and then to target that
> particular niche. Then one needs to forge the development tool for
> that niche, and once the tool is sort of ready one needs to do some
> heavy advertising.
This is how product placement should be done. I agree with you here.
But I disagree with the underlying implicit assumption: we are not
trying to sell a product here. I'm not sure if Tim agrees with me, as
far as VO is concerned, but I can comment on the OOC side of things.
What OOC is not:
o OOC is no university research project. This means it isn't created
by work spent on research topics at university, e.g. as part of a
project paper, a seminar, a diploma thesis, or a dissertation.
o OOC is no product that needs to "sell". There is no inherent need
to reach a large audience. "World domination" is a nice goal, but
no one is working on OOC (or Linux) with this goal in mind; getting
to people is not the driving motivation.
What OOC is:
As I mentioned earlier, OOC is not "just a compiler". It is a project
composed of many parts. The parts were contributed by various people
for various reasons. I can only guess at the motivation behind some
of the contributions. I'm quite sure that the following factors are
in part responsible for contributions to OOC:
o interest in compiler technology (parsing, language semantics,
intermediate code representation, optimization techniques)
o interest in creating useful abstractions for the library (i.e.,
taking an idea and turning it into a set of module specifications)
o the need to have a certain set of functions implemented in the
library
o a wish to increase the value of OOC in general, e.g. to make it more
usable, or to make it attractive to a larger audience
For whatever the reason, people brought some of their work into the
project. OOC is the accumulation of the work of various people. A
unit of "work" can be just an idea, a module specification, a module
implementation, a piece of documentation, a tool, or a whole new
library.
> I think the difference between the "bazaar style" and the usual
> commercial style lies mostly in the stage at which the product is
> presented to prospective users. In the "bazaar style" it is
> permissible to release half-done products, while in the commercial
> style products need to be much more finished. (Another difference is
> of course source code availability, which is mandatory in the
> "bazaar style".)
There is another difference between commercial and "bazaar" style. A
commercial product needs to sell, which implies a certain kind of
aggression by the manufacturer. A market has to be created for the
product, often culminating in marketing hype. On the other hand, the
basic nature of a "bazaar" product is always an offer. It is
distributed in the hope that some people consider it useful. This is
of course a much more passive approach. There is no need for any kind
of marketing, because there is no need to create a market for the
product.
To take OOC as an example, I'm satisfied with a fairly prominent place
on Guy's Reference Site (which OOC has), and a fairly decent WWW page
to distribute information to interested people (which OOC hasn't).
The current OOC Home Page is a sorry affair; when we were forced to
move to a http-only server some things broke (we even have broken
links, I have to admit). Unfortunately I'm not the site's maintainer.
If you have specific ideas what information you expect to get from
OOC's home page, and how it should presented, please send mail to
jnzimmer@informatik.uni-kl.de (CC to acken@informatik.uni-kl.de).
Such an email would also be a worthy contribution to OOC ;-)
[My thanks to Wojtek for pointing out, that getting attention _is_
important after all.]
> I do not think the Linux "bazaar style" was a goal in itself. I
> rather think it was a means to achieve a goal. I think in every
> "bazaar project" one can identify two elements (1) an unoccupied
> niche, and (2) a group of people willing to invest their time to
> fill that niche.
I believe that every piece of "bazaar" software out the in the net has
its own niche. It might be small, maybe encompassing only a small
number of people beyond the primary author, but it is there.
> [...] From that point of view most niches in Oberon community are
> already occupied.
This may be true. But most of the niches are filled by code developed
as part of research projects at ETH Zuerich. As research projects go,
they are finished as soon as the diploma or dissertation thesis is
written, or the system is good enough to prove the point in question.
Nobody at the ETH is interested in creating a market for Oberon (the
language or the system). The people in Zuerich were kind enough to
offer the fruits of their research to the world.
[It is an offer, not more. People miss this basic fact, whenever
they are complaining, that the ETH is not more actively advertising
Oberon.]
In time Oberon V4 and System 3 will get stale, unless someone starts
coordinated work to develop and maintain these systems further. On
the other hand, OOC is and will be a work in progress.
-- Michael van Acken
------------------------------------------------------------------------
Subject: Re: Target audience (was Beyond Multi...)
Date: 17 Apr 1998 16:43:59 GMT
skulski@nsvs33.nsrl.rochester.edu wrote:
> Hmm, from "What OOC is" and "What OOC is not" I did not quite
> learn "what OOC is" in terms of logistics and support. This question
> is not as innocent as it may sound, because behind it is an implicit
> fear that OOC will one day disappear into the thin air, as so many
> Oberon projects did before (V4 at ETH on the university side, Unified > V4 on the community side). I know it is silly to ask about the future, > but still I would welcome a comment.
There will never be a formalized guarantee of support. Like all the
other "bazaar" style projects, OOC thrives on voluntary contributions
of people all over the world. This is no disdavantage; just look at
Linux for an example.
A "bazaar" project is as good as the people behind hit. But this
offer of support is often better than that of commercial vendors.
-- Michael van Acken
------------------------------------------------------------------------
Subject: Re: Target audience (was Beyond Multi...)
Date: 17 Apr 1998 18:43:59 GMT
Tim.Teulings@materna.de wrote:
> >Does this mean that supporting "industry standard" components will be
> >difficult or impossible? That would be bad news.
>
> Interfacing to C is - as said - very easy. [...]
OOC, and its current compiler incarnation oo2c, can interface with any
kind of C code. Interfaces to (well defined) portable packages can be
defined in a special INTERFACE module, which is subsequently used like
a standard Oberon-2 module. An example for this is the interface to
the X11 library and how it is used by VO.
System-level C code (i.e., all code taken from libc) is best
encapsulated in a FOREIGN module. Such a module is implemented in C,
but offers the standard Oberon-2 interface to any client modules. An
example for this are the low-level I/O modules (Files, SysClock, and
so on) of oo2c.
C++ is another thing altogether. While you can map any C type to a
similar Oberon-2 type, things get vastly complicated with C++'s class
types. There is no way to map all the intricacies of the C++ class to
Oberon-2, an without such a mapping you can't access them in an
Oberon-2 program. Even the best solution can probably just interface
to a subset of C++.
> >1. Portability across major platforms used in science: all major Unices,
I had reports on successful installation of oo2c for many Unix
systems: Linux, SunOS 4+5, HP-UX 9+10, AIX, IRIX, etc. If it doesn't
work, first check the file PROBLEMS in the distrib, and if that
doesn't address your problem, simply drop me a note and I'll try to
fix it.
There are no OOC ports to other OSes yet. Such a port is not
difficult, but obviously someone has to come along and do the work.
> >2. Portability in time. I am still using scientific programs and packages
>
> Its GNU. You will always have the sources, if nothing else works and
> we all get catched by marsians :-)
Excellent point. You will not get such a guarantee for any research
or bazaar project. And I would not trust such a guarantee from a
commercial vendor myself.
>
> >3. Reasonable performance. By reasonable I mean "not as sluggish as Java
>
> oo2c ist fast, surely fast enough.
Agreed.
> >4. Trust in developer team and in the product line. Difficult to quantify.
Accumulated over time. This is something you can not get before
having committed yourself.
> >5. Support for mixed language programming. Ability to call/use foreign
This can be done. With OOC you can interface to C code, and you can
turn a bunch of modules into a shared or static library to be used
from C.
> >6. A reasonable prospect that future technologies will be covered.
As long as there are people willing to do the work. Sitting back and
uttering things like "I need that" and "I want this" will not help, of
course. We are talking "bazaar" here, after all.
> >7. Avoid proprietary language "extensions" by any means! In physics
I always stated that I wanted to be OOC an Oberon-2 compiler. This
has not changed. Occasionally people drop by on the mailing list and
post wishes that would effectively turn OOC into a swiss army knife,
if ever implemented.
Note that certain things are very close to the compiler
implementation, even if the language itself isn't touched. Anything
interacting with a compiler's run-time system tends to be
non-portable: meta-programming faclities, exceptions, dynamic loading,
to name a few.
> Why not interface to CORBA or COM/DCOM. If they can be implemented
> in C we can implement them in Oberon. However there is not planed
> interface in VisualOberon for this but that can be changed.
CORBA would be nice.
> >What about the underlying communication bus? What about dynamical loading
> >like Oberon System has now?
>
> Ah, finaly. Michael can say more about this ;-)
OOC should have dynamic loading. No question. Any native code OOC
compiler could do it with moderate effort. But with oo2c and its
inherent C-sickness I'm a bit limited. I can do dynamic loading of
modules a la Oberon System, but only on systems supporting dlopen()
and on HP-UX. That is, I cannot implement dynamic loading for all
platforms that run oo2c. When there is ever a GNU DLD 4, the number
of target systems may be large enough to make it worthwhile, but at
the moment it isn't (for oo2c).
-- Michael van Acken