Discuss Scratch

Gaza101
Scratcher
500+ posts

Link to Phosphorous

DaSpudLord wrote:

Gaza101 wrote:

DaSpudLord wrote:

Gaza101 wrote:

DaSpudLord wrote:

Gaza101 wrote:

DaSpudLord wrote:

No support, easy to workaround.
That argument I use for block ideas. This is not a block idea. Your attempted irony is invalid.
You lack full support for anything that has a workaround. I can't help but interpret this as slightly hypocritical.
Again, notice the difference between a block idea and this idea?
There is certainly a difference and I acknowledge that however they fall under the same category of creating unnecessary complexity. You're evidently a supporter of that.
I'm trying to figure out whether or not you're joking…
Take a wild guess . Anyway, whether you believe your suggestion to be hypocritical or not, there's still a point that's been made: you lack full support for anything that has a workaround. Even <true> and <false> blocks! There are core features of languages which you lack support for due to the existence of a workaround. Of course there's a workaround for most things but some features should not be kept from being added to the language just because there's an available workaround. That belief does create unnecessary complexity.
DaSpudLord
Scratcher
1000+ posts

Link to Phosphorous

Gaza101 wrote:

DaSpudLord wrote:

...
Take a wild guess . Anyway, whether you believe your suggestion to be hypocritical or not, there's still a point that's been made: you lack full support for anything that has a workaround. Even <true> and <false> blocks! There are core features of languages which you lack support for due to the existence of a workaround. Of course there's a workaround for most things but some features should not be kept from being added to the language just because there's an available workaround. That belief does create unnecessary complexity.
While I don't know much about other programming languages, as programming with Scratch is really just a hobby to me, I can say this- Those blocks are completely unnecessary in the Scratch environment. Maybe there's a reason those features exist in other programming languages, I don't know. Maybe they're actually useful in other languages. I don't know. But I know that we don't need them in Scratch-
if <true::operators> then//Because this will always be true, no matter what, then you don't need this if block.
...//Just place this outside of the if block and delete the if block.
end

if <false::operators> then//Because this will always be false, no matter what, then again, you don't need this.
...//Just delete this script; it's completely useless.
end

Last edited by DaSpudLord (Sept. 16, 2015 16:06:26)

Gaza101
Scratcher
500+ posts

Link to Phosphorous

DaSpudLord wrote:

if <true::operators> then//Because this will always be true, no matter what, then you don't need this if block.
...//Just place this outside of the if block and delete the if block.
end

if <false::operators> then//Because this will always be false, no matter what, then again, you don't need this.
...//Just delete this script; it's completely useless.
end
I understand your reasoning slightly more now however there definitely are applications for these blocks. A simple example includes the following.
define move (steps) steps, bounce? <bounce>
move (steps) steps
if <bounce :: custom> then
if on edge, bounce
end
When calling the block, we're forced to use the following method.
move (10) steps, bounce? <not <>> :: custom
move (10) steps, bounce? <> :: custom
Instead of…
move (10) steps, bounce? <true :: operators> :: custom
move (10) steps, bounce? <false :: operators> :: custom
It seems a little silly, doesn't it?
DaSpudLord
Scratcher
1000+ posts

Link to Phosphorous

Gaza101 wrote:

DaSpudLord wrote:

if <true::operators> then//Because this will always be true, no matter what, then you don't need this if block.
...//Just place this outside of the if block and delete the if block.
end

if <false::operators> then//Because this will always be false, no matter what, then again, you don't need this.
...//Just delete this script; it's completely useless.
end
I understand your reasoning slightly more now however there definitely are applications for these blocks. A simple example includes the following.
define move (steps) steps, bounce? <bounce>
move (steps) steps
if <bounce :: custom> then
if on edge, bounce
end
When calling the block, we're forced to use the following method.
move (10) steps, bounce? <not <>> :: custom
move (10) steps, bounce? <> :: custom
Instead of…
move (10) steps, bounce? <true :: operators> :: custom
move (10) steps, bounce? <false :: operators> :: custom
It seems a little silly, doesn't it?
Not really. In fact, for inputing true, it actually saves a step.
DrKat123
Scratcher
1000+ posts

Link to Phosphorous

support.
i don't have flash player on my other CPU.
and it would be great if scratch can run without flash
Gaza101
Scratcher
500+ posts

Link to Phosphorous

DaSpudLord wrote:

Gaza101 wrote:

DaSpudLord wrote:

if <true::operators> then//Because this will always be true, no matter what, then you don't need this if block.
...//Just place this outside of the if block and delete the if block.
end

if <false::operators> then//Because this will always be false, no matter what, then again, you don't need this.
...//Just delete this script; it's completely useless.
end
I understand your reasoning slightly more now however there definitely are applications for these blocks. A simple example includes the following.
define move (steps) steps, bounce? <bounce>
move (steps) steps
if <bounce :: custom> then
if on edge, bounce
end
When calling the block, we're forced to use the following method.
move (10) steps, bounce? <not <>> :: custom
move (10) steps, bounce? <> :: custom
Instead of…
move (10) steps, bounce? <true :: operators> :: custom
move (10) steps, bounce? <false :: operators> :: custom
It seems a little silly, doesn't it?
Not really. In fact, for inputing true, it actually saves a step.
Well, since you imply that Scratch is the only language you know, I can empathise with you regarding why you're unaware of the usefulness of these functions and values. Remember that you're not the only person reading your code and that the values of true and false make the code easier to understand. Another thing, boolean values are conceptually similar to strings and numerical values in the world of programming. Surely we should be able to input them as values rather than results; what if the ability to manually enter strings and numbers wasn't implemented and we were forced to use costume names and IDs? It's the same principle.
Firedrake969
Scratcher
1000+ posts

Link to Phosphorous

This is offtopic, and no support again.
DaSpudLord
Scratcher
1000+ posts

Link to Phosphorous

I am going to BUMP this topic. Why? Because.

BUMP
-Cherri-
Scratcher
100+ posts

Link to Phosphorous

No support, most projects don't work very well on phosphorus, and if they really really want to see the project, they'll probraly find it themselves.
:geek:

Last edited by -Cherri- (Sept. 29, 2015 22:33:14)

14917
Scratcher
8 posts

Link to Phosphorous

when green flag clicked
broadcast [I'm just going to leave slowly]


when I receive [I'm just going to leave slowly]
forever

move (-1) steps
wait (0.1) secs
end
DaSpudLord
Scratcher
1000+ posts

Link to Phosphorous

14917 wrote:

when green flag clicked
broadcast [I'm just going to leave slowly]


when I receive [I'm just going to leave slowly]
forever

move (-1) steps
wait (0.1) secs
end
Please don't blockspam. Thanks!
gamebeater187
Scratcher
1000+ posts

Link to Phosphorous

75% as per above
Leadrien2366
Scratcher
100+ posts

Link to Phosphorous

Support.

Last edited by Leadrien2366 (Nov. 14, 2015 22:48:11)

-Cherri-
Scratcher
100+ posts

Link to Phosphorous

Can people stop necroposting? -_-
KingOfAwesome58219
Scratcher
1000+ posts

Link to Phosphorous

I think it'd be cool if it was built in, but I'm no coder so I don't know how much work that'd be…
gamebeater187
Scratcher
1000+ posts

Link to Phosphorous

-Cherri- wrote:

Can people stop necroposting? -_-
I was the one who necroposted but you can not necropost in the Suggestions Forums.
DaSpudLord
Scratcher
1000+ posts

Link to Phosphorous

-Cherri- wrote:

Can people stop necroposting? -_-
It's not necroposting if the suggestion is still relevant.
gatzke
Scratcher
100+ posts

Link to Phosphorous

AFAIK, Phosphorus is on github. The scratch team could grab a copy of the code and run it on their own site if they wanted, assuming the license permits (MIT license, I think it is free to use and free to take, modify, close source and sell?).

I agree, the ST should offer a phosphorus variant to play as a Beta option when the device attempting to access won't run flash.

Plus, I had not idea that their security is so bad that unshared projects. That is a major flaw they really need to correct. Crazy! I just checked some of mine and it is still an open issue.
mobluse
Scratcher
100+ posts

Link to Phosphorous

DaSpudLord wrote:

I was thinking that when you view a project, if you don't have flash installed, underneath of the “install flash” message there should be a link to run the project in Phosphorous. That way I can easily launch a project from my tablet despite not having flash installed.
Support!

I often want to run Scratch-projects on Raspberry Pi in its default browser (Epiphany) and that doesn't have Flash. There could be a warning though that the project may not work as it normally does in Flash.

In non-shared projects one can't even view the project page if one doesn't have Flash – and this should be fixed by ST. In shared projects the project-owner can make a link to Phosphorus, but many users will forget to do this.
edward789121
Scratcher
500+ posts

Link to Phosphorous

Support!€:

Powered by DjangoBB