Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NoFlo Kickstarter, the hacker's perspective

bergie.iki.fi

Post reply on HN
Print view View original

21–30 of 51 posts

Re: NoFlo Kickstarter, the hacker's perspective

#21

Post by rits »

adamnemecek wrote: post #14

I'm not quite sure what problem is this solving. What exactly does dataflow programming allow me to do that is not possible with non-data flow programming? It appears that the single components are still text, and data flow is only used to hook up these components. So how is this different than say an IDE with definition and reference lookup? I've used Pure Data (which they mention) a little bit and here is an exampl…

Flow chart can be beautiful or ugly just as a textual code can be beautiful or ugly. Also shape of nodes and connectors as important as indentation in text. Look for example of some graph from Nuke - http://www.spaille.be/dev/wp-content/uploads/2010/10/works_n...

Re: NoFlo Kickstarter, the hacker's perspective

#22

Post by chipsy »

bunkat wrote: post #17

Looks like an interesting way to enforce the pattern of testable, reusable components for developers that tend to end up with spaghetti code. However, I think it's a little dubious to say that designers without coding experience will suddenly become empowered to contribute to the code base (or write their own applications) in any meaningful way. Looking at one of the sample pictures on the Kick Starter page I see Anc…

Where these projects tend to fail is in being designed with the assumption of needing to be as decomposed and abstracted as textual code. Suddenly the components become "syntax" again and you're just doing regular old coding with more clicking. On the other hand, the most popular implementations in the historical record - projects like Pure Data - have relatively weak coding abstractions and instead gain strength from staying tightly focused on their domain and never deviating - they are big libraries with a very tiny language, not the other way around.

NoFlo is building on the existing legacy of what has been shown to work, and is most progressive in the sense that it aims to have libraries for many different domains, rather than just one.

Re: NoFlo Kickstarter, the hacker's perspective

#23

Post by johnw »

This reminds me of Quartz Composer[1] in a lot of ways: you wire the inputs and outputs of a bunch of different nodes together (called patches in QC) and each patch gets you a step closer to the solution. This seems to work especially well for graphics programming type problems where there are many different variables to tweak and you're applying many transformations to the image at each stage.

The problem is each component in the process still needs to be written in code. In QC I would often be frustrated when a patch didn't quite do what I needed and I had to keep trying to make my idea fit the limitations of the available patches.

So while this might help non-programmers understand on a big picture level what's happening, to go beyond that they're still going to have to learn how the individual components work which comes back to learning to code textually.

[1] http://en.wikipedia.org/wiki/Quartz_composer

Re: NoFlo Kickstarter, the hacker's perspective

#24

Post by werg »

31reasons wrote: post #4

Code at Compile time is a different entity than the Code at Runtime. Programmers learns to visualize expanding and collapsing data structures and the web of pointers and call-backs. One simple tiny recursive function can become a massively complex tree at runtime. These two complexities are similar yet very different. Any system that doesn't respect the runtime will fail to understand the mindset of a programmer. I h…

Exactly this is the problem with grafting visual programming interfaces onto textual programming semantics. One of the main important reasons to do VP is to be able to inspect the code, to easier see what it does, ideally at a glance. Yet as you point out, simple recursion can make this really difficult to do. My thesis is that we need VPLs that have semantics specifically tailored for the visual interface. It's possible, but takes a bit of thinking to work out

Re: NoFlo Kickstarter, the hacker's perspective

#25

Post by mks »

This

  > NoFlo graphs instead are only the coordination layer 
  that manages the control flow of your software.
reminds me a lot the whole SOA/BPEL/BPMN mess that was hot few years ago in enterpriseland. The surge in visual programming just resulted in developing the same logic with less powerful tools in languages that were not designed for programming (XML and in this case JSON).

These kind of tools focus on the wrong side of the problem. It is not about how to connect the nicely designed services, but how to actually get services to be nicely designed. Once you have service that can be easily connected in the visual tool, it can be trivially used from the conventional programming language as well.

Reasons why services can not be just trivially composed include:

  - every service that is comprehensively mapping real problem is inherently complex 
  (even for seemingly simple things like address geocoding)
  - any two services will have slightly different APIs 
  (consider various signatures of substring method in various languages)
   and oftentimes the backend system details 
  - limitations are leaking over the service API
  (datatypes, formats, paging, ...).
For these reason there exists the large branch of programming that deals with integrating services (sometimes called Enterprise System Integration) that basically wraps, formats and preprocesses data before shoving them to the target service.

For restricted domains - it could probably work. But for general service integration within larger company, the best approach so far has been a lightweight approach with mixture of Spring Integration and plain old Java.

Re: NoFlo Kickstarter, the hacker's perspective

#26

Post by KingdomSprite »

I think this is a great idea, but experience is everything, as others have stated, the diagrams presented still have quite the learning curve, knowing what names connect where. I think if NoFlo allowed actual coding through a visual interface like Scratch, with the ability to group components into functions and classes, this could really go somewhere.

Re: NoFlo Kickstarter, the hacker's perspective

#27

Post by rainforest »

kybernetyk wrote: post #16

From the kickstarter page: > If you’re a programmer, deep down, you know code is bad, it rots, > and with each new line your software accrues complexity debt. > New code means more bugs, more refactoring and more time needed > to bring someone else up to speed. Yeah, and moving little interconnected boxes around a project workspace will solve that? It's not like visual programming is something revolutionary new and d…

I think their reasoning isn't entirely flawed. I have a hunch that by showing how the code is laying out, tolerating spaghetti mess will be much harder than it is in a common IDE - the amount of complexity that code hides can't be hidden when splayed out as graph.

As for solving problems with current codebases, you're entirely correct. I think this will have a purpose in identifying common functionality for refactoring for small projects, but to wrangle a large project into something usable with this will require good automated code clone detection (which may or may not be good enough as of today) to enable the redundant nodes to be coalesced.

Re: NoFlo Kickstarter, the hacker's perspective

#28

Post by rainforest »

adamnemecek wrote: post #14

I'm not quite sure what problem is this solving. What exactly does dataflow programming allow me to do that is not possible with non-data flow programming? It appears that the single components are still text, and data flow is only used to hook up these components. So how is this different than say an IDE with definition and reference lookup? I've used Pure Data (which they mention) a little bit and here is an exampl…

> Now imagine that you inherit a legacy codebase that looks like that.

I wager that every codebase beyond a few years of churn looks like that, you just don't look at the CFG to see how much of a mess it is.

There's a key to their approach in that abstraction can be used - the nodes aren't statements as they are in PD, but chunks of code. This means the low-level stuff is hidden from you and you see how higher-level components integrate (if you take the time to tell it what the high level components are, presumably).

Re: NoFlo Kickstarter, the hacker's perspective

#29

Post by gbrits »

Interesting. This would seem a natural fit for stream / event based processing. Digesting server-logs, social signals, etc. Something like Twitter Storm but with components on a more fine-grained level. Wonder how concepts like iterative map/reduce map to this.

Re: NoFlo Kickstarter, the hacker's perspective

#30

Post by polymatter »

kybernetyk wrote: post #16

From the kickstarter page: > If you’re a programmer, deep down, you know code is bad, it rots, > and with each new line your software accrues complexity debt. > New code means more bugs, more refactoring and more time needed > to bring someone else up to speed. Yeah, and moving little interconnected boxes around a project workspace will solve that? It's not like visual programming is something revolutionary new and d…

Good point, but poor analogy. Everyone knows that red cars go faster (http://tvtropes.org/pmwiki/pmwiki.php/Main/RedOnesGoFaster).

I think more to the point I can't see anything about visual programming that will make refactoring easier or less necessary.

Post reply on HN