4 ms·

And what about CLOS? Does not make Lisp, in your words, a "hash programming language"? Really I don't get the difference you state between list/hash programmin

by edu 19y ago

And what about CLOS? Does not make Lisp, in your words, a "hash programming language"? Really I don't get the difference you state between list/hash programming languages, I've work a little with EcmaScript and I don't know anything about Io, but I'll put it in my to-do list. Can you, please, extend it? What's the main difference between them? Because you say that the primary abstraction of a "list" programming language is a tree, which I think not. Since a tree is a directed graph without cycles, you wouldn't have loops. So, at least is a directed graph. But then, which property has the "hash" language graph that the "list" language graph has not? It's an undirected graph? It think it is not possible, because if it's undirected how do make your program to go "forward" and not "backward"? I hope I'm not too obfuscated and my questions make some sense.

gordianknot 19y ago
I've never looked at CLOS. But, what I mean is the "dominant metaphor," which I suspect is still lists. I'll just go through my probably plebeian understanding. Arrays are to lists as hashtables are to objects. An array, in my mind, is a list that only contains one type and is indexed with enumerated integers. On the other hand a list can contain any type, but is also indexed with enumerated integers. In JavaScript: array = [1, 2, 3] list = ["one", [[array], 3]] array[0] == 1 list[20] = 23 // list indices aren't necessarily a linear enumeration Of course, arrays and lists are both technically Arrays in JavaScript (a bad naming choice; I'd have called them Lists). Now a hashtable is typically just a list that uses strings for indices instead of integers. hashtable = { "today":20080403, future:function(x) { return this.today + x } } A "method" is just a value that happens to be a function. Usually hashtable-oriented languages choose to abstract away the string, and treat it as a variable. hashtable["today"] == hashtable.today hashtable.method(23) Like with lists/arrays, JavaScript gets hashtables/objects almost exactly right, but again is subject to some questionable naming choices. RE: trees and graphs -- I was getting at the relationships between nodes, not the actual computations, but I'm not comfortable enough with the terminology to explain exactly what I meant.
- edu 19y ago
  Ok, I think I get you. But then I think you can't categorize programming languages this way, the default data-structures provided by the language don't characterize it. In fact, it seems to me that you like most JavaScript because it's object oriented, it's dynamic typing and functions are first-class. Features that others languages lack, and not because the "dominant metaphor" is the hash. Casually in JavaScript the objects are built with hashes (at least apparently), and can be easily extended. It's a fun thread :D
  - gordianknot 19y ago
    Built-in data structures are a big point of categorization of langs on my end. To me, the defining feature of Java is its classical structure. If you got rid of classes, you'd have a different language (in the interface sense). And interface is really all I'm talking about. I'm basically just asserting that objects (should) == hashtables. This is quite literal in JavaScript. Other languages bend the metaphor in different directions, and obscure it to that no one even knows what "object-oriented" really means beyond particular idiosyncratic syntax in this language or that. PG of course talked about this before, in Why Arc Isn't Especially Object-Oriented: > I've done a lot of things (e.g. making hash tables full of closures) that would have required object-oriented techniques to do in wimpier languages ... I'd argue that he was employing genuine object-oriented techniques, but just didn't have classical syntax and didn't consider what he had an "object." Other languages make a point about it, and use special syntax, which fogs the whole thing. Perhaps some people in "OO" mindsets have the kind of naivete that C-only hackers I've met have about first-class functions. Actually, I just realized the whole reason C++, Java, C#, and co. have "methods" in the first place is just compensation for not having first-class functions you can stick in a hashtable.
    - anamax 19y ago
      If objects == hash tables, any language with decent hash tables, including lisp, has objects that you're perfectly happy with. Lisp also has other data types, but their existence means that lisp has more power, not less.
- 19y ago
jimbokun 19y ago
"And what about CLOS? Does not make Lisp, in your words, a "hash programming language"?" I think in the "hash" languages, you usually consider the method to "belong" to an object in some way. With multi-method dispatch, the relationship between objects and methods is more fluid. So I think there is a difference here, too. It's not that "list" languages only use tree structures for everything, just that trees are the more "natural" choice in those languages.

by edu 19y ago

gordianknot 19y ago

I've never looked at CLOS. But, what I mean is the "dominant metaphor," which I suspect is still lists. I'll just go through my probably plebeian understanding. Arrays are to lists as hashtables are to objects. An array, in my mind, is a list that only contains one type and is indexed with enumerated integers. On the other hand a list can contain any type, but is also indexed with enumerated integers. In JavaScript: array = [1, 2, 3] list = ["one", [[array], 3]] array[0] == 1 list[20] = 23 // list indices aren't necessarily a linear enumeration Of course, arrays and lists are both technically Arrays in JavaScript (a bad naming choice; I'd have called them Lists). Now a hashtable is typically just a list that uses strings for indices instead of integers. hashtable = { "today":20080403, future:function(x) { return this.today + x } } A "method" is just a value that happens to be a function. Usually hashtable-oriented languages choose to abstract away the string, and treat it as a variable. hashtable["today"] == hashtable.today hashtable.method(23) Like with lists/arrays, JavaScript gets hashtables/objects almost exactly right, but again is subject to some questionable naming choices. RE: trees and graphs -- I was getting at the relationships between nodes, not the actual computations, but I'm not comfortable enough with the terminology to explain exactly what I meant.

edu 19y ago
Ok, I think I get you. But then I think you can't categorize programming languages this way, the default data-structures provided by the language don't characterize it. In fact, it seems to me that you like most JavaScript because it's object oriented, it's dynamic typing and functions are first-class. Features that others languages lack, and not because the "dominant metaphor" is the hash. Casually in JavaScript the objects are built with hashes (at least apparently), and can be easily extended. It's a fun thread :D
- gordianknot 19y ago
  Built-in data structures are a big point of categorization of langs on my end. To me, the defining feature of Java is its classical structure. If you got rid of classes, you'd have a different language (in the interface sense). And interface is really all I'm talking about. I'm basically just asserting that objects (should) == hashtables. This is quite literal in JavaScript. Other languages bend the metaphor in different directions, and obscure it to that no one even knows what "object-oriented" really means beyond particular idiosyncratic syntax in this language or that. PG of course talked about this before, in Why Arc Isn't Especially Object-Oriented: > I've done a lot of things (e.g. making hash tables full of closures) that would have required object-oriented techniques to do in wimpier languages ... I'd argue that he was employing genuine object-oriented techniques, but just didn't have classical syntax and didn't consider what he had an "object." Other languages make a point about it, and use special syntax, which fogs the whole thing. Perhaps some people in "OO" mindsets have the kind of naivete that C-only hackers I've met have about first-class functions. Actually, I just realized the whole reason C++, Java, C#, and co. have "methods" in the first place is just compensation for not having first-class functions you can stick in a hashtable.
  - anamax 19y ago
    If objects == hash tables, any language with decent hash tables, including lisp, has objects that you're perfectly happy with. Lisp also has other data types, but their existence means that lisp has more power, not less.
19y ago

jimbokun 19y ago

"And what about CLOS? Does not make Lisp, in your words, a "hash programming language"?" I think in the "hash" languages, you usually consider the method to "belong" to an object in some way. With multi-method dispatch, the relationship between objects and methods is more fluid. So I think there is a difference here, too. It's not that "list" languages only use tree structures for everything, just that trees are the more "natural" choice in those languages.