Feature: Block(s) for List Slicing

[cycomachead]

Normally, I'd suggest these would be fine blocks to build yourself (or for tools), however, the performance implications of a wrapper around a JS would be really nice, especially as students work with larger projects.

[jmoenig]

again, can you share a project or a list that doesn't perform right (enough) by simply warping the copier?

[cycomachead]

Same project before is where I noticed it. Chrome (on a good machine) can take a few seconds (usually ~5) to popular 15k items, and the block was warped. http://snap.berkeley.edu/snapsource/snap.html#present:Username=cycomachead&ProjectName=List%20Error%20Tests

[brianharvey]

I shaved a second off this time by using linked-list reporters instead of the dynamic array blocks, except that my answer is in reverse order. :-) This argues for something I want anyway: mutators for pairs.

As for the original suggestion, I fear that this is only one of a trillion things that native JS can do faster than interpreted code. If we put this in, we'll end up putting the entire JS library into Snap!. (See, Jens, I'm just like you about this most of the time.) Here's the part where I'm not like Jens: I still want a call-JS primitive block.

[jmoenig]

Yeah.

I also shaved off a full second by using primitive blocks instead of the FOR block from the tools library:

[cycomachead]

I guess the improvement isn't bad, but also I still feel like this is something that is slower than it should be. I definitely see where using primitives is good in this case, but it's also a little bothersome of common custom blocks have a relatively large (~20%) consequence in speed since they're what students are expected to use.

I used 5s because the number varied widely between machines / browsers. I think I tried 4-5 combos and the average was 5s but some cases were as fast as 3s and as slow as 12s. That's also interesting because cross-browser console differences are much less dramatic.

As for the original suggestion, I fear that this is only one of a trillion things that native JS can do faster than interpreted code. If we put this in, we'll end up putting the entire JS library into Snap!. (See, Jens, I'm just like you about this most of the time.) Here's the part where I'm not like Jens: I still want a call-JS primitive block.

I that sense, I agree a general JS block is really a better solution than having to update Snap! every time there's a use case for a primitive, or primitive like block. (I also wasn't advocating, to be clear, that we add this block as a primitive.)

[brianharvey]

(I also wasn't advocating, to be clear, that we add this block as a primitive.)

So is this just the call-JS block suggestion? If so I'm going to rename it.

[cycomachead]

So is this just the call-JS block suggestion? If so I'm going to rename it.

Yeah, I think so. It's a much better approach. :)

[The other related suggestion is to be able to 'import' primitives which are hidden by default. Though, I think this is more messy, but still potentially useful.]

[jmoenig]

I'm sooooo tired about these discussions, and soooo angry!

(... huge rant taken out here ... )

This problem will be solved once and for all. I'm working on it right now.

[jmoenig]

I've had the half-finished code for this lying around somewhere for a couple of years:

I've just now completed it. It adds first-class JavaScript functions to Snap. It solves all of your problems. Ever. I hate it. It's never about what you can do, but what you decide not to.

I'm going to release this now.

[brianharvey]

Aargh, I don't want JS eval, which is what that block is. That just encourages people to write their entire program in JS. I want JS apply, like this: Instead of encouraging people to write their whole program in JS, this encourages people to write the structure of the program in Snap!, and use JS one function at a time when it gives a real advantage. (Note also that the conversion of the list to array form is done automatically by the call-JS block, and also the conversion back to a Snap! list. This makes it a feature usable by users, not just by Snap!-innards experts.)

Please don't do things you hate.

[cycomachead]

Aargh, I don't want JS eval, which is what that block is. That just encourages people to write their entire program in JS. I want JS apply, like this:

There's use cases for both. eval is very useful for implementing things like label or like a real XHR block. I do see how this could lead to some poor results when used improperly, but this block could also just be moved to dev mode, if we wanted. In dev mode, you could use it to be other blocks, then go and turn dev mode off when things are done and most users would never be encouraged to use the block.

[brianharvey]

most users would never be encouraged to use the block.

You must not know any teenagers.

[cycomachead]

You must not know any teenagers.

That's not the point, and not what I was saying... Certainly, even in dev mode, there are many people who will play with an experiment with such block (some to their own peril), but I don't think most people would use Snap! to write their own JS for most of the program, otherwise they probably wouldn't use Snap! in the first place, and if most people found JS that easy well... Snap! wouldn't have as much of a use case.

At the same time, this block isn't tons different than what could be done in the console...it really just allows things to more easily be done within snap and to be shareable. (Shareable-ish since we can't share libraries.)

[studej]

I was thinking that Snap! is focused on teaching programming, not on teaching JS. I don't like that JavaScript block. Why it isn't at least hidden in dev mode? :( In fact I feel at a disadvantage compared to others, beacuse I don't know JS and I can't program such a fast blocks or functionalities. Also, and this is the worst consenquence, I'm not able to understand projects which will use this block...

Do you want to say me that I can program label block? Really? Let's see what I have to do now: I have to find code here on GitHub, then I have to rewrite it by myself (beacuse it is shown on screenshot) and then I can only hope that I did not make any mistake. I don't know what am I creating, I don't know where can be any mistake, I don't know how to fix it and I don't know if it is dangerous (is it possible to write dangerous code with JavaScript block?).

I don't really understand why this block exists. I really do not. As a user = I hate it.

[brianharvey]

Jens and I both hate it too (although for somewhat different reasons). Jens put it in as a desperate effort to get everyone else, but mainly Berkeley students, to shut up and stop harassing him with tiny issues. I don't think you should take it as a permanent shift in the philosophy of Snap! and its relationship to its users. We're going to work this out eventually.

[studej]

Well at least its good for Math.pow(x, y) function. This, I think, is good example of simple usage.

[cycomachead]

Closing this. :)