Already we have only this option to split word by letter:
but feature would will be a possible to choose by how much letter, script would split.
Info
Continuing the discussion from Fast way to split every 'X' letters a text?:
yes, it would be great, although it can also be done quickly with a block
I seriously doubt that this'll become a primitive since it's been done before, and it's pretty fast. You need to remember, snap still needs to have room for people to figure things out.
I think this would be a great relabel option for the split block!
Yes, we wait for message from Snap! Developers
Splitting by a fixed number of letters is just the beginning of things people could ask for. Splitting by any of a set of delimiters (e.g., aeiou, to count syllables), splitting by a fixed number of words, ... If we were going to do anything like that, we'd just bite the bullet and implement regular expressions. But no, we're not doing that. Sounds like a great Snap! programming project.
What's wrong with regular expressions for Snap?
It's a piece of knowledge more useful than the programming itself and for a broader audience.
Also a great opportunity for exercises.
Well, wouldn't you want to know how it works? In case you use a programming language without the functions? It also would remove the satisfaction of figuring out how to split a string by multiple delimiters.
Oh, nothing! I love things like converting between REs and FSMs. Just, we're not adding that to the SPLIT block.
Really I don't understand why not . But it isn't my decision.
What we make primitive, apart from the things that have to be primitive (namely lambda and CALL), is a pedagogic decision. How useful is it to have this feature readily available, vs. how much do you learn by writing it yourself.
In the case of SPLIT, it originally just provided what the underlying Javascript function provides. Over time we've added to it because of specific needs in our curricula, but even some of those decisions feel iffy to me. For example,
is just
and you learn a lot by writing it that way. But when teaching "big data," teachers want to get right to the table manipulation issues without having to get over the hurdle of parsing a csv, which is hard to think about even though the actual code, once written, is remarkably simple.
Parsing regular expressions is a great learning experience, and we don't have any need for it in curriculum.
The image didn't show up...
Hmm, the problem was a stray "i" in the middle...
Fixed, thanks.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.