Profile cover photo
Profile photo
Nathan Typanski
Nathan's posts

Post has attachment
Last 6 months' reading material. Not a bad handful of books.

Post has shared content

Post has attachment
Just read this, and it gave me some really great insight into some of the mental hiccups that affect me as a developer (and a human being), and what I can do to actually overcome them.

I feel inspired and refreshed after reading it. If you write software, give it a look and I bet you'll be happier for doing so.

Post has attachment
Facebook just open-sourced Haxl, a Haskell library for efficient concurrent data access.

Post has attachment
I don't understand all the fuss HN is making about Python dying. Python has its niche and Go certainly is not a realistic contender to supersede it. Sure, people switching from Python to Go exist, but if they were doing enough with Python that making that switch made any sense, then they weren't really the target market.

I see Python as the "full-featured proramming language" equivalent of Bash scripting. It's a bunch of handy things for common problems, and then a whole bunch of community libraries that solve more specialized problems. It's great for rapidly tying things together, even if those "things" are low-level C code, and also great for sketching out object-oriented designs. When you start getting to the point where speed is a bottleneck, you can either (a) search for ways to make Python faster, (b) write super-fast C code and use it in Python, or (c) port everything to another language. The people choosing (c) either knew Python was a short-term thing for the early project stages or finally found enough resources to where programmer efficiency is no longer the bottleneck for their software.

If I need to quickly rip data apart and patch it together, I use GNU utils, Awk, and all the standard shell stuff. If I have to do a little more, or my code is > 50 lines or so, then Python is a nice choice and I still haven't found a sane alternative.

Post has attachment
Nathan Typanski commented on a post on Blogger.
Took me a while to track this post down. You're surprisingly not the only "Gerald McAllister" on the Internet.

Personally I subscribe to the mindset from esr's "How To Become A Hacker"[1] on issues like these:

> There is perhaps a more general point here. If a language does too much for you, it may be simultaneously a good tool for production and a bad one for learning. It's not only languages that have this problem; web application frameworks like RubyOnRails, CakePHP, Django may make it too easy to reach a superficial sort of understanding that will leave you without resources when you have to tackle a hard problem, or even just debug the solution to an easy one.
> If you get into serious programming, you will have to learn C, the core language of Unix. C++ is very closely related to C; if you know one, learning the other will not be difficult. Neither language is a good one to try learning as your first, however. And, actually, the more you can avoid programming in C the more productive you will be.

I think the general solution to the problem of "frameworks/libraries crippling knowledge" is not really to do everything yourself. If you write everything yourself, at the lowest level possible, you just risk being unproductive.

What I normally find myself doing is referencing the source code for the libraries I use. If I work with some codebase enough, I will eventually find myself delving into the implementation details. Usually this arises when I go "oh, hey, I need some way to solve problem `x`, and library `y` solves problem `x` in a really elegant way, I'm wondering how I can use that knowledge to improve my code without adding a dependency for the whole library."

> Going one step further, should this count as coding, or should it count as something else?

I think one of the big principles among programmers is not repeating work. There is the curse of "not invented here" that has long prevented me from building useful software, and often my only interesting work happens when I reject that attitude and work on top of existing code. Otherwise, I succumb to burnout before the project even sees completion.

> Me personally, I like to learn how the tools work, and then apply those uses when I use tools.

One instance where I found the line significantly blurred between "using a tool" and "hacking at its internals" was my fairly recent switch from vim to emacs. With Vim, the VimL language is so obtuse as to prevent all but the most determined to understand the internals of their text editor.

Emacs Lisp OTOH is self-documenting and is a Lisp dialect. Emacs benefits from a highly established, incredibly expressive extensions language, and I was able to jumpstart into it because it was (essentially) a language that I already knew.

Customizing your tools is a powerful way to make you more productive. I tend toward tools that give me that advantage, because one thing I can't stand is being unable to quickly make improvements to something I use every day.

[1]: <>

Post has attachment

Post has attachment
Early attempts at USB DisplayLink on Arch.
Wait while more posts are being loaded