Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learn C and build your own Lisp (2014)

buildyourownlisp.com

Post reply on HN
Print view View original

71–80 of 90 posts

Re: Learn C and build your own Lisp (2014)

#71

Post by UbrtrbNchDneRle »

desine wrote: post #11

I'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.…

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. 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.

Re: Learn C and build your own Lisp (2014)

#72

Post by Smithalicious »

theiasson wrote: post #22

This book is on "Stuff that should be avoided" list[0]. [0] http://iso-9899.info/wiki/Main_Page#Stuff_that_should_be_avo...

I cannot take this page seriously, it's just a list of links with a one-liner rarely specifying more than "it's bad".

Re: Learn C and build your own Lisp (2014)

#73

Post by Smithalicious »

astrange wrote: post #14
phlalexsh wrote: post #13

Earlier quoted context omitted.

The criticism may be justified but jeez the person who wrote that comes off like a HUGE asshole. Reminds me of people I've worked with in the past who think they know everything and have an arrogance so thick you could cut it with a knife.

Every Lisp programmer I've ever met is like this. I don't know why, but it's probably Erik Naggum's fault. They used to be called "Lisp weenies" and now would be called "abusers". (The Clojure and Racket people are supposedly nice.)

I've found the Emacs Lisp crowd to also be nice.

Re: Learn C and build your own Lisp (2014)

#74

Post by kazinator »

UbrtrbNchDneRle wrote: post #71
desine wrote: post #11

I'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.…

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.

Re: Learn C and build your own Lisp (2014)

#75

Post by thewakalix »

Koshkin wrote: post #16

Building a simple Lisp interpreter which can be then embedded in your project is the single best thing that you can do. Configuration? Solved. Serialization? Solved. Separating the application logic from the gory details of its implementation? Done.

If you don’t have time to write an embedded Lisp interpreter yourself, store-bought is fine. (I recommend Guile.)

Re: Learn C and build your own Lisp (2014)

#76

Post by mrmuagi »

kazinator wrote: post #74
UbrtrbNchDneRle wrote: post #71

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.

Hmm, unless I am mistaken, does not using portable types stdint.h u?int(8|16|32)_t fix this?

Re: Learn C and build your own Lisp (2014)

#77

Post by mrmuagi »

UbrtrbNchDneRle wrote: post #71
desine wrote: post #11

I'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.…

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. Other languages do other things better, like Java can teach you about memory management via garbage collection and references.

Re: Learn C and build your own Lisp (2014)

#78

Post by kazinator »

mrmuagi wrote: post #76
kazinator wrote: post #74

Earlier 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.

Hmm, unless I am mistaken, does not using portable types stdint.h u?int(8|16|32)_t fix this?

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.

Re: Learn C and build your own Lisp (2014)

#80

Post by mrmuagi »

kazinator wrote: post #78
mrmuagi wrote: post #76

Earlier quoted context omitted.

Hmm, unless I am mistaken, does not using portable types stdint.h u?int(8|16|32)_t fix this?

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 define your own struct types I can see where this goes awray, but I think " __attribute__((__packed__))" eliminates alignment spaces for that case.

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.

Post reply on HN