Live data from Hacker News

The State of the Art is Terrible

zackarymorris.tumblr.com

191–200 of 242 posts

Re: The State of the Art is Terrible

#191

I'd like to buy Zack a drink, because all of this is obvious to those poor shmucks among us that handle the support end of things (also known as the "shit end"). I've been saying a lot of the same things for years. I'm tired of it now; I'm starting to give up, because it's obvious there isn't a programmer out there that gives a damn. You can try telling them that there's something wrong with software -- something fun…

>allowed_users You can pay someone to implement this, as well as any other missing AD features, then open source it so no-one has to implement it again. The original devs that did much of the reverse-engineering work on Samba have since moved on to much more rewarding work. That work will essentially never be done again, nor be improved upon until financial incentives are introduced. Much of the work on Samba since h…

>> Still fun for me, after ~15 years of coding, 5 of them professionally.

Lots of us did coding as a hobby for 10 years before gettting out into the professional world. With 5 years under your belt, you're still a junior programmer and the world's your oyster. Let us know how much fun it is 15-20 years or more from now. (And when you do have to care about things more important than programming: family, health, aging parents, job security, etc., etc.)

Re: The State of the Art is Terrible

#192
post #98

The thing that the author of this rant and every other rant like it don't understand is that computer science is hard . While tools like functional programming may indeed deliver on the promise of a 60% code reduction, they have a correspondingly higher barrier to learning. Evolving algorithms? Automatic programming? These problems become theoretically intractable so quickly it's not even funny (I currently do resear…

> While tools like functional programming may indeed deliver on the promise of a 60% code reduction, […] Most code is badly written C++ that could have been written in, say, Ocaml, Haskell, or Lisp. This is easily a 10 fold reduction. And the guys at http://vpri.org/ are doing at least five times better than that (50 fold reduction compared to well written C). On your point 3, Bugs have lower accountability . Meaning…

(The downvote suggest I may have to clarify my statement. I suppose unqualified bashing isn't exactly a good idea.)

By the LOC count of currently maintained projects, most code is definitely badly written, and in a low-level or otherwise unsuitable language such as C++ (C++ is fast, but most of the time we shouldn't even care.) Most code I see (beware selection bias) is indeed badly written C++ (I even authored some of it). Now, if you count by project times end-user popularity, then you have a completely different story. It is a poor proxy for programmer's work quantity, however.

Regarding the 10 fold reduction, just know that I experienced first hand 5 fold reductions when doing my best with C++ and Ocaml respectively. A 10 fold reduction is not unrealistic at all when we talk about badly written C++. For instance…

…I currently write plugin for a 2 million-lines program. The exposed interface alone weights 80,000 lines. Many classes have hundreds of methods, and the inheritance hierarchy is generally 5 levels deep, sometimes up to 8 or 9. And, it actively deals with no less than 6 different types for handling strings (std::string, char* , old Pascal strings of 3 different types, and some String type that inherits std::string). Oh, and it's slow. C++ didn't even help here. We are past the point where we can talk about technical debt: it's a Big Ball of Mud.

For such a program, I expect a 20 fold reduction. And I bet there are other Chtulu abominations out there that make look this program like a little diamond.

Re: The State of the Art is Terrible

#193

"Most computers today, for all of their potential speed, are largely a mistake, based on the provenly unscalable Von Neumann architecture, controlled with one of the most shortsighted languages of all time, x86 assembly. They are almost unfathomably inefficient." Well put, Sir.

OTOH there are compilers (SBCL) which take that beautiful thing Zach probably likes (Lisp) and run efficiently on the stupid thing he seems to hate (Von Neumann machines)...

Re: The State of the Art is Terrible

#194

Earlier quoted context omitted.

(Off-topic, but if you want to rejuvenate the F#-as-node.js thing, look into FastCGI. It's still a bag of hurt, though - notably, mod_fcgi feels proof-of-concept-y and will not multiplex requests over a single connection. Other HTTP servers apparently do better.)

I got as far as mod_fcgi, but I couldn't figure out how to write a mono program to integrate with it. Found some nice C examples, but nothing for mono. I still think it would be a hell of a great side project -- lots of power and expressiveness in F# that JS doesn't have.

I assume you're aware of http://www.mono-project.com/FastCGI? I suppose you could just implement the FastCGI spec yourself, it's a bit fiddly but not that complicated.

Of course, this assumes you have plenty of time to spend on such projects. ;-)

Re: The State of the Art is Terrible

#196
I used to work on Clinical Trials management software. We had an IVR product written in PHP and PGSQL. Project designers would build a project workflow with a half-baked web "flow chart" and custom PGSQL function that called existing PGSQL functions.

I have a nacent dream of a language that could elegantly replace the workflow definitions with pure code that looked like Lisp or Json. I'd like to work on a program like that.

Re: The State of the Art is Terrible

#197
"Because they know what you are just starting to grasp. That it shouldn’t be like this. That computers have vastly underserved their users. Conceptually, mobile and casual interaction is the future of computing. But it has no formal basis."

"The good tools like functional programming and provably correct algorithms are either too esoteric or too expensive for the mainstream"

I was really with him there.

Then when he said:

"That’s a reason why one of my favorite languages is php. It just works. Screw up your variable typing? Who cares. Forget a symbol somewhere? Heck you still get some output and can see your error."

Is the contradiction there not obvious?

Re: The State of the Art is Terrible

#199
post #168

I'd like to buy Zack a drink, because all of this is obvious to those poor shmucks among us that handle the support end of things (also known as the "shit end"). I've been saying a lot of the same things for years. I'm tired of it now; I'm starting to give up, because it's obvious there isn't a programmer out there that gives a damn. You can try telling them that there's something wrong with software -- something fun…

This may be another flame war, but I don't use IDEs specifically to prevent me from writing the kind of code that I don't want to work on.

You must have used some pretty shitty IDEs then. I use IDEs for the productivity boost, owing to code completion, fast lookups, folding, integrated documentation, syntax highlighting, integrated build system, interactive graphical debugging, integrated source control, project based search, GUI tools, etc.

Of course, all IDEs have their design flaws (like any other piece of software), but the benefits are compelling.

Re: The State of the Art is Terrible

#200
post #145

Earlier quoted context omitted.

That's what hobbies are for - i.e. exploring other interests can make you more well-rounded, and occasionally give you marketable skills.

That's how programming started for a lot of us. Start playing with transistors, then discover 555s, 741s and discrete logic. Eventually discover micro controllers and start coding in assembly and the C. 10 years down, find yourself managing a large team of developers and you absolutely hate it :)

Continuing:

And so you start using your programming skills to travel the world while working, see some amazing places, but discover to your dismay that things aren't any better no matter where you go.

But you continue writing your own stuff, releasing open source programs here and there, and then somewhere along the way you move into freelancing, which removes the protective layer between you and unreasonable customers.

Tiring of that, you move into iPhone apps and discover that you suck at marketing.

And then one day you find yourself living in San Francisco, founding a startup with a bunch of awesome partners, working insane hours, and having a BLAST trying to solve hard problems.

There is much joy and wonder in this world; you just need to look harder.

Post reply on HN