quasi

Microsoft should do an Apple and build the Windows 13 on GNU/Linux.

Agree on the first point, which is why the "for example". Regarding second: standard practices, clear thought, good abstractions, readable documentation are all necessary and have much much more impact on the lack of torture. The OP (and I think you) are saying that indirection can lead to torture and hence avoid using it (the title of the article). Misuse or lack of understanding of any technique, principle et.al will lead us and others to confusion and torture. IMHO there is nothing inherently wrong with using indirection, say, as long as we understand what we are doing (as with a lot of other things). And because, as you so rightly said, impressionable people are reading along with us, we don't want to leave the impression that 'indirection', say, is somehow a villain here.

Isnt this just 'good coding practices'? How is 'Avoid Indirection in Code' justified?

The point made by the article (avoid using due to problems for debugging and code review etc.) does not hold much water. 'Indirection' can be invaluable while separating 'how you got it' from 'what to do with it' (it=some data), for example. 'what you do with it' can remain unaffected by changing 'how you got it'. This will not mess with code review practices but make understanding the pieces easier. It will also make debugging easier as you can test both those pieces independently. What the OP calls indirection is just bad code or meaningless abstraction.

Zed Shaw puts it well: "Abstraction and indirection are very different yet cooperating concepts with two completely different purposes in software development. Abstraction is used to reduce complexity. Indirection is used to reduce coupling or dependence."

multicursors are useful for repeated patterns of text which need simultaneous /editing/. The regex-replace-all is not good enough apparently. Mostly HTML or siblings I would guess (I really hope not code!!). This is mostly /visual/ editing. I have used them and I dont think they are the bees' knees. I dont use mouse much while editing.

They must be made to regret this bullying behaviour : file a case please.

It's about feeding a man vs. teaching him to find his food. All the collected wealth will vanish if we use it to feed people. People/Communities/Governments have to learn to build wealth and not live off it. Some part of this can go into making the land a better place but I think the most important use of it is to make the people proud and want to live better and build more wealth (hence standard of living). A large part of this treasure should be proudly displayed in a fantastic Museum.

I am sure there are other success stories which are not heard. At Cleartrip we had a largish team of Common Lisp programers. We became from new entrant to a number 2 position with software written in Common Lisp. So many myths about lisp were proven plain wrong. * you need to be brilliant to write lisp - none of us were "super" lisp programers with years of experience. We had common sense and nice simple code. * hard to learn lisp - not any more than, say, ruby. Out of the 10 odd lispers we had only 2 had CL exposure. The rest learned on the go. Whichever language / platform you use you have to train your team if they are fresh. * Lisp is slow - haha. * Lisp software is hard to run - haha again. we had months of uptime and we could patch our servers on the go. * Lispers are pricks - We were all normal people who worked together well. Lispers, Ruby guys, JS guys - all.

But still everything was not rosy. * When we started, documentation was a huge problem. We would never have got approved except for Edi, who's efforts were an inspiration and a basis of our stuff. * Library support was sparse. Now it is a lot better. But the community is small. Not that they are all pricks, but they are stretched too thin. If I have seen anything, if they use lisp for work, most of them have to fight daily battles against the anti-lisp crowd which will not look rationally at any good work you have done. * Library management - now much better because of quicklisp (thanks Zach) * For most people lack of a usual ORM and a MVC framework was unthinkable. CLSQL has been a pain point.

Programming in the Lisp environment, with the REPL, is a pleasure. I have had to do php after than and O-M-G - its horrible. All I will say to other fellow Lispers - The naysayers are always present. Trust your instinct. You will enjoy life better if you are able to love what you do.

(Cleartrip does not run on CL now. Java, I think. Because of reasons other than technical IMHO.)

Java is the best example of a not-so-great pudding being pulled along for over a decade (till it became better) just because of a large budget.

ah. To pick on a non-native English speaker's English language prowess - very brave indeed.

You call being slower by a (sometimes) 34 msec over 10000 network io requests as slow ? Most of the io stuff for php etc. is pure C. If you have /any/ non trivial application then the stability and performance of CL systems become apparent. If that is your problem, then try benchmarking string operations of CL vs. the rest of the gang.