Snap! Team development discussion 2: Lost in New York!

There's this Scratch YouTube filter mentioned in the forum someplace, but it doesn't work when I try to use the URL as given. Is it no longer being used, or do you have to be coming from a Scratch forum page for it to work, or what? TIA.

bharvey wrote:

There's this Scratch YouTube filter mentioned in the forum someplace, but it doesn't work when I try to use the URL as given. Is it no longer being used, or do you have to be coming from a Scratch forum page for it to work, or what? TIA.

You should be able to link to the youtube page on the forums. And if you aren't on them, you can do
I think.

It's discussion for Snap!, not YouTube on Scratch

jokebookservice1 wrote:

https://scratch.mit.edu/discuss/youtube/VideoIdGoesHere/

Yeah. It works for me, too, but not for my colleagues. I'll have to look over their shoulders.

Update: Now it works for everyone. One of those inexplicable things…

I propose to change JOIN WORDS so that if one of its inputs is an empty word, the result doesn't end up with two consecutive spaces surrounding it – it's as if the input didn't exist at all.

I think this is clearly the right thing when the goal is to produce an English (or whatever language you speak natively) sentence. My question is, would this break anything?

(This came up while I was writing solutions for the sentence-generation mini-project in BJC.)

Note, this is just about JOIN WORDS, not JOIN, which should clearly be simple string concatenate.

@Brian But might that not hide bugs in your code? If you're generating empty strings somewhere, that's probably a mistake and you should not do that.

blob8108 wrote:

@Brian But might that not hide bugs in your code? If you're generating empty strings somewhere, that's probably a mistake and you should not do that.

In Logo, words and sentences are distinct data types. (Sentences are implemented as lists of words, but they display as text, not, you know, {“like”, “this”}.) In particular, it's possible to distinguish between an empty sentence (which is very common, e.g., as the base case of a recursive function) and an empty word (which is, as you say, generally a bug). On the other hand, so as not to drive users crazy, text selector functions such as FIRST and BUTFIRST have word-or-sentence as their domain and (for BUTFIRST) range. Given all that, there's no reason for SENTENCE (which is what JOIN WORDS is called in Logo) to treat empty words specially.

But in Snap!, there is only one text data type, the string. (I'm staring at that sentence I just wrote unhappily; it's misleading. We have words and lists, same as Logo, and Logo sentences are lists. The real difference is not in the types available, but in their external representations. In Logo, if you typewhat you get internally is a list of four words. But when you print it, you just see text, not a picture with a grey rounded rectangle with four little red ones inside.)

This is why it's so important to have sentence→list and list→sentence in the tools library. The Snap! idiom for Logo-like text programming is to convert the sentence to a list as soon as possible, so you can deal with it in a civilized way, and convert back to a text string just in time to display the final result.

Oh, the other relevant thing is that Logo SENTENCE isn't exactly JOIN WORDS. It takes any combination of words and sentences as inputs, turns the words into lists of length 1, and APPENDs the results. If you append an empty list to something, you just get the something, not the something plus an empty item. But, since an empty word is distinguishable from an empty sentence, you do get an empty item in the result for an empty word in an input.

But, in the text-string domain, we can't distinguish an empty word from an empty sentence. So I am proposing to give the user the benefit of the doubt and assume that an empty text string is meant to be an empty sentence, not an empty word.

This is really only an issue at the point in the curriculum where we are just dealing with sentences for the first time and haven't yet introduced the idea of representing them as lists. We are doing random sentence generation, where you start out with lists of nouns, verbs, adjectives, etc., and you write procedures like NOUN PHRASE:This all works great, without having to convert to lists, until the Take-It-Further problem that proposes allowing any number of adjectives in a noun phrase. This is a recursive function whose range is sentences (in the Logo sense of “a bunch of words”), and in the base case it returns an empty string, representing an empty sentence – but JOIN WORDS treats it as an empty word.

And, by the way, the extra space before “girl” is pretty subtle – it wouldn't help much as a debugging aid anyway!

Thank you, Brian, for that “noun phrase” example, it totally convinced me.

I love generating random English so much

Jonathan50 wrote:

I love generating random English so much

If we were less nice people we could make a sarcastic remark for which you've left yourself wide open!

bharvey wrote:

Jonathan50 wrote:

I love generating random English so much

If we were less nice people we could make a sarcastic remark for which you've left yourself wide open!

I have a bad habit of not putting periods on the end of my posts now. Is that what you are talking about?

Jonathan50 wrote:

I have a bad habit of not putting periods on the end of my posts now. Is that what you are talking about?

No, something along the lines of “yes, a lot of what you say is random.” But it would be mean and untrue so we would never say it…

bharvey wrote:

Jonathan50 wrote:

I have a bad habit of not putting periods on the end of my posts now. Is that what you are talking about?

No, something along the lines of “yes, a lot of what you say is random.” But it would be mean and untrue so we would never say it…

Not much of what you say could reasonably be randomly generated

Anyway, back to the topic, I made the change to Join Words.

I wonder if there are any languages that actually use two spaces in a row.

I know that Japanese doesn't use any spaces at all, which may be problematic. Does the JOIN WORDS block in the Japanese setting (is there one?) have spaces?

birdoftheday wrote:

I know that Japanese doesn't use any spaces at all, which may be problematic. Does the JOIN WORDS block in the Japanese setting (is there one?) have spaces?

I'm pretty certain the tool blocks have the same code in every (human) language.

bharvey wrote:

And, by the way, the extra space before “girl” is pretty subtle – it wouldn't help much as a debugging aid anyway!

That's true. I'm convinced too

Localising code is insanely difficult.

If JOIN WORDS tried to account for every human language, it would be huge and incomprehensible.

If it was an issue, there could be a new block called JOIN JAPANESE WORDS or something instead

birdoftheday wrote:

I wonder if there are any languages that actually use two spaces in a row.

Sometimes in English people will put two spaces after the end of a sentence, but I think that's pretty rare at this point.