Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Hi Mark

Actually, this is not quite true about Smalltalk code (which is linked to its class). But referring to things is also done via variables and selectors of various kinds, and these are names which have to be locally known. Smalltalk can also find quite a few things by description (for example it can find things like the "sine function" via examples of inputs and outputs).



> it can find things like the "sine function" via examples of inputs and outputs

I think this is a really important idea. On one hand, it can save us from re-inventing code which already exists (e.g. "this existing code will satisfy your test suite"), it can help us discover relationships between existing things ("the function 'sine' behaves like the function 'compose(cosine, subtract(90))'"), it can aid refactoring/optimisation/etc.

On the other hand, it could also help us discover services/information which we could not obtain by ourselves. For example, discovering a database mapping postcodes to latitude/longitude.

There's some interesting work applying this to pure functions, using testing https://hackage.haskell.org/package/quickspec and proofs https://github.com/danr/hipspec

It's also closely related to inductive programming (e.g. inductive logic programming, inductive functional programming, or even superoptimisation), where combinations of existing functions are checked against the specification. Of course, that leads down the path to genetic programming, and on to AI and machine learning in general!


I misspoke. I just tried doing what I described, with String. Squeak notified me about "obsolete references" to the original class name in existing source code. It's been a long time since I did this. I might've seen that before when I did this, and I guess it left me with the impression that it was not capable of adapting to the change by itself. The name change didn't cause a problem in continuing to use String, even in the compiler, such as doing in a workspace: 'hello world ', 'hi there'.

I am familiar with Method Finder. I've used it several times with varying degrees of success. Sometimes I found that what I was trying to describe couldn't be expressed with the conventions it uses. I am also familiar with the fact that all of that functionality is accessible from a set of objects, but my understanding is you have to explicitly use those objects in your code to look up by description. If you just say "Classname new", you're not going to get that. That's what I was talking about (at least trying to :) ) in my previous comment.

BTW, I read Ted Kaehler's paper on using the aforementioned objects to try to access objects, if I remember correctly, within Squeak strictly by description, as a means to try out methods for "computing through negotiating with objects." It seemed to come with a little difficulty, as I remember him talking about some number of "destructive actions" that happened as a result. Interesting experiment. I had the thought around then that in order for negotiation to happen safely, the receiving system would need to put objects in a "test harness" to prevent such destructive actions.

Working with Method Finder was one of the examples I used as inspiration for trying to "sketch" a language where the idea was I could "program by suggestion," which I described in an earlier comment here (https://news.ycombinator.com/item?id=11945188).


> it can find things like the "sine function" via examples of inputs and outputs

I really like the idea, and reading through comments this question came to my mind.

Names are important for us. They synthesize what a "thing" is, and they help us organize knowledge.

So even though it might be true that for computers names are not that important (i can describe what i want), i believe they are for us, humans, when trying to understand a given system.

We grow systems both for humans and for computers.

What's your take on this? How would you find balance between the two?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: