Are you sure about that? What grounds would you fire such a person under? Is it against the law to criticize your employer?
It is not against the law for an employer to fire an employee for criticizing him/her/it. Freedom of speech is not required to be defended within the premises of a private entity, nor does it give you ABSOLUTE IMMUNITY from the consequences of your actions. If you cannot make that distinction, you are an ignorant fool.
Consider this, if you work for an employer, and you tweet "my employer sucks", do you honestly believe you are immune from getting fired (even if indeed your employer sucks)?
The only things you cannot get fired for are already stipulated in federal and state laws. The typical protections against labor discrimination regarding gender, age, race, religion, political affiliation, retaliation over obeying the law, sexual harassment, and other protected statuses that emanate from them.
The list sorely misses some important ones (say, sexual orientation), but that is not to say that bad mouthing or publicly criticizing your employee (or doing anything that gives a "bad" image, something that will most likely be in the employment agreement that you willing signed) should be protected against getting fired for it. That is just silly.
Most IT Workers Don't Have STEM (Science, Tech, Engineering, Math) Degrees
In a nutshell: IT =/= STEM. Never has. Never will.
In details: most work under the "IT" umbrella (mundane app development included) doesn't require a 4-year college degree either.
I started my career as a software developer with an AA degree (and a shitload of programming courses, with "shitload" being relative to what most sophomore/junior college students have.) Later I completed a BS degree in CS, and later went to grad school. I've done development, software engineering, architecture on both the application and system programming domains, commercial or defense sectors, enterprise, embedded, whatever. I've also done IT work (including systems administration.)
Rarely I've had to rely on significant CS/STEM skills to do work when it came to do IT work. And yet, we insist on people getting a 4-year degree in CS as a mandatory requirement to do IT. That's bull. All you need is a good 2 years under a solid AS community college curriculum to get the necessary skills, with programming courses not on one, or two, but three or more programming languages, in series that increase in complexity of topics, databases and the basics of network infrastructure.
That kind of education will prepare people with the skills necessary for 80% of the work encountered in IT. Anything above that would probably require the skills and education that come with a 4-year degree.
We really need to stop deluding ourselves into thinking IT is a subset of STEM.
But after digging the code Georg Lukas concluded that the blame goes to Oracle.
Why is it Oracle's fault? I'm not a fan of Oracle, but I fail to see why blame of this situation goes to it? It would seem that Google, given the plenty of implementation latitude it already has on Android, that it could have side-stepped compatibility to provide stronger cyphers.
So why is this Oracle's fault and why no mention of Google's fault exist in this one-sided article? As Colbert once said "I can't prove it, but I can say it.". That seems to be what governs the writing of this particular submission.
It goes from corporate espionage to some guy stealing credit card numbers as a 'hobby'.
I work at a major corporation that has security cards to get into the building and my computer is password protected with an encrypted hard drive & a physical lock on the computer. Are security guards with guns really necessary?
Depends on the situation. If your property is that valuable, perhaps. Now, consider this:
If people are willing to physically break into your facilities, that's passing the threshold that divides a cyber-violation to a physical violation. Statistically, breaking into someone's property usually correlates with a willingness to commit physical aggression. With that in mind, guns for security guards and LEO's are not simply to "shoot" the bad guys, but for them to protect themselves.
If I owned a property that has been broken into, or that is at risk of suffering a break-in, and if I had a need to protect valuables inside, I could not in good conscience put a security guard there with no legal means to defend himself if/when SHTF.
Cool story. Would be a lot cooler if you didn't work for Blackberry. It's not like you hide your identity well Aaron Wiebe.
I don't have an e-dog in this e-fight, but c'mon, why don't you address his points (and debunk them if you have the arguments to do so) instead of launching an ad-hominem?
Because it is not as economical (in terms of software development efficiency) compared to Java (that's my perspective as a a C/C++/Java developer in the *NIX and Windows, app and embedded arenas.)
This. As a US citizen, it embarrasses me how uninformed US citizens are about wtf is happening in the rest of the world. Outside the realms of operating systems, the US is a follower in the mobile workd (hardware, ecosystems, marketing, logistics), not a leader.
Nokia used to be such a big player in the mobile market that they did not need to become "yet another Android vendor". They had the know-how, capital, fame, and few billions of loyal customers to either come up with a competing OS (MeeGo) or just fork Android and not give a flying fuck about Google trademark. They even had Nokia-built map and navigation good enough to rival Google's.
By resting on its laurels and past fame (like Motorola did), Nokia ended up the way it did (like Motorola did.) It should have given a fuck about Android (or even gone Windows Phone). But it didn't, so, all that remains for it now is to indulge in past glories while circling down the drain.
That's absurd. Learning time-sensitive ordered tasks, such as in music or dance, or alternative ways to express similar ideas, such as language skills, are invaluable to skilled programmers. The ideas of checklists, logical operations, and revising a program on the basis of alternate events, learning about backup and what you can lose without it, are all useful.
I'd be more concerned about what happens with _bad_ programming lessons, being taught to manipulate only GUI based patterns in a teacher expected way or be marked down for not doing it the way an uninformed, underpaid coding monkey wrote to mark the checksheet off their daily tasks and pays no attention to encouraging the children to learn how things work. I'm concerned tht the children will be taught only how to fill out a checklist blindly. I've worked with programmers taught that way, and they can become an active obstacle to good computing, good science, or even good politics.
I'm afraid that a lot of the pre-teen children I've been meeting in public school would be better off, though, with real recess or a daily siesta rather than yet another mandatory lesson that requires sitting in a computer classroom. They're exhausted, and getting their bodies moving is being neglected in conflicting academic policies and goals.
Finally someone who is paying attention to children's physiology. Their sleeping patterns are different from adults, and they do require additional sleep (and depending on their age, different nutritional content.)
Also, as you said, it is important to give precedence to more fundamental, cognitive/social skills. Slashdot is infected by too many keyboard warriors that think coding should become a basic, fundamental topic. It is not.
Don't rush kids into learning to code. Get them to learn the essentials first, math/algebra, natural sciences, language, history, civics and the basics of personal finance. All that, in particular personal finance, are more important that learning to code. We have a lot of shitty coders as it is, and a lot of people who suck at the basics of math, history, civics and logical thinking. What the do people think it's going to happen when we rush/force kids to learn to code?
Also, who is going to teach coding? A proficient developer, or a we going to repeat the current pattern of forcing a teacher of specialty X to teach specialty Y for which he/she is completely unqualified?
TFA says this is for "Rich Internet Applications," that is, Java applets embedded in Web pages. It doesn't seem this would affect Java programs that you execute locally, such as (for example) Eclipse.
It begs the question, who the f* still writes java applets in this time and age, specially for web RIA? So many options exist for RIA in Java or JavaScript (or both), applets are, in general a devil's spawn from a distant past (and a clumsy tool for the clueless software shop.)
"What's funny is it really doesn't take much effort to be more enjoyable than the C++ examples from earlier...just getting to write gets.chomp and puts over cout > made all the difference. Ruby examples kept me engaged just long enough that I could find Why's Poignant Guide to Ruby.
To me, this just does not make any sense. The preference of gets.chomp over cout << (or viceversa) are so subjective that they borderline on the ridiculous. I don't think I will ever relate to such minutia. Even when I was in my formative years as a future programmer, such minutia seemed as irrelevant then as it does now.
At least for me my focus and motivation were always a) what can I create with this programming language, and b) how can I tame this beast. That's the approach I took with BASIC, with Pascal, with Delphi, with C and C++, with assembly, with Ada, with Lisp and Prolog, with Java, with C# and so on and so on.
The only thing out of this story that I could relate to is that indeed C++ (like Java and C#) is a horrible introductory language, and that something like Ruby (or Python or Lisp or BASIC or a Pascal variant) is a better prog-101 language. Heck, I would go as far as to claim that Assembly (a real one or a simulated one) is better to teach programming than C++.
But to suggest that such ridiculous minutia "engages" someone to learn, to me that's suggestive of prioritizing on the wrong things. Every person is different and unique and perhaps *THIS* works for them. To me OTH, it has always been about being able to create more and more powerful things with whatever language I had to learn (or work with.) Syntactical minutia is just not such a significant impediment unless you focus on them and give them greater power (positive or negative) than they actually have.
As for the value of goofing, of course that is important, but that is not a function of the language. It is a function of the professor, and the student. I know professors that will suck at it even if they use Ruby, and I've had wonderful professors that took me on great journeys with whatever language, low-level or high-level, that they were teaching at the time.
Ultimately, fun is subjective and it is just a function of what you make of the things you have at your disposal. Your learning potential will likely suffer if you take minutia as the focus of your likes or dislikes.
Yeah. Funny enough, people in my country always say that long-term investments in R&D and etc are the last places you want to cut in a crises because they garantee our future.
That's stupid. If you're in a crisis, you make sure everybody has food on the table, you get people into jobs, the economic going.. then you re-invest in the long-term stuff. This is obvious in a household. But for whatever reason it doesn't follow for some.
Maybe because a household =/= a whole goddamned state?
I cannot imagine one such company to be honest (a relevant company that is.) Until recently I worked in the defense sector, which is very bureaucratic and regulated. And even there, Blackberry isn't even in the most remote of pictures with the future (a distant BYOD future that is), it is all iOS or Android.
Having no need for Windows, I really don't keep up with its capabilities. But, really, this is the year 2013 --- Windows is still that pathetic, that basic tasks like syncing files between multiple computers take special software that doesn't just come with the OS? Why is anyone still using that crap? Are corporations really so utterly incompetent on IT issues that they'd put up with shit like this because they don't know any better?
Dude, even on Linux, you need special software to synch files (rsync, git, whatever.) Since file synching is an app-specific functionality, this is not a OS problem. This is an operator problem, and I've seen Linux/Unix sysadmins doing the same kind of crap job as the one described in the original question/article/whatever.
This is a solved problem on both Windows or Linux/Unix. But incompetent IT staff exists on both domains. You can't defensively program against stupid (nor should you.)
It's not great (not my first choice), but it is not that awful either. I like the concept of a vob and the powerful access control models that come with it. It's just the idiotic complexity of attributes and objects in ClearCase that uglifies it.
This works great with only one caveat: most office documents are binary files (or are treated like binary files by the SCM), so you'll need to put a process in place to lock the file in question prior to editing to prevent people stomping over others' changes to them.
That's typically not needed. MS Office products, for instance, have built-in diff review-n-merge capabilities. And even without such a capability, a src-controlled binary is simply that, a coarse-grained resource. Whoever commits the last is the one whose changes prevail. This is what is done with SharePoint anyways or TeamSite anyways. No need for locking.
You'll have to excuse him, he comes from Windows Land:)
Meh, I know you are posting in jest, but honestly, I've seen people from Unix-land also having no clue about source control/revision control systems. Proficient software people (Unix, Windows or whatever) know how and when to use such a system. Everybody else, well, you get what the submitter is describing:/
Unless you want your students to only use scripting languages and whitespace formatting forever, you're setting them up for failure.
This only true if the student does not cover anything but scripting languages. That is not an argument that I made, but don't let that stop you from building a straw man.
What are they to do when they get into the real world and run into "semantic baggage" languages in the enterprise space?
Well, what is a student to do in the real world when they encounter the "semantic baggage" of the enterprise with only one or two introductory programming courses using either C++ or Java? Would you expect a student to be able to be capable to deal with the real world with a course or two, regardless of the programming language used?
Obviously not. So your question is moot and not really meaningful. A person is supposed to get grilled through a curriculum of programming courses, ideally exposing them to a variety of programming languages and paradigms.
Become website designers because programming is too hard?
No. Selecting an appropriate kaleidoscope of programming languages and paradigms that allow a constructive introduction of hard subjects, starting from the basics of problem solving and control structures, models of computation with minimum baggage possible. Can be Python, BASIC, Lisp, Pascal or C. Hell, it can be even Assembly (that's how it was done before with good results anyways.)
I don't care what language you chose for teaching, one or two elementary courses will never equip anyone to the real world. Furthermore, Java, C++, Scala, C#, Erlang or Haskel are not appropriate for that level of teaching. They are great languages at the intermediate or advance level, after the prospective student has been grilled on the basics in a repetitive fashion in one or more of the languages I mentioned before (C, Python/Ruby kept proceduraly, or BASIC.)
Then, once a person has gone through a barrage of programming problems, and with a solid grasp of procedural programming, then they can move to object oriented and functional programming. Why? Because by now they can focus on those topics alone as opposed to having to deal them (quite ineffectively) while still wondering whether to use a for loop or a while loop (I see that a lot with schools that insist in teaching with Java or C++ from the start.)
If they can't grasp OOP up front then they shouldn't be programmers.
And yet, you see (or I least I see) the industry full of professional programmers who are shitty OOP programmers because they can't grasp the fundamental programming principles behind procedural and modular programming. They can't tell me for shit the difference between a class and a struct or plain record, or what makes them different from a ADT. Because they can't still get proper layering of their system because they never really understood what modular programming does for you. Because they never quite got enough homework or work that drill down the concept of divide-and-conquer.
People think "oh yes, I know OOP" and yet they can't tell me how they measure coupling or cohesion in a systematic manner. They can't tell me why delegation and composition is better than plain inheritance. But they can write classes in C++ and Java with their eyes closed like idiot savants.
They can't tell me how or why to layer their classes vertically and horizontally which is something a person can easily deduce if he knows modular programming in a cold-turkey manner.
They think they do not need to know about Cyclomatic complexity because he doesn't use functions but methods. Yes, I've seen people saying that (producers of hyper spaghetti code). They have no clue what basic things LCOM or "tell, don't ask" principles are for, but they sure know how to create class hierarchies in diagrams resembling the death start.
Maybe the problem is you are too stupid to understand complex things?
" Too many semantic subtleties that have nothing to do with elemental programming tasks.
Apparently I am right.
Since insulting seems the way to prove you are right (or let me say "your right" so that you get a chance to bash teh gramm3r), maybe I should just let you assume the answer to your question since you seem to be the pedagogical expert here.
See, your typical answer indicates with almost certainty that you are a) either an inexperienced fanboi or perhaps b) an idiot savant that might have many years of experience, and still be an idiot savant. Perhaps you might be c) a software Sheldon Cooper, but probability alone would dictate that you are either a) or b).
This has nothing to do with me being able to grasp complex software/CS concepts. Perhaps your infantile reading comprehension betrayed you and did not catch the part where I said I've been a software professional for many,many years using Java and C++ for both application and system/embedded development. I'm pretty sure I can draw circles on those languages around many of the self-proclaimed geeks in this site.
It has nothing to do with me. But it has everything to do with teaching an elementary programming course. The consensus among most Java and C++ professionals has always been that either language is piss poor as a programming language FOR AN ELEMENTARY PROGRAMMING COURSE. The few who disagree either have a vested interest while selling Java or C++ books or are academics who have done little to no programming for a living.
Or maybe I'm stupid as you said. I'll weight the substance of each other arguments and see who is the most logically backed-up one. As for you, I will leave you with your high schoolish name calling.
Ruby and Python are scripting languages. Students are better off being exposed to Java or C++ from the start so they can see if they have the knack for programming or not. Sink or swim, as it were. Putting students on scripting languages just creates the perception that they are doing true software development when they are not. If you're going to use Python or Ruby you might as well put them on VBScript or JavaScript. Or go whole hog and put them on CoffeeScript so they don't have to deal with the agony of curly braces and proper formatting.
That's bull. Scripting or otherwise doesn't make a difference for the tasks of learning the basics. Again, based on my 12 years of programming experience with Java, Java is not a good pedagogical choice. And C++ (where I also have work experience)? Please, that's another bad choice. Too many semantic subtleties that have nothing to do with elemental programming tasks. Plain old C is a much better pedagogical option. Like C++, no memory management and plenty of segfaults and pointer management. Unlike C++, no semantic complexities related to OOP, STL, IO streams, clunky/incomplete exception handling mechanisms and the like.
At that level, I'm interested in a student to immediately know how to focus on the details of an algorithmic solution, and the essence of data structures and basic control flows. I'm interested in him/her understanding procedural programming principles.
All the additional semantic baggage that comes with Java and C++ (a function of what *WE* thought was essential language/compiler design principles at the time) just get in the way.
Moreover, this semantic baggage requires the learner to have a certain programming dexterity on the fundamentals that are better obtained when we focus on those alone. Yes, I believe in sink-or-swim as well. But do it with purpose by exposing the essential complexity of programming, not because we suck monkey gonads at choosing our pedagogical tools.
Right, that's 4 concepts which have to be explicitly explained (or passed over) before we even get to how to put a single character on the screen, or add two numbers....
Exactly this. It's accidental complexity that has nothing to do with the fundamental tasks of programming that are supposed to the focus of study.
A BASIC/Python "print" or a Pascal "write/writeln" is supposed to be obsolete and clunky, but System.out.println enclosed within a mandatory class that is just not a class, but a public one, with not just a main function, but a static one, and with its name exactly case-matching the filename that declares it while making sure that no other "public" class exists in said filename, that is supposed to be pedagogical progress </rolls eyes>
I really find it a tedious stumbling block explaining to my kids all the ``public static void main'' stuff --- really wish that Oberon had made it instead. Niklaus Wirth at least has his manuals heading in the right direction (Pascal, hundreds of pages; Modula, a hundred or so, Oberon, dozens).
As a professional who has done Java for application (enterprise/web/web service) and system/network protocol development for 12 years, I would say no. Java is not a good choice for a beginning or even intermediate level programming curriculum. As a very productive platform for developing robust systems, Java delivers.
For pedagogical purposes, specially as a starting programming language, it is atrocious. I would have preferred Python or Ruby focusing first on procedural programming, leaving object and functional features for later (rarely does a student leverages OOP and FP cleanly without having a good grasp of procedural programming, data structures and algorithms.) Or *gasp* BASIC or a Pascal variant or even C (students need to know right of the bat what a segfault is.)
I would typically choose Java for development of robust systems. I would never use it as a language in an into-to-programming course.
Are you sure about that? What grounds would you fire such a person under? Is it against the law to criticize your employer?
It is not against the law for an employer to fire an employee for criticizing him/her/it. Freedom of speech is not required to be defended within the premises of a private entity, nor does it give you ABSOLUTE IMMUNITY from the consequences of your actions. If you cannot make that distinction, you are an ignorant fool.
Consider this, if you work for an employer, and you tweet "my employer sucks", do you honestly believe you are immune from getting fired (even if indeed your employer sucks)?
The only things you cannot get fired for are already stipulated in federal and state laws. The typical protections against labor discrimination regarding gender, age, race, religion, political affiliation, retaliation over obeying the law, sexual harassment, and other protected statuses that emanate from them.
The list sorely misses some important ones (say, sexual orientation), but that is not to say that bad mouthing or publicly criticizing your employee (or doing anything that gives a "bad" image, something that will most likely be in the employment agreement that you willing signed) should be protected against getting fired for it. That is just silly.
Most IT Workers Don't Have STEM (Science, Tech, Engineering, Math) Degrees
In a nutshell: IT =/= STEM. Never has. Never will.
In details: most work under the "IT" umbrella (mundane app development included) doesn't require a 4-year college degree either.
I started my career as a software developer with an AA degree (and a shitload of programming courses, with "shitload" being relative to what most sophomore/junior college students have.) Later I completed a BS degree in CS, and later went to grad school. I've done development, software engineering, architecture on both the application and system programming domains, commercial or defense sectors, enterprise, embedded, whatever. I've also done IT work (including systems administration.)
Rarely I've had to rely on significant CS/STEM skills to do work when it came to do IT work. And yet, we insist on people getting a 4-year degree in CS as a mandatory requirement to do IT. That's bull. All you need is a good 2 years under a solid AS community college curriculum to get the necessary skills, with programming courses not on one, or two, but three or more programming languages, in series that increase in complexity of topics, databases and the basics of network infrastructure.
That kind of education will prepare people with the skills necessary for 80% of the work encountered in IT. Anything above that would probably require the skills and education that come with a 4-year degree.
We really need to stop deluding ourselves into thinking IT is a subset of STEM.
It. Is. Not.
But after digging the code Georg Lukas concluded that the blame goes to Oracle.
Why is it Oracle's fault? I'm not a fan of Oracle, but I fail to see why blame of this situation goes to it? It would seem that Google, given the plenty of implementation latitude it already has on Android, that it could have side-stepped compatibility to provide stronger cyphers.
So why is this Oracle's fault and why no mention of Google's fault exist in this one-sided article? As Colbert once said "I can't prove it, but I can say it.". That seems to be what governs the writing of this particular submission.
It goes from corporate espionage to some guy stealing credit card numbers as a 'hobby'.
I work at a major corporation that has security cards to get into the building and my computer is password protected with an encrypted hard drive & a physical lock on the computer. Are security guards with guns really necessary?
Depends on the situation. If your property is that valuable, perhaps. Now, consider this: If people are willing to physically break into your facilities, that's passing the threshold that divides a cyber-violation to a physical violation. Statistically, breaking into someone's property usually correlates with a willingness to commit physical aggression. With that in mind, guns for security guards and LEO's are not simply to "shoot" the bad guys, but for them to protect themselves.
If I owned a property that has been broken into, or that is at risk of suffering a break-in, and if I had a need to protect valuables inside, I could not in good conscience put a security guard there with no legal means to defend himself if/when SHTF.
Cool story. Would be a lot cooler if you didn't work for Blackberry. It's not like you hide your identity well Aaron Wiebe.
I don't have an e-dog in this e-fight, but c'mon, why don't you address his points (and debunk them if you have the arguments to do so) instead of launching an ad-hominem?
Why didn't they switch to C++ and do it properly!
Because it is not as economical (in terms of software development efficiency) compared to Java (that's my perspective as a a C/C++/Java developer in the *NIX and Windows, app and embedded arenas.)
1) Import as much as possible 2) stockpile it 3) resell later for massive profit
Amazing that this was even up-voted. Slashdot users suck at logistics.
at what point should it be considered to have the same rights as a human?
Including fully-sentient human clones?
Europe and Asia. Now what?
This. As a US citizen, it embarrasses me how uninformed US citizens are about wtf is happening in the rest of the world. Outside the realms of operating systems, the US is a follower in the mobile workd (hardware, ecosystems, marketing, logistics), not a leader.
Nokia used to be such a big player in the mobile market that they did not need to become "yet another Android vendor". They had the know-how, capital, fame, and few billions of loyal customers to either come up with a competing OS (MeeGo) or just fork Android and not give a flying fuck about Google trademark. They even had Nokia-built map and navigation good enough to rival Google's.
By resting on its laurels and past fame (like Motorola did), Nokia ended up the way it did (like Motorola did.) It should have given a fuck about Android (or even gone Windows Phone). But it didn't, so, all that remains for it now is to indulge in past glories while circling down the drain.
That's absurd. Learning time-sensitive ordered tasks, such as in music or dance, or alternative ways to express similar ideas, such as language skills, are invaluable to skilled programmers. The ideas of checklists, logical operations, and revising a program on the basis of alternate events, learning about backup and what you can lose without it, are all useful.
I'd be more concerned about what happens with _bad_ programming lessons, being taught to manipulate only GUI based patterns in a teacher expected way or be marked down for not doing it the way an uninformed, underpaid coding monkey wrote to mark the checksheet off their daily tasks and pays no attention to encouraging the children to learn how things work. I'm concerned tht the children will be taught only how to fill out a checklist blindly. I've worked with programmers taught that way, and they can become an active obstacle to good computing, good science, or even good politics.
I'm afraid that a lot of the pre-teen children I've been meeting in public school would be better off, though, with real recess or a daily siesta rather than yet another mandatory lesson that requires sitting in a computer classroom. They're exhausted, and getting their bodies moving is being neglected in conflicting academic policies and goals.
Finally someone who is paying attention to children's physiology. Their sleeping patterns are different from adults, and they do require additional sleep (and depending on their age, different nutritional content.)
Also, as you said, it is important to give precedence to more fundamental, cognitive/social skills. Slashdot is infected by too many keyboard warriors that think coding should become a basic, fundamental topic. It is not.
Don't rush kids into learning to code. Get them to learn the essentials first, math/algebra, natural sciences, language, history, civics and the basics of personal finance. All that, in particular personal finance, are more important that learning to code. We have a lot of shitty coders as it is, and a lot of people who suck at the basics of math, history, civics and logical thinking. What the do people think it's going to happen when we rush/force kids to learn to code?
Also, who is going to teach coding? A proficient developer, or a we going to repeat the current pattern of forcing a teacher of specialty X to teach specialty Y for which he/she is completely unqualified?
How Early Should Kids Learn To Code?
As early as they are capable of devising logical constructs (probably by the 2nd grade) IF AND ONLY IF they provide an aptitude and desire for it.
TFA says this is for "Rich Internet Applications," that is, Java applets embedded in Web pages. It doesn't seem this would affect Java programs that you execute locally, such as (for example) Eclipse.
It begs the question, who the f* still writes java applets in this time and age, specially for web RIA? So many options exist for RIA in Java or JavaScript (or both), applets are, in general a devil's spawn from a distant past (and a clumsy tool for the clueless software shop.)
"What's funny is it really doesn't take much effort to be more enjoyable than the C++ examples from earlier...just getting to write gets.chomp and puts over cout > made all the difference. Ruby examples kept me engaged just long enough that I could find Why's Poignant Guide to Ruby.
To me, this just does not make any sense. The preference of gets.chomp over cout << (or viceversa) are so subjective that they borderline on the ridiculous. I don't think I will ever relate to such minutia. Even when I was in my formative years as a future programmer, such minutia seemed as irrelevant then as it does now.
At least for me my focus and motivation were always a) what can I create with this programming language, and b) how can I tame this beast. That's the approach I took with BASIC, with Pascal, with Delphi, with C and C++, with assembly, with Ada, with Lisp and Prolog, with Java, with C# and so on and so on.
The only thing out of this story that I could relate to is that indeed C++ (like Java and C#) is a horrible introductory language, and that something like Ruby (or Python or Lisp or BASIC or a Pascal variant) is a better prog-101 language. Heck, I would go as far as to claim that Assembly (a real one or a simulated one) is better to teach programming than C++.
But to suggest that such ridiculous minutia "engages" someone to learn, to me that's suggestive of prioritizing on the wrong things. Every person is different and unique and perhaps *THIS* works for them. To me OTH, it has always been about being able to create more and more powerful things with whatever language I had to learn (or work with.) Syntactical minutia is just not such a significant impediment unless you focus on them and give them greater power (positive or negative) than they actually have.
As for the value of goofing, of course that is important, but that is not a function of the language. It is a function of the professor, and the student. I know professors that will suck at it even if they use Ruby, and I've had wonderful professors that took me on great journeys with whatever language, low-level or high-level, that they were teaching at the time.
Ultimately, fun is subjective and it is just a function of what you make of the things you have at your disposal. Your learning potential will likely suffer if you take minutia as the focus of your likes or dislikes.
Yeah. Funny enough, people in my country always say that long-term investments in R&D and etc are the last places you want to cut in a crises because they garantee our future.
That's stupid. If you're in a crisis, you make sure everybody has food on the table, you get people into jobs, the economic going .. then you re-invest in the long-term stuff. This is obvious in a household. But for whatever reason it doesn't follow for some.
Maybe because a household =/= a whole goddamned state?
What company still has that policy?
I cannot imagine one such company to be honest (a relevant company that is.) Until recently I worked in the defense sector, which is very bureaucratic and regulated. And even there, Blackberry isn't even in the most remote of pictures with the future (a distant BYOD future that is), it is all iOS or Android.
Having no need for Windows, I really don't keep up with its capabilities. But, really, this is the year 2013 --- Windows is still that pathetic, that basic tasks like syncing files between multiple computers take special software that doesn't just come with the OS? Why is anyone still using that crap? Are corporations really so utterly incompetent on IT issues that they'd put up with shit like this because they don't know any better?
Dude, even on Linux, you need special software to synch files (rsync, git, whatever.) Since file synching is an app-specific functionality, this is not a OS problem. This is an operator problem, and I've seen Linux/Unix sysadmins doing the same kind of crap job as the one described in the original question/article/whatever.
This is a solved problem on both Windows or Linux/Unix. But incompetent IT staff exists on both domains. You can't defensively program against stupid (nor should you.)
Any of those but ClearCase. What an awful tool.
It's not great (not my first choice), but it is not that awful either. I like the concept of a vob and the powerful access control models that come with it. It's just the idiotic complexity of attributes and objects in ClearCase that uglifies it.
This works great with only one caveat: most office documents are binary files (or are treated like binary files by the SCM), so you'll need to put a process in place to lock the file in question prior to editing to prevent people stomping over others' changes to them.
That's typically not needed. MS Office products, for instance, have built-in diff review-n-merge capabilities. And even without such a capability, a src-controlled binary is simply that, a coarse-grained resource. Whoever commits the last is the one whose changes prevail. This is what is done with SharePoint anyways or TeamSite anyways. No need for locking.
You'll have to excuse him, he comes from Windows Land :)
Meh, I know you are posting in jest, but honestly, I've seen people from Unix-land also having no clue about source control/revision control systems. Proficient software people (Unix, Windows or whatever) know how and when to use such a system. Everybody else, well, you get what the submitter is describing :/
Unless you want your students to only use scripting languages and whitespace formatting forever, you're setting them up for failure.
This only true if the student does not cover anything but scripting languages. That is not an argument that I made, but don't let that stop you from building a straw man.
What are they to do when they get into the real world and run into "semantic baggage" languages in the enterprise space?
Well, what is a student to do in the real world when they encounter the "semantic baggage" of the enterprise with only one or two introductory programming courses using either C++ or Java? Would you expect a student to be able to be capable to deal with the real world with a course or two, regardless of the programming language used?
Obviously not. So your question is moot and not really meaningful. A person is supposed to get grilled through a curriculum of programming courses, ideally exposing them to a variety of programming languages and paradigms.
Become website designers because programming is too hard?
No. Selecting an appropriate kaleidoscope of programming languages and paradigms that allow a constructive introduction of hard subjects, starting from the basics of problem solving and control structures, models of computation with minimum baggage possible. Can be Python, BASIC, Lisp, Pascal or C. Hell, it can be even Assembly (that's how it was done before with good results anyways.)
I don't care what language you chose for teaching, one or two elementary courses will never equip anyone to the real world. Furthermore, Java, C++, Scala, C#, Erlang or Haskel are not appropriate for that level of teaching. They are great languages at the intermediate or advance level, after the prospective student has been grilled on the basics in a repetitive fashion in one or more of the languages I mentioned before (C, Python/Ruby kept proceduraly, or BASIC.)
Then, once a person has gone through a barrage of programming problems, and with a solid grasp of procedural programming, then they can move to object oriented and functional programming. Why? Because by now they can focus on those topics alone as opposed to having to deal them (quite ineffectively) while still wondering whether to use a for loop or a while loop (I see that a lot with schools that insist in teaching with Java or C++ from the start.)
If they can't grasp OOP up front then they shouldn't be programmers.
And yet, you see (or I least I see) the industry full of professional programmers who are shitty OOP programmers because they can't grasp the fundamental programming principles behind procedural and modular programming. They can't tell me for shit the difference between a class and a struct or plain record, or what makes them different from a ADT. Because they can't still get proper layering of their system because they never really understood what modular programming does for you. Because they never quite got enough homework or work that drill down the concept of divide-and-conquer.
People think "oh yes, I know OOP" and yet they can't tell me how they measure coupling or cohesion in a systematic manner. They can't tell me why delegation and composition is better than plain inheritance. But they can write classes in C++ and Java with their eyes closed like idiot savants.
They can't tell me how or why to layer their classes vertically and horizontally which is something a person can easily deduce if he knows modular programming in a cold-turkey manner.
They think they do not need to know about Cyclomatic complexity because he doesn't use functions but methods. Yes, I've seen people saying that (producers of hyper spaghetti code). They have no clue what basic things LCOM or "tell, don't ask" principles are for, but they sure know how to create class hierarchies in diagrams resembling the death start.
If you are a good OOP
Maybe the problem is you are too stupid to understand complex things?
" Too many semantic subtleties that have nothing to do with elemental programming tasks. Apparently I am right.
Since insulting seems the way to prove you are right (or let me say "your right" so that you get a chance to bash teh gramm3r), maybe I should just let you assume the answer to your question since you seem to be the pedagogical expert here.
See, your typical answer indicates with almost certainty that you are a) either an inexperienced fanboi or perhaps b) an idiot savant that might have many years of experience, and still be an idiot savant. Perhaps you might be c) a software Sheldon Cooper, but probability alone would dictate that you are either a) or b).
This has nothing to do with me being able to grasp complex software/CS concepts. Perhaps your infantile reading comprehension betrayed you and did not catch the part where I said I've been a software professional for many,many years using Java and C++ for both application and system/embedded development. I'm pretty sure I can draw circles on those languages around many of the self-proclaimed geeks in this site.
It has nothing to do with me. But it has everything to do with teaching an elementary programming course. The consensus among most Java and C++ professionals has always been that either language is piss poor as a programming language FOR AN ELEMENTARY PROGRAMMING COURSE. The few who disagree either have a vested interest while selling Java or C++ books or are academics who have done little to no programming for a living.
Or maybe I'm stupid as you said. I'll weight the substance of each other arguments and see who is the most logically backed-up one. As for you, I will leave you with your high schoolish name calling.
Ruby and Python are scripting languages. Students are better off being exposed to Java or C++ from the start so they can see if they have the knack for programming or not. Sink or swim, as it were. Putting students on scripting languages just creates the perception that they are doing true software development when they are not. If you're going to use Python or Ruby you might as well put them on VBScript or JavaScript. Or go whole hog and put them on CoffeeScript so they don't have to deal with the agony of curly braces and proper formatting.
That's bull. Scripting or otherwise doesn't make a difference for the tasks of learning the basics. Again, based on my 12 years of programming experience with Java, Java is not a good pedagogical choice. And C++ (where I also have work experience)? Please, that's another bad choice. Too many semantic subtleties that have nothing to do with elemental programming tasks. Plain old C is a much better pedagogical option. Like C++, no memory management and plenty of segfaults and pointer management. Unlike C++, no semantic complexities related to OOP, STL, IO streams, clunky/incomplete exception handling mechanisms and the like.
At that level, I'm interested in a student to immediately know how to focus on the details of an algorithmic solution, and the essence of data structures and basic control flows. I'm interested in him/her understanding procedural programming principles.
All the additional semantic baggage that comes with Java and C++ (a function of what *WE* thought was essential language/compiler design principles at the time) just get in the way.
Moreover, this semantic baggage requires the learner to have a certain programming dexterity on the fundamentals that are better obtained when we focus on those alone. Yes, I believe in sink-or-swim as well. But do it with purpose by exposing the essential complexity of programming, not because we suck monkey gonads at choosing our pedagogical tools.
Right, that's 4 concepts which have to be explicitly explained (or passed over) before we even get to how to put a single character on the screen, or add two numbers....
Exactly this. It's accidental complexity that has nothing to do with the fundamental tasks of programming that are supposed to the focus of study.
A BASIC/Python "print" or a Pascal "write/writeln" is supposed to be obsolete and clunky, but System.out.println enclosed within a mandatory class that is just not a class, but a public one, with not just a main function, but a static one, and with its name exactly case-matching the filename that declares it while making sure that no other "public" class exists in said filename, that is supposed to be pedagogical progress </rolls eyes>
I really find it a tedious stumbling block explaining to my kids all the ``public static void main'' stuff --- really wish that Oberon had made it instead. Niklaus Wirth at least has his manuals heading in the right direction (Pascal, hundreds of pages; Modula, a hundred or so, Oberon, dozens).
As a professional who has done Java for application (enterprise/web/web service) and system/network protocol development for 12 years, I would say no. Java is not a good choice for a beginning or even intermediate level programming curriculum. As a very productive platform for developing robust systems, Java delivers.
For pedagogical purposes, specially as a starting programming language, it is atrocious. I would have preferred Python or Ruby focusing first on procedural programming, leaving object and functional features for later (rarely does a student leverages OOP and FP cleanly without having a good grasp of procedural programming, data structures and algorithms.) Or *gasp* BASIC or a Pascal variant or even C (students need to know right of the bat what a segfault is.)
I would typically choose Java for development of robust systems. I would never use it as a language in an into-to-programming course.