Continuing the translation of "articles" to modern blog entries... Article 34 from March 16, 2004.

---

Strike one against blogger.

I haven't been using it for a week and already I have problems. I can no longer publish blog entries to my web site.

I'm not sure of the cause yet, so I'm going to do some research and give them a few days to work out the kinks.

But, regardless, this is pretty stale for week one.

Labels: Gripes, Webworks

Most of my concerns last time were about syntax, which might strike you
as superficial. So before I get any further into syntax, let me recognize
the importance of a clean underlying language model.

There's a lot of value to a pure language model. A clear low-level imperative
model enables languages like C and FORTRAN to be translated into efficient
machine code, making them good system and scientific computation languages,
respectively. A clear object model enables packaging vast quantities of code
into rich libraries for reuse, making Smalltalk and Java good languages for
experimentation and rapid development, respectively. Pure functional
orientation makes correctness proofs and parallel transforms easy,making
Haskell and Objective Caml darlings of the language design movement.
And pure logical design makes it easy to specify what you want to do,
rather than how, and that makes languages like Prolog and Mercury
popular in certain artificial intelligence circles.

But, in my mind, pragmatics ultimately trumps all. There's a reason
C++ was built on top of C, a reason Java has bare-metal types,
a reason Lisp has (progn) and (loop), a reason Prolog has cut.
Programmers have to be able to use the language to solve useful
problems, or the language is a toy.

Now, this isn't intended to denigrate language designers who have
taken one element of the paradigm to the max while at the same
time focusing on pragmatic concerns like execution efficiency,
expressiveness, and ease of use. But, to be frank, most language
designers who do leap onto the fundamentalist imperative / functional
/ logic / object-oriented bandwagon don't even bother to address
such concerns --- because they are fundamentally incompatible
with the programmatic consequences of the delusions and lies that
their religious views force them to adopt.

Which brings us back to syntax. Time and time again, I've heard
language designers say "I don't like such-and-so features, so I'm not
going to put them into my language." Balderdash. That's not a valid
reason to do something in a programming language that
other programmers are supposed to use; it's just childish
foolishness. Oh, you don't wan't multi-line comments, nested comments,
or function types in your language? Too bad. Grow the fuck up.

What's a good reason to do something in a language? It's about the
consequences. Multiple inheritance was omitted from Java because
it caused problems in the semantics and construction of C++ which
made it difficult for programmers to construct correct programs. Similarly,
at the syntactic level Java uses a separate assignment and equality
symbol and removes the equivalence of integers and booleans
to prevent a class of common programmer errors.

On the flip side, having expressive syntactic notations like the slice syntax,
list comprehensions and hash table constructors makes it possible for
programmers to write programs that accomplish a great deal concisely.
Lisp, my favorite language, makes it hard to write concise programs
because of its over-reliance on parentheses as its single list / grouping
/ code block / function definition / macro / what have you construct.
I understand completely why ultimately a real Lisp dialect has to be
reducible to something like an s-expression comprising functions and
data. But programmers should not have to write
all of those s-expressions if there's a more concise way to represent
it, nor should they have to rely on squinting at flashing parens and
reformatting indentation in their syntax-aware graphical editor just
to know whether or not they've written the right number of enclosing
parens on whatever godawful cond-lambda-reduce-map construct
they had to construct to get their job done.

So my plan moving forward: collect examples of syntax I like, and
show how they might reduce to s-expressions in a variant of Lisp.
Ultimately I want to push this back to collecting examples of semantic
features I like, and derive a clean model that would be both expressive,
interpretable, compilable and efficient.

Labels: Development

I've been doing a lot of thought about language design recently. I just switched from a couple of years of Visual Basic hackery back to the more familiar territory of Java, and while most of my time has been spent reacquainting myself with the landmarks of my college town and checking out the features of the new mall, I've also had a chance to check out some of the neighboring countryside. The up-and-coming development called C# is growing nicely, and while I was wandering the old town suburbs of Bash scripting and Perl I ran into the charming subdivisions of Python and Ruby, also with many features.

But while I was born programming FORTRAN and shortly thereafter moved to BASIC, my hometown language will always be LISP. And while I like many of the features I find in modern languages, I find myself still hankering after LISP's elegant s-expressions and the ability to compose arbitrary data structures with them.

I suppose that's the same nostalgia a C programmer gets for the ability to create arcane constructs like a dereferenced an array of pointers to functions. And I wouldn't want to give up my cherished Java packages, objects and methods (or C#'s namespaces, objects and methods, or VB's references, objects, and methods) in favor of (load "myfile") just to get s-expressions. But I suspect that C programmers are far happeir with the tradeoffs they have moving to C++ than I am with moving from Java to Lisp.

The C programmer loses some speed and freedom in C++, but keeps all of his old operators while gaining classes, inheritance, and the Standard Template Library. I, on the other hand, gain classes, inheritance, platform independence, and a vast library --- but Java's collection classes are a poor substitute for s-expressions and Lisp's list operators.

This isn't the only thing that you lose. Java and Visual Basic both have good regular expression libraries, but they're a pain in the butt to work with compared to the elegant integration you find in Perl, Python or Ruby. And there are many other language technologies that have arisen in recent years --- the slice notation for sequences from Icon which is now found in Python and Ruby, the interned immutable strings of Java and Python, list comprehensions in Python, hashes from Perl and Python, packages and namespaces from Java and C# --- that haven't yet migrated to as many other languages as they should.

I know different languages have different purposes. A shell script is not a scripting language, and a RAD tool is not for programming provably correct programs. But, damn it, programmers should be able to USE these language technologies, no matter what language they come from! Why can't I say something like "foreach i in [0..9] do println myArray[1:i].toString();" in just about any language to print a triangle of array values, rather than the torturous process I have to go through to do this in most normal languages?

So, I've decided to do something about it. I'm going to design my dream language on paper, and then all you language zealots can tell me why your particular language trumps it. I'm going to start to collect my favorite language features in my blog, and start to collect comments about what features work with each other. I don't want to create a kitchen sink of a language like PL/I that no-one would use; I want to collect a list of safe language features, syntactic constructs, and useful operators that anyone ought to be able to include in their language, and then start discussing how we can begin to use these more effectively in future language design.
To start with, here are a few language features I've come across that I think are cool --- or, more pointedly, that I think should be a natural part of any language other than low-level system workhorses and toy language-theory workbenches:

Regular Expressions.
Awk, Perl and Python programmers take these for granted. Programmers in other languages should be able to as well. Visual Basic and Java expose regular expression frameworks which you can access in a clunky way using object-oriented notation, but there's something to be said for syntactic support at the level of the =~ operator. Other languages, like C and Lisp, simply leave you twisting in the wind trying to roll your own. No more, I say to you future language designers: go thee emulate "$scalar =~ /bladeblah/", or improve upon it. Enough said.

Slice Notation.
For the longest time, I never thought of using arrays any other way than the usual: "declare myArray[size]; pass myArray = arrayOund; get myArray[element];". Then I saw Python's slice notation myArray[3:5] and saw the light. Why shouldn't I be able to refer to the subelements of an array by something as simple as [3:5]? Or everything to the end of the array as [5:]? And do the same for strings as in "This that the other"[3:5] when the language supports viewing strings this way? I guess my point is that you as a language designer may not want that special syntax because it wrecks the purity of your object oriented syntax model, tweaks your function calling notation, doesn't fit with your ideas of programs as data, or simply because you, Larry, want the colon. In the end, people have to use the damn language to do things. While a simple, clean syntax makes rare things possible, it can make easy things hard. Get over it and add slices to your language.

Coexistence of Object-Oriented and "Bare Metal" Types
I know from experience you can use Java in both a pure object-oriented, LISP-like high-level way and a low-level, C-emulation mode, with a consequent tradeoff of programming flexibility for speed and power. I think part of Java's success is its vast library of objects, which in turn can use bare ints, booleans and floats to do the meat of the programming. I think C# will become even more successful for a similar reason, because it provides even more opportunity to manipulate the metal while letting you fly off into high-level object land if you need to.

How Does It All Fit Together?
It doesn't yet. If I was to throw all the items in my list into some bastardized example I'd get something like:

        println "The first ten characters of the method name are: "
        foreach character in ( strMethodCall =~ /[A-Z](.*)\./ ).[1:10] do
                println  "   " + character

Hm.

I'm not sure I'd want to program in yet. How are blocks indicated - by indentation? Ick. Where do statements end? Can we omit the semicolons? Should we add braces? Can we come up with better syntax regular expressions than the gawdawful "/[A-Z](.*)\./", or do we just stick with it because it's standard? Do we call the loop method "for" as in Python, or "foreach" because we want to reserve "for" for a C-style loop?

I have another 30 or so things on my list, and I'm not going to go into all of them in this essay, saving them for future entries instead. I'm going to keep at this sounding board for a while, proposing useful constructs I've mined from reading language definitions, in the hope of finding a basic set of syntactic constructs that are clear, useful, productive, and most of all, satisfy the principle of least astonishment: a C or Pascal or Lisp programmer should be able to move to this new language and see its programming language constructs are somehow ... familiar, even if they've never used them before.

Labels: Development

Continuing the translation of "articles" to modern blog entries... Article 33 from March 14, 2004.

---

A quick note --- the community of merchants at Georgia Tech's new Technology Square at 5th and Spring Street are sponsoring a street festival. Sandi and I just returned from two days showing her art. Even though Georgia Tech is on spring break and the advertising for the fair was pulled at the last moment, we got a lot of foot traffic and Sandi sold one of her newest paintings.

The organizers of the street fair are determined to make it a success --- they want to turn 5th Street into a popular Midtown walking location on the weekends and plan to hold a street fair like this every weekend. They are actively seeking artists, musicians, vendors, and passersby to help turn this festival into a really big thing. Email rgarrison135 at aol dot com if you want to set up a table.

It runs from noonish to fiveish on Saturdays and Sundays. So check it out!

Labels: Artworks, Pointers, We Call It Living

So welcome to Dresan Today ... a new weblog enabling yet another wannabe digerati to dump his latest unfiltered thoughts to the Internet.

I'm Dr. Anthony G. Francis, Jr., a science fiction author and computer scientist living in Atlanta. Many of my longer pieces of nonfiction can be found on the parent site of this weblog, The Library of Dresan.

It takes me a while to update that site, so this weblog will (hopefully) serve a complementary purpose, giving me a quick sounding board for passing thoughts, cool pointers, and so forth.

I recommend the following sites:

Vast and Infinite, Gordon Shippey's weblog. I've known Gordon for almost 10 years and he's always got something interesting to say.

Studio Sandi, Sandi Billingsley's art site. Sandi is not just my significant other, she's also a fantastic artist!

On the topic of art, Megatokyo is one of my favorite webcomics; also be sure to check out The Devil's Panties, a webcomic by Jennie Breeden, a local Atlanta cartoonist.

Enjoy!
-The Centaur

Labels: Webworks

Continuing the translation of "articles" to modern blog entries ... Article 32 from March 10, 2004. Coincidentally, the announcement of this very Blogger blog.

I am continually interested in the language style of these "old" articles, some of them composed as long as two weeks ago. The ingratiating "check it out" style of the pointers, I do not like. Presumably, in future I will not like my current LOLcat style. Edison hate future. Yes.

---

Check out Dresan Today, my new weblog --- as well as the home for my experiments with weblogging software.

Manually adding entries to this site is a pain, which is one reason I tend to write big chunks spaced out over a long period of time. I've been meaning to set up software to help me automatically add updates to the Library for some time now, but between work, art and writing it's been a challenge to find enough time to work on the prototype AND work through the limitations of hosting the software on my web provider's account.

SO today I decided to cut the Gordian knot and experiment with the freely available services. The http://www.dresan.com/daily/ directory will house both my current weblog Dresan Today as well as any experiments I'm doing with weblogging tools.

Currently, I'm experimenting with Blogger, which is quick and easy to use, free, configurable, and (most importantly) doesn't require any software running on my web provider's server. This is exactly the feature set I wanted in my roll-your-own blog (not counting source code availability, extensibility, wiki features, and a searchable database of blog entries on my home machine) I decided to give it a shot. Since it took less time to set up the blog than it took to create this "normal" entry in InterDev, I think it is definitely worth a try.

So see what's on Dresan Today!

Labels: Webworks