Comments for Dysfunctional Programming

Comment on Oracle sues Google over Android and Java by Jason

Jason — Fri, 13 Aug 2010 04:27:54 +0000

So Oracle is using these Java patents to turn into a patent troll? Anti-yay.

Comment on Functional Programming, Reductio by Brendan Miller

Brendan Miller — Fri, 02 Jul 2010 02:34:34 +0000

I also find a mixed style appealing. I don’t see any reason why some parts of a program can be referentially transparent and not others. There are many useful ways to mix functional and non functional code.

The implementation of a referentially transparent function can manipulate state internally for instance, such as stack data, so long as the caller is never exposed to these state changes. Even in C this is very common, in fact recommended.

It seems to me that the case for pure functional programming is usually overstated. It mostly buys you lazy evaluation, but you can get that in other languages as long as you manage it explicitly.

Comment on Best way to learn a Programming Language by Best and Free Programming Ebooks | Dysfunctional Programming

Best and Free Programming Ebooks | Dysfunctional Programming — Sun, 20 Jun 2010 02:54:17 +0000

[...] I wrote my list of some unique programming texts. But on the more practical side, there’s [...]

Comment on Is it better to remain blissfully unaware… by aaron

aaron — Thu, 03 Jun 2010 04:37:03 +0000

I really *really* want to find an answer that isn’t tragic.

One positive side I have seen is that the truly naive don’t try to do advanced things in ‘normal languages’ — the entry cost to do anything is so high, they’ll avoid learning anything they can. This sometimes leads to linear searches of arrays where a hash table would have been better. But fixing that is easy. Large monolithic classes? Eh, at least they tried, and it’s no worse (often equivalent to) everything being global.

What happens when you give the truly naive programmer Scheme? They implement 20 data types using lg(20) levels deep nested lambda expressions. Give them Common Lisp? equally hairy macros. Haskell? They write a really pointless yet obfuscating monad, then blog about how it’s like a taco.

I guess my point is that normal languages are so inefficient that they keep the truly naive from messing things up too quickly!

Comment on Is it better to remain blissfully unaware… by bao

bao — Wed, 02 Jun 2010 19:19:06 +0000

I have similar answers. Other programming languages and environments have given me tremendous insight into software development. They’ve helped me think of core problems instead of getting caught up in syntax. They’ve been sources of inspiration for solutions in other languages. They’ve helped me write elegant code since it’s possible for elegance to flow between languages. They have value even when you can’t use them, even when you can’t really quantify that value.

It’s somewhat depressing using normal languages, but on the other hand I see it as a challenge to produce elegant code in non-optimal languages. I’ve seen others get so used to complexity and verbosity that they simply accept it without any serious thought about how things can improve. There’s always room for improvement, and with that viewpoint feeling depressed is a good thing. It’s tragic when you’re blissfully unaware.

Comment on Best way to learn a Programming Language by Ximo

Ximo — Thu, 27 May 2010 17:59:39 +0000

Awesome list! Thanks for sharing!

Comment on Return-code vs. Exception handling by Szindbad

Szindbad — Mon, 14 Sep 2009 09:40:24 +0000

I do not understand the “set visible last” problem. You need set visible last in any type of error handling, dont you? None of these handling styles will help make this issue more explicit.

What kind of help can that knowledge provide if i know that the developer of the code frament tries to implement error handling? I dont get it.

Comment on Return-code vs. Exception handling by aaron

aaron — Sat, 01 Aug 2009 19:49:19 +0000

Thanks for the feedback.

Regarding #2, Yes, I moved the goalposts intentionally. To cheat. ^_^ You can see this in…

Regarding #1, should set_icon fail (throw), the NotifyIcon will be destroyed before the exception leaves this function. So the ‘set visible last’ issue is improved.

Comment on Return-code vs. Exception handling by Raymond

Raymond — Fri, 24 Jul 2009 07:12:57 +0000

While it’s true that RAII helps immensely, note that (1) you still have the “must set visible last” issue, and (2) you moved the goalposts: The original code was in C#, which does not support shared_ptr nor RAII. (In a GC language, all objects conceptually have infinite lifetime.)

Comment on Memoizer revisited – Python by Den mipsDrams

Den mipsDrams — Thu, 18 Dec 2008 14:48:18 +0000

First of all congratulation for such a great site. I learned a lot reading article here today. I will make sure i visit this site once a day so i can learn more.