Scratch

bharvey wrote:

On the technology front, Jens's big project right now is to develop a uniform interface for locally installed software providing Snap! with access to hardware such as robots and sensors, and optionally to the local filesystem.  Once this is done, the device-specific stuff should be writeable in Snap! itself, allowing quick and easy support for new devices as they're invented.  Not to mention serious local saving of projects.  We are also, as part of the same project, going to gain the ability to serve media (costumes, etc.) from an Internet back end.

How? JS has terrible permissions and even worse compatibility. 

bharvey wrote:

Since I can't get posting my project to work, I'm reposting my nonworking AMB project as a screenshot.  Jens can fix it if it's a Snap! bug, and joefarebrother can fix it if it's a bug in my code. 

http://cs.berkeley.edu/~bh/bad-amb.png

PS The THINK block is just there for debugging.

Waiter, there's a serif font in my Snap!

xly wrote:

I already use the following method for local saving of my projects

Yes, I do that too, but we can't expect teachers and kids to do something so complicated.

Hardmath123 wrote:

How? JS has terrible permissions and even worse compatibility. 

There is a way for one site to provide resources for another site.  The idea is that people who want this feature install a local server that isn't the Snap! server but lets Snap! talk to it over http, and provides access to hardware ports and/or local files.

This is just the right level of security: People who trust us can use Snap! to do anything on their computers, while people behind paranoid IT departments can still run Snap!.

Jens wrote:

I'm not debugging anything in Times

Fine, does this make you happy?

Looks like the Berkely site's down, all of Brian's images are gone.

bharvey wrote:

There is a way for one site to provide resources for another site.  The idea is that people who want this feature install a local server that isn't the Snap! server but lets Snap! talk to it over http, and provides access to hardware ports and/or local files.

I'm assuming Snap'll use node.js?

A really good guide I've been working through. Though a lot of the explanations of how functions are executed would be old news to you.

EDIT: And an AWESOME analogy that questions Java in considering everything an object.

Last edited by shadow_7283 (2012-08-17 15:59:57)

joefarebrother wrote:

Why are spaces brown circles in snap!?

Only in input slots, not in SAY or THINK or other display of values.  It's mainly so that you can tell the difference between a string containing just a space and an empty string, both of which come up reasonably often in programs.  One of the participants in my summer workshops spent an hour or two trying to catch a bug that turned out to be about this; he thought he had an empty input slot for the function in a MAP call, but really he had a nonempty input consisting of a space.

I see what you're saying. I don't think the author was making a case against OOP- far from it. I think he was questioning the requirement that functions have to be wrapped inside of classes. He believes that functions should be allowed to stand alone as seperate entities. Java, for whatever reason, doesn't have first-class functions. 

One question I did have though- I've always associated Lambda with OOP. But the article made them sound like complete opposites.

Lambda the Ultimate... In this place it is said that there are no nouns at all, only verbs!

Admittedly I really don't understand a lot of the CS concepts you discuss. Could you explain it Brian?

I have an idea. It's a bit complicated, but it would be really cool. Why don't you make just one edit mode? In this you could do the sizing of the stage yourself by dragging a handle (like the one from chirp) toward one side. Dragging it right would shrink it and dragging it left would grow it. What do you think?

Last edited by dasbloekendeschaf (2012-08-18 17:15:38)

shadow_7283 wrote:

Could you explain it Brian?

Yeah, after I get back from today's day trip to Delphi.

Hardmath123 wrote:

Delphi? As in the Oracle, or Indiana?

Oracle.  After sacrificing a goat to Apollo, I asked, "How can I ensure that Snap! will take over the world?" and the priest replied, "Narf!"

I'm in Athens for Constructionism 2012 and came a few days early to sightsee.

Okay, nouns and verbs.

TL:DR -- You can use lambda to implement OOP, but they're quite different ideas.

This is what I hate about blogs; the guy seems to know what he's talking about, as near as I can tell, but he's much more interested in sounding clever than in helping the reader understand what he means.  I think he is mixing up several different issues.

First of all, forget about OOP and functional programming, and think about plain old programming.  And think specifically about the problem of generic operators.  The classical example (SICP 2.4 and 2.5) is arithmetic operators +-*/ on different kinds of numbers (say, integer, exact rational, real, and complex).  For the purposes of this paragraph, suppose that the two operands are always the same kind of number as each other, so we only have one type at a time to worry about.  (SICP 2.5 if you want to know how to solve the general problem.)  So that's four operators and four data types, for a total of 16 functions with names like +int, +rat, etc.  If you now imagine a more complicated situation with 20 operators on 30 types, that's 600 functions, too horrible to contemplate as individual global named functions.

So we try to organize them in some way.  Conceptually, they form a two-dimensional array (types as rows, operators as columns).  There are three basic ways to organize them all:

1.  Conventional style -- the way people did it before anybody thought very hard about the problem:  You have one + procedure, and inside the code for that procedure you have a big multiway branch: if type is int, then ... else if type is rational, then ... etc.  People did it this way because, as the blog guy says, we tend to think about actions in terms of verbs.  + is a verb; 3 is a noun.

2.  Data-directed programming:  You turn the mental two-D array into an actual two-D array data structure in your program, and the elements of the array are the individual +int etc. functions.  (If your language has lambda, you don't even have to give the functions names, just put lambda expressions in the array elements.)  Then you write a generic operate function that extracts the type from the data and looks for the appropriate entry in the table.

3.  Message passing:  For each data type you write a dispatch procedure, just like #1 but representing a row of the conceptual array instead of a column:  if op is +, then ... else if op is -, then ... etc.  This dispatch procedure represents a noun.

So far, in terms of code maintainability, #2 is the clear winner.  Think about adding a new type, or adding a new operator.  #1 makes adding an operator easy (you just write a new procedure for it), but to add a new type you have to go through your existing code, finding every operator procedure without missing any, and adding a new else if clause without breaking any of the old code.  #3 has the opposite problem; adding a new type is easy but adding a new operator is hard.  With #2, we can do either just by adding new elements to the array.

So far, then, neither emphasizing nouns nor emphasizing verbs has much to recommend it.  And the analogy between programming language elements (operations and data) and natural language elements (verbs and nouns, respectively) hasn't brought much clarity to the issues.

Moving on, we're going to see that each of nouns-first and verbs-first paves the way for a brilliant stroke of genius that brings the programmer a huge burst of expressive power.  In both cases, though, the expressive power comes at a cost: the programmer has to choose to play by the rules of this stroke of genius, without cheating, in order for it to work.

First the verbs-first one:  The genius is Alonzo Church, and the brilliant move is to make functions first class!  In other words, we need to be able to manipulate functions as data -- ironically, turning the verbs into nouns.  If a function can be the value of a variable or an item in a list, then it's a thing as well as an action.  This really is an unnatural way for people to think, and it's one of the big reasons why most people have to struggle to get very far in formal mathematics (not high school math).  There are two reasons to make the effort:

(a)  If you play by the functional programming rules, which means that you never change the value of a variable or the elements of a data structure, then your payoff is a program that's easy to parallelize and safe against concurrency bugs.  (If no part of the program changes anything, then it doesn't matter what order the parts are run in.)

(b)  The point that the blog misnames "lambda the ultimate" -- there's a history about that name, not important right now -- is that first class functions are universal.  Anything that can be computed at all can be computed with just lambda and procedure calling; you don't need numbers, or lists, or anything else you might think you need, because they can all be defined in terms of lambda.  (In particular, by the way, you don't need OOP because you can build it out of lambda; see SICP 3.1.)  The universality of lambda is really interesting, but of no practical importance; you wouldn't want to program in a language without numbers.  So it's kind of a red herring in the blog.  He wants to use the power of functional programming to argue for verbs, but he doesn't want to follow the discipline of functional programming, so arguing from it is a cheat.

Okay, we're finally ready to talk about OOP, the nouns-first stroke of genius.  The genius is Alan Kay, although he cites a long line of predecessors.  And the big idea is that if you add to message passing the ideas of local state (mutable variables that belong to an object rather than being global, and that stick around forever) and inheritance (being able to define a new class as a slight modification to an old class, sharing most methods), you end up with a great way to model time-varying situations, which can be anything from a video game to an operating system.  (By contrast, functional programming excels at problems in which the passage of time in the situation being simulated isn't an issue.  I don't mean that the efficiency of the program itself isn't an issue!)

But, to get the benefit of the idea, you can't cheat.  Everything has to be an object.  Objects interact only by sending each other messages.  As I said before, Java doesn't do this, because numbers aren't objects, neither are arrays, etc., so if you want to invent some new kind of number (exact rationals, for example) your new numbers won't share methods with the old ones.  That is, if you define square(x) to be x * x, unless you really stand on your head, that function won't work for exact rationals.  But it does work smoothly in Smalltalk, because square is a method of the Number class, of which Integer and Real are subclasses, and you can make Rational another subclass of Number and if you provide a multiplication method for them, square just works.

Note that the blog is wrong in treating lambda calculus and OOP as symmetric opposites.  Lambda calculus can do without primitive nouns (e.g., variable declarations) altogether, whereas OOP still has functions, buried inside the classes as methods.  But he's right that they're sort-of opposites.

I think it's right that Java doesn't really get any benefit from outlawing global functions, because it's not a truly OO language.  Java's design fetishizes (think the forum autocensor knows that word?) certain aspects of OOP to try to make up for the parts they leave out.  But the trouble is that Java doesn't take nouns-first seriously enough, not that it does nouns-first at all.

P.S.  I should add that some programming language theoreticians think we are now in a post-paradigm world in which the best modern languages aren't purely functional, or purely OOP, or purely declarative, but instead try to support all of these programming styles without just being a mess.  Javascript is an interesting example -- I'm not sure I'd say it's a 100% successful example, but it's a step in the right direction.  Java is a mess.  IMHO.

Last edited by bharvey (2012-08-19 14:43:34)