Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Programming is Difficult (2014)

joearms.github.io

Post reply on HN
Print view View original

71–80 of 117 posts

Re: Why Programming is Difficult (2014)

#71

Post by nitrogen »

noir_lord wrote: post #49
nickpeterson wrote: post #48

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.

You could probably hack this into an editor with folding support, such as Vim. Just tag each layer with a different folding marker, and bind a hotkey to open/close all folds for that layer.

http://vim.wikia.com/wiki/Folding

Re: Why Programming is Difficult (2014)

#72

Post by foreigner »

sklogic wrote: post #15
WWKong wrote: 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.

We have not seen any theoretical breakthroughs in over 20 years anyway. Unlikely programming is going to change fundamentally. But there is a lot of game changing practical advances which totally overturned the way we design systems. Microcontrollers are powerful and dirt cheap now. Low end FPGAs are more accessible than ever. GPGPU is a dramatic game changer, and it is dead easy to use it these days. RAM is nearly i…

Decent version control! Continuous integration!

Re: Why Programming is Difficult (2014)

#73

Post by engi_nerd »

ScottBurson wrote: post #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 ge…

> This is why I always say that the essence of software engineering is the management of complexity.

Your point is valid, and you can delete the word "software" and make a more general point that is also true.

Re: Why Programming is Difficult (2014)

#74

Post by erichocean »

WWKong wrote: 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.

> The bigger question is, why are we still programming the way we did 20yrs ago?

It's been a problem longer than that, and the culprit (ironically) is Fred Brooks. Yes, the guy we hand the "I didn't get a Turing award, all I got was this lousy Fred Brooks award" T-shirt to people.

If you don't know, Fred Brooks was the manager of the first large scale programming project at IBM that actually tried to use a programming language, as opposed to machine code/assembler and the toolset and paradigms people used with that approach.

Anyway, long story short, the project was deemed a "failure", and this Fred Brooks guy, presumably in a bit of ego-damage control and to save his professional reputation, did something interesting: he claimed that anyone would have failed, not just him, and that there is no possible solution to the problem that fundamentally fixes it. (Literally: "there is no silver bullet.")

Well, Brook's knee-jerk proclamation about killed all research into the "programming is hard" problem at the academic level. People now strive for x% improvement but firmly believe--after literally one bad experience--that fundamental improvement is impossible. But maybe, just maybe, we're "doing it wrong" as it were and we were wrong to give up after literally one bad experience by a pointy-headed boss in CYA mode on a major project.

I firmly believe that we're doing programming wrong, that Fred Brooks was (and is) wrong, and that 50 years from now, we'll look back at a million monkeys (referring to myself) typing out text to the computer and laugh at how primitive we all are today.

Re: Why Programming is Difficult (2014)

#75

Post by merlinsbrain »

xyzzy4 wrote: post #36
merlinsbrain wrote: post #11

Earlier quoted context omitted.

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

Parse is shutting down though.

While I view them as pioneers in the space, the fact that executed their cloud code functionality, and did it well is enough for the rest of us to take it from here :)

Perhaps it's even a part of the (now) open source parse-server?

I am not sure, but as I am building a similar thing I will definitely be having a closer look at their source code in the coming weeks.

Re: Why Programming is Difficult (2014)

#76

Post by rorykoehler »

JustSomeNobody wrote: post #69
mbrock wrote: 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…

What I've seen kill code quality is a) management putting out fires and b) cocky programmers who boast they can do X in a few hours. Ok, sure, any of us can but why don't you take longer and properly refactor the code. Problem is, they've already opened their mouth so now management expects it in a few hours.

Business people care about instant revenue generation therefore the fastest programmer is the highest value one in their eyes. Maintainability and technical debt is an abstract and far off cost through this lens. Agile methodology was developed in response to this but in my experience the move fast and break things mindset it brings usually translates into move fast, break things and then put the broken things onto a ever growing bug database where only the most critical bugs ever get fixed.

Re: Why Programming is Difficult (2014)

#77

Post by [deleted] »

mbrock wrote: 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…

[deleted]

Re: Why Programming is Difficult (2014)

#78

Post by invalidOrTaken »

[deleted] wrote: post #77
mbrock wrote: 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…

[deleted]

>structured programming visual, which is misguided.

Can you expand on this? What is "structured programming"? Why is it misguided to make it visual?

I am working on a tool that could be described as 2D functional programming, so these are not idle questions.

Re: Why Programming is Difficult (2014)

#79

Post by erichocean »

invalidOrTaken wrote: post #78
[deleted] wrote: post #77

Earlier quoted context omitted.

[deleted]

>structured programming visual, which is misguided. Can you expand on this? What is "structured programming"? Why is it misguided to make it visual? I am working on a tool that could be described as 2D functional programming, so these are not idle questions.

Historically, structured programming was developed to eliminate the need for the GOTO statement and gave us the conventional control structures present in most PLs today: for-loops, while-loops, if-then-else statements, switch-case statements, etc.

I think these structures are inappropriate in 2D because they assume a linear, 1D context for understanding.

Re: Why Programming is Difficult (2014)

#80

Post by [deleted] »

invalidOrTaken wrote: post #78
[deleted] wrote: post #77

Earlier quoted context omitted.

[deleted]

>structured programming visual, which is misguided. Can you expand on this? What is "structured programming"? Why is it misguided to make it visual? I am working on a tool that could be described as 2D functional programming, so these are not idle questions.

[deleted]
Post reply on HN