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

21–30 of 88 posts

Re: dBase: 1979-2026

#21

Post by actionfromafar »

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

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.

Re: dBase: 1979-2026

#22

Post by smackeyacky »

actionfromafar wrote: post #21
smackeyacky wrote: post #18

Earlier quoted context omitted.

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

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. Except for one obscure Sybase based driver I have forgotten the details of.

Just couldn't deal with it again I don't think.

Re: dBase: 1979-2026

#23

Post by pjc50 »

antonvs wrote: post #19
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…

It’s a pity your father’s perspective didn’t prevail. We’d all be using better programming languages now.

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 choice of = for assignment and == for equality testing won, but of course that's not a choice in a vacuum and it's tied up with a thousand other choices.

Re: dBase: 1979-2026

#24

Post by bux93 »

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.

Re: dBase: 1979-2026

#25

Post by vasac »

pjmlp wrote: post #13

One of my favourite DB systems, started with dBase III+ where our teacher made us enter the high-school library records, followed up with Clipper Summer '87, and shortly thereafter Clipper 5.x with its OOP extensions. Great productivity tool, garbage collected, compiled, in the constrained environment of MS-DOS PCs. The migration to Windows 3.1 took too much time, giving time to FoxPro, Access, Visual Basic and Delph…

Ah, Clipper was a major force in the late ’80s in Yugoslavia, as economic reforms enabled the widespread establishment of private companies that needed accounting software, and PCs became cheap enough for one-person shops to develop custom accounting solutions. It was the Wild West for a few years, with a zillion different applications, until some bigger players emerged.

IIRC, it needed one or two 360K floppies for a full install (a pirated copy; maybe the legal distribution was larger - at that time, all software was pirated). Compiling was fast (on a computer where you type dir and can read the filenames appearing on the screen faster than the computer can print them), but linking was slow, so everyone replaced MS Link with Borland’s TurboLink, which was an order of magnitude faster. It didn’t support overlays, but there were ways to work around that.

There was also documentation available in some third-party TSR app.

Later, another linker became popular: Blinker, which had a bunch of interesting features, such as loading overlays into EMS memory and providing various security functions to help protect your software. But by that time, the writing was already on the wall for DOS.

Funnily enough, many customers actually preferred DOS, since navigating with the keyboard was far faster than using a mouse, and Windows apps generally weren’t designed with keyboard navigation in mind.

Re: dBase: 1979-2026

#26

Post by gpderetta »

pjc50 wrote: post #23
antonvs wrote: post #19

Earlier quoted context omitted.

It’s a pity your father’s perspective didn’t prevail. We’d all be using better programming languages now.

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.

Re: dBase: 1979-2026

#27

Post by michibertel »

I still maintain a VFP9 project from time to time. Although AI has been extremely helpful in writing VFP9 code, I can't imagine migrating this enormous project, which has grown over the course of 30 years, to a more modern system by feeding the source code to AI.

While one could debate which approach would be best for migrating such a project, an 'AI-led Big Bang Migration' would be insane.

However, AI would certainly be helpful for migration.

Re: dBase: 1979-2026

#28

Post by pjmlp »

vasac wrote: post #25
pjmlp wrote: post #13

One of my favourite DB systems, started with dBase III+ where our teacher made us enter the high-school library records, followed up with Clipper Summer '87, and shortly thereafter Clipper 5.x with its OOP extensions. Great productivity tool, garbage collected, compiled, in the constrained environment of MS-DOS PCs. The migration to Windows 3.1 took too much time, giving time to FoxPro, Access, Visual Basic and Delph…

Ah, Clipper was a major force in the late ’80s in Yugoslavia, as economic reforms enabled the widespread establishment of private companies that needed accounting software, and PCs became cheap enough for one-person shops to develop custom accounting solutions. It was the Wild West for a few years, with a zillion different applications, until some bigger players emerged. IIRC, it needed one or two 360K floppies for a…

Ah, Blinker! Never used it, but remeber the ads in magazines.

Same in Iberian penisula regarding software acquisition, even during university, the same copy centers for books, also offered catalogs of which software we would like to have, or street baazars even, only in the 2000's the goverment (in Portugal) actually started hunting down those practices.

Re: dBase: 1979-2026

#29

Post by e12e »

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.

As an alternative to leaving this to an LLM I came across:

https://github.com/infused/dbf/

I'm not sure what the article suggests - create a custom rust program that reads and writes to a given dbf file? Create a rust program that mirrors the PRG code, writing/reading data in a custom format?

Re: dBase: 1979-2026

#30

Post by pkphilip »

The Borland/Inprise/Embarcadero mess impacted a lot of software.

They could have still been the king of the hill now if it weren't for the suits who completely ruined it after Philippe Kahn left the scene.

Post reply on HN