Hacker News new | ask | show | jobs
by leoscuro 3309 days ago
I was a foreign language specialist in the military. When we were learning a new language, a few of the students hit a wall because they were approaching the material as "analogous to English." You can't think that way with most non-romance languages.

I'm now doing sysadmin work, and do a little bit of scripting here and there while working on teaching myself Python and C. Do you have any advice to avoid the kind of anthropomorphic thinking you mentioned your coworker does? The last thing I want to do is learn the "wrong way" and potentially struggle to rethink how to code.

4 comments

I've been learning Japanese for a bit over a year now, and while I am still very far away from being happy with my level in the language, I definitely noticed a distinct shift for the better in my understanding of the language and how fast I picked up new grammatical constructs etc when I stopped trying to contrast it to the western languages I already knew.

You have to accept that Japanese grammar might have some basic concepts in common with the grammar of western languages (verbs, objects, adjectives, etc) but that really doesn't get you far.

(for japanese learners reading this comment, the article that pushed the first domino for me was this one: http://www.guidetojapanese.org/blog/2007/09/03/repeat-after-... )

Regarding your question about programming, I'd encourage you to read both The Little Schemer and Structure and Interpretation of Computer Programs.

Speaking as someone who is studying both linguistics and Japanese, this this type of comment is just cringy to read. In the grand scheme of potential "languages" Japanese and English (as well as all natural human languages; including signed languages) have incredibly similar grammars. It is only when you restrict your view to the range of human languages that Japanese and English start to look incredibly different.

With regards to your link. Japanese absolutely has subjects.

The question of presisly what -ga marks is a bit more controversial, but calling it a subject marker is a perfectly defensible position. Indeed, having studied linguistics before studying Japanese, I found that thinking of -ga as a subject marker and -wa as a topic marker made the distinction easy for me.

The point of this comment is not to say that we should be teaching English-native Japanese students that Japanese does have subjects and -ga marks them. I am not qualified to make that judgement, and my benefit likely came as a result of leveraging my linguistic studies.

As others have pointed out, thinking of Japanese as analogous to English is counter-productive for most students. This is despite the fact that Japanese is analogous to English in most cases, including (potentially) cases where seeing the analogy could be counter productive.

Returning to the original article; this is a good indication that just because something is wrong does not mean that it is not useful. Anthropomorphizing might not be technically correct, but it could still be a useful tool to help our human brains make sense of the world or subject matter. In the same way that saying "Japanese does not have subjects" might not be technically correct, but it might still be useful.

> Speaking as someone who is studying both linguistics and Japanese, this this type of comment is just cringy to read. In the grand scheme of potential "languages" Japanese and English (as well as all natural human languages; including signed languages) have incredibly similar grammars. It is only when you restrict your view to the range of human languages that Japanese and English start to look incredibly different.

That seems like a total non sequitur. Do you also find the expression "like comparing apples to oranges" cringey, since apples and oranges are quite similar when compared to black holes?

That might not have been the best way for me to make my point, which is just that, qualitatively, all human languages appear to be incredibly similar. I am not aware of any way to quantify this observation. I do know, however, that children who do not acquire any language during the critical period find it much more difficult to acquire a language as an adult relative to a typical adult acquiring a second language [0]. This means that a native English speaker would be realying heavily of his knowledge of English when learning Japanese (although not necessarily at a conscious level).

I tried to avoid the "apple to oranges" objection you are raising by restricting the domain to that of "potential languages", which seems like the "fair" point of reference to take. Since Japanese and English are both natural human languages, I would consider comparing them more akin to comparing red apples and green apples.

The main point I was trying to make (which admittadly got berried at the end of my post) was that "wrong" and "not useful" are two very different concepts.

[0] This is best observed in deaf children who are not exposed to sign language at a young age.

So what? You understood, and to all appearances agreed with, the point being made ("thinking of Japanese as analogous to English is counter-productive for most students"), right?

The poster clearly wasn't making any broader claim about the "qualitative similarity of all human languages" (whatever that might be).

What a needlessly pedantic and condescending reply
I think your language metaphor works here, but I won't try to extend it for fear of misleading you with anthropomorphism :)

Anthropomorphized code reads like someone reading off a gigantic checklist that keeps getting longer and longer. Each time a new problem comes up, we solve it by adding another "If A then B" except it's something like this

    if foo.bar.baz[0][1]['value']
      if (foo.bar.baz[0][1]['value'] == 'undocumented business rule')
        globalVariable = false # why? who knows
      else
        globalVariable = true

      globalVaraiable = foo.bar.baz[0][1]['value']
Relying on “If A then B” quickly get out of hand. The number of possible paths that your code can take grows quickly, even exponentially depending on the structure of your program. I don't want to be dogmatic, but always be asking yourself if you can structure your code as to avoid relying heavily on conditionals, especially nested ones.

Focus on the problem you're trying to solve, not the operational details of the language or other tools you're using. However, keep exposing yourself to more languages, that are different from each other in semantics, run-times. Learn about different programming paradigms: declarative, imperative, functional, etc, focusing on semantics and not syntax.

Dear god, I think this would be what would drive coders mad if some Lovecraftian old one were a coder. I have a colleague that writes code like that last one. I know he won't change, but I wish he'd at least use a damned switch statement.
Actually the first example looks perfectly reasonable to me. I would have used changes of "if () return" instead of a huge OR, but the result would have been the same.

The second example I can't judge. Probalby the variable name is bad, but not extraordinarily so. It's a lookup table, I can't tell if it is a good or bad idea without know what is being looked up.

Would could possibly be the advantage of hard coding divisibility checks against every prime number? There's so many problems with this. The simplest thing would be to just make an array of primes and iterate through it. There's also faster algorithms to check for primality.
That code is making an array of primes and iterating through it. It's just that the array is stored in instruction memory, and there is no explicit fiddling with indices or pointers.

As for more advanced primality testing methods, I guess it depends on where the the fancier algorithms begin to pay off. It would not surprise me if this simple algorithm was the fastest for any input small enough to be stored in a single machine word.

I think in the second one, a simple list of values that correspond to true would be more reasonable than putting this in your source code, if you just need a look up table. The way the comments are structured though, I wonder if each row an option map, (annotated by the comments along the top)
The second example was a 15 line switch statement that they replaced with a lookup because they thought it would be faster.
These are great, I need to start a collection like this.

Here's something from this codebase, with names and variables altered but for the most part left alone. Note the hardcoded `ajax_max` variable.

https://gist.github.com/anonymous/2d06bd45222999647d99df54fb...

I suppose learning a language that forces you to work in a declarative style (such as Haskell) rather than imperative might be enlightening, but if that's not practical you could try using declarative style in C and/or Python. For instance, don't use global mutable variables and whenever possible write functions that take in const arguments and produce some return value without changing the state of anything.
I'll definitely check out Haskell, thanks for the input!
Another language I might suggest for exposing yourself to declarative / functional programming is Erlang or Elixir. I've tried to learn Haskell myself but the number of new concepts can be really daunting. Erlang is a little easier to get going with, and exposes you to many similar declarative concepts.

http://learnyousomeerlang.com/content

I think the answer here is analogous between spoken and programming languages. When I was learning Japanese the thing that made me grok the grammar was when I stopped "learning" and started imitating - that is, instead of trying to know all the rules needed to translate what I wanted to say from English, when I concentrated on reading lots of sentences in the target language, and saying things in Japanese using the patterns I saw there.

So for programming the same gimmick would amount to, rather than just building code out of the constructs you're most comfortable with, also read code written by experts and try to imitate the patterns you find there.