Since they do totally different things the comparison is meaningless
Not totally different. They do one overlapping thing: they issue statements to the public.
trust in a very generic way means our belief that they'll do their "given task"
I didn't say that. I didn't imply that. I was very specific in my definition of trust, and I think this definition is rather obviously gleaned from the survey, and, in fact, that the definition of trust as "reliably telling the truth" is actually used at least as frequently as "behave predictably in doing what they do," if not more so. It isn't terribly meaningful to survey people about whether or not they trust that they can predict the behavior of one group more than another (at least, not nearly so as the alternative). So...as I said, it is a bit obtuse to completely ignore the context and select the wrong definition of truth as the one that they mean. Perhaps I was wrong...you did get a lot of moderation there.
They want to sell it to me, even if they have to lie to do so. With traditional media, truth sells...some of the time, anyway. If a paper always lies, they're not going to have as many sales. With corporations, they just call that marketing.
...and once again you drive home my other point. Living in a world where people don't know the difference between marketing (or, as the case may be, newspaper bias) and lying sucks. They aren't the same thing. Lying is much, much worse.
These are students being taught for their future and will need the skills required for their future jobs. Pushing the Mac platform is a horrible idea and a form of playing russian roulette with their computer skills and future job possibilities.
Keeping in mind what is possible through *freely available* VMs, and the programs that are available on any platform, if the skillset that you gain in high school computer usage is so specific that you *need* a windows machine to do your work, because it probably means that you need Windows 7, and won't even be flexible enough to handle Windows 8.
Regardless of anyones personal opinion of computer OS's, Windows still rules in both the personal and business OS level. And I don't care what anyone else has to say on the level of 'but, but, Macs are slowly gaining.' Thats great for Mac. But here's a good dose of reality. OSX was released in March of 2001. Its now June of 2010, just over 9 years later. Mac has been able to improve its market share from 1-2% to 6-9%. That means less then one in 10 computers is a Mac even after 9 years and one hell of an aggressive marketing campaign (we've all seen those 'Pc vs Mac' commercials).
None of this stuff matters. I can go sit down at a Mac, PC, linux box, whatever. Tell me how to get to the word processor. Tell me how to get to the software that I use the most.
The school is also mentioning security as an issue, but thats getting more and more of a questionable problem. Fact of the matter is, Windows 7 is pretty secure (but not the most secure). And computer security is no longer as simple as how fast a virus/worm can spread. This keeps being shown on the Pwn2Own contests, as security is now based on what else is running on the computer. The biggest security risk seems to be running Flash on the system.
Do you think, from an administrative level, that it's ever been about that? That's just a symptom of the problem. The biggest security risk is stupid users, and nothing you do can stop them from getting their computers infected with something. The cure is having separation of security concerns to limit the damage, and it's still more of a (only a) problem for Windows than it is for anything else. If I was a computer administrator that had to support 1600 laptops that I didn't actually have control over, I would want something to make it easy to fix them and isolate problems.
Also to consider is things like hardware compatibility. Most hardware is written to support Windows, with some to little to no support for Mac. Sure, Macs play great with other Mac hardware but if Apple doesn't make it things get iffy (again, depends on what it is your talking about exactly). These students go home and will want to use their laptops with their devices at home. Have a blackberry phone? Good luck doing anything but the basics of syncing (and no, showing me some complex set of instructions doesn't count. We are talking students of different interests and backgrounds, not the slashdot crowd). Printers and scanners?
From the perspective of the school, though, the things that they're going to worry about are the things that everybody has and that teachers are actively told to encourage the use of. And it's a lot easier to support 1600 identical machines than it is a huge number of completely different kind of machines.
I completely agree with you here. These are students being taught for their future and will need the skills required for their future jobs. Pushing the Mac platform is a horrible idea and a form of playing russian roulette with their computer skills and future job possibilities.
In summary: the premise that a particular piece of software is necessary to gain an understanding of how computers, technology, or anything that one would learn in high school is ridiculous. Of course, if I ever have children, I'm sure that mine will be unbelievably competitive compared to yours if you teach 'em that full mastery of how to navigate windows and use office products will take them somewhere in life while I'm teaching them the underlying concepts that govern how all computers work.;)
Well...the poll is clearly trusting its readers to be able to glean the rather obvious context of "trust" from the question.
We're asking how much we trust news outlets, google, apple, and Microsoft to tell us the truth.
And I have to say, the news seems to have done a fantastic job at indoctrinating us with their crap. Looking through this thread, I don't see a single article that differentiates between "bias" and "lies."
If we're going to talk about semantics, that's a lot more important. There must be a line of trust beyond which any transgression makes me trust that you're trying to fool me into believing something that you don't believe. And past that line we're not talking about bias.
This is why I don't trust MS as much as traditional media. I know that they will never tell me when their product isn't suitable to my needs (which usually happens because it isn't ready for market yet). They want to sell it to me, even if they have to lie to do so. With traditional media, truth sells...some of the time, anyway. If a paper always lies, they're not going to have as many sales. With corporations, they just call that marketing.
Sounds like there's a design flaw in the rubber that's being used...or in the ink that most everybody makes. I would much rather have a printer that makes due with any kind of ink over one that requires super-fancy-awesome ink.
Perhaps the flaw is using ink at all, rather than using heated powder?
In any case, I don't really care if they've solved the our-ink-doesn't-destroy-our-printers problem, because the actual problem that I want solved is "how do I convert this image on my computer into a printout?" If the tech that does this has a huge number of ancillary problems that come up because of it's weaknesses, then perhaps it isn't the best solution.
Perhaps we should be using laser. I've got a laserjet 5si that I've had for years. I use 30 pages per week. I get a new cartridge once every five years or so. The last one cost me $30. The printer cost me $100. When a part on the machine wears out, I buy a new one. This has happened once, and I paid $30.
We have no economic reason to buy into this game. Laser looks absolutely fantastic.
You're saying that there's no such thing as table salt. This is obviously false.
Compounds with strong ionic bonds tend to disassociate completely in water forming the constituent ions (completely being as previously indicated - not really complete).
However, the moment that they leave the water, they're back to what they were - full molecules again.
just aren't willing to fund the social programs and mental health infrastructure to take care of these people, so they end up in the streets. and not all cities with a homeless population have shelters
You seem like someone who has never spent any time with any crazy homeless people. Nearly all big cities do have shelters. All the ones I've visited and had the chance to look do (Orlando, Chicago, New York, Atlanta, Indianapolis).
Those are generally *not* for the crazy homeless, though. They're for the temporarily homeless. If you really want to keep being homeless, and you refuse any medical treatment that will help you get better, you are allowed to remain homeless. You are not forced to change. I know that the primary city in which I've lived - Orlando - has *plenty* of ways of keeping people from being homeless and of giving the very, very poor homes and medical treatment - both through the government and through local philanthropic organizations.
little has been done about it
Thanks especially to this, we realized that "fixing" such people means that we're curtailing their freedom - freedom to be crazy, and freedom to make the choices that leave them homeless.
Let me have my own self-destructive vices; let the homeless have theirs. It is their right as human beings. Don't try to make decisions for them. I am proud that we live in a country were we don't lock up our crazy people like criminals just because we don't like the way that they think, and am glad that "little is being done about it."
I noticed in your sig that you are a consultant. I am as well...to government agencies. I convert gibberish into cash-flow...but it's not the gibberish I spew. Bear all that in mind when I bring up my other points, also related to money:
3) The *domain* in which an agency works determines what is optimal IT-wise for them to do their work. Some of that can, and should, be standardized way more. This is not always intuitive. (For example, a police department actually needs to spend much more on Geographical Information Services software than does a transit authority). Believing that a single man is going to know enough to actually make standardization of every kind of government agency is a recipe for disaster. IT improvement has to come from within the agencies themselves.
4) People with knowledge and vision to do Things the Right Way are almost never in a position to do so because experienced government work pays so badly compared to its industry counterparts. What you get, then is the people who either won't leave their government jobs because they don't have the motivation to do so (which means that they *naturally resist change*), or people who aren't competent enough to learn new things.
Part of that is knowing how to use the libraries that you need.
There is but a single construct within normal SQL that can't be represented in Hibernate - functions in subselects anywhere except the select subclause.
You can do absolutely everything else, and there's even a workaround for that - use functions only within the select subclause, or use formulas (same thing). My guess is that you didn't actually look into how HQL works.
Anyway, what I'm getting at is that there are libraries for a single task, and libraries to make programming itself easier. You've chosen libraries that fall into the second category. If it's not making your life easier most of the time and at *every* level of scalability, you're probably using them wrong.
My general experience is that libraries that implement a lot of extra functionality that you don't need, but that you *have to use* in order to use them are generally more pain than they're worth. If you need to extend, you often have to implement lots of extra stuff that you're not using. Otherwise, the libraries give you a good starting place, if nothing else.
Hibernate also chooses to hide those SQL differences
Wrong. Reread my last comment. You're perfectly free to use any function, aggregate, or other feature defined only within your database when you're using hibernate. The ONLY thing the ORM is doing is combining relational with OOP. It isn't binding you to some whole new language that limits the features you can use (other than the aforementioned lack of aggregates in subselects).
It needs backend drivers to recognize the small portion of SQL that it actually uses to do such a mapping. Hiding the functionality of the database is well and good, but sometimes databases have fantastic functionality that you don't want to miss.
I don't want to be bound by the lowest common denominator of database functionality when I'm writing my code, and if Entities always requires this, then it is certainly always going to be much less functional than the databases it supports...and so will not be used.
This is not true. In plain LINQ to Objects, every single operator is supported, and any function call works. Without any limitations whatsoever. Because it actually, you know, just calls those functions?
Okay, sure. I've never tried that; its fairly useless to me. Most of the syntactic sugar I need is in the database design. What I have tried, and the examples I had problems with, are from Linq to Entities.
Yeah? Try calling a stored procedure in a server-agnostic way. Or work with dates. Or concatenate two strings. Or get a substring of a string. Or limit the output of a query to the first N rows. Or create an autoincrementing field.
The "autoincrement" thing is necessary for creating new records in the database. That needs to be specified for any language variant. The other things mentioned here can be interpreted by the relational database. The advanced query language doesn't need to know what they are.
This is true of nearly every operator in each language variant. The important thing isn't recognizing all the operators/functions and how they work; it's recognizing the difference between a function/operator and a table and field. If the ORM can do that, it has all it needs to convert queries from its language into pure SQL.
Sounds like what you're saying is that Linq is just the language that goes along with an ORM mapper. Something like what HQL is capable of doing.
In the rest of the programming world, one would make no such distinction. ORM=>ORM+API sublanguage.
And I see no reason to make such a distinction here. It's not like Hibernate isn't capable of dealing with things besides databases. Why should we place an emphasis on that when talking about Linq to (*), but not when dealing with anything else?
Even if we were...you've essentially *possibly* invalidated point #5. What about the other 4? Those don't actually have anything to do with ORM, but actually deal with using Linq as a language (vs using HQL as a language).
Moving on, lets address your point: database-agnostic (there was an Entity Framework provider for PostgreSQL released recently, and more are in the works)
If you actually have to make a new language variant for every single database, and it's hard enough that there wasn't one for the 10 most heavily used databases included with the initial launch, then it isn't even close to database agnostic. You can do almost everything you need to using standard, compatible-with-every-server SQL most of the time...but you have to be developing with that in mind.
Out of the box, Linq to Entities works with SQL Server. If you go into VS2008SP1, and create a new Linq to Entities project, the only database option available is SQL Server. Everything else is still an unsupported add-on.
Re:recommended for advanced programmers
on
Programming .NET 3.5
·
· Score: 3, Interesting
Java could have its own LINQ analog and type inference already, if only Sun (or Google, or IBM, or other of the big players) wanted it - which they don't. End result - talented language designers like Neal Gafter are leaving the Java scene and joining Microsoft [artima.com] to work on C#.
Well...Linq is sort of a hybrid thing, but it's mostly Microsoft finally adding an ORM language to.Net.
Quite frankly, as a developer who uses both Java and.Net in my job (and am currently using.Net 3.5 sp1), Linq is an embarrassment. I have found the following problems: 1) I cannot easily be sure which parts will run in the database and which in the VM. 2) I have little control over how caching works. 3) Does an extremely poor job of modeling relationships other than "Has A" and "Belongs To" (the very common "Has and Belongs to Many", for example, is missing). 4) Some functions that work in BOTH the database and the VM don't work with Linq, or don't work reliably (examples I've found: shift operator, bitwise and when used with ulong). 5) Almost all of the database functionality in Linq will not work with anything besides SQL Server.
All of these reasons are why I'm sticking with Hibernate for Java, and NHibernate for.Net for as long as I can. Hibernate behaves predictably and reliably, and you can figure out what its doing when you have to and optimize queries that are taking too long, and you seldom have to worry about it failing in unpredictable ways.
The only complaint I have with Hibernate is that you can't do subselects containing aggregate functions in Hibernate Query Language.
Do they always assume that? I've always heard the phrase "heat death of the universe," which doesn't imply nothing...exactly, but it would be close.
Thanks to almighty laws of thermodynamics, we could theoretically reach a point where every bit of matter has been broken down into mere energy, and every quantum of energy is so far away from every other quantum of energy that no interaction ever happens again - everything stays in the lowest possible energy state, at the lowest level of organization.
If you could suddenly teleport to that time in the future, what you'd see for light years in every direction would be nothing at all. Sure, there'd be *something* since energy can't be destroyed.
It just wouldn't be doing much...probably not enough to detect.
Most of the time, you do know the state of the machine at a given point in the code.
No you don't. If you think otherwise, you haven't been programming for very long, or you have an inflated view of your own programming ability. You usually know *MOST* of what you need, but everybody always forgets something. I cite the fact that there are so few bug-free programs, and the general practice of encapsulation & defensive programming as evidence.
Keeping state information in general is not the same as OOP.
No it isn't. Keeping a clearly defined set of properties that you reusing over and over is. The difference between OOP and not is in the fact that your state is well defined. Feel free to disagree. I can't stop you. No use arguing a belief. I can say, though, that this is the irreducible property from which all other OOP concepts spring. You can't have OOP without this, but from this you can create all of OOP.
Don't use object properties for loop variables.
Don't think that object properties that are used in loops are actually loop variables. If you can do a single piece of code to finish them all out, then they aren't loop variables. You've described the problem wrong.
Also, I hope you realize that you're just transferring the problem.
I disagree. You start to track the flow of the program using the language syntax rather than the logic of the program, which drastically simplifies the problem. You might consider actually supporting your claims with actual reasons rather than just saying that I'm wrong if you hold an opposing view.
printing out a message to tell the user something...and that's when you want to start moving into using interfaces and aspect oriented programming, which is another issue altogether. It certainly isn't a reason to use gotos.
Goto does not cause hardware or operating system level errors, which is what you seem to be implying.
Let me just go ahead and say that. Operating systems track program state, and if you try to GOTO an area you're not allowed, most modern OSes will, in fact, throw an error and crash the program. More and more of such logic is being moved into processors as well as more multitasking-related operations are moved into the processor level.
I can't tell if you're being serious, or a troll. Apparently you're idea is insightful to at least 3 people, so that's why I think it's worth responding. [Computer Science 101] GOTO remains the best way, in most programming languages, to exit multiple loops, branch to common clean-up code before leaving a function, etc.
No it doesn't. I remains one of the worst ways for the following reasons, which are exactly the same reasons its bad in general programming practice. The logic goes something like this:
1) When you enter the thing that you're going to, you don't know the state of the machine before that. There is no structure in place to check for, or prevent side effects (such as variables not being initialized, or their state not changing the way you expect). In addition, when you're going back through the code, it's usually quite difficult to be sure what code block depends on the "goto" code.
2) In practice adding structure to specifically check for side effects is much more wasteful (and more likely to be filled with bugs) than just not using Goto statements, and repeating the statement multiple times without gotos.
3) So what you do instead, to track the location that you're going to and to prevent side effects is to use some state information that you pass around to know where you've come from and where you're going within the process. Congratulations! That's a wonderful solution. Unfortunately, you didn't actually invent it. That's just object oriented programming...but without the nice syntax and niceties to make it easy to follow.
As a former BASIC programmer (started on apple IIs and Commodore 64s), I actually started in on the move away from GOTOs with exactly this point of view. to exit multiple loops, branch to common clean-up code before leaving a function, etc.
Its rather interesting that you chose these functions specifically, as they're really very specifically uses for which OOP was designed.
to exit multiple loops
The programming pattern where you'd use multiple loops that each have a single termination would presumably be using similar data in different ways in each loop. Otherwise, the "finish up" code would be different for each piece. In OOP, you'd say that they're using object properties. These are properties that are available to all of the functions in an object, so the OOP way of doing this would be something like "finishBranches()", which is about as hard as writing "goto finishBranches" but without as much risk of side effects (because everything is defined by the hopefully-compiler-verified object properties).
branch to common clean-up code before leaving a function
A destructor function is common clean-up code that runs when an object is destroyed. Build your destructors right, and manual clean-up is seldom needed. It keeps you from deallocating memory when there's still a constructor still hanging out somewhere.
There are two main arguments I can think of against this: 1) Now you might be thinking "but language X" doesn't have OOP." Not really important. OOP is a concept based mostly around the idea that program flow is about how the data is transformed and not how the program flows. It can be implemented in any Turing complete language.
2) But "Goto" is what the computer really does. Not really. Modern processors keeps track of threads and more, with associated state information. There are nearly always limits on where you can GOTO. Point there is that GOTO isn't really enough. For the stability of the system, state info need to be tracked. Not to the level that humans use it, but then again, computers aren't really reading our high level languages at all, are they?
Note that these are just the basics of why gotos are pretty much a bad idea all of the time. For a more complete intro, I highly recommend a degree in computer science.
It works with Visual Studio, which has built-in automagical wizards for filling out frontends. This tool even works with libraries that other people have made.
It also has a web programming model that's almost exactly the same as its non-web model.
I haven't seen this level of RAD support in any other system which also has support for the web - much as I would like to - especially in Java.
Hopefully, one day I will. I'm subscribed to the MyEclipse project. Mylyn is awesome, subclipse is the best subversion client I've ever used, but I have found no actual set of libraries that I can develop with the rapidity of the ones that come with.Net 3.5.
Your logic is flawed. It doesn't matter how many people you sleep with. Your chances are based upon the number of people in your node network.
Lets say that non-slut=only two sex partners (ever), but that the standards slip as they get further away from you in the sex-partner network.
So each of your girlfriends has had only one other sex partner, but each of those has had two, and each of *those* has three others...for simplicity, lets say that the pattern maxes out at 6, and none of those people have ever had sex with anyone other than their partner.
How many is that? 4+8+16+32+64+128=252
So in this relatively small chain (unlikely small), you are assuming that no one has HIV, or that they don't transmit it to any of their partners, or that there's a barrier protecting you (i.e., all the ones close to you in the node tree are *really good* at not making condoms break).
Now for some STDs, your partner can know that they have it, which mitigates circumstances greatly. HIV can go unknown for a *REALLY LONG TIME*.
So I'd generally say that you're wrong unless you can somehow know the entire sexual history of everyone you sleep with and trace it back to people who have only slept with one person.
It's necessary to "stop fucking people whose HIV status you don't know"
I'm sure that everyone would like to know how to make sure that no one connected to them though a node network of sexual partners has aids. All it would take is one guy/girl lying, and spreading it to all the people who sleep with them, and for the next eight years, everybody they slept with will spread it to everyone else they sleep with (and on, and on).
But you seem to have the answer. How can this be made to not happen?
Some of us just aren't wired for monogamy, and telling people "don't be what you are!" is always a piss-poor recommendation. Especially when it comes to basic drives like sex.
Yeah...well, we're wired to kill, too. It is also a basic drive. Do we let people do that indiscriminately? Apparently telling people "don't be what you are" is a piss-poor recommendation.
We need to fix the education, though. I think it may be time to institute a "guns in schools" program so that they can know how to use them safely. We wouldn't want our youngsters to accidentally hurt themselves while they're off satisfying their basic urges of killing people.
See where I'm going here? There are plenty of valid arguments for non-monogamy. The idea that resisting instincts is somehow bad isn't one of them. Resisting basic instincts is part of what it means to have a civilization.
We take it for granted that we don't kill, steal, rape, despite the extremely natural instinct to do these things. I see no reason why sex isn't exactly like those other things.
I don't want to discount your idea entirely. Do you have a reason why non-monogamous sex is important to have that doesn't revolve around believing that instincts shouldn't be repressed? Do you have any actual facts to support your claim?
Seems to me that it just comes down to the fact that people want it more than they are worried about consequences from it rather than any actual reasoned view that justifies non-monogamy. Which, ironically, is about the same reasoning by people who steal, kill, and rape (i.e., they don't put much thought into justifying it...they just do it).
The basic premise of the book was that the internet has evolved to the point where a few people can interface via a VR interface and it's experienced as a immersive 3d world with avatars etc., but that something weird is happening and some people who are connecting to a very specific location, eventually dubbed Otherland, are getting "stuck" in the virtual worlds, even though they aren't using neural interfaces.
Fixed that for you. Did you even read the series? Your description is way off.
Otherland isn't really a single world with lore, rather it's more of a meta-world in which the players randomly get dropped into one of many worlds each with their own lore.
You're missing the most important bit - Otherland itself. Each "world" within Otherland has it's own masters who have ideas about what that world should be, and created it as such. The rest are mostly just fronts for something similar to the internet. It would be foolish not to include this concept - and perhaps some of the neat worlds that Tad Williams envisioned - in such a new MMO.
It should also be noted that the rest of the net is small by comparison to Otherland - which is the only place that people are actually creating *worlds* instead of just *sites*. I can't see why this wouldn't also be true.
While this is true, you'd generally have to be a masochist to want to use a key signature with 7 sharps when you have the option of minimizing your accidentals by putting it in Db (five flats).
Then it'd be Db, F, Ab. Notice that I said the people pronounce E# as "eff." It's almost universally how everybody thinks about it. I didn't say that it wasn't correct to call it E#.
Re:Foctothorpe FTW
on
C# In-Depth
·
· Score: 1, Informative
Pretty sure that music precedes unicode, dude, and they write the sharp sign using anything that looks like a tiny smooshed tick-tack-toe board.
At any case, you're both wrong. "E#" is pronounced "eff" - there is a half step between E and F, and the "#" sign denotes "do this note, except take it up half a step."
I've come to learn that when you combine craftsmanship and engineering, you end up with something that doesn't tend to break, and is almost always extremely useful.
Throw "art" into the mix, and you end up with something that is marginally useful, full of potential design flaws introduced for the sake of art that may cause it to break, and not terribly fun to look at.
This seems to fit. I put art into parentheses because I believe that a good craftsman is an artist. He makes the art seem invisible, and you admire the design for its utility - for how it fits you. Seems like art to me.
To me, it'd be cooler if they unveiled a clock that will always keep accurate time and won't need repairs or replacements except once every fifty years or so.
Slashdot Mirror
Since they do totally different things the comparison is meaningless
Not totally different. They do one overlapping thing: they issue statements to the public.
trust in a very generic way means our belief that they'll do their "given task"
I didn't say that. I didn't imply that. I was very specific in my definition of trust, and I think this definition is rather obviously gleaned from the survey, and, in fact, that the definition of trust as "reliably telling the truth" is actually used at least as frequently as "behave predictably in doing what they do," if not more so. It isn't terribly meaningful to survey people about whether or not they trust that they can predict the behavior of one group more than another (at least, not nearly so as the alternative). So...as I said, it is a bit obtuse to completely ignore the context and select the wrong definition of truth as the one that they mean. Perhaps I was wrong...you did get a lot of moderation there.
They want to sell it to me, even if they have to lie to do so. With traditional media, truth sells...some of the time, anyway. If a paper always lies, they're not going to have as many sales. With corporations, they just call that marketing.
...and once again you drive home my other point. Living in a world where people don't know the difference between marketing (or, as the case may be, newspaper bias) and lying sucks. They aren't the same thing. Lying is much, much worse.
These are students being taught for their future and will need the skills required for their future jobs. Pushing the Mac platform is a horrible idea and a form of playing russian roulette with their computer skills and future job possibilities.
Keeping in mind what is possible through *freely available* VMs, and the programs that are available on any platform, if the skillset that you gain in high school computer usage is so specific that you *need* a windows machine to do your work, because it probably means that you need Windows 7, and won't even be flexible enough to handle Windows 8.
Regardless of anyones personal opinion of computer OS's, Windows still rules in both the personal and business OS level. And I don't care what anyone else has to say on the level of 'but, but, Macs are slowly gaining.' Thats great for Mac. But here's a good dose of reality. OSX was released in March of 2001. Its now June of 2010, just over 9 years later. Mac has been able to improve its market share from 1-2% to 6-9%. That means less then one in 10 computers is a Mac even after 9 years and one hell of an aggressive marketing campaign (we've all seen those 'Pc vs Mac' commercials).
None of this stuff matters. I can go sit down at a Mac, PC, linux box, whatever. Tell me how to get to the word processor. Tell me how to get to the software that I use the most.
The school is also mentioning security as an issue, but thats getting more and more of a questionable problem. Fact of the matter is, Windows 7 is pretty secure (but not the most secure). And computer security is no longer as simple as how fast a virus/worm can spread. This keeps being shown on the Pwn2Own contests, as security is now based on what else is running on the computer. The biggest security risk seems to be running Flash on the system.
Do you think, from an administrative level, that it's ever been about that? That's just a symptom of the problem. The biggest security risk is stupid users, and nothing you do can stop them from getting their computers infected with something. The cure is having separation of security concerns to limit the damage, and it's still more of a (only a) problem for Windows than it is for anything else. If I was a computer administrator that had to support 1600 laptops that I didn't actually have control over, I would want something to make it easy to fix them and isolate problems.
Also to consider is things like hardware compatibility. Most hardware is written to support Windows, with some to little to no support for Mac. Sure, Macs play great with other Mac hardware but if Apple doesn't make it things get iffy (again, depends on what it is your talking about exactly). These students go home and will want to use their laptops with their devices at home. Have a blackberry phone? Good luck doing anything but the basics of syncing (and no, showing me some complex set of instructions doesn't count. We are talking students of different interests and backgrounds, not the slashdot crowd). Printers and scanners?
From the perspective of the school, though, the things that they're going to worry about are the things that everybody has and that teachers are actively told to encourage the use of. And it's a lot easier to support 1600 identical machines than it is a huge number of completely different kind of machines.
I completely agree with you here. These are students being taught for their future and will need the skills required for their future jobs. Pushing the Mac platform is a horrible idea and a form of playing russian roulette with their computer skills and future job possibilities.
In summary: the premise that a particular piece of software is necessary to gain an understanding of how computers, technology, or anything that one would learn in high school is ridiculous. Of course, if I ever have children, I'm sure that mine will be unbelievably competitive compared to yours if you teach 'em that full mastery of how to navigate windows and use office products will take them somewhere in life while I'm teaching them the underlying concepts that govern how all computers work. ;)
Well...the poll is clearly trusting its readers to be able to glean the rather obvious context of "trust" from the question.
We're asking how much we trust news outlets, google, apple, and Microsoft to tell us the truth.
And I have to say, the news seems to have done a fantastic job at indoctrinating us with their crap.
Looking through this thread, I don't see a single article that differentiates between "bias" and "lies."
If we're going to talk about semantics, that's a lot more important. There must be a line of trust beyond which any transgression makes me trust that you're trying to fool me into believing something that you don't believe.
And past that line we're not talking about bias.
This is why I don't trust MS as much as traditional media. I know that they will never tell me when their product isn't suitable to my needs (which usually happens because it isn't ready for market yet). They want to sell it to me, even if they have to lie to do so. With traditional media, truth sells...some of the time, anyway. If a paper always lies, they're not going to have as many sales. With corporations, they just call that marketing.
Sounds like there's a design flaw in the rubber that's being used...or in the ink that most everybody makes. I would much rather have a printer that makes due with any kind of ink over one that requires super-fancy-awesome ink.
Perhaps the flaw is using ink at all, rather than using heated powder?
In any case, I don't really care if they've solved the our-ink-doesn't-destroy-our-printers problem, because the actual problem that I want solved is "how do I convert this image on my computer into a printout?" If the tech that does this has a huge number of ancillary problems that come up because of it's weaknesses, then perhaps it isn't the best solution.
Perhaps we should be using laser. I've got a laserjet 5si that I've had for years. I use 30 pages per week. I get a new cartridge once every five years or so. The last one cost me $30. The printer cost me $100. When a part on the machine wears out, I buy a new one. This has happened once, and I paid $30.
We have no economic reason to buy into this game. Laser looks absolutely fantastic.
You're saying that there's no such thing as table salt. This is obviously false.
Compounds with strong ionic bonds tend to disassociate completely in water forming the constituent ions (completely being as previously indicated - not really complete).
However, the moment that they leave the water, they're back to what they were - full molecules again.
just aren't willing to fund the social programs and mental health infrastructure to take care of these people, so they end up in the streets. and not all cities with a homeless population have shelters
You seem like someone who has never spent any time with any crazy homeless people. Nearly all big cities do have shelters. All the ones I've visited and had the chance to look do (Orlando, Chicago, New York, Atlanta, Indianapolis).
Those are generally *not* for the crazy homeless, though. They're for the temporarily homeless. If you really want to keep being homeless, and you refuse any medical treatment that will help you get better, you are allowed to remain homeless. You are not forced to change. I know that the primary city in which I've lived - Orlando - has *plenty* of ways of keeping people from being homeless and of giving the very, very poor homes and medical treatment - both through the government and through local philanthropic organizations.
little has been done about it
Thanks especially to this, we realized that "fixing" such people means that we're curtailing their freedom - freedom to be crazy, and freedom to make the choices that leave them homeless.
Let me have my own self-destructive vices; let the homeless have theirs. It is their right as human beings. Don't try to make decisions for them. I am proud that we live in a country were we don't lock up our crazy people like criminals just because we don't like the way that they think, and am glad that "little is being done about it."
Money is at the crux of this issue, in two ways:
I noticed in your sig that you are a consultant. I am as well...to government agencies. I convert gibberish into cash-flow...but it's not the gibberish I spew. Bear all that in mind when I bring up my other points, also related to money:
3) The *domain* in which an agency works determines what is optimal IT-wise for them to do their work. Some of that can, and should, be standardized way more. This is not always intuitive. (For example, a police department actually needs to spend much more on Geographical Information Services software than does a transit authority). Believing that a single man is going to know enough to actually make standardization of every kind of government agency is a recipe for disaster. IT improvement has to come from within the agencies themselves.
4) People with knowledge and vision to do Things the Right Way are almost never in a position to do so because experienced government work pays so badly compared to its industry counterparts. What you get, then is the people who either won't leave their government jobs because they don't have the motivation to do so (which means that they *naturally resist change*), or people who aren't competent enough to learn new things.
Part of that is knowing how to use the libraries that you need.
There is but a single construct within normal SQL that can't be represented in Hibernate - functions in subselects anywhere except the select subclause.
You can do absolutely everything else, and there's even a workaround for that - use functions only within the select subclause, or use formulas (same thing). My guess is that you didn't actually look into how HQL works.
Anyway, what I'm getting at is that there are libraries for a single task, and libraries to make programming itself easier. You've chosen libraries that fall into the second category. If it's not making your life easier most of the time and at *every* level of scalability, you're probably using them wrong.
My general experience is that libraries that implement a lot of extra functionality that you don't need, but that you *have to use* in order to use them are generally more pain than they're worth. If you need to extend, you often have to implement lots of extra stuff that you're not using. Otherwise, the libraries give you a good starting place, if nothing else.
Hibernate also chooses to hide those SQL differences
Wrong. Reread my last comment. You're perfectly free to use any function, aggregate, or other feature defined only within your database when you're using hibernate. The ONLY thing the ORM is doing is combining relational with OOP. It isn't binding you to some whole new language that limits the features you can use (other than the aforementioned lack of aggregates in subselects).
It needs backend drivers to recognize the small portion of SQL that it actually uses to do such a mapping. Hiding the functionality of the database is well and good, but sometimes databases have fantastic functionality that you don't want to miss.
I don't want to be bound by the lowest common denominator of database functionality when I'm writing my code, and if Entities always requires this, then it is certainly always going to be much less functional than the databases it supports...and so will not be used.
This is not true. In plain LINQ to Objects, every single operator is supported, and any function call works. Without any limitations whatsoever. Because it actually, you know, just calls those functions?
Okay, sure. I've never tried that; its fairly useless to me. Most of the syntactic sugar I need is in the database design. What I have tried, and the examples I had problems with, are from Linq to Entities.
Yeah? Try calling a stored procedure in a server-agnostic way. Or work with dates. Or concatenate two strings. Or get a substring of a string. Or limit the output of a query to the first N rows. Or create an autoincrementing field.
The "autoincrement" thing is necessary for creating new records in the database. That needs to be specified for any language variant. The other things mentioned here can be interpreted by the relational database. The advanced query language doesn't need to know what they are.
This is true of nearly every operator in each language variant. The important thing isn't recognizing all the operators/functions and how they work; it's recognizing the difference between a function/operator and a table and field. If the ORM can do that, it has all it needs to convert queries from its language into pure SQL.
Sounds like what you're saying is that Linq is just the language that goes along with an ORM mapper. Something like what HQL is capable of doing.
In the rest of the programming world, one would make no such distinction. ORM=>ORM+API sublanguage.
And I see no reason to make such a distinction here. It's not like Hibernate isn't capable of dealing with things besides databases. Why should we place an emphasis on that when talking about Linq to (*), but not when dealing with anything else?
Even if we were...you've essentially *possibly* invalidated point #5. What about the other 4? Those don't actually have anything to do with ORM, but actually deal with using Linq as a language (vs using HQL as a language).
Moving on, lets address your point:
database-agnostic (there was an Entity Framework provider for PostgreSQL released recently, and more are in the works)
If you actually have to make a new language variant for every single database, and it's hard enough that there wasn't one for the 10 most heavily used databases included with the initial launch, then it isn't even close to database agnostic. You can do almost everything you need to using standard, compatible-with-every-server SQL most of the time...but you have to be developing with that in mind.
Out of the box, Linq to Entities works with SQL Server. If you go into VS2008SP1, and create a new Linq to Entities project, the only database option available is SQL Server. Everything else is still an unsupported add-on.
Java could have its own LINQ analog and type inference already, if only Sun (or Google, or IBM, or other of the big players) wanted it - which they don't. End result - talented language designers like Neal Gafter are leaving the Java scene and joining Microsoft [artima.com] to work on C#.
Well...Linq is sort of a hybrid thing, but it's mostly Microsoft finally adding an ORM language to .Net.
Quite frankly, as a developer who uses both Java and .Net in my job (and am currently using .Net 3.5 sp1), Linq is an embarrassment.
I have found the following problems:
1) I cannot easily be sure which parts will run in the database and which in the VM.
2) I have little control over how caching works.
3) Does an extremely poor job of modeling relationships other than "Has A" and "Belongs To" (the very common "Has and Belongs to Many", for example, is missing).
4) Some functions that work in BOTH the database and the VM don't work with Linq, or don't work reliably (examples I've found: shift operator, bitwise and when used with ulong).
5) Almost all of the database functionality in Linq will not work with anything besides SQL Server.
All of these reasons are why I'm sticking with Hibernate for Java, and NHibernate for .Net for as long as I can. Hibernate behaves predictably and reliably, and you can figure out what its doing when you have to and optimize queries that are taking too long, and you seldom have to worry about it failing in unpredictable ways.
The only complaint I have with Hibernate is that you can't do subselects containing aggregate functions in Hibernate Query Language.
Do they always assume that? I've always heard the phrase "heat death of the universe," which doesn't imply nothing...exactly, but it would be close.
Thanks to almighty laws of thermodynamics, we could theoretically reach a point where every bit of matter has been broken down into mere energy, and every quantum of energy is so far away from every other quantum of energy that no interaction ever happens again - everything stays in the lowest possible energy state, at the lowest level of organization.
If you could suddenly teleport to that time in the future, what you'd see for light years in every direction would be nothing at all. Sure, there'd be *something* since energy can't be destroyed.
It just wouldn't be doing much...probably not enough to detect.
Most of the time, you do know the state of the machine at a given point in the code.
No you don't. If you think otherwise, you haven't been programming for very long, or you have an inflated view of your own programming ability. You usually know *MOST* of what you need, but everybody always forgets something. I cite the fact that there are so few bug-free programs, and the general practice of encapsulation & defensive programming as evidence.
Keeping state information in general is not the same as OOP.
No it isn't. Keeping a clearly defined set of properties that you reusing over and over is. The difference between OOP and not is in the fact that your state is well defined. Feel free to disagree. I can't stop you. No use arguing a belief. I can say, though, that this is the irreducible property from which all other OOP concepts spring. You can't have OOP without this, but from this you can create all of OOP.
Don't use object properties for loop variables.
Don't think that object properties that are used in loops are actually loop variables. If you can do a single piece of code to finish them all out, then they aren't loop variables. You've described the problem wrong.
Also, I hope you realize that you're just transferring the problem.
I disagree. You start to track the flow of the program using the language syntax rather than the logic of the program, which drastically simplifies the problem. You might consider actually supporting your claims with actual reasons rather than just saying that I'm wrong if you hold an opposing view.
printing out a message to tell the user something ...and that's when you want to start moving into using interfaces and aspect oriented programming, which is another issue altogether. It certainly isn't a reason to use gotos.
Goto does not cause hardware or operating system level errors, which is what you seem to be implying.
Let me just go ahead and say that. Operating systems track program state, and if you try to GOTO an area you're not allowed, most modern OSes will, in fact, throw an error and crash the program. More and more of such logic is being moved into processors as well as more multitasking-related operations are moved into the processor level.
I can't tell if you're being serious, or a troll. Apparently you're idea is insightful to at least 3 people, so that's why I think it's worth responding.
[Computer Science 101]
GOTO remains the best way, in most programming languages, to exit multiple loops, branch to common clean-up code before leaving a function, etc.
No it doesn't. I remains one of the worst ways for the following reasons, which are exactly the same reasons its bad in general programming practice. The logic goes something like this:
1) When you enter the thing that you're going to, you don't know the state of the machine before that. There is no structure in place to check for, or prevent side effects (such as variables not being initialized, or their state not changing the way you expect). In addition, when you're going back through the code, it's usually quite difficult to be sure what code block depends on the "goto" code.
2) In practice adding structure to specifically check for side effects is much more wasteful (and more likely to be filled with bugs) than just not using Goto statements, and repeating the statement multiple times without gotos.
3) So what you do instead, to track the location that you're going to and to prevent side effects is to use some state information that you pass around to know where you've come from and where you're going within the process. Congratulations! That's a wonderful solution. Unfortunately, you didn't actually invent it. That's just object oriented programming...but without the nice syntax and niceties to make it easy to follow.
As a former BASIC programmer (started on apple IIs and Commodore 64s), I actually started in on the move away from GOTOs with exactly this point of view.
to exit multiple loops, branch to common clean-up code before leaving a function, etc.
Its rather interesting that you chose these functions specifically, as they're really very specifically uses for which OOP was designed.
to exit multiple loops
The programming pattern where you'd use multiple loops that each have a single termination would presumably be using similar data in different ways in each loop. Otherwise, the "finish up" code would be different for each piece.
In OOP, you'd say that they're using object properties. These are properties that are available to all of the functions in an object, so the OOP way of doing this would be something like "finishBranches()", which is about as hard as writing "goto finishBranches" but without as much risk of side effects (because everything is defined by the hopefully-compiler-verified object properties).
branch to common clean-up code before leaving a function
A destructor function is common clean-up code that runs when an object is destroyed. Build your destructors right, and manual clean-up is seldom needed. It keeps you from deallocating memory when there's still a constructor still hanging out somewhere.
There are two main arguments I can think of against this:
1) Now you might be thinking "but language X" doesn't have OOP." Not really important. OOP is a concept based mostly around the idea that program flow is about how the data is transformed and not how the program flows. It can be implemented in any Turing complete language.
2) But "Goto" is what the computer really does.
Not really. Modern processors keeps track of threads and more, with associated state information. There are nearly always limits on where you can GOTO. Point there is that GOTO isn't really enough. For the stability of the system, state info need to be tracked. Not to the level that humans use it, but then again, computers aren't really reading our high level languages at all, are they?
Note that these are just the basics of why gotos are pretty much a bad idea all of the time. For a more complete intro, I highly recommend a degree in computer science.
-Former GOTO user.
[/ Computer Science 101]
And for anyone else who was fooled, when the parent says "picture" he means it.
It is not a photograph. It is a rendition of what some artist thinks it'd look like.
What's wrong with that? I have it on my shelf alongside the rest of the titles in the series that have served me well:
Advanced Visual Basic for Operating System Design,
Advanced Speak 'n Spell for Authors,
Advanced Cross Country Shipping for Scooters
and my absolute favorite:
Advanced Duct Tape for Space Station Construction
It works with Visual Studio, which has built-in automagical wizards for filling out frontends. This tool even works with libraries that other people have made.
It also has a web programming model that's almost exactly the same as its non-web model.
I haven't seen this level of RAD support in any other system which also has support for the web - much as I would like to - especially in Java.
Hopefully, one day I will. I'm subscribed to the MyEclipse project. Mylyn is awesome, subclipse is the best subversion client I've ever used, but I have found no actual set of libraries that I can develop with the rapidity of the ones that come with .Net 3.5.
Your logic is flawed. It doesn't matter how many people you sleep with. Your chances are based upon the number of people in your node network.
Lets say that non-slut=only two sex partners (ever), but that the standards slip as they get further away from you in the sex-partner network.
So each of your girlfriends has had only one other sex partner, but each of those has had two, and each of *those* has three others...for simplicity, lets say that the pattern maxes out at 6, and none of those people have ever had sex with anyone other than their partner.
How many is that?
4+8+16+32+64+128=252
So in this relatively small chain (unlikely small), you are assuming that no one has HIV, or that they don't transmit it to any of their partners, or that there's a barrier protecting you (i.e., all the ones close to you in the node tree are *really good* at not making condoms break).
Now for some STDs, your partner can know that they have it, which mitigates circumstances greatly. HIV can go unknown for a *REALLY LONG TIME*.
So I'd generally say that you're wrong unless you can somehow know the entire sexual history of everyone you sleep with and trace it back to people who have only slept with one person.
It's necessary to "stop fucking people whose HIV status you don't know"
I'm sure that everyone would like to know how to make sure that no one connected to them though a node network of sexual partners has aids. All it would take is one guy/girl lying, and spreading it to all the people who sleep with them, and for the next eight years, everybody they slept with will spread it to everyone else they sleep with (and on, and on).
But you seem to have the answer. How can this be made to not happen?
Some of us just aren't wired for monogamy, and telling people "don't be what you are!" is always a piss-poor recommendation. Especially when it comes to basic drives like sex.
Yeah...well, we're wired to kill, too. It is also a basic drive. Do we let people do that indiscriminately? Apparently telling people "don't be what you are" is a piss-poor recommendation.
We need to fix the education, though. I think it may be time to institute a "guns in schools" program so that they can know how to use them safely. We wouldn't want our youngsters to accidentally hurt themselves while they're off satisfying their basic urges of killing people.
See where I'm going here? There are plenty of valid arguments for non-monogamy. The idea that resisting instincts is somehow bad isn't one of them. Resisting basic instincts is part of what it means to have a civilization.
We take it for granted that we don't kill, steal, rape, despite the extremely natural instinct to do these things. I see no reason why sex isn't exactly like those other things.
I don't want to discount your idea entirely. Do you have a reason why non-monogamous sex is important to have that doesn't revolve around believing that instincts shouldn't be repressed? Do you have any actual facts to support your claim?
Seems to me that it just comes down to the fact that people want it more than they are worried about consequences from it rather than any actual reasoned view that justifies non-monogamy. Which, ironically, is about the same reasoning by people who steal, kill, and rape (i.e., they don't put much thought into justifying it...they just do it).
The basic premise of the book was that the internet has evolved to the point where a few people can interface via a VR interface and it's experienced as a immersive 3d world with avatars etc., but that something weird is happening and some people who are connecting to a very specific location, eventually dubbed Otherland, are getting "stuck" in the virtual worlds, even though they aren't using neural interfaces.
Fixed that for you. Did you even read the series? Your description is way off.
Otherland isn't really a single world with lore, rather it's more of a meta-world in which the players randomly get dropped into one of many worlds each with their own lore.
You're missing the most important bit - Otherland itself. Each "world" within Otherland has it's own masters who have ideas about what that world should be, and created it as such. The rest are mostly just fronts for something similar to the internet. It would be foolish not to include this concept - and perhaps some of the neat worlds that Tad Williams envisioned - in such a new MMO.
It should also be noted that the rest of the net is small by comparison to Otherland - which is the only place that people are actually creating *worlds* instead of just *sites*. I can't see why this wouldn't also be true.
While this is true, you'd generally have to be a masochist to want to use a key signature with 7 sharps when you have the option of minimizing your accidentals by putting it in Db (five flats).
Then it'd be Db, F, Ab. Notice that I said the people pronounce E# as "eff." It's almost universally how everybody thinks about it. I didn't say that it wasn't correct to call it E#.
Pretty sure that music precedes unicode, dude, and they write the sharp sign using anything that looks like a tiny smooshed tick-tack-toe board.
At any case, you're both wrong. "E#" is pronounced "eff" - there is a half step between E and F, and the "#" sign denotes "do this note, except take it up half a step."
E#==F.
I know for a different reason.
All the best stuff I know I learned from cartoons.
Turns out that I'd never heard "Get Along, Little Doggie" before that, either.
I've come to learn that when you combine craftsmanship and engineering, you end up with something that doesn't tend to break, and is almost always extremely useful.
Throw "art" into the mix, and you end up with something that is marginally useful, full of potential design flaws introduced for the sake of art that may cause it to break, and not terribly fun to look at.
This seems to fit. I put art into parentheses because I believe that a good craftsman is an artist. He makes the art seem invisible, and you admire the design for its utility - for how it fits you. Seems like art to me.
To me, it'd be cooler if they unveiled a clock that will always keep accurate time and won't need repairs or replacements except once every fifty years or so.