Functional Programming in JavaScript

In distant homage to my father, who for a short while in the early 1960's went to night school after work and before coming home to his wife and three or (if my youngest brother had arrived) four kids, I have sought to improve myself professionally. But Haskell may be too distant. On page 165 of a book eerily titled Real World Haskell I read that this language "strictly separates pure code from code that could cause things to occur in the world." If I heard about a cult that murdered virgins in order to save them, my first thought would be: Haskell programmers.

But still...I feel I need to inquire. I do not feel that I or anyone needs to be, as this site nicely phrases it, "a determined programmer" - after all, the machinery is supposed to work for us, not the other way around - but just because the machinery's commands are hard to master is no reason to scorn them. That would be as churlish as, oh, refusing to go to Turkey because Turkish grammar is hard to master. Living in a college town is no excuse.

So, here's a little JavaScript program, written two ways. Both do the same thing, itself pointedly lacking in drama: if you're in a helicopter trying to land, and there's another helicopter trying to land in the same place at about the same time, you want no drama, am I right? The program is modest but I feel it is far more than you will get from most websites. As is the case elsewhere on this site, you can always view the source code. It is amply commented. Right here, let me just say what the thing does: "helicopters" (I was going to pick "airplanes" but hovering is easier to program than a holding pattern!) approach a port from the west and north; when they are fairly close, an assessment is made of their arrival times; if these are considered too near, one helicopter is caused to hang motionless (and turn light-blue). When at last it is permitted to land and does, another issues from its rear horizon, with a speed randomly assigned, but constant as long as it's moving. The speed is set to zero only when it is compelled to hover.

The "FP" version's differences are (with one exception) under the hood and can be summarized thus:

• Global variables are few in number, declared upfront, and (this is the only thing that keeps them out of hell) never change.
• Local variables are assigned within a function just once.
• There are no loops. Such would involve a variable varying, either one inside the loop, or the loop's counter if it had one: either way, can't have that! I haven't seen it admitted anywhere, but it appears in Haskell that something like "x=12" means not that x names a place in memory currently occupied by 12 but later to be occupied by something else, but rather that x is a function that takes no arguments and always returns 12. Well, that's...reliable, I guess.
• When a function returns something, it depends ONLY on what it received and on those lumpy inert globals.

Bizarre, no? One is forced to be resourceful...gotta give it that much.

But this all does make me want to revive an idea I had and abandoned some time ago: create a programming language modeled on Turkish. Each command would be like a sentence, subject-verb-object, where the (grammatical) subject would be some (computer-science) "object," the (grammatical) verb would be some subroutine it fed into, and the (grammatical) object would be some other (computer-science) "object" that sustained some useful change as a result of this. The "Turkish" thing about it would be that the (grammatical) subject and object, being nouns, could be modified by adjectives which, if they were Turkish participles, could themselves be built in the subject-verb-object way. For example, to sort through a database of medical care-seekers, to collect only those who lived in a certain influential Congressman's district, the program's "main" function could be database elements-are flipped through and and routed into-output, with the "noun" database elements modified by the "adjective" whose Congressman is so-and-so or who live in such-and-such Congressional district. Obviously English works the same way, but the structure shows up better in Turkish. Figuring out a Turkish sentence (if you weren't born to the language), unlike intuiting a Turkish sentence (if you were so born) is a recursive process: find a noun, find the noun-that-owns/participle-that-is-owned phrase that modifies it, for that noun find the noun-that-owns/participle-that-is-owned phrase that modifies it, and so on. Computers were built to handle precisely this.

Are these ideas farfetched? Yes. Are these ideas more farfetched than Haskell? I don't think so.