I spent several weeks during the Summer of '82 living in dorms and taking college courses at UCF. My suitemate, John, was writing Petman in machine code, on and for his PET 16. An enduring memory for me and one which reminds me that there are programmers who are 100 more productive than others - I was at the stage of typing in code from magazines.
I used an East German version of the KIM (LC80) for lab experiments. In 1999!
Tying in code was slow and debugging even slower, but the hardware I/O was easy, no fuzzing around with RS232. Ahhh, good times.
Date: Monday, April 29, 1985
Age: 29
Location: Santa Ana, California.
Company: electronics manufacturer
setup: dumb black & green 24x80 14" CRT terminal
Hardware: Honeywell mini
OS: Honeywell proprietary
DBMS: Pick (Ultimate Flavor)
Language: BASIC
App: Work Order Processing (I wrote from scratch.)
Date: Monday, April 29, 2013
Age: 57
Location: Miami, Florida
Company: aerospace manufacturer
setup: Windows PC, 19" & 32" flat screens monitors
Hardware: who knows
OS: Unix
DBMS: Pick (Unidata flavor)
Language: BASIC
App: Work Order Processing (I'm writing from scratch.)
That's right, everything I wrote in 1985 would compile and run perfectly in the environment I'm connected to in my other session right now. And everything I'm writing today would have also worked on that mini-computer back then. I wonder how many other programmers could make the same claim.
I have learned and continue to use many other client/server and web-based technologies since then but somehow, I always come back to "old faithful".
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.
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.
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...
> 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.
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.
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.
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.)
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.)
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.)
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.
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.
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).
This brings back a lot of memories ... Hand-compiling code for a COSMAC ELF (http://www.cosmacelf.com/docs.htm) and punching it into memory on a hex keyboard (the original had a switch for each bit and 4 push-buttons for load, run, etc).
By the time I was coding for 6502 and 8088 processors (still in assembly language - I was after all an embedded engineer), I had assemblers and an 80-column by 43-line text editor.
Aren't we spoiled today? I wouldn't want to go back, but I've also found that the low-level experience with machine code is something many "newer engineers" are missing ... it's an appreciation of the hardware that you can't get any other way.
Computer Engineering still offers this experience. It's the main reason I picked this major when I returned to school after many years as a programmer. Most of the graduates from here go on to software development. The low level experience makes them well suited to work on embedded systems, device drivers, and operating systems.
heh. i also programmed a stepper motor in ~1985 (after building the driver board). but it was z80-based (and it never ran smoothly - when i left i think they were going to try adding some noise to the timing, but that didn't sound likely to me - more likely i had a crossed wire in the hardware...). anyway, i am pretty sure i had an assembler (and this was working for a one-man company in the backwoods of n yorkshire). why were you hand assembling?
I was in high school in 1985 and our computer club built a Heathkit HERO-1, which had a 6808 processor and also had to be programmed through the hex keypad. After a few months of hand writing machine code and typing the opcodes into machine, I wrote a simple assembler on the Apple //e that would then download the assembled programs to the robot through the RS-232 interface. So much fun.
My dad had one of those. So cool, I enjoyed keying in "programs" on the head keypad to make it move and speak (I was around 9 or 10); I would have loved your tool (if I could get it for the Osbourne we had then...).
Edit (+12mins): I see lots of people viewing, but not a single edit over the past 10 minutes.
Edit (+60mins): One other anonymous user helped at last and the document is complete, but didn't leave his username in the contributors list yet. Anyway, thanks!
Now the big question is how to run this. If you have any idea how to run it, let us know!
I did my bachelors (in India) in the mid-90s, and we all coded this way in our 8085 labs. Many of us even did final-year projects on similar-looking 8085 kits.
Given that such kits are still sold [1] in India, I guess quite a few engineering students still learn to code like that.
My bosses, though, had all worked on punched cards.
>>Given that such kits are still sold [1] in India, I guess quite a few engineering students still learn to code like that.
Did my Bachelors(in India) in 2010's, and yes even we coded this way in our 8085 labs!!! Nothing has changed. Talked to my cousin who is now in his 3rd semester, They to start out coding the same way. Its 2013 and NOTHING has changed.
I had a KIM-1 in the late seventies and for several years I would run into other people who used one, but 1985 seems really late for programming on one of these. For me, the KIM-1 was my first experience with programming and a computer of any sort. It influenced my taste for low-level concepts, not only through x86 assembly programming for graphics in the 90s but much later in the lambda calculus and combinatory logic. I'm tickled that the KIM-1 is seeing such a resurgence of interest.
But that FSK demodulator was incredibly finicky. More than one tape I recall I had to try to read a lot of times while tweaking the playback speed on the recorder!
one of the good things about a formal CS education (well, mine anyhow) is that they force you to do things like write in assembly. obviously there's far less immediate practical application these days, but the exercise is definitely valuable, and probably not something I would have done voluntarily. Actually, it feels like something I would have thought sounded cool, tried, and then given up on when it got annoying.
You can make transistors with some...hazardous components, but you may want to start with relays or tubes and resistors (which could, theoretically, just be varying lengths/guages of wire) and build NAND gates. It would be big, hot, noisy, slow, and a huge waste of your time, but there were computers before semiconductors.
Relays are doable from scratch (mining and refining copper; winding coils, etc etc) but it's going to be pretty hard work and you're going to have a very slow computer at the end of it.
I honed mine early enough that the most I need from a program is a few Sprintf statements just to give the brain debugger some context when the application is dealing with external data or data transformation.
I personally find it hard to turn off the brain debugger and rely on software. Originally this was because you'd very much be used to the debugger being wrong. As in, "Ah, but in this case the debugger thinks X but Y is the case", and later just because the brain debugger had become so effective that not using it seemed like a lot of hard work for little extra gain.
How other programmers visualise or handle code in their brain, and how they put together new functionality in their head, is deeply fascinating. Even if you have self-awareness enough to grasp the basics of how you do it, you can be reasonably sure that each of us does it slightly differently.
I can often do that on code I've written or am intimately familiar with, but tons of the code I work on is code that someone else wrote and that I rarely interact with. As a result, I love my debugger.
In my experience this only works if the feedback cycle is quick. If working with a language like ruby or python and just refreshing webpages or running a script, no big deal. However, I then would have to wade through logger output to filter out the information I needed. I ultimately found I appreciated a debugger such as pry.
Then I started writing for Android and the time between compilation, installation, running the app, and then reproducing the scenario was too long and a debugger was a godsend.
Yea!, I used to steal "NCR programing paper sheets" from my older bro (he worked for NCR) to write most of my assembly code.. (For a Zinclair Z80) ahh the memories of peek & poke :)
It's kind of useful to write out code by hand, or at least pseudo-code...I'm not a neuroscientist but I wouldn't be surprised if it turns on a different part of the brain. Last week I was sitting in the park with nothing to do and I reflexively pulled out my iPod to play Sudoku on it. Since it was one of our first nice days I felt bad about that so I just wrote out the Sudoku grid on a pad of paper and solved it from there. It was surprisingly difficult, even though it was an easy puzzle (the iOS version highlights which minigrids on the main grid that a given number appears in for starters).
Anyway, anytime I think about what a pain in the ass writing, or even just typing out code can be, I refer to the chapter in iWoz in which, lacking development software at the time, he "wrote out the software [for Little Brick Out] with pen and paper and then hand assembled the instructions into 4096 bytes of raw machine code for the 6502"
There is a psychiatric condition known as 'graphomania' in which one has an obsessive compulsion to write, the content being secondary in importantce. So it's conceivable that such a structure in the brain exists and can become overstimulated.
That's really fantastic that he was able to save his work from 28 years ago. I really wish I had the foresight to do the same from only five years ago, though I expect the result would be less like unearthing buried treasure and more like finding what stinks in the fridge.
I am just beginning to worry about this sort of thing (#)
but what age were you in 1979/82 with your sharp computer,
and I have assumed I will be trying to guide my son / daughter onto emulators (nand2tetris etc) rather than real physical machines - or are there real physical machines which are simple enough and have root on to be early hacking machines?
"are there real physical machines which are simple enough and have root on to be early hacking machines?"
If you really want to re-enact the OP article, visit Briel Computers and get a Micro-KIM. Mine works perfectly. At the 2013 Midwest Gaming Classic someone (not me) was exhibiting an original KIM (as seen in the post) and a microKIM side by side in the retrocomputing room, which my family found entertaining because I also have one mounted on a wood plaque in my "office" area. How else are you going to display one?
I was always more of a Z80 guy... speaking of Z80 computers, one currently shipping project is the N8VEM CP/M SBC project which I found pretty trivial to assemble and use, not to forget the P112 SBC as recently seen on kickstarter.
Then there's my stack of FPGA devices ranging from the micronova mercury to my boring typical Spartan boards, which twists the borders of "real hardware" and emulation.
I gave my daughters TRS 80 model 100 computers for their tenth birthdays. It has a 8085 processor and really a quite powerful basic (the last software bill gates worked on, and its not bad) with a bit mapped display. They run for weeks on 4 Aa batteries and have a better keyboard than most modern laptops. here is an emulator available, but since they go for about $30 on eBay, I like having the real thing.
I bought a box of these recently and they are really great; I used to have TRS 80 III and 4 so when I saw I box (don't hit me) of model 100s for 10 euros I bought it. They're a very nice addition to my museum and batteries last forever. The box had 1 Sharp PC-1211 too. Talking about battery life :)
What always amuses me is that my computers from around 2000 are not working anymore (heck, most laptops I have from the past 10 years are not even booting anymore) while computers from my parents basement which are around 30 years old just work like they just came from the shop. Even the Philips computers from that time who had known capacitor issues in the power circuitry work like time didn't happen.
Arduino kits are great hits with the 8-15 year olds in the family. They can play with the sample code and tweak it and see something happen "in the real world", whether it's a flashing LED or "upgrading" their Lego to torment the cat.
It's similar to those Radio Shack "3000 electronic experiments" boards that were sold in the 80s(?) and yet can scale with the kids' understanding.
Sure, it's not self-hosting, but I've noticed the physical connection to caps, resistors, diodes, etc. in a "safe" environment makes them more proud of their accomplishments than their html/css projects.
That's late for hand coding assembler (and very late for a KIM 1). Last time I did any hand assembly was 81/82 for a ZX81. Graduated to an Apple //e where I wrote my own assembler using the mini-assembler in the integer basic ROM and Apple Writer I as a text editor. By 1984 I had gotten my hands on the Apple ProDOS assembler so my bodged mini-assembler got put out to pasture.
Mind you I've just got an Atari 65XE from ebay today which I will now have to explain to my wife (I always thought the Atari graphics was neat and wanted to play with the display list stuff but never did so at the time)
I remember playing around with machine instructions on the 6502. I wouldn't call it hand assembly; it was more like copying and groping around. I probably wrote less than 200 lines in my life.
But what a neat feeling! There's something about putting in these numerical codes and seeing a graphical result that I haven't experienced since then. Yes, higher-level languages rock, but dang, this is coding next to the metal.
After learning a bit about logic gates and playing around with the theory, there was an incredible feeling of discovery. Somehow I had deciphered the code of computers, and was finally speaking their native language. This brought back great memories. Thank you.
I know that feeling. My undergrad CS course had a rigorous electronics component where we coded in ASM for the 8086. One of my fondest moments of that time was when I wrote a program that would split the terminal screen into two halves of different color, and display what you typed on one side and the inverse case on the other.
This could probably be done with less than 50 lines in python, but doing it in assembly, calling all those interrupt routines, making sure your registers contained all the right values, man, when it finally worked, it was the greatest feeling in the world!
Wasn't it? And for that moment, you could look out and imagine "Damn, I could code the whole freaking thing like this!"
Then you realize it would take around 30 years, but still -- it was doable. You finally figured out how it all worked. You could make the computer do anything it was capable of doing. There was no more mystery there.
Do you really think it would take 30 years? The NAND-To-Tetris kids do most of it in a semester, and they're starting at the level of individual gates.
I mean, Chuck Moore has been doing it for about 30 years, but he had a working top-to-bottom system after less than five years.
Here's what I think it would look like:
Week 0: build a working interactive Forth system that can compile itself, in machine code. This is assuming you already have hardware and a way to boot it into some code you wrote. If not, that could be a matter of minutes or of months.
Weeks 1-3: build an interactive high-level language interpreter on top of it. Say, JS.
Week 4: enough of TCP/IP to do HTTP GET.
Week 5: write a bitmap font editor and a minimal filesystem.
Weeks 6-8: parse HTML (more or less), lay it out with a simplified box model, and draw it to pixels on a canvas, using a pixel font.
Week 9: cookies, HTTP POST, XMLHttpRequest.
Week 10: a more elaborate filesystem, maybe based on Git.
Weeks 11-12: some more HTML5 features, maybe including WebGL.
Weeks 13-14: TLS.
This is sort of cheating because you're taking advantage of our previous 70 years of experience to figure out what's worth building, and you're likely to end up spending a fair bit of time going back and retrofitting stuff onto previous iterations — JIT compilation, say, and multitasking — but it still seems like rebuilding the personal computing environment ought to be more like a one-semester project than a 30-year project.
You could argue that you get a huge speedup by not writing stuff in assembly, and I agree, but I think that's only a constant factor. You could easily write assembly code that maps directly onto JS semantics:
At 12 I had learned how to program, in Z80 assembly, a routine to output to the graphics card of my dad's ancient-even-then Radio Shack model 16. I created a custom font that looked like the beautiful VGA font and used it to render 16-bit numbers in gorgeous decimal digits.
Jokes aside, writing down something like OP's software in pen from scratch would require some degree of proficiency and confidence. I can still see some pencil around the paper, in any case :) (Not to diminish the achievement - As a young programmer, I'm always impressed when I see these things and I'd love to see more and more of them!)
i agree, you have to give serious props for that. anytime i write any kind of prototyping/design sketch in pen, it gets all scratched up and crossed out..
And this was just a small utility. Then think about things like the Apollo program being coded the same way (or more obliquely on punch cards).
There is a finite and limited amount of complexity this allows for. We've been given quite the catch-22: the ability to build increasingly complex system while needing to maintain those increasingly complex systems.
On whatever project you are currently working on, how much less code do you think you'd be writing if you had to hand write it? Where would the project be better for it and where would it be worse?
Slightly longer: we're re-inventing the wheel through a very roundabout path, I think right now we've gone back in time to roughly the mainframe area, it won't be long before someone will invent the mini computer all over again only this time it will be a local cluster in a box. Next after that the PC, a 'personal cluster' with a few 100 nodes the size of the desktop machine you had last year.
I don't think it was the web. The pre-web applications with GUI clients running on PCs and servers on mainframes were already pretty complicated (remember Microsoft's ever-changing object APIs, or CORBA?). What made things increasingly complicated was the ever-growing power of computer and communication hardware, which made it possible to create larger and more complex systems. If you're limited by having to run your software on a machine with a total of 256K of memory (like the first machine I used Unix on in 1980), you just can't build something as complex as what you can build today on a cheap laptop.
We were building clusters of PCs in the 1980's using arcnet. Those were pretty large and complex systems, they used a very elegant message passing protocol. And that definitely wasn't the only game in town for large and complex systems (but it was one of the most productive ways of constructing those systems with a small team).
And it's not the first time the mainframe has been re-invented - I remember sitting through a presentation on the technical architecture of SAP (don't laugh) and I thought "it's a software mainframe".
In the 70s and 80s programmers were working on fixing the problems that programmers faced in the 70s and 80s: memory management, GOTO spaghetti, efficient assembly etc. In response we got heaps, garbage collectors, functional languages, virtual machines, compilers, debuggers, IDEs.
Now most programmers spend most of their time dealing with problems of persistence, networking, parallelism, security, and massive codebases. In response we are creating scripting languages with slightly different syntax, adding closures to Java, and arguing about vim vs emacs. We're so obsessed with solving the problems of the 80s, my way, that we've just gotten trapped there.
I have fond memories of programming my "Arnesh" 68 K board around 1995. We used them in our microprocessor course, and since I had so little time in the lab, I bought my own board. After the class ended I would lend it to friends until it came back fried. One of these days I need to dig it out and try to repair it, now that I feel a little more secure with a soldering iron.
119 comments
[ 2.8 ms ] story [ 202 ms ] threadI have learned and continue to use many other client/server and web-based technologies since then but somehow, I always come back to "old faithful".
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?
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.
asking cause 28 years is an eternity in regards of IT - or at least that's what we hear day in, day out.
I wouldn't choose PICK for a brand new project today, but as Ed says, there's life in the old dog yet...
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.
Small world.
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.
I was totally engrossed in writing custom batch files using ANSI.SYS escape sequences to create text "graphics."
Probably a lot more than you think.
I've seen estimates of 1-2 million COBOL developers worldwide.
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.
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...
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.
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 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.
By the time I was coding for 6502 and 8088 processors (still in assembly language - I was after all an embedded engineer), I had assemblers and an 80-column by 43-line text editor.
Aren't we spoiled today? I wouldn't want to go back, but I've also found that the low-level experience with machine code is something many "newer engineers" are missing ... it's an appreciation of the hardware that you can't get any other way.
I've made a start, but it takes a little longer than I'd thought (handwriting is often hard to read). Let's do some crowdsourcing?
https://docs.google.com/document/d/192TW6ghnmMFnVaNvIe98aqTG...
Edit (+12mins): I see lots of people viewing, but not a single edit over the past 10 minutes.
Edit (+60mins): One other anonymous user helped at last and the document is complete, but didn't leave his username in the contributors list yet. Anyway, thanks!
Now the big question is how to run this. If you have any idea how to run it, let us know!
Given that such kits are still sold [1] in India, I guess quite a few engineering students still learn to code like that.
My bosses, though, had all worked on punched cards.
[1]: http://www.dynalogindia.com/products/education-solutions/808...
Did my Bachelors(in India) in 2010's, and yes even we coded this way in our 8085 labs!!! Nothing has changed. Talked to my cousin who is now in his 3rd semester, They to start out coding the same way. Its 2013 and NOTHING has changed.
It was very cool to know that when the world ends I can build a new computer, from scratch.
Relays are doable from scratch (mining and refining copper; winding coils, etc etc) but it's going to be pretty hard work and you're going to have a very slow computer at the end of it.
I honed mine early enough that the most I need from a program is a few Sprintf statements just to give the brain debugger some context when the application is dealing with external data or data transformation.
I personally find it hard to turn off the brain debugger and rely on software. Originally this was because you'd very much be used to the debugger being wrong. As in, "Ah, but in this case the debugger thinks X but Y is the case", and later just because the brain debugger had become so effective that not using it seemed like a lot of hard work for little extra gain.
How other programmers visualise or handle code in their brain, and how they put together new functionality in their head, is deeply fascinating. Even if you have self-awareness enough to grasp the basics of how you do it, you can be reasonably sure that each of us does it slightly differently.
Then I started writing for Android and the time between compilation, installation, running the app, and then reproducing the scenario was too long and a debugger was a godsend.
Anyway, anytime I think about what a pain in the ass writing, or even just typing out code can be, I refer to the chapter in iWoz in which, lacking development software at the time, he "wrote out the software [for Little Brick Out] with pen and paper and then hand assembled the instructions into 4096 bytes of raw machine code for the 6502"
http://en.wikipedia.org/wiki/Integer_BASIC
Would be fascinating to see it in an fMRI.
https://en.wikipedia.org/wiki/Graphomania
(#)https://github.com/lifeisstillgood/importantexperiments4kids
If you really want to re-enact the OP article, visit Briel Computers and get a Micro-KIM. Mine works perfectly. At the 2013 Midwest Gaming Classic someone (not me) was exhibiting an original KIM (as seen in the post) and a microKIM side by side in the retrocomputing room, which my family found entertaining because I also have one mounted on a wood plaque in my "office" area. How else are you going to display one?
I was always more of a Z80 guy... speaking of Z80 computers, one currently shipping project is the N8VEM CP/M SBC project which I found pretty trivial to assemble and use, not to forget the P112 SBC as recently seen on kickstarter.
Then there's my stack of FPGA devices ranging from the micronova mercury to my boring typical Spartan boards, which twists the borders of "real hardware" and emulation.
A link to the MicroKIM1
http://www.brielcomputers.com/wordpress/?cat=24
What always amuses me is that my computers from around 2000 are not working anymore (heck, most laptops I have from the past 10 years are not even booting anymore) while computers from my parents basement which are around 30 years old just work like they just came from the shop. Even the Philips computers from that time who had known capacitor issues in the power circuitry work like time didn't happen.
It's similar to those Radio Shack "3000 electronic experiments" boards that were sold in the 80s(?) and yet can scale with the kids' understanding.
Sure, it's not self-hosting, but I've noticed the physical connection to caps, resistors, diodes, etc. in a "safe" environment makes them more proud of their accomplishments than their html/css projects.
There's something called the Maximite, which is a single IC computer running BASIC with output to VGA and SD storage (http://geoffg.net/maximite.html)
There's something called 'petite computer' for Nintendo DS (http://www.petitcomputer.com/)
But it'd be great if someone started a hub for this kind of thing.
Mind you I've just got an Atari 65XE from ebay today which I will now have to explain to my wife (I always thought the Atari graphics was neat and wanted to play with the display list stuff but never did so at the time)
But what a neat feeling! There's something about putting in these numerical codes and seeing a graphical result that I haven't experienced since then. Yes, higher-level languages rock, but dang, this is coding next to the metal.
After learning a bit about logic gates and playing around with the theory, there was an incredible feeling of discovery. Somehow I had deciphered the code of computers, and was finally speaking their native language. This brought back great memories. Thank you.
This could probably be done with less than 50 lines in python, but doing it in assembly, calling all those interrupt routines, making sure your registers contained all the right values, man, when it finally worked, it was the greatest feeling in the world!
Then you realize it would take around 30 years, but still -- it was doable. You finally figured out how it all worked. You could make the computer do anything it was capable of doing. There was no more mystery there.
Fun stuff.
I mean, Chuck Moore has been doing it for about 30 years, but he had a working top-to-bottom system after less than five years.
Here's what I think it would look like:
Week 0: build a working interactive Forth system that can compile itself, in machine code. This is assuming you already have hardware and a way to boot it into some code you wrote. If not, that could be a matter of minutes or of months.
Weeks 1-3: build an interactive high-level language interpreter on top of it. Say, JS.
Week 4: enough of TCP/IP to do HTTP GET.
Week 5: write a bitmap font editor and a minimal filesystem.
Weeks 6-8: parse HTML (more or less), lay it out with a simplified box model, and draw it to pixels on a canvas, using a pixel font.
Week 9: cookies, HTTP POST, XMLHttpRequest.
Week 10: a more elaborate filesystem, maybe based on Git.
Weeks 11-12: some more HTML5 features, maybe including WebGL.
Weeks 13-14: TLS.
This is sort of cheating because you're taking advantage of our previous 70 years of experience to figure out what's worth building, and you're likely to end up spending a fair bit of time going back and retrofitting stuff onto previous iterations — JIT compilation, say, and multitasking — but it still seems like rebuilding the personal computing environment ought to be more like a one-semester project than a 30-year project.
You could argue that you get a huge speedup by not writing stuff in assembly, and I agree, but I think that's only a constant factor. You could easily write assembly code that maps directly onto JS semantics:
That's more code to write and read, but only by a linear factor. So it might take you two semesters, or four, but not 60.At 12 I had learned how to program, in Z80 assembly, a routine to output to the graphics card of my dad's ancient-even-then Radio Shack model 16. I created a custom font that looked like the beautiful VGA font and used it to render 16-bit numbers in gorgeous decimal digits.
Most of us still do. Especially while dealing in areas which are not familiar to us.
There is a finite and limited amount of complexity this allows for. We've been given quite the catch-22: the ability to build increasingly complex system while needing to maintain those increasingly complex systems.
On whatever project you are currently working on, how much less code do you think you'd be writing if you had to hand write it? Where would the project be better for it and where would it be worse?
Yeah, I know. Rose tinted and all that.
Two words: 'the web'.
Slightly longer: we're re-inventing the wheel through a very roundabout path, I think right now we've gone back in time to roughly the mainframe area, it won't be long before someone will invent the mini computer all over again only this time it will be a local cluster in a box. Next after that the PC, a 'personal cluster' with a few 100 nodes the size of the desktop machine you had last year.
Macintosh Common Lisp circa 1987: http://basalgangster.macgui.com/RetroMacComputing/The_Long_V..., specifically: http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...
Firebug circa 2013: http://getfirebug.com/logging, specifically http://getfirebug.com/img/logging/consoleDir.png
Oh well.
Now most programmers spend most of their time dealing with problems of persistence, networking, parallelism, security, and massive codebases. In response we are creating scripting languages with slightly different syntax, adding closures to Java, and arguing about vim vs emacs. We're so obsessed with solving the problems of the 80s, my way, that we've just gotten trapped there.