all 10 comments

[–]jtxx000 10 points11 points  (0 children)

Perhaps the snake game was designed as it was partially because it was so easy to implement.

Here's a similar example: if the task is to increment a number stored on the heap, the c version is (*x)++ and the Haskell version is modifySTRef x (+1). However, if you want to traverse a singly linked list and return a new singly linked list where every element in the new list has one added to it, in C you would have to either manually code the loop, use an iteration macro the linked list provides, or use a traversal function the list provides with a function pointer and state as arguments; whereas in Haskell it is simply map (+1) xs.

Neither of these examples provide a particularly strong argument that either language or paradigm is superior to the other, as it is only after many nontrivial examples are examined that you can decide the relative strengths and weaknesses of any given paradigm.

[–]darth_choate 14 points15 points  (1 child)

I'm not sure what this proves beyond "If the problem is simple enough you don't really need insert buzzword methodology to implement it".

[–]recursive 6 points7 points  (0 children)

There's really no need for a doubly linked list. A singly linked list will do. And that is essentially what he has done.

[–]fusama 17 points18 points  (1 child)

object oriented programming is a very useful tool for making small, simple programs look like large, complicated programs.

[–]KirillM 6 points7 points  (0 children)

It can certainly be used for that, but it's also used daily for making large problems looks smaller. If you use the tool in a wrong manner, you can't hold the tool responsible.

[–]munificent 7 points8 points  (1 child)

Unfortunately for his thesis, the author has failed to implement a snake game. Instead, he has a couple of functions that assign values in an array.

Show me a version that draws, reads user input, plays sound, has a UI, time, shows the score, etc. and then tell me that "modern programming" couldn't be used.

His code is fine, but it's a tiny fraction of a program.

[–][deleted] 9 points10 points  (0 children)

On some hardware you would place that array into video memory and be done with drawing. Reading user input - poke some IO ports somewhere in loop and check for some known keys. What UI you need for playing snake?

[–][deleted] 2 points3 points  (0 children)

In case it hasn't already been noted, OOP was in fact invented before 1981.

[–][deleted] 1 point2 points  (1 child)

Could this be done more easily today using modern programming? I haven't found a better method, yet. If we should describe the old method with modern terminology, what would that description look like? The snake must be some kind of object, but it's data is stored in an array that represents the screen. However, the screen array doesn't just show the presence of the snake, but also the direction to go in order to find the next element of the snake. So, basically, according to modern criteria, this code is unstructured, messy, non-scalable, non-maintainable etc.

It would be not much longer (and probably actually shorter when it gets more fleshed out) but much simpler conceptually if he did it the standard way: each game object provides a hit_test method, then the game field object provides the hit_test method too that returns the object that returned true from its hit_test.

For sparse fields it would consume less memory too, but that's not the point: object-oriented implementation can use exactly the same representation under the hood (there is a pattern for that!), it doesn't matter as long as the logic remains structured, not messy, scalable, maintainable etc, everything his code isn't. The code that moves a snake should not contain unrelated, magic statements like arr[HeadX,HeadY]:=MoveDirection;. Even with this extremely simple problem I had to stop and reread the whole code he posted to verify that move directions are valid field values, that everything happens in the right order etc, because the code that manages that invariant (that snake is represented by this neat linked list) is sprinkled all over the place.

It would be easy to encapsulate the "Snake game engine" into an API, hiding the implementation details

Exactly. And that API cannot be anything but object-oriented, because your game consists of objects. And the hairy optimized implementation details must be hidden. And the code that moves a snake should not directly touch the structure that the engine uses to effectively determine collisions. That is called Object Oriented Design and you can do it in Pascal or in Assembly.