Hacker News Reader

How did I know this story would have your comment and it would be up top? :)

To still add something to the discussion -> I never coded on a black&green CRT, but I did learn programming on an environment doing 24x80 16colour ... graphics? Text graphics. (this was ~1994)

It was fun. For the first few years of my computing experience I never really left DOS and kept trying to reproduce the shiny Windows stuff in there. I still think that was better and more fun than when I briefly tried learning how to make "real applications" before jumping ship to Web.

My story is similar to yours, even the year 1994.

I was totally engrossed in writing custom batch files using ANSI.SYS escape sequences to create text "graphics."

My story is also similar to yours, but it involves QBasic, Mode 13h, and 1995. :)

How can you not go crazy doing the same thing over and over? My first commercial software project was in BASIC, back on a Commodore PET, it was a billing app for a shared telex system, but there's not way on earth I'd want to be still using BASIC, or Pick for that matter. The one constant for me over the years has been Unix (from Apollo, to HP UX, to Sun to Linux) but if you try new tech stacks you'd never want to go back to systems from 40+ years ago.

While I think there's money to be made in maintaining those old systems, I would just go insane not keeping up with technology and using modern stacks. CS has progressed for a reason, the level of abstraction today is so much higher that we don't have to write from scratch all the time, there are well tried and tested components.

Setup=Windows PC && OS=Unix, doesn't seem to make much sense, unless you mean Windows as a terminal (putty et al.)

Now, back to Python...

How can you not go crazy doing the same thing over and over?

Because I'm not doing the same thing over and over. I'm just using the same technology. I rarely encounter things I can't do with it. I love Pick more than anything else I've ever used.

but there's not way on earth I'd want to be still using BASIC, or Pick for that matter

Pick is almost like a cult and for good reason. It's incredibly elegant, simple, and powerful. Most Pick programmers, even after learning newer technologies, still love Pick and use it whenever practical.

but if you try new tech stacks you'd never want to go back to systems from 40+ years ago

Exactly the opposite of my experience. I've tried many tech stacks and have come to appreciate their pros and cons. But I love coming back to "old faithful". With Pick, I spend most of my time on the problem at hand, not the tech stack. Not so true for many more modern technologies.

I would just go insane not keeping up with technology and using modern stacks.

I never said I didn't keep up. I do and I love to. The thing that would make me go insane: not having fresh customers with fresh problems.

CS has progressed for a reason

Make no mistake about it; the biggest reason has been the internet. So much CRUD technology is so powerful and stable, there hasn't been as much need for "progress".

the level of abstraction today is so much higher that we don't have to write from scratch all the time

I never write from scratch. I use the same 30 or 40 building blocks for every project.

there are well tried and tested components

I'd say that Pick's 40 years and millions of apps make it well tried and tested, too.

unless you mean Windows as a terminal (putty et al.)

I do. Putty on my left, Firefox on my right.

Now, back to Python...

Oy.

I wonder how many other programmers could make the same claim.

Probably a lot more than you think.

I've seen estimates of 1-2 million COBOL developers worldwide.

You're connected right now to a Pick system? From your point of view, how does Pick compare to the current wave of NoSQL databases, practically speaking? What are the advantages and disadvantages?

UniData/UniVerse were acquired by IBM and then spun off to form Rocket Software. As I recall (this could be total folklore) the product team wasn't getting the love from IBM and managed to convince IBM to sell off the BU.

Rocket and IBM have done a bit with U2 to open up the multi-value data files and UniBASIC programs to "open systems", i.e., Java, .NET, SOAP, REST-ish, etc.

It's still a bit of a pain because values are strings, one has to extract MV/SV data by tokenizing along delimiters, there's a massive amount of data duplication (no FK relationships), multi-byte causes problems with older programs (and many, many of them are very old programs), and there's no concept of data queues as you might be expecting if you've worked in an OS/400|i Series|System i|i|etc. shop with RPG.

That said, it runs happily on Linux and is quite robust.

Many of the problems relate to programming practice. As you can imagine, there are some "lifers" who don't stretch themselves, argue GOTO vs. GOSUB, copy-and-modify existing programs for new requirements, and don't use source control or automated unit testing. Then there are those who refactor 17 copied versions of programs doing basically the same thing into a modular package and slap an object-ish API on top.

With a rational approach, the environment is actually quite pleasant, but it does take some discipline. It is difficult to retrofit a more rigorous engineering process onto legacy code, but that's the case whether it's Pick/UniData or any other programming environment.

I haven't used NoSQL databases, so I don't have an opinion on that comparison. As for more traditional relational DBMSs (MySQL, Postgress, Oracle), there are many differences which could be considered either advantages or disadvantages, depending on who you asked. Examples:

  - level of normalization determined by programmer, not DBA
  - relationships (joins, etc.) enforced at program level, not schema
  - no typing (everything is a string)
  - DBMS performance is mathematically predictable & determined (hashing)
  - everything is variable length
  - anything can be multi-valued or multi-subvalued
  - No schema needed. Just code.

It sounds a lot like the benefits of one flavor of the NoSQL databases — thus my question. (Another flavor of NoSQL, stemming from BigTable, is more focused on horizontal scalability and partition-tolerance.)

but isn't it questionable that you're (seemingly) writing the same stuff, from scratch, for 28 years now? shouldn't there be a work order processing standard solution for aerospace by now?

like an engineer re-inventing the process to build bricks anytime a new building is requested.

industry observation, not personal.

> shouldn't there be a work order processing standard solution for aerospace by now?

There are probably several, all mutually incompatible in some way, and chances are every company picks bits from each to make their own "local" standard (a local standard that gets worked every time the name associated with a C*O title changes).

Sometimes we are not in a position to control the constant wheel evolution and just have to get on with it & accept the paycheck.

I'm not writing the same stuff. I've written over a thousand different custom applications using the same technology. That was my point. This environment is so tried and true and so effective, it still kicks ass after 28 years. Pretty amazing when you think about how much has changed.

shouldn't there be a work order processing standard solution for aerospace by now?

I'm sure there is. Just like there are blog, website, & CMS standard solutions. And plenty of people using them. I never see them because those people would never call me. Like many other programmers here, I imagine, we only see the customers who need something custom, almost always for good reason.

+1 for Pick. I've met several people who were/are Pick devotees. Also heard stories about how Dick Pick was kind of crazy.

My mentor knew Dick, and I also heard stories!

A shameless plug for people wondering "what is this PICK thing?" I host http://www.pickwiki.com, in an effort to capture some of those fascinating (to me) stories. The guy that created it really was called Dick Pick.

I wouldn't choose PICK for a brand new project today, but as Ed says, there's life in the old dog yet...

sounds like you need a new mentor

so how do you keep trying new environments and after validating them return to your preferred one?

asking cause 28 years is an eternity in regards of IT - or at least that's what we hear day in, day out.

The aerospace industry is a license to print money for any vendor involved.

I'm wondering, is the dialect and feature set of the BASIC you use now the same as the one you used back then? I imagine the largest factor in that list is the language.

I commonly have to code in older versions of my preferred language, and it's always a bit grating. I'm always pining for the newer features that I've grown accustomed to.

Damn, I love reading your comments. Although my early memories were from typing BASIC programs into a Commodore 64...from the back of a magazine! (I'm a little younger than you).

I last played with pick and pick-basic back in 1999 (and I used the UniData flavor). Here is what I remember of PickBasic: an overly simplistic version of BASIC without the advancements of scoped variables and methods, you still had to use GOTO <numbered-label>.

I don't miss that language one bit.

Now PICK as a data storage. Not bad, but did nothing well either. Could be I have the reverse of positive nostalgia on this one.

Strange how much code I wrote on a 80 char x 20 line Beehive terminal in RSX-11 and later on a 80 x 25 line Heathkit H29 (woo hoo detachable keyboard!). Now with arbitrarily sized screens I really can't go back to just "one" (or in the case of the VT420 "two") screens worth of text.

Holy crap. I'm the annoying chubby suit bringing in all the Java, Rails, and ecommerce people.

Small world.