Earlier quoted context omitted.
As a student, I disagree on C. 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…
> IMO whatever C can teach you, assembly can do better. 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.
Learn C and build your own Lisp (2014)
81–90 of 90 posts
Re: Learn C and build your own Lisp (2014)
#82Earlier quoted context omitted.
My first reaction to those reviews was that they read pretty disrespectfully. Writing a book is extremely challenging and some of the feedback is not appropriate for a page that's associated with a standards body. 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…
> a page that's associated with a standards body Is it? As far as I saw, this is just the web site of the ##C channel on Freenode.
Re: Learn C and build your own Lisp (2014)
#83Earlier quoted context omitted.
As a student, I disagree on C. 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…
I never got too into C where I heavily used macros. I've seen some magic in C where you define function tables for objects and recreate object oriented programming but to be frank it's painful mimicry as well here. The best mixin I've seen is where you use function pointers to help de-duplicate code. I would say C taught and learned correctly can teach you the memory model computers use and the concept of pointers. O…
Re: Learn C and build your own Lisp (2014)
#84Earlier quoted context omitted.
Using the same int _t on all the targets may fix it in terms of correct behavior, but doesn't meet the definition of using different types on the different machines in the same overall logic, while getting the same result.
I mean, you're right that this is a problem and it gives people the ability to shoot themselvesin the foot but bytes and byte order is apart of a C programmers framework for better or worse. I want to argue it gives you incredible control of the data at the lowest level and that's the tradeoff. If you write non portable code, it seems like you have to go out of your way not using standard portability types. If you de…
typedef unsigned int whatever_t;
#define WHATEVER_MAX UINT_MAX
I can write the code such that I can edit whatever_t and WHATEVER_MAX to whatever values I want, and it still works, without changing any of the rest of the code.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.
Re: Learn C and build your own Lisp (2014)
#85Earlier quoted context omitted.
I've seen Erik Naggum's name mentioned in this context before, but years ago I looked through a bunch of his contribution on comp.lang.lisp and couldn't see anything justifying this reputation. His articles rather looked quite eloquent and thought-through. Could you provide an example?
Alas it's been a long time and I don't remember enough anymore. I just remember what I used to remember. 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.
Re: Learn C and build your own Lisp (2014)
#86I've had this in my bookmarks for awhile, intending to work through it. I think I can probably even do it solo without the guide, at this point. After years of programming, and learning (or at least playing with) many languages, I've come to a philosophical conclusion of sorts: C and Lisp should be the two languages all students start with, in my opinion. Probably SICP style Scheme education, and classic simple C89.…
Universities should not fear teaching Lisp and Smalltalk in the first year.
Universities should not have become fearful of teaching Lisp and Smalltalk in the first year, once Java gained popularity.
Re: Learn C and build your own Lisp (2014)
#87Earlier quoted context omitted.
Terrible suggestion. We need to kill all these c'isms as fast as possible. Teach people to write nice data-structures, with good api's, and with generic and sensible types. All these C'isms like returning -1 for false and 'nil' children seriously sucks. For a systems class it might still be suitable, but you could design good courses around other languages like ada, zig, rust w/e. If you want to teach them a lisp as…
I'm fairly conflicted about this. While I believe that learning C teaches bad habits - manual memory management tends to account for some absurd percentage (70-80%) of CVEs in modern programs - it's also unquestionably tethered to the history of software, and a majority of the immense foundation of tooling on a Linux system is authored in C. There is a terrific benefit to learning on a platform where you can not only…
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
Re: Learn C and build your own Lisp (2014)
#88Earlier quoted context omitted.
> IMO whatever C can teach you, assembly can do better. 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 already addressed this. IMO the portability mantra is something I disagree over „C for everyone“. It’s an annoying obstacle, but not exactly fundamental or hard to learn on the job.
Re: Learn C and build your own Lisp (2014)
#89This book is on "Stuff that should be avoided" list[0]. [0] http://iso-9899.info/wiki/Main_Page#Stuff_that_should_be_avo...
> Bad C and terrible rationales. 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
Re: Learn C and build your own Lisp (2014)
#90Earlier quoted context omitted.
It seems the author has added an appendix [0] where he replaces the library parser with a hand-rolled one. 0. http://buildyourownlisp.com/appendix_a_hand_rolled_parser
the author should not have written this. why would anyone ever hand-roll a parser? it's neither useful nor interesting