Good to see you're starting on PHP, Rad. The big question though, which isn't related to PHP as such is how comfortable are you with regular expressions? Those are the things we were actually dealing with in the mod_rewrite rules, to transform the incoming URLs to something else, but it hadn't occurred to me to ask at the time if you were familiar with them.

If there's one skill associated with PHP that I would recommend you concentrate hard on, it would be those; since web pages are just big documents, and regular expressions are so useful for wrangling strings, so practice every web-related technology uses them heavily. Being really comfortable with both reading and writing them will give you a real leg up.

Hi Nigel. Regular Expressions are covered in chapter 9 .. which begins like so:


Quote:

Programmers build applications that are based on established rules regarding the classification, parsing, storage, and display of information, whether that information consists of gourmet recipes, store sales receipts, poetry, or some other collection of data. This chapter introduces many of the PHP functions that you’ll undoubtedly use on a regular basis when performing such tasks. This chapter covers the following topics: • Regular expressions: A brief introduction to regular expressions touches upon the features and syntax of PHP’s two supported regular expression implementations: POSIX and Perl. Following that is a complete introduction to PHP’s respective function libraries. • String manipulation: It’s conceivable that throughout your programming career, you’ll somehow be required to modify every possible aspect of a string. Many of the powerful PHP functions that can help you to do so are introduced in this chapter. • The PEAR Validate_US package: In this and subsequent chapters, various PEAR packages are introduced that are relevant to the respective chapter’s subject matter. This chapter introduces Validate_US, a PEAR package that is useful for validating the syntax for items commonly used in applications of all types, including phone numbers, Social Security numbers (SSNs), ZIP codes, and state abbreviations. (If you’re not familiar with PEAR, it’s introduced in Chapter 11.) CHAPTER 9 ■ STRINGS AND REGULAR EXPRESSIONS Regular Expressions Regular expressions provide the foundation for describing or matching data according to defined syntax rules. A regular expression is nothing more than a pattern of characters itself, matched against a certain parcel of text. This sequence may be a pattern with which you are already familiar, such as the word dog, or it may be a pattern with specific meaning in the context of the world of pattern matching, <(?)>.*<\ /.?>, for example. PHP is bundled with function libraries supporting both the POSIX and Perl regular expression implementations. Each has its own unique style of syntax and is discussed accordingly in later sections. Keep in mind that innumerable tutorials have been written regarding this matter; you can find information on the Web and in various books. Therefore, this chapter provides just a basic introduction to each, leaving it to you to search out further information. If you are not already familiar with the mechanics of general expressions, please take some time to read through the short tutorial that makes up the remainder of this section. If you are already a regular expression pro, feel free to skip past the tutorial to the section “PHP’s Regular Expression Functions (POSIX Extended).” Regular Expression Syntax (POSIX) The structure of a POSIX regular expression is similar to that of a typical arithmetic expression: various elements (operators) are combined to form a more complex expression. The meaning of the combined regular expression elements is what makes them so powerful. You can locate not only literal expressions, such as a specific word or number, but also a multitude of semantically different but syntactically similar strings, such as all HTML tags in a file. ■Note POSIX stands for Portable Operating System Interface for Unix, and is representative of a set of standards originally intended for Unix-based operating systems. POSIX regular expression syntax is an attempt to standardize how regular expressions are implemented in many programming languages. The simplest regular expression is one that matches a single character, such as g, which would match strings such as gog, haggle, and bag. You could combine several letters together to form larger expressions, such as gan, which logically would match any string containing gan: gang, organize, or Reagan, for example.

I'll take that as meaning you aren't familiar with them yet, but these are definitely the most important part of PHP for you to study and seek to completely understand. PHP itself isn't particularly interesting or powerful by comparison (although it's certainly useful as a practical tool, and worth learning on that basis alone, its design is terrible and it is otherwise just as undistinguished as all the other "popular" languages of that kind).

In addition to being an  important practically useful thing, regular expressions are are immensely important in other ways; when you get to the * operator, you will see it called the Kleene closure. Stephen Kleene was a logician in the early 20th who with that great mind Alonzo Church laid the foundations of modern computing well before the machines themselves existed.

They defined and laid out the mathematics of the regular languages (including regular expressions) and the lambda calculus (Lisp, essentially) in the 1930's. If you can gain a firm grasp of regular expressions, and you then do the same with Lisp (JavaScript is essentially a very simplified Lisp), then you will have within your grasp the ability to easily understand every computer language, because all any computer language is (or does) is express the essence of these ideas in superficially different ways.

wrote on May 24^th, 2008 at 12:19am:

I'll take that as meaning you aren't familiar with them yet

[smiley=smiley.gif] True.


wrote on May 24^th, 2008 at 12:19am:

PHP itself isn't particularly interesting or powerful by comparison

What *is* then, powerful & interesting by comparison?


wrote on May 24^th, 2008 at 12:19am:

its design is terrible

Can you provide a "for example"?


wrote on May 24^th, 2008 at 12:19am:

laid the foundations of modern computing well before the machines themselves existed

On purpose? Or did it simply turn out this way? I don't see how they could've laid the foundations of modern computing if no computers existed.


wrote on May 24^th, 2008 at 12:19am:

They defined and laid out the mathematics of the regular languages (including regular expressions) and the lambda calculus (Lisp, essentially)

Interesting. I never equated math with programming before, altho now, I can see how they would intersect. I've always been good in math. Math is my gig, so to speak. Had 2 semesters of calculus (both 'A's.).

Yes, this sounds like like it could turn into a very interesting discussion.  I've found PHP to be very useful (although I only know the basics.)  I'm thinking about learning a lot more about web programing soon for a side project.  Is there a language you suggest?  Is Rails as good as the hype?  Or do you just use Perl or some cgi scripting?  Or do you like the .NET languages?

Rad wrote on May 24^th, 2008 at 6:20am:

What *is* then, powerful & interesting by comparison?

Unfortunately, none of the languages that do fit that category are widely used for web purposes; there's a reason, for that, of course. By being deliberately simplified for the purpose of little more than wrangling strings, PHP and its ilk are easier to learn (and safer for hosting firms to deploy) than full-blown programming languages, and you'll be productive sooner than you would be with them.

However, just bear in mind that all PHP really is, is a vehicle for taking in and pushing out strings. You'll move beyond it one day, so don't get too invested in it, that's all. It will serve its purpose for you now, but as you learn more you'll almost certainly outgrow it.


Rad wrote on May 24^th, 2008 at 6:20am:

Can you provide a "for example"?

I could, but to be fair I'd be judging it as if it was a proper programming language, which isn't quite fair. Remember, PHP started as a very cut-down, deliberately simplified subset of Perl, which has then grown and mutated to serve pragmatic ends rather than to have much conceptual integrity.

You can do a lot with it, and do it well - as I've mentioned before, DokuWiki is an excellent example of good PHP code, one of the very few around, and you will learn a lot by studying it. However, as soon as your needs get very complex you'll be well outside the "sweet spot" for it as a tool.

PHP suffers most because all its original facilities were oriented around making simple things simple. Unfortunately, that has meant that trying to do anything complex in it is in turn very complex, and quite different. So, designs that start out small tend to quickly reach a point of collapse where they are unmaintainable messes - DokuWiki as an example, hit just such a wall and only coped with this by essentially going into hibernation for long time, and getting almost 50% rewritten (breaking all the existing user extensions to it).

A lot of PHP's bad reputation comes from this, because much of the non-trivial PHP out there is at or well past the point where its initial design no longer works.


Rad wrote on May 24^th, 2008 at 6:20am:

On purpose? Or did it simply turn out this way? I don't see how they could've laid the foundations of modern computing if no computers existed.

What computers do - what they can possibly do - is subject to some mathematical laws which are absolutely universal, and which these gentlemen had worked out in the context of what mathematicians called recursive function theory.

When real computers later arrived, Alan Turing was working out the mathematical limits of what they could do, which lead to the abstract model of them called the Turing Machine. Turing and Church then discovered that these two things - Church's recursive systems of equations, and Turning's machine with the tape - were absolutely equivalent in every way (and many other systems have subsequently turned out to be equivalent to them too).

Similarly, what Turing had posed as the Halting Problem for his machines (whether the programs would ever complete or not) turned out via this correspondence to be roughly equivalent to Kurt Goedel's famous Incompleteness Theorem, which established that there are limits of what could be determined via proof.

This deep equivalence between computers and the behaviour of recusive functions (and abstract models of logic and proof) was unanticipated and quite surprising. But it's there. Quite what this really means, in a philosophical sense, is something that has generated all kinds of thought.

For instance, many years ago, a mathematician called John Conway posed a simple evolving system called The Game of Life. Popularized by Martin Gardner in his Mathematical Games column, it became something of a hit (that particular issue was one I read as a child, in fact; the Mathematical Games column helped set the course of my life).

However, it was no mere diversion. What Conway and his collaborators were trying to investigate was whether they could create a simple system which was what we call Turing-complete, and whether it could in essence function as a computer. And it turns out that it can. Computation is almost inevitable, in fact

MrMagoo wrote on May 24^th, 2008 at 1:18pm:

Or do you like the .NET languages?

That's a complex thing. The .NET runtime (which you can study in the SSCLI aka Rotor) I would regard as a work of art. It really is a thing of beauty, and there are parts of the framework (such as the regex implementation) which use it in exquisite ways.

The languages, not so much, although they are definitely evolving in the right way.

When Java came out, the marketing hype was that it would be an amalgam of Smalltalk (great) and Common Lisp (great) but be easier for C++ programmers (well, ok). Unfortunately, the last thing was really the only part that was really true, because they had thrown away all the great parts of Smalltalk and Common Lisp and was left with something that was really pretty lame, and which spawned a truly incompetent developer culture around it over the next decade.

.NET, in contrast, largely does meet the reality of allowing folks to combine the best of the best - it's reflective like SmallTalk, and if you want to you can do Lispy things in it too. Which leaves me on the fence about it as a whole, because there's so much to like - C#3.0 captures a lot of good language design, and the run-time is a great design, and they really did achieve a lot making all the specialized .NET languages  interoperate smoothly - but there's also some things around it that aren't so good. The libraries (the .NET Framework) have a lot of the "Java culture" about them, for instance, and for GUI work are tied far too closely to Windows.

Right now, nothing is all things to all people, especially because of the split between the client (JavaScript being the only game in town, and being a Lisp being naturally good) and server sides. And now you have things like Google App Engine giving a huge boost to whatever languages they decide to support in future. Whether (and how) Microsoft respond to this will be interesting.

Your posts are content-rich .. so much so that I have to re-read them ..  which I'm doing now.

If you ever need a web host, by the way, for anything .. I'd be glad to host you .. for free. I have plenty of available space.

I've made a similar offer to Magoo & NightOwl & Dan Goodall and others here .. but nobody has taken me up on the offer.

Just a side note .. as you obviously are well-read, and have interesting things to say. I have never done this b4, so it might take me a while to set it up, but it doesn't seem too complicated. All you would need is a domain name.

I would be interested to hear a single-paragraph description of all the popular programming languages .. as you see them .. compared and contrasted.

Looks like the most recent DocuWiki was released a few weeks ago:  http://www.splitbrain.org/projects/dokuwiki

Rad wrote on May 24^th, 2008 at 10:32pm:

I would be interested to hear a single-paragraph description of all the popular programming languages .. as you see them .. compared and contrasted.

It wouldn't be so interesting, really. I don't have the ability to write well enough to make it interesting.

Other people with similar knowledge to mine do it better and funnier, like Steve Yegge - this part of that little rant still gives me the giggles every time:

Quote:

There are "better" languages than Perl — hell, there are lots of them, if you define "better" as "not being insane". Lisp, Smalltalk, Python, gosh, I could probably name 20 or 30 languages that are "better" than Perl, inasmuch as they don't look like that Sperm Whale that exploded in the streets of Taiwan over the summer. Whale guts everywhere, covering cars, motorcycles, pedestrians. That's Perl. It's charming, really. But Perl has many, many things going for it that, until recently, no other language had, and they compensated for its exo-intestinal qualities. You can make all sorts of useful things out of exploded whale, including perfume. It's quite useful. And so is Perl.

You can't help but admire a phrase like "exo-intestinal qualities". The man can write.

Thanks for the offer of some web hosting, but I really don't have the time to do much of anything with that. The next year at work is going to be crushingly busy, albeit in a good way.

Oops, corrected the Life link to go to the right one here. My bad, forgot there was something else with a similar name.

Anyway, about programming, you're definitely going to do well with it. It's fun.

PHP *is* a good choice to start, but you you won't stop at one language. Just for web work you'll want to become familiar with JavaScript at some point, for instance, and probably you'll end up picking up either Perl or Python too just in the nature of things. Whether or not they are "good" in an abstract sense they are handy to know, and as you learn techniques from more languages it expands your repertoire for the others.

Do you have a clear idea of what you want to achieve with your first PHP project, yet? One of the things that we set aside after looking at the index.rad/.htaccess thing was making a script to make the "index.html" -> "index.rad" translation happen so that we can have two alternative views of the site content from a single set of source documents.

By the way, the business about Conway having created Life to explore computability was something I never knew; last year he was here in New Zealand and he gave a public lecture where he talked about that. It's always good to keep an eye out for opportunities like that to hear great men speak - keep an eye out on the websites of the universities near you!

Anyway, in addition to computability, Conway and his colleagues were also interested in von Neumann machines. If you read the science fiction of the recently deceased Arthur C. Clarke you may recall that in the book of 2001, the mysterious black monoliths were self-replicating probes, i.e. von Neumann machines, the same ones Conway was looking into.

Now, the architecture of the modern computer CPUs we use aren't things with tapes like Turing Machines are - instead, they are built on a thing called the von Neumann Architecture, invented by the very same John von Neumann who had earlier proposed the self-replicating machines that Conway was exploring.

This is good: http://steve.yegge.googlepages.com/tour-de-babel

(I am still there.) Thanks.

And von Naumann was part of the Manhattan project. Wow.

Pretty much every one of Steve's articles are gold. For instance, I commented earlier that PHP code starts to run into real problems as it grows; now, this isn't unique to PHP or indeed any language. It's largely a problem with PHP because people start using it because it's easy (which is a good thing, in the main) but then their small thing grows large.

As for von Neumann, yup, involved not just with the Manhattan Project but with guys like Paul Dirac on quantum mechanics.

Oh yeah, another thing which turns out to be able to run programs... Noam Chomsky, who spent much of the 20th century studying (human) language and communicaton, and devising grammars for them to describe human languages ... those grammars are equivalent to Turing machines too.

Since I've mentioned a linguist, this leads on to the Sapir-Whorf Hypothesis, which can close the loop on the discussion somewhat.

In computer language, this definitely holds. The computer languages you know and learn constrain the way you think about solving problems with them. It's absolutely the case that (the vast majority, anyway) of people work to solve problems using the terms and style of thought that goes with the language they use.

For regular expressions, this isn't a problem because they are part of the universal mathematical background (and producing and consuming strings is part of how computers deal with human beings, so are universally useful).

For computer languages, their power in solving problems is a seductive trap which can end up with one believing that their way of solving problems is equally universal, when other computer languages (are consciously designed to) embody different modes of thought yielding different solutions.

Hence, why you'll never stay still and won't stop with PHP. Even if you could get everything you need done in it, learning a different programming language will free your mind (and you'll get better in PHP as a result too, by being able to "step outside the box" somewhat).

So much to think about.

Regarding programming languages, it's hard not to be drawn to Ruby (& Ruby on Rails) as a result of reading Steves piece:


Quote:

If languages are bicycles, then Awk is a pink kiddie bike with a white basket and streamers coming off the handlebars, Perl is a beach cruiser (remember how cool they were? Gosh.) and Ruby is a $7,500 titanium mountain bike.

Quote:

For the most part, Ruby took Perl's string processing and Unix integration as-is, meaning the syntax is identical, and so right there, before anything else happens, you already have the Best of Perl. And that's a great start, especially if you don't take the Rest of Perl. But then Matz took the best of list processing from Lisp, and the best of OO from Smalltalk and other languages, and the best of iterators from CLU, and pretty much the best of everything from everyone.

He never did mention PHP, tho.

Rad wrote on May 25^th, 2008 at 9:50pm:

He never did mention PHP, tho.

True. In general though, pretty much everything that applies to Perl also applies to PHP; it's a little different because Larry Wall isn't involved and PHP's purpose is much more focused because it's a subsetted variant of Perl built purely for pumping out web pages rather than being a general Unix scripting tool.

It's less insane, but there are still whale guts everywhere. And of course, it's still eminently useful despite that.

Ruby's nice, no doubt about it. Try the interactive web tutorial. However, in the context of Web development there's a lot of .NET-style confusion between Ruby the language (which is nice but like Python effectively defined by a single implementation) and Rails the web framework which Ruby developers use.

Most people who talk about Ruby are really talking about Rails.

The thing about Rails is that although it happened on Ruby, it's really not that tied to it. Smalltalk and Lisp-like languages have done all this stuff for decades. The same things that the Rails folks are all ga-ga about are just "oh, so you're finally catching on to where we were in the 1970's".

Of course, there's a marketing problem with Smalltalk and Lisp, which is despite being both better than everything else which has tried to replace them, has the problem that they are a) old, and therefore not shiny and new and possessing "hotness", and b) a little weird to modern eyes which have only ever known the Windows PC.

So, although by all accounts Seaside a popular Smalltalk library does most of what Rails done and does much better besides, it can't become the flavour of the month, because it's "yuck Smalltalk, icky" to most modern developers (who have never look at, let alone learned a language designed before they were born).

Similarly the good parts of Javascript are taken straight from Lisp, but if that fact hadn't been disguised it'd never have got anywhere. In fact, it only got taken seriously because of the "Java" prefix, despite Javascript actually being Lisp and not garbage like Java ... which is inspired marketing, because it delivers on real authentic Lisp power but because Java was "hot" at the time, it traded on that hotness and got taken up by people who would never in a billion years go near a Lisp.

Most of language choice in the industry is just marketing, and naive faith that "new = better".

The reality is that Lisp and Smalltalk have never been exceeded as designs. Why .NET deserves to win is that it packages up Smalltalk, in particular, in a way that modern folks don't have a clue that it's where all the concepts they are using come from.

The big new thing in C# for instance, is LINQ. That's just a repackaging of a concept - List Comprehensions - that has been ho-hum in the functional programming world for decades. But LINQ, see, it's Shiny! And New! And a generation of developers will never realise that it's the same stuff the old-timers have been trying to tell them about for decades.

Well, crud. I mentioned linguistics and forgot to mentioned one of the funnest languages around - Inform. Seriously, just reading the manual written by Emily Short is a joy.

Those neato Lisp hackers at MIT delivered the goods in the 1970's creating a game built on Lisp's ability to wrangle natural language (parse Chomsky Grammars, or at least a passable collection of them). A game called Zork, which ran on everything from mainframes to the 120Kb floppy disk in an Apple ][ due to being compiled to run in an amazingly compact virtual machine (the Z-machine), which was the first of a truly astonishing series published by the company they formed, Infocom (their motto: Imagination Sold and Serviced Here).

And Graham Nelson has taken that amazing work, and it's sometimes spooky ability to work with the written word as well as print it, and performed the ultimate art of linguistic Jujitsu; turned the natural-language system created by those guys to understand the input to the games to the purpose of writing the games themselves.

Inform is written in a language targeting Z, and reads a description of a game world written as a novel to compile into a Z-machine (runnable with the exact same code that ran Zork in the 1970's). It's the ultimate expression of Donald Knuth's concept of Literate Programming.


Quote:

ZORK I: The Great Underground Empire Copyright (c) 1981, 1982, 1983 Infocom, Inc. All rights reserved. ZORK is a registered trademark of Infocom, Inc. Revision 88 / Serial number 840726 West of House You are standing in an open field west of a white house, with a boarded front door. There is a small mailbox here. >open mailbox Opening the small mailbox reveals a leaflet. >read leaflet (Taken) "WELCOME TO ZORK! ZORK is a game of adventure, danger, and low cunning. In it you will explore some of the most amazing territory ever seen by mortals. No computer should be without one!" >

Inform sometimes has to strain a little to maintain the metaphor of writing a novel to express a program, but it's an amazing accomplishment nonetheless. If only I could use it instead of C++ at work :-)

Just wanna say, Nigel, I'm still pluggin' away at learning PHP. Been distracted with legal things recently, but those should clear up in a month or so.

I'm digging it. One quote that stuck out called PHP » "The reigning king of web development."

Heh. At some point in the near future I'll be writing a lot of PHP myself again; I need to port all my changes to DokuWiki (I did a HUGE amount of customization to it back on our internal site web when I moved us to that in 2003/2004) to the 2008 edition after reformulating the changes that I made which the base version hasn't caught up to as plugins against it.

[ And hopefully, this time I'll be able to contribute them back. Couldn't back in those days due to the hostile ex-PQ VP, but he's not ruining our lives any more. ]

Probably will have to be done after-hours though, like the first time around. Be nice to actually do some of this stuff on paid time for a change, but unless we hire more folks I'll never ever get a free hour in the office.

Incidentally, as for "king of web development" it's interesting to look at the stats for requests for languages to run with the Google App Engine (which is Python-based to start, largely because Google hired Guido van Rossum).

Note that Java, of all things, is the #1 requested thing; PHP second, with Ruby and Perl in the next two spots. The next language listed is the one I'd prefer it do over all the others, JavaScript (because it's a Lisp, so it's automatically more powerful than any non-Lisp, and unlike full Common Lisp or Smalltalk the fact it's the linchpin client-side for web development already makes it a win over them), but as you can see that's only the fifteenth issue overall.

Bear in mind that Java also might have picked up votes from people who really despise Java but who know they can at least use the JVM to run something better than Java itself, though (viz the 150-ish folks having also explicitly asked for the JVM separate from Java).

wrote on Jun 15^th, 2008 at 11:23pm:

At some point in the near future I'll be writing a lot of PHP myself again

Again? Didn't know you dabbled. I know you told me about Dokuwiki (I've visted the site several times.) But didn't know you actually worked with it.

I am not very familiar with the Google apps. I know Java is a popular language, but I don't find many Java apps on the web.

I read some things about JavaScript, as it pertain to web design, and because it is implemented in the browser, it's know to cause an awkward "flickering" is some instances .. after the web page loads .. but before the JS runs.

But you know way more about this stuff than me.

I've also been watching TortoiseSVN, which should be releasing v1.50 any day/week now. That seems like it would be a good launch pad.

http://tortoisesvn.net/

Rad wrote on Jun 15^th, 2008 at 11:53pm:

But didn't know you actually worked with it.

One can cover a bit of ground when one is interested in something from a young age and is able to pursue that interest with monomaniacal intensity for several decades. I recently compared notes with a musician (singer/songwriter) also in his 40's, who I first got to know when he was performing while I was a student over 20 years ago; he got his first guitar when he was about 12, a similar age to when I chose computing/mathematics. And neither of us has (or likely will) ever stop trying to get better at what we have chosen as our life's direction.

The comparison is helped by the fact that just as all (Western, anyway) music is played on the same scale, computing has the single mathematical basis I talked about earlier.

Really there are only two major kinds of computer languages, and in the imperative group in particular which accounts for all the languages most working programmers can deal with, almost all of them are really similar in all but their surface aspects. They all are basically derivatives of the classics from the 50's and 60's - FORTRAN and Algol - to some degree, with perhaps a dash of string-processing mixed in for the more scripty ones (the notable progenitors of that sub-species being Ralph Griswold's SNOBOL and later Icon), and where they differ beyond this is merely to cut their cloth a little differently to tailor it for some application area.

Learn FORTRAN, something low-level like FORTH, something string-oriented, and something object-oriented, and you've basically covered almost everything any language in the imperative world can really throw at you - and then it's just a matter of ticking off the applied use of them in different problem domains; databases, concurrency, networking, user interfaces, and so forth. In the application areas some language may bring a certain ease (or be cumbersome) based on some specific built-in facility or other, but none of them really solve problems in a way that involves a truly major difference in how you think.

Now functional languages - particularly lazy-functional languages like, say Haskell, named another of the logicians working in the early 20th century on formal logic along with Church and Kleene (there is an important technique in the lambda calculus called "Currying" also named in his honor) - are another kettle of fish entirely, but then if you've gone through one of the related branches of mathematics (denotational semantics, category theory, or the like) then you've done the hard part for the bulk most of the entrants in this sub-group as well, although they do differ more from each other than the imperative group.

Even so, in this sub-field if you cover say Common Lisp, Prolog and Haskell, then you've seen a good chunk of what's on offer from this group and then you're just mastering the applied problem domains (albeit with a different spin; functional languages used functionally treat time in a fundamentally different way to imperative languages, and the most gnarly problem domains in the imperative world are those which involve wrangling time in some way).

Rad wrote on Jun 15^th, 2008 at 11:53pm:

it's know to cause an awkward "flickering" is some instances .. after the web page loads .. but before the JS runs.

That's not so much to do with Javascript-the-language, so much as it's a consequence of the Document Object Model and the poor integration between HTML and script generally when scripting was first retrofitted into HTML and browsers. This flickering is a consequence of the way that classic old-school Javascript is written to manipulate the base HTML document, how the browser responds to that, and the way that the page-load and rendering processes don't work together well.

In particular, you get this when the script is used to write raw HTML into sections of a page (via, say, document.write () which was one of the first things people did with Javascript to make pages change dynamically). Because browsers render ahead as they grab the document - which was essential in the mid-90's when 28k8 modems were still considered fancy - script that then retroactively changes parts of the page the browser had already made visible naturally means the browser has to undo its guesswork, with these ugly consequences.

Different browsers handle this different ways (early browsers flicker much more, IE7 and FF3 much less because they are very smart about repainting), but the essence of the tradeoff is that if the page is being changed too much then you have to stop the rendering-ahead of things that aren't static to stop this completely - it depends on the page itself and how you approach legacy browsers as to how you go about that, is all. Sometimes just a display:none style is all it takes, for instance, so that the container into which scripted content is put doesn't get visible ahead of time.

GMail, for instance, deals with all this by going through server-side user agent sniffing to determine whether to give rich or dumb content back (and they even have graded levels of dumb content) and in the richest case then basically goes through a landing page that loads all the important script before making anything else visible.

By the way, one of the many good books which my great friend for many years Andrew Paxie - who works in the office across the hall from me - steered me to long with many others over the years is one by Simon Peyton-Jones called The Implementation of Functional Programming Languages.

Prentice-Hall who published so many of the Great Works of computer science (I've certainly got a heap of their white-and-red paperbacks in my stacks) have let the work go out of print but to balance this have let the copyright revert to the author - kudos to them - and although the TeX originals of the manuscript have been lost you can view a high-quality scan of the work online at the link above.

This is deep stuff indeed - although the elements are simple, being able to really see the meaning of the opening 25 pages and the amazing thing that is the Y combinator is an important milestone - and despite the research community having long moved on past this treatise you may note that things like ZF-expressions (list comprehensions based on the theory of set comprehensions) which this book treats as quite a simple thing are the very same as that is being marketed now with so much fanfare as LINQ in C#, over 25 years after their introduction in practical programming languages.

Knowing what you know, I take seriously all your suggestions .. tho I sometimes feel you over-estimate my intelligence. :)

Here are the 1st two sentences from your ref:

http://research.microsoft.com/~simonpj/Papers/slpj-book-1987/PAGES/001.HTM


Quote:

This book is about implementing functional programming languages using lazy graph reduction, and it divides into three parts. The first part describes how to translate a high level functional language into an intermediate language, called the lamda calculus, including detailed coverage of pattern-matching and type-checking".

Q1: Are there (do they exist) such animals as NON-functional prgm'ing languages?
Q2: Why would anybody want to translate a high level language into a lower-level (intermediate) language? Higher is usually better than lower, no?
Q3: "THE lamda calculus"?? .. and not just (regular, ol') "lamda calculus"?
Q4: What patterns?

Maybe if I could sit next to you, and pick your brain .. I could proceed, but reading seems to present more questions than answers .. at least at this stage of my prgm'ing venture.

In learning PHP, I've come across references to 'C' .. and a book that keeps coming up in the "K&R" book:

http://www.amazon.com/C-Programming-Language-2nd-Ed/dp/0131103709/

Have you heard of this?

Seems that many languages evolve from C, no?

on a less esoteric note .. are the terms 'functions' and 'statements' interchangable?

if not, how do they differ?

my book seems to use them interchangably, yet I doubt they are.

Today I read about the importance of good documentation and was pointed to phpDocumentor:

http://www.phpdoc.org/

.. where I tried to glean insight on how to use. Eventually I made my way to a manual that is over 1,300 pages itself:

http://manual.phpdoc.org/

http://manual.phpdoc.org/PDFdefaultConverter/documentation.pdf

I mean, this is even bigger than my PHP/MySQL book, and it's a fatty (>1K pages).

Here's something I'm having trouble understanding .. an example from the book:


Code:

printf("%d bottles of tonic water cost $%f", 100, 43.20);

Isn't it easier to simply write html/text » 100 bottles of tonic water cost $43.20 ??

I'm sure I'll see the light as I continue .. but right now, I fail the see the utility of outputting php strings to screen/browser. Seems easier to do it in html.

First, a quick diversion to the ever-reliable Stevey, and his Portrait of a Noob. Along with an enormous number of user comments. Good read, as always.


Rad.Test wrote on Jun 17^th, 2008 at 6:20pm:

Today I read about the importance of good documentation

Cool. It is important.

The only problem, unfortunately, being nailing down a useful notion of what "good" means, and more importantly to whom it applies.

Now, skill matters - but in relation to commentary in code or other forms of documentation, what really matters so much isn't the skill of the person writing the code, but the person who the commentary is one day going to be read by.

Who is that person? What is he (or she, naturally) looking at this code for anyway?

[ And for that second one, many of the answers lead to an inevitable follow-up: where the hell will I be then? ]

Of all the things you can describe in the code - who, what, when, where, why, and how - what are the ones that matter most to the purposes of that notional future reader?

The skill question comes in because the most contentious aspect of the commentary is how much of it is redundant duplication of things that are easily understandable from the code itself, and how much of it is describing all the things that aren't there in the code.

The other thing is that code is, in many settings, not the only artifact around. The identity of the person who wrote things? That's in the source-control system, right?. When they wrote it? Ditto? And there's why information going into the changelist summary in the source-control system too, yeah?

What if you've got a bug-tracking system in which there are summaries of future intent and plans made. What about a Wiki and forums? Indeed, it's likely that we have all of them, and they all link easily together thanks to the magic of the web.

What then, is the particular importance of the stuff that we write that goes into the code itself, and isn't kept for us elsewhere?

Those questions aren't actually all that easy to answer in the abstract, and often they aren't easy to answer in the particular either. And they especially aren't easy when you consider that writing genuinely readable and informative prose is actually quite a demanding skill in itself, and one that isn't necessarily correlated with those more mathematical skills involved in the wrangling of the code itself.

Everyone wants more documentation. Of course, it takes time (and therefore money, in a business context) to write, and it then also becomes an artifact that has to be maintained just like the code itself so it doesn't become out of date when the code changes.

[ And how rapidly does the code change? If really rapidly, maintaining the docs to match it adds to the same drag effect of sheer size that bedevils development. If really infrequently, then no-one is looking at the comments, so what did we put all that effort into writing them for? ]

Given all that, what do you do?

Me, I in practice I end up write a lot of commentary (relatively little in PHP or other kinds of script, lots and lots for C++). And I write huge honking change descriptions for the change-control system. And I use wikis and issue-trackers and such. And none of that text really describes things that can be determined by something who knows the language reading the code itself ether.

And who is the notional future reader am I writing it for? A future Me, pretty much, who I can therefore rely on to be perfectly capable of reading the code itself, and thus doesn't need a reference manual but does tend to forget all kinds of other stuff. And since I've maintained most of the code I've written for many, many years, I've slowly learned what it is that I do tend to forget and need to re-learn.

In fact, that's a really important source of comments. Maintaining things. When I come to revisit something later on, if there's anything that *isn't* obvious to me later on, when I go to the effort of re-discovering it *that's* something I always put into the code to save myself time if it happens again (as it often does, because the parts of systems that need maintenance at all tend to need it on an ongoing basis).

Rad wrote on Jun 17^th, 2008 at 8:54pm:

Isn't it easier to simply write html/text » 100 bottles of tonic water cost $43.20 ??

Yup. Sure would be.

The example makes more sense if the source of the number of bottles was an entry form, though. And if the price came from a database. And you're writing the PHP for the shopping cart for your store... and so you replace those literal numbers with variables that contain the data you got from those other sources.

Hey, good questions. I linked to that book not as a serious suggestion that you learn Haskell or anything, but more for mathematical interest, by the way.


Rad wrote on Jun 17^th, 2008 at 3:50pm:

Q1: Are there (do they exist) such animals as NON-functional prgm'ing languages?

Yup. Heaps. They vastly outnumber the functional kind, in fact, which are comparatively a small niche.

The common kind are called imperative, because rather than trying to describe things in terms of mathematical equations, you're treating the computer like a mindless robot slave, telling it step by step what to do and in precisely what order.

1. Pick up the trash can.
2. Move to the door.
3. Open the door.
4. Go through the door and out to the curb.
5. Put down the trash can.
6. Go back to the door.
7. Go through the door.
8. Close the door.

That's ultimately what most programming tends to be like, although we're ordering our mindless robot slaves to move strings of text from place to place instead.

wrote on Jun 17^th, 2008 at 9:56pm:

The example makes more sense if the source of the number of bottles was an entry form, though. And if the price came from a database. And you're writing the PHP for the shopping cart for your store... and so you replace those literal numbers with variables that contain the data you got from those other sources.

Okay, I can see that. That's clearly better.

Rad wrote on Jun 17^th, 2008 at 3:50pm:

Q2: Why would anybody want to translate a high level language into a lower-level (intermediate) language? Higher is usually better than lower, no?

For humans, yes. Computers, though, have to ultimately do everything at the level of their CPU instructions.

Getting from point A (high level, human-readable) to point B (CPU instructions encoded as numbers) requires a lot of work.

Of course, that work is mechanical, and so we can get computers to do that, too. So we have programs to translate programs.

...but what do we write those in?

As the old joke goes, if the world is a disc sitting on the back of an elephant, what are the elephants standing on?
The answer is: another elephant. In fact, it's elephants all the way down.

Working with PHP, you're working with a particular kinds of program called an interpreter. Part of that first translates your PHP program into an internal form (compiling it to an internal program) and then another part of it actually does the work of running the program (interpreting that compiled program).

Writing PHP, you're moving down a level to the world of strings and numbers.

But there's another level inside that, which is the PHP interpreter. And another world inside that. And often, there's another world inside that.

[ In fact the CPU instructions aren't what the hardware really runs, either. The CPU itself has a little thing that re-encodes those too, into an even lower level form, designed for the particular arrangement of gates and switches and registers inside it. In the old days those were an interpreter inside the CPU called microcode, these days they are still there but aren't as easy to describe. ]

From go to whoa, there are actually can be an enormous number of these onion-like layers present.

The thing is, interpreters actually aren't all that different to other programs. When we create very general programs, they in turn often become programmable things - steps in a bigger process.

...your old Guide to Norton Ghost is, in many respects, just a high-level program, designed to be run with human beings and other programs as its component pieces instead of strings and numbers...

And while you probably thinking in terms of the PHP programs you write being aimed at the level of humans (which they certainly can be), in fact lots of Web development is actually aimed at web transport of data that are used by other programs (the most common kind of those being Javascript programs that run in the browser, but also plenty of that happens between web servers too).

The distinction between programs that work with human beings and programs that work with other programs and then finally the programs that work on other programs to rewrite them from high-level to low-level forms can ultimately become quite subtle.

Rad wrote on Jun 17^th, 2008 at 3:50pm:

Q3: "THE lambda calculus"?? .. and not just (regular, ol') "lambda calculus"?

It gets to be called "THE" because it's so incredibly important; as I mentioned earlier in the thread (and as the book talks about) even though it was created in the early 20th century as a piece of mathematical logic, it captures so perfectly what computing is that it has taken on an incredibly special status in theory.

Functional programming languages are especially beloved in academic research purposes because being structured as equations, you can prove theorems about such programs in general. The lambda calculus has become the vehicle in which most of that theoretical work has historically been done, and so by defining as direct a possible a transformation into it, new functional languages can easily pick up and have that theory applied to them as well.

And of course, it's practical too. The Lisp and Scheme programming languages are almost direct vehicles for lambda-calculus expressions, and those being so venerable (Lisp c. 1956 being almost as old as electronic computers themselves) have been well studied in terms of how to run them efficiently, so translating to them is a practical shortcut used in "bootstrapping" a brand new functional language in an elegant way.

[ The equivalent status for "bootstrapping" imperative languages is to use translation to C, but there the purpose is almost purely just the practical one of C being ubiquitous, and its ubiquity derives from C having a clear route for translation into CPU instructions. ]

Rad wrote on Jun 17^th, 2008 at 3:50pm:

In learning PHP, I've come across references to 'C' .. and a book that keeps coming up in the "K&R" book: http://www.amazon.com/C-Programming-Language-2nd-Ed/dp/0131103709/ Have you heard of this?

Indeed I have, and in fact I've had the pleasure of meeting Dennis Ritchie in the flesh a couple of decades ago (during one of his visits to New Zealand he dropped in to Auckland University).

C as a language is in many way spectacularly unremarkable. However, in terms of being in the right place at the right time, it's the all-time top dog. The story of how it came to be is part of that - a spare PDP-11 turning up at Bell Labs and Dennis Ritchie and Brian Kernighan being at a loose end and writing a little hobby operating system to occupy themselves.

That PDP-11 didn't have any operating system, so Ritchie started to write one. Mostly in PDP-11 assembly language, which was a pain, so Brian Kernighan started to write a compiler for a higher-level language on it.

Brian Kernighan had earlier looked at a quite simple programming language called BCPL designed in Cambridge - BCPL was very low-level, built on a deliberately simple model of computer memory - and as part of exploring it had written a subset of it (being a subset, called B). The brand new processor for the PDP-11 had a very simple design which turned out to fit the model in BCPL almost perfectly, so to program for that PDP-11 they knocked up a more complete subset of it (having used B, called C).

And each time Dennis Ritchie improved his little OS, more and more of it became written in C, until eventually it all was, and eventually the C compiler itself ended up written in itself too.

And the source code for that little OS - called UNIX - was published, along with the C compiler itself, and got sent to some Universities who also had PDP-11's. And the effect was quite remarkable.

When the microprocessor really started to take hold, the design of those early microprocessors (the 6502 and 6800 and such like) was basically taken from the PDP-11; 8-bit bytes and 16-bit addresses and the ASCII character set were all things associated with the DEC series, and so as the microprocessor started to really take off, C (even more so than UNIX) was a great fit for it.

Rad wrote on Jun 17^th, 2008 at 4:10pm:

are the terms 'functions' and 'statements' interchangable?

That's actually quite a deep one to answer.

The short answer is that in imperative languages, they mostly are interchangable, because functions are mostly just a different kind of statement that happens to compute a value (a value being a number or a string, usually). In imperative languages, the central concept is the statement - the commands you issue, and while functions exist they exist in the context of, and themselves are built out of, statements.

Oddly enough, they are mostly interchangeable in functional languages too, because in those everything is a function, and if you want to do something that doesn't need to return a value by convention there's a special "no value" kind of value called "nil" or "null".

Sometimes books use the term "statement" more narrowly and apply it more to the special built-in constructs like "IF" and "WHILE" and such, because although almost everything is a statement, these things which provide the "control structures" for the language are the most special kinds of statement.

HIGH RADIATION ALERT!

Ok, so having popped over to Stevey's blog to get some linkage for this thread I saw a new article had been posted and settled into a fun read....

cue the Twilight Zone music please...

Stevey writes:

Quote:

when I was in the Navy Nuclear Power School program in Orlando, Florida

OK, now I'm creeped out. That's just too scary a coincidence.

That *is* a coincidence.


Quote:

So we all think we're smart for different reasons. Mine was memorization. Smart, eh? In reality I was just a giant, uncomprehending parrot. I got my first big nasty surprise when I was in the Navy Nuclear Power School program in Orlando, Florida, and I was setting historical records for the highest scores on their exams. The courses and exams had been carefully designed over some 30 years to maximize and then test "literal retention" of the material. They gave you all the material in outline form, and made you write it in your notebook, and your test answers were graded on edit-distance from the original notes. (I'm not making this up or exaggerating in the slightest.) They had set up the ultimate parrot game, and I happily accepted. I memorized the entire notebooks word-for-word, and aced their tests.

i recall rejurgitating 'keywords and tricky phrases'. orlando is where i went, too.

Can't help but wonder what class he was in. I was in 7709 .. (began Sept 1977).

I never recall hearing anyone being compared to previous classes. For all I know that data was not available.

Regarding this script (it *is* called a 'script,' right?):


Code:

printf("%d bottles of tonic water cost $%f", 100, 43.20);

I'm kinda wondering WHY the $%f is NOT a variable (since variables begin with $...).

Rad wrote on Jun 19^th, 2008 at 6:55pm:

I'm kinda wondering WHY the $%f is NOT a variable (since variables begin with $...).

Another good question.

This is due to a subtle thing that is present in computer and natural languages, where the meaning of a thing - such as in this case the '$' - isn't determined just by itself, but also by its surrounding context. Sometimes that context is close by, sometimes it's far away. Sometimes it's on the left of the thing you're looking at, sometimes on the right, sometimes both.

[ Being very technical for a moment, this context sensitivity is important; it's degrees of context sensitivity that are underpin the hierarchy of mathematical power that divides what regular expressions can do from the more powerful grammars. ]

So for instance, the meaning of a $ within a double-quote isn't necessarily the same as the meaning outside one. The rules that apply within the double-quote about the meaning of such strings are not the same as - indeed, conflict with a small degree with - to the ones for the meaning of $ outside.

In particular, the PHP system has to decide for every character in the double-quoted string whether it means "itself", which is the primary meaning of things in strings, or "escapes out" of that context to draw in something from another part of the language, such as to to substitute a variable value (which PHP calls interpolation, a term not used elsewhere for this).

The other thing is that although there is a way to say explicitly in double-quoted strings that the '$' is just a '$' by using '\$', PHP as a scripting-type language tends to a philosophy that rather than generating an error, it tries to do its best.

So, when encountering the $ in the left context of a double-quoted string, the PHP interpreter doesn't immediately decide what it is, but starts drawing in the right context of what follows the string to see whether it can make sense of that as the name of a variable to substitute in.

If it can't make sense of it - because the simple syntax - doesn't match, which in your example it doesn't because the next character after the $ is %, which isn't a valid variable name - then it has a choice.

Although PHP could legitimately choose to raise an error because the expression makes no sense, the implementation could instead choose to simply guess that you meant to use \$ but forgot.

Languages, particularly imperative languages, are full of these kind of policy choices, because they are not designed with any reference to mathematical principles but grown by use. And just as with human languages, the process of growth by use leads to ambiguity and puns, and the language interpreter having to apply what could be called disambiguation heuristics to try and guess a meaning for things that are not actually well-defined.

These things are concessions to usability, by trying to let humans get on with "do what I mean you silly machine" instead of the compiler being seen as picky, but they complicate the implementation of the language itself immensely, and they tend to be the kinds of things that are the most susceptible to breaking horrible as the language evolves, because a later extension to the language may ascribe a meaning to something formally underfined before, or a rewrite of the code may accidentally not preserve a bug which disambiguated things one way and not another.

while i read your last, another question: i keep seeing references to to 'decimal' integer..

.. oh, nevermind. i see decimal is simply base-10 integer. i follow. i would've chosen another term than decimal .. which conjures up ideas of floats (decimal points mean you no longer have an integer).

wrote on Jun 19^th, 2008 at 7:36pm:

degrees of context sensitivity that are underpin the hierarchy of mathematical power that divides what regular expressions can do from the more powerful grammars

I thot regular expressions *were* powerful .. re the title of this thread.

Okay, now that you got me curious, what are "the more powerful grammars"??

Rad wrote on Jun 19^th, 2008 at 6:55pm:

Regarding this script (it *is* called a 'script,' right?):

PHP programs generally are, yes, just as UNIX shell scripts and Perl script and Javascript.

That said, though, the distinction between what's script and isn't is really pretty fuzzy and there is no formal definition of what is and isn't.

Things that are "load-and-go", where the language system works by sucking in the source code and then immediately doing what the source code says are the things that are most usually called "scripts". If the source code is pretreated by a separate toolchain first so that the original source code isn't what's used at the time things go, that's usually not called script.

Really though, that distinction isn't all that firm. There are systems which don't work as above, and other properties (such as whether the language possesses a static type system or a dynamic type system) that tend to split down a similar line but which don't capture the essence either.

At the end of the day, whether something is a script or not is as much about how we think about the program rather than being an intrinsic property of the language (or the implementation of the language). Things that work is a "script-y" way tend to have a lot of features in common (load-and-go, dynamic type system) as a result but that's a consequence, not a cause, of what it is that people tend to do with them.

wrote on Jun 19^th, 2008 at 7:36pm:

So for instance, the meaning of a $ within a double-quote isn't necessarily the same as the meaning outside one. The rules that apply within the double-quote about the meaning of such strings are not the same as - indeed, conflict with a small degree with - to the ones for the meaning of $ outside.

Note that examples *have* been given where $variables are located INSIDE the dbl-quotes. (in a print statement). So .. it's not defined obviously solely by being inside/outside "".

Rad wrote on Jun 19^th, 2008 at 7:58pm:

i would've chosen another term than decimal

The more you work in non-decimal number systems (binary, octal, hexadecimal) the more you get used to explicitly calling out the cases of decimal numbering.

[ This relates of course, to cultural conventions of currency and weights and measures too. "Decimal currency" is a reasonably common term in the British Commonwealth because the conversion from the non-decimal Imperial system to a base-10 one is still mostly within living memory. ]

Rad wrote on Jun 19^th, 2008 at 8:02pm:

I thot regular expressions *were* powerful .. re the title of this thread. Okay, now that you got me curious, what are "the more powerful grammars"??

Well, as I mentioned earlier it turns out that most attempts to describe languages through grammars, the grammars themselves turn out to fit into the class of things which are equivalent to the lambda calculus (aka "turing-equivalent"), and which therefore are fully capable of acting as computer languages themselves.

Regular expressions, as formally described, don't fall into that class. In between regular expressions and turning-equivalent are some other finely-graded categories of things; mapping out these is of interest to Automata Theory, and context is a crucial thing that distinguishes the classes.

wrote on Jun 17^th, 2008 at 11:36pm:

And the source code for that little OS - called UNIX - was published, along with the C compiler itself

This guy invented *both* C and Unix?

Rad wrote on Jun 19^th, 2008 at 8:37pm:

This guy invented *both* C and Unix?

They co-evolved together, almost inseparably, and really only the main principals know precisely who did what. From outside, Dennis Ritchie, Brian Kernighan, and Ken Thompson may as well have been a single hive mind.

Great quote from Ken Thompson, snagged from this page with more background.

Quote:

That brings me to Dennis Ritchie. Our collaboration has been a thing of beauty. In the ten years that we have worked together, I can recall only one case of miscoordination of work. On that occasion, I discovered that we both had written the same 20-line assembly language program. I compared the sources and was astounded to find that they matched character-for-character. The result of our work together has been far greater than the work that we each contributed.

Rad wrote on Jun 19^th, 2008 at 8:11pm:

So .. it's not defined obviously solely by being inside/outside

Sure, but internally to the PHP system a $ outside a string and a $ inside one have to be treated by different code; the situations deliberately look similar so that there are less things to learn, but the language has to work quite hard to maintain that illusion.

Internally to the language, what it does in order to make this magic happen can have odd consequences. This makes it hard to intuitively know what the fastest of all the dozens of equivalent ways of doing the same thing are, but because almost everything does work it's much easier to write something and have it be useful.