I like Yegge's quote later on:

Isn't Lisp some silly toy language you can't build anything with, relegated to freezing in the AI winter?

I think the value of seeing the computer react to the programmer in interesting and visual ways is more important than using a Lisp to start with. There's a time for theory, but probably not at days 1 -> 100.

Of course, it takes a certain type.

you manually enter them one by one. gets pretty dreadful if you have more than just a few. And like I said, we only needed the top score and could discard all the rest.


Just got done writing a very basic sort of AI for a text-based game. I know it's simple and they supplied most of the fundamentals, but it's still immensely satisfying trying to figure out how to put it all together and make it function properly.

Why I didn't do this ten years ago I'll never know.

Well, I know exactly why, but it's a dumb reason and I feel dumb. But who cares, cuz it's on now!

I think Lisp as a first language is a lot easier than Lisp as a second language if that makes any sense.

But these days I'd pretty much 100% recommend a language that lets you get stuff done on your own and if you struggle have great support (community). Getting stuff done also means that there's robust libraries/frameworks for common tasks that are well documented. I think OOP as a concept to think about the world is important enough to pick a language that supports OOP (as a programming paradigm it's ok but often misused imo, if used well it's surprisingly good at quick prototyping).

Like I said I'd probably recommend Python/Ruby or Java. I've thought about it a bit and might actually recommend Java because I think starting with a strongly typed langauge has some advantages.
Python/Ruby probably get stuff done quicker though (even though I always underestimate Java in that regard).

Please explain.

Maybe it's easier to write Lisp code in Python than it is to write Python code in Lisp? (or whatever the non-Lisp language is in this scenario)

I can't really explain it. It's true for Prolog for many people. I think it's easier to think functional/declarative if you haven't been exposed to anything else. It's kind of true for me as well...usually takes a warmup period before my brain clicks over to Prolog mode.

I'd kind of like to A/B test (or whatever fancy test you can come up with) it

The Scheme course I mentioned above was sort of an A/B test. I think its definitely true that total beginners to programming had an easier time with the concepts of Scheme (not necessarily the concepts of CS) than students that came in with other programming background.

It's definitely easier to write Pythonic Lisp than it is to write Lispy Python, though it is ugly either way. Python does have quite a few ideas that are Lispy in nature.

I'm not sure why anyone thinks Lisp is inherently functional / declarative. Although Lisp encourages using functions and shies away from global variables, I'm led to understand that this is good practice in any language.

Why Structure and Interpretation of Computer Programs matters

I picked up Algorithms by Sedgewick, and I was shocked to see that the first 125 pages of a 800 page book was an extended tutorial on Java syntax and nary an algorithm. I'm assuming the rest of the book is salted with more Java tutorials. The idea of using Lisp was to skip all of that. CLRS circumvents this issue by using pseudocode. If I ever wanted to learn Java, I'd probably give Sedgewich a look again.

Here's another interesting read, but still more emotionally-driven than I'd like.

Scheme vs. Python

I think that people hear Lisp and they think OMG SICP, and thus assume that Lisp has some magic powers. I still do incredibly stupid things in Lisp and other languages. I don't think the recognition of this fact would be any different if I never heard of Lisp.

This is the part I completely agree with. I like the exercise of looking at a programming languages "Hello World" implementation and really thinking about all of the concepts you need to know to understand what is written.

I agree with that as long as it aligns with the goals of the course, whether university- or self- administered.

I take issue with the idea that programming in Lisp makes you a better programmer in Language X.

I'm also unsure about how much studying how OO is implemented is useful. I can think of one time where I needed that knowledge, but seriously, wrong tool for the job.

Quick C++ question, what's the difference between:

const double getX();

and

double getX() const;

?

The first returns a const double.

The second only makes sense as a class' method; it cannot modify any data members (unless they're marked as mutable iirc).
That also means the method cannot call non-const methods of its class.

I might read the Scheme vs. Python article later but so far I think Python maps very well to pseudocode. The pseudocode I write for algorithms/AI stuff is essentially Python so I'm unsure why it would be deemed bad for algorithmic stuff.

The main point I was trying to make is another though. I think in general "language shapes thought" is a pretty valid thing to say. If your first language was the typical OO one that you find in many schools I think the more you use it the more you get used to seeing the world in OO terms (and also to think imperatively). I'd argue that it might be harder to work in another language paradigm if you are somewhat deeply rooted in OO/imperative land. If it's true or not I cannot say, it's one of the things the academic in me wants to test (one of the most fascinating talks I had last year was with a guy from Tokyo who examined if "loop blindness" and "recursion block" are a thing).

Obviously my frame of reference is Prolog and I myself have trouble switching "modes of thought" between Prolog and other languages. It takes my brain some time to readjust and get into the "oh right just describe what the solution looks like not how to get there".
So I'd be very curious if someone who has only worked in Prolog (lol...guess those folks don't exist) would have similar issues if he'd learn say Java next and would have to mentally make the switch "oh right I have to write WHAT the program has to do in what order etc"

[I feel like I'm expressing myself very poorly :P]

Edit: I don't know how many here are fluent in multiple languages but I notice this phenomenon quite a bit with natural languages as well. When I'm in "German mode" I think about stuff differently than when I'm in "English mode". I don't consider English a foreign language any more because I regularly think/dream in it but the general line of thinking (structure really) actually changes depending on my "language mode".
[Like I said this is really hard to express and it may very well be completely different for other people]

Great, thanks.

I don't know who would argue that Python is bad for algorithmic stuff. There are quite a few limitations of the language for more CS'y stuff, like its broken lamdba and tuple, but those aren't super-critical for creating algorithms and data structures.

I think that the way these ideas as taught are either incorrect or poorly interpreted. There is nothing in functional programming that says nothing mutates, and there is nothing in OO that says everything must mutate. I think much of the dissonance is stemmed from the fact that OO, procedural, declarative, functional, etc, is not well-defined, and I don't think pigeon-holing languages help with this. If we separate the concepts from the language, we find that we sometimes prefer OO and we something don't: there is nothing wrong with this, and there is nothing magical about a language that eschews OO. If we only consider OMFG FP Language and judge the talent of the programmer on this, we forget that these languages do express mutation (or side-effects) just as well as any other language.

Even James Gosling (the creator of Java) says this about mutation:

http://www.artima.com/intv/gosling313.html

This says to me that the failing isn't in OO -vs- FP, but a failing to understand which idea is needed in the parts of the program we are working in. An "FP programmer" prefers to keep mutation to a minimum, and I don't think that good OO programmers would design their programs with mutation spread like measles across her entire program, and would therefore keep mutation to a minimum.

It's sort of funny. The db girl doesn't know anything but PL, so she'd be someone interesting to experiment with. I did show her a bit of Python and I suppose she likes it a little.

I guess you can argue that Lisp is my "first language." Granted, I did some stuff with other languages before that, but I didn't understand much of anything even after one month of using Python in that intro class. Something like 80% of my lifetime code is in Lisp, so I suppose my brain is wired to think in Lisp and, by your theory, adjusting to OO / procedural and that should be relatively easy for me. I guess I have no good perspective on this thinking, but I don't think those assumptions hold much water. I struggle just as much as anyone else, though it is possible I struggle with different things.

I can't help think of the oft-said quote from "40 Year Old Virgin" (modified to keep things G-Rated and relevant):

"Your putting Lisp on a pedestal."

Anybody have thoughts/research on optimal work intervals for programming? (In other words, is 1.5 hours then a 15 minute break the "best", etc.)

Also would like to hear what you think about napping and timing. I'm not drinking caffeine for the time being so I need to nap sometimes, like after a long day of work when I'm still expecting to learn to code afterwards.

Assuming I've already mapped out what I'll be doing either mentally or on paper I work best just putting my head down and going until I need to use the bathroom, get more water, get something to eat or until I'm done

I suspect that this is going to vary a lot from person to person.

My python class is such a joke. It's taught by a cal-state professor and one of our hw assignments is to watch the Matrix and find words that are tech related.

Our class hasn't covered methods or classes yet but the hw below states to use it:



In addition, one of our in class assignments was literally word for word written like this:

I regret not dropping that class.

Random for me, sometimes I can burn and do 7 or more hours of solid good quality work non stop, other times I am very inefficient and can only do 30 minute spurts.

If you are fortunate enough to have the freedom to do this, one of the most important things is to write good quality code. If you're not, probably best to stop or slow down as you could lose a lot more time in the future.

I have no research to back this up but I pretty much agree with the "flow is dangerous" school of thought. I did the best doing pomodoro style i.e. 25 minutes with 0 interruptions, get up and walk around for 5...longer breaks after a couple of these.

I'd wager that there are no hard and fast rules, productivity seems very personal. What works for one might be horrible for others. Best advice is probably to consciously experiment and test.

+1. I've been trying to get better at consciously thinking about a task and deciding if it's a 'flow' type task that I'll be able to just dive into and code for hours on, or if it's a 'work a bit - rest a bit' type of task.

For me if I have a really well defined back-end problem with little to no subjectivity (implement a semi-complex algorithm) then that's a flow type task. If I have a lot of subjectivity or front-end work (which I'm not as good at) then I need to break the problem into very small pieces and take conscious breaks because I'm not going to get into a flow type state and I can just end up spinning my wheels for a long time.

As far as naps go, new research shows the coffee nap (drink a cup of coffee or something with caffeine - maybe only works on coffee since that has a unique caffeine type - and then take a 20-30 minute nap right after drinking) is the most effective at leaving you feeling alert and refreshed afterwards, more so than either napping or coffee alone.

Additionally, if you're trying to learn something new when you're tired, apparently a great way to do so is to almost fall asleep and then keep processing the new ideas.

Many of the world's greatest designers and inventors have used this technique throughout history. From inventors who would hold their keys, only to drop them upon nodding off so the sound would wake them back up, to Le Corbusier, the architect who designed an armless chaise lounge that he would doze in and when his arms fell to his sides it would wake him up.

Fascinating research is being done in both of these fields.

I work until I start making stupid mistakes. Then I know it's diminishing returns and I should just knock off.

When I'm really going good the last thing I want is a 15 minute break. I'm usually juggling a lot of things in my head at once and taking a break wrecks my concentration. Of course now that I'm a lead that only happens if I work Saturday or late at night when I'm not answering questions and running around trying to impost my will on people all day.

Barrin-
I'll commiserate. That's the worst **** I've ever seen.