Page:Sacha Chua - Emacs Chat with Carsten Dominik.djvu/18

From Wikisource
Jump to navigation Jump to search
This page has been proofread, but needs to be validated.

different packages, play around with internals and just smoosh them together, tweak things to make things fit you.

Carsten: Yes. Quite often, when I have students come in and they want to do a little project, and then they want to program, and then there's a discussion about which programming language to use. In the institute, we often have a discussion, “We should train our students more in programming language, which language would be the right one?”

I always think it doesn't really matter, because if you know one programming language, you know them all. But there's one exception, and that's Lisp. I think Lisp is the one programming language which is really different from all the others, because the concept is really completely the other way around. If you write Lisp well, then you hardly ever assign values to variables because, there's just one flow through this chain of forms and function calls in which way this is organized.

I think that's one of the reasons why I started to learn it, because I thought that was an interesting concept.

Sacha: So you work with a ton of Lisp. What do you do in terms of debugging, refactoring it? Have you come across any great tips? Or is it just edebug all the way?

Carsten: It's edebug basically. That's what I use. Profiling. That is really the key. To find the bugs, it's just edebug. But then when you have written the code, just make it a habit to profile stuff which you have written and to see where it's spending its time. That, I think, is also a good way to debug. Often that means it's spending its time with something which is not really useful or necessary, so you have done this is in a bad way. It's a great way to educate yourself to do good programming.

Profiling teaches you a lot about yourself, programming style, and where you should pay attention. Because otherwise, you can spend days of making a little corner of your code nice and smooth and work better, to basically no outside effect. Sometimes you can put in an hour… I remember that we had these issues in the past. The agenda was extremely slow at some point. There have been several steps to really speed this up. Bastien has recently worked on this. A couple of years ago, we basically sped everything up by a factor of 10 or 20, by just finding a couple of stupid things. Things that were not done in a good way.