Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Paul Rubin Newsgroups: comp.lang.forth Subject: Re: Really? Date: Tue, 07 Feb 2017 23:24:42 -0800 Organization: A noiseless patient Spider Lines: 63 Message-ID: <87k291w3et.fsf@nightsong.com> References: <1239a88b-a574-401b-9454-50ac7e000049@googlegroups.com> <5899a408.386236853@news.eternal-september.org> <87shnqw989.fsf@nightsong.com> <2017Feb7.183554@mips.complang.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="5c7ed3cdfa3e6f1866ae0e4a7b66c587"; logging-data="26352"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+04qUScJns9JJjeuieaLft" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Cancel-Lock: sha1:iQVV0TuGBbVgIOJkUTDTekJyKWo= sha1:TdeCuG0mdO/g8qyaRRtviCP/p7o= Xref: csiph.com comp.lang.forth:54708 anton@mips.complang.tuwien.ac.at (Anton Ertl) writes: >>different development style than Forth or C, where you have to be >>careful to not give back hard-earned gains. > If you run into that problem, there probably is something wrong with > your basic architecture or your code, and the "gains" are actually a > burden. What I've seen with large C programs is that bugs are elusive--they lurk around for a long time before even being noticed, they they're hunted for a while before any pattern emerges, and then they're often quite hard to diagnose and fix. So old C programs are valuable because they're "seasoned": much effort has been spent finding and chasing bugs over the years, that has to be re-done if you toss out the code. By comparison, the mantra with fancy typed languages like Ocaml is that once you fix all the compile-time type errors the code tends to work. With latently typed languages like Python, you avoid every sort of compile-time error, and in return you get a lot of early runtime errors that give exact stack traces and are easy to debug. You don't invest nearly the debugging time as you do in C so the program doesn't gain as much value as it ages. I had a significant change in perspective when I got involved in a Python project dealing with a large (terabytes) data corpus. The motto there was basically that data is gold but code is crap. I'd been used to hearing it the other way around. We were constantly writing throwaway programs to munch the data one way or another, but replacing the data (collected over decades) would have been impossible. > Better don't throw good programming effort after bad (that may have > been the problem with Valdocs). I don't know what happened with Valdocs. I wasn't able to find the reference HAA mentioned. > Concerning run-time checks, if you think that helps, put them into your > code. The trouble is that errors happen in exactly the places you don't expect them to, or else they wouldn't be errors ;). Yes some asserts here and there are good, but pervasive checking catches a lot of stuff that could go unnoticed. Think of all the subscript errors in Fortran and C programs over the years. > If you are used to garbage collection, you may find that hard, and > requiring you to think outside the box of your usual practices. > Programming like in a GC language and trying to put in FREEs where > necessary will not lead to good results. For lots of purposes, single-ownership pointers (std::unique_ptr) in C++ can take the place of GC with almost no overhead and not too much programmer effort. But they rely on the C++'s so-called RAII paradigm, where a value's type signature can tell the compiler to call user-supplied code when the value goes out of scope, and also operator overloading to track the movement of values from one place to another. It's much easier than manual alloc/free and I don't think it can be done in Forth. But, the Boehm GC works pretty well in C and sounds ok for Forth (you'd know better than me about that). I think embedded and instrumentation-like programs that are Forth's specialty avoid the whole problem by not having dynamic memory allocation at all. Just some static variables and buffers, maybe a few ALLOTs at initialization time, plus the stacks.