no-sprites Snap! v2

that example has it as the name of a constant, which makes more sense as an attribute

no, the random choosing is just an arbitrary choice in reinterpreting the "flowchart"

Well, as the name of an object, a particular object, what would be an instance in a class/instance object system. When you call it a "constant" it sounds as if you're talking about how that object might appear in a program, e.g., if you say "3 is a constant" you mean that when the string "3" appears in a program (without the quotes) it represents a particular value, or alternatively in some languages you can say
const three = 3
but then it's THREE that you're calling a constant, not 3. Similarly, 1/4 could appear in the program as the value of a variable, or not, and either way it would still have its internal name.

Consider that the name could be computed, so for example you could determine that the name of 22/7 is "twenty-two sevenths".

note that i'm referring to "constant" in the mathematical sense, not the (in general) programming sense

exactly, but suppose you have an arbitrary list--how would a language know what to call it other than just "a list" or if it's in a variable, the name of the variable?

true, as my german number names and joecooldoo's number names projects demonstrate

I'm not saying objects should need names! I agree that for the most part it'd be silly to give lists names, although some lists might merit internal names, e.g., the list 14, 18, 23, 28, 34, 42, 50, 59, 66, 72, 79, 86, 96, 103, 110, 116, 125, 137, 145, 157, 168, 181, 191, 207, 215, 225, 231, 238, 242 might have the name Local stops on New York City 1 Train (Broadway-7 Avenue Local) subway.

then give me a reason costumes should need names

would you make a programming language that checks every list made in it and gives it a name pulled from the oeis?


I don't think costumes need names, but many costumes do come from named graphics files, and there's no reason not to remember that this one :alonzo: is called Alonzo. You could imagine wanting to offer users a costume search feature, for example.

exactly. if you want to give a list a name, put it in a variable like oeisa000053 or local_stops_on_New_York_City_1_Train_Broadway_7_Avenue_Local_subway

what would it search from, though? again, there's no wardrobe

so do scripts sometimes, and do scripts have names?

But there could be something like a folder of costumes that a user can import an image into. It would be like the snap costumes tab, only you can't select a current costume.

if i wanted that, i'd've kept the spriteBar around and repurposed (subpurposed? since it already has that as one of its purposes in Snap!) it for that (and sounds). but instead, i just completely removed it

[looks] [control]
[sound] [sensing]
[operators] [other]
[lists] [variables]

the code

Don't be like school administrators who think there's no other possibility than that some subject be required for all students or that it not be offered at all.

If lists were objects, which they would be in a fully OOP language such as Smalltalk, there would be no reason not to have a NAME field in those objects that might or might not be assigned a value. I would actually argue for it to be a field in the Object class, so you could always give an internal name to any object you felt like naming. So for example if you asked to print a costume, you might see #[a costume], for a program-generated costume, or you might see #[the costume Alonzo].

ok you're definitely starting to convince me

consider that Looks and Sound don't really play as big of a role, with no sprites (at least Looks doesn't, bringing its level of "importance" down to about the same as Sounds), whereas Control, Operators, Variables, and Lists are more "important"

I'm a teacher; I'm always right! ;~)

i was just working on Text-Based Snap and i found out how to fix this

Edit: should be fixed now

You should make it so you can drag variable monitors around the screen (if it's even an intended feature to have them shown)

But yet you're keeping the categories anyway, aren't you?