Archive for the ‘Programming Languages’ Category

R6+RS

Tuesday, September 15th, 2009

I have been following the R6RS and the R7RS discussion processes since shortly after the beginning of the former. It is educational, if nothing else, and I do enjoy watching the debates, though I have seldom posted to the group. As with virtually all engineering, most decisions are less matters of things that are strictly correct or strictly incorrect (read: wrong) than they are a discussion of tradeoffs. I have little doubt that there would be a lot less heat in these debates if more issues where strictly right or strictly wrong. It would then become less a question of design and more a question of solving the problem in the straight-out method used to solve problems in mathematics. All of those posting are extremely intelligent. This is not surprising. Given the state of the industry, few blub programmers ever make it so far as to hear about Scheme, let alone care about the next standard issued under that name. Most of these people have PhDs and are doing this as part of their research.

So, I would summarize the R6+RS mailing list as being a lot of smart people arguing heatedly over design tradeoffs. At least, it keeps things from being boring. I find it interesting how dedicated these people are to sitting down and proving to the whole group that their way is obviously the best way. It may very well be, but if the majority of those standardizing Scheme do not want it, why worry? Why not take the R 4, 5, or 6 RS and draft your own spec, publishing it under your own name? Just take it and create another Lisp dialect. Show us all that it is better than Scheme or Common Lisp. It is almost like the languages world has decided that we shall have precisely two Lisps: Scheme and Common Lisp. Most of the Lisp-esque languages out there are starting from Scheme or Common Lisp and making some minimum number of tweaks (often, like Clojure, to make it run on some other platform) rather than designing a new language from the ground up. It seems to me that there is plenty of room for interesting experimentation. In fact, it seems to me that the standardization process would be a lot more fruitful if we could see a lot more Lisps out in the wild. We could take the good and avoid the bad and have a real, living model to look at instead of some airy discussions.

What Web Programming Gets Right

Tuesday, September 8th, 2009

There are a lot of things in the wonderful and wacky world of web programming that are simply wrong, browser specific hacks being the biggest by far. One thing it gets right compared to the majority of the desktop programming world is that setting up a GUI is declarative. Most .NET, Java, and C++ GUI libraries are procedural when it comes to setting up a UI. True, they usually use OOP techniques, but setting up a UI is a long string of statements that say, in effect, “create this widget, with properties X, Y, Z, A, C, and D and put it here”. There are some things in place to try and take the pain out, but this is what is happening. For example, if you look at the code that the .NET form editor creates, you find stuff just like this. Don’t even get me started on Java’s Swing framework. WPF is a move towards a declarative way to do GUIs as is Glade, but these make up a comparably small amount of GUI code in the wild. For the most part, GUIs are still done in a highly procedural way. Programmers who come solely from a Java/C++/C# background (hereafter, referred to as the “Java way”) accept this as more or less the way things must be done. This is because the Java way is only pseudo OOP in the first place and the meat of the work is done procedurally. The heavy lifting does not happen, ala Smalltalk, through signals propagating through a web of classes, but through a series of instructions in a method.

However, the functional tradition (which includes languages that are less hard core than Haskell) does not view the world this way. Instead, in functional languages you seek, as much as possible, to be declarative in your code. This brings me to the greatest irony of all: despite having the best facilities to represent user interfaces, functional languages have few libraries for GUI work and are seldom used for this purpose.

HTML has the right idea, and should show the way. <button type=”button” onclick=”foo();”> is exactly how all GUIs should work. Hopefully, in the future, we will see more tools that declare GUIs instead of construct them.

ISO and ANSI are Irritating Me…

Monday, August 31st, 2009

Lately, as I have been swinging around various technologies I have been increasingly finding myself directed to various standards issued by the ISO. The latest ones (with reasons raging from curiosity to serious research) include ISO 8879, published in 1986 and specifying SGML the ancestor of HTML and XML, and ANSI/INCITS 319-1998 which specifies SmallTalk (this one I managed to find on the web in the form of its last draft). Now, maybe I am getting spoiled by the IETF, ECMA, and W3C, which release both their drafts and their final standards for free, but I find the prices that the ISO and ANSI charging are ridiculous.

In fact, I would argue that if you have to pay for a digital copy of the standard, then the whole point of standardization has been bypassed. Standardization allows anyone to pick up a copy of the standard and implement what it says with the expectation that it should work with other implementations (hey, that’s the theory; practice varies). Charging for paper copies is, of course, understandable and fair since it costs to put those together. When you charge for access to a standard, and especially when you charge a lot, it dramatically reduces the number of people able to attempt to implement it (slowing down the spread of standards-compliant versions of the technology). It also reduces the industry’s ability to check behavior and see if it matches the specification. Let us say, for example, that the World Wide Web Consortium charged ballpark $1,000 to have a copy of the XML 1.0 specification. I am using some XML parsing library and it does not behave as I expect. If the cost for the spec is $1,000, I cannot afford it. There are many companies who will refuse to afford it. After all, how valuable can that specification be? How can I check whether I am correct or if the parser is correct? I can’t.

Moreover, many of the people chairing these boards are professors or researchers in whatever technology they are working on. So their salaries are basically paid by someone else anyway. The rest of the costs of running the organization should be minimal. Both of these organizations are non-profits, ANSI being a private non-profit and the ISO being an NGO, so why charge for the standards? They are not supposed to be making a profit anyway (I, personally, think that non-profits and our entire tax structure are insane, but that is, again, another blog post), so why not disseminate the standards more widely?

This probably sounds like me deviating from my capitalist roots. It is not, really. That would be the case if I wanted some sort of governmental agency to handle standardizations (blasphemy!) or some sort of regulation enforcing the behavior I described above–but I believe nothing of the sort. The ANSI and ISO have every right in the world to try and make an industry out of technology standards, but I, as a consumer, have the right to try to refuse them. It all comes down to supply and demand and, I think, over the long haul the trend will go very much against the ISO and ANSI. I am sure some larger corporations are only too glad to whip out their wallets and pay up for these documents, but these are in the minority.

Over time, I am certain that ISO and ANSI will be forced to shift towards the policies of the IETF, ECMA, and W3C. For example, when Microsoft decided to publish a standard for C# and the .NET framework, they did not go to ISO and ANSI. Instead, they went to the ECMA. Most likely, this was done for reasons of time and expense, but this too is what differentiates the smaller organizations from the ISO and ANSI. The demand will continue to move in this direction, for more efficient standardization, cheaper standardization, and wider availability of said standards. Ultimately, all standards organizations have two bodies of clients: the standardizers and those who would read the standards. If no one publish specs through your organization, the rest does not matter. Similarly, if you publish specs that no one reads you will be irrelevant. It is ultimately in the best interests of both parties to have things quick, easy, and cheap. Let us say that Microsoft did not want their spec to be widely available. Why would they get it published at all? It would be easier to just use it for you dev teams and never let it see the light of day. With the advent of the world wide web, no one needs a standardization comittee to make their work widely available. A few minutes and a few dollars and it is up for the world to see. Largely, what these committees offer is prestige, but inaccessible prestige fails to serve either clientele.

Philosophical Language

Sunday, August 2nd, 2009

I began reading In the Land of Invented Languages today after hearing about it on Lambda the Ultimate. Currently, I am reading about John Wilkinson’s failed attempt (one of, apparently, many) to build a philosophical language. Like several readers at LtU, my mind turned to its application to programming. Like the noble readers of that blog, I feel that the correlation between constructed languages (from Elvish and Klingon to Esperanto) and programming languages is a strong one. The irony is that the latter has gained more traction than the former. Many constructed languages, like Wilkinson’s, are based around the idea that ambiguity should be removed from language. In programming, it is not a matter of taste. Ambiguity must and, eventually, is removed. In complex languages like C++ (which, I assert, is complex in entirely the wrong way but that is a post for another time), it may be unclear from a spec how a feature should be implemented, but the implementors ultimately make some decision. So, we have dialects: Visual C++, GNU C++, Borland C++, etc ad nauseum. In human language, however, ambiguity is not neutral. It is actually a positive. Literature and poetry revel in the ambiguity of language, in puns and rhymes and all those stupid idiosyncrasies. John Wilkinson would probably have made one heck of a programmer.

Arika Okrent, the author of In the Land of Invented Languages points out that Wilkinson’s language was a great linguistic study and completely unusable as a spoken tongue. She is right. A language that is unfit for human speech is not necessarily worthless. As evidence, look at the myriad of computer languages available. These are all useful (well, almost all), but you would never catch me speaking to a person in C#, Java, PHP, Lisp, or what have you. The philosophical language is the kind of thing that computers love. Lacking in ambiguity, with new concepts as simple as placing a stub in a massive dictionary. The understanding comes almost for free. A great deal of effort has gone into trying to get machines to understand human language. At the current stage of development this is a lost cause. Hopefully it will not always be, but right now our combination of machine and algorithm cannot untangle the ambiguities of human speech. The example one of my computer science professors used was how a machine would figure out the meaning of the phrase “fruit flies like a banana”. Is it that flies, fruit flies in particular, enjoy bananas? Or that fruits fly through the air as a banana would?

The philosophical programming language might be the next step. True, it might be a little harder than picking up BASIC or PHP, but it would be a great deal more expressive. I know. This also sounds like it is approaching the heresy of building a DSL and expecting random business personnel to do their own programming. That’s not really what I have in mind. The programming would still have to be done by programmers–but more of a dictation and less of a description. As I looked at the excerpts from Wilkinson’s tables it reminded me strangely of Prolog predicate evaluation. It would be easy to represent his whole vocabulary as a sequence of facts in the opening of a Prolog program. With a nonambiguous grammar, the whole thing could be parsed, understood, and executed.

To the best of my knowledge, this has never been tried. I would love to see a first shot at it, wrinkles and all. Give me a shout if you know of or are working on something like this.