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

81–90 of 117 posts

Re: Why Programming is Difficult (2014)

#81

Post by nly »

mbrock wrote: post #24
sklogic wrote: post #15

Earlier quoted context omitted.

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…

Yeah, practical and cultural shifts determine how the theoretical foundations come into play. Ten years ago, if you said you were into functional programming, most people wondered if you were crazy and why you didn't just program in a real, normal language. Fifteen years ago, garbage collection was considered slow and mostly only suitable for "scripting." Twenty-five years ago, there was Haskell, Erlang, Common Lisp,…

The matters from each era you mention haven't become any more agreed upon... the hype bubbles just evaporated and reformed elsewhere. Nobody became wiser, the landscape just changed. And, you know, it's probably more interesting to look at the landscape than the architecture anyway.

The 70s brought us computing, the 80s brought us networking, the 90s brought us eCommerce, the 00s brought us social and mobile. I don't think anyone has a clue what the next broad stoke is.

Re: Why Programming is Difficult (2014)

#82

Post by jcoffland »

jacquesm wrote: post #58
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…

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

This is absolutely correct. Maintaining control of your software means maintaining a good understanding of it which requires relentless refactoring. Refactoring without guilt. Too many programmers think they are wasting time when they refractor large parts of their program but this is always necessary.

Re: Why Programming is Difficult (2014)

#83

Post by invalidOrTaken »

erichocean wrote: post #79
invalidOrTaken wrote: post #78

Earlier quoted context omitted.

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

This seems worth remembering:

>Structured programming gave us the conventional control structures present in most PLs: for-loops, while-loops, if-then-else statements, switch-case statements, etc. None of them are appropriate in 2D (but are very appropriate in a 1D program, usually written in text). Historically, structured programming was developed to enable the elimination of the GOTO statement.

However I don't understand how conventional control structures are necessarily inappropriate for 2D. It seems to me that the 1D nature of text is used to map to execution point; even if that point jumps around a lot, it starts at the beginning, moves down by one line unless told otherwise, and ends at the bottom.

In my tool, execution order is determined by dependencies, which is fine because there's no mutation (not by code anyway) so order doesn't really matter. So some constructs---`for`, `while` and `until` for instance---do become obsolete/meaningless.

If and switch, however, remain very relevant. For that matter, switch draws its name from real-life switches in real-life machines, which run on ultra-concurrent physics. But we still find a use for them.

Have I mis-stated or misunderstood you?

As for the 2D similarity of 1D languages, that certainly sounds interesting. By "presenting them in 2D," do you mean something like Blockly? Blockly kind of leaves me cold because it seems like normal code, plus extreme syntax help. I mean, cool and stuff, but we can dream bigger, you know? Anyway, do you mean that imperative, functional, and concatenative all have the same basic made-from-text look when put into something like Blockly, or is there a deeper point I'm missing?

Thanks a ton, btw. I'm always interested to hear what people think on this subject.

Re: Why Programming is Difficult (2014)

#84

Post by radlad »

amatic wrote: post #67
mbrock wrote: post #31

Earlier quoted context omitted.

Yeah, I think the sheer manual friction of moving things around is a big impediment to change. But also, I think there has to be some conceptual basis for us to be able to think about factoring in a clear way, and that kind of intellectual labor is hard on another level. Eric Evans' book on domain-driven design has some examples of programming tasks that generate confusing and unclear code, until the coder together w…

Very smart comment. I've had a long brake from programming and all this functional and lisp stuff is new, and it is not always clear what is the benefit. But is great to see a diversity and experimentation.

Lisp is actually the second oldest programming language (behind Fortran.)

1. https://en.wikipedia.org/wiki/Lisp_%28programming_language%2...

Re: Why Programming is Difficult (2014)

#85

Post by jcoffland »

rorykoehler wrote: post #76
JustSomeNobody wrote: post #69

Earlier quoted context omitted.

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…

If you're afraid you're going to break things then you need to refractor. Fear that changes will break things is a sign of code fragility.

Re: Why Programming is Difficult (2014)

#86

Post by [deleted] »

rorykoehler wrote: post #76
JustSomeNobody wrote: post #69

Earlier quoted context omitted.

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…

[deleted]

Re: Why Programming is Difficult (2014)

#87

Post by erichocean »

invalidOrTaken wrote: post #83
erichocean wrote: post #79

Earlier quoted context omitted.

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.

This seems worth remembering: >Structured programming gave us the conventional control structures present in most PLs: for-loops, while-loops, if-then-else statements, switch-case statements, etc. None of them are appropriate in 2D (but are very appropriate in a 1D program, usually written in text). Historically, structured programming was developed to enable the elimination of the GOTO statement. However I don't und…

> I don't understand how conventional control structures are necessarily inappropriate for 2D.

That's just my opinion and I don't have a good justification for it other than to point to a project like Google's Blockly as an example of how it seems to work poorly in practice.

Good luck with your tool! I'm happy people are working on projects like that. :)

Re: Why Programming is Difficult (2014)

#88

Post by jcoffland »

amatic wrote: post #67
mbrock wrote: post #31

Earlier quoted context omitted.

Yeah, I think the sheer manual friction of moving things around is a big impediment to change. But also, I think there has to be some conceptual basis for us to be able to think about factoring in a clear way, and that kind of intellectual labor is hard on another level. Eric Evans' book on domain-driven design has some examples of programming tasks that generate confusing and unclear code, until the coder together w…

Very smart comment. I've had a long brake from programming and all this functional and lisp stuff is new, and it is not always clear what is the benefit. But is great to see a diversity and experimentation.

Algol was created in the same year as lisp.

Re: Why Programming is Difficult (2014)

#89

Post by jcoffland »

amatic wrote: post #67
mbrock wrote: post #31

Earlier quoted context omitted.

Yeah, I think the sheer manual friction of moving things around is a big impediment to change. But also, I think there has to be some conceptual basis for us to be able to think about factoring in a clear way, and that kind of intellectual labor is hard on another level. Eric Evans' book on domain-driven design has some examples of programming tasks that generate confusing and unclear code, until the coder together w…

Very smart comment. I've had a long brake from programming and all this functional and lisp stuff is new, and it is not always clear what is the benefit. But is great to see a diversity and experimentation.

Algol was created in the same year as lisp.

Re: Why Programming is Difficult (2014)

#90

Post by squidbidness »

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.

I do worry about programmers forgetting to check hidden layers even more than we may currently tend to ignore comments, so I worry about this adding parallel maintenance burdens even worse than the common problem of comments getting out of date with the code. Maybe there could be some way to have compile-time diagnostics or static tools to enforce updating of the documentation layers with the code. Though that could add obstacles to adoption, as the tools and meta-concepts would have to evolve along with the layering concept itself.
Post reply on HN