Computers in schools have been a colossal waste of money. In the 'computer lab' you spend years upon years 'learning Word' and typing.
In school, using computers I learned BASIC programming, Logo, the relation between frequency and musical notes, binary arithmetic, and quite a lot else -- and that's just 4th through 6th grade, in the 1980s, without the internet (or any other kind of net.) The problem's I've seen in recent years in schools with computers is that we've vastly expanded the number of computers in schools and the percentage of students that have access to them -- but eliminated most of the idea of a coherent, meaningful use of computers to teach anything, other than the use of computers as generic office tools.
Of course, the way public school teachers are compensated or treated, if they had the skills to do anything else, they could make four times as much money with much better non-financial working conditions outside of the schools, so I'm not really surprised; there are still some people out there doing better, but the number of people with both the skills and the willingness to suffer through the environment that school teachers have is small. More computers in more schools won't help without dealing with that issue, and more broadband penetration will only help a little (it'll help some of the places that are doing good in this respect do better).
Mormons have not had plural marriages in well over a century.
If, by "Mormons", you mean only members of the organization known as "the Church of Jesus Christ of Latter-Day Saints", but not any of the many offshoot splinter sects of that group. Since many outside observers refer to offshoot splinter sects that break off of and are out of Communion with the Roman Catholic Church but identify themselves as the "correct" form of the same faith tradition, as "Catholic" groups, its not really that unusual that outside observers might use parallel language in discussing "Mormon" groups.
And once you create that, you lose the multiprocessing advantage you had, and you might as well have used a imperative language in the first place.
That depends on the role of the cell in the algorithm; you most likely lose some, but not all, of that advantage.
Its true that the best algorithms for parallelization may not be the same as the best algorithms not considering parallelization; that doesn't mean FP breaks existing algorithms.
Your idea is not feasible because it screws up too many marketing campaigns.
Actually, the "speed up cores rather than increase the number of them" was the dominant trend, and the center of most marketing campaigns, up until chip manufacturers absolutely couldn't do it anymore without making chips that melted themselves.
After tha, when despite the fact that both engineering efforts and marketingt campaigns had been centered around the GHz race, chip manufacturers realized they needed to go somewhere else, and multiplying cores is what worked.
So saying speeding up cores isn't viable for marketing reasons is completely backwards.
Yea but if you did that, you'd be missing the point.
Right, I don't disagree with that. What I'm saying is the algorithm doesn't "break" because you are using an FP language. You can usually do a fairly direct tranlation of the implementation from another language, or you can do a more idiomatic implementation in the new language, but any algorithm you can use in any other language can be implemented in an FP language.
There may be times when the best algorithm for on in an FP language isn't the best algorithm otherwise (there may be several, e.g., O(n) algorithms available, and the one that has the smallest constant multiplier may change from language to language -- or even from language or library implementation in the same language -- or the expression of one of two equally-performant algorithms may be far simpler in one language, where the other simpler in the other language.)
With functional programming languages make a rather restrictive assumption, and that is all variables are immutable.
This doesn't break algorithms. It just changes the way a particular algorithm will be expressed in code. Any functional language will provide a way to create and access a mutable storage cell, though it may be more programming work to do so than it would be in a language where that was the normal use of a variable.
The bad news? Getting good at functional programming is hard, harder than moving from iterative Pascal or Basic or C coding to object-oriented development.
I suppose its hard for someone whose done lots of lots of programming and none of it in a functional style, much less a functional language, and who is used to artifacts of other languages as if they were fundamental elements of programming.
It's an exaggeration but a useful one: When you move to FP, all your algorithms break.
Algorithms don't break. The algorithms that have a simple, concise realization in an FP language may not be the same ones that do so in, e.g., C, and the implementation of an algorithm, even one that is similarly easy in the FP language and C, may be very different, but changing programming paradigms doesn't do anything remotely like breaking algorithms.
If secret ballots are necessary for a democracy, why do all the elected officials have their votes recorded and published?
Because votes by elected officials are not the votes by the citizens in a democracy, they are acts by which officials represent citizens in the representative form of democracy. Their openness is part of the accountability of the government to the citizens.
Why do we choose secrecy over accuracy?
We don't.
We choose ballot secrecy over ballot openness. The idea that open ballots would lead to more accuracy in practice is a controversial claim that is, in your post, assumed without any support given.
But it is when you give them the real choices of secret ballot with lost votes greater than the margin of victory or loss of a small amount of secrecy to eliminate lost votes.
Well, no, you assume, without support: 1) That that is the real choice (and that there are no other downsides to losing ballot secrecy), and 2) That if people saw that as the real choice, the secret ballot would be controversial.
But, even if those unsupported assumptions are correct, you would still be wrong when you say that the secret ballot is controversial.
Like many things, its good in moderation (for CO2, at the naturally occurring level in the atmosphere.) OTOH, adding CO2 faster than it is taken out of the atmosphere by natural processes is considerably less good; as such, it is "dirty".
However, coal and gas powered things do emit more than CO2 which is bad for the environment.
True. As do oil powered things, though CO2 is the main global threat (most of the other forms of pollution produce effects that, while more severe in the short term, are more localized.)
That's why I don't understand why the Western nations want to cut carbon emissions while givng countries like China, India and Russia a near free pass.
Uh, they don't. OTOH, they do want to reduce global carbon emissions, and given the actual per capita emissions, they don't have any credibility doing that unless the developed countries, which emit more, start the process.
China and India have almost no environmental regulations compared to the US and Western Europe.
True.
Shipping our industry overseas is actually going to increase pollution.
The idea is to make industry cleaner, not ship it overseas.
Complete transparency only seems impossible because right now only a small group of people are watching everyone.
No, it seems impossible because it is.
We don't have a small group of people watching everyone now, we have no one watching everyone and everyone watching what they are interested in within their limits of access. Even if you assume everyone had access to everything (which is unlikely to be practical), you still won't have everyone watching everyone.
It would be orders of magnitude harder to hide constantly something from everyone than it is to hide something from just a small group.
Only if everyone is interested in and looking for it.
Which for almost most things, even things that people would be interested in if they found out about it, wouldn't even be remotely close to the truth.
Even if everyone had access to everything they chose, no one would have the time or ability to integrate information to monitor more than the vanishingly small fraction they were most interested in. And, anyway, without infinite resources, everyone couldn't monitor everything. Because that would require the ability to distribute an infinite amount of information (since the information that person X is monitoring input Y is part of the information flow that must be subject to monitoring, and, on the assumption that everyone is completely monitoring everyone else, must be transmitted to everyone.)
MVC does have a purpose, but it's almost useless in the web context because you can't actually implement it (as it requires a call back from the model to the view, which would typically be javascript running on the client, and therefore can't accept such a call back).
If its JS, rather than just HTML, it could certainly poll a message queue, which (given suitable tolerance for latency) would allow it to accept and respond to callbacks, albeit asynchronously rather than synchronously.
In fact, the only one that I can think of that is purposefully NOT that way is the Ruby on Rails framework which takes the path of "punishment" in the form of "ugly code" for those who attempt to deviate from the orthodoxy of the framework.
This is only true to the extent that one views normal Ruby code as "ugly". Rails doesn't provide any extra elegance to code that doesn't follow its architectural assumptions, but then one could hardly expect it to do so. It doesn't do anything to make such code uglier, except by comparison to the streamlining it provides code that does follow its architectural assumptions.
Old-school developers liek myself have a significant problem with Design Pattern: they're new and confusing names for old ideas. Almost everything in the Gang of Four's book, for example, was some work-around for some limitation of C++.
Some books focus on pattern implementations in particular languages (either explicitly, or implicitly because of the patterns chosen), and tend to focus on patterns that need substantial implementations because the languages on which the book focuses can't implement them in a simple, elegant manner or in a form which is readily adaptable to a library rather than a repeated code pattern.
OTOH, other works focus on design patterns as elements of design (as the name "design patterns" suggests), not in terms of language-centric implementation (though they may provide concrete examples, and may talk about implementation in terms of pattern composition.) A good example of this is Enterprise Integration Patterns.
I'd argue that the latter types of works are the ones which focus on the design patterns as design patterns, and are the ones that actually do help provide a common language for discussing approaches to solving a problem.
4chan'ers harass anonymously, do you think they would be still as willing to do so if you knew who they were? If EVERYONE knew who they were?
Even with total transparency, everyone wouldn't know who they were, since no one could manage all the available information. People who cared would be able to find out, but if the harassers were part of a big enough group with enough resources that it was ineffective for their targets to retaliate against them, they could still get away with a lot. You'd have to do a lot more control with laws rather than privacy, OTOH, if you really had perfect transparency, enforcing those laws would, presumably, be easy.
Of course, without magic, you won't have perfect transparency; the government will always retain the right to keep secrets, and those with sufficient resources will find ways to avoid or spoof attempts at universal monitoring, which will become a tool for the controls of those without resources by those with.
My point is that if people talk about "NuLab" or "Zanu Laour" doing x, y or z then you know they think that the action they are taking are more comparable to IngSoc or Mugabe's ZanuPF as opposed to those of a responsible political party of government in a western democracy.
Yes, and its still flamebait.
If they want to make the argument about what actions are problematic and why those actions are problematic, then they can be part of a decent, productive, substantive discussion.
Everything that is flamebait tells you what someone's opinion of something is. That something is a shorthand way of conveying opinion doesn't stop it from being flamebait.
That something uses incendiary language to simply express a judgement rather than presenting an argument to support the judgement makes it flamebait.
It's a hyperbole and a quick comparison to show your disgust at the action, not a detailed analysis of the situation.
Hyperbolic expressions of disgust are, inherently. flamebait.
You realize that secret ballots aren't part of a democracy.
They are certainly part of a democracy. In fact, they are part of very many democracies.
They are not essential to democracy in theory, though they have proven to of benefit to free and fair elections (without which there is no real democracy) in practice.
They weren't done in the US for about the first 100 years.
True.
No one bought votes or committed fraud any more than now.
I would not agree with that assessment, though the open ballot isn't the sole problem which contributed.
Around the time of the Civil War, there were more voting issues, poll taxes, and voting barriers. One of the barriers was large white men with sticks that would beat you to death if you voted for someone they didn't like. Voting in secret helped get past that.
I would argue that that demonstrates vividly one of the ways the secret ballot has proven essential to free and fair elections, without which any claim to democracy is a sham.
The only reason to keep secret ballots is if you think that people would physically harm you if they could find out who you voted for.
Physical harm is not the only form of retaliation and source of intimidation to be concerned about, but it certainly is the most important one.
Personally, I think the US is past that pettyness
Sure, no one is ever assaulted for their expressed political views in the US.
but then most people that are for secrecy are the people I would be most afraid of.
"Most people that are for secrecy"? That's, in the US at least, not far from a majority of the population, as the secret ballot isn't even a slightly controversial issue in the US.
Eclipse won't let you make an untitled document (at least that I saw), and it drives me mad. It means I can't just open a quick window for jotting something down temporarily, storing some text I've copied and pasted but will overwrite in the clipboard (standard clipboards need to be more like Emacs's kill ring, but that's another topic), etc. without giving that file a place in the file system, which means if I want it to be temporary, I have to go in and delete it.
If you are using the "allocate-before-editing" mechanism, it would make sense to either provide a mechanism for the user to choose to allocate a "scratch" document that will not be preserved (whether it isn't saved at all, or uses whatever the OS provides for allocating and releasing temporary files), or provide a mechanism to abandon-and-delete the file from the editing application (such as a "File -> Abandon" menu option) rather than forcing the user to delete it outside of the application. There's no reason, really, not to provide both options (the latter has use outside of scratch files: deleting a document from the application where you would work with it, rather than the through the file browser or some other tool unrelated to the document, makes a certain kind of sense, IMO.)
The solution to this would be to have the "save document" window come up before you could even type something, like Microsoft Access does. You first put a file name and save location, then you get to work.
Yeah, that model (which is fairly common in applications that "save" incrementally to a database, even if it is a single file database, or to a mutifile structure) is what I was getting at -- there's no reason not to use it for other things, as well; anyhow, the dangerous part (without versioning) is when you are working with a file that has already been saved; if it saved silently on close, you might overwrite when your intent may have been to branch. With versioning-by-default (provided by the app, OS, or file system) this isn't a data loss problem, but without it it could be.
Versioning-by-default combined with name-before-working and automatic, silent save-on-close would, while it would take a little getting used to, probably be a big productivity win, and eliminate common ways to accidentally lose data and the need for application closing nag screens (including the application-close-on-OS-shutdown nag screens.)
Might not be a bad idea, except that when you wanted to find it again you wouldnt have a clue. Okay, maybe YOU would. My mom and the zillion jillion other users like her wouldn't though. So its not just an issue of having enough space to save it, its also helping the user know where to look for it when they want it back next time.
The problem is the default "Untitled" document. If you started without an open document, and created the file when you wanted to start working on it, then you'd know where to find it (particularly if the app or the OS or both has a recent documents list).
Though this might be slightly dangerous unless either the app or the file system did versioning by default.
The answer is basically to free up RAM for disk cache, based on a belief (sometimes backed up by benchmarks) that for typical use patterns, the performance hit of sometimes having to swap RAM back into physical memory is outweighed by the performance gain of a large disk cache.
Whether or not it works (and I'm not sure how well it does), there's something odd about swapping out RAM contents to disk so that you can mirror disk contents in RAM.
Interestingly I've been seeing more and more of this type of language around the internet; my favourites are "Jaquiboot Smith" for the home sectary as it sums up my opinion of her, and "NuLab" because of the obvious Orwellian comparisons to IngSoc. I don't think it's flamebaitjust a concise way to sum up thoughs on the creeping authoritarianism of this new* Labour Goverment
*how long can they justifiably continue to style themselves as "new"?
Using incendiary epithets is flamebait.
The fact that the incendiary epithets happen to comport well with your personal feelings doesn't change that (in fact, it would be odd to use an epithet which didn't.)
If you want to make arguments about creeping authoritarianism without flamebait, then make the arguments without the epithets.
Probably because of the unnecessarily incendiary language in GP like "NuStasi" for New Labour.
Only true NuLabour sheeple would think otherwise.
...And here you're doing (a lesser form of) the same thing that got the GP rightly modded as flamebait.
If you don't want to get posts tagged as flamebait, explain and justify your opinions without peppering your posts with gratuitous insults; in short, use arguments instead of epithets.
Slashdot Mirror
In school, using computers I learned BASIC programming, Logo, the relation between frequency and musical notes, binary arithmetic, and quite a lot else -- and that's just 4th through 6th grade, in the 1980s, without the internet (or any other kind of net.) The problem's I've seen in recent years in schools with computers is that we've vastly expanded the number of computers in schools and the percentage of students that have access to them -- but eliminated most of the idea of a coherent, meaningful use of computers to teach anything, other than the use of computers as generic office tools.
Of course, the way public school teachers are compensated or treated, if they had the skills to do anything else, they could make four times as much money with much better non-financial working conditions outside of the schools, so I'm not really surprised; there are still some people out there doing better, but the number of people with both the skills and the willingness to suffer through the environment that school teachers have is small. More computers in more schools won't help without dealing with that issue, and more broadband penetration will only help a little (it'll help some of the places that are doing good in this respect do better).
If, by "Mormons", you mean only members of the organization known as "the Church of Jesus Christ of Latter-Day Saints", but not any of the many offshoot splinter sects of that group. Since many outside observers refer to offshoot splinter sects that break off of and are out of Communion with the Roman Catholic Church but identify themselves as the "correct" form of the same faith tradition, as "Catholic" groups, its not really that unusual that outside observers might use parallel language in discussing "Mormon" groups.
That depends on the role of the cell in the algorithm; you most likely lose some, but not all, of that advantage.
Its true that the best algorithms for parallelization may not be the same as the best algorithms not considering parallelization; that doesn't mean FP breaks existing algorithms.
Actually, the "speed up cores rather than increase the number of them" was the dominant trend, and the center of most marketing campaigns, up until chip manufacturers absolutely couldn't do it anymore without making chips that melted themselves.
After tha, when despite the fact that both engineering efforts and marketingt campaigns had been centered around the GHz race, chip manufacturers realized they needed to go somewhere else, and multiplying cores is what worked.
So saying speeding up cores isn't viable for marketing reasons is completely backwards.
Right, I don't disagree with that. What I'm saying is the algorithm doesn't "break" because you are using an FP language. You can usually do a fairly direct tranlation of the implementation from another language, or you can do a more idiomatic implementation in the new language, but any algorithm you can use in any other language can be implemented in an FP language.
There may be times when the best algorithm for on in an FP language isn't the best algorithm otherwise (there may be several, e.g., O(n) algorithms available, and the one that has the smallest constant multiplier may change from language to language -- or even from language or library implementation in the same language -- or the expression of one of two equally-performant algorithms may be far simpler in one language, where the other simpler in the other language.)
This doesn't break algorithms. It just changes the way a particular algorithm will be expressed in code. Any functional language will provide a way to create and access a mutable storage cell, though it may be more programming work to do so than it would be in a language where that was the normal use of a variable.
I suppose its hard for someone whose done lots of lots of programming and none of it in a functional style, much less a functional language, and who is used to artifacts of other languages as if they were fundamental elements of programming.
Algorithms don't break. The algorithms that have a simple, concise realization in an FP language may not be the same ones that do so in, e.g., C, and the implementation of an algorithm, even one that is similarly easy in the FP language and C, may be very different, but changing programming paradigms doesn't do anything remotely like breaking algorithms.
How is maintaining the rate of increase in the number of transistors that can be economically placed on an integrated circuit a software problem?
Because votes by elected officials are not the votes by the citizens in a democracy, they are acts by which officials represent citizens in the representative form of democracy. Their openness is part of the accountability of the government to the citizens.
We don't.
We choose ballot secrecy over ballot openness. The idea that open ballots would lead to more accuracy in practice is a controversial claim that is, in your post, assumed without any support given.
Well, no, you assume, without support:
1) That that is the real choice (and that there are no other downsides to losing ballot secrecy), and
2) That if people saw that as the real choice, the secret ballot would be controversial.
But, even if those unsupported assumptions are correct, you would still be wrong when you say that the secret ballot is controversial.
Like many things, its good in moderation (for CO2, at the naturally occurring level in the atmosphere.) OTOH, adding CO2 faster than it is taken out of the atmosphere by natural processes is considerably less good; as such, it is "dirty".
True. As do oil powered things, though CO2 is the main global threat (most of the other forms of pollution produce effects that, while more severe in the short term, are more localized.)
Uh, they don't. OTOH, they do want to reduce global carbon emissions, and given the actual per capita emissions, they don't have any credibility doing that unless the developed countries, which emit more, start the process.
True.
The idea is to make industry cleaner, not ship it overseas.
No, it seems impossible because it is.
We don't have a small group of people watching everyone now, we have no one watching everyone and everyone watching what they are interested in within their limits of access. Even if you assume everyone had access to everything (which is unlikely to be practical), you still won't have everyone watching everyone.
Only if everyone is interested in and looking for it.
Which for almost most things, even things that people would be interested in if they found out about it, wouldn't even be remotely close to the truth.
Even if everyone had access to everything they chose, no one would have the time or ability to integrate information to monitor more than the vanishingly small fraction they were most interested in. And, anyway, without infinite resources, everyone couldn't monitor everything. Because that would require the ability to distribute an infinite amount of information (since the information that person X is monitoring input Y is part of the information flow that must be subject to monitoring, and, on the assumption that everyone is completely monitoring everyone else, must be transmitted to everyone.)
If its JS, rather than just HTML, it could certainly poll a message queue, which (given suitable tolerance for latency) would allow it to accept and respond to callbacks, albeit asynchronously rather than synchronously.
This is only true to the extent that one views normal Ruby code as "ugly". Rails doesn't provide any extra elegance to code that doesn't follow its architectural assumptions, but then one could hardly expect it to do so. It doesn't do anything to make such code uglier, except by comparison to the streamlining it provides code that does follow its architectural assumptions.
Some books focus on pattern implementations in particular languages (either explicitly, or implicitly because of the patterns chosen), and tend to focus on patterns that need substantial implementations because the languages on which the book focuses can't implement them in a simple, elegant manner or in a form which is readily adaptable to a library rather than a repeated code pattern.
OTOH, other works focus on design patterns as elements of design (as the name "design patterns" suggests), not in terms of language-centric implementation (though they may provide concrete examples, and may talk about implementation in terms of pattern composition.) A good example of this is Enterprise Integration Patterns.
I'd argue that the latter types of works are the ones which focus on the design patterns as design patterns, and are the ones that actually do help provide a common language for discussing approaches to solving a problem.
Even with total transparency, everyone wouldn't know who they were, since no one could manage all the available information. People who cared would be able to find out, but if the harassers were part of a big enough group with enough resources that it was ineffective for their targets to retaliate against them, they could still get away with a lot. You'd have to do a lot more control with laws rather than privacy, OTOH, if you really had perfect transparency, enforcing those laws would, presumably, be easy.
Of course, without magic, you won't have perfect transparency; the government will always retain the right to keep secrets, and those with sufficient resources will find ways to avoid or spoof attempts at universal monitoring, which will become a tool for the controls of those without resources by those with.
Yes, and its still flamebait.
If they want to make the argument about what actions are problematic and why those actions are problematic, then they can be part of a decent, productive, substantive discussion.
Everything that is flamebait tells you what someone's opinion of something is. That something is a shorthand way of conveying opinion doesn't stop it from being flamebait.
That something uses incendiary language to simply express a judgement rather than presenting an argument to support the judgement makes it flamebait.
Hyperbolic expressions of disgust are, inherently. flamebait.
They are certainly part of a democracy. In fact, they are part of very many democracies.
They are not essential to democracy in theory, though they have proven to of benefit to free and fair elections (without which there is no real democracy) in practice.
True.
I would not agree with that assessment, though the open ballot isn't the sole problem which contributed.
I would argue that that demonstrates vividly one of the ways the secret ballot has proven essential to free and fair elections, without which any claim to democracy is a sham.
Physical harm is not the only form of retaliation and source of intimidation to be concerned about, but it certainly is the most important one.
Sure, no one is ever assaulted for their expressed political views in the US.
"Most people that are for secrecy"? That's, in the US at least, not far from a majority of the population, as the secret ballot isn't even a slightly controversial issue in the US.
If you are using the "allocate-before-editing" mechanism, it would make sense to either provide a mechanism for the user to choose to allocate a "scratch" document that will not be preserved (whether it isn't saved at all, or uses whatever the OS provides for allocating and releasing temporary files), or provide a mechanism to abandon-and-delete the file from the editing application (such as a "File -> Abandon" menu option) rather than forcing the user to delete it outside of the application. There's no reason, really, not to provide both options (the latter has use outside of scratch files: deleting a document from the application where you would work with it, rather than the through the file browser or some other tool unrelated to the document, makes a certain kind of sense, IMO.)
Yeah, that model (which is fairly common in applications that "save" incrementally to a database, even if it is a single file database, or to a mutifile structure) is what I was getting at -- there's no reason not to use it for other things, as well; anyhow, the dangerous part (without versioning) is when you are working with a file that has already been saved; if it saved silently on close, you might overwrite when your intent may have been to branch. With versioning-by-default (provided by the app, OS, or file system) this isn't a data loss problem, but without it it could be.
Versioning-by-default combined with name-before-working and automatic, silent save-on-close would, while it would take a little getting used to, probably be a big productivity win, and eliminate common ways to accidentally lose data and the need for application closing nag screens (including the application-close-on-OS-shutdown nag screens.)
Not running Microsoft's latest bloatware is probably the best way to speed up a slow system if you are currently doing that.
The problem is the default "Untitled" document. If you started without an open document, and created the file when you wanted to start working on it, then you'd know where to find it (particularly if the app or the OS or both has a recent documents list).
Though this might be slightly dangerous unless either the app or the file system did versioning by default.
Whether or not it works (and I'm not sure how well it does), there's something odd about swapping out RAM contents to disk so that you can mirror disk contents in RAM.
Using incendiary epithets is flamebait.
The fact that the incendiary epithets happen to comport well with your personal feelings doesn't change that (in fact, it would be odd to use an epithet which didn't.)
If you want to make arguments about creeping authoritarianism without flamebait, then make the arguments without the epithets.
Probably because of the unnecessarily incendiary language in GP like "NuStasi" for New Labour.
If you don't want to get posts tagged as flamebait, explain and justify your opinions without peppering your posts with gratuitous insults; in short, use arguments instead of epithets.