This is more of historical interest than of technological interest...
Lisp in fewer than 200 lines of C
21–30 of 108 posts
Re: Lisp in fewer than 200 lines of C
#22Earlier quoted context omitted.
The author isn't responsible if people read it and think it's how they should be writing C, especially when the objective of writing lisp in as little C as possible is communicated. So why is it fair to label it irresponsible?
it's not irresponsible, but copy/paste proliferation does exist, and happens surprisingly often with code posted online like this. When you write code for posting online, you'd want to consider this problem.
If you have to worry about the entire world whenever you do anything, you'll never get anything done.
Re: Lisp in fewer than 200 lines of C
#23Earlier quoted context omitted.
"but this is an irresponsible way to write software" Segfault is a totally safe way to terminate a process on a modern desktop os. Besides - there is no 'correct' way to write software.
Sorry, this is wrong. A segfault means you got lucky and your bad memory access hit an unmapped or otherwise invalid page. Other times the program will keep running with incorrect results. Many such issues represent exploitable bugs. In any case it's a bad issue and should not be a normal failure mode for a syntax error.
"Other times the program will keep running with incorrect results. Many such issues represent exploitable bugs."
None of which matter if it's a prototype, running on a developers machine.
If you want memory safety you run the program through valgrind anyway with a large input dataset. And write unit tests. And integration tests. And so on.
The baggage of production quality software development environment is so high it easily stifles the joy of quick and dirty prototypes.
The main use of prototype is to facilitate understanding. This is the most critical constraint, whose needs drive over anything else.
Besides, who on earth is going to exploit a few hundreds of lines of code a developer runs on his or her own machine?
Re: Lisp in fewer than 200 lines of C
#24No calls to free() to match calloc(), no overflow checking in gettoken() and then I read this: > a program with missing or unmatched parenthesis, unresolved symbols, etc will likely just result in something like a segmentation fault. I understand this is just a fun thing to hack on, but this is an irresponsible way to write software. I hope no one here is reading this and thinking it's how they should be writing C.
The author isn't responsible if people read it and think it's how they should be writing C, especially when the objective of writing lisp in as little C as possible is communicated. So why is it fair to label it irresponsible?
I would add that there is already hundreds of implementations of Lisp in C and hundreds of little tutorials that are extremely similar to this online anyway, it's not like one more is going to make a difference.
Yes, his C code could be a lot better, but at the end of the day it really doesn't matter and nobody is going to be using this for anything important.
Re: Lisp in fewer than 200 lines of C
#25Earlier quoted context omitted.
"but this is an irresponsible way to write software" Segfault is a totally safe way to terminate a process on a modern desktop os. Besides - there is no 'correct' way to write software.
Sorry, this is wrong. A segfault means you got lucky and your bad memory access hit an unmapped or otherwise invalid page. Other times the program will keep running with incorrect results. Many such issues represent exploitable bugs. In any case it's a bad issue and should not be a normal failure mode for a syntax error.
I think people were referring to the free-free approach where you just quit a short lived program without deallocating anything.
Re: Lisp in fewer than 200 lines of C
#26Earlier quoted context omitted.
Sorry, this is wrong. A segfault means you got lucky and your bad memory access hit an unmapped or otherwise invalid page. Other times the program will keep running with incorrect results. Many such issues represent exploitable bugs. In any case it's a bad issue and should not be a normal failure mode for a syntax error.
"Other times the program will keep running with incorrect results. Many such issues represent exploitable bugs." None of which matter if it's a prototype, running on a developers machine. If you want memory safety you run the program through valgrind anyway with a large input dataset. And write unit tests. And integration tests. And so on. The baggage of production quality software development environment is so high…
I don't know if you noticed this but C hackers are a minority on here. Thus it's not unreasonable to think people get an impression of how C is done from submissions here. We owe it to the craft to serve as good examples. It's not as burdensome as you suggest.
Re: Lisp in fewer than 200 lines of C
#27If you like short interpreter implementations, you might like this: http://code.jsoftware.com/wiki/Essays/Incunabulum
I love how it demonstrates how recursion/loops and shape/dimension based programming can be both thin, fast and generic
Re: Lisp in fewer than 200 lines of C
#28No calls to free() to match calloc(), no overflow checking in gettoken() and then I read this: > a program with missing or unmatched parenthesis, unresolved symbols, etc will likely just result in something like a segmentation fault. I understand this is just a fun thing to hack on, but this is an irresponsible way to write software. I hope no one here is reading this and thinking it's how they should be writing C.
The author isn't responsible if people read it and think it's how they should be writing C, especially when the objective of writing lisp in as little C as possible is communicated. So why is it fair to label it irresponsible?
> The author isn't responsible if people read it and think it's how they should be writing C,
Seems we disagree on the basic premise then. If someone learns the wrong thing based on my example I view myself as responsible. (I have not been a perfect example all the time either. We owe it to ourselves and others to always improve on that front.)
Re: Lisp in fewer than 200 lines of C
#29If you like short interpreter implementations, you might like this: http://code.jsoftware.com/wiki/Essays/Incunabulum
or this interpreter of a lazy lambda calculus based language in 25 lines of (obfuscated) C:
Re: Lisp in fewer than 200 lines of C
#30I'd be surprised if it was C in 200 lines of Lisp.