Ask HN: How do you remember syntax?
I have to take written exams about Maple and I am struggling with keeping track of the myriad of commands. Any tricks/methodology I can use?
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.
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.
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.
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.
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.
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.
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.
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.
There are software tools for this, I'm sure, but I would still recommend using physical paper cards.
I only passed Japanese in College because someone taught me how to properly use flash cards.
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.
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.
Solution? For the syntax of a given programming language, just glance at some old source code in that language. Then 99 44/100% done.
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...
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..
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.
Spaced repetition FTW.
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
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."
[1] https://en.wikipedia.org/wiki/Clancy_of_the_Overflow
[2] http://www.wallisandmatilda.com.au/clancy-of-the-overflow.sh...
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.
I personally memorize stuff when I write it down on paper.
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.
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.
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.
I can't speak to the best tools for Maple, but hopefully someone can offer a suggestion.
Remembering syntax in quiz format or spaced repetition cards is perverse.
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).
Though dozens of special forms and hundreds of macros implementing syntax.
A lot to remember. A lot syntax.
The syntax for DEFUN in Common Lisp:
defun function-name lambda-list [[declaration* | documentation]] form*
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])}*])
And so on.
Every Lisp has arbitrary complex syntax due to macros and special operators.
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?
I think the original question was about exams, which is an unnatural thing, and nothing to optimize a lifetime for. Write as much code as you can, study however is most effective for you, and empty your brain when you lay your pencil/keyboard down.
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.
It's not every simple thing but there are some bits that for whatever reason manage to never stick in my head
I don't know why I have that mental block, but I do. There have been some particularly notable cases in the reference book days where I could remember what page number to look at but not the syntactic construct on that page.
This is the "pass by reference" approach :^)
It's really useful to remember some things though like basic server configs to quickly make a site on a hackathon or some libraries for the languages you usually use if you're on a plane with no internet.
I write a lot of go, and it has a relatively easy syntax, but I constantly use my docs key binding to see what a function signature is or what the function even does. There's a lot of meaning behind "read the docs". I don't just do it once, I do it all day.
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.