Hi, On Tue, Jun 2, 2020 at 2:08 PM dmccunney <dennis.mccun...@gmail.com> wrote: > > On Mon, Jun 1, 2020 at 5:30 PM Rugxulo <rugx...@gmail.com> wrote: > > > > I don't think this particular BASIC is a compiler, only an > > interpreter. (The very first BASIC was a compiler.) > > Doesn't matter. You can create an entire application in an > interpreted language, and people did. And BASIC being interpreted on > early machines was likely a matter of hardware available. Kemeny and > Kurtz were working on larger multi-user systems. Consider the > Commodore 64, which had MS BASIC v2 embedded. When you booted it, you > were in the interpreter, talking to BASIC. BASIC on that machine was > embedded in a 8KB ROM.
Except for graphics and sound (which are apparently missing here), aka machine specific, I still think AWK is probably "better" than non-structured GW-BASIC. Of course, QBASIC (non-standard, well ... "de facto" standard, circa 1988/1991) fixed and added a lot. So, lots of people did cool things with that. Since it was installed by default in MS-DOS 5 (and others?? OS/2? NT?), it might make more sense to target that than other tools, if you needed a quick script to do something. But since FreeBASIC's "lang qb" is imperfect (not that I really tested QB64 either), maybe relying on "POSIX" AWK is good enough. (N.B. FreeBASIC [since 2004] compiles itself using auxiliary DJGPP tools.) > Awk and REXX are script languages, and were generally interpreted. Not to split hairs, but many of these "interpreters" are byte-code interpreters. > Awk is used in things like pipelines, where you call awk to query and > process a text file and pass the results to something else. REXX was > the next generation of script language on IBM mainframes, intended to > provide more power than CLISTs. REXX was meant to be simple to learn and use, even for non-programmers. It was, roughly speaking, an easier version of PL/I. It was meant as both a scripting language and a macro language. No reserved keywords, no pointer manipulation, automatic garbage collection (no memory leaks), easy to use stems (associative arrays) with various built-in functions (BIFs). Or something like that. > REXX subsequently got brought up under other architectures. (I have a > version that works under Palm OS.) Yes, Howard Fosdick wrote a nice book on it (that I haven't fully read yet), also available as an e-book. Not sure when OS/2 first got REXX (1.3?), but it was very popular there. Even PC-DOS (2000?) dropped QBASIC for REXX. (The ANSI REXX standard was in '96, but most people seemingly prefer non-standard ooREXX for Smalltalk-ish OOP. Regina doesn't support that. So TRL2 is version 4 while ANSI is 5 and OOP is 6. You can check at runtime which standard "version" you're running.) > > (untested by me, but just FYI) > > * http://awka.sourceforge.net/index.html > > Convert awk to C, then compile to an executable. I recall hearing > back when that AT&T was working on an awk compiler. I have no idea if > this bears any relation to that effort. Maybe BWK wrote a C++ transpiler for it?? Dunno. Anyways, this one is apparently based upon MAWK, which is a byte-code interpreter ("faster"). I never used classic Visual BASIC, but something like v4 was bytecode, v5 was 32-bit, v6 was translated to C and compiled behind the scenes. Something like that, I forget the details. That classic version was last updated in '98, and then came the .NET versions. (Even VB.NET is somewhat falling behind these days, allegedly.) Lots of languages compile to C, and FreeBASIC can optionally do so too (since it's not very optimizing). > > I'm actually a bigger fan of Sed, but that's much more limited > > (intentionally?). > > Intentionally. It has a different use case than awk. SED is a stream > editor, explicitly intended to be called in a pipeline to perform > *scripted* edits on what is fed to it. Most small Sed interpreters are based upon your friend ESR's work (e.g. minised). Sed is a very well-designed tool and works great, but still there are several "dark corners" regarding portability. It's almost unavoidable in the "real world", but it still works fairly well. GNU Sed is still built for DJGPP by some volunteers and also works pretty well. I honestly wouldn't want to prefer QBASIC to that, but in DOS circles, if Edlin didn't cut it, QBASIC probably made more sense (rather than rolling a more limited homegrown tool in C or assembly, although even that isn't a horrible idea sometimes). > One bit often missed by DOS folks back in the day was that *EDLIN* > could be used that way. Advanced batch programmers in environments > like corporate installations where they weren't allowed to install > third party code used EDLIN where they might otherwise have installed > SED. Yes, and while I'm somewhat sympathetic there, I still never used Edlin much. (DR-DOS 7.03 didn't have Edlin nor QBASIC.) My old Vista 32-bit laptop still had DOS versions of Debug and Edlin, though. > > In recent years, BWK wrote a book on Go. That language has come a long > > way and done a lot. A lot of people from Plan 9 still work on that. > > Oh, one guy did write a compatible implementation of AWK in Go! > > The main honcho behind Go is Rob Pike, with Ken Thompson and Robert > Griesemer contributing. (Griesmer was a main developer for the V8 > JavaScipt engine.) Pike and Thompson were colleagues of Kernighan > back the AT&T Bell Labs in Murray HILL NJ when Thompson and Kernighan > were designing Unix and Dennis Ritchie was developing the C language. > Go is specifically intended for concurrent programming, and addresses > weaknesses in C/C++ (primarily in memory management) that bite when > you are trying to create concurrent code. Go's intent is to handle > the memory management for the developer, so they can just develop code > and not have to worry about it. I'm on a Chromebook right now. I think Chrome, like FireFox, is written in modern C++ (as are most C++ compilers like Clang and GCC). I'm not saying Go is redundant, it's not. It was meant to be fast (modules?) and was certainly partially inspired by Oberon. But Go debuted in 2009, I think, even before C++11 (biggest), and we've come a long way since then. The old joke "I don't know what the future will look like, but it will be called Fortran!" is probably more applicable to C++ nowadays. But still, Go is quite popular and has lots of users. As cliche as it sounds, it's good to have competition. > Open source advocate Eric S. Raymond has largely switched to Go these > days. A paying project he's technical lead on is updating NTP. That > was a morass of security holes and being used in DDOS attacks. The > first challenge was scraping away decades of accumulated cruft in the > form of special case code for various old architectures and > environments. The last I knew, his current version of the core NTP > code is about 70% smaller than the C code it replaced, and is far more > secure. Many recent security bugs filed against NTP don't exist on > his code because his code removes the attack surfaces they target. Go > turned out to be just the thing to use for the project. Walter Bright once said that arrays in C were the biggest flaw because they decayed into pointers. Also, manual memory management is both hated and loved for various flaws. So nobody can agree on everything. But even GCC supports D nowadays, which has modules and (semi-optional) garbage collection and templates and whatnot. Everybody wants to replace C, but nobody's quite done it yet (nor even C++). As much hate as classic (J&W) Pascal gets, at least it didn't need "pointers" at all except for the heap. No, it wasn't a systems language (like Modula-2), but that safety allowed Oberon to be garbage-collected by default. FreePascal is a very good (TP and Delphi) compiler that builds itself and even cross-targets i8086-msdos since 2015 (3.0.x). Upcoming 3.2.0 will finally have the built-in assembler and linker for much faster smartlinking. > > I don't think UNIX originally came with a C compiler (except maybe > > add-on?), so all you had was Sh and AWK. > > I have an AT&T 3B1. I got it *before* I got a DOS PC. It was a > single user Unix workstation, based on a 10mhz Motorola 68010 CPU (the > first model of that CPU with HW memory management.) It ran AT&T Unix > System V Release 2, and could boot and run an instance of SysVR2 in > *one* MEGABYTE of RAM. I would love to see a real guru (or genius) do something useful with that on YouTube. I kinda resent the idea that nothing useful can be done on lower-end machines. Modern hardware has spoiled us and dulled our senses, so to speak. I'm not asking for a C++20 compiler in one megabyte, but it's a shame that we can't barely do anything without 20 GB nowadays. ("It's hard." Yes, I know. But you can't keep throwing gigs of RAM at every problem as if that's a valid solution.) > Give it more and it flew. (Mine has 3.5MB > RAM.) It came with AT&T's "cc" C compiler, and I recall it being a > built-in, not an add-on. Things were different back then. It's like comparing Minix 2.x (1998) to modern Linux. Or even old ZipSlack (2006)! A lot has changed, not just games, compilers, web browsers, graphics, videos, HD, USB and whatnot. It's quite a mess. Even Minix 3 (2005-14) couldn't keep up! I still heavily respect them for trying, though. Modernity is just a bottomless pit, so to speak. > I was able to build Daniel Lawrence's version of MicroEMACS "out of > the box" on my 3B1, with no fiddling with the supplied sources needed. > Lawrence did a good job of confining non-portable code to architecture > specific modules that only got built if the code was being built on > that architecture. VILE was based upon MicroEmacs. It [2010] builds with DJGPP although I haven't tried any newer patches in recent years either. > I had fun implementing the WordStar command set in MicroEMACS, and on > the 3B1 I could use ME's macro language to add support for an > assortment of special keys on the 3B1 keyboard and do something > sensible in it when they were pressed. The extremely minimal DOS version [2005?] of the 16-bit e3 editor is "Wordstar only". I only used it due to its small size. Far from perfect, but for what it does, it does quite well. It builds with NASM. Normally, I prefer TDE (based upon DTE). > I respect Wall, and perl, but know just enough of it to be dangerous. > His "There's more than one way to do it!" dictum was both a blessing > and a curse. Honestly, sometimes just having only one way to do things is simpler. Variety is nice, or even better overall, but it's also more to maintain and keep compatible. That's why portability is so hard. Even with sympathetic developers, finding and maintaining reliable builds for obscure OS targets is not easy. (Luckily, FreeDOS still has some good tools and mostly works with various emulators.) FreePascal works hard to support dozens of targets. > There's a humorous list floating around comparing languages by how you > shoot yourself in the foot. For perl, the entry is "You shoot > yourself in the foot, but nobody else can figure out how you did it. 6 > weeks later, neither can *you*". :-p I believe the Modula-2 line was "since you can't do anything useful with it, you shoot yourself in the head!" (*nix nerds don't like very strict languages like Ada or Modula-2 and never used any modern Pascals or Oberon.) > Whether Sed is lighter than awk may depend on what version you run on > what hardware. But they have completely different use cases. You > probably can't replace awk with sed, or vice versa, and you may need > to use *both*. Sed is much easier to work with, IMHO, but it's less powerful. Presumably Sed would also be easier to bootstrap, but that depends on many factors (and most people don't care). > (I personally am disgusted when one open source project cannot use > code from another because of incompatible licensing, with the GPL > being the biggest problem child. Rob won't go anywhere near GPL > code. For that matter, neither will Google. These days, if I have an > option, I won't either.) License incompatibilities are counter-productive. But some people don't care. Honestly, licensing is almost always a waste of time. It's a shame that the wheel has to be reinvented over and over again because somebody wanted to be a stick in the mud for zero practical gain. > > Yes, Perl is overkill. You know, I rebuilt old NASM 0.98.39 [2005] > > recently for 8086. (Pre-existing 16-bit DOS binaries were 186 only, > > ugh, heheh.) > > My old XT clone is on a shelf under my computer desk. I gave it a > turbo 10mhz motherboard and NEC V20 CPU. The V20 had optimized > microcode, ran about 5% faster than the Intel 8088, and supported 186 > instructions. :-) > > (I recall seeing *one* PC clone in the old days, aimed at gamers, and > specifically using the 80186 CPU. I saw the 80186 in add-on cards for > Unix systems, where it was a controller for attached dumb terminals.) HP 200LX or whatever? What about that Tandy 2000 with Bill Gates in the ad? Yeah, the actual 186 was somewhat rare. > The significant thing for perl is that a DOS build *exists* Whether > anyone might have an actual use for it is another matter. 2007 was a long time ago in tech. Yes, I'm glad we have it, but I wouldn't trust *any* code to work with it. Perl is non-standard, and even "standards" are heavily ignored. It would take a genius to do anything significant with Perl that would work with DOS at this point. Not to be overly pessimistic, but practically speaking, Perl on DOS is dead. (Sometimes I think it's a miracle we have anything. I'm not blaming anyone. Kudos to those who helped over the years.) Most Perl code is almost certainly not tested on old interpreters. > > Yeah, it's just a mess. Big projects are harder to maintain, and > > unfortunately DOS is not "top tier" for most actively-developed > > projects. > > DOS probably isn't even on the radar screen. Why should it be? At this point, it's very difficult to support anything. There's too many cpus. One guy wanted Fedora to target AVX2 [2013/2015] as *minimum*, and that didn't go over well (give it a few years). It's not that DOS is important, it's that you can't rely on 2007 Perl to work flawlessly "out of the box" in 2020. (Heck, even this Chromebook is only supported for two more years. Nothing lasts. Maybe that's good, somehow??) I just wish everything wasn't so brittle, so trendy and quick to deprecate. There are so many hardworking people who try their best, and succeed, but some things always fall through the cracks. Let's just be happy that anything works anymore! > > Sorry for the ramble, it's just a minefield of tools out there. Still fun! > > That's true for pretty much everything. Want a minefield? Develop in > JavaScript. JavaScript is explicitly a "batteries not included" > language. Probably no worse than C, where people presume C99, GNU extensions, POSIX mmap, renaming/deleting open files, LFNs, Unicode, FPU, and tons of other environmental dependencies. We shouldn't expect miracles from developers. They're not always infallible, but they often do their best. (Sorry, again, for the ramble.) _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
