I still don't buy your premise that Macbook Pros with external boxes for these sorts of things are going to be common.
Maybe, maybe not. I know of several audio professionals that use a MBP as their main workstation -- and when necessary, they simply unhook it and take it with them for remote recording.
Typically, you'll be using 96kHz @ 24 bits for tracking and mixing (and these days, mastering, too). Add to that digital mixers, multiple sends and receives, multiple audio interfaces, STEM sends, etc., and the bandwidth consumption really starts to add up.
For pro video and pro audio use cases, outboard processing equipment is a necessity, especially if your workstation is a laptop. Which these days is often the case. I consider thunderbolt and external PCI chassis to be one of the best things since sliced bread.
And, for what it's worth, firewire is still very popular in the pro video and pro audio world.
I would love to see the code running in handheld GPS units that first find a variable number of satellites and then calculate the latitude, longitude, and elevation of the unit.
No you don't. Trust me, you'll be very disappointed.
The article suggest that one solution is to simply not do GC until the end of the trading day. I have to admit that's a good pragmatic solution, certainly so for HF prop traders.
Not enough memory on your servers? Add more. Still not enough? Add even more. The cost would be a pittance for any prop trading company worth its salt.
built-in support for concurrent programming for multicore computers, very friendly C programming interfaces for embedding and extending, a LLVM-based JIT compiler, a Clang-based module for embedding C/C++ codes in Dao, and a Clang-based tool for automatic binding generation from C/C++ header files
I don't know the first thing about Dao, but I'm always interested in any environment that makes embedding/extending easier. When you're working with a 15 year old code base, it's a lot cheaper to embed existing libraries into a new system than it is to re-write them. (Or, add new capabilities to a old system via extending).
Alas, there has never been a language where this capability doesn't end up being an absolute CM nightmare.
See, you want the ones that write quality code and test-drive the crap out of everything so they don't have to put in 15 hour days to make the latest milestone.
Yes, exactly. So that when the inevitable mid-project changes to requirements, scope, and/or milestones happen, they'll be better able to cope with throwing away all that up-front planning and preparation -- and start working 15 hour per day to meet the new deadlines.
I know that Python is much better than a lot of other languages for integrating C/C++ code. But in the end, if you're doing production systems, you'll end up getting bitten by some unforeseen incompatibility caused by some upgrade somewhere.
If the company you work for is large enough to have an "IT Department", then the company you work for is too large, period. It's time to go find a job in a smaller company.
Oh and don't bother if you're not a regex guru too.
Look, I'm sorry, but if you don't know regexes, then you really don't have any business being a system administrator. I certainly wouldn't hire you.
If by "socialism" you mean "corporate socialism", then we agree.
I bet HF trading ends up being a prime market for this technology.
I still don't buy your premise that Macbook Pros with external boxes for these sorts of things are going to be common.
Maybe, maybe not. I know of several audio professionals that use a MBP as their main workstation -- and when necessary, they simply unhook it and take it with them for remote recording.
Typically, you'll be using 96kHz @ 24 bits for tracking and mixing (and these days, mastering, too). Add to that digital mixers, multiple sends and receives, multiple audio interfaces, STEM sends, etc., and the bandwidth consumption really starts to add up.
And this doesn't even touch on video.
What PCIe cards are you plugging in again?
http://www.uaudio.com/uad-plug...
http://www.uaudio.com/interfac... (with optional thunderbolt interface).
http://www.presonus.com/produc...
http://createdigitalmusic.com/...
For pro video and pro audio use cases, outboard processing equipment is a necessity, especially if your workstation is a laptop. Which these days is often the case. I consider thunderbolt and external PCI chassis to be one of the best things since sliced bread.
And, for what it's worth, firewire is still very popular in the pro video and pro audio world.
Um, so how does one break into this dull field?
I would love to see the code running in handheld GPS units that first find a variable number of satellites and then calculate the latitude, longitude, and elevation of the unit.
No you don't. Trust me, you'll be very disappointed.
The article suggest that one solution is to simply not do GC until the end of the trading day. I have to admit that's a good pragmatic solution, certainly so for HF prop traders.
Not enough memory on your servers? Add more. Still not enough? Add even more. The cost would be a pittance for any prop trading company worth its salt.
If a syadmin is abusing their position of power then they need to be removed.
Aye, but how do you know when they're abusing their position of power? Tread lightly out there.
I don't know the first thing about Dao, but I'm always interested in any environment that makes embedding/extending easier. When you're working with a 15 year old code base, it's a lot cheaper to embed existing libraries into a new system than it is to re-write them. (Or, add new capabilities to a old system via extending).
Alas, there has never been a language where this capability doesn't end up being an absolute CM nightmare.
boost.function, boost.asio, boost.optional, boost.foreach, boost.shared_ptr, boost.ptr_container
start using those libraries (at a minimum), and C++ coding starts to become as easy as scripting. Of course, you'd have to learn C++ first.
See, you want the ones that write quality code and test-drive the crap out of everything so they don't have to put in 15 hour days to make the latest milestone.
Yes, exactly. So that when the inevitable mid-project changes to requirements, scope, and/or milestones happen, they'll be better able to cope with throwing away all that up-front planning and preparation -- and start working 15 hour per day to meet the new deadlines.
If you want server-side javascript, then why not just use node.js, like everyone else is doing?
Marfa is where hipsters go to be alone.
emacs
FTA sidebar:
In Austin, a year with only 4.6 days exceeding 95 degrees would be a miracle indeed!
In conclusion, downtown L.A., here I come!
Integrated multi-language solutions are teh suck.
I know that Python is much better than a lot of other languages for integrating C/C++ code. But in the end, if you're doing production systems, you'll end up getting bitten by some unforeseen incompatibility caused by some upgrade somewhere.
It will happen.
Ah, grasshopper, you haven't yet learned the truism that states: your customers hate you and want you to fail.
If you want to put those FLAC downloads on your iOS device, keep in mind that FLAC to ALAC is easy-peasy using ffmpeg. It even preserves the tags.
You can't possibly call yourself a programmer if your code can't recover from a hardware fault.
A quick rule of thumb:
If the company you work for is large enough to have an "IT Department", then the company you work for is too large, period. It's time to go find a job in a smaller company.
I think you missed "firewall" when I typed "NATing firewall".
Just guessing.
If your home linux desktop isn't behind a NATing firewall, then your home setup is not correct.