Live data from Hacker News

Negative focus

nrkbeta.no

41–47 of 47 posts

Re: Negative focus

#41

No. You're too damn positive. "We could solve this problem if we just had some idealistic 20 somethings form a start-up about it." "This industry sucks, but someone will have the courage to 'disrupt' it." "When I die, I want my body frozen so I can be regenerated after the singularity." "My start up is doing great. I'm 'crushing it.' All the time." "I'm not overworked. I just require far less sleep than the average p…

Most damning bit:

This does not add up. Haven’t you noticed that we have taken over the world?

No, software has exploded into previously untouched fertile ground--in another few decades, it'll be as boring and constrained as anything else, probably.

Other engineering disciplines are right to mock and laugh and be somewhat terrified about software folks, because they can't engineer for shit.

One of the biggest things that, say, the ASME does is to help standardize practices in its field. The mark of a mature engineering branch is that it has guidelines that are applicable to most use cases, and agreed-upon tools that work for most things.

Software is nothing like this, for better or worse--we still haven't standardized on a set of programming languages, we still haven't standardized on a way of documenting and planning projects, we still haven't even settled on the most basic of issues of training.

And you know what? We openly mock the people that have tried that--think about the criticisms of "architecture astronauts" and UML and XML and waterfall and testing and all the rest.

We don't deserve to be called engineers...we're simply lucky enough that people are willing to pay such large sums for such hastily-built things.

Re: Negative focus

#42

By telling someone else that 'X sucks', you're asserting your knowledge of X (and often Y or Z too, one of which you might recommend instead of X). Within limits, this is perfectly reasonable - there are pitfalls out there, and advising other people to avoid them is helpful. However, there are a few big risks which arise when doing this, particularly around non-technical people: 1) The developer who cried wolf - if y…

"Considered Harmful" was not Dijkstra's idea, but his editor! And there's no way to say that "PHP is good", that's just untrue in all universes.

OK, but he's still on the hook for "mentally mutilated".

Also, my point is that "good" is really a relative term. PHP is good, because the baseline for programming language quality is quite high. You can do so much stuff using PHP - you can build YouTube[1], Facebook, Wikipedia, WordPress and much more. I don't know what the total value of web applications written in PHP is in billions of dollars, but it's a big number. My point is that if that's what we can do with PHP, just think what we could do with better tools! In my definition, "good" means "enables the creation of valuable things", and PHP does that. I hope that it gets replaced by something better, for the same reason that I hope current medical treatments get replaced by better ones, but I can't call it "bad".

It's weird, but programmers are sometimes the people with the least appreciation for how valuable their creations are. We do things that non-programmers simply cannot do, creating massive value in the process. Yet many programmers are afflicted by impostor syndrome and the sense that what they do is not really that valuable and that most of what they build is crap. This negativity is misdirected, towards other programmers - "I'm better than her because she uses PHP and I use Haskell" - when it should be directed towards the things that cause real project failure. A well-conceived and well-managed project that creates a PHP web application is much more valuable for everyone than a badly-managed project that produces a Haskell application that nobody uses.

[1] The first version, at least. Google doesn't do PHP.

Re: Negative focus

#43

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 compu…

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?

Re: Negative focus

#44

Earlier quoted context omitted.

"Considered Harmful" was not Dijkstra's idea, but his editor! And there's no way to say that "PHP is good", that's just untrue in all universes.

OK, but he's still on the hook for "mentally mutilated". Also, my point is that "good" is really a relative term. PHP is good, because the baseline for programming language quality is quite high. You can do so much stuff using PHP - you can build YouTube[1], Facebook, Wikipedia, WordPress and much more. I don't know what the total value of web applications written in PHP is in billions of dollars, but it's a big numb…

It's not that php is good per se, although that is not nearly as objective a term as language bikeshedders tend to believe, but that better languages are still worse at the one thing php was intended to do - or at the very least, better in ways which don't actually matter. Almost all web application development is CRUD anyway, and php is perfectly adequate to the task.

Re: Negative focus

#45

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 compu…

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.

Re: Negative focus

#46

Earlier quoted context omitted.

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 fa…

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....)

Re: Negative focus

#47

Earlier quoted context omitted.

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 fa…

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 co…

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).

Post reply on HN