91–100 of 100 posts
40-second video that lagged so much it was unplayable on my X200 that runs discord fine, and can have 300 tabs open in firefox without a sweat. Obviously, we're off to a good start.
Forever benchmarking on old hardware is counterintuitive to forward progress. As much as I love my T400, I know someday, probably sooner rather than later, it won’t be suited to daily use.
40-second video that lagged so much it was unplayable on my X200 that runs discord fine, and can have 300 tabs open in firefox without a sweat. Obviously, we're off to a good start.
Don't be snarky.
Earlier quoted context omitted.
This is actually a great idea. I had a conversation over beers with some people in a higher intellectual realm who were discussing the details of flow-based languages. It was the general consensus among them that in the future, flow-based programming will be the way everyone learns structural thinking, and we will look back on sequential instruction programming the same way we look back on punch cards today.
this seems obviously true. but why has it failed for like 40 years so far? many attempts have been made. for some reason all tools seem to fail, no matter how simple, they cause more problems than they're worth.
I'm so confused. "Build interactive web apps" "Create bespoke tools" Any examples besides weird shapes?
This isn't necessarily made for building enterprise web apps or social media sites. There always seems to be a complete absence of appreciation for value to artists on HN. This is very clearly a creative tool first and foremost.
Earlier quoted context omitted.
this seems obviously true. but why has it failed for like 40 years so far? many attempts have been made. for some reason all tools seem to fail, no matter how simple, they cause more problems than they're worth.
I think an interface providing proper abstraction hasn’t been properly built yet. Imagine every API call to Amazon was a block in a flow based system- some of those endpoints have hundreds of options and multiple accepted input formats, so designing an abstraction layer that doesn’t add more complexity than it takes away is a difficult problem to solve.
A flow based system would require more flow on the other (server) side. Imagine each sentence to be a request in the following, and how many avenues of potential service abuse it could bring. That's why we avoid designs like this today.
Here lets's begin a new (cloud?) server definition. Inside this server definition let's begin network specification. Inside this network specification let's begin open ports specification. Here, there's a batch of ports we computed we need. Here, there's another batch of ports we need. End network specification. [...] Let's get back to that port spec, because of something emergent. [...]
Earlier quoted context omitted.
This isn't necessarily made for building enterprise web apps or social media sites. There always seems to be a complete absence of appreciation for value to artists on HN. This is very clearly a creative tool first and foremost.
Almost all 3D softwares have ways to write shaders with node based programming. If that is how this is being posed, there is nothing special to this.
I somehow fail to understand what this is, but am impressed by it nonetheless. Is this purely for animation designers with coding skills? I thought animation work is done in editors with even less code required usually, but for me as a developer this seems more approachable. I could not look at the advanced examples on my iPad though.
We're more geared towards programmers as you define what each node does in their code but you can choose to expose selected node parameters when exporting, for a designer/animator to potentially tweak. Sorry about the advanced examples, some use WebGL and might have issues on iPad Safari that we'll need to check.
Thanks for the answer
Earlier quoted context omitted.
I think an interface providing proper abstraction hasn’t been properly built yet. Imagine every API call to Amazon was a block in a flow based system- some of those endpoints have hundreds of options and multiple accepted input formats, so designing an abstraction layer that doesn’t add more complexity than it takes away is a difficult problem to solve.
We tend to design API calls over the net as stateless. It's more efficient to implement in a server and prevents abuse (keeping client states on servers for unknown amount of time lead to DoS attacks). A flow based system would require more flow on the other (server) side. Imagine each sentence to be a request in the following, and how many avenues of potential service abuse it could bring. That's why we avoid design…
However even with such a paradigm I could see plenty of potential for abuse, even unwittingly - while sequential programming forces you to try-catch, flow based programmers may end up connecting the “error flow” back to the original flow that caused the error, creating an infinite loop that would be much harder to debug.
Unpopular idea here (from a hobbyist programmer). I would "kill" for a text editor/IDE/REPL shaped as a spreadsheet where each cell is a block of code with 2 possible views (text or result) linkable to other cells. This "spreadsheet" would be programming language agnostic (each cell could use a different language) and I could organize/format my cells (location, colors, size, etc) as I wish.
Not language agnostic, but table based.
(eve went in to a different direction afterwards though)