Learn C and build your own Lisp (2014)(buildyourownlisp.com) |
Learn C and build your own Lisp (2014)(buildyourownlisp.com) |
From there, sure, learn C++, Java, Rust, Go, Node.js, whatever toolset matches your industry. Start with the fundamentals, though.
If you want to teach them a lisp as a first language, at least use Racket, which actually have modules designed for education. I think it's less of a headache to use a language with a more modern syntax, like python or pyret, but Racket is excellent of course. You can introduce lisp later in a undergraduate compiler/interpreter class so you don't have to talk about parsing for a month.
Lisp famously has one of the simplest syntaxes possible that is still structured, and one of the simplest data structures to understand. There's almost nothing to it.
And why would you introduce Lisp in a compiler/interpreter course, to people who are presumably already quite advanced in their knowledge?
Lisp is best as a teaching aid to introduce common high-level language concepts, in a way where it's clear how they all actually work in a familiar syntax- because it's Lisp nearly all the way down. (No black boxes.)
Most other languages suffer from a "trust me" problem, where students are taught what complicated things do but have to take it as gospel because they can't read the implementation, so they end up with high level concepts but no idea what's really going on to make those work, and a vague belief that "underneath" is more complicated and mysterious than it has to be. (Black boxes abound.) Indeed some students struggle to understand high-level concepts until they can see the mechanism.
There is a terrific benefit to learning on a platform where you can not only look up documentation within the system (man pages), but also "dig deep" into the code of any particular piece of the system you are interested in. So in learning C, you gain access to the body of knowledge contained in a Linux system, or contained in a BSD, and when you get curious about something like "These loops and conditionals are all fine and well, but how does a window actually get drawn to my screen?" you have everything at your fingertips to go and answer it.
Is that connection to the machine possible without learning C? You could use a toy operating system written in something else, but you miss out on the honesty that comes from teaching the same system that people are actually using (or at least able to use).
I think Go might not be an unreasonable alternative. It shares C's philosophical heritage, removes the need for manual memory management, and is capable of exposing a student to pointers, creating images, and HTTP communication all within the stdlib and the first chapter of the official book. The only downside, as I see it, is that one would need to additionally learn something like Rust to be able to apply the concepts to things like kernel drivers and close-to-the-metal programming.
From that foundation, they'd have the exposure they need to expand out.
I also enjoyed the path my University took. You started with Java. Data Structures was in C++, Java, and Python. Operating Systems was in C. AI was in Common Lisp (with some examples in Java and Python). Programming Languages was in any language you wanted, but examples were mostly in C and SML (SML/NJ). Computer System Design was in HDL, Assembly, and C. Software Design I and II used Java. Requirements Elicitation and Specification used Z. Concurrent/Distributed systems I and II used Promela, SPIN, TLA, and code was in Java.
Universities should not have become fearful of teaching Lisp and Smalltalk in the first year, once Java gained popularity.
C is fun for playing with pointers and doing raw memory things, but it becomes overwhelmingly painful and frustrating so quickly. And for the wrong reasons. Once you have to touch macros, or want to reuse code, it is just … old. Not hard, not minimalistic - just old. C can be fun the way bash can be fun, or baking without a recipe. It is fun to overcome an arcane mess, for the challenge. But you really learn little, or the wrong thing.
And C is not easy to look up online either. It took me so many hours figuring out some things are just not possible in C (without making it a new language via macro madness). Things that should be possible. Like „generics“. Kinda possible, but never satisfying. You constantly have to endure verbosity over abstraction. Not because that’s how computers work, but because how people did it 30 years ago, or because some industrial microcontroller needs it this way.
IMO whatever C can teach you, assembly can do better. Without tricking you into believing it’s a practical choice for most anything.
I think Rust is visually offputting for new students and it’s not really a good choice, but at least you learn something important, when things get hard. In C you are either trained to view programming as the most repetitive, joyless activity ever, or to indulge in hacking your way around broken shit, disregarding cooperation (with your future self), universal elegance and safety.
If there is „one language everyone needs to learn“ it’s some accessible and fun, which let’s enjoy computers and not tell you limits at every opportunity. There is no way to avoid C entirely, if you enjoy programming anyway; at some point you have to interface or tweak C, most likely.
Other than, oh, things like getting the same code to produce exactly the same result on two different machines, where the sizes of the types being used by the code are different.
I would say C taught and learned correctly can teach you the memory model computers use and the concept of pointers. Other languages do other things better, like Java can teach you about memory management via garbage collection and references.
It is a fantastic language to use because the tradeoff is obviously evident in the language.
You can use Smalltalk for a day. Understand the history. Understand the compromise.
And Objective-C captures a beautiful moment in the trajectory to ever more high level abstraction.
It really is astonishing that most programmers (whom I know) consider Lisp to be this weird language with too many brackets.
Programmers (humans really) are really good at having knee-jerk reactions to things and then sticking with the same opinion for some reason. As engineers, you would think we'd be better at looking at things objectively, but somehow discussions/thinking around programming languages tend to be a very emotional thing for many, so they stick with their first impressions.
LISP From Nothing (https://t3x.org/lfn/)
LISP System Implementation (https://www.t3x.org/lsi/)
Scheme 9 from Empty Space (https://t3x.org/s9book/)
They're more leaning towards the LISP implementation side, and far less on the learning C side, for which there are far better options.
[0] http://iso-9899.info/wiki/Main_Page#Stuff_that_should_be_avo...
Most of what makes Lisp great you won't find here.
When I learn a new language, I like learning something else in the way, because language learning tends to be samey once you have gone through a couple. This book was right up my alley, cause you get a sense of language design and the very basics of C.
After reading the book I managed to write some cli programs in C, modifying someone else's code.
The main caveat about the book: It Is an introduction in both it's topics. I know the bare minimum of C and I could not design a language. Yes, the lisp you build... Well I would not use for anything.
But is well written and it has exercises, and I believe exercises is how you learn.
Learn C and Build Your Own Lisp (2014) - https://news.ycombinator.com/item?id=17478489 - July 2018 (86 comments)
Learn C and build your own Lisp - https://news.ycombinator.com/item?id=10474717 - Oct 2015 (49 comments)
Learn C and build your own Lisp - https://news.ycombinator.com/item?id=7530427 - April 2014 (145 comments)
I recommend it, it was a lot of fun and I still tinker with the Connery from time to time.
0. http://buildyourownlisp.com/appendix_a_hand_rolled_parser
(The Clojure and Racket people are supposedly nice.)
Lisp and C are my favorite languages and most of the people I know who like one tend to like the other. I was surprised by this guy who praises lisp but hates C with such a passion.
This book uses gets() which is a function that can not be used safely. Any input that exceeds the buffer length will corrupt memory. The conventional wisdom in the C community is to NEVER use gets. I personally stopped reading in chapter 4 where this is done.
Unfortunately strictly avoiding memory issues is somewhat involved und thus often ignored in C beginner books. It is also hard to see unless you are pretty familiar with C's pitfalls. IMHO this is why this list of bad books is desperately needed.
The language allows too much freedom for a beginner and things can go bad quickly if you aren't rigorous about developing the right habits.
Years of experience helping people and seeing it happen first-hand is what leads to these strong opinions that you interpret as gatekeeping.
It goes beyond matters of style and straight to things like memory leaks that can cause security issues.
Then I wondered, "If these are the resources to avoid, where do these people recommend I find the good information?"
Alas, those links are mostly broken.
As a long time programmer recently learning C, I've been surprised by how prickly and unhelpful C culture tends to be.
The concensus seems to be that no published information is good enough, and none of the critics are willing to publish the good information.
Maybe I just haven't found the right groups?
Is it? As far as I saw, this is just the web site of the ##C channel on Freenode.
It would be nice if they actually bothered to explain. I'm inclined to trust Build Your Own Lisp over blah blah dot info if the latter is going to engage in nonspecific mudslinging.
MPC for a lisp? No macros? No GC? No readline but editline, but not on Windows? fgets? A lisp is fine with a readchar() and putchar() alone. The rest should be done in a safe and more expressive language, lisp. Compare to a good and small Lisp instead. It need not to be "Lisp in Small Pieces", rather your typical lisp in 10 days or in 1K project.
* https://github.com/rui314/minilisp/blob/master/minilisp.c
* SIOD Scheme in one day
Whilst "A Modern Approach" is a great book, it's hard for me to keep focused as I'm not really implementing anything other than the exercises and projects (for which there are too many IMO, and I struggle to get them all done).
I've been working through Build Your Own Lisp in parallel, and it's great fun. I get to work on an actual project, and any holes I find in my knowledge can usually be filled in via A Modern Approach.
The books were triaged based on the feedbacks we heard, the kind of questions that are asked on the channel, or how confused those readers are after reading through them.
this is a garbled thought. The average person may have trouble with manual memory management, and C requires some manual memory management (the stack is automatic), but that's not C teaching bad habits.
You can learn to do manual memory management in C, because C teaches manual memory management.
that doesn't make manual memory management a good idea for the average programmer, but that's not C's fault.
experience with C teaches good manual memory management in the same way that working with sharp knives teaches good knife management. Do professional people get cut with sharp knives? yes. Are sharp knives a good idea? yes. All the time for everybody!? nope
The aforementioned list for example has Jed Shaw's Learn C The Hard Way as having "[t]oo many factual problems and a presentation that gets you to do things wrongly before being shown how to do it correctly, and not even always then". This is an opinion held by the ##c channel, not necessarily every (competent) C programmer. LCTHW itself did a great service by introducing valgrind very early, and most criticisms [1] seem to be presentation issues that might be partly necessary for beginners and partly a matter of taste. (I personally think LCTHW was in particular unfairly attacked because of its merciless treatment of K&R. It's a shame that Jed Shaw gave up then.) To this date I don't have any good beginner-level C book to recommend, including K&R.
[1] as judged by famous Don't Learn C the Wrong Way essay by Tim Hentenaar: http://hentenaar.com/dont-learn-c-the-wrong-way
/* Read a line of user input of maximum size 2048 */
fgets(input, 2048, stdin);
Maybe they updated? Also I'd understand not trying to be 100% safe in the code here to make the code easier to read, unlike in a production version of the tool.
There's some here (http://xahlee.info/Netiquette_dir/death_of_a_troll.html) and classic discussion can be found at (https://wiki.c2.com/?SocialProblemsOfLisp). The rest of the odd pattern of every Lisp programmer I've ever met being an asshole is mostly lost to IRC history, but I guess RMS is another example.
"What a whiny little bitch." -- wudangmonk, https://news.ycombinator.com/item?id=27601530
When I look at these two statements, I wouldn't describe the first as being particularly abusive.
BUT, if you are coming from a networking/file perspective I can emphathize with you. Byte ordering is a pain for data serialization, even that has chance to cause issues and is no doubt a source of bug and pain.
typedef unsigned int whatever_t;
#define WHATEVER_MAX UINT_MAX
This is not very highly abstract, but higher than assembly language.
If you want to teach this sort of hardware independence, asm is probably not the best teaching tool.