Bloomberg started out as a network system independent of the Internet. Michael Bloomberg was a network engineer. I'm not sure they ever really switched to proper TCP/IP. This company sure looks like a dinosaur these days. However its hard to imagine a company being able to replace even a chunk of their infrastructure. They are tightly integrated into all institutions and there is no other service which offers a complete coverage of all the world's financial assets.

Yes, we use proper TCP/IP :)

The issue was probably something like a broadcast storm because of defective fault detection on some redundant network kit. That won't stop people blaming it on the fact that the stack isn't built on the latest hipster frameworks.

While I see your point do we have to throw the word "hipster" at everything new?.

I'm not a huge fan of Javascript and it's proliferation of frameworks but some of that stuff is objectively both good and useful.

It's human nature to want to label things. IIRC a while ago I was watching one of those "house hunter" type shows and a husband on there was really annoying. I found a discussion online and people were calling him a "hipster douche". So, perhaps hipster by itself isn't so bad. :)

Back a long time ago the applicable pejorative was "yuppie". I haven't heard that one recently. I suspect that many people reading here would have to look it up in Wikipedia.

Edit: BTW at the time I was partial to calling people "yuppie scum". Sigh. It's so hard to keep up with the changing putdowns! :)

Using the term 'hipster' to refer to the newest and shiniest web framework always felt like a bit of a misnomer to me. A solid portion of hipsterdom is rooted in recycling of the obscure and of the vintage (vinyl, the popularity of the lumber sexual look, etc). It seems like the 'hipster' thing to do would be to write a web framework in PL/I or cobol or something.

New and obscure are all too frequently synonymous.

That said, there might be a market for a web framework in PL/I there is a whole lot of IBM big iron out there :-P

...among other things.

Yes I think to replace them someone needs to create a marketplace for different aspects of Bloomberg and you buy access to specific services and data as you need it.

Would be an amazing business that, supposing you could get buy in from a load of other firms.

Really don't see an ala carte solution being worth it for most firms unless they're really trying to cut down on cost. Integrating and maintaining separate services alone is going to require additional developers. Cost associated with that coupled with quality of service and reliability (outside of this situation) of Bloomberg's current offering makes it a very tough sale. Also, guys who have been using terminals for years are really not going to want to switch.

I'm more thinking "if someone was to compete with Bloomberg how would they even come close to what they offer" may not be practical in reality!

interesting view - what makes Bloomberg brilliant (aside from the support) is that i have, for example, an array of my portfolios that i can access from every function. So if you could create a service that took all of the information that was relevant to you (portfolios, news feeds, models etc) and normalize it to make it interoperable with a whole host of 3rd party systems, you could be on to something!

It's crusty old code because it works and it's tried and true. If you have a backend that works, why mess with it?

Sure, C++/C/Fortran/some home grown template library is what it's built on. What would they gain by rewriting it some node framework of the week or whatever other shiny distraction? If they did do that and that caused downtime, there would be the same naysayers here complaining about that instead.

I swear I should start a consultancy in the control of software complexity because I am seeing this sort of thing everywhere, and the downages and security issues will only continue (or get worse, as we continue to rely more on software)

yep, lets not forget 700mb + executables...

Only 700mb? Maybe back in the perkin elmer days, these days they're up to 4gb, constrained only by the various linkers, file size and address spaces available...

Server-side is very big - in fact, a long time ago the part called simply "the Big" got too big and now there are multiple Bigs.

When I was there (2008, intern), they were in the process of moving server code from Bigs into separate services (BAS's, if I recall).

And this is one reason why I don't like C++. I only hear about executables getting too big in C++ projects.

That equate from what I hear to 128gb+ memory usage!