Inflammatory comments on programming
Submitted by raevnos on Thu, 2007-09-20 17:05.
Recursion should be embraced, not shunned.
goto is perfectly okay when used appropriately.
object oriented is not always the the answer.
The people who advocate writing unit tests before writing what they're testing might be on to something.
perl kicks php, python and ruby's behinds.
It even comes close to scheme.
java and C++ are two of the most commercially successful languages around today. They are also quite painful and ugly and awkward compared to many less-popular languages. Mediocrity wins again.
I'm about 95% settling on using scheme to write a new mush server in. But I might still change my mind again and use ocaml. Or erlang.
lisp has too much syntax. ;)
»
- raevnos's blog
- Login or register to post comments
Click 
Recursion should be embraced
Recursion should be embraced as a step to finding the dynamic programming method. If no such method exists, tail recursion should be embraced. Unfortunately, without tail recursion we're well stuck if we want any real depth.
Those who argue against goto forget to argue against break and return, both with similar qualities to goto. They're all handy.
OO is pointless in the majority of cases.
Unit tests are a great idea, but laziness and being in the Deep Code Zone all too often leaves unit test writers far behind.
Perl may be the fastest when executed, but Ruby wipes the floor with it, flexibility wise.
Javascript (on Rhino or the C implementation) is surprisingly a contender with P* and Ruby, as far as language syntax goes, but it really needs more standard library features and better anonymous function scoping.
Scheme is god.
Mediocrity wins in engineers as well as with languages.
I wouldn't write a new MUSH server without incorporating radically different concepts like my old networked mush design - Many servers, one "world". Players would be separate and act as "visitors" in each sub-world. Processes that can "jump" across systems. . .
These are your Father's Parentheses. Elegant weapons, for a more ... civilized age.
--
My kingdom for a minute of silence!
This is inflammatory?
Choose the tool to do the job. The more you know makes the selection more intelligent but not necessarily correct in 2, 3, 5, 10 or 20 years. Philosophy shifts every few years.
Discarding what already works will always be the wrong choice in the short term and likely the long term. New programmers always want to toss away implementations because it is crufty or outdated. I'm not suggesting you fall into that category. Wholesale changes will always result in new and different bugs. I'm prone to the replacement strategy but I'm learning not to fix what already works.
As for languages, I look at operating systems to indicate what works and what doesn't for sheer performance. That's a very coarse metric and there are many others that do particular things well. Know the problem before you make a decision.
If people actually understood what they were attempting to do, they'd choose differently. Instead, they get to work in environments where the choice is already made and the task was due yesterday.
In the so called "open" world, you get new solutions for the same problems solved half-assed just like the previous implementation except in a new language. Those "improvements" churn out an interesting set of improvements but typically are stuck on the same problem the original implementor failed to conquer. Very few projects actually push through the barrier of becoming useful beyond the predecessor.
As for goto, return, break, blah blah blah. Write a solution. No one cares how it works as long as it works, reliably. That crap is for professors and other people who don't actually write code on a day-to-day basis. Tomorrow, a new manual will come out telling you not to use feature X. Frankly, it doesn't f*)()()ing matter. If the code works, it gets used. If it fails, it gets discarded.