LtU Forum

Abstractions considered harmful?

Posit that OO was a reaction to GUI development where control flow and state in procedural code had gotten out of hand, so it was segregated for manageable design. Then, doesn't abstraction fail us when it comes time to debug? I'll want to see the control flow in a linear fashion, not follow the program counter go flying through umpteen different files, mentally trying to piece everything back together again. If abstraction has thusly harmed us, are there other abstractions that throw the debugging baby out with the design bath water?

Note: Ah, sorry to see this is perhaps belabouring the point (although I hope it is a slightly different facet of abstractions).

News: The wiki has started. Please contribute.

What is Intuitive?

[$0.02 in the category of 'perhaps we can get past the silly holy wars and into interesting ones'] I've seen it come up a few times in discussions: the claim that something is more intuitive than something else. I have a passing interest in usability, UI, and visualization, so the term 'intuitive' is something I come across a lot. I think Jef Raskin had it right: it is not an absolute, it heavily depends on individual experience.

Thus, this is a request for folks to avoid getting sucked into the 'is too' 'is not'. You have to say 'to whom' and 'when' and 'under what circumstances'. For PL evangelists, I think this is good to keep in mind.

Logix: Multi-Language Programming

I just came across Logix, which appears to be a language for building (and freely intermixing) DSLs. It is similar to Lisp in many ways (a point the website makes several times), but with a substantially different syntax, and an approach based more on objects than lists. From the website:

Logix is more than a programming language. It is multi-language programming system. With Logix, each part of your program can be developed in a language that is finely tuned to the task.


Featuring a procedural macro facility, dynamic syntax extension, and multi-language parsing. A new operator, complete with syntax and semantics, can be added on-the-fly with a single line of code.
The "60 second intro" provides a couple of brief examples of the way syntax enxtension works. There is also a more extensive tutorial that discusses the base Logix language (which is somewhat like Python), as well as providing more detail on how to extend the language.

Logix as presently implemented generates Python byte-code, but the designers are investigating other platforms (Mono, Parrot, LLVM).

mondo bizarro

c-jump looks harmful to children. Time for a Scheme board game? I think I've found a good name for it.

Ruby: Language of the Programming Ãœbermensch?

I spent a couple of hours this evening writing my first real Ruby code for the Lexical Semantics course I am taking this fall. It's excellent. The syntax is very appealing. Tokens are strangely verbose, replacing "{" and "}" of C descent with "def" or (insert block starting token here) and "end". For the first 30 seconds after encountering this on page 1, I wasn't sure how I felt about it. It seemed verbose. But now I see that "end" is much easier to type than "}", whose presence in Java forces me to reach and twist for basic program vocabulary. Maybe it would be different if I weren't on Dvorak, but words as delimiters rather than punctuation is a definite win. And while the tokens are fat—in a good way—they are also few. The syntax is remarkably terse, but not at the peril of clarity as I feel is the case with Perl. Ruby makes me understand the power of judicious syntactic support for common tasks. String interpolation is an obvious and immediately addictive feature. Built-in regular expression literals are also a plus. And there is an elegant interplay between these syntactic features on both a functional and visual level. As syntax is concerned, Scheme has represented a year-long exile in the wilderness. The bare minimalism of S-expressions was good for me. Scheme's uniform and parsimonious syntax let me focus on concepts that are fundamental to high-level programming: recursion, higher order procedures, and data abstraction. Scheme taught me by giving me only a handful of powerful tools and then training me to use them well. Now I think that Ruby can empower me by equipping that sharpened outlook with richer facilities for the completion of common tasks. Its assumptions are friendly to my most cherished and hard-won programming intuition, but they also cater to the harsh realities of programming in an imperative world.

Paul Graham says that languages are evolving ever-closer to Lisp, and he asks, why not skip directly to it? And I think that I finally have an answer. Perhaps the ideal programming experience is purely functional, and the mainstream's gradual adoption of features pioneered by functional languages reflects this truth. But there are other truths. Tim O'Reilly presents another point. He says that as new computing paradigms emerge, new languages seem to rise with them, suggesting that from a pragmatic standpoint, a language's "goodness" is sensitively dependent on the world in which it is used and with which it must interact. Every time I have programmed functionally for practical applications, I am keenly aware of how imperative the world outside my program really is. The operating system doesn't behave functionally, and I/O operations certainly never could. There has to be a reason why these languages are so popular, beyond the simple fact that they are easier to learn for programmers whose first language was C. My conclusion is this. In the real world of computing, one finds explicit notions of state; one finds assignment. The computing hyperscape is not (yet, perhaps) very functional. State-oriented computational objects seem a natural complement to our false intuition of objects existing in the real world as well. Nietzsche would say that there are no objects, and, indeed, there aren't even any facts. There is only "will to power". Sounds remarkably similar to me trying to explain to C programmers that there is no data, and there isn't, in fact, any need for assignment. There is only Lambda. I think Nietzsche is right and I think Steele and Sussman were right, but that truth does not mean that the illusion of objects is an utterly worthless one. If we actually cognized the outside world as consisting only of "will to power" rather than tables and chairs and people, we'd never get anything done. And perhaps, similarly, when we pretend that everything is a Lambda, we face similar difficulties in interfacing this remarkably beautiful, completely true notion with an ability to do anything about it.

These ideas, are, I guess, nothing new. Haskell's monad system, from the cursory understanding I have of it, is a formalization of them, a clean interface between the rough and tumble outside universe and the sublime purity of Haskellspace. But if I'm not going to use an airlock, maybe a clever, elegant, and even artistic bridge between functional wisdom and imperative truth will suffice. For now, Ruby seems to be a pretty decent attempt. Lambda may be vulgarized into a quirky codeblock, but in a language in which shell commands are syntactically supported, at least it exists.

Categories for Software Engineering - recommend?

Have any of our mathematically inclined readers browsed Categories for Software Engineering and would they recommend it to a not-so-theoretical software developer?

Table Oriented Programming

I have written an article on in which i was able to write a domain specific language using SQL when the database is modelled using "Table Oriented Programming" techniques.You can find the article here.One notable advantage of this technique is that we do not have to write seperate parser/grammar to get a DSL,we just use TOP and SQL syntax.

I am not a TOP fanatic(ala TopMind), but have found the technique pretty useful at work which prompted me to write this article. Also note that this article was intended to be published in a magazine for general developers, so the terminology is a little loose.

However Corrections, flames and opinions are always welcome.

Live update of source with inferred type?

(A pie-in-the-sky wish.) Personally, I love automatic type inference and generics a la ML, Haskell etc. I wish such systems would go one step further and offer an optional means of annotating the code I'm writing after the type inference happens; that way when reading code for the first time one would get the benefit of knowing what things are when they are first introduced, without having to divine it from how they are then used. I do not know of anything that does this, but would love to hear if there is such a system (or if there are evil Emacs hack ideas along such lines).

Dynamic vs. Static Typing - A Pattern-Based Analysis

In some cases, static typing is more error-prone than dynamic typing. Some statically typed languages force you to manually emulate dynamic typing in order to do "The Right Thing".

The writer takes on Java. He mentions three problems:

  • Statically Checked Implementation of Interfaces
  • Statically Checked Exceptions
  • Checking Feature Availability

SeaFunc meets Tues. Sept. 27th

SeaFunc is Seattle. SeaFunc is functional. Functional language.
Functional PRO-gramming. We shall attempt to adjust your software, as
there is something wrong. You're in a C funk. Get out of your C funk.
Stumble on down to the best Belgian booze around.

The Mothership lands at 8 pm on Tuesday, Sep. 27th at:

Ruby Restaurant
4241 University Way NE
Seattle, WA 98105 - 5806
(206) 675-1770

Ruby's is in the U. District on "The Ave," near 43rd St. Good,
non-pricey food, and normal beer.

To receive timely meeting announcements by e-mail, including where we
will be meeting, subscribe to the mailing list at
http://groups.yahoo.com/groups/SeaFunc

For the uninitiated: "Functional Programming" (FP) treats computation
as the symbolic substitution of functions. Solving problems by making
changes to program state is often avoided. Common Lisp, Scheme,
Standard ML, OCaml, Haskell, and Clean are examples of FP languages.

The merits of the FP approach are highly debateable. Much more clear,
is that people who debate these issues are interesting (to other such
people :-) and provide useful networking contacts. SeaFunc aims to be
the premiere group in the Seattle region for advanced programming
language paradgims. If you think there must be more to life than C++,
Java, and C#, please join us!

"Make my func the SeaFunc, I wants to get funked up." - Parliament

XML feed