[avgDev]

I am currently rewriting a 10 year old VB application, which is in web forms. That application communicates with AS400 DB2 database. I get to use as400 here and there.

My application is in .NET Core 2. There are some issues as anything IBM can be a pain in the ass to work with. Also, the as400 dev and me have a tremendous knowledge gap. I know everything new such as unit testing, proper source control, dependency injection, linq and ORM tools. However, when it comes to speed of queries he is much better at optimization. Since, he has worked with some ancient languages he has a better understanding of low-level programming.

Honestly, it is pretty interesting at what speeds the current tools allow us to develop applications. For example, he would need to set up the DB, then security, then applications, stored procedures, map parameters in code and so on. I can accomplish most of these things with an ORM like Entity Framework in less than an hour and have a working project, obviously depending on the scale of it. However, both approaches have pros and cons.

Having old legacy code is problematic. It is harder and harder to find developers and rates are going up as the BIG fish still rely on them and can pay more.

[rswail]

> I know everything new such as unit testing, proper source control, dependency injection, linq and ORM tools. However, when it comes to speed of queries he is much better at optimization.

The reason he is better at optimization is because he is not using an ORM. ORMs are a leaky abstraction that loses the power of SQL for the limited benefit of slightly easier programming. They also tend to move things that in SQL would be a JOIN that is executed in the database back into code.

Data is not an object, much that some "modern" languages would prefer to lose the distinction, with ORMs and DTOs obfuscating it.

RDMSs are based on cohesive logic (set theory) and have been tuned and optimized by people to do the best possible automation of data storage and retrieval, while abstracting the very low level.

ORMs on the other hand, take the logic that should be at the data management level, including invariants and moves it into code that does what SQL does, but slowly and badly.

[larrik]

I worked at an AS/400 shop out of college (this was in the 2000's, though). The other programmers there did NOT have a better understanding of low-level programming than me. In fact, it was hard to call them programmers at all.

[yellowapple]

Yeah, a lot of AS/400 programming is actually pretty high-level (comparatively speaking). COBOL in general was meant to be accessible to end users (or at most power users) such that they could readily define business logic without having to resort to something like assembly or PL/I or what have you.

[larrik]

Yeah, these guys didn't really know COBOL either. They used RPG (an AS/400 exclusive language).

[rswail]

RPG is more like throwing random characters on a screen and seeing what happens.

Report Generator (RPG) is designed for an 80 column punch card. Put a F in column 6 to mean this, put a "C" to mean something else, match one of the 99 variables (named, intuitively 01 through 99) to make output happen.

I had the distinct displeasure in 1984 of trying to maintain a warehouse stock control system that some evil people had decided to implement in RPG. From memory, RPG only has the equivalent of single dimensioned arrays, so the location of items in the warehouse was an intersection of three arrays pointing to yet another array containing the SKUs.

It's designed to take one or more input files with defined columns in each row (card) and do some stuff (mostly subtotalling etc) and produce output.

Of course, it's been stretched beyond all recognition since it was introduced in 1959. It's literally 60 years old this year.

[larrik]

Yup, though we technically used RPGLE which was slightly better. It also had a "free text mode" which looked a bit more like a real language, but my coworkers were terrified of that.

[avgDev]

Is there any resources you could recommend? I would interested in maybe learning more.

[larrik]

What are you looking to learn more about?

When I learned RPG, it was through physical audio tapes. In 2005, with broadband. I haven't come across to many good places to learn from (but I haven't really been looking, either).

[mattmanser]

Having been someone who's had to "setup" the db, app, etc. before ORMs were mainstream, you're wildly overestimating how complicated it was. It doesn't actually take very long, you'd maybe save a couple of days or so on a month project, having to write a a CREATE TABLE and then the corresponding class are actually trivial. You make the design decisions when you write the create statement, the class is simply a copy of it.

It's just a bit easier, not a lot. I certainly use ORMs now, but it's a convenience rather than a revolution. The truly revolutionary thing for code from that era of C# were lambda expressions.

In all honesty, he's an idiot for not updating his skills. If he simply learnt a bit of modern EF and learnt how to use git, he'd run rings around you. I'd note that "proper" source control practice has been around for well over a decade now (SVN was adequate, just not great for distributed teams), so he must be really adverse to change.

The unit testing and DI, on the other hand, is all pretty useless noise in a statically typed language like C#, for all MS push it. The only benefit in DI is keeping the same instance of the EF around, and it's pretty hard to actually get that working properly through-out the entire stack when you want to do anything even remotely creative.

As for unit testing, never seen the benefit. I took over a project with something like 50% unit test coverage that I never bothered to keep up, in 3 years the existing tests caught 1 bug.

All that highlighted to me that it was an utter waste of time and money it was writing all those tests.

[rswail]

Source code control has been around since SCCS in the early 80s (although wikipedia says 1977), it begat RCS which begat CVS, which begat SVN.

People have been using source code control since then, but the history of computing is of wheel reinvention and not-invented-here, so we are condemned to rediscover things.

Unit testing is useful for business logic, not for individual functions. If you're writing unit tests around whether or not you go outside an array bound, then you're testing the wrong thing. If, on the other hand, you're making sure that someone under 13 can't signup for a service, that's a reasonable unit test.

DI can be useful for running code, allowing you to instrument the code to identify problems. But that's runtime DI, not compile/deployment time.

As a design pattern, it's more an abstraction / reduction of general parameterized polymorphism, usually dragging in an opinionated framework that requires you to follow a set pattern of development and deployment.

[zadokshi]

100% test coverage is not so valuable. But, I would argue that test coverage for the bits of complex logic that people are “afraid to touch for fear of breaking it” are valuable. Create tests for this code before you change it for assurance you haven’t broken it. If there are weird border cases the original developer wants to ensure remain supported, you need a test case for it.

[jdsully]

A decade of source control is an understatement. If you weren’t using it in the 2000s you were woefully behind. In the 90s it was exotic and terrible though. Even Microsoft had a horrendous system called SLM (or slime for short).

[avgDev]

Interesting perspective. I do agree that it is not good that he did not keep updating his skills but he has a few clients even bigger than us and is going to retire soon, AS400 has served him very well.

[mattmanser]

I've met programmers who've done the same thing (for COBOL).

I personally would not enjoy it as all you end up doing is maintenance and working with nasty old code bases.