10.0 looks amazing

Advanced Topics
124

If you're interested, I have a 2.2.4 starter project that contains all the code given in the book, and has stubs for some others that are needed in order to define those. It's really old, as you can tell from the fact that it has written-in-Snap! HOFs included, etc. It also doesn't know how to handle non-vector pictures, because we didn't have first class costumes yet when I wrote it.

Were CAR and CDR problematic specifically because of their non-mnemonic names? If they were called FIRST OF and ALL BUT FIRST OF would you have gotten past that?

Maybe they should have named it LAMBDA-EXP? instead of LAMBDA?. Would that have helped?

Based on my experience teaching this stuff, I totally understand that many students have a hard time keeping straight the difference between metacircular code and underlying-Scheme code. For example, they have trouble explaining why it's okay to use IF in the definition of EVAL-IF. But I think all the same issues would come up in a block language version; the part I can't understand empathetically is why that experience got you upset with text languages rather than upset with levels of abstraction.

125

Sorry. I meant that most games are just walking, jumping, and swordfighting.

126

Don't be sorry; that's exactly what you wrote. I'm sorry for reading carelessly!

(Edit: Maybe because I wanted to tell that story!)

It's true that the navigation of 3D space in games is restricted to a narrow repertoire of actions, compared to real life, but doing turtle graphics in 3D is limited in similar ways, so it's still possible that one helps cope with the other.

127

I see.

128

Huh. I find it strange that you disagree on principle with abstracting away the computer, but you enjoy block programming and not text language programming. I mean, computers don't actually run on blocks. Even text languages are an abstraction over machine language, which is, you know, ones and zeros. And block languages are a further abstraction over text languages.

129

If you're interested, I have a 2.2.4 that contains all the code given in the book, and has stubs for some others that are needed in order to define those. It's really old, as you can tell from the fact that it has written-in-Snap*!* HOFs included, etc. It also doesn't know how to handle non-vector pictures, because we didn't have first class costumes yet when I wrote it.

No. Ouch. I had a look at that and closed it reflexively. It also messed with my login with the forums.
I'll have another look in a second

Were CAR and CDR problematic specifically because of their non-mnemonic names? If they were called FIRST OF and ALL BUT FIRST OF would you have gotten past that?

Weirdly, Yes.

Maybe they should have named it LAMBDA-EXP? instead of LAMBDA?. Would that have helped?

Weirdly, No.

the part I can't understand empathetically is why that experience got you upset with text languages rather than upset with levels of abstraction.

It's not the text that annoys me, it's the Abstraction.

Huh. I find it strange that you disagree on principle with abstracting away the computer, but you enjoy block programming and not text language programming. I mean, computers don't actually run on blocks. Even text languages are an abstraction over machine language, which is, you know, ones and zeros. And block languages are a further abstraction over text languages.

The only reason I like snap! is because it makes sense to me, I took CS in highschool and didn't do all that well, because in my highschool we learned C and Pascal and then jumped into Microsoft Access and Databases.

My frustration then was they were teaching us how to make pretty databases and not the underlying logic, what I wanted to do even then was use access to build the software and then strip out the access part and make it self reliant. ie; Compiling, but because we skimmed over that I didn't have the ability to explain it and the teachers didn't have the ability to listen. Unless I was the favourite student (Which, hahahah no)

Fast forward to TAFE/ Community College a few years later and my repeated frustration was most of the teachers were reading from the textbook and couldn't answer my questions, or wouldn't.

SNAP! makes sense in a way that nothing ever did, but Snap! is a means to an end. Always was, always will be.

My thesis is the difference layers of abstraction aren't actually as concrete as they appear to be, but me being me, I won't do anything until I can either prove or disprove it. Which is why I'm here, clogging up this thread.

130

Hmm. None of my business, really, but I can't help it, I'm a teacher: To me it seems that you're fighting yourself, and I'm not surprised that that makes you angry. You like Snap! because you understand it. What makes it understandable to you? Abstraction! Lots and lots of abstraction, not just because it's a block language, but because it takes its design inspiration from very high level languages: Smalltalk, Scheme, APL. Not, you know, C or C++. And that's not something unique to you; the reason abstraction is a big deal is precisely that it lets human beings understand computer programs. The computer itself doesn't care about the abstraction. It doesn't even know about the abstraction, which has disappeared by the time the computer is running the program.

But (this is where, like teachers everywhere, I arrogantly try to read your mind) you've convinced yourself that taking advantage of abstraction is cheating; that Real Programmers program in ones and zeros. And that your inability to do that is a defect in yourself. But nobody can do that any more. Yes, when I was a kid, programs were simple, and we could understand every detail in them. But those days, (1) user interfaces were all text; (2) only English-speakers were allowed to use computers; (3) there wasn't a worldwide network full of malicious users ranging from teenagers to agents of governments; (4) computing wasn't event-driven and massively parallel. Today, people write compilers in Lua or Ruby, not in C or even Python; that is, people use high level languages, where "high" means high in levels of abstraction.

Okay I'll stop ranting now...

131

Exact opposite. The analogy I use is the Rosetta stone. We're taught in school that there was one, except the truth was, we had hundreds of the things, we just didn't realise what they were until someone realised the other sides were not decorations and it was actually an ancient dictionary, but time and context had stolen that knowledge.

My issue with abstraction is that every language, high or low level insists on starting from scratch and that every other opposing brand name language is wrong and incompetent and that it's my way or the high way.

Which means that we get cross talk over artificial barriers and no-one dares venture outside their silos to actually check how much ground gets covered and recovered.

I was trying to find the MIT open press page again looking for the example text when I stumbled upon the 1986 lecture by Jay Sussman, the one where he looks like Matt Smith's doctor decades before Matt Smith chose the look lol and he makes a comment in that about "There are people who are suggesting graphical interfaces and I really can't see the point, with the images you're preventing the pass through"

And he was thinking in form of image compression and overhead.

He was already wrong.

The Unicode consortium wasn't officially around yet, and they wouldn't meet until 1987, but Joe Becker's 1984 thesis was the origins, so it was already being considered. Likewise, emoticons were first proposed in 1981, but it wasn't until 1992 when it was popularised in japan via a pager aimed at teenagers and called emoji that the idea started to grow.

It wasn't till 2007 when those two concepts finally emerged and the Unicode Consortium started publishing the Emoji standard that they would finally merge.

Snap/Scratch == [scratchblocks] (2 + 2) [/scratchblocks] == Scheme == (+ 2 2)

As you say, it's an abstraction, but the computer can't tell the difference between those two operations, because one is visual and the other is bracketed.

The computer does not care. We do... and that's the problem. That's the entire problem.

Wether it's Snap! or Scheme or C or Lua or Brand Name Here, the whitespace is human readable, but the computer does not give the slightest of crap.

I should be able to drop a .C file or a .scm or a .whatever file into snap and snap will read it. The idea that it's impossible is artificial. I can't prove it is the point, and what annoys me is that people DON'T GET IT.

Scratchblocks existence should be the clue. It's right there. It's RIGHT *********** THERE. but "Nah we can't do that due to "translation layers" or whatever excuse I'm given. They're wrong.

132

The fundamental problem is that no-one can know the syntax and semantics inside and out for every language, and implementing a transpiler for all of the is even more impossible. Plus, some languages, like Prolog or those fancy stack-based languages, work fundamentally differently than Snap!.

133

Are you sure that's what he meant? I'd need more context to know for sure, but what it sounds like to me is that code as blocks isn't data (list structure) the way Lisp "text" code is. ("Text" in quotes because it's been turned into lists, maybe nested, by the time it's evaluated. So the evaluator doesn't have to do any text parsing; that has already happened.)

I don't buy this. Why is that Snap! 's job? If every language IDE has to understand every other language's code, that's n2 large buggy programs that have to be maintained. Instead, every language should be able to translate to and from one chosen standard language. And given the extent to which everything happens in a browser window now, that language should be JavaScript. With that plan, you only have 2n large buggy programs to maintain.

More tomorrow... it's 3am now...

134

The 3D beetleblocks library is back in dev version

image
image897×870 144 KB

135

Can't wait to try it! ​​​​

136

Oh my word, WHY DOES THIS HAPPEN!? IT'S THERE, IT'S NOT, NOW IT'S THERE AGAIN!????????????

137

Oh my god, I love the 3D library, and please keep the FP view Jens, it's so neat.

I made this cool little script here, it generates a ball, and lets you walk around the area.
untitled script pic (11)
I highly encourage you try this script out, if you weren't already sold that the 3D library is cool, this might convince you.

138

Why I don't get the 3-dimensional library? (despite I'm on the newest of v10)

139

DEV VERSION, silly.

140

Should be here, it's where I found it.

141

Still cannot find it, even when I've clicked this link. :confused:

142

Go to the libraries.

143

I seriously hope the Snap! team think about trying to implement 3D in the near future. For now I guess we're stuck with 2D representations of 3D or raycasting or whatever.