Live data from Hacker News

Learn C and build your own Lisp

buildyourownlisp.com

71–80 of 150 posts

Re: Learn C and build your own Lisp

#71

Earlier quoted context omitted.

If there's one thing that I really can't stand are magic numbers. The K&R says to always use constants, which means this has been a good practice for more than 40 years and I really can't grasp how someone can hope to teach something when his own knowledge lacks the basics.

In examples, magic numbers are OK. It's in large production systems (that will require tuning, which becomes impossible with "magic numbers") that they're a code smell. I'd much rather, in a small example, see: new int[2048]; than #define TWENTYFORTYEIGHT 2048 new int[TWENTYFORTYEIGHT]; Also, it's generally OK to use a "magic number" if you know that the constant will only be used in that one place, or that there is…

Tell me what the number represents rather than what the value of the number is. How about this?

    #define BUFFER_LENGTH 2048
    new int[BUFFER_LENGTH];

Re: Learn C and build your own Lisp

#72
post #68

Earlier quoted context omitted.

In examples, magic numbers are OK. It's in large production systems (that will require tuning, which becomes impossible with "magic numbers") that they're a code smell. I'd much rather, in a small example, see: new int[2048]; than #define TWENTYFORTYEIGHT 2048 new int[TWENTYFORTYEIGHT]; Also, it's generally OK to use a "magic number" if you know that the constant will only be used in that one place, or that there is…

In my experience, aliasing numbers to words has never improved any code in any way whatsoever, and sometimes causes more headaches since numbers are easy and natural to reason about numerically (big surprise...), while values such as TWENTYFORTYEIGHT impose more mental overhead and open you up to typos. It strikes me as a symptom of the "magic numbers are evil witchcraft" religion gone to the extreme. The whole point…

Programmers that replace 0 with ZERO, 1 with ONE, and 2048 with TWENTYFORTYEIGHT are severely misunderstanding why magic numbers are a bad thing in the first place. TWENTYFORTYEIGHT means exactly the same thing as 2048 (that is to say, TWENTYFORTYEIGHT means roughly nothing), but replacing 2048 with a symbolic constant that actually means something (say, BUFFER_SIZE) is a good idea.

Re: Learn C and build your own Lisp

#73
post #68

Earlier quoted context omitted.

In examples, magic numbers are OK. It's in large production systems (that will require tuning, which becomes impossible with "magic numbers") that they're a code smell. I'd much rather, in a small example, see: new int[2048]; than #define TWENTYFORTYEIGHT 2048 new int[TWENTYFORTYEIGHT]; Also, it's generally OK to use a "magic number" if you know that the constant will only be used in that one place, or that there is…

In my experience, aliasing numbers to words has never improved any code in any way whatsoever, and sometimes causes more headaches since numbers are easy and natural to reason about numerically (big surprise...), while values such as TWENTYFORTYEIGHT impose more mental overhead and open you up to typos. It strikes me as a symptom of the "magic numbers are evil witchcraft" religion gone to the extreme. The whole point…

I would say ONE_TB is an improvement over 1099511627776 when it comes to "natural to reason about" numbers, but yes, defining ZERO and ONE is moronic.

Re: Learn C and build your own Lisp

#74
I dislike the use of a parser generator libary. If it were any other language, sure. But Lisp is so easy to parse. Writing parsers is fun, and it would be a good exercise. I applaud you for wanting to teach beginners how to install libraries, but this seems like the wrong choice.

Props for mentioning conditional compilation early. It's underrepresented in books but essential for real life.

Re: Learn C and build your own Lisp

#76

I am new to programming. What is it so special about Lisp that I keep hearing about it in Hacker's News (often in Machine Learning and from old programmers)?

You will get different answers from different people. There doesn't appear to be any commonly accepted universal truths in Lisp (otherwise we'd all be programming in some variant of it by now). However there are plenty of good ideas which many more popular languages have adopted. What made it special for me was discovering the link between symbolic computing and the lambda calculus. The kernel at the center of every…

I agree with everything, though the idea of least cognitive load I think only runs skin deep (syntax).

This helpful for small scripts which need to be scanned quickly, but anything non-trivial will already have a significant layer of abstraction which takes time to parse.

Lisp people love their macros. Clojure has fancy data structures and control flow. It will take time to understand these things whether its in lisp or sandskrit.

Re: Learn C and build your own Lisp

#78

Using this guide, is it possible to create a programming language in a non-English language?

The basic principles apply whether you're using English or not. You should theoretically be able to write a programming language in any real-world language you want.

Re: Learn C and build your own Lisp

#79
post #7

I always find it so hard to help out proof-reading code for causes like this. Often, the code is more complicated than I find reasonable, while omitting things that make a lot of sense in "real" code, and it's very hard to know as an outside reader what the exact motivation for each decision was, by the author. A few such things that caused me to WTF: The initial few examples use a pointlessly static and global line…

If there's one thing that I really can't stand are magic numbers. The K&R says to always use constants, which means this has been a good practice for more than 40 years and I really can't grasp how someone can hope to teach something when his own knowledge lacks the basics.

[deleted]

Re: Learn C and build your own Lisp

#80
In similar vein to tomp's comment: if someone's interested in the bonus project of implementing macros, I've implemented a simple lisp with first class macros (fexprs): http://github.com/akkartik/wart. Moreover, you can write anonymous macros out of more primitive constructs.

Over time it's accumulated other features: http://akkartik.name/post/wart. But hopefully it's still easy to understand, because it has thorough unit tests. If you have a question about some line of code you can try changing it. Seeing what tests break is a great way to get feedback as you learn, in my experience.

Post reply on HN