Live data from Hacker News

Typing Practice for Programmers

speedcoder.net

161–170 of 172 posts

Re: Typing Practice for Programmers

#161
post #159

I don't feel that I need it but I thought I'd give it an honest try and follow the instructions. I never realized it but when it comes to curly braces and other keys in that corner "{ [ ] } \". I would take my hand off and use my ring and middle finger. Therefore I was under utilizing my pinky. I also noticed that I tended to use the same shift key for all the letters resulting in weird contortions of my hand. Doing…

I've been touch typing for 20 years at this point and 90 WPM seems crazy to me. I first tried the speed coder site on some Python code and only managed 45wpm. After reading your comment I then went and did a 1 min test on some general text and only managed to hit 55wpm! That said, I've never felt constrained by my typing speed while programming.

Re: Typing Practice for Programmers

#162

If I type more, I make more bugs. But my mom made me take a typing course, the summer before high school, i.e., in 1978. It has had an unexpected benefit, years later: I suffer from eyestrain headaches when I stare at a computer screen for a long time. I can type very fast, including all of the numbers and symbols, but if I slow down just a tiny bit, then I can type quite accurately. As a result, I can type long stre…

It may do you a world of good to see an optometrist and get a pair of single vision (not progressive) prescription lenses adjusted so you see clearly at the distance to your computer screen. If you use a laptop, bring it with you. If you use a desktop with external monitor, measure the distance from your eyes to the screen. But if you are currently doing something like getting up close to the display and squinting so…

Thanks. That's a good idea. I've been planning on doing it for reading sheet music, but an additional prescription for computer reading is definitely worth a try. Right now I wear bifocals, and the problem is that I have to tip my head back to read stuff, which aggravates my neck. So a single vision prescription might just be the thing.

Re: Typing Practice for Programmers

#163
post #132
post #125

Earlier quoted context omitted.

I encourage you to drink heavily. A friend of mine learned to touch-type because he came in to work hung over too many times, and felt queasy switching between looking at keyboard and screen... so it made him learn to touch-type...

Your advice is "drink heavily"? Is this a kind of joke?

I think it was a bit tongue in cheek.

Re: Typing Practice for Programmers

#165

Earlier quoted context omitted.

This is why no matter how much sense it makes to use something like vim or emacs as your primary development editor, I could never justify the amount of time it would take me to actually be totally comfortable and start seeing benefits (beyond just using it for small quick edits at the command line). Typing speed is never the bottleneck. You could double most developers' typing speed when they code and it'd probably…

I'm just curious what code editor do you use right now?

I use the JetBrains family of IDEs (IntelliJ IDEA, PyCharm, RubyMine, PhpStorm, WebStorm) and I'm really happy with them.

I've also been playing around a bit with Atom lately.

Re: Typing Practice for Programmers

#166

Programming is a unique field: if you're doing it right, it should never be dull. Frustrating? Draining? Rage-inducing? Sometimes. But not mind-numbing. Why? Because we can build our own tools. If we find ourselves doing repetitive work, we can build a tool to automate that work. This automation is itself likely at least somewhat interesting. What isn't repetitive and that can't be automated should be interesting as…

Cutler Normal Form! I love it, use it exclusively now on all my projects.

    _Use_decl_annotations_
    PVOID
    TraceStoreAllocateRecordsWithTimestamp(
        PTRACE_CONTEXT  TraceContext,
        PTRACE_STORE    TraceStore,
        ULONG_PTR       NumberOfRecords,
        ULONG_PTR       RecordSize,
        PLARGE_INTEGER  TimestampPointer
        )
    /*++
    
    Routine Description:
    
        This routine allocates records from a trace store.  It can be considered
        the TraceStore-equivalent of a calloc()-type interface, in that the record
        size and number of records are specified rather than the total size.
    
        The memory to satisfy the total size is sourced from the trace store's
        active memory map.  If sufficient space is available, allocation is simply
        a matter of adjusting the relevant pointers and returning.
    
        If the required size can't be satisfied by the remaining memory in the
        map, this routine consumes the "next" memory map that has been prepared
        asynchronously in a threadpool if one is available.  If the prepared map
        is not yet available, the allocation fails and NULL is returned.
    
        N.B. This routine should be called indirectly through the TraceStore's
             AllocationRoutine function pointer.
    
        The total size that can be allocated is limited to the maximum size of the
        memory map.  The allocator is geared more toward lots of small allocations
        versus larger ones.
    
    Arguments:
    
        TraceContext - Supplies a pointer to a TRACE_CONTEXT structure.
    
        TraceStore - Supplies a pointer to a TRACE_STORE structure that the memory
            is to be allocated from.
    
        NumberOfRecords - Supplies the number of records to allocate.  The total
            size is derived by multiplying RecordSize with NumberOfRecords.
    
        RecordSize - Supplies the size of the record to allocate.
    
        TimestampPointer - Optionally supplies a pointer to a timestamp value to
            associate with the allocation.  When non-NULL, the 64-bit integer
            pointed to by the variable will be written to the allocation timestamp
            metadata store.  This should be NULL if the trace store is a metadata
            store, or if the trace store's traits indicates that it is a linked
            store (implying that allocation timestamp information will be provided
            elsewhere).
    
    Return Value:
    
        A pointer to the base memory address satisfying the total requested size
        if the memory could be obtained successfully, NULL otherwise.
    
    --*/

Re: Typing Practice for Programmers

#167

Programming is a unique field: if you're doing it right, it should never be dull. Frustrating? Draining? Rage-inducing? Sometimes. But not mind-numbing. Why? Because we can build our own tools. If we find ourselves doing repetitive work, we can build a tool to automate that work. This automation is itself likely at least somewhat interesting. What isn't repetitive and that can't be automated should be interesting as…

Cutler Normal Form! I love it, use it exclusively now on all my projects. _Use_decl_annotations_ PVOID TraceStoreAllocateRecordsWithTimestamp( PTRACE_CONTEXT TraceContext, PTRACE_STORE TraceStore, ULONG_PTR NumberOfRecords, ULONG_PTR RecordSize, PLARGE_INTEGER TimestampPointer ) /*++ Routine Description: This routine allocates records from a trace store. It can be considered the TraceStore-equivalent of a calloc()-ty…

I wish there were explicit pre- and post-condition sections. The pointer-typedef stuff never made much sense to me either.

Re: Typing Practice for Programmers

#168

Earlier quoted context omitted.

Cutler Normal Form! I love it, use it exclusively now on all my projects. _Use_decl_annotations_ PVOID TraceStoreAllocateRecordsWithTimestamp( PTRACE_CONTEXT TraceContext, PTRACE_STORE TraceStore, ULONG_PTR NumberOfRecords, ULONG_PTR RecordSize, PLARGE_INTEGER TimestampPointer ) /*++ Routine Description: This routine allocates records from a trace store. It can be considered the TraceStore-equivalent of a calloc()-ty…

I wish there were explicit pre- and post-condition sections. The pointer-typedef stuff never made much sense to me either.

I'm definitely on-board these days with the typedef-everything approach used by NT. Every public function gets a typedef with SAL annotations exposed in the module's public header file, e.g. in this case, TraceStore.h has:

    typedef
    _Check_return_
    _Success_(return != 0)
    PVOID
    (ALLOCATE_RECORDS_WITH_TIMESTAMP)(
        _In_     PTRACE_CONTEXT  TraceContext,
        _In_     PTRACE_STORE    TraceStore,
        _In_     ULONG_PTR       NumberOfRecords,
        _In_     ULONG_PTR       RecordSize,
        _In_opt_ PLARGE_INTEGER  TimestampPointer
        );
    typedef ALLOCATE_RECORDS_WITH_TIMESTAMP *PALLOCATE_RECORDS_WITH_TIMESTAMP;
    typedef PALLOCATE_RECORDS_WITH_TIMESTAMP \
        volatile VPALLOCATE_RECORDS_WITH_TIMESTAMP;
That allows me to include it in a public struct via:

    typedef struct _TRACE_STORE {
        ...
        VPALLOCATE_RECORDS_WITH_TIMESTAMP AllocateRecordsWithTimestamp;
        ...
    } TRACE_STORE, *PTRACE_STORE;
Basically I've resigned to living with the ugliest possible function typedefs, complete with SAL annotations and whatnot, at the benefit of much cleaner interaction elsewhere in the code, e.g. to call it I'd just do:

    Foo = (PFOO)TraceStore->AllocateRecordsWithTimestamp(
        TraceContext,
        TraceStore,
        4,
        sizeof(*Foo),
        &Timestamp
    );
_Use_decl_annotations is a life saver.

Re: Typing Practice for Programmers

#169

Earlier quoted context omitted.

I wish there were explicit pre- and post-condition sections. The pointer-typedef stuff never made much sense to me either.

I'm definitely on-board these days with the typedef-everything approach used by NT. Every public function gets a typedef with SAL annotations exposed in the module's public header file, e.g. in this case, TraceStore.h has: typedef _Check_return_ _Success_(return != 0) PVOID (ALLOCATE_RECORDS_WITH_TIMESTAMP)( _In_ PTRACE_CONTEXT TraceContext, _In_ PTRACE_STORE TraceStore, _In_ ULONG_PTR NumberOfRecords, _In_ ULONG_PTR…

Oh, sure. I miss SAL terribly. The consensus outside Microsoft seems to be that we need annotation-less static analysis because developers will never add annotations --- annotation-less static analysis, IME, has a much higher false positive rate than prefast. Windows is proof that extremely robust static analysis works.

Back when I was in Windows, the system was so robust that if the static analyzer reported on your code, it was your code that had the problem, not the analyzer. It did bounds checking, nullability analysis, and tons of useful stuff. It's fantastic.

The thing about NT-style pointer typedefs is that they discourage const-correctness: it's enough of a pain to make a PFOO. You want a PCFOO too? That said, I'd be more than happy to live with poiner typedefs if I got SAL back.

BTW, I also used a hacked-up cc-mode that understood all the SAL annotations and fontified them using font-lock-keyword-face. It worked great.

Re: Typing Practice for Programmers

#170

Earlier quoted context omitted.

I'm definitely on-board these days with the typedef-everything approach used by NT. Every public function gets a typedef with SAL annotations exposed in the module's public header file, e.g. in this case, TraceStore.h has: typedef _Check_return_ _Success_(return != 0) PVOID (ALLOCATE_RECORDS_WITH_TIMESTAMP)( _In_ PTRACE_CONTEXT TraceContext, _In_ PTRACE_STORE TraceStore, _In_ ULONG_PTR NumberOfRecords, _In_ ULONG_PTR…

Oh, sure. I miss SAL terribly. The consensus outside Microsoft seems to be that we need annotation-less static analysis because developers will never add annotations --- annotation-less static analysis, IME, has a much higher false positive rate than prefast. Windows is proof that extremely robust static analysis works. Back when I was in Windows, the system was so robust that if the static analyzer reported on your…

Ah, yeah, const-correctness definitely gets way more tedious, but eh, just like the ugly as sin typedefs, I think it's a net win.

I've been contemplating doing a little project that scans all the SDK/DDK headers for SAL annotations in use and making a big cross-reference where you can, like, click on the #defines in and see all the places where there are real examples of it being used.

Some of the complex uses are really hard to grok just from MSDN documentation alone; I've found looking around at the WDK/DDK headers much more useful.

Unrelated question: why'd you leave Microsoft? Were you doing NT kernel development there? Is that what you've done in the past?

Post reply on HN