If only there was some way to find this article, some way we could locate it in a universe of articles and videos out there. Man, that would be cool.

Kerowo: http://worrydream.com/

There are only a few articles there, but they are all well worth reading. I agree with gaming_mouse's assertion that he is a very deep thinker, but you really have to take away time from reading Nobokov to get through them.

*for all I know, the article he is talking about isn't on the site.

wow, wtf, i was sure i had pasted the link in. the one i was talking about is:

http://worrydream.com/#!/LearnableProgramming

sorry guys....

EDIT: dave, the one called climbing the ladder, which i believe you read a while back, is also amazing.

Sheesh, man. I thought I wrote long articles, but I don't feel so bad because I generally keep them below 3,500 words.

I read about 33% of it so far, and I 10000% disagree with that cursor thing. There is absolutely zero chance she'll understand what the hell she is writing unless she pulls out a pen and paper and step through those loops using substitution. It's so critical to do those pencil-and-paper step-thrus that I'm totally surprised that he would ever suggest mousing along and reading some outputs. No one can can read a screen of outputs and expect it to sink in.

What the hell is wrong with making mistakes when you are learning how to program?

The whole idea is to think critically about what you are writing and what you are creating. Yeah, seeing a loop go bongo is part of the learning process. Screwing up is a the best teacher you can ever find. Why? Because when you are forced to think of a solution, you are forced to understand the problem and solution at a very deep level. It is the Stack Overflow effect, where you write out a question then before you press submit, you think of the answer.

If you think that is a good idea, I have zero clue how you can say Lisp is a great language, as it is highly dependent on syntax and understanding the output by abstracting the steps and what is going on underneath. It is absolutely critical, when using Lisp, to have a keen visual of what is going on with all the things you cannot see, because a print statement isn't going to help one iota in writing Clojure programs because many of the steps are pushed out of sight. You are forced, in Lisp / Clojure to really think about what the expected input and outputs are and create from there. It is very easy to go bonkers and build broken systems with it because there are many things you simply cannot tangibly see no matter how hard you try. It is critical to control those things that you can't see and to design the entire program around that. It is the complete opposite mind-set than what he is talking about.

I guess he really likes to use Flash?

There is nothing inherently superior to using a primitive tool over a more advanced tool, and that's what he's talking about. When your IDE is a stack of punch cards then being able to be a paper computer is an excellent skill. When you can see the changes in your code in real time then why do it on paper? His whole point is about removing the barriers to understanding what is going on in a program that traditionally have been solved by the programmer having it in their head. Like every layer of abstraction, this IDE will make basic programming possible for a wider range of people and will make more difficult programming easier for people who already do this in their head. Can a tool like this be written by someone who only knows this tool? Probably not, but then again there will always be people who want to know how the tool works and go below the abstraction to make it better.

What does this do in Clojure?

Well.... There's no way to step through it and visualize it via any tools, but it may be equivalent to:

Or is it:

The point is that you have to really really understand the abstractions and there is no way to get through this unless you already understand the abstraction it is acting on.

dave,

i'll try to respond in more depth later, but basically what you are saying is, i worked hard and learned it the hard way, so that's what everyone has to do and should do. it is, admittedly, the view of many experienced programmers. i think it is a failure of imagination. there are much better ways than the current way. that's why he makes those sample tools: to show you what it could be like, just a little. i'm surprised you could read his argument and see those videos and think doing everything by hand is a better way to learn. i'll try to address your specific points later.

How many times did you have to see this construct, look up the documentation for it, run it with different values, or step through it in a debugger before you knew?

How much faster would that process have gone if your IDE walked you through all of that? So you didn't have spend hours on StackOverflow hoping the answers you could find were for the current version of your IDE or were close enough to give you a clue?

This many times?

In regards to resources, I generally use this helpful cheatsheet: http://clojure.org/cheatsheet and the Clojure book I have.

I've posted three questions ever on SO. In general, the questions tend to be too specific or esoteric to really be useful.

The problem with Lisp is that you really can't get much out of the language until you really get down into it and take the time to understand what it is happening. Let-binding, lambda, destructuring, cons cells and cdr'ing are all things that you sort of have to grind your nose into and just feel it out until you achieve some understanding. Dr. Racket (Scheme variant) has a graphical debugger that shows the pathways, but it doesn't help to much beyond the basics. In general, there will be an X somewhere and it generally doesn't help.

It's not without reason that you find blogs about people taking *a long time* to understand Clojure or Lisp, which contrasts wildly with people saying they can "master" a language in 3 weeks. Not the case at all with Lisp.

^ I must really hate myself.

In what problem domains are tuples best suited for? I wrote a Lisp program once in school to do symbolic differentiation. Lisp seemed well suited for that. I once wrote a real-time package on an embedded system in assembly language where the processor had lots of registers because execution speed was paramount. Doing that in Lisp is out if the question. Doing symbolic differentiation in assembly language is pretty out of the question. In my view problem domain should dictate language choices. I think you're a little confused on what an abstraction consists of, what the requirements for an abstraction are. Probably a good thread topic.

In Clojure? None. Tuples don't exist in that language. *Most* data structures are immutable in Clojure and I just changed it to a tuple to demonstrate that point.

Ugh.. nightmares. I recall Abelson or Sussman saying that someone managed to encode all of calculus in Lisp. Apparently took 5,000 LOC, which I guess isn't too shabby.

Wolfram Alpha is a sick piece of software. I wonder how many LOC they have riding under that.

Well... I just don't know what the better word is.

I'm sure if I didn't give out the answer right away, you would not say "That is a brute-force algorithm that returns an immutable sequence of vectors" which looks pretty close to Python's Tuple of Lists, though it most certainly doesn't behave the same way.

There is no way to white-box that algorithm, so you see the output and the real stuff is basically in a black box. Even though I wrote all the necessary code to make it work and it looks clear as day what is happening, I still cannot pull out the information in real time. The important point is that if you see the output, you *know* what the function does. Now imagine how dangerous it would get if you hand that off to someone who doesn't know what that really does (n^2) and pushes variants of it all over her code?

Not that dangerous.

There are tons of decisions every day we make when programming that are non-optimal when it comes to performance either due to ignorance and/or laziness. The vast majority of the time it doesn't matter. When it does, you profile, you learn, you move on.

We had an argument earlier in this thread where I think a lot of people disagreed with me about something similar. I think it had to do with how the compiler optimizes code in certain ways. My point there was that its totally impractical to understand all the ways a compiler/processor is going to optimize your code and attempting to code to take advantage of all of them is probably a giant waste of time. I think the same general idea holds here.

Is Wolfram Alpha written in Lisp? In the FAQ it says:

You didn't answer my question about tuples. Whether or not Clojure has a tuple data structure is completely irrelevent regarding my question.

I'll defer this question to the Python experts.

Poorly written by me. Didn't mean to suggest that it was lisp.

Haven't read the article yet and the follwing rambling is only very loosely related to the topic but....
I have recently started to force myself to use mindmaps more (again). I get sloppy every now and then but basically everytime I have to look something up in the docs I put it in my mindmap now (used to use FreeMind but am back to markers and paper because it's more fun).

Maybe my brain is incapable of absorbing information but there used to be stuff that I had to look up 4-5 times before it stuck after repetitive use. Smallish sample size now but I didn't have to look up anything I put in a MM up yet.

I almost feel like I should learn a brand new programming language just to test the assertion that I learn stuff about 5x better this way.

I'm not sure I understood your question but the answer seems fine to me. The answer would be "all problem domains that tend to be solved with lists or similar constructs in other languages". Other than convenience there usually isn't really a need to have mutable lists. I don't know Clojure but I'm assuming lists are pretty much the same as Prolog lists. Non mutable data structures with a head/tail.
Guess the real answer is somewhere in the "zomg them functional languages. mutable data bad...threads be evil yo" hype :P

Edit...interesting discovery:
mutable
****table (<- dot mutable)

lol WTF

In what problem domains are tuples best suited for? Just making a point.

Dangerous is executing something like this in a non protected memory environment like kernel mode in windows:

*ptr = 0;

Of course it's necessary but necessary doesn't always mean safe. An n squared algorithm isn't dangerous I agree.

I have exported my mind to the cloud. I have to look up things constantly

works for me!

****table is probably some bizarre old filter for a spammer site or something

Tuples in python are simply immutable lists. They are best suited where mutability makes the code difficult to reason (shared data structure between code segments, whether due to complex callback semantics in event-handling routines, concurrency models, etc). They are almost always better than mutable lists except when mutability is explicitly required.

Tuples in most other languages are lists whose length is part of the static type. They are much close to records/structs than to lists. They are preferable to (for reasons of type safety and performance) lists if you're dealing with a fixed number of items.

I'm far from expert, but I'd say in Python it would make more sense to say that tuples should be the default and lists are guilty until proven innocent. I mean, how hard is it to change a tuple to a list (if necessary) than vice-versa? And are there any tuple gotchas on the level of the ones we just talked about upthread?

I feel like in Python, any time I could use list or X builtin type, X is always better. That isn't to say I don't use lists, I just only use them when I have a concrete reason that I can't use a tuple, a set, or a dict.

Here's a stupid tuple gotcha:

(foo) vs (foo,)

It's really easy to do the first one.

If you think about the example I showed, adios isn't asking a deep question. He just wants me to say the default return value from that function would be a tuple.