It makes it easier for the independent houses to produce complete software packages, making it a viable proposition, so they don't have to sell up to bigger companies.
A BSD license doesn't result in "increasing concentration of copyrights... in the hands of the big". Think about it -- if their products are based on BSD materials, then they actually have a smaller copyright portfolio, because a lot of their code is exactly the same as that of free alternatives. The difference between their product and the free alternative is dramatically lessened. Moreover, if they want to profit from ongoing community improvements to the code base, they cannot fork the product too radically. In the end, the commercial houses have to decide between sustaining a minor commercial advantage (minimal forking, but easier for the free alternative to catch up) or go for a major differentiation that prevents them drawing on the open source version anyway.
BSD means proprietary software houses get something for free -- that cannot be denied. But I just do not believe it gives them a commercial advantage. I will say again that BSD removes the commercial advantage of big companies (ie. massive established codebase) thereby favouring the small houses and independent commercial coders.
My point isn't that the independents stay small and keep going, but that there is a constant stream of new independents , the most notable of which are founded by senior devs who leave the big corporate studios seeking creative freedom. Yes, their studios often get bought out, but there'll be another independent studio along five minutes later to fill the gap.
The small are eventually and inexorably sold to the large. at least those that succeed...
But is this truly inevitable, or is it a consequence of the current market ecosystem? It takes an awful lot of work (=time and money) to get a full product up and running. By the time they hit the market, a great many small companies are up to their eyeballs in debt, and selling up is the only way to pay off the creditors.
If you look at computer gaming, it's reached a sort of equilibrium between large software houses and independents, because while EA and their ilk are constantly buying up the independent dev outfits, devs keep leaving the big houses to set up new independent studios. But these independent studios don't normally write full products from the ground up, instead licensing commercial engines to take a lot of the "heavy lifting" out of the dev work. Are you aware of any compiler architecture that is commercially available to all comers in the same way as Unity or Source? It doesn't happen, because IBM, Microsoft etc don't want the competition. GPL software doesn't fill that gap either.
The democratic will of the populace? Proportional representation? The Libdems got 22% of the seats with 23% of the votes, so they have every right to vote the way they were elected to vote.
This comes from his belief that proprietary closed source software is dangerous and should be fought. So he is just being consistent. You may disagree with his assumption (I disagree at least with part of his ideas as well), but you can't say that his posture is inconsistent with his beliefs.
The problem with his belief system is a failure to make a distinction between the big software houses and the small, independent outfits. He lumps them together under the evil banner.
The GPL as it stands is actually helping the big guys beat out the small guys. How can a new entrant hope to build a compiler stack that can take on IBM, Microsoft et al, who have a vast base of legacy code to draw from? He can't. He can't build it off GCC, or he loses control. But someone can now build an innovative tool to replace one bit of the LLVM stack, sell it at a reasonable price (and not coupled to a particular IDE) and make a good living.
Isn't it better to support a diverse market of little guys than have three or four mega-vendors?
(And if it's OK, I'd like to plug my own blog post on the topic. If it's not OK, feel free to mod me down as spam...)
So you're saying they should've subverted democracy by helping push a party into power that only got 29% of the vote rather than one that got 36% of the vote? You may not like the Tories but they got the support they needed to be the party that got first dibs on government.
"Subverted democracy"? How so? You are represented by your MP. I am represented by my MP. Our MPs form collectives called parties, and are free to change party as their conscience demands during their elected term.
Now would you suggest it is "subverting democracy" when Labour vote against Tory policies, because they are voting "against the will of the majority"? Surely it is more a "subversion" of democracy when an MP votes in direct contravention of their manifesto promises...?
Sorry, but it's not "democratic" for MPs to vote in direct contravention to the wishes of the people who elected them in order to represent the people who didn't. There are policies that can be horse-traded against each other, but there are some that have to be a line in the sand. Tuition fees were a key manifesto promise for the Libdems, and bowing on that one destroyed their credibility with the electorate. They couldn't have imposed their policy on the Tories, but they could have opposed Tory policy completely.
> Programmers, as a rule, are obsessed with the notion of "human-readable code" and the plain-text editor.
It always amuses me that certain old-school programmers shit on Python's significant whitespace, touting the flexibility of C formatting because whitespace is not significant... then rant and rave about "correct" indentation, the placement of curly brackets, whether there should be a space before the '(' in a function call, etc.
You can't eat your cake and still have it. If you want insignificant whitespace, shut up about nonstandardized formatting.
Way to miss my point entirely. And before slagging people off for being "old-school", why not first get into the 21st century and stop coding in a 1960s programming paradigm that assumes fixed-width fonts?
My entire point was that both sides of this argument are wrong, because we can use computers to take out the heavily lifting.
Modern code editors already have sophisticated lexers and parsers, so let's leave the editor to automatically lay the code out based on syntax. That way I can have spaces between my functions and brackets if I want, and when you load up my code, you won't need to see them (because your preferences say that's not your choice of layout). And while we're at it, we can start using proportional fonts, thus increasing the amount of visual information available and making code more readable.
The problem is, "making things easier" often means "giving you enough rope to hang yourself". Inheritance reduces readability of code, because individual objects no longer contain the full description of their public interface.
I never really got the point of OO when I was at university, but now I'm working in a problem domain that is ideally suited to OO. But when I go to look at what I can do with a given object, I have to manually go back through the inheritance tree to look for all the methods and attributes of the class. Worse still is multiple inheritance, cos you've got to go back to the language spec multiple times to make sure you're doing your tree traversals the same way as the compiler.
OO means that the data and methods go together. All the other various definitions and techniques branch out from there.
That's certainly a basis for OO, but without inheritance, it just isn't OO.
Nope. All modern OO systems may employ inheritance, but the single core concept that defines object orientation is that the program must consist of "objects" that manage their own data and their own behaviour. How they do that is up to them.
Inheritance is a natural consequence of OO, and I would agree that designing an OO language without it would be a stupid move, but it is not core to OO.
Personally, I wish that inheritance had to be manually specified, eg ChildClass.method = ParentClass.method, because while it seems like extra work to start off with, automatic inheritance means that object definitions are not self-documenting, and because multiple-inheritance often results in unclear dependencies.
Sorry, that's nonsense. The iOS market continues to grow. That the rate of growth is slowing is different from "shrinking" by a long margin.
Android owns the vast majority of that market and is growing rapidly (very rapidly in China and other emerging markets).
Android handset sales have overtaken iOS according to many figures, but that's only half the story -- many cheap Android handsets will never get any extra apps installed on them, instead being little more than "phone with web browser" in the eyes of their owners. Android development is also hampered by the complexity of support on a massively heterogenous platform. Google are slowly abstracting away hardware issues, but there are hundreds of vastly different hardware configurations out there running multiple subtly different Android builds, compared to a couple of dozen highly similar iOS hardware devices, most of which are running one of the two latest iterations of the OS at any given time.
There was a huge exodus from Android apps development a few years back, when software houses realised that Android support was not only eating into their Android profits, but stealing their iOS profits.
I hate to be the bearer of bad news (I am certainly no Apple fanboy -- I got given an iPad as a present and was really annoyed about not being able to even load music onto it from Linux) but that's the way it is. I'm hoping to get an application into development for mobile shortly, and it's the Android compatibility issues that are my worst fear at the moment....
Backend is node.js. It doesn't block, which makes it faster.
Are you using a Dragon 32 as a webserver or something? If you tried running something with a pre-emptive multitasking operating system, you'd find that blocking hasn't been a big deal since the 1990s....
The significant whitespace thing being an issue is pretty amusing to me after all these years. Admittedly I held a little of that in my early years, but the real eye opener for me came down to the active reuse of code in all of the various languages. I primarily used with C/C++ for a long time and every other snippet I came across had some readily apparent, though small, difference in the syntactic formatting. It's not something that will jump out right away, but when you get to maintaining a project of significant size it can be a significant hindrance to readability when the various sections of code are not formatted using the same guidelines. At that point, it becomes almost necessary to run any foreign addition through a beautifier that gets it almost to your specification. I feel like the significant whitespace thing wasn't new with Python, that's just one major place where they recognized the value of codifying it into the language.
Guido was right about the problem of actual syntactic blocks vs perceived syntactic blocks (ie when whitespace implies blocks that the braces don't), but I still think his solution was the wrong one.
Programmers, as a rule, are obsessed with the notion of "human-readable code" and the plain-text editor. And yet, most use IDEs that do indentation and syntax highlighting automatically. If our code editors all understand the meaning of block delimiters, why not just write editors that automatically format the code's visual formatting based on the syntax? Heck, they already do this, indenting after { and dedenting after }, but they do so in terms of "human-readable" indentation (ie. adding multiple whitespace characters to the source file), and they allow the coder to override the settings. Why? Why not just have the editor force correct indentation based on block delimiters?
Besides, Guido cheated. He stated that there were no block delimiters, but that's not true. There is no end delimiter for blocks, but every block starts with a colon. "No," you may say, "that's part of the statement before." In terms of the language's definition, that is technically true, but as all of the statements that it follows are logically quite different (at least three types: class and function definitions, conditionals, loops), it is easier for the programmer to generalise the colon to mean "start of block" than to mean "end of three-eight different things", and the human brain is wired to eliminate unnecessary complexity.
Also, new technologies are highly overrated. 98% of them will go by the wayside in a few years, and you don't want to waste your time becoming an expert in the newest square wheel.
Yes, but the technologies all embody certain concepts and paradigms, and the useful language to learn is the one that teaches you the most about the specific problem domain. Python, for instance, is a general purpose programming language and teaches nothing about the web -- all its web features are tacked on via libraries. This means it doesn't teach "web thinking". Sadly, this is probably true of most web technologies, as they were mostly written by C coders....
You should probably re-examine old English before making such a stupid statement. Start with the number of borrows.
The problem with that statement is that "English" and "Old English" are two different languages. The Old English spelling system may have been largely phonetic and/or phonemic, but Modern English suffers badly from an increasing disjunction between written and spoken forms, making many words damn-near ideographic.
The English spelling system is phonemic (NB: not phonetic) in origin, but in its modern form it is the least phonetic and the least phonemic alphabetic orthography I know of. (Except possibly Faroese, which was designed to highlight Old Norse etymology during an era where history and misguided notions of linguistic purity were used by anyone and everyone to justify why their language and people were superior to everyone else.)
I don't think that's the "add to it" bit -- he called the most powerful man on the planet an idiot, and got locked up for it. Even the Catholic church itself tacitly acknowledges that the Holy Roman Empire was a disaster, and that it shouldn't be directly involved in government or politics. To this day, members of the clergy aren't allowed to stand for political office or join politically active societies.
Later we learned stuff like Columbus was the one to figure out the earth is round, which is made up. The resistance to his journey was that he might not find land before reaching Africa (they didn't know the map), in which case the expedition would have starved to death before arriving. This was too great a risk compared to the price of the expedition.
It was more than that -- we had known the circumference of the Earth to a surprising degree of accuracy for almost two millenia before Columbus set off. We know that this hadn't been forgotten as there are pre-Columban maps that depict the known lands as a projection from a globe, and the area of the globe missing for them takes up the angle you would expect the western Atlantic, America and the eastern Pacific to fill up.
In light of all that, I find it almost impossible to believe that Columbus didn't know America was there -- he did not have enough food and water to cross all the way to China in one go, so even if he was looking for a passage to India, he must have been expecting to make landfall on the way to restock.
A lot of the historical confusion may well come from nomenclature. They keep saying that Columbus sailed for "India", but the talk was of "The Indies", which was originally anything from India eastwards. Was the term used geographically at the time, or was it a socio-political term for a territory deemed ripe for colonisation?
No, fair enough, I'm not. But then again, we're not talking about industrial manufacture here, but home fabbing.
Whether you start with the block or the cast part, you're still going to need a CNC milling machine, so sandcasting is actually more expensive, because you're not working on the scale where the reduction in metal wastage and cutting bit replacement is going to make up for the extra cost of building a high-temperature foundry in your back garden. As such, 3D printing makes the whole process more complicated and expensive.
3D printers aren't going to help, because printing is an additive process. Machining engine parts is subtractive manufacture, and CNC tools are already available for machining such parts.
Look, you have to remember that, in a capitalist system, the question of physical presence is hardly the point: they charge a price, you decide if it's fair. If the cost of the base model is inflated, compared to the competition, due to the extra hardware, then just buy the competition instead. If the price is comparable, then how exactly is it skin off your nose if they include disabled extras?
If I get a 2 litre engine block software-restricted to 1.6l equivalent power output, I still have that heavier lump of metal under the bonnet. If I carry around heated seats that I can never turn on, the extra weight still consumes more petrol. Such a system is inherently inefficient.
Yes, but having the confidence to actually go and do something useful is in itself a privilege. The reason so many (socially and economically) underprivileged kids fail at school is because others expect little of them, and they learn to expect little of themselves.
This just doesn't hold up in a society of "participation trophies" and valuing a child's self-esteem and confidence over everything else in school. We did that experiment. It solved none of society's ills. Time to admit it was a mistake and move all.
That's not the same thing at all -- it's a horrible charicature of it.
The psychologists looked in the school environment and saw that every mistake drew the teacher's attention and disapproval, while most successes passed without comment. This meant that kids were more aware of their failings than their strengths, and grew despondent. I don't remember the exact figures, but it was something along the lines of kids who got 75% of answers right in tests saw themselves as only getting 50% right. Intelligent kids thought they were thick. Psychologists simply told teachers that they should provide positive emotional feedback when kids get things right -- no more impassive "yes... yes... correct... right" followed by a deeply disapproving "no!", but "yes" with a smile, "perfect!", "that's right!"
The pedagogues messed up the message entirely, because doing what the psychologists asked is actually pretty hard. You try nodding enthusiastically and smiling every time a pupil or student gets an extremely simple question right. As a teacher, you always feel under pressure to get the simple stuff out of the way so that you can move on to the more important stuff, and it's easy to forget that what seems simple to you is completely new to them, and the simple stuff actually is the most important stuff.
Participation certificates are a cheap and easy way for the teacher to pretend that they're giving positive emotional feedback, but it misses the point: in order to encourage children, you have to reward successes as and when they happen, as the child will be conditioned to seek the reward and the feeling of achievement. If the "reward" is not given as and when the success occurs, the child is not taught to seek the reward through succeeding. So no, the experiment has not been done yet.
Slashdot Mirror
It makes it easier for the independent houses to produce complete software packages, making it a viable proposition, so they don't have to sell up to bigger companies.
A BSD license doesn't result in "increasing concentration of copyrights... in the hands of the big". Think about it -- if their products are based on BSD materials, then they actually have a smaller copyright portfolio, because a lot of their code is exactly the same as that of free alternatives. The difference between their product and the free alternative is dramatically lessened. Moreover, if they want to profit from ongoing community improvements to the code base, they cannot fork the product too radically. In the end, the commercial houses have to decide between sustaining a minor commercial advantage (minimal forking, but easier for the free alternative to catch up) or go for a major differentiation that prevents them drawing on the open source version anyway.
BSD means proprietary software houses get something for free -- that cannot be denied. But I just do not believe it gives them a commercial advantage. I will say again that BSD removes the commercial advantage of big companies (ie. massive established codebase) thereby favouring the small houses and independent commercial coders.
My point isn't that the independents stay small and keep going, but that there is a constant stream of new independents , the most notable of which are founded by senior devs who leave the big corporate studios seeking creative freedom. Yes, their studios often get bought out, but there'll be another independent studio along five minutes later to fill the gap.
The small are eventually and inexorably sold to the large. at least those that succeed...
But is this truly inevitable, or is it a consequence of the current market ecosystem? It takes an awful lot of work (=time and money) to get a full product up and running. By the time they hit the market, a great many small companies are up to their eyeballs in debt, and selling up is the only way to pay off the creditors.
If you look at computer gaming, it's reached a sort of equilibrium between large software houses and independents, because while EA and their ilk are constantly buying up the independent dev outfits, devs keep leaving the big houses to set up new independent studios. But these independent studios don't normally write full products from the ground up, instead licensing commercial engines to take a lot of the "heavy lifting" out of the dev work. Are you aware of any compiler architecture that is commercially available to all comers in the same way as Unity or Source? It doesn't happen, because IBM, Microsoft etc don't want the competition. GPL software doesn't fill that gap either.
The democratic will of the populace? Proportional representation? The Libdems got 22% of the seats with 23% of the votes, so they have every right to vote the way they were elected to vote.
This comes from his belief that proprietary closed source software is dangerous and should be fought. So he is just being consistent. You may disagree with his assumption (I disagree at least with part of his ideas as well), but you can't say that his posture is inconsistent with his beliefs.
The problem with his belief system is a failure to make a distinction between the big software houses and the small, independent outfits. He lumps them together under the evil banner.
The GPL as it stands is actually helping the big guys beat out the small guys. How can a new entrant hope to build a compiler stack that can take on IBM, Microsoft et al, who have a vast base of legacy code to draw from? He can't. He can't build it off GCC, or he loses control. But someone can now build an innovative tool to replace one bit of the LLVM stack, sell it at a reasonable price (and not coupled to a particular IDE) and make a good living.
Isn't it better to support a diverse market of little guys than have three or four mega-vendors?
(And if it's OK, I'd like to plug my own blog post on the topic. If it's not OK, feel free to mod me down as spam...)
So you're saying they should've subverted democracy by helping push a party into power that only got 29% of the vote rather than one that got 36% of the vote? You may not like the Tories but they got the support they needed to be the party that got first dibs on government.
"Subverted democracy"? How so? You are represented by your MP. I am represented by my MP. Our MPs form collectives called parties, and are free to change party as their conscience demands during their elected term.
Now would you suggest it is "subverting democracy" when Labour vote against Tory policies, because they are voting "against the will of the majority"? Surely it is more a "subversion" of democracy when an MP votes in direct contravention of their manifesto promises...?
Sorry, but it's not "democratic" for MPs to vote in direct contravention to the wishes of the people who elected them in order to represent the people who didn't. There are policies that can be horse-traded against each other, but there are some that have to be a line in the sand. Tuition fees were a key manifesto promise for the Libdems, and bowing on that one destroyed their credibility with the electorate. They couldn't have imposed their policy on the Tories, but they could have opposed Tory policy completely.
> Programmers, as a rule, are obsessed with the notion of "human-readable code" and the plain-text editor.
It always amuses me that certain old-school programmers shit on Python's significant whitespace, touting the flexibility of C formatting because whitespace is not significant... then rant and rave about "correct" indentation, the placement of curly brackets, whether there should be a space before the '(' in a function call, etc.
You can't eat your cake and still have it. If you want insignificant whitespace, shut up about nonstandardized formatting.
Way to miss my point entirely. And before slagging people off for being "old-school", why not first get into the 21st century and stop coding in a 1960s programming paradigm that assumes fixed-width fonts?
My entire point was that both sides of this argument are wrong, because we can use computers to take out the heavily lifting.
Modern code editors already have sophisticated lexers and parsers, so let's leave the editor to automatically lay the code out based on syntax. That way I can have spaces between my functions and brackets if I want, and when you load up my code, you won't need to see them (because your preferences say that's not your choice of layout). And while we're at it, we can start using proportional fonts, thus increasing the amount of visual information available and making code more readable.
The problem is, "making things easier" often means "giving you enough rope to hang yourself". Inheritance reduces readability of code, because individual objects no longer contain the full description of their public interface.
I never really got the point of OO when I was at university, but now I'm working in a problem domain that is ideally suited to OO. But when I go to look at what I can do with a given object, I have to manually go back through the inheritance tree to look for all the methods and attributes of the class. Worse still is multiple inheritance, cos you've got to go back to the language spec multiple times to make sure you're doing your tree traversals the same way as the compiler.
Define "OO techniques".
OO means that the data and methods go together. All the other various definitions and techniques branch out from there.
That's certainly a basis for OO, but without inheritance, it just isn't OO.
Nope. All modern OO systems may employ inheritance, but the single core concept that defines object orientation is that the program must consist of "objects" that manage their own data and their own behaviour. How they do that is up to them.
Inheritance is a natural consequence of OO, and I would agree that designing an OO language without it would be a stupid move, but it is not core to OO.
Personally, I wish that inheritance had to be manually specified, eg ChildClass.method = ParentClass.method, because while it seems like extra work to start off with, automatic inheritance means that object definitions are not self-documenting, and because multiple-inheritance often results in unclear dependencies.
iOS is a shrinking market (not growing as fast).
Sorry, that's nonsense. The iOS market continues to grow. That the rate of growth is slowing is different from "shrinking" by a long margin.
Android owns the vast majority of that market and is growing rapidly (very rapidly in China and other emerging markets).
Android handset sales have overtaken iOS according to many figures, but that's only half the story -- many cheap Android handsets will never get any extra apps installed on them, instead being little more than "phone with web browser" in the eyes of their owners. Android development is also hampered by the complexity of support on a massively heterogenous platform. Google are slowly abstracting away hardware issues, but there are hundreds of vastly different hardware configurations out there running multiple subtly different Android builds, compared to a couple of dozen highly similar iOS hardware devices, most of which are running one of the two latest iterations of the OS at any given time.
There was a huge exodus from Android apps development a few years back, when software houses realised that Android support was not only eating into their Android profits, but stealing their iOS profits.
I hate to be the bearer of bad news (I am certainly no Apple fanboy -- I got given an iPad as a present and was really annoyed about not being able to even load music onto it from Linux) but that's the way it is. I'm hoping to get an application into development for mobile shortly, and it's the Android compatibility issues that are my worst fear at the moment....
Backend is node.js. It doesn't block, which makes it faster.
Are you using a Dragon 32 as a webserver or something? If you tried running something with a pre-emptive multitasking operating system, you'd find that blocking hasn't been a big deal since the 1990s....
The significant whitespace thing being an issue is pretty amusing to me after all these years. Admittedly I held a little of that in my early years, but the real eye opener for me came down to the active reuse of code in all of the various languages. I primarily used with C/C++ for a long time and every other snippet I came across had some readily apparent, though small, difference in the syntactic formatting. It's not something that will jump out right away, but when you get to maintaining a project of significant size it can be a significant hindrance to readability when the various sections of code are not formatted using the same guidelines. At that point, it becomes almost necessary to run any foreign addition through a beautifier that gets it almost to your specification. I feel like the significant whitespace thing wasn't new with Python, that's just one major place where they recognized the value of codifying it into the language.
Guido was right about the problem of actual syntactic blocks vs perceived syntactic blocks (ie when whitespace implies blocks that the braces don't), but I still think his solution was the wrong one.
Programmers, as a rule, are obsessed with the notion of "human-readable code" and the plain-text editor. And yet, most use IDEs that do indentation and syntax highlighting automatically. If our code editors all understand the meaning of block delimiters, why not just write editors that automatically format the code's visual formatting based on the syntax? Heck, they already do this, indenting after { and dedenting after }, but they do so in terms of "human-readable" indentation (ie. adding multiple whitespace characters to the source file), and they allow the coder to override the settings. Why? Why not just have the editor force correct indentation based on block delimiters?
Besides, Guido cheated. He stated that there were no block delimiters, but that's not true. There is no end delimiter for blocks, but every block starts with a colon. "No," you may say, "that's part of the statement before." In terms of the language's definition, that is technically true, but as all of the statements that it follows are logically quite different (at least three types: class and function definitions, conditionals, loops), it is easier for the programmer to generalise the colon to mean "start of block" than to mean "end of three-eight different things", and the human brain is wired to eliminate unnecessary complexity.
Also, new technologies are highly overrated. 98% of them will go by the wayside in a few years, and you don't want to waste your time becoming an expert in the newest square wheel.
Yes, but the technologies all embody certain concepts and paradigms, and the useful language to learn is the one that teaches you the most about the specific problem domain. Python, for instance, is a general purpose programming language and teaches nothing about the web -- all its web features are tacked on via libraries. This means it doesn't teach "web thinking". Sadly, this is probably true of most web technologies, as they were mostly written by C coders....
Or ... don't learn about technology. If you're interested in it, you'll learn anyways.
Digging the logic there. How about... don't read Slashdot. If you're interested in it, you'll read anyways.
You get my point, I hope...
You should probably re-examine old English before making such a stupid statement. Start with the number of borrows.
The problem with that statement is that "English" and "Old English" are two different languages. The Old English spelling system may have been largely phonetic and/or phonemic, but Modern English suffers badly from an increasing disjunction between written and spoken forms, making many words damn-near ideographic.
The English spelling system is phonemic (NB: not phonetic) in origin, but in its modern form it is the least phonetic and the least phonemic alphabetic orthography I know of. (Except possibly Faroese, which was designed to highlight Old Norse etymology during an era where history and misguided notions of linguistic purity were used by anyone and everyone to justify why their language and people were superior to everyone else.)
Then to add to it he openly mocked the pope,
I don't think that's the "add to it" bit -- he called the most powerful man on the planet an idiot, and got locked up for it. Even the Catholic church itself tacitly acknowledges that the Holy Roman Empire was a disaster, and that it shouldn't be directly involved in government or politics. To this day, members of the clergy aren't allowed to stand for political office or join politically active societies.
Later we learned stuff like Columbus was the one to figure out the earth is round, which is made up. The resistance to his journey was that he might not find land before reaching Africa (they didn't know the map), in which case the expedition would have starved to death before arriving. This was too great a risk compared to the price of the expedition.
It was more than that -- we had known the circumference of the Earth to a surprising degree of accuracy for almost two millenia before Columbus set off. We know that this hadn't been forgotten as there are pre-Columban maps that depict the known lands as a projection from a globe, and the area of the globe missing for them takes up the angle you would expect the western Atlantic, America and the eastern Pacific to fill up.
In light of all that, I find it almost impossible to believe that Columbus didn't know America was there -- he did not have enough food and water to cross all the way to China in one go, so even if he was looking for a passage to India, he must have been expecting to make landfall on the way to restock.
A lot of the historical confusion may well come from nomenclature. They keep saying that Columbus sailed for "India", but the talk was of "The Indies", which was originally anything from India eastwards. Was the term used geographically at the time, or was it a socio-political term for a territory deemed ripe for colonisation?
JavaScript was the "hot" back-end technology about 4-5 years ago. At that time, most devs have concluded that it's not so hot after all.
FTFY
If you're going to correct someone's English, do it right. Because now you look like a fool.
I take it your not familiar with manufacturing.
No, fair enough, I'm not. But then again, we're not talking about industrial manufacture here, but home fabbing.
Whether you start with the block or the cast part, you're still going to need a CNC milling machine, so sandcasting is actually more expensive, because you're not working on the scale where the reduction in metal wastage and cutting bit replacement is going to make up for the extra cost of building a high-temperature foundry in your back garden. As such, 3D printing makes the whole process more complicated and expensive.
3D printers aren't going to help, because printing is an additive process. Machining engine parts is subtractive manufacture, and CNC tools are already available for machining such parts.
Look, you have to remember that, in a capitalist system, the question of physical presence is hardly the point: they charge a price, you decide if it's fair. If the cost of the base model is inflated, compared to the competition, due to the extra hardware, then just buy the competition instead. If the price is comparable, then how exactly is it skin off your nose if they include disabled extras?
If I get a 2 litre engine block software-restricted to 1.6l equivalent power output, I still have that heavier lump of metal under the bonnet. If I carry around heated seats that I can never turn on, the extra weight still consumes more petrol. Such a system is inherently inefficient.
Yes, but having the confidence to actually go and do something useful is in itself a privilege. The reason so many (socially and economically) underprivileged kids fail at school is because others expect little of them, and they learn to expect little of themselves.
This just doesn't hold up in a society of "participation trophies" and valuing a child's self-esteem and confidence over everything else in school. We did that experiment. It solved none of society's ills. Time to admit it was a mistake and move all.
That's not the same thing at all -- it's a horrible charicature of it.
The psychologists looked in the school environment and saw that every mistake drew the teacher's attention and disapproval, while most successes passed without comment. This meant that kids were more aware of their failings than their strengths, and grew despondent. I don't remember the exact figures, but it was something along the lines of kids who got 75% of answers right in tests saw themselves as only getting 50% right. Intelligent kids thought they were thick. Psychologists simply told teachers that they should provide positive emotional feedback when kids get things right -- no more impassive "yes... yes... correct... right" followed by a deeply disapproving "no!", but "yes" with a smile, "perfect!", "that's right!"
The pedagogues messed up the message entirely, because doing what the psychologists asked is actually pretty hard. You try nodding enthusiastically and smiling every time a pupil or student gets an extremely simple question right. As a teacher, you always feel under pressure to get the simple stuff out of the way so that you can move on to the more important stuff, and it's easy to forget that what seems simple to you is completely new to them, and the simple stuff actually is the most important stuff.
Participation certificates are a cheap and easy way for the teacher to pretend that they're giving positive emotional feedback, but it misses the point: in order to encourage children, you have to reward successes as and when they happen, as the child will be conditioned to seek the reward and the feeling of achievement. If the "reward" is not given as and when the success occurs, the child is not taught to seek the reward through succeeding. So no, the experiment has not been done yet.
Sounds more like the Simpsons' Comic Book Guy to me....