On Thu, Nov 17, 2011 at 9:36 AM, Michael Clagett <[email protected]>wrote:
> A couple thoughts --
>
> First of all, as far as I can tell Factor is one big shared library; so
> much of even the core language is implemented in library code that this is
> truer for Factor than it is for many languages one encounters.
>
I see.
>
> That brings a cost, however, as I've seen up to this point. It
> distributes responsibility for documenting behavior across a community that
> like most communiteis is uneven in its fulfillment of responsibility. The
> greater the dependency on "just read the code to figure out what's going
> on", the greater the barrier to entry to newcomers. I have talked to more
> than one such person who has come to take a look and turned away for this
> very reason. The power and flexibility is tremendous, no question. But
> power and flexibility aren't always the only thing you need.
>
> As a development manager managing a group of about eight individuals, I
> have to say that one of the benefits of operating systems and runtimes like
> .NET and Java is the shared vocabulary they give a team to develop working
> practices and patterns. The value of this obviously varies from situation
> to situation, but the greater difficulty that Factor and other flexible and
> extendible vocabulary-based development platforms can bring with them in
> terms of achieving standards and discipline is a concern that to me is very
> real and potentially limits the scope of their adoption. Maybe it was
> never intended that Factor become a mainstream language suitable for use in
> primarily team-based environments and perhaps I am applying a standard to
> it that is not appropriate. But wouldn't it be nice to have a platform
> that offers the power and flexibility of Factor that also plays nicely with
> OSes and other runtime environments?
>
The idea I had in mind is that there could be a system where the vocabulary
*is* the OS.
In this system, a program would just be a regular word in the vocabulary.
It is similar to the idea in TCL that "everything is a command".
Imagine in this system, there are two commands, "cat" and "more", like
their unix equivalents.
The "cat" command is composed of sub-routines, which are also regular words
in the vocabulary.
Assume that we don't want "more" to just be a wrapper of "cat".
We may want "more" to also be able to access the sub-routines of which
"cat" is composed.
This is easy, since the code for "more" can import the namespace of "cat",
and access its sub-routines.
I'm not sure whether "cat" and "more" actually share any code in normal
unix.
This is a naive example, of course.
I'm wondering, though, whether there is any reason why a complete OS could
not be written in Factor or Forth.
Also, I was thinking about how it is sort of fascinating how different
software realms are converging.
The similarity of Factor and Forth is interesting.
Is this a deliberate choice of design? Is it also a sort of natural
inevitable convergence?
Is there a similarity between the Factor vocabulary and the apt-get package
system of Linux?
Both give you a giant list of stuff you can do with the computer.
It seems like a vocabulary is somehow more general than a package-list.
Then I wondered if a package-list could be replaced by a vocabulary.
Then the vocabulary would *be* the OS, and the listener would be the
command-line.
Someone pointed out to me before that this idea has long existed in Forth,
for special-purpose architectures.
I am just thinking out loud about doing the same thing on a modern PC.
- Leonard
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk
