359 karma · joined August 18, 2011
I’ve seen firsthand how much frustration COBOL can cause. Many of my colleagues didn’t enjoy writing it, they stuck with it because it paid well, not because they loved the work. The language itself isn’t the hard part; it’s the decades of accumulated technical debt and the sheer complexity of the environment. Over time, these systems become so intertwined with business processes that untangling them feels impossible. But what if we approached it incrementally?
Imagine taking an existing COBOL codebase, say, for a large insurance system and identifying the core business logic buried within it. These are the rules and conditions that power critical operations, like calculating premiums or processing claims. Now, instead of trying to rewrite everything at once, you build a parallel backend in a modern language like Java or Go. You don’t aim for a literal translation of the COBOL code, you focus on replicating the functionality in a way that makes sense in a modern context. For example, replace hardcoded file operations with database calls, or screen based interactions with REST APIs.
Most mainframe customers already use middleware like MuleSoft or IBM Z/OS Connect to route requests to both systems simultaneously. For every write operation, you update both the mainframe’s DB2 database and a modern relational database like Postgres. For every read operation, you compare the results from both systems. If there’s a discrepancy, you flag it for investigation. Over time, as you handle more and more business scenarios, you’d start covering all the edge cases. This dual system approach lets you validate the new backend without risking critical operations.
Of course, this process isn’t without its struggles. Testing is a huge challenge because mainframe systems often rely on implicit behaviors that aren’t documented anywhere. My colleagues used to joke that the only way to understand some parts of the system was to run it and see what happened. That’s why rigorous testing and monitoring are essential you need to catch discrepancies early before they cause problems. There’s also the cultural side of things. People get attached to their mainframes, especially when they’ve been running reliably for decades. Convincing stakeholders to invest in a multi year migration effort requires strong leadership and a clear case for ROI.
But I think the effort is worth it. Moving off the mainframe isn’t just about saving money though that’s a big part of it. It’s about future proofing your organization. Mainframes are great at what they do, but they’re also a bottleneck when it comes to innovation. Want to integrate with a third party service? Good luck. Need to hire new developers? Most of them have never touched COBOL. By transitioning to a modern platform, you open up opportunities to innovate faster, integrate with other systems more easily, and attract talent who can actually work on your codebase.
In the end, this isn’t a quick fix it’s a long term strategy. But I believe it’s achievable if you take it step by step. Start small, validate constantly, and gradually build up to a full replacement. What do others think? Are there better ways to tackle this problem, or am I missing something obvious?
#Operator: - Operand 1 - Operand 2
The fact is that the node difference (7nm vs. 10nm) is critical here, SiFive’s area/power efficiency gains aren’t purely architectural but partly process-driven. Even with that advantage, matching a 2018 A75 (designed for mobile thermal/power limits) in 2024 feels like catching up to ARM’s rearview mirror. ARM’s A720 today benefits from years of iterative refinement (cache hierarchies, branch predictors, memory subsystems) that aren’t easily replicated overnight.
Scaling beyond cores is another hurdle, interconnects, memory controllers, and accelerators matter just as much as raw IPC. RISC-V’s ecosystem (tools, firmware, software optimization) also lags ARM’s, which could limit adoption even if the P550 were competitive.
SiFive’s claims highlight RISC-V’s potential, but until they benchmark against modern cores on the same node and demonstrate system-level competitiveness (not just microarchitecture wins), the gap will persist. That said, disruption takes time—ARM wasn’t born polished either. The real test is whether SiFive can close the maturity deficit before ARM’s roadmap (and AI-driven heterogeneity) leaves them behind. I doubt it, the GAP in GPU cores alone between Cortex and M Series is so huge, and then there are accelerators like NPU cores, which SiFive havent even started working on yet.
Even Cortex NPU's are behind Apple M Series, and if a large companies liek Samsung, Qualcomm, Mediatek lag behind Apple is Quality ARM chips with Decent GPU, NPU on Board memory, what hope does SiFive Have? At Worse Burn Investor money and die. At Best supply chips for your remote control, washing machine etc ... competing with mainstream applications would not be wise by any standards.
Buddhist caves with votive stupa: https://www.bandhavgarh-national-park.com/blog/buddhist-cave...
Nigallakonda https://www.alamy.com/view-of-ruin-of-ancient-group-of-stupa...
Votive stupas with faces of make and female bodhisattvas: https://en.wikipedia.org/wiki/Lingam#/media/File:4_Buddha_an... https://upload.wikimedia.org/wikipedia/commons/a/a4/1_Buddha...
Why Buddhas face on this claimed shivalinga: https://www.nortonsimon.org/art/detail/F.1972.11.2.S
https://en.wikipedia.org/wiki/Mukhalinga#/media/File:Five_He... https://www.civilsdaily.com/wp-content/uploads/2016/12/macin... https://en.wikipedia.org/wiki/Mukhalinga#/media/File:Five_He... https://upload.wikimedia.org/wikipedia/commons/4/4e/025_Shiv...
Claimed as shivalinga, can you explain why the buddhas hand mudra: https://static.india.com/wp-content/uploads/2023/05/Nepal-1....
Who are these characters 2 males and one female? https://i.pinimg.com/736x/08/00/fc/0800fc34453462c46a78dc99f...
Is this shivas face on his own phallus? https://www.metmuseum.org/art/collection/search/38242
Broken votive stupa at the same Kapilvastu buddhist site : https://upload.wikimedia.org/wikipedia/commons/4/42/Shiva_Li...
Large Stupas , Dhamek Stupa
https://upload.wikimedia.org/wikipedia/commons/7/7d/Dhamekh_...
Stupas on teh Sanchi Hill: https://asearchformore.wordpress.com/2014/11/12/stupas-on-th...
Other votive stupas: https://framemark.vam.ac.uk/collections/2006AM4892/full/1400...
https://www.vajiramias.com/current-affairs/what-is-a-votive-...
https://www.istockphoto.com/photo/votive-stupas-in-bhaja-cav...
https://en.wikipedia.org/wiki/Lenyadri#/media/File:Lenyadri_...
https://www.istockphoto.com/photo/votive-stupas-in-bhaja-cav...
https://i.ytimg.com/vi/ypB5i7VGArQ/oar2.jpg
https://www.alamy.com/votive-stupa-with-four-buddhas-culture...
Votive stupas inside Ranpur Buddhist caves are being claimed as shivas phallus: https://youtu.be/3vzGBxjG9E8
Forced occupation of the cave by claiming a wall to be Ganesha: https://youtu.be/ypB5i7VGArQ
Bhadrakali Temple Itkhori stupa worshipped as shivalinga: https://youtu.be/O22bc_UIxt0
Tara devi converted to Hindu godess: https://youtu.be/6-FHiEA--x4
The list goes on and on because brahman Dharma (Hinduism) had no sculpture art, it is banned in it. India is full of buddhist art with votive stupas having multiple faces of either Buddha or Bodhisattvas. Brahminism doesnt have sculpture infact it is banned in many texts, nor do they have any description of their gods. Shiva doesnt even exist in Vedas. The character Rudra being claimed as Shiva in Vedas is the god of Thunder storms in vedas. Most of all if it is such an important god why cut write a story of its penis cut by another lowly god of the vedas? The sculpture speaks for itself.