How Religion Destroys Programmers | Hacker News Reader

How Religion Destroys Programmers

simpleprogrammer.com

52 pointsjsonmez57 comments

One of the advantages of being a cynic and a pessimist is that I don't go in for these religious attachments to technology, since I know (think) that it's all crap. Just some is more crap than others.

Indeed. I tend to be a bit luddite about such things even. If it is trendy, chances are people are creating lots of crap in it ;-).

In fact my religious approach has been to avoid trends.

This being said, within any framework, there are right ways to do things and wrong ways to do things, and a good, solid programmer in the worst framework in the world (ok, maybe not the worst but close) will beat a shakey programmer in the best.

Hipster programming!

I was writing ColdFusion before it was even cool!

before it was cold

Dude, ruined it.

A great way to become a cynic and pessimist about programming is to get a computer engineering degree. Once you understand computers at the gate & flip-flop level, you realize that most of what people argue about on the Internet is window dressing.

Clearly, then, you're not a true cynic until you understand how transistors work at the quantum level...

Weird, I got an engineering degree, learnt about gates and flip-flops and transistors at the quantum level and still think discussions about tools have merit. Just because there are levels below the one you're using doesn't mean you shouldn't use it.

Explain this. I'm not disagreeing or challenging you. This is interesting and I'd be curious to hear more. What happens at the gate level that makes language-level concerns less interesting?

To me, I think that low-level and high-level computing are fundamentally different in terms of their concerns. You can get multiplier-type effects with successes at the low level (if you're really expert) and that's what pushes Moore's Law, innovations in GPU technology, etc. However, making computers useful to other people (including programmers who, working day-to-day, can't possibly understand all the moving parts) involves an entirely separate set of concerns.

What I think is "just window dressing" is a lot of the business mediocrity that gets dressed up as "scaling" or actual computer science (to the ignorant). The Business tends to overvalue parochial, shallow, and not very transferrable knowledge while undervaluing genuine computer science (much less mathematics). But there is junk at the low (make some mediocre product built with shitty technology 10% faster) and high (business bikeshedding) levels of abstraction.

What I believe low-level computing teaches you is that fundamental computation hasn't changed (architectural or system-level) for decades. We've had Lisp (and its associated software improvements) since the late 50s, protected memory and multitasking since the late 60s (OS/360), virtualization and security since the early 70s (VM/CMS, Bell–LaPadula Model), GUIs/networking since at least the mid-70s (Xerox PARC), and formal computer security models since the mid-80s (Rainbow series). In the last few decades we've seen some dramatic improvements in semiconductor miniaturization, a couple architectural improvements (just off the top of my head, ASLR, W^X, and the Pentium's RISC-to-CISC design, though there are some others), and then mostly a lot of integration (computer+phone, computer+car, computer+plane, etc) and software craftsmanship based on principles developed decades ago. I'm not knocking craftsmanship (we all pay the bills practicing it), but due to design decisions made decades ago (such as the security nightmare that is Von Neumann architecture) we base software quality on how few mistakes individual artisans make rather than design systems that prevent artisans from making mistakes.

Thanks. That's an excellent reply.

What alternatives to the Von Neumann architecture would you want to see, and what are the major differences?

Why do you think VN machines "won", given their deficiencies?

There are two major competitors to the Von Neumann architecture, and then a few speculative ones. The most popular one is Harvard architecture, where code and data are in separate memories (improves security and performance, but makes loading code difficult). Most modern processors operate like a Harvard architecture machine when they are running directly from cache, but they act like Von Neumann machines when they have access to RAM. This means that they get some of the performance benefits, but you need hacky things like W^X to get (partially) the security benefits.

The other one is dataflow architecture, which involves representing programs as a digraph where nodes represent instructions. Data flows through edges from one instruction to the next non-deterministically. This was popular research material in the late 70s and early 80s, but there were efficiency concerns.

IBM (and Von Neumann) also dabbled with making computers that resembled neural networks, but VN passed away before he could dedicate a lot of time to it. AFAIK IBM's neural computer is still in research phase.

I'd say Von Neumann machines "won" for a few reasons. First, Von Neumann consulted for IBM in the department that developed their first commercially-sold computers, so he got a lot of creative control. Second, as Hennessey and Patterson wrote in Computer Architecture: A Quantitative Approach, advocates of Von Neumann computers regarded HA machines as reactionary, implying there was even some religion back then. Third, Von Neumann architecture machines are significantly easier to load programs into. My guess is that a combination of business/political concerns on IBM's part in the 50s and 60s combined with momentum and switching costs is the main reason VN machines continue to win.

Not quite. One thing that is easy to miss is that "more is different" [1], that is, although we might understand the elementary components of a system, when these interact in a large number new phenomena can emerge (e.g. phase transitions).

[1] P. W. Anderson, https://www.sciencemag.org/content/177/4047/393.extract

I'd disagree with you. I have a CS degree, and knowing the basics of Computer Architecture doesn't do anything to people participating in debates over software development tools.

If anything it should make you realize that tooling is very important, as you get to experience first hand the enormous increases of potency each abstraction level gives you, from electronic gates to bit codes to asm to C to Smalltalk or Lisp.

If any of those levels opened up your eyes to the power of tools, why wouldn't it open your eyes to many other technologies?

Some good fundaments for your arguments make sure you can build a good opinion. I like Ruby because its object model is near perfect, I like C# because it's got one of the most powerful syntaxes out there, I like Haskell because of the incredibly pure functional style and I like Javascript because it runs in the browser (of course I write CoffeeScript so I don't have to deal with some of its failures).

Do I think these technologies could be better? Yes, but that doesn't mean they're window dressing, and it doesn't mean I'm not optimistic about them.

Also, I'd definitely argue the crap out of anyone who dares to disagree ;)

If I may float the counter argument:

Sometimes the only way to beat analysis paralysis is to pick something, anything, and then pursue it with religious zeal. (Sometimes even to the point of excluding something you find out later would have been a much better choice)

I can definitely get behind the idea that you shouldn't be an unpleasant bigot about it, but a little dedication doesn't hurt. Its better than "Gandalfing" the merits of this or that technology for longer than it takes to just pick something and get it done.

> Sometimes the only way to beat analysis paralysis is to pick something, anything

Sure.

> and then pursue it with religious zeal.

This does not follow. You can pick something while still being fully aware that you just picked it "because you had to", rather than delude yourself into thinking you picked it because it was the absolute best.

I'd rather use the perl project of the guy who loves perl than the project of the guy who chose it "because he had to". Not sure if I'd want him as a coworker though...

I'm confused. Your original comment discusses a way to beat analysis paralysis, and now you're talking about someone who loves Perl. Is your original comment about a project that needs to get done, and about a way to get it done, or is it about a side-project that one starts just because they love writing it?

It doesn't seem like these two are very similar.

Why? It is quite possible that "because he had to" guy will produce more readable code. There is no reason to care about developers personal relationship with whatever technology.

Important question is whether he is able to produce functional, readable, well-designed code in acceptable speed. In case of projects under time pressure, the important question is whether the developer can do reasonable trade-offs between those expectations (eg. sacrifice the right one).

Agreed. I want the person who hates the language; they're not going to write their code with all the 'neat' things Perl has, so it comes out looking like someone banged their head against the keyboard a few times, or as poetry (Black Perl). They may not write idiomatic Perl (if such a thing exists), but I bet I can follow it.

I do not believe that "delud[ing] yourself into thinking you picked it because it was the absolute best" is the correct interpretation of @noonespecial's comments.

I read @noonespecial's comment as saying that once you pick something, sometimes you should stick with it "even to the point of excluding something you find out later would have been a much better choice".

I think the "with religious zeal" bit was either a mistake or was intended to mean something different.

Maybe, but I still don't see why that's good. If you find something better later on, and it's so much better than it's worth going through the pain of switching, why stick with the old thing?

I don't see where @noonespecial is claiming that "If you find something better later on, and it's so much better tha[t] it's worth going through the pain of switching", you shouldn't switch.

Rather, I interpret it as recognizing both the costs and benefits of switching, as well as the costs and benefits of evaluating costs and benefits.

But then the point becomes trivial. He does say "(Sometimes even to the point of excluding something you find out later would have been a much better choice)".

Indeed, and it's also better than being stuck in the hard-scrabble frontier of perpetual novelty, where you spend more time adjusting to your new tools than getting things done. I've come to see moderate (though not religious) hysteresis in technology choice as a virtue.

I like to look at technology stacks by thinking about what problems I'd like to deal with on a daily basis. You'll encounter different issues in a Java/Hibernate/Oracle environment compared to a Perl/Postgres environment or a pure C# environment. They all have their share of problems (though some more than others, like PHP), and it is possible to write great software with all of them.

Entirely true, but it's worth remembering the flipside: some stacks are better than others. Some have their niche, and some are simply obsolete. Some were the best choice at the time and aren't worth the cost of moving away from, and some need to be abandoned right away or the pain is only going to get worse.

Hear hear!

Let me take the example PHP, since you mentioned it and I don't know enough to have an opinion.

PHP is generally claimed to suck badly. But even I can see that the "haters" on HN generally don't know/discuss the existing PHP frameworks and methods.

If I would look at PHP to evaluate it for a project, I'd look at if it seems fun to use (really important!) -- and if it would be usable with good coding standards and modern frameworks.

The bad things people talk about PHP (bad cruft in naming of methods, kludgy parts) are not relevant if it takes a few hours/days to learn that -- and if a good coding standard can limit yourself to a subset of the language. You need to do that for all languages anyway. (See JavaScript.)

But: One big red flag would be if the language proponents are language war fanatics that vote down criticism of their language/framework while attacking all competition. You probably know which ones I talk about.

> The bad things people talk about PHP (bad cruft in naming of methods, kludgy parts) are not relevant if it takes a few hours/days to learn that -- and if a good coding standard can limit yourself to a subset of the language. You need to do that for all languages anyway. (See JavaScript.)

Javascript is by no means a good language. I think "needs a coding standard and a few hours/days to learn which parts to avoid" is a point against a language - not necessarily reason to rule it out entirely, but a mark in the negative column. There are plenty of languages where this need for a standard doesn't seem to arise, because the obvious way to do things is good enough (e.g. Python).

> But: One big red flag would be if the language proponents are language war fanatics that vote down criticism of their language/framework while attacking all competition. You probably know which ones I talk about.

That's a terrible reason to make any decision. It reminds me of the guy who wouldn't listen to U2 because he didn't like their fans. If you avoid languages that're used by idiots you'll find yourself on a treadmill where you're constantly moving from incomplete language to incomplete language, because as soon as a language gets good enough, idiots will find it and use it.

>>Javascript is by no means a good language

My point was that you have to compare the practical use cases, that is "the good parts" of a language/framework -- not the bad cruft you can avoid. A few hours investment is nothing. (JS still has problems, many are being solved.)

This is trivial of course, but strangely ignored by many on HN with an IQ that probably is the sum of our two's...

>>If you avoid languages that're used by idiots

I wrote that I am suspicious of environments used by language war cultists, intelligence is orthogonal.

(A typical example is someone that starts recommending his favorite environment even when it isn't discussed, as suitable for everything just by its std use cases... Like you :-) )

Edit: Absolutely agree, mercurial.

I think there is a point to be made for avoiding an ecosystem (without necessarily using a loaded word) due to a perception of low quality of available libraries. This has certainly happened to me in the past.

On the other hand, some stacks, I feel, do help with writing better code. But don't fool yourself that there is a silver bullet.

Programming religion is a reflection of the relative inexperience and youth of the average programmer. (At least the average programmer posting on message boards, blogs and mailing lists)

I've been doing IT professionally for 15 years now (how did that happen, I'm old!), and I've been an computer nut for about 25. I think as you grow professionally, you start to recognize that tools are tools, and the best tools depend on the environment, team and task at hand.

I used a handsaw and miter box to cut some moulding this weekend to finish up a home project. I like using hand tools for small projects, but that doesn't mean that my brother-in-law's professional power miter saw is "bad', or that using a hand-saw at a construction site where time=money to "good".

Too be honest, after coding for 20+ years, I'm don't have a particular 'religion', but that probably has more to do with my main bread and butter coming from Coldfusion development.

What I try and be is acutely aware of trends and then try and use them in my spare time or introduce them into my day to day development. So at the moment there is a lot of love out there for Javascript frameworks (AngularJS in particular). I like how it allows your front end to become middleware agnostic.

It's one sexy trend I think is also a lot of fun and gives great results and I'm jumping on board for the next couple of years.

Just remember to try and learn something new everyday :)

Out of curiosity, has ColdFusion turned into what Cobol kind of is, that niche where no one is starting new projects, but a lot of legacy systems still need support, and the price for that support is beaucoup money?

I ask because I actually learned ColdFusion back in the mid to late 90s, but never really did much with it; Perl largely supplanted it in the stuff I was doing, and by the time I entered college, Java supplanted that for web (and actually in industry I'm using a lot of others).

(Not that I want to do that, by any means; I don't have the experience or desire. But curious)

Not so much Cobol, but basically the only places that still use it are profitable companies set up in the early 2000's.

There's nothing wrong with it (although a lot of the time I end up writing Java as CF now compiles to it).

It just doesn't have the user base out there and most companies did the right thing and bit the bullet and migrated to "a nother" technology. In the UK this usually meant .Net

Currently I'm of the impression that we'll end shifting to Python or Java however there is a huge legacy set of code to overcome first.

To me as a language pluralist, none of this particularly sounds like anything new.

My initial programming training was FORTRAN (in 2006!) and I then "taught myself" C++ (I didn't know anything about C++ by the end of it), wrote a ruby-on-rails "site" for a friend, and then got a job writing C# and MS SQL, where I wound up actually writing a lot of Actionscript 2.

This was all while I was still learning about new programming concepts, e.g. I was using lambdas/anonymous functions in Actionscript before I knew that there was anything special or difficult about having inline functions as objects. When I finally tried to write a non-trivial program in C, I started to understand the difficulties and trade offs of all the complex, mutable collection types I had been using in higher level languages. and so on.

I say all this, because when you come into programming on that journey (now rounded off with 3 years of Python-and-C/C++-extensions) you don't have time to develop a religion (that lasts any length of time). It becomes apparent that lots of different technologies work in different circumstances, and that each of them shares a lot of ideas, and have some unique features (good or bad).

That said I do have a preference, indeed I posted a language rant last year[1]. I still think homoiconicity is wicked, even if not always useful - and I've not yet ever written something that anyone uses in lisp.

[1] http://joe-jordan.co.uk/blog/2012/10/one-syntax-to-rule-them...

to be honest with you i always find it suspicious when someone can only program one or two languages. either he doesn't want to or he's not capable of.

there used to be a time where all our scientists used to be philosophs with a lot of proficiency in a lot of different domains. that's not even too far back.

See: maximizing vs satisficing

http://journal.dedasys.com/2006/02/18/maximizers-satisficers...

TempleOS would beg to differ.

One of my fun daydreams is that TempleOS begins to attract followers and becomes a new religious movement of hard core assembly language programmers seeking the SOURCE.

SimpleProgrammer, another site that brings up a box blocking all content ,SUBSCRIBE NOW = Instant Close site

Fully agree. At the end of the day, what matters is delivering a product that works to satisfy a purpose.

The customer couldn't care less what gets used to develop the product.

Technology religion only serves to sell training stuff, fill conferences and entertain ourselves in flame wars.

"The problem with this self-imposed religion is that our technological religion blinds us from the truth."

No. The problem is that this self-imposed religion blinds us from the fact that there is no "truth".

Religious wars are also counterproductive, because they tend to give too much power to the MBA-culture conquistadores who really don't belong in technology, but end up ruling it because engineers are so fractious.

When we have the Scala and Python and Lisp crowds all slugging each other over minor differences in the languages, it generates background FUD in the same way that mechanical collisions create waste heat. Then the MBA-culture colonizers get overloaded thanks to all these disparate overblown accounts of each language's deficiencies, but since they construe their job as Making Decisions, they feel a need to Say Something and make everyone use Java, because it's "the standard". Now there's no Scala and no Python and no Lisp for anyone (at least, at that company).

Religious wars actually lead us to mediocrity, because business people get to make the decisions when we become so fractious.

Slightly off-topic, but would anyone recommend Sonmez's Pluralsight videos - Java Fundamentals in particular?

There is no best, only design decisions.

Relative to a specific purpose, one design decision is often better than another. But something doesn't need to be best to be good enough.

How not following certain direction "destroys" programmer? It is like saying muslims should try to be christians for a year or two.

For example I am Java guy (or more precisely JVM guy), it satisfy all my needs. There are new innovative languages, IDEs, databases, concurrency libraries here... It would take multiple lifetimes just to explore small fractions of that.

It takes years to get efficient at some platform. Other technology also means changing working habits, libraries, IDE, debugging style...

I know C++, PHP, Ruby, JavaScript, Erlang etc are not for me. Not based on some 'religious' arguments, but because I actually investigated it or worked with it at some point.

- C++ language is horrible, there is small island around QT, but most code out there is mess. Not much has changed since my school

- PHP has reasonable runtime, but code culture is atrocious.

- Ruby has horrible runtime, horrible community and code culture even worse than PHP

- JavaScript has not changed much since 1999. Sure there is JQuery and HTML5, but it still sucks.

- Erlang is interesting, but too alien. Plus it is not usable outside of very narrow specialization.

fry meme face Can not tell if serious.

C++...most code in any language is a mess. The language being horrible is an opinion.

PHP can't comment.

Ruby...the community always struck me as a strength for it, honestly. As there are multiple implementations, which are you referring to, exactly?

Javascript hasn't changed since 1999 except for jQuery and HTML5? -Really-? Ecmascript 3 (actually, 2; 3 was standardized in December 1999) is the same as 5, and all the libraries and functionality and approaches and ideas are no different than a time when Geocities was a big thing?

Erlang is alien (fair, but...that's a reason to be dismissive?) and -not usable outside of (a) very narrow specialization-?! It's extremely usable -except- in a few specializations, which the language site even lists for you.

I am serious.

Most people think that learning new languages gives some sort of spiritual enlightenment. But in reality most languages are minefield of legacy problems and hidden traps. The 'boost' or enlightenment usually comes from learning new stuff, not just programming language.

Sure if you like some new clearly designed language (Clojure comes to mind) give it try. But do not expect miracles from 20 years old platform.

I dont want to argue about languages. All languages have to keep backward compatibility and for outsider Java is strange as well. Lets just say that all of those points are my opinion.

I too cannot tell if this is serious -- but the idea that members of religion X enlighten themselves by learning about religion Y is a very interesting one. Perhaps that would go a long way towards solving the massive amounts of religious intolerance and misunderstanding (as well as FUD, which empowers leaders at the expense of followers) that we have to deal with today.

> members of religion X should try religion Y is a very interesting one

Now I can not tell if you are serious. There is pretty bad history with forced conversions. Also in most monotheistic religions it is the worse possible offense to worship other gods.

I'm sorry, but it should be clear from my comment that I was not talking about forced conversions.

However, just to avoid any ambiguity, I've edited to try and clarify what I meant.

Depends what is meant.

In terms of try, as in, convert, no, for obvious reasons.

If you mean observe, learn from, and attempt to find common ground, obviously. Attend services of religions you don't agree with, in a spirit of curiosity, see what practices you can borrow. I mean, the Catholic Thomas Merton found inspiration in Zen Buddhism, and he found the Zen practices, detached from the Buddhist beliefs, worthwhile.

Yes, obviously.

However, just to avoid any ambiguity, I've edited to try and clarify what I meant.

> I know C++, PHP, Ruby, JavaScript, Erlang etc are not for me. Not based on some 'religious' arguments, but because I actually investigated it or worked with it at some point.

> [rest of message filled with religious arguments]

Reply on news.ycombinator.com