Category: FlowSharp

Building a Web-Based Diagramming App with SVG and Javascript

I’ve been wanting to learn about SVG for a while now, and there are certainly any number of helpful websites on creating SVG drawings and animations. But I didn’t want to learn how to create static (or even animated) SVG drawings, I wanted to learn how to use SVG dynamically:

  • Create, modify, and remove SVG elements dynamically.
    Hook events for moving elements around, changing their attributes, etc.
    Save and restore a drawing.
    Discover quirks and how to work around them.

That’s what this article is about — it will only teach you SVG and Javascript in so far as to achieve the goals outlined above. However, what it will teach you is how to create dynamic SVG drawings, and what better way to do this than to actually create a simple drawing program. Then again, I learned a lot about both SVG and modern Javascript writing this article.

Read the rest of the article on Code Project!

Code is also on GitHub.

 

FlowSharpCode, continued…

fsc2.png

A simple example, but the “problem” is that the three Drakon shapes (begin loop, output, and end loop) each still have individual C# code-behind in each shape.  For example, the begin loop has the code-behind:

 var n in Enumerable.Range(1, 10)

My original idea was that the Drakon shape description should not define the language-specific syntax, instead that should be implemented by the developer in the code-behind.

In practice (and I’ve written a complex application in FlowSharpCode, so I know) it becomes unwieldy to deal with one-liner code behind, the result of which is that I tend not to use Drakon shapes, but that results in nothing better than a meaningless box with some code in it.

I’m also reluctant to put the code in the shape label (though this is supported) as again we’re now dealing with language specific syntax.

I’m also reluctant to create a meta-language for Drakon shapes, for example, something that could interpret:

n = 1..10

into C#, Python, whatever.  What if the developer wants to write:

Count from 1 to 10

So, what I’m considering is letting the developer create the Domain Specific Language (DSL) so that they can expressively communicate the semantics of a Drakon shape and also provide the rules for how the semantics is parsed, ideally in an intermediate language (IL), for example, something that expresses a for loop, a method call, whatever.

The advantage to this is that the developer can create whatever DSL they like to work in, the IL glues it together into the concrete language.

Two things happen then:

  1. The DSL is interchangeable.  Any IL can be super-composed into your DSL choice.
  2. The IL is language independent, so it can be de-composed into language specific syntax.

Item #2 of course imposes some significant limitations — what if a language doesn’t support classes, or interfaces, or yield operator, or whatever?  I’m not particularly too concerned about that as a language-independent DSL/IL is more of a curiosity piece, as it becomes rapidly untenable when your code starts calling language-framework-platform dependencies.

However, I’d love to hear my readers thoughts on this DSL/IL concept I’m considering.

 

 

FlowSharpCode Gets DRAKON Shapes

drakon1.png

I’ve added some select DRAKON shapes for creating flowcharts.  The Python code in the lower right editor is generated from the flowchart, and the output from the run is shown on the left.

PyLint is also now integrated into FlowSharpCode’s PythonCompilerService.  This really improves the development process as many syntactical errors are detected before even running the code.

Also, the code generator creates an execution tree which independent of the language syntax, which means that support for other languages is easily added.  Now granted, the code itself in each of the DRAKON shapes is Python code, but I have some ideas of how to make that code agnostic as well.

What Will a 6GL Look Like?

First generation languages (1GL) were closely tied to the hardware, requiring the human operator to physically manipulate toggle switches to enter in the machine language instructions directly.

Second generation languages (2GL) can be loosely categorized as assembly languages.

Third generation languages (3GL) abstracted assembly language into a more human readable syntax.

Fourth generation languages (4GL) are distinguished from 3GH in that they are typically further abstracted from the underlying hardware.

Fifth generation languages (5GL), which abstracts the language itself such that it is based on “”solving problems using constraints given to the program, rather than using an algorithm written by a programmer.”

What will a 6GL look like?

In my opinion, it will look a lot like FlowSharpCode in which programs are written by piecing together the building blocks of smaller pieces of code (“behaviors”) using very visual tools, either a 2D canvas or a 3D virtual surface.

flowsharpcode

And while we’re at it, a 7GL?

Some may argue that a 6GL will be an AI, but again in my opinion, an AI that truly succeeds at “writing” an original program will do so by building from smaller behaviors.  Expecting an AI to produce “code” in the languages that exist today is, well, a cute but absurd thought.  A successful AI most likely will utilize some kind of “visualization” (whatever that looks like to an AI) for manifesting its “imagination” into concrete behaviors.  And most likely, whatever visualization system the AI uses will most likely be able to be mapped onto a 3D or 4D (including time dimension) surface for us to peruse.