Re: I highly Recommend the Sonus GDE
@20, you actually don't need to know a lot of math - though knowing at least the concepts of math (i.e. what a conditional is, a function, a variable and constant, etc) will make things a bit easier. The only times you need to know math are when your ding things like matrices, handling coordinates, panning, velocities, etc. -- which you'd need to know regardless.
@22, I'm not exactly sure where you ever got the idea that this is 'programming elitism'. All you need to od is look up "why visual programming is bad" and you'll find that a large amount of developers all over the world agree with us "elitists". This one answer, from Quara, does describe it in a nice way; the original answer was on why we "hate it". (For reference, I don't "hate" it, I dislike it.) The answer was:
Hate is a strong word.
I will say that as a seasoned developer I don’t care for visual programming languages as they usually fall short when you have to do something very custom and low-level in your code.
You just can’t get as “fine grained” with visual programming as you can with traditional textual programming. Textual programming allows you to go to a far lower level of detail than does visual programming, thereby providing the developer more “power”.
Visual programming was created to make programming easier for those who might be intimidated by textual programming. The downside of visual programming is that what it gains in ease of programming it takes away from the ability to manipulate the “fine details”.
Most successful developers don’t need a tool to “dumb down” their craft, it would only cause them frustration. Imagine you are a gourmet chef. Now imagine that in order to make your job easier you can simply serve your diners microwave meals bought at the grocery store. Will you want to serve your diners microwave meals? No, not at all. The microwave meals are great for those who aren’t very good at cooking, but they are not an acceptable alternative to a hand-prepared gourmet meal. This is just like the difference between visual programming (the microwave meal), and textual programming (the hand-prepared gourmet meal).
Also, its not that we have the need to 'secure fort nox'. Security is a very big thing these days, and when your designing a project that is definitely something you need to consider -- especially if your going to release it. We can't make it impossible for someone to break security but we can make it impractical to do so. To secure something right though, you need to know how first. Visual programming doesn't give you enough fine-grained control to do something like that safely. That idea applies similarly across most domains of programming things. We don't hate the idea of visual programming, we disagree with the hole notion because we feel that in the end you learn far less than you would if you typed the code out or read it to get a full understanding of how it worked. Plus, you have far less control over literally everything. Sometimes, you need a lot of control over how something works (i.e. audio processing, networking) that visual programming may not give you. So before you go shouting to the world that this is programming elitism, kindly do some research on the subject first.
@24, I can see how that's difficult, and I get your point. I would like to at least try to help you to see if we can find a syntax that you like to work with sometime.
Edit: Another programmer at Hacker News also described his reasons for disliking visual programming:
Experience with tools like Blender or Nuke and particularly with visual programming in games engines is actually where a lot of the better informed dislike of visual programming comes from.
The biggest problem with these tools is scalability and maintainability. You will hear many stories in the games and VFX industries of nightmare literal spaghetti code created with visual programming tools that is impossible to debug, refactor or optimize.
Visual programming seems easy for very small examples but it doesn't scale. It has no effective means of versioning, diffing or merging and usually lacks good mechanisms for abstraction, reuse and hierarchical structure. It doesn't have tooling for refactoring and typically lacks tooling for performance profiling.
Some of these problems seem to be more fundamental and others like they could potentially be addressed with better tooling but that tooling never seems to emerge.
I've got a lot of experience with shader programming and have never found node based shader editors to be better than text over the long term, although there are some nice visual debugging features which are rarely implemented in text based IDEs (though I have seen it done). I've also found visual scripting to all too frequently get out of hand and have to be replaced with code due to being unmaintainable, undebuggable or unoptimizable.
I think there is possibly fertile terrain to explore in trying to get some of the benefits of visual programming approaches while avoiding all these downsides but many of us have been burned enough to be very skeptical of the majority of visual programming systems that don't even try to fix the worst problems.
You'll find many people on both sides with varying reasons and opinions about why one is better than the other. hold mine -- that its a bad idea -- and I have yet to see anything to change that. This may be due to the fact that I prefer textual representations because I'm able to lay out my thoughts and ideas out in a format I understand far better than I would a user interface.
Source: https://news.ycombinator.com/item?id=19025639
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
