Ted Leung on the air
Ted Leung on the air: Open Source, Java, Python, and ...
Ted Leung on the air: Open Source, Java, Python, and ...
Mon, 02 Feb 2004
Hashtable oriented programming
Ian Bicking picked up on yesterday's post on Lisp/Python and makes an excellent point about hashtables. One of the great strengths of Python is that it makes dictionaries very easy. You can also pun the syntax to make things look like hashtables, and I agree that this is a strength in many applications, particularly "scripting" tasks. When you want this sort of notation, you want it badly because it makes the code much more succinct.
Then I started thinking about it some more. What if you took a language that was easy to reason about, and embedded a dictionary/hash-table oriented programming model in it? If you had a mechanism for syntactic extension, like Ben wants, then you would only pay for this very useful feature when you needed it, and you could make it look like part of the language proper. Of course, there aren't many languages where you could do this. You'd be limited to languages with some sort of macro system. Maybe I've just imbibed a bit too much of the Lisp/Scheme multi-paradigm view of the world.
I'm very interested in apps that are driven off of semi structured data models, and a hash-table oriented programming model makes a large amount of sense for these applications -- in fact, this is one of the reasons that Python was selected for Chandler. At the same time, many of those applications want to do tasks that remind me of AI programs. Some of these tasks are computationally intensive, and efficiency becomes a concern. And lastly, those applications need a good way to talk to a human, which means that the ability to integrate/talk to existing libraries of widgets, speech synthesizers, etc is also a must. So far, I haven't found a single language that incorporates all of these possibilities.
In any case, this is very thought provoking, and helping to get a deeper understanding of Python than I had before. I know the Lisp/Scheme multiparadigm stuff well because I studied it in school and followed it as a research thread in graduate school. I still consider myself a Python beginner, since I haven't dabbled in the Python object system internals, etc. So all of this is helping me to become a better Python programmer.
[23:57] |
[computers/programming] |
# |
TB |
F |
G |
7 Comments |
Seriously, have you looked at JavaScript, Ted? The syntax has exactly what you describe when you talk about the sugar needed to make hashtables an imperceptible part of the language.
Here's an example:
Object, of course, doesn't have the bar and baz properties - I've just defined them at instance-level. If I wanted to define them at class-level, I'd define them in the prototype, instead (thus, making it non-hashmapped anymore).
Hmm... maybe Python has this too, and I just hadn't noticed? :)
Posted by Carlos Villela at Tue Feb 3 16:23:48 2004
Here's an example:
foo = new Object();
print(foo.bar); // null
foo.bar = 10;
foo.baz = 100;
print(foo.bar * foo.baz); // 1000
print(foo["bar"]); // 10
print(foo[1]); // 10
Object, of course, doesn't have the bar and baz properties - I've just defined them at instance-level. If I wanted to define them at class-level, I'd define them in the prototype, instead (thus, making it non-hashmapped anymore).
Hmm... maybe Python has this too, and I just hadn't noticed? :)
Posted by Carlos Villela at Tue Feb 3 16:23:48 2004
Carlos,
Thanks for the reminder of JavaScript. I've used it a tiny bit but tend to forget about it.
The issue here is not just whether you can do easy hashtable type stuff, it's also how much does the language pay for it. It's not clear to me that it's any easier to reason about JavaScript programs than Python programs (in the compilation sense of reasoning). The expense of the Python hashtable/object model is there whether you are using the flexibility or not.
Posted by Ted Leung at Tue Feb 3 23:13:57 2004
Thanks for the reminder of JavaScript. I've used it a tiny bit but tend to forget about it.
The issue here is not just whether you can do easy hashtable type stuff, it's also how much does the language pay for it. It's not clear to me that it's any easier to reason about JavaScript programs than Python programs (in the compilation sense of reasoning). The expense of the Python hashtable/object model is there whether you are using the flexibility or not.
Posted by Ted Leung at Tue Feb 3 23:13:57 2004
There are four ways to do this in Microsoftland. I'm sure some of those are faster than Python, although probably verbose. Also, check out the record type in dotlisp.
Posted by Robert Sayre at Wed Feb 4 06:59:34 2004
Posted by Robert Sayre at Wed Feb 4 06:59:34 2004
I was going to ask about JavaScript as a 'hashtable' language also, but someone beat me to it.
Just for kicks - here's ecmascript4xml, adding native XML support to the script language.
http://xml.coverpages.org/ECMAScript-XML.html
and
http://dev2dev.bea.com/products/wlworkshop/articles/JSchneider_XML.jsp
(I know some folks the helped with a reference implementation)
Posted by Mike Dierken at Wed Feb 4 21:25:13 2004
Just for kicks - here's ecmascript4xml, adding native XML support to the script language.
http://xml.coverpages.org/ECMAScript-XML.html
and
http://dev2dev.bea.com/products/wlworkshop/articles/JSchneider_XML.jsp
(I know some folks the helped with a reference implementation)
Posted by Mike Dierken at Wed Feb 4 21:25:13 2004
Hey Mike,
Yes, I'm familiar with the e4x/ecmascript4 xml work.
Posted by Ted Leung at Wed Feb 4 22:36:17 2004
Yes, I'm familiar with the e4x/ecmascript4 xml work.
Posted by Ted Leung at Wed Feb 4 22:36:17 2004
FWIW like other scripting languages, Groovy has native subscript operators for working with hashtables (anything which implements the Map interface).
Though through operator overloading anything can look map-ish by providing a getAt(key) and putAt(key, newValue) method. So 2 methods is all it takes on any type to allow things like
foo[123] = foo['abc']
etc.
So I guess operator overloading is another option instead of macros?
Posted by James Strachan at Tue Feb 17 00:08:31 2004
Though through operator overloading anything can look map-ish by providing a getAt(key) and putAt(key, newValue) method. So 2 methods is all it takes on any type to allow things like
foo[123] = foo['abc']
etc.
So I guess operator overloading is another option instead of macros?
Posted by James Strachan at Tue Feb 17 00:08:31 2004
Have you had a look at LUA at www.lua.org.
This language has all you need for table oriented programming and is very compact. It has a hash table that is better than python and javascript. It's one main drawback is the lack of libraries, but it is very easy to extend. I use it embedded in C, Delphi and .NET business applications.
I used to use Python frequently but found it very bloated and a pain in the arse to embed, I find LUA far supperior as a language, that can easily be extended and embedded with little overhead and effort.
I have developed many data driven business applications using the LUA interpreter that reduces maintenance overhead, are easy to extend and update without throwing 100's of users offline.
A lot of game writers use LUA as an embedded interpreter.
There are lots of advantages to Data Driven Programming in the real world but OO seems to be the flavour at the moment to the detriment of any other good programming concepts.
Regards
Peter Kulek
Posted by Peter Kulek at Tue Jan 31 14:33:23 2006
This language has all you need for table oriented programming and is very compact. It has a hash table that is better than python and javascript. It's one main drawback is the lack of libraries, but it is very easy to extend. I use it embedded in C, Delphi and .NET business applications.
I used to use Python frequently but found it very bloated and a pain in the arse to embed, I find LUA far supperior as a language, that can easily be extended and embedded with little overhead and effort.
I have developed many data driven business applications using the LUA interpreter that reduces maintenance overhead, are easy to extend and update without throwing 100's of users offline.
A lot of game writers use LUA as an embedded interpreter.
There are lots of advantages to Data Driven Programming in the real world but OO seems to be the flavour at the moment to the detriment of any other good programming concepts.
Regards
Peter Kulek
Posted by Peter Kulek at Tue Jan 31 14:33:23 2006
You can subscribe to an RSS feed of the comments for this blog:
Add a comment here:
You can use some HTML tags in the comment text:
To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are:
You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk
To insert a URI, just type it -- no need to write an anchor tag.
Allowable html tags are:
<a href>
, <em>
, <i>
, <b>
, <blockquote>
, <br/>
, <p>
, <code>
, <pre>
, <cite>
, <sub>
and <sup>
.You can also use some Wiki style:
URI => [uri title]
<em> => _emphasized text_
<b> => *bold text*
Ordered list => consecutive lines starting spaces and an asterisk