But, as an over-30 on HN, I'd be afraid that having the word "mainframe" on my resume would alienate a 20-something co-founder or hiring manager. :)
OK, OK, I did once do a little bit of mainframe-related work. It was reverse-engineering a small part of a certain domain-specific mainframe network protocol, with the goal of replacing at least one of the companies' mainframes with... 21st century Linux servers running... Lisp. (IMHO, the HN karma should at least balance out there by using Lisp, like the post did by using Rust.)
Writing a transpiler is easily the most boring and tedious job you can have, especially if the target or source language is useless (so you don't learn anything useful as a matter of course).
I once briefly worked on a transpiler from Windows .BAT ("batch script", going back to DOS) to C#. The reason we wanted this is because some part of the Windows build system was a huge pile of .BAT files plus some PowerShell. The .BAT files were so unpleasant to work with, that we figured it would be good to at least translate them to a language that is easier to understand.
We didn't learn anything "useful" except we got to understand things like the bizarre FOR construct for the first time.
I'm sure Raymond Chen could write an airtight argument why the batch scripting language HAD TO BE exactly the way it is, and there was no alternative to iterating over files and lists using the FOR command with its bizarre flags, but once he leaves the room, I'll go back to insisting that this is one of the most screwed up things that have ever been done with software, and it's a travesty that this was still being used to run the Windows build system at Microsoft in 2013.
Unlambda is a thoroughly useless language, but writing a compiler from any sane language to Unlambda would teach you a lot, including some useful things.
There are millions and millions of lines of old COBOL code. I’m surprised there isn’t a commercial “pluggable” transpiler product. Read in COBOL, output Java, Rust, Go… Many COBOL systems also have a lot of intelligence in the job stream order, and dependencies - so that needs to be converted too. This seems like a no-brainer to build a consulting practice and tools around. Oh, and the data has to be converted too.
gnu-cobol is likely what you're after (cloudflare even used it to demo their Worker platform) but my experience has been that the language isn't the nonsense it's the environmental that's horrific to port
Consider a hypothetical Python example:
import os
os.system("DIRECTORY ./SHELVED_STATE")
if you ported the python to C# it wouldn't suddenly work on Windows or Linux
I'm surprised modern languages haven't gone farther with base 10 numbers. C# has decimal (not sure how widely used that is) but what other language has built-in, non-library base 10 numbers?
Python has decimals for example as do many other languages. C# decimal is used everywhere currency is used (I really hope). But apart from currency... why would you use base 10? We've got native bigints in lots of languages so you don't even have to care how they're represented internally.
Not all decimal numbers have finite binary representations. 0.3, for example, is 0.010011 with a repeating block of 0011. For some business applications, you know you're being given a base 10 decimal of finite (but possibly very large) length.
Decimals are always represented in a way that preserves the exact value. That doesn't mean internally it needs to be stored in base10. There's lots of ways to achieve that.
Some countries don't have cents, some countries have 3 digits of cents. So, yes you can but you also then get thinking you can express everything as ints. But, the moment you need to convert from KWD to VND (84000.00:1) you could be at the edge of the size of a 64 bit int. Note: VND is pretty stable, when currencies start deflating the numbers can get crazy.
You're kind of asking why would anyone need decimal data, if they can implement their own decimal data with explicit decimal shifts around the codebase... The answer is - so they don't have to do it.
which defines a signed money value represented in decimal. If you print that value, it will be formatted as requested.
There are a few other formatting characters. A "CR" at the end will cause negative numbers to be printed with "CR" (Credit) at the end.
A "Z" causes lead zero suppression. "*" causes lead zeros to be replaced with asterisks, for check-writing.
Numeric display formatting is an attribute of the data.
That concept, and built-in support of money-like values, has been lost in later languages. In Rust you can have implicit Display or Debug functions for types, although it's mostly used for debugging.
I think it's uniformity. You have 9(n) all over the place, and only pay attention to the number in parentheses. It's more error-prone to count repeating characters, and it's easier (to me) to notice a typo in the form 9(4) instead of 9(3) than 9999 instead of 999.
This would be fun to work on.
But, as an over-30 on HN, I'd be afraid that having the word "mainframe" on my resume would alienate a 20-something co-founder or hiring manager. :)
OK, OK, I did once do a little bit of mainframe-related work. It was reverse-engineering a small part of a certain domain-specific mainframe network protocol, with the goal of replacing at least one of the companies' mainframes with... 21st century Linux servers running... Lisp. (IMHO, the HN karma should at least balance out there by using Lisp, like the post did by using Rust.)
Just say you worked on an on-prem private cloud.
Interesting. Looks like everyone on HN is getting interesting jobs left and right.
The most compiler-ish work I ever worked on is a yaml to yaml transpiler. I mean, yeah...at least I got to write some recursions.
Writing a transpiler is easily the most boring and tedious job you can have, especially if the target or source language is useless (so you don't learn anything useful as a matter of course).
I once briefly worked on a transpiler from Windows .BAT ("batch script", going back to DOS) to C#. The reason we wanted this is because some part of the Windows build system was a huge pile of .BAT files plus some PowerShell. The .BAT files were so unpleasant to work with, that we figured it would be good to at least translate them to a language that is easier to understand.
We didn't learn anything "useful" except we got to understand things like the bizarre FOR construct for the first time.
I'm sure Raymond Chen could write an airtight argument why the batch scripting language HAD TO BE exactly the way it is, and there was no alternative to iterating over files and lists using the FOR command with its bizarre flags, but once he leaves the room, I'll go back to insisting that this is one of the most screwed up things that have ever been done with software, and it's a travesty that this was still being used to run the Windows build system at Microsoft in 2013.
Unlambda is a thoroughly useless language, but writing a compiler from any sane language to Unlambda would teach you a lot, including some useful things.
There are millions and millions of lines of old COBOL code. I’m surprised there isn’t a commercial “pluggable” transpiler product. Read in COBOL, output Java, Rust, Go… Many COBOL systems also have a lot of intelligence in the job stream order, and dependencies - so that needs to be converted too. This seems like a no-brainer to build a consulting practice and tools around. Oh, and the data has to be converted too.
That exists. There are multiple vendors that have solutions to automatically transform COBOL code.
Deloitte, for example, has quite a big practice around Mainframe modernization with a toolsuite https://www2.deloitte.com/us/en/pages/consulting/topics/appl...
And AWS bought a company with such a toolsuite and offers it now as a service https://aws.amazon.com/de/mainframe-modernization/capabiliti...
gnu-cobol is likely what you're after (cloudflare even used it to demo their Worker platform) but my experience has been that the language isn't the nonsense it's the environmental that's horrific to port
Consider a hypothetical Python example:
if you ported the python to C# it wouldn't suddenly work on Windows or LinuxI'm surprised modern languages haven't gone farther with base 10 numbers. C# has decimal (not sure how widely used that is) but what other language has built-in, non-library base 10 numbers?
Python has decimals for example as do many other languages. C# decimal is used everywhere currency is used (I really hope). But apart from currency... why would you use base 10? We've got native bigints in lots of languages so you don't even have to care how they're represented internally.
Not all decimal numbers have finite binary representations. 0.3, for example, is 0.010011 with a repeating block of 0011. For some business applications, you know you're being given a base 10 decimal of finite (but possibly very large) length.
You can use an arbitrary length integer to store the number of cents? (Or whatever your smallest unit is.)
Many languages also have libraries (or standard libraries) for supporting arbitrary length and precision rational numbers.
Decimals are always represented in a way that preserves the exact value. That doesn't mean internally it needs to be stored in base10. There's lots of ways to achieve that.
I'm not quite sure why anyone would need a 'decimal' data type for currencies?
Couldn't you just express everything in eg cents, if you want that?
Otherwise, many languages also have libraries for working with exact rational numbers.
Some countries don't have cents, some countries have 3 digits of cents. So, yes you can but you also then get thinking you can express everything as ints. But, the moment you need to convert from KWD to VND (84000.00:1) you could be at the edge of the size of a 64 bit int. Note: VND is pretty stable, when currencies start deflating the numbers can get crazy.
Well, obviously you put the smallest unit in your integers.
Cents was just an example. Old British currency used to be even crazier than your example of a unit divided into 1,000.
> But, the moment you need to convert from KWD to VND (84000.00:1) you could be at the edge of the size of a 64 bit int.
So? You should use arbitrary length integers for that. Many languages have good support for them. Eg in Python they are the default integer you get.
You're kind of asking why would anyone need decimal data, if they can implement their own decimal data with explicit decimal shifts around the codebase... The answer is - so they don't have to do it.
The COBOL syntax for that looks like
which defines a signed money value represented in decimal. If you print that value, it will be formatted as requested.There are a few other formatting characters. A "CR" at the end will cause negative numbers to be printed with "CR" (Credit) at the end. A "Z" causes lead zero suppression. "*" causes lead zeros to be replaced with asterisks, for check-writing. Numeric display formatting is an attribute of the data.
That concept, and built-in support of money-like values, has been lost in later languages. In Rust you can have implicit Display or Debug functions for types, although it's mostly used for debugging.
Nice read but I don't get, and maybe someone here knows;
> 9(3) is shorthand for 999
I did some cobol work in the past and know 9(3) but you can write 999? And how is 4 chars shorthand for 3?
I think it's uniformity. You have 9(n) all over the place, and only pay attention to the number in parentheses. It's more error-prone to count repeating characters, and it's easier (to me) to notice a typo in the form 9(4) instead of 9(3) than 9999 instead of 999.
[flagged]
Cool, but that’s not what we’re discussing here. Submit it as a story if you want to have a conversation about it.