WA
William Adams
Tue, Apr 16, 2019 3:44 PM
Has anyone come across this before?
https://www.floodeditor.com
I'm flabbergasted that it doesn't seem to have made more of a splash.
William
Has anyone come across this before?
https://www.floodeditor.com
I'm flabbergasted that it doesn't seem to have made more of a splash.
William
RD
Revar Desmera
Tue, Apr 16, 2019 4:50 PM
Hadn't seen this one before. Looks nice, but it has the standard critical flaw of a visual programming system. Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity. The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.
There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting! I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!" So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous. But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.
To specify the number 20, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.
The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc. You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen. Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add 9*7. In a visual paradigm, I have to select and place three nodes. Something like 4 clicks, scrolling, and a drag per node. Then two more clicks and drags to connect the nodes.
Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.
Hadn't seen this one before. Looks nice, but it has the standard critical flaw of a visual programming system. Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity. The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.
There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting! I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!" So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous. But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.
To specify the number `20`, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.
The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc. You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen. Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add `9*7`. In a visual paradigm, I have to select and place three nodes. Something like 4 clicks, scrolling, and a drag per node. Then two more clicks and drags to connect the nodes.
Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.
- Revar
> On Apr 16, 2019, at 8:44 AM, William Adams <will.adams@frycomm.com> wrote:
>
> Has anyone come across this before?
>
> https://www.floodeditor.com <https://www.floodeditor.com/>
>
> I'm flabbergasted that it doesn't seem to have made more of a splash.
>
> William
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
DM
Doug Moen
Tue, Apr 16, 2019 5:02 PM
It looks very slick. I like that you can tweak any numeric literal using a slider and get dynamic feedback. Or click on the node for a solid and it is highlit.
The node based visual programming UI seems clumsy, and the set of shape types and shape operations is pretty limited. I don't think I could be productive using it, in its current state. I get that it isn't designed for me, but even for beginners, I think the UI could be better designed. It is marked "beta" of course.
I was thinking about providing the author with more detailed feedback, but the last code change was June 2015, and there's only one contributor, so it looks moribund.
I will still be pointing novices at TinkerCAD first, and OpenSCAD if they want to write programs.
On Tue, Apr 16, 2019, at 11:45 AM, William Adams wrote:
It looks very slick. I like that you can tweak any numeric literal using a slider and get dynamic feedback. Or click on the node for a solid and it is highlit.
The node based visual programming UI seems clumsy, and the set of shape types and shape operations is pretty limited. I don't think I could be productive using it, in its current state. I get that it isn't designed for me, but even for beginners, I think the UI could be better designed. It is marked "beta" of course.
I was thinking about providing the author with more detailed feedback, but the last code change was June 2015, and there's only one contributor, so it looks moribund.
I will still be pointing novices at TinkerCAD first, and OpenSCAD if they want to write programs.
On Tue, Apr 16, 2019, at 11:45 AM, William Adams wrote:
> Has anyone come across this before?
>
> https://www.floodeditor.com
>
> I'm flabbergasted that it doesn't seem to have made more of a splash.
>
> William
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
KT
Kevin Toppenberg
Tue, Apr 16, 2019 5:03 PM
I agree with what you have said. But it would also be cool if it had the
ability to use either the graphical mode OR a text mode. Some of the
graphics engines have this visual interface -- but one can also use
traditional programming methods.
Kevin
On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera revarbat@gmail.com wrote:
Hadn't seen this one before. Looks nice, but it has the standard critical
flaw of a visual programming system. Visual programming is nice for small
projects, but becomes very unwieldy when you start adding complexity. The
density of code/information of a visual language is necessarily far lower
than a text language, due to connectors, block/window titles, etc.
There is a trap here, that seems to come up from time to time. Someone
will look at text programming languages and say "This is cryptic and not
self documenting! I don't know what the inputs or outputs are, without
delving into arcane documentation! We can do better!" So they go and break
everything down into small pieces that they can represent in small GUI
windows where all the inputs and outputs are visually represented and
obvious. You can hover over them to see pop-up windows explaining the them.
Connections between parts are obvious. It's like making flow charts to
document your program, but they actually run. The wonder of this visual
paradigm is obvious with rather small demos that look gorgeous. But no
complex demos. Because that's all that'll fit on the screen. Every bit of
it takes up massive amounts of screen real-estate. If complex demos exist,
you have to zoom out to illegibility, then scroll about, then zoom back in.
To specify the number 20, takes up 300x45 pixels, including the
connector linking it to the next node. The actual number itself is about
15x15 pixels on the screen, including spacing around the digits. That is a
density difference factor of 60 times. Let's not even get into nodes for
add and subtract.
The other big flaw of visual programming is that it forces you to move
between your keyboard and mouse constantly. Instead of continuous typing of
code, you keep having to select and place new nodes, add connectors, etc.
You have to target and select various buttons and pay a lot of attention to
positioning your mouse on the screen. Pure text programming, on the other
hand, can be done blindfolded. Or, at the least, with far less spatial
attention required. With three keystrokes I can add 9*7. In a visual
paradigm, I have to select and place three nodes. Something like 4 clicks,
scrolling, and a drag per node. Then two more clicks and drags to connect
the nodes.
Not to bash Flood, because it does look nice. But, like pretty much all
visual languages, it just isn't very practical for anything non-trivial.
On Apr 16, 2019, at 8:44 AM, William Adams will.adams@frycomm.com wrote:
Has anyone come across this before?
https://www.floodeditor.com
I'm flabbergasted that it doesn't seem to have made more of a splash.
William
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
I agree with what you have said. But it would also be cool if it had the
ability to use either the graphical mode OR a text mode. Some of the
graphics engines have this visual interface -- but one can also use
traditional programming methods.
Kevin
On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <revarbat@gmail.com> wrote:
> Hadn't seen this one before. Looks nice, but it has the standard critical
> flaw of a visual programming system. Visual programming is nice for small
> projects, but becomes very unwieldy when you start adding complexity. The
> density of code/information of a visual language is necessarily far lower
> than a text language, due to connectors, block/window titles, etc.
>
> There is a trap here, that seems to come up from time to time. Someone
> will look at text programming languages and say "This is cryptic and not
> self documenting! I don't know what the inputs or outputs are, without
> delving into arcane documentation! We can do better!" So they go and break
> everything down into small pieces that they can represent in small GUI
> windows where all the inputs and outputs are visually represented and
> obvious. You can hover over them to see pop-up windows explaining the them.
> Connections between parts are obvious. It's like making flow charts to
> document your program, but they actually run. The wonder of this visual
> paradigm is obvious with rather small demos that look gorgeous. But no
> complex demos. Because that's all that'll fit on the screen. Every bit of
> it takes up massive amounts of screen real-estate. If complex demos exist,
> you have to zoom out to illegibility, then scroll about, then zoom back in.
>
> To specify the number `20`, takes up 300x45 pixels, including the
> connector linking it to the next node. The actual number itself is about
> 15x15 pixels on the screen, including spacing around the digits. That is a
> density difference factor of 60 times. Let's not even get into nodes for
> add and subtract.
>
> The other big flaw of visual programming is that it forces you to move
> between your keyboard and mouse constantly. Instead of continuous typing of
> code, you keep having to select and place new nodes, add connectors, etc.
> You have to target and select various buttons and pay a lot of attention to
> positioning your mouse on the screen. Pure text programming, on the other
> hand, can be done blindfolded. Or, at the least, with far less spatial
> attention required. With three keystrokes I can add `9*7`. In a visual
> paradigm, I have to select and place three nodes. Something like 4 clicks,
> scrolling, and a drag per node. Then two more clicks and drags to connect
> the nodes.
>
> Not to bash Flood, because it does look nice. But, like pretty much all
> visual languages, it just isn't very practical for anything non-trivial.
>
> - Revar
>
>
>
> On Apr 16, 2019, at 8:44 AM, William Adams <will.adams@frycomm.com> wrote:
>
> Has anyone come across this before?
>
> https://www.floodeditor.com
>
> I'm flabbergasted that it doesn't seem to have made more of a splash.
>
> William
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
DM
Doug Moen
Tue, Apr 16, 2019 5:16 PM
Flood has a "script" object where you can type in an expression.
It would be interesting to see a graphics editor that lets you view and edit the same program as either text or a flowchart. Has anybody used software that works this way? Links?
On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
I agree with what you have said. But it would also be cool if it had the ability to use either the graphical mode OR a text mode. Some of the graphics engines have this visual interface -- but one can also use traditional programming methods.
Kevin
On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera revarbat@gmail.com wrote:
Hadn't seen this one before. Looks nice, but it has the standard critical flaw of a visual programming system. Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity. The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.
There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting! I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!" So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous. But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.
To specify the number 20, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.
The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc. You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen. Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add 9*7. In a visual paradigm, I have to select and place three nodes. Something like 4 clicks, scrolling, and a drag per node. Then two more clicks and drags to connect the nodes.
Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.
Flood has a "script" object where you can type in an expression.
It would be interesting to see a graphics editor that lets you view and edit the same program as either text or a flowchart. Has anybody used software that works this way? Links?
On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
> I agree with what you have said. But it would also be cool if it had the ability to use either the graphical mode OR a text mode. Some of the graphics engines have this visual interface -- but one can also use traditional programming methods.
>
> Kevin
>
> On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <revarbat@gmail.com> wrote:
>> Hadn't seen this one before. Looks nice, but it has the standard critical flaw of a visual programming system. Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity. The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.
>>
>> There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting! I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!" So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous. But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.
>>
>> To specify the number `20`, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.
>>
>> The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc. You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen. Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add `9*7`. In a visual paradigm, I have to select and place three nodes. Something like 4 clicks, scrolling, and a drag per node. Then two more clicks and drags to connect the nodes.
>>
>> Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.
>>
>> - Revar
>>
>>
>>
>>> On Apr 16, 2019, at 8:44 AM, William Adams <will.adams@frycomm.com> wrote:
>>>
>>> Has anyone come across this before?
>>>
>>> https://www.floodeditor.com
>>>
>>> I'm flabbergasted that it doesn't seem to have made more of a splash.
>>>
>>> William
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
WA
William Adams
Tue, Apr 16, 2019 5:33 PM
Apparently the developer has been busy with a startup (higharc.com)
A 3rd view where you could hide everything except for designated numerical
inputs would work for me, and using the "script" objects allows one to hide
a lot of the complexity.
If I could just figure out how to do a difference, I'd be ready to start on
at least a small project.
William
On Tue, Apr 16, 2019 at 1:16 PM Doug Moen doug@moens.org wrote:
Flood has a "script" object where you can type in an expression.
It would be interesting to see a graphics editor that lets you view and
edit the same program as either text or a flowchart. Has anybody used
software that works this way? Links?
On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
I agree with what you have said. But it would also be cool if it had the
ability to use either the graphical mode OR a text mode. Some of the
graphics engines have this visual interface -- but one can also use
traditional programming methods.
Kevin
On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera revarbat@gmail.com wrote:
Hadn't seen this one before. Looks nice, but it has the standard critical
flaw of a visual programming system. Visual programming is nice for small
projects, but becomes very unwieldy when you start adding complexity. The
density of code/information of a visual language is necessarily far lower
than a text language, due to connectors, block/window titles, etc.
There is a trap here, that seems to come up from time to time. Someone
will look at text programming languages and say "This is cryptic and not
self documenting! I don't know what the inputs or outputs are, without
delving into arcane documentation! We can do better!" So they go and break
everything down into small pieces that they can represent in small GUI
windows where all the inputs and outputs are visually represented and
obvious. You can hover over them to see pop-up windows explaining the them.
Connections between parts are obvious. It's like making flow charts to
document your program, but they actually run. The wonder of this visual
paradigm is obvious with rather small demos that look gorgeous. But no
complex demos. Because that's all that'll fit on the screen. Every bit of
it takes up massive amounts of screen real-estate. If complex demos exist,
you have to zoom out to illegibility, then scroll about, then zoom back in.
To specify the number 20, takes up 300x45 pixels, including the
connector linking it to the next node. The actual number itself is about
15x15 pixels on the screen, including spacing around the digits. That is a
density difference factor of 60 times. Let's not even get into nodes for
add and subtract.
The other big flaw of visual programming is that it forces you to move
between your keyboard and mouse constantly. Instead of continuous typing of
code, you keep having to select and place new nodes, add connectors, etc.
You have to target and select various buttons and pay a lot of attention to
positioning your mouse on the screen. Pure text programming, on the other
hand, can be done blindfolded. Or, at the least, with far less spatial
attention required. With three keystrokes I can add 9*7. In a visual
paradigm, I have to select and place three nodes. Something like 4 clicks,
scrolling, and a drag per node. Then two more clicks and drags to connect
the nodes.
Not to bash Flood, because it does look nice. But, like pretty much all
visual languages, it just isn't very practical for anything non-trivial.
On Apr 16, 2019, at 8:44 AM, William Adams will.adams@frycomm.com wrote:
Has anyone come across this before?
https://www.floodeditor.com
I'm flabbergasted that it doesn't seem to have made more of a splash.
William
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Apparently the developer has been busy with a startup (higharc.com)
A 3rd view where you could hide everything except for designated numerical
inputs would work for me, and using the "script" objects allows one to hide
a lot of the complexity.
If I could just figure out how to do a difference, I'd be ready to start on
at least a small project.
William
On Tue, Apr 16, 2019 at 1:16 PM Doug Moen <doug@moens.org> wrote:
> Flood has a "script" object where you can type in an expression.
>
> It would be interesting to see a graphics editor that lets you view and
> edit the same program as either text or a flowchart. Has anybody used
> software that works this way? Links?
>
> On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
>
> I agree with what you have said. But it would also be cool if it had the
> ability to use either the graphical mode OR a text mode. Some of the
> graphics engines have this visual interface -- but one can also use
> traditional programming methods.
>
> Kevin
>
> On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <revarbat@gmail.com> wrote:
>
> Hadn't seen this one before. Looks nice, but it has the standard critical
> flaw of a visual programming system. Visual programming is nice for small
> projects, but becomes very unwieldy when you start adding complexity. The
> density of code/information of a visual language is necessarily far lower
> than a text language, due to connectors, block/window titles, etc.
>
> There is a trap here, that seems to come up from time to time. Someone
> will look at text programming languages and say "This is cryptic and not
> self documenting! I don't know what the inputs or outputs are, without
> delving into arcane documentation! We can do better!" So they go and break
> everything down into small pieces that they can represent in small GUI
> windows where all the inputs and outputs are visually represented and
> obvious. You can hover over them to see pop-up windows explaining the them.
> Connections between parts are obvious. It's like making flow charts to
> document your program, but they actually run. The wonder of this visual
> paradigm is obvious with rather small demos that look gorgeous. But no
> complex demos. Because that's all that'll fit on the screen. Every bit of
> it takes up massive amounts of screen real-estate. If complex demos exist,
> you have to zoom out to illegibility, then scroll about, then zoom back in.
>
> To specify the number `20`, takes up 300x45 pixels, including the
> connector linking it to the next node. The actual number itself is about
> 15x15 pixels on the screen, including spacing around the digits. That is a
> density difference factor of 60 times. Let's not even get into nodes for
> add and subtract.
>
> The other big flaw of visual programming is that it forces you to move
> between your keyboard and mouse constantly. Instead of continuous typing of
> code, you keep having to select and place new nodes, add connectors, etc.
> You have to target and select various buttons and pay a lot of attention to
> positioning your mouse on the screen. Pure text programming, on the other
> hand, can be done blindfolded. Or, at the least, with far less spatial
> attention required. With three keystrokes I can add `9*7`. In a visual
> paradigm, I have to select and place three nodes. Something like 4 clicks,
> scrolling, and a drag per node. Then two more clicks and drags to connect
> the nodes.
>
> Not to bash Flood, because it does look nice. But, like pretty much all
> visual languages, it just isn't very practical for anything non-trivial.
>
> - Revar
>
>
>
> On Apr 16, 2019, at 8:44 AM, William Adams <will.adams@frycomm.com> wrote:
>
> Has anyone come across this before?
>
> https://www.floodeditor.com
>
> I'm flabbergasted that it doesn't seem to have made more of a splash.
>
> William
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
DM
Doug Moen
Tue, Apr 16, 2019 5:55 PM
According to the source code, SolidSubtract should be a difference, but it doesn't work for me.
On Tue, Apr 16, 2019, at 1:34 PM, William Adams wrote:
Apparently the developer has been busy with a startup (higharc.com)
A 3rd view where you could hide everything except for designated numerical inputs would work for me, and using the "script" objects allows one to hide a lot of the complexity.
If I could just figure out how to do a difference, I'd be ready to start on at least a small project.
William
On Tue, Apr 16, 2019 at 1:16 PM Doug Moen doug@moens.org wrote:
__
Flood has a "script" object where you can type in an expression.
It would be interesting to see a graphics editor that lets you view and edit the same program as either text or a flowchart. Has anybody used software that works this way? Links?
On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
I agree with what you have said. But it would also be cool if it had the ability to use either the graphical mode OR a text mode. Some of the graphics engines have this visual interface -- but one can also use traditional programming methods.
Kevin
On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera revarbat@gmail.com wrote:
Hadn't seen this one before. Looks nice, but it has the standard critical flaw of a visual programming system. Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity. The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.
There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting! I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!" So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous. But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.
To specify the number 20, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.
The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc. You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen. Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add 9*7. In a visual paradigm, I have to select and place three nodes. Something like 4 clicks, scrolling, and a drag per node. Then two more clicks and drags to connect the nodes.
Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.
According to the source code, SolidSubtract should be a difference, but it doesn't work for me.
On Tue, Apr 16, 2019, at 1:34 PM, William Adams wrote:
> Apparently the developer has been busy with a startup (higharc.com)
>
> A 3rd view where you could hide everything except for designated numerical inputs would work for me, and using the "script" objects allows one to hide a lot of the complexity.
>
> If I could just figure out how to do a difference, I'd be ready to start on at least a small project.
>
> William
>
>
> On Tue, Apr 16, 2019 at 1:16 PM Doug Moen <doug@moens.org> wrote:
>> __
>> Flood has a "script" object where you can type in an expression.
>>
>> It would be interesting to see a graphics editor that lets you view and edit the same program as either text or a flowchart. Has anybody used software that works this way? Links?
>>
>> On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
>>> I agree with what you have said. But it would also be cool if it had the ability to use either the graphical mode OR a text mode. Some of the graphics engines have this visual interface -- but one can also use traditional programming methods.
>>>
>>> Kevin
>>>
>>> On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <revarbat@gmail.com> wrote:
>>>> Hadn't seen this one before. Looks nice, but it has the standard critical flaw of a visual programming system. Visual programming is nice for small projects, but becomes very unwieldy when you start adding complexity. The density of code/information of a visual language is necessarily far lower than a text language, due to connectors, block/window titles, etc.
>>>>
>>>> There is a trap here, that seems to come up from time to time. Someone will look at text programming languages and say "This is cryptic and not self documenting! I don't know what the inputs or outputs are, without delving into arcane documentation! We can do better!" So they go and break everything down into small pieces that they can represent in small GUI windows where all the inputs and outputs are visually represented and obvious. You can hover over them to see pop-up windows explaining the them. Connections between parts are obvious. It's like making flow charts to document your program, but they actually run. The wonder of this visual paradigm is obvious with rather small demos that look gorgeous. But no complex demos. Because that's all that'll fit on the screen. Every bit of it takes up massive amounts of screen real-estate. If complex demos exist, you have to zoom out to illegibility, then scroll about, then zoom back in.
>>>>
>>>> To specify the number `20`, takes up 300x45 pixels, including the connector linking it to the next node. The actual number itself is about 15x15 pixels on the screen, including spacing around the digits. That is a density difference factor of 60 times. Let's not even get into nodes for add and subtract.
>>>>
>>>> The other big flaw of visual programming is that it forces you to move between your keyboard and mouse constantly. Instead of continuous typing of code, you keep having to select and place new nodes, add connectors, etc. You have to target and select various buttons and pay a lot of attention to positioning your mouse on the screen. Pure text programming, on the other hand, can be done blindfolded. Or, at the least, with far less spatial attention required. With three keystrokes I can add `9*7`. In a visual paradigm, I have to select and place three nodes. Something like 4 clicks, scrolling, and a drag per node. Then two more clicks and drags to connect the nodes.
>>>>
>>>> Not to bash Flood, because it does look nice. But, like pretty much all visual languages, it just isn't very practical for anything non-trivial.
>>>>
>>>> - Revar
>>>>
>>>>
>>>>
>>>>> On Apr 16, 2019, at 8:44 AM, William Adams <will.adams@frycomm.com> wrote:
>>>>>
>>>>> Has anyone come across this before?
>>>>>
>>>>> https://www.floodeditor.com
>>>>>
>>>>> I'm flabbergasted that it doesn't seem to have made more of a splash.
>>>>>
>>>>> William
>>>>>
>>>>> _______________________________________________
>>>>> OpenSCAD mailing list
>>>>> Discuss@lists.openscad.org
>>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> Discuss@lists.openscad.org
>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> Discuss@lists.openscad.org
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> Discuss@lists.openscad.org
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
TP
Torsten Paul
Tue, Apr 16, 2019 6:12 PM
On 16.04.19 19:16, Doug Moen wrote:
Has anybody used software that works this way? Links?
On 16.04.19 19:16, Doug Moen wrote:
> Has anybody used software that works this way? Links?
I have not actually used it myself, but ICEStudio works
that way (https://github.com/FPGAwars/icestudio) - which
is a visual editor for Verilog.
ciao,
Torsten.
WA
William Adams
Tue, Apr 16, 2019 6:22 PM
Thanks! That was my interpretation as well, but I was stymied by it not
working either --- guess I'll have to raise an issue on github.
William
On Tue, Apr 16, 2019 at 1:55 PM Doug Moen doug@moens.org wrote:
According to the source code, SolidSubtract should be a difference, but it
doesn't work for me.
On Tue, Apr 16, 2019, at 1:34 PM, William Adams wrote:
Apparently the developer has been busy with a startup (higharc.com)
A 3rd view where you could hide everything except for designated numerical
inputs would work for me, and using the "script" objects allows one to hide
a lot of the complexity.
If I could just figure out how to do a difference, I'd be ready to start
on at least a small project.
William
On Tue, Apr 16, 2019 at 1:16 PM Doug Moen doug@moens.org wrote:
Flood has a "script" object where you can type in an expression.
It would be interesting to see a graphics editor that lets you view and
edit the same program as either text or a flowchart. Has anybody used
software that works this way? Links?
On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
I agree with what you have said. But it would also be cool if it had the
ability to use either the graphical mode OR a text mode. Some of the
graphics engines have this visual interface -- but one can also use
traditional programming methods.
Kevin
On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera revarbat@gmail.com wrote:
Hadn't seen this one before. Looks nice, but it has the standard critical
flaw of a visual programming system. Visual programming is nice for small
projects, but becomes very unwieldy when you start adding complexity. The
density of code/information of a visual language is necessarily far lower
than a text language, due to connectors, block/window titles, etc.
There is a trap here, that seems to come up from time to time. Someone
will look at text programming languages and say "This is cryptic and not
self documenting! I don't know what the inputs or outputs are, without
delving into arcane documentation! We can do better!" So they go and break
everything down into small pieces that they can represent in small GUI
windows where all the inputs and outputs are visually represented and
obvious. You can hover over them to see pop-up windows explaining the them.
Connections between parts are obvious. It's like making flow charts to
document your program, but they actually run. The wonder of this visual
paradigm is obvious with rather small demos that look gorgeous. But no
complex demos. Because that's all that'll fit on the screen. Every bit of
it takes up massive amounts of screen real-estate. If complex demos exist,
you have to zoom out to illegibility, then scroll about, then zoom back in.
To specify the number 20, takes up 300x45 pixels, including the
connector linking it to the next node. The actual number itself is about
15x15 pixels on the screen, including spacing around the digits. That is a
density difference factor of 60 times. Let's not even get into nodes for
add and subtract.
The other big flaw of visual programming is that it forces you to move
between your keyboard and mouse constantly. Instead of continuous typing of
code, you keep having to select and place new nodes, add connectors, etc.
You have to target and select various buttons and pay a lot of attention to
positioning your mouse on the screen. Pure text programming, on the other
hand, can be done blindfolded. Or, at the least, with far less spatial
attention required. With three keystrokes I can add 9*7. In a visual
paradigm, I have to select and place three nodes. Something like 4 clicks,
scrolling, and a drag per node. Then two more clicks and drags to connect
the nodes.
Not to bash Flood, because it does look nice. But, like pretty much all
visual languages, it just isn't very practical for anything non-trivial.
On Apr 16, 2019, at 8:44 AM, William Adams will.adams@frycomm.com wrote:
Has anyone come across this before?
https://www.floodeditor.com
I'm flabbergasted that it doesn't seem to have made more of a splash.
William
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Thanks! That was my interpretation as well, but I was stymied by it not
working either --- guess I'll have to raise an issue on github.
William
On Tue, Apr 16, 2019 at 1:55 PM Doug Moen <doug@moens.org> wrote:
> According to the source code, SolidSubtract should be a difference, but it
> doesn't work for me.
>
> On Tue, Apr 16, 2019, at 1:34 PM, William Adams wrote:
>
> Apparently the developer has been busy with a startup (higharc.com)
>
> A 3rd view where you could hide everything except for designated numerical
> inputs would work for me, and using the "script" objects allows one to hide
> a lot of the complexity.
>
> If I could just figure out how to do a difference, I'd be ready to start
> on at least a small project.
>
> William
>
>
> On Tue, Apr 16, 2019 at 1:16 PM Doug Moen <doug@moens.org> wrote:
>
>
> Flood has a "script" object where you can type in an expression.
>
> It would be interesting to see a graphics editor that lets you view and
> edit the same program as either text or a flowchart. Has anybody used
> software that works this way? Links?
>
> On Tue, Apr 16, 2019, at 1:04 PM, Kevin Toppenberg wrote:
>
> I agree with what you have said. But it would also be cool if it had the
> ability to use either the graphical mode OR a text mode. Some of the
> graphics engines have this visual interface -- but one can also use
> traditional programming methods.
>
> Kevin
>
> On Tue, Apr 16, 2019 at 12:51 PM Revar Desmera <revarbat@gmail.com> wrote:
>
> Hadn't seen this one before. Looks nice, but it has the standard critical
> flaw of a visual programming system. Visual programming is nice for small
> projects, but becomes very unwieldy when you start adding complexity. The
> density of code/information of a visual language is necessarily far lower
> than a text language, due to connectors, block/window titles, etc.
>
> There is a trap here, that seems to come up from time to time. Someone
> will look at text programming languages and say "This is cryptic and not
> self documenting! I don't know what the inputs or outputs are, without
> delving into arcane documentation! We can do better!" So they go and break
> everything down into small pieces that they can represent in small GUI
> windows where all the inputs and outputs are visually represented and
> obvious. You can hover over them to see pop-up windows explaining the them.
> Connections between parts are obvious. It's like making flow charts to
> document your program, but they actually run. The wonder of this visual
> paradigm is obvious with rather small demos that look gorgeous. But no
> complex demos. Because that's all that'll fit on the screen. Every bit of
> it takes up massive amounts of screen real-estate. If complex demos exist,
> you have to zoom out to illegibility, then scroll about, then zoom back in.
>
> To specify the number `20`, takes up 300x45 pixels, including the
> connector linking it to the next node. The actual number itself is about
> 15x15 pixels on the screen, including spacing around the digits. That is a
> density difference factor of 60 times. Let's not even get into nodes for
> add and subtract.
>
> The other big flaw of visual programming is that it forces you to move
> between your keyboard and mouse constantly. Instead of continuous typing of
> code, you keep having to select and place new nodes, add connectors, etc.
> You have to target and select various buttons and pay a lot of attention to
> positioning your mouse on the screen. Pure text programming, on the other
> hand, can be done blindfolded. Or, at the least, with far less spatial
> attention required. With three keystrokes I can add `9*7`. In a visual
> paradigm, I have to select and place three nodes. Something like 4 clicks,
> scrolling, and a drag per node. Then two more clicks and drags to connect
> the nodes.
>
> Not to bash Flood, because it does look nice. But, like pretty much all
> visual languages, it just isn't very practical for anything non-trivial.
>
> - Revar
>
>
>
> On Apr 16, 2019, at 8:44 AM, William Adams <will.adams@frycomm.com> wrote:
>
> Has anyone come across this before?
>
> https://www.floodeditor.com
>
> I'm flabbergasted that it doesn't seem to have made more of a splash.
>
> William
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
WA
William Adams
Tue, Apr 16, 2019 6:27 PM
Arguably Illustrator is a visual tool for PostScript --- or Inkscape for
SVG.
There are some graphical tools for the various TeX related drawing tools
such as xasy for Asymptote and metagraf for METAPOST.
It's discussions like this which make me miss Display PostScript and Altsys
Virtuoso's custom PS fills and strokes.
I wish that Solvespace could be a visual editor for OpenSCAD files though.
William
On Tue, Apr 16, 2019 at 2:12 PM Torsten Paul Torsten.Paul@gmx.de wrote:
On 16.04.19 19:16, Doug Moen wrote:
Has anybody used software that works this way? Links?
Arguably Illustrator is a visual tool for PostScript --- or Inkscape for
SVG.
There are some graphical tools for the various TeX related drawing tools
such as xasy for Asymptote and metagraf for METAPOST.
It's discussions like this which make me miss Display PostScript and Altsys
Virtuoso's custom PS fills and strokes.
I wish that Solvespace could be a visual editor for OpenSCAD files though.
William
On Tue, Apr 16, 2019 at 2:12 PM Torsten Paul <Torsten.Paul@gmx.de> wrote:
> On 16.04.19 19:16, Doug Moen wrote:
> > Has anybody used software that works this way? Links?
>
> I have not actually used it myself, but ICEStudio works
> that way (https://github.com/FPGAwars/icestudio) - which
> is a visual editor for Verilog.
>
> ciao,
> Torsten.
>
>
> _______________________________________________
> OpenSCAD mailing list
> Discuss@lists.openscad.org
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
