Suffering-oriented programming (2012)

Re:Suffering-oriented programming (2012) by colechristensen on Wednesday September 05, 2018 @11:29PM (#17923693)

I have experienced quite a lot of people pushing to over-abstract code (abstractions that will are used only once with reuse being wishful thinking for the far future) and very little pushback against as though reaching the "perfection" of abstracted code has a moral high ground.

I would like to balance the difficulty of wading through abstractions with the difficulty of repetitive code, not to act like one difficulty is superior to the other.

[ Parent | on HN ]

Re:Suffering-oriented programming (2012) by watwut on Thursday September 06, 2018 @02:33AM (#17924287)

After working with people who refuse any kind of tiny little abstraction because "abstractions are complicated" and "even splitting it into named functions is step toward being like java", it is no better.

It was high in repetition and whenever you changed something, you had to not forget five places. It was also hard to get the big picture of what was supposed to happen.

There is such a thing as too little abstraction as much as there is too much abstraction.

[ Parent | on HN ]

Re:Suffering-oriented programming (2012) by rabidrat on Thursday September 06, 2018 @03:53AM (#17924595)

Forth is great. It takes both DRY and JIT abstraction to the extreme. Developing software is creating a DSL with a custom vocabulary for the problem space being solved.

[ Parent | on HN ]

Re:Suffering-oriented programming (2012) by feliksik on Saturday September 08, 2018 @01:41AM (#17939600)

Did those happen to be Go developers? Just curious.

Interesting language, but some peculiar fanboys.

[ Parent | on HN ]