Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you remember syntax?
61 points by noobie on Sept 20, 2015 | hide | past | web | favorite | 77 comments
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?



I use org-drill, the spaced-repetition tools for org-mode,

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.


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.


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.


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.


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.


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.


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.


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


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.


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.


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.


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.


Flash Cards are great. I recommend using actual cards and carrying them around with you everywhere you go. Whenever you are in line for something or just waiting around pull them out and flip through them.

I only passed Japanese in College because someone taught me how to properly use flash cards.


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


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


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.


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


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.


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.


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

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


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


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.


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

Spaced repetition FTW.


Spaced repetition is great. Have you tried Anki (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


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

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

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

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


Derek Sivers's article[0] on SRS for learning a programming language is a good read.

[0] https://sivers.org/srs


Spaced repetition - first time hearing about that. Thanks!


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.


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.


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.


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.


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


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.


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


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.


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 That and jshint/eslint (for my javascript).


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.


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.


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.


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


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


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


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


There is almost no syntax.

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

A lot to remember. A lot syntax.


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


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.


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


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


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


Never memorize something you can look up - Einstein


Wasn't that Feynman?


No, it was Einstein. I looked it up.


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


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


Write code. Read code. Debug code.


by using it in real life to solve problems


Practice


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.


Seconded. I look up basic syntax all the time of languages I use daily for years. It's been that way since I started coding 25 years ago. At least these days it's easier with Google and such instead of having to lead throughout reference books.

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.


>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 :^)


That reminds me of my CS prof. He had been programming forever and said that one of the first languages he learned (Ada? Fortran? Can't Remember.) was a "two knee" language - meaning that you had to have a reference book open on each knee in order to write it!


That's a good term. Of the two, Fortran is relatively simple, while Ada has quite an expressive type system and built-in concurrency constructs, so I'd bet on it being Ada.


I'd like to blame it somewhat in being a heavy polyglot but I was always like this


I guess you don't remember it because you consider it to be trivial and discard it as noise disturbing you from what you are focusing on (eg. algo).


same here, I really have to jump between, c/c++, c++ CLI, c#, javascript, vb.net, vb, SQL (which is not exactly the same on MySQL, MS SQL, MS SQL Azure), python, jade, powershell. it is impossible for my little brain as I know it so far to remember every syntax; I stay focus on the algorithm (to be efficient, O(n), O(nlogn)), on the problem to solve, on code simplicity and maintainability and just go quickly to language syntax documentation as often as I need it. google makes things much easier, there were times when google was faster in finding msdn doc pages then msdn search itself :))))


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?


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.


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


Write a lot of code, and you'll remember the things that you happen to be doing whether you're trying or not. The rest, look it up (because you have to after all). For me, with the small brain that I have, trying to learn and remember everything about a language is a waste of time that is better spent building whatever's in front of me.

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.


My somewhat faulty short-term memory retains the information once it's in active use. I reckon it's like some sort of "brain cache with garbage collection". For example, I've been in Ruby for the last 3 years, and I don't have to google syntax as often as I did 2 years ago. Compare that with my last gig, writing pawn software. I used to know pawn laws quite well, now I'd be hard pressed to recall mush of that info.


I sometimes intersperse lines of pseudo-code if I don't already know what the syntax is, then go back and implement it properly when it looks like I've got everything else in place.


You'll just learn the syntax automatically in that case.


That's the Google Effect.

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.


While this has more to do with library than actual syntax, I install vim plugins that allow Shift-K to bring up docs for a function or keyword my cursor is over.

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.


What is the plugin(s) that you are using? Does it tie into Dash or Devdocs or just using ctags?


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.


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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: