Live data from Hacker News

Why Programming is Difficult (2014)

joearms.github.io

51–60 of 117 posts

Re: Why Programming is Difficult (2014)

#51
Programming is difficult because it is easy.

Here is what I mean. Implementing new functionality where nothing existed before is easy: just figure out what you want the machine to do, and tell it to do that. It isn't trivial, but on a relative scale, it's easy.

Precisely because it's easy to create functionality, we do a lot of it. Our programs grow. As they grow, they get complicated. As they get complicated, it gets to be more and more difficult to understand what they're already doing so that we can make them do something different. So, the less tongue-in-cheek version of my thesis here is that programming gets to be difficult because it starts out being easy.

This is why I always say that the essence of software engineering is the management of complexity. And this is the part that people who have not actually worked on large programs will probably never understand. (As someone once said to me, "what you need to get is that management views programming as primarily a clerical function".) Viewed one-by-one, the tasks seem simple. And yet, somehow, when you put them all together, they're not simple anymore.

Re: Why Programming is Difficult (2014)

#53
I see these posts every so often: "X is hard". Aside from just illuminating the X, I don't really see the point of the posts. Most higher-order jobs are difficult, that's why people train and educate themselves to work in the field. Coding has it's own set of challenges, but I don't think anyone is saying coding something slightly complex is easy. Just like how designing a building is hard, or swimming an olympic time is hard, or solving a complex science equation is hard. If I'm being honest, these posts come off a little whiny.

Re: Why Programming is Difficult (2014)

#54
post #2

In my experience, the overwhelmingly most difficult thing about programming is writing code that makes sense, even after it has gone through a couple rounds of requirements changes and bug fixes. Any concrete coding task can be dealt with straightforwardly enough, but projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. The idea of composability i…

Totally agree. It seems like the driver is the tendency for businesses to think in the short term.

It seems like building only the things that _really_ matter would be a solution. Then time would be more easily allocated to test driven design, composable architecture, state management, and data modeling.

The question then becomes: "what truly matters to build". That's a whole other discussion.

Re: Why Programming is Difficult (2014)

#55
post #19

I don't think programming - in the sense of what 99% of programmers do - is as difficult as programmers love to blog about. Most professional programmers write stuff that is not all that hard, and most of it has been done by others countless number of times. All the "hard" cutting edge stuff is done by a tiny tiny fraction of programmers. Heck even the things people think are cutting edge now, just taking a random ex…

You should write a blog.(hate that word, but we're stuck with it I guess?). I think it's human nature to overstate the difficulty of one's profession? I know my father felt being a union electrician was on par with--strike that; he felt electricians were the boy profession worth talking about. As a electrician, I can state it's basically knowing 40 important codes, the right training, and a strong back.

It's funny how some fields get the difficult label, and some fields get the easy label. I've always felt a good mechanic, whom can work on any aspect of pre obd2 vechicles, and has a good grasp on today's computers on wheels, don't get enough respect.

I belive it comes down to how a subject is taught, and complete honesty. I'll pass this along. Watch repair is not that difficult. In about a year's work of time, and the right tools; the average person could repair watches. Yes, there are odd balls out there, but most high end watches are still using the basic escapement to regulate that train of gears. You open one, and the next one looks familiar.

I do find programming difficult though. My front end work, I don't find that difficult. I've noticed each year Programming tutorials just get better. The books get better. I guess I gave the Internet to thank, and honest/benevolent folks who don't mind spreading information?

Re: Why Programming is Difficult (2014)

#56

Earlier quoted context omitted.

One thing I really liked about the DDD idea of ubiquitous language was that you reduce the amount of artificial abstractions between domain experts and the code, and it forces developers to be able to converse better with the business. I also think we should be doing a much better job documenting the intent of an entire system. New features get added by working them into the narrative of the 'Document of Intent', rat…

Something I've considered on and off is that our current way of writing code is insufficient, I'd really like to have an editor/IDE that had "layers" so that I could attach code related comments in one layer and intent/documentation in another layer - throw in the ability to hide/show layers at will and you'd have a much more flexible way of documenting code than we currently have.

It was possible do it with literate programming for ages. Combine it with emacs, mmm-mode and, say, auctex - and you'll get your IDE.

Re: Why Programming is Difficult (2014)

#57
post #4

It is not difficult, trust me. I know C, C++ , Java and Phyton. It is all about logics and the only thing that differs is the syntax. Get in touch I might help you

> I know C, C++ , Java and Phyton. It is all about logics and the only thing that differs is the syntax.

Those are all basically the same language; if you think only syntax differs, you haven't tried enough languages that are actually different. Try a Lisp, a Smalltalk, and a Haskell and you'll learn they're semantically different, not just syntactic.

Re: Why Programming is Difficult (2014)

#58
post #2

In my experience, the overwhelmingly most difficult thing about programming is writing code that makes sense, even after it has gone through a couple rounds of requirements changes and bug fixes. Any concrete coding task can be dealt with straightforwardly enough, but projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. The idea of composability i…

Complexity creep is something that should be fought tooth and nail where ever you find it. It's the biggest enemy of keeping your code maintainable. As soon as you feel that you're losing track of what is going on you need to step back and re-think your approach and re-factor. If you don't then in the long term you'll lose control completely. It's not a matter of 'if' but 'when' and by the time 'when' rolls around you will end up wishing you had taken care of the problem when it was still tractable. Short term thinking on long term projects is not an option.

Re: Why Programming is Difficult (2014)

#59
post #5

The bigger question is, why are we still programming the way we did 20yrs ago? Higher level languages were a great improvement over machine language. But what comes next? Why don't we have it yet? A decade ago I was setting up database, writing queries, designing forms, writing the code to wire it all up. I still have to do all these steps with more amount of effort today.

I think Backend-as-a-Service providers are a good step towards a place we want to be, although I still think we're not super close to using such services to deploy complex business logic on. Services like parse cloud code and AWS lambda are another step closer. Context: We (me + couple of collaborators) are writing a similar platform for ourselves, although the purpose is dogfood more than $.

Aws lambda does look like a particularly large innovation regarding complexity management. Anyone have stories on using it to share?

Re: Why Programming is Difficult (2014)

#60
post #2

In my experience, the overwhelmingly most difficult thing about programming is writing code that makes sense, even after it has gone through a couple rounds of requirements changes and bug fixes. Any concrete coding task can be dealt with straightforwardly enough, but projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema. The idea of composability i…

> Projects as a whole tend to deteriorate by arbitrary fixes, maintenance patches, and failure to uphold a conceptual schema.

Personally, I think this isn't inherent, but is just an effect of how all the current programming paradigms (procedural, functional, even logic) tend to compose features together by simply sticking more code into each node of the function graph. So code that was originally a single stream of simple definitions becomes a complex mess where each line could have come from a consideration a week ago or a decade ago, and you can't "follow the train of thought" that led to the current state any given function is in.

I think we need to think very differently. A truly aspect-oriented programming language, like Inform7 but not limited to the domain of Interactive Fiction, could allow for "literate programming" that treats a codebase as a linear narrative of feature additions, rather than a mutable graph representing current behavior. You'd actually be able to read a codebase from "beginning to end" and get a sense of what thoughts went into constructing it, in order.

Just reading git commit history won't get you there. Commits aren't the right granularity, for one thing—a log of merged PRs might work better. More importantly, git commits to a codebase are a mix of feature-commits and bug-fixing commits, which horribly muddies your vision of how each feature is defined. What you really want is for features to each be files, and bug-fixes to be commits to those files, such that you can read "the up-to-date edition" of each of the features.

Do note that we already have this in one particular place. This is how database migrations work. We just need code migrations! :)

Post reply on HN