I don't go out and actively memorize things, not do I know anyone who does. But the syntax you use often gets memorized nonetheless, simply through common use.
Presenting memorization as "learning" is a crippling effect of the limited ways to measure results forced by the accounting needs of the school system.
Memorization is not understanding and is a very small fraction of the possibilities of learning.
So, no, of course we don't. We use the language, use the reference when needed, and little by little, use it less for the beaten paths of our particular use.
Years ago, or perhaps decades ago, when there switching languages every few months wasn't common, yes - syntax was not only memorized, it was second nature. Not only that, but the language influenced how you thought and solved computing problems. I have always felt that it would take about a year to retrain your brain to efficiently program (or rather think) in a new language. Until then, you would structure your code as if it was written in the last language you use, because that's how you break down problems in a logical nature.
There was not a time in the past when switching languages was less common. The tools of the past assumed one would switch between any number of languages; each tool would have its own, often maximally powerful, language. This has become less pervasive as communication and code sharing has become easier, allowing conventions and standards to unify.
I'll shoot off at a different angle from the other posts here. I'm a blue-collar dev doing web development. I feel the syntax of the major scripting languages is relatively small and the amount that you have to know even smaller. Many developers can just shoot from the hip and get by with some doc look-ups along the way and get things done. Maybe you don't know the prettiest syntax, but you can work around it something which works good enough. You could probably significantly strengthen that grasp with a little bit of scheduled time doing nothing but leveling up on syntax. Or maybe you never find the time to do that and you still manage to get things done. And keep in mind that editors help out a bit with this as well.
I find the difficulty in memorizing is in library usage and all the other stuff which is outside of the syntax. When I'm getting kicked in the head, it's maybe trying to remember how to do something in Git. Or maybe I have to remember the sequence of some development process. Or maybe I forgot a password I never bothered to enter in my manager. There's loads of things you get a cognitive beating from, but syntax doesn't strike me as the worst.
Programming since age eight here. I would say that before Google and Stack Overflow were prevalent, really early on, maybe like in the early 90s, I would remember things more. Because the alternative was actually looking through a book, and although I did that plenty of times, it was often more convenient just to remember.
But as the internet got better at instantly providing examples and references and more and more technologies came out and I started using many different programming languages, its at the point where I often Google very basic things if I am tired or just not 100% sure which way the particular language works or about all of the details.
Its essentially using Google/the internet as an extension of my brain. Like, I probably could remember this thing, but why bother? I believe it increases my productivity because it means I can save my "brain juice" or energy for actual problem solving.
Before I had a reference book of the language. Also I would program always in the same language before stack overflow.
Now I switch between so many languages. But still use references. But now it's easier in Dash.app I have references to most of the languages, API, libraries I use. This way if I want to know how to make if then else syntax work in Go or Javascript or Python I can look it up super fast. Same for Libraries and API's.
Now language idioms is something you need to keep on top off. These are better to remember so you can implement it.
In my many decades working as a professional programmer I have never made a conscious effort to try an memorize any information relating to programming.
I would also say that if you are finding yourself spending lots of time trying to memorize programming related information then your approach to programming is probably wrong.
Stuff you use more often tends to get memorized, less common stuff googled when you need it. When it’s memorized you do save a lot of time. I’d say if you’re really experienced in a language you rarely google syntax because 95% of it has become memorized.
I would say no, but actually it’s a bit more nuanced than that. I use many different languages and if I am not actively working in one I might forget some syntax just after a couple of weeks. It only takes about an hour or so of working in that language (and RTFM) to get it all back. I don’t think others have as much of an issue if they’re in a single language all day but I jump around a lot and my hands-on-ness fluctuates.
I do, but I have a terrible memory. I use flashcards to remember names of technologies that are important but that I don't use daily. I create flashcards when I make a mistake in programming, so I'm less likely to make that mistake again. I create flashcards every time I look up information, so that I keep it in mind.
If you have a normal memory, you probably don't need it as much.
One of the best parts of Lisp is the slobber-proof syntax (except in a few well-known oft-complained-about cases). Another is that the hyperspec is published online.
Between the two, there isn't a whole lot of memorization needed. You can still tell a pro's code over a hobbyist, but it doesn't take all that long for the distinction to blur.
I guess practice is a form of memorization afterall.
This is contrary to most of the advice in this thread, most of the folks here probably skew towards the highly skilled, and thus they don't really know what they know since it has been engrained into their muscle memory.
The syntax of a language is difficult to lookup, I don't know what languages are you are using, but I would say yes, you should know 95% of the syntax of the languages are you are coding in.
Furthermore, I think you should be able to switch between idioms in the language fairly fluidly, between functional, oo, data driven, async, iterators, etc.
I can easily switch between C#, javascript and postgres SQL. But when it comes to powershell.. I google every little language construction. It happens to me every 2-3 weeks for a decade. I still cannot remember from the first time how to iterate over collection, how to define collection or hash table. I dont know why I struggle so much to remember it.
My coworker and I feel the same way. We’re both .net devs for over 15 years each. We avoid power shell like the plague. The syntax is ugly and there is a bit too much magic in it.
As a point of comparison, we are both quite happy to use bash so we don’t have an issue with command line tools or scripting languages.
That said, after writing a Windows forms app using powershell, I had a slightly better understanding of it.
I do a lot of code puzzles and code golf which gives me a motivation to learn some obscurer language features. But for professional software development, it's more important to learn the concepts that the language's syntax is encapsulating.
That said, there are a few syntactic snafus I regularly find myself in.
1. I regularly switch between Python and Javascript, so I'm always typing `push` instead of `append` and vice versa.
2. I also switch a lot between Redshift and RDS, so I always forget which functions are exclusive to Redshift and which to Postgres.
I think that if you don’t, you might end adopting superstitious “best practices” to compensate.
For example: Countless engineers I’ve worked with don’t know operator precedence. So tons of ”y = ((i * m) + b);” type stuff. Do not need any parentheses in this case, but if I remove them, then they have no idea what happens... So they litter all math with superstitious parens.
There are so many better examples, but you get the idea. I have suffered “coding standards“ that existed solely because of the devs that won’t RTFM.
I'd think most people would remember * before + from school math, but for other operators the precedence is kind of arbitrary (can vary between languages) and adding parentheses to make it less ambiguous and more readable doesn't seem like the worst idea.
Yes, it can vary, but it’s kind of important. If you don’t know the order of specific operators, or if your language violates math rules, a dev might want to know that instead of resigning to just not know things.
For readability, yes... sometimes, but for readability sake, not “I don’t know what this does without them.”
I’m not just talking about math operators, but logical ones too. I’ve seen people put parens around every “not” because they weren’t sure. There are three essential logical operators. Surely those can be learned at least. And yes... in those cases where readability is an issue, of if they’re necessary, please do add them, but please don’t if you’re unsure what “!a && b || c” does. Seeing “((!a) && b) || c” raises red flags.
They communicate to people who don't know the binding, but perhaps more importantly they don't let you accidentally change order of operations if you change the operators in your computation.
it would be interesting to know the frequency of bugs that are due to mistakes about operator precedence. even by experienced programmers. a lot? do use of parens reduce the frequency?
Not necessarily the syntax of a specific language, but more the ur-syntax of what sort of operations are available to work with and what things they do. A good programmer doesn't necessarily have the exact syntax memorized for mapping over an array, but "it's straightforward to build an array by applying a function to every element of an array" should be there when it's relevant to the problem you're solving.
Language is just a tool. It's important to know which tool is best for which task.
After identifying which language to use, picking up a language usually just takes a day or two max. Memorizing is definitely not a necessity, but is a side-effect when you continuously work using a language for more than a few days.
I can type quickly so if i am not sure of the particular precedence rules or syntactic sugar I dont bother because it is quicker to correctly write something a little more verbose than it is to remember a cute language trick that the poor maintainer also has to look up.
to be productive, you have to minimize the need to rtfm, but you should also be cognizant of any new implementations -- a refresher may sometimes provide a better way.
I recently stumbled on the postgres method jsonb_insert(jsonb,path,value) which is much more elegant than jsonb_set(jsonb,path,jsonb||value) when you just want to add a thing to some json array inside an object.
I hadn't really looked at the docs much since 9.x, I deal with jsonb everyday, so I had what I needed memorized. But despite keeping my installs updated, I had been doing it the hard way for way too long.
I dont think this is required. Every language has some rules but more importantly control structures which are identical but have difference in syntax. ie, take Foreach loop, I almost every time confirm the foreach's language specific syntax. Try jumping b/w php, java, python, js in same day multiple time.
so i will say remembering it is not necessary, but definitely handy thing.
Knowing the features of your language can expand your horizons. I had already been a programmer for years when JavaScript entered a new era, and I thought I knew a thing or two about computing.
With time, I understood that what I had was a lot of memorised knowledge about specific systems. The layout of a Master Boot Record. The numbers to BIOS interrupt calls. Memory addresses.
The transition from Pascal to C that I made at age 12 had only opened my eyes a little. I learned that there is no true distinction between a function and a procedure (subroutine), that statements and expressions are really two sides of the same coin, that a for() loop doesn’t have to enumerate anything, and that pointers, direct memory access and direct access to system calls are a very powerful tool.
For the past 10 years, I found myself repeatedly involved in web development projects. I had minimal interest in JavaScript at first, viewing it as a toy language for simple automations, and I did most of the heavy lifting in PHP and Java Servlets. Gradually, as people began doing more and more “weird” stuff in it, I became more curious.
That’s when I fell into the rabbit hole.
Functional programming, map-reduce, lambda notation, closures, asynchronous code, generators, observables, applying argument lists to functions at runtime, destructuring assignments, spread notation, treating functions as behaviours you can pass around...
Basically, stuff that modern JavaScript has borrowed from languages such as Lisp.
It made me aware that there’s a distinction between computing as a Platonic ideal and computing as a practical discipline. Computing is a set of ideas about information and the logic of manipulating it.
Computer science is a branch of mathematics and information theory. Computer programs are living equations, written in a notation rigid enough that a machine can read them and perform computations with them.
I didn’t have that kind of perspective 10 years ago. My skill as a programmer has taken a very solid step up. Unfortunately, this has also made me overqualified, and I’m often in a situation where I’m doing work that just about any developer with a couple of years’ experience could pull off, and would learn much more from than me because they’ve never done it before.
I’ve come to the conclusion that the jobs that require you to actually appreciate the nuances of computing and programming on this level are virtually non-existent. Most customers don’t care if the application software is a rotting carcass under the hood. They want it cheaply and quickly, and if it breaks, “That’s what computer programs do, isn’t it?” and then they pay someone to fix it.
In most cases, the practical craft of programming is very far removed from that Platonic ideal I mentioned.
I would argue that the craft of programming is in fact almost entirely unrelated to the field of computer science. Here is an analogy: Building elaborate cuckoo clocks involves a great deal of classical mechanics, but it doesn't teach you anything fundamental about physics. A watchmaker is not a theoretical physicist, even if his practical knowledge of the mechanical movement of small parts suspended in a mixture of oxygen and nitrogen in a narrow temperature range under the influence of the gravitational field of a particular planet may be quite excellent.
The field of information technology is still in its infancy. Had it been more mature, we would already have formalised the distinction between the researcher, the engineer and the craftsman, so commonly seen in other fields.
Our current use of titles is loose and very imprecise, and serve as marketing more than anything else. I would like to see a formal distinction between the different roles.
Douglas Engelbart, Dennis Ritchie, Richard Stallman and Linus Torvalds are not "developers" or "programmers".
Engelbart was a "computer scientist" in the true sense of the word. His systems saw little practical application, but they enhanced our understanding of what computing machines could do.
Ritchie, Stallman and Torvalds are engineers. If they were in the car industry, they would be renowned engine and drive train engineers.
Your typical programming job, on the other hand, is equivalent to the title of "mechanic", "construction worker" or "craftsman".
Many people who enter the field don't actually want to be craftsmen, but since we are so poor at making the distinction, we get misunderstandings. There are retired programmers who worked in the business for 30 years who never quite understood why the job turned out to be so different from what they had imagined.
One consequence of making this distinction is that a hierarchy of exclusivity inevitably emerges from this. There are far more car mechanics than drivetrain engineers. Only so many people have the privilege of doing that.
I don't know if the supply of computer engineers and computer scientists is smaller or greater than the demand, but what I do know is that these jobs aren't the kind you find on a job site. They are found through networking, which requires you to have the right kind of network, which isn't possible for everyone who would be a good fit for the position.
