Comment by saidajigumi | Hacker News Reader

Comment by saidajigumi | Hacker News Reader

The innovation tokens concept seems to be a stand-in for both good engineering judgement and iterative exploration of the design/implementation space before committing to a path. I've been in several (successful) startups that leveraged both of these principles to great effect.

Both "innovative" and "boring" can shoot you in the foot. TFA focsues on "innovative" as a risk, but that's just daft. This industry is constantly rolling its lessons learned back into its shipped and shared technology. Ever gone back to a pre-Rails era web/backend codebase and screamed in horror? Ever gone to a "new" shop that never assimilated those lessons, used "boring" technology (thus dodging their shared/encapsulated forms), and recreated the old horror? (personally: check and check)

Trite policies are not a replacement for spending dedicated up-front (and occasional ongoing) time cycling between 1) evaluating/understanding your problem, 2) researching the current state of the art {processes, technology, etc.} related to your problem, and 3) using good engineering judgement to choose the best path then-and-there.

I have seen some incredibly good 'legacy' codebases written with vary old tech. There is a huge advantage when someone works with a technology for 10+ years and knows all the rough edges to avoid and then bakes it into their design.

Java may be the worst example of a ‘bulb’ language I can think of. However, I recently spoke with a team which had an awesome response to all the things I hated about the language. The closest analogy I can think of is mechanics working on popular cars get to the point where they can diagnose problems in seconds because they know the kinds of things that break. Cars come with plenty of sensors to help diagnose problems, but in this case familiarity often beats better tools.

Being an expert at something is not equivalent to saying that thing is boring. One insidious danger of "boring" tools is how they lull developers into complacency.

"You can’t pay people enough to carefully debug boring boilerplate code. I’ve tried." -Yaron Minsky

We are still a freepascal shop and it works flawlessly. Every now and then someone wants to do a rewrite in something fancy, but we really have nothing to gain. The current codebase is actually quite pretty, compiles fast, and is easy to maintain.

New hires don't need more than a week or two to get the gist of everything. The web frontend has been migrated from perl though. It got the job done, but it wasn't pretty and nobody dared touch it.

> Both "innovative" and "boring" can shoot you in the foot.

This is true, but it misses one of the points of TFA, which is that with boring tech you already know the ways it can shoot you in the foot, because lots of people have had their feet shot by it before you came along. You can learn what not to do just by looking around and seeing which sets of feet have the smoking holes in them. With exciting tech, you don't know; you get to be one of the people who discovers those things.

I guess I do know the ways in which CGI-based web applications shoot me in the foot because I wrote them in Python and Perl. Said knowledge is why I no longer use:

1. CGI

2. Python

3. Perl

Did you stop using Python and Perl for performance reasons?

Not the OP, but using TCL in the first .com wave taught me that any language without JIT or AOT support on their toolchains are bad fit for anything that needs to scale.

As such I only use Python for scripting.

PyPy works with most Python code

Please. Don't. PyPy is not mature and still suffers from many deficiencies in python itself and the community.

I'm not a huge fan of Ruby, but Ruby, its community, and rubinius are doing it much better.

I do most of my work in ruby and am a fan of it (less of some decisions it's community makes, but I'm still okay with it)... and I shy away from rubinius because I don't think it has enough to offer to justify the non-boring risk/tax. I don't want to be discovering that some gem I use (perhaps only a couple versions after i start using it) isn't compatible with rubinius. Even if it's a small risk (and I honestly am not sure how much of a risk it is), for what? Slight performance edge? I don't need it. Multi-core parallelism? I usually don't need it, and if I do, I'm going to choose JRuby (reluctantly).

By working most of the time and not all of the time, it is yet another layer to debug.

PyPy is great, but until it gets to replace CPython it isn't something I would advise in production.

This is specific to Tcl, but it is byte compiled [0], and work is ongoing right now to target llvm[1]. To say nothing of punting and coding performance-critical code in C and orchestrating it all via Tcl.

[0] https://www.tcl.tk/community/tcl2002/archive/Tcl2002papers/k...

[1] http://sourceforge.net/p/tcl/mailman/message/33568154/

That isn't nothing new to us old time TCLers.

Well, the LLVM announcement certainly is new. You'll have to forgive me though, I thought you may have been propagating the old "in Tcl, everything literally is a string" trope.

What did you press it into service for in ye old .com boom?

An application server built on top of Apache and IIS modules, targeting Windows and multiple UNIX flavours.

Similar to AOL Server and already using quite a few patterns that people seemed to only have discovered years later with Ruby On Rails, but since Portugal isn't SV no one heard of them.

All critical path routines were actually done in C.

However, eventually the platform was migrated to .NET with focus on Windows.

The founders of this company went on to found OutSystems, with the lessons taken from this attempt.

>for performance reasons?

No. Moving to Haskell did give me much nicer options for concurrency and performance. Was principally about productivity (area under a curve).

I'm willing to bet it was more CGI than Perl or Python that was shooting you in the foot, to be fair :)

I'd have an easier time maintaining a CGI app written in Haskell than I would a Rails app.

“You want to learn from experience,” says Warren Buffett, “but you want to learn from other people’s experience when you can.”

> iterative exploration of the design/implementation space before committing to a path

This is something worth fighting for, but by God, it's a hard fight, both in big corps and smaller "more agile" companies.

Great comment, anyway.

Worse than shops that are still using boring technology, are those that are in some wasteland of inbetween an old technology and a new one.

Reply on news.ycombinator.com