A libertarian socialist engineer solves the financial crisis  - <AUTHOR> http://sepwww.stanford.edu/sep/jon/financialcrisis.html

<comment><USER2> So, lawyers and economists are corruptable but engineers aren't?

The only difference between this and a crackpot is that the domain is stanford.edu and not geocities.com.

There's so much wrong here that I can't even figure out where to begin. Most points are based on distorted facts, contains fallacies, ignores realities, and so on.

There are some reasonable ideas (standardized mortgages) that I've heard elsewhere, but a lot of it is crap.

#1 fixes what, exactly?

#2 is reasonable.

#3 is just ranting about credit cards. the fees may be egregious but someone does need to get paid to run the machinery. of course, it should be a fixed cost per transaction and the machinery should be less complicated. but it's not related to the actual crisis.

#4 just moves the problem.

#5 is just painful.

#7 are you kidding?

#8 is just silly. and I work there.

#9 is more pain.

#10 is not the problem either. It's that there's multiple processes. It was leverage and VAR that hurt, not the raw gaussian mis-approximation (although it didn't help.) The markets are gaussian (well, GARCH) short-term, but the regime shifts and changes are the output of another process.

A more reasonable solution going forward is going to be a) transparency in financial instruments for consumers, b) strict guidelines about new kinds of financial instruments, and c) leverage restrictions on financial organizations.

I think that simultaneous failures of other industries due to lack or loss of flexibility will have to be dealt with in different ways.

<comment><USER3> It's harder to be corrupt if you have to argue technically why your decisions will improve the economy.

Engineers and Scientists value the truth, whereas Lawyers value a convincing argument whether it is true or not. Think about their jobs: you can't convince reality you're right, but you can convince a jury.

I think you'd find it much harder to create feedback models of the economy which just happen to predict the best thing to do is to "Give Goldman Sachs a bonus to fix the economy", than it is to come up with some unprovable scare- mongering which terrifies the politicians into doing just that.

So yes, engineers or scientists would probably be more trustworthy running the economy as long as they stay true to the discipline.

<comment><USER4> "Scientific" government is what produced the USSR and is currently operating in China. There is even a word for it: technocracy.

People who think they know best for everyone else need to be kept far away from real power, whatever their political flavour.

<comment><AUTHOR> There's another way of being "scientific" when it comes to policy. Instead of having a bunch of crooks in positions of power deciding for everyone, why not have the government designing markets and institutions that work, leaving the decision-making for the people?

The scientific approach to government should not be the USSR over- centralization. It should be intelligent design. Create the incentives, set the rules, and step back when the games begin.

</comment></comment></comment></comment><comment><USER5> _New tax bracket, 90% tax bracket for anyone making more than the president of the USA -- retroactive two years. Rates were higher than that in 1963 (historical rates)._

Bad idea. Besides being in very poor form (changing the rules after the fact), retroactive taxes will snare people who made perfectly reasonable financial decisions given the rules at the time, but would now find that they don't even have the money to pay their (retroactive) taxes.

As for 90% taxes on high income, I'd prefer that they simplified the tax code and got rid of loopholes.

<comment><USER6> They tried that in the UK in the 70s. Paul Graham mentions it in one of his articles. It just serves to drive wealthy and ambitious people overseas or to spend a lot of time and money looking for loopholes. The net result is that the size of your "economic pie" gets smaller and smaller.

</comment></comment><comment><USER6> You can't be a libertarian and a socialist at the same time. Libertarianism is against coercion whereas socialism (excepting voluntary socialism - eg hippy communes) is a forced system of banning voluntary trade.

<comment><USER7> <http://en.wikipedia.org/wiki/Libertarian_socialism>

<comment><USER6> Doesn't seem to answer the paradox of who will enforce the socialism in a libertarian society. What if in this society you want to share my wealth but I don't?

</comment></comment></comment><comment><USER8> I really hate to be "that guy", but his incomplete sentences are killing me.

</comment><comment><USER9> The 90% tax bracket is too much, that actually does make people not want to work. 65-70% would be better, or just actually closing all of the tax loopholes.

<comment><USER8> I think the sensible option is to eliminate income tax completely.

</comment></comment><comment><USER10> "Institute a 10% tax on landlords that flows into a federal savings account in the name of the renter. The renter can draw from his account only for a home mortgage, or at his retirement."

So landlords raise rents 10% (or more) and the effect is simply forced savings. Why not just make the SS tax rate 10 percentage points higher? Ridiculous.

</comment><comment><USER11> That would be fantastic, you know, if the banks didn't already rule the world. Do you think that banks are going to let software replace them? I have a hard time believing that this would come to fruition with anything less thank a full on revolution.

That said, I would wholeheartedly support such a revolution.

<comment><AUTHOR> In a way, computers are already replacing a lot of people at investment banks. Mostly brokers and traders, for sure. Even David E. Shaw himself once wrote that a lot of stuff in finance that is currently done by humans should be done by computers.

However, if you take a look at actual _banking_ , like commercial banking and corporate finance, the sector remains rather low-tech. And there's a reason for it: there are no new ideas in banking. It's all about packaging and selling old ideas. That will never be replaced by computers, unfortunately.

</comment></comment><comment><USER12> am i the only one that read (at least a few of the suggestions) as tongue in cheek?

</comment><comment><USER13> I agree. Esp running the country with Engineers rather than politicians or bankers.</comment>


ARC in Depth: Part II - <AUTHOR> https://sectionfive.net/blog/2015/06/12/arc-in-depth-part-ii/

<comment><USER2> Is this a parody website? Can anyone read that font?

<comment><USER3> Seems fine to me.</comment></comment>


Node.js recipe for automating JavaScript profiling in Chrome - <AUTHOR> https://github.com/paulirish/automated-chrome-profiling <comment><USER2> Could we take heap snapshots as well? With some trigger in client side code, it might be possible to detect memory leaks.</comment>


Stream Torrents Instantly From XBMC - <AUTHOR> http://forum.xbmc.org/showthread.php?tid=174736

<comment><AUTHOR> Also important to note that you can send magnet links from Chrome to it (a-la Chromecast) via the Play-to-XBMC Chrome extension.

Supported platforms are:

\- Windows x86 x64

\- OS X x64

\- Linux x86 x64 (XBMCbuntu)

\- Raspberry Pi (Raspbian, OpenELEC, Raspbmc, Xbian)

\- Android 4.0+ ARM

<comment><USER2> Slightly offtopic, what is considered the best RPI distro for xmbc?

<comment><USER3> I tried both Raspbmc and OpenElec. I didn't see a significant difference in performance. Using Raspbmc now. Unless they made some significant changes to OpenElec the past 3-4 months they are more or less the same.

<comment><USER4> I pretty much did the same, I started with OpenElec because my pi shipped with it, changed to raspbmc because I liked the fact it was debian-based. There really doesn't seem to be much performance difference.

</comment></comment></comment></comment><comment><USER5> Additional links also relevant for this crowd:

[https://github.com/steeve/torrent2http](https://github.com/steeve/torrent2http) \- turns magnet links into sequential HTTP downloads

[https://github.com/steeve/libtorrent- go](https://github.com/steeve/libtorrent-go) \- Go bindings for libtorrent- rasterbar

[http://www.rasterbar.com/products/libtorrent/](http://www.rasterbar.com/products/libtorrent/) \- 'efficient, easy' torrent library

<comment><USER6> Also worth the look:

[https://github.com/jackpal/Taipei-Torrent](https://github.com/jackpal/Taipei- Torrent) \- Taipei-Torrent, a working pure go bittorrent application

Disclaimer: I participated in it.

<comment><AUTHOR> Cool. How mature is it ?

<comment><USER6> "It works" in the sense that you can use it as a cli tool to download/share a torrent, much like aria2 would do. It implements many standard features ((multi) tracker, extensions, dht, magnet, ...), with the following notable exceptions:

\- no peer choking \- no throttling \- no LPD/LSD \- no PEX

also, its output is quite verbose. All things considered, a very pleasing experience with Go that works. Not used a lot though I'm afraid.

</comment></comment></comment></comment><comment><USER7> I rigged up Azureus to do this kind of sequential downloading a long time ago once, and it was quite neat, but I didn't share the patch because I reckoned it would be bad for torrent health if everyone started doing this. Isn't that still true, and with Popcorn and this popping up now, isn't it just a question of time before seeders start recognising and penalising sequential downloaders?

<comment><AUTHOR> You are right, but there's a lot more to it (time randomization, hot spots which are also the most shared etc..).

That's also why the addon is using libtorrent-rasterbar (as opposed to peerflix), and tries _very_ hard to do the right thing as to minimaly hurt the swarm (it does, but it tries to make up for it).

</comment></comment><comment><USER8> Honestly, I feel this comes a little too late.

It would have been nice with RaspBMC, but I've recently switch to using Put.io + Chromecast. The fact that Put.io has almost instantaneous access to entire torrents is kind of a dealbreaker.

<comment><USER9> How legal is that anyway, since they're acting like a sort of proxy server for torrent data.

<comment><USER8> I think they're getting around it by being a strict torrenting service - i.e. when you add a torrent that is already there, you get one single seed for the entire file, and the person who originally brought it in is liable for sharing it, not put.io

</comment></comment></comment><comment><USER10> Disclaimer: I am the author of the channel.

Would like to mention SS Plex[1]. It doesn't use torrents, nor XBMC really, but it allows you to stream and download content to a wider variety of devices.

I say "wider variety" because Plex runs on everything XBMC runs on (via PleXBMC), and transcodes files into a format the client supports.

[1]: [http://mikew.github.io/ss-plex.bundle/](http://mikew.github.io/ss- plex.bundle/)

<comment><USER11> I've recently switched from XBMC on a hacked ATV1 to Plex on a MacMini and been really happy with it so far. Having the Plex app on my Samsung TV and then on iPhone and iPad is a great bonus meaning it's trivial to pick up where I left off.

I always thought the "keep watching from a different device" thing was such a gimmick, but I'll go from watching a movie on the TV, then to watching a few minutes more in bed before sleeping then another few minutes over breakfast.

If my 18mo old is lazing in bed with us, I can pull up a TV show he likes, give him some headphones and snooze for a bit longer.

</comment></comment><comment><USER12> I've been using this for 2-3 months already. The fact you can send magnet links from chrome is what sold me on its usefulness. Thank you dev.

</comment><comment><USER13> Why can't I find it from inside XBMC ?

<comment><AUTHOR> Because it's not in the official repo

<comment><USER13> Of course I know.

My other comment is a hint to the developer ;)

</comment></comment></comment><comment><USER14> How is this different from the popcorn time app that was posted here a couple days ago? Any reason this is better?

<comment><AUTHOR> Disclaimer: I'm the author

Well, apart from the fact that it existed way before, it also serves a different purpose:

\- Last version has 8 providers (as opposed to 1)

\- Appart from Win/Mac/Linux, it works on Android and Raspberry Pi

\- Tailored for TV (because XBMC)

\- You can send "magnets" to it via Chrome (see FAQ in post)

\- Leverages a better bittorrent library (enhancing the swarm healthiness)

<comment><USER15> Would it be very hard to make this work with MediaPortal? I know that the two packages started out quite similar but have forked rather drastically over time. I only ask because despite trying to change over to XBMC a number of times (almost every major revision) I've never been able to make it do what I need it to do and MePo has a much higher WAF when setup well.

</comment></comment></comment><comment><USER16> Anyone know what the XBMC theme is in those screenshots? It's somewhat more appealing than Confluence..

<comment><USER17> Looks like Xperience1080+: [http://forum.xbmc.org/showthread.php?tid=150116](http://forum.xbmc.org/showthread.php?tid=150116)

</comment></comment><comment><USER18> FYI, XMBC works great as a media server running on a Raspberry PI

</comment><comment><USER19> My dreams have come true. (Commenting to save for later)

</comment><comment><USER20> Does it provide PeerBlock ([http://www.peerblock.com/](http://www.peerblock.com/)) style protection? Or can it be integrated into it?

<comment><USER21> Peerblock is effectively useless. There's no reason to waste time implementing it.

<comment><USER20> Why is it useless?

<comment><USER22> Because it is trivial for anyone who wants to sample a swarm to get a new IP address.</comment></comment></comment></comment>


How the Bitcoin Community Turned to War - <AUTHOR> http://www.blockcy.com/how-bitcoin-community-turned-to-war <comment><USER2> As someone who has been closely following the Bitcoin community since 2011, I am baffled by the toxicity of the blocksize debate and the resistance even against a moderate blocksize increase.

<comment><USER3> Wait a minute! Are you telling me that after all this, the supply of bitcoins is, ultimately, like all fiat currency, controlled by the will of human beings?

I'm not being sarcastic, I really don't know the answer to that question, but if, as it sounds, someone or group could just change the blocksize, that, based on my simple understanding of math, seems to indicate an ability to alter the supply-demand curve for the commodity.

<comment><USER4> Block size has nothing to do with the supply of Bitcoin. It has to do with the transaction throughput of the network. No one has ever proposed a change the Bitcoin supply. The original Bitcoin release from Satoshi set the block size at 32MB (it's currently at 1MB) so increasing the block size to 2MB as is being proposed by classic would bring Bitcoin closer to it's original implementation.

Perhaps your comment is genuine but when people say stuff like "if we increase the block size next they will want to increase the money supply!" I feel like they are trying to hood wink less technically adept Bitcoin users into supporting their small block view.

<comment><USER3> After reading the article, I get that now, but is there a difference? If there are 1,000,000 bitcoins and you can only use 100,000 of them per day in transactions, then there are only 100,000 bitcoins in supply. I understand there may be more than one bitcoin per transaction, however, the fact remains. The supply of bitcoins, via the ability to use bitcoins to transfer value, is controlled by human beings.

The consequence is identical. Is it not? Perhaps, the consequence is the opposite? If there is no ability to transact with the currency, the currency has no value?

I'm seriously ignorant, you can tell, but I would like to understand. Perhaps my questions can help reveal the answer? If not only to me, then to the community? Is that too scary? The truth? Too scary?

<comment><USER4> No, the consequence of increasing the block size is not related in any way to the money supply of Bitcoin. That argument has no merit.

Bitcoin's value is limited by small block size though. A large part of the value of BTC is the value of the total transactions done through it. Limiting the number of transactions will severely limit the price in in the long term. BTC will probably lose out to an alt coin if the transaction back log due to the small block size continues and is not resolved sooner rather than later.

<comment><USER3> Thanks for clarifying that blocksize controls only transaction volume. I get that now. I didn't when I made my original post.

I think, still though I'm not articulating my point well enough. Fiat currency fails 100% of the time because it is controlled by humans. My understanding thus far was that bitcoin was controlled by physical limits in the real world, that of electricity, compute power, ultimately: Math.

Now, here, we are not talking about the supply of bitcoins themselves, but rather, the number of transactions with them that can occur.

That too is a factor in the value of a currency. It's not just the supply of currency that affects the value, but whether or not the person receiving that currency believes in its value, in this case, they must believe they can themselves use that currency to conduct future transactions.

It is this belief, in the case of bitcoin -- transactability for the lack of a better word, that is controlled by human beings -- and this is the same failing that has caused the collapse of every fiat currency in history prior to the US Dollar.

Now I'm learning that bitcoin has not solved this problem and I can't understand how bitcoin will survive this failure.

For a money to survive, it must be bound by physical laws beyond the reach of humans to change. It is human fallibility that is the culprit behind all fiat failures in history. We must invent a currency immune to the decisions of humans to solve the problem that has plagued fiat throughout history.

<comment><USER4> The difference between government issued currencies (what you call fiat) and Bitcoin is that. Policies controlling Government currencies are decided by a small group of people generally well connected to banks and other wealthy interests (ie: a central bank with an appointed board of governors)

Bitcoin's governing rules on the other hand are enshrined in software and can only be changed through a democratic consensus process. It's a big step forward over fat cats deciding monetary policy in smoke filled back rooms.

<comment><USER3> It's not what _I_ call fiat, it's the definition of fiat. I thought bitcoin was not a fiat currency, but in fact it is, because it's value is controlled by supply and demand based on the decisions of humans.

I am now convinced that bitcoin will, like all fiat currencies, inevitably fail. It doesn't matter if its value is controlled by one human or a democratic process controlled by humans, it is controlled by humans and humans are fallible, therefore bitcoin will fail.

There is no question of this. The only question is, When?

<comment><USER4> Yes, but you created a new account to troll so that conclusion was inevitable.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER5> I'm strongly reminded of "I'm a Former Green Beret and Here's How I Would Bring Down Bitcoin"[1] (which I see is so popular it was just re-posted to HN after a week). Only, instead of "bring down," the objective is control; much more money to be made that way, I suppose.

I suspect that Bitcoin's lasting value, at this point, will be as an object lesson in what happens to decentralized, open-source projects (particularly those that have placed themselves "beyond regulation") once they start to have direct, and significant, monetary value. I don't think that it will teach libertarians to love strong government, but perhaps it make the views of such crowds, overall, more nuanced and less absolutist.

\-- [1][https://news.ycombinator.com/item?id=11191416](https://news.ycombinator.com/item?id=11191416)

</comment><comment><USER6> I took the simple pragmatic approach: I used the tiny amount of Bitcoin I had for purchases, specifically Namecheap renewals/extensions.

Does it seem to anyone else that among the defining characteristics of people heavily involved in Bitcoin are "poor social skills" and "does not work well with others?"

</comment><comment><USER7> My grandfather used to say, "when the money gets funny the people get funny".

Blockchain and other advancements aside for many people this has, in fact, always been about money.

</comment><comment><USER8> The Bitcoin community has never been peaceful.

<comment><USER9> Maybe, but now they're flinging DDoS attacks at each other. This is not the regulation-free utopia everyone was sold on over the past few years.

Frankly, it reminds me of nothing more (to cite a video game in about as serious a way as I can) than Rapture in Bioshock -- something that seemed like a good idea only until the first meaningful disagreement, and then fell apart completely.

<comment><USER10> Nobody was denied service.

People were simply denied service at their previous, exceptionally-cheap rates they had become accustomed to paying.

This is like saying that you are subject to ddos when a concert you want to see sells out. You either fork over the premium on the market, or you don't participate.

<comment><USER9> Um, no. This isn't about block size exhaustion. According to the article (I didn't do any research of my own to corroborate) proponents of various sides are throwing _real_ DDoS attacks at bitcoin nodes and/or web content friendly to the "others".

<comment><USER11> Yes, I am running three Bitcoin Classic node and all three have been attacked in the last 24 hours. The attack seems to be only uni-directional at this point, Core trying to shut down Classic nodes.

</comment></comment></comment></comment></comment><comment><USER12> Good article with good insight! I don't expect every story here to be biased, and while this one isn't perfect, it's very informative!

</comment><comment><USER13> > We'd think we finally overcame the attack, to then only be hit again.

Here's an interesting difference with digital versus fiat currency. In one you find counterfeiters (if you can) and generally put them in prison, which raises the cost of that business. Is it even illegal to hack Bitcoin?

<comment><USER4> It's illegal to DDOS, commit fraud, steal, etc... One of those laws would apply to anything you might do to 'hack' Bitcoin.

<comment><USER13> I bet you can count on one hand the amount of people ever prosecuted for DDOS.

And would a jury convict someone like this of anything other than a slap on the wrist? To people my parents age they think of it like kids playing pranks on each other.

<comment><USER4> You're question was if it was illegal. It pretty clearly is. People are prosecuted and convicted of computer crime on an increasingly frequent basis to think you would be able to get away with disruptive behavior like that in the long term because you think common people don't view it as real crime is naive. I also see no evidence this is true.

</comment></comment></comment></comment><comment><USER14> "Savage War"?

Oh dear. Have many people been killed?

</comment><comment><USER15> This war will be settles and ultimately Bitcoin the network will be more scalable to onboard new members.

This is only an issue because the network is growing at a rapid rate, aka a "good problem" to have.

</comment><comment><USER16> Does anybody know who the author was?

</comment><comment><USER17> I flagged the post. The title makes it appear that the blog post is unbiased, but reading through, it's clearly biased and trying to paint a rosy picture from the "classic" side.

To give some pointers:

1\. Most bitcoiners still support Bitcoin Core. Bitcoin Core users are upgrading from 0.11 to 0.12 pretty fast that 0.12 has now more nodes than classic: [https://bitnodes.21.co/nodes/](https://bitnodes.21.co/nodes/)

2\. The Classic nodes are mostly new and XT nodes: [https://coin.dance/nodes](https://coin.dance/nodes) Users are not really moving from bitcoin core.

3\. Classic has only 3% of hash power. They are even trying to rent hashing power to generate classic blocks: [http://nodecounter.com/mining_donation_fund.php](http://nodecounter.com/mining_donation_fund.php)

<comment><USER4> I'm not sure if you are being serious but all three of your points are bogus to some extent.

1\. The link you provided clearly shows classic and core 0.12 tied for the number of nodes. Support for Classic is much higher than reflected in that chart because there is an ongoing DDOS against classic nodes. Just a few days ago there was over 2,000 Classic nodes. You are also leaving out all the nodes that are voting for a block size increase but aren't classic nodes like Bitcoin Unlimited, and some remaining XT nodes. Once you account for all these factors support for Classic or a block size increase in general is higher than core 0.12 by double or more.

2\. Bitcoin Classic has only been out for a week or two of course classic nodes are 'new'. Further a lot of people running classic are doing it in parallel with core before making the switch. Several large high profile mining operations have said as much.

3\. Renting hash power has always been a huge sector of the Bitcoin mining industry rented hash power is no more or less legitimate than any other kind. Classic has only been out for a couple weeks and we are just seeing large miners start to mine classic blocks starting this past week. The likely scenario is that they will switch to a 50/50 scenario to start before going 100% classic as a mitigation against DDOS attacks.

I think the question any observer should ask themselves is if core has such massive support as you and others claim then why do they resort to illegal tactics like DDOSing alternative node implementations and similar dirty tricks?

<comment><USER18> > why do they resort to illegal tactics like DDOSing

Who is the "they" here? Mining operations that are in support of core? Core developers that oppose the change?

<comment><USER4> It's not clear. A reddit comment by one of the self proclaimed perpetrators says he was paid in order to DDOS nodes with classic in the user agent string. At the same time employees of Blockstream (aka: members of Bitcoin Core's dev team) deny that there are any DDOS attacks taking place[1]. It wouldn't surprise me if Blockstream was somehow behind this but no one is going to publicly admit to such an obviously illegal act.

[0][http://www.blockcy.com/bitcoin-classic-nodes-under-ddos- atta...](http://www.blockcy.com/bitcoin-classic-nodes-under-ddos-attack) [1][https://www.reddit.com/r/btc/comments/4835fp/blockstreamgmax...](https://www.reddit.com/r/btc/comments/4835fp/blockstreamgmaxwell_will_have_you_believe_there/)

<comment><USER11> Agree, all 3 of my Classic Nodes have been taken offline several times last night. Everyone BUT Bitcoin Core says this is happening and has evidence. The only ones denying the crime seem to be most guilty.</comment></comment></comment></comment></comment>


Show HN: Libra Blockchain Explorer - <AUTHOR> https://libexplorer.com/ <comment><USER2> Very nice. Why doesn't the team put an about page with details of the team there. Says powered by Libra and has links to the Libra project, but how are people to know if this is a third party effort or from the team?</comment>


Ask HN: Software for musicians to play music live together with little latency? - <AUTHOR> <comment><USER2> I also thought about this and it's a hard problem. It would basically have to work like a real-time game engine where user actions/inactions are predicted; those sounds get sent to everyone; everyone hears the result; some people can change their inputs; sound gets corrected with inputs.

The resulting sound will be glitchy as in notes that were not played will briefly be heard--similar to how a character position might glitch in an MMO. Anything without predictive sound broadcast wouldn't have the timing to be fun to play together is basically my conclusion. I would love to see this, as glitchy as it might be would still be awesome. Maybe something that uses both TCP and UDP might help. UDP to get early input changes, and TCP to always eventually catch changes.

</comment><comment><USER3> Jamulus is nice: [http://llcon.sourceforge.net/](http://llcon.sourceforge.net/)

Yes, there is latency over the internet, but IMO you can get used to it.

</comment><comment><USER4> So, I have never tried it, but with Reaper you should be able to jam online with other musican with this.

[https://www.cockos.com/ninjam/](https://www.cockos.com/ninjam/)

</comment><comment><USER5> Not going to work, latency will be greater than 10ms which is too much for musical timing and coordination</comment>


Hero Programmer Quest - <AUTHOR> http://www.kloonigames.com/heroprogrammer/

<comment><USER2> This looks like a fun idea, but 10 seconds are just too short. In those 10 seconds, I have barely realized the structure of the code. Actually reading the code, seeing what it does and spotting for bugs is just not possible in 10 seconds for me.

<comment><USER3> Not to mention the "bugs" (at least the few I bothered to inspect) consist of:

\- missing close-quote

\- missing expression in return statement of non-void function

\- missing semicolon

Seriously, who cares? If it doesn't even compile (first and third), is it an interesting bug? Not to me. The second is slightly less so, but still not very interesting -- any sane combination of compiler flags will emit a warning about this that you'd have to be an idiot to ignore.

Though in 10 seconds, finding any "real" bugs would be a joke too -- so frankly I don't really see the point.

<comment><USER4> Perhaps it's just a bit of fun.</comment></comment></comment>


Rr records nondeterministic executions and debugs them deterministically - <AUTHOR> http://rr-project.org <comment><USER2> If anyone is curious about what this would look like on a whole-system level, there is a series of patches [1] to QEMU that enables deterministic replay and reverse execution (i.e., step backward in gdb).

One can also use PANDA [2], but it doesn't currently support the gdb interface in replay mode.

[1] [http://lists.nongnu.org/archive/html/qemu- devel/2014-12/msg0...](http://lists.nongnu.org/archive/html/qemu- devel/2014-12/msg00805.html) [2] [https://github.com/moyix/panda](https://github.com/moyix/panda)

</comment><comment><USER3> What's new compared to GDB's Process Record and Replay [1] and Reverse Debugging [2]? The ability to save the traces? I am not a (regular) GDB user.

[1] [https://sourceware.org/gdb/wiki/ProcessRecord](https://sourceware.org/gdb/wiki/ProcessRecord)

[2] [https://sourceware.org/gdb/wiki/ReverseDebug](https://sourceware.org/gdb/wiki/ReverseDebug)

</comment><comment><USER4> Wow. That's impressive. Only a factor of 1.2 slowdown for full capture of execution history on a program the size of Firefox. This could, if properly used, eliminate the closing of bug reports as "can't reproduce". It may mean sending in gigabytes of bug trace data, though.

<comment><USER5> rr can compress traces, so while it's big, it's not as big as you think.

[https://github.com/mozilla/rr/issues/700](https://github.com/mozilla/rr/issues/700)

</comment></comment><comment><USER6> What other languages/frameworks have similar tools?

I wrote something like this for cgi-bin scripts in 1996. Problem: you don't necessarily see everything happening in the browser, especially someone else's, especially if they're remote (or unknown), and the only evidence might be a a line in the error log. "playback <script>" would create a wrapper script that saved all environment/server variables and POST data to a file (for later playback) and then call the original script. When run from the command line or debugger, a file containing the selected playback info would be "re-hydrated" into the proper settings, and then call the original script, and it would run as it had previously on the server.

There was a library to extend this to arbitrary data (within the framework). The idiom was something like (after some initial setup):

      if ( $PLAYBACK_MODE ) {
        $result1 = get_playback_value('result1');
      } else {
         $result1 = normal_function_call();
         save_playback_value('result1', $result1);
      }

Which is pretty much portable to any language. If your language supports it, maybe automagically wrap normal_function_call so the caller doesn't have to-- if you want this for every call. Recording multiple values could be done by appending something to the identifier (e.g. "result1:$i"). Generally, too much data collected in tight loops (or every db request, etc.), but you could programmatically turn it on in certain cases, only save after an assertion has failed, etc.

Playback use can be great for debugging, somewhere in between unit tests and end-to-end testing, kind of like a mock for medium-level complexity. Decouple data, events, etc. from the context in which they occur ("the real world") for later examination in a more controlled environment. Helping make irreproducible results more produceable.

</comment><comment><USER7> record/playback tools are immensely useful for debugging.

For instance, with rr, you can easily playback the same run through valgrind to isolate complex memory issues that would be very hard to debug by looking just at the final state.

You can easily use rr -g and gdb to debug issues that couldn't be stepped back using gdb's (limited) reverse execution.

All of this in the same development environment and negligible impact. If that's not enough, with qemu+kvm+gdb you can push it even further, though at a higher speed penalty.

rr recently got amd64 support, and it's in debian as well.

In the same vein, for OpenGL there's vogl from Valve: [https://github.com/ValveSoftware/vogl](https://github.com/ValveSoftware/vogl)

(hint: if some debian maintainer is reading this, a package of vogl would also be nice!)

</comment><comment><USER8> This is great - something I always wished I have as a tool.

I haven't found it explicitly, but this is Linux-only, right? And I guess porting to other platforms is not too trivial.

Btw., why is this not written in Rust?

I took a fast look at the code - very modern and nice C++11 code. And quite a few Linux dependencies (Linux headers + /proc usage).

</comment><comment><USER9> This is awesome! Is it a drop-in replacement for gdb? The docs seem to suggest so but just wanted to know if there are any fine prints.

<comment><USER10> You use it with GDB, it wraps it and makes the execution under gdb deterministic, so you can set breakpoints earlier in your execution by going back to the start and replaying up to your breakpoint. This sounds a bit inefficient, but compared to reversible debugging it works quite well.

You should watch the videos</comment></comment>


From Angular to Vue: Feeling Like a Beginner Again - <AUTHOR> https://blog.florimondmanca.com/from-angular-to-vue-feeling-like-a-beginner-again <comment><USER2> I found this post quite overstates the difficult of picking up a new web framework...

Try learning Haskell and a completely new paradigm if you want to feel like a beginner again, and every day afterwards.

I suppose web developers may lack exposure to the type of technology churn we software engineers experience on a biweekly basis.

<comment><AUTHOR> Hi, thanks for your answer and interesting point of view!

To my defence, I wrote this post the very night I installed and fired up everything Vue-related. Having taken a step back now, it might sound a bit too theatrical. I've accomodated to the framework pretty quick, which either says a lot about Vue or that I have overreacted to the change in the first place.

I must return the note to you, though — do you, as a non-web developer I suppose, actually learn a new language everyday? I suppose you take Haskell from your experience but it may be an emblematic example only. The web development world (esp. frontend) has its own amount of newness (and hotness, to be frank) every so often. Not to play the "What kind of dev is the best" game here, just interested in discussing.

Also, I am genuinely interested in the usage of "web _developer_ " vs. "software _engineer_ ". Why is it that you use a different term, e.g. why not "software _developer_ "? As an engineering school student, web development is only part of my skills (and only its basics are taught in class, actually) and I see myself as a software engineer more than anything. Yet, you seem to exclude web development from software engineering. Am I just having the wrong definition?

Thanks</comment></comment>


It's COBOL all the way down - <AUTHOR> https://increment.com/programming-languages/cobol-all-the-way-down/ <comment><USER2> Ok, let me just say at work I've spent the last 4 years working on a product that interfaces with COBOL. In-house we:

\- Generate native windows interfaces with COBOL, to the point where only a few lines of code create a control like a data grid, button or text entry with rich functionality. You'd never know these snappy native apps, with features like visual data validation and asynchronous menus/context popups, are COBOL.

\- Render rich web pages with COBOL using a in-house DSL that automatically become somewhat responsive between devices. The presentation information streams over a web socket so it's snappy and as responsive as the above desktop application

\- Perform complex queries and rich data validation. A few lines of code can automatically be linked to grid view that has HEAPS of built-in functionality like export or data side-view (link applications/side panels to the currently selected row), app row highlighting and styling, auto pagination with range expand, column sorting, reorder, filtering, conditional highlight and more.

So yeah, COBOL isn't dead. It's actually the coolest damn thing Ive seen in a while. Because it's pretty high-level we can build whatever we need on top as a runtime and the same apps can run on the web, native desktop, handheld tablet or on an old VT100 over SSH.

<comment><USER3> Can you point to any accessible versions of this? I'd love to check out an example, sounds really interesting.

<comment><USER2> Unfourtunately not, it's part of a very expensive ERP package. But this article has a few screenshots:

[https://www.scopesystems.com.au/whats-new-pronto- xi-740-scop...](https://www.scopesystems.com.au/whats-new-pronto- xi-740-scopetalk/)

<comment><USER4> Is this really all the same COBOL application? I'm truly impressed! Is there some kind of GUI toolkit for COBOL or the COBOL in this case only the logic behind the application and the GUI here is another language/framework?

I ask because your parent comment certainly rings true if this is all COBOL!

</comment></comment></comment></comment><comment><USER5> I worked in insurance so much time ago, in a COBOL shop (I was doing web- services on top, so I'm not a COBOL programmer myself). A few things come to my mind:

\- COBOL has no stack and no dynamic memory allocation. The memory cost of a procedure is known in advance and you cannot leak memory. There is not much room to be smart, and in the long run it's likely a reason for success. You would not want people with a three month training editing 20-yr old C code.

\- COBOL procedures are damn CPU-efficient at what they do

\- COBOL works in symbiotic relationship with DB2. A lot of things that are complex/tiring to do in COBOL (like e.g. working with strings...) can be done in SQL. And when you have SQL you can do pretty powerful things.

\- COBOL procedures do not usually sent SQL queries as strings to the database. They compile down to a procedure that does physical, low-level handling of database tables. If you change a table, you have to recompile all procedures that depend on it (and it may take hours to days....) but again is damn efficient in production.

\- mainframes run _constantly_ at a CPU usage of over 90-95%. There is a huge amount of procedures constantly running to maximise the return on the system.

<comment><USER6> > COBOL has no stack...

So no function calls?

<comment><USER7> Although I am not familiar with COBOL I am assuming this means you have to indicate where the control returns to after a function ends

<comment><USER8> So that's kind of like a coroutine. Taking recursion away seems like an unnecessary limitation, considering how much power main frames have. Resource efficiency is great and all, and certainly there's a benefit to not hammering the stack as often, but that takes away an entire category of definitions you can't express, right?

Maybe someone who writes cobol could chime in on this.

<comment><USER9> > Taking recursion away seems like an unnecessary limitation

Modern Cobol doesn't seem to have this limitation, eg [http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/handhel...](http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/handheld/Connected/BOOKS/IGY3PG20/4.1.4). When Cobol originally appeared, call stacks weren't standard, Lisp didn't exist yet, and neither Fortran nor Algol supported recursive functions; it made sense at the time.

<comment><USER8> Ohhhhhh, of course!

Gosh, thanks. I sometimes hold historical technology to unfair standards because I'm not thinking about the continuity of it all.

Crazy to think twenty-somethings are out there hacking COBOL!

</comment></comment></comment></comment></comment></comment><comment><USER10> I actually appreciate the fact that COBOL, while verbose, lets me scan the source code and get a general understanding of what it does.

Just did a migration from a mainframe to Java microservices. We were lucky to have subject matter experts on hand so we didn't have to delve too much into the COBOL code. Used JHipster Domain Language Studio to quickly go from a Bachman diagram to an entity domain model.

One quirk was that we were not permitted to use a modern UI; we had to emulate an IBM 3270 screen! The client ran out of money for retraining users so we had to do a lift-and-shift of the UI.

<comment><USER11> You drive the terminal with one microservice per character, obviously.

</comment></comment><comment><USER12> I'm a young developer who also happened to work in a bank so I did a lot of Cobol in 2017-2018.

Good points of Cobol:

\- No boilerplate

\- You could understand the use case just by reading the code

\- Never seen such a fast processing of millions of records (this was done with VSAM files)

But the most important and a real eye-opener for me:

\- Any developer can easily learn how to program in Cobol. You don't need superstars 10x programmers and ever changing frameworks and paradigms. There were grandmothers working as developers in the bank. I've actually never seen such a diversity in IT (not only age but also gender diversity). And you know what, that made it a real nice place to work

<comment><USER13> I'm also a young developer that works with COBOL, but I work in the insurance sector. The environment you describe is also how it's like here. And I've never worked with such nice and intelligent people!

One thing I really love about this environment is you learn a lot about the business area when working with COBOL, since the business logic is so plainly written in many programs. I don't like using the term "self-documenting code," but COBOL is really close to that.

</comment></comment><comment><USER14> Speaking as someone who occasionally gets roped into supporting a COBOL application at a large financial institution, I genuinely don't get the "we must replace it because it's old!" mentality. If it's still the best tool for the job then why move away? Just train people up and build tools to work with it on modern systems, just like Micro Focus and COBOL Cowboys (both mentioned in the OP) are already doing. As an added bonus, you can make a lot a money in the process too.

"The guy who wrote it left and nobody knows what it does" is a poor excuse with a self-documenting language like COBOL. How much sense do you think your tangled mess of Java will make in 50 years?

<comment><USER15> While I generally agree with the "if it ain't broke" sentiment, you have to perform some pretty wild mental gymnastics to end up calling COBOL the "best tool for the job".

Adoption and ease of learning should always be considered when selecting a tech stack for a solution. COBOL's semantics are so foreign to modern programming languages that it makes the language pretty inaccessible.

Also, COBOL's strength is in the generation of reports, but in the end, it's no more expressive for that purpose than any general-purpose programming language coupled with a nice report generation library.

<comment><USER16> > _While I generally agree with the "if it ain't broke" sentiment, you have to > perform some pretty wild mental gymnastics to end up calling COBOL the "best > tool for the job"._

Do you? Lack of programmers, aside, it was created and evolved exactly for the kinds of jobs its used in.

<comment><USER17> It is something of a DSL, as the name suggests (Common Business Oriented Language).

I would also disagree with GP that COBOL's semantics are really very foreign. Variable declarations, assignments, expressions, loops, conditionals, etc. are not that different from other imperative languages. More verbose, certainly, but not foreign.

JCL on the other hand....

<comment><USER18> If it's similar to other imperative languages, what makes it a DSL? What _is_ the domain of "business"?

<comment><USER16> It's similar to other imprative languages in some constructs, it's very business application focused in others -- e.g. built-in support for forms, for monetary calculations and such.

</comment></comment></comment></comment></comment></comment><comment><USER19> After years of struggle, our IT-department recently managed to conclude the migration of all COBOL applications from machines running on Unisys 2200 to Java EE running on GNU/Linux. As a Java developer working with the latter, the final months were wild. The old COBOL greybeards (some 70+, convinced to stay until migration was finalised) certainly didn't go gently into that good night, literally throwing insults at us, leaving meetings, wishing us bad luck etc. We could never be sure they had given us all information about their stuff, out of spite. I hope I don't finish my working years like they did.

<comment><USER20> So, how was your IT department treating them at time time?

As valued employees, pairing with the Java devs on code, attending team lunches and other functions, generally integrated with the teams to which they were passing on their life's work?

Because to be honest I'm struggling to believe they were being treated as equal members of a team if they were behaving like that.

<comment><USER21> I think the statement "convinced to stay until migration was finalised" already answers your question. I'm sure there would be some that would have wanted to, and been capable of, picking up a different language, but that is not how companies do things. It's replace with the new, even though a lot of business/application knowledge could be retained otherwise.

</comment></comment></comment><comment><USER22> I did COBOL for two years out of college. It is the most frustrating and terrible language to work in. We weren't using it on a mainframe we were using it to build GUI apps that run on client machines. I would spend days writing code that would take 20 minutes in c#.There were 10k line files with all global variables and you might think it was just bad design and what not but the team was very disciplined and focused on quality. There are no tests, documentation or Google queries to help you. Your job is to dig in an enormous codebase to understand what it does and that is tough. The developer output compared to a modern language is tiny compared to a Java or .NET developer.

<comment><USER23> > I would spend days writing code that would take 20 minutes

And then weeks debugging the phantom problems caused by the overuse of global variables that COBOL more or less mandates... I feel your pain, brother.

<comment><USER24> I know it isn't cool, but I often wonder if anyone will come out with a language that isn't meant to be the next C but the next COBOL, RPG, etc. I wonder if anyone has a LLVM backend for z/Architecture and TIMI.

<comment><USER25> That's a problem I've occasionally considered working on—modern alternatives with tractable, incremental migration paths away from COBOL/RPG/MUMPS—but I hardly know where to begin.

I'm sure for a lot of these companies, due to the sheer size and often mission-critical nature of these systems, the cost analysis still comes down on the side of keeping the COBOL/&c. systems and just using new tooling around them, like static analysers, integrations with frontend frameworks, ways to interoperate with relational databases, and software emulation of mainframes.

An alternative would be not only difficult to build but hard to sell. There'd probably be a lot of money in it if you had a team with the financial runway, technical skills, and market connections to do it, though.

<comment><USER24> I've thought about it a bit, and I do wonder if defining a VM and compiling the COBOL/RPG/MUMPS to it first then building the language off that. The languages are pretty straight forward and defining a decent high level VM instruction set would probably help with the not only the conversion but provide some assurance that you didn't miss something important.

</comment></comment></comment></comment></comment><comment><USER26> It would be a nice surprise to come across an article on COBOL that has anything nice to say, much less informative, about the language. One could start with that it's one of a tiny minority of languages based on decimal arithmetic as opposed to binary. This is kind of handy when dealing with money.

<comment><USER27> Perl 6 uses rational arithmetic by default (or by defining typed variables), which covers the money use case well. And, of course, we have SQL's DECIMAL type in most backends.

<comment><USER28> And Common Lisp, although it's not necessarily "default". (/ 2 3) works as expected, but 1.7 is a float (unfortunately), and not a rational 17/100\. Shame, really.

<comment><USER29> Nothing unfortunate about that. When you work with rationals, it's very easy to grow incredibly large denominators, at which point all arithmetic operations slow to a crawl. Floats are fast and predictable, which is why they're used for most calculations in CL and other languages.

<comment><USER30> Except when you hit denormals or underflow. Or accidentally lose precision ending up with a wrong result.

If I could get a cent for every money transaction done on floats and incorrectly rounded, I'd be a billionaire.

</comment></comment></comment></comment></comment><comment><USER31> I wrote the Apple Pay DPAN provisioning message tokenizer at a major financial institution in COBOL. Messages came through the payment network backend (BASE24) and our systems are all mainframes. COBOL will never go away until our major financial institutes are obsolete.

I met with manager to, what I thought was, to discuss the project and I brought up that tokenized PANs were our opportunity to transition off the mainframe and that we missed the boat. It fell of deaf ears because our meeting was actually to discuss how I was being reprimanded for using an SSH connection which the company couldn't perform a MITM attack on. It was at that point I knew I could not advance my career there.

<comment><USER32> You got reprimanded because the company wanted to perform a MITM attack on people? (sorry I got confused on the last line and wanted to be sure)

<comment><USER33> It sounds like they were having trouble doing their job because their corporate IT decided it was more important to intercept all TLS/SSL traffic on the corporate network than to allow software developers to do their job securely.

They weren't MITM attacking people outside the company, just MITM attacking their own employees.

I feel that pain, quite often (and am slowly losing a war on it at my current employer, sigh). TLS/SSL Interception Proxies are scum that make the internet overall less secure for a weird sense of security by corporate IT departments.

As a software developer, it's my job to make sure that no one is MITM attacking me so that the code I download to incorporate into projects is safe and secure. I can't check if a bad actor is MITM attacking me when my own employer is MITM attacking me.

<comment><USER32> > "It sounds like they were having trouble doing their job because their > corporate IT decided it was more important to intercept all TLS/SSL traffic > on the corporate network than to allow software developers to do their job > securely."

Right, that was what I thought too, this is honestly why I'm turned off from applying to work with more bureaucratic companies (soon to be fresh graduate), I understand the reason for sensitive informations being leaked. But this seriously causes a lot of productivity loss...

I've interned with a small company that needs to SSL into government/companies servers to do work. (I don't do them, just on local company machine for testing etc. Also maybe why they can't let me do live site related stuffs) It'll be a big pain to not be able to SSL remotely and do work.

</comment></comment></comment></comment><comment><USER34> I have an uncle who's about to retire after a career as a cobol dev. He tells me that he can teach me the language in two days, show me around the legacy systems of [big company you know] in two months, and then I could have a safe and lucrative career until I retire, too.

I wish he was interested in writing a blog post of war stories.

<comment><USER17> COBOL is easy to learn if you already know how to program. What's a bit harder is learning the mainframe environment it's deployed in. It's not like Unix or DOS at all.

<comment><USER13> Yes, this exactly. Whenever I tell people I'm a mainframe developer, they always ask how they can learn COBOL. Oh, that's the easy part. The environment is very different and takes a while to get used to, but it's where COBOL thrives.

</comment></comment></comment><comment><USER35> Today, Commonwealth Bank of Australia (as mentioned in the article) has indeed successfully migrated to SAP Core Banking. Westpac is in a similar transformation to Oracle Core Banking. Some European banks, eg Nordea, are slowly moving to Temenos T24, a Swiss java based core banking system. Danske Bank built their own. It was expensive and, afaik, still has issues.

<comment><USER36> Are there open source core banking software out there?

<comment><USER37> I don't think banks are famous for sharing (or caring :) ).

<comment><USER38> They probably don't share much nowadays, but look up CBT tapes for an counter example of Banks doing open source and code sharing before it was a thing.

</comment></comment></comment></comment><comment><USER39> > billions more being written each year for maintenance and new features

This is funny to me, because the where I'm working right now, they have teams building entirely new projects in COBOL. The reason is that it's a company with a very high average age and incredible secondary benefits for baby boomers (old contracts, young people get ripped off), so they have an army of COBOL developers while there's a shortage for pretty much every other type of dev.

<comment><USER37> Yeah, but what will they do in 10-15 years? Those people aren't immortal and newcomers will have to be:

* persuaded to come: tough sell for Cobol

* 99% internally trained cause the pool of Cobol devs is probably similar to that of Elm devs :)

<comment><USER40> This problem is solvable by basic market dynamics. When everyone knows that a JavaScript "Dev" can make $80k and a cobol one can make $190k, people with learn cobol. It isn't hard. If you can grasp one imperative language, you can grasp any of them.

<comment><USER37> True, but if the Cobol market is for 10k developers worldwide, not many people will venture there, even for higher pay. Cause if you get fired from your Cobol job and there's no openings for Cobol devs, your market value just plummeted to $40k as a Junior Javascript dev ;)

And despite what we may think, except for the big tech companies, everyone else doesn't really hire generalists. You could have 20 years experience as a programmer in 10 different languages, HR still wants a Java programmer with 5 years of Java experience.

<comment><USER41> Fuck it, I am sick of the churn associated with modern development. Cobol sounds quite appealing right now.

<comment><USER42> You could also become an embedded dev. Write software for cars or planes, or train, or nuclear power plants. If you want you can work on the same piece of software using the same tooling for your whole career.

<comment><USER41> Whats the language of choice for that? C or would Rust be worth learning? Any pointers for how to get started in that field?

<comment> murph-almighty (heh pointers)

I was in ECE in college (graduated in 2017) but do full stack software engineering for a bank now. AFAIK it's still C, but I wouldn't be surprised if Rust picked up due to the emphasis on memory safety- dynamic memory allocation and recursion are usually avoided in embedded.

Some of the lessons I got from embedded have carried over to my place of work- I found a repo that used floating point for money and immediately knew why that was a bad idea, because my embedded systems professor had spent an almost an entire lesson explaining why you don't use floating point for money or time.

side note: Said professor (Phil Koopman) was an expert witness in the Toyota unexpected acceleration lawsuit, he has a talk on it that can be found at [https://betterembsw.blogspot.com/2014/09/a-case-study-of- toy...](https://betterembsw.blogspot.com/2014/09/a-case-study-of-toyota- unintended.html).

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER43> Is it really better if we replace x million lines of COBOL with x million lines of java or c++? What is the financial language of the future that is easy to write and reduces errors?

<comment><USER44> It would actually be better if we replaced x million lines of COBOL with x million lines of COBOL. For many reasons:

1\. it would run on a modern environment instead of a weird mainframe OS using a weird database

2\. it would use modern coding conventions such as local variables and control structures instead of goto

3\. it wouldn't be x million lines after you remove all the dead and duplicate code. These are codebases have been developed for 3 decades with the principle "we don't know how any of this old shit works, don't touch anything you don't need to"

But yes, you would also get a lot of advantages from porting everything to a modern programming language with good tooling.

<comment><USER45> I agree with you somewhat there; you mean refactor instead of rewrite and yes, I believe that is a better choice. But the problem is not language related; Joel Spolsky said it with far smaller and more modern codebases, but, as you even indicate within #3, 100000s of changes were done in the code over 30 years by people who did not understand the full system or, often, did not even understand the local parts they are editing fully. A lot of changes in legacy code, but let's not kid ourselves, also in modern code, depend on 'things' the programmer deemed right at that moment. Then after testing (even testing in practice with people's money), now after unittests (or in practice, with people's money), too much of the business logic/functionality depends on bad code. Code that is off-by-one that isn't discovered for decades or at all is not unheard of for instance because that routine is only triggered for a specific insurance policy only 100 people have and for those 100 the bug actually gives back the right answer. It would require deep understanding of all the corner cases and that's why it's often just not rewritten.

We were working, around 2000, on partially porting a Cobol+Fortran insurance system (which was an 'integration' of systems acquired by acquisition over the years) to Java (yes, EJBs..... ..... ..... the sins of my youth...). The work was mostly 20 people working for months on creating all the encoded rules into spreadsheets and, in a much shorter time, us translating those to Java. This particular piece was done because the company wanted to webify that part of the system. I am not sure if the modern versions of 'software mainframes' or modern hardware mainframes would be fast enough to handle web with the old code running?

<comment><USER17> The thing about most old COBOL is that there is very little shared code. There are things called "copybooks" which are snippets that get copied into your program at compile time, but they are not "shared" code. So you have much less chance of affecting anything else when you change a COBOL program. Most are written to perform a single transaction or generate a single report or screen, and are entirely self-contained.

</comment></comment></comment></comment><comment><USER46> Anyone have thoughts on how to go about learning mainframe programming and COBOL? Honestly seems like a useful skill given its existence everywhere but I don't think very many engineers (myself included) know where to start in learning it.

<comment><USER47> A number of people, I think in the "COBOL Cowboys" discussion, on HN have pointed out that it's not learning COBOL that's the issue. The language is the easy part. The real problem is learning the mainframe systems and concepts, and especially gaining meaningful experience with them. Emulators are available in some cases but back in the day all this stuff was proprietary, and doesn't follow the familar UNIX-a-like mould of many modern OSes. (It goes without saying they're nothing like Windows, either.)

EDIT: I think this is the COBOL Covboys discussion I referred to above: [https://news.ycombinator.com/item?id=14083214](https://news.ycombinator.com/item?id=14083214)

<comment><USER48> Yes. I agree with this. Having command line and interactive terminal experience and actually programming your environment the more fundamental skill to have on mainframes.

<comment><USER17> I don't know -- It's been decades since I wrote any COBOL, and at the time I was pretty fresh out of a unix-centric undergrad environment. I was at home in emacs and the shell command line and familiar with unix utilities, but the mainframe was just another planet entirely. None of that experience really translated.

</comment></comment></comment></comment><comment> orbital-decay COBOL code base is pale in comparison to modern systems, and mostly self- contained. The number of critical legacy systems written in ancient languages nobody supports anymore is going to increase, and given the reliance on third- party code (libraries, compilers, frameworks, tools etc) the problem will be much more prominent in several decades from now, when all current programmers retire and the institutional memory should kick in.

<comment><USER49> > The number of critical legacy systems written in ancient languages nobody > supports anymore is going to increase, and given the reliance on third-party > code (libraries, compilers, frameworks, tools etc) the problem will be much > more prominent in several decades from now

You're talking about Javascript?

<comment> orbital-decay AFAIK Javascript is not used for critical systems which will be in service for decades. Besides James Webb Space Telescope, of course.

<comment><USER50> I don't know if you are serious, but regardless of that, the James Webb space telescope will stay near the L2 Lagrange point. This is not a stable orbit, and left to its own, the spacecraft will drift away from the desired orbit. That means it needs thrusters to keep itself in place, and it will bring enough fuel for about 10 years of operations. After that it will slowly drift out of L2. Given the distance from earth, there is also no way there ever will be any service missions that the Hubble space telescope relied upon.

So no, James Webb space telescope won't be in operation for decades.

<comment> orbital-decay It was mostly a snark. Yes, you're absolutely right, JWST service life is propellant-limited, not to mention its limited liquid helium supply for the first phase of the mission. And they are not using pure ECMAScript either, it's a heavily customized version.

</comment></comment></comment></comment></comment><comment><USER51> >The language ostensibly self-documents, because it's so verbose and requires so many explicit declarations about what it's doing

You know, I just finished a COBOL class at university and this makes sense. One of the main things I hated about cobol was how strict and weird the syntax was. It uses so many full verb identifiers rather than just operands. The language just really feels like it was built to be rock solid.

</comment><comment><USER52> Few people want to program in COBOL; but businesses still depend on _running_ COBOL code. Reminds me of another language: JavaScript.

The developers who didn't want to code in JavaScript, solved the problem of having to _deploy_ JavaScript by creating other languages that compiled _to_ JavaScript: CoffeeScript, TypeScript, Elm, ClojureScript, etc. And, more recently, by just turning the JavaScript interpreter into a glorified low- level VM, through WASM, so that it can be programmed in _any_ language.

Why hasn't this approach been taken with COBOL?

With such a language in hand, you _could_ take existing codebases (or compiled binaries) and write a decompiler that would convert them to your language of choice, so that the whole project could exist in the new form. Or, more simply, you could just write new modules (and rewrite any modules you have to change) in the new language, leave old modules as COBOL, and then link them together.

</comment><comment><USER53> This is timely given the terrible problems the TSB bank is having after failing to properly transition from a legacy COBAL system [http://www.bbc.com/news/business-43948889](http://www.bbc.com/news/business-43948889)

<comment><USER54> You mean, transition from a fully working COBOL system that their former parent company is happily using, to a modern one that shows NullPointerException to the end user?

<comment><USER55> > happily using

Not sure you can say they are 'happily' using the agglomeration of bolt on systems that they have pulled in over the years.

There's remnants of Cheltenham and Gloucester, Halifax, Bank of Scotland, TSB (now spun out), Scottish Widows, Standard Chartered Bank (IIRC) and I think some parts of Abbey National.

Those are just the one I remember and some of those are comprised of a mish mash of prior systems.

Keeping all that going is likely a huge burden. Indeed, they charged TSB £100 million a year just to emulate TSB's part of the system so TSB could just keep using that until their subsequent merger.

<comment><USER11> Santander bought Abbey National. Did some of it end up in TSB somehow?

<comment><USER55> I just looked it up - I got confused as it was Abbey Life not Abbey National.

</comment></comment></comment></comment></comment><comment><USER56> > He also noted that billions of dollars would likely be needed to implement > this kind of migration across multiple agencies.

> You can't just rewrite the whole thing.

Is it that bad? I guess I'm being crazy thinking I can do it single handedly in 5-10 years for a couple million.

<comment><USER57> > I can do it single handedly

For every 1 programmer working on a Cobol system who would and could rewrite it, there's another 3 who actively resist rewrites to keep their jobs and put bugs in the system to generate overtime-paying after-hours callouts. There's yet another 6 programmers who don't have the aptitude to program but who somehow managed to get into their job and are just productive enough to avoid being terminated. And perhaps they bring one of their kids to work for the day every now and then.

You don't get to do a Cobol rewrite single-handedly when there's 9 others on the team working against it happening.

<comment><USER56> I agree.

But that also means the major roadblocks are sociopolitical and not technical (not saying technical challenge is not there, just that it's not the biggest issue).

</comment></comment></comment><comment><USER58> If COBOL is really as self-documenting as everyone seems to claim, why is it not possible to translate it to some other language and then use that version going forward?

<comment><USER59> It is possible. I did it early in my career, fresh out of college. It wasn't hard, just tedious.

I think (total speculation) that the root cause of failure in these projects is due to mismanagement and (maybe) the kinds of people who are pulled into the projects. To the latter point, it's really hard to attract great developer talent into such a project, same goes for medical systems and government contracting. There's better money, and _way_ better work environments in other sectors. (Just my 2 cents.)

</comment></comment><comment><USER60> The puzzle is, when and how will this state of affairs (running legacy technology) change. Is it because C-suite movers and shakers doesn't have skills to bring about change? Or is it that things we take as trusted and agile modern systems and methodologies discussed here in HN happen to be things that the market at large will not bet on for a forseeable future.

<comment><USER61> Replacement projects for big legacy technology stacks have a track record of costing huge amounts and then not delivering. So keeping them running for as long as possible can be perfectly rational.

</comment></comment><comment><USER62> I took two semesters of mainframe classes (COBOL, JCL, DB2, etc) as electives, in 2015-16. I wouldn't want to do that full time (though the jobs are there and it's an applicant's market), but it was a great experience.

So much different than all my other CS classes, and gave insight into an important part of IT that isn't really taught anymore.

</comment><comment><USER63> Neat article. I am quite old but never touched COBOL (they used Java to teach in Uni). There are so many articles about the failures of transitioning on legacy system to a modern one. Like that British bank going over to a Spanish one (TSB?). Does anyone know of success stories? What were their techniques/strategies?

When I hear about the COBOL line count it always makes me think that someone should write a program that eats COBOL as input and spits out Java/C++/LangDuJour as output. Might make a good company. Mind you, it may already exist, or, be impossible because of some aspect of the COBOL language I don't understand.

<comment><USER64> Microfocus has a cobol to jvm transpiler.

Issue is that cobol often relies on intricacies of specific mainframes or cobol implementations so it's never quite that simple.

Also a lot of cobol directly interfaces with databases with side effects which makes it ever harder.

<comment><USER65> Micro Focus is an interesting company. And apparently very profitable. From a smallish company making tools for mainframe development and consultancy to now owning HP Enterprise and a whole bunch of other companies as well. They're raking it in money wise.

</comment></comment></comment><comment><USER35> And worth noting the real pressure comes about when you move to real time payments. COBOL / mainframes are batch transaction processing systems and generally struggle with real time / event based transactions.

<comment><USER66> That's what CICS is for, and has been around for quite some time [https://en.wikipedia.org/wiki/CICS](https://en.wikipedia.org/wiki/CICS)

</comment></comment><comment><USER67> I'd take a guess that the recent problems with the TSB migration are down to something like this. (Google it if you haven't heard). They tried to replace lots of ancient systems with a big new one and ... it didn't work.

Root cause on something like this is problematic: management instituted a hard deadline despite signs of serious problems early on, and there seems to have been some monkey patching being applied to live systems as they try to get it working. But a big factor has got to be the huge problem of figuring out what all those old legacy systems actually do.

</comment><comment><USER68> My company has plenty of Cobol. While I am not on their part of IT, I used to work together with them for integration. I left with very mixed feelings.

Some bad sidess * The language is old, in a bad way. Reading cobol learns you pretty fast why todays practices are better than the multi million spaghetti monster of the past. * IT practices are old. They havent yet embraced lower case. I trieds to tell one of them about UTF-8, but the whole idea that 1 char=1 byte might not be an universal truth was so far out she immediately rejected me as insane. * IT tooling is unique. These guys did CI/CD in the 80ies, but did it with a whole custom stack. They wrote their own source code control, and added an engine wih auto compiles checked in code, rejects code not according to the very strict rules, does some testing, and manages promotion from dev to test to preprod to prod. * The database consists of 12 files (we would call them tables). Each of them has exactly 1 index. You either do a full read or an indexed lookup. There are no more files left, they are used up. Quite a lot of nightly batches exist for looking up data not reachable by the index by doing a full read for each record. See it as a kind of manual join. * Security practices are old. There is no isolation, every application has full access to everything (There is 1 mainframe shared between user data, HR data, payment systems, ...) . If an application crashes, it dumps core. This is considered a feature, as the user can restart without much trouble. The idea that a dump might indicate some kind of exploitable problem is incomprehensible, so it is a continuous fight to keep these guys from connecting cobol straight to the internet.

But even if the technology side is horrible, they provide a lot of business value, especially compared to modern oracle/sap/tata/... 'enterprise class' applications: * The terminal application is quick, even if the learning curve is horrible. You just type as fast as you can. If cobol cant follow, you'll see a pause on the screen, but don't let that slow you down, the mainframe will catch up. * There is no sexism here. The male/female mix is approx 50/50\. * These guys know their business. Every edge case of an edge case is known. Compare that with the enterprise applications, where every release proves within a week to be hopelessly unfit for business purposes. We have to throw millions at the new applications just to keep them limping along. * There is no hubris here. No Architect, no Consultants, no expensive management ideas. A recent migration from cobol to oracle OSB+gui actually required us to add 1/3 of personnel to account for the slowdown caused by people . Yeah we all saw it comming, those wo reported problems were not given raises until we got the message. But cobol culture is 'That can't be done', after which the Architects recoil in horror and let them be.

All in all, Im not sure if this post is an argumant for or against Cobol

<comment><USER41> Out of interest what do you see as the benefits of UTF-8 in source files?

It has caused me problems a couple of times, and I don't ever think I have needed anything outside of ASCII for source code, with the exception of entering some foreign names in to a database via a script.

<comment><USER68> Sorry, that post got horribly mangled.

I want UTF-8 in the database, not the source files. This is Europe, user data has accents aplenty.

This once ran on a real mainframe, but was then migrated. So it has the common subset of win1252 and some ebcdic variant, minus lowercase. No euro sign on the financial report anywhere ;-)

</comment></comment></comment><comment><USER69> Weirdly, I submitted the exact same URL 20 hours ago: [https://news.ycombinator.com/item?id=16958811](https://news.ycombinator.com/item?id=16958811)

Not complaining, just surprised: I thought that HN deduplicated within a few days or weeks.

</comment><comment><USER70> COBOL maybe alive but from doing a little bit of searching, the pay scale looks like about half of what a senior engineer in a more modern language makes.

</comment><comment><USER71> I like studying computer programming history and I'd love to become proficient at COBOL and work on old mainframes! Where do I sign up?

</comment><comment><USER72> I've noticed that people only speak well of COBOL when Grace Murray Hopper's name occurs nearby.

I suspect that this says something about COBOL.

<comment><USER73> Grace Hopper is a legend not because the tools she invented are great by modern standards, but because she laid the groundwork. She was also one of the earliest to recognize how important computing was going to be and that hand- writing everything in hex was not a great idea. Later she championed even higher-level abstractions. Programming at the start of her career was considered non-creative secretarial work for women to do, which has the dubious distinction of being wrong and sexist at the same time.

When judged by standards of the day COBOL wasn't bad. It was one of the first examples of a high-level language. People's experiences with it (and large undocumented spaghetti logic programs) helped inform the next generation of languages.

Later our (ongoing) experiences with the unsafety of C led to Java, C#, and D among others. Further reactions to those are Swift and Rust.

I'd argue we wouldn't have any of those languages in the same form without COBOL.

<comment><USER74> >When judged by standards of the day COBOL wasn't bad. It was one of the first examples of a high-level language.

Compared to LISP?

<comment><USER75> > COBOL (Common Business Oriented Language)

You can't compare the languages like that, they were created to fill very different roles, and both were very successful at what they did.

</comment></comment></comment></comment><comment><USER76> Is the pay stellar? If so, I could do COBOL.</comment>


Docker Compose reads your ".env" without opt-out - <AUTHOR> https://github.com/docker/compose/issues/6741 <comment><USER2> Docker Hub still does not have any form of 2FA. Even SMS 2FA would be something / great at this point.

As an attacker, I would put a great deal of focus on attacking company's registries on Docker Hub. They can't have 2FA, so the work/reward ratio is quite high.

<comment><USER3> Why would any serious company not use a private registry?

<comment><USER4> AWS Docker registry (ECR) is a good middle ground since you don't have to maintain your own registry and you can take advantage of IAM to improve security.

<comment><USER5> Some CICD services such as GitLab already provide docker image registries per project for free, and enable users to create any number of projects.

</comment></comment></comment></comment><comment><USER6> This is the exact class of problem that docker itself attempts to avoid. This is why I run docker-compose inside a docker container, so I can control exactly what it has access to and isolate it. There's a guide to do so here[1]. It has the added benefit of not making users install docker-compose itself - the only project requirement remains docker.

1: [https://cloud.google.com/community/tutorials/docker- compose-...](https://cloud.google.com/community/tutorials/docker-compose-on- container-optimized-os)

<comment><USER7> > docker-compose inside a docker container

Do you use Docker-in-Docker or do you mount the docker socket inside your docker-compose container?

Oh dear god .. it's Docker all the way down.

<comment><USER6> Mount the docker socket. There's some quirks with storage volume paths. Also, security implications. Was not super hard to get working though.

I'd love to go straight to containerd or even basic linux containers but I'm not willing to run kubernetes on my personal machine and haven't found any ergonomic enough ways to run containers.

<comment><USER8> Check out [https://podman.io](https://podman.io)?

Like docker (uses CRI images) but daemonless.

<comment> yjftsjthsd-h I thought it didn't even support compose like functionality? Or did they add that now?

<comment><USER5> Docker-compose is an add-on script that only automates how containers are launched/shut down.

</comment></comment></comment></comment></comment></comment><comment><USER9> You can run docker-compose.yml in any folder in the tree but it only reads the .env from cwd. Just CD into some place and run docker-compose

<comment><USER10> This works. I discovered this by accident trying to figure out why my .env files were not being read.

I was in a different dir to the docker-compose.yml file and launched docker- compose with the -f filename option and could not get .env to load.

</comment></comment><comment><USER7> I was going to use Docker Compose for setting up a lot of my self hosted stuff; since so many projects already had docker compose files in their git repos and it would seem to be easy to leverage that. Early on I got super frustrated with compose though (can't remember all the reasons why) and ended up just writing my own custom provisioner:

[https://github.com/sumdog/bee2](https://github.com/sumdog/bee2)

It has unit tests, but not a lot of good errors messages and is pretty specific to the stuff I host. I'm glad I did it though; great learning experience around the Docker API and how the internals of the Docker Engine work. I still use it to maintain all my self-hosted sites and tooling.

There are a lot of good libraries around the Docker API for Ruby, Python, Java/Scala, etc. If you're on a green field project setting up your local docker environments, and have the time, I'd almost suggest trying to build your own tooling from scratch rather than leveraging docker-compose at this point.

<comment><USER11> I actually really like Docker Compose, and especially Swarm. Despite being a relative Docker noob, I've found it to be relatively straightforward to use, and the configuration and secret options are pretty comprehensive. Haven't hit any issues I recall.

Would CNAB work with a custom provisioner, or would support for that need to be coded in?

</comment></comment><comment><USER12> For reasons like and to avoid confusion I always name my environment file something specific like `.env.development` or `.env.dockercompose`

Any system that reads `.env` files usually allows some way to specify the exact file to be read.

<comment><USER11> Huh, I wasn't aware of this! If nothing else, I like the idea of separate files for separate concerns.

</comment></comment><comment><USER13> As a workaround you could rename your .env file to something else and mount it as .env in the docker-compose volume options.

<comment><USER14> How does this help all the existing applications, tools, scripts etc. that use .env?

<comment><AUTHOR> If you wanna make it work; this is sadly the only way until Docker Compose is patched.

Rename .env to something else and reconfigure autoenv.

<comment><USER14> Right. Usually workarounds actually, you know, work :-P

</comment></comment></comment></comment><comment><USER15> No great fan of docker and on a train with a demo laptop and no way to install it to test, but I would expect that

> docker-compose --env-file /dev/null

will get it to not read a .env file.

Will test later/tomorrow.

<comment><USER16> They do mention that being an option in the comments on the bug report, but still sound the alarm as that's (seemingly) the _only_ option. One-off fixes are possible, but that's not a viable solution at scale.

</comment></comment><comment><USER17> Stuff like this is why docker alternatives exist.

<comment><USER7> This doesn't have anything to do with Docker, but specifically docker-compose. What are the alternatives you suggest to that? Minikube?

<comment><USER17> Yeah, I like Kubernetes. But I'll admit it's not exactly the most inviting thing to get into. It's cool once you get the hang of it.

But the attitude runs all the way through docker products: arbitrary decisions made for their benefit with no thought to the externalities.

</comment></comment></comment><comment><USER18> Call me ol' fashioned, but if I'm not administrating hundreds or thousands of micro-services... I just use "Plain Ol' Unix Processes on ZFS," or as I lovingly call it "POUPZ."

I can honestly say this exact issue is impossible for anyone who POUPZ. If you haven't tried POUPZ in production, or even POUPZ at home, my recommendation is to give it a try.

I think you'll be pretty glad for once that you POUPZ where you eat.

<comment> yjftsjthsd-h Does this address the package-like behavior that is one of docker's big selling points? I guess I could imagine building something out of zfs send+receive, but it feels like you'd need tooling to make it nice, and now you've reinvented the wheel.</comment></comment>