How are they going to get feedback from their users?
Release things that would currently be released as "labs" offerings either as "experimental features" in a selectable beta version of an established product, or as limited release independent products that have a roadmap to being full self-sustaining products.
They've actually done a lot of that while Labs was alive, and I'd expect that to continue.
how can a small co innovate if one with deep pockets either can't or refuses to?
Small companies have always been better at innovating than big companies, because big companies have investors that want a secure rate of return, while small companies tend to be funded by people with more risk tolerance who are willing to except greater risk for greater potential return.
So let me get this straight. The US sends jobs overseas to India when we have high unemployment.
Actually what India is asking for (note, India is asking: there is no indication that anyone in the U.S. government is doing anything but recieving the request) is that Indian workers employed on notionally temporary Visas in the U.S. are granted an exemption from U.S. taxes that will make hiring such workers in the U.S. more attractive to U.S.-based employers.
Perhaps we need a domestic policy that gives priority for the US government to give jobs to qualified Americans.
We already have one. The issue here is private jobs, not government jobs. Most U.S. government jobs require U.S. citizenship. I think some may accept lawful permanent residents. None allow H-1Bs.
I hate to break it to you but they have already pissed away all of your social security "savings". The lock box you hear about is just filled with I.O.Us (government bonds).
In the same way that the "lock box" that you call a "bank account" is just filled with your banks promise to provide you cash, which they don't even hold enough to cover, as its all tied out in loans they have to other people (that is, they promise that they'll pay you with money that other people have promised to pay them.) If you have the right kind of account, all those promises are backstopped by a promise that the U.S. government will pay you if your bank can't.
And I won't even begin to consider how that compares to most investment options...
As a H1B, no, you are not eligible for social security. (Taxation without representation?)
Uh, no. I mean, H1B's are taxed without representation, but not for that reason. Because being eligible for social security isn't representation either. H1B's (and green card holders, who are eligible for social security, and anyone else who is not a citizen but is subject to any federal, state, or local taxes in the U.S., no matter which tax and no matter what benefits they are eligible for) are taxed without representation because they are taxed by the US government (and/or by State governments, including administrative subdivisions of states) but have no right to representation in the US or State government.
Representation in a government is (logically) orthogonal to eligibility for benefits provided by that government.
and jail != prison. Jail is where people are held awaiting trial or sentencing.
Or where they go after sentencing for minor crimes with relatively short terms of incarceration in most U.S. jurisdictions (under 1 year is, as I recall, a fairly common rule.) Or where they go after sentencing for most crimes under California's plan to meet the federal court order to reduce the population in its overcrowded State prison system. There's not really a consist, bright line -- even among U.S. jurisdictions -- between what "jail" and "prison" are used for.
so if a judge decides that you just need to pay a fine for a dui incident, you did not commit a criminal act?
No, DUI is a crime (at least, AFAIK, in all U.S. jurisdictions), independently of whether or not jail time is involved. All things that send you to jail* are crimes, but not all crimes send you to jail.
All things that are crimes are illegal, but not all things that are illegal are crimes (while a crime might have a fine, civil offenses which might result in damages or a civil monetary penalty that looks a lot like a fine are not criminal, despite being illegal.)
Things that send people to jail are a subset of crimes, and crimes are a subset of illegal acts; it is an error to equate the argument that "X should be illegal" with "X should result in people going to jail". The latter may imply the former, but the former does not imply the latter.
* actually, there are some exceptions such as being held as a material witness, etc., but they are tangential to the basic categorization of ways of breaking the law here.
** except that it doesn't, either, as explained in the immediately previous point.
This is the judicial equivalent of saying "cry about it."
Actually, its not. The DHS lost, was found to have acted illegally by adopting the rule without public comment, and is forced to go through the regular public-comment rulemaking procedure (contrary to DHS's arguments in the case that they could not only implement the rule that they were using without public comment, but could in theory go further and adopt a rule requiring strip searching every single air traveler without such process.)
Its fairly typical for courts to return matters to lower courts of regulatory agency to follow the proper process without reversing the outcome when they find that a decision was flawed due to a procedural error, and go further only when if and when an outcome from the lower court or regulatory agency is challenged after having gone through the proper procedure.
Optimum solution to getting them to change their minds is for us to take a path of suffering instead of a path of violence. We all subject ourselves to the pat down. Then it will take 12 hours to get through the check points
Then the TSA administrators will solve the problem by removing the option of the pat down, citing the delays and inconvenience produced as rendering the pat down option impractical, so everyone will have to go through the scanners.
This is an optimum solution if and only if the problem you perceive is the availability of the pat down option. If you are trying to get rid of the scanners, it doesn't help at all. The pat down exists to make people chose the scanners; if it doesn't serve that purpose, the TSA administrators will be more than willing to just mandate the scanners which is what they really want.
If you want to eliminate the scanners, instead of everyone choosing the pat down, everyone needs to refuse to fly and cite the pat down vs. scanner choice as the reason. If airlines can't sell tickets because of the TSA's choice of security procedures, those procedures will change. (That is, if regular procedures don't work: bombarding the TSA with negative comments during the public comment period, and then challenging the outcome of that process in the courts is also an avenue that ought to be pursued.)
Really? Because almost everyone I know on both Google+ and Facebook has pretty much already stopped using Google+ and gone back to using Facebook exclusively.
Everyone you know isn't a random sample from which valid conclusions about the rest of the world can be drawn.
It's not even a critical mass thing. it's that it just does a hell of a lot less than Facebook.
Which is why its in a limited preview with core functionality; this is how Google grows products before they are ready for general release.
Sure it may be more private by default but in exchange for everything Facebook offers, given that one can also do a hell of a lot to make a Facebook profile private...
More private by default or better maximum privacy aren't major benefits of Google+, better control of who things are shared with is.
A musical recording of some notes taken to replicate the musical notes as closely as possible, even if it requires great technical skill for breathing and such, is not a creative work, but an uncopyrightable derivative of the musical notes.
Does that mean recorded songs are not copyrightable?
I'm not sure GP is correct with the statement about photographs on which this is based, but, no, a recording to reproduce an existing musical work is a copyrightable derivative of the original (that is, it is subject to copyright as its own work, but it is also a derivative work and so the right to create it is impacted by the exclusive rights of the copyright holder of the original work with regard to derivatives.)
Don't know about Openstack, but KVM and Xen both suffer the same problem.
They provide you with a fairly primitive - albeit effective - toolkit. They don't provide you with a pre-cooked setup which you can just hit "Install" on and 15 minutes later, away you go. If you want to do anything flashy (for instance, put together something that competes with AWS), you are going to have to dedicate insane amounts of time to it.
I think that's true (by design, really) for KVM and Xen, but Openstack and Eucalyptus are, as I understand it, more complete packages (Eucalyptus is API-compatible with AWS, and OpenStack is, from my understanding, similar in scope to Eucalyptus but uses a different API.)
"The Cloud" is a vague term which is sometimes used to refer to cloud computing (whether or not remote hosting is involved), sometimes used to refer to simple remote application hosting whether or not clould computing is involved, and sometimes used to refer to web-based applications, whether or not remote hosting (from the business to whom the app belongs) or cloud computing are involved.
EC2 is an Infrastructure-as-a-Service (IaaS) offering using cloud computing (dynamic on-demand logical server provisioning, which abstracts, from the user, the underlying physical servers) technology.
If a service cannot survive simultaneous catastrophic failures in multiple physical locations, it is not a cloud service.
That's certainly a kind of service that is facilitated by cloud computing technologies, but services like that existed before cloud computing, and not all applications of cloud computing are intended to provide that particular feature.
Because inefficiencies in the use of shared resources produce external costs, which are internalized by increasing the costs of transactiosn involving those inefficiencies. (The choice between taxes/fees and bans as a method of internalizing external costs is a whole different discussion.)
If you want to ban it cause it's toxic, that's one thing, but if you want to ban it just because it is a waste of money, isn't that what market forces are for?
The ban on incandescent bulbs aren't because they are an inefficient use of the purchaser's money, its because they are an inefficient use of the shared resources expended when they are used (this is, conceptually, the same reason on a more general level as a ban due to toxicity.) Further, things that are inefficient for the purchaser in the way that incandescent light bulbs might arguably be (low initial costs, but higher long-term costs) are things that "market forces" demonstrably deal with poorly, since the reliance on market forces to correctly deal with that kind of efficiency is reliance on people basing decisions on the actual expected disutility of a future cost stream distributed over time, and cost/benefit streams distributed over time are one of the things (like risk) that people demonstrably do not account for well in making economic decisions. But if there weren't social costs involved, even noting that market forces would not correct the personal inefficiency for the reasons described, there arguably wouldn't be any justification for public action.
How ten years ago of you. You do realize that MySQL and Postgres are getting rather close on feature parity right?
No, they aren't.
Both of them have been adding features the other lacked.
Maybe true, but PostgreSQL has also been adding features that neither PostgreSQL nor MySQL had before, and keeping its lead.
The biggest selling point with Postgres for me is the schema handling/support.
The rule system and support for more-advanced standard SQL features like Common Table Expressions is a big one for me. The richer type system is a plus, too. And there's a slew of new stuff well along in the pipeline (like Range Types).
TFS implies that there was some kind of specific decision to choose North Korea to preside based on an assessment of merit, but this is not the case. The rules of procedures for the Conference of Disarmanent state (in rule 9): "When the Conference is in session, the Presidency of the Conference shall rotate among all its members; each President shall preside for a four-working-week period."
Teaching kids JS first then real OO languages later will confuse the crap out of them.
Not really. Unless, by "real OO" languages you mean languages that feature class-based OO where classes aren't, themselves, first class objects rather than class-based lanugages with first-class classes (e.g., Ruby).
The class-based languages without first-class classes might be confusingly crippled to someone who learned either a prototype-based language like JavaScript or a class-based language with first-class classes first, but I wouldn't call those problematic language "real OO" as compared to either class-based languages with first-class classes or prototype-based languages.
With the exception of calling by reference and maybe linked lists nothing here is low level: these are programming language features that you need to know as soon as possible so you can focus on the interesting stuff (designing efficient algorithms for instance).
Well, no, you can optimize efficiency within the constraints of an environment without any of those things, if you know the performance characteristics of the elements of the language you are using. You can analyze and optimize the efficiency of algorithms in languages in which things like strong typing and explicit declaration do not exist.
And, while optimizing algorithmic efficiency becomes important, its only important after you know how to analyze a problem and implement a correct solution in code. So even if knowing those things was necessary to be able to learn how to do that (its not, in general, though of course it is when you are working in an environment in which those things are present.)
How can you even program if you don't know how to use recursion ?
By using iteration. Which tends to be safer than recursion in most languages where learning any of the other things on the list would be meaningful, because they tend not to feature tail-call optimization, and so even the cases of recursion that are safe to use without worry in languages that feature tail-call optimization aren't safe. (On the other hand, the poster upthread was wrong to feature recursion on the list, since recursion in JavaScript is just as easy as in most modern languages.)
But I guess that's also a cultural thing. When I was taught the basics we had that in two separate modules: algorithms (pen and paper) and programming languages (the gory details).
I think its a matter of focus. Its important for people who are going to be CS majors to understand computers at a low level, and that should probably happen fairly early on in the major (maybe in the introductory class using a model like you describe hear, maybe a little later, but definitely the coding part of that should use things that are fairly low level for the platform they are implemented on, like C/C++ for most platforms or Java on the JVM.)
OTOH, I think for non-majors -- and possibly for a first course in the major, with the lower-level course as a second course -- the important thing is to focus on the higher level analytical and programming process of building and validating correct (whether or not optimal, from a performance standpoint) solutions to problems.
If you aren't majoring in CS, its quite likely that the main value you will get out of learning programming (assuming that you end up working in whatever field you are majoring in) is doing solo projects to support whatever your field is, or doing requirements analysts on a project where professionals are doing the actual coding; in either of those areas, its more critical that you can analyze a problem and understand how to approach a correct solution (and, in the first case, that you can actually implement that correct solution) than that you can optimize performance.
JavaScript can/does do objects perfectly well. You choose not to, but then again you can choose not to write object-oriented code in C++ as well.
What GP said about JavaScript OO: "Quit thinking of JS as object-oriented. Just stop. Yes, it has some OO cludges, and it can kinda-sorta-not-really do objects, but it's much closer to a functional language."
That works better for C++ (with "functional" replaced with "procedural") than it does for JavaScript in its original form.
(Yes, yes, for lots of people "object-oriented" has come to be defined by behaving like C++ -- and languages influenced fairly directly by C++, like Java -- rather than Smalltalk and languages which were inspired more directly by Smalltalk rather than getting through C++, but, man, talk about ugly cludges...)
Then when? The sooner you get this stuff carved into the students' minds, the better.
I disagree. Most of that stuff is peripheral to the important skills in programming. (Though they are important skills to coding in certainl languages.) The later you get people to focus on those kinds of low-level details, the better, more flexible programmers they will end up being.
Minimize those kind of incantantions, and students can focus on problem analysis, logical design of the solution, and implementation of the solution using high-level code.
Its certainly useful if people are going to do much more with programming that they will need to learn languages that are closer to the machine and understand more low-level implementation details and the differences between different low-level approaches, but in an introductory course focus on those things is, IMO, a distraction from the focus on designing solutions to problems.
Linked lists. Recursion. Calling by reference. Strong typing. Explicit declaration (or at least the need of it). There are some ways around those, but these hacks are even going to warp their minds worse than not learning those things would.
None of which are important to the process of problem analysis and programming, though obviously those are important tools for implementing programs in some common languages, which are sometimes used for good reasons. They are certainly things that are important to learn in the course of a degree in computer programming, but they aren't things that are important to learn an introductory class for non-majors.
Sure, it offers quick satisfaction, but when you hit the wall (and you do soon in JS), you hit it hard because what you learned will not translate well into a more powerful and flexible language.
JavaScript is a more powerful and flexible language than most of the popular ones that would make learning the things you reference meaningful. (It may not be, in its available implementations, as fast, but that's often diametrically opposed to powerful and flexible.)
Slashdot Mirror
Release things that would currently be released as "labs" offerings either as "experimental features" in a selectable beta version of an established product, or as limited release independent products that have a roadmap to being full self-sustaining products.
They've actually done a lot of that while Labs was alive, and I'd expect that to continue.
Small companies have always been better at innovating than big companies, because big companies have investors that want a secure rate of return, while small companies tend to be funded by people with more risk tolerance who are willing to except greater risk for greater potential return.
Actually what India is asking for (note, India is asking: there is no indication that anyone in the U.S. government is doing anything but recieving the request) is that Indian workers employed on notionally temporary Visas in the U.S. are granted an exemption from U.S. taxes that will make hiring such workers in the U.S. more attractive to U.S.-based employers.
We already have one. The issue here is private jobs, not government jobs. Most U.S. government jobs require U.S. citizenship. I think some may accept lawful permanent residents. None allow H-1Bs.
In the same way that the "lock box" that you call a "bank account" is just filled with your banks promise to provide you cash, which they don't even hold enough to cover, as its all tied out in loans they have to other people (that is, they promise that they'll pay you with money that other people have promised to pay them.) If you have the right kind of account, all those promises are backstopped by a promise that the U.S. government will pay you if your bank can't.
And I won't even begin to consider how that compares to most investment options...
Uh, no. I mean, H1B's are taxed without representation, but not for that reason. Because being eligible for social security isn't representation either. H1B's (and green card holders, who are eligible for social security, and anyone else who is not a citizen but is subject to any federal, state, or local taxes in the U.S., no matter which tax and no matter what benefits they are eligible for) are taxed without representation because they are taxed by the US government (and/or by State governments, including administrative subdivisions of states) but have no right to representation in the US or State government.
Representation in a government is (logically) orthogonal to eligibility for benefits provided by that government.
When Linux was released, BSD wasn't open source, and neither was Minix, and being open source was the compelling advantage of Linux.
Now, BSD is open source, and Linux is open source, and Minix 3 is open source, and the list goes on.
Or where they go after sentencing for minor crimes with relatively short terms of incarceration in most U.S. jurisdictions (under 1 year is, as I recall, a fairly common rule.) Or where they go after sentencing for most crimes under California's plan to meet the federal court order to reduce the population in its overcrowded State prison system. There's not really a consist, bright line -- even among U.S. jurisdictions -- between what "jail" and "prison" are used for.
No, DUI is a crime (at least, AFAIK, in all U.S. jurisdictions), independently of whether or not jail time is involved. All things that send you to jail* are crimes, but not all crimes send you to jail.
All things that are crimes are illegal, but not all things that are illegal are crimes (while a crime might have a fine, civil offenses which might result in damages or a civil monetary penalty that looks a lot like a fine are not criminal, despite being illegal.)
Things that send people to jail are a subset of crimes, and crimes are a subset of illegal acts; it is an error to equate the argument that "X should be illegal" with "X should result in people going to jail". The latter may imply the former, but the former does not imply the latter.
* actually, there are some exceptions such as being held as a material witness, etc., but they are tangential to the basic categorization of ways of breaking the law here.
** except that it doesn't, either, as explained in the immediately previous point.
Actually, its not. The DHS lost, was found to have acted illegally by adopting the rule without public comment, and is forced to go through the regular public-comment rulemaking procedure (contrary to DHS's arguments in the case that they could not only implement the rule that they were using without public comment, but could in theory go further and adopt a rule requiring strip searching every single air traveler without such process.)
Its fairly typical for courts to return matters to lower courts of regulatory agency to follow the proper process without reversing the outcome when they find that a decision was flawed due to a procedural error, and go further only when if and when an outcome from the lower court or regulatory agency is challenged after having gone through the proper procedure.
Then the TSA administrators will solve the problem by removing the option of the pat down, citing the delays and inconvenience produced as rendering the pat down option impractical, so everyone will have to go through the scanners.
This is an optimum solution if and only if the problem you perceive is the availability of the pat down option. If you are trying to get rid of the scanners, it doesn't help at all. The pat down exists to make people chose the scanners; if it doesn't serve that purpose, the TSA administrators will be more than willing to just mandate the scanners which is what they really want.
If you want to eliminate the scanners, instead of everyone choosing the pat down, everyone needs to refuse to fly and cite the pat down vs. scanner choice as the reason. If airlines can't sell tickets because of the TSA's choice of security procedures, those procedures will change. (That is, if regular procedures don't work: bombarding the TSA with negative comments during the public comment period, and then challenging the outcome of that process in the courts is also an avenue that ought to be pursued.)
Everyone you know isn't a random sample from which valid conclusions about the rest of the world can be drawn.
Which is why its in a limited preview with core functionality; this is how Google grows products before they are ready for general release.
Sure it may be more private by default but in exchange for everything Facebook offers, given that one can also do a hell of a lot to make a Facebook profile private...
More private by default or better maximum privacy aren't major benefits of Google+, better control of who things are shared with is.
And, beyond that, illegal != criminal. Lots of things are illegal and don't result in anyone going to jail.
Like every other TSA incident where people have said this, it won't.
People will continue to complain, and no one will do anything that matters.
I'm not sure GP is correct with the statement about photographs on which this is based, but, no, a recording to reproduce an existing musical work is a copyrightable derivative of the original (that is, it is subject to copyright as its own work, but it is also a derivative work and so the right to create it is impacted by the exclusive rights of the copyright holder of the original work with regard to derivatives.)
I think that's true (by design, really) for KVM and Xen, but Openstack and Eucalyptus are, as I understand it, more complete packages (Eucalyptus is API-compatible with AWS, and OpenStack is, from my understanding, similar in scope to Eucalyptus but uses a different API.)
"The Cloud" is a vague term which is sometimes used to refer to cloud computing (whether or not remote hosting is involved), sometimes used to refer to simple remote application hosting whether or not clould computing is involved, and sometimes used to refer to web-based applications, whether or not remote hosting (from the business to whom the app belongs) or cloud computing are involved.
EC2 is an Infrastructure-as-a-Service (IaaS) offering using cloud computing (dynamic on-demand logical server provisioning, which abstracts, from the user, the underlying physical servers) technology.
That's certainly a kind of service that is facilitated by cloud computing technologies, but services like that existed before cloud computing, and not all applications of cloud computing are intended to provide that particular feature.
Because inefficiencies in the use of shared resources produce external costs, which are internalized by increasing the costs of transactiosn involving those inefficiencies. (The choice between taxes/fees and bans as a method of internalizing external costs is a whole different discussion.)
The ban on incandescent bulbs aren't because they are an inefficient use of the purchaser's money, its because they are an inefficient use of the shared resources expended when they are used (this is, conceptually, the same reason on a more general level as a ban due to toxicity.) Further, things that are inefficient for the purchaser in the way that incandescent light bulbs might arguably be (low initial costs, but higher long-term costs) are things that "market forces" demonstrably deal with poorly, since the reliance on market forces to correctly deal with that kind of efficiency is reliance on people basing decisions on the actual expected disutility of a future cost stream distributed over time, and cost/benefit streams distributed over time are one of the things (like risk) that people demonstrably do not account for well in making economic decisions. But if there weren't social costs involved, even noting that market forces would not correct the personal inefficiency for the reasons described, there arguably wouldn't be any justification for public action.
No, they aren't.
Maybe true, but PostgreSQL has also been adding features that neither PostgreSQL nor MySQL had before, and keeping its lead.
The rule system and support for more-advanced standard SQL features like Common Table Expressions is a big one for me. The richer type system is a plus, too. And there's a slew of new stuff well along in the pipeline (like Range Types).
TFS implies that there was some kind of specific decision to choose North Korea to preside based on an assessment of merit, but this is not the case. The rules of procedures for the Conference of Disarmanent state (in rule 9): "When the Conference is in session, the Presidency of the Conference shall rotate among all its members; each President shall preside for a four-working-week period."
Not really. Unless, by "real OO" languages you mean languages that feature class-based OO where classes aren't, themselves, first class objects rather than class-based lanugages with first-class classes (e.g., Ruby).
The class-based languages without first-class classes might be confusingly crippled to someone who learned either a prototype-based language like JavaScript or a class-based language with first-class classes first, but I wouldn't call those problematic language "real OO" as compared to either class-based languages with first-class classes or prototype-based languages.
Well, no, you can optimize efficiency within the constraints of an environment without any of those things, if you know the performance characteristics of the elements of the language you are using. You can analyze and optimize the efficiency of algorithms in languages in which things like strong typing and explicit declaration do not exist.
And, while optimizing algorithmic efficiency becomes important, its only important after you know how to analyze a problem and implement a correct solution in code. So even if knowing those things was necessary to be able to learn how to do that (its not, in general, though of course it is when you are working in an environment in which those things are present.)
By using iteration. Which tends to be safer than recursion in most languages where learning any of the other things on the list would be meaningful, because they tend not to feature tail-call optimization, and so even the cases of recursion that are safe to use without worry in languages that feature tail-call optimization aren't safe. (On the other hand, the poster upthread was wrong to feature recursion on the list, since recursion in JavaScript is just as easy as in most modern languages.)
I think its a matter of focus. Its important for people who are going to be CS majors to understand computers at a low level, and that should probably happen fairly early on in the major (maybe in the introductory class using a model like you describe hear, maybe a little later, but definitely the coding part of that should use things that are fairly low level for the platform they are implemented on, like C/C++ for most platforms or Java on the JVM.)
OTOH, I think for non-majors -- and possibly for a first course in the major, with the lower-level course as a second course -- the important thing is to focus on the higher level analytical and programming process of building and validating correct (whether or not optimal, from a performance standpoint) solutions to problems.
If you aren't majoring in CS, its quite likely that the main value you will get out of learning programming (assuming that you end up working in whatever field you are majoring in) is doing solo projects to support whatever your field is, or doing requirements analysts on a project where professionals are doing the actual coding; in either of those areas, its more critical that you can analyze a problem and understand how to approach a correct solution (and, in the first case, that you can actually implement that correct solution) than that you can optimize performance.
What GP said about JavaScript OO: "Quit thinking of JS as object-oriented. Just stop. Yes, it has some OO cludges, and it can kinda-sorta-not-really do objects, but it's much closer to a functional language."
That works better for C++ (with "functional" replaced with "procedural") than it does for JavaScript in its original form.
(Yes, yes, for lots of people "object-oriented" has come to be defined by behaving like C++ -- and languages influenced fairly directly by C++, like Java -- rather than Smalltalk and languages which were inspired more directly by Smalltalk rather than getting through C++, but, man, talk about ugly cludges...)
I disagree. Most of that stuff is peripheral to the important skills in programming. (Though they are important skills to coding in certainl languages.) The later you get people to focus on those kinds of low-level details, the better, more flexible programmers they will end up being.
Minimize those kind of incantantions, and students can focus on problem analysis, logical design of the solution, and implementation of the solution using high-level code.
Its certainly useful if people are going to do much more with programming that they will need to learn languages that are closer to the machine and understand more low-level implementation details and the differences between different low-level approaches, but in an introductory course focus on those things is, IMO, a distraction from the focus on designing solutions to problems.
None of which are important to the process of problem analysis and programming, though obviously those are important tools for implementing programs in some common languages, which are sometimes used for good reasons. They are certainly things that are important to learn in the course of a degree in computer programming, but they aren't things that are important to learn an introductory class for non-majors.
JavaScript is a more powerful and flexible language than most of the popular ones that would make learning the things you reference meaningful. (It may not be, in its available implementations, as fast, but that's often diametrically opposed to powerful and flexible.)
Java is not "most of the alternatives" to JavaScript as a learning language.