* [TUHS] ratfor vibe @ 2022-01-31 20:46 Will Senn 2022-02-01 15:37 ` arnold 2022-02-03 4:00 ` Will Senn 0 siblings, 2 replies; 64+ messages in thread From: Will Senn @ 2022-01-31 20:46 UTC (permalink / raw) To: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2961 bytes --] All, I have been doing some language exploration in v7/4.3bsd and came across Software Tools (not the pascal version). It's written using ratfor, which I had seen in the v7 UPM. I fired up v7 and tried my hand at the first example: # copy - copy input characters to output integer getc integer c while(getc(c) != EOF) call putc(c) stop end The first thing I noticed was that it read more like C than Fortran (I know C quite well, Fortran just a smidge)... awesome, right? So I ran the preprocessor on it and got the following f77 code: c copy - copy input characters to output integer getc integer c c while 23000 if(.not.(getc(c) .ne. eof))goto 23001 call putc(c) goto 23000 c endwhile 23001 continue stop end Cool. The way it translated the EOF test is weird, but ok. Trying to compile it results in complaints about missing getc and putc: $ f77 copy.f copy.f: MAIN: Undefined: _getc_ _putc_ _end Ah well, no worries. I know that they're in the c lib, but don't about fortran libs... Meanwhile, over on 4.3BSD, it compiles without issue. But running it is no joy: $ ./a.out This is a test $ I remembered that the authors mentioned something about EOF, so I tweaked the code (changed EOF to -1) and rebuilt/reran: $ ./a.out This is a test This is a test $ Fascinating. Dunno why no complaints from F77 about the undefined EOF (or maybe mis-defined), but hey, it works and it's fun. I'm curious how much ratfor was used in bell labs and other locations running v6, v7, and the BSD's. When I first came across it, I was under the impression that it was a wrapper to make f66 bearable, but the manpage says it's best used with f77, so that's not quite right. As someone coming from c, I totally appreciate what it does to make the control structures I know and love available, but that wasn't the case back then, was it? C was pretty new... Was it just a temporary fix to a problem that just went away, or is there tons of ratfor out there in the wild that I just haven't seen? I found ratfor77 and it runs just fine on my mac with a few tweaks, so it's not dead: ratfor77 -C copy.r | tee copy.f C Output from Public domain Ratfor, version 1.0 C copy - copy input characters to output integer getc integer c 23000 if(getc(c) .ne. eof)then call putc(c) goto 23000 endif 23001 continue stop end What's the story? Oh, and in v6 it looks like it was rc - ratfor compiler, which is not present in v7 or 4.3BSD - is there a backstory there, too? Will [-- Attachment #2: Type: text/html, Size: 4193 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-01-31 20:46 [TUHS] ratfor vibe Will Senn @ 2022-02-01 15:37 ` arnold 2022-02-01 15:52 ` Ralph Corderoy 2022-02-03 4:00 ` Will Senn 1 sibling, 1 reply; 64+ messages in thread From: arnold @ 2022-02-01 15:37 UTC (permalink / raw) To: will.senn, tuhs Will, This will be a high level reply. I undoubtedly have some details wrong, as I wasn't inside Bell Labs. Sherman, set the wayback machine for 1974. -- Mr. Peabody In 1974, Unix was still young, and while C existed, it was not widespread. The predominant programmng language in use at the time in Bell Labs and in many, many other places, was Fortran. For our purposes, Fortran IV and Fortran 66 are the same thing: the only control flow constructs the language had was 'if', 'goto' and a 'do' loop that could only count up. The only data structure was the array. Structured Programming had started to take hold in the Computer Science community, with lots of discussion and papers about what the best control flow structures were, and so on. At the time there were preprocessors for Fortran that made it easier to program in. I don't know what got him started, by Brian Kernighan decided to write one that would give Fortran control flow constructs similar or identical to those of C. This was ratfor, for RATional FORtran. He used C and Yacc (which was also fairly young) to do this. Recognizing that the Unix environment was very pleasant, but that the wide world wouldn't drop everything they had to move to it, he and P.J. (Bill) Plauger used ratfor to create a bunch of tools that provided functionality similar or identical to many of the Unix utilities, and wrote a book on the tools, using it as a platform to at the same time teach good programming practices. This is https://www.amazon.com/Software-Tools-Brian-W-Kernighan/dp/020103669X/ref=sr_1_5?crid=LXBHQKV9D0QP&keywords=software+tools&qid=1643720166&s=books&sprefix=software+tools%2Cstripbooks%2C220&sr=1-5 which I STRONGLY recommend getting and reading, even almost 50 years after it was published (1975 or 1976). This book changed my life. Literally. The original tools are in the TUHS archives. (If anyone has not synched their copy, please do so, there were some errors in the files that I have recently fixed and which Warren has put in place.) (A modernized version of UNIX ratfor is at https://github.com/arnoldrobbins/ratfor, so you don't have to use V7 to get it. The doc is included and it's easy to make PDF of it.) The book and tools were extremely popular into the early 80s, until Unix itself started to spread. Debbie Scherer can give the history of her group, which took the tools and made them portable to all kinds of computing environments. At Georgia Tech, 3 students took the tools and adapted them into a lovely environment for use on Pr1me systems, which were otherwise rather less user-friendly. At Bell Labs, Brenda Baker wrote 'struct' which read Fortran and turned it into ratfor; see the recent list archives for more on my efforts to bring that program into the 21st century. (Apologies for the self plugs. :-) In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid the book to go with it. This is https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ref=sr_1_3?keywords=software+tools+in+pascal&link_code=qs&qid=1643727958&sourceid=Mozilla-search&sr=8-3 which I also recommend getting a copy of. This in turn led to Kernighan's famous "Pascal is not my favorite programming language" memo (which is also in my github :-). The Pascal tools are also in the TUHS archive. I hope this helps. Arnold Will Senn <will.senn@gmail.com> wrote: > All, > > I have been doing some language exploration in v7/4.3bsd and came across > Software Tools (not the pascal version). It's written using ratfor, > which I had seen in the v7 UPM. I fired up v7 and tried my hand at the > first example: > > # copy - copy input characters to output > integer getc > integer c > > while(getc(c) != EOF) > call putc(c) > stop > end > > The first thing I noticed was that it read more like C than Fortran (I > know C quite well, Fortran just a smidge)... awesome, right? So I ran > the preprocessor on it and got the following f77 code: > > c copy - copy input characters to output > integer getc > integer c > c while > 23000 if(.not.(getc(c) .ne. eof))goto 23001 > call putc(c) > goto 23000 > c endwhile > 23001 continue > stop > end > > Cool. The way it translated the EOF test is weird, but ok. Trying to > compile it results in complaints about missing getc and putc: > > $ f77 copy.f > copy.f: > MAIN: > Undefined: > _getc_ > _putc_ > _end > > Ah well, no worries. I know that they're in the c lib, but don't about > fortran libs... Meanwhile, over on 4.3BSD, it compiles without issue. > But running it is no joy: > > $ ./a.out > This is a test > $ > > I remembered that the authors mentioned something about EOF, so I > tweaked the code (changed EOF to -1) and rebuilt/reran: > > $ ./a.out > This is a test > This is a test > $ > > Fascinating. Dunno why no complaints from F77 about the undefined EOF > (or maybe mis-defined), but hey, it works and it's fun. > > I'm curious how much ratfor was used in bell labs and other locations > running v6, v7, and the BSD's. When I first came across it, I was under > the impression that it was a wrapper to make f66 bearable, but the > manpage says it's best used with f77, so that's not quite right. As > someone coming from c, I totally appreciate what it does to make the > control structures I know and love available, but that wasn't the case > back then, was it? C was pretty new... Was it just a temporary fix to a > problem that just went away, or is there tons of ratfor out there in the > wild that I just haven't seen? I found ratfor77 and it runs just fine on > my mac with a few tweaks, so it's not dead: > > ratfor77 -C copy.r | tee copy.f > C Output from Public domain Ratfor, version 1.0 > C copy - copy input characters to output > integer getc > integer c > 23000 if(getc(c) .ne. eof)then > call putc(c) > goto 23000 > endif > 23001 continue > stop > end > > What's the story? Oh, and in v6 it looks like it was rc - ratfor > compiler, which is not present in v7 or 4.3BSD - is there a backstory > there, too? > > Will > > > ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-01 15:37 ` arnold @ 2022-02-01 15:52 ` Ralph Corderoy 2022-02-01 16:58 ` Clem Cole ` (2 more replies) 0 siblings, 3 replies; 64+ messages in thread From: Ralph Corderoy @ 2022-02-01 15:52 UTC (permalink / raw) To: tuhs Hi Arnold, > In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid > the book to go with it. This is > https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ > which I also recommend getting a copy of. I agree the original Software Tools is a must read, but having done so, why would I suffer working through the hurdles put in place by Pascal compared to Ratfor? I never bothered so your recommendation makes me wonder what I missed. I did read Kernighan's ‘not my favourite’ and took from that I wouldn't enjoy the Pascal book given I'd read the original. -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-01 15:52 ` Ralph Corderoy @ 2022-02-01 16:58 ` Clem Cole 2022-02-01 17:02 ` silas poulson 2022-02-02 7:47 ` arnold 2 siblings, 0 replies; 64+ messages in thread From: Clem Cole @ 2022-02-01 16:58 UTC (permalink / raw) To: Ralph Corderoy; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 5192 bytes --] On Tue, Feb 1, 2022 at 10:53 AM Ralph Corderoy <ralph@inputplus.co.uk> wrote: > I agree the original Software Tools is a must read, but having done so, > why would I suffer working through the hurdles put in place by Pascal > compared to Ratfor? I'll take a stab. Again set Arnold's Way-Back machine to the late '60 and through the mid 1970s. The Algol vs. FTN war was raging. FTN had 'won' the Science and Engineering communities and Algol was the Math/CS types [I'm over simplifying]. In fact, when I was at CMU in the mid-70s; my professors all said *FTN was dead* ( mind you production quality FTN code has paid my salary in the HPC world my entire career ). At CMU, the compromise is all engineers were required to take an intro to computing using in FTN/WATFIV course and then all other 200 level or greater CS course after that were usualy based using an Algol/ or later Pascal. The point being any reasonable computer system being brought to market by a *credible systems vendor* had at least an implementation of FTN4 that could pass the ANSI test suite and many started to have one that support F77 [although thank you DEC VMS FTN != F77]. But ... because of the push from the teaching/CS side in most places, Pascal started to show up as a standard offering [C did not - yet - have that backing]. I suspect if you check my generation and for the next 10-20 years after, you will see Pascal was the first language you saw in college. So by the late 70s/early 80s, [except for MIT where LISP/Scheme reigned] Pascal had become the primary teaching language for the CS communities at most schools. C was considered a tad 'dirty' [not as bad as assembler -- but close]. It might have been used in an OS or Compiler course. In fact in the grad Graphics course I took, which was taught by Xerox folks, I had to get a special exception to use C. But the fact is, at that time, if you read the literature, you would believe that Pascal was going to be the future. Hence the concept of doing the SWT in Pascal made sense >>in theory<<. Another important fact was that while the P4 system made moving Pascal easier than many other languages, as Rob pointed out, the Pascal I/O was so screwy and frankly not well bound to the host OS, that every new implementation messed with it in some manner [see Brian's wonderful tome for more details]. Similarly, the lack of standardized way to do separate compilation for support libs (which had been a prime idea in FTN and allowed a rich market for libraries), really had a huge effect. Again it was solved many times with each compiler implementation, but each scheme tended to be a little different. Fortran, of course, had been around long enough and had an ANSI standard (and a test suite for it) at least made portable FTN possible. So the theory was good -- Pascal was a 'better' language in theory and everyone was coming out of school knowing it. Again, reality ... since UNIX came with C and was 'open source' in the sense that everyone that had it, had the AT&T source code. One of the first things that happened was C was retargeted to a number of processors -- often not by either the manufacturer or by the system vendor. Interestingly, this was about 50/50 between Academics/Research and Industry. So while all the world's ISA were not a PDP-11, the fun part is the code *could be made reasonably* portable - in fact *in practice* [partly because C had a pre-processor which Pascal did not and of course is what ratfor is] have one source base that could compile for different targets. The problem (as you note) these issues are >>obvious<< in hindsight, but during that time -- it was not. It certainly seems like Pascal had a lot of momentum. They were a lot compilers for a lot of systems. Look, it was the language Apple used for the Lisa and Mac. Things like UCSD Pascal was being made by the press as 'the answer for 8 bit processors' [note MSFT had a FTN for the 8080 on CPM in those days]. Turbo Pascal was, in fact, an excellent compiler. But C was starting to come on strong. FWIW: In the end, I personally believe that C 'won' because the practical side made it cheaper to use (economics always beat architecture). The cynical part of me thinks that a big reason why C++ caught on is because a lot of the pro-Pascal community got to sing the praises of OOP with C++ and they could change sides without claiming C beat Pascal. Hey, Microsoft made a pretty good C for DOS and finally going C++ probably helped. It sold more than the FORTRAN and my guess is that people using FORTRAN at that point were scientists and needed the address space that 8086 did not have. The 386 with a linear address for using things like the PharLap tools made it possible and frankly the Intel 8087 started to make that processor a better target for science. In the end, Pascal never had a code base like the FTN Scientific code base or todays C and C++ code base. FWIW: I can think of few production Pascal codes from those days that are still being used [other than the Front-End of the DEC/Intel FORTRAN compiler - which was moved from BLISS to Pascal for all the same 'C is dirty' issues BTW]. [-- Attachment #2: Type: text/html, Size: 7504 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-01 15:52 ` Ralph Corderoy 2022-02-01 16:58 ` Clem Cole @ 2022-02-01 17:02 ` silas poulson 2022-02-02 7:47 ` arnold 2 siblings, 0 replies; 64+ messages in thread From: silas poulson @ 2022-02-01 17:02 UTC (permalink / raw) To: Ralph Corderoy; +Cc: Paul Ruizendaal via TUHS > On 1 Feb 2022, at 15:52, Ralph Corderoy <ralph@inputplus.co.uk> wrote: > I never bothered so your recommendation makes me wonder what I missed. Whilst I haven’t read the original, believe Kernighan and Plauger state in preface that Pascal enabled recursive algorithms to be written in their natural manner. Don’t believe Fortran has record or set datatypes and imagine those enabled code improvements between the Ratfor and the Pascal > I did read Kernighan's ‘not my favourite’ and took from that I > wouldn't enjoy the Pascal book given I'd read the original. Not quite sure reading both editions of the book but would definitely recommend examining the code which Arnold states is available on the TUHS archive. Silas ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-01 15:52 ` Ralph Corderoy 2022-02-01 16:58 ` Clem Cole 2022-02-01 17:02 ` silas poulson @ 2022-02-02 7:47 ` arnold 2022-02-03 5:47 ` [TUHS] more about Brian Rich Morin ` (2 more replies) 2 siblings, 3 replies; 64+ messages in thread From: arnold @ 2022-02-02 7:47 UTC (permalink / raw) To: tuhs, ralph Ralph Corderoy <ralph@inputplus.co.uk> wrote: > Hi Arnold, > > > In ~ 1981, Kernighan and Plauger rewrote the tools in Pascal and redid > > the book to go with it. This is > > https://www.amazon.com/Software-Tools-Pascal-Brian-Kernighan/dp/0201103427/ > > which I also recommend getting a copy of. > > I agree the original Software Tools is a must read, but having done so, > why would I suffer working through the hurdles put in place by Pascal > compared to Ratfor? I never bothered so your recommendation makes me > wonder what I missed. I did read Kernighan's ‘not my favourite’ > and took from that I wouldn't enjoy the Pascal book given I'd read > the original. > > -- > Cheers, Ralph. As others mentioned, recursion and real data structures make code easier to read. They also refined the text some. But in general, I think the principle of "ANYTHING written by Brian Kernighan is worth reading, at least once" applies, even in this case. FWIW, Brian has told me more than once that he wishes they'd done "Software Tools In C" instead of in Pascal, and that the Pascal book was a failure to read the market correctly. Long ago, I once dreamed that I found "Software Tools In C" in a bookstore; the cover had green lettering instead of the red and blue used in the real books. I was sorta disappointed when I woke up... :-) HTH, Arnold ^ permalink raw reply [flat|nested] 64+ messages in thread
* [TUHS] more about Brian... 2022-02-02 7:47 ` arnold @ 2022-02-03 5:47 ` Rich Morin 2022-02-03 7:44 ` markus schnalke 2022-02-03 18:57 ` [TUHS] ratfor vibe silas poulson 2022-02-10 15:18 ` Ralph Corderoy 2 siblings, 1 reply; 64+ messages in thread From: Rich Morin @ 2022-02-03 5:47 UTC (permalink / raw) To: The Unix Heritage Society mailing list > On Feb 1, 2022, at 23:47, arnold@skeeve.com wrote: > > ... in general, I think the principle of "ANYTHING written by Brian > Kernighan is worth reading, at least once" applies, ... I've been having a good time watching YouTube videos that have Brian either interviewing or being interviewed by assorted folks. My favorite one, so far, is this "fireside chat": VCF East 2019 -- Brian Kernighan interviews Ken Thompson https://www.youtube.com/watch?v=EY6q5dv_B-o In any case, the K&P book I'd _really_ like to see brought up to date is "The Elements of Programming Style". It could have been subtitled "How to write small, simple programs that work." It's still a very fine book, but I'm not sure that the current crop of beginning programmers would be patient enough to deal with the sadly dated example code. If you're still here, I'll give you a vignette from many years ago. My spouse and I were both early fans of AWK, having been introduced to it around 1983 by our friend Jim Joyce. Indeed, she used AWK to process line printer plot files (dendograms, for the curious) into a format that my homegrown SunCore interpreter could render for screen display and printing on our dot matrix printer. Some of them ended up in her Master's Thesis... Anyway, we traveled with Jim to Copenhagen for a EurOpen conference. At the closing banquet, I got to an empty table before anyone else and tossed down a "no smoking" placard. Vicki and I then sat down. Shortly thereafter, Brian walked past and saw the placard. Brian: "Is this a non-smoking table?" Us: "It is now. (:-)" So, he sat down and we had a chance to dine with a personal hero (and all-around nice guy). The next day, we got on a train to Stockholm, on our way to Helsinki (to teach a Unix Intro course with Jim). Our four-person compartment turned out to include Brian, Vicki, me, and a long-suffering European businessman. IIRC, we pestered Brian for hours about AWK, Bell Labs, and so forth. He was unfailingly gracious and a wonderful person to spend the trip with. -r ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-03 5:47 ` [TUHS] more about Brian Rich Morin @ 2022-02-03 7:44 ` markus schnalke 2022-02-03 8:18 ` Rich Morin 2022-02-04 2:23 ` Adam Thornton 0 siblings, 2 replies; 64+ messages in thread From: markus schnalke @ 2022-02-03 7:44 UTC (permalink / raw) To: tuhs Hoi. [2022-02-02 21:47] Rich Morin <rdm@cfcl.com> > > In any case, the K&P book I'd _really_ like to see brought up > to date is "The Elements of Programming Style". It could have > been subtitled "How to write small, simple programs that work." > It's still a very fine book, but I'm not sure that the current > crop of beginning programmers would be patient enough to deal > with the sadly dated example code. Don't you think that ``The Practice of Programming'' is the modern version of ``The Elements of Programming Style''? (Also a K&P book, btw. ;-) ) (Of course, the C++ and Java code in there would be seen as outdated as well, by now.) But even this one, today's programmers don't wanna read. They all go for ``Clean Code'', because they seem to like the style where someone with perfect selfconfidence answers all their questions and tells them what to do, as long it is not telling them to think for themselves and compromise between various conflicting goals that you all like go reach and thus that it depends on the specific situation. The problem IMO is not some dated example code but today's programmers having few interest in learning things outside their main modern focus and the style the're used to. They usually think that running fast is the best way moving forward, but they don't realize that slowing down, looking around, understanding the paths that lead us where we are and taking time to learn and think, isn't as slow as they might expect and eventually leads to better results. Being used to reading code and understanding concepts that are not fully in the style you're used to and transferring them to one's own world actually is a valuable ability, that people should train instead of avoid. Thus especially students should do read that good old ``Elements of Programming Style'' and discuss that, not a new book. Overall I don't really think that there's much hope in getting programmers to read such stuff, because they simply don't want to. Many don't care for good code, because they don't think in code lifespans of more than three to five years. They don't care to understand what they do and how the internals work, because that's hard work without instant results. And in today's world it's usually pays out to not do it. They don't care for simplicity but they want features and nice GUIs. Besides, they use technologies that favor huge programs and often are poorly suited for programming with small programs. Likewise, their whole thinking is focussed on large programs, because that's what they've been taught the whole time. What attracts them more and probably is more helpful is something like Go, which solves their problems. They don't use it because of conceptional beauty but because of its features. If you want to attract the masses, then you have to give them solutions to their problems and their wishes, not trying to educate them. ;-) To really step forward with the Unix philosophy Go needs to enter education and become today's Java as a main programming learning language. And for those, who are different, it doesn't matter so much how dated the examples are. It's the ideas and concepts which attract them. With Go there is a very modern technology, for beginners and experts alike, that carries Unix concepts and its way of thinking and decision making throughout. That probably is much more effective than any book. Besides, there are lots of Youtube videos around Go which transport the ideas and concepts, which as well are probably much more effective today than books. Anyone on this list, on the other hand, will probably be very happy in reading on of these old books (again) ... and have a great time! :-) meillo P.S. Thanks for sharing your bwk stories! ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-03 7:44 ` markus schnalke @ 2022-02-03 8:18 ` Rich Morin 2022-02-04 2:23 ` Adam Thornton 1 sibling, 0 replies; 64+ messages in thread From: Rich Morin @ 2022-02-03 8:18 UTC (permalink / raw) To: The Unix Heritage Society mailing list > On Feb 2, 2022, at 23:44, markus schnalke <meillo@marmaro.de> wrote: > > Don't you think that ``The Practice of Programming'' is the modern > version of ``The Elements of Programming Style''? Not really. It's a fine book, but a lot bigger, so it contains a lot more (and more diverse) material. I like the facts that "The Elements of Programming Style" is pretty tightly focused and that it can be read quickly (and absorbed over time :-). That is, the title's homage to "The Elements of Style" is not an accident... -r ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-03 7:44 ` markus schnalke 2022-02-03 8:18 ` Rich Morin @ 2022-02-04 2:23 ` Adam Thornton 2022-02-04 2:34 ` [TUHS] more about Brian... [really Rust] Jon Steinhart ` (3 more replies) 1 sibling, 4 replies; 64+ messages in thread From: Adam Thornton @ 2022-02-04 2:23 UTC (permalink / raw) To: markus schnalke, The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 969 bytes --] It feels like the tide has turned from Go to Rust. I speak Go relatively fluently but have never used Rust in anger. Do the august personages on this list have opinions about Rust? People who generally have tastes consonant with mine tell me I'd like Rust. Although a bit outdated, I stand by what I wrote about Go several (six?) years ago: https://athornton.github.io/go-it-mostly-doesnt-suck Adam On Thu, Feb 3, 2022 at 12:45 AM markus schnalke <meillo@marmaro.de> wrote: > > > What attracts them more and probably is more helpful is something > like Go, which solves their problems. They don't use it because of > conceptional beauty but because of its features. If you want to > attract the masses, then you have to give them solutions to their > problems and their wishes, not trying to educate them. ;-) To > really step forward with the Unix philosophy Go needs to enter > education and become today's Java as a main programming learning > language. > > > [-- Attachment #2: Type: text/html, Size: 1452 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... [really Rust] 2022-02-04 2:23 ` Adam Thornton @ 2022-02-04 2:34 ` Jon Steinhart 2022-02-04 13:07 ` Thomas Paulsen 2022-02-04 23:18 ` Dan Cross 2022-02-04 3:28 ` [TUHS] more about Brian Dan Stromberg ` (2 subsequent siblings) 3 siblings, 2 replies; 64+ messages in thread From: Jon Steinhart @ 2022-02-04 2:34 UTC (permalink / raw) To: The Eunuchs Hysterical Society Adam Thornton writes: > Do the august personages on this list have opinions about Rust? > People who generally have tastes consonant with mine tell me I'd like Rust. Well, I'm not an august personage and am not a Rust programmer. I did spend a while trying to learn rust a while ago and wasn't impressed. Now, I'm heavily biased in that I think that it doesn't add value to keep inventing new languages to do the same old things, and I didn't see anything in Rust that I couldn't do in a myriad of other languages. But, my real issue came from some of the tutorials that I perused. Rust is being sold as "safer". As near as I can tell from the tutorials, the model is that nothing works unless you enable it. Want to be able to write a variable? Turn that on. So it seemed like the general style was to write code and then turn various things on until it ran. To me, this implies a mindset that programming errors are more important than thinking errors, and that one should hack on things until they work instead of thinking about what one is doing. I know that that's the modern definition of programming, but will never be for me. Jon ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... [really Rust] 2022-02-04 2:34 ` [TUHS] more about Brian... [really Rust] Jon Steinhart @ 2022-02-04 13:07 ` Thomas Paulsen 2022-02-04 23:18 ` Dan Cross 1 sibling, 0 replies; 64+ messages in thread From: Thomas Paulsen @ 2022-02-04 13:07 UTC (permalink / raw) To: Jon Steinhart; +Cc: tuhs --- Ursprüngliche Nachricht --- Von: Jon Steinhart <jon@fourwinds.com> Datum: 04.02.2022 03:34:40 An: The Eunuchs Hysterical Society <tuhs@tuhs.org> Betreff: Re: [TUHS] more about Brian... [really Rust] 'Well, I'm not an august personage and am not a Rust programmer. I did spend a while trying to learn rust a while ago and wasn't impressed. ...instead of thinking about what one is doing. I know that that's the modern definition of programming, but will never be for me.' check out go(lang), Ken and Rob are involved. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... [really Rust] 2022-02-04 2:34 ` [TUHS] more about Brian... [really Rust] Jon Steinhart 2022-02-04 13:07 ` Thomas Paulsen @ 2022-02-04 23:18 ` Dan Cross 1 sibling, 0 replies; 64+ messages in thread From: Dan Cross @ 2022-02-04 23:18 UTC (permalink / raw) To: Jon Steinhart; +Cc: COFF [-- Attachment #1: Type: text/plain, Size: 10779 bytes --] [TUHS to Bcc, +COFF <coff@minnie.tuhs.org> ] This isn't exactly COFF material, but I don't know what list is more appropriate. On Thu, Feb 3, 2022 at 9:41 PM Jon Steinhart <jon@fourwinds.com> wrote: > Adam Thornton writes: > > Do the august personages on this list have opinions about Rust? > > People who generally have tastes consonant with mine tell me I'd like > Rust. > > Well, I'm not an august personage and am not a Rust programmer. I did > spend a while trying to learn rust a while ago and wasn't impressed. > > Now, I'm heavily biased in that I think that it doesn't add value to keep > inventing new languages to do the same old things, and I didn't see > anything > in Rust that I couldn't do in a myriad of other languages. > I'm a Rust programmer, mostly using it for bare-metal kernel programming (though in my current gig, I find myself mostly in Rust userspace...ironically, it's back to C for the kernel). That said, I'm not a fan-boy for the language: it's not perfect. I've written basically four kernels in Rust now, to varying degrees of complexity from, "turn the computer on, spit hello-world out of the UART, and halt" to most of a v6 clone (which I really need to get around to finishing) to two rather more complex ones. I've done one ersatz kernel in C, and worked on a bunch more in C over the years. Between the two languages, I'd pick Rust over C for similar projects. Why? Because it really doesn't just do the same old things: it adds new stuff. Honest! Further, the sad reality (and the tie-in with TUHS/COFF) is that modern C has strayed far from its roots as a vehicle for systems programming, in particular, for implementing operating system kernels ( https://arxiv.org/pdf/2201.07845.pdf). C _implementations_ target the abstract machine defined in the C standard, not hardware, and they use "undefined behavior" as an excuse to make aggressive optimizations that change the semantics of one's program in such a way that some of the tricks you really do have to do when implementing an OS are just not easily done. For example, consider this code: uint16_t mul(uint16_t a, uint16_t b) { return a * b; } Does that code ever exhibit undefined behavior? The answer is that "it depends, but on most platforms, yes." Why? Because most often uint16_t is a typedef for `unsigned short int`, and because `short int` is of lesser "rank" than `int` and usually not as wide, the "usual arithmetic conversions" will apply before the multiplication. This means that the unsigned shorts will be converted to (signed) int. But on many platforms `int` will be a 32-bit integer (even 64-bit platforms!). However, the range of an unsigned 16-bit integer is such that the product of two uint16_t's can include values whose product is larger than whatever is representable in a signed 32-bit int, leading to overflow, and signed integer overflow is undefined overflow is undefined behavior. But does that _matter_ in practice? Potentially: since signed int overflow is UB, the compiler can decide it would never happen. And so if the compiler decides, for whatever reason, that (say) a saturating multiplication is the best way to implement that multiplication, then that simple single-expression function will yield results that (I'm pretty sure...) the programmer did not anticipate for some subset of inputs. How do you fix this? uint16_t mul(uint16_t a, uint16_t b) { unsigned int aa = a, bb = b; return aa * bb; } That may sound very hypothetical, but similar things have shown up in the wild: https://people.csail.mit.edu/nickolai/papers/wang-undef-2012-08-21.pdf In practice, this one is unlikely. But it's not impossible: the compiler would be right, the programmer would be wrong. One thing I've realized about C is that successive generations of compilers have tightened the noose on UB so that code that has worked for *years* all of a sudden breaks one day. There be dragons in our code. After being bit one too many times by such issues in C I decided to investigate alternatives. The choices at the time were either Rust or Go: for the latter, one gets a nice, relatively simple language, but a big complex runtime. For the former, you get a big, ugly language, but a minimal runtime akin to C: to get it going, you really don't have to do much more than set up a stack and join to a function. While people have built systems running Go at the kernel level ( https://pdos.csail.mit.edu/papers/biscuit.pdf), that seemed like a pretty heavy lift. On the other hand, if Rust could deliver on a quarter of the promises it made, I'd be ahead of the game. That was sometime in the latter half of 2018 and since then I've generally been pleasantly surprised at how much it really does deliver. For the above example, integer overflow is defined to trap. If you want wrapping (or saturating!) semantics, you request those explicitly: fn mul(a: u16, b: u16) -> u16 { a.wrapping_mul(b) } This is perfectly well-defined, and guaranteed to work pretty much forever. But, my real issue came from some of the tutorials that I perused. Rust is > being sold as "safer". As near as I can tell from the tutorials, the model > is that nothing works unless you enable it. Want to be able to write a > variable? Turn that on. So it seemed like the general style was to write > code and then turn various things on until it ran. > That's one way to look at it, but I don't think that's the intent: the model is rather, "immutable by default." Rust forces you to think about mutability, ownership, and the semantics of taking references, because the compiler enforces invariants on all of those things in a way that pretty much no other language does. It is opinionated, and not shy about sharing those opinions. To me, this implies a mindset that programming errors are more important > than thinking errors, and that one should hack on things until they work > instead of thinking about what one is doing. I know that that's the > modern definition of programming, but will never be for me. It's funny, I've had the exact opposite experience. I have found that it actually forces you to invest a _lot_ more in-up front thought about what you're doing. Writing code first, and then sprinkling in `mut` and `unsafe` until it compiles is a symptom of writing what we called "crust" on my last project at Google: that is, "C in Rust syntax." When I convinced our team to switch from C(++) to Rust, but none of us were really particularly adept at the language, and all hit similar walls of frustration; at one point, an engineer quipped, "this language has a near-vertical learning curve." And it's true that we took a multi-week productivity hit, but once we reached a certain level of familiarity, something equally curious happened: our debugging load went way, _way_ down and we started moving much faster. It turned out it was harder to get a Rust program to build at first, particularly with the bad habits we'd built up over decades of whatever languages we came from, but once it did those programs very often ran correctly the first time. You had to think _really hard_ about what data structures to use, their ownership semantics, their visibility, locking, etc. A lot of us had to absorb an emotional gut punch when the compiler showed us things that we _knew_ were correct were, in fact, not correct. But once code compiled, it tended not to have the kinds of errors that were insta-panics or triple faults (or worse, silent corruption you only noticed a million instructions later): no dangling pointers, no use-after-free bugs, no data races, no integer overflow, no out-of-bounds array references, etc. Simply put, the language _forced_ a level of discipline on us that even veteran C programmers didn't have. It also let us program at a moderately higher level of abstraction; off-by-one errors were gone because we had things like iterators. ADTs and a "Maybe" monad (the `Result<T,E>` type) greatly improved our error handling. `match` statements have to be exhaustive so you can't add a variant to an enum and forget to update code to account in just that one place (the compiler squawks at you). It's a small point, but the `?` operator removed a lot of tedious boilerplate from our code, making things clearer without sacrificing robust failure handling. Tuples for multiple return values instead of using pointers for output arguments (that have to be manually checked for validity!) are really useful. Pattern matching and destructuring in a fast systems language? Good to go. In contrast, I ran into a "bug" of sorts with KVM due to code I wrote that manifested itself as an "x86 emulation error" when it was anything but: I was turning on paging very early in boot, and I had manually set up an identity mapping for the low 4GiB of address space for the jump from 32-bit to 64-bit mode. I used gigabyte pages since it was easy, and I figured it would be supported, but I foolishly didn't check the CPU features when running this under virtualization for testing and got that weird KVM error. What was going on? It turned out KVM in this case didn't support gig pages, but the hardware did; the software worked just fine until the first time the kernel went to do IO. Then, when the hypervisor went to fetch the instruction bytes to emulate the IO instruction, it saw the gig-sized pages and errored. Since the incompatibility was manifest deep in the bowels of the instruction emulation code, that was the error that returned, even though it had nothing to do with instruction emulation. It would have been nice to plumb through some kind of meaningful error message, but in C that's annoying at best. In Rust, it's trivial. https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/ 70% of CVEs out of Microsoft over the last 15 years have been memory safety issues, and while we may poo-poo MSFT, they've got some really great engineers and let's be honest: Unix and Linux aren't that much better in this department. Our best and brightest C programmers continue to turn out highly buggy programs despite 50 years of experience. But it's not perfect. The allocator interface was a pain (it's defined to panic on allocation failure; I'm cool with a NULL return), though work is ongoing in this area. There's no ergonomic way to initialize an object 'in-place' (https://mcyoung.xyz/2021/04/26/move-ctors/), and there's no great way to say, essentially, "this points at RAM; even though I haven't initialized it, just trust me don't poison it" ( https://users.rust-lang.org/t/is-it-possible-to-read-uninitialized-memory-without-invoking-ub/63092 -- we really need a `freeze` operation). However, right now? I think it sits at a local maxima for systems languages targeting bare-metal. - Dan C. [-- Attachment #2: Type: text/html, Size: 12941 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 2:23 ` Adam Thornton 2022-02-04 2:34 ` [TUHS] more about Brian... [really Rust] Jon Steinhart @ 2022-02-04 3:28 ` Dan Stromberg 2022-02-04 5:11 ` Rich Morin 2022-02-04 7:38 ` [TUHS] more about Brian Andy Kosela 3 siblings, 0 replies; 64+ messages in thread From: Dan Stromberg @ 2022-02-04 3:28 UTC (permalink / raw) To: Adam Thornton; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 930 bytes --] On Thu, Feb 3, 2022 at 6:25 PM Adam Thornton <athornton@gmail.com> wrote: > It feels like the tide has turned from Go to Rust. I speak Go relatively > fluently but have never used Rust in anger. Do the august personages on > this > list have opinions about Rust? People who generally have tastes consonant > with mine tell me I'd like Rust. > > Although a bit outdated, I stand by what I wrote about Go several (six?) > years ago: https://athornton.github.io/go-it-mostly-doesnt-suck > I think Rust brings something new and interesting to language design. Databases like to have many readers or a single writer for a given piece of data. Rust takes this idea and makes it part of the language. It also manages to be largely memory-leak free, without a garbage collector. And it still allows you to shoot your foot off if you really want to. But there's a hoop to jump through first, which, I think, is how it should be. [-- Attachment #2: Type: text/html, Size: 1492 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 2:23 ` Adam Thornton 2022-02-04 2:34 ` [TUHS] more about Brian... [really Rust] Jon Steinhart 2022-02-04 3:28 ` [TUHS] more about Brian Dan Stromberg @ 2022-02-04 5:11 ` Rich Morin 2022-02-04 21:22 ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods 2022-02-04 7:38 ` [TUHS] more about Brian Andy Kosela 3 siblings, 1 reply; 64+ messages in thread From: Rich Morin @ 2022-02-04 5:11 UTC (permalink / raw) To: The Eunuchs Hysterical Society Well, this topic certainly took an odd turn. Owell... > On Feb 3, 2022, at 18:23, Adam Thornton <athornton@gmail.com> wrote: > > It feels like the tide has turned from Go to Rust. ... The incursions of Rust (and not Go) into Linux, Mozilla, and such may indicate a trend. > Although a bit outdated, I stand by what I wrote about Go several (six?) years ago: https://athornton.github.io/go-it-mostly-doesnt-suck I quite enjoyed this and found it to be informative, as well. My personal reaction to Go (mostly derived from skimming Brian's book) is that (a) it's well tuned to Google's needs and (b) not well tuned to mine. Specifically... Google needs a language which runs efficiently and links in a reasonable amount of time, even when HUGE sets of libraries are involved. It also needs a convenient way to do massive concurrency. Finally, it needs zillions of programmers to be fungible, dropping into code bases that they've never seen before, without tripping over landmines. My impression is that Go meets these criteria admirably. But, horses for courses... I program mostly on my own, so most of these criteria are irrelevant to my needs. I use Ruby for short scripts and Elixir for larger programs. Neither one is blazingly fast, but they both feel comfortable to write in. I like Matz's taste in design and think that José Valim has pulled together a very appealing mix of concepts and syntax from Clojure, Erlang, F#, Lisp, Ruby, etc. One problem I have with Go is that it doesn't match the way I code. Kind of like (I imagine) an oil painter might work, I start with broad swatches and fill in the details over time. So, any new program is likely to have stubs lying about, waiting to be implemented. Also, I might well calculate a variable only to support a trace statement which is currently commented out. Go is very intolerant of this sort of thing: an unused variable, IIRC, is a fatal error. Google isn't paying me to put up with this sort of thing, so I don't. Another problem I have with Go is the concurrency model. First, it uses threads, which I've never felt competent to use safely. Shared mutable state is one of those things that seem to me like an accident waiting to happen. Also, though I have no real experience with CSP, it seems like the Actor model may be better suited to exploratory programming. Getting back to Rust, my impression is that its design assumes that having the computer put up guard rails will (mostly) keep programmers from making catastrophic mistakes. In contrast, the Erlang (and thus Elixir) approach assumes that things WILL crash and that the important thing is to make sure that the system as a whole keeps running smoothly. So, for example, it provides supervision trees which can handle any crash of an Actor, etc. Also, I learned pretty early in my career (ca. 1972) that some of the biggest botches come from folks not understanding the needs of the users. I wrote a 10 KLOC PDP-11 assembly language program, based on a 1" thick specification document. It never got used, because it didn't solve the users' problem. Fine code, broken spec... Having said all this, I'm actually quite happy about the fact that Rust is creeping into Linux. The coding style is likely to be a bit more careful and it may well help to provide some protection against security issues. (ducks) -r ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) 2022-02-04 5:11 ` Rich Morin @ 2022-02-04 21:22 ` Greg A. Woods 2022-02-04 21:37 ` Richard Salz 0 siblings, 1 reply; 64+ messages in thread From: Greg A. Woods @ 2022-02-04 21:22 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 4268 bytes --] I find programming in Go to be an extremely fun, and usually relatively easy thing to do, and it's never boring or tedious (though when learning some new idiom or technique or library it can be challenging, but that's a good thing). Maybe writing tests can be tedious at times, but it's also very satisfying, and quite easy to do with the support in the Go environment. At Thu, 3 Feb 2022 21:11:14 -0800, Rich Morin <rdm@cfcl.com> wrote: Subject: Re: [TUHS] more about Brian... > > Another problem I have with Go is the concurrency model. First, > it uses threads, which I've never felt competent to use safely. > Shared mutable state is one of those things that seem to me like > an accident waiting to happen. Also, though I have no real > experience with CSP, it seems like the Actor model may be better > suited to exploratory programming. Go's concurrency model was a lot easier for me after I spent some time working in a C environment that transparently supported working with either proper threads (with the target system's libpthread as the underlying implementation) or coroutines (with libcoro as the underlying implementation). Valgrind was my friend for finding races and other things one should not do in a threaded program. > Getting back to Rust, my impression is that its design assumes > that having the computer put up guard rails will (mostly) keep > programmers from making catastrophic mistakes. In contrast, the > Erlang (and thus Elixir) approach assumes that things WILL crash > and that the important thing is to make sure that the system as a > whole keeps running smoothly. So, for example, it provides > supervision trees which can handle any crash of an Actor, etc. I find Rust to be appalling and very very very unappealing (to me). It's C++ for Perl programmers -- and all the bad parts/warts of both. Rust is, to me, ugly, inelegant, and hard to read and reason about. I still work on and write lots of C, but I'm very tired of UB. I want a C-like language (in that it's close the metal/SiO2) and that has absolutely zero UB in the spec. None. Everything MUST be defined behaviour. There are a couple of "new" languages in my sights (for applications where Go might not be ideal): - Drew Devault's secret new language: https://drewdevault.com/ - Zig -- http://ziglang.org/ (by Andrew Kelley) ready and running, apparently. BUT oh, gawd -- it's currently written in C++ and uses CMake (though apparently comes with its own built-in build system so that Zig programs don't need anything like CMake, etc.) - Jai: imperative static/strongly typed C-style language by Jonathan Loom https://inductive.no/jai/ https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md No implicit type conversions No header files Beautiful and elegant. Built-in build system. Jai code can be built on top of existing C libraries - V -- https://vlang.io Perhaps the most mature of the lot. But I would also be happy with just plain old C (though perhaps C99 not C11), with all the UB caveats nailed down into Defined Behaviour. The authors and maintainers of modern compilers are not really truly sane. They most certainly should not be allowed to exploit UB, especially not behind the user's back as they mostly do now. C's primitive nature engenders the programmer to think in terms of what the target machine is going to do, and as such it is extremely sad and disheartening that the standards committee chose to endanger C's users in so many ways. As Phil Pennock said: If I program in C, I need to defend against the compiler maintainers. [[ and future standards committee members!!! ]] If I program in Go, the language maintainers defend me from my mistakes. And I say: Modern "Standard C" is actually "Useless C" and "Unusable C" (especially if one does not fully embrace tools like Valgrind and enable all compiler features that point out UB in all possible ways at all times) BTW, there's also a new scripting language I've got on my stack to investigate further: https://wren.io -- Greg A. Woods <gwoods@acm.org> Kelowna, BC +1 250 762-7675 RoboHack <woods@robohack.ca> Planix, Inc. <woods@planix.com> Avoncote Farms <woods@avoncote.ca> [-- Attachment #2: OpenPGP Digital Signature --] [-- Type: application/pgp-signature, Size: 195 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) 2022-02-04 21:22 ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods @ 2022-02-04 21:37 ` Richard Salz 2022-02-04 22:32 ` Steffen Nurpmeso ` (2 more replies) 0 siblings, 3 replies; 64+ messages in thread From: Richard Salz @ 2022-02-04 21:37 UTC (permalink / raw) To: The Unix Heritage Society mailing list [-- Attachment #1: Type: text/plain, Size: 123 bytes --] I really wish there were a manpage that says "foo is the one true language" just like ed(1). Then this thread would stop. [-- Attachment #2: Type: text/html, Size: 182 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) 2022-02-04 21:37 ` Richard Salz @ 2022-02-04 22:32 ` Steffen Nurpmeso 2022-02-04 23:05 ` Thomas Paulsen 2022-02-04 23:15 ` Seth J. Morabito 2 siblings, 0 replies; 64+ messages in thread From: Steffen Nurpmeso @ 2022-02-04 22:32 UTC (permalink / raw) To: Richard Salz; +Cc: The Unix Heritage Society mailing list Richard Salz wrote in <CAFH29tpSUoQ08vfVJKgBqV54CAq_vHX6-Y5mfmaOxEP73mtz4A@mail.gmail.com>: |I really wish there were a manpage that says "foo is the one true language" |just like ed(1). Then this thread would stop. |I really wish there were a manpage that says "foo is the one true langua\ |ge" just like ed(1). Then this thread would stop. Manpages are second class citizens. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) 2022-02-04 21:37 ` Richard Salz 2022-02-04 22:32 ` Steffen Nurpmeso @ 2022-02-04 23:05 ` Thomas Paulsen 2022-02-04 23:15 ` Seth J. Morabito 2 siblings, 0 replies; 64+ messages in thread From: Thomas Paulsen @ 2022-02-04 23:05 UTC (permalink / raw) To: Richard Salz; +Cc: tuhs [-- Attachment #1: Type: text/html, Size: 1660 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) 2022-02-04 21:37 ` Richard Salz 2022-02-04 22:32 ` Steffen Nurpmeso 2022-02-04 23:05 ` Thomas Paulsen @ 2022-02-04 23:15 ` Seth J. Morabito 2022-02-05 1:41 ` Adam Thornton 2 siblings, 1 reply; 64+ messages in thread From: Seth J. Morabito @ 2022-02-04 23:15 UTC (permalink / raw) To: tuhs Richard Salz <rich.salz@gmail.com> writes: > I really wish there were a manpage that says "foo is the one true > language" just like ed(1). Then this thread would stop. [...] -rwxr-xr-x 1 root 24 Oct 29 1929 /bin/ed -rwxr-xr-t 4 root 1310720 Jan 1 1970 /usr/ucb/vi -rwxr-xr-x 1 root 5.89824e37 Oct 22 1990 /usr/bin/emacs [...] Of course, the wonderful thing about programming languages is that, like editors, there are so many to choose from and everyone can find one that they find enjoyment using. I really like C, and Rust, and Haskell, and Lisp, and Python, and Erlang, and many others. Some others I enjoy quite a bit less than these. And all of them can be used to write good programs and bad programs. -Seth -- Seth Morabito web@loomcom.com Poulsbo, WA, USA ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] Go vs. Rust, and etc. (was: more about Brian...) 2022-02-04 23:15 ` Seth J. Morabito @ 2022-02-05 1:41 ` Adam Thornton 0 siblings, 0 replies; 64+ messages in thread From: Adam Thornton @ 2022-02-05 1:41 UTC (permalink / raw) To: Seth J. Morabito, The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 757 bytes --] I've written COBOL for money. I'm not proud of it but I won't deny it. I've written Python, C, Perl, and Go (and doubtless some others) for both love and money at different times. I've written LISP (well, Scheme) for a grade and for love. I've written Inform 6 and 7, and 6502 assembler, and a bunch of other things, just for love. I am sure I couldn't stop writing programs if I had to. As Emmylou Harris sang: Well, I did it for kicks and I did it for hate I did it for lust and I did it for faith I did it for need and I did it for love Addiction stayed on tight like a glove On Fri, Feb 4, 2022 at 4:22 PM Seth J. Morabito <web@loomcom.com> wrote: > > I really like C, and Rust, and Haskell, and Lisp, and Python, and > Erlang, and many others. [-- Attachment #2: Type: text/html, Size: 1249 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 2:23 ` Adam Thornton ` (2 preceding siblings ...) 2022-02-04 5:11 ` Rich Morin @ 2022-02-04 7:38 ` Andy Kosela 2022-02-04 8:10 ` Steve Nickolas 3 siblings, 1 reply; 64+ messages in thread From: Andy Kosela @ 2022-02-04 7:38 UTC (permalink / raw) To: Adam Thornton; +Cc: The Eunuchs Hysterical Society On 2/4/22, Adam Thornton <athornton@gmail.com> wrote: > It feels like the tide has turned from Go to Rust. I speak Go relatively > fluently but have never used Rust in anger. Do the august personages on > this > list have opinions about Rust? People who generally have tastes consonant > with mine tell me I'd like Rust. > > Although a bit outdated, I stand by what I wrote about Go several (six?) > years ago: https://athornton.github.io/go-it-mostly-doesnt-suck 2010 Go != 2022 Go I used to be a big proponent of Go back in 2010. The language definitely felt fresh and minimal back then when Java and C++ were dominant on the market. And it definitely felt like the authors of Go wanted to replace them . It made sense in the Google environment, but very soon people realized that you can't write everything in Go. Garbage collector is cool but actually it prevents you from writing kernel or performance critical code, e.g. games. But Go became popular anyway. A lot of substandard PHP and New Age programmers started using it and it showed. In the beginning the humble authors of Go preferred minimal variable names and less than 80 char lines. In time all this turned into Java-like long, expressive variable names and extremely long lines. I really hate lines longer than 80 chars...in any language. They are really hard to focus as you need to constantly move your eyes from left to right. The same phenomenon happens with very wide browser windows. And due to popular demand they started to add on to the language features: modules, generics, etc.. The language still feels a lot less bloated than C++, but IMHO plain old C just feels more natural and minimal. And because I still program on a lot of old retro systems today I returned back to C. You can use C on pretty much everything -- from 8-bit machines to amd64. You can't say the same about Go. And Rust? If Go was trying to reinvent C, Rust definitely feels like it is trying to reinvent C++... --Andy ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 7:38 ` [TUHS] more about Brian Andy Kosela @ 2022-02-04 8:10 ` Steve Nickolas 2022-02-04 8:44 ` markus schnalke 2022-02-04 18:54 ` John Cowan 0 siblings, 2 replies; 64+ messages in thread From: Steve Nickolas @ 2022-02-04 8:10 UTC (permalink / raw) To: Andy Kosela; +Cc: The Eunuchs Hysterical Society On Fri, 4 Feb 2022, Andy Kosela wrote: > I used to be a big proponent of Go back in 2010. The language > definitely felt fresh and minimal back then when Java and C++ were > dominant on the market. And it definitely felt like the authors of Go > wanted to replace them . It made sense in the Google environment, but > very soon people realized that you can't write everything in Go. > Garbage collector is cool but actually it prevents you from writing > kernel or performance critical code, e.g. games. > > But Go became popular anyway. A lot of substandard PHP and New Age > programmers started using it and it showed. In the beginning the > humble authors of Go preferred minimal variable names and less than 80 > char lines. In time all this turned into Java-like long, expressive > variable names and extremely long lines. I really hate lines longer > than 80 chars...in any language. They are really hard to focus as you > need to constantly move your eyes from left to right. The same > phenomenon happens with very wide browser windows. I tend to prefer to keep everything to 77-79 when I'm actually formatting code for releases as opposed to "just don't care". > And due to popular demand they started to add on to the language > features: modules, generics, etc.. The language still feels a lot > less bloated than C++, but IMHO plain old C just feels more natural > and minimal. I tend to feel that C strikes a perfect balance between minimalist and powerful. > And because I still program on a lot of old retro systems today I > returned back to C. You can use C on pretty much everything -- from > 8-bit machines to amd64. You can't say the same about Go. Same. I mean, I've started to pick up 8086 assembler, but I can write C, I can code for my Apple //e, or I can code for my AMD64 boxen, or for my old PS/2, or theoretically for my ancient Macintoshes...or a number of other systems. It's not quite "write once run everywhere", but it's pretty close. -uso. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 8:10 ` Steve Nickolas @ 2022-02-04 8:44 ` markus schnalke 2022-02-04 9:16 ` Steve Nickolas 2022-02-04 18:54 ` John Cowan 1 sibling, 1 reply; 64+ messages in thread From: markus schnalke @ 2022-02-04 8:44 UTC (permalink / raw) To: tuhs Hoi. [2022-02-04 03:10] Steve Nickolas <usotsuki@buric.co> > On Fri, 4 Feb 2022, Andy Kosela wrote: > > > > And due to popular demand they started to add on to the language > > features: modules, generics, etc.. The language still feels a lot > > less bloated than C++, but IMHO plain old C just feels more natural > > and minimal. > > I tend to feel that C strikes a perfect balance between minimalist and > powerful. You have to consider that each language is a child of its time; the culture of each programming language is shaped by the people who use it, write libraries and books and teach others. If you would introduce the C language today for the first time, it wouldn't become the same language that we like. Its libraries and culture would be very different because today's programmers are different. Likewise, would Go have been introduced in older times, it probably would have evolved differently. Thus, with liking the minimalist/powerful balance of C and the style of how programs in C are written (because that C culture has grown decades ago and is now also a part of the language) you actually say that you like the old times better than the new times. (I don't blame you for that.) This all is much more about culture and what types of people program and the reasons why they program and the kinds of projects they do and the kinds of companies and their motivation in programming and how all this shapes the culture of any language ... than it is about specific languages itself, IMO. meillo ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 8:44 ` markus schnalke @ 2022-02-04 9:16 ` Steve Nickolas 0 siblings, 0 replies; 64+ messages in thread From: Steve Nickolas @ 2022-02-04 9:16 UTC (permalink / raw) To: markus schnalke; +Cc: tuhs On Fri, 4 Feb 2022, markus schnalke wrote: > You have to consider that each language is a child of its time; > the culture of each programming language is shaped by the people > who use it, write libraries and books and teach others. > > If you would introduce the C language today for the first > time, it wouldn't become the same language that we like. Its > libraries and culture would be very different because today's > programmers are different. Likewise, would Go have been > introduced in older times, it probably would have evolved > differently. Probably true. > Thus, with liking the minimalist/powerful balance of C and the > style of how programs in C are written (because that C culture > has grown decades ago and is now also a part of the language) > you actually say that you like the old times better than the new > times. (I don't blame you for that.) Could be that I cut my teeth on an 8-bit computer and did a lot of work on 16-bit systems, so I'm used to working with limited RAM and CPU. > This all is much more about culture and what types of people > program and the reasons why they program and the kinds of > projects they do and the kinds of companies and their motivation > in programming and how all this shapes the culture of any > language ... than it is about specific languages itself, IMO. There is certainly truth to that. And even human languages tend to adapt in culture-specific ways ("two countries divided by a common language" being a common joke about the US versus the UK, for example). -uso. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 8:10 ` Steve Nickolas 2022-02-04 8:44 ` markus schnalke @ 2022-02-04 18:54 ` John Cowan 2022-02-04 19:45 ` Thomas Paulsen 1 sibling, 1 reply; 64+ messages in thread From: John Cowan @ 2022-02-04 18:54 UTC (permalink / raw) To: Steve Nickolas; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 714 bytes --] On Fri, Feb 4, 2022 at 3:20 AM Steve Nickolas <usotsuki@buric.co> wrote: > > Garbage collector is cool but actually it prevents you from writing > > kernel or performance critical code, e.g. games. > I'm sure kernels with GC are on their way. I think they already exist in research contexts. As for games, the problem seems to be that the market will not pay enough for hardware to do a good job. so the attitude is "So what if it crashes, it's just a dumb game." The last C program I worked on was an interpreter for the Joy language. It had a precise GC for objects, but strings were a mess. I added libgc and ripped out all the half-assed solutions. If I had to write C today, I'd write it with libgc. [-- Attachment #2: Type: text/html, Size: 1692 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 18:54 ` John Cowan @ 2022-02-04 19:45 ` Thomas Paulsen 2022-02-04 20:28 ` Hellwig Geisse 0 siblings, 1 reply; 64+ messages in thread From: Thomas Paulsen @ 2022-02-04 19:45 UTC (permalink / raw) To: John Cowan; +Cc: tuhs [-- Attachment #1: Type: text/html, Size: 2723 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 19:45 ` Thomas Paulsen @ 2022-02-04 20:28 ` Hellwig Geisse 2022-02-04 21:03 ` Jim Capp ` (2 more replies) 0 siblings, 3 replies; 64+ messages in thread From: Hellwig Geisse @ 2022-02-04 20:28 UTC (permalink / raw) To: tuhs Hi Thomas, On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > I tell you one thing: I never ever experienced any problems with > traditional malloc()/free(). did you ever write a program which does heavy malloc()/free() on complicated (i.e., shared) data structures *and* runs for days, perhaps weeks? IMO it's very difficult to do this without a GC, and you have to exercise quite an amount of discipline to do it right. > A kernel using GC is a kernel written by inexperienced kids. Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990) used a GC, and it did that quite efficiently. Hellwig ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 20:28 ` Hellwig Geisse @ 2022-02-04 21:03 ` Jim Capp 2022-02-04 22:30 ` Steffen Nurpmeso 2022-02-04 22:25 ` Steffen Nurpmeso 2022-02-06 0:56 ` Larry McVoy 2 siblings, 1 reply; 64+ messages in thread From: Jim Capp @ 2022-02-04 21:03 UTC (permalink / raw) To: Hellwig Geisse; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 978 bytes --] I have a subsystem that populates a database from disparate data streams. It's been known to run for years without restarting, thanks to valgrind. From: "Hellwig Geisse" <hellwig.geisse@mni.thm.de> To: tuhs@minnie.tuhs.org Sent: Friday, February 4, 2022 3:28:10 PM Subject: Re: [TUHS] more about Brian... Hi Thomas, On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > I tell you one thing: I never ever experienced any problems with > traditional malloc()/free(). did you ever write a program which does heavy malloc()/free() on complicated (i.e., shared) data structures *and* runs for days, perhaps weeks? IMO it's very difficult to do this without a GC, and you have to exercise quite an amount of discipline to do it right. > A kernel using GC is a kernel written by inexperienced kids. Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990) used a GC, and it did that quite efficiently. Hellwig [-- Attachment #2: Type: text/html, Size: 1277 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 21:03 ` Jim Capp @ 2022-02-04 22:30 ` Steffen Nurpmeso 0 siblings, 0 replies; 64+ messages in thread From: Steffen Nurpmeso @ 2022-02-04 22:30 UTC (permalink / raw) To: Jim Capp; +Cc: tuhs Jim Capp wrote in <8901533.793.1644008621545.JavaMail.root@zimbraanteil>: |I have a subsystem that populates a database from disparate data streams. |It's been known to run for years without restarting, thanks to valgrind. Oh please, not. Have they fixed their file descriptor problems? Just go a bit and your allocator will tell you what there still is, and where it came from. I mean gigantic billions of modules plugged together to form a brilliant whole that is larger than its particels may be harder. $ prt-get quickdep libreoffice libnghttp2 openssl zlib xz expat jsoncpp attr bzip2 lzo libuv lzlib ncurses rhash ninja libffi libnsl libtirpc mpdecimal xorg-util-macros libgmp chrpath fakeroot giflib libpcre kmod db nasm xorg-libpciaccess xorg-libpixman libspiro libuninameslist libgpg-error linux-pam npth alsa-lib libogg libvisual opus hyphen icu cppunit glm libexttextcat hunspell libnumbertext libpaper libqrcodegen libtommath lpsolve libaio libpcre2 nspr libtool unzip file libpng potrace zstd libxml2 dbus neon acl elfutils zip readline xorg-xtrans glpk libmpfr swig eudev libgcrypt libksba libassuan libcap libvorbis libmythes curl boost libxslt libarchive gdbm sqlite3 unixodbc gcc-fortran util-linux libusb libtheora librevenge mdds raptor xmlsec cmake perl python3 nss openblas pinentry libabw libepubgen libwpd libmwaw libodfgen libpagemaker libqxp libstaroffice libvisio libwps libzmf rasqal abseil-cpp clucene metis libjpeg-turbo brotli libcuckoo fmt mariadb p5-xml-parser python3-setuptools xorg-xcb-proto lapack gnupg libmspub libwpg redland libtiff woff2 spdlog intltool meson python3-libxml2 llvm python3-markupsafe python3-chardet python3-soupsieve python3-cssselect python3-cython python3-webencodings coin-or-coinutils suitesparse gpgme libwebp lcms2 sane libixion xorg-xorgproto glib libdrm fribidi freetype orc itstool python3-mako python3-beautifulsoup4 python3-html5lib coin-or-osi libcdr libfreehand openjpeg2 liborcus xorg-libxau xorg-libxdmcp xorg-libxshmfence xorg-libice gobject-introspection liblangtag fontconfig graphite2 shared-mime-info python3-lxml coin-or-clp xorg-libxcb xorg-libsm atk graphene gstreamer libgudev libe-book libetonyek gdk-pixbuf coin-or-cgl xorg-libx11 xorg-xcb-util coin-or-cbc xorg-libxext xorg-libxfixes xorg-libxrender coin-or-mp xorg-libxinerama libglvnd xorg-libxv xorg-libxxf86vm xorg-libxi xorg-libxdamage xorg-libxcomposite xorg-libxcursor xorg-libxrandr cairo gl-headers xorg-libxvmc xorg-libxtst box2d harfbuzz mesa at-spi2-core xorg-libxft libepoxy at-spi2-atk pango gtk3 gst-plugins-base fontforge libreoffice It could be this requires a bit of work. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 20:28 ` Hellwig Geisse 2022-02-04 21:03 ` Jim Capp @ 2022-02-04 22:25 ` Steffen Nurpmeso 2022-02-06 0:56 ` Larry McVoy 2 siblings, 0 replies; 64+ messages in thread From: Steffen Nurpmeso @ 2022-02-04 22:25 UTC (permalink / raw) To: Hellwig Geisse; +Cc: tuhs Hellwig Geisse wrote in <1644006490.2458.78.camel@mni.thm.de>: |Hi Thomas, | |On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: |> I tell you one thing: I never ever experienced any problems with |> traditional malloc()/free(). | |did you ever write a program which does heavy malloc()/free() |on complicated (i.e., shared) data structures *and* runs for |days, perhaps weeks? IMO it's very difficult to do this without Yes. |a GC, and you have to exercise quite an amount of discipline |to do it right. And i fail to see the relationship really. Especially given that all kernels and all daemons i know (he!) are all written in C. Object based programming is surely easier to manage, as containers manage containers manage containers manage whatever allocations. So you have a very natural chain of life, so to say. |> A kernel using GC is a kernel written by inexperienced kids. | |Well, not exactly. Niklaus Wirth's Oberon kernel (around 1990) |used a GC, and it did that quite efficiently. Well i have no idea of that also really, so i am not saying anything. I never liked GC; i looked at the source of "that" C GC however (yes, i have forgotten the name). It maybe different to languages like Nim or Lua or, sigh, JAVA, Go and such environments etc., where possibly every object is reference counted. And that where recursive mutexes are declared evil for performance reasons, and kernel code is full of ASSERT(is_locked()) stuff. But this is speculative execution and thus far out of my league. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-04 20:28 ` Hellwig Geisse 2022-02-04 21:03 ` Jim Capp 2022-02-04 22:25 ` Steffen Nurpmeso @ 2022-02-06 0:56 ` Larry McVoy 2022-02-06 1:10 ` Will Senn 2 siblings, 1 reply; 64+ messages in thread From: Larry McVoy @ 2022-02-06 0:56 UTC (permalink / raw) To: Hellwig Geisse; +Cc: tuhs On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: > Hi Thomas, > > On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > > I tell you one thing: I never ever experienced any problems with > > traditional malloc()/free().?? > > did you ever write a program which does heavy malloc()/free() > on complicated (i.e., shared) data structures *and* runs for > days, perhaps weeks? IMO it's very difficult to do this without > a GC, and you have to exercise quite an amount of discipline > to do it right. I've done this and I've employed people who have done this. We're a dieing breed, the focus seems to be on programming languages and tools for idiots. People don't want to learn the discipline it takes to work with malloc()/free(). It's sad. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 0:56 ` Larry McVoy @ 2022-02-06 1:10 ` Will Senn 2022-02-06 4:52 ` Rob Pike 2022-02-06 16:16 ` [TUHS] more about Brian Brad Spencer 0 siblings, 2 replies; 64+ messages in thread From: Will Senn @ 2022-02-06 1:10 UTC (permalink / raw) To: Larry McVoy, Hellwig Geisse; +Cc: tuhs [-- Attachment #1: Type: text/plain, Size: 1327 bytes --] On 2/5/22 6:56 PM, Larry McVoy wrote: > On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >> Hi Thomas, >> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >>> I tell you one thing: I never ever experienced any problems with >>> traditional malloc()/free().?? >> did you ever write a program which does heavy malloc()/free() >> on complicated (i.e., shared) data structures *and* runs for >> days, perhaps weeks? IMO it's very difficult to do this without >> a GC, and you have to exercise quite an amount of discipline >> to do it right. > I've done this and I've employed people who have done this. We're > a dieing breed, the focus seems to be on programming languages and > tools for idiots. People don't want to learn the discipline it takes > to work with malloc()/free(). It's sad. I completely agree. This is ridiculous. Do modern programmer's seriously think that the old code wasn't complex or robust? Sheesh, there's code out there that has run through more millions of transactions an hour for more years than most of these folks have been alive. There's also code that's been running without any updates, for decades. Most code written by the newbreed won't run for a month without surfacing dozens of bugs. Margaret Hamilton would prolly have some choice words for these folks. [-- Attachment #2: Type: text/html, Size: 2034 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 1:10 ` Will Senn @ 2022-02-06 4:52 ` Rob Pike 2022-02-06 4:58 ` Dan Halbert ` (2 more replies) 2022-02-06 16:16 ` [TUHS] more about Brian Brad Spencer 1 sibling, 3 replies; 64+ messages in thread From: Rob Pike @ 2022-02-06 4:52 UTC (permalink / raw) To: Will Senn; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2294 bytes --] Be careful with your castigations. Yes, there is lots of old working code, but keep in mind that that code has often not been as widely tested and deployed as much of the software that runs today. The fact that it worked well on old hardware doesn't mean it will be suitable for modern networked remotely administered multicore machines pounded on by millions of people. And speaking of multicore, it's possible to write code using malloc/free that doesn't leak when run concurrently, but it's a lot easier, safer, and robust to let the machine do the memory accounting. And the fact that "kids today" can't do it doesn't mean they are lazy or failures, it means they grew up in a different time. And a lot of them are as capable as you all, just in a different environment. Lately this list has a lot of attitude and prejudice pretending to be wisdom and superiority. -rob On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote: > On 2/5/22 6:56 PM, Larry McVoy wrote: > > On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: > > Hi Thomas, > > On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > > I tell you one thing: I never ever experienced any problems with > traditional malloc()/free().?? > > did you ever write a program which does heavy malloc()/free() > on complicated (i.e., shared) data structures *and* runs for > days, perhaps weeks? IMO it's very difficult to do this without > a GC, and you have to exercise quite an amount of discipline > to do it right. > > I've done this and I've employed people who have done this. We're > a dieing breed, the focus seems to be on programming languages and > tools for idiots. People don't want to learn the discipline it takes > to work with malloc()/free(). It's sad. > > > I completely agree. This is ridiculous. Do modern programmer's seriously > think that the old code wasn't complex or robust? Sheesh, there's code out > there that has run through more millions of transactions an hour for more > years than most of these folks have been alive. There's also code that's > been running without any updates, for decades. Most code written by the > newbreed won't run for a month without surfacing dozens of bugs. Margaret > Hamilton would prolly have some choice words for these folks. > > > [-- Attachment #2: Type: text/html, Size: 3154 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 4:52 ` Rob Pike @ 2022-02-06 4:58 ` Dan Halbert 2022-02-06 5:06 ` Will Senn 2022-02-06 6:19 ` Ed Carp 2 siblings, 0 replies; 64+ messages in thread From: Dan Halbert @ 2022-02-06 4:58 UTC (permalink / raw) To: tuhs [-- Attachment #1: Type: text/plain, Size: 2632 bytes --] Thank you, Rob. I composed a similar reply, and debated whether to send it. You hit all the right points more succinctly and directly. --Dan H. On 2/5/22 23:52, Rob Pike wrote: > Be careful with your castigations. Yes, there is lots of old working > code, but keep in mind that that code has often not been as widely > tested and deployed as much of the software that runs today. The fact > that it worked well on old hardware doesn't mean it will be suitable > for modern networked remotely administered multicore machines pounded > on by millions of people. > > And speaking of multicore, it's possible to write code using > malloc/free that doesn't leak when run concurrently, but it's a lot > easier, safer, and robust to let the machine do the memory accounting. > And the fact that "kids today" can't do it doesn't mean they are lazy > or failures, it means they grew up in a different time. And a lot of > them are as capable as you all, just in a different environment. > > Lately this list has a lot of attitude and prejudice pretending to be > wisdom and superiority. > > -rob > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote: > > On 2/5/22 6:56 PM, Larry McVoy wrote: >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >>> Hi Thomas, >>> >>> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >>>> I tell you one thing: I never ever experienced any problems with >>>> traditional malloc()/free().?? >>> did you ever write a program which does heavy malloc()/free() >>> on complicated (i.e., shared) data structures *and* runs for >>> days, perhaps weeks? IMO it's very difficult to do this without >>> a GC, and you have to exercise quite an amount of discipline >>> to do it right. >> I've done this and I've employed people who have done this. We're >> a dieing breed, the focus seems to be on programming languages and >> tools for idiots. People don't want to learn the discipline it takes >> to work with malloc()/free(). It's sad. > > I completely agree. This is ridiculous. Do modern programmer's > seriously think that the old code wasn't complex or robust? > Sheesh, there's code out there that has run through more millions > of transactions an hour for more years than most of these folks > have been alive. There's also code that's been running without any > updates, for decades. Most code written by the newbreed won't run > for a month without surfacing dozens of bugs. Margaret Hamilton > would prolly have some choice words for these folks. > > [-- Attachment #2: Type: text/html, Size: 4193 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 4:52 ` Rob Pike 2022-02-06 4:58 ` Dan Halbert @ 2022-02-06 5:06 ` Will Senn 2022-02-06 6:19 ` Ed Carp 2 siblings, 0 replies; 64+ messages in thread From: Will Senn @ 2022-02-06 5:06 UTC (permalink / raw) To: Rob Pike; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 2588 bytes --] Sure. It's gone off topic, quite a ways. I wasn't really castigating, just marveling at the hubris. On 2/5/22 10:52 PM, Rob Pike wrote: > Be careful with your castigations. Yes, there is lots of old working > code, but keep in mind that that code has often not been as widely > tested and deployed as much of the software that runs today. The fact > that it worked well on old hardware doesn't mean it will be suitable > for modern networked remotely administered multicore machines pounded > on by millions of people. > > And speaking of multicore, it's possible to write code using > malloc/free that doesn't leak when run concurrently, but it's a lot > easier, safer, and robust to let the machine do the memory accounting. > And the fact that "kids today" can't do it doesn't mean they are lazy > or failures, it means they grew up in a different time. And a lot of > them are as capable as you all, just in a different environment. > > Lately this list has a lot of attitude and prejudice pretending to be > wisdom and superiority. > > -rob > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote: > > On 2/5/22 6:56 PM, Larry McVoy wrote: >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >>> Hi Thomas, >>> >>> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >>>> I tell you one thing: I never ever experienced any problems with >>>> traditional malloc()/free().?? >>> did you ever write a program which does heavy malloc()/free() >>> on complicated (i.e., shared) data structures *and* runs for >>> days, perhaps weeks? IMO it's very difficult to do this without >>> a GC, and you have to exercise quite an amount of discipline >>> to do it right. >> I've done this and I've employed people who have done this. We're >> a dieing breed, the focus seems to be on programming languages and >> tools for idiots. People don't want to learn the discipline it takes >> to work with malloc()/free(). It's sad. > > I completely agree. This is ridiculous. Do modern programmer's > seriously think that the old code wasn't complex or robust? > Sheesh, there's code out there that has run through more millions > of transactions an hour for more years than most of these folks > have been alive. There's also code that's been running without any > updates, for decades. Most code written by the newbreed won't run > for a month without surfacing dozens of bugs. Margaret Hamilton > would prolly have some choice words for these folks. > > [-- Attachment #2: Type: text/html, Size: 4150 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 4:52 ` Rob Pike 2022-02-06 4:58 ` Dan Halbert 2022-02-06 5:06 ` Will Senn @ 2022-02-06 6:19 ` Ed Carp 2022-02-06 6:27 ` Rob Pike 2 siblings, 1 reply; 64+ messages in thread From: Ed Carp @ 2022-02-06 6:19 UTC (permalink / raw) To: Rob Pike; +Cc: TUHS main list "it's a lot easier, safer, and robust to let the machine do the memory accounting" I disagree. "The machine" is, as you know, is in reality app code built on top of frameworks built on top of libraries built on top of more libraries built on top of malloc/free calls. While the automated testing tools are a lot better than they were when I started coding C back in 1985, we're still talking about a *lot* of complexity and a lot of layers of code, and programmers today know far less about things like boundary conditions, off-by-one bugs, and the like that bit us in the ass - hard - and so we learned to watch for those sorts of things. On 2/5/22, Rob Pike <robpike@gmail.com> wrote: > Be careful with your castigations. Yes, there is lots of old working code, > but keep in mind that that code has often not been as widely tested and > deployed as much of the software that runs today. The fact that it worked > well on old hardware doesn't mean it will be suitable for modern networked > remotely administered multicore machines pounded on by millions of people. > > And speaking of multicore, it's possible to write code using malloc/free > that doesn't leak when run concurrently, but it's a lot easier, safer, and > robust to let the machine do the memory accounting. And the fact that "kids > today" can't do it doesn't mean they are lazy or failures, it means they > grew up in a different time. And a lot of them are as capable as you all, > just in a different environment. > > Lately this list has a lot of attitude and prejudice pretending to be > wisdom and superiority. > > -rob > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote: > >> On 2/5/22 6:56 PM, Larry McVoy wrote: >> >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >> >> Hi Thomas, >> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >> >> I tell you one thing: I never ever experienced any problems with >> traditional malloc()/free().?? >> >> did you ever write a program which does heavy malloc()/free() >> on complicated (i.e., shared) data structures *and* runs for >> days, perhaps weeks? IMO it's very difficult to do this without >> a GC, and you have to exercise quite an amount of discipline >> to do it right. >> >> I've done this and I've employed people who have done this. We're >> a dieing breed, the focus seems to be on programming languages and >> tools for idiots. People don't want to learn the discipline it takes >> to work with malloc()/free(). It's sad. >> >> >> I completely agree. This is ridiculous. Do modern programmer's seriously >> think that the old code wasn't complex or robust? Sheesh, there's code >> out >> there that has run through more millions of transactions an hour for more >> years than most of these folks have been alive. There's also code that's >> been running without any updates, for decades. Most code written by the >> newbreed won't run for a month without surfacing dozens of bugs. Margaret >> Hamilton would prolly have some choice words for these folks. >> >> >> > ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 6:19 ` Ed Carp @ 2022-02-06 6:27 ` Rob Pike 2022-02-06 6:40 ` Stuart Remphrey ` (3 more replies) 0 siblings, 4 replies; 64+ messages in thread From: Rob Pike @ 2022-02-06 6:27 UTC (permalink / raw) To: Ed Carp; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 3980 bytes --] I don't understand your disagreement. In what way is automatic memory management harder, more unsafe, and less robust than hand-written memory management using malloc and free? You seem to think that garbage collection only exists in languages that have a smell you don't like. Perhaps that's true, but it's been around for 60 or more years and a lot of important languages use it, while the programmers that use those languages are often quite capable. Using malloc and free might be a badge of honor to some, but it's also a failure of automation. This discussion should probably go to COFF, or perhaps I should just leave the list. I am starting to feel uncomfortable here. Too much swagger. -rob On Sun, Feb 6, 2022 at 5:19 PM Ed Carp <erc@pobox.com> wrote: > "it's a lot easier, safer, and robust to let the machine do the memory > accounting" > > I disagree. "The machine" is, as you know, is in reality app code > built on top of frameworks built on top of libraries built on top of > more libraries built on top of malloc/free calls. While the automated > testing tools are a lot better than they were when I started coding C > back in 1985, we're still talking about a *lot* of complexity and a > lot of layers of code, and programmers today know far less about > things like boundary conditions, off-by-one bugs, and the like that > bit us in the ass - hard - and so we learned to watch for those sorts > of things. > > On 2/5/22, Rob Pike <robpike@gmail.com> wrote: > > Be careful with your castigations. Yes, there is lots of old working > code, > > but keep in mind that that code has often not been as widely tested and > > deployed as much of the software that runs today. The fact that it worked > > well on old hardware doesn't mean it will be suitable for modern > networked > > remotely administered multicore machines pounded on by millions of > people. > > > > And speaking of multicore, it's possible to write code using malloc/free > > that doesn't leak when run concurrently, but it's a lot easier, safer, > and > > robust to let the machine do the memory accounting. And the fact that > "kids > > today" can't do it doesn't mean they are lazy or failures, it means they > > grew up in a different time. And a lot of them are as capable as you all, > > just in a different environment. > > > > Lately this list has a lot of attitude and prejudice pretending to be > > wisdom and superiority. > > > > -rob > > > > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote: > > > >> On 2/5/22 6:56 PM, Larry McVoy wrote: > >> > >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: > >> > >> Hi Thomas, > >> > >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > >> > >> I tell you one thing: I never ever experienced any problems with > >> traditional malloc()/free().?? > >> > >> did you ever write a program which does heavy malloc()/free() > >> on complicated (i.e., shared) data structures *and* runs for > >> days, perhaps weeks? IMO it's very difficult to do this without > >> a GC, and you have to exercise quite an amount of discipline > >> to do it right. > >> > >> I've done this and I've employed people who have done this. We're > >> a dieing breed, the focus seems to be on programming languages and > >> tools for idiots. People don't want to learn the discipline it takes > >> to work with malloc()/free(). It's sad. > >> > >> > >> I completely agree. This is ridiculous. Do modern programmer's seriously > >> think that the old code wasn't complex or robust? Sheesh, there's code > >> out > >> there that has run through more millions of transactions an hour for > more > >> years than most of these folks have been alive. There's also code that's > >> been running without any updates, for decades. Most code written by the > >> newbreed won't run for a month without surfacing dozens of bugs. > Margaret > >> Hamilton would prolly have some choice words for these folks. > >> > >> > >> > > > [-- Attachment #2: Type: text/html, Size: 5097 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 6:27 ` Rob Pike @ 2022-02-06 6:40 ` Stuart Remphrey 2022-02-06 6:44 ` Bakul Shah ` (2 subsequent siblings) 3 siblings, 0 replies; 64+ messages in thread From: Stuart Remphrey @ 2022-02-06 6:40 UTC (permalink / raw) To: Rob Pike; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 4578 bytes --] I like the point that malloc()/free() could be seen as a "failure of automation". As to the GC and (Go | Rust) vs (C | Java | C++) earlier in this increasingly-off-topic thread: perhaps it's an issue of whether that automation is applied at runtime or compile-time... (the latter still requiring guidance from the programmer, trading some programmer-brain-time against cpu-execution-time & memory space?) On Sun, 6 Feb 2022, 14:28 Rob Pike, <robpike@gmail.com> wrote: > I don't understand your disagreement. In what way is automatic memory > management harder, more unsafe, and less robust than hand-written memory > management using malloc and free? > > You seem to think that garbage collection only exists in languages that > have a smell you don't like. Perhaps that's true, but it's been around for > 60 or more years and a lot of important languages use it, while the > programmers that use those languages are often quite capable. > > Using malloc and free might be a badge of honor to some, but it's also a > failure of automation. > > This discussion should probably go to COFF, or perhaps I should just leave > the list. I am starting to feel uncomfortable here. Too much swagger. > > -rob > > > On Sun, Feb 6, 2022 at 5:19 PM Ed Carp <erc@pobox.com> wrote: > >> "it's a lot easier, safer, and robust to let the machine do the memory >> accounting" >> >> I disagree. "The machine" is, as you know, is in reality app code >> built on top of frameworks built on top of libraries built on top of >> more libraries built on top of malloc/free calls. While the automated >> testing tools are a lot better than they were when I started coding C >> back in 1985, we're still talking about a *lot* of complexity and a >> lot of layers of code, and programmers today know far less about >> things like boundary conditions, off-by-one bugs, and the like that >> bit us in the ass - hard - and so we learned to watch for those sorts >> of things. >> >> On 2/5/22, Rob Pike <robpike@gmail.com> wrote: >> > Be careful with your castigations. Yes, there is lots of old working >> code, >> > but keep in mind that that code has often not been as widely tested and >> > deployed as much of the software that runs today. The fact that it >> worked >> > well on old hardware doesn't mean it will be suitable for modern >> networked >> > remotely administered multicore machines pounded on by millions of >> people. >> > >> > And speaking of multicore, it's possible to write code using malloc/free >> > that doesn't leak when run concurrently, but it's a lot easier, safer, >> and >> > robust to let the machine do the memory accounting. And the fact that >> "kids >> > today" can't do it doesn't mean they are lazy or failures, it means they >> > grew up in a different time. And a lot of them are as capable as you >> all, >> > just in a different environment. >> > >> > Lately this list has a lot of attitude and prejudice pretending to be >> > wisdom and superiority. >> > >> > -rob >> > >> > >> > On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote: >> > >> >> On 2/5/22 6:56 PM, Larry McVoy wrote: >> >> >> >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: >> >> >> >> Hi Thomas, >> >> >> >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: >> >> >> >> I tell you one thing: I never ever experienced any problems with >> >> traditional malloc()/free().?? >> >> >> >> did you ever write a program which does heavy malloc()/free() >> >> on complicated (i.e., shared) data structures *and* runs for >> >> days, perhaps weeks? IMO it's very difficult to do this without >> >> a GC, and you have to exercise quite an amount of discipline >> >> to do it right. >> >> >> >> I've done this and I've employed people who have done this. We're >> >> a dieing breed, the focus seems to be on programming languages and >> >> tools for idiots. People don't want to learn the discipline it takes >> >> to work with malloc()/free(). It's sad. >> >> >> >> >> >> I completely agree. This is ridiculous. Do modern programmer's >> seriously >> >> think that the old code wasn't complex or robust? Sheesh, there's code >> >> out >> >> there that has run through more millions of transactions an hour for >> more >> >> years than most of these folks have been alive. There's also code >> that's >> >> been running without any updates, for decades. Most code written by the >> >> newbreed won't run for a month without surfacing dozens of bugs. >> Margaret >> >> Hamilton would prolly have some choice words for these folks. >> >> >> >> >> >> >> > >> > [-- Attachment #2: Type: text/html, Size: 6052 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 6:27 ` Rob Pike 2022-02-06 6:40 ` Stuart Remphrey @ 2022-02-06 6:44 ` Bakul Shah 2022-02-06 19:08 ` Steffen Nurpmeso 2022-02-06 12:52 ` Ralph Corderoy 2022-02-06 13:14 ` Ed Carp 3 siblings, 1 reply; 64+ messages in thread From: Bakul Shah @ 2022-02-06 6:44 UTC (permalink / raw) To: Rob Pike; +Cc: TUHS main list Just ignore the swagger. I would go further than Rob in that even for sequential programs there is no virtue in sticking to malloc/free if you don't have to. The whole point of automation (for me) is to delegate all the boring and repetitive work to computers so that I can focus on more interesting things! And solving malloc/free related bugs is boring and repetitive. For embedded code in limited space you want to use memory carefully but for most of userland code we don't have to worry about saving every byte. Most userland code is not real time code (and doesn't run on realtime OSes). That doesn't mean using memory like water -- there is a middle ground. Don't blame the GC for incompetently programmed websites or for layers of code using third party libraries using other third party libraries. > On Feb 5, 2022, at 10:27 PM, Rob Pike <robpike@gmail.com> wrote: > > I don't understand your disagreement. In what way is automatic memory management harder, more unsafe, and less robust than hand-written memory management using malloc and free? > > You seem to think that garbage collection only exists in languages that have a smell you don't like. Perhaps that's true, but it's been around for 60 or more years and a lot of important languages use it, while the programmers that use those languages are often quite capable. > > Using malloc and free might be a badge of honor to some, but it's also a failure of automation. > > This discussion should probably go to COFF, or perhaps I should just leave the list. I am starting to feel uncomfortable here. Too much swagger. > > -rob > > > On Sun, Feb 6, 2022 at 5:19 PM Ed Carp <erc@pobox.com> wrote: > "it's a lot easier, safer, and robust to let the machine do the memory > accounting" > > I disagree. "The machine" is, as you know, is in reality app code > built on top of frameworks built on top of libraries built on top of > more libraries built on top of malloc/free calls. While the automated > testing tools are a lot better than they were when I started coding C > back in 1985, we're still talking about a *lot* of complexity and a > lot of layers of code, and programmers today know far less about > things like boundary conditions, off-by-one bugs, and the like that > bit us in the ass - hard - and so we learned to watch for those sorts > of things. > > On 2/5/22, Rob Pike <robpike@gmail.com> wrote: > > Be careful with your castigations. Yes, there is lots of old working code, > > but keep in mind that that code has often not been as widely tested and > > deployed as much of the software that runs today. The fact that it worked > > well on old hardware doesn't mean it will be suitable for modern networked > > remotely administered multicore machines pounded on by millions of people. > > > > And speaking of multicore, it's possible to write code using malloc/free > > that doesn't leak when run concurrently, but it's a lot easier, safer, and > > robust to let the machine do the memory accounting. And the fact that "kids > > today" can't do it doesn't mean they are lazy or failures, it means they > > grew up in a different time. And a lot of them are as capable as you all, > > just in a different environment. > > > > Lately this list has a lot of attitude and prejudice pretending to be > > wisdom and superiority. > > > > -rob > > > > > > On Sun, Feb 6, 2022 at 12:11 PM Will Senn <will.senn@gmail.com> wrote: > > > >> On 2/5/22 6:56 PM, Larry McVoy wrote: > >> > >> On Fri, Feb 04, 2022 at 09:28:10PM +0100, Hellwig Geisse wrote: > >> > >> Hi Thomas, > >> > >> On Fr, 2022-02-04 at 20:45 +0100, Thomas Paulsen wrote: > >> > >> I tell you one thing: I never ever experienced any problems with > >> traditional malloc()/free().?? > >> > >> did you ever write a program which does heavy malloc()/free() > >> on complicated (i.e., shared) data structures *and* runs for > >> days, perhaps weeks? IMO it's very difficult to do this without > >> a GC, and you have to exercise quite an amount of discipline > >> to do it right. > >> > >> I've done this and I've employed people who have done this. We're > >> a dieing breed, the focus seems to be on programming languages and > >> tools for idiots. People don't want to learn the discipline it takes > >> to work with malloc()/free(). It's sad. > >> > >> > >> I completely agree. This is ridiculous. Do modern programmer's seriously > >> think that the old code wasn't complex or robust? Sheesh, there's code > >> out > >> there that has run through more millions of transactions an hour for more > >> years than most of these folks have been alive. There's also code that's > >> been running without any updates, for decades. Most code written by the > >> newbreed won't run for a month without surfacing dozens of bugs. Margaret > >> Hamilton would prolly have some choice words for these folks. > >> > >> > >> > > ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 6:44 ` Bakul Shah @ 2022-02-06 19:08 ` Steffen Nurpmeso 0 siblings, 0 replies; 64+ messages in thread From: Steffen Nurpmeso @ 2022-02-06 19:08 UTC (permalink / raw) To: Bakul Shah; +Cc: TUHS main list Bakul Shah wrote in <10B8CDC8-12FF-4B93-AD34-3393BA5C13D5@iitbombay.org>: |Just ignore the swagger. | |I would go further than Rob in that even for sequential |programs there is no virtue in sticking to malloc/free if you |don't have to. The whole point of automation (for me) is to Well maybe. When i do perl or awk i do not even think about that memory as such exists, mostly. In so far. |delegate all the boring and repetitive work to computers so |that I can focus on more interesting things! And solving |malloc/free related bugs is boring and repetitive. For But, you know, this is a philosophy i do not like. Just like i never understood why Stroustrup gave C++ exceptions the full power of flexibility instead of allowing only a single base class but giving the entire C++ environment a toggle to produce __FILE__/__LINE__ diagnosis out of the box. Or instead of even introducing symbols which go the non-preprocessor if(XY) way and allowing access to these from within code if XY is true. So you have to invent preprocessor mess in order to be able to pass debug info down the call chain, or use non-portable ELF or so related info (which i never did). But if you do have the information at hand, your program could say #?1|kent:steffen$ s-nail -Rf /dev/empty s-nail: /dev/empty: No such entry, file or directory ... #?0!0/NONE#ERROR|:? quit ... s-nail[info]: Count cur/peek/all: 4/ 1658/ 12524 ... s-nail[info]: 0x55ef9a581b50 (72 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064 There are messages in the error ring, manageable via `errors' command??? s-nail[info]: 0x55ef9a581ae0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035 ????????????????E???????P?X??U??E??????? s-nail[info]: 0x55ef9a581420 (48 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1064 /dev/empty: No such entry, file or directory???? s-nail[info]: 0x55ef9a5813b0 (40 bytes): /home/steffen/src/nail.git/src/mx/auxlily.c, line 1035 ??X??U??????????,??????? ?X??U??,???^??? even upon receive of a signal. And this is just a silly wrapper, not even a complete thing. It is just like always, "there is no wrong weather, just the wrong clothes". |embedded code in limited space you want to use memory |carefully but for most of userland code we don't have to |worry about saving every byte. Most userland code is not real |time code (and doesn't run on realtime OSes). That doesn't |mean using memory like water -- there is a middle ground. |Don't blame the GC for incompetently programmed websites or |for layers of code using third party libraries using other |third party libraries. All the new languages [offer] [myriads] of [symbol] [annotations] in order to improve things, which also aids in giving more info to the tools. And, what is maybe more important, all programs written in these languages are written from scratch. And even if people tend to produce bugs here and there, and tend to forget the background of a problem now and then, or did not know about it when they wrote the code, ... the experience with programming has improved a lot compared to times that members of these list went through! That is of course only my personal opinion. I like C a lot (like C++ without everything but classes). --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 6:27 ` Rob Pike 2022-02-06 6:40 ` Stuart Remphrey 2022-02-06 6:44 ` Bakul Shah @ 2022-02-06 12:52 ` Ralph Corderoy 2022-02-06 13:14 ` Ed Carp 3 siblings, 0 replies; 64+ messages in thread From: Ralph Corderoy @ 2022-02-06 12:52 UTC (permalink / raw) To: tuhs rob wrote: > This discussion should probably go to COFF It should have long ago; way too noisy and off-topic for TUHS. -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 6:27 ` Rob Pike ` (2 preceding siblings ...) 2022-02-06 12:52 ` Ralph Corderoy @ 2022-02-06 13:14 ` Ed Carp 2022-02-06 14:13 ` Dan Cross 2022-02-06 14:15 ` Larry McVoy 3 siblings, 2 replies; 64+ messages in thread From: Ed Carp @ 2022-02-06 13:14 UTC (permalink / raw) To: Rob Pike; +Cc: TUHS main list Since you made this personal and called me out specifically, I will respond: "In what way is automatic memory management harder, more unsafe, and less robust than hand-written memory management using malloc and free?" Because there's no difference in the two. Someone had to write the "automatic memory management", right? "You seem to think that garbage collection only exists in languages that have a smell you don't like." I said nothing of the kind. You've got me mixed up with someone else. Just because I respond to a thread doesn't mean I agree with everything said in the thread. "Using malloc and free might be a badge of honor to some, but it's also a failure of automation." Again, the automation code has to written by *someone*. It doesn't just appear by itself. "This discussion should probably go to COFF, or perhaps I should just leave the list. I am starting to feel uncomfortable here. Too much swagger." I read through the thread. Just because people don't agree with each other doesn't equate to "swagger". I've seen little evidence of anything other than reasoned analysis and rational, respectful discussion. Was there any sort of personal attacks that I missed? The fact of the matter is, code written with malloc/free, if written carefully, will run for *years*. There are Linux boxes that have been running for literally years without being rebooted, and mainframes and miniframes that get booted only when a piece of hardware fails. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 13:14 ` Ed Carp @ 2022-02-06 14:13 ` Dan Cross 2022-02-06 14:15 ` Larry McVoy 1 sibling, 0 replies; 64+ messages in thread From: Dan Cross @ 2022-02-06 14:13 UTC (permalink / raw) To: Ed Carp; +Cc: COFF [-- Attachment #1: Type: text/plain, Size: 5205 bytes --] Oh dear. This is getting a little heated. TUHS to Bcc:, replies to COFF. On Sun, Feb 6, 2022 at 8:15 AM Ed Carp <erc@pobox.com> wrote: > Since you made this personal and called me out specifically, I will > respond: > > "In what way is automatic memory management harder, more unsafe, and > less robust than hand-written memory management using malloc and > free?" > > Because there's no difference in the two. Someone had to write the > "automatic memory management", right? > I cannot agree with this, there is a big difference. With GC, you are funneling all of the fiddly bits of dealing with memory management through a runtime that is written by a very small pool of people who are intimately familiar with the language, the runtime, the compilation environment, and so on. That group of subject matter experts produce a system that is tested by every application (much like the _implementation_ of malloc/free itself, which is not usually reproduced by every programmer who _uses_ malloc/free). It's like in "pure" functional languages such as Haskell, where everything is immutable: that doesn't mean that registers don't change values, or that memory cells don't get updated, or that IO doesn't happen, or the clock doesn't tick. Rather, it means that the programmer makes a tradeoff where they cede control over those things to the compiler and a runtime written by a constrained set of contributors, in exchange for guarantees those things make about the behavior of the program. With manual malloc/free, one smears responsibility for getting it right across every program that does dynamic memory management. Some get it right; many do not. In many ways, the difference between automatic and manual memory management is like the difference between programming in assembler and programming in a high-level language. People have written reliable, robust assembler for decades (look at the airline industry), but few people would choose to do so today; why? Because it's tedious and life is too short as it is. Further, the probability of error is greater than in a high-level language; why tempt fate? [snip] > "This discussion should probably go to COFF, or perhaps I should just > leave the list. I am starting to feel uncomfortable here. Too much > swagger." > > I read through the thread. Just because people don't agree with each > other doesn't equate to "swagger". I've seen little evidence of > anything other than reasoned analysis and rational, respectful > discussion. Was there any sort of personal attacks that I missed? > It is very difficult, in a forum like this, to divine intent. I know for a fact that I've written things to this list that were interpreted very differently than I meant them. That said, there has definitely been an air that those who do not master manual memory management are just being lazy and that "new" programmers are unskilled. Asserting that this language or that is "ours" due to its authors while that is "theirs" or belongs solely to some corporate sponsor is a bit much. The reality is that languages and operating systems and hardware evolve over time, and a lot of the practices we took for granted 10 years ago deserve reexamination in the light of new context. There's nothing _wrong_ with that, even if it may be uncomfortable (I know it is for me). The fact of the matter is, code written with malloc/free, if written > carefully, will run for *years*. There are Linux boxes that have been > running for literally years without being rebooted, and mainframes and > miniframes that get booted only when a piece of hardware fails. > That there exist C programs that have run for many years without faults is indisputable. Empirically, people _can_ write reliable C programs, but it is often harder than it seems to do so, particularly since the language standard gives so much latitude for implementations to change semantics in surprising ways over time. Just in the past couple of weeks a flaw was revealed in some Linux daemon that allowed privilege escalation to root...due to improper memory management. That flaw had been in production for _12 years_. Sadly, this is not an isolated incident. That said, does manual memory management have a place in modern computing? Of course it does, as you rightly point out. So does assembly language. Rust came up in the context of this thread as a GC'd language, and it may be worth mentioning that Rust uses manual memory management; the language just introduces some facilities that make this safer. For instance, the concept of ownership is elevated to first-class status in Rust, and there are rules about taking references to things; when something's owner goes out of scope, it is "dropped", but the compiler statically enforces that there are no outstanding references to that thing. Regardless, when dealing with some resource it is often the programmer's responsibility to make sure that a suitable drop implementation exists. FWIW, I used to sit down the hall from a large subgroup of the Go developers; we usually ate lunch together. I know that many of them shared my opinion that Rust and Go are very complimentary. No one tool is right for all tasks. - Dan C. [-- Attachment #2: Type: text/html, Size: 6350 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 13:14 ` Ed Carp 2022-02-06 14:13 ` Dan Cross @ 2022-02-06 14:15 ` Larry McVoy 2022-02-06 16:31 ` Warner Losh ` (2 more replies) 1 sibling, 3 replies; 64+ messages in thread From: Larry McVoy @ 2022-02-06 14:15 UTC (permalink / raw) To: Ed Carp; +Cc: TUHS main list Let's keep it civil and non-personal, I don't think Rob was pointing at anyone, I think he was pointing at some not so forward thinking. I have to side with Rob on this one, even though I'm squarely in the I like C best camp. While I _can_ do all the malloc/free stuff myself (and have decades of working code to prove it), it's become harder and harder to find other people who can. Younger programmers just sort of stare at you with a "I have to do what?" look. They think you are a dinosaur for working like that when other reasonable languages do that work for you. When I did little-lang.org, granted, not widely used but we used it a lot, it did all the memory management behind the scenes, used reference counting so you never had the big GC sweep that some languages used, worked great. And super pleasant to not have to do all that memory management. Having the languages do more for you, and put up guard rails so people can't make stupid mistakes, seems to be the way of the future. It's not my future, I love C, it does what I want and I can live with what it needs me to do to have working code. But I'm a dinosaur and I know it. I'm not trying to push C where people don't want it. On Sun, Feb 06, 2022 at 06:14:36AM -0700, Ed Carp wrote: > Since you made this personal and called me out specifically, I will respond: > > "In what way is automatic memory management harder, more unsafe, and > less robust than hand-written memory management using malloc and > free?" > > Because there's no difference in the two. Someone had to write the > "automatic memory management", right? > > "You seem to think that garbage collection only exists in languages > that have a smell you don't like." > > I said nothing of the kind. You've got me mixed up with someone else. > Just because I respond to a thread doesn't mean I agree with > everything said in the thread. > > "Using malloc and free might be a badge of honor to some, but it's > also a failure of automation." > > Again, the automation code has to written by *someone*. It doesn't > just appear by itself. > > "This discussion should probably go to COFF, or perhaps I should just > leave the list. I am starting to feel uncomfortable here. Too much > swagger." > > I read through the thread. Just because people don't agree with each > other doesn't equate to "swagger". I've seen little evidence of > anything other than reasoned analysis and rational, respectful > discussion. Was there any sort of personal attacks that I missed? > > The fact of the matter is, code written with malloc/free, if written > carefully, will run for *years*. There are Linux boxes that have been > running for literally years without being rebooted, and mainframes and > miniframes that get booted only when a piece of hardware fails. -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 14:15 ` Larry McVoy @ 2022-02-06 16:31 ` Warner Losh 2022-02-06 18:36 ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart 2022-02-06 19:27 ` Jon Steinhart 2 siblings, 0 replies; 64+ messages in thread From: Warner Losh @ 2022-02-06 16:31 UTC (permalink / raw) To: Larry McVoy; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1254 bytes --] On Sun, Feb 6, 2022 at 7:17 AM Larry McVoy <lm@mcvoy.com> wrote: > While I _can_ do all the malloc/free stuff myself (and have decades of > working code to prove it), it's become harder and harder to find other > people who can. > While it's not too bad to do malloc/free in userspace in single threaded programs, it gets harder for multi-threaded where you have multiple objects holding references to an object you might want to free. And to get things to run fast, you have to use increasingly sophisticated "locking" primitives to get performance: RCU, lifetime flexibility, etc. Those methods are hard to get right, which is why most of them include extensive run-time proofing / asserts to try to catch leaks and other problems. For kernel work, that adds a whole other level of complexity as well. I'd love to have all this stuff automatically optimized and correct. However, the state of the art for alternatives to C aren't there today for the kernel context. While rust in Linux is a thing, it's not in the fast path yet. Time will tell if it can grow up to do that or not, and I'll stop there since it's a rapidly developing area and I'm sure anything I say about the state of the art when I last looked will be wrong in some way. Warner [-- Attachment #2: Type: text/html, Size: 1818 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ] 2022-02-06 14:15 ` Larry McVoy 2022-02-06 16:31 ` Warner Losh @ 2022-02-06 18:36 ` Jon Steinhart 2022-02-06 19:27 ` Jon Steinhart 2 siblings, 0 replies; 64+ messages in thread From: Jon Steinhart @ 2022-02-06 18:36 UTC (permalink / raw) To: TUHS main list Larry McVoy writes: > Let's keep it civil and non-personal, I don't think Rob was pointing > at anyone, I think he was pointing at some not so forward thinking. > > I have to side with Rob on this one, even though I'm squarely in the > I like C best camp. > > While I _can_ do all the malloc/free stuff myself (and have decades of > working code to prove it), it's become harder and harder to find other > people who can. Younger programmers just sort of stare at you with a > "I have to do what?" look. They think you are a dinosaur for working > like that when other reasonable languages do that work for you. > > When I did little-lang.org, granted, not widely used but we used it a > lot, it did all the memory management behind the scenes, used reference > counting so you never had the big GC sweep that some languages used, > worked great. And super pleasant to not have to do all that memory > management. > > Having the languages do more for you, and put up guard rails so people > can't make stupid mistakes, seems to be the way of the future. It's > not my future, I love C, it does what I want and I can live with what > it needs me to do to have working code. But I'm a dinosaur and I > know it. I'm not trying to push C where people don't want it. I look at this from a different perspective. The world needs a lot of programmers these days. It takes a lot of work to have internet-connected refrigerators push advertising, to make washers and dryers sing about their work, to have Bixby piss off Samsung phone users, to ensure that IoT devices are insecure, and of course to leak personally identifying information on government web sites. This is critical work and there just aren't enough "good" programmers to go around. I view people that programming for Android, making web pages unusable, and so on, as if they're using domain-specific languages. The difference is that while many of us grew up loving domain-specific "little languages" these languages are huge. While I'm not an expert here, I'm sure that being an expert in the Android, IOS, Java, or WWW ecosystems involves more "learning" than many of us had to do when we learned our craft. A big problem with our profession is that we have no agreed on terminology to distinguish among practitioners. A story told to me by a co-worker in the '80s illustrates this well. Ken had gone home for Christmas with his family. One of his uncles took him aside and asked something like "Hey, you're a computer guy. Can you help me with this .COM and .BAT stuff?" Ken replied "Don't have a clue what you're talking about." When Ken related this story to me, he said "The funny thing about it was that we both walked away thinking that the other person didn't know anything about computers." I think some of what we're debating here is whether or not "programmers" need to understand fundamentals. Many of us think that they do, but we're not the ones working on a subscription model for starting your car. I replaced my deck last summer. Had to do a lot of contractor interviewing. I didn't choose one who said "I can do it" and showed me photos of work he had done. I chose one who said "I can do it" and looked around and said "You know, won't be able to tell until I get the old one removed but I think that there some things that need fixing underneath." Another example, because I'm also a hardware engineer. Many digital circuit designers think that digital is an isolated domain. There was a time a few decades ago when an analog engineer couldn't get a job. But then there was an awakening when folks realized that everything was analog at its core and all of a sudden "full stack hardware engineers" were writing their own tickets. Sure, many digital designers said "Why do I need to know this stuff? Nobody uses Rubylith anymore and the DRC (design rule checker) software takes care of stuff for me. Analog designers bail those people out when things don't work. To me, a big problem with what I'll call domain-specific programmers is that they get involved in standards and specifications and aren't trained in how to abstract. So standards are produced that result in enlarged, more complex domains. One of the best examples is CSS, a standard that is too complex to be documented. I have no clue as to how many CSS properties exist anymore. It's not cleanly designed, and of course with the addition of each new property the interaction matrix grows exponentially. And the increasing number of mode-switching properties is growing the number of interaction matrices. There are literally thousands of things a CSS "programmer" needs to know, yet people still ask question like "How do I vertically center something" because it's still hard to do. Even the worst programming language is orders of magnitude simpler than CSS. But hey, CSS isn't "programming" so of course it's better. Bottom line to me is that people with serious expertise are always going to be needed. Someone has to design the hardware, someone has to make the tools used to design the hardware, someone has to implement programming languages and operating systems and all that. But that's a different domain than what the majority of the world wants today. Jon ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ] 2022-02-06 14:15 ` Larry McVoy 2022-02-06 16:31 ` Warner Losh 2022-02-06 18:36 ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart @ 2022-02-06 19:27 ` Jon Steinhart 2022-02-06 19:33 ` Warner Losh 2 siblings, 1 reply; 64+ messages in thread From: Jon Steinhart @ 2022-02-06 19:27 UTC (permalink / raw) To: TUHS main list Oh, one more thing. It was kind of implied in my earlier post, but a big concern is when domain-specific programmers cross over into a different domain but think that the rules from the domain with which they're familiar apply. For example, I wouldn't want someone from a GC domain messing with an OS kernel without learning about memory and memory management. Stuff has to interoperate in a way that an insecure talking toaster doesn't. I probably have the quote completely wrong, but Dan Healy, sound man for The Grateful Dead an inventor of much of modern concert hall sound technology said something like "Bozos are fine people and fun to be around but that doesn't mean that I would let one near my soundboard with a pair of diagonal pliers." Jon ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ] 2022-02-06 19:27 ` Jon Steinhart @ 2022-02-06 19:33 ` Warner Losh 2022-02-06 19:37 ` Jon Steinhart 0 siblings, 1 reply; 64+ messages in thread From: Warner Losh @ 2022-02-06 19:33 UTC (permalink / raw) To: Jon Steinhart; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 1003 bytes --] On Sun, Feb 6, 2022 at 12:27 PM Jon Steinhart <jon@fourwinds.com> wrote: > I probably have the quote completely wrong, > but Dan Healy, sound man for The Grateful Dead an inventor of much of > modern concert hall sound technology said something like "Bozos are > fine people and fun to be around but that doesn't mean that I would > let one near my soundboard with a pair of diagonal pliers." > I personally like having the choices. I don't want to be bothered with malloc/free when I'm hacking together an awk or python script. On the other hand, when it has to run fast or do lots of TPS inside a kernel, I really don't want somebody else deciding when a good time to take a 'hiccup' in performance is... It all depends on what I'm doing since using techniques from the latter to optimize the former is a waste of time. The whole reason I do a GC'd language is to write what I'm writing faster with less hassle... Some days I'm Dan Healy, some days I'm waving diagonal pliers around... :) Warner [-- Attachment #2: Type: text/html, Size: 1515 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... [ really GC vs malloc/free languages ] 2022-02-06 19:33 ` Warner Losh @ 2022-02-06 19:37 ` Jon Steinhart 2022-02-06 20:21 ` [TUHS] COFF is over there Ralph Corderoy 0 siblings, 1 reply; 64+ messages in thread From: Jon Steinhart @ 2022-02-06 19:37 UTC (permalink / raw) To: TUHS main list Warner Losh writes: > I personally like having the choices. I don't want to be bothered with > malloc/free when I'm hacking together an awk or python script. On > the other hand, when it has to run fast or do lots of TPS inside a kernel, > I really don't want somebody else deciding when a good time to take > a 'hiccup' in performance is... It all depends on what I'm doing since > using techniques from the latter to optimize the former is a waste of > time. The whole reason I do a GC'd language is to write what I'm writing > faster with less hassle... > > Some days I'm Dan Healy, some days I'm waving diagonal pliers around... :) Completely agree with you. I do the same. But I actually know how to use those diagonal pliers; I don't want someone who doesn't know what they're doing to start snipping things. Jon ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] COFF is over there. 2022-02-06 19:37 ` Jon Steinhart @ 2022-02-06 20:21 ` Ralph Corderoy 0 siblings, 0 replies; 64+ messages in thread From: Ralph Corderoy @ 2022-02-06 20:21 UTC (permalink / raw) To: TUHS main list Hi Jon, You've brought up an interesting point to start this subthread, but it still isn't TUHS-worthy IME. COFF would welcome it. :-) -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 1:10 ` Will Senn 2022-02-06 4:52 ` Rob Pike @ 2022-02-06 16:16 ` Brad Spencer 2022-02-08 5:22 ` Ed Carp 1 sibling, 1 reply; 64+ messages in thread From: Brad Spencer @ 2022-02-06 16:16 UTC (permalink / raw) To: Will Senn; +Cc: tuhs Will Senn <will.senn@gmail.com> writes: [snip] >> I've done this and I've employed people who have done this. We're >> a dieing breed, the focus seems to be on programming languages and >> tools for idiots. People don't want to learn the discipline it takes >> to work with malloc()/free(). It's sad. > > I completely agree. This is ridiculous. Do modern programmer's seriously > think that the old code wasn't complex or robust? Sheesh, there's code > out there that has run through more millions of transactions an hour for > more years than most of these folks have been alive. There's also code > that's been running without any updates, for decades. Most code written > by the newbreed won't run for a month without surfacing dozens of bugs. > Margaret Hamilton would prolly have some choice words for these folks. This would appear to be a Not Unix conversation... but... So... the idea that code would run that long was not at all valued at my last job. The management found it simpler and better (for some definition of better) to just reinvent everything every 3 to 6 years. In the mean time, the languages used would change. The idea that one would "have to waste time" figuring out how to use malloc() and free() properly was not looked upon well when the development time would be better spend solving the needed higher level problems. In other words there literally was no interest in creating code that was going to be maintained for more than about 6 years and in a lot of cases would not be maintained more than 3 or even 1 year. To bring this back to Unix somewhat... When I started there, everything was a Solaris based private cloud (SmartOS by Joyent) running Java apps. In the 5 years I was there, the move was from Java to Go, due to the licensing changes that Oracle made to Java and then a move to containers. SmartOS has a container technology that is sort of like Docker, but since the majority of the containers in the world that people know about are fully Docker in some form with Linux it wasn't as compatible as required so SmartOS was dumped and everything was redone in Azure public cloud with Linux and as much of the native Azure stuff as they could stand to use. Make everything "green field" all of the time, or something.... I didn't really agree with much of this, but I became pretty mercenary as I got old and the place paid well. -- Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] more about Brian... 2022-02-06 16:16 ` [TUHS] more about Brian Brad Spencer @ 2022-02-08 5:22 ` Ed Carp 0 siblings, 0 replies; 64+ messages in thread From: Ed Carp @ 2022-02-08 5:22 UTC (permalink / raw) To: Brad Spencer; +Cc: tuhs And that reminds me of the old "Three Envelopes" joke: A new CEO takes his seat at the helm of a large corporation He finds three envelopes on his desk, numbered 1 to 3, and a note. "Dear successor, On this desk you find 3 envelopes that will help you in times of a crisis. Open them only in the order they are numbered, and only when you face a crisis that you cannot manage. Best of luck". He stores them in his safe and goes to work. But the economy isn't picking up, the corporation isn't doing too well and the board wants an explanation. He decides it's time for the first envelope. He rips it open and reads: "Blame your predecessor". And he does. He steps up at the press conference and blames everything on the shortcomings and nearsightedness of his predecessor and how he just needs a bit more time to turn things around. Everyone is pleased and he remains CEO. But after a while, the displeasure isn't waning and the corporation isn't doing any better. Another press conference is held and he rips open the next envelope: "Call for reorganizations". And he does. He presents a great reorganization project with no stone remaining unturned, this will surely improve productivity and move the corporation into the future. Everyone's so busy reorganizing that nobody can even notice how the corporation is running worse and worse, until there's really no way to cover it up anymore. He reaches for the third and last envelope, hoping for the great reveal that will save him once and for all. He rips it open and reads: "Prepare 3 envelopes and a note". On 2/6/22, Brad Spencer <brad@anduin.eldar.org> wrote: > Will Senn <will.senn@gmail.com> writes: > > [snip] > >>> I've done this and I've employed people who have done this. We're >>> a dieing breed, the focus seems to be on programming languages and >>> tools for idiots. People don't want to learn the discipline it takes >>> to work with malloc()/free(). It's sad. >> >> I completely agree. This is ridiculous. Do modern programmer's seriously >> think that the old code wasn't complex or robust? Sheesh, there's code >> out there that has run through more millions of transactions an hour for >> more years than most of these folks have been alive. There's also code >> that's been running without any updates, for decades. Most code written >> by the newbreed won't run for a month without surfacing dozens of bugs. >> Margaret Hamilton would prolly have some choice words for these folks. > > This would appear to be a Not Unix conversation... but... > > So... the idea that code would run that long was not at all valued at > my last job. The management found it simpler and better (for some > definition of better) to just reinvent everything every 3 to 6 years. > In the mean time, the languages used would change. The idea that one > would "have to waste time" figuring out how to use malloc() and free() > properly was not looked upon well when the development time would be > better spend solving the needed higher level problems. In other words > there literally was no interest in creating code that was going to be > maintained for more than about 6 years and in a lot of cases would not > be maintained more than 3 or even 1 year. > > To bring this back to Unix somewhat... When I started there, everything > was a Solaris based private cloud (SmartOS by Joyent) running Java apps. > In the 5 years I was there, the move was from Java to Go, due to the > licensing changes that Oracle made to Java and then a move to > containers. SmartOS has a container technology that is sort of like > Docker, but since the majority of the containers in the world that > people know about are fully Docker in some form with Linux it wasn't as > compatible as required so SmartOS was dumped and everything was redone > in Azure public cloud with Linux and as much of the native Azure stuff > as they could stand to use. Make everything "green field" all of the > time, or something.... > > I didn't really agree with much of this, but I became pretty mercenary > as I got old and the place paid well. > > > > > > > > -- > Brad Spencer - brad@anduin.eldar.org - KC8VKS - http://anduin.eldar.org > ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-02 7:47 ` arnold 2022-02-03 5:47 ` [TUHS] more about Brian Rich Morin @ 2022-02-03 18:57 ` silas poulson 2022-02-04 8:26 ` arnold 2022-02-10 15:18 ` Ralph Corderoy 2 siblings, 1 reply; 64+ messages in thread From: silas poulson @ 2022-02-03 18:57 UTC (permalink / raw) To: arnold; +Cc: Paul Ruizendaal via TUHS > FWIW, Brian has told me more than once that he wishes they'd done > “Software Tools In C" instead of in Pascal, and that the Pascal book > was a failure to read the market correctly. Ah, but then we wouldn’t have had his wonderful *Why Pascal* paper! Has Brian ever said what would’ve been different if a C version had been written? Silas ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-03 18:57 ` [TUHS] ratfor vibe silas poulson @ 2022-02-04 8:26 ` arnold 2022-02-04 19:41 ` John Cowan 0 siblings, 1 reply; 64+ messages in thread From: arnold @ 2022-02-04 8:26 UTC (permalink / raw) To: silas8642, arnold; +Cc: tuhs silas poulson <silas8642@hotmail.co.uk> wrote: > > FWIW, Brian has told me more than once that he wishes they'd done > > “Software Tools In C" instead of in Pascal, and that the Pascal book > > was a failure to read the market correctly. > > Ah, but then we wouldn’t have had his wonderful *Why Pascal* paper! > > Has Brian ever said what would’ve been different if a C version had > been written? No, he has not. I suspect it would have looked like the ratfor code but with real data structures and recursion, and without the need to build the standard I/O library (getc, putc, etc.). Arnold ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-04 8:26 ` arnold @ 2022-02-04 19:41 ` John Cowan 0 siblings, 0 replies; 64+ messages in thread From: John Cowan @ 2022-02-04 19:41 UTC (permalink / raw) To: Aharon Robbins; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 537 bytes --] On Fri, Feb 4, 2022 at 3:26 AM <arnold@skeeve.com> wrote: No, he has not. I suspect it would have looked like the ratfor code > but with real data structures and recursion, and without the need to > build the standard I/O library (getc, putc, etc.). > See Jez Higgins's STinC++ (Software Tools in C++) project at < https://www.jezuk.co.uk/tags/software-tools-in-c++.html>. He's working from ST in Pascal, but this is a rewrite from scratch, not a translation. So far he's done Chapters 1, 2, and 5, implementing each tool as he goes. [-- Attachment #2: Type: text/html, Size: 1188 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-02 7:47 ` arnold 2022-02-03 5:47 ` [TUHS] more about Brian Rich Morin 2022-02-03 18:57 ` [TUHS] ratfor vibe silas poulson @ 2022-02-10 15:18 ` Ralph Corderoy 2 siblings, 0 replies; 64+ messages in thread From: Ralph Corderoy @ 2022-02-10 15:18 UTC (permalink / raw) To: tuhs Hi Arnold, > > I agree the original Software Tools is a must read, but having done > > so, why would I suffer working through the hurdles put in place by > > Pascal compared to Ratfor? I never bothered so your recommendation > > makes me wonder what I missed. I did read Kernighan's ‘not my > > favourite’ and took from that I wouldn't enjoy the Pascal book given > > I'd read the original. > > As others mentioned, recursion and real data structures make code > easier to read. They also refined the text some. > > But in general, I think the principle of "ANYTHING written by Brian > Kernighan is worth reading, at least once" applies, even in this case. Well, that's true. I've read every other technical book of his apart from the ‘AMPL: A Modeling Language for Mathematical Programming’. https://amzn.to/3BdQ0dV It was the quality of his writing which meant I could learn C and Unix at home well enough to get a C programming job on Sun OS on leaving school, which is sixteen over here. Within a year or so, work sent me to Sydney as part of shipping the flight simulator to Qantas. Good books have immeasurable worth across all their readers. Thanks, it's ordered, arriving Valentine's Day, which will impress SWMBO. :-) -- Cheers, Ralph. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-01-31 20:46 [TUHS] ratfor vibe Will Senn 2022-02-01 15:37 ` arnold @ 2022-02-03 4:00 ` Will Senn 2022-02-03 4:31 ` Al Kossow 2022-02-03 20:00 ` Adam Thornton 1 sibling, 2 replies; 64+ messages in thread From: Will Senn @ 2022-02-03 4:00 UTC (permalink / raw) To: TUHS main list [-- Attachment #1: Type: text/plain, Size: 4786 bytes --] On 1/31/22 2:46 PM, Will Senn wrote: > All, > > I have been doing some language exploration in v7/4.3bsd and came > across Software Tools (not the pascal version). It's written using > ratfor, which I had seen in the v7 UPM. I fired up v7 and tried my > hand at the first example: I thought I'd close the loop on the language side of this thread. I am happy to report that ratfor (and fortran) is alive and well. It works on my mac! The Software Tools book is awesome, if challenging. The first chapter is particularly challenging as it takes a bit to figure out where the authors are coming from and what they include, exclude, and highlight... and why. The key to understanding the book, as a modern reader, is to understand that the authors assume their readers are fortran (or PL/I) programmers. Because of this, they don't explain anything that would be obvious to said programmers (read, write, LUNs, Hollerith cards, format, etc). In addition, they will push down details of implementation until they practically disappear (think singularity... annoyingly consistent in this regard). When they say something like "EOF is a symbolic constant... We won't tell you what its value is, since the particular value doesn't matter", they really mean it. Unfortunately, in order to actually implement stuff, you gotta know what every symbolic constant and macro replacement is :). For example, even in the tiny copy program example, from the introductory chapter, once you include the primitive getc and putc subroutines, there are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF, SPACE and character, which is really an integer and gets replaced with integer by some mythical preprocessor (chapter 8). Anyhow, in the modern world, MAXLINE and MAXCARD don't really have meaning, but they can magically be treated as lines of a file, the rest do have meaning, but they don't evaluate to the same things in Fortran-land as in modern-land. STDIN is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that lets them be treated as terminal input and output), EOF is -1, SPACE is 32, NEWLINE is 10. Anyhow, long story just a bit shorter, replace those constants, swap character for integer, and combine getc, putc, and copy and yahoo, a working copy program that works in v7, 4.xBSD, and Mac OS X Mojave (and BSD, etc), without any further modifications... at all. Included for the curioius (copynew.r): # on v7 # $ ratfor -C copynew.r > copynew.f # $ f77 -o copynew copynew.f # on mac # $ ratfor77 -C copynew.r > copynew.f # $ gfortran -o copynew copynew.f # $ ./copynew # This is a test. # This is a test. # CTRL-d # $ # getc (simple version) - get characters from standard input integer function getc(c) integer buf(81), c integer i, lastc data lastc /81/,buf(81) /10/ lastc = lastc + 1 if(lastc > 81) { read(5, 100, end=10) (buf(i), i = 1, 80) 100 format(80 a 1) lastc = 1 } c = buf(lastc) getc = c return 10 c = -1 getc = -1 return end # putc (simple version) - put characters on the standard output subroutine putc(c) integer buf(80), c integer i, lastc data lastc /0/ if (lastc > 80 | c == 10) { for (i = lastc + 1; i <= 80; i = i + 1) buf(i) = 32 write(6, 100) (buf(i), i = 1, 80) 100 format(80 a 1) lastc = 0 } if (c != 10) { lastc = lastc + 1 buf(lastc) = c } return end # copy - copy input characters to output integer getc integer c while(getc(c) != -1) call putc(c) stop end Of course, it's criminal to have all those hardcoded magic numbers, wouldn't it be swell if there were some sort of macro facility?... oh, wait, that's what Chapter 8's all about... I can't wait. Will [-- Attachment #2: Type: text/html, Size: 6184 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-03 4:00 ` Will Senn @ 2022-02-03 4:31 ` Al Kossow 2022-02-03 5:16 ` Warner Losh 2022-02-03 20:00 ` Adam Thornton 1 sibling, 1 reply; 64+ messages in thread From: Al Kossow @ 2022-02-03 4:31 UTC (permalink / raw) To: tuhs On 2/2/22 8:00 PM, Will Senn wrote: > Of course, it's criminal to have all those hardcoded magic numbers Graybeards chucking at the follies of youth. ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-03 4:31 ` Al Kossow @ 2022-02-03 5:16 ` Warner Losh 0 siblings, 0 replies; 64+ messages in thread From: Warner Losh @ 2022-02-03 5:16 UTC (permalink / raw) To: Al Kossow; +Cc: TUHS main list [-- Attachment #1: Type: text/plain, Size: 322 bytes --] On Wed, Feb 2, 2022, 9:37 PM Al Kossow <aek@bitsavers.org> wrote: > On 2/2/22 8:00 PM, Will Senn wrote: > > > Of course, it's criminal to have all those hardcoded magic numbers > > Graybeards chucking at the follies of youth. > Yea, this code is quite well written relative to most of the code of that era... Warner > [-- Attachment #2: Type: text/html, Size: 877 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-03 4:00 ` Will Senn 2022-02-03 4:31 ` Al Kossow @ 2022-02-03 20:00 ` Adam Thornton 2022-02-04 6:06 ` Ori Idan 1 sibling, 1 reply; 64+ messages in thread From: Adam Thornton @ 2022-02-03 20:00 UTC (permalink / raw) To: Will Senn, The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1028 bytes --] On Wed, Feb 2, 2022 at 9:01 PM Will Senn <will.senn@gmail.com> wrote: > > For example, even in the tiny copy program example, from the introductory > chapter, once you include the primitive getc and putc subroutines, there > are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF, > SPACE and character, which is really an integer and gets replaced with > integer by some mythical preprocessor (chapter 8). Anyhow, in the modern > world, MAXLINE and MAXCARD don't really have meaning, but they can > magically be treated as lines of a file, the rest do have meaning, but they > don't evaluate to the same things in Fortran-land as in modern-land. STDIN > is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that > lets them be treated as terminal input and output), EOF is -1, SPACE is > 32, NEWLINE is 10. > > Pretty sure that EOF is _still_ -1. SPACE and NEWLINE also look pretty > familiar and their values haven't changed, although we might spell them a > little differently these days. > [-- Attachment #2: Type: text/html, Size: 1560 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-03 20:00 ` Adam Thornton @ 2022-02-04 6:06 ` Ori Idan 2022-02-04 17:35 ` Adam Thornton 0 siblings, 1 reply; 64+ messages in thread From: Ori Idan @ 2022-02-04 6:06 UTC (permalink / raw) To: Adam Thornton; +Cc: The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1362 bytes --] SPACE is 32 and NEWLINE is 10 is that the reason that space in ASCII is 32 As for EOF it is 0xFF which is not always -1, depending if your char is signed or unsigned. -- Ori Idan CEO Helicon Books http://www.heliconbooks.com On Thu, Feb 3, 2022 at 10:01 PM Adam Thornton <athornton@gmail.com> wrote: > > > On Wed, Feb 2, 2022 at 9:01 PM Will Senn <will.senn@gmail.com> wrote: > >> >> For example, even in the tiny copy program example, from the introductory >> chapter, once you include the primitive getc and putc subroutines, there >> are 7 symbolic constants: MAXLINE, MAXCARD, NEWLINE, STDIN, STDOUT, EOF, >> SPACE and character, which is really an integer and gets replaced with >> integer by some mythical preprocessor (chapter 8). Anyhow, in the modern >> world, MAXLINE and MAXCARD don't really have meaning, but they can >> magically be treated as lines of a file, the rest do have meaning, but they >> don't evaluate to the same things in Fortran-land as in modern-land. STDIN >> is 5 and STDOUT is 6 (card reader and punch LUNs, again some magic that >> lets them be treated as terminal input and output), EOF is -1, SPACE is >> 32, NEWLINE is 10. >> >> Pretty sure that EOF is _still_ -1. SPACE and NEWLINE also look pretty >> familiar and their values haven't changed, although we might spell them a >> little differently these days. >> > [-- Attachment #2: Type: text/html, Size: 2442 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-04 6:06 ` Ori Idan @ 2022-02-04 17:35 ` Adam Thornton 2022-02-04 17:44 ` Will Senn 0 siblings, 1 reply; 64+ messages in thread From: Adam Thornton @ 2022-02-04 17:35 UTC (permalink / raw) To: Ori Idan, The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 831 bytes --] On Thu, Feb 3, 2022 at 11:07 PM Ori Idan <ori@heliconbooks.com> wrote: > As for EOF it is 0xFF which is not always -1, depending if your char is > signed or unsigned. > > Ha! You fell into my trap! getc() returns an int! (I don't know if EOF is _always_ "all bits set", and even if it is, that's only -1 on a twos-complement machine, if we want to head off into some real pedantry...) The need to use feof() and ferror() at least appear in the BUGS section on my Mac. Linux is not so gracious. The real bug, if you ask me, which no one did, is that getc() and pals return an int rather than a char, which is surprising and certainly has tripped me up several times across the decades (and yes, I understand that since any character value is a legal character to have gotten, you need some other way of signalling an error). [-- Attachment #2: Type: text/html, Size: 1241 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
* Re: [TUHS] ratfor vibe 2022-02-04 17:35 ` Adam Thornton @ 2022-02-04 17:44 ` Will Senn 0 siblings, 0 replies; 64+ messages in thread From: Will Senn @ 2022-02-04 17:44 UTC (permalink / raw) To: Adam Thornton, Ori Idan, The Eunuchs Hysterical Society [-- Attachment #1: Type: text/plain, Size: 1522 bytes --] On 2/4/22 11:35 AM, Adam Thornton wrote: > > > On Thu, Feb 3, 2022 at 11:07 PM Ori Idan <ori@heliconbooks.com> wrote: > > As for EOF it is 0xFF which is not always -1, depending if your > char is signed or unsigned. > > > Ha! You fell into my trap! getc() returns an int! (I don't know if > EOF is _always_ "all bits set", and even if it is, that's only -1 on a > twos-complement machine, if we want to head off into some real > pedantry...) > > The need to use feof() and ferror() at least appear in the BUGS > section on my Mac. Linux is not so gracious. The real bug, if you > ask me, which no one did, is that getc() and pals return an int rather > than a char, which is surprising and certainly has tripped me up > several times across the decades (and yes, I understand that since any > character value is a legal character to have gotten, you need some > other way of signalling an error). This is prolly why the authors steadfastly refused to commit to a particular value for EOF. Instead, they said in essence, that it was a matter of agreement, convention, if you will, and that whatever value was chosen, it should NEVER be a legal character. I made it -1, for v7, cuz it worked... and I wanted so badly to get a working ratfor program that I sacrificed any semblance of technical rigor to make it copy a character, onscreen, in real time, live. Heck, and it only took me a couple of days to figure out all how to get it working, EOF was easy, STDIN and STDOUT, not so much. [-- Attachment #2: Type: text/html, Size: 2854 bytes --] ^ permalink raw reply [flat|nested] 64+ messages in thread
end of thread, other threads:[~2022-02-10 15:21 UTC | newest] Thread overview: 64+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-31 20:46 [TUHS] ratfor vibe Will Senn 2022-02-01 15:37 ` arnold 2022-02-01 15:52 ` Ralph Corderoy 2022-02-01 16:58 ` Clem Cole 2022-02-01 17:02 ` silas poulson 2022-02-02 7:47 ` arnold 2022-02-03 5:47 ` [TUHS] more about Brian Rich Morin 2022-02-03 7:44 ` markus schnalke 2022-02-03 8:18 ` Rich Morin 2022-02-04 2:23 ` Adam Thornton 2022-02-04 2:34 ` [TUHS] more about Brian... [really Rust] Jon Steinhart 2022-02-04 13:07 ` Thomas Paulsen 2022-02-04 23:18 ` Dan Cross 2022-02-04 3:28 ` [TUHS] more about Brian Dan Stromberg 2022-02-04 5:11 ` Rich Morin 2022-02-04 21:22 ` [TUHS] Go vs. Rust, and etc. (was: more about Brian...) Greg A. Woods 2022-02-04 21:37 ` Richard Salz 2022-02-04 22:32 ` Steffen Nurpmeso 2022-02-04 23:05 ` Thomas Paulsen 2022-02-04 23:15 ` Seth J. Morabito 2022-02-05 1:41 ` Adam Thornton 2022-02-04 7:38 ` [TUHS] more about Brian Andy Kosela 2022-02-04 8:10 ` Steve Nickolas 2022-02-04 8:44 ` markus schnalke 2022-02-04 9:16 ` Steve Nickolas 2022-02-04 18:54 ` John Cowan 2022-02-04 19:45 ` Thomas Paulsen 2022-02-04 20:28 ` Hellwig Geisse 2022-02-04 21:03 ` Jim Capp 2022-02-04 22:30 ` Steffen Nurpmeso 2022-02-04 22:25 ` Steffen Nurpmeso 2022-02-06 0:56 ` Larry McVoy 2022-02-06 1:10 ` Will Senn 2022-02-06 4:52 ` Rob Pike 2022-02-06 4:58 ` Dan Halbert 2022-02-06 5:06 ` Will Senn 2022-02-06 6:19 ` Ed Carp 2022-02-06 6:27 ` Rob Pike 2022-02-06 6:40 ` Stuart Remphrey 2022-02-06 6:44 ` Bakul Shah 2022-02-06 19:08 ` Steffen Nurpmeso 2022-02-06 12:52 ` Ralph Corderoy 2022-02-06 13:14 ` Ed Carp 2022-02-06 14:13 ` Dan Cross 2022-02-06 14:15 ` Larry McVoy 2022-02-06 16:31 ` Warner Losh 2022-02-06 18:36 ` [TUHS] more about Brian... [ really GC vs malloc/free languages ] Jon Steinhart 2022-02-06 19:27 ` Jon Steinhart 2022-02-06 19:33 ` Warner Losh 2022-02-06 19:37 ` Jon Steinhart 2022-02-06 20:21 ` [TUHS] COFF is over there Ralph Corderoy 2022-02-06 16:16 ` [TUHS] more about Brian Brad Spencer 2022-02-08 5:22 ` Ed Carp 2022-02-03 18:57 ` [TUHS] ratfor vibe silas poulson 2022-02-04 8:26 ` arnold 2022-02-04 19:41 ` John Cowan 2022-02-10 15:18 ` Ralph Corderoy 2022-02-03 4:00 ` Will Senn 2022-02-03 4:31 ` Al Kossow 2022-02-03 5:16 ` Warner Losh 2022-02-03 20:00 ` Adam Thornton 2022-02-04 6:06 ` Ori Idan 2022-02-04 17:35 ` Adam Thornton 2022-02-04 17:44 ` Will Senn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).