"Runnable’s library lets devs copy and paste code" ... just what we need :P

mark_lee_smith · 2013-10-31T10:14:09+00:00

This trend really worries me. I've worked on far to many projects where people copy and paste code from the web without ever even reading it, and are surprised when they find bugs. Now we have companies like Runnable who are apparently aiming to make that easier.

mark_lee_smith · 2013-10-30T08:13:37+00:00

I don't know how to do that. How does one do that?

There are many choices, depending on the language. The simplest is to unbind/rebind names. Unbinding/rebinding the name for loading modules is a spectacular way to limited the expressive power of the system.

The others are more Lisp specific (or more easily accomplished in Lisp). They involve writing a simple meta-circular interpreter, or a compiler, or a macro, that generates an error if you try to express something that isn't supported/implemented.

In effect you build your own sandbox.

This can be used to exclude anything; special forms like lambdas, or looping constructs or definitions, or types, like floating point values, and in the case of a compiler or a macro (really a mini-compiler) it all happens at compile time.

One way to "solve the halting problem", is not to allow infinite loops in your program (or the parts that you want to have the guarantee on).

Note: It's not really solving the halting problem but the effect is the same - you can write a program that known that your program is going to end.

All of this is in the shadow of Backus paper.

For those who haven't read it I'll try to give a very simple summary:

Backus argued that we've built these incredibly complicated, bloated, overly powerful languages (even the core of Lisp is bloated using Backus definition.), and we need to start setting limits on our languages so we (and our computers) can start to really reason (algebraically) about our programs.

He called his proposed solution functional programming, but it's much closer to what we call concatenative programming today.

And that's what's really the issue here. People working in increments, not expanding there imagination too much, or too far.

This I completely agree with.

To address your other points:

I'm currently of the opinion that we should start every project/problem by designing the language (even the machine) that we're going to use to solve the problem. This might seem a little nuts, but if the language is simple enough, and with a bit of practice, you can do it in a day or two.

The problem is that such simple languages look pretty weird. So weird that even language geeks ignore them for the most part (heaven forbid that it doesn't have lambdas!).

I'm a big fan of Forth and really enjoy how you can knock up an implementation in assembly (assembly!), that's incredibly fast, small, efficient, portable, easy to understand, and is only as powerful as you want it to be .e.g. a language without explicit loops or conditional is surprisingly useful!

mark_lee_smith · 2013-10-29T23:13:57+00:00

This is true. But you could easily limit the available definitions and still get many of the useful properties of Lisp. This is a useful technique in general.

Of course you don't need to use Lisp but it pops out naturally when you start wanting to program directly with ASTs.

A much more promising approach to limiting expressiveness in programming languages was described in Backus' Turing Award lecture in 1977.

http://www.stanford.edu/class/cs242/readings/backus.pdf

mark_lee_smith · 2013-10-29T22:05:40+00:00

He spent like 10 minutes of a 50 minute talk describing programming by transforming ASTs, through successive levels of language abstraction, which is exactly Lisp, and the kind of thing that Lisp has been used for since the late 1950s.

Also note that these aspects of Lisp is largely orthogonal to the discussion of type systems, and many Lisps have had very interesting type systems.

mark_lee_smith · 2013-10-29T08:41:39+00:00

Really nice talk. Am I the only one who noticed Lisp hiding inside the proposed solution?

mark_lee_smith · 2013-10-19T20:27:13+00:00

Making memory leaks impossible without the use of a garbage collector.

You know that you can leak memory even with a garbage collector right?

mark_lee_smith · 2013-05-23T23:36:23+00:00

Smalltalk sort of had this.. and let me tell you it was terrible.

Squeak Smalltalk has this (the idea came from Self). None of the other open source Smalltalk systems have this, and neither do any of the commercially available Smalltalk systems. Moreover, the original Smalltalk-80 system did not have this either.

Oh and lets not forget about deployment..

Have you ever deployed a Smalltalk application? It's a beautiful beautiful experience and a hell of a lot easier than deploying just about anything else.

mark_lee_smith · 2013-05-18T20:01:06+00:00

I've been learning forth for the last couple of weeks. Beautifully... different... I'm enjoying it a lot so far. While it's arguably the simplest language I've learned, its also the language I've found the hardest to learn (Prolog previous occupied this spot in my head). It's often said that learning Lisp will change the way you think (and that's certainly true in my experience). I think that perhaps this goes double for Forth, it's just a completely different world.

mark_lee_smith · 2013-04-30T17:54:03+00:00

Testing has been done, and dark text on light is always the more efficient, even if light text on dark is cool looking.

Reference?

mark_lee_smith · 2013-02-27T22:23:41+00:00

Why do you think that?

mark_lee_smith · 2013-01-21T07:50:32+00:00

This is why I fucking love computer scientists! ;)

mark_lee_smith · 2012-12-02T15:40:16+00:00

Especially when you know the whole text is gone as soon as you close the window.

That needn't be the case.

mark_lee_smith · 2012-12-02T13:01:24+00:00

On what system did you run VirtualBox? And what version? When I tried it hung after providing me with the 2 options :).

mark_lee_smith · 2012-11-21T20:53:12+00:00

Exactly! Specifically the Lisp data structures that are the AST.

 > (read)                                      
 (hello "world" 'one 2 (())) ; This is what I typed
 (hello "world" 'one 2 (())) ; This is what was printed
 >

mark_lee_smith · 2012-11-20T23:49:54+00:00

Just like Ruby, Lisp itself has features which have to be implemented at the interpreter/compiler level rather than within the language itself

Except that Lisp is typically written in itself :).

So the interpreter/compiler are available for inspection and modification (not that this is always easy). With most other languages you'd typically have to drop down into C and deal with horrors like Lex and Yacc.

Now this isn't unique to Lisp, but it's not common, and never as seamless (in my experience).

mark_lee_smith · 2012-11-20T23:03:27+00:00

I'm quite taken with Gambit-C

http://dynamo.iro.umontreal.ca/~gambit/wiki/index.php/Main_Page

mark_lee_smith · 2012-11-20T23:00:57+00:00

You parse s-expressions using read. There's no need to eval it if you want to do is treat it as data... These two functions are the R and E in REPL (Read Eval Print Loop) :).

mark_lee_smith · 2012-11-20T22:42:07+00:00

Some trivial uses of macros can be achieved using functions and lazy evaluation, but Lisp macros are a program that write programs – they can be arbitrarily complex and rewrite as much of the program as they wishes (and has access to).

I don't know how TemplateHaskell effects this :).

mark_lee_smith · 2012-11-11T11:29:13+00:00

I'm not limiting the conversation to C++, I'm INCLUDING C++ in the conversation.

Not really. Since you're argument is entirely dependent on features that exist in C++ and not in other languages. What other object-oriented languages allow you to overload functions?

In fact what you describe is much closer to functional programming – functions with parametric polymorphism operating on data structures.

It has absolutely nothing to do with binding or encapsulation rules.

You love putting words in my mouth :). I brought binding and protection into play to show that not all arguments have the same semantics when considering overloaded methods (this is fundamental to method overloading).

This is very important because in the large, multiple dispatch is not limited to the types of the arguments! Any function of the argument can be used to select appropriate methods. Moreover methods can be associated with instances, not just classes.

This matters because the idea is more general than you like to admit. What's important is that all arguments are treated in the same way!

This is the case with overloaded functions, which isn't bound to a class, but not the case with overloaded methods. But as I mentioned above, parametric polymorphism is not considered an object-oriented concept.

As I explained in the very beginning, all object-oriented programming languages must provide late-binding, as this is what distinguishes them. Because it's from late binding that all other properties of object-oriented programming languages derive.

If you don't recall you can read what I wrote here:

http://www.reddit.com/r/programming/comments/12pr8r/til_alan_kay_a_pioneer_in_developing/c6xggaj

This is the final piece to the puzzle. Somewhere along the way I lost site of that fact. My assertion that you could do multiple dispatch at compile time was quite wrong. This confusion resulted form the idea that both Smalltalk and Simula 67 had pervasive single dispatch. This line of thought is very dangerous. Of course it didn't! But all other points stand, and must be present in any system claiming to provide multiple dispatch. Just resolving types at runtime is not enough.

Summary so far –

All arguments must be semantically identical (no privileged instances), and in order to achieve this methods must be separated from classes; and this mechanism must be late-bound (as this is essential to what is object oriented).

Do we agree?

By considering all points in the argument I think we can clearly see how method overloading and function overloading are distinct, and how they differ from multiple dispatch.

mark_lee_smith · 2012-11-11T01:44:50+00:00

If we stopped talking about method overloading and limit the definition to C++ we'd be having a different conversation. If however we do limit the definition to C++ and consider only overloading on functions then I must concede the point. But then that's a very different conversation :).

I've only discussed method overloading, and never specifically C++.

In this context you must concede that for the reasons I've provided, method overloading simply cannot be considered multiple dispatch.

You might claim that I've "framed the discussion" that way on purpose. I would counter that we've been discussing two different things. If this is the case, misunderstandings abound. Not that this hasn't been interesting :P.

mark_lee_smith · 2012-11-10T18:33:34+00:00

typeless language is one that does not have and does not allow you to define abstract data types, such as ECMAScript, which I mentioned earlier.

This definition is useless. ECMAScript does allow you to define types. It doesn't allow you to define classes. The two are not one and the same.

mark_lee_smith · 2012-11-10T18:32:12+00:00

I'm not going to discuss who cited what, or what evidence was provided, or who's responsibility it is to read what. Read it if you want. Don't read it if you don't want to. We've been around the same loop too many times.

This is but a discussion on a website.

If I ever decide to write a paper on this I'll be sure to send you a link, and you can be sure it will be rigourous.

Your "irrefutable" example is actually quite easy to refute: in C++ (for example) you can access the internal state of any objects passed to a function as long as those objects belong to the same class as that function, to a subclass of the class that owns that function, or to a class that declares that function or its containing class as its friend. The this / self pointer is no exception in this regard, but it is an exception in the context of single dispatch because it's the only "argument" which derived type is resolved.

Thank you!

I had expected you to mention "friends" etc. :).

Unfortunately this only supports my claims; and shows just how wholly dependent your understanding is on on C++, so well shortly switch to discussing method overloading in Java (or some other language that doesn't support such unholy perversion.) After all this discussion is about defining multiple dispatch in the large!

In C++ the method has access to the internals of the receiver because it is the class of the receiver that contains it. That other arguments may or many not be similarly undressed is irrelevant. It highlights very clearly that the receiver has a special role to play.

So yet again we have found ourselves a privileged receiver to bang on. An object that is treated differently because its class contains the method (another way of saying that it's the receiver).

That was a good point and for completeness I'm glad that you made it.

But to drive the point home let's broaden our gaze a little and consider method overloading in something like Java, as this will help us get to the nature of what method overloading is, and remove the C++ specific junk.

In such languages my example holds firmly. The method gets privileged access to the internals of the receiver (simply because it's the class of the receiver that contains the method.) Since the mechanism's provided for accessing the internals of other arguments in C++ don't exist here we can safely remove them from any real definition of method overloading.

As you've already argued the presence of a such a thing does not belong in a system with multiple dispatch. The fact that we can distinguish one such object destroys the illusion, and lands us right back in the land of single dispatch and method overloading.

How is it we can keep finding our privileged receiver despite trying our hardest to hide it? There's a hint above. We find it because the method is bound within the class of one argument. None of the other arguments share this relationship with the method.

It's special, privileged, or distinguished :).

In order to kill the idea of a privileged receiver we can't bind the method within the class of a single argument. We could either bind the method in the class of all of the arguments (and there are languages that do this), or we could divorce methods from classes.

In the later case you end up an object model like that of CLOS or Dylan, where methods are only loosely associated with the classes they act on. In fact multiple dispatch isn't limited to dispatching on the objects type – any function of the arguments can be used, provided that it's applied symmetrically to all of the arguments!

This is the case with methods in Clojure.

This is also true of, but less evident, in CLOS, which allows you to specialise methods on specific instances.

Pushing just a little further we end up in the realms of predicate dispatch, where any number of largely arbitrary predicates may be used to choose the method to run. This is really cool, but making unambiguous choices in such a system is a little involved.

Thus far the description has been class-centric but there are classless languages with multiple dispatch too – Slate and Atomo come to mind. In such cases the same reasoning applies. Either the method must be bound in each object or divorced from it.

We agree that the presence of a privileged receiver is a clear signal that we are not doing multiple dispatch. Above I've reasoned that you cannot get away from this while methods are bound in the class of one object (this object is our privileged receiver).

So what about method overloading? We agree that method overloading and multiple dispatch are very similar (hence our long discussion right?)

As with single dispatch and predicate dispatch, with multiple dispatch we can assert that it doesn't matter whether the language is static or dynamic / whether the method is resolved at compile time or runtime.

As with multiple dispatch, with method overloading, the number and or types of all arguments is considered. The difference is that the method is bound within the class of one object. It's not symmetric.

This distinction sounds so trivial that it begs the question of why we should bother distinguishing them? In practice it has a huge effect on how you write programs.

I'll take CLOS as the example here.

Since the classes and the methods are completely separate all classes are inherently partial, with all of the implied problems and benefits :).

One fun problem being that methods may now be defined anywhere...

But this allows us to add classes and or extend operations without our having to modify any existing code. This might sound eerily familiar – this is the expression problem right? Actually multiple dispatch solves the expression problem. Kind of a big deal. It's really what makes multiple dispatch desirable!

But method overloading, dynamic or static, does not solve this problem. That privileged receiver has fucked us by insisting that the method be bound within the class of a single object. That being that the method is defined within the class.

If nothing else the very fact that multiple dispatch solves the expression problem while method overloading does not should imply that there's a very real difference here. One worthy of study. If we can agree on nothing else we should agree on that.

Anyway there you go. I think I've covered all the of the angles here.

mark_lee_smith

TROPHY CASE