Benchmark code like this does not represent how these languages are used in practice. Idiomatic Java code tends to be full of dynamic classes and indirection galore. Just testing "arithmetic and trigonometric functions [...] and [...] simple file I/O" is not going to tell you anything about how fast these languages are in the real world.
See the index to find out where (hint: it is in the 'language' item).
Aside from the CSP issue, I feel that those index semantics are questionable. If you are going to
include an index, please make it a comprehensive one. I have no problem with including
"CSP" under "Language" in the index, but it must have its own entry too! I had looked for CSP
quite hard - I looked up every mentioned reference to
"Hoare"; I checked the bibliography (it was mentioned, but no back reference). To find an item in the index,
one should not have to know what context to find it in: that's the job of the Contents page!
Out of interest, using your ports paradigm,
is it straightforward to have some flow control without
making the protocol synchronous? When writing
concurrent programs, I've often found pipeline
and tree structures to be useful, but presumably if one
were using asynchronous ports, a producer that's consistently faster than a consumer would
quickly exhaust memory as space for all those
unconsumed messages was allocated.
I'm a bit dubious about a book that talks about
the "substitution property" of objects without
once mentioning
Liskov'ssubstitution principle,
or that talks about message passing concurrency
wthout mentioning Tony Hoare's CSP.
Is this book really as authoratitive as it tries to appear?
to be more specific than Dr. Skwid,
plan 9 has had multiple IP stacks from
the word go (check out the man page).
but not only that, but the fact that resources can be distributed transparently over the network means
that a specific network interface (perhaps an interface
to the outside world) can be imported from another
machine, and used, exactly as if it were a local
IP stack.
none of this requires any particularly deep magic;
it does however require a fresh approach from the
ground up, something you're unlikely to find in any
of the mainstream unix-like OSes...
My brother was in the gulf as principal warfare
officer on board a british naval vessel.
I found his emails fascinating. Here's an extract:
The 6 hours on 6 hours off routine is quite punishing but I am getting into
the way of it. Getting up is the big problem, as I rarely get more than 4
hours at a stretch but I am surviving. Meals tend to be eaten at high speed
and I have hardly been outside. I have major problems remembering whether
it is morning or evening! The 'PWOing' is unlike anything I have done
before. We communicate with other ships almost exclusively by chat room on
a coalition wide network. It is most odd to spend 6 hours conducting
operations with other ships and not to hear a voice from them at all, just
to pass messages on chat. It can get rather frantic at times with 2 or 3
'net meetings' in progress, each with up to a dozen people in it and a
similar number of private chats at the same time. When any of them receives
a new message it jumps to be the top window and flashes at you. It requires
rapid typing and good skills with the mouse to shuffle them all around and
make sure that they don't obscure each other all the time. I guess it is
the future of warfare, and it is very good for some things but there are
occasions when you just want to talk - but the Americans don't do that
anymore!
Re:Real functionality for mouse buttons
on
3-button Optical Mice?
·
· Score: 2, Interesting
I use plan 9, and spend most of my time inside
acme, which in my view has
one of the nicest developer interfaces around.
The mouse interface feels particularly natural once
one is used to it and not only do all three buttons
have distinct (and consistent) uses, combinations of buttons do too!
button 1 selects text.
button 2 selects text; it then executes the
selected text as an editor command, or a shell
command.
button 3 selects text; it then looks for that
text: if it's a filename, it opens it in a new window,
or moves to it if already open; otherwise it
looks for the next occurrence of that text
inside the current window.
Note that acme is basically a text editor: everything
in it (including the titlebars of the windows) contains
editable text. There are no menus, buttons, widgets
or icons. To delete a window, you middle-button
click on the text "Del" (I could do it now on that text!).
To paste some text from the cut&paste buffer,
select the text to be replaced, and middle click on "Paste".
For operations like cut & paste, that's a little time consuming
so there are mouse short cuts, using mouse chords.
If you've selected some text with button-1, before
you let go of the button, you can click button-2 to cut the
text, or button-3 to paste some text. (button-2 followed by
button-3 leaves the text unchanged, just copied into the
copy&paste buffer).
This is immensely convenient - you can do without the
keyboard for a great deal of editing work, shuffling
pieces of code around, browsing looking for variable
declarations, running compilations, etc, etc.
Rather than having my hands always on the keyboard
and occasionally moving to the mouse, I find my hand
is always on the mouse, and only occasionally moves
to the keyboard (to enter text! - exactly what the keyboard is for).
Here's an example of a system that uses 3 mouse buttons
in a completely consistent way to really leverage the
expressive power of a mouse.
Programming languages are as important for what
they don't allow you to do as for what they
do allow you to do. Why does Java have a statically declared type system? Why... for the sole
purpose of forbidding you to perform certain actions (e.g. calling a method on an object that
doesn't implement that method).
Certain language features lend themselves to abuse
(C++ operator overloading has been held up as example of this in the past). In my view, a well designed language should provide powerful features
that also lend themselves well to "modular-reasoning". By this I mean that in an arbitrarily large software project, I can look at one tiny bit of it and
work out something of what it's doing.
Given that most large software projects are, in their
totality beyond one person's conception, I'd say
this was a highly desirable feature in a modern
computer language.
Features like AOP undermine this kind of modular
reasoning by changing the semantics of code
that was originally written (and tested) without the
knowledge that it would be changed like that.
There are all kinds of invariants that programmers
maintain when writing their code, and this kind of feature seems like a very good way of breaking them
in all kinds of subtle ways. Welcome to Bug City.
Random comment:
If you're interested, this is an
OO language which seems to be genuinely well done.
Actually, this is precisely what AOP seeks to do. By gather all the logging or DB transaction logic into one place and giving rules to the compiler for determining when/where to insert that code, you achieve a very clean separation of concerns.
Clean from the point of view of the person implementing the logging or DB transaction code, perhaps... but think about it from the point of view
of the person debugging the system:
at any method invocation in the original code,
some other arbitrary code might run, with possibly
arbitrary side effects, including possibly invoking other
methods and/or changing instance variables in the
object that's currently being used.
Of course, no sensible person would use this kind
of feature in a way that would cause these kind of side-effects, but when debugging a system you don't
know whether the original implementor was sensible. Perhaps they made a mistake (something I
believe has been known to happen...).
The point is that by adding primitives like this, you've
gone from building your system on solid building blocks to a foundation of shifting sands. An API
that was stable before might be utterly demolished
by a slightly injudicious use of this feature.
Those people in this thread comparing this feature
to LISP macros were dead on... experienced LISP programmers use them seldom.
As this says:
Macros are powerful, but dangerous. Use them sparingly, and only
when you really understand what they might do.
Do people really want to build reliable software using
this sort of stuff?
Sounds like a disgusting way of trying to legitimise
hacks to me. Changing code in ways it wasn't meant
to be changed, guaranteed to break lots of things
(hence the "horribly easy to accidentally create
infinite recursion" reference... no shit Sherlock!)
When will people realise that the most important
thing in a programming language is to make it
possible to reason about one part of it independent
of another part? Most of the time spent developing
a program is spent modifying code, not creating new
code!
Unfortunately people don't realise this: they just
want a way of hacking something existing into
something different, cross their fingers and hope that
it works when someone changes some other part
of the system.
Then again, maybe I'm completely wrong, and AOP
has a sound theoretical basis and has been
created by someone with deep understanding
of programming language developments over
the last thirty years... someone please reassure me!
As far as I can see, this algorithm runs in time
proportional to the number of documents,
which might be fine for a small number
of documents, but would be abysmal in
large environments.
It's a pity the article doesn't make this clearer
(instead, it just says "Searches take place in
RAM, so there's no disk or database access",
which makes it sound as if it would be faster!)
There's a reason people invented indexing schemes!
The issue is linking. Is your program linked (in the compilation sense of the word) with the DNS sever?
I don't think that is the issue.
After all, with Java there's not necessarily any compilation going on at all (if it's not running in JIT
mode) - it's just an interpreter, and the programs
(the non-GPL program and the GPL'd JAR) are
just inputs to that interpreter.
The GPL says:
If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.
It seems to me that anything that needs to use GPL
software in order to be used cannot be considered
independent of the GPL software, and hence must be
distributed under the GPL license.
How is an interpreted Java program that relies on a
piece of external GPL code qualititavely different from (say)
a document written with a GPL word processor (in a format specific to that word processor)?
I don't think it is... and I hence I can understand entirely the reluctance of Apple's lawyers to countenance the bundling of any GPL code with
MacOS X...
P.S. I don't think I emphasised enough the beauty
of having a fully customisable namespace.
I mention this just because I've only this moment
been struggling with trying to get a program going
under Unix that expects a data file to be in a particular
location. Unfortunately I don't have write permissions
in that location... so I'm buggered, there's nothing
I can do, the program is useless until I can persuade
a sys admin to let me write there.
Under Plan 9, on the other hand, you can always rearrange resources for a program: don't like the
contents of that config file? Just bind another file
over the top of it. Want a program to read a remote
mouse rather than the local one? Just import the
remote filesystem and bind the remote
mouse on top before running the program.
No needless barriers!
(The astute amongst you will have realised that this
is one reason why Plan 9 doesn't have set-uid executables, not something greatly missed.)
Why is Plan 9 cool? I don't know much about it am really curious. What does it do that UNIX does not?
There are various bits of UNIX (and I include Linux here, as it's
essentially a UNIX clone) that have been bolted on without regard for
the elegance of the whole system. In particular, graphics, pseudo
terminals and networking were all added late in UNIX's lifetime and
considerably clutter the system and limit its capabilities.
Take the ubiquitous psueudo terminals as an example. Almost
nobody actually uses a genuine VT220 (or whatever) as their
input device. However, the output from every command-line
program in UNIX goes through something that pretends to be such
a device. The kernel has much elaborate stuff (the tty driver) built in to
convince command line programs that they're talking
to a real terminal. The kernel knows about command line editing,
it knows how to print control characters nicely, and it knows
what key means "word erase".
This is all crap! It adds unnecessary complexity to the kernel,
and not only that, but every command line program that wants a
a slightly more sophisticated interface (e.g. cursor-based editing)
has to do it itself (c.f. GNU readline). This not only bloats the
kernel and many of its applications, it also means that the commands
are less versatile than they could be (requiring people to use tools
like expect to demangle their output).
Under Plan 9, there are no special system calls devoted to terminals
or networking: instead, the interface to device drivers is made more
versatile (all you need is
open,
read and write to access a device driver, no fancy ioctls or fcntls
required. This gets back to the original purity of the
7th Edition programming
interface: programs are a joy to write, and once written can be
put to many more uses, as the currency of command line programs
(text written to stdin/stdout) is also the currency of device drivers.
Because everything is unified under one hood (the
name space),
I don't have to write a special program to get fancy functionality.
Want to find out what programs have a particular file open?
grep filename/proc/*/fd
Plan 9 is all about the joys of writing less code, more cleanly, and
finding it more useful when written; of having a box of tools
that can be plugged together in a multitude of different ways,
transparently and securely across networks; of having a clean user
interface that is concerned principally with power and simplicity
rather than appearance.
Of course in this day and age, when a word processor takes >2,000,000
lines of code and "features" are rated more highly than overall usability,
it's not surprising that Plan 9 isn't that well known, or that
Dennis Ritchie reverts to Windows NT in order to browse the web.
As for myself, I'll stick to Plan 9's (and Inferno's) deep joy for as long as I possibly can!
Dude, I'm sure it's a great book and that there's
a bunch of excellent words in there, but GROYNE is the [...]
LOL!
Ok, you've got me! I haven't got a copy of
the book and "groyne" was the best that google
could offer by way of an extract.
Merkin would have been a better example, but
the words themselves are nothing without
the definitions they're given with, and
associated suggested ways of using them..
this reminds me
on
A Word a Day
·
· Score: 3, Informative
This christmas, we gained much hilarity
(and some education) from The Superior Person's Book of Words. It sounds as if it's
along the same kind of thing as the book reviewed in this slashdot article.
I've nothing to do with the publishers or the author,
I just think it deserves to be known about.
Highly recommended, if you're into unusual words.
Example
GROYNE n. ~ This is the correct term for one of those
little wooden fences or brick walls that run down English beaches and out into the water for some distance, as a device to check the drifting of the same. Pronounced, and sometimes spelled, groin. "Shall we get together down by the groyne?"
Yeah, you "just" need to worry about synchronization, deadlocking, and other concurreny issues instead. Muuuuuuch easier. But what you said above made no sense to me (perhaps I need some more coffee) - can you explain this in more detail?
It depends on the thread abstractions that are used for synchronisation and thread communication. The most commonly used abstractions today (semaphores, locks, etc) date from the 1970s; there are much better ways to do it!
One way derives from a mathematical notation created by Tony Hoare, called CSP. There is one unit of thread communications and synchronisation, called a channel. It's like a rendezvous point that allows a value to be passed between threads. If one thread tries to send a value on a channel, it will block until another thread tries to read from the channel (also, reading from the channel will block until another thread tries to send on it).
This scheme is incredibly versatile, easy to use and cheap. There are also some tools that can aid in automatic verification of software built in this way. It's true that it's possible to deadlock in concurrent systems, but it's almost always possible to structure the system in such a way that it's deadlock-free by construction. For instance, if my program is structured as a one-way pipeline, it's impossible to deadlock.
Concurrency at this level in a GUI application can greatly enhance the simplicity and maintainability of a program. This is because it's generally much easier to write a straightforward piece of imperative code than encode the same thing as a state machine, e.g.
callback(buttons, point) {
if (state == DRAGGING) {
if (buttons != 0)
drawat(point);
else
state = NOTDRAGGING;
} }
You say: That would be the case if interaction was a parallel activity, but unfortunately it's not.
But it is! Yes, the user themselves only contributes one thread to the activity, but the program itself is often dealing with multiple activities at the same time; for instance updating itself in response to network activities or updating graphics on a time-step basis.
The most important thing it gives you, in my experience, is the sense of control. As a separate thread, you are free to structure your application in a way directly appropriate to the task being solved. In a callback system, you are at the mercy of the caller; you can't just wait for an event, then do the next thing, you have to encode your current state, return, and wait to be called back, whereupon you have to figure out where you just were!
For a language that exemplifies this, see Limbo, the language of choice in the Inferno environment. No problems with thread unsafe graphics there!
that might not be the case here: he didn't say it was a realtime product, but an "embedded networking"
product.
given that people usually compare hardware using benchmark
tests (driver included), i'd imagine that it
would be quite important that it be as fast
as possible.
there are too many highly complex GUIs out there.
most of them are unnecessarily complex.
if you apply Occam's Razor at every opportunity,
take every chance you can to cut down on the
number of degrees of freedom, eliminate
all choices that are not absolutely necessary, you
will usually end up with something that is more intuitive, more powerful, easier (= cheaper!) to implement
and has fewer bugs to boot.
in these days of 20 million LOC word processors,
and "pile on every feature that we can think of"
applications, simplicity is an underrated virtue.
it was a few years back, but i still have a copy
of the software (it still seems to work, amazing).
i hooked it to a graphical display, so you
could get an idea of what satellites were visible
at what time... what an amazing system it was.
the specs probably changed considerably from when
i was doing this, but at that time, they were considering a network of 840 satellites!
in some areas of the world you had maybe 10 or 20
satellites visible at once. if this thing had ever got off
the ground, you'd have had some pretty spectacular
displays around dawn and dusk.
what an amazing waste of money.
personally i think that high altitude balloons sound
like an excellent idea as a cheap alternative to
behemoths like teledesic.
what a pity that the POSIX threading model
is so archaic (and that nobody seems to have
heard of any alternatives).
for instance
CSP has a reasonable theoretical foundation
and is infinitely nicer to program with than those
locks and semaphors invented in the '70s...
factotum is not necessarily single sign on
on
Passport vs. Plan 9
·
· Score: 4, Insightful
oh, i wish that at least someone out
there would go and read the original
article before mouthing off.
factotum (plan 9's authentication agent) is
not a single sign-on solution, although
it can be when used in conjunction with
secstore. what it does mean
is that applications do not have to be burdened with
complex and error-prone authentication code,
and that there is one, well-verified, point in the
system that holds secrets and understands the
protocols.
in the factotum scheme, you can mark certain accounts (e.g. your bank account access) so that
they will always require a password to be entered;
you can also use the scheme without secstore
(which is what i'm doing currently) which just
forces you to type in each password the first time
it's required. secstore is a means to store all
your passwords in one place securely, which you
can then use to prime factotum.
this is the essence of the plan 9 approach - choose
an abstraction and write it in a simple, modular
way so that it's applicable to a wide range of previously unanticipated scenarios.
it's a wonderful system, and one that carries forward the true unix tradition, something that UNIX lost long ago.
Slashdot Mirror
No you couldn't: not if your spec was to fit in with existing OO code (and it often will be).
Benchmark code like this does not represent how these languages are used in practice. Idiomatic Java code tends to be full of dynamic classes and indirection galore. Just testing "arithmetic and trigonometric functions [...] and [...] simple file I/O" is not going to tell you anything about how fast these languages are in the real world.
Aside from the CSP issue, I feel that those index semantics are questionable. If you are going to include an index, please make it a comprehensive one. I have no problem with including "CSP" under "Language" in the index, but it must have its own entry too! I had looked for CSP quite hard - I looked up every mentioned reference to "Hoare"; I checked the bibliography (it was mentioned, but no back reference). To find an item in the index, one should not have to know what context to find it in: that's the job of the Contents page!
Out of interest, using your ports paradigm, is it straightforward to have some flow control without making the protocol synchronous? When writing concurrent programs, I've often found pipeline and tree structures to be useful, but presumably if one were using asynchronous ports, a producer that's consistently faster than a consumer would quickly exhaust memory as space for all those unconsumed messages was allocated.
Well, there's always Plan 9's fossil. Oh... you mean Linux software?
Is this book really as authoratitive as it tries to appear?
but not only that, but the fact that resources can be distributed transparently over the network means that a specific network interface (perhaps an interface to the outside world) can be imported from another machine, and used, exactly as if it were a local IP stack.
none of this requires any particularly deep magic; it does however require a fresh approach from the ground up, something you're unlikely to find in any of the mainstream unix-like OSes...
The mouse interface feels particularly natural once one is used to it and not only do all three buttons have distinct (and consistent) uses, combinations of buttons do too!
- button 1 selects text.
- button 2 selects text; it then executes the
selected text as an editor command, or a shell
command.
- button 3 selects text; it then looks for that
text: if it's a filename, it opens it in a new window,
or moves to it if already open; otherwise it
looks for the next occurrence of that text
inside the current window.
Note that acme is basically a text editor: everything in it (including the titlebars of the windows) contains editable text. There are no menus, buttons, widgets or icons. To delete a window, you middle-button click on the text "Del" (I could do it now on that text!). To paste some text from the cut&paste buffer, select the text to be replaced, and middle click on "Paste".For operations like cut & paste, that's a little time consuming so there are mouse short cuts, using mouse chords. If you've selected some text with button-1, before you let go of the button, you can click button-2 to cut the text, or button-3 to paste some text. (button-2 followed by button-3 leaves the text unchanged, just copied into the copy&paste buffer).
This is immensely convenient - you can do without the keyboard for a great deal of editing work, shuffling pieces of code around, browsing looking for variable declarations, running compilations, etc, etc. Rather than having my hands always on the keyboard and occasionally moving to the mouse, I find my hand is always on the mouse, and only occasionally moves to the keyboard (to enter text! - exactly what the keyboard is for).
Here's an example of a system that uses 3 mouse buttons in a completely consistent way to really leverage the expressive power of a mouse.
Certain language features lend themselves to abuse (C++ operator overloading has been held up as example of this in the past). In my view, a well designed language should provide powerful features that also lend themselves well to "modular-reasoning". By this I mean that in an arbitrarily large software project, I can look at one tiny bit of it and work out something of what it's doing.
Given that most large software projects are, in their totality beyond one person's conception, I'd say this was a highly desirable feature in a modern computer language. Features like AOP undermine this kind of modular reasoning by changing the semantics of code that was originally written (and tested) without the knowledge that it would be changed like that.
There are all kinds of invariants that programmers maintain when writing their code, and this kind of feature seems like a very good way of breaking them in all kinds of subtle ways. Welcome to Bug City.
Random comment: If you're interested, this is an OO language which seems to be genuinely well done.
Clean from the point of view of the person implementing the logging or DB transaction code, perhaps... but think about it from the point of view of the person debugging the system: at any method invocation in the original code, some other arbitrary code might run, with possibly arbitrary side effects, including possibly invoking other methods and/or changing instance variables in the object that's currently being used.
Of course, no sensible person would use this kind of feature in a way that would cause these kind of side-effects, but when debugging a system you don't know whether the original implementor was sensible. Perhaps they made a mistake (something I believe has been known to happen...).
The point is that by adding primitives like this, you've gone from building your system on solid building blocks to a foundation of shifting sands. An API that was stable before might be utterly demolished by a slightly injudicious use of this feature.
Those people in this thread comparing this feature to LISP macros were dead on... experienced LISP programmers use them seldom. As this says:
Do people really want to build reliable software using this sort of stuff?When will people realise that the most important thing in a programming language is to make it possible to reason about one part of it independent of another part? Most of the time spent developing a program is spent modifying code, not creating new code!
Unfortunately people don't realise this: they just want a way of hacking something existing into something different, cross their fingers and hope that it works when someone changes some other part of the system.
Sadly, it's not just AOP: some of the "usual" OO programming language features suffer this kind of problem too.
Then again, maybe I'm completely wrong, and AOP has a sound theoretical basis and has been created by someone with deep understanding of programming language developments over the last thirty years... someone please reassure me!
It's a pity the article doesn't make this clearer (instead, it just says "Searches take place in RAM, so there's no disk or database access", which makes it sound as if it would be faster!)
There's a reason people invented indexing schemes!
I don't think that is the issue. After all, with Java there's not necessarily any compilation going on at all (if it's not running in JIT mode) - it's just an interpreter, and the programs (the non-GPL program and the GPL'd JAR) are just inputs to that interpreter.
The GPL says:
It seems to me that anything that needs to use GPL software in order to be used cannot be considered independent of the GPL software, and hence must be distributed under the GPL license.How is an interpreted Java program that relies on a piece of external GPL code qualititavely different from (say) a document written with a GPL word processor (in a format specific to that word processor)?
I don't think it is... and I hence I can understand entirely the reluctance of Apple's lawyers to countenance the bundling of any GPL code with MacOS X...
Under Plan 9, on the other hand, you can always rearrange resources for a program: don't like the contents of that config file? Just bind another file over the top of it. Want a program to read a remote mouse rather than the local one? Just import the remote filesystem and bind the remote mouse on top before running the program.
No needless barriers!
(The astute amongst you will have realised that this is one reason why Plan 9 doesn't have set-uid executables, not something greatly missed.)
There are various bits of UNIX (and I include Linux here, as it's essentially a UNIX clone) that have been bolted on without regard for the elegance of the whole system. In particular, graphics, pseudo terminals and networking were all added late in UNIX's lifetime and considerably clutter the system and limit its capabilities.
Take the ubiquitous psueudo terminals as an example. Almost nobody actually uses a genuine VT220 (or whatever) as their input device. However, the output from every command-line program in UNIX goes through something that pretends to be such a device. The kernel has much elaborate stuff (the tty driver) built in to convince command line programs that they're talking to a real terminal. The kernel knows about command line editing, it knows how to print control characters nicely, and it knows what key means "word erase".
This is all crap! It adds unnecessary complexity to the kernel, and not only that, but every command line program that wants a a slightly more sophisticated interface (e.g. cursor-based editing) has to do it itself (c.f. GNU readline). This not only bloats the kernel and many of its applications, it also means that the commands are less versatile than they could be (requiring people to use tools like expect to demangle their output).
Under Plan 9, there are no special system calls devoted to terminals or networking: instead, the interface to device drivers is made more versatile (all you need is open, read and write to access a device driver, no fancy ioctls or fcntls required. This gets back to the original purity of the 7th Edition programming interface: programs are a joy to write, and once written can be put to many more uses, as the currency of command line programs (text written to stdin/stdout) is also the currency of device drivers.
Because everything is unified under one hood (the name space), I don't have to write a special program to get fancy functionality. Want to find out what programs have a particular file open? /proc/*/fd
grep filename
Plan 9 is all about the joys of writing less code, more cleanly, and finding it more useful when written; of having a box of tools that can be plugged together in a multitude of different ways, transparently and securely across networks; of having a clean user interface that is concerned principally with power and simplicity rather than appearance.
Of course in this day and age, when a word processor takes >2,000,000 lines of code and "features" are rated more highly than overall usability, it's not surprising that Plan 9 isn't that well known, or that Dennis Ritchie reverts to Windows NT in order to browse the web.
As for myself, I'll stick to Plan 9's (and Inferno's) deep joy for as long as I possibly can!
LOL!
Ok, you've got me! I haven't got a copy of the book and "groyne" was the best that google could offer by way of an extract.
Merkin would have been a better example, but the words themselves are nothing without the definitions they're given with, and associated suggested ways of using them..
Example
GROYNE n. ~ This is the correct term for one of those little wooden fences or brick walls that run down English beaches and out into the water for some distance, as a device to check the drifting of the same. Pronounced, and sometimes spelled, groin. "Shall we get together down by the groyne?"
Yeah, you "just" need to worry about synchronization, deadlocking, and other concurreny issues instead. Muuuuuuch easier. But what you said above made no sense to me (perhaps I need some more coffee) - can you explain this in more detail?
It depends on the thread abstractions that are used for synchronisation and thread communication. The most commonly used abstractions today (semaphores, locks, etc) date from the 1970s; there are much better ways to do it!
One way derives from a mathematical notation created by Tony Hoare, called CSP. There is one unit of thread communications and synchronisation, called a channel. It's like a rendezvous point that allows a value to be passed between threads. If one thread tries to send a value on a channel, it will block until another thread tries to read from the channel (also, reading from the channel will block until another thread tries to send on it).
This scheme is incredibly versatile, easy to use and cheap. There are also some tools that can aid in automatic verification of software built in this way. It's true that it's possible to deadlock in concurrent systems, but it's almost always possible to structure the system in such a way that it's deadlock-free by construction. For instance, if my program is structured as a one-way pipeline, it's impossible to deadlock.
Concurrency at this level in a GUI application can greatly enhance the simplicity and maintainability of a program. This is because it's generally much easier to write a straightforward piece of imperative code than encode the same thing as a state machine, e.g.
while (buttons != 0) {
(buttons, point) = <-mouse;
drawat(point)
}
(where <- receives from a channel), versus:
callback(buttons, point) {
if (state == DRAGGING) {
if (buttons != 0)
drawat(point);
else
state = NOTDRAGGING;
}
}
You say:
That would be the case if interaction was a parallel activity, but unfortunately it's not.
But it is! Yes, the user themselves only contributes one thread to the activity, but the program itself is often dealing with multiple activities at the same time; for instance updating itself in response to network activities or updating graphics on a time-step basis.
The most important thing it gives you, in my experience, is the sense of control. As a separate thread, you are free to structure your application in a way directly appropriate to the task being solved. In a callback system, you are at the mercy of the caller; you can't just wait for an event, then do the next thing, you have to encode your current state, return, and wait to be called back, whereupon you have to figure out where you just were!
For a language that exemplifies this, see Limbo, the language of choice in the Inferno environment. No problems with thread unsafe graphics there!
given that people usually compare hardware using benchmark tests (driver included), i'd imagine that it would be quite important that it be as fast as possible.
if you apply Occam's Razor at every opportunity, take every chance you can to cut down on the number of degrees of freedom, eliminate all choices that are not absolutely necessary, you will usually end up with something that is more intuitive, more powerful, easier (= cheaper!) to implement and has fewer bugs to boot.
in these days of 20 million LOC word processors, and "pile on every feature that we can think of" applications, simplicity is an underrated virtue.
think minimalist!
oh god, old memories:
Latin is a dead language,
As dead as dead can be.
It killed all the Romans,
And now it's killing me.
no it's not.
it's only undefined when used like:
a ^= b ^= a ^= b;
(or whatever it usually is, i haven't memorised it 'cos it's wrong!)
doesn't python have tuples, so you can do:
(a, b) = (b, a);
(caveat: i don't know python!)
the specs probably changed considerably from when i was doing this, but at that time, they were considering a network of 840 satellites! in some areas of the world you had maybe 10 or 20 satellites visible at once. if this thing had ever got off the ground, you'd have had some pretty spectacular displays around dawn and dusk.
what an amazing waste of money. personally i think that high altitude balloons sound like an excellent idea as a cheap alternative to behemoths like teledesic.
for instance CSP has a reasonable theoretical foundation and is infinitely nicer to program with than those locks and semaphors invented in the '70s...
here's a brief history and more accessible explanation. plan 9 has a nice C implementation.
so much nicer to program with!
factotum (plan 9's authentication agent) is not a single sign-on solution, although it can be when used in conjunction with secstore. what it does mean is that applications do not have to be burdened with complex and error-prone authentication code, and that there is one, well-verified, point in the system that holds secrets and understands the protocols.
in the factotum scheme, you can mark certain accounts (e.g. your bank account access) so that they will always require a password to be entered; you can also use the scheme without secstore (which is what i'm doing currently) which just forces you to type in each password the first time it's required. secstore is a means to store all your passwords in one place securely, which you can then use to prime factotum.
this is the essence of the plan 9 approach - choose an abstraction and write it in a simple, modular way so that it's applicable to a wide range of previously unanticipated scenarios. it's a wonderful system, and one that carries forward the true unix tradition, something that UNIX lost long ago.