61–70 of 150 posts
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)?
In the last chapter, Bonus Projects, the author mentions Static Typing & type systems. If anyone's interested in learning more: I've implemented a few simple implementations of basic (and not so basic) type systems[1]. Currently, only 3 type systems are finished (Hindley Milner's Algorithm W, and Daan Leijen's extensible rows and first-class polymorphism), while gradual typing is almost done (based on [2], in branch…
This is a good stuff. 4 years ago, I wrote a Lisp in 500 lines of C in one day after finishing SICP. Typing it out did made what I learned more concrete. https://gist.github.com/sanxiyn/523967
How good is this book for a complete beginner? I am starting to learn C in my free time and I have no objective way to judge this book.
I would think that either way you can learn C. Which way is better for you depends if you are more motivated by going through one long project, or if you prefer to have many small ones.
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.
new int[2048];
#define TWENTYFORTYEIGHT 2048
new int[TWENTYFORTYEIGHT];
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.
But it depends how the code is presented. "Here's an example of..." is different than "Here's how you should do..."
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…
It strikes me as a symptom of the "magic numbers are evil witchcraft" religion gone to the extreme. The whole point of banishing magic numbers is to improve code's clarity and robustness to change. I've seen
#define ZERO 0
#define ONE 1
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)?
Earlier quoted context omitted.
Oh wow! This is extremely useful, thank you. I've been wanting to develop my own statically-typed language, but almost all tutorials on the web are for dynamic languages with little mention given to type systems. I've already started a toy dynamically-typed language, but the step up from that to a static language seems significant, particularly given the dearth of information I can find on the web (aside from dense a…
Here's a different book you might be interested in ("Practical Foundations for Programming Languages": http://www.cs.cmu.edu/~rwh/plbook/book.pdf It gets pretty math-heavy at times, at least in the beginning (you can probably skip the first chapter if it's too rough), but ultimately the book is about programming language design and different ways of designing and evaluating typed (or un(i)typed) languages. It also lo…