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

101–110 of 117 posts

Re: Why Programming is Difficult (2014)

#101

Post by rapind »

sklogic wrote: post #56
noir_lord wrote: post #49

Earlier quoted context omitted.

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.

I used litcoffee* for a while, and it really makes you think about and code for a future reader / maintainer, which is pretty great.

It really slows you down though (good thing?) when trying to dump your ideas into code, especially if you end up writing exploratory code that you later delete (I do this a lot).

I think literate code could be really great however for refactors. Once you've figured out the correct implementation and have the time & hopefully budget to revisit your fast code. Maybe it won't feel like the chore of straight up documentation, and more like the enjoyment of polishing your art.

* http://coffeescript.org/#literate

Re: Why Programming is Difficult (2014)

#102

Post by room271 »

davidjnelson wrote: post #59
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 $.

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

Nothing amazingly innovative, but I've used it a lot at work. For simple jobs/event processing it is amazing as it removes a load of complexity (logging, monitoring, scaling, deploying).

Lambdas tend to be Lambda is also very cheap if you have bursty or just very low-volume workloads.

Re: Why Programming is Difficult (2014)

#103

Post by sklogic »

rapind wrote: post #101
sklogic wrote: post #56

Earlier quoted context omitted.

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.

I used litcoffee* for a while, and it really makes you think about and code for a future reader / maintainer, which is pretty great. It really slows you down though (good thing?) when trying to dump your ideas into code, especially if you end up writing exploratory code that you later delete (I do this a lot). I think literate code could be really great however for refactors. Once you've figured out the correct imple…

Interesting. My experience is different - I write my throwaway code starting with a free form prose, dumping all my vague ideas into a text, which is then filled with a very volatile code to explore the listed ideas. It results in a mess, of course, but a mess with a track of what I tried to achieve.

I'd always rewrite what is left of such an effort from scratch, but it is easy to do so with all the literate brain-dump surrounding my code.

Re: Why Programming is Difficult (2014)

#104

Post by rapind »

sklogic wrote: post #103
rapind wrote: post #101

Earlier quoted context omitted.

I used litcoffee* for a while, and it really makes you think about and code for a future reader / maintainer, which is pretty great. It really slows you down though (good thing?) when trying to dump your ideas into code, especially if you end up writing exploratory code that you later delete (I do this a lot). I think literate code could be really great however for refactors. Once you've figured out the correct imple…

Interesting. My experience is different - I write my throwaway code starting with a free form prose, dumping all my vague ideas into a text, which is then filled with a very volatile code to explore the listed ideas. It results in a mess, of course, but a mess with a track of what I tried to achieve. I'd always rewrite what is left of such an effort from scratch, but it is easy to do so with all the literate brain-du…

Definitely a different approach. I think I will try that. I would imagine you end up refactoring the documentation as much as the code.

I pair quite a bit these days, and this may compliment our process nicely.

Re: Why Programming is Difficult (2014)

#105

Post by allengeorge »

turaw wrote: post #17
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…

Do you think that sort of a problem (incremental changes eroding an initially sound structure) could be fixed with better refactoring tools? It seems like the issue you're describing is that logic is leaking from some parts of the codebase to others, which might be fixable with sufficiently powerful refactorings.

Only in the most trivial cases.

Most systems I've worked on have some overriding architecture and assumptions. The worst quality erosions happen when changes are shoehorned into the code without a complete understanding of those factors: it's likely there'll be semantic mismatch between the new feature and existing components, unexpected bugs, and harder to modify code (because the overall architecture is no longer coherent).

You can mitigate the disintegration by having a maintainer with a strong understanding of the architecture and the problem(s) being solved by the original system. Talking with them can give you a roadmap on how to modify it properly, and if it's even possible to do so while maintaining architectural and design coherence.

Note: my comment is an opinion based on personal experience. I'm not trying to play it off as fact.

Re: Why Programming is Difficult (2014)

#106

Post by imtringued »

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…

When things are easy expectations rise until they reach a point where things become hard again.

Re: Why Programming is Difficult (2014)

#107

Post by soared »

gozur88 wrote: post #62
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.

Why does something come next? Maybe we're already doing it right.

Step 1 in grinding innovation to a halt: Assume you're right and can't be improved.

Re: Why Programming is Difficult (2014)

#108

Post by njharman »

gozur88 wrote: post #63
njharman wrote: post #12

>code that produced it should be cleaned up and documented before the next project was started. A major why waiting to the end to test document and clean up code is a failure. Write beautiful, tested code from the start. Even throwaway code, because half time prototypes, etc end up production.

At most places I've worked there's not much point in documenting everything meticulously at the start. The users don't know what they want yet, and they won't think through the details until they get the first prototype. What makes sense in testing and documentation is really project dependent. What's right for flight control software is very different from what's right for Yet Another Twitter Clone.

I mean programmer documentation, how to build this thing, why was this choice made, what ideas were attempted and abandoned and why, what gotchas, what shortcuts were taken/tech debt incured. A lot of this should be in commit messages and/or "tickets" refed in commit messages. Rest goes into README, code comments.

User docs are completely outside my realm as a software developer.

My point (and strongly held belief) is NO, when you do testing and documentation is not really project dependent. All projects need to do it from the start. Some, flight control software, need more rigorous process. Everything needs to be viewed through ROI. My contention is too many devs underestimate the return of "doing it right" from the start. and overestimate the effort and effectiveness of doing it later/at the end.

Re: Why Programming is Difficult (2014)

#109

Post by aryehof »

I think for those programming complex systems in business and industry, the biggest problem remains how to represent concepts in code.

Even the simplest problem, like a Purchaser placing a Purchase Order for a Product from a Supplier can't be easily modeled and programmed by the majority of software developers - with any sort of predictability based on prior art or their own experience.

At best, we approach a problem with a combination of modular procedural code (modularity via subroutines)(from the 1950's) and structured programming with functional decomposition (from the 1960's).

There is no shortage of technical prowess, but a warehouse system is not based on design patterns, libraries, frameworks, or technologies. Instead, it is based on people, places, things and transactions interacting together to solve a problem.

How to represent real-world concepts and systems (real or abstract) into code, remains the challenge it always has been. We just don't seem to learn any lessons from the past.

Re: Why Programming is Difficult (2014)

#110

Post by Terr_ »

huuu wrote: post #97
Terr_ wrote: post #95

Earlier quoted context omitted.

Augh! Stop reading my mind! I've been working to push DDD-ness on my company for a couple years now, and it's been tough. A contributing factor is organizational: There can be a managerial or "coordinator" layer composed of people who have neither the domain-knowledge of end-users nor the technical-knowledge of programmers. Unless this layer is composed of very good people, what you get are specs that resemble a game…

In my experience some small rules can help to grow towards DDD. For example when the team starts to use immutable model objects everybody is forced to think in a more domain driven way because what happens at the model constuction becomes very important.

Yeah, I've been pushing them to use a lot more immutability / "versioning" of items. Have a mutable copy used for composing purposes, and spawn snapshots from that which are what the rest of the system uses.

The actual way the data is used isn't particularly high-performance or massively-parallel, so it's all about fencing-in crappy logic and avoiding zillion-phase commits.

Post reply on HN