An epic fail by me

I'm new to JS, and I decided to try to make an index of () in [list] block using it. It took me a total of around 3 hours to figure it out.
Today, I found out that there's an asArray() method that would cause the list to work properly in a JS function (because apparently the lists are objects). That was absolutely fun for me to find out! (No it wasn't).
Anyways, here's my way-too-complicated block.
Link to forum post
Link to project

A beginners javascript script script pic

why not use Snap!?

I know that I can use the asArray method. I said so in my OP.

I've already made an index reporter using blocks. I just wanted to play with JS.

I don't think Jens intended to tell you about the asArray method; I think he was showing you a shorter way to do it.

Any obviously-useful utility function has probably already been written in JS. :~)

We deliberately don't provide every possible JS method as a Snap! primitive, because after all the purpose of the language is to help people learn to program, and so it's good to let people invent these things on their own (which is what you did, @codeman1044).

But sometimes you have to weigh one principle against another, which is what we did by introducing MAP etc. as primitives. They're easy-ish to write in Snap!, but when dealing with huge amounts of data, either from a database on the net or from the pixels of a picture, they're too slow if not primitives. We're working on inventing a way to have our cake and eat it too, about this.

a potential problem when using JS like this is that it might mutate the list and change it from being a linked list internally to becoming an arrayed one even though you're not intending to mutate it. Therefore, yes, I'm proposing to obsess less about JS.

If I understand the differences between linked lists and arrays right, then I think I can say that I've already encountered this and that my solution was just to use some operators to manipulate it back and forth.
(I probably don't know what I'm talking about :stuck_out_tongue:)

If what you're trying to do is learn, and if you're using small lists, you don't have to worry about conversion between representations. But if you're trying to write something useful, and/or you have a lot of data in the list, then you really don't want to keep converting back and forth; your program will run very slowly.

For instance, here's a simple implementation of MAP:


This is a thing of beauty! But the ALL BUT FIRST OF converts the list to linked form. So the real implementation is more like this:

(The gray IS __ LINKED? block doesn't really exist in Snap!; it's a JS one-liner. That's the only thing you'd really have to do in JS.) The actual MAP primitive is written in JS for speed, and it's a little more complicated because you have to know how to store intermediate results in a computation that might be interrupted by the browser running another window in midstream, but it basically uses this algorithm. This one is not a thing of beauty, but it uses functional list primitives if the input list is linked, and imperative primitives if it's an array internally.

Why is this so complicated? Well, because Snap! users aren't supposed to worry about it; we take a lot of trouble under the hood so that functional programs run fast, and so do imperative programs. It's only if you switch back and forth that things unexpectedly and dramatically slow down.

So, the moral isn't for you to dive into this code; as Jens says, what you want to learn is computer science, not the gory details under the hood.

Actually, the reason I want to learn JS is not only because I want to work with it but also because, coincidentally, I want to get a better grasp of the "gory details under the hood" for things.
I'm not just using Snap*!* to learn JS, so sooner or later I'll probably have to work with those details.
I'm not saying I don't appreciate the fact that you've made the code cleaner for users. I just want to be able to work with JS no matter what I need to do with it, so stuff like this is what I'm starting with because I can work in a familiar environment (the blocks) while learning things with JS and being able to experiment with isolated code easier. If that means that I slow down my program, then that's how I'll learn. Optimization is something that I had to learn separately from block coding with Scratch, and I assume I'll have to do the same with JS.

Do you mean you want to learn more about the evaluator, or more about the user interface, or both? For the evaluator, stop reading code and start reading John Allen, Anatomy of Lisp. It's old and out of print, but a great starting place, so try the nearest college library. As for the user interface, ask Jens, I guess... not my department at all. (Not the implementation, I mean, I've designed parts of the user-visible appearance.)