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

31–40 of 51 posts

Re: NoFlo Kickstarter, the hacker's perspective

#31

Post by msy »

rainforest wrote: post #27
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 refactori…

The complexity and spagetti will just end up inside those nodes rather than between them, the same discipline required to refactor and rearchitect as requirements change will apply. This just seems like a visual wrapper on a much more functional programming / actor model style approach.

Re: NoFlo Kickstarter, the hacker's perspective

#33

Post by kybernetyk »

polymatter wrote: post #30
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.

Yes, that's why I chose yellow and green, obviously ;)

Re: NoFlo Kickstarter, the hacker's perspective

#34

Post by Gonzih »

Lets solve spaghetti code with more spaghetti code hidden behind some nice UI. How about actually thinking about problems and finding fundamental flaws in workflow? I know it's harder, I know you can't then film fancy promo video in some expensive hotel. But it actually might work.

I'm not saying that ideas of visual programming are bad. What I'm saying it that hiding complexity behind some more complexity and saying that we invented simplicity is bad. NoFlo doesn't look like something new but more like just wrapper around existing methodologies. Nothing new, just hiding details from programmer. OOP way of thinking.

Re: NoFlo Kickstarter, the hacker's perspective

#35

Post by dkersten »

polymatter wrote: post #30
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.

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

I don't fully agree. Well, I do agree that it is just as necessary and good software engineering principles are necessary to prevent the code from (quite literally) becoming spaghetti code, but from the work I've done in Max/MSP, I feel that as long as you follow software engineering principles (most Max/MSP people don't because most are eg musicians and such who have no software engineering training) I found it to be a very pleasant experience with many advantages over traditional textual languages. Granted, some things really are best represented textually (certainly complex expressions or formulas) but a lot of code is just routing data around and I found that the visual languages I've used (mainly Max and Synthmaker) really shine at that. in fact, I find that moving data around is the single most important programming task in most programs.

Other areas where visual programming really shines is in experimental programming and I think a big part of that is that 1) you can easily "wire" things up differently and change things just to see what happens and 2) you don't have to name things until you're good and ready. You still should properly name things, of course, but during prototyping and experimentation I find this often gets in my way when using textual languages and I end up giving things temporary names like foo or x. Another area where (some) visual languages shine is debugging because they often let you visually see the flow of data through the code and intercept it and such. I found Max/MSP's debugger to be very nice to use, though I also feel there is a lot of room for it to improve even more still and unit testing tools are needed too.

As for refactoring - you know how some IDE's have a feature where you can select a bunch of code and hit refactor and it puts it into its own function for you? Max does this really well too: click-drag to select all the components you want to factor out and it places it all into a new component for you. Really quick and easy. This isn't a visual vs textual thing but rather a tooling thing, of course.

Re: NoFlo Kickstarter, the hacker's perspective

#36

Post by rubinelli »

meemoo wrote: post #11
freework wrote: post #10

As much as I want to love this thing, I can't help but feel like they are trying to solve an unsolvable problem. We don't consider Michaelangelo a genius because he thought up the David statue. We consider him a genius because he went through the process to make the statue exist. Great software exists not because someone thought it up. Great software exists because someone went through the process of making that soft…

More than making coding easier, I think we're trying to give strict structure to code and pair it with a visual metaphor to help manage complexity. There is a learning curve, but we're designing it to stick close to JavaScript. If we succeed, I imagine that we'll just increase the complexity of the coding that we take on. That's an interesting possibility. I'd like to imagine a new generation of startups with more in…

The strict structure kinda bugs me. I expect situations where a clean solution using higher order functions outside this framework is possible, but if I implement it, I no longer have this clear picture of the system. Or I submit to it, perhaps duplicating code and spreading gnarly business rules on top of what should be "pure" data flow logic.

EDIT: Still, I'm all for experimentation. If they can pull this off, great!

Re: NoFlo Kickstarter, the hacker's perspective

#37

Post by ronaldx »

msy wrote: post #31
rainforest wrote: post #27

Earlier quoted context omitted.

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 refactori…

The complexity and spagetti will just end up inside those nodes rather than between them, the same discipline required to refactor and rearchitect as requirements change will apply. This just seems like a visual wrapper on a much more functional programming / actor model style approach.

> The complexity and spagetti will just end up inside those nodes rather than between them

Great! I would see that as a massive improvement in itself.

First priority: the overview of the system should be clear. Then: drill down a level to see the detail within each node.

Re: NoFlo Kickstarter, the hacker's perspective

#39

Post by CmonDev »

ronaldx wrote: post #38

I would like to know if NoFlo is being bootstrapped, i.e. are NoFlo developers actively using NoFlo to further develop NoFlo? Some video of this type of development process would be an amazing proof-of-value.

I seriously doubt it. NoFlo is not a language, it's a DSL on top of some another language. There will always be NoFlo.core and NoFlo.libs.

Re: NoFlo Kickstarter, the hacker's perspective

#40

Post by CmonDev »

Schuback wrote: post #19

Throwing this out there, I have shelved a similar web-based project that did this with Verilog designs, which lends itself more naturally to this struture imo. I stopped because I don't believe there's a big enough market for it. That, and I wasn't sure how to tackle the problem of thousands of I/Os in a visual format (would make things real hard to see).

I have seen about 3 game engines exploiting the idea lately. It's good for specific domains but not useful for general purpose stuff.
Post reply on HN