Hacker News new | ask | show | jobs
by zackmorris 4367 days ago
As a borderline ranter/troll myself, I recognize the sentiment that there is too much negativity in the developer sphere. But, the difference between what I say and what the typical mouth breathers spout on, say, political forums, is that I can point to specific examples and evidence of why the status quo sucks.

What the people with a positive slant on all this seem to miss is that it’s not just any one area of computer science that is facing difficulties, it’s all of it. For any technology or methodology, I immediately see flaws that range from merely annoying (semicolons in C, colons in Python) to downright devastating (shared mutable state between processes, the inability to statically analyze imperative code). Very little software has been written that is provably bug-free, and it came at great cost. Some of the control code that NASA has written comes to mind, or perhaps some of the early work in lisp, maybe a few other things like Excel that attempt to avoid programming altogether. Most everything else succumbs to an inability to scale, because code complexity grows exponentially while performance grows linearly. So code that works is generally small and modular. Unfortunately, when we try to tie everything together under umbrella frameworks like UNIX, something is lost and we’ve never solved that in a mainstream way, at least not to my satisfaction.

The great successes today have come in spite of existing technology, not because of it. I very much wish that the world would slow down for a moment, take a step back, and really assess the numerous ways that computing as we know it today has failed to deliver on the promises made by pioneers 50 years ago. It’s like the recent post on HN of how concurrency is the new memory management. While that’s true, it merely reveals the tip of the iceberg, not just in the fact that most languages fall down in the face of concurrency, but that even hardware has been unable to keep pace with the newest trends. It doesn’t even scratch the surface of the wetware issue, that generations of programmers have been raised on orthodoxy that can’t take us to the next level. I know that something is terribly wrong when I point out a problem and am met with such hostility, disguised as positivity. To me, this can be as damaging as excessive criticism. But it’s shielded behind the enormous profitability of the tech sector, where people would rather jump through hoops and make money than solve problems once and all for society and increase everyone’s wealth.

1 comments

Most of your points are wrong.

"inability to statically analyze imperative code", a.k.a, the halting problem. And we've still done a lot here--consider PVS-Studio or similar tools.

Tying stuff together in nix works fine, and has worked fine for decades.

Hardware keeps pace just fine with newest trends, and in fact enables* programmers to try things they couldn't have before.

"Wetware" issue? What're you on about?

Sorry, I don’t mean to diminish what you are saying because it’s valid too. I just disagree. The problem with imperative code vs functional code is that it's difficult to analyze all of the states without just running it (I realize there's a lot more nuance than that). I personally don't think that any of the major players like C++, java or even Go can be saved because there are just too many side effects. But, in fairness no language can be guaranteed to work 100% properly once it has access to external resources (unless the inputs and outputs can be guaranteed to be within a known set). The other big players like Haskell/Closure/Scala can’t be saved either, because they can do anything imperative code can do (you could basically write a C compiler in a functional language and make it unpredictable under some condition). Worse than that, functional languages are basically unreadable without strong backgrounds in the theory. As has been said many times, there is no silver bullet.

But, that doesn’t mean we shouldn’t try. I think for starters, a reasonably safe language that is binary compatible with C could begin replacing some of the aging code under the right circumstances. I think we are long overdue for a tool that can exercise a binary over some number of inputs and outputs and come up with the underlying code. Unfortunately it would also copy errors, which is kind of bizarre to think about. We sort of have decompilers now but they generally result in an unreadable mess because they have no notion of the kinds of considerations humans make when they write code. I would prefer a decompiler that takes a typical toolset (linked lists, binary trees, etc) and arranges those metaphors in a way that generates the same code even if it’s a little less efficient. That kind of efforts obviously needs a moonshot from universities/government/philanthropists and I don’t see it happening any time soon. It’s on par with strong AI. And more importantly, it’s probably not profitable. But if we had it, we could take the behavior driven design that business people or Star Trek characters reason in and generate a program that performs that behavior. Genetic programming comes close here but current hardware isn’t suited to it because we aren’t used to thinking in terms of search spaces 10 or 20 orders of magnitude larger than what we can hold in our heads.

I remember the first time I saw UNIX, my very first thought was “this can’t possibly be how computers work”. It only seems to work now because we’ve been immersed in it so long, but its fatal flaw is illiteracy. 99% of the population isn’t educated enough to use it effectively. I remember thinking the same thing when I saw HTML. The main reason the web took off is that it could handle plain text, not because of some magic with parsing tags. All people wanted to do was post MS Word files, and it failed at that (among numerous other things). So I’m not arguing against something like the stream as the underlying principle that makes UNIX so powerful, I’m arguing against everything else added on top of it that was written in a non-human way and makes it illegible and brittle.

Hardware has gone almost nowhere in 30 years. I’m still using the basically single threaded CPU that I was using the first time I saw a Mac in 1984. It’s faster and cheaper but fundamentally the same. Video cards have kind of gone somewhere, but with their proprietary/closed and narrowly scoped use case, they have made 3D programming needlessly complex compared to a true programmable multicore CPU. Until my computer can run a concurrent version of Go on a realistic number of processors (say 256+, or unlimited via the web) I don’t see any revolutionary advances in AI, physics, medicine, etc coming any time soon.

Unfortunately I really can’t go into enough detail with this stuff on a forum. I guess that’s the gist of the wetware issue. How do I take my experience and distill it down into something others can use to avoid the same mistakes? More importantly, how do I convey the greater expectations that would be possible if we had better tools? Or even incorporate other people’s notions myself when I’m knee-deep in code? I’m thinking in terms of things like freeing people from labor and admittedly technology has gone a long way towards that end, but for some reason it stuttered maybe in the mid 90s and I can’t quite figure out how that happened or how to get past it. It’s a bit like living within the Matrix and knowing that something is terribly wrong without being able to fathom what would be beyond it. Maybe it’s something geopolitical and people have decided that this level of progress is enough and just don’t care about going further. I’m certain if there was a demand, manufacturers would sell the tech that would run circles around what we’re having to use now. But there is more money in video games and solving first world problems, so here we are.

Ah, thank you for the elaboration--I actually agree on several of your points now that you've provided additional context. :)

3D programming is not overly complex; it maps straight to its problem domain in most cases, along with some trivia about the underlying hardware. It's only as we've tried to embrace more general computational models that things've gotten more complicated--IrisGL/OpenGL 1.x were fairly clean conceptually, and not hard to work with.

I disagree too with your statement about hardware--it's similar to saying that airplanes have gone nowhere in 100 years: only true if you discount the massive improvements in engineering and functionality. Modern CPUs do a great deal more with virtual memory, SIMD instructions, and whatnot than old chips. New chips like the Propeller or Mill have some new tricks as well.

(Now, whether or not fundamental architectures are better or worse than, say, old machines from Burroughs et al in the 60s/70s is a different matter altogether....)

Ya I actually really miss OpenGL 1.x as well, as kind of a minimal environment needed to do projections. Something has been lost with shaders. For example, limitations on program size has been a real burden for me, and strikes me as not being general computation. My iPad 1 can only read like 4 source pixels at a time, making blurs very difficult while they are comparatively easy with handwritten blitters. Hopefully WebGL will nudge the spec back towards simpler times.

I kind of look at hardware today like the internal combustion engine. Great strides have been made to speed up single threaded processing, and it is truly remarkable that we run 3 GHz chips without even thinking about it, while most other electronics have seen very little improvement except to go from vacuum tubes to transistors. But if I had a billion transistors to work with, it would be kind of like going to electric motors and the chip I came up with would look nothing like an Intel Core i7. It would be more like an FPGA, with 10,000 or 100,000 simple cores and no caching or anything like that. So it would be abysmal at running an operating system (basically taking us back to the early 90s) but would be faster than any video card today for embarrassing parallel computation like image processing or search (kind of like the bitcoin ASICs but general purpose).