Simplest (Overlooked) Things

Core Data looks like a simple, useful data extension to the Next Step, er, Cocoa, framework. (via Bill Bumgarner)

Objective-C and Cocoa seems to be an ongoing counter-example to Jon Udell's take on Microsoft's apparent dynamic language strategy. Jon wrote...

Jim Hugunin, who created first Jython and then IronPython, may be the world's foremost expert on this topic. When I met with him recently, I asked if he thought we'd see official .NET Framework classes written in IronPython. He said that, although dynamic languages will accelerate the development of the framework, extensions written in Python will likely be rewritten in statically-compiled languages for production use. To some dynamic-language advocates that may sound old-fashioned, but to me it sounds pragmatic.

The counter-example is Objective-C itself and the way Next (now Apple) has developed its frameworks. Objective-C makes C available where developers determine to use it, but the key to its capabilities is the dynamic object language cleanly integrated into C.

Objects in the language are fully dynamic and first-class. They enable C and other static languages to participate easily in the object-oriented frameworks without extensions or modifications to those languages. But they also enable dynamic languages to participate easily as well.

Witness the really neat integrations of Python, Smalltalk, and Lisp with the Next Step frameworks. No contortions or compromises, just simple, straightforward integration of reusable frameworks into your language of choice, static or dynamic.

Objective-C and Next/Apple's use of it is underrated and overlooked in its technical simplicity relative to the struggles of dynamic languages in the C++, C#, and Java environments. Notably, this approach dates back to Next's original effort around 1985. This is a twenty year old approach, which satisfies those of us who live in the past. 8^)

Spreadsheets and Databases

Over on the new Smallthought blog there is a conversation about spreadsheets, databases, and end user programming. I added this in a comment, but want to capture it for my own purposes and your enjoyment...

Databases — I have a friend who made a living for a good number of years on a dbase application he wrote for small businesses. Over the years he added more capabilities. He’d go into a new customer’s site, install it, tweak it, maybe implement some new things, and then take the new stuff back to previous customers that may want it. He had no formal software development education or even formal business education. He was a tinkerer, built his own airplane, his own house, etc.

Another story — a friend, MBA in finance, capable of doing decent things with Excel, tried to implement an Access application to track a small golf tournament he was organizing. Nothing ambititous at all. Access presented him with a number of “formal” database concepts that just did not matter to him. He go some things running but mentally associating various tables and forms was not immediately obvious to him, or to me when I looked at it. Maybe it was just us, but even I did not enjoy trying to get Access to do relatively uncomplicated things.

There is a spectrum of choices between a traditional spreadsheet and a traditional database. Perhaps a more usable system in this space would allow someone to begin working more like a spreadsheet and allow shapes to emerge and be supported more like a database, but not expose that support in traditional database terms. The support for those shapes should be more identifiable by the end user programmer without a 20th century software education.

New Lisp

Ted Neward wonders...

Is Ruby the next Lisp? And if so, does that make Ruby a "second chance" for widespread acceptance for Lisp?

I would not say Ruby is the next Lisp. Rather, Ruby is one of the most recent Lisp-like languages. Python is a Lisp-like language going back a decade or whatever longer.

Smalltalk is even a Lisp-like language, as has been noted recently, and Kay states Smalltalk was directly influenced by Lisp. (pdf)

Can I learn to be a better Ruby programmer by learning Lisp, or vice versa?

Yes. For that matter, one can learn to be a better C programmer by learning Lisp. Or Ruby.

If one of Lisp's strengths is writing programs to write programs, does that make Lisp a natural candidate for building DSLs?

Absolutely. And has been in practice for 40 years or more. Literally.

And, again, if the Ruby == modern(Lisp) equation holds true, does that make Ruby a candidate for building DSLs?

Ruby would not be *bad* for building DSL's. The difference with Lisp is the syntax and syntactical tools are not as good for doing this in Ruby as they are in Lisp.

DSL's are best built in Lisp and Smalltalk, somewhat less so in Ruby and Python. But Ruby and Python programmers could argue that pretty well with me. I think I know both of them pretty well but not so well as to say I know I know both of them pretty well.

Python Moving Into the Enterprise

From Slashdot...

"Seems that Python is moving into the enterprise. At the recent PyCon it has become apparent that it's not just Google, GIS, Nokia or even Microsoft anymore. The article points out that Python is increasingly becoming a perfectly viable and even preferred choice for the enterprise. More and more companies are looking at Python as a good alternative to past favorites like Java. Will we finally be able to code for living in a language that's not painful? Exciting times!"

Evolutionary

"There is no such thing as a non-self organizing system." -Esther Derby(?)

Yep

"Poor management can increase software costs more rapidly than any other factor." -Barry Boehm

Buddies, ACL's, and Capabilities

Tim wrote some time ago about making everything network aware, including...

• If you assume ad-hoc networking, you have to automatically define levels of access. I've always thought that the old Unix UGO (User, Group, Other) three-level permission system was simple and elegant, and if you replace the somewhat arbitrary "group" with "on my buddy list," you get something quite powerful. Which leads me to...
• Buddy lists ought to be supported as a standard feature of all apps, and in a consistent way. What's more, our address books really ought to make it easy to indicate who is in a "buddy list" and support numerous overlapping lists for different purposes.

Rather than ACLs, I'd like netware to provide me a list of actions it's capabable of doing on the network, along with an easy way of composing new actions. Then I'd like to make several groups of those actions from all my netware. One grouping for myself, others with decreasing capabilities for family, friends, associates, and the world at large.

My buddy list would then include for each member the groups of capabilities I have granted them. As relationships change I would then be able to increase or decrease their reach into my world.

I've not followed the e-rights world for a while. I wonder where this is going.