7 ms·

The section on "Cult Oriented Programming" is also still very relevant today. You could substitute "Smalltalk" for "React" and it still mostly makes sense. > .

The section on "Cult Oriented Programming" is also still very relevant today. You could substitute "Smalltalk" for "React" and it still mostly makes sense. > ...a programmer's personal preference is more important to getting results than the language or paradigm itself. In other-words, if a programmer can work with the tools and languages that he or she most prefers, then productivity and quality may be much higher than from passing down edicts based on a blanket choice of tool, language, or paradigm. This backs up a lot of what I've seen over the years and I consider it wasteful in the extreme. Maintainable, functional applications are constantly thrown out because programmers don't want to use things they consider "dirty". "Eww, I don't want to go anywhere near that. It's (procedural|PHP|got 'goto' statements|VBA|not the cool thing that everyone's talking about)." Yeah, but this thing works just fine as it is. Your job is to improve it without making it worse for the next person, not Reactify it until you've exhausted somebody else's supply of money on a hunt for unicorns.

sgt101 11y ago
I'd codify this further with the view that subsituting one set of technical debt with another that fits with local trends and personal opinions is bad. The reasons to program in a particular fashion are as weak as "look how elegant that code is" appealing to the asthetic of the text and layout rather than any actual metric of clarity, reusability, interpribility or whatever. Goto considered evil is folk law when it comes down to it, I think it's almost universally believed but the fact that I don't immediately think of a crystal clear quantitative result to underpin the view that jumps in code are bad is telling. I think that some of what is going on here is economics though, coding in the new way gives a good line of patter for the next gig, and we all need to think about the next gig.
- JustSomeNobody 11y ago
  Funny how GOTO is bad, but "break"ing out of a FOR loop is acceptable. The break is a very specific case of a GOTO.
  - mc808 11y ago
    Any kind of loop is just syntactic sugar over a goto. Having looping semantics in the language makes it clear when that particular pattern is being used, and it can prevent bugs that might pop up if everyone was writing their own ad hoc loops. Same thing with break. It makes the intent clear and makes it harder to accidentally stray from that intent. Of course, there's a problem when sometimes you want to stray from the patterns encouraged by the language, but it doesn't provide adequate means to do so.
  - jerf 11y ago
    The essence of badness of GOTO is precisely that it is not "specific". When a higher level language restricts it, it is no longer the "bad goto" that structured programmers warned against. The problem isn't "transferring control flow", it was the ability to do it completely unrestricted.
  - pjc50 11y ago
    Bad GOTO is jumping into a FOR loop in the middle of an entirely unrelated piece of code.
  - acveilleux 11y ago
    Fortran IV would let you GO TO out of a DO loop into a whole different procedure's DO loop. (It didn't have FOR.) But why limit yourself to GO TO to fixed places??? Fortran IV also let you GO TO an arbitrary statement that would only be chosen at run-time "assigned goto". Fortran 77 still has that capability but you can limit it to specifically selected statements and it won't GO TO outside of the current unit (a concept Fortran IV lacked.) Dijkstra's remarks were contemporary of Fortran IV.
jacquesm 11y ago
Funny you should write that. One company I looked at was on their fourth rewrite of the system powering their main revenue stream. Every rewrite (by the usual suspects, proponents of some technology with a good babble but less than stellar tech chops) led to a reduction of that income stream, users leaving and so on. My first piece of advice was to ditch the current system and revert to the old. This had been purposefully sabotaged by the suppliers of the new system. The only way out was then to go forward and this nearly killed the company.
- arethuza 11y ago
  A previous employer had an application that was very successful (from a business perspective) because it wasn't flexible - they did a lot of acquisitions (one a month at one stage) and if there were any questions around their internal systems they got this application inflicted on them. At first I was horrified (it was ancient, user hostile, completely inflexible) but I actually saw that it worked - the companies being acquired were all in the same industry and their core processes were all pretty much identical (even if the terminology was all different) - so they could all adapt to the new application and it actually ended up working pretty well. More "modern" flexible applications ended up having multi-month/multi-year "implementation" phases as teams tried to change their new application to their existing processes when it was actually easier to standardise the processes around a fixed application.
  - jacquesm 11y ago
    Airline companies typically have ancient stuff running but from a productivity point of view that old stuff beats the 'new' stuff hands down. It just works, has 0 overhead in terms of eye candy and so on. Ok, you can't play minecraft or solitaire on those machines but that's probably a benefit.
    - mipmap04 11y ago
      Also, on those old systems running IBM RPG and other "green-screen" UIs, it's really impressive how fast users can navigate the system via keyboard commands when they are forced to not have a mouse.
krylon 11y ago
> Maintainable, functional applications are constantly thrown out because programmers don't want to use things they consider "dirty". "Eww, I don't want to go anywhere near that. It's (procedural|PHP|got 'goto' statements|VBA|not the cool thing that everyone's talking about)." Personally, I really, really don't like Visual Basic. I don't even claim to have anything resembling a rational reason for this attitude. It's deeply ingrained prejudice. And if I have a reasonable alternative to touching VB code, I'll take it gladly. But I've had to touch a few VBA/Excel based "applications" over the last year or two, and I did it. It was no fun at all, but it was still better than rebuilding those things from scratch. In one case, we replaced an Excel sheet crawling with VBA by a PivotTable which does the same job, is more maintainable, the file is a lot smaller and it appears to run slightly faster. There is also a part of me that loves picking up some old code written by somebody who has long since left the company, possibly to solve a problem I do not fully comprehend, and fix some obscure bug or add some minor feature. So far, I'll admit I was quite lucky in that those programs I had to touch were reasonably well written, or at least readable and structured in a sanity-preserving way. But still, it's fun, in a way, and the "dirtier", the funnier; at least as long I have a clearly defined task and get to walk away from it when I'm done. Using the hot new toy that all the cool kinds are using is probably fun, too. But working on a 10-20 year old application that only a handful of people have ever touched, has an appeal that outweighs the distinct lack of sex appeal. Plus, you get to tell some interesting stories about the things you've seen. =)

sgt101 11y ago

I'd codify this further with the view that subsituting one set of technical debt with another that fits with local trends and personal opinions is bad. The reasons to program in a particular fashion are as weak as "look how elegant that code is" appealing to the asthetic of the text and layout rather than any actual metric of clarity, reusability, interpribility or whatever. Goto considered evil is folk law when it comes down to it, I think it's almost universally believed but the fact that I don't immediately think of a crystal clear quantitative result to underpin the view that jumps in code are bad is telling. I think that some of what is going on here is economics though, coding in the new way gives a good line of patter for the next gig, and we all need to think about the next gig.

JustSomeNobody 11y ago
Funny how GOTO is bad, but "break"ing out of a FOR loop is acceptable. The break is a very specific case of a GOTO.
- mc808 11y ago
  Any kind of loop is just syntactic sugar over a goto. Having looping semantics in the language makes it clear when that particular pattern is being used, and it can prevent bugs that might pop up if everyone was writing their own ad hoc loops. Same thing with break. It makes the intent clear and makes it harder to accidentally stray from that intent. Of course, there's a problem when sometimes you want to stray from the patterns encouraged by the language, but it doesn't provide adequate means to do so.
- jerf 11y ago
  The essence of badness of GOTO is precisely that it is not "specific". When a higher level language restricts it, it is no longer the "bad goto" that structured programmers warned against. The problem isn't "transferring control flow", it was the ability to do it completely unrestricted.
- pjc50 11y ago
  Bad GOTO is jumping into a FOR loop in the middle of an entirely unrelated piece of code.
- acveilleux 11y ago
  Fortran IV would let you GO TO out of a DO loop into a whole different procedure's DO loop. (It didn't have FOR.) But why limit yourself to GO TO to fixed places??? Fortran IV also let you GO TO an arbitrary statement that would only be chosen at run-time "assigned goto". Fortran 77 still has that capability but you can limit it to specifically selected statements and it won't GO TO outside of the current unit (a concept Fortran IV lacked.) Dijkstra's remarks were contemporary of Fortran IV.

jacquesm 11y ago

Funny you should write that. One company I looked at was on their fourth rewrite of the system powering their main revenue stream. Every rewrite (by the usual suspects, proponents of some technology with a good babble but less than stellar tech chops) led to a reduction of that income stream, users leaving and so on. My first piece of advice was to ditch the current system and revert to the old. This had been purposefully sabotaged by the suppliers of the new system. The only way out was then to go forward and this nearly killed the company.

arethuza 11y ago
A previous employer had an application that was very successful (from a business perspective) because it wasn't flexible - they did a lot of acquisitions (one a month at one stage) and if there were any questions around their internal systems they got this application inflicted on them. At first I was horrified (it was ancient, user hostile, completely inflexible) but I actually saw that it worked - the companies being acquired were all in the same industry and their core processes were all pretty much identical (even if the terminology was all different) - so they could all adapt to the new application and it actually ended up working pretty well. More "modern" flexible applications ended up having multi-month/multi-year "implementation" phases as teams tried to change their new application to their existing processes when it was actually easier to standardise the processes around a fixed application.
- jacquesm 11y ago
  Airline companies typically have ancient stuff running but from a productivity point of view that old stuff beats the 'new' stuff hands down. It just works, has 0 overhead in terms of eye candy and so on. Ok, you can't play minecraft or solitaire on those machines but that's probably a benefit.
  - mipmap04 11y ago
    Also, on those old systems running IBM RPG and other "green-screen" UIs, it's really impressive how fast users can navigate the system via keyboard commands when they are forced to not have a mouse.

krylon 11y ago

> Maintainable, functional applications are constantly thrown out because programmers don't want to use things they consider "dirty". "Eww, I don't want to go anywhere near that. It's (procedural|PHP|got 'goto' statements|VBA|not the cool thing that everyone's talking about)." Personally, I really, really don't like Visual Basic. I don't even claim to have anything resembling a rational reason for this attitude. It's deeply ingrained prejudice. And if I have a reasonable alternative to touching VB code, I'll take it gladly. But I've had to touch a few VBA/Excel based "applications" over the last year or two, and I did it. It was no fun at all, but it was still better than rebuilding those things from scratch. In one case, we replaced an Excel sheet crawling with VBA by a PivotTable which does the same job, is more maintainable, the file is a lot smaller and it appears to run slightly faster. There is also a part of me that loves picking up some old code written by somebody who has long since left the company, possibly to solve a problem I do not fully comprehend, and fix some obscure bug or add some minor feature. So far, I'll admit I was quite lucky in that those programs I had to touch were reasonably well written, or at least readable and structured in a sanity-preserving way. But still, it's fun, in a way, and the "dirtier", the funnier; at least as long I have a clearly defined task and get to walk away from it when I'm done. Using the hot new toy that all the cool kinds are using is probably fun, too. But working on a 10-20 year old application that only a handful of people have ever touched, has an appeal that outweighs the distinct lack of sex appeal. Plus, you get to tell some interesting stories about the things you've seen. =)