Your type safety only goes away only if you shoot yourself in the foot in the first place. Yes, I can break some generic code by overriding an interface in a way that completely subverts it. But I can also, say, feed a call counting function to a sorting routine that, instead of comparing two elements, returns true if the number of calls is even, and false if it's odd, and make the sorter fail. Oh noes, I was malicious and I broke code! This happens if your language is object oriented, procedural or purely functional.
All we really have to do, in any language paradigm is to make code sufficiently clear as to minimize the chances of your average dev to break interface contracts accidentally.
When using a review system like this, few things are more valuable to a manager than some really terrible employees.
Imagine I have 2 amazing developers in my team and 3 very good ones, and the ranking system is going to force me to give one a bad review: It will not only make that one very good developer mad, but sour things for the other two, that have to keep beating the poor sob I randomly chose as the one getting the bad review. However, what if I transfer one of my very good developers to a different team in exchange for a worthless chump? Give the chump nothing important to do, and then the rest of your team can continue unhindered and unafraid of getting an awful review just because they are associated with a competitive team.
I used to work at a place like this. If a new hire was just way too good, he was moved to a different team that had lost a top performer, and team quality was kept relatively even: We had to protect the good developers we had. Any team that was too good just had to be split up, or they'd quit anyway.
The webview component is, in the end, yet another target browser with its own set of inconsistencies and problems. The guy in the next office has been having all kinds of fun trying to use the webview component in a swing app, using an embedded javafx scene: Javascript components that work fine in, say, firefox, have rendering problems in the web view that make pages utterly unusable.
As a UI developer, I find ScalaFX and GroovyFX to be infants, concerned too much about layout, and not about the things that really make UI development challenging. In my latest Scala and JavaFX toy project, I felt I was far better off using the Java interface and using Scala for the things it really does well.
Also, JavaFX is still in its infancy, so it's still a very hard sell for production applications. The architecture is very clear, but extremely verbose. The components that are there are beautiful, but severely lacking in features: Want any interaction whatsoever with the chart component, for instance? You have to build it all from scratch. The grid component has less features than even web grids. Investing in it now is like investing in Swing in the early years: You end up having to write all kinds of code for generic stuff you shouldn't, and then spend money removing your customizations if the standard components ever get better.
If Oracle actually cared about JavaFX, it has to mature far faster than it's doing now.
Bad pyros are horrible for a team, and most Pyros are bad.
Now, someone that has no problems reflecting rockets, understands that pyros can't charge straight against a team, and can pick off medics in the chaos of close quarters combat is welcome in any team.
The used market softens the ridiculous price of games when they come out. If Joe buys a game for $60, and resells it for $10, , he can use those $10 to buy another game. If reselling used games becomes impossible, then Joe might be short $10 the next time he tries to buy a new game, and will not be able to afford it. He could just wait until it's on sale.
The one place where the game industry loses is because of the friction of the used market: The cut that the intermediaries take. If they want to make that friction go away, why not allow reselling of games, right within their platforms? Why not lower prices to spur sales at full price. I sure have not bought a game for $60 in many years.
And then there's also the model followed by this guy called Gabe Newell. The best ROI his company ever got did not come from extremely expensive games that people can't resell. It came from making a game free to play, and instead of making people pay to get advantages in game, he just got his Australian sidekick to sell digital hats. Since people loved the game, they also bought the hats for Gabe's free game.
But it's easier to blame piracy, or used games, or the Wicked Witch of the West than it is to build a very solid product first and figure out how to get paid later.
Re:Such systems have been proposed before
on
The Zuckerberg Tax
·
· Score: 1
You are expecting people to never be able to leave the country?
Make a billion dollars in the US. Move to Aruba, and spend it there. Tax avoidance FTW!
Dynamically typed languages almost demand a large unit test suite to minimize quality issues. TDD and all that. If you are going to do that anyway, the dynamic language's weaknesses don't come into play as much, and you get the advantages, like typically needing a whole lot less code to get the same thing done. Look at Groovy, for instance: You can typically reproduce a Java program in half the code, and that if you are not facing one of those problems where dynamic typing really makes your life dramatically easier.
But you do not find that MBA thought at every firm. Chances are that low level management still came from the field, and it's their job to ask for the people they need. If the higher level manager doesn't trust the staffing advice he gets, chances are he'll lose the expertise, and the company becomes a cesspool.
The company where the people that do the job have a say will hire a good mix between 60K rookies and 150K senior staff, get rid of the senior people that are not pulling their weight at all, and be productive.
Not everyone with 20 years of experience is worth the 150K. Proper personnel management is all about figuring out when you need the top level expertise, and to to realize when your 150K senior employee is not helping you do the best work possible, but running your organization into the ground.
There are mistakes, which is why stores have physical inventories every so often: Being off by 2% of your inventory is not really all that strange. Barcode scanners fail, stickers in cases are wrong, returns aren't processed correctly, shrinkage... errors happen.
And there are costs for getting local inventories on the web: Many systems still only rely inventory data to the central servers on a daily basis, instead of doing so constantly. Some stores do this extremely well, others not so much. Either way, hooking it all up to the forward website means a whole lot more reads that such DBs are used to getting: Operational databases and sales sites tend to be separate. The warehouse's system and the online inventory aren't necessarily 100% in synch, much less so each of 500+ retail stores. This is why some stores have a 'likely in stock' category when giving online inventory status to cover their asses.
Still, every corporate culture is different: Some are all about in store pickups nowadays, while others would much rather provide as little brick and mortar information as possible, other than the store location, and if an item can be carried in stores or is online-only.
Better than most? True. But The Economist is known for horrible pro-city hack jobs. There's plenty of topics where reading the Economist without three teaspoons of salt will leave you with a very skewed view of issues.
It's not about what the richest eats, but about what the man on the street eats. There are great restaurants in Washington DC, but the food your average American eats is still chain made shit. From that perspective, the UK is not exactly at the top of the heap.
For good food for the common man, go to Mediterranean countries.
While there's a lot of value to NGDP, it is awful to compare different country's actual economic performance, as it makes no effort to separate inflation from the increase of other economic activities.
Most of the differences that you see there can be explained by just monetary policy. As the Fed, and then the ECB, became terrified of inflation, the NGDP dropped like a rock. China meanwhile runs expansionary policies and is not afraid of inflation.
Zimbabwe would have crushed all of those in NGDP growth rates in all three decades, but it's not exactly a country you'd consider an economic success.
1 second is still a disaster for complex sites: You load the page. The page includes some javascript file. Said javascript file includes some more. Then it makes a couple dozen web service calls... and that's if we hope the browser is smart enough to request every link in the page at once.
I've seen many a custom business apps that was tested with pings of 0-10 be a bit slow with 80s, and a total disaster when used from another continent. A 1 second ping makes a connection from the US to India seem like a LAN.
And that is why we are seeing pretty decent sales for cheaper indie games, or for regular games at very discounted prices on downloading platforms that know what they are doing.
When it comes to piracy, listen to Gaben. Valve has no piracy problems for a reason.
Unauthorized downloads are very different from, say, selling a program as your creation. In this case, we are dealing with just copying apps without permission, so you are comparing apples and oranges.
Massive Illegal immigration? Welcome to the late 90s, when the US had a ton of jobs. The raise in unemployment in the US has dropped illegal immigration to a trickle.
Random mutation? That's not how now GMO breeding works at all. Proper breeding technology requires no trans species genes at all. Taking existing seeds and using modern mechanisms to figure out their genotypes and trying to obtain natural cross breeding that generates better yielding crop is perfectly legal in most places that are against GMO. In fact, it'd be very difficult to breed edible corn at all without doing such things.
If you looked at the beeding process of a seed company that deals in GMOs, a very large percentage of the process is still the same tried and true mechanisms that have been followed forever, just with more expensive methods of determining the best seeds.
And there's the beautiful vudu advertisment feature: If you have a single episode of a series in a network drive, there is no view out there that will show you just what you have: If Vudu sells the rest of the episodes, they will show up on your screen, and there will always be a link to download from them, even if you already ripped the dvds.
And the lack of UI customization makes it so that if you have a different use for the box than their idea of a norm, you are out of luck: For example, they have a parental controls feature (which is no good, BTW), and do not provide a simple way to just display a specific list of movies. I want to be able to say: Tyke, you go here, and here are your cartoons: It's not an issue of forbidding content, but make the content he actually wants to be more convenient. Instead, we either need multi login, which is stupid, or use the pre-defined genre filters, which are as accurate as a drunk grandmother with a.44.
I would much rather have a phone-sized device that has internet access almost anywhere but cannot make phone calls to a phone that has no real internet access.
On an average month, I might use 5 phone minutes. Data? Well over a gig.
But you can still get screwed over by a maniac. How do protect yourself from someone going over a median? How do you protect yourself from getting rear ended by a semi at a traffic light? How do you use any defensive driving techniques when in heavy traffic?
Many risks can be mitigated, but there are accidents you could have never avoided if you were told about it 3 seconds before it happened.
Nah, agile provides gains compared to many other methodologies, but for two reasons: -It does its best at avoiding retarder requirements processes that lead to spending way too much time rewriting code or programming secondary features -Provides practices that help team cohesion, which in turn lower turnover.
Too many employers have insane requirement processes and have nobody that works on the same team for more than a year. By just avoiding said demons, agile will provide improvements. If you already have a team that works together instead of as a set of separate individuals that just happen to work on the same codebase, and get to talk to your users/customers, you've already way ahead of the curve.
I have seen the negative value developer in the past: Someone who created more bugs than he fixed, and when given new functionality, it'd be harder to figure out how exactly it was going to fail on you and fix it than to just throw it all away and write it all from scratch.
Now, what people don't realize is that the real reason only 10 lines remain even for average programmers is that the hard part of most business software is requirements. It is not hard to generate requirements: The difficult part is to make sure the requirements really fit the need, and are understood by the developers. I have spent a lot of time over my career ripping apart code that made assumptions that were not true even before the program was launched, or tied together concepts that should have never been combined. I have seen the core of an inventory system rewritten 6 times before it was ever used.
The best programmer is not one that can write the most code in a day, but the one that knows the right questions to ask when handed a problem, makes high quality assumptions, and writes code that is readable and ready for change.
Enough turnover makes the creator make no difference. Employee driven turnover tends to come in waves. One day you have a team of 4. 2 weeks later half the team has gone to a place that pays better. You hire replacements, but the team chemistry is sunk: The other two original members leave within 3 months. Now you have a team with 2 people with little experience on the application, and are fumbling to have them train replacements.
To protect yourself, you must work so hard on knowledge sharing that the development speed becomes glacial.
First, enough turnover will always kill you no matter your procedures. If a team turns over 75% of its developers in 6 months, there's nothing to be done. So step 1: make sure your developers don't want to quit.
But even if you are using TDD or BDD, even a bit of sloppiness here and there can still leave you with a very hard to solve puzzle. Maybe a unit test isn't maintained well enough, and it passes even though the code isn't really doing what the test description said. It keeps passing for a year. Then, you go back, and a change makes the unit test go back towards its originally intended codepath and starts failing. But at that point, we do not know anymore if the releases for the last year have been bad, the requirements were bad in the first place, or what. All it takes is the right kind of slip up. And even with the best intentions, there's always slip ups.
Slashdot Mirror
Your type safety only goes away only if you shoot yourself in the foot in the first place. Yes, I can break some generic code by overriding an interface in a way that completely subverts it. But I can also, say, feed a call counting function to a sorting routine that, instead of comparing two elements, returns true if the number of calls is even, and false if it's odd, and make the sorter fail. Oh noes, I was malicious and I broke code! This happens if your language is object oriented, procedural or purely functional.
All we really have to do, in any language paradigm is to make code sufficiently clear as to minimize the chances of your average dev to break interface contracts accidentally.
When using a review system like this, few things are more valuable to a manager than some really terrible employees.
Imagine I have 2 amazing developers in my team and 3 very good ones, and the ranking system is going to force me to give one a bad review: It will not only make that one very good developer mad, but sour things for the other two, that have to keep beating the poor sob I randomly chose as the one getting the bad review. However, what if I transfer one of my very good developers to a different team in exchange for a worthless chump? Give the chump nothing important to do, and then the rest of your team can continue unhindered and unafraid of getting an awful review just because they are associated with a competitive team.
I used to work at a place like this. If a new hire was just way too good, he was moved to a different team that had lost a top performer, and team quality was kept relatively even: We had to protect the good developers we had. Any team that was too good just had to be split up, or they'd quit anyway.
The webview component is, in the end, yet another target browser with its own set of inconsistencies and problems. The guy in the next office has been having all kinds of fun trying to use the webview component in a swing app, using an embedded javafx scene: Javascript components that work fine in, say, firefox, have rendering problems in the web view that make pages utterly unusable.
As a UI developer, I find ScalaFX and GroovyFX to be infants, concerned too much about layout, and not about the things that really make UI development challenging. In my latest Scala and JavaFX toy project, I felt I was far better off using the Java interface and using Scala for the things it really does well.
Also, JavaFX is still in its infancy, so it's still a very hard sell for production applications. The architecture is very clear, but extremely verbose. The components that are there are beautiful, but severely lacking in features: Want any interaction whatsoever with the chart component, for instance? You have to build it all from scratch. The grid component has less features than even web grids. Investing in it now is like investing in Swing in the early years: You end up having to write all kinds of code for generic stuff you shouldn't, and then spend money removing your customizations if the standard components ever get better.
If Oracle actually cared about JavaFX, it has to mature far faster than it's doing now.
Bad pyros are horrible for a team, and most Pyros are bad.
Now, someone that has no problems reflecting rockets, understands that pyros can't charge straight against a team, and can pick off medics in the chaos of close quarters combat is welcome in any team.
The used market softens the ridiculous price of games when they come out. If Joe buys a game for $60, and resells it for $10, , he can use those $10 to buy another game. If reselling used games becomes impossible, then Joe might be short $10 the next time he tries to buy a new game, and will not be able to afford it. He could just wait until it's on sale.
The one place where the game industry loses is because of the friction of the used market: The cut that the intermediaries take. If they want to make that friction go away, why not allow reselling of games, right within their platforms? Why not lower prices to spur sales at full price. I sure have not bought a game for $60 in many years.
And then there's also the model followed by this guy called Gabe Newell. The best ROI his company ever got did not come from extremely expensive games that people can't resell. It came from making a game free to play, and instead of making people pay to get advantages in game, he just got his Australian sidekick to sell digital hats. Since people loved the game, they also bought the hats for Gabe's free game.
But it's easier to blame piracy, or used games, or the Wicked Witch of the West than it is to build a very solid product first and figure out how to get paid later.
You are expecting people to never be able to leave the country?
Make a billion dollars in the US. Move to Aruba, and spend it there. Tax avoidance FTW!
Dynamically typed languages almost demand a large unit test suite to minimize quality issues. TDD and all that. If you are going to do that anyway, the dynamic language's weaknesses don't come into play as much, and you get the advantages, like typically needing a whole lot less code to get the same thing done. Look at Groovy, for instance: You can typically reproduce a Java program in half the code, and that if you are not facing one of those problems where dynamic typing really makes your life dramatically easier.
But you do not find that MBA thought at every firm. Chances are that low level management still came from the field, and it's their job to ask for the people they need. If the higher level manager doesn't trust the staffing advice he gets, chances are he'll lose the expertise, and the company becomes a cesspool.
The company where the people that do the job have a say will hire a good mix between 60K rookies and 150K senior staff, get rid of the senior people that are not pulling their weight at all, and be productive.
Not everyone with 20 years of experience is worth the 150K. Proper personnel management is all about figuring out when you need the top level expertise, and to to realize when your 150K senior employee is not helping you do the best work possible, but running your organization into the ground.
There are mistakes, which is why stores have physical inventories every so often: Being off by 2% of your inventory is not really all that strange. Barcode scanners fail, stickers in cases are wrong, returns aren't processed correctly, shrinkage... errors happen.
And there are costs for getting local inventories on the web: Many systems still only rely inventory data to the central servers on a daily basis, instead of doing so constantly. Some stores do this extremely well, others not so much. Either way, hooking it all up to the forward website means a whole lot more reads that such DBs are used to getting: Operational databases and sales sites tend to be separate. The warehouse's system and the online inventory aren't necessarily 100% in synch, much less so each of 500+ retail stores. This is why some stores have a 'likely in stock' category when giving online inventory status to cover their asses.
Still, every corporate culture is different: Some are all about in store pickups nowadays, while others would much rather provide as little brick and mortar information as possible, other than the store location, and if an item can be carried in stores or is online-only.
Better than most? True. But The Economist is known for horrible pro-city hack jobs. There's plenty of topics where reading the Economist without three teaspoons of salt will leave you with a very skewed view of issues.
It's not about what the richest eats, but about what the man on the street eats. There are great restaurants in Washington DC, but the food your average American eats is still chain made shit. From that perspective, the UK is not exactly at the top of the heap.
For good food for the common man, go to Mediterranean countries.
While there's a lot of value to NGDP, it is awful to compare different country's actual economic performance, as it makes no effort to separate inflation from the increase of other economic activities.
Most of the differences that you see there can be explained by just monetary policy. As the Fed, and then the ECB, became terrified of inflation, the NGDP dropped like a rock. China meanwhile runs expansionary policies and is not afraid of inflation.
Zimbabwe would have crushed all of those in NGDP growth rates in all three decades, but it's not exactly a country you'd consider an economic success.
1 second is still a disaster for complex sites: You load the page. The page includes some javascript file. Said javascript file includes some more. Then it makes a couple dozen web service calls... and that's if we hope the browser is smart enough to request every link in the page at once.
I've seen many a custom business apps that was tested with pings of 0-10 be a bit slow with 80s, and a total disaster when used from another continent. A 1 second ping makes a connection from the US to India seem like a LAN.
And that is why we are seeing pretty decent sales for cheaper indie games, or for regular games at very discounted prices on downloading platforms that know what they are doing.
When it comes to piracy, listen to Gaben. Valve has no piracy problems for a reason.
Unauthorized downloads are very different from, say, selling a program as your creation. In this case, we are dealing with just copying apps without permission, so you are comparing apples and oranges.
Massive Illegal immigration? Welcome to the late 90s, when the US had a ton of jobs. The raise in unemployment in the US has dropped illegal immigration to a trickle.
Random mutation? That's not how now GMO breeding works at all. Proper breeding technology requires no trans species genes at all. Taking existing seeds and using modern mechanisms to figure out their genotypes and trying to obtain natural cross breeding that generates better yielding crop is perfectly legal in most places that are against GMO. In fact, it'd be very difficult to breed edible corn at all without doing such things.
If you looked at the beeding process of a seed company that deals in GMOs, a very large percentage of the process is still the same tried and true mechanisms that have been followed forever, just with more expensive methods of determining the best seeds.
And there's the beautiful vudu advertisment feature: If you have a single episode of a series in a network drive, there is no view out there that will show you just what you have: If Vudu sells the rest of the episodes, they will show up on your screen, and there will always be a link to download from them, even if you already ripped the dvds.
And the lack of UI customization makes it so that if you have a different use for the box than their idea of a norm, you are out of luck: For example, they have a parental controls feature (which is no good, BTW), and do not provide a simple way to just display a specific list of movies. I want to be able to say: Tyke, you go here, and here are your cartoons: It's not an issue of forbidding content, but make the content he actually wants to be more convenient. Instead, we either need multi login, which is stupid, or use the pre-defined genre filters, which are as accurate as a drunk grandmother with a .44.
I would much rather have a phone-sized device that has internet access almost anywhere but cannot make phone calls to a phone that has no real internet access.
On an average month, I might use 5 phone minutes. Data? Well over a gig.
But you can still get screwed over by a maniac. How do protect yourself from someone going over a median? How do you protect yourself from getting rear ended by a semi at a traffic light? How do you use any defensive driving techniques when in heavy traffic?
Many risks can be mitigated, but there are accidents you could have never avoided if you were told about it 3 seconds before it happened.
Nah, agile provides gains compared to many other methodologies, but for two reasons:
-It does its best at avoiding retarder requirements processes that lead to spending way too much time rewriting code or programming secondary features
-Provides practices that help team cohesion, which in turn lower turnover.
Too many employers have insane requirement processes and have nobody that works on the same team for more than a year. By just avoiding said demons, agile will provide improvements. If you already have a team that works together instead of as a set of separate individuals that just happen to work on the same codebase, and get to talk to your users/customers, you've already way ahead of the curve.
I have seen the negative value developer in the past: Someone who created more bugs than he fixed, and when given new functionality, it'd be harder to figure out how exactly it was going to fail on you and fix it than to just throw it all away and write it all from scratch.
Now, what people don't realize is that the real reason only 10 lines remain even for average programmers is that the hard part of most business software is requirements. It is not hard to generate requirements: The difficult part is to make sure the requirements really fit the need, and are understood by the developers. I have spent a lot of time over my career ripping apart code that made assumptions that were not true even before the program was launched, or tied together concepts that should have never been combined. I have seen the core of an inventory system rewritten 6 times before it was ever used.
The best programmer is not one that can write the most code in a day, but the one that knows the right questions to ask when handed a problem, makes high quality assumptions, and writes code that is readable and ready for change.
Enough turnover makes the creator make no difference. Employee driven turnover tends to come in waves. One day you have a team of 4. 2 weeks later half the team has gone to a place that pays better. You hire replacements, but the team chemistry is sunk: The other two original members leave within 3 months. Now you have a team with 2 people with little experience on the application, and are fumbling to have them train replacements.
To protect yourself, you must work so hard on knowledge sharing that the development speed becomes glacial.
First, enough turnover will always kill you no matter your procedures. If a team turns over 75% of its developers in 6 months, there's nothing to be done. So step 1: make sure your developers don't want to quit.
But even if you are using TDD or BDD, even a bit of sloppiness here and there can still leave you with a very hard to solve puzzle. Maybe a unit test isn't maintained well enough, and it passes even though the code isn't really doing what the test description said. It keeps passing for a year. Then, you go back, and a change makes the unit test go back towards its originally intended codepath and starts failing. But at that point, we do not know anymore if the releases for the last year have been bad, the requirements were bad in the first place, or what. All it takes is the right kind of slip up. And even with the best intentions, there's always slip ups.