5 ms·
This is simply untrue. It’s not even true in spirit. It ignores all UI programming, game development, and line of business code. This might be true for an extr
by flappyeagle 5y ago
This is simply untrue. It’s not even true in spirit. It ignores all UI programming, game development, and line of business code.
This might be true for an extremely narrow band of startup and consumer facing web programming.
It might be true for the generally low quality programmers getting churned out of Austen’s bootcamp, because they can’t do much more than the stated activity.
- dragonwriter 5y ago> It ignores all UI programming, game development, and line of business code. It is certainly not the case that UI programming and LOB code categorically does not involve integrating poorly documented APIs. I'd be surprised if that was true categorically of gamedev, either.
- barbazoo 5y agoIt's just someone trying to find the next edgy tweet to please their followers. Making such broad generalizing statements in a few characters is rarely successful.
- tomatowurst 5y agosame can be said of the parent's comment. just say something contrarian and not back it up.
- onlyrealcuzzo 5y agoUI programming - let's take websites - the DOM can be considered an API. Game development, using literally any pre-existing function can be considered an API (libraries are APIs). This really boils down to saying - the average line of code is used many times. How many, I guess, depends on how poorly designed the APIs are. If the average function takes longer to use than it did you write (I'm skeptical) - then it would be <9 usages per line. If it takes less time to use a function than to write it - then it would be >9 times.
- tomatowurst 5y agoyou haven't worked in the industry long enough if you haven't encountered poorly constructed/documented API integration from vendors. the ideal world you described does not exist on this planet.
- bostik 5y agoEvery time I got to do anything interesting in an UI, I have had to dive in to read the source code of the library I have to appease. Documentation simply has not been available, explicitly marked as non-existent, or in the more hilarious cases, was outright lying. Maemo media player? The only way to get results was to commit multiple layer violations and manually chase through at least two chains of d-pointers. (Opaque structs that are explicitly not documented.) My own poker tracker? Welcome to Xlib internals. Mind reels at the memory alone. Other phone software? Deep insides of Android source tree, coupled with Qt, and always - ALWAYS its -private headers. Wayland browser? Dissect the insides of Glib, GTK+, WebKit, Pango and Cairo. The list goes on and on. As far as I am concerned, UIs are the blighted forest where no sane person ventures alone, and few come out sane.
- john567 5y agoIt can quickly spiral out of control. My best advice is to just hold back. My experience is that most people don't care about a fancy UI they just want something that works for them. If you can build this from common basic components it should turn out ok. I think the trick is discovering what your application needs. What kind of interface it should be and what goes where. The it's mostly the same thing over and over again until it's not. Then this exploratory phase starts all over. I like to draw experience from game engines. They typically build success around a few key components that have well defined constraints. As long as the right constraints are in place it's possible to make a fun experience. If you have the wrong constraints and you find yourself constantly battling the system then stuff is all wrong and you need to find a new approach.
- sjg007 5y agoIt's APIs all the way down to the ones and zeros.