Slashdot Mirror

You really think Amazon wants to take the PR hit by suing a contractor who worked in their warehouse for 10 dollars an hour?

Great, then they should have no problem removing the portion of the agreement that would give them the right to do so.

http://blog.plover.com/law/contracts.html

Aren't these called constraints or propagation networks?

Structure and Interpretation of Computer Programs and Higher-order Perl have got something to say about these.

I agree with almost everything Mark Jason Dominus says in this http://perl.plover.com/yak/presentation/

A system using proper fractions can actually get exactly the right answer every time OR it will overflow and we will know for a fact the answer isn't exact.

What theory of numeration are you using, that has all numbers rational? I'm sorry, but even the humble square root is something I don't want to give up, to say nothing of transcendental functions. The theory of exact arithmetic on the reals is not all that well developed. Bill Gosper makes a start, and a handful of researchers take it somewhat further, but actually using exact arithmetic for everything you'd want to do remains a mirage.

If it's at all like Higher-Order Perl, it certainly isn't some new breakthrough paradigm. It's LISP re-invented. I hope the author understands LISP (or better yet, Scheme) so he doesn't re-invent it poorly.

This sounds a bit like Berry's paradox: "Some natural numbers, like 2, are interesting. Some natural numbers, like 255610679 (I think), are not interesting. Consider the set of uninteresting natural numbers. If this set were nonempty, it would contain a smallest element s. But then s, would have the interesting property of being the smallest uninteresting number. This is a contradiction. So the set of uninteresting natural numbers must be empty."

So perhaps by the same logic there are no non-notable languages. Go! is notable merely because it's not notable.

Wikis are great for collaboration, and can be exported into LaTeX.

MJD of Perl fame wrote a great book, Higher Order Perlwhich is open source and has interesting community-based achievements, such as the most recent edition having been made of edits contributed on a bug tracker, iirc, among other such notable achievements.

I use blosxom, which is extremely lightweight. The only way to get lighter is to have a static blog. It's only about 800 lines of Perl in a single script, so anyone who knows a little programming can easily become intimate with it. Many people who use it, including me, slowly modify it over time to fit our needs, molding it like a piece of putty. Its small size, with its worse is better tradeoffs, makes it pretty robust in terms of security, because there isn't any complexity in which to have vulnerabilities emerge.

In the two years I have been using it I'm only aware of one vulnerability, which was a mere cross-site attack where a specific argument in a URL could inject HTML. If you renamed the script from the default (which should be done out of caution anyway) and had on URL rewriting, then you were immune.

The only downsides are no comment system and lack of navigation links, though there are plugins for those features.

I use blosxom, which is extremely lightweight. The only way to get lighter is to have a static blog. It's only about 800 lines of Perl in a single script, so anyone who knows a little programming can easily become intimate with it. Many people who use it, including me, slowly modify it over time to fit our needs, molding it like a piece of putty. Its small size, with its worse is better tradeoffs, makes it pretty robust in terms of security, because there isn't any complexity in which to have vulnerabilities emerge.

In the two years I have been using it I'm only aware of one vulnerability, which was a mere cross-site attack where a specific argument in a URL could inject HTML. If you renamed the script from the default (which should be done out of caution anyway) and had on URL rewriting, then you were immune.

The only downsides are no comment system and lack of navigation links, though there are plugins for those features.

Perl became popular because it is very good at what it was designed to do - munging text with incredible flexibility and impressive speed - and it was the best available tool for the job when that ability was in high demand: the birth of the web.

Now, you can argue syntax ugliness all you want, I consider that subjective. However, when you begin to truly grok all of Perl's abilities, it's hard *not* to appreciate a fundamental beauty to the language.

I dare say, would you declare the German language a "monstrosity" because to American ears Deutsche has too many harsh-sounding words? Tell that to a German and he'll gladly smack you upside the head with a book of Goethe's poetry or perhaps the works of Wagner or Strauss!

Go read "Higher Order Perl" by Mark Jason Dominus and learn how to leverage Perl's features using the same techniques that LISP and ML programmers take for granted...

As a native speaker of Perl, I actually consider sigils and braces quite natural and beautiful.

Perl Regular Expression with backtrack is NP-Complete.

Personally I hate Perl's object system.

Ha. You speak as if there were only one. (I wish). Multiple different ways of implementing Objects exist in the perl 5 world, and there are many, many new attempts at fixing perceived limitations of the earlier styles. You've got your choice of Moose, Object::InsideOut, Class::InsideOut, and so on.

Whether this is a symptom of perl's glorious diversity or a lack of sane standardization, is of course open to question.

It's not that Perl 5 is broken, it's that other languages are evolving to a new level (in many cases a new level of LISPness :)).

Perl 5 is already pretty-lispy: Higher-Order Perl.

Then, check out this new one, High Order Perl:
        http://hop.perl.plover.com/

I'm half way through it, and I already can't wait to see how it ends! Heh :)

        -dZ.

...one day a language more like haskell and less like C will end up being the most popular.

Welcome Perl. Read Higher-Order Perl ( http://hop.perl.plover.com/ ) if you don't believe me.

Best of all, it's always installed on all unix boxes (including macs!)

The only thing that's lacking is automatic palatalization across many cores for map{} operations, but I'm sure I can write a custom iterator to bucket things into N-threads on N-core CPUs if such a need arises.

This is really why perl is shunned.

Obfuscated Perl

http://perl.plover.com/obfuscated/bestever.pl it doesn't have three meanings specifically, but its a program that can run as a perl script, OR a postscript document, and produces different output as each.

Mark Dominus over at A Universe of Discourse came up with a program called runN which would accomplish a similiar task but without having to write out a specific Makefile for it.

You provide a command, number of jobs, and a bunch of files to run it on (after a "--" argument),

# Untar files in parallel, 4 at a time
runN -n 4 tar -xzf -- *.tar.gz

# Encode 4 video at a time (from parent's example, but I don't know how tovid actually works)
runN -n 4 tovid -ntsc -dvd -noask -ffmpeg -in -- *.avi

Of course, your Makefile option provides a bit more control as you can specify an output filename, and if you must specify an output filename, runN will not work. In any case, any solution which uses processes instead of threads is a good solution.

M. Crane wrote a follow-up sometime later describing how to make it more useful (and make the above examples actually work).

Mark Dominus over at A Universe of Discourse came up with a program called runN which would accomplish a similiar task but without having to write out a specific Makefile for it.

You provide a command, number of jobs, and a bunch of files to run it on (after a "--" argument),

# Untar files in parallel, 4 at a time
runN -n 4 tar -xzf -- *.tar.gz

# Encode 4 video at a time (from parent's example, but I don't know how tovid actually works)
runN -n 4 tovid -ntsc -dvd -noask -ffmpeg -in -- *.avi

Of course, your Makefile option provides a bit more control as you can specify an output filename, and if you must specify an output filename, runN will not work. In any case, any solution which uses processes instead of threads is a good solution.

M. Crane wrote a follow-up sometime later describing how to make it more useful (and make the above examples actually work).

Because Lisp wasn't so much invented as discovered. It was a mathematical formulation, with a toy syntax, meant for pure mathematical work, that was never meant to be implemented as a real programming language. Then a grad student had the bright idea to write eval in machine code... thus creating the first interpreted language. Ever.

Those same mathematical principles apply to any programming language, and thus each new language is just slightly more Lisp-like than the one it replaces. Java is C++ with garbage collection (invented in Lisp). Perl added closures (invented in Lisp) to many peoples' everyday vocabularies -- every time you type "map { ... }" or "sort { ... }" in Perl, that's Lisp peeking through. Perl 6 is going the extra step of adding Lisp-style macros and a user-modifiable grammar, thus making it (in the mathematical sense) a dialect of Lisp, albeit one with a funny syntax.

Go read Paul Graham's What Made Lisp Different, then claim that it's just a coincidence that every new programming language borrows more and more ideas from something invented in the 1950s. Then do yourself a favor and buy Higher-Order Perl.

Perl can be used as a functional language. It can also be used as an object-oriented language, especially if you use a modern OO library instead of the low-level core support for object-oriented development. Perl is also a great structured programing language too, of course.

Other than Systems Programming and Operating Systems, you could use Perl and CPAN to address all of the computer science subjects you mention, and you could use the Inline module and the other modules in its namespace to teach other languages, within the context of a Perl development framework.

I'm not suggesting that universities should switch from all-Java to all-Perl (though doing so would probably improve productivity for most programmers, so long as they're taught to use Best Practices and not create the write-only code that bad/non programmers often create with Perl.) Instead, I'm thinking that an introductory course could teach Perl syntax and best practices, and use that as a basis to provide introductory training in all of the different development styles and subjects you've touched upon. By using one language that is flexible enough to cover this wide variety of material, the topics could be covered without confusing beginning students with a variety of languages.

Also, in the olden dayf, why is S so very often replaced by f? WTF is that?

At that time, it wasn't unusual to write the long medial "s" as an "f". Somewhat randomly, here's some quick reading on the subject .

If you know perl, you can learn functional programming in about a day. You can learn the concepts involved in about an hour. See http://perl.plover.com/lambda/.

As far as your example goes, note that if you allow yourself mathematical syntax, since trans1 = G(item), F(trans1) = F ( G(item) ). Indeed, since F and G are functions, we can create a new function (F o G) given by the rule (F o G)(x) = F( G(x) ). This is called functional composition. Lambda is a function constructor, as it is in the lambda calculus.

The functional program says:

1. create a function called 'compose2' which takes two arbitrary functions (which for the purposes of the definition will be called F and G) as arguments. Define compose2 as F ( G ( x) ).

2. Let "target" be the result of applying (F o G)(x) (as described above) to each element in a list called source_list. (The semantics of map mean that target is a list such that target[i] = (F o G)(source_list[i])

Way simpler, once you get it.

In real life, most OO perl programmers are bombarded with example code, third party modules, and CPAN modules that are not OO. Because of this, most perl code falls back on it's procedural roots out of frustration. You can blame this on the programmers, but this doesn't happen nearly as much in Ruby or Python.

What it might be is that OOP itself has been over-sold as a holy grail, and it's not such a bad thing to be able to bail on it and write proceedural code.

Or for that matter, functional code: Higher Order Perl.

The whole 'we need better abstractions' thing comes up every time this topic comes up. I'm not sure it matters very much; if someone finds an abstraction that is clearly better, it will quickly be adopted. That better is probably measured with power and democracy, all the power in the world isn't very useful if no one else can understand it. I would point out that language(programming languages are largely highly formal versions of human languages) is already pretty abstract, and it has been evolving for thousands of years. I doubt that humans will abstract abstraction any time soon.

An interesting discussion of it happening with nobody noticing:

http://blog.plover.com/prog/design-patterns.html

they already do! I came across this the other day:

private getThis() { return this; }

One of my favorite articles on the web about regular expressions is How Regexes Work by Mark-Jason Dominus. It's a great article if you're at the point where you already have some experienceusing regular expressions, but you want to gain some insight into how they do what they do. I found that after I read this article it was easier for me to come up with cleaner regexps more quickly.

I haven't read the book being discussed. It probably covers the same stuff, but I found M-J D's article easy to read, short, and very informative.

With this new technology, programming in Perl is going to be mistaken for a new dialect of Swahili.

@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q*=2) +=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_}=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[ P.]/&&
close$_}%p;wait until$?;map{/^r/&&}%p;$_=$d[$q];sleep rand(2)if/\S/;print

Anyone? (from here http://perl.plover.com/obfuscated/)

That's a joke, right? (Please tell me you're joking.)

You might be right that he's not a functional programming guru, but I think your argument is a bit of a strawman. On the book site, he says "Higher-Order Perl is about functional programming techniques in Perl. It's about how to write functions that can modify and manufacture other functions." It doesn't say it's about functional programming in general, or how to be a good functional programmer, but how techniques from functional programming can be applied to Perl. In any case, you might look at for example this message, or this one or this one to decide if he knows enough about functional programming (I couldn't tell you).

You might be right that he's not a functional programming guru, but I think your argument is a bit of a strawman. On the book site, he says "Higher-Order Perl is about functional programming techniques in Perl. It's about how to write functions that can modify and manufacture other functions." It doesn't say it's about functional programming in general, or how to be a good functional programmer, but how techniques from functional programming can be applied to Perl. In any case, you might look at for example this message, or this one or this one to decide if he knows enough about functional programming (I couldn't tell you).

to make things look difficult
(or like in another post :
it looks like perfectly normal code)

I don't think it does. I couldn't make sense out of it, even though I also cleaned it up first.

It doesn't run on Windows, and I've never used pipe in Unix, and very rarely used fork. So that's my excuse for not understanding it. But I suspect those who consider it as normal code don't quite understand it either. Or those who do must be quite great Perl hackers. On par with the author: Mark-Jason Dominus.

Anyway, the explanation is well worth reading.

Perl hackers may prefer to try to guess how it works from as little hints as possible:

Hint 1 | Hint 2 | Hint 3 | Hint 4 | Hint 5 | Hint 6 | Hint 7 | Hint 8 | Hint 9 | Hint 10 | Hint 11

Others will jump straight to the spoiler.

I'd also recommend MJD's Higher Order Perl if you want to go even deeper.

[obvious]First, you shouldn't just try to execute code you find on /.[/obvious] Second, you can send your bug reports to the site that I stole the snippet from: http://perl.plover.com/obfuscated/

He said that it can't be obfuscated perl contest. The thing you gave comes from here which is the second place winner of the 5th anual perl obfuscated contest...

First of all, we know we have to use a functional language to design the program.

No you don't. You can use any language you want.

So what we're left with are languages like C and Pascal, PHP

So how is it you throw out C++, Perl and Python in your "have to use a functional language" cut, but C and Pascal survived? C++ at least has libraries like Boost.Lambda, and Higher Order Perl shows off it's functional side a bit. And of course in your final list of languages, the closest thing you have to a functional language is Lisp (which is commonly thought of as functional, but it's really multi-paradigm, and is more often than not coded in an imperative manner). Me = confused...

Anyway, the bottom line is: choose whatever language you want to use.

Here.

There's some validity to your point here. In this case, static typing signals you at compile time that you made a "stupid" mistake (ie, a mistake not caused by an improper understanding of the program requirements). But a dynamic language would signal the error just as quickly, because you'll get a clear, obvious error the first time your code runs.

Though the error may be clear and obvious, knowing it the first time the code runs can be too late. I've wrote code that can only run a few weeks every year (nothing important, but the nature of the program limited it to running only at very specific times), and Python has allowed numerous stupid bugs (typos, etc.) to stay dormant until I was able to run it. Static typing would have been very useful in this case.

Pychecker is a step in the right direction. It doesn't do very advanced type checking, but can warn you about inconsistant return types (returning a string in one path, but another data type in another, for example) at least. MJD's Strong Typing and Perl discusses how strong and static typing can be done right (in ML), in order to prevent many bugs at compile-time (in his case, infinite recursion). I hope we see more options for static typing in Python, if only as an option. I wouldn't want to not ever be able to write simple Python programs without declaring every variable, but for larger programs, static typing is definitely useful. Maybe in the future we'll see more languages that are able to prove that a program is correct (using static typing, etc).

regular expressions are nice and all but i still cant get used to them .. a good manual should be kept handy at all times. [ ... ]
Suggestions are welcome.

I have a suggestion. Write a few regular expressions to get your brain refreshed on them, then go read this excellent article on how regular expressions work. At the very least, it will clear some confusing things up. Most likely you'll find that having a better understanding of the underlying concepts will make it easier for you to work with regular expressions day to day.

Also, it helps if you are familiar with finite state machines. I learned about them in a couple classes while getting my CS degree, but they're not that hard and most people should be able to grasp them without any kind of formal CS training.

In this talk appears the quotation:

It was only because he was unfamiliar with 1960's programming styles that he thought that one goto every fifty lines was a frequent use of goto.)

Which made me physically shudder. What could these ancient horrors look like? Could anyone post a link to some of this ancient and offensive code? I mean I've written code for school if a group member has used *a* goto. This is something I need to see.

ML!?!!! But that's yet another functional language I don't know!

Sigh... you may or may not have been joking here, but I want to make it clear that I said ML instead of OCaml is because it's common across the ML family of languages, just as some concept may be common to *nix or *TeX.

Yes, of course it makes sense, and no thanks for the slur on my education

Hey, you're the one who said you only had a minimal introduction to recursion. And since you said that the horrific example of recursion you gave came straight from that introduction, I'd have to surmise that it was a very poor introduction. You've certainly given me no evidence to the contrary... Especially when you say things like:

So far, you've had to resort to special FP specific tricks like "memoization" and "tail-recursion" in order to try to match normal imperative programming results.

Memoization and tail recursion are hardly FP specific.

I'm not sure I'm interpeting your example correctly, but this is what I think it does, and the minimal mental operations required to process it:

Close-ish, but not quite right. It's more like:

(1) Define a function map that takes f and lst as parameters
(2) Define a function map_helper, local to map that takes three parameters, f, lst, and acc. This function does the following:
(3) Pattern match on lst. If lstis an empty list
(4) Reverse acc
(5) Return it
(6) Otherwise split lst into its first element and a list of the remaining elemets, call these head and tail.
(7) Apply f to head
(8) Cons the result onto acc.
(9) Overwrite the current stack frame with a new one where f is the same as it was before, lst is replaced with tail, and acc is replaced with the value computed in (8) -- Goto (3)
(10) Call the function defined in (2) passing it f as f, lst as lst and an empty list as acc.
(11) Return whatever value this hands back to you.

Note that there is no stack growth (well, there is one new frame appended for the first call to map_helper [I think... the compiler may optimize this call away as a tail call as well -- I'll have to see if that's the case]), and then for every additional call to map_helper, the current stack frame is just reused. And so we have the following concepts to handle: Define a function, apply a function, add and remove elements to/from the head of a list, return a value. That's all...

Of course there are a few neat things that go on under the hood here. For example, the compiler is able to determine the following things about map:
map_helper's f must be a function that takes something of unknown type 'a and return a value of unknown type 'b ('a -> 'b). It knows this because we apply it to head in step (7).
map_helper's lst must have type ('a list). It knows this because f (of type 'a -> 'b) is applied to head in step (7), so head must be of type 'a, and the list it came from must be an 'a list (as OCaml lists are homogeneous).
acc must have type 'b list, because we stick (f head) in it, and f returns values of type 'b.
map_helper is a function of type (('a -> 'b) -> 'a list -> 'b list -> 'b list) because it takes f, lst, and acc of the first three types and returns the reversed acc, which has the same type as acc
map's f and lst are of type ('a -> 'b) and 'a list respectively, because that's what it passes into map_helper's f and lst, and it

I know their agenda. Their next is to block the access to the devil avocating BSD and its submissive linux partner.

For those who have not caught the joke, please load the images :-)

<opinion>

I think that Java is the language of choice for Software Engineers. Software Engineers are people who write specs, unit test, meet deadlines, write good API's....You know what I mean -- the under-appreciated grunts of the software industry. They are NOT as brilliant as the hackers, but over their lifetime they will be more productive. Just not in any 24 hour period.

There is alot of stuff that definitely be done faster in $LANGUAGE_X than in Java.

To a man with a hammer, everything looks like a nail. --- Mark Twain

I don't know how maintainable/scaleable/reusable $LANGUAGE_X is compared to java, but I have yet to be on a larger commercial project where realistically, you could expect the code to be maintained by at least 100 different developers over the next 5 years in which anything other than the uber-development languages of Java, C or C++ were being used. Of course I've never worked on a MSFT compatible project either -- I'm sure that VB is used on that scale as well.

Hackers and Software Engineers by definition have different skill sets and goals. You need both. I find I like to let the hacker do it his way, and then we do what we need to language wise to make it conform to "best practices," which the hacker finds restrictive and chafing.

Henry Ford did not invent the car, but he brought it to the people. He was an engineer, not a hacker. And there is room for both types in every industry.

But I guess there is no point in posting to this thread without a backhanded stab at one of these religions, so how about this

I've left the opinion tag open for people who want to reply -- if you're posting FACTS you should close it 8)

I had that explained to me in person in an excellent, unrelated presentation at YAPC 2002 by Mark-Jason Dominus when he failed to follow his own advice.

I had that explained to me in person in an excellent, unrelated presentation at YAPC 2002 by Mark-Jason Dominus when he failed to follow his own advice.

It's seven lines anyhow. http://perl.plover.com/qrpff/article-main.html

$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a= unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map {xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$ d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[ 3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8)) <<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6) )<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,1 1,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a ^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}( 16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128.. $#a]}print+x"C*",@a}';s/x/pack+/g;eval

@P=split//,".URRUU\c8R";@d=split//,"\nrekcah xinU / lreP rehtona tsuJ";sub p{
@p{"r$p","u$p"}=(P,P);pipe"r$p","u$p";++$p;($q *=2)+=$f=!fork;map{$P=$P[$f^ord
($p{$_})&6];$p{$_ }=/ ^$P/ix?$P:close$_}keys%p}p;p;p;p;p;map{$p{$_}=~/^[ P.]/&&
close$_}%p;wait until$?;map{/^r/&&<$_>}%p;$_=$d[$q];slee p rand(2)if/\S/;print

Perl Contains the Lambda Calculus.

Working with the Lambda Calculus on a computer, as a mathematician who is used to only the brain and pen/paper, makes me alternatively want to piss my pants and orgasm everywhere. It's, like, the simplest programming language on the earth!

BTW, a nondeterministic finite automaton is much less flexible than ordinary code; there are many things (checking for palindromes being the classic example) which code in a programming language can do but an NFA (and hence a regular expression) cannot. What you mean is that regexps provide a more concise syntax, and perhaps a more efficient implementation (since the regexp engine is in C).

Perl's so-called regular expressions are not true NFAs however, because they have wacky things like backreferences. In fact they are NP-complete.