While I know it would never happen, I would love to see the FCC get involved in this. Spectrum is kinda their domain and stingray was messing it up, so this is a good example of one agency giving another a bit of a black eye. I would totally chip in some popcorn and a comfy couch for watching that fight.
I take it you did not live in one of the regions that had DSL covered under Title II? The number of options and price ranges were far wider than today since Verizon was required to lease its lines, allowing 3rd parties to actually exist. When the FCC pulled them off the regulation, competition and options vanished almost overnight.
This is not far off how it used to be. Years back Verizon DSL was covered under Title II. They provided the lines, but you could choose any one of dozens of ISPs to actually buy your service from. It was wonderful.
The problem with elegant code is more often than not 'elegance' is rooted in how similar it is to what the reader has read before as opposed to objective measures. One only has to go to a meeting where people argue about what coding standard a project should use to see 'but this is so much more readable!' is all its arbitrary glory.
While I would not describe it as a religious issue, I would describe it as a cultural issue just as much as an experienced/engineering one. Experience is rooted in what has been done, so often it can be pretty reactionary regarding what mistakes have gone out of style and which ones have been forgotten long enough to be acceptable again.
This is why I tend to point to Java's dependency injection as an example of the pendulum swinging too far the other way. Much of it was developed as a reaction to what was being done at the time, but also in the faded memories of what was done before that...
I think the key piece is 'it depends on what you are writing'. Use of 3rd party solutions or internally developed ones is something that needs to be evaluated on a case by case basis, with various cultures and companies within tech, all too often, defaulting to one path or the other. I tend to feel that the pendulum has swung a bit too much, with 'not invented here' becoming such a boogie man that an increasing number of projects and defaulting to using external dependencies unless you can justify breaking away from that.
In modern development one can go through an entire project without using any of the language's standard libraries or even, in extreme cases, the language itself. If you ever want to see a frightening example of this gone too far, take a look at over uses of Apache Camel or even Spring, where you can write entire systems using code embedded in XML files and that weird 'conditional logic as constructor arguments' camel allows for.
Even worse, when the framework is so general that there is really no envisioned usage outside 'all the things!' and you end up with something that requires just as much glue code as working with the standard API would have since it is no more special purposed than the original.
Sadly, it did not take a day. I really felt that the solution was not only more complicated but took longer to implement and test than the internal coding option would have. Granted the two approaches were not tried in parallel, but the amount of time and effort that was eaten up by taking the dependency injection route seemed quite excessive given the complexity of the problem being solved.
One example that really drove me crazy was a developer who was tasked with putting in a 'retry' mechanic. Rather than simply working with the socket he pulled in some spring library that altered the socket behavior according to an external XML file and was praised by the lead for doing it this way. The code (java + XML) was several times longer than it would have been otherwise, plus a new library had to be included in the build/distribution, but it was still 'proper'. I think that was the breaking point for me working on that project.
I do not see this topic brought up nearly as much, which worries me. I have worked on quite a few projects where the unwillingness to write functionality internally lead to excessive testing of external options and overuse of generic frameworks which not only increased the dependency/complexity of the project but often required just as many lines of code to use as just writing our own damn module would have.
It feels like this is worst in the Java (enterprise) community, but that could be my imagination. Sometimes I think those programmers need their 3rd party instantiation taken away from them....
And crap, looks like I have been moved over to slashdot-beta so I will probably never see if I get responses....
What does being in the computer industry for 20 years have to do with knowing the history of CS? Very few CS programs have any coursework on history, and it is not a topic that is highly covered in industry. Working in tech might give one a default knowledge of products and technologies developed during their time in industry, but even that is going to be limited to a person's specific subdomain unless they are actually independently interested in learning deeper history.
As another poster pointed out, it is about power rather than constancy. Baptizing dogs or trees is not worth it since there is no additional power to be gained over either in doing so. A strong AI on the other hand provides a significant incentive for some parties to assign it a soul since doing so opens up their ability to influence its thoughts and assumptions.
On the other hand, it is fun to overthink things. I also work in AI but find these discussions fascinating since they do not really have obvious answers and are a good way to explore the human condition separated from, well, humans.
Religion, in general though, is not just about 'who created who', but comprises an entire moral, philosophical, historical, and metaphysical structure.
The only place I can really see this making sense would be rural or otherwise fairly remote/sparse areas, kinda like the old book-mobiles except mobile manufacturing. In those situations, a couple hours to print might be better than the days or weeks shipping might take, with the added bonus that you could move around and serve a wider area. However as a general rule regions like that have very poor economies (or at least very limited), and thus the economics of having a fleet of these things serving them probably would not make sense.
True, at the moment they are still somewhat disapointing, but that is to be expected when you are scaling machines that just a few years cost tens of thousands of dollars down to something consumers can play with.
Though one irony is that much of the tech that is going into them was developed for situations where CNC machines were not versatile as people hoped and they needed new tools.
On the other hand, there are entities out there who's entire business is R&D who then license their work to companies that build actual products. It is important to keep these types of entities in mind since their specialization on IP is a net benefit and they depend on patent law to keep their customers honest.
I am not really understanding what the point of making the fabrication itself mobile, other than not having to pay rent on dedicated facilities. They would still have to have some kind of depot for the raw materials, so why have all the extra weight of driving around the equipment? Esp since you could not print while driving since that would really screw up the accuracy.
Slashdot Mirror
While I know it would never happen, I would love to see the FCC get involved in this. Spectrum is kinda their domain and stingray was messing it up, so this is a good example of one agency giving another a bit of a black eye. I would totally chip in some popcorn and a comfy couch for watching that fight.
Level playing fields are for commies.
No, robber barons generally sent someone to your house too. They were more powerful than local government in many regions.
I take it you did not live in one of the regions that had DSL covered under Title II? The number of options and price ranges were far wider than today since Verizon was required to lease its lines, allowing 3rd parties to actually exist. When the FCC pulled them off the regulation, competition and options vanished almost overnight.
This is not far off how it used to be. Years back Verizon DSL was covered under Title II. They provided the lines, but you could choose any one of dozens of ISPs to actually buy your service from. It was wonderful.
The problem with elegant code is more often than not 'elegance' is rooted in how similar it is to what the reader has read before as opposed to objective measures. One only has to go to a meeting where people argue about what coding standard a project should use to see 'but this is so much more readable!' is all its arbitrary glory.
While I would not describe it as a religious issue, I would describe it as a cultural issue just as much as an experienced/engineering one. Experience is rooted in what has been done, so often it can be pretty reactionary regarding what mistakes have gone out of style and which ones have been forgotten long enough to be acceptable again.
This is why I tend to point to Java's dependency injection as an example of the pendulum swinging too far the other way. Much of it was developed as a reaction to what was being done at the time, but also in the faded memories of what was done before that...
I think the key piece is 'it depends on what you are writing'. Use of 3rd party solutions or internally developed ones is something that needs to be evaluated on a case by case basis, with various cultures and companies within tech, all too often, defaulting to one path or the other. I tend to feel that the pendulum has swung a bit too much, with 'not invented here' becoming such a boogie man that an increasing number of projects and defaulting to using external dependencies unless you can justify breaking away from that.
Yep, you are that old ^_~
In modern development one can go through an entire project without using any of the language's standard libraries or even, in extreme cases, the language itself. If you ever want to see a frightening example of this gone too far, take a look at over uses of Apache Camel or even Spring, where you can write entire systems using code embedded in XML files and that weird 'conditional logic as constructor arguments' camel allows for.
Even worse, when the framework is so general that there is really no envisioned usage outside 'all the things!' and you end up with something that requires just as much glue code as working with the standard API would have since it is no more special purposed than the original.
Sadly, it did not take a day. I really felt that the solution was not only more complicated but took longer to implement and test than the internal coding option would have. Granted the two approaches were not tried in parallel, but the amount of time and effort that was eaten up by taking the dependency injection route seemed quite excessive given the complexity of the problem being solved.
One example that really drove me crazy was a developer who was tasked with putting in a 'retry' mechanic. Rather than simply working with the socket he pulled in some spring library that altered the socket behavior according to an external XML file and was praised by the lead for doing it this way. The code (java + XML) was several times longer than it would have been otherwise, plus a new library had to be included in the build/distribution, but it was still 'proper'. I think that was the breaking point for me working on that project.
Keep in mind that there was no 'original path' in christianity, it began as a highly fractured system and never really fully centralized.
To be fair, quite a few religions grew out of not being controlled, so they can also be a counter to such structures.
I do not see this topic brought up nearly as much, which worries me. I have worked on quite a few projects where the unwillingness to write functionality internally lead to excessive testing of external options and overuse of generic frameworks which not only increased the dependency/complexity of the project but often required just as many lines of code to use as just writing our own damn module would have.
It feels like this is worst in the Java (enterprise) community, but that could be my imagination. Sometimes I think those programmers need their 3rd party instantiation taken away from them....
And crap, looks like I have been moved over to slashdot-beta so I will probably never see if I get responses....
What does being in the computer industry for 20 years have to do with knowing the history of CS? Very few CS programs have any coursework on history, and it is not a topic that is highly covered in industry. Working in tech might give one a default knowledge of products and technologies developed during their time in industry, but even that is going to be limited to a person's specific subdomain unless they are actually independently interested in learning deeper history.
As another poster pointed out, it is about power rather than constancy. Baptizing dogs or trees is not worth it since there is no additional power to be gained over either in doing so. A strong AI on the other hand provides a significant incentive for some parties to assign it a soul since doing so opens up their ability to influence its thoughts and assumptions.
On the other hand, it is fun to overthink things. I also work in AI but find these discussions fascinating since they do not really have obvious answers and are a good way to explore the human condition separated from, well, humans.
Religion, in general though, is not just about 'who created who', but comprises an entire moral, philosophical, historical, and metaphysical structure.
Silicon Hell, along with all the photocopiers.
The only place I can really see this making sense would be rural or otherwise fairly remote/sparse areas, kinda like the old book-mobiles except mobile manufacturing. In those situations, a couple hours to print might be better than the days or weeks shipping might take, with the added bonus that you could move around and serve a wider area. However as a general rule regions like that have very poor economies (or at least very limited), and thus the economics of having a fleet of these things serving them probably would not make sense.
True, at the moment they are still somewhat disapointing, but that is to be expected when you are scaling machines that just a few years cost tens of thousands of dollars down to something consumers can play with.
Though one irony is that much of the tech that is going into them was developed for situations where CNC machines were not versatile as people hoped and they needed new tools.
*shrug* I have seen them at work and used in prototyping, have for years. The consumer ones are still VERY new and hardly a mass or stable market.
On the other hand, there are entities out there who's entire business is R&D who then license their work to companies that build actual products. It is important to keep these types of entities in mind since their specialization on IP is a net benefit and they depend on patent law to keep their customers honest.
I am not really understanding what the point of making the fabrication itself mobile, other than not having to pay rent on dedicated facilities. They would still have to have some kind of depot for the raw materials, so why have all the extra weight of driving around the equipment? Esp since you could not print while driving since that would really screw up the accuracy.