Zro716 wrote:

DaSpudLord wrote:

…a split block does have a workaround.

split [hello world] by [ ] into [list v]
/* have to hack the custom block procDef and call blocks to be able ::grey
   to specify an available list without having to type it in every time */ ::grey
define split (string) by (splitter) into (list)
delete (all v) of (list) // have to hack the list blocks
set [split_substr v] to []
set [split_i v] to [0]
if <(splitter) = []> then // empty splitter means split by each letter
  repeat (length of (string))
    change [split_i v] by (1)
    add (letter (split_i) of (string)) to (list)
  end
else
  repeat (length of (string))
    change [split_i v] by (1)
    set [split_chr v] to (letter (split_i) of (string))
    if <(split_chr) = (splitter)> then
      add (split_substr) to (list)
      set [split_substr v] to []
    else
      set [split_substr v] to (join (split_substr)(split_chr))
   end
  end
  if <not <(split_substr) = []>> then // leave no substring unadded
    add (split_substr) to (list)
  end
end

DaSpudLord wrote:

Zro716 wrote:

you don't have enough experience to appreciate the benefit of the split function.

No, but I have enough wisdom to understand the benefit of not having the split function-

It could be confusing to inexperienced scratchers. Considering Scratch revolves around new scratchers, this is a stronger reason than some might realize.

Forcing inexperienced scratchers to come up with the workaround allows for a learning experience. It offers a chance to put their skills to the test in a problem-solving application. If they fail, then they can look up the answer and figure out how it works, so that next time they might succeed. Scratch revolves around teaching scratchers how to program and, more importantly, how to make stuff for themselves instead of being handed workarounds.

Again, this is also a learning experience for skilled Scratchers. Without the block, you guys are forced to create the workaround. Whenever the workaround doesn't work they way you need it to for your project, that's another learning experience as you guys must test your brains to make the workaround work for you instead of having a workaround that doesn't work.

var run = function(loops,string) {
    var start = Date.now();
    while (loops--) string.split(' ');
    var end = Date.now();
    return (end - start) / 1000;
}
console.log(run(10000,'Lorem ipsum dolor sit amet, quando inimicus senserit ne per. Vim cu accusata repudiare, in mel ullum') + " seconds");

Tired of programming being too simple? Then leave. Scratch is not about the skilled scratchers. It is not about you and me. It is for the unskilled scratchers to learn. Our purpose on this site is to create projects to act as guides that teach others how to do stuff that they might not know how to do. Stop trying to take Scratch and make it for you and the other skilled Scratchers. Instead, start thinking about the little guys for once.

While visiting an after-school center, I met a student who was creating an interactive game in Scratch. He didn’t know how to keep score in the game, and asked me for help. I showed him how to create a variable in Scratch, and he immediately saw how he could use a variable for keeping score. He jumped up and shook my hand, saying “Thank you, thank you, thank you.” I wondered how many eighth grade algebra teachers get thanked by their students for teaching them about variables? (Resnick, 21)

meowmoo wrote:

Support, I saw the workaround code and it's longer than I feel is a good workaround.

Zro716 wrote:

DaSpudLord wrote:

Zro716 wrote:

you don't have enough experience to appreciate the benefit of the split function.

No, but I have enough wisdom to understand the benefit of not having the split function-

Please go back to Programming 101 or prepare for a rebuttal of epic proportions, wise guy.

It could be confusing to inexperienced scratchers. Considering Scratch revolves around new scratchers, this is a stronger reason than some might realize.

That's not a good enough reason as you might think because you're basing it too much on what you think happens (could, but would it really?). It can be temporarily confusing, but there is difference between that and truly confusing, depending on how prodigious you are. The split function does not come even close to being that confusing, mind you. What merits all of the “confusing” blocks is a need for a higher ceiling, a means of providing both newbies and us higher-up programmers the right tools we need to bring our big ideas to fruition. If something isn't well understood, we can always improve the documentation on the wiki and in the editor's help system, and provide plenty of guides and tutorials on the main site and the forums. There should not be any excuse to not understand something that is thoroughly explained everywhere.

Consider looking back to the days when Scratch did not have trig functions, when lists were nonexistent, and when us advanced programmers had to roll out extremely large scripts due to the lack of instantaneous execution prior to 2.0. Sure all of these had workarounds with varying complexity, but they existed. It didn't matter so much. When the ST added trig and lists, they had a high ceiling in mind because like many programming languages, they are essential for building great projects, and flourishing creativity followed. This here is concrete proof that they value the needs of everyone, not just the little ones.

If Scratch were focused on just the newbies, like you say, they would not learn a thing or two about practical programming skills and paradigms. Practical programming is a concept in which you are tasked to solve a real problem using a programming language. Practical solutions need practical means of making them. Practical means are formal and therefore advanced in some way, but learning them is important, especially to the newbies, who came here because they showed interest in programming. For a first programming language, Scratch has to make a big enough impression and continue impressing the user as they discover more key features, such as trig, variables, lists, and custom blocks and cloning. Eventually they will become adept enough at Scratch to move on to more formal languages. They might even come back to recommend features to smooth the transition from Scratch to real programming, based on how well they transitioned. It's a mutual relationship to fit the needs of seasoned programmers while giving more opportunity to the beginners.

Forcing inexperienced scratchers to come up with the workaround allows for a learning experience. It offers a chance to put their skills to the test in a problem-solving application. If they fail, then they can look up the answer and figure out how it works, so that next time they might succeed. Scratch revolves around teaching scratchers how to program and, more importantly, how to make stuff for themselves instead of being handed workarounds.

Forcing them? “That's not how we roll.” Users are free to learn at their own pace and collaborate with one another in an open source community. There is no force except that of inspiration which already guides me and the rest of the community. You are right that Scratch is mostly about teaching basic computer programming skills, but it's not just that. According to the About page, “Scratch helps young people learn to think creatively, reason systematically, and work collaboratively — essential skills for life in the 21st century”. Whether you're going for a computer science degree or just fiddling with Scratch as a hobby, developing creative thinking skills is important for advancing in today's society.

I don't like how you seem to shame others for sharing their workarounds. Remember that Scratch is hugely active in the collaboration and remixing sect. When was the last time you had to build a project without any help? I can admit that despite the huge effort put into my projects I couldn't have done a lot of things alone. I'm grateful that others are around to provide their skills for the betterment of all, and you should too.

There are times when workarounds are sufficient and when they are not. There is a very relevant article that compares the skills of two kinds of programmers, analogous to how the engineer creates the tools for the carpenter. The article goes into depth to say that both kinds of skill sets, of the hardcore math-to-code programmers and of the software developers that put the code to use, are equally necessary to solve a problem. Just because you are as skilled with creating the workaround does not mean you will be any more productive than someone that uses the function built into their software. Skill is different than productivity in that you know how to do something versus you know how to do something and you can do it more efficiently.

Again, this is also a learning experience for skilled Scratchers. Without the block, you guys are forced to create the workaround. Whenever the workaround doesn't work they way you need it to for your project, that's another learning experience as you guys must test your brains to make the workaround work for you instead of having a workaround that doesn't work.

While I love how you address our ability to cope with the lack of practical blocks as if we like it, I firmly and bitterly disagree. We learn nothing by creating and using the same workaround over and over. You may remember it more strongly, but the learning doesn't continue, it becomes fatiguing to have to recreate it. And I'm aware I can always backpack a script or save it to my computer, but this convenience is not always standardized to my design goals per project, nor do I always work online either. I have suggested a means of saving a single script to file before and I do hope it is considered.

I counted how many unique projects, shared, unshared, and saved on my computer, that use a workaround for the split function: More than 40 out of 300. Each one of them uses the split function for a different purpose,but each implementation has the same limited performance and versatility, making it more of a grind than a learning experience. Basically, you can't get a faster generic split function than this, and even that requires a few drawbacks such as hacking the JSON code, and it's limited to only one-character delimiters. For my quadcore Acer laptop with 1.6 GHz and Flash 18.0, at 100 letters and fully optimized split scripts, 10000 splits takes 5.913 seconds to process in Scratch; in JavaScript, the same number of splits takes a mere 0.013 seconds, or about 0.22% of Scratch's speed (a holy moly whopping ~4550% faster (edit: a magnitude off)). Source code I used:

var run = function(loops,string) {
    var start = Date.now();
    while (loops--) string.split(' ');
    var end = Date.now();
    return (end - start) / 1000;
}
console.log(run(10000,'Lorem ipsum dolor sit amet, quando inimicus senserit ne per. Vim cu accusata repudiare, in mel ullum') + " seconds");

Put that into perspective, a native split block in Scratch would hasten heavy operations in encryption/decryption, cloud, highscore, multiplayer, chatbot input analysis and response, data structuring, pseudo collections… things that us advanced users would find more useful than anyone else and giving more beginners the opportunity to try out more complex things. No need to shun away the idea just because the workaround is “real learning”. It's knowledge of how to use it that counts, not some made-up “do it the hard way first” principle.

Tired of programming being too simple? Then leave. Scratch is not about the skilled scratchers. It is not about you and me. It is for the unskilled scratchers to learn. Our purpose on this site is to create projects to act as guides that teach others how to do stuff that they might not know how to do. Stop trying to take Scratch and make it for you and the other skilled Scratchers. Instead, start thinking about the little guys for once.

I can't believe you can just pull this abominable chunk of thoughts you call an argument like that. First of all, I can't even fathom why you would suggest leaving just because one finds programming to be “too simple”. I have been struggling everyday for 3 years trying to come up with new ideas and methods in Scratch, but it doesn't deter me like you think it would. I love a good challenge but I'm not afraid to ask for help either. Along the way I've built myself a reputation as a talented Scratcher and source for help to many.
Second, how can you even form an obvious lie that Scratch is only for the unskilled? Scratch is for everyone, skilled and unskilled, young and old, male and female, straight and gay, big and small, able and disabled.
Third, you shouldn't label our one true purpose like you know it. According to the About page, our purpose is to “learn to think creatively, reason systematically, and work collaboratively”. We go our own routes in programming, whether it's to provide tutorials for students and aspirants, to discover new techniques or to further our understanding of the universe. I love what I do on Scratch, just being myself, and no one can tell me otherwise.
Lastly, you seem to think that raising the ceiling == raising the floor, which is completely fallacious. You're overthrowing this whole topic which started as a split function into, what, thinking the “little guys” will get a little confused? Let me assure you they won't flip their tables if they don't understand something at first. Consider reading one of the many research papers about Scratch, “Sowing the Seeds For a More Creative Society” by Mitch Resnick, who described the moment a boy learned how to create and use a variable:

While visiting an after-school center, I met a student who was creating an interactive game in Scratch. He didn’t know how to keep score in the game, and asked me for help. I showed him how to create a variable in Scratch, and he immediately saw how he could use a variable for keeping score. He jumped up and shook my hand, saying “Thank you, thank you, thank you.” I wondered how many eighth grade algebra teachers get thanked by their students for teaching them about variables? (Resnick, 21)

You see, kids are not as volatile and scared of new things as you think they are. They can handle a little confusion, and after learning they'll feel ecstatic and eager to learn more. This is the true magic of Scratch as it was designed for. Embrace it.

Listen to yourself. Basically you want us “advanced” users to leave the kids to their tonka toy trucks and pretty pink unicorns because you're afraid of what will happen if we introduce something as simple as a split function. That's counter-intuitive to your argument saying that “Scratch is for learning”. If you don't want kids to learn new things, then just say so. Otherwise, there is no good reason to hold something back from them that is essential to learn for computer science. This is coming from someone experienced with multiple real programming languages to say without hesitation that your “beneficial” reasons for not having the split function are complete and utter nonsense. I hope this was worth the 8-9 hours of writing because you roused me enough to do this. Now I must sleep.

*drops mic*

Zro716 wrote:

DaSpudLord wrote:

Zro716 wrote:

you don't have enough experience to appreciate the benefit of the split function.

No, but I have enough wisdom to understand the benefit of not having the split function-

Please go back to Programming 101 or prepare for a rebuttal of epic proportions, wise guy.

...//Extremely long 8-9 hour essay that probably deserves some kind of medal snip

Zro716 wrote:

I don't like how you seem to shame others for sharing their workarounds.

Zro716 wrote:

…

DaSpudLord wrote:

Also, one more thing- (and yes, while this is not a definite reason to no support a suggestion, this is something I want to point out.)

I see 100 suggestions daily- all kinds of stuff. Almost none of them get accepted. What makes you think this one is special? I'm just saying I highly doubt this will get implemented.

gamer270 wrote:

I want a block like this to be added like

(split (scratch) at character(character to split at))

you could put it inside a list item select block like this

(item (1 v) of (split (scratch) at character(character to split at))) 

If

(character to split at)

was “a” the two items in the list would be “scr” and “tch”

Superdoggy wrote:

In general Scratch doesn't seem to have much support for string manipulation. On one hand I definitely think that it needs more string manipulation blocks (substring, split, find, insert, remove, and definitely a way to tell between lowercase and uppercase (perhaps a strict comparer)) so I'd be inclined to support anything with string manipulation.

However, on the other hand, I'm not sure if I would've ended up learning advanced string manipulation if it was always done for me. And string manipulation can get pretty tricky, so it does kinda need to be learned at some point or another anyway.

Eh, I'm gonna support this one. I think. Mostly. Kinda. Admittedly using workarounds is a very slow alternative so some string manipulation would be nice, but again, not sure.

[split v] the letter [] from []  :: operators
[insert v] the letter [] from [] :: operators
[remove v] the letter [] from [] :: operators
[find v] the letter [] from [] :: operators

split [string] at [i] into [list v] :: lists

gamer270 wrote:

I want a block like this to be added like

(split (scratch) at character(character to split at))

you could put it inside a list item select block like this

(item (1 v) of (split (scratch) at character(character to split at))) 

If

(character to split at)

was “a” the two items in the list would be “scr” and “tch”

1234abcdcba4321 wrote:

no support, already workaroundable.

TheAwesomeMaster wrote:

1234abcdcba4321 wrote:

no support, already workaroundable.