6 ms·

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

by avgDev 7y ago

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.

larrik 7y ago
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 7y ago
  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 7y ago
    Yeah, these guys didn't really know COBOL either. They used RPG (an AS/400 exclusive language).
    - rswail 7y ago
      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 7y ago
        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 7y ago
  Is there any resources you could recommend? I would interested in maybe learning more.
  - larrik 7y ago
    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 7y ago
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.
- jdsully 7y ago
  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 7y ago
  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 7y ago
    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.
rswail 7y ago
> 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.

by avgDev 7y ago

larrik 7y ago

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 7y ago
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 7y ago
  Yeah, these guys didn't really know COBOL either. They used RPG (an AS/400 exclusive language).
  - rswail 7y ago
    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 7y ago
      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 7y ago
Is there any resources you could recommend? I would interested in maybe learning more.
- larrik 7y ago
  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 7y ago

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.

jdsully 7y ago
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 7y ago
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 7y ago
  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.

rswail 7y ago

> 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.