That was good. There are not many true programmers around anymore. Since memory and processor power are both cheap and plentiful today's coders do not worry about tightness and efficiency. When I started as a programmer trainee, learning OJT and no degree, it was on an IBM360/30 with 32K of memory. All programming was done in Assembler. I still program in C when possible and 'play' with both FreeBSD and Linux.
I'm not saying by any means that i'm savvy at programming; but yeah, it's easy to see that that's the case (and problem for that matter) of today programming and devs. A lot of the code (even the language used) could be made a lot more efficient and "tight", there's some fails at using more demanding code or not at all smooth. It's really a shame that something like that happens in a time like this and happens even more usually than years (and decades) before.
A version of this talk is available at th-cam.com/video/2kEJoWfobpA/w-d-xo.html It has better audio. The details for that talk are available at www.bsdcan.org/2015/schedule/events/612.en.html The slides for both are the same and are available at www.bsdcan.org/2015/schedule/attachments/306_srbBSDCan2015.pdf
46:19 Why Python has been so successful is absolutely in a big part due to the language design. The fact that it is a small core that manages to include so much versatility and functionality is why so many different libraries have been implemented on top of it. Consider the elegant way it provides operator overloading, for example, which is something Java, which is a much more complex language, is unable to do.
Does anyone have further resources about the ZCODE intermediate layer that he talks about? I have found references to a paper, /S. R. Bourne. ZCODE, a Simple Machine. Cambridge University Computer Laboratory, tenth edition, 1977/, but no downloadable version of it.
That was good. There are not many true programmers around anymore. Since memory and processor power are both cheap and plentiful today's coders do not worry about tightness and efficiency.
When I started as a programmer trainee, learning OJT and no degree, it was on an IBM360/30 with 32K of memory. All programming was done in Assembler. I still program in C when possible and 'play' with both FreeBSD and Linux.
I'm not saying by any means that i'm savvy at programming; but yeah, it's easy to see that that's the case (and problem for that matter) of today programming and devs. A lot of the code (even the language used) could be made a lot more efficient and "tight", there's some fails at using more demanding code or not at all smooth. It's really a shame that something like that happens in a time like this and happens even more usually than years (and decades) before.
A version of this talk is available at th-cam.com/video/2kEJoWfobpA/w-d-xo.html It has better audio. The details for that talk are available at www.bsdcan.org/2015/schedule/events/612.en.html The slides for both are the same and are available at www.bsdcan.org/2015/schedule/attachments/306_srbBSDCan2015.pdf
Fascinating.
3:25 CAP--An early capability-based OS en.wikipedia.org/wiki/Capability-based_security .
Anyone remember "Semaphors"
46:19 Why Python has been so successful is absolutely in a big part due to the language design. The fact that it is a small core that manages to include so much versatility and functionality is why so many different libraries have been implemented on top of it. Consider the elegant way it provides operator overloading, for example, which is something Java, which is a much more complex language, is unable to do.
Does anyone have further resources about the ZCODE intermediate layer that he talks about? I have found references to a paper, /S. R. Bourne. ZCODE, a Simple Machine. Cambridge University Computer Laboratory, tenth edition, 1977/, but no downloadable version of it.
Very interesting talk. Thanks
30:10 Which is close to what Perl did.
41:45 what is the name of the shell testing framework mentioned here?
41:25 “set -ev” helps.
3:32 (what was the development like)
29:41 Tom Duff's rc manages.
The Good old "Bourne Shell"
also the bit about quoting hell hahaha even the guy who made it thinks so
6:11 He said “SNOBOL” en.wikipedia.org/wiki/SNOBOL .
So disappointing; the audio quality made it impossible to follow.
So I am not alone in finding modern man pages not very useful due to their length and complexity.
@@somercet1 thats great. On topic is yesterday I realized the gcc man page is ~22k lines so...
"leave it alone and go find another way to do it" his opinion on using the shell language.
Who are these idiots who thumbed this down? What must have been wrong with your childhood and subsequent life to find some issue with this?