[29313] in Perl-Users-Digest
Perl-Users Digest, Issue: 557 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Jun 22 18:10:20 2007
Date: Fri, 22 Jun 2007 15:09:09 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Fri, 22 Jun 2007 Volume: 11 Number: 557
Today's topics:
Re: array not working as a hash value. <noreply@gunnar.cc>
Re: array not working as a hash value. <bik.mido@tiscalinet.it>
Re: array not working as a hash value. <mritty@gmail.com>
Portable general timestamp format, not 2038-limited <james.harris.1@googlemail.com>
Re: Portable general timestamp format, not 2038-limited <lew@lewscanon.nospam>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <pjb@informatimago.com>
Re: The Modernization of Emacs: terminology buffer and <garrickp@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <bscrivener42@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: The Modernization of Emacs: terminology buffer and <twisted0n3@gmail.com>
Re: why we need perl6 if we have parrort? <bik.mido@tiscalinet.it>
Re: why we need perl6 if we have parrort? <bik.mido@tiscalinet.it>
Re: why we need perl6 if we have parrort? <spamtrap@dot-app.org>
Re: why we need perl6 if we have parrort? <spamtrap@dot-app.org>
Re: why we need perl6 if we have parrort? <uri@stemsystems.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 22 Jun 2007 22:13:32 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: array not working as a hash value.
Message-Id: <5e2p0rF36bahsU1@mid.individual.net>
Kaldrenon wrote:
>
> my %roxiecluster = (
> "1" => \@range_one,
> "2" => \@range_two
> );
<snip>
> foreach (@{$roxiecluster{$choice}}) {
> print "10.230.0.$_\n";
> }
>
> $roxiecluster{$choice} is scalar,
More exactly an array reference.
> but wrap it in @{...}
Dereference it...
> and it's an array again.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Fri, 22 Jun 2007 22:17:02 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: array not working as a hash value.
Message-Id: <cgbo73drh74075ie8d5ck2kvrknjbnelb9@4ax.com>
On Fri, 22 Jun 2007 11:15:44 -0700, usaims <usaims@yahoo.com> wrote:
>Subject: array not working as a hash value.
[snip]
>but its printing:
>1
>10.230.0.ARRAY(0x8105294)
You forgot dereferencing. See
perldoc perlref
for instructions about how to do so.
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Fri, 22 Jun 2007 20:52:33 -0000
From: Paul Lalli <mritty@gmail.com>
Subject: Re: array not working as a hash value.
Message-Id: <1182545553.660014.92650@z28g2000prd.googlegroups.com>
On Jun 22, 2:32 pm, Klaus <klau...@gmail.com> wrote:
>
> my @roxie = @{ $roxiecluster{$choice} };
>
> That should work.
>
> I remember vaguely that one has to use @{ ... } in those
> cases, but I can't find the exact reference anymore in perldoc
How ironic... :-)
perldoc perlref
"ref", for "references", you see.
Paul Lalli
------------------------------
Date: Fri, 22 Jun 2007 13:33:04 -0700
From: James Harris <james.harris.1@googlemail.com>
Subject: Portable general timestamp format, not 2038-limited
Message-Id: <1182544384.709759.235300@o11g2000prd.googlegroups.com>
I have a requirement to store timestamps in a database. Simple enough
you might think but finding a suitably general format is not easy. The
specifics are
1) subsecond resolution - milliseconds or, preferably, more detailed
2) not bounded by Unix timestamp 2038 limit
3) readable in Java
4) writable portably in Perl which seems to mean that 64-bit values
are out
5) readable and writable in Python
6) storable in a free database - Postgresql/MySQL
The formats provided by the two database systems are such as 8-byte or
12-byte values which, even if I could get Perl to work with I guess it
would be messy. Keeping to 32-bit values should give me portability
and be easy enough to work with without obscuring the program logic.
Since 32 bits of microseconds is less than 50 days I have to store two
32-bit values. How to split them? The option I favour at the moment is
to split days and parts of days like this:
a) store, as a 32-bit number, days since a virtual year zero (there is
no year zero in common era time <http://en.wikipedia.org/wiki/
Common_Era>). This allows over five million years plus and minus.
Still not completely general, I know.
b) store parts of days as another 32-bit value. Its range would have
to go to 86401 seconds - the number of seconds in a leap day. This
means each 'tick' would be around 21 microseconds. For regularity I
could make the ticks 25 microseconds so there would be 40,000 in a
second and 3,456,000,000 in a day; and, finally, the counter could
tick about 5 hours into the next day if not caught.
Any thoughts on a better way to do this? (Please reply-all. Thanks).
--
James
------------------------------
Date: Fri, 22 Jun 2007 17:38:52 -0400
From: Lew <lew@lewscanon.nospam>
Subject: Re: Portable general timestamp format, not 2038-limited
Message-Id: <XNqdnWj3rNjx3OHbnZ2dnUVZ_sfinZ2d@comcast.com>
James Harris wrote:
> a) store, as a 32-bit number, days since a virtual year zero (there is
> no year zero in common era time
<http://en.wikipedia.org/wiki/Common_Era>).
But according to the same article:
> (It [year zero] is, however, used in the astronomical system and ISO 8601.)
--
Lew
------------------------------
Date: Fri, 22 Jun 2007 20:47:48 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182545268.055596.228700@i38g2000prf.googlegroups.com>
On Jun 21, 12:11 pm, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> Twisted <twisted...@gmail.com> writes:
>
> >> But Emacs does not have a "clunky" interface.
>
> > That's for the everyday novice-to-intermediate user to decide.
>
> Why should the ignorant decide? Do you leave the decision of what great
> art is to 3 year olds and their doting parents?
Did I say it was for the "beginner" to decide? No, I said "novice-to-
intermediate".
How clunky versus usable an interface to a tool is is for those who
invest some, but not extraordinary amounts of, time into its use to
decide. If it requires years of mastery, it is clunky -- period. This
may be unavoidable if it's something involved in nuclear power plants,
delicate neurosurgery, or whatever. If it's a text editor, on the
other hand, it's clearly going to have superior competition in the
area of usability.
Besides, ANY interface that involves fumbling around in the dark
trying to find a light switch is clunky. You should be able to see
what the hell you're doing and navigate easily. Applications that not
only eschew normal methods of navigation of the interface, but force
you to fumble your way between the help and the task you're trying to
do, are definitely clunky. An analogy to a genuine emacs experience:
you enter a workshop with some raw materials and tools. Unfortunately
there's no big ceiling lights so you can just flip the switch by the
door and then always be able to see where everything is. Instead
there's little lights here and there by various specific tools and
storage areas, and in one area a map of the place with switches to
control the lights. So first you have to fumble around until you
happen upon the map/light controls. Then you need to (in the dark!)
hit the switch for the map/light control area itself. (Now you've
found the help and gotten it to be the active pane, er "window".) Now
you need to find the tool you want on the map -- OK, that was easy.
Now you turn on its light. Oh, hell -- the light on the map/light
controls has now gone out though! That also included the instructions
on using the specific tool. You can go to and use the one tool, if you
memorized those instructions, but then it's back to the darkness...
(You find the help on doing a particular thing, then can't get back to
the document to do it because of clunky navigation. So you go back to
the help on switching windows, and now you can flip back to the
document. Only you realize you can have the document and help open at
the same time, but the only time the document has focus is when the
help is open to "help on switching windows", which makes this rather
useless! You end up having to memorize the help, because *you can't
have arbitrary parts of the help and your document open side by side
and be working on the document*. All because you can't simply tab or
click to the document. At minimum, you have to *memorize* some arcane
key controls for switching panes ... er, "windows", that are totally
unintuitive and unlike what is normally used.
Oops. The interface design is a nightmare. The most basic requirement,
that it be easy to have the help open side by side with your document
and switch back and forth and navigate inside the help easily, is
broken. If you have to consult the help just to navigate the help or
to switch focus between document and help, then you're trapped, and
that is what happens with emacs.
I don't know why people keep harping about what version. It was
probably something in the low 20s, after an earlier try with one in
the upper teens. The interface never improved over that time -- the
biggest problem consistently being that whenever focus was
successfully transferred to the document window, the help window was
invariably open to the instructions for switching windows, so you
could never be doing something with the document and have the help for
that something available at a glance. Defeating the whole purpose of
having a help system. A separate printed manual would have been
better, if I could have spared the paper and toner, as I could hold
that off to one side of the monitor and flip through it and open it to
anywhere I wanted to, then go back to my document without even having
to think about it. Even though it would be at the price of no full-
text search capability -- not that I could ever get that to work in
emacs anyway. There was no apparent way to do a simple substring
search and click "next match" or "previous match" to navigate among
the hits...more arcane keypresses would be required, and as soon as it
showed you the first match inside the help, the keypress documentation
of course vanished.
As far as I can tell, it just is not and never was possible to get
started with emacs without a separate, outside-of-emacs cheat sheet,
or to be very productive at all without actually memorizing the damn
thing. Modern user interfaces require a minimum of memorization, most
of which is basic, standard stuff that is the same from one app to the
next, so you already know it all -- your clicks and double clicks,
your alt-tabs and alt-enter-for-properties etc.; application-specific
keyboard shortcuts can be learned as convenient. Infrequently used
commands you can stand to hunt for in menus. When you find you use one
frequently, you can try to learn the keyboard shortcut -- and you can
find it without even consulting the help, simply by finding the
command's menu item. Every time you want to use the command but can't
remember the shortcut you just find it in the menu and activate it
from there, and see the shortcut while you're at it, helping to
eventually memorize it. And the commonest sorts of File and Edit menu
items have near-universal shortcuts, the big variation tending to be
whether Redo is shift-ctrl-Z, ctrl-Y, nonexistent, or menu-only.
But you can start using it right away with low productivity, and
increase your productivity with proficiency and learning (optional)
shortcuts, chiefly those to the commands you happen to use a lot.
Not so emacs, or most other unix-heritage tools. Those you can't use
in any nontrivial way without ascending a sheer cliff of memorization
*first*, before doing a single useful thing.
One person elsewhere in this thread even went so far as to suggest
that to avoid having a similar hurdle with every application you just
use emacs for everything. If you like being claustrophobically trapped
in 80x24x8BPP instead of 1280x1024x32BPP, that may be your cup of tea.
Also if you like having zero productivity in every single task instead
of just one until you've scaled the El Capitan of user interfaces. On
the other hand, you can avoid having a similar hurdle with ANY
application by simply using standard GUI apps developed with Mac and
Windows users in mind. I hear they even have them for Unix now --
technically including everything written for MacOSX as well as modern
WMs on Linux and probably *BSD.
(Use emacs for everything? That's like suggesting I move all my tools
*into* that dark place with the screwy lighting system, rather than
*out*. Me, I'd rather just avoid that place, or if necessary bring in
a big bank of floodlights and install them, and the sensitive artiste
who originally architected it be damned. Which is what Xah started
this whole mess by suggesting, in effect.)
------------------------------
Date: Fri, 22 Jun 2007 21:00:50 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182546050.465987.115740@q19g2000prn.googlegroups.com>
On Jun 21, 12:09 pm, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> Twisted <twisted...@gmail.com> writes:
>
> >> > I have that exact URL now --
> >> >http://www.asktog.com/columns/027InterfacesThatKill.html
>
> >> Utterly unrelated to Emacs.
>
> > I think it is quite relevant. Clunky computer interfaces may not be so
> > dramatically dangerous, but they certainly can hamper productivity.
>
> You're quite right. Windows/Mac user interfaces are so clunky that they
> massively hamper productivity.
This is a joke, right?
> Emacs, OTOH, enables it. For example,
> C-s is search forward; C-r is search backward ('reverse'); C-M-s is
> search forward for a regular expression; C-M-r is search backward for a
> regular expression.
Aside from the collision with the standard in the case of C-s (should
be save focused document if it has unsaved changes), these present no
problem. The inability to find and use them without memorizing all
those keystrokes does present a problem.
> A Windows or Mac editor would have C-s for save,
> and that's it. It might have C-f for find, but it'd pop up a dialogue
> instead of offering an interactive search, causing a mental context
> switch.
Eh? In other words, it works the way it's supposed to. That dialogue
will ordinarily be modeless but floating, so you can get it out of the
way or use it to navigate the document, then edit the document without
having to close the dialogue, and avoid the dialogue disappearing
behind other things. New search can be typed in at the drop of a hat.
Some editors have regular expression searches. All have a
straightforward substring search. Generally if there's anything in the
least arcane (e.g. regular expression searches) there's a ? button to
pop up help, which goes directly to the search help. You can read this
and tab back to the search dialogue with ease, and get them side by
side without any mess or fuss. Of course the dialog offers search
forward and usually search backward. And it normally also offers
search-AND-REPLACE, to boot.
Is this somehow not "interactive" enough for you? Versus having to
memorize a bunch of keys. It also means no esc-meta-alt-ctrl-shift BS,
as the document window needs to have only a few bindings, such as C-f
and C-s, and only the one (C-f) for search; all the search bindings in
the one window in emacs get replaced by just one binding in the
document window and a bunch applicable to the find dialogue. And the
find dialogue can be operated without knowing the bindings by mouse,
and the bindings can be seen directly in the find dialogue by
underlined letters on button labels (see that underlined N in "find
Next"? It means you can hit alt-N while the dialogue has focus,
followed by alt-tab to jump to the document with the next occurrence
selected, or alt-N repeatedly to jump to later occurrences until you
see the one you want, just in case you have rodent allergies).
It has useful key bindings. It is also wise enough to make learning
them optional, so you can learn the ones that speed up your most
common tasks and spare the effort otherwise, where it would consume
more time than it would eventually save you (less common tasks). With
an emacs type interface, you only get to ignore the key bindings for
commands you will NEVER use, rather than ones you use but
infrequently. Forgetting the latter means a trip to the help every
time, also.
> Searching would interrupt one's flow of thought rather than being part of it.
Where does this come from?
------------------------------
Date: Fri, 22 Jun 2007 23:06:15 +0200
From: Pascal Bourguignon <pjb@informatimago.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <871wg3k8c8.fsf@thalassa.lan.informatimago.com>
Twisted <twisted0n3@gmail.com> writes:
> On Jun 21, 12:09 pm, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
>> Twisted <twisted...@gmail.com> writes:
>>
>> >> > I have that exact URL now --
>> >> >http://www.asktog.com/columns/027InterfacesThatKill.html
>>
>> >> Utterly unrelated to Emacs.
>>
>> > I think it is quite relevant. Clunky computer interfaces may not be so
>> > dramatically dangerous, but they certainly can hamper productivity.
>>
>> You're quite right. Windows/Mac user interfaces are so clunky that they
>> massively hamper productivity.
>
> This is a joke, right?
How do you call a Mac user interface that let a user work during 3
hours to do a simple modification to a MS-Word file that takes 15
seconds to do with emacs or a simple unix script?
--
__Pascal Bourguignon__ http://www.informatimago.com/
NOTE: The most fundamental particles in this product are held
together by a "gluing" force about which little is currently known
and whose adhesive power can therefore not be permanently
guaranteed.
------------------------------
Date: Fri, 22 Jun 2007 14:16:19 -0700
From: Falcolas <garrickp@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182546979.295368.146110@q19g2000prn.googlegroups.com>
On Jun 22, 3:06 pm, Pascal Bourguignon <p...@informatimago.com> wrote:
> How do you call a Mac user interface that let a user work during 3
> hours to do a simple modification to a MS-Word file that takes 15
> seconds to do with emacs or a simple unix script?
Would you mind elaborating on *what* took 3 hours to do, as opposed to
just throwing around unquantified numbers? Would you also mind
explaining the user's familiarity with the tools they were using on
the mac?
It's just as easy for me to say that it took me 30 minutes to simply
exit emacs, and use that to justify that emacs, and by extension
Linux, is a terrible tool.
------------------------------
Date: Fri, 22 Jun 2007 21:21:58 -0000
From: BartlebyScrivener <bscrivener42@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182547318.325617.16370@o11g2000prd.googlegroups.com>
On Jun 22, 3:47 pm, Twisted <twisted...@gmail.com> wrote:
> If it requires years of mastery, it is clunky
Well, now you keep harping on this, but it's just not true.
I use vim myself, but for purposes of this argument it doesn't matter.
If you take the Vim tutorial and use the help (which appears in a
split window anytime you want it), you can use Vim like any other text
editor within a day or so, especially if you use Cream, which is set
up to hold your Windows hands and act like any other Windows text
editor on the surface. But if you use Vim for YEARS you get better and
faster and more efficient precisely BECAUSE of its arcane
capabilities. If you are going to keep your hands on the keyboard
where they belong, if you REALLY want to go fast, then there's no
alternative to having complex key commands, which become second nature
over time, and take the place of repetitive, totally inefficient
mousing around.
You might enjoy this. Especially the link to an old essay called
"Interface Zen"
http://tinyurl.com/2da3om
rd
------------------------------
Date: Fri, 22 Jun 2007 21:42:43 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182548563.561252.82480@i13g2000prf.googlegroups.com>
On Jun 21, 11:06 am, jadam...@partners.org (Joel J. Adamson) wrote:
> And it's baloney! No one in my office that uses one of these supposedly
> user-friendly machines thinks that it's actually easy to use. They
> slam their keyboards and throw their hands up *every* day.
Because of bugs or the network going down or stuff like that, I'll
bet, not because they can't find out or remember how to do some basic
task.
That's entirely orthogonal to the issue of interface learning curve OR
interface ease-of-use. Emacs has deficiencies in both areas, if
principally the former. (For an example of the latter, consider
opening a file. Can't remember the exact spelling and capitalization
of the file name? Sorry, bud, you're SOL. Go find it in some other app
and memorize the name, then return to emacs. Now THAT is what I call
disruptive context switching. Meanwhile even the lowly Notepad
responds to "open" by displaying a list of text files and tools to
navigate the folder hierarchy without having to do it blind, while
still letting you blind-type a path if you remember it. And you can
also paste the path in from the clipboard. Unix systems don't even
*have* a proper system-wide clipboard and copy/paste capability. Under
X there's a weak, text-only imitation, which doesn't help you much
when you want to copy a selection from an image in a paint program and
paste it into a CAD or web-design or specialized image-manipulation
tool or whatever...you have to save it to a file and load it, which is
a pain in the butt and slowly clutters your hard drive with
"temporary" files you occasionally forget to delete.
> The only solution that really works is for people to _learn_ how to
> use computers, and to accept that it will be a challenge.
How much learning it takes can be varied by the programmer, however.
They can choose to make the learning curve steeply vertical at
takeoff, or they can make it start out shallow and climb steeply only
when the user desires expert functionality. (They can also, stupidly,
choose to leave out fancier functionality entirely, of course.)
As for bugs and other frustrations, better robustness in the key areas
of memory management and concurrency control is needed. Most serious
(especially crash-causing, data-losing, or data-corrupting) bugs
involve memory mismanagement and a lot more, as well as other serious
bugs, result from race conditions. These sorts of bugs are also
responsible for a lot of security holes -- buffer overrun exploits are
only possible against targets with memory management and input
validation bugs. Java apps, due to Java's memory management model, are
immune to these.
The Windows world may have a fair bit to learn from the Unix world
about software reliability and QA, and also about better supporting
task automation. But not about user interface design for when tasks
are done manually.
> And as for the arcane commands needed to get to the help page, their
> on the splash screen. Have you used Emacs recently?
Of course not. It's too hard to get started using it, so I gave up on
it years ago.
------------------------------
Date: Fri, 22 Jun 2007 21:51:34 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182549094.366282.286740@m37g2000prh.googlegroups.com>
On Jun 21, 12:03 pm, Robert Uhl <eadmun...@NOSPAMgmail.com> wrote:
> Twisted <twisted...@gmail.com> writes:
>
> >> Emacs is amazingly beginner-friendly for the power and flexibility it
> >> provides. [snip]
>
> > That's a joke, right? I tried it a time or two. Every time it was
> > rapidly apparent that doing anything non-trivial would require
> > consulting a cheat sheet. The printed-out kind, since navigating to
> > the help and back without already having the help displayed and open
> > to the command reference was also non-trivial.
>
> C-h i, C-x b RET is non-trivial?!?
Let's change that so that you see it the way most human beings see it:
> > navigating to
> > the help and back without already having the help displayed and open
> > to the command reference was also non-trivial.
> Erh h, dhsd f hHE is non-trivial?
I'm sorry. I don't speak Chinese.
I trust I've made my point. Not only does it insist you learn a whole
other language (though I'm guessing it's not actually Chinese --
Greek, maybe), even when you know that's a bunch of keystrokes and
even what they are...
HOW IN THE BLOODY HELL IS IT SUPPOSED TO OCCUR TO SOMEONE TO ENTER
THEM, GIVEN THAT THEY HAVE TO DO SO TO REACH THE HELP THAT WOULD TELL
THEM THOSE ARE THE KEYS TO REACH THE HELP?!
I suppose it just pops in there by divine inspiration? Or it's
supposed to be self-evident to anyone who has TRUE wisdom? Or maybe
it's just expected that you be mentored by an expert, who would know
that arcane incantation and could pass it on to a new student. Well
I've got news for you buddy -- there's no such thing as divine
inspiration, it's not self-evident, and most people can't afford (if
they could find) a tutor just to learn how to use A TEXT EDITOR.
Of course, Notepad is so easy to use it doesn't even need help,
despite which it's readily available. In case you forgot the bog-
standard (and therefore it IS self-evident) "F1" there's even a "Help"
menu in plain view as soon as you open a Notepad.
This is the lowly Notepad, which I'll freely admit is the rusty
bicycle of text editors, and it's much easier to use (including the
help) than the supposed Mercedes-Benz of editors.
[remainder snipped, apparently describing some piece of software that
presents you automatically with an emacs tutorial if you start emacs
while it's running. I've seen emacs a few times in my day but never
whatever unnamed piece of software is being referred to here...but it
does occur to me that a context-sensitive auto-popup cheat sheet tool
would be useful on the typical unix system!]
------------------------------
Date: Fri, 22 Jun 2007 22:03:51 -0000
From: Twisted <twisted0n3@gmail.com>
Subject: Re: The Modernization of Emacs: terminology buffer and keybinding
Message-Id: <1182549831.068658.123870@i13g2000prf.googlegroups.com>
On Jun 21, 10:52 am, Bjorn Borud <borud-n...@borud.no> wrote:
> [Twisted <twisted...@gmail.com>]
> |
> | Being beginner-friendly doesn't have to be at the expense of power or
> | expert-user usability.
>
> depends on your definition of "expert". :-)
Well, admittedly, if your definition of "expert" is "elitist pig who
considers beginner-hostileness itself to be a required feature in
order for him to regard the software as usable", then you may be
right.
That sort of negative-sum thinking is alien to me. Software being easy
for beginners to get started using does not in and of itself detract
from its value to expert users. Only if they "value" such perverse
things as "being one of the exclusive club that can actually manage to
use this thing" does any of this make sense. That's a form of
artificial scarcity, and as I think I've mentioned before, artificial
scarcity is one of the more major roots of evil.
------------------------------
Date: Fri, 22 Jun 2007 22:09:47 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: why we need perl6 if we have parrort?
Message-Id: <p2bo73t5nn1s4u2ub5usqfdgo92q8dkrn0@4ax.com>
On Fri, 22 Jun 2007 23:32:22 +0800, "sonet" <sonet.all@msa.hinet.net>
wrote:
>1.Why we need perl6 ? We can learn how to coding in PIR direct.
Why we need C? We can learn how to coding in assembler direct.
>2.Why not convert perl5 to PIR (convert to Parrot bytecode)?
5.12
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Fri, 22 Jun 2007 22:14:57 +0200
From: Michele Dondi <bik.mido@tiscalinet.it>
Subject: Re: why we need perl6 if we have parrort?
Message-Id: <j5bo73lmvm6qubpooe0rk1v6f4qtqg68nv@4ax.com>
On Fri, 22 Jun 2007 11:41:03 -0700, "Clenna Lumina"
<savagebeaste@yahoo.com> wrote:
>Why did they go with parrot instead of just augmenting the existing Perl
>interpreter. Using Parrot (or any 3rd party interpreter) just kinda maks
Because the existing Perl interpreter has already been augmented to a
point that the language proper is defined by the implementation, and
hacking the latter is far from being a trivial task.
>it feel less like Perl in a way; not as "pure" as Perl5 and ealier :)
Because Perl 5 already runs on a bytecode, but with shortcomings.
Parrot aims at clearly separating the two levels...
Michele
--
{$_=pack'B8'x25,unpack'A8'x32,$a^=sub{pop^pop}->(map substr
(($a||=join'',map--$|x$_,(unpack'w',unpack'u','G^<R<Y]*YB='
.'KYU;*EVH[.FHF2W+#"\Z*5TI/ER<Z`S(G.DZZ9OX0Z')=~/./g)x2,$_,
256),7,249);s/[^\w,]/ /g;$ \=/^J/?$/:"\r";print,redo}#JAPH,
------------------------------
Date: Fri, 22 Jun 2007 17:37:12 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: why we need perl6 if we have parrort?
Message-Id: <m2hcozy8l3.fsf@dot-app.org>
"Clenna Lumina" <savagebeaste@yahoo.com> writes:
> Why did they go with parrot instead of just augmenting the existing Perl
> interpreter.
Because the existing code base is huge and brittle - as a result of twenty-
odd years since Perl 1 of "just augmenting" it. There was a very real need
to do a major ground-up rewrite.
> Using Parrot (or any 3rd party interpreter) just kinda maks
> it feel less like Perl in a way; not as "pure" as Perl5 and ealier :)
Parrot isn't a 3rd-party interpreter.
sherm--
------------------------------
Date: Fri, 22 Jun 2007 17:38:22 -0400
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: why we need perl6 if we have parrort?
Message-Id: <m2d4zny8j5.fsf@dot-app.org>
Michele Dondi <bik.mido@tiscalinet.it> writes:
> On Fri, 22 Jun 2007 23:32:22 +0800, "sonet" <sonet.all@msa.hinet.net>
> wrote:
>
>>1.Why we need perl6 ? We can learn how to coding in PIR direct.
>
> Why we need C? We can learn how to coding in assembler direct.
Why do we need assembler? We can learn how to coding by flipping toggle
switches on an operator console.
sherm--
------------------------------
Date: Fri, 22 Jun 2007 21:47:24 GMT
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: why we need perl6 if we have parrort?
Message-Id: <x7aburirv7.fsf@mail.sysarch.com>
>>>>> "SP" == Sherm Pendley <spamtrap@dot-app.org> writes:
SP> "Clenna Lumina" <savagebeaste@yahoo.com> writes:
>> Why did they go with parrot instead of just augmenting the existing Perl
>> interpreter.
SP> Because the existing code base is huge and brittle - as a result
SP> of twenty- odd years since Perl 1 of "just augmenting" it. There
SP> was a very real need to do a major ground-up rewrite.
actually perl5 was a complete rewrite by larry and didn't share any
source code with perl4.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 557
**************************************
