Otaku, Cedric's weblog

The main one for me was functions as values/closures. I was coming from a C/Pascal background and it took me a full day of doing an assignment in Scheme for my programming languages course before I figured out what the big deal was. I have not since been happy programming in any other way.

I was also mystified by PEEK/POKE on the Commodore 64, mainly because I had no manual for it and just copied code out of Byte magazine. I would just change values to figure out what to do with them, but it wasn't until recently that I learned what those operations really did.

Perl for me, I have to re-learn it everytime I want to use it :)
Seriously though I struggle to think of a reason I'd use closures. I have a vague recollection of being totally baffled by peek and poke in my Vic 20 days (I was 8). Having learnt to code such a long time ago I find it hard to remember that programming constructs are highly abstract to most people (non-coders). This became very clear to me recently when I was trying to explain objects/classes to an interested friend.

Regular Expressions. It is amazing what you can do with expressions that look like line noise...

The one thing that gave me serious trouble was the fact how really quite simple it is to talk to periphery in software, in several senses. Assembler mystified me largely because of this; I understood what PRINT does in BASIC, but I couldn’t fit into my mental model how you would go about doing that in assembly. For the longest time I thought I would have to write code that would be directly responsible for driving the CRT. A similar confusion was that I thought compilers translate code by doing something like treating function calls as macros and inlining their code.

I was irritated about the concept of pointers when I first encountered it, but I understood it quickly, and I started to like them very quickly.

(And a while after that I finally started understanding how assembly really works, whereupon I plunged into a several-year obsession with it, writing graphics routines such as a texture mapper. (That was way before 3D graphics cards.))

I also thought fork() was a really stupid approach to process creation when I first encountered it. But I gradually realised why it makes sense, and now I haven’t just gotten used to it, I do in fact think that any other approach is manifestly inferior.

As for continuations… uhm, I understood them before I knew I did. I pretty much came up with the idea independently before I learned that it already existed and already has a name. To be precise, what I came up with on my own is a special case of continuations roughly on par with what’s known as indirect threading in Forth.

Functional programming was difficult for me when I first found it (heavily disguised under Perl’s imperative-looking exterior) mostly because I had to unlearn years of braindamage from Pascal and the rest of the ALGOL posse. But I could taste it right away and I understood it made sense, just not exactly how; I kept at it until I figured it out.

In contrast, understanding object oriented programming was a pain and a half. It took me over a year before I understood it at all; it took me over a decade before I learned about the Replace Conditional With Polymorphism refactor and finally put together how to really use it to good effect. I now find OOP useful for certain kinds of design problems, but I still dislike it and consider it ridiculously overrated.

Definetly:
- Regular expressions. They really look like someone is insulting you...
- Operator Preceence. I did a conversion from C to Java, and after a while HORROR. They don't have the same priority for / and *...

Nightmares :-(

30 years in "The industry"? ?! You've been a professional coder since you were 6? :)

I learned pointers in Pascal as well, and it was every bit as painful. I learned the mathematics of the arithmetic more or less, but without understanding it fundamentally. It wasn't until years later (and a degree in math, not cs) that it really clicked.

Now I routinely encounter senior Java programmers who obviously don't really understand pointers. They can talk about pass-by-reference 'til they're blue in the face, but they'll turn around and want to "optimize" some method by passing an int field of an object, instead of the actual, already-loaded-in-memory object...

Wow, 30+ years. You must be ancient. I'm 43 and I only have 18 years experience.

Second on the learning assembly, then learning about c pointers. And suddenly it dawns on you.. this is not hard, i've done this in assembly.

move.l #$10000,a0
move.l #$10000,(a0)

(68000 assembly, ymmv)

Same thing for continuations, one of the worst memories of a Scheme training.

Now struggling with monads. I'll see if it works better.

I hate Assembley langunage .I couldn't pass the lesson However I worked :(

Trees.

I found quite difficult to develop them, because one has to keep track of several pointers at the same time, and be extremely precise on which pointers to change, and think every single routine in a general way, and it's not even easy to debug, and blahblahblah.

In this days I'm writing B-Tree[s] routines for a database, and I spent several hours just to have a working insertion.
Of course, I love trees ;-)

On the other side, I never had any problem anyway with recursion, pointers, or assembler :-)