Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: COBOL devs, how are AI coding affecting your work?

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 190 posts

Re: Ask HN: COBOL devs, how are AI coding affecting your work?

#61

Post by xandrius »

hmaxwell wrote: post #50
edarchis wrote: post #6

Not COBOL but I sometimes have to maintain a large ColdFusion app. The early LLMs were pretty bad at it but these days, I can let AI write code and I "just" review it. I've also used AI to convert a really old legacy app to something more modern. It works surprisingly well.

I feel like people who can't get AI to write production ready code are really bad at describing what they want done. The problem is that people want an LLM to one shot GTA6. When the average software developer prompts an LLM they expect 1) absolutely safe code 2) optimized/performant code 3) production ready code without even putting the requirements on credential/session handling. You need to prompt it like it's an…

Exactly this. Not sure what code other people who post here are writing but it cannot always and only be bleeding edge, fringe and incredible code. They don't seem to be able to get modern LLMs to produce decent/good code in Go or Rust, while I can prototype a new ESP32 which I've never seen fully in Rust and it can manage to solve even some edge cases which I can't find answers on dedicated forums.

Re: Ask HN: COBOL devs, how are AI coding affecting your work?

#62

Post by krupan »

tjwebbnorfolk wrote: post #58
krupan wrote: post #28

Earlier quoted context omitted.

Compiling high level languages to assembly is a deterministic procedure. You write a program using a small well defined language (relative to natural language every programming language is tiny and extremely well defined). The same input to the same compiler will get you the same output every time. LLMs are nothing like a compiler.

Except for COBOL, which is famously not a turing-complete language. So certain guesses have to be made.

But the compiler doesn't "roll the dice" when making those guesses! Compile the same code with the same compiler and you get the same result repeatedly.

Re: Ask HN: COBOL devs, how are AI coding affecting your work?

#63

Post by rramadass »

elzbardico wrote: post #46
rramadass wrote: post #29

Earlier quoted context omitted.

Both Fortran and COBOL will be here long after many of the current languages have disappeared. They are unique to their domains viz. Fortran for Scientific Computing and COBOL for Business Data Processing with a huge amount of installed code-base much of it for critical systems.

Don't know about COBOL, but FORTRAN and Ada definitely would survive an Extinction Level Event on earth. Plenty of space based stuff running Ada and maybe some FORTRAN.

The key to understanding their longevity lies in the fact that they were the earliest high-level languages invented at a time when all software was built for serious long-lived stuff viz. Banking, Insurance, Finance, Simulations, Numerical Analysis, Embedded etc. Computing was strictly Science/Mathematics/Business and so a lot of very smart domain experts and programmers built systems to last from the ground up.

Re: Ask HN: COBOL devs, how are AI coding affecting your work?

#64

Post by pjmlp »

krupan wrote: post #60
pjmlp wrote: post #34

Earlier quoted context omitted.

If we ignore optimizing compilers and UB. "Project the need 30 years out and imagine what might be possible in the context of the exponential curves" -- Alan Kay

Is there any compiler that "rolls the dice" when it comes to optimizations? Like, if you compile the exact same code with the exact same compiler multiple times you'll get different assembly? And th Alan Kay quote is great but does not apply here at all? I'm pointing out how silly it is to compare LLMs to compilers. That's all.

Rolling the dice is accomplished by mixing optimizations flags, PGO data and what parts of the CPU get used.

Or by using a managed language with dynamic compiler (aka JIT) and GC. They are also not deterministic when executed, and what outcome gets produced, it is all based on heuristics and measured probabilities.

Yes, the quote does apply because many cannot grasp the idea of how technology looks beyond today.

Re: Ask HN: COBOL devs, how are AI coding affecting your work?

#67

Post by hnlmorg »

tjwebbnorfolk wrote: post #57
hnlmorg wrote: post #49

Earlier quoted context omitted.

Whilst I agree with your point, I think what sometimes gets lost in these conversations is that reviewing code thoroughly is harder than writing code. Personally, and I’m not trying to speak for everyone here, I found it took me just as long to review AI output as it would have taken to write that code myself. There have been some exceptions to that rule. But those exceptions have generally been in domains I’m unfami…

I think the point is in a banking context, every line of code gets reviewed thoroughly anyway.

I’d expect every line of code to get reviewed in any organisation.

The difference with AI is that the “prompt engineer” reviews the output, and then the code gets peer reviewed like usual from someone else too.

Re: Ask HN: COBOL devs, how are AI coding affecting your work?

#68

Post by dmux »

hmaxwell wrote: post #50
edarchis wrote: post #6

Not COBOL but I sometimes have to maintain a large ColdFusion app. The early LLMs were pretty bad at it but these days, I can let AI write code and I "just" review it. I've also used AI to convert a really old legacy app to something more modern. It works surprisingly well.

I feel like people who can't get AI to write production ready code are really bad at describing what they want done. The problem is that people want an LLM to one shot GTA6. When the average software developer prompts an LLM they expect 1) absolutely safe code 2) optimized/performant code 3) production ready code without even putting the requirements on credential/session handling. You need to prompt it like it's an…

I’ve found LLMs to be severely underwhelming. A week or two ago I tried having both Gemini3 and GPT Codex refactor a simple Ruby class hierarchy and neither could even identify the classes that inherited from the class I wanted removed. Severely underwhelming. Describing what was wanted here boils down to minima language and they both failed.

Re: Ask HN: COBOL devs, how are AI coding affecting your work?

#69

Post by TZubiri »

Quothling wrote: post #45
deaddodo wrote: post #22

Earlier quoted context omitted.

AI isn’t particularly great with C, Zig, or Rust either in my experience. It can certainly help with snippets of code and elucidate complex bitwise mathematics, and I’ll use it for those tedious tasks. And it’s a great research assistant, helping with referencing documentation. However, it’s gotten things wrong enough times that I’ve just lost trust in its ability to give me code I can’t review and confirm at a glanc…

AI is pretty bad at Python and Go as well. It depends a lot on who uses it though. We have a lot of non-developers who make things work with Python. A lot of it will never need a developer because it being bad doesn't matter for what it does. Some of it needs to be basically rewritten from scratch. Over all I think it's fine. I do love AI for writing yaml and bicep. I mean, it's completely terrible unless you prompt…

Cgpt is built on python (training and finetuning priority), and uses it as a tool call.

Python is as good as output language as you are going to get.

Re: Ask HN: COBOL devs, how are AI coding affecting your work?

#70

Post by shevy-java »

icedchai wrote: post #51
lopezb wrote: post #42

Earlier quoted context omitted.

I can't comment on Zig and Rust, but C is one of the languages in which LLMs are best, in my opinion. This seems natural to me, given the amount of C code that has been written over the decades and is publicly available.

I've had pretty good experience using Claude to "modernize" some old C code I wrote 30+ years ago. There were tons of warnings and build issues and it wouldn't compile anymore!

Sounds like rubocop though. I used that years ago to update an old legacy ruby codebase. Is that still AI?
Post reply on HN