Does the OP even know what made COBOL successful and useful ? Or for that matter , does the OP even know a Cobol programmer ? I suspect the answer is no and yet his blog is being discussed on HN front page. Cobol predates the RDBMS and made a lot of sense when writing structured data to flat file systems. Cobol language and cobol programmers never aspired to do a general purpose computing. Back in those days, the sci…
Java is the COBOL of my generation and Go is its successor
51–60 of 96 posts
Re: Java is the COBOL of my generation and Go is its successor
#52Does the OP even know what made COBOL successful and useful ? Or for that matter , does the OP even know a Cobol programmer ? I suspect the answer is no and yet his blog is being discussed on HN front page. Cobol predates the RDBMS and made a lot of sense when writing structured data to flat file systems. Cobol language and cobol programmers never aspired to do a general purpose computing. Back in those days, the sci…
New programmers who don't want to learn old technologies to maintain existing code bases will most likely want to replace it with something they know. It's almost always a very bad idea. All of these "x is the future" articles show a huge lack of perspective on what made languages successful in the first place and why they're still in use today.
Not because it was or is the best tool, not because it's the most efficient or the most performant or most readable, but because simple mundane politics and FUD.
Re: Java is the COBOL of my generation and Go is its successor
#53Jesus, I hope not. Go now is like Java in 1997. A mediocre language with lots of corporate support and a big standard library. It's popular in the developer crowd right now because it's A)simple B)has a good standard library and C)getting support (in the forms of tools, tutorials, etc.) is easy. We shouldn't let those things be the deciding factors in choosing what language to stick with over the next ten or twenty y…
Even a seasoned Haskell programmer like Erik Meijer has a more nuanced view on the topic than you: https://www.youtube.com/watch?v=on5DeUyWDqI&t=23m40s
> you can't extend important built-ins like range or make()
This was a deliberate design decision. When the Go team was asked about what they like about Go one answer was:
"It's very simple to understand, and the code that I read on the page is the code that is executed.
When I iterate over a slice, there's not some chance that there's an iterator implementation that fetches a file from a web server in Romania and serves me some JSON or something.
Instead, the language is very deliberately simple and contained so that it's very easy to reason about code that you're reading." https://www.youtube.com/watch?v=sln-gJaURzk
Re: Java is the COBOL of my generation and Go is its successor
#54COBOL is like bedbugs. Nobody likes COBOL; the reason it sticks around is because it's damn near impossible to get rid of. COBOL is very hard to migrate out of production because it's incredibly difficult to translate COBOL code to other languages. Everyone writes their own version of their COBOL, and even translating one COBOL program to another COBOL programmer's "dialect" is non-trivial. COBOL provides all the pow…
The reason it sticks around is because lots of enterprises either have mission critical code that works well in it and still has the same requirements (leaving no reason to replace it) -- or because poorly documented and tightly coupled code-bases makes it impossible to smoothly transition to something new. Often a combination of the two.
Re: Java is the COBOL of my generation and Go is its successor
#55Jesus, I hope not. Go now is like Java in 1997. A mediocre language with lots of corporate support and a big standard library. It's popular in the developer crowd right now because it's A)simple B)has a good standard library and C)getting support (in the forms of tools, tutorials, etc.) is easy. We shouldn't let those things be the deciding factors in choosing what language to stick with over the next ten or twenty y…
You forgot to mention the Go ABI which isn't even compatible with C. That alone for me is reason enough not to use it as a systems programming language.
I would choose D over Go any day of the week. It's longer to learn and master, sure, but it is also much more powerful and expressive.
Re: Java is the COBOL of my generation and Go is its successor
#56COBOL is like bedbugs. Nobody likes COBOL; the reason it sticks around is because it's damn near impossible to get rid of. COBOL is very hard to migrate out of production because it's incredibly difficult to translate COBOL code to other languages. Everyone writes their own version of their COBOL, and even translating one COBOL program to another COBOL programmer's "dialect" is non-trivial. COBOL provides all the pow…
Funny you mention it... almost replied to the post earlier saying that if I were to bet my career on a single language it would certainly be COBOL. Not glamorous, but it runs critical infrastructure and schools aren't exactly pumping out mainframe programmers. That said, I have not and would not recommend betting on a single language. Being polyglot has its own advantages. edit: any ideas for a first project with Go?…
Re: Java is the COBOL of my generation and Go is its successor
#57Earlier quoted context omitted.
New programmers who don't want to learn old technologies to maintain existing code bases will most likely want to replace it with something they know. It's almost always a very bad idea. All of these "x is the future" articles show a huge lack of perspective on what made languages successful in the first place and why they're still in use today.
Often the "why they're still in use today" when describing legacy tech can be described as a combination of fear of change, lack of resources, and technical debt (the result of both of those things). Not because it was or is the best tool, not because it's the most efficient or the most performant or most readable, but because simple mundane politics and FUD.
Most legacy projects I've worked with were not that hard and costly to maintain. Rewriting these code bases would definitely cost more than what would be saved afterwards.
Re: Java is the COBOL of my generation and Go is its successor
#58Re: Java is the COBOL of my generation and Go is its successor
#59Earlier quoted context omitted.
I think you're missing the point of the basic type system: simplicity. It's a bigger win than you think when it comes to attracting new developers and making code easier to read. Sure, there are languages that let you write more succinct code and support all sorts of crazy typing, but one of the things good code requires is readability. Your code my be terse and elegant, but if other people can't understand it, it wo…
I think you're missing the point of the basic type system: simplicity. It's a bigger win than you think when it comes to attracting new developers ...and that brings us full-circle to the blog post: rounding the corners so that the developers don't cut themselves and avoiding ideas that require developers to get out of their comfort-zones is exactly what made Java so successful. It put OO within the reach of mortals…
I look forward to the next wave of off-shoring Go projects then.
Re: Java is the COBOL of my generation and Go is its successor
#60Sigh. We're still banging rocks together and amazed when occasionally there is a spark? Look, Ruby and Python -- their implementations just plain suck. There, I said it. MRI and CPython are just a pile of crap. We've known since 1991-ish (see Self) how to make performant runtimes for dynamic languages and 23 years later Ruby and Python still have crappy slow interpreters with no useful concurrency support. Note that…
What language created in the last 5 years has a feature that wasn't originally discovered in the 80s or earlier? It's all too easy to bash new languages for not having some hot new, never before seen feature, meanwhile there are almost no examples of new languages doing earth shattering things. I think what we're currently seeing with Go, Rust, Elixir and others is taking the features that are perceived as good as tr…