Tag Archives: programming

Emacs users are like Terry Pratchett’s Igors

After that, it was really a sky-rocket of productivity. Eventually I would write Elisp casually in between programming on work projects. I would notice that a way of working was repetitive, or that Emacs behaved in a way I just didn’t quite like, or I simply thought of a nice thing that I could add. I’d happily spend anywhere from 30 seconds to half an hour writing some functionality to extend my editing facilities.

more on chrisdone.com.

A peek into the dark and wonderful realm of Emacs.

Extreme Programming, a Reflection

But in the midst of all that hype and churn, those twelve practices have remained. Some of their names have changed a bit. 40 Hour Week became Sustainable Rate. Testing became TDD. Metaphor became DDD. Small Releases became Continuous Integration and Continuous Deployment. But despite these changes the practices remain very much as they were described fourteen years ago.

Uncle Bob looks back at the tremendous success of practices introduces in Kent Beck’s Extreme Programming Explained.

The JavaScript Event Loop: Explained

JavaScript’s event-driven interaction model differs from the request-response model many programmers are accustomed to – but as you can see, it’s not rocket science. With a simple message queue and event loop, JavaScript enables a developer to build their system around a collection of asynchronously-fired callbacks, freeing the runtime to handle concurrent operations while waiting on external events to happen.

Good explanations of the programming model behind JavaScript event loop.

Solving the wrong problem

Suppose 10% of your program is sequential (the rest being parallel) – the time to execute the parallel bit can be shrunk to zero by having sufficiently many parallel processors. But the sequential part will remain.

With 10% sequential code the maximum speedup of your program will be a factor 10. One tenth of the program can never speed up, the time for the other 9/10’s can shrink to zero.

So for Erlang programmers the trick to speeding up their programs is to find the sequential parts in the code.

For anybody who writes sequential code the trick to speeding up their programs is to find the parallel parts in their code

Erlang evangelist explains why the rest of the programming world is wrong.

“My favorite programming language:” Google’s Go has some coders raving

Google unveiled version 1.1 of Go earlier this month, promising a big speed boost. (Kuehnl said he’s already using the new version.) Google, which is also developing a JavaScript alternative called Dart, declined an interview request from Ars about the future of Go. Google noted, however, that Go is used internally by the company for "core infrastructure services; cluster management; large-scale distributed processing, including some uses of MapReduce; [and in] tools for software development."

Because Go doesn’t try to compete with JavaScript on the client, like Dart does, it has a much better chances to succeed, even if it will stay a niche language in the foreseeable future.

Dynamic languages have jumped the shark

Dynamic languages promised an ease of development, a sense of thinking about solving the problem instead of worrying about talking to the computer. And the world fell in love.

Instead, dynamic languages delivered a hodgepodge so wibbly-wobbly it always forces you to think about data types, even about the particular quirks of how this particular language handles certain conversions. Always at the worst possible moment. Nothing is true anymore, you can’t rely on a single thing; without automated tests you’re flying blind, relying on nothing but your raw coding prowess to stave off the always imminent failure.

more on swizec.com.

Yes, you old school people, you may now say “didn’t I tell you so?”.

Temporally Quaquaversal Virtual Nanomachine by Damian Conway

Watch in horror as Damian writes a Perl program to extract square roots using nothing but quantum mechanics, general relativity, and the very fabric of the space-time continuum. Along the way we’ll also investigate: Wittgenstein’s dark secret; the diminishing returns of physical computation; Roman philosophy; when Super Science Adventures go wrong; the greatest Lego kit of all time; the secret identity of Sith; carbon logic vs silicon logic; the giants of 1930’s physics; elementary spin-half quanta under relativistic motion; CAT scans; Will Smith; bongos; drunken bets involving penguins; algorithmic consistency; God’s dice and the problem of free will; intrinsic self-inconsistency; the many worlds outside Copenhagen; and the inventor of stage diving.

Hilarious and educating presentation that demonstrates that Perl is no less crazy (and amazing) than quantum physics.

Why no curl 8

We’ve done 29 minor releases and many more patch releases since version seven was born, on August 7 2000. We did in fact bump the ABI number a couple of times so we had the chance of bumping the version number as well, but we didn’t take the chance back then and these days we havemuch harder commitment and determinism to not break the ABI.

When reading something like this I wonder when our technology will collapse under the burden of backward compatibility and obsolete foundations that nobody understands anymore.

how to make a quick buck

The guy behind the keyboard looks up and says ‘You’re the guy my brother sent, the ‘whizz kid’?’.

So he jokingly tells me that his brother suggests I can fix this, he doesn’t believe it, but he’s willing to give me a chance if I can fix it in the next five minutes. It’s pretty clear that he feels he’s wasting his time and that he wants to get back instantly. The four suits stand aside for a bit so I can get closer to the screen and the keyboard.

Programmers have their tales too.

The comeback of static typing

Contrary to conventional thinking, I actually find statically typed languages to be good for projects that undergo a lot of churn, either because the problem requires an experimental approach or the requirements are hazy (as with the case with a lot of start-ups). Although it’s much easier to start hashing things out in a dynamically typed language, I noticed that as the codebase became larger, it becomes much harder for me to feel confident about the various changes I was making without the presence of proper tests. And, tests are painful to maintain when there is a lot of churn happening. Static typing does not replace tests, but it definitely catches a lot of stupid errors and makes refactoring code really easy. Apart from better IDE support, you also get the confidence that when the code compiles, you can be reasonably sure that atleast syntactically things are alright.

On a JavaScript conference I recently attended, static typing was all the rage, just as dynamic typing was few years ago during the advent of Ruby, Python and JS. Everything old is new again.