The problem with this “VL is part of old vvvv” that for what VL is capable of now it’s way much faster to do the same thing in C# for me. And I will choose C# over VL for vvvv plugin development in most situations because obviously VL is more limiting in what i can do with it (it’s not a comparison just a fact). I know you guys want to make sure that VL is supersolid and superrelyable which is awesome but you’re holding back a big portion of potential VL can have. The reason why I cared about VL is the potential to do a more lower level sharpdx implementation with total control of resources and execution (because what we have in vvvv is great but still very limiting and automagical at some points) but i can’t have a look on that because that library importer is not public (tbh i have no idea why are you sitting on that too) or a proper api documentation (at least an autogenerated one from comments) is not there yet. Anyways I love your work and I love your style guys I love vvvv too (after a project with UE4 i realised how awesome vvvv is actually) and I probably will love VL too when I’ll be able to extend it to my needs. Unfortunately you spoiled so many major reasons why people was interested in VL holding back above mentioned features for at least half a year is not really helping. And I’m not even bitching about standalone/implementable version and compiling.

Btw while dealing with the voodoo non-sense of some game engines recently i realised VL can be the next UE4/unity sooo easily (in perspective obviously it would be a decent amount of time/work/resources) so guys pull yourselves together! Visualize money, bitches, drugs and rock-roll around VL!

@u7angel:

this is very hard to answer in general. The reason is that you’d typically express yourself differently within VL. As an example: in C# you rarely use immutable data types, but in VL you typically do. What’s good is that you have more than one way to solve a specific problem and when you discover that a working solution is too slow you can attack the problematic part later on and refactor if necessary.

Generally speaking: In the end C# and VL both compile to the same “IL” code and access the same .NET libraries. By that we also benefit of the optimizations done by the JIT compiler as C# does. So basically there is just not that much of a difference, we share the same universe with C# in that regard. If you would patch the exact program in VL and C# there is hardly any significant difference.

So the only thing that really matters is how VL patches differ in expression style from C# code. We embrace readability first - especially the compatibility with the dataflow paradigm. But we support other styles (like working with mutable data) and therefore it is possible to tweak performance where needed. In the end performance depends really very much upon the patch and the use case and can’t really be answered in such a general manner.

@gregsn, a late thank you for your elaboration

while having a look at VL here and there, i started wondering why you abandon the conciseness/simplicity of vvvv and introduce - i may say - this noisy language. and you have to admit its noisy. i guess sunep did a good example a while ago and the firmata VL is also a good example.

would it be thinkable to have a higher level patching style (i.e. old vvvv) as the default way and an advanced mode VL style living together in this new piece of software ?

or is this the plan anyway ?

@u7angel: exactly. The plan is to stick with the high level vvvv and lower level VL combination for now. We put some work in that integration and i think that the combination really gives you a great toolchain (vvvv) to realize your projects, which now will come with a new integrated tool (vl) to solve some hard problems you stumble upon.

VL was born to solve problems that you can’t solve with vvvv. It therefore starts from the other end of the spectrum. Over time we’ll strive to get it easier to use and less noisy (which is hard if you still want all the language features, but we’ll still try hard).

For the higher level project patches: we might end up with design patterns that favors only some few language features for those patches (like the use of process nodes) and disfavors others (which you only should use in lower level patches). We also had discussions about another higher level patch layer (that works different), but then again the incompatibilty between the different levels might get a pain. So this is only an option if there is no other way around it.

So for now we are happy with the combination of both systems vvvv & VL, since vvvv is strong for those higher level project patch. When VL becomes bigger and finally offers everything you need for your project, we’ll definetly see how we can get the top-down high level easy to enter aspect back, but for now see it as a tool for people that want to solve a hard problem with a visual language that just can’t be solved in vvvv directly. (since it is too high level for that problem……..)

@gregsn, so we can teach design students the “easy” way of patching and the brainiacs can dive into “low level” programming. sounds good to me.

your way of developing the next gen vvvv makes absolutely sense, from complex to simple. i never really noticed this is the plan, it came accross differently or i wasn’t listening carefully enough.

“compile executables” “will run on anything that has .net” are little statements that instantly made a lot of people dream of running vvvv in OSX and on linux (I dreamt of running it on embedded systems) and that took focus away from it actually being a great way to refine and tweak the language without everyone starting out beind super disappointed the it still needs a lot of refinement.

I suspect there will be a new “statement” about the current state and direction, to set the expectations when beta35 comes out, probably in the not too distant future.