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.
Name:
Anonymous2010-04-06 21:36
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.
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.
Name:
Anonymous2010-04-06 21:41
Killed my entire summer with it, goddamn. Stop thinking strategically and love solving problems with programming. Scheme does that for me.
Name:
Anonymous2010-04-06 21:43
swinging my meat around like a baseball bat seemed to work well
Name:
sage2010-04-06 21:45
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.
Name:
Anonymous2010-04-06 21:53
>>5
No, friend. You did not kill your summer. What you did was more beautiful.
>>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.
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.
Name:
Anonymous2010-04-06 22:34
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.
>>14
Lua just has first order functions and closures, Python has that and list comprehesions, lambda functions, a bunch of mapping functions, reduce(), etc
>>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.
>>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.
--
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.
>>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.
>>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.
Name:
Anonymous2010-04-07 17:04
>>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).
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.
There's so much religion about encapsulation that people tend to forget what the actual point of it is.
Thinking on this, I half agree with you. Pythons approach is equivalent to getters/setters. I was blinded by the case where you do not provide explicit getters/setters.
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.
I meant name mangling here . Some people name mangle in C because there aren't namespaces.
>>41 Some people name mangle in C because there aren't namespaces.
How the fuck is that supposed to work? I've seen lots of stupid C code written in the name of encapsulation, but how would name mangling help at all? I'd {love|hate|vomit} to see an example.
>>42
You know exactly what I meant. SOME_UNIQUE_PREFIX_SOME_FUNCTION rather than SOME_FUNCTION. My terminology was incorrect *hands up*, but I didn't think it would have confused anyone.
>>42
also, didn't we have someone who wanted to generate random numbers at compile time a while back. That might work as an example if you generated function prefixes/suffixes instead.
Name:
Anonymous2010-04-07 18:31
>>38 The backtrace myth has already been argued extensively elsewhere and I'm not going to bother repeating it.
Implementing backtrace compression means further complicating all existing interpreters, all tools from debuggers to profilers to code coverage analyzers (for all existing platforms) and so on. To put it bluntly: it's a nice hack that can work for a toy language that simply doesn't have all that ecosystem around. For a real language it's not worth it even if you do it from the very beginning, much less when you are considering such a drastic change after shy of twenty years of evolution.
they preserve proper object oriented abstractions
I have a vague recollection of what you're talking about, I remember deciding that for such a contrived case you are better off implementing your code flow explicitly. I could reconsider if you give me the chance, by providing a link.
Name mangling always was and always will be a hack and relies on you playing nice, which undermines the whole encapsulation point.
No. The point of encapsulation is not in providing security. When you want to run a code that was written by someone who might have not been "playing nice", you need much more than encapsulation to prevent him from formatting your hard drive, and the effort is much better applied at other points and larger scales. Python's name mangling does exactly what it supposed to do with minimal effort, providing a zero chance that someone might not "play nice" accidentally and doing nothing more, not getting in the way of reflection for example.
We complain about it in languages like C which don't have namespaces, why shouldn't we complain about it in python.
I'm sorry, but this makes me think that you don't have an idea of what are you talking about. I hope you are able to find your way to Python reference describing how its name mangling works without my assistance.
>>44 My terminology was incorrect *hands up*, but I didn't think it would have confused anyone.
You would have confused anyone who knows what ``name mangling'' means. You also would not make a mistake this stupid if you actually understood the concept yourself.
Somehow I had it in my head that this was tied to proper encapsulation rather than just avoiding namespace collisions (that problem is solved without mangling.) I agree though, it's a nasty side of C.
>>46
What about sticking your backtrace into a ring buffer?
>I have a vague recollection of what you're talking about, I remember deciding that for such a contrived case you are better off implementing your code flow explicitly. I could reconsider if you give me the chance, by providing a link.
I was referring to Guy Steele's take on the "Understanding Data Abstraction, Revisited" paper. His example was contrived to fit in a blog post and was about implementing sets in an OO fashion. The example was there to point out that if you do it in an OO manner, then you will build up a large stack because most languages don't optimise tail calls. If you do not optimise them, you have to break the abstraction. http://projectfortress.sun.com/Projects/Community/blog/ObjectOrientedTailRecursion
One thing to take away from this thread:
If you want some discussion on /prog/, insult python.
Name:
Anonymous2010-04-07 20:08
>>50 What about sticking your backtrace into a ring buffer?
And then you write a tail-recursive iteration over some long enough list that crashes at the end, having evicted all useful information from the ring buffer.
Or, you discover that your program blows the heap because some objects that must be long dead are still referenced from your circular buffer. What's more, the behaviour depends on the interpreter settings and isn't under your control.
The root problem is that the idea of TCO that is kind of not always TCO is based on the thoroughly rotten foundation. In fact, the idea of implicit TCO is based on the same rotten foundation as well.
The primary requirement for the core of your programming platform is comprehensibility and predictability. You can have a fuzzy understanding of how exactly some particular library works, but the language itself must be simple, transparent and predictable enough for you to have a fairly accurate mental model of it. Of everything about it, from the parsing (I hope that Perl is not going to die completely and will remain as an example of where the DWIM school of thought leads, for the generations to come) to the memory management. The more important some aspect is, the simpler conceptually it should be, and the more explicit expression it should require whenever the misunderstood intent may lead to a disastrous failure.
TCO itself is deeply flawed in this respect. It is not at all obvious when a call is in the tail position, if you consider more dense coding styles. Can you explain why foldr (+) 0 [1..1000000] stackoverflows? I mean, it doesn't stackoverflow in the foldr itself, stack overflow happens when the expression it constructs is forced, but why is the evaluation not TCO'd?
But it gets much worse when someone tries to invent a stacktrace compression scheme. We had a compiler trying to read the implicit intent of the programmer from his code, but fair enough, at least it more or less depends on the code, if only in an obscure and non-obvious way. Now the algorithm has to read the intent directly from the programmer's mind, because there are no clues whatsoever in the code for whether this or that stackframe is better saved, while some other can safely be discarded!
And it's not something unimportant, some pleasant addition that we can make without, no, when you are in the situation when you see a stacktrace, you are already knee-deep in shit (especially if the stacktrace was mailed to you from an office on the other continent and no, they absolutely can't provide the raw data), and the last thing you want at the moment is to discover that the "clever compiler" did in fact read your mind wrong, performing TCO where you didn't need it at all and discarding the relevant information.
Name:
Anonymous2010-04-07 20:15
TCO itself is deeply flawed in this respect. It is not at all obvious when a call is in the tail position, if you consider more dense coding styles. Can you explain why foldr (+) 0 [1..1000000] stackoverflows? I mean, it doesn't stackoverflow in the foldr itself, stack overflow happens when the expression it constructs is forced, but why is the evaluation not TCO'd?
Foldr isn't tail recursive
And it's absolutely hilarious when you actually think about it rather relying on Guy's authority.
As soon as any of his objects is written in a way that does not permit TCO, purely syntactically, like when the dude just wanted to assign the result to a variable and then return the variable, and his abstraction disappears in a puff of decaying unrealistic expectations.
His interface does not encapsulate the thing he relies on, the TCO. His belief that it would be applied through the whole chain goes completely on faith, absolutely not specified for the compiler and not checked for at all.
So I still stick to my original opinion: his example would be better off with an explicit traversal strategy, where it would be immediately obvious that when a set can't just return a value in response to a certain query, then something is wrong, and when the direct implementation for that case would not be TCOed as well, only silently.
And then you write a tail-recursive iteration over some long enough list that crashes at the end, having evicted all useful information from the ring buffer.
I did consider that, as far as I can see it isn't really fixable with a fixed size buffer. Or, you discover that your program blows the heap because some objects that must be long dead are still referenced from your circular buffer. What's more, the behaviour depends on the interpreter settings and isn't under your control.
I thought the circular references were a problem in python anyway because it used reference counting *shrugs*
is not at all obvious when a call is in the tail position
The rules are very plain in functional languages, but I can see it being a problem in imperative ones. It's not uncommmon to see foo = bar.baz()
return foo
which would ideally be optimized, but that's me digressing into sufficiently smart compiler territory.
And it's not something unimportant, some pleasant addition that we can make without, ...
No-one ever said that you should make do without stack traces, nice strawman
>>55
AFAIC it doesn't work in Haskell because they delay all the evaluations, I believe they have a special form foldl' or something that does it.
Name:
Anonymous2010-04-07 20:25
>>55
I mean both variants stackoverflow, for completely different reasons though, but at this point I'd prefer banging my head against the wall to trying to recover or understand anew the useless details of why exactly each of them fails.
Whatever though, I'm too tired for a flamewar. I concede.
Name:
Anonymous2010-04-07 20:33
>>56 I thought the circular references were a problem in python anyway because it used reference counting *shrugs*
Your moran, circular buffers have nothing to do with circular references, go die in a fire.
Also, CPython uses a generational garbage collector which frees unreferenced subgraphs. You really are speaking out of your ass, my earlier intuition was right.
No-one ever said that you should make do without stack traces, nice strawman
Yours. I stated explicitly that I would not satisfied by the stacktraces that a benevolent moronic stacktrace compressor coded by morons like you would deem worth saving.
Name:
Anonymous2010-04-07 20:37
>>59
Yeah, the question was, in case you forgot it among your nagging...
stack overflow happens when the expression it constructs is forced, but why is the evaluation not TCO'd?
And no I didn't say that you can make do without a stack trace, I said that it was a myth that TCO and stack traces were incompatible (that is as a rule, not necessarily in a specific case)
If you claim that you don't want/need TCO, fine. For my purposes, I'd rather have it.
You have won. I have nothing more to say, except that it's been a while since I've had such a good conversation in this shithole.
>>52
Personally I'm quite happy to have implicit TCO. It's easy to defeat if you really need to.
But you know what? I'm rooting for you. I'm a much bigger fan of pragmatic TCO than merely implicit. Not because I'm the slightest bit worried the wrong call may be eliminated, but because (like in >>54) I would like to communicate to the compiler or interpreter that failing to eliminate a given call is an error--hey it's probably going to crash anyway, but it's much better to know at compile time, or at the very least be guaranteed to know during testing (say TCO fails, but it doesn't exhaust the stack when called with 5, but does with 6. Or with the same values on different machines. Or implementations. Or the phase of the moon.)
That said, I'm still not phased by having my stack trace look ugly. The program has crashed, things are already ugly. And the tools for dealing with ugly cadavers aren't nearly as bad as advertised. So I'm happy to have implicit TCO wherever available, and explicit TCO wherever required, and so on. Ideally pragma should let you set whatever optimizing profile you like.
>>63
I would also be happy with a pragma, it's an interpreter option in Ruby too, no?
Name:
Anonymous2010-04-07 20:55
>>62 I said that it was a myth that TCO and stack traces were incompatible (that is as a rule, not necessarily in a specific case)
No, you have it backwards. TCO and stacktraces are incompatible by definition, because the raison d'etre of TCO is the elimination of some stack frames. Anything that does not eliminate any stack frames is not TCO, but merely a simulation of stack on the heap.
But I would agree that a sufficiently clever stacktrace compressor could eliminate only uninteresting frames most of the time. It's just that "most of the time" is not good enough for me, when applied to such an important thing as stacktraces.
>>66
Actually I just checked, it's implementation dependant.
Name:
Anonymous2010-04-07 20:57
>>67
Point taken.
New topic: Should programmers treat the stack like a history?
Name:
Anonymous2010-04-07 21:03
>>64
Yes, yes, I more or less understand what happens there, but it's not at all obvious why the evaluation of the resulting unforced tree of (+)'s is not TCO'd. I mean, it obviously could be optimized in this particular case, right?
More generally, my point was that when you use any external code in a nontrivial way, you can't be sure that it wouldn't blow your stack. The type system doesn't capture the notion of being eligible for TCO through and through.
>>67
Pardon me if I'm getting this wrong, but if I phrase my thoughts like that, I realise why you and I have such different views of backtraces. It comes down to a view of the stack as a history versus the stack as a future. Am I wrong?
Name:
Anonymous2010-04-07 21:10
>>70
Well obviously it could be optimised, but it goes against call by need nature of haskell. Although, in a pure function it wouldn't change the answer, it could set of a chain of other previously deferred computations (which may not be needed)
>>67 But I would agree that a sufficiently clever stacktrace compressor could eliminate only uninteresting frames most of the time. It's just that "most of the time" is not good enough for me, when applied to such an important thing as stacktraces.
I disagree with this on practical grounds. Finite state machines are, well, finite. And simple recursion doesn't need anything, but maybe you want a counter.
The thing about FSMs is that they simply don't cause any more trace related headaches than iterating would. So any details added by the compressor should be a nice bonus. But I get the feeling you don't write many state machines. (Try not to take that as a judgmental comment.)
What's left? Calls that are neither recursive evaluations nor state machines? In most cases these are relatively shallow, and obviously so. I will admit to having written what I consider to be excellent code that violates that rule, but while I didn't set out to write a state machine I'm not sure it is undeserving of being so classified. What am I saying here? - I think it is reasonable to expect a selective kind of optimization that can deduce with great accuracy whether or not a call should be optimized, on the grounds that state machines and recursion should optimize (and maybe things you'd normally inline), and that's it.
>>69
It's a pedantic point, but I think those who do in an absolute sense are fools. OTOH I can forgive those who aspire do so for practical purposes even if I can't identify with them.
>>74
As I kept saying it's fine and does work, for example PLT gives you some nice pretty arrows pointing about your code. Various other schemes have tracing libs.
>>74
Hint: try that on something that isn't simple recursion, Randall1.
--
1. he would know better.
Name:
Anonymous2010-04-08 0:06
Just wanted to point this out to everyone posting about Lua: Lua is not a programming language. It is a scripting language. i.e. if you lua script, then you're a skiddie.
the only thing that differentiates a scripting language is that its interpreted and runs on a VM. Sun was and MS is trying to convert the Java VM and .NET VM to handle dynamic typing. If that happens then even Java and C# will be scripting languages
The whole reason of not providing TCO on Python is somewhat stupid. In CL, the standard doesn't require TCO, but most implementations provide it, and the user can turn it on/off (implementation-specific), that way, you can see full backtraces when you want them, or only perform TCO locally on some functions, or globally if you wish, or turn off TCO on some piece of code, and so on. It's always the user's choice. I don't see why Python couldn't take such an approach, but then that would go against that silly rule of THERE IS ONLY ONE WAY TO DO IT.
>>88
I don't get Python. FIOC is a bit obscene to my mind1, but my real issue with it is that it throws exceptions at the drop of a hat. Exceptions should be exceptional, not flow control.
__________________________________________ 1. Google's Go works the other way: they removed the parens from flow control but kept the braces. It saves you just about as much typing, but also maintains the concrete (as opposed to what strikes me as 'coincidental') separation of code blocks. It still provides FIOC, but it does it for you in the formatter. (Of course they still found plenty of ways to fuck everything up, like removing semicolons aggressively enough to make certain common expressions ambiguous to the programmer.)