On Fri, 5 May 2006, Tim Blechmann wrote:

right, and keeping some features underdeveloped on the grounds that Pd isn't supposed to be a programming language, just fuels the need for workarounds, and it ends up that artists have to figure out the same workarounds as when a programmer is confronted to underdeveloped aspects of a programming language... only that the programmer is better trained at figuring out workarounds.

This is a different problem because messages and lists can't be unified without making another problem appear elsewhere. If every message is seen as a list then there is no way left to tell an object to do something special because all possible messages get already seen as data. I've already explained this in great detail on pd-list and/or pd-dev. Think of the "set" method for example.

So I think that in the message-vs-list case, if there are obscure problems, they should be transformed into clear problems by teaching them to every pd user.

There are many other things that could be made simpler without introducing the same amount of new problems (but not all of them can be made so without breaking compatibility).