GONNA LEARN ME SOME COMPUTERS

Sup /prog/.

DUAL TOPIC:

I'm tryin' to design a roguelike and decided I'd make the attempt in Python since I have next to no programming experience and a high level language seemed like a good place to start.

1) Am I correct in this assumption, or should I just suck it up and learn C/C++/Haskell/something faster yet much more difficult to learn than Python?

2) I can't do shit until I at least understand the language, so suggest little things for me to program so I can figure out what the hell is going on, oh god how did this get here I am not good with computer

programming in python will do two things
1) ruin your programming ability for life
2) turn you into a python salesperson

programming in python will do two things
1) ruin your programming ability for life
2) turn you into a python salesperson

>>2
Perhaps the same could be said of all languages?

Read SICP.

>>5
Well, live example before our eyes.

0) read sicp.
1) learn factor, then haskell.
2) project euler.

>>7
That's actually not half bad a sugestion if you replace "factor" with "forth".

>>1
1. More or less correct. Python is a much better choice than C (which does have its uses), C++, or some of the other languages RL devs like to use (Java and, inexplicably, Delphi). Haskell ain't bad, but I have no idea whether it would be hard as a first language. At least you wouldn't have any Ctardation to unlearn.

2. RLs scale pretty well. You can start by either implementing the drawing of a hard-coded map, then add a moving @, or vice versa. Then some simple enemies, and it can snowball from there. Seems to me that there are enough easy mode tasks in a RL that you'll be able to make a bit of headway and get your bearings. And don't worry too much about making it well-written. Don't get sloppy but:
The management question, therefore, is not whether to build a pilot system and throw it away. You will do that. [...] Hence plan to throw one away; you will, anyhow.

>>7
(0) This is actually good advice. However SICP is a big book, so read it concurrently with your project or you'll forget to do the RL by the time you're done. (1) Too bad there's no introductory material for Factor or I would recommend it too.

>>8
I'm learning Forth thanks to you now. I hope you're proud of yourself.

>>8
Hey, I'm the Forthfag around here.

>>10
Are you reading http://www.forth.com/starting-forth/ ?
Also all programmers should read http://thinking-forth.sourceforge.net/ .

>>11
I already know Haskell. Is that book you linked to appropriate  for someone who already knows Haskell?

>>12
Which one, the first, or the second? The first is good if you're learning Forth. It's basic, but Forth has several low-level quirks that a person needs to know to write it effectively. It's a quick read, and a person with little to no knowledge of Forth would do well to read it before reading the second. A person with a general idea how to read Forth code who wasn't interesting in programming in Forth in the near future could skip the first book.

The second book is just great. It's about program design, from the perspective of a Forth expert. A combination of Forth's concatenative nature, its low-level foundation, and its interactivity yield design insights that were completely new to me, coming from a Lisp background and being schooled in typical fag languages. Where else do you get topics like Minimizing Control Structures (conditionals and such) and The Limits of Level Thinking (high-level/low-level program components)? Lots of things that are good to keep in mind in any language, but which are seldom well articulated.

>>13
Thanks for the comprehensive summary. I guess I'll spend my night discovering Forth.

One more thing: recommended implementation for lunix?

OP here.

>>7
Parts of this actually don't seem like a bad idea.

>>9
Thank you, surprisingly helpful Anon. That sounds like some reasonable advice and more or less what I figured I should do, but good to know I had the right idea. Guess I'll be sticking with Python.

Haskell is a terrible choice, it's not used for anything.

>>15
Fuck if I know. Forth implementations seem almost as crazy-making as K and Q implementations.

I recommend writing the graphics subsystem in COBOL, the game engine in JAVASE and the database system which your enterprise java framework will pull from in BASIC. You can then interface the different parts together using sepples sockets to create a robust cloud computing supportive (read: future proof) solution.

>>15
just pick one and go with it.

K&R, SICP, and the IA32SDMs are all you need.

>>15
gforth is decent.

>>9
(0) This is actually good advice. However SICP is a big book, so read it concurrently with your project or you'll forget to do the RL by the time you're done.

CONCURRENCY IS THE FUTURE.

Topics like Minimizing Control Structures conditionals and   such and The   whole point is   i already have   cat running Just   GUESSING Linux 2   I am a   Scheme programmer So   I think installing   Java Enterprise Edition   But Java Enterprise   Edition is perfectly   possible and if   we did any   work in the   mirror tl dr   post Comments appreciated.