'Just Let Me Code!' 372
An anonymous reader writes: Andrew Binstock has an article about the ever-increasing complexity required to write code. He says, "I got into programming because I like creating stuff. Not just any stuff, but stuff other people find useful. I like the constant problem solving, the use of abstractions that exist for long periods nowhere but in my imagination, and I like seeing the transformation into a living presence. ... The simple programs of a few hundred lines of C++ long ago disappeared from my experience. What was the experience of riding a bicycle has become the equivalent of traveling by jumbo jet; replete with the delays, inspections, limitations on personal choices, and sudden, unexplained cancellations — all at a significantly higher cost. ... Project overhead, even for simple projects, is so heavy that it's a wonder anyone can find the time to code, much less derive joy from it. Software development has become a mostly operational activity, rather than a creative one. The fundamental problem here is not the complexity of apps, but the complexity of tools. Tools have gone rather haywire during the last decade chasing shibboleths of scalability, comprehensiveness, performance. Everything except simplicity."
The complexity has to go somewhere (Score:5, Interesting)
As things become more powerful, you can't just wish away the complexity [wikipedia.org]. Maybe you can hide it in one of these 'shibboleth' things mentioned in the summary. That sounds big enough to hide things. Or maybe we could just use describe things more clearly -- but that's crazy talk.
Re:Code the way you want... (Score:5, Interesting)
I finally got to code when I switched from being an employee to being a consultant. My bill rate is high enough that they would rather me work than to get bogged down in meetings. Not saying it will work for everyone, but it worked for me. I've done more REAL work in the past two or three years than I did in the previous 10.
Re:Who is stopping him? (Score:4, Interesting)
I fully understand what he's saying and he's right.
I started doing software work in the early 80's and it was easy, fast and fun.
now, its about 'scrum' and 'agile' and all that stupid shit (sorry if that offends). we had a simple life with makefiles and cvs, but now the librarians are complex and not intuitive, the build systems are uber complex and the CI (cont. integr.) stuff is a big change (and a whole system in itself) compared to the nightly build idea. code reviews, enforced coding standards add more slowness to the dev cycle. bug reporting systems are also complex.
in short, its no fun anymore for us old guys. I fully see what he's saying. he's not talking about tiny snippets but getting shipping code out the door - its more process than it really needs to be, and the quality is STILL NOT THERE, so I don't think we made any real progress. and add in java where even idiots are allowed to write code (no need to free, whoopee!) and you have people who get lazy and if they ever have to write in C, they are totally lost.
lastly, there are too many fad languages and this wastes everyone's time and since you can't be good at so many things, it spreads you too thin if a project has 5+ languages in it.
Re:"Just let me build a bridge!" (Score:4, Interesting)
I recall attending a Microsoft Visual C++ Developer's Conference about 15 years ago, when COM and interfaces were all the new rage. I recall one MS guy giving a speech about the complexity of developing with it, bragging, "If it came down to usability for developers or functionality, we chose functionality."
I knew then I was dealing not with real engineers but with clowns proud of a college project.
Re:Code the way you want... (Score:5, Interesting)
Well, it's different in the ways that make a difference for me...which weirdly enough are "different syntactic sugar" and "a different IDE". It's not as different as it could be, but it does have the advantage of keeping me sharp in the same concepts Java uses as well. I don't have to yell at Eclipse when I'm at home, and I get legit excited when I can play with Linq. (What has my life become...) And that's enough to prevent burnout. But, projectwise, instead of writing backend server components for internet things, I'm writing one big program that decompiles an old retro game and extracts its map and graphics data with a nice graphical client. It feels too big for python. I guess at this point, "small projects" means "things that are not fifty-dev enterprise software things". Small enough that one developer can actually do it all.
I can say that being one dev in control of an entire hobby project makes me a better unit tester (seriously, what company actually follows its own internal UT guidelines) and is great for architecture experience, if you are a midlevel SDE on the rise.
There's probably something positive intellectually about having two languages with slightly different data structures; when you try to solve a problem the same way and are forced to make minor changes, you might find optimizations that are useful in both languages.
My hobby language used to be Multi-User Forth. That got tedious.
Re:Documentation (Score:0, Interesting)
That's because Node.js is an ugly hack built on an ugly language, both of which have piss-poor support for concurrency and parallelization. Callback continuations are idiotic. But it's the only way to do concurrency in Javascript because the language's evolution is constrained by the existing JIT implementations, which cannot cleanly support fibers or coroutines. (And in a browser context you simply don't want massively concurrent execution of contexts within a web page, anyhow. Yet in a server environment it's the precise thing you want most!)
I manage a small Lua library which is simpler, cleaner, smaller, more useful (coroutines instead of callbacks, condition variables instead of promises, although I've implemented promises using condition variables and coroutines), infinitely easier to extend (Lua is unsurpassed this way), and more portable (O(1) polling on all BSDs, OS X, Linux, and Solaris; signal polling on all; file change notification on all; among other facilities) using Lua. LuaJIT is faster than V8, although most web apps aren't bottlenecked by the things that a JIT accelerates. In any event the library builds as a module for LuaJIT, PUC Lua 5.2, and PUC Lua 5.3.
The last piece to my puzzle is implementing a networked module loader. I can seamlessly interpose the require() function and download modules on-the-fly, maintaining a local cache. Requiring users to pre-install modules a la NPM is so 1990s. With my library you'll be able to use any module you care about without worrying about installation or removal. I can even download updates to modules in the background, so that security updates or bug fixes can be applied to running instances, as long as the module is careful about state management.
See http://25thandclement.com/~william/projects/cqueues.html, which is the low-level library I'm building the project around. It has zero dependencies, building cleanly on OS X, NetBSD, FreeBSD, OpenBSD, Linux, and Solaris 11 using the stock environment (libc and OpenSSL).
Re:"Just let me build a bridge!" (Score:4, Interesting)
those two people SHOULDN'T be the same person.
In my experience, that is the heart of what is wrong with a lot of software projects: it's considered taboo to do both architecting and developing.
The theory is obvious enough, but in practice an architect that is not implementing overlooks some very significant issues. The implementer has his hands tied because 'the architect said so' and the implementer trudges on also blindly unaware of anything beyond his little island.
The best teams I've been in have had everyone participate in architecting and development, with healthy amounts of communication.
The thing about construction projects is that they are simply so massive you need a horde of construction workers. In software development, we often like to *think* we are making something equally massive when in practice if we do need that many people working on it to get to the goal then it 99% of the time means we are doing something wrong in the first place. If we put hubris aside and realized that the scale isn't so grand as to require a trillion little dependencies and components, we produce good code. This doesn't mean the opposite situation of a gigantic monolithic blob is good, but there is a reasonable middle ground.