2007-02-24 01:25:48 UTC
Disclaimer: in my email there few topics (like JStyx or ACME) discussing
which may ease result in flame war. I don't try to start flame war here,
so please if you really-really wanna say "you wrong!" to me please use
email instead of maillist. These topics isn't related to main idea of this
there can be somebody ported vi?Few years ago I also asked these questions... and lack of satisfactory
i want mplayer, any more :-)
i want mplayer, any more :-)
answer result in forgetting about Inferno for next few years.
Maybe it's only me (and few my friends who also interested in Inferno) so
stupid, so we unable to understand What Is Inferno... but I think there
can be a lot of people with similar problem.
For me, "AHA!" happens few days ago, when I realized:
---> Inferno _ISN'T_ OS, it's environment! <---
Sounds strange, year? Especially after "Inferno is a compact operating
system ..." stated in first sentence at
Nowadays when people hear "OS" they start thinking about Windows or Linux.
Many also know "OS" can be for desktop and for server. But Inferno doesn't
look feature rich enough even for server OS. So, people compare Inferno to
Windows/*nix, and decide it's wonderful, amazing, but "toy" OS, unusable
for them right now... maybe later, when bash, apache, mysql, perl, vi and
mplayer :) will be ported... 4 years later we come back and... found
nothing is changed! Still no apache/mysql/etc!! WTF?! ;-)
My own "AHA!" can be described this way: Inferno isn't OS, it's more like
usual service/daemon, which serve Styx protocol and make resources of
host OS available for network.
BTW, that answer my old question: why there is no independent Styx
protocol realization on every popular language for every popular OS
yet - because they don't needed! I know, there one attempt do to this
for Java - JStyx project, but I suppose it authors just misunderstand
What Is Inferno like me and that's main reason why JStyx was born.
(If JStyx authors reading this and disagree - that's ok, it's just
my supposition and I may be wrong.)
This is was very simple, and probably not really correct "AHA!", but it
immediately changed everything: I stop feeling frustration about lack
of features in Inferno, I already have bash, vi (with syntax highlight for
limbo!), mc, mplayer and everything else I need for comfortable
development for Limbo/Inferno!
BTW, few years ago I've spend about 1-2 weeks trying to understand
ACME philosophy and learn how to use it... Lack of syntax highlight,
IntelliSense-like autocomplete (or even Vim-like word autocomplete),
3-button mouse requirement (my 2-nd button is wheel, and it isn't
comfortable to use it as usual button -- and I never see real
3-button mouse in shop in last ~10 years), using only part of screen
for editing source code (I prefer full-screen apps and hate window
philosophy)... Probably acme is just 'not for me', don't know.
Also, I must say, mouse-oriented interface is slow, even in acme!
Using key combinations like in Vim is much, much, much faster...
Today, after few discussions in this maillist and my own tests, I'm going
to change my mind this way: maybe it will be more correct to compare
Inferno to programming languages, like Perl. In both cases I should write
program, it will be compiled into bytecode, and then executed in virtual
machine. My program will have access to some high-level abstractions and
low-level (host OS) syscalls. So it can do virtually everything, and
probably with comparable speed! Only different things between Perl and
Inferno is environment with which I should interact while coding:
- Perl provide "more than one way to do it", a lot of high-level things like
structural, object-oriented and functions (map, grep, sort, etc.) styles
or programming, scalar variables and no type checking, and a lot of other
things to make development pleasant.
- Inferno provide very simple and elegant environment, hiding from me all
horrors of POSIX/Linux kernel/Glibc architecture and realization.
Also, I hope, it provide me much better control over resources spend by
my application (perl not just "eat" memory, it DEVOUR it! :)) without
forcing me to coding at too low level: free() memory, constructing
strings from arrays of chars and calling function every time I need to
concatenate or compare strings, etc.
I say "Inferno is like Perl" just because to use it I should know HOW I
can use it or What Is Inferno. For example, I need to develop some app:
fetch webpage from server, find all urls on this page and check is these
urls alive/exists. I can use perl/linux or limbo/inferno for this task.
Probably size of code, development speed and execution performance will be
comparable. So, only difference for me will be environment: choose
feature-rich and flexible perl together with ugly linux architecture or
not-so-feature-rich, but simple limbo with amazing inferno architecture.
If I'm developing complex regex app, I probably choose perl, because it's
regex much more flexible than inferno's. If I'm developing application
more tied to low-level linux architecture (complex I/O client/server).
Of course I don't really think Inferno isn't OS - it's OS!
Of course I don't really think Inferno is just another programming
language like Perl or Java.
I use these assertions just to detect some boundaries of unusual Inferno
- is I must use Inferno's browser, shell and text editors, or I can
edit .b files using mc and vim, and run wm/wm only when I need debugger
- is I should use Limbo only for development distributed application
or I can use it for most of other applications where I previous used
- etc. (I expecting more "AHA" soon ;-))
RESUME: Probably Inferno documentation/website lack one very important
document, which made 100% clear What Is Inferno and for which (real!)
tasks it has sense to use it instead of another existing solutions.
What is strong and weak sides of Inferno, which limitation it has, etc.
Examples of tasks very suitable for Inferno (which use most strong and
less weak sides of Inferno), and examples of tasks not suitable for
Inferno is a tool. Very amazing tool. But to use it this isn't enough.
To use it we should know for which real tasks we can use this tool,
and how it compares to another tools (for these tasks).
I.e. when we've a task, we should be able to realize: that task is better
to develop using Inferno!
Sorry, looks like I'm repeating... time to stop writing. ;-)