4 ms·

Synthesizing conventional wisdom into readable blog posts is Paul Graham's specialty though. It clearly has a market.

neom 2y ago
Well the blog post said that some other wisdom was conventional wisdom, I'm not sure what the conventional wisdom he was pointing to is, I was just saying, people have known how to build, grow and manage enterprises for a little while now, I'm not sure why Ron Conway was so flabbergasted. Maybe he didn't make notes because he'd read some Patrick Lencioni. ;)
wahnfrieden 2y ago
Was it conventional wisdom when he published an article suggesting that lisp knowledge would have prevented 9/11 hijackers from succeeding? It’s so conventional that he de-listed the article but keeps it published and available by URL
- kragen 2y ago
  what's the url? usually pg thinks lisp knowledge makes people more likely to succeed, not less
  - wahnfrieden 2y ago
    https://paulgraham.com/hijack.html https://paulgraham.com/hijack.html > By promoting themselves from data to code, hijackers on September 11th promoted box-cutters into 400,000 lb. incendiary bombs Published September 2001
    - kragen 2y ago
      aha, this is awesome! and indeed the solution he suggests (locking the cockpit door) is the only one of the various security measures put in place to prevent a recurrence that is generally agreed to have been effective rather than just security theater i want to give pg a lot of credit for clear thinking here, but of course if he'd suggested locking cockpit doors in august 02001 instead of september, that would have been significantly more impressive your original summary of https://paulgraham.com/hijack.html https://paulgraham.com/hijack.html was not correct
      - wahnfrieden 2y ago
        Thanks for explaining my link back to me
        kragen 2y ago
        sure, i hope it helped you understand it. thanks for the link! i don't remember if i read it at the time or not
    - kazinator 2y ago
      That doesn't say anything like that Lisp knowledge could have prevented the attacks. It does say that reasoning similar to reasoning about computer systems security could have led to better aircraft security. The code/data rhetoric is not exclusively an earmark of Lisp. A primary concern in security are situations in which what is intended to be data allows for a surprising malicious use whereby it effectively becomes a way to program behaviors into the software which processes the data. For instance, Winamp being exploited by loading a specially crafted MP3 playlist file is an instance of data becoming code; no Lisp in sight. Code being a flipside of data, in the context of security, is simply the consequence of the Von Neumann model. Graham is arguing for compartments; exactly why we use containers and such. The main idea is that the passenger cabin should be sandboxed away from the cockpit, which isn't earth-shattering. Where he mentions Lisp is this: > The defense that does work is to keep code and data in separate places. Then there is no way to compromise code by playing tricks with data. Garbage-collected languages like Perl and Lisp do this, and as a result are immune from buffer overflow attacks. This point seems bungled. Garbage collection is no panacea. Bugs in a garbage collected run-time can expose applications to exploitable attacks. The advantage in Perl and Lisp is that the application programmer is not writing low-level buffer manipulation routines from scratch. That stuff is in the language run time, where we debug the low-level implementation code once, and have thousands of applications use the debugged thing. If a hole is found, we fix it once, and close the issue in thousands of apps once they upgrade to the new run-time. Garbage collected languages do not necessarily keep code and data in separate places. Moreover, non-garbage-collected languages do that. The C language can easily be implemented in a conforming manner such that the data areas (automatic storage (a.k.a. stack) and dynamic (malloc) are not executable. C keeps code and data separate. Functions are not objects. In some C implementations, like certain DSP chips, functions are in a separate space; you cannot cast a function pointer to char * and access the function image, because the resulting pointer will be interpreted in a different memory area. Of course, C data can contain pointers to functions, which can be redirected if overwritten. Lisp data can also contain function pointers: e.g. a closure object with a pointer to code and to an environment. If that is stored in a heap somewhere where an array is also stored, and the run-time has a bug which allows array overrun, it could perhaps be exploited.
      - kragen 2y ago

neom 2y ago

Well the blog post said that some other wisdom was conventional wisdom, I'm not sure what the conventional wisdom he was pointing to is, I was just saying, people have known how to build, grow and manage enterprises for a little while now, I'm not sure why Ron Conway was so flabbergasted. Maybe he didn't make notes because he'd read some Patrick Lencioni. ;)

wahnfrieden 2y ago

Was it conventional wisdom when he published an article suggesting that lisp knowledge would have prevented 9/11 hijackers from succeeding? It’s so conventional that he de-listed the article but keeps it published and available by URL

kragen 2y ago
what's the url? usually pg thinks lisp knowledge makes people more likely to succeed, not less
- wahnfrieden 2y ago
  https://paulgraham.com/hijack.html https://paulgraham.com/hijack.html > By promoting themselves from data to code, hijackers on September 11th promoted box-cutters into 400,000 lb. incendiary bombs Published September 2001
  - kragen 2y ago
    aha, this is awesome! and indeed the solution he suggests (locking the cockpit door) is the only one of the various security measures put in place to prevent a recurrence that is generally agreed to have been effective rather than just security theater i want to give pg a lot of credit for clear thinking here, but of course if he'd suggested locking cockpit doors in august 02001 instead of september, that would have been significantly more impressive your original summary of https://paulgraham.com/hijack.html https://paulgraham.com/hijack.html was not correct
    - wahnfrieden 2y ago
      Thanks for explaining my link back to me
      - kragen 2y ago
        sure, i hope it helped you understand it. thanks for the link! i don't remember if i read it at the time or not
  - kazinator 2y ago
    That doesn't say anything like that Lisp knowledge could have prevented the attacks. It does say that reasoning similar to reasoning about computer systems security could have led to better aircraft security. The code/data rhetoric is not exclusively an earmark of Lisp. A primary concern in security are situations in which what is intended to be data allows for a surprising malicious use whereby it effectively becomes a way to program behaviors into the software which processes the data. For instance, Winamp being exploited by loading a specially crafted MP3 playlist file is an instance of data becoming code; no Lisp in sight. Code being a flipside of data, in the context of security, is simply the consequence of the Von Neumann model. Graham is arguing for compartments; exactly why we use containers and such. The main idea is that the passenger cabin should be sandboxed away from the cockpit, which isn't earth-shattering. Where he mentions Lisp is this: > The defense that does work is to keep code and data in separate places. Then there is no way to compromise code by playing tricks with data. Garbage-collected languages like Perl and Lisp do this, and as a result are immune from buffer overflow attacks. This point seems bungled. Garbage collection is no panacea. Bugs in a garbage collected run-time can expose applications to exploitable attacks. The advantage in Perl and Lisp is that the application programmer is not writing low-level buffer manipulation routines from scratch. That stuff is in the language run time, where we debug the low-level implementation code once, and have thousands of applications use the debugged thing. If a hole is found, we fix it once, and close the issue in thousands of apps once they upgrade to the new run-time. Garbage collected languages do not necessarily keep code and data in separate places. Moreover, non-garbage-collected languages do that. The C language can easily be implemented in a conforming manner such that the data areas (automatic storage (a.k.a. stack) and dynamic (malloc) are not executable. C keeps code and data separate. Functions are not objects. In some C implementations, like certain DSP chips, functions are in a separate space; you cannot cast a function pointer to char * and access the function image, because the resulting pointer will be interpreted in a different memory area. Of course, C data can contain pointers to functions, which can be redirected if overwritten. Lisp data can also contain function pointers: e.g. a closure object with a pointer to code and to an environment. If that is stored in a heap somewhere where an array is also stored, and the run-time has a bug which allows array overrun, it could perhaps be exploited.
    - kragen 2y ago