

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

Or perhaps more specifically, for some of us: what is the first thing you <i>write</i> when experimenting with a new language?<p>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.<p>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?
======
koningrobot
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.

------
evanrmurphy
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...

------
mathgladiator
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.

------
maushu
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.

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

------
jcr
RTFM

~~~
evanrmurphy
Speaking of which, from the OP:

> what is the first thing you _write_...

~~~
jcr
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.

