On Sun, 19 Apr 2015 09:03:23 -0700, Rustom Mody wrote: > Now if Thomson and Ritchie (yeah thems the guys) could do it in 1970, > why cant we revamp this 45-year old archaic program=textfile system > today?
Revamp? What's to revamp? C, C++, C#, Java, FORTRAN, Python, Perl, Ruby, POSIX shells, Javascript, and a whole spectrum of arguably mainstream languages *still* work that way. Plenty of other languages that compile to Python or Java bytecode work that way, even if the source code isn't Python or Java. New languages, like go, Rust, and Julia work that way. What's to revamp? My IDE is UNIX. Java programmers who don't dare leave their beloved pointy clicky IDE for a command line store their source files as plain text (and they cringe when I sed sed against those source files, but I digress). The one project I ever did on a mainframe had a common text editor that supported FORTRAN, JCL, and COBOL, and stored source code in files of containing fixed length records of EBCDIC characters, IIRC. The notion of a "line of code," even in white-space-neutral languages, is deeply rooted in punch cards, and isn't going away anytime soon. IMO, until git's successor tracks content-_not_-delimited-by-linefeeds, languages will continue to work that way. Smalltalk, Forth, and LISP don't follow the program=textfile system (although LISP can, and does sometimes); and UCSD Pascal didn't (at least I think it didn't; the only tools I remember from those days all ran inside UCSD Pascal and didn't expose much of the internals). Slash rant. Sorry. Now that we've settled on UTF-8 as a successor to ASCII, the program=textfile system has a long future in front of it. Dan -- https://mail.python.org/mailman/listinfo/python-list
