I've read comments by Larry to the effect that Perl is great at writing lexers but not parsers. If you look at some of the later examples (around page 11) it's clear that he's trying to make Perl regexes powerful/clear enough to parse Perl. They remind me of yacc/bison, which makes sense.
Re:I just started learning Perl a two months ago..
on
Apocalypse 5 Released
·
· Score: 2
I probably don't understand your question properly, but map returns a list and foreach doesn't. Also the former is more functional, the latter more procedural. I guess it boils down to TMTOWTDI.
The same applies for their redunancy in the face of hyper-operators. Why scare of people who are used to procedural programming by turning Perl into a something very functional? It took me a while to get used to using map when I first started and I guess the same will apply when hyper-operators appear. Backward (and sideways) compatability for programmer's brains?
I'll only buy it if they release it in anamorphic widescreen.
What are you on? All the Star Trek series were shot in academy ratio (4:3) for the TV.
Apologies; I was referring to B5 and should have quoted the comment I was replying to. Of course I don't want to see Picard stretched to 16:9! I have a hard enough time explaining widescreen to the family. B5 was filmed in widescreen although it looks like much of the CGI wasn't, which causes problems.
I'll only buy it if they release it in anamorphic widescreen. There used to be a petition site somewhere to this effect, but it's disappeared as far as I can tell. Fat chance of WB taking any notice, 7000 "signatures" or no. Their production on film DVDs is lackluster to say the least.
Yes, but the coder (i.e. the equation) and decoder (i.e. equation to image converter) of your spectacular fractal image have to know that the equation represents a fractal image. You cannot apply this technique to arbitrary data, so my original point about the general case still stands.
JPEG is a lossy image compression technique and we're talking about general lossless compression here.
For example, at the top of the list Dr. Piotr Blass is listed as Chief Technical Adviser from Florida Atlantic University. But he seems to be missing from the faculty. Google doesn't turn up much on the guy either. Hmmm.
Data compression is based on finding redundant data, i.e. repetition, that can be factored out. With random data this tends toward 1:1 as your increase the size of the data. Sorry, but I haven't got time to point you in the right direction, just hit Google with "random data compression theory" or the like.
It all boils down to the fact that you just plain can't compress random data in the general case.
What about the Tux2 file system that was announced on Slashdot last year? The SourceForge site is dead and Google only turns up the original announcement and links to dead pages.
And of course, if it had been Bruce Perens and Linus Torvalds instead of N'Stink we'd all be disgusted at the blatent attempt to pander to the Linux geek market, wouldn't we? Wouldn't we?:/
I was wondering about exactly this a little while ago when I came across this very interesting site called Database Debunking by Fabian Pascal. Very interesting to see such a "contrarian" view. He's the guy who wrote Practical Issues In Database Management.
It took me ages to learn to juggle but now I can keep three things up in the air instead of two. It took me a fair ammount of time to grok Perl but now it lets me be very productive. Complicated things take time to learn, so don't write it off just because it doesn't look (or think) like C/C++/C#/Java. To the people saying "use C/C++/Java for proper apps" it's like saying "don't build your house from wood, you must use bricks".
As has been commented before, what Berlin needs is an X compatability layer, in the same way MacOS X has Cocoa and.... erm.... whatever it's called to support both backward and forward compatability.
That way, all of a sudden your existing apps (X, GTK, KDE....) work on the new platform and new apps (and rewrites) get to take advantage of the funky new architecture.
The trouble is, this is a very unglamourous project to take on. Who would want to do that when they could be playing with their transparent terminals?
"Release early. Release often. And listen to your customers."
This assumes that your customers express their dissatisfaction, or even realise that something is wrong. Your average (non-geek) user will just accept that things are the way they are. How do you explain the dominance of Windows (BSOD et al) otherwise?
I strongly suggest you look at Mason. It is a Perl equivalent of ASP or PHP. It also has several very useful tricks such as templating and caching. While it traditionally works with mod_perl under Apache, some people have got it to fly under CGI.
Slashdot Mirror
From Apple's Firewire page:
Now, call me a pedant, but that's five words.
According to the SVG project page, it won't be integrated until the licence conflict with libart (LGPL only) is resolved.
I've read comments by Larry to the effect that Perl is great at writing lexers but not parsers. If you look at some of the later examples (around page 11) it's clear that he's trying to make Perl regexes powerful/clear enough to parse Perl. They remind me of yacc/bison, which makes sense.
Can I suggest that you read ...And Now for Something Completely Similar by Damian Conway.
Read this document to find out why the spaces appear and what you can/should do to fix it. Nobody said standards compliance wouldn't hurt.
In some VB code I saw:
' Add one to the counter variable.
intCounter = intCounter + 1
No kidding. Every line was commented that way. I didn't know whether to laugh or cry.
I probably don't understand your question properly, but map returns a list and foreach doesn't. Also the former is more functional, the latter more procedural. I guess it boils down to TMTOWTDI.
The same applies for their redunancy in the face of hyper-operators. Why scare of people who are used to procedural programming by turning Perl into a something very functional? It took me a while to get used to using map when I first started and I guess the same will apply when hyper-operators appear. Backward (and sideways) compatability for programmer's brains?
Apologies; I was referring to B5 and should have quoted the comment I was replying to. Of course I don't want to see Picard stretched to 16:9! I have a hard enough time explaining widescreen to the family. B5 was filmed in widescreen although it looks like much of the CGI wasn't, which causes problems.
I'll only buy it if they release it in anamorphic widescreen. There used to be a petition site somewhere to this effect, but it's disappeared as far as I can tell. Fat chance of WB taking any notice, 7000 "signatures" or no. Their production on film DVDs is lackluster to say the least.
Bah! Humbug! If it's not on the web, how can it be real? :)
Yes, but the coder (i.e. the equation) and decoder (i.e. equation to image converter) of your spectacular fractal image have to know that the equation represents a fractal image. You cannot apply this technique to arbitrary data, so my original point about the general case still stands.
JPEG is a lossy image compression technique and we're talking about general lossless compression here.
Okay, the mysterious Dr. Wlodzimierz Holtzinski doesn't get a single hit on Google. Dr. Steve Smale hasn't release a paper in five years and is in his seventies. Retired, perhaps?
I'm still not impressed.
For example, at the top of the list Dr. Piotr Blass is listed as Chief Technical Adviser from Florida Atlantic University. But he seems to be missing from the faculty. Google doesn't turn up much on the guy either. Hmmm.
I've not even had time to check the rest yet.
Data compression is based on finding redundant data, i.e. repetition, that can be factored out. With random data this tends toward 1:1 as your increase the size of the data. Sorry, but I haven't got time to point you in the right direction, just hit Google with "random data compression theory" or the like.
It all boils down to the fact that you just plain can't compress random data in the general case.
What about the Tux2 file system that was announced on Slashdot last year? The SourceForge site is dead and Google only turns up the original announcement and links to dead pages.
And of course, if it had been Bruce Perens and Linus Torvalds instead of N'Stink we'd all be disgusted at the blatent attempt to pander to the Linux geek market, wouldn't we? Wouldn't we? :/
I'm not trying to sound stupid or off-topic here, but have you considered Mozilla? Beyond ther browser, they've developed a really interesting cross-platform C++ (and JavaScript) development platform. For a start there's a cross platform implementation of COM and you can develop your UI's in an XML dialect called XUL.
I was wondering about exactly this a little while ago when I came across this very interesting site called Database Debunking by Fabian Pascal. Very interesting to see such a "contrarian" view. He's the guy who wrote Practical Issues In Database Management.
Windows Mozilla and Netscape users wanting QuickTime support should vote for bug 74327 on Bugzilla.
I would say that embedded/lightweight Perl dialects will become *easier* to make given that Perl6 will be based on the (already existant) Parrot VM.
It took me ages to learn to juggle but now I can keep three things up in the air instead of two. It took me a fair ammount of time to grok Perl but now it lets me be very productive. Complicated things take time to learn, so don't write it off just because it doesn't look (or think) like C/C++/C#/Java. To the people saying "use C/C++/Java for proper apps" it's like saying "don't build your house from wood, you must use bricks".
As has been commented before, what Berlin needs is an X compatability layer, in the same way MacOS X has Cocoa and.... erm.... whatever it's called to support both backward and forward compatability.
That way, all of a sudden your existing apps (X, GTK, KDE....) work on the new platform and new apps (and rewrites) get to take advantage of the funky new architecture.
The trouble is, this is a very unglamourous project to take on. Who would want to do that when they could be playing with their transparent terminals?
Have none of the "time to replace X" posters heard of Berlin?
This assumes that your customers express their dissatisfaction, or even realise that something is wrong. Your average (non-geek) user will just accept that things are the way they are. How do you explain the dominance of Windows (BSOD et al) otherwise?
I strongly suggest you look at Mason. It is a Perl equivalent of ASP or PHP. It also has several very useful tricks such as templating and caching. While it traditionally works with mod_perl under Apache, some people have got it to fly under CGI.