
Ask HN: How do you remember syntax? - noobie
I have to take written exams about Maple and I am struggling with keeping track of the myriad of commands. Any tricks&#x2F;methodology I can use?
======
juanre
I use org-drill, the spaced-repetition tools for org-mode,

[http://orgmode.org/worg/org-contrib/org-
drill.html](http://orgmode.org/worg/org-contrib/org-drill.html)

Combined with org-capture templates is a great tool.

Several commenters are saying that it does not make sense to remember the
myriad commands you need to learn. I disagree. Just as you are much more
efficient when your hands can execute the emacs chords and editing happens
without conscious thought, programming is a much more enjoyable experience
(and it is easier to stay in the flow) when you don't have to stop and look up
your next move.

~~~
jwhitlark
It never occurred to me to look for a spaced repetition tool in org-mode. It
looks like a great tool to improve those corner cases you always have to look
up.

I agree that there are things you should just google, but it's worth
memorizing some thing to speed up your coding, and it's really important to do
that for coding interviews, both for the good impression and the speed up.

------
Jemaclus
Same way you learn anything else: repetition. Practice, practice, practice,
practice, practice.

You'll probably have to make some judgment calls about what's worth keeping in
that cognitive space, though. For commands you use all the time, you should
know the syntax without even thinking about it. For things you use only
rarely, it's a better use of your time to just look it up. If you use it semi-
regularly, look it up, bookmark it, and eventually you'll just memorize it.

~~~
jeremiep
I can't upvote this enough. Its the same as learning to read or write or play
a musical instrument.

You can try to memorize the syntax but that won't give you much understanding
on why things are that way leading to brittle knowledge that quickly goes
away.

Practice, on the other hand, directly develops the understanding and
familiarity with the subject as you get to see hands-on how things work and
when you make mistakes you learn why things are the way they are.

I'm pretty sure almost nobody thinks consciously of how to work their mouth
muscles in order to talk, they just think of the words. That's what practice
gets you.

~~~
akinity
I'm inclined to disagree with repetition. Spaced repetition may be effective
but taking something and describing it in your own words(elaboration) will
help with retention AND comprehension. If you can explain something to someone
else well enough for then to understand it, then you probably understand it
decently enough to be well on your way to memorization.

~~~
jeremiep
True, but to reach that level you need to practice a lot.

You gain that comprehension through practice first and then you polish it by
trying to explain it to someone else.

I know I'll write tons of toy programs to teach myself a concept before I try
to explain it to someone, just like I'll try every position of a scale until I
can effortlessly play it before I try to show it off.

------
ufmace
Do you mean actual syntax, like how to define and call classes, methods,
variables, loops, if-thens, etc? Or API definitions, like the standard
classes, the methods available on them, what classes they return and what you
can do with those classes, the best-practice way to do various things?

You should have a pretty good handle on the syntax after a week or two writing
original code in that language. And other languages get easier after you learn
the first one or two pretty well. But that's the easy part.

The hard part is the API definitions. Most good languages/frameworks have such
massive standard libraries and sets of common add-ons that very few people can
be certain of the details of more than a small portion off the top of their
heads. You tend to memorize a good bit after working on it for an extended
amount of time, but Google and autocomplete will always be your friends.

But for any school-type tests on programming, you'll want to pay close
attention to exactly how they're grading. That may tell you a lot about what
you need to do.

------
Fiahil
> I have to take written exams

Is it still a thing in 2015? In these kind of exams, I used to express my
overwhelming frustration of not having a compiler to check my syntax, by
writing zealously unintelligible working programs. Assuming your corrector
don't want to spend 30 to 45 minutes trying to understand what's going on, or
typing each of your answers to check them, he will probably give you none of
the points (because, you know, if it looks like gibberish, it's probably
wrong). After you have complained several times and show him the working
program on your computer, he will just assume most of your answers are right
and give you points without looking at them. At this point, in the next exams,
just work on a couple of easy answers at the beginning and the most difficult
one in the test. Fill out the rest with legit-looking random things.

~~~
swhipple
They're definitely still being used today, though in my experience, we weren't
docked points for syntax errors where the intent was obvious, except in the
introductory classes where the syntax was one of the criteria being tested. In
the algorithms and math programming courses, legible pseudo-code was often
considered fine.

Pen and paper definitely make it easier for the test administrators to prevent
cheating with resources saved on the computer or using the internet. In one of
the introductory engineering programming courses, which was electronically
submitted in class and auto-graded, there was an issue one semester with
students using TeamViewer during class and having others take the test for
them.

------
hacksparrow
I trick myself into thinking I am inventing the syntax, along with the
justifications for the form of the syntax. It is much easier to remember what
you have created than remembering something someone else has created.

~~~
natrius
This is one of the huge benefits of taking a compilers class. You'll probably
never write one, but you'll understand the languages you use better.

------
csours
Flash cards. Buy some index cards and write your own flash cards. The act of
writing them out does a lot; during review you can tell how far along you've
come. If you have no trouble remembering one, take it out of the deck. Review
the whole deck every day (week, whatever).

There are software tools for this, I'm sure, but I would still recommend using
physical paper cards.

~~~
patrickdavey
If you are after an electronic version (which I am personally very happy with)
[http://ankisrs.net/](http://ankisrs.net/) is fantastic.

~~~
Namrog84
Used this for a lot of cs classes that sadly required a lot of memorization
for tests. I like anki a lot. Would recommend for any study flash card style
app

------
adwf
I don't really. Cheat sheet, official docs and Google do for the beginning.
Then after a while programming in the same language I will just remember bits
and bobs. But even in languages that I've programmed in for years, I still
forget the occasional rarely used function (eg. I rarely use even half of
Common Lisp)

Then there are languages that I used to program - like Perl - but haven't even
touched for years and years. I still claim them as a skill, but I'd need a
good refresher on syntax before starting a new project.

------
codingvelocity
My advice for written exams is just memorize the basics
(conditionals,loops,access control) and also to talk to whoever is grading the
exam prior to you taking it. Often written exams will only deduct minor points
for something an ide/compiler would pick up and knowing this walking into the
exam can let you focus on things more important than syntax

------
jordanpg
It really depends on the nature of the exam.

If it's like the Oracle Java exams, for example, you can expect syntactical
"trick" questions, eg. questions that appear to be about one thing, but are
actually testing your knowledge of some unrelated syntax error.

In this case, you only have repetition at your disposal. Whatever works best,
whatever is most time-effiicient, do it again and again until you are seeing
success numbers that you're happy with. Actual coding is best, but there might
not be time.

On the other hand, if it's a school exam, written by a professor it
(probably/possibly) will be about understanding, and syntax won't be as
heavily tested/scored for. This would be more like a physics test where you
only loose 1 or 2 points for an algebra error early on.

In this case, the answer is coding. Dream up challenges for yourself and solve
them. Guess what will be on the test and solve them. Read examples from your
book and extend them.

------
graycat
I gave up: So many programming languages, I've done a lot of programming in at
least eight, so much similar but not exactly the same syntax, mostly all the
same semantics, so, I just gave up.

Solution? For the syntax of a given programming language, just glance at some
old source code in that language. Then 99 44/100% done.

------
nareshv
1\. Start with the basic syntax/cheat-sheet of the language.

2\. Read instructions as 'that's what they are' and try to come-up with
examples for yourself as why they are like that. (This is a bit creative and
examples are only for yourself so that you can remember it)

3\. once step-2 is done, its going to make it easier to remember things via
your own-made-examples and things will flow smoothly when you see things.

say:
[http://www.maplesoft.com/support/help/maple/view.aspx?path=s...](http://www.maplesoft.com/support/help/maple/view.aspx?path=syntax)

1\. take 'concatenation'. a || b

2\. remember it like you are gluing two things with || thingy. and || thingy
can be remembered as a chewing-gum or anything you like

3\. next time you see || you remember the object (chewing-gum) and it always
leads you to concatenation.

Try it out, it might sound funny. But works..

------
userbinator
I think it's like learning any other language: lots of practice, with
occasional - and hopefully gradually decreasing over time - use of the
documentation.

------
intull
I don't know Maple, can't speak for it. But here are some tips -

1\. Look for patterns - it usually is the case that languages use a particular
pattern in their command/syntax structure.

2\. Remember the reverse - instead of mapping commands to actions, choose one
program you know uses some of them and reverse map actions to commands/syntax.
You may forget the syntax, but you probably won't forget problem statements of
programs.

3\. Think of alternatives. When you have alternative methods in your memory,
it's easier to recollect the actual syntax.

4\. Practice. There's no better teacher than practice. You go out of touch
from one language, you'll actually forget the syntax.

The trick to remember is to find alternative channels that'll aid you to
remember; channels that you're sure not to forget.

------
ColinWright
For simple memorization, Flashcards, spaced repetition, and constant usage.

Spaced repetition FTW.

~~~
nemild
Spaced repetition is great. Have you tried Anki
([http://ankisrs.net/](http://ankisrs.net/))? It's a flashcard app with spaced
repetition. They have desktop and a mobile app, and the latter is especially
useful for any downtime you have. In addition to just flashcards on their own,
I'd try to learn the commands in the context of using them as well.

Have you read Moonwalking with Einstein? There are some good tips there.

Finally, you may want to understand yourself better to decide how you learn
best, as each person is different:
[https://en.wikipedia.org/wiki/Learning_styles](https://en.wikipedia.org/wiki/Learning_styles)

~~~
ColinWright
I wrote my own minimalist spaced repetition system - it was an interesting
exercise to make sure I understood the mechanisms, and got exactly what I
needed. I've recently used to to learn a speech in Norwegian, before that to
learn the poems "Cargoes"[0] and "Clancy of the Overflow"[1][2] - Spaced
Repetition[3] is extraordinarily effective when used well.

With regards learning styles, I quote from the Wikipedia article you
reference:

    
    
        There are substantial criticisms of learning-styles
        approaches from scientists who have reviewed extensive
        bodies of research.  A 2015 peer reviewed article
        concluded: "Learning styles theories have not panned
        out, and it is our responsibility to ensure that
        students know that."
    

[0]
[https://web.cs.dal.ca/~johnston/poetry/cargoes.html](https://web.cs.dal.ca/~johnston/poetry/cargoes.html)

[1]
[https://en.wikipedia.org/wiki/Clancy_of_the_Overflow](https://en.wikipedia.org/wiki/Clancy_of_the_Overflow)

[2] [http://www.wallisandmatilda.com.au/clancy-of-the-
overflow.sh...](http://www.wallisandmatilda.com.au/clancy-of-the-
overflow.shtml)

[3]
[https://en.wikipedia.org/wiki/Spaced_repetition](https://en.wikipedia.org/wiki/Spaced_repetition)

------
jwr
I use languages which have as little syntax as possible (Lisp family,
Clojure+ClojureScript recently), and then I make heavy use of what my editor
(Emacs) tells me when I start typing a function name.

Also, I use Dash.app (highly recommended if you're on a Mac).

Basically, I remember very, very little. In fact, the older I get, the less
syntax and function names I can remember. This is not something I'm worried
about, though — this gets replaced with better intuition and systems thinking.

------
lokio9
In order to prepare for an exam try to make your own "cheat sheet" (I don't
mean to take it to the exam).

I personally memorize stuff when I write it down on paper.

~~~
TheGRS
I'll second this, though I don't believe everyone learns this way. At work and
previously at school I write notes all the time, not so I can look at them
later, but simply so I can recall them better. Something about writing with
pen and paper helps to remember it better in the future.

------
zellyn
I agree with the cramming suggestions, at least for this particular test.

In similar situations in the past (eg preparing for interviews), I've found it
valuable to simulate test conditions: actually try to write a whole solution
out on paper, and only when done, go type it in, see if it works, and correct
the errors. You'll start memorizing things in no time if you make not
remembering them actually annoy you.

------
lokio9
I don't try to memorize syntax on purpose - it happens automatically when you
code a lot in one programming language.

------
geophile
You learn it by using it.

If you have a decent professor giving the exam, he will be more concerned with
mastery of the concepts more than getting the syntax exactly right. Of course,
if you were supposed to be using Maple all semester, it would make sense to
expect you to get the syntax right.

------
JustSomeNobody
Muscle memory. Whatever syntax you are trying to remember, write lots of it.
Lots and lots.

------
regularfry
Write a lot of it. That's all. This includes typing out all the examples in
any textbook you've got to hand. It doesn't matter what you're actually
writing, as long as it's correct.

------
delbel
Just understand the language and have a few generic code snippets available in
your editor. They are called Code Templates or Live Templates in the JetBrain
IDE family, but I'm sure your editor has them as well. I don't know if their
is a standardized code template format (?). Here's an example:
[https://www.jetbrains.com/idea/help/live-
templates.html](https://www.jetbrains.com/idea/help/live-templates.html) That
and jshint/eslint (for my javascript).

------
ownedthx
My unintuitive experience is that I remember .NET 2.0/C# syntax better than
any other language, and it was because Visual Studio had the best tab-
completion around (probably still does).

Perhaps because I never had to switch out to a browser (usually I could just
'tab' to the right answer), I was able to keep the code in front of my eyes
and 'loaded', and somehow etch more corner-case syntax into my brain.

------
WiseWeasel
Typically, you would use a good IDE that autocompletes syntax for you,
displays contextual docs for standard functions, etc. Good tools will make you
much more productive, and let you worry about architecture rather than syntax.
You might have to spend a little depending on the platform, but that
investment is typically well rewarded.

I can't speak to the best tools for Maple, but hopefully someone can offer a
suggestion.

------
Paul_S
Forgive the apparent glibness but: write code every day. Nothing beats
learning by doing.

Remembering syntax in quiz format or spaced repetition cards is perverse.

------
rmetzler
It often helps me to see a BNF if it is available.

------
Mikeb85
Same way you remember grammar and syntax in a spoken language. You see
examples, practice writing it, learn basic forms, etc...

------
DonHopkins
Walking around a memory palace of the BNF or parser state machine.

The bubbles and arrows on the pages of the Pascal User's Manual and Report are
very real places I can go back to in my mind, as real and navigable as my
mental map of Adventure (for what that's worth).

------
Gonzih
In lisp there is almost no syntax. So nothing really to remember :)

~~~
lispm
There is almost no syntax.

Though dozens of special forms and hundreds of macros implementing syntax.

A lot to remember. A lot syntax.

~~~
Gonzih
Yeah, but it's more about macros semantics rathen than syntax in general
sense.

~~~
lispm
Macros implement syntax and semantics. Arbitrary complex syntax. Check out the
complex syntax for DEFGENERIC, DEFCLASS, DEFSTRUCT, defpackage ... LOOP

The syntax for DEFUN in Common Lisp:

    
    
      defun function-name lambda-list [[declaration* | documentation]] form*
    

The syntax for lambda-list then is:

    
    
      lambda-list::= (var* 
                      [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
                      [&rest var] 
                      [&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* [&allow-other-keys]] 
                      [&aux {var | (var [init-form])}*]) 
    

Lisp syntax is not atom | '(' atom* ')'. It's much more complex.

And so on.

Every Lisp has arbitrary complex syntax due to macros and special operators.

------
spencore
It's just practice. Same way you "remember" music.

------
babo
Write code without any IDE, try and learn from it, repeat.

~~~
Zigurd
Probably the right answer, but it's like having to harvest the rubber for your
tires to take a driving test.

------
m52go
Never memorize something you can look up - Einstein

~~~
JoeAltmaier
Wasn't that Feynman?

~~~
Zecc
No, it was Einstein. I looked it up.

------
wener
Lex + Grammar = Syntax ? Lex about worlds, grammar about rules.That's so hard
for me. :P

------
thewhitetulip
don't look at programmming languages as work, use them to write small programs
to do something that you want to do

------
JupiterMoon
Write code. Read code. Debug code.

------
thewhitetulip
by using it in real life to solve problems

------
adultSwim
Practice

------
mbrutsch
I don't. Having been in the industry since the 1980s, I make little attempt to
memorize the intricacies of whatever language my client is using. I know what
I want to do and how I want to do it; Google can remember trivial things like
syntax.

~~~
sleepychu
I'm fully on board with this way of working.

If you only use one language for a long time, though, don't you think you're
better served by avoiding breaking for flow as much as possible?

~~~
jerf
In all seriousness, is there anybody here who can seriously stand up and say
that after working with a language for, say, three months, they still have
frequent problems with the _syntax_ of the language? I don't mean "I
occasionally have to look up an obscure corner case", or "After working with X
for three or four days I do need a moment to recall Y's syntax if I switch
back", but literally after working with a language for a couple of months they
have trouble typing a syntactically correct statement.

I do a lot of Perl programming at work, and even after literally 10 years with
it it still does, every once in a while, manage to surprise me. (This is,
IMHO, a fairly damning criticism, but that's a well-beaten horse.) But I don't
particularly have to think about the simple act of writing a single statement
and haven't for a long time.

It seems to me there's a debate here going on about a total non-problem.

~~~
jghn
Me. I just poste elsewhere in this subthread so will spare the details but
I'll stand up and say that.

It's not every simple thing but there are some bits that for whatever reason
manage to never stick in my head

------
douche
Cram to pass the test, then be okay with forgetting most of it.

1.) Is this something you really want to get deep into your long-term memory?
Are you ever going to use this later? Special-purpose mathematical languages
are not my wheelhouse, but is Maple something that is widely used, compared
to, say R or MatLab or Python, or Mathematica?

2.) In any real situation, you will have the ability to lookup the details on
any function or language feature in your browser or on your phone in seconds.
If you have decent tooling, function signatures, parameter documentation, etc,
should come up automatically in your editor. Memorizing this kind of minutia
is not the best use of your time and abilities. Learn enough to know what is
there, so you know what you have to search for when you need those details.

~~~
knappador
I started to answer this as a language syntax question, but it really seems
like a big API problem. And yeah, just cram them and learn the signatures
well. I'd just read a lot of library code and follow along in some hello-world
scale examples.

