All the examples and the explanations use a binary choice question for the election. The explanations mentioned the possibility of multiple question ballots, but the possibility of having three or more possible answers for a question wasn't raised (and the classification of ballot papers as either "inverting" or "non-inverting" would seem to make it difficult).
Is this a trivial extension to the protocol, or something that just isn't possible? Multiple party elections aren't that unusual!
It's hard to see a serious advantage given us by replacing our ^S (or ^XS or Command-S or even:w) with a middle-click on the word "Put"
From a user interface standpoint, one obvious advantage is that of
affordance. Any text in
acme affords the command of that name. Command key combinations are hidden
out of sight - "Put" is visible and evident, as are "Undo", "Redo", etc, etc.
And when TFP cheerfully described how Acme doesn't have an internal concept of global search and replace but rather relegates those to tool commands that one pipes together, I was certainly impressed. Just, you know, not in a positive way.
Actually, that is one aspect that has changed since the paper - sam-style editing commands are now built in to the editor.
Unlike any modern text editor within Windows or Linux, (and to be fair many people
here are talking about vi (1976) and emacs (1984) here) acme is an integrating environment. Second-by-second, you build little operations to help accomplish your goals. Along the way, you can use throwaway (or more permanent) shell scripts to help with any more complex operations. For example, run any program that prints a file name - the name is then
immediately available for use; right-click it, and up comes a window to edit it; middle-click
it to execute it; give it as an argument to a command by typing the command name in front of it.
The unix command line uses text as a powerful representation medium - acme makes it more powerful still by making all that text amenable to the editor commands, avoiding the restrictiveness of the command-line.
Seriously, it's based on a 1995 paper and with all due respect, it looks 1995 as well.
The prettiness of the user interface has absolutely nothing to do with how useful, usable or life-enhancing a program is...
Re:Aw, you gave up way too soon
on
Acme for Windows
·
· Score: 1
The scrollbars do require one to RTFM (I remember being very confused the first time I encountered them) but actually make a lot of sense. The middle button works similarly to using the left button on a conventional scrollbar. The left and right buttons scroll up and down relatively.
The further down the scrollbar you click them, the further the movement. Clicking near the top moves line-by-line; clicking near the bottom moves page-by-page. Once you're used to it, it's a very efficient UI design - no moving the mouse to point to little clicky arrows.
Wait till you get to the bit where you middle-click and drag over a word to run a command (because pressing a couple of keys just wouldn't require enough dexterity!)
For any one-word command you don't need to drag over the text - just click anywhere in the word (this conveniently excludes execution of the many unix shell commands that require an argument in order to be dangerous, e.g. rm). Alternatively, you can select the text at your leisure with the left button, and then click with the middle. I have to say that as a confirmed acme user who is also fairly cack-handed, I always do it this way, rather than
dragging out text with the middle button.
you have to guess whether it will consider the 'command' to be a unix shell command, an internal editor command, a Plan 9 filesystem path...
Well, since you've chosen the text yourself, presumably you know what you want it to do. And it's not too hard - there are only a small number of internal editor commands, and they all begin with a capital letter (e.g. Del, Undo). There's no distinction between shell commands and filesystem paths beyond where the shell looks for the executable. So
ls differs from/usr/rog/bin/blah but the difference is obvious!
The only glimmer of RSI problems I've ever had came when I was using a keyboard interface which required much use of Control- key combinations. I find using acme very comfortable. I get the feeling (and this seems to support the idea) that gesturing with the mouse uses a different area of my brain from the creative/analytical processes that I'm working on. For me, this makes for a very relaxing editing experience - most editing processes happen as directly as if I'd reached out and used my hand. This might help with RSI or not - but as far as using the mouse goes, it's like using your hand after taking a boxing glove off!
If you're editing over a remote link, it really depends how limited you are in the protocols you can use. If you've only got telnet/ssh, you're probably screwed. If, however, you can run something on the other end, then you've got a world of opportunity, as this (remote access) is the kind of thing that plan 9 and inferno excel at. Using a straight telnet/ssh link these days makes me feel like I've got one arm tied behind my back.
For using acme remotely, the best option is to run something, for example u9fs to export the files you wish to edit, then import the filesystem, whereupon you can use acme to edit the files in it. It's also possible to run acme remotely, (by using inferno or drawterm and making a cpu connection), but the graphics speed will then be predicated on the speed of your connection, which can make this unrealistic.
I used vi for about 10 years and thought it was great. Then I started using acme. There's definitely a learning curve, but I've been using it constantly for about 8 years now, and I now find it really frustrating if I have to use anything else. The fact that the output of any command is text that can be used to drive acme itself is amazingly powerful. It also has sam'sstructural regular expressions which, combined with arbitrary undo/redo make it easy to figure out a way to make almost any kind of regular change to a large text file. If you can't, there's always the entire shell's command-line power only a middle-button click away.
One thing that I think people find hard to understand about acme is just how powerful the mouse actually is. By assigning universally applicable actions to each mouse button (select, execute, look), and giving it the entire window contents as its domain (almost any part of which is user-changeable), the mouse is no longer something that must be moved in order to let the keyboard do something, but an expressive tool in its own right. Add mouse chording to that, enabling cut, copy and paste of arbitrary pieces of text with no keyboard input necessary, and it's the keyboard which is more seldom used. I've looked over the shoulder of developers using acme to edit and debug software and seen 20 minutes go by without the keyboard being used once! And in that time, programs have been run, projects built, and many source files browsed and edited.
It's not something that can be fully appreciated until you've used it for a while. But once hooked, you won't find anything to beat it.
However, [Occam] really blows the socks off any other programming language out there, feature-wise.
I used Occam for a while, and I'd have to disagree... it had many nice aspects, but feature-wise it lacked (for a good reason) some of the most useful features around. In particular, it didn't have any dynamic memory allocation at all. This meant that it was easy to statically prove properties of an Occam program, but... no dynamic data structures really cramps your style!
The really nice thing about Occam was the concurrency. Ultra lightweight processes
(zero context switch time) and CSP-style channels were just great. That's why I was so happy to play with Inferno's Limbo, which takes these features (well ok the context-switch time isn't precisely zero, but it's pretty darn quick) and adds full dynamism and a really nice syntax. Programming GUI and networky kinda stuff in Limbo is a dream - it's amazing how elegant and useful concurrency can be when you have the right set of primitives. Most "threaded" languages make it gratuitously hard.
Re:Looks interesting, but does it fold?
on
Acme for Windows
·
· Score: 1
Folding sounds nice in principal, but makes it very easy to write terrible code. I worked with someone who used a folding editor - we wrote a reasonable sized (50000-ish lines) project together. The problem was that the folding makes it trivial to copy a block of code, say 300 lines, change a few lines of it and have it almost invisble. A fold containing 3 lines looks identical to one containing 10000.
When 90% of the code is tucked away behind n levels of fold, it becomes hard to see exactly what's going on. The conclusion we came to was that if you need to fold code, then
it should be broken down into smaller functions, which is good for internal modularity, and helps to maintain nice looking and understandable code overall.
You have different levels of freedom at each level of the system. The designer makes a choice as to how much freedom you have at any moment. Of course you want all the power available, but that doesn't mean that it should all be available at any one point - there just needs to be a path to get there.
What this means is that a well designed user interface implements something akin to Huffman encoding with respect to user-input and resulting actions. Common actions should be encoded with short/easy input sequences, where less common actions can be encoded with something more verbose.
For instance, a digital camera might dedicate a whole button to just taking a photo (1 bit), but require accessing a menu interface to delete a photo. Writing a new script, or combining UI elements is perhaps the equivalent of introducing a new node in the encoding tree.
A well designed UI anticipates likely patterns of user action and makes their encodings small (but hopefully consistent with the rest of the system). This is inevitably a personal thing, as everyone has different actions they wish to perform.
For instance some Nokia mobile phones have a great UI for me - most common actions just take a single button-click - the context is all-important.
No, the computer can't read your mind, but the designer can, to some extent, by looking at the problem domain and extrapolating from empirical facts about human nature. I completely concur with the original author, and I can entirely see why many people get frustrated with modern software.
Ok, so I've got a non-standard web browser. But it complies with older web standards, and works just fine with Google, and much of the rest of the WWW.
Why, oh why, does Microsoft have to rely on Javascript for this page, when a simple HTML form would do?
Re:Mod parent up - there is no "grid computing"
on
GGF and Grid Security
·
· Score: 1
Interesting article, thanks. My favourite quote from it:
...low technical barriers to entry...
I had to laugh. Web services are so ludicrously complex that unless you use loads of existing (complex and platform-specific) software, the technical barriers to entry are remarkably high! I've implemented some web services stuff from scratch, and it's really not easy at all. The WSDL standard drags in many other standards.
Just for a laugh, I started to try to enumerate the standards referred to, directly and indirectly, from the WSDL. I ran out of time after getting two levels deep, but already the referred-to standards totalled 4.8MB (approx. 103000 lines)! And this is a "low technical barrier to entry"?!
This enormous complexity is simply not necessary to make a decent, general-purpose framework for program accessibility and interoperability. As an example, the Styx protocol is general purpose protocol that actually does considerably more than web services, but it is completely documented in under 42K (just over 1000 lines). It references only one other standard (UTF-8), (one that I didn't include in the above count for WSDL, even though it was referred to there). You can knock up a client or a server from scratch in a couple of days. It's light-weight enough that it can be implemented on tiny devices, such as the Lego brick.
Hence my initial question. What is it with all the web services stuff?
But I don't agree that it's superior to Java's way
Actually, it's demonstrably superior to Java's way, as Java doesn't maintain the Liskov Substitution Principle. With no subclassing, Limbo doesn't have this problem.
I wouldn't say that Limbo's way was superior in the same way to all languages with subclassing, as that's a matter of taste. I'll just say that IMHO, the main obstacle to writing sound, maintainable programs is the problem of complexity.
A big contributor to the complexity of a system is the amount of interdependency between its components, which is often encapsulated by class/module interfaces. In a system with subclassing, I cannot understand a subclass unless I have understood all its interface superclasses; likewise I cannot understand a class implementation unless I have understood all its implementation superclasses.
Instead of encapsulating complexity behind an interface as narrow as possible, subclassing promotes unnecessary interdependency between software components, and therefore makes for a more complex and less maintainable system.
This page has more references on this kind of thing.
You'd end up keeping the receive patterns and that one in sync, which would be pain
That's what type checking's about, dude! As far as I can see, with Erlang message passing, if you accidentally send a message of the wrong type, it'll just hang around, lost in transit. The type checking on Limbo channels is just the same as that on function calls, and that's great. For looser, untyped, interconnections, you've got files (which in Inferno can represent any external resource).
That's not to say I don't think that Erlang isn't cool - I do, and I like functional programming languages. I'm just saying that Inferno has a great deal to offer too, and perhaps more in some areas.
Re:Mod parent up - there is no "grid computing"
on
GGF and Grid Security
·
· Score: 1
Could tell me what is the point of "web services"? To a naive outsider, they look amazingly complex (XML Schema, anyone?) for what they give you. I'm sure I must have overlooked some vital aspect of the whole WS thing, because for the life of me I can't work out what all the fuss is about. To me, they seem like a strange thing to base a whole infrastructure around.
It'd still be nice if I didn't have to go through this for the "Hello world" module, though"
Actually, the only reason that the "hello world" example contains its own module declaration is so that the ps listing shows the correct name for the newly written process. You could just as easily do:
implement Command; include "sys.m"; include "draw.m"; include "sh.m";
init(ctxt: ref Draw->Context, argv: list of string) { sys:= load Sys Sys->PATH; sys->print("hello, world\n"); }
Here, the "sh.m" header file provides the declaration of the Command module interface.
...or for other situations where the one implementation is enough.
Actually, the above code is one of the canonical examples where one implementation is not enough. The only reason the above program can be invoked by the shell is that the shell loads it as a module, expecting it to implement the Command interface. Every command-line program is an implementation of the Command module!
If a module doesn't implement any module interface, then there's no way for any other module to invoke it, so it might as well not exist! (although a module interface containing nothing at all can occasionally be useful - it's compatible with all other module interfaces, for example, so you can use it to cache modules, even though you can't do anything with them).
The best bit about the module interface stuff is that there's no inheritance - you can look at one interface declaration and see the whole picture; conversely, when designing a piece of software, you can start by designing the interface, deferring entirely how you might implement it. This really helps to keep the number system interdependencies (and hence overall complexity) down.
What if the dynamically-generated string contained a }
I agree that the combining of the two languages isn't very pretty... then again what you lose in prettiness you gain in other ways. BTW The Inferno tk has a superquote convention, so you could do:
tk->cmd(t, "button.b -text '"+_("hello, world"));
and it would work regardless of what the string translated to. There's also a "quote" function in the tk module, so:
Plus, as you mentioned, the compiler could find errors for you. I like catching errors as soon as possible; that's why I prefer type inference to dynamic typing
While I agree in principle here, I think you'll find that
any language has a more-or-less arbitrary dividing line between static and dynamic typing, depending on where you draw the line between language-level objects and program-interpreted values. A static type system is a way of expressing some invariants in the program such the compiler can check that they will never be broken. You can't do this for all aspects of every program, otherwise we'd have a compiler that could prove any program correct (which we know to be impossible).
So, for any given API, where we draw the line between statically- and dynamically-checked aspects of the program is a matter of taste. If we were to go down the statically checked route with Tk objects, we'd have to map all aspects of the tk interface into Limbo objects. So your new Button(...) example is vastly incomplete. In the Tk interface, for a new button, one can specify background colour, foreground colour, justification, font, etc, etc. One would have to invent language-level objects for all these things (instead of using "red", you'd perhaps have to create a new Colour object, initialised in an appropriate way that you could then pass to the Button's "setcolour" method (excuse brit spelling).
I like the way that by defining a small, special-purpose language, one
Actually in my (admittedly biased) opinion, Inferno is better than plan 9 for this, as it can run under existing systems (e.g. Linux & Windows), and the authentication model is peer-to-peer (no auth server bottleneck). I do use Plan 9 on my desktop, but one can use Inferno with little effort
to leverage the power of existing networks of computers which one would perhaps be unwilling to switch over to running Plan 9.
You don't need a VPN to have a secure grid system. For a start, a computational grid need not allow the grid coordinator to run anything on the nodes of the grid.
It seems to be a commonly held misconception that making your node part of a computational grid implies making all of its resources available in the absence of "physical" layers of security (e.g. VPN, virtual memory protection). This is not true - in the "client pull" model, a node on the grid can choose exactly what it cares to run - and if this is a selection from a small set of trusted programs which operate within certain limits, regardless of parameters, then the client is still secure.
As Bruce Schneier might say, there's no absolute level at which you can judge a system "secure". It's all about establishing a level of security that is acceptable to you.
For one example, the grid compute-farm
s/w I wrote allows you to do this.
Re:Mod parent up - there is no "grid computing"
on
GGF and Grid Security
·
· Score: 2, Informative
I agree there's loads of hype around grid computing, but I think there are some interesting problems there. It's not really the same as dedicated clustering, because often (usually?) the cluster is not dedicated. A "grid network" often consists of a scattered set of heterogeneous machines over multiple networks, controlled by many people.
The real task is to transform that sprawling, unreliable beast into something that provides some sort of useful, dependable resource. Machines will be switched off, programs will crash or hang unexpectedly, people will write malicious apps, and through all of that, there is still the possibility of getting some useful work done.
In my personal view, the real failing of the "Grid Computing community" is to try to solve too many problems at once. But what the heck, it gets lots of papers published.
If "grid computing" were saleable, ISPs would be offering off-peak compute time on their server farms, and people would be buying it. They're not.
Most people don't have problems that are suitable for grid compute-farm processing, particularly over WANs. Most companies that do have such problems wouldn't want to make the data that's being processed available to arbitrary client nodes. Neither of these things mean that grid computing is dead.
Inferno isn't entirely about speeding things up through distributed computation, although we
have done that - most importantly, it provides an appropriate set of tools for dealing with today's distributed, networked world.
By using a single, simple metaphor to represent external resources (a hierarchical filesystem with streamlined semantics), it's possible to write general purpose components that are not conceivable in other systems, because their resources are not available in such a uniform way.
For instance:
Distributed resources:
A simple, but deeply-thought-out protocol allows access to a resource hierarchy to be made available, transport independently, through a channel. Thus, any resource in the filesystem can trivially be made available over the network. This includes graphics, network interfaces, serial devices, raw disks, user-level filesystems, user-level program interfaces, etc, etc.
Authentication: Inferno can use a single well-defined authentication protocol to secure access to all external resources in a transparent, end-to-end fashion. Applications need not have any knowledge of this, but nonetheless gain all the benefits. If you're using this stuff, you couldn't care less about 802.11 security (or lack of it) - it's irrelevant.
Transformation: it's easy to "layer" resources; for instance I could export a read-only version of a particular resource just by forbidding all Styx Twrite, Tremove, Twstat, etc operations.
Application transparency: because everything looks like a file, and all the traditional unix tools just work on files (or byte-streams - same difference), it's possible to use all of Inferno's unix-like tools directly on devices, or aspects of a program's external interface without any extra "glue" code at all. This vastly decreases the dev-time, as you can just write independent components, test them individually, and just stick 'em together to make the final application.
Basically it's all about isolating complexity, network and everything else, into independently verifiable bits;
the system lets you plug it all together.
Almost all of the complexity in most conventional systems today comes from backward compatibility requirements. Inferno can do what it does by discarding that backward compatibility - the obvious cost is that it's quite an effort to get your old programs to run underneath it. However, for many applications, that's not an issue, whereas the unreasonable complexity of other "modern" systems is.
At the time (c. 2000), it had a few misfeatures, such as no way to signal that you've closed a channel between two threads
Actually, that's not a misfeature, but a fundamental (and desirable, I think) part of the way that channels work. The point is that, unlike pipes, channels have just a single endpoint. Any process can use that endpoint for reading or writing as it likes - the runtime system will sort out the rendezvous.
So there's no real concept of a channel being "between" two threads. It just exists, and processes use it to exchange data. If a reader of a channel gets killed off, who is to say that that is not intentional?
Channels are a local thing, in the same way that function calls are a local thing. You can use them to structure your program in a similar kind of way that you might use functions. If you want to make one section of your program reslient to another sesction crashing, then channels are not the way to do this - you can use the namespace, which does provide such notification, instead (this also lets you distribute functionality across machines).
expicit static typing to Python's dynamic typing. (I don't like either; I prefer ML-style type inference.)
Actually, Limbo does use a certain amount of type inference (although it doesn't go nearly as far as ML).
I can say: x:= y; and x will be given the same type as y and assigned its value. This is more useful when dealing with functions, e.g.
x:= f(); g(x); h(x);
You don't need to know what the return type of f is called, but the code gets properly statically checked. This is more than just syntactic convenience; it makes code transformation easier, because the code has less dependencies.
declarations and definitions in separate files....When editing, it's much more friendly to change these in one place
Inferno is very much about reusable software - it is formed of specialised components that can plug together in many different ways in order to create the system you're after. The key here is to have specialised, replacable components with narrow interfaces. Limbo modules are designed with this in mind. The declaration and the definition of a Limbo module are two completely independent things. All modules are loaded dynamically (but with assured static type checking). When you write a module, you implement a particular interface. Many modules might implement an interface (each differently), and many modules might use a particular interface - it's the interface itself (the header file) which is the most important component. Hence it makes complete sense
for this to be in its own file. Implementation and interface are two completely separable things (you can declare your own interface locally if you wish to be completely independent).
graphics through Tk. Meaning embedded strings in a completely different, interpreted programming language.
This is debatable. For a start, Limbo strings are dead easy to use, 'cos they're a first class type, like integers or reals. So strings are actually quite a convenient representation for many things within the language.
Also, a GUI toolkit is a really big and complex thing. If you do everything in the language proper, you have to map all the GUI concepts to abstractions within the language. This results in an interface that is really big, and not necessarily easier to use (although it will let the compiler do more checking).
The Limbo tk module interface is 25 lines, comprising a grand total of 10 functions. It's really quite easy to comprehend what's going on - and the fact that all commands are strings makes it trivial to write a little prototyping shell, where you can knock up little GUI components interactively, or experiment without having to write an limbo code. You can even write little UI components in the shell.
the channel feature you mentioned. It seems like a suckier version of Erlang's message-passing
Channels are one of Limbo's most important features. Unlike Erlang's message passing, Limbo's channels are strictly local affairs - and synchronous. They're used to solve a different problem from Erlang's messages - Erlang's messages are intentionally asynchronous and unreliable. If you wish to pass messages reliably between system components, you have to build some reliability on top.
Limbo's channels are designed to make it easy to manage concurrency. In a networked application, you've usually got many things happening simulataneously - very cheap processes and message passing down channels makes it easy to structure an
application as separate, independent processes, each dealing with one aspect of the program's concurrent behaviour. The usual thread-library stuff (locks, semaphores, etc) is stone age compared to this.
I don't see any redeeming qualities
Try using it. You'd be pleasantly surprised. It really is a beautiful language.
The problem, I think, is really an issue of lack of vision combined with a kind of greediness. We really can obtain utility computing... for some kinds of task. For others it's more difficult, maybe impossible. Modularity is (must be, IMHO) the answer.
The greediness I mention comes from the fact that it's difficult to get people to agree to a narrow (they'd call it "restrictive") interface, as they can always argue that you could "get more" (more speed, more close to the fundamental capability of the system). They're greedy for more, but they don't realise, I think, that the very narrowness of an interface is its power, and that you have to sacrifice some performance for reliability.
But with computing, each new feature, standard, operating system, and application has the potential to break other elements of my computing architecture.
This is only the case if your computing architecture is not sufficiently modular! With electricty, if a power station goes down, it does not necessarily mean that you get a power-cut, as power supply can switch to a different station. The same can apply to computing, so long as your view of that external computing resource is compressed is narrow enough that all external resources appear identical.
Another difficulty, I think, is that there is a tendency to group all areas of "utility computing" together; whereas I believe there are several distinct domains it might be applied to. One example is a compute grid, the kind of thing that SETI At Home does. I wrote some software recently to do this sort of thing.
The interesting thing, I found, is that the basic functionality (send a task to a remote machine, get the results) is trivial to implement, but what makes the software really useful (compared to, say, ssh) is the way it covers up faults in the system (network outages, machines being switched off at random, server crashes, etc) and makes the whole thing appear seamless.
The reason it can do this is through the use of narrow interfaces, pared down to the very minimum necessary. I want to use the grid? Dial the server, start handing it my data, and data comes back, computed. You can even use a shell command:
I want to act as a compute node for the grid? Dial
the grid server, read data, compute on it, write data back:
mount myserver.com/n/grid
while{} {seti </n/grid/task >[1=0]}
This really is what the interface looks like (well, it helps a lot having styx as a unifying protocol, I have to admit).
So anyway, to get back to the point, it is possible to have utility computing - you just have
to be very clear as to the utility that you're trying to provide. In this case you take x1, x2,... xn
and compute f(x1), f(x2),..., f(xn). Other systems might provide different kinds of service. We just have
to decide which, rather than being greedy and trying to get everything at once.
Dream jobs don't have to take your vacation. I get over 10 weeks vacation a year, and I'm doing pretty much my dream job. If anyone out there is working on distributed computing, networking, etc, imagine a world where all those barriers of unnecessary complexity were suddenly lowered, where the entire Berkeley sockets interface collapses to 3 function calls with two arguments, where remote resource access is as simple as "echo", where things can be accurately and completely documented on one page...
I'm suddenly aware of just how dreamy it all is, 'cos I've been looking hard at the WSDL spec, and ohmygod I feel the need to rant. With stuff like this, how can anyone get on with doing the difficult bits of the problems of the future.
It seems to me I work in an island of sanity amidst the spewing supertankers of the W3C and their ilk... an island where a difficult decision is not always put off by adding another "optional" layer of abstraction.
Plus, not only do I work in a world with (IMHO) the best software Lego bricks around, but I also have the freedom to build with them anything that might be useful or interesting.
Only problem is it's difficult to keep the mind on continuous creative output... on "mind-fuzz" days, I sometimes wish I just stacked shelves!
Slashdot Mirror
Is this a trivial extension to the protocol, or something that just isn't possible? Multiple party elections aren't that unusual!
oh the joy of having archival snapshots of each day, instantly available.
most of all i miss singing along to yesterday.
From a user interface standpoint, one obvious advantage is that of affordance. Any text in acme affords the command of that name. Command key combinations are hidden out of sight - "Put" is visible and evident, as are "Undo", "Redo", etc, etc.
And when TFP cheerfully described how Acme doesn't have an internal concept of global search and replace but rather relegates those to tool commands that one pipes together, I was certainly impressed. Just, you know, not in a positive way.
Actually, that is one aspect that has changed since the paper - sam-style editing commands are now built in to the editor.
emacs doesn't have structural regular expressions.
The unix command line uses text as a powerful representation medium - acme makes it more powerful still by making all that text amenable to the editor commands, avoiding the restrictiveness of the command-line.
Seriously, it's based on a 1995 paper and with all due respect, it looks 1995 as well.
The prettiness of the user interface has absolutely nothing to do with how useful, usable or life-enhancing a program is...
Wait till you get to the bit where you middle-click and drag over a word to run a command (because pressing a couple of keys just wouldn't require enough dexterity!)
For any one-word command you don't need to drag over the text - just click anywhere in the word (this conveniently excludes execution of the many unix shell commands that require an argument in order to be dangerous, e.g. rm). Alternatively, you can select the text at your leisure with the left button, and then click with the middle. I have to say that as a confirmed acme user who is also fairly cack-handed, I always do it this way, rather than dragging out text with the middle button.
you have to guess whether it will consider the 'command' to be a unix shell command, an internal editor command, a Plan 9 filesystem path...
Well, since you've chosen the text yourself, presumably you know what you want it to do. And it's not too hard - there are only a small number of internal editor commands, and they all begin with a capital letter (e.g. Del, Undo). There's no distinction between shell commands and filesystem paths beyond where the shell looks for the executable. So ls differs from /usr/rog/bin/blah but the difference is obvious!
If you're editing over a remote link, it really depends how limited you are in the protocols you can use. If you've only got telnet/ssh, you're probably screwed. If, however, you can run something on the other end, then you've got a world of opportunity, as this (remote access) is the kind of thing that plan 9 and inferno excel at. Using a straight telnet/ssh link these days makes me feel like I've got one arm tied behind my back.
For using acme remotely, the best option is to run something, for example u9fs to export the files you wish to edit, then import the filesystem, whereupon you can use acme to edit the files in it. It's also possible to run acme remotely, (by using inferno or drawterm and making a cpu connection), but the graphics speed will then be predicated on the speed of your connection, which can make this unrealistic.
RTFM
One thing that I think people find hard to understand about acme is just how powerful the mouse actually is. By assigning universally applicable actions to each mouse button (select, execute, look), and giving it the entire window contents as its domain (almost any part of which is user-changeable), the mouse is no longer something that must be moved in order to let the keyboard do something, but an expressive tool in its own right. Add mouse chording to that, enabling cut, copy and paste of arbitrary pieces of text with no keyboard input necessary, and it's the keyboard which is more seldom used. I've looked over the shoulder of developers using acme to edit and debug software and seen 20 minutes go by without the keyboard being used once! And in that time, programs have been run, projects built, and many source files browsed and edited.
It's not something that can be fully appreciated until you've used it for a while. But once hooked, you won't find anything to beat it.
I used Occam for a while, and I'd have to disagree... it had many nice aspects, but feature-wise it lacked (for a good reason) some of the most useful features around. In particular, it didn't have any dynamic memory allocation at all. This meant that it was easy to statically prove properties of an Occam program, but... no dynamic data structures really cramps your style!
The really nice thing about Occam was the concurrency. Ultra lightweight processes (zero context switch time) and CSP-style channels were just great. That's why I was so happy to play with Inferno's Limbo, which takes these features (well ok the context-switch time isn't precisely zero, but it's pretty darn quick) and adds full dynamism and a really nice syntax. Programming GUI and networky kinda stuff in Limbo is a dream - it's amazing how elegant and useful concurrency can be when you have the right set of primitives. Most "threaded" languages make it gratuitously hard.
When 90% of the code is tucked away behind n levels of fold, it becomes hard to see exactly what's going on. The conclusion we came to was that if you need to fold code, then it should be broken down into smaller functions, which is good for internal modularity, and helps to maintain nice looking and understandable code overall.
What this means is that a well designed user interface implements something akin to Huffman encoding with respect to user-input and resulting actions. Common actions should be encoded with short/easy input sequences, where less common actions can be encoded with something more verbose.
For instance, a digital camera might dedicate a whole button to just taking a photo (1 bit), but require accessing a menu interface to delete a photo. Writing a new script, or combining UI elements is perhaps the equivalent of introducing a new node in the encoding tree.
A well designed UI anticipates likely patterns of user action and makes their encodings small (but hopefully consistent with the rest of the system). This is inevitably a personal thing, as everyone has different actions they wish to perform. For instance some Nokia mobile phones have a great UI for me - most common actions just take a single button-click - the context is all-important.
No, the computer can't read your mind, but the designer can, to some extent, by looking at the problem domain and extrapolating from empirical facts about human nature. I completely concur with the original author, and I can entirely see why many people get frustrated with modern software.
Why, oh why, does Microsoft have to rely on Javascript for this page, when a simple HTML form would do?
I had to laugh. Web services are so ludicrously complex that unless you use loads of existing (complex and platform-specific) software, the technical barriers to entry are remarkably high! I've implemented some web services stuff from scratch, and it's really not easy at all. The WSDL standard drags in many other standards.
Just for a laugh, I started to try to enumerate the standards referred to, directly and indirectly, from the WSDL. I ran out of time after getting two levels deep, but already the referred-to standards totalled 4.8MB (approx. 103000 lines)! And this is a "low technical barrier to entry"?!
This enormous complexity is simply not necessary to make a decent, general-purpose framework for program accessibility and interoperability. As an example, the Styx protocol is general purpose protocol that actually does considerably more than web services, but it is completely documented in under 42K (just over 1000 lines). It references only one other standard (UTF-8), (one that I didn't include in the above count for WSDL, even though it was referred to there). You can knock up a client or a server from scratch in a couple of days. It's light-weight enough that it can be implemented on tiny devices, such as the Lego brick.
Hence my initial question. What is it with all the web services stuff?
I'd be crying if I wasn't busy being sick.
Actually, it's demonstrably superior to Java's way, as Java doesn't maintain the Liskov Substitution Principle. With no subclassing, Limbo doesn't have this problem.
I wouldn't say that Limbo's way was superior in the same way to all languages with subclassing, as that's a matter of taste. I'll just say that IMHO, the main obstacle to writing sound, maintainable programs is the problem of complexity.
A big contributor to the complexity of a system is the amount of interdependency between its components, which is often encapsulated by class/module interfaces. In a system with subclassing, I cannot understand a subclass unless I have understood all its interface superclasses; likewise I cannot understand a class implementation unless I have understood all its implementation superclasses.
Instead of encapsulating complexity behind an interface as narrow as possible, subclassing promotes unnecessary interdependency between software components, and therefore makes for a more complex and less maintainable system.
This page has more references on this kind of thing.
You'd end up keeping the receive patterns and that one in sync, which would be pain
That's what type checking's about, dude! As far as I can see, with Erlang message passing, if you accidentally send a message of the wrong type, it'll just hang around, lost in transit. The type checking on Limbo channels is just the same as that on function calls, and that's great. For looser, untyped, interconnections, you've got files (which in Inferno can represent any external resource).
That's not to say I don't think that Erlang isn't cool - I do, and I like functional programming languages. I'm just saying that Inferno has a great deal to offer too, and perhaps more in some areas.
Could tell me what is the point of "web services"? To a naive outsider, they look amazingly complex (XML Schema, anyone?) for what they give you. I'm sure I must have overlooked some vital aspect of the whole WS thing, because for the life of me I can't work out what all the fuss is about. To me, they seem like a strange thing to base a whole infrastructure around.
Actually, the only reason that the "hello world" example contains its own module declaration is so that the ps listing shows the correct name for the newly written process. You could just as easily do:
Here, the "sh.m" header file provides the declaration of the Command module interface.
Actually, the above code is one of the canonical examples where one implementation is not enough. The only reason the above program can be invoked by the shell is that the shell loads it as a module, expecting it to implement the Command interface. Every command-line program is an implementation of the Command module!
If a module doesn't implement any module interface, then there's no way for any other module to invoke it, so it might as well not exist! (although a module interface containing nothing at all can occasionally be useful - it's compatible with all other module interfaces, for example, so you can use it to cache modules, even though you can't do anything with them).
The best bit about the module interface stuff is that there's no inheritance - you can look at one interface declaration and see the whole picture; conversely, when designing a piece of software, you can start by designing the interface, deferring entirely how you might implement it. This really helps to keep the number system interdependencies (and hence overall complexity) down.
What if the dynamically-generated string contained a }
I agree that the combining of the two languages isn't very pretty... then again what you lose in prettiness you gain in other ways. BTW The Inferno tk has a superquote convention, so you could do:
and it would work regardless of what the string translated to. There's also a "quote" function in the tk module, so:
would work fine too.
Plus, as you mentioned, the compiler could find errors for you. I like catching errors as soon as possible; that's why I prefer type inference to dynamic typing
While I agree in principle here, I think you'll find that any language has a more-or-less arbitrary dividing line between static and dynamic typing, depending on where you draw the line between language-level objects and program-interpreted values. A static type system is a way of expressing some invariants in the program such the compiler can check that they will never be broken. You can't do this for all aspects of every program, otherwise we'd have a compiler that could prove any program correct (which we know to be impossible).
So, for any given API, where we draw the line between statically- and dynamically-checked aspects of the program is a matter of taste. If we were to go down the statically checked route with Tk objects, we'd have to map all aspects of the tk interface into Limbo objects. So your new Button(...) example is vastly incomplete. In the Tk interface, for a new button, one can specify background colour, foreground colour, justification, font, etc, etc. One would have to invent language-level objects for all these things (instead of using "red", you'd perhaps have to create a new Colour object, initialised in an appropriate way that you could then pass to the Button's "setcolour" method (excuse brit spelling).
I like the way that by defining a small, special-purpose language, one
Actually in my (admittedly biased) opinion, Inferno is better than plan 9 for this, as it can run under existing systems (e.g. Linux & Windows), and the authentication model is peer-to-peer (no auth server bottleneck). I do use Plan 9 on my desktop, but one can use Inferno with little effort to leverage the power of existing networks of computers which one would perhaps be unwilling to switch over to running Plan 9.
It seems to be a commonly held misconception that making your node part of a computational grid implies making all of its resources available in the absence of "physical" layers of security (e.g. VPN, virtual memory protection). This is not true - in the "client pull" model, a node on the grid can choose exactly what it cares to run - and if this is a selection from a small set of trusted programs which operate within certain limits, regardless of parameters, then the client is still secure.
As Bruce Schneier might say, there's no absolute level at which you can judge a system "secure". It's all about establishing a level of security that is acceptable to you.
For one example, the grid compute-farm s/w I wrote allows you to do this.
The real task is to transform that sprawling, unreliable beast into something that provides some sort of useful, dependable resource. Machines will be switched off, programs will crash or hang unexpectedly, people will write malicious apps, and through all of that, there is still the possibility of getting some useful work done.
In my personal view, the real failing of the "Grid Computing community" is to try to solve too many problems at once. But what the heck, it gets lots of papers published.
If "grid computing" were saleable, ISPs would be offering off-peak compute time on their server farms, and people would be buying it. They're not.
Most people don't have problems that are suitable for grid compute-farm processing, particularly over WANs. Most companies that do have such problems wouldn't want to make the data that's being processed available to arbitrary client nodes. Neither of these things mean that grid computing is dead.
By using a single, simple metaphor to represent external resources (a hierarchical filesystem with streamlined semantics), it's possible to write general purpose components that are not conceivable in other systems, because their resources are not available in such a uniform way.
For instance:
- Distributed resources:
A simple, but deeply-thought-out protocol allows access to a resource hierarchy to be made available, transport independently, through a channel. Thus, any resource in the filesystem can trivially be made available over the network. This includes graphics, network interfaces, serial devices, raw disks, user-level filesystems, user-level program interfaces, etc, etc.
- Authentication: Inferno can use a single well-defined authentication protocol to secure access to all external resources in a transparent, end-to-end fashion. Applications need not have any knowledge of this, but nonetheless gain all the benefits. If you're using this stuff, you couldn't care less about 802.11 security (or lack of it) - it's irrelevant.
- Transformation: it's easy to "layer" resources; for instance I could export a read-only version of a particular resource just by forbidding all Styx Twrite, Tremove, Twstat, etc operations.
- Application transparency: because everything looks like a file, and all the traditional unix tools just work on files (or byte-streams - same difference), it's possible to use all of Inferno's unix-like tools directly on devices, or aspects of a program's external interface without any extra "glue" code at all. This vastly decreases the dev-time, as you can just write independent components, test them individually, and just stick 'em together to make the final application.
Basically it's all about isolating complexity, network and everything else, into independently verifiable bits; the system lets you plug it all together.Almost all of the complexity in most conventional systems today comes from backward compatibility requirements. Inferno can do what it does by discarding that backward compatibility - the obvious cost is that it's quite an effort to get your old programs to run underneath it. However, for many applications, that's not an issue, whereas the unreasonable complexity of other "modern" systems is.
Actually, that's not a misfeature, but a fundamental (and desirable, I think) part of the way that channels work. The point is that, unlike pipes, channels have just a single endpoint. Any process can use that endpoint for reading or writing as it likes - the runtime system will sort out the rendezvous.
So there's no real concept of a channel being "between" two threads. It just exists, and processes use it to exchange data. If a reader of a channel gets killed off, who is to say that that is not intentional?
Channels are a local thing, in the same way that function calls are a local thing. You can use them to structure your program in a similar kind of way that you might use functions. If you want to make one section of your program reslient to another sesction crashing, then channels are not the way to do this - you can use the namespace, which does provide such notification, instead (this also lets you distribute functionality across machines).
Actually, Limbo does use a certain amount of type inference (although it doesn't go nearly as far as ML). I can say: x := y; and x will be given the same type as y and assigned its value. This is more useful when dealing with functions, e.g.
You don't need to know what the return type of f is called, but the code gets properly statically checked. This is more than just syntactic convenience; it makes code transformation easier, because the code has less dependencies.
declarations and definitions in separate files....When editing, it's much more friendly to change these in one place
Inferno is very much about reusable software - it is formed of specialised components that can plug together in many different ways in order to create the system you're after. The key here is to have specialised, replacable components with narrow interfaces. Limbo modules are designed with this in mind. The declaration and the definition of a Limbo module are two completely independent things. All modules are loaded dynamically (but with assured static type checking). When you write a module, you implement a particular interface. Many modules might implement an interface (each differently), and many modules might use a particular interface - it's the interface itself (the header file) which is the most important component. Hence it makes complete sense for this to be in its own file. Implementation and interface are two completely separable things (you can declare your own interface locally if you wish to be completely independent).
graphics through Tk. Meaning embedded strings in a completely different, interpreted programming language.
This is debatable. For a start, Limbo strings are dead easy to use, 'cos they're a first class type, like integers or reals. So strings are actually quite a convenient representation for many things within the language.
Also, a GUI toolkit is a really big and complex thing. If you do everything in the language proper, you have to map all the GUI concepts to abstractions within the language. This results in an interface that is really big, and not necessarily easier to use (although it will let the compiler do more checking).
The Limbo tk module interface is 25 lines, comprising a grand total of 10 functions. It's really quite easy to comprehend what's going on - and the fact that all commands are strings makes it trivial to write a little prototyping shell, where you can knock up little GUI components interactively, or experiment without having to write an limbo code. You can even write little UI components in the shell.
the channel feature you mentioned. It seems like a suckier version of Erlang's message-passing
Channels are one of Limbo's most important features. Unlike Erlang's message passing, Limbo's channels are strictly local affairs - and synchronous. They're used to solve a different problem from Erlang's messages - Erlang's messages are intentionally asynchronous and unreliable. If you wish to pass messages reliably between system components, you have to build some reliability on top.
Limbo's channels are designed to make it easy to manage concurrency. In a networked application, you've usually got many things happening simulataneously - very cheap processes and message passing down channels makes it easy to structure an application as separate, independent processes, each dealing with one aspect of the program's concurrent behaviour. The usual thread-library stuff (locks, semaphores, etc) is stone age compared to this.
I don't see any redeeming qualities
Try using it. You'd be pleasantly surprised. It really is a beautiful language.
The greediness I mention comes from the fact that it's difficult to get people to agree to a narrow (they'd call it "restrictive") interface, as they can always argue that you could "get more" (more speed, more close to the fundamental capability of the system). They're greedy for more, but they don't realise, I think, that the very narrowness of an interface is its power, and that you have to sacrifice some performance for reliability.
But with computing, each new feature, standard, operating system, and application has the potential to break other elements of my computing architecture.
This is only the case if your computing architecture is not sufficiently modular! With electricty, if a power station goes down, it does not necessarily mean that you get a power-cut, as power supply can switch to a different station. The same can apply to computing, so long as your view of that external computing resource is compressed is narrow enough that all external resources appear identical.
Another difficulty, I think, is that there is a tendency to group all areas of "utility computing" together; whereas I believe there are several distinct domains it might be applied to. One example is a compute grid, the kind of thing that SETI At Home does. I wrote some software recently to do this sort of thing.
The interesting thing, I found, is that the basic functionality (send a task to a remote machine, get the results) is trivial to implement, but what makes the software really useful (compared to, say, ssh) is the way it covers up faults in the system (network outages, machines being switched off at random, server crashes, etc) and makes the whole thing appear seamless.
The reason it can do this is through the use of narrow interfaces, pared down to the very minimum necessary. I want to use the grid? Dial the server, start handing it my data, and data comes back, computed. You can even use a shell command:
cat datafile | farm myserver.com seti > resultfile
I want to act as a compute node for the grid? Dial the grid server, read data, compute on it, write data back:
mount myserver.com /n/grid /n/grid/task >[1=0]}
while{} {seti <
This really is what the interface looks like (well, it helps a lot having styx as a unifying protocol, I have to admit).
So anyway, to get back to the point, it is possible to have utility computing - you just have to be very clear as to the utility that you're trying to provide. In this case you take x1, x2, ... xn
and compute f(x1), f(x2), ..., f(xn). Other systems might provide different kinds of service. We just have
to decide which, rather than being greedy and trying to get everything at once.
I'm suddenly aware of just how dreamy it all is, 'cos I've been looking hard at the WSDL spec, and ohmygod I feel the need to rant. With stuff like this, how can anyone get on with doing the difficult bits of the problems of the future.
It seems to me I work in an island of sanity amidst the spewing supertankers of the W3C and their ilk... an island where a difficult decision is not always put off by adding another "optional" layer of abstraction.
Plus, not only do I work in a world with (IMHO) the best software Lego bricks around, but I also have the freedom to build with them anything that might be useful or interesting.
Only problem is it's difficult to keep the mind on continuous creative output... on "mind-fuzz" days, I sometimes wish I just stacked shelves!