Pull requests are also massively useful for a corporate environment. They allow you to easily integrate code changes from teams (or contractors) that don't have write access to the origin repo.
As someone who uses git in a traditional corporate environment... I would never go back to SVN. Yes, there is a learning curve, but it's so worth it. Even if you don't use any of git's features, the speed increase alone is worth the change.
Sounds like that old Ford commercial
on
The New PHP
·
· Score: 1
Fiat is rolling out there electric 500 to California, supposedly with a lease price of $199 a month. The lease price includes 15 days of gas car rental per year included. Sounds like a pretty awesome deal to me.
Hipsters didn't kill non-networked code. Amazon did. No manager is going to shell out for a big iron Sun box these days when your "scientific, financial, engineering" analysis code can run on a couple dozen ec2 nodes for a quarter of the price.
I'm a software engineer. I only use my laptop (13" MacBook Pro, usually hooked up to a full size monitor and keyboard) for actual programming or other "work" stuff. I use my tablet for pretty much everything else, browsing, shopping, email, games. Heck, I even recently downsized from an iPad2 to a Nexus 7. I even use the nexus 7 for email while I'm at work and the MacBook is right in front of me.
I think the primary goal should be too identify what problems the customer is having, not what solution they want. Observer the client and figure out their problems. It's the development companies job to figure out the best solution. When I say 'problems' I don't mean things like "I don't like that I have to use 2 screens to do y". I mean thing like "our shipping process takes too long and losses too many packages".
So what if it's written down? No one in close proximity to my computer is trying to hack me. I'm not scared of my family or co-workers getting my credentials. I'm afraid of a remote attacker compromising the server where the credentials are stored.
Carbon fiber doesn't really dent. I'm guessing you'd either have no damage or a crack, and not really any state in between. If it's just a body panel that doesn't have any structural purpose, small and medium cracks could probably be repaired with epoxy, which would most likely be cheaper than repairing a dent. The crack may cause a reduction in capacity, but I doubt it would know the whole thing off line.
The vast majority of people doing data-intensive code with Python are either running code that is distributed across many nodes, where shared memory threads aren't very useful, or don't really care about execution time. I doubt a GILless cPython will ever come out, because it would require a massive amount of work and would provide little value to most existing Python users. People who need threads are already using other technologies, and I doubt many would switch back to Python just for that feature alone.
The core areas where Python is popular are all areas where threading is not very useful, either because the code is executed in a distributed fashion across many nodes (scientific computing, big data, web), because there are better concurrency paradigms (asynchronous networking), or because it's used for small scripting tasks that execute within a couple of minutes (system admin, text parsing, web scraping). Not surprisingly, Python isn't very popular for the type of tasks where threading is advantageous (games, desktop apps). I don't think there is much motivation to remove the GIL because it would require an almost complete rewrite of cPython and provide very little benefit to existing users in Python's core competency areas.
Yeah, there is no way the legal department in the company I work for would allow us to use a software library with no license. Of course, we may be willing to pay you for a license, but I think it would still slow the adoption of your project significantly.
I've used JS for many large projects. JS is vastly different from Perl in the fact that it has well defined behavior (unlike Perl 6, Javascript is based on an actual spec that you can go read) and JS is a compile target of more expressive languages. I would say the future is probably going to be transpiling to JS.
A big problem with JS is no built in namespaces/modularity, but that is somewhat easily fixed with libraries like require.js. I think the lack of a decent standard library is a greater problem, because every framework out there duplicates the same stuff. Common.js is trying to solve this, but hasn't been terribly successful so far. I think people who complain about asynchronous operations and prototype based inheritance are just stuck in their ways, because these methods offer a lot of advantages over more traditional class based oop languages.
immutable source code?
The problem with this is that someone will inevitably add new calls to the old function (with it's broken behavior), even if it's marked as deprecated.
Slashdot Mirror
Pull requests are also massively useful for a corporate environment. They allow you to easily integrate code changes from teams (or contractors) that don't have write access to the origin repo.
git is massively faster. Checkouts that take 2 hours with SVN take 10 minutes with git.
As someone who uses git in a traditional corporate environment... I would never go back to SVN. Yes, there is a learning curve, but it's so worth it. Even if you don't use any of git's features, the speed increase alone is worth the change.
Have you coded PHP lately?
FYI: the FDIC doesn't insure most fiat currency exchange accounts either.
It can definitely be more concise than that. See functional programs that don't even have the (for in) construct.
I can't imagine trying to make comprehensible diff view between versions of a visual programming language.
Fiat is rolling out there electric 500 to California, supposedly with a lease price of $199 a month. The lease price includes 15 days of gas car rental per year included. Sounds like a pretty awesome deal to me.
Hipsters didn't kill non-networked code. Amazon did. No manager is going to shell out for a big iron Sun box these days when your "scientific, financial, engineering" analysis code can run on a couple dozen ec2 nodes for a quarter of the price.
I'm a software engineer. I only use my laptop (13" MacBook Pro, usually hooked up to a full size monitor and keyboard) for actual programming or other "work" stuff. I use my tablet for pretty much everything else, browsing, shopping, email, games. Heck, I even recently downsized from an iPad2 to a Nexus 7. I even use the nexus 7 for email while I'm at work and the MacBook is right in front of me.
I think the primary goal should be too identify what problems the customer is having, not what solution they want. Observer the client and figure out their problems. It's the development companies job to figure out the best solution. When I say 'problems' I don't mean things like "I don't like that I have to use 2 screens to do y". I mean thing like "our shipping process takes too long and losses too many packages".
So what if it's written down? No one in close proximity to my computer is trying to hack me. I'm not scared of my family or co-workers getting my credentials. I'm afraid of a remote attacker compromising the server where the credentials are stored.
Well, lets says it's 5 mpg * 20 gallons, I would say you'd get around 100 miles in a stock street legal sports car.
yes, but communication could be possible. Especially using quantum entanglement for ftl communication.
If the batteries are part of the structure, they may be significantly lighter, which will give the car better performance and more range.
Carbon fiber doesn't really dent. I'm guessing you'd either have no damage or a crack, and not really any state in between. If it's just a body panel that doesn't have any structural purpose, small and medium cracks could probably be repaired with epoxy, which would most likely be cheaper than repairing a dent. The crack may cause a reduction in capacity, but I doubt it would know the whole thing off line.
HFT algos aren't making bets on equity price movements. They're usually using sophisticated methods of finding and exploiting arbitrage opportunities.
Whatever you think of HFT, this tech sounds awesome and may have other interesting applications.
The vast majority of people doing data-intensive code with Python are either running code that is distributed across many nodes, where shared memory threads aren't very useful, or don't really care about execution time. I doubt a GILless cPython will ever come out, because it would require a massive amount of work and would provide little value to most existing Python users. People who need threads are already using other technologies, and I doubt many would switch back to Python just for that feature alone.
They still aren't full lambdas, since you can't mutate closed variables inside of the inner function.
Use coffeescript instead?
The core areas where Python is popular are all areas where threading is not very useful, either because the code is executed in a distributed fashion across many nodes (scientific computing, big data, web), because there are better concurrency paradigms (asynchronous networking), or because it's used for small scripting tasks that execute within a couple of minutes (system admin, text parsing, web scraping). Not surprisingly, Python isn't very popular for the type of tasks where threading is advantageous (games, desktop apps). I don't think there is much motivation to remove the GIL because it would require an almost complete rewrite of cPython and provide very little benefit to existing users in Python's core competency areas.
Yeah, there is no way the legal department in the company I work for would allow us to use a software library with no license. Of course, we may be willing to pay you for a license, but I think it would still slow the adoption of your project significantly.
I've used JS for many large projects. JS is vastly different from Perl in the fact that it has well defined behavior (unlike Perl 6, Javascript is based on an actual spec that you can go read) and JS is a compile target of more expressive languages. I would say the future is probably going to be transpiling to JS. A big problem with JS is no built in namespaces/modularity, but that is somewhat easily fixed with libraries like require.js. I think the lack of a decent standard library is a greater problem, because every framework out there duplicates the same stuff. Common.js is trying to solve this, but hasn't been terribly successful so far. I think people who complain about asynchronous operations and prototype based inheritance are just stuck in their ways, because these methods offer a lot of advantages over more traditional class based oop languages.
immutable source code? The problem with this is that someone will inevitably add new calls to the old function (with it's broken behavior), even if it's marked as deprecated.