no-sprites Snap! v2

[warpedwartwars]

@bh

numerator = 1
denominator = 4
name = "one quarter"
printform = "1/4"

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

@bh

Am I really understanding you correctly to be saying that every time you start your version of Snap*!* the palette is arranged differently???

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

[bh]

@warpedwartwars

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

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".

[warpedwartwars]

@bh

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.

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

@bh

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.

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?

@bh

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

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

[bh]

@warpedwartwars

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?

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.

[warpedwartwars]

@bh

I'm not saying objects should need names!

then give me a reason costumes should need names

@bh

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.

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

[bh]

@warpedwartwars

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

No...

@bh

I'm not saying objects should need names! I agree that for the most part it'd be silly to give lists names

---

@warpedwartwars

then give me a reason costumes should need names

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 is called Alonzo. You could imagine wanting to offer users a costume search feature, for example.

[warpedwartwars]

@bh

No...

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

@bh

You could imagine wanting to offer users a costume search feature, for example.

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

@bh

but many costumes do come from named graphics files

so do scripts sometimes, and do scripts have names?

[ego-lay_atman-bay]

@warpedwartwars

there's no wardrobe

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.

[warpedwartwars]

@ego-lay_atman-bay

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

[mr_owlssssnap2]

@warpedwartwars

what other order for the categories would you suggest?

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

[mr_owlssssnap2]

@awdeni

What’s the guide?

the code

[bh]

@warpedwartwars

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

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].

[warpedwartwars]

@bh

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

[warpedwartwars]

@mr_owlssssnap2

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

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"

[bh]

@warpedwartwars

ok you're definitely starting to convince me

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

[warpedwartwars]

@warpedwartwars

when it's initializing, the instance of StageMorph isn't yet a child of IDE_Morph, so this.world() is null, so it can't check if it's in dev mode

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

Edit: should be fixed now

[coder_07]

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

[mr_owlssssnap2]

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

[warpedwartwars]

unless i make them libraries, like Scratch did with the Pen category in 3.0

[warpedwartwars]

you know what, that's a good idea. i'll try to remember to do that