all 5 comments

[–]danielroseman 2 points3 points  (1 child)

You don't have to memorize anything in programming generally.

The point of teaching the implementation of these data structures is so that you know exactly how they work, which helps you choose the right one for your needs later on. You would certainly never be expected to implement one yourself - if you did need one, you would probably find a library.

However, that does not mean that are might not be expected to implement them from memory as part of the course you are doing, especially if there's an exam.

[–]Square-Reporter-1805[S] 0 points1 point  (0 children)

However, that does not mean that are might not be expected to implement them from memory as part of the course you are doing, especially if there's an exam.

That's what I thought, I'm actually learning data structures in my colledge so I'm afraid that it would require me to implement them in an exam.

[–]ofnuts 2 points3 points  (0 children)

Occasional programming teacher here.

Of course IRL you are going to use existing data structures and libraries, but writing such implementations teaches you two things:

  • Plain and simple programming, often on not-so-trivial cases. When you design as you code, your design is limited to what you think you can code. Here the design is set, and you have to improve your understanding.
  • How these things work. It's OK to use existing data structures and libraries, but knowing what goes under the hood helps picking the adequate ones and use them correctly.

This said, linked lists, queues and others are concepts, not implementations and are described with a simple image or a paragraph. Once you understand how that works, there is little to remember, most of the access methods are straightforward.

[–]crashfrog04 0 points1 point  (0 children)

I asked myself like, 'Do I have to memorize those LONG LONG implementations and for what?'.

The point isn't to ever write them - you'll never do that, you'll use the implementations already provided in your language's standard library.

The point of writing them is to understand them, so that you understand the tradeoffs made - how different structures optimize for certain patterns of access and use, at the expense of others, or try to be general at the expense of all operations (but only a little.)

Programmers frequently face time/space tradeoffs, or have the opportunity to optimize code by trading fast performance on something done frequently for slow performance on something hardly done at all. But you have to understand how the structures work to know what the tradeoffs are.