Ask HN: What is the first thing you do when trying a new programming language? | Hacker News Reader

Ask HN: What is the first thing you do when trying a new programming language?

5 pointsjoshes10 comments

Or perhaps more specifically, for some of us: what is the first thing you write when experimenting with a new language?

Whenever I am trying out a new language, I like to tinker around sort of aimlessly, meandering about picking up on intricacies until I feel temporarily fulfilled. But I imagine that some, if not many, of us like to jump right into something specific that helps to provide us with some level of insight that we crave.

So what is the first thing that you write, trivial or otherwise, when you first get your hands on a programming language? What is that first technique you try, that first structure you implement, that first algorithm you hammer out? Is there a certain function or method you like to tackle? Or do you just explore without any real direction?

View on HN

Ostensibly, if I want to learn two languages, I write an interpreter for the one in the other. In reality, I try to make a habit of using it whenever I need to do anything small (from simple arithmetic to implementing some graph algorithm I don't understand yet). Couple this with a habit of looking for better ways to do things that come out clunky and you're off! In real reality, I usually dismiss languages on first sight because I don't like their complicated syntax.

Typically I'm not patient enough to learn a new language very systematically, so instead I find myself following a pattern like this:

1. Hear about how great the macros are that Lisp has or the monads are that Haskell has enough times that I decide I need to try it

2. Independently have the idea for some new weekend project / mashup / potential startup and start obsessing about it

3. Persuade myself that this new language and new project are a match made in heaven and compulsively try to build the one with the other while furiously multitasking through tutorials

4. Get a little wiser and more sober about both of them through the experience

5. Hear about how great the asynchronous I/O is that node.js has...

I look at how it does strings as it seems everything practical involves strings.

If string handling sucks, then I'll probably skip it.

If string handling rocks, then I'll look at IO. If the IO libraries are no good, then I skip it.

Doesn't anyone write "Hello World"s anymore?

I usually write a simple hello world example then make it more and more complicated, usually following with IO next, data structures, networking, etc.

I implement Conway's Game of Life in order to get a feel for the language's merits and its warts.

RTFM

Then RTFSC.

Speaking of which, from the OP:

> what is the first thing you write...

Write the fucking manual.

I realize my short and trite answer might, at first sight, seem like I'm just being an ass, but seriously, the very first thing one should do with a new language is read the documentation. If the documentation is poorly written, you can expect the same of the language it describes, and you are most likely wasting your time.

If the documentation passes the initial sniff-test, then start reading some code. Since you've just learned the basics of the language from reading the docs, code should make sense when you read it. If small programs and algorithms don't make sense, something is wrong, and your second sniff-test has failed. Of course, this might be your own fault if you didn't study the docs well enough, but that's another type of problem.

The third sniff-test is reading the language implementation code itself. Pay special attention to the bootstrap code.

Before you start writing code, you should know how the language is put together and how to use it, or else you'll waste eons digging for your bugs and trying to find the docs to explain what you did wrong.

Most people wouldn't eat sausage if they knew how it was made.

Reply on news.ycombinator.com