Scratch

I got a nice little Python server going; so now I can export lists to a file! 

Jens wrote:

You'll see the "export..." feature if and as soon as there is something "texty" assigned to the variable, either a text or a number.

Is there any way to include newlines? Neither (unicode (10) as letter) nor (unicode (13) as letter) seem to work...

EDIT: Ah, I see Hardmath beat me to it 

Last edited by blob8108 (2013-01-23 09:04:08)

Jens wrote:

Yes, this is clearly The Right Thing.

That's not so clear to me.  It's clearly The Scratch Thing but Scratch was limited by not wanting to allow reading or writing files under program control.  We are limited by Javascript not wanting to allow that, but in other such cases we've decided to wait until browsers implement the official HTML5 way to do it.  The right thing, it seems to me, would be to have blocks OPEN FILE, READ LINE FROM FILE, WRITE LINE TO FILE, etc.  (Not just a CONTENTS OF FILE reporter, even though that would be in some ways more elegant, because some files are very very big.)

Only that in Snap we're using generic variable watchers for lists, so we want to import plain text files directly into a variable's value, and do the parsing ourselves.

I don't see how the conclusion follows from the premise.  In Scratch, you can't set the value of a variable to a list, so they have to have their kludge operate on Make-a-list lists, which we don't have.  But we could set the value of the user's variable to a list, one item per line.

Also, using a browser tab as an intermediary between the file and the Snap! project works only for text files.  If the file is HTML, or a JPG, or something, the browser will insist on interpreting the file's contents.  So if I'm trying to write a program that, I don't know, datestamps all the pictures in a certain folder, I can't do it this way.

Sorry, I know you don't like arguing about design in the forum, but you sprang this on me.

EDIT:  CONTENTS OF FILE would be fine if we had lazy lists, but they're hard to reconcile with a visual language.  After 4.0 is out we can talk about whether that's feasible.  I think it would be pedagogically awesome.

EDIT 2:  ... and because we can create lists dynamically, there's no reason (unlike the case in Scratch) why the contents of a file have to be associated with a variable, let alone a global one.  First class files!

Last edited by bharvey (2013-01-23 18:29:55)

bharvey wrote:

nXIII wrote:

@bharvey your ring has quite a following 

I wonder Y?

Sorry, I know you don't like arguing about design in the forum, but you sprang this on me.

Why? I much prefer it to having to guess about your reasoning behind the design because you decide on it in private email messages.

As for importing stuff, how about exporting all values as XML? It's consistent with the project format, requires very minimal work on the client, and produces human-readable data. We could also offer an "import plain text" option for users who have data in other formats that they want to import and parse themselves.

Last edited by nXIII (2013-01-23 14:32:29)

nXIII wrote:

Why? I much prefer it to having to guess about your reasoning behind the design because you decide on it in private email messages.

I don't know what Jens's reasons are, but one of mine is that you guys are a very atypical set of users.  We're trying to design for, you know, the kids who stuff you guys in lockers and/or wastebaskets.  (This is partly a joke, employing an exaggerated stereotype -- two of them, I guess -- to paint a quick picture, just so nobody feels the need to yell at me; in particular, our target audience includes girls, who for the most part are neither stuffers nor stuffees.  My serious point is that our target audience is non-programmer, non-mathematicians.)  So the things you want aren't necessarily the right choices.

Also, I think I spend a lot of time in this group explaining why we did various things the way we chose to do them.  But we can't explain the design until we understand it ourselves, and the beginning stages of a discussion sometimes involve more heat than light, a process we couldn't engage in so freely in public.

Just for example, when we first started talking about OOP, I think I was the only one in our gang with any real experience (from Object Logo) working with prototyping OOP.  The rest of you all grew up with Java and/or Smalltalk.  And I had the huge advantage of having hung out with Henry Lieberman back in the day.  So I knew I was right (no smiley, sorry, I really did) but had to convince Jens, and somehow we ended up having the argument in front of y'all, which made it kind of unpleasant.  (It would have been extra bad if I'd convinced everyone else before convincing Jens.  Luckily we were having an email conversation in parallel with the forum one.)

We definitely sometimes get great ideas from you that we might not otherwise have thought of.  But even in the real world, large design groups tend to lead to creeping featurism, so in the end you have a language nobody can learn even though each individual feature is fantastic.  (This is what's happened to Scheme recently, alas!)

P.S.  Yeah, B.A.A., I know I haven't convinced you yet. 

P.P.S.  And I also know that some of the details of the OOP design were too confusing, although I think including the tool blocks (in particular, TELL and ASK) in the reference manual will help a lot.

P.P.P.S.   ...but we're not going to have a public discussion about OOP until Jens and I have at least a detailed proposal and preferably a working version to present!

Last edited by bharvey (2013-01-23 18:23:29)

blob8108 wrote:

Jens wrote:

You'll see the "export..." feature if and as soon as there is something "texty" assigned to the variable, either a text or a number.

Is there any way to include newlines? Neither (unicode (10) as letter) nor (unicode (13) as letter) seem to work...

EDIT: Ah, I see Hardmath beat me to it 

Woah, that was awesome. But my suggestion was more generic; I wanted to be able to have newlines in every string, including variables and say bubbles. 

Oh. I suppose list watchers should be Text, then?

@bharvey: That's a pretty ambitious goal. All the (pardon me) non-intellectual kids who are mainly soccer players seem to be pretty averse to anything involving numbers, or, for that matter, thinking. And for them learning to code in school (Visual Basic *utter disgust smiley here*) is basically no better than history class.    I suppose I was really lucky; I was introduced to computers out of my own sweet will, and everything I learned, I learned on my own because I wanted to. That makes a difference.

Hardmath123 wrote:

Oh. I suppose list watchers should be Text, then?

Everything should be a TextMorph, and StringMorphs shouldn't exist at all.

Last edited by nXIII (2013-01-24 15:41:41)

BornAgainAtheist wrote:

I don't really mind Java like syntax, of course that may just be because Eclipse and Visual Studio make me lazy.

I get the feeling that any language that needs an editor like Eclipse to be productive has failed somehow. 

Hardmath123 wrote:

a cross between Lisp and Python

Called Lyspthon, obviously. 

Jeez, nXIII.
(the Pope is more broad-minded). 

Hardmath123 wrote:

how tough would it be to implement a programming language from scratch?

It's not very hard to write a toy implementation of a language (especially if the language is Lisp, which has no syntax to worry about).  It's a lot harder to write a really efficient implementation.  Garbage collection alone is an ongoing research topic and not easy to get right.  (Multiprocessor GC boggles the mind.)

Even though a lot of people use it, I'd put Berkeley Logo in the "toy" category, partly because its GC is rather primitive, and partly because of issues with tail call elimination.  (Scratch, BYOB, and Snap! all benefit from being implemented on top of languages that provide garbage collection.  But an interpreter on top of an interpreter has its own efficiency problems.)

I was thinking of writing a cross between Lisp and Python, two of the coolest languages ever. The idea is to combine the (lack of!) syntax of Lisp with the efficiency of Python, and I already have a few syntax elements in my mind.

If that's meant to suggest that Lisp is inefficient, you should do timing runs of compiled Common Lisp against Python.

For teaching purposes, we Lispians encourage beginners not to worry about efficiency in a first course, and that means things like encouraging simpler (non-tail-)recursive procedures over more complicated iterative ones with extra state variables thrown in.  But professional Lisp programmers can write iterative code where it matters.

If the object of the exercise is for you to learn about programming language design and implementation, go for it!  But if you truly expect any "a cross between" language to end up better than its parents, history is against you.  The languages that go down in history have a simple organizing idea around which the language is structured.  C is a more important language than C++ because the former is organized around bringing the notation of a high level language to a semantic model that makes explicit the placement of data in memory, whereas the latter is a cross between C and Smalltalk.  Lisp is organized around functions and linked lists.  I'm not a big Python fan partly because it seems to have three different implementations of the Sequence abstraction (although of course also because it has a broken lambda).