SICP

Say, someone who has no prior experience with programming, and is at a rather 'young' age (Teen still) wants to get ahead of the game, and start up now, rather than later. Would one go about this by reading SICP? I've seen it linked so many times, I've only got to think it's a start.

Just grab yourself Scheme from somewhere and start doing the exercises. It's actually entertaining; once you start, you just won't be able to stop till the end, that's for sure. Then you'll be sad and wish there was more.

>>2 Sounds good, second opinions anyone?

I forgot to mention; you don't have to keep using LISP afterwards. SICP teaches you a way of thinking; it is not the generic "<programming language> for dummies"-kind of thing.

Killed my entire summer with it, goddamn. Stop thinking strategically and love solving problems with programming. Scheme does that for me.

swinging my meat around like a baseball bat seemed to work well

Is it just me or Lua could be modified to have semantics very close to those of LISP? Too bad its main data structure are tables instead of linked lists.

>>5
No, friend. You did not kill your summer. What you did was more beautiful.

Holy shit, >3 posts in less than an hour!

>>1
You should also have him read K&R too, for the low-level stuff, maybe some assembler as well.
>>4
What's wrong with using Lisp afterwards? He might want to pick a more industrial-strength Lisp like CL, of course. It seems pointless to throw away an useful tool.

>>7

Lua's pretty similar to Javascript. They both have things in common with scheme. (Dynamically typed, good functional programming support.) This is kind of related: http://www.crockford.com/javascript/little.html . I imagine you could do the same transliteration with Lua (in fact that'd prolly be pretty awesome).

Linked lists are nice, but having hash tables as a first class citizen is really nice too.

The book "Simply Scheme" teaches what SICP does in an easier to understand way.

>>11
The designers of Lua make a big thing out of its functional programming features, but it actually doesnt even have half as much functional features as Python does. Lua's main advantage is its speed and embeddability into applications such as games.

If you want a buttkicker of a scripting language that feels like Sepples, you should try Squirrel. There is even a version of Squirrel as a shell language. Now this is what C shell should have been.

version of Squirrel as a shell language
All those nights of prayer have not gone to waste. Goodbye, /bin/bash.

>>12
doesnt even have half as much functional features as Python does
Really now? Any examples of that? HIBT?

>>1
Forget it, go study biology or something.

>>14
Lua just has first order functions and closures, Python has that and list comprehesions, lambda functions, a bunch of mapping functions, reduce(), etc

>>16
Lua has lambdas... IHBT

>>16
Python's lambdas are hardly worth the name.

>>18
I think he was just kidding or trolling.

If you want a buttkicker of a scripting language that feels like Sepples

Wait... what?

I'm unable to comprehend the kind of question to which that is the answer

>>16
Functions are functions

Yes Lua may have a general mechanism, but python also has a few specific examples
lol

lambda functions, a bunch of mapping functions, reduce(), etc
Not for much longer if Guido gets his way

>>22
Python has always been a good language in spite of its creator. That's nothing new.

No-no-no! Wait.
First, typed and untyped lambda calculus.
Second, category theory.
Third, SICP.

>>23
s/good/OK/

>>25
I'd actually say good. There are certainly areas where there's some room for improvement, so it's not perfect, but they aren't such that they detract from productivity or fun. Most of the things people enjoy complaining about when it comes to Python are non-issues.
If you're going to call Python merely OK, you have to face the fact that there are no languages that are actually good.

Read it, how could it do any harm?

>>27
tail recursions perhaps?

>>26
Most of the things people enjoy complaining about when it comes to Python are non-issues.
For most things you can argue that, but you can run into the blub paradox if you are not careful. Take TCO for instance, if you've never used a language with proper TCO you can claim that "it's not a problem in practice", and it may not have been for you. Some of us like to write our programs in other ways, and find python wanting in certain aspects. One other issue, is that object fields are public. Again, maybe not a problem for you, but some of us know how useful proper encapsulation can be.
you have to face the fact that there are no languages that are actually good.
I agree with this statement.

<sub>--
1. I'm not talking about writing loops recursively. Anyone who writes a basic iteration recursively instead of using a higher order construct is a moron. TCO is especially useful in any case where you have a state-maching-like structures, and I've written imperative programs that have ended up kind of like that more times than I'd care to admit.</sub>

anyone interested in getting started with Scheme/Lisp should listen to this podcast:
http://www.se-radio.net/podcast/2008-01/episode-84-dick-gabriel-lisp

>>30
if I immitate his voice will I have a gay lisp?

>>30
He and Guy Steele gave a wonderful talk called 50 in 50
http://lambda-the-ultimate.org/node/3101

>>31
No

>>29
I don't give a shit about FIOC or even about complaining about it, but I want to reinforce your point about TCO. Writing a state machine without TCO is some kind of sick punishment, like writing XML by hand.

I have the suspicion that people who think FSMs aren't all that important are the same people whose attitudes about program state amount to "it is right and good to leave program state to the mercy of side effects, and we all know that detours from this attitude are only of academic interest anyway." And these people design languages! Systems languages! ~sigh~ Okay, I'm done.

http://www.se-radio.net/podcast/2008-01/episode-84-dick-gabriel-lisp
*gabs dick*

>>29
Take TCO for instance
The problem with TCO in FIOC, as I understand it, is that the most vocal proponents of it sound like "Give us implicit TCO we want recursive fibs also u don't understand `reduce` u suck derp haskal derp derp". Of course Guido perceives that as the way to say "I have read SICP today" (which it totally is) and disregards them in bulk.

And he is right, adding implicit TCO to Python is the dumbest idea ever, because suddenly all Python scripts in existence would start producing confusing stacktraces, pdb and the rest of advanced tools that expect orderly stacktraces would have to be patched in subtle ways and so on. Adding a switch to the interpreter or maybe a special import or something wouldn't help either because TCO is not an optimisation. So that is never gonna happen.

But even if someone managed to calmly explain that, dude, what we need is a new .tailcall bytecode like in .NET and a special "tailcall return" keyword, and present a set of real-world applications for the new functionality, even then I'm afraid it would be rejected.

Because if you need TCO for your FSM, writing a trampolining decorator takes five minutes and ten lines of code. Is some minute increase in speed by implementing it in the interpreter worth the effort? And it's not only CPython that would have to be patched, mind you. No, absolutely not.

object fields are public
Start private field names with an underscore. It will mangle the names, so no one would be able to accidentally access them, while deliberate access is not different from accessing them via reflection, which every language in existence that has reflection allows anyway.

>>29,35
Also worth noting with regard to private variables is that you can fake them with things like __getattribute__ and __setattr__ if you really need them (though you never do).

>>36
How?

I don't want to turn this into a why python is awesome/shit thread. So I'll post this, you can respond (if you want to) and then we leave it at that.

>>35
The backtrace myth has already been argued extensively elsewhere and I'm not going to bother repeating it.
FSMs were an example, another is that they preserve proper object oriented abstractions as you do not need to peek behind the interfaces to prevent stack overflows.

Name mangling always was and always will be a hack and relies on you playing nice, which undermines the whole encapsulation point. We complain about it in languages like C which don't have namespaces, why shouldn't we complain about it in python.

Actually, one more
Is some minute increase in speed by implementing it in the interpreter worth the effort
You will notice from my posts that I have never once made claims about any speed improvements or lack thereof.

>>38
Name mangling always was and always will be a hack and relies on you playing nice, which undermines the whole encapsulation point.
I don't think anyone's denying that name mangling is basically a dumb thing thrown in to appease people whining about private variables, but every implementation of private variables requires you to play nice to some extent. Python just doesn't get unduly in the way of people who don't want to play nice for whatever reason, unlike languages like Java where you can still see and change private variables, but it requires a lot more pointless code.
It doesn't undermine encapsulation in the slightest. If you want to pretend mangled names don't exist, you can without problems, and you won't accidentally overwrite a vital attribute.

There's so much religion about encapsulation that people tend to forget what the actual point of it is.

We complain about it in languages like C which don't have namespaces, why shouldn't we complain about it in python.
Going out on a limb, I'd say it's because it's a completely different issue and namespacing doesn't have anything to do with private or public variables one way or the other.