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

51–60 of 88 posts

Re: dBase: 1979-2026

#51

Post by badsectoracula »

bux93 wrote: post #24

The article states >By feeding legacy PRG (circa 1985) and logics to models like Claude, ChatGPT, developers can now instruct the AI to translate decades-old dBase PRG directly into memory-safe Rust, highly concurrent Go, or modern Dart/Flutter cross-platform applications. And it alludes to this early on, but it doesn't show any examples.

I don't know about converting it to "high concurrent Go" or anything like that, but after searching a bit, i found some old PRG code for dBase III Plus someone posted in a googlegroup, gave it to Devstral Small 2 (local model) and asked it to convert it to C# and the conversion looked fine to me, using .NET's database functionality, etc. It is too long to post it though (also TBH the code had some questionable fields).

In general LLMs seem to be very good at translating between programming languages and something like PRG uses very straightforward syntax and concepts. The first attempt by the LLM did a mostly one-to-one conversion using the console but i asked it to convert it to Windows Forms and the code looked fine for that too, using appropriate controls for the fields like text, combobox or datetime pickers (though it used fixed coordinates for the controls so i'm not sure if that looked fine).

FWIW, i didn't try to run the code (i'm on Linux and i do not even have anything related to C# on my PC nor a DB to work with :-P) and chances are there might be some subtle mistakes, but it looked like a decent starting point. IME, at least with local models, converting code between languages in a piecemeal fashion is trivial even with weird/less common languages (you may need to put some instructions to the LLM on a few edge cases though). And IMO that approach would be the right way to do it instead of dumping the entire codebase to it and hoping for the best :-P

Re: dBase: 1979-2026

#52

Post by mamcx »

smackeyacky wrote: post #18
mamcx wrote: post #11

Resurrect this kind of language is one of my goals ( https://tablam.org ) but of course with different takes. I think the main gist: you work not as app developer but as db developer, is something that is missing in some partial attempt like access and such. BTW: Wanna join me or help?

I want to say no. As a way of working those dbms systems were a dead end. Not every problem is database tables and having had a job replacing a dBase III system I never want to see it or its ilk again

I fully aware of the limitations of that tools (I worked professionally as Foxpro developer), that is what I said about resurrect the spirit but not the way is implemented.

The idea is to make things "relational" (with improvements) instead of fully "physical database tables" that is what tied you into a binary format.

With this, this binary format stop to begin opaque, and can be even be represented (tables and such) textually or by "standard" outputs like Msgpack.

So think that `data Customer` has decoupled the idioms, programatic interface to their specific storage. In rust terms, each `data` is `serde`, so you can change and move between how physically things are represented.

BTW this is how the relational idea was mean to be used.

Re: dBase: 1979-2026

#53

Post by badsectoracula »

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

Why not <= then? I'd expect both < and = to be available.

Re: dBase: 1979-2026

#54

Post by mamcx »

smackeyacky wrote: post #22
actionfromafar wrote: post #21

Earlier quoted context omitted.

80% of everything is crap anyway, no matter which tech stack. But I think something was lost, not everything is a database, but ever since Microsoft started ignored MS Access, nothing is a database. Or rather, Excel is used as a database. That can't be good either.

Oh 100% agree on Excel - it's no substitute for those dBase/Clipper/Fox systems. Y'know what? It's probably true that niche needs filling again as long as it isn't the dBase file format. I had to deal with one system that blew the documented max file size for dBase III but for some bizarre reason, the original dBase III executable didn't care. However, you couldn't load it with any of the ODBC drivers it would fail.…

Yeah, this is totally correct. What was great is the ability to do things like `SELECT name FROM NameOfForm` (in Foxpro, `forms` where stored in tables, so you can do sql on them), but what I say is that is the "free" query interface that is great, but if the actual thing is stored as json, csv, sqlite or whatever is orthogonal.

Re: dBase: 1979-2026

#55

Post by peterpanhead »

I wonder if there will be a drop of a new relational database to take on Postgres with a similar permissive license. Postgres isn’t great for every case. MySQL and MariaDB are not warranted as they can disappear at any time.

Re: dBase: 1979-2026

#56

Post by allenu »

I have vivid memories of thick dBase manuals on shelves in offices wherever somebody had an IBM PC or compatible computer. As a kid, I had no idea what it was, but the thick grey books made me think they must be a very important thing indeed. Just seeing the name dBase immediately evoked the memory of those books. Eventually I did get into computers and programming languages in my early teens but never did figure out what this whole dBase thing was.

Re: dBase: 1979-2026

#57

Post by tandr »

badsectoracula wrote: post #53
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

Why not <= then? I'd expect both < and = to be available.

Probably because '<=' is very easily read as "less or equal"? (unless you are joking, of course)

Re: dBase: 1979-2026

#58

Post by kccqzy »

gpderetta wrote: post #26
pjc50 wrote: post #23

Earlier quoted context omitted.

It's a notational issue. IIRC Pascal used := for assignment and = for equality testing. Where this becomes extremely Rorsarch is the spectrum between "notation is absolutely critical: there is only one correct representation of programs in people's heads and we have to match that exactly" vs. "all program text is ultimately syntactic sugar and programmers will just adapt to whatever". History tells us that the C choi…

I think parent was alluding to mutability.

Yes! In lazy but immutable languages like Haskell, it is totally fine to refer to the value itself during definition. This is really the same idea that a recursive function can refer to itself during definition. It’s common to define a variable for the infinite list of prime numbers, where the definition requires the list of prime numbers itself.

    primes = 2 : sieve primes [3..]
    sieve (p:ps) xs = let (h, t) = span ( rem n p > 0) t)
Here `primes` is a variable that refers to itself in its definition (called corecursion), and `sieve` is a recursive function.

Re: dBase: 1979-2026

#59

Post by whartung »

Jemm wrote: post #37

I worked in dBase professionally for a long time. Loved the system but the database constantly needing repair was an issue.

Switching from a "raw" b-tree system to an SQL system with transactions was an eye opening experience.

The typical troubleshooting path with the b-tree system almost inevitably, and very quickly, led to a "rebuild the indexes" process which no one enjoyed.

The transactions on the SQL system pretty much eliminated that error path completely. Only actual on disk file corruption would lead to trouble. We could always (and did) post wrong data to the DB, but the DB did what it was told (right or wrong), but having the indexes lose sync with the as records was never a problem.

Its hard to describe how refreshing that was.

I'm sure there were b-tree systems with in built transaction systems to keep the base rows in sync with the indexes, but they were pretty late to the game and the SQL DBs started taking over.

Re: dBase: 1979-2026

#60

Post by ASalazarMX »

hh2222 wrote: post #32
susam wrote: post #12

I remember dBASE IV from my childhood days when my father, who had no computer background, was required to take computer training by his workplace. My father and his colleagues were given free evening computer lessons by their company, taught by the same teachers who used to teach us, the kids, computers in our school. After their first class, he brought home a fat dBASE IV manual. Since I was very interested in comp…

Perhaps this is why BASIC originally used LET in the form LET X = X + 1, to imply a calculation rather than equality.

As kids we had the same debate because we were taught algebra before BASIC, and naturally tried to interpret it mathematically. Fortunately, sometimes a kid can explain it better to other kids than an adult, and that was the case.
Post reply on HN