12 ms·

The biggest problem is they have engineers who have turned their hands to programming, one would expect, without the formal training and so have latched onto va

The biggest problem is they have engineers who have turned their hands to programming, one would expect, without the formal training and so have latched onto various antipatterns without knowing any better because Pascal allowed them to get away with it - painting themselves into a corner. He mentioned an awful lot of code that would have to be refactored, and it could be that they are just too far down the rabbit hole to get themselves out.

fsloth 8y ago
I have a hunch the majority of domain specific engineering products are at least initially implemented by engineers of the domain and not software engineers.
walshemj 8y ago
Very strange in a hardcore technical programming context, I would have thought they would have used Fortran which is still being actively developed. I have never seen a reasoned argument why C++ vs Fortran is better for technical programming.
scj 8y ago
In this case, I'd look into compiling the existing code into .dll/.so files, and just linking between Extended Pascal and ${NEW_LANGUAGE}. Then, convert the code to ${NEW_LANGUAGE} as needed, if needed. That solution is probably the lowest cost / safest course... Assuming the Extended Pascal compiler they have supports it. But I suspect choosing D was a fait accompli.
- Skunkleton 8y ago
  This approach has always been the one that makes the most sense to me, but yet it also seems to be rare. I couldn't explain why.
- _veelo 8y ago
  This is the approach I took to modernise Fairway (which is just one component of our suite). It doesn't free us from the limitations of the Extended Pascal compiler. It still works, but we want a way out.
  - scj 8y ago
    Hello, I assume by your username that you're the author! Transpiling is normally a little risky. Transpiling with a custom transpiler over ~500KLOC is downright terrifying. I'd be concerned that the cure is worse than the disease. I understand the allure of this solution. Bringing 30ish years of code into the modern era with a single piece of code sounds like a huge win. But you owe it to your employer (who seems really gracious and trusting) to ask: 1. Are there edge cases? Programmers are a clever bunch, and you can never be too sure about what features/bugs they've used/abused! 2. How will success of the transpile be determined? I'd use unit tests, but that'd take a lot of unit tests! 3. What % of that code path is critical? Can you get away with ensuring the functionality of a subset of the codebase? If so, could you just manually port that? 4. "Blaming the compiler" will be a reasonable excuse for any problem over the next year or two after deployment. I guarantee you'll be spending time proving that other peoples' mistakes are not your fault. How much flak are you and your boss going to take for this? 5. Since the code can be linked, might a more popular language (that will be known by a wider community) with a slow porting plan be reasonable? 6. Python is commonly used with scientific computing. Why does this case preclude it? If you are doing mostly numeric processing, that gets directly passed to the hardware anyway! You have been given a rare chance to pay down technical debt. From what I understand of your solution, I believe the bespoke transpiler and semi-known language will ultimately increase it. And I know you love D, but if I were brought in as a consultant, I'd be recommending the .dll/.so solution with Python. If something is really time sensitive, use Python binding to work with other languages (avoiding premature optimization). Even if myself or my fellow posters made a point that resonated, it might be too late for such discussions. I can't weigh the political costs for changing strategy now. So I'll wish you good luck, and hope that Extended Python doesn't have too many sharp edges for you to contend with. I hope to see a postmortem a few years from now detailing the outcome of this plan.
    - blub 8y ago
      Python has two big issues: performance and dynamic typing. The solution of using a HLL and dropping down to C for performance strikes me as overly optimistic: the only language where one can legitimately claim that it's pleasant to use C for extra performance is Objective-C. Anything else will be different degrees of painful. I didn't get the solution of using a dynamic lib and calling/extending that from Python. One would end up with 500kloc of Pascal and a Python one liner. All the work still happens in Pascal.
noir_lord 8y ago
Given they started in the 80's Pascal probably has fewer corners to paint oneself into then many languages then (and now probably).
- _veelo 8y ago
  Indeed!
52-6F-62 8y ago
To be fair, I work with a large number of formally trained engineers who commit far worse in terms of anti-pattern and data hygiene infractions on the regular and I’ve had the fortune of refactoring their messes. I don’t think it’s solely dependent on having afforded formal training. Knowing enough to know that you might not know and just might need to measure or look something up and caring enough to do so is more of the core of it.

fsloth 8y ago

I have a hunch the majority of domain specific engineering products are at least initially implemented by engineers of the domain and not software engineers.

walshemj 8y ago

Very strange in a hardcore technical programming context, I would have thought they would have used Fortran which is still being actively developed. I have never seen a reasoned argument why C++ vs Fortran is better for technical programming.

scj 8y ago

In this case, I'd look into compiling the existing code into .dll/.so files, and just linking between Extended Pascal and ${NEW_LANGUAGE}. Then, convert the code to ${NEW_LANGUAGE} as needed, if needed. That solution is probably the lowest cost / safest course... Assuming the Extended Pascal compiler they have supports it. But I suspect choosing D was a fait accompli.

Skunkleton 8y ago
This approach has always been the one that makes the most sense to me, but yet it also seems to be rare. I couldn't explain why.
_veelo 8y ago
This is the approach I took to modernise Fairway (which is just one component of our suite). It doesn't free us from the limitations of the Extended Pascal compiler. It still works, but we want a way out.
- scj 8y ago
  Hello, I assume by your username that you're the author! Transpiling is normally a little risky. Transpiling with a custom transpiler over ~500KLOC is downright terrifying. I'd be concerned that the cure is worse than the disease. I understand the allure of this solution. Bringing 30ish years of code into the modern era with a single piece of code sounds like a huge win. But you owe it to your employer (who seems really gracious and trusting) to ask: 1. Are there edge cases? Programmers are a clever bunch, and you can never be too sure about what features/bugs they've used/abused! 2. How will success of the transpile be determined? I'd use unit tests, but that'd take a lot of unit tests! 3. What % of that code path is critical? Can you get away with ensuring the functionality of a subset of the codebase? If so, could you just manually port that? 4. "Blaming the compiler" will be a reasonable excuse for any problem over the next year or two after deployment. I guarantee you'll be spending time proving that other peoples' mistakes are not your fault. How much flak are you and your boss going to take for this? 5. Since the code can be linked, might a more popular language (that will be known by a wider community) with a slow porting plan be reasonable? 6. Python is commonly used with scientific computing. Why does this case preclude it? If you are doing mostly numeric processing, that gets directly passed to the hardware anyway! You have been given a rare chance to pay down technical debt. From what I understand of your solution, I believe the bespoke transpiler and semi-known language will ultimately increase it. And I know you love D, but if I were brought in as a consultant, I'd be recommending the .dll/.so solution with Python. If something is really time sensitive, use Python binding to work with other languages (avoiding premature optimization). Even if myself or my fellow posters made a point that resonated, it might be too late for such discussions. I can't weigh the political costs for changing strategy now. So I'll wish you good luck, and hope that Extended Python doesn't have too many sharp edges for you to contend with. I hope to see a postmortem a few years from now detailing the outcome of this plan.
  - blub 8y ago
    Python has two big issues: performance and dynamic typing. The solution of using a HLL and dropping down to C for performance strikes me as overly optimistic: the only language where one can legitimately claim that it's pleasant to use C for extra performance is Objective-C. Anything else will be different degrees of painful. I didn't get the solution of using a dynamic lib and calling/extending that from Python. One would end up with 500kloc of Pascal and a Python one liner. All the work still happens in Pascal.

noir_lord 8y ago

Given they started in the 80's Pascal probably has fewer corners to paint oneself into then many languages then (and now probably).

_veelo 8y ago
Indeed!

52-6F-62 8y ago

To be fair, I work with a large number of formally trained engineers who commit far worse in terms of anti-pattern and data hygiene infractions on the regular and I’ve had the fortune of refactoring their messes. I don’t think it’s solely dependent on having afforded formal training. Knowing enough to know that you might not know and just might need to measure or look something up and caring enough to do so is more of the core of it.