WebDragon's Friends' Journals

use Perl; Shutting Down Indefinitely

pudge — 2010-09-08T22:07:47+00:00

Amiga Ethernet

scrottie — 2010-08-25T20:09:48+00:00

Yesterday, I got my X-Surf 3cc Ethernet card I broke down and ordered for my Amiga 3000. There's some backstory about serial consoles, Sparcs, and the cluster, but it's not important. The 3000 was also packaged as a Unix machine, running a pretty standard port of SysV. It was the first Amiga standard with an MMU and SCSI. It'll also kick out 1280x resolution graphics at 2bpp. Commodore sold an Ethernet board for it along with Unix on tape.

The X-Surf is really an ISA card, probably NE2000, mounted in a little carrier. There are confusingly few pins attached and the logic on the carrier amounts to a few small 7400 series chips and one slightly larger chip that also couldn't possibly have enough logic on it to do what it does. And then just to convince you that your nuts, it adds an IDE port that alone has more lines than the one little adapter chip does. The Amiga really is a machine for psychopaths, by psychopaths. Everyone sits around all of the time trying to out psycho everyone else. Just take a look at the demo scene for the thing. Amiga virtually defined the demo scene.

I have/had Amiga OS 3.9 on the thing. 3.9 is post-Commodore death. Someone bought the rights and sold them and someone bought them and sold them and so on until a sue happy band of self righteous ruffians managed to convince the remaining user base buying the rights at garage sale prices entitled them to be king of the squalid kingdom so that they could go around lynching anyone else trying to do anything for the Amiga. Anyway, OS 3.9 is pretty recent as far as Amiga stuff goes, even though it's ten years old. Most people stopped at 3.1. 3.9 only came out on CD-ROM. The 3000 doesn't have a bay but it does have SCSI, so the CD-ROM, when needed, gets hung off the side with the case open. I could also set up an enclosure and plug it into the back. I could also probably buy one of those.

X-Surf's stuff did not want to install.

X-Surf actually had an installer, which is impressive. AmigaOS 3.x has a scripting language for installers and an interpreter for that. This installer gave you the choice of two TCP stacks. AmigaOS 3.9 comes with a TCP stack but you can still swap it out. It's a bit Windows 3.1-like in that regard. The options are GENESiS/AmiTCP and Miami. GENESiS, the AmiTCP configurerer and dialer that cames with AmiTCP, was shipped in a version requiring libraries not included in AmigaOS3.9 so it wouldn't run. AmiTCP would, and AmiTCP was on the HD, though buried a bit. Miami is shareware/crippleware. It required the same library, MagicUI, that I didn't have.

I spent hours sorting out what required what and what I did and didn't have and how these various packages worked and fit together. That's ignoring the device driver for the ethernet card which is straight forward. The Amiga has a directory for libraries (which end in .library; the Unix terseness is missing from AmigaOS even though a lot of the feel is there). AmigaOS3.9 also won't read iso9660 filesystem CDs. Perhaps some BoingBag update fixes that but the BoingBag updates themselves are large .lha archives. I'm avoiding plugging the serial line into a Unix machine and speaking kermit or zmodem or something to transfer stuff. I've been down that road. Eventually I burned AmigaSYS4, a version of AmigaOS3.9 with lots of add-ons and the various BoingBag updates on it, stick it in the Amiga, and was able to steal MUI off of it and get both TCP stacks running.

Amiga programmers love to do ports of Unix software and add GUIs. They've been doing this for ages. They've had gcc since the early ages of gcc, and I ran the Amylaar MUD driver on AmigaOS 1.3 to do development locally, also in the dark ages. Kicking around on aminet.net from the Amiga, I see PHP, MySQL, Apache, bittorrent, Python, bind9, samba, VNC, and all sorts of stuff. No one ports just the client. If they port the client, they port the server, too. In the case of AmiTCP, the suite of utilities you'd expect are there, such as host, finger, traceroute, and so on, but to configure TCP/IP, you run a little GUI program and it asks you questions. It took Linux ages to get to this point and Amiga was doing it long before. One of the extras on the Extras disc, even as far back as 1.3, was a version of emacs with drop down menus.

Completely unsurprisingly, the 16mhz 68030 processor running AWeb (which does some JavaScript) is vastly faster than firefox on my 1.2ghz Centrino Linux machine. Amiga programmers do not write slow software. It's entirely against their nature. Threading is fantastic. It'll do downloads, render several jpgs in the page, update the page layout as HTML comes across, and never lose snappy UI responsiveness. On firefox, I yank on the scrollbar only to have it ignore me and snap back, or else the scroll bar doesn't move at all, or the whole thing just goes away for a few heart sinking seconds, making me wonder if it just crashed.

My ambition is to get a desk in a shared office space going and stick this baby there with an updated video card that does high res, high bit depth graphics. If I'm willing to start replacing and upgrading chips on the motherboard, I can take the thing up to a gig of RAM, too, and NetBSD supports it if I ever decide I want to see how firefox runs on a 16mhz processor. What I'm really hoping for is someone to take the latest Coldfire chips from Motorola's spin off, Freescale, and do an 800mhz accelerator card for the Amiga 2000/3000/4000. That would RULE.

-scott

How I spent my day today (or, slowass.net pops a hole)

scrottie — 2010-08-17T05:30:44+00:00

1. Ran backups
2. Verified integrity of ssh on my local system versus last backup; changed local passwords
3. Verified integrity of my linode chpass with md5sum versus previous backup
4. Locked accounts; fixed changes to shell for system programs, removed additional accounts, changed passwords
5. Killed root processes and shells; accounted for all of the shells and processes in ps
6. Compared md5sums of everything in ps, login shells, rsync, inetd, su, vmlinuz, ps and various things between previous backup and current
7. compared nmap to netstat -lnp; accounted for netstat -lnp entries
8. Ran find to find setuid/setgid programs; verified no additional ones exist; ran md5sum against existing ones
9. Replace sshd, ssh and their config files and host keys; restarted sshd; relogged and changed passwords
10. Upgrade sshd
11. Killed .ssh directories
12. Temporarily took some services down until I can decide if I trust/replace them (squid, cron, sendmail)
13. diff -r'd between the two backups; read through the output to account for all changes to the system (new files and changed files) (several notable)
14. Ran find to find world writable files; ran find to find device files in the wilds of the filesystem

use Perl;

pudge — 2010-08-11T23:34:11+00:00

I am no longer working for Slashdot/Geeknet as of September 30. I am actively seeking new employment. Unless you want to hire me, you don't need to care, unless you also care about use Perl;, because it has been generously hosted by Geeknet since I started the site over 10 years ago, shortly after I was hired by Andover.Net to work on Slashdot.

Long story short, I have not done much with the site in recent years, so my options at this point are to do nothing; migrate the site to a new server and keep it running as-is; or take the data and do something with it on a new site. Or something I haven't thought of.

I am hereby accepting proposals for what to do with use Perl;. In short, I would like to donate it to someone who will give it a good home. If you're interested, give me your best pitch.

Cross-posted on <pudge/*>.

Matt Trout, aka mst, is insane

pudge — 2010-08-11T16:41:54+00:00

Wow. I occasionally, but not too often, go into #perl. Very busy with family and life. So I go in today, and for no reason, mst bans me and tells me to not come back.

What's up with him being such an irrational dick?

My reply to Removing database abstraction

scrottie — 2010-08-06T21:53:04+00:00

My longwinded response to http://blogs.perl.org/users/carey_tilden/2010/08/removing-database-abstraction.h tml :

Don't get trapped in the mindset of "I have to use X because if I don't, I'm doing it wrong". Quite often, if you don't use X, it's entirely too easy to do it wrong if you don't know what you're doing. You probably don't want to re-implement CGI parameter parsing, for example. But that's not the same thing as saying that you should always use CGI because it's a solved problem so never do anything else. Nothing is a solved problem. mod_perl is a valid contender to CGI and now Plack is a valid contender to mod_perl. FastCGI was and is a valid contender to mod_perl and servers like nginx do awesome thing. Yet, tirelessly, the fans of one explain that the competing ideas are somehow not valid.

Sorry, I'm trying to do proof by analogy here. It isn't valid except to the degree that it is. I'll get to databases in a minute.

Quick recap: there are lots of valid approaches; using an alternative is not the same as re-inventing the wheel.

Furthermore, the heaviest technology is seldom the long term winner. Witness the return to lighter HTTP pipelines. For ages, Apache boasted being a bit faster than IIS, in response to which I could only wonder why Apache was so slow.

Okay, back to databases. DBIx::Class to a relational database is a valid option. It's also very heavy. It alo doesn't really let you scale your web app out unless the database in question is DB2, Oracle, or one of a few of those that runs on a cluster with a lot of processors rather than just one computer. Otherwise you've just added a new bottleneck. DBIx::Class makes it harder to do real relational work -- subqueries, having, or anything hairy. At the very least, you have to create a class file with a lot of boilerplate, reference that file from other files that you made or generated, and stuff the same SQL into there. Abstracting the querying away in simple cases makes it easier to query the database without thinking about it. This leads you to query the database without thinking about it. That's a double edged sword. In some cases, that's fantastic.

Lego blocks make it easy to build things but you seldom buy home appliances built out of Legos. Even more so for Duplo blocks. Some times easy tools are in order; some times, low level engineering with an RPN HP calculator is absolutely in order.

Okay, I'll get back to databases in a minute here, but I want to talk about something outrageous for a moment -- not using a relational database at all.

I wrote and use Acme::State for simple command line and daemonized Web apps. It works well with Continuity and should work with the various Coro based Plack servers for the reason that the application stays entirely in one process. All it does is restore state of variables on startup and save them on exit or when explicitly requested. It kind of goes overboard on restoring state and does a good enough job that it breaks lots of modules if not confined to your own namespace, hence the Acme:: designation.

Similarly, people have used Data::Dumper or Storable directly (Acme::State uses Storable under the hood) to serialize datastructures on startup and exit. In AnyEvent frameworks, it's easy to set a timer that, on expiration, saves a snapshot. Marc Lehmann, the man who created the excellent Coro module, has patches to Storable to make it reenterant and incremental, so that the process (which might also be servicing network requests for some protocol) doesn't get starved for CPU while a large dump is made. His Perl/Coro based multiplayer RPG is based on this idea. With hundreds of users issuing commands a few times a second, this is the only realistic option. If you tried to create this level of performance with a database, you'd find that you had to have the entire working set in RAM not once but several times over in copies in parallel database slaves. That's silly.

You can be very high tech and not use a database. If you're not actually using the relational capabilities (normalized tables, joining tables, filtering and aggregating, etc), then a relational database is a slow and verbose to use (even with DBIx::Class) replacement for dbmopen() (perldoc -f dbmopen, but use the module instead). You're not gaining performance, elegance or scalability, in most cases. People use databases automatically and mindlessly now days to the point where they feel they have to, and by virtue of having to use a database, they have to ease the pain with an ORM.

Anytime someone says "always", be skeptical. You're probably talking to someone who doesn't understand or doesn't care about the tradeoffs involved.

Okay, back to databases. Right now, it's trendy to create domain specific languages. The Ruby guys are doing it and the Perl guys have been doing it for ages. Forth was created around the idea -- the Forth parser is written in Forth and is extensible. Perl 5.12 lets you hijack syntax parsing with Perl in a very Forth-ish style. Devel::Declare was used to create proper argument lists for functions inside of Perl. There's a MooseX for it and a standalone one, Method::Signatures. That idea got moved into core. XS::APItest::KeywordRPN is a demo. Besides that, regular expressions and POD are two other entire syntaxes that exist in .pl and .pm files. It's hypocritical to say that it's somehow "bad" to mix languages. It's true that you don't want your front end graphic designer editing your .pl files if he/she doesn't know Perl. If your designer does know Perl, and the code is small and doesn't need to be factored apart yet, what's the harm? It's possible to write extremely expressive code mixing SQL and Perl. Lots of people have written a lot of little wrappers. Here's one I sometimes use:

http://slowass.net/~scott/tmp/query.pm.txt

Finally, part of Ruby's appeal -- or any new language's appeal -- is lightness. It's easy to keep adding cruft, indirection, and abstraction and not realize that you're slowly boiling yourself to death in it until you go to a new language and get away from it for a while. The Ruby guys, like the Python guys before them, have done a good job of building up simple but versatile APIs that combine well with each other and keep the language in charge rather than any monolithic "framework". Well, except for Rails, but maybe that was a counter example that motivated better behavior. Look at Scrapi (and Web::Scraper in Perl) for an example.

Too much abstraction not only makes your code slow but it makes it hard to change development direction in the future when something cooler, faster, lighter and more flexible comes out. Just as the whole Perl universe spent ten years mired down in and entrenched in mod_perl, so is there a danger that DBIx::Class and Moose will outlive their welcome. POE, which was once a golden child, has already outlived its welcome as Coro and AnyEvent stuff has taken off. Now there are a lot of Perl programs broken up into tiny non-blocking chunks that are five times as long as they could be, and the effort to move them away from POE is just too great. The utility of a package should be weighed against the commitment you have to make to it. The commitment you have to make to it is simply how much you have to alter your programming style. With Moose as with POE, this degree is huge. DBIx::Class is more reasonable. Still, it's a cost, and things have costs.

Thank you for your article.

Regards,
-scott

DEFCON, day 1

scrottie — 2010-07-30T19:43:53+00:00

Basically no mischief or craziness. Having DEFCON at a casino did to it exactly what I would have expected. No money pots to eat the cockroach, no naked fire jugglers, no getting thrown in the pool, no parties by the pool.

Bros outnumber the blackshirts now. They're talking loudly and proudly about how little they know and care.

Kilts are representing, too. The freaks are here. There's a Japanese gang dressed in kimonos. Some other Japanese guys walked by talking vigorously amonst themselves, laughing and pointing. Punks with combs, raisers and hairspray are in the contest area/lounge dispensing mohawks. They have their own official area. Strange hats abound. One kid has a fez. There are BDUs and lab coats. Lots of colored hair.

Aha! Finally spotted someone I knew -- Kevin, a friend of Ernie's, who also worked in the gaming industry, but on a different side of it.

People are sitting next to me reading long hex strings from the "background" of the talks description book.

They ran out of badges as usual. My flight got delayed two hours which seriously cut into my time here.

"My only crime is that of outsmarting you"... shirts have slogans.

There's a lot less interesting in WiFi and a lot more in smartphones. The common area is woefully inadequate.

UnixSurplus is here again and people are packing in to see old Unix hardware. Some people are going to be coming home with O2s.

More later, perhaps.

-scott

OpenSSI cannot find NIC with static node configuration

scrottie — 2010-07-14T18:10:34+00:00

Pasting an email reply since everyone seems to be stumbling over this one:

----

I've had this problem too.

This happens when the driver for the NIC on that machine isn't included in /etc/mkinitrd/modules. When the node boots, it can't find the NIC card
because it doesn't have a driver for it, and since it can't find the NIC
card, it doesn't know the MAC address, and without the MAC address, it
can't configure the node. Without the NIC card, it can't connect to the
initnode.

You can add the names of the NIC devices for all of the machines during
install, or you can add them before you boot the other machines into the
cluster and then run 'mkinitrd -o /boot/initrd.img-2.6.14-ssi-686-smp 2.6.14-ssi-686-smp'
(adjusted to match your kernel version, see 'uname -a') and run 'ssi-ksync'.

It's possible to add the correct device names and rebuild initrd but still
the node won't find the NIC or MAC address. For some reason, some drivers
just don't work correctly with how OpenSSI configures nodes. The e100 and
e1000 don't work correctly with OpenSSI for configuring nodes. I got a
bunch of 3com 3c509 cards and stuck those in the nodes and use only those
for the cluster interconnect, for now. Later I hope to get Infiband going.

So, make sure /etc/mkinitrd/modules has the correct driver in it,
rebuild initrd, ssi-sync, and if all else fails, use some old 3com
cards.

Good luck!
-scott

Perl 6 Design Minutes for 30 June 2010

chromatic — 2010-07-03T08:13:30+00:00

The Perl 6 design team met by phone on 30 June 2010. Allison, Patrick, and chromatic attended.

Allison:

working on Parrot packages for Debian experimental
seems like a good idea to do that before the 2.6 supported release
there was also a request for Rakudo packages
not sure if I'm the best person to do it

Patrick:

I'm sure we should package Rakudo Star

Allison:

Debian had a packager for those, but I haven't looked at the packages
this'd be an early run of what we'll do with Rakudo Star

Patrick:

we're not quite ready for packaging that yet
maybe a couple of weeks
finished the List and Iterator types for the #30 release
adjusted Rakudo's Associative and Positional roles
much cleaner implementation now
that'll require a few small spec changes
redid Rakudo's container types
more robust
preparing for autovivification of hashes and arrays
expect to finish those in the next couple of days
there was no container model previously; the code was consequently crufty
lots of cleanup of incorrect assumptions
Rakudo lists are now properly lazy
comment syntax fixed
ROADMAP updated
fixed the meaning of Nil; it's defined, not undefined
added the sink prefix (?)
fixed setting of $!
started fixing bugs and closing tickets on Monday, did 15 or 20
mostly already fixed in the previous couple of weeks
looking at the implementation of the series operator
spec is self-contradictory or ambiguous or both
waiting for Larry's clarification
fixed a bug in $*ARGFILES
had a nice contribution of that implementation last week
that behavior works on any set of files, not just those on the command line
working on autoviv
have some regex backtracking bugs to fix
will work on closures after that
put together three new YAPC presentations
the Rakudo Star presentation will become a video cast or a blog post or both

worked on a slew of Parrot optimizations for Rakudo
have a few more to go
might have to create a Rakudo branch temporarily
will try to help merge the new GC
working on a metamodel for Parrot objects, informed by Perl 6 and Moose

Modern Perl: The (Draft) Book

chromatic — 2010-06-28T23:43:33+00:00

This took longer than I expected, but the draft of the Modern Perl book is available for review. I'm especially interested in hearing from people who don't consider themselves expert Perl 5 programmers. The goal of the book is to explain how Perl 5 works (and how to write Perl 5 effectively) to help novices become adepts.

Perl 6 Design Minutes for 16 June 2010

chromatic — 2010-06-26T17:07:30+00:00

The Perl 6 design team met by phone on 16 June 2010. Larry, Allison, Patrick, Will, and chromatic attended.

Larry:

documented TOP (again), and explained how parsing is initiated and how it actually works
series operator (...) now picks a monotonic function when using single characters as endpoints
STD can now catch duplicates involving protos as well as onlys
STD no longer advises removal of parens on spaceless sub() declaration
mostly advised sorear and pmichaud
Stefan is finishing the boostrap of the STD parser
also working on adding a parallel NFA and DFA engine
no, he doesn't want to generate all the states in advance
it works faster lazily

Allison:

working on chroot environments with something more secure than chroot
relevant to building Parrot packages
looking at some bugs for Will

Patrick:

Rakudo developers decided not to make extra special effort to make a June release of Rakudo Star
the calendar works against us
the new date for the release is July 29
we're I comfortable with hitting that target
we won't be happy with the results of moving heaven and earth to release in June
there are lots of advantages
one disadvantage is not having Rakudo Star at YAPC::NA
one big advantage is using the supported Parrot 2.6 release as the basis
I'll write a post outlining the plan in the next couple of days
otherwise working on lists and interators in Perl 6 and Rakudo
after deciding to make iterators immutable, Larry and I realized that solves many problems
everything works out as plain as day after that
very happy with that design
the incorrect assumptions of the old model were pervasive
replacing the old pieces is taking a while, which is no surprise
this approach feels right though
the new branch does things no previous version could do
slices work much better, for example
metaoperators work properly
map is lazy
slurpy arguments in lists are lazy by default
no weird binding or action at a distance problems
plenty of changes to Associative and Positional roles
those are now super clean and may be lazy
more features work
~30 failing tests (not test files, just tests) now, ~500 last night
most of the current failures are minor
will try to merge the branch before the release
replacing lots of ugly code with fewer lines of elegant code
Jonathan and others have worked on lots of other pieces
adding plenty of new features
looking forward to tomorrow's release

editing the Rakudo book
moving the Rakudo release date may let us have a printed book available about the same time
depends on how much there is left to write

PerlMongers group organization lessons

scrottie — 2010-06-25T19:58:45+00:00

My pasted reply to a yapc mailing list message:

Missed this BoF too. I've written a lot about my experiences with
Phoenix.PM. As far as I can tell, the key ingredients are:

* organizer with the right personality
* audiance happy with social meetings or else a few people willing to present over and over year after year
* central location to minimize excuses from people who have families to go home to
* core people to attend so the thing doesn't bottom out while it's ramping up

We had a mix of people hoping the meetings would have tangible,
immediate improvements to their career (more immediate than teaching
them awesome Perl hackery, such as recruiters standing by),
maintenance programmers whose life with Perl just sucks and won't
be made by happy that doesn't just take a rotorooter to their
codebase, weirdos like Marlana from Fight Club who just go to every
meeting in town but never actually do anything or have any personal
interest in any of it, and hip kids looking for the cool thing.
Most of these groups saw we had nothing to offer (only awesome
technical presentations) and never came back.

-scott

Perl is Dead - the supply lines have been cut

scrottie — 2010-06-25T05:55:21+00:00

I wrote this once and it didn't post (that often happens here, in various scenarios) or else it got deleted. Assuming the former. Here's a super short version of the same thing. The first go was much better. Dammit.

* College CS departments are owned by Microsoft and Sun. They use C# and Java out of consideration for strings-attached grant money.

* Highschool and gradeschool kids learn PHP, jquery/JS, Squeak, Processing, Flash, or Python/PyGame. Perl has a foot in the web world (though not the appeal to the ultra-low-brow user base) but virtually no foot in the playing with graphics department. SDL is okay but it isn't easy enough or flashy enough to compete.

* Perl teams are small. Fewer people are hired to do a project compared to Java -- radically fewer. And companies hire almost exclusively senior level Perl programmers. It's hard to get a toe hold in the industry. You virtually have to publish a lot of great stuff on CPAN to get a job. Strong typing in Java I think makes it easier to integrate weaker programmers into a team and keep them from doing damage. They aren't kept out of your living room with a shutgun but with locked doors. Compartmentalizing the code, it's harder for someone new or intermediate to do damage; they just do or don't succeed. That's a big improvement.

* There is no perception that there's a lot of money to be made writing Perl. Java jobs with far lower expectations have paid me personally far better than Perl jobs with high expectations. Really good Perl programmers don't get actively recruited away. Countries with developing economies aren't tooling up on Perl and Perl companies aren't sponsoring H1B visas. Nor are Perl companies making long term investments in employees and letting them spend years only marginally productive with the idea that they'll be there for 10 or 20 years. Perl jobs just tend not to be that "milk". We all have just one battle story after another complete with scars. The lack of promise of money plus comfortable employment does not draw in adults in over Perl's job market.

* Relatedly, no one is out there just making cool stuff in Perl and saying, "Hey, look what Perl can do". Yahoo! Pipes is Perl and it's way awesome but they aren't playing up the Perl bit and there are precious few examples of this. People's perceptions would be that Perl is only used for big, cranky, serious old web apps. And they'd mostly be right.

* Perl was and perhaps still is the language of choice for system administration on Unix but other things are competitive in this field now. This is probably the largest avenue by which people discover and learn Perl -- Unix admins. Shops that do a lot of Unix administration probably still take non-programmers and tell them to learn Perl.

* Microsoft, Sun, IBM (SAP really wins here) are buying their customers lunch and being buddy-buddy with them. They're listening to them, agreeing with them, sympathizing with them, and drinking with them. In this regard, Perl doesn't even exist. Microsoft and Sun get a lot of money from companies but they don't just walk over with their hand out -- they woo them. This is a bonus point that's unrelated to the main point.

Want to kill something? Cut the supply lines. There's precious few new projects using Perl (neither large business nor garage style maybe-the-next-Twitter type). The avenues by which people have discovered Perl in the past have almost entirely been closed off. Nothing dies quickly. COBOL is still around. COBOL is even in demand -- the dearth of new people learning for the amount of legacy code out there itself creates demand. Except for system administration (I don't know, what else can you think of? Where do people come from?), our lines have been cut.

As I wrote in the last post, Perl is still assimilating and the community adapts very quickly after assimilating something. In about a year, half of the web infrastructure made for Perl switched to Plack. That's almost over night. Coro has been making waves. We ran with ORMs like tweaked out squirrels with scissors. It's disgusting, really. Collectively, we're having a lovefest with git.

Yeah, there's CPAN. Trying to figure out what happened to sunsite.unc.edu (go find out! You'll like the answer) I happened into CTAN -- the Comprehensive Tex Archive Network. No one gives a flying fuck how much stuff is in there because they have no plans to use Tex. CPAN isn't going to sell people on Perl. It did sell them on the idea of creating repo archives, though.

I hope you've enjoyed my little rant. My goal isn't to kick Perl while it's down nor is it to pointlessly piss people off. The subject is subjective and debatable and I don't mean to try to "win" the debate, only to add usefully to it. Past a certain point, saying "Perl isn't dead!" just is not constructive. We have a lot of work to do.

-scott

YAPC::NA2010 wrap-up

scrottie — 2010-06-25T05:06:12+00:00

I flew USAir. This was the airline that promised me a $200 flight voucher and gave me nothing. They announced on the way back that the stop in Phoenix was actually a plane change for the people going through to CA. The airlines started doing "stops" rather than layovers because people hated switching planes -- too often they wouldn't make their connection and they were twice as likely to have a canceled flight.

As people boarded the plane, USAir was confiscating carry-ons, telling people that the plane was full. One guy was almost in tears -- he had a case that was full of glass. He boarded without it. The plane was not full. Not nearly. Nor were the overhead luggage racks. I've heard airlines use this to hurry people on planes before. I wonder what the next tactic will be when this one wears out. This "plane is full" stuff came after they called all of the stand-by passengers up to the podium. The lie was bare faced.

I don't mean to hate on the airlines; businesses are machines. Things devoid of soul aren't worthy of hate. But I'm trying to piece together thoughts on what happens when humans don't or aren't able to stand up for themselves.

From what I'm hearing on IRC, other people's experiences were actually legitimately bad, not just annoying. It rained somewhere so flights got canceled left and right. People barely made it home in time to eat at The Cracker Barrel.

The travel days are interesting. Between the bus, taxi, plane, and airport, it's nearly an all day affair.

I'd live in Columbus. People were laid back and earnest. Bikes represented well. College town was bursting with interesting establishments. Awesome old buildings of brick or wooden things with elaborate roofs with gables were all over, far outnumbering the new structures. It felt like a place that people cared about.

The whole time, people complained about the heat. I think it was mid 70's but muggy. I felt extremely comfortable to me -- I could roll naked in the grass. Okay, the chiggers might not be so comfortable later. Shirtless or scantily clad students were jogging, playing basketball, or walking around.

The Perl community... oh boy. Recent years has brought a push to organize. The Perl Foundation has been doing more and different things and recruiting people into roles doing specialized things that programmers generally can't do. I was steeped in organization and volunteerism for a different cause. I went around YAPC wearing my TBAG (Tempe Bike Action Group) shirt for two days. Smelly shirts go well with eye bags. It was interesting to see how well I do not function with extended lack of sleep. I had the stupid, bad.

The Perl community is full of misfits, freaks, man-boys, server room dwelling shut-ins, gimps, maladapts, rejects from other cultures, and the curiously alternative, plus the suspiciously normal looking, and I love them. It took me a few years but I learned that I can talk to nearly anyone there and have my mind blown. It's exciting to see and hear about the things everyone is working on. Every now and then, we make someone doing something especially nifty feel like a rockstar. It would be like going into a Hollywood studying and seeing a movie being made, if I actually cared about Hollywood. Some of the talks are riotous.

My "hey, look at me, I'm weird!" instinct is dying down. People know all about it for one, and secondly, I should be paying more attention to the ways other people are weird. Also, I've pretty much failed in making people hate me which is always an easy way out of social situations. Perhaps I should have taken lessons from buu. It just isn't as rewarding as it was.

It looks like the cluster going down was due to a power outage. The machines that survived on battery (laptops with longer battery lives) shat themselves when the initnode went down and laptops with shorter battery lives died before that happened, leaving notices on the screens of the other laptops that they went down and left the cluster. The last minute errand of putting new batteries in the old UPS saved my ass. While I was giving the talk, one of the machines went out. This old APC600 has a serial port on it. I guess I should see about actually plugging it in to something so I have some idea of what's going on when I'm remote at least. Clearly the service level needs to be bumped up. I might have to break down and do the Cox Internet thing, as much as I hate those fuckers.

Perl is still assimilating just as it always has. Perl 5 and Perl 6 are doing that concurrently. When Perl assimilates something, the community usually aggressively embraces it, even to the point of silliness. I kind of wish mixing in some strong typing had been embraced but what are ya going to do. There's a lot Perl does not have. PyGame, for one. Because so much has been coming from outside of our own camp, it concerns me that we might be forgetting that we can start memes too. I want to resurrect the old clustering meme, and in a lot of ways, Perl and Perl programmers are perfect for it. Perl has infrastructure for working with Unix primitives and processes beyond what most languages offer. forks, the threads API implementation for forks, comes to mind. And a lot of us are cranky old sysadmin types.

Just sitting around coding socially is something I really don't get to do in Phoenix, working from home. The coffee shops don't offer much in that way either.

I showed YAPC a photo of myself from Phoenix, the day before I left for Ohio.

It was good hanging out with beppu again, a man I admire and draw inspiration from.

I have code I started for my presentation that I need to finish still.

I got to put faces to coworkers.

-scott

Perl 6 Design Minutes for 09 June 2010

chromatic — 2010-06-24T12:24:33+00:00

The Perl 6 design team met by phone on 09 June 2010. Larry, Allison, Patrick, and chromatic attended.

Larry:

not much spec change this week
figured out a syntax for a regex block to return more than one cursor
based on gather/take
in STD hacking, continued to assist Stefan O'Rear in getting STD bootstrapped via viv
now that it's bootstrapped, we're refactoring things that make sense now
we're now starting to move bits of Cursor code from Perl 5 into Perl 6
refactoring the grammar for sanity of design
started upgrading STD to normal Perl 6 syntax where it previously catered to gimme5's limitations
for example, switched STD's old .<_from> and .<_pos> hash lookups to using .from and .pos accessors
started the prep work for moving EXPR out of STD to make it generally available to any grammar wanting operator precedence
in STD parsing, made Perl 5 $< detection have a longer token to avoid confusion with match variables
STD no longer attempts two-terms detection on infix_circumfix_meta_operator
STD now parses >>R~<< correctly, or at least dwimmily
STD doesn't complain about P5isms in printf formats like "%{$count}s"
STD was parsing /m and /s with the opposite semantics
termish now localizes $*MULTINESS in its scope so that inner declarations aren't accidentally multified
STD now carps about package Foo; as a Perl 5 construct

Allison:

talked to Chris Shiflett, a PHP developer, on someone from the PHP community to sit on the Parrot board
will be in the US for a few weeks

Patrick:

working on list simplification
had a couple of breakthrough ideas on Monday
working on the implementation now
worked out inversion lists for character class matching in regexes
will make them faster, especially with long ranges of character classes
fixed a half-dozen tickets in RT
fixed Rakudo hash constructors
fixed an intermittent bug with colon-pair signatures
two possible parses exist in STD, but we removed an unneeded one in Rakudo
fixed a bug with Parrot's exit opcode
NQP and PAST needed an update not to cheat with PASM constants
I fixed that too
Vasily added multisub and multimethod support to NQP, that was a big plus
fixed the ** quantifier in regexes to understand surrounding whitespace
regex engine tried to match beyond the end of a string, so I added guards for that
will work on lists furiously before the next release
I don't think it'll take long
closures are next, hope to have those in place by the weekend

released a new version of Pod::PseudoPod::LaTeX to support the various books in progress

perl and AtariBASIC, part III

scrottie — 2010-06-23T18:46:01+00:00

In a Perl 6 talk, pmichaud felt necessary to justify to the audience why something was a bit cryptic: he was running out of space on the line. dconway, from the back, commented "If I had a dollar for every time someone wrote unmaintainable code with that excuse...", prompting me to point out on IRC that putting lots of stuff on one line is an optimization technique in AtariBASIC. The moment I said that I realized (or remembered) that Perl has exactly the same problem: it does a linear traversal through statements looking for the target label (or line, in AtariBASIC). The more statements it has to traverse to find the target, irregardless of size, the longer it takes.

Therefore, it follows that longer lines in Perl make for faster programs.

http://slowass.net/~scott/tmp/gotot.pl.txt

-scott

Perl 6 Design Minutes for 02 June 2010

chromatic — 2010-06-22T01:12:29+00:00

The Perl 6 design team met by phone on 02 June 2010. Larry, Allison, Patrick, Will, and chromatic attended.

Larry:

mostly, I supported sorear in bootstrapping STD to use viv instead of gimme5
his stage 2 and stage 3 now output identical Perl 5 versions of STD
produces a huge amount of warnings
appears to require Perl 5.12 at the moment
working on both of those
S03 refines hyper dwimminess to be more like APL, with modular semantics
S02 refines Blobs to simply be immutable Bufs, with similar generic characteristics
S02 now describes native blob types
implemented post-declaration checks for BEGIN and use, since those can't wait for end of file
STD no longer loses existing bindings when we go to a sublanguage
STD now uses $*GOAL variable only as informative, never as a "stopper"
instead, we create a <stopper> rule for $*GOAL if necessary
can check for that only, instead of that or $*GOAL
answering lots of questions on how STD and viv work besides that

Allison:

did a lot of research on graph color algorithms for register usage algorithms
will finish my finals on Monday

Will:

trying to herd the discussion of dynop libraries
a recent branch to close an old ticket broke a lot of assumptions
some bugs have become more visible because of these changes
hope to get that cleaned up this week

Allison:

I liked your suggestion of bringing back the getstderr and related opcodes

Will:

trying to resurrect Partcl
stuck on a TT #389 closing issue
not sure how to fix that, the way things are now

Patrick:

working on the iterator and list design
brainstorming the implementation
will implement somethine one way or another this week
people keep implementing workarounds for the current system
they'll bite us eventually
Moritz and I worked on making the regex engine returning real Perl 6 objects
that mostly works
exposes some places where lists don't work exactly right
the workarounds there made me replan the list and iterator implementation
answered some questions online
Jonathan added a better backtrace algorithm for Rakudo
reports Perl 6 source lines instead of PIR lines
I'll review his code
think I can borrow it for NQP for all HLLs
Jonathan reports that it was a lot easier in NQP than PIR

trying to answer a few Parrot design questions
looking at the continuation of design from Perl 1 - 4 to Perl 5 and Perl 6
hope to have coding time soon

Perl 6 Design Minutes for 26 May 2010

chromatic — 2010-06-20T19:40:02+00:00

The Perl 6 design team met by phone on 26 May 2010. Larry, Allison, Patrick, Will, and chromatic attended.

Larry:

:() syntax is now always signature
we now use foofix:[...] as the general op form instead of foofix:(...)
refactored the sematics of :nth and :x
:nth() now only ever takes a monotonically increasing list
S03 now explains how "not-raising" works on != and ne
it now basically matches the intuitions of an English speaker via HOP definition of negate metaop
STD sometimes didn't require semi between statements
statement modifiers are expression terminators but not valid statement terminators
an unexpected statement modifier word like if could terminate one statement and start another
fixed up backslashes in character classes to allow \s etc and reject \u etc
STD was accidentally using the same lexpad for different multis
Cursor now treats :() on name extension as a signature always, never as a categorical
we shouldn't introduce the stopper for circumfix until we're in the circumfix, or we can't use the same char on both ends
placeholder messages error messages are now much more informative and correct
we now disallow use of placeholder after same variable has been used as a non-placeholder, even for an outer reference
renamed add_macro (which it doesn't) to add_categorical (which it does)
participating frequently in discussions on semantics both on irc and p6l
working closely with sorear++ as he brings viv closer to bootstrapping, yay!
soon can bootstrap past gimme5

Allison:

worked on Pynie this week in my limited spare time
one goal is to generate the parser directly from the Python grammar
wrote a small, lightweight PEG parser which generates a match tree from the Python 3 grammar
can generate a lexer directly
right now it creates a parse tree
looks similar to the match nodes of NQP-rx
dumps out a tree to the PIR parser
working on PaFo elections for next year, but trying to delegate those
will have more time after June 7

Will:

working on Perl 6 advent tests
many more people are doing more work than me
liasing with Rakudo folks for any important Parrot bugs before the Rakudo Star release
my current direction there is "don't break anything"

Patrick:

sorear added hash flattening to NQP
lots of work on closures in PAST and NQP
they properly clone
fixes some lexical problems
need to get that to work in Rakudo
that's tougher; Rakudo has to wrap Parrot subs
wrapper object needs cloning as well, along with its attributes
we'll add a new PAST node type to help
that node understands contexts
essentially a way to add void context optimizations to your AST
that solves many problems in Rakudo beyond closures
added a setting into NQP along with its test suite
not automatically loaded, but available
contains standard hash and array methods
Parrot's ops2c project uses those
other people can update and enhance that setting as necessary
NQP also has the ability to parse type names
NQP doesn't do anything with them yet
eventually they'll allow the use of multis
cleaning up some NQP bugs regarding lexicals and package storage of subs
Bruce Keeler enabled variable interpolations in regexes
working on some refactorings to simplify that approach
works in NQP and Rakudo now
that's a feature we've never had before
Rakudo's REPL now works better, thanks to sorear
HLLCompiler now written more in NQP as part of that
NQP now can do eval
NQP remembers lexicals in interactive mode now
adding that to Rakudo is more complex
working on that
pleased with the progress on #perl6

reviewing long term plans for GC and Lorito
should have more time free soon

MUD cannot be written in Perl and here's why

scrottie — 2010-06-17T19:25:44+00:00

Awwaiid urls http://github.com/jasonmay/abermud# perl based mud with mooseyness (early stages)

You ack loudly.

You say in common: yuck

You say in common: every MUD knock-off in the last 20 years as sucked ass and completely missed the point.

You say in common: Aber, Tiny, Circle's take on Diku, UberMUD, Muck... people *knew* what they were doing for a while, but now everyone completely misses the point.

You say in common: it's all cargo-culting... taking the superficial stuff while missing the point. makes me sad.

You say in common: turns the end of MUD, people were far more interested in throwing tech at it randomly... TMI, EoTL II, etc

You say in common: that's what killed MUD... mindless weilding of tech

You say in common: I think I'm going to put the "TECHNOLOGY WANTS YOUR SOUL" sticker on this laptop.

Awwaiid says in common: haha

Awwaiid says in common: so bitter! Maybe jasonmay is having fun and you should join him... bring "the point" into his code :)

Awwaiid says in common: or maybe that's not possible, since this is apparently a mud-framework as opposed to a mud itself?

You say in common: the most successful MUD software of all time, LPMud 2.4.5, was distributed as a copy of a running a game. you could fire it up and run it.

You say in common: it had a couple of security flaws in the "mudlib" code (the interpreted C-like stuff that's easy to change).

You say in common: it lacked a lot of features... races and classes most significantly

You say in common: but it had monsters, areas, spells and lots of stuff.

You say in common: you could fire one up, "wiz" the people who madeit to level 20 and let them start adding to it.

You say in common: one thing that's well established is under no circumstances should a live game "wiz" people who have not played through and beat that particular game.

You say in common: that goes for the admins too. no one should ever start a MUD without wiz'ing on one MUD and having that MUD go down or them being forcibily ejected from it.

You say in common: for some profound human nature reason, doing otherwise is always the same... you have to profoundly care about a game to contribute to it and the only way to do that is to go through the long process of making friends, partying, helping novices, learning your way around it, etc, etc over months or years.

You say in common: I guess more fundamentally, MUDs need to be targetted towards *players*, not towards coders. players become coders.

You say in common: a Perl MUD is a good idea. the zombie game was a stab at that. but there a pile of lessons like that... more than I could remember... that people haven't learned. either they haven't had the experience or else they second guessed what they saw in the name of tech devotation. ....

By the time someone makes it to level 20 and is generally (a willing sponsor aside) then permitted to code, seeing the code has to make the game even more magical. This is critical: seeing the code has to be a wondrous event. They should relive all of their adventures again from the point of view how things actually really worked rather than what their imagination thought was going on. Their imagination will have inflated the realities of the world. But they'll see opportunity to create more of this illusion. This is analogous to working through a math problem or riddle before seeing the answer and just being told the answer. Seeing the code should be a glorious "aha!" moment.

That MUDs are text is superficial to why they were successful and why so many people loved them and still do. What makes a MUD is being up to your eyeballs for months or years, making friends, fighting monsters together, exploring, the politics of the gods, the policies of the games, the dramas, the loss and gain, the interaction between people of different philosophies including personas of people's experimental alter egos. A profound love of the game, strong feelings (period) towards the admin, and a sense of serving people like your many friends drives you to create more adventures, places, creatures, oddities, and interactions. You're adding magic to the game. This is the only time and the only point that magic is added to the game -- when a player beats it and adds to it.

I lied: Diku was probably the most popular game. It too game ready to play. Rather than be coded on (Circle would later change this), creation was done with level editors. Creativity was mostly limited to economics and prose, and this was fine.

Diku was a clone of Aber, stealing and changing it slightly. Aber was a knock off of the original MUD which was a commercial enterprise; the creation of MUD was a blessed event. LP was a knock off of Aber. Lars was an Aber player and beat Aber.

No one is going to clone Aber, Diku or LP in Perl because they want to do a "better" framework. How good the framework is matters now. In fact, TinyMUD was huge and it ran a very simple BASIC. Diku didn't run user code at all. You had to hack on the C source code to add features. Same for Aber, except Diku let you extend the map at run time.

To create a MUD -- in the spirit of MUD -- in Perl, you'd have to make a game. That's a much harder problem than creating a "framework" for making games. For the reasons outlined above, no one is going to take your framework and run with it. Anyone who cares is going to just make a game and worry about the "framework" later. Even myself, I had a harm time having energy left over the game. It's profoundly hard to do the tech and the game at the same time. Stealing egregiously is the only way to do this. Previous efforts have used mechanical translation from one game to another, and un-tech-savvy friends cutting and pasting. People cared about the game that much. They knew. Even when a new game started, enough had to be added to it to make it interesting, even though it came playable. Most people didn't have the energy for that. There were countless failed attempts at starting games where all they had to do is take a running game -- often 2.4.5 -- and add classes, races, and/or a mix of other unusual, new, unique and interesting things to define that game. Taking an existing, ready to play game with a pile of features as long as your arm and dozens of areas and thousands of monsters and adding a few more features takes more energy and creativity than the vast majority of people have to spare. And that's why you can't create a game framework in Perl and expect it somehow turn into something. Your effort is insignificant and misguided. You make me sad. Go code on an existing MUD that already had hundreds of wizards pour their life and soul into it. Bolt Perl onto the side. But, if you actually played and beat the thing and lived it, bolting on Perl would be the last thing you cared about.

-scott

Perl 6 Design Minutes for 19 May 2010

chromatic — 2010-06-16T21:38:09+00:00

The Perl 6 design team met by phone on 19 May 2010. Larry, Will, and chromatic attended. Patrick added his notes later.

Larry:

S03 makes more explicit that doctrine that ~~ topicalizes, and removes smartmatch table fossils that automatically fall out from that
S05 renames 'accent' to 'mark' for better Unicode conformance
:a and :aa changed to :m and :mm
S05 disrequires retroactive semantics on :samecase and :samemark
the method form must now explicitly add case or mark modifiers to the pattern
regularized mm// to ms// to avoid confusion with new :m ignoremark option
STD now does a bit better at diagnosing bogus ??!! constructs of various sorts
STD now correctly adds operators to symbol tables as subs
CORE.setting now has protos of all the operators so they can be recognized as subs too
Cursor now canonicalize operator names in the symbol table
btw, not quite like specced
STD now reads user's mind on 'Str $toto' to intuit missing declarator
STD now properly diagnoses a typename between routine declarator and sub name

Will:

working on code for Carl Masak, trying to get his poker code example running on Rakudo
both fun and frustrating
some stuff doesn't quite work yet
going through the Advent examples
adding them to spectests
make sure we won't regress on such public examples
other people are helping with that now

will get back to editing the Rakudo book soon
hope to have it in print by YAPC, but no guarantee

Patrick:

fixed closures in NQP, as a precursor for fixing them in Rakudo
worked with sorear on REPL in Rakudo and PCT in general
ported the NQP "standard library" done by japhb++, bacek++, and many others into the nqp-rx repository and made it part of the standard build sequence for nqp and Parrot
decided we need a new "context sensitive" node type in PAST, will be used to create proper closures and to handle sink context
worked with bacek on adding better multimethod support to PAST and nqp-rx
discovered a problem with lexical subs in NQP being automatically entered into the package namespace (and some existing code relying on this behavior)
did some initial fixes to at least get things entered properly, but a complete fix may require a deprecation cycle
plan to review others' patches this week
plan to fix REPL, closures, and sink context in Rakudo (since those are currently large pain points)
plan to work on loops and iterators after that

Perl 6 Design Minutes for 12 May 2010

chromatic — 2010-06-16T01:47:02+00:00

The Perl 6 design team met by phone on 12 May 2010. Larry, Allison, Patrick, and Will attended.

Larry:

clarified usage of brackets around infixes
added various 128-bit types to the spec; we might make them arbitrarily extensible via role
at least LLVM could support this, even to non-powers-of-two sizes
modernized the paleolithic grammatical category description in S02
STD now uses double-quote rules for interpolating @foo[] into regex
STD now gives better message on 1__3
added the specced 128-bit types to CORE.setting
added minmax function to CORE.setting
implemented circumfix:«X Y» as grammar derivation
currently only allows a >> inside
now also recognizes foofix:("\x[face]") and foofix:("\c[YOUR CHARACTER HERE]") without actually evaluating
playing with factoring yaml out of gimme5, since viv is not likely to go that route.
mostly just answered a lot of questions on irc
egged people on about concurrency issues

Patrick:

thought on handling closures properly
have a solution, just need some time to implement
discussion on changes to CodeString
work on compiler toolkit to avoid CodeString, using StringBuilder instead where possible, in PCT, NQP, and rakudo. Pretty easy, no downstream projects block on a deprecation issue
after that, lists
also been answering questions on interactive mode (REPL) for rakudo et al. (the issue with losing lexicals)

Allison:

resolved the git conversation pretty well (for Parrot's repo migration)
worked on a pure PEG parser (following the paper), straight PIR, single day; now self-parsing. Interesting project, is lightweight. currently has memoization, but that might not be right for us because of backtracking. With some more effort, could probably handle EBNF form (useful for python)
could be setup for developer status for Debian which will improve our packaging status for Debian and Ubuntu

Will:

Parrot CodeString performance improvements
we're definitely faster in branch, but some feedback from pmichaud should help us clean up the API a bit as well, look for those to hit trunk in the next few days
Parrot makefile deps cleanup

Moose, DBIx::Class, and the _new_ OO

scrottie — 2010-06-04T07:19:57+00:00

Simula introduced OO in the 60s. Smalltalk took it to its logical and pure extreme in the 80s. C++ brought it to systems programming and gave it the performance that only static optimized code can enjoy.

Really smart people wrote really smart code using really powerful, really futuristic features in C++... and created great big steaming piles of crap.

Efforts to create any reasonable operating system or database system using C++ failed. Telephone switches, previous infallible, failed spectacularly in cascade. Countless klunky, slow, buggy, bloated, unmaintainable Windows apps were written. Government agencies swore off of it in favor of other systems, even avoiding systems with OO at all, favoring APL or C. Windows programmers eschewed the complexity of C++ in favor of VisualBasic.

This created a bit of a paradox.

Was it the language responsible for all of these flawed designs and executions? Did adding objects, destructors, multiple inheritance, and so on, create a language that it just isn't possible to write clean code in?

For a long time, people thought so. "C++ is a messy language", they said, conflating the learning curve of the syntax of the language with learning to design objects and APIs that made sense.

Gosling and those behind Java seemed to think so. They threw away multiple inheritance, operator overloading, and a pile of other things. For a time, Java code was clean. So clean that they started teaching it in schools. Projects started demanding it and all across the world, people with no prior programming knowledge quickly ramped up on the language. They joined the workforce and wrote buggy, overly complex, unmaintainable code.

Simula's idea of OO was to provide a new abstraction to programmers with which to better model the interactions of the parts of a complex system. If a programmer could conceptualize the program in a way that drew parallels to real objects acting on each other, the objects and their interactions could all be better understood. In so much as that's true, there's nothing wrong with OO and no reason it should lead to unmaintainable code.

Much earlier, Donald Knuth wrote _Literate Programming_. Local variables and functions were the celebrated abstraction with which people were making huge messes. Knuth sat down and asked what was going wrong and speculated about how those problems might be avoided. It proved far easier to offer people a new abstraction that they haven't yet ruined than to get them to example the psychological, social, and technical forces driving them to write crap.

When the C++ guys realized that not only were they writing terrible code but that they were predictably and consistently writing terrible code, they too sat down and put some of their profound intelligence into asking why this was. This was the birth of the field of "Object Oriented Design and Analysis". There were a lot of things that people tried to do with objects that just didn't make sense and didn't work in the long run. There are a lot of early warning signs of failures to conceptualize things well and map them to objects.

The Java guys, determined not to repeat the mistakes of the C++ guys, adopted less analytical, more rule-of-thumb versions of this and called them "Design Patterns", "Code Smells", and so on. They fairly successfully marketed to their own ranks the ideas of studying design for design's sake rather than merely learning a language.

The Perl camp briefly and very superficially flirted with these ideas too but the glamour wore off and sitting down and just winging it and seeing where it goes is just so gosh darn much fun. History is boring. Of course, if you've read history, repeating it is boring.

Even this sort of backfired for the Java camp; understanding so well how to build certain types of abstractions, they went nuts building them all over the place and then managed to construct great big steaming piles of crap out on a much higher level -- they built them composed out of large scale constructs devised to avoid problems at lower levels.

While Java failed to convince everyone to actually studying the inherent follies and blunders novices make when designing software in hopes of avoiding them, it did introduce the world to a different idea: rather than using objects to model programs in terms of parts that interact, use objects to create massive APIs.

It's a big step backwards but it kind of wins in the "worse is better" department in that it's a lot easier for people to wrap their heads around than OODA. The language vendor created a whole lot of objects for you to use that represent different parts of the system they built, and if you base your application largely around using these pre-created objects, you're less likely to fuck things up. The win of objects became easily traversing large sets of documentation to figure out how things are done. If you get a Foo back from calling Bar.bar, you can instantly look up the docs for it and see if maybe you can weasel a Baz out of that to pass to Quux. This began the umpteenth documentation push which started with flowcharts, spent years on massive shelves of spiral bound printed pages from vendors, and, at some point culminated in programmers having bookshelves full of O'Reilly books before branching out into CPAN display module docs.

Everyone got tired of Java and gave up hope that any sort of cure for the worlds programming ills would emerge from that camp. Yo dawg, I heard you like MVCs so I put an MVC in your MVC! Even reading histories of how Java fucked things up and repeatedly missed the point is boring, and history is interesting. Java just smears boring all over stuff.

Meanwhile, the Python folks were writing much better software without nearly so large of sticks up their butts. No one knows how the Python people did it so I guess they just supposed that Python is magical and code written in it is clean. Likewise, no one understands why Ruby is so magically delicious, so like amateurs banging on a piano keyboard after the maestro gets up, they're trying their hand at it.

Back to present day and Perl. OO and OO abstractions mean something entirely different than what the Simula guys had in mind.

Now, when we sit down and create a system, we don't conceptualize the parts of the system and their interactions. We don't model the problem space using analogues to real world ideas and real world interactions. We don't search for the correct idiom.

Instead, we use APIs, and the more, the better. There is no User; instead, there are DBIx::Class ResultSet objects for a user or login table; there are admin screens that check things in that; there are Apache Response objects for talking to the user through; there are piles of Moose meta things that have nothing to do with hypothetical objects modeling a hypothetical universe but do a neat job of setting up neat things. Everything is abstracted -- except for the concepts the program is trying to actually model in its own logic. If there are objects definitively, unique, and authoritative representing things and nothing but that thing in a normalized SQL sense, then those objects are all thrown together in a big pile. A lot of the C++ OODA textbook's pages are concerned with finding idioms for how things interact to model those interactions. In Perl, we just pass stuff. And we're proud of our redneck selves.

In C++, and again in Java, and most certainly in Perl, we've shat on the grave of Simula. Smalltalk did not; Ruby had a blessed birth by virtue of drawing so heavily from Smalltalk. Python programmers tried hard to keep the faith even though OO is borderline useless -- nearly as bad as Perl's -- in that language.

If we were to sit down and try to represent our actual problem space as objects -- what the program is trying to do rather than the APIs it's trying to use -- we'd find that we're knee deep in shit.

This isn't one man's opinion. C++ programmers trying to claw their language's way out of its grave named parallel inheritance hierarchies as a thing to avoid; Java redubbed them as "code smells". If you have multiple objects each representing a user in some capacity, but not representing some limited part or attribute of the user, you have this disease. If you're using a bunch of abstraction layers to represent the User, for example, you have this disease.

Yet it has been escaped from. There are cures. You can have your objects representing things which your program deals with and have good abstractions to program in too. MVC frameworks aren't the cure but some people benefit from any restraint they can get.

And here it is, 2010. Everyone wants to learn the language syntax and fuck around with it, which is fine and great. But not everyone is here, reading this, being told that you can and will paint yourself into a corner in any language -- even assembly language -- and that it isn't the language's fault but especially: the language won't help you.

Perl programmers and Perl programs suck because Perl programmers think that rather than Perl fostering bad code, it'll help you dig your way out, with all of the magical things it can do. This is what C++ programmers thought. Perl programmers would be far better off if they actually thought that Perl fostered bad code and worked against this imagined doom.

So, let me say it: every programmer in every language, if he lets himself tackle large or ill defined enough tasks, will code himself into a corner. Not him nor perhaps anyone who follows him will be able to dig him out. The house of cards will implode. Trusting in abstractions of the language to save you will accelerate this process unless, just perhaps, you're privy to the lore. Books talk about how to design inheritance hierarchies that make sense. They talk about how to handle multiple inheritance and how to conceptualize things as objects. There's lots of benefit to modeling your problem space not as "objects" in the sense of the API you're using but in the sense of actors and props in a drama.

Like C++ programmers of yore, Perl programmers reliably, consistently build houses of cards.

As Ruby programmers start to build larger systems and have the time to grow things to that point, they'll discover that merely representing things as objects isn't enough, and that the interactions between objects are out of hand.

This isn't to say that I'm not susceptible to these same forces. I most certainly am. And I fear them.

Walking into a new codebase: tips

scrottie — 2010-06-02T07:14:31+00:00

Find out where the cache is. Rig tests or a test script to delete it before each run.

Make a file with the commands necessary to reinitialize the database to a known good state. Make that an optional step in running the tests.

Use the test suite as docs to find out which APIs are important and how they're used.

Use the debugger to figure out which cross section of the code runs for a given task. Step through with a mixture of 'n' (next statement) and 's' (single step including stepping into function/method calls). As you trace through execution, you'll learn which utility subroutines can safely be taken for granted and skipped over. Note which tables data gets stuffed into and pulled from.

Strategically pop over to another window and inspect database tables while in the middle of single stepping.

Write SQL queries to inspect database state. Even if you like DBIx::Class, it's handy to be able to simply write "select count(*) from foo group by state order by state desc" and other things.

If tests don't already inspect the tables for the correct left state, add tests that do. The utility queries will start life in a notebook or scratch file, get refined, then maybe wind up in a stub .pl, but don't stop there. Add them to the tests. Yes, tests should only test function, not implementation, but, in one sense, the API is probably just a database diddler with sideeffects, and its correct operation could be specified as not mucking up the database.

Get the code running on your local machine -- that should go without saying. Mock services, APIs, commands, and whatever is necessary to get the core code to run. Mock stuff until you get the code passing tests again and then start modifying the code. From one project, I have a mock implementation of a Vegas slot machine. My cow-orker and I referred to it affectionately as "ASCII Slots". It handshook, spoke XML over SSL, had a credit meter, tilted on protocol violations, and the whole nine yards. Furthermore, it could be told to abuse the client with a string of simulated network errors including every possible scenario for the connection having gone away after a packet was sent but before it was received, including for packet acknowledgments.

Before you start work, run the test harness piped into a file. After work, pipe it into a different file and diff it, or add the first one to git and let git show you what tests have started passing/failing when you do 'git diff'.

Comment the source code you're working on with questions, speculation, and so on. This will help you find stuff you were looking at by way of 'git diff'. You can always checkout HEAD on that file to get rid of it or else just delete the comment, but you may find that the comments you write to yourself as notes while you're exploring the code have lasting value.

Similarly to saving test harness output, save full program traces created with perl -d:Trace t/Whatever.t. Trace again later and diff it if you find that an innocent seeming change causes later tests to break. This can dig up the turning point where one datum value causes a while/if to take a different route.

If execution takes a route that it shouldn't have and meanders for a while before actually blowing up, add a sanity check earlier on.

-scott

Summary of Celtics vs. Lakers NBA Finals History

pudge — 2010-05-30T05:25:50+00:00

There have been 60 NBA Finals. The Boston Celtics have won 17, and the Minneapolis/Los Angeles Lakers have won 15, which amounts to those teams winning more than half of all NBA Finals. This year, they play each other in the Finals again, making it 33 champions out of 61 being either the Lakers or the Celtics.

Additionally, 39 of the 61 Finals have included either the Lakers or the Celtics. Including this year, the Celtics and Lakers have played each other in the Finals a whopping 12 times (just under one-fifth of all Finals have been these two teams).

The Celtics have made 21 total Finals appearances, so have faced the Lakers more than half of the times they've been in the Finals. The Lakers have made 30 Finals appearances, facing the Celtics in two-fifths of those.

The Celtics won nine of those against the Lakers, which accounts for more than half of all their 17 championships. The Lakers' two victories over the Celtics came after the Celtics won their first eight encounters.

The longest streak without either team in the Finals was eight years from '92-'99. The longest streak with either the Lakers or Celtics in the Finals was 10 years, done twice (from '57-'66, in which the Celtics appears all 10 years, and the Lakers five of those; and '80-'89, in which the Lakers appeared eight times, the Celtics five).

The longest streak for one team appearing in the Finals was, as noted, Boston, in the 10 years from '57-'66. Boston won nine of those 10 years, including eight in a row (the longest winning streak from any one team) from '59-'66, and also won 10 in 12 years, from '57-'69.

The Lakers' longest appearance streak is "only" four, from '82-'85, winning twice; but they have also appeared three times in a row five additional times (including the current three-year streak). In two of those, they won all three years; in one, they lost all three.

The only other team to "threepeat" was the Bulls, winning three years in a row twice in eight years ('91-'98). No other team but the Celtics and Lakers have had four consecutive appearances. The only other team to have three consecutive appearances was the Knicks, losing all three from '51-'53.

The 2010 NBA Finals begin in Los Angeles on Thursday.

Cross-posted on <pudge/*>.

Bane of the existance of IPSs...

scrottie — 2010-05-19T21:59:27+00:00

In Minnesota around '93, an ISP started offering unlimiting dialup. Through an arrangement with the state to make Internet more widely available than government offices and college campuses, they were to resell from the UMN.edu modem pool and the one T1 coming into the state to the general public. After my brother and I tag-teamed 24/7 for about two months, they changed their unlimited usage policy "due to the actions of one user".

That's after the 24 hour labs I was sleeping in, in one case ruining a keyboard with drool. Oops.

For years, I paid for dedicated SLIP connections, first in Minnesota then in Arizona, then ran a ppp emulator that takes a dial-up shell account and gives you full PPP with nat. I helped kill Global Crossing staying dialed in to the "shell account" 24x7. Downloads ran at night while I was sleeping.

When Ricochet hit Phoenix, I couldn't resist. $70 was not too much for total freedom of movement. Getting a real IP address and having the option of a dedicated IP was just awesome. Ricochet went bust, sadly. The modems were too expensive to make, and they had Alps Electric of Japan making them, and they had too many made, riding the dot com optimism, and uptape was too low. God bless Ricochet. I seriously doubt wireless will be half that awesome again.

Then there was Cox in the days before you could get a home NAT appliance. I had a FreeBSD machine doing NAT -- strictly illegal. One modem (yes, cable modem) per computer on the 'net was the policy. And no serving. I carefully recorded scans against my network for a month and a half and firewalled to refuse, not drop, any future probes from those that probed me, then started hosting crap. Cox never caught me. When I moved, their system completely hosed my account. They could ping me, even as I held the modem in my hand completely disconnected from cable, power, Ethernet, or any other connection. Clearly it wasn't me they were pinging but I could never establish that with them. This was the first time I tried to convince techs that the system was *un*plugged. Cox started off on the wrong foot and just stayed there.

After months of paying for service that didn't work, I had to cancel and went DSL for the first time. Not many people had DSL at that time. Quest was giving out Cisco 675s that you configured by typing commands at over a serial cable from a terminal program -- not xterm but minicom or HyperTerminal or whatever. Having good enough lines was a really big deal. Most people didn't. Most people still don't but they sell you the service anyway, refuse to fix the lines, and, for many users, DSL sucks in comparison to cable.

When wireless data again became available, I hopped back on the bandwagon, this time with T-Mobile. For $30/monthy, you could unlimited dial-up speed data using GPRS. They ran you through a "transparent" HTTP proxy that recompressed images and cached shit, or made it look like it hadn't changed when it was. This was extremely disruptive to a would-be web developer. It also ran you through two levels of NAT. It is and was ghetto. Outages were frequent. It was like Atlas holding the globe up, but instead of a big strong guy who cares, it was a fat stoner dude who could just barely reach the fridge.

The next major trend I just had to jump on was aiming high gain antennas down the road. Shitty MMMC connectors that have a service life of 0.5 insertions and increased WiFi noise as more and more APs go in and move more and more data seems to be making this unusable.

So, back to DSL. Except that it disconnects constantly and has less throughput than 56k dialup. It keeps training down to 64kbps when I try to use it and then probably drops and if not, has an error rate that's through the roof. I'm pretty sure that dial-up would handle the noise better. This was after it didn't work at all until I took it into the ISP (little local ISPs rule -- I sat in the FastQ office for 2.5 hours while they messed with the thing). It worked on DHCP but not static (with static IPs) and no one could figure out why but everyone was interested. I didn't press for details, but I guess it turned out to be "technical reasons". I had a great time chatting about tech and old school shit while this went on though. I feel like I need to go hang out at the ISP more, and bring pizza next time.

I'm seriously tempted to turn that cell data back on. I might also give CDMA data a whirl, care of Cricket, who wants $40/month, no contract, 5gb/soft limit.

I could easily imagine having the gateway machine with the dipole antenna soldered onto the mini-PCI card and a 56k modem plugged in, this Keyocera CDMA data card sharing appliance box, the and DSL modem all running concurrently and me continuing to fumble around for a good connection all day long.

Perl 6 Design Minutes for 05 May 2010

chromatic — 2010-05-10T06:07:34+00:00

The Perl 6 design team met by phone on 05 May 2010. Larry, Allison, Patrick, Will, and chromatic attended.

Larry:

various spec updates, some major
removed p5=> description because it's not supported in core
deleted self:sort construct because self isn't a real syntactic category
explained Perl patterns in terms of PEGs, and spec'ed tiebreaking rules explicitly
last but not least, finally purveyed the long-threatened revamp of proto to keep routine and method semantics similar
they all now work much more like the multiple dispatch semantics currently used by STD, where we always call the proto first
the proto is then always in charge of the actual multiple dispatch; it can of course delegate that
and the default for a null body corresponds closely to current semantics
in hacking news, the lexer generator mislaid any alternative that was a bare . pattern, so cursor_fate never called its alternative, oops
took me a long time to run that one down, because it resulted in a horrendous backtrack causing mysterious misplaced errors
revamped character class parsing to be more helpful and correct
STD now check a normal regex bracket's innards for old-school character class, and warns if found
added a .looks_like_cclass method to Cursor to detect most accidental uses of P5 ranges
some valid P6 brackets will complain, but the workarounds are easy
just put whitespace on both ends is one way
removed a few of these old-school-ish character classes from STD
changed :tr language to :cc language since character classes share it
(translation pays more attention to ordering, but the language is the same)
turned out parsing character classes discovered issues in STD; various character classes needed to backslash # that would otherwise be a comment
to that end, we now allow \# in character classes instead of misparsing as unspace
if we find an invalid - in a regex, we now presume we're in an old-school character class and fail with a sorry instead of a panic to give the character class code a shot at it
STD now uses ~ syntax for regex brackets to set $*GOAL correctly
cleaned up recursive panic detection; it was possible to get both false positives and negatives before
STD shouldn't use 'note' to emit a panic inside a suppose because that leaks the message that should be trapped
STD now suppresses duplicate sorry messages more correctly
sorry no longer uses panic in a supposition, but dies directly to throw the exception to the suppose's try block
STD now allows subscripts on regex variables so $x[0] isn't taken as a character class; still needs speccing

Patrick:

can we make them consistent?

Larry:

historically S05 has allowed bare arrays to mean interpolation

Patrick:

we've never had a working implementation of that

Larry:

a bare @ would be illegal

Patrick:

it's currently illegal

Larry:

you'd have to backslash it to match part of an email address
it's not like the @ alternations are a big deal one way or another
that'd be a little more consistent
I forced it to think of the sigil as $ than what it really is

Patrick:

after seeing how Jonathan et all did interpolation for quoted strings, I thought we should do the same thing in regexes

Larry:

STD now has a partial fix to prevent leakage of ::T from role signatures
unfortunately, the current fix will lose signatures of file-scoped generic roles
this probably has to do with not knowing whether we're really going to want a new pad; unfortunately we'd have to look ahead to know that currently
various other minor tweaks and bug fixes in STD and Cursor

Patrick:

mostly responding to messages and reports
should be able to get back to coding full-time and online for the next week
plan to resolve the list and closure issues with NQP and Rakudo
will answer other questions and try to keep other people productive
planning for the Rakudo Star release on June

Allison:

busy with the last week of classes
spent most of it writing a little language with PCT
it was easy to use and easy to swap the stages of PCT
I remembered what Patrick did with LOLCODE
also had a discussion of source code control systems
next week should be more productive
need to work more closely with Debian packagers to get packages into Debian

Will:

cleaning out as many deprecations in Parrot as possible
trying to improve the speed of CodeString after the immutable STRINGs merge
bundling lots of little concats helps
hope to merge in an optimization branch for that by the weekend
want to make that faster or less memory intensive
may require the use of a new StringBuilder for Parrot
hopefully will result in a faster Rakudo build

Patrick:

I've never seen CodeString take a long time
unless you run into memory problems
* discussion of the StringBuilder PMC *

still working on optimizations, particularly CodeString
looking at more PBC and PBC-building optimizations
PBC size went down dramatically and startup improved for Rakudo
should have that much faster for the 2.4 release
will poke at GC tasks starting next week

Perl 6 Design Minutes for 28 April 2010

chromatic — 2010-05-02T00:27:42+00:00

The Perl 6 design team met by phone on 28 April 2010. Larry, Allison, Jerry, Will, and chromatic attended.

Larry:

caught up on a week's worth of backlog
made a few spec tweaks
discussed them with other people
trying to make error messages more awesome in STD
working on the ability to parse the insides of character classes
STD doesn't like parsing itself recursively there
need to iron out a few things
enum names can now be variables

Allison:

Debian packages ready to ship to Debian sponsors
putting together a list of GC tasks
cleaned out the existing page, have the big things listed
trying to decide which tasks to do first
doing a lot of reading and research
my little language project is due on Monday
HLLCompiler was enormously useful
will start working on the GC stuff next week
should also start a fresh pass through the ticket queue
added a workaround for the final remaining TT #389 bug
Jonathan had a test case

Will:

tried to focus on getting Rakudo blockers removed

spent some time getting Rakudo to work with trunk
will need a Rakudo guts hacker for the last part
worked on the compact_string revamp branch with Vasily
merged now
that makes trunk about 12% faster than the 2.3.0 release
will work on a few Rakudo profiles once it works with trunk again
expect at least a 5% performance improvement there
have some other ideas, but won't do them without profiling first
came up with a scheme to reduce PBC size by coalescing strings
Peter Lobsinger is exploring that

Perl 6 Design Minutes for 21 April 2010

chromatic — 2010-04-28T22:20:35+00:00

The Perl 6 design team met by phone on 21 April 2010. Larry, Allison, Patrick, Will, Jerry, and chromatic attended.

Larry:

been under the weather, so didn't get much done other than keeping up with questions
S05 now allows negative quantifier ranges on reversible patterns
S02 now defines the term now to return the current instant
like rand and self, it does not parse as a function, since it never takes arguments
we now specify what kinds of math are allowed on instants and durations
improved error message on attempt to use old-school backreferences in regexes
STD now implements the now term and several other time-related names
we now allow enum names to be "constant variables" so that a class enum can declare an accessor
thinking alot about a better unification of the semantics of protos
this may also solve the current ambiguity in the meaning of postfix parens
in any case, this is for post Rakudo *

Allison:

mainly worked on packaging for Debian and Ubuntu before the release
closed TT #389, no methods in namespaces
collecting thoughts on what we need next from the GC
we've done a lot of small cleanups
now we need to solve some persistent problems
might need to make some fundamental changes, like reducing copying
coming up on my final week of classes, so lots of work there coming up

Will:

updated a spectest
minor ticket wrangling in Rakudo's RT queue

Jerry:

GSoC will make its acceptance announcements soon
expect TPF will get 10 slots

Patrick:

reviewing Rakudo's current state
made a couple of minor NQP patches
reviewing patches, especially from Moritz and Bruce Keeler
should check them in, probably with some refactorings
hope to work on the List implementation, especially laziness and context

fixed as much of line numbering as I found broken
working on branch merges
still looking at optimizations
will focus most energy this month on the sweep-free GC
hope to encourage other people to work on identified optimizations
will review Solomon Foster's Mandlebrot example, especially with regard to performance

Unique

pudge — 2010-04-26T17:45:28+00:00

I wonder how long it will be before people start just putting together random letters for names of companies, bands, and so on, so they can be unique in Google searches.

Your search - fobhwueufg8 - did not match any documents.

^^ my new band name

(Hm, "Did Not Match Any Documents" would be a fun band name. Or the name of the debut album of the band fobhwueufg8.)

Cross-posted on <pudge/*>.

Bob Jacobsen interview on FLOSS Weekly

merlyn — 2010-04-23T03:55:11+00:00

Last week, I interviewed Bob Jacobsen for FLOSS Weekly. Bob used Perl's Artistic 1.0 license on some Java code to manage model trains. The code was later patented by an Oregon-based company(!) and then Bob got sued(!!) for Bob distributing the other company's patented code(!!!). The good part of the story is that this is the first test at the US Federal Appeals Court level for an open source license to be enforceable even if no money exchanges hands, and... we won!

Bob spent a lot of time and money on the case though. Listen to the podcast and contribute to his legal defense if you care about open source.