61–70 of 88 posts
Somehow I scored a (stripped down?) copy on multiple floppies that I couldn't even use, as an Amiga owner - but incredibly, this freebie came with a fantastic paper manual which I devoured.
Earlier quoted context omitted.
Perhaps this is why BASIC originally used LET in the form LET X = X + 1, to imply a calculation rather than equality.
The = for assignment is FORTRAN’s fault. In the beginning there was no equality, just assignment, and FORTRAN (being just a FORmula TRANslator after all) made the somewhat dubious decision to use = for that (punch card space being sparse and symbols limited and all). When FORTRAN gained equality it went for .EQ. out of practicality and necessity. Many others followed suit but used the somewhat more pleasant == instea…
X is 5
X is x + 5
Earlier quoted context omitted.
Perhaps this is why BASIC originally used LET in the form LET X = X + 1, to imply a calculation rather than equality.
The = for assignment is FORTRAN’s fault. In the beginning there was no equality, just assignment, and FORTRAN (being just a FORmula TRANslator after all) made the somewhat dubious decision to use = for that (punch card space being sparse and symbols limited and all). When FORTRAN gained equality it went for .EQ. out of practicality and necessity. Many others followed suit but used the somewhat more pleasant == instea…
x is 5
x is x + 5
I'm guessing dBase was itself built using Microsoft's compilers, so pulling in other code from the same compiler was plausible. Not a product choice re: the Turbo compilers, just a disjoint path dependency between two acquired product lines (Ashton-Tate's dBase, and Wizard C).
This is the reason that Clipper, a third-party dBase compiler, could only link against .OBJs from particular versions of Microsoft C. Clipper compiles to p-code whose interpreter is implemented in Microsoft C; "linking" a Clipper program is actually linking a Microsoft C program with a static array comprising the Clipper compiler's output. So you can mix in a .OBJ expecting that version of the Microsoft C runtime library. Not a .OBJ expecting the Turbo C++ runtime library.
Earlier quoted context omitted.
I think parent was alluding to mutability.
While I'm a big fan of immutable design, it makes some algorithms much more expensive and ultimately DRAM is mutable. And the example we're talking about could be a loop counter!
> ultimately DRAM is mutable
Ultimately the CPU executes machine code, but I don’t see you directly writing that. You’re cherry-picking to defend an indefensible position.
Earlier quoted context omitted.
The = for assignment is FORTRAN’s fault. In the beginning there was no equality, just assignment, and FORTRAN (being just a FORmula TRANslator after all) made the somewhat dubious decision to use = for that (punch card space being sparse and symbols limited and all). When FORTRAN gained equality it went for .EQ. out of practicality and necessity. Many others followed suit but used the somewhat more pleasant == instea…
I would prefer X is 5 X is x + 5
I kid, of course, but "X is x + 5" brings Prolog to mind with all the unification and bidirectionality that implies.
Shapefiles, the legacy multifile file format for geospatial stuff that is still an incredibly important interchange format since it has basically universal support is built around DBF files. So despite it being an incredibly old file format it's still used constantly in the GIS world and it's probably not going to go away because while it's not a good format, it does basically everything at to at least a mediocre lev…
Earlier quoted context omitted.
The = for assignment is FORTRAN’s fault. In the beginning there was no equality, just assignment, and FORTRAN (being just a FORmula TRANslator after all) made the somewhat dubious decision to use = for that (punch card space being sparse and symbols limited and all). When FORTRAN gained equality it went for .EQ. out of practicality and necessity. Many others followed suit but used the somewhat more pleasant == instea…
I would prefer x is 5 x is x + 5
Earlier quoted context omitted.
Perhaps this is why BASIC originally used LET in the form LET X = X + 1, to imply a calculation rather than equality.
The = for assignment is FORTRAN’s fault. In the beginning there was no equality, just assignment, and FORTRAN (being just a FORmula TRANslator after all) made the somewhat dubious decision to use = for that (punch card space being sparse and symbols limited and all). When FORTRAN gained equality it went for .EQ. out of practicality and necessity. Many others followed suit but used the somewhat more pleasant == instea…
And now we have all 3 in Python (=, ==, and :=) which makes me sad.