Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

dBase: 1979-2026

delphinightmares.substack.com

Post reply on HN
Print view View original

81–88 of 88 posts

Re: dBase: 1979-2026

#81

Post by keernan »

orionblastar wrote: post #4

Microsoft Access 2.0 had filters to import and export data from and to DBF files. We used this in WFW 3.11 to convert from DBase to MS-Access and later on SQL Server. There were some Turbo C and Turbo Pascal source code that read DBF files, but hardly anyone used them. Most stored data is in text files that can be read by any application.

I started with dBase but quickly moved to foxbase which was much faster. Foxbase was renamed FoxPro when DOS moved to Windows and soon thereafter Microsoft purchased FoxPro. Since FoxPro was a dBase derivative, there were high quality conversion interfaces between Access and FoxPro (and all dBase dialects).

Aside: I was such a fan of Foxbase that the very day Microsoft's acquisition was announced (circa ~1992), I invested $10,000 in Microsoft. I sold maybe 10 years later for $100,000. Stupid Stupid Stupid.

Re: dBase: 1979-2026

#82

Post by layer8 »

UltraSane wrote: post #74
layer8 wrote: post #69

Earlier quoted context omitted.

But x isn’t x + 5. If anything, it should be “x becomes x + 5”.

Ok. How about Set x to x + 5

That’s pretty much COBOL syntax: https://www.ibm.com/docs/en/debug-for-zos/17.0.x?topic=comma...

Except that COBOL doesn’t allow an arithmetic expression there, so you have to write

    COMPUTE X = X + 5.
instead. ;)

Re: dBase: 1979-2026

#83

Post by jackzhuo »

weinzierl wrote: post #45
hh2222 wrote: post #32

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…

[dead]

Re: dBase: 1979-2026

#84

Post by selcuka »

Doxin wrote: post #78
selcuka wrote: post #70

Earlier quoted context omitted.

> ALGOL decided to stick close to mathematical tradition And now we have all 3 in Python (=, ==, and :=) which makes me sad.

Splitting = and := in python is very intentional though, It makes writing bugs like this impossible: if is_logged_in=True: allow_access() I've got... opinions on the way python separates statements and expressions, but there's some real benefits to it too.

Splitting = and := is intentional, but not for the reason you stated. We could have used := for all assignments from the beginning:

    is_logged_in := True
or

    if is_logged_in := True:
I agree that this would require blurring the statement/expression distinction. You can still do that in a weird way, by disguising your assignment as an expression. This is valid:

    (is_logged_in := True)
The reason it was done that way because := was an afterthought, and making it the assignment operator would have introduced a breaking incompatibility. That lead to having 3 different symbols for 2 use cases (assignment and comparison).

Re: dBase: 1979-2026

#85

Post by jdougan »

teddyh wrote: post #48
weinzierl wrote: post #45

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…

A rumor I heard was that x := 4 was chosen because it looks similar to x ⇐ 4

In some of the draft versions of ASCII the positions currently taken by underscore and caret were left arrow and up arrow respectively. As late as 1985 I used terminals (LanparScope) the supported the older draft.

Re: dBase: 1979-2026

#86

Post by teddyh »

jdougan wrote: post #85
teddyh wrote: post #48

Earlier quoted context omitted.

A rumor I heard was that x := 4 was chosen because it looks similar to x ⇐ 4

In some of the draft versions of ASCII the positions currently taken by underscore and caret were left arrow and up arrow respectively. As late as 1985 I used terminals (LanparScope) the supported the older draft.

All Commodore machines also uses the older ASCII standards, (in addition to filling out the full 8 bit range with various graphics). It’s usually referred to as “PETSCII”, from the original Commodore “PET” series, but PETSCII was also used in the vastly more popular Commodore 64 (and 128) home computers.

Re: dBase: 1979-2026

#87

Post by Doxin »

selcuka wrote: post #84
Doxin wrote: post #78

Earlier quoted context omitted.

Splitting = and := in python is very intentional though, It makes writing bugs like this impossible: if is_logged_in=True: allow_access() I've got... opinions on the way python separates statements and expressions, but there's some real benefits to it too.

Splitting = and := is intentional, but not for the reason you stated. We could have used := for all assignments from the beginning: is_logged_in := True or if is_logged_in := True: I agree that this would require blurring the statement/expression distinction. You can still do that in a weird way, by disguising your assignment as an expression. This is valid: (is_logged_in := True) The reason it was done that way beca…

except if := was the default then accidentally typing ":=" instead of "==" would be the easy bug to make.

:= was bolted on after of course, and I think that was a mistake, but no one asked me, nor do I expect anyone to ;P

Re: dBase: 1979-2026

#88

Post by kcartlidge »

c_prompt wrote: post #43

Don't forget DataEase [1]. That's what I eventually moved to from dBase (although, IIRC, it was through back-and-forth evaluations of FoxPro, Clipper, and Paradox). DataEase was considered a "Fourth-Generation Language" (4GL) and it was wonderful to work with. As a teenage "systems analyst" working for a division of GE (my first paid tech job), I built a file room management system for their large file rooms (remembe…

One of my trifecta of 'perfect' DOS software: DataEase 4.53, WordPerfect 4.2, and TopSpeed Modula-2. Given the restrictions of the day, all three were incredible.
Post reply on HN