Why the software industry is morally bankrupt, volume #0xDEADBEEF

[tim]

A blog comment in response to an argument that writing a parser for Perl is Turing-complete:

"That's some mighty fine left brain thinking there( especially for a Monday morning ), but does it in anyway affect any practical aspect of Perl? Like can it be used to show that Perl is more or less reliable/secure? This isn't a criticism of your node, but I left college 35 years ago, and this sort of analysis seems very ivory-tower-ish to me now. It's sort of like saying 'one cannot prove self-existence'. Is the fact that Perl cannot parse itself a good or bad thing, or can other languages do it? Does that make them superior?"

Computer science is an intellectual and pragmatic failure. Kids, if you're looking for a good career, major in English.

Comments

[asrabkin]

I didn't have a particular Turing-complete type system in mind -- I knew that some research languages had that property, and that it wasn't considered a per-se crazy thing to do.

I don't actually see why "parsing is/can be as hard as evaluation" is necessarily a problem. This seems like one of those very loose lower bounds we get a lot in CS -- where some problem has very hard instances, but in practice, the instances we care about are generally OK.

This is certainly an implementational headache, and a limitation for people who want to do program analysis, but I don't see it as directly relevant users. This property limits the variety and power of perl-analysis tools, but if I was dissatisfied with the offerings out there, I shouldn't be using perl anyway.

[tim]

Parsing is a solved problem. There's no excuse not to write a parser that you couldn't (in theory) prove termination for. I can't think of a reason why Perl's grammar needs to be undecidable other than the implementors' sloppiness.

In general, people are beginning to see that they need to be able to reason about their programs. If you want to know something about your code, you also need to know something about the language environment you're using to execute it (remember the whole what-you-see-is-what-you-execute idea from Grammatech?) In general, proving a compiler correct is a very hard problem. If you were going to write a Perl compiler, there would be very little you could prove about it given that you can't even write a parser that is guaranteed to tell you in a finite amount of time whether your program is syntactically valid.

You might say that if someone is programming in Perl, then they don't care about reasoning, but it is at least important for a Perl programmer to be aware of how low their confidence must be that their programs will do what they expect. "Reasoning" means that you can predict what a program will do by thinking about it logically and you don't have to resort to finding out through the scientific method. That it's so difficult to reason about Perl is a shortcoming of the language and it's worrisome to see people dismissing it as "ivory tower nonsense".

[asrabkin]

Mm. I think if you're programming in perl, you probably already know that you won't have a lot of confidence in it. People joke about perl being a write-only language -- if you care about your program, and you expect to be maintaining it, you shouldn't be doing it in perl anyway, so the fact that it's hairy in a deep computational sense is maybe irrelevant, given that it's hairy and error-prone in every other way, too. It's sort of satisfying to know that the defects in perl really are deep and fundamental; but even the ephemeral and shallow defects are quite serious enough that anybody using perl for something critical should have their programming license revoked.

It's a language designed for knocking out short little scripty things, that probably only get run a handful of times. And yeah, certainly, nobody ought to design a language like perl in the future -- but precisely the problem with perl is that it grew by accretion.

[tim]

I think we're saying the same thing. If you're using Perl, you ought to know that you don't know a lot about what you know about your programs. Programmers like the commenter dismissing the undecidability of Perl's grammar as "ivory tower nonsense" are dangerous because they aren't aware of how much they don't know. People like that generally don't think they need to test their code, either.

[wkfauna.livejournal.com]

It really is possible to write elegant, efficient and maintainable Perl. I've worked at two companies with very large codebases that fit this description.

Perl, however, is noob-friendly enough to allow even unskilled people to write programs that work, and also geek-friendly enough to allow people to run Perl golf contests. These two groups, IMO, give it an unfair write-only reputation.

[wkfauna.livejournal.com]

One of the main selling points of Perl is its syntactic expressiveness. I don't think implementation sloppiness is the main reason why the grammar is undecidable.

[tim]

Well, since I'm not too familiar about the language, do you have a quick example that shows what expressive power you get with an undecidable grammar that couldn't be easily accomplished through some other language design mechanism?

[wkfauna.livejournal.com]

Heh, no, because your "easily accomplished" clause is too broad (what's easy? what's another mechanism? does conciseness count? etc). But the example "whatever" clause in the original post is interesting and shows some features that are each either neat or horrible, depending on your point of view:
* passing args without parens
* implicit matching on $_ and the existence of $_
* void context and the lack of failure thereof

Anyway, I'm not here to argue for the beauty of the design of Perl, 'cause even I think it's horrible. There's certainly plenty of design and implementation sloppiness there to go around. One just has to look at the way sort works to be convinced of that (hint: it involves manipulating symbol tables).