How can you possibly say that "Java's a little complicated to program in?" If you're using C++ (I assume you are not referring to the C precompiler by "cpp"), I cannot understand how Java is anything but SIMPLER than C++. Java has a single, consistent object model. You don't have to worry about objects on the stack versus objects on the heap. Java doesn't have all of the funkiness caused by mixing class types with typedef'ed other stuff; there is just the simple reference type for all objects, including arrays.
After programming in C++ and Java each for several years, I can only say that C++ is the more complicated of the two. I do not like using Swing (Java's standard GUI components), but I haven't tried them for just over two years now, and it may now be much improved. For the server-side work I do now, Java beats C++ hands down for ease of use.
All of the following and more make Java simpler, though they cost a little bit in flexiblity and speed. However, server-side Java (forget about Swing and how slow it is) performs quite well for me. Today's PCs seem to do a good job running Java. I've been pleasantly surprised by just how much better JIT was over non-JIT and again by how much better Sun's Hotspot JVM and IBM's JVM are than earlier JIT JVMs. Special hardware might be useful for embeded devices, but mainstream CPUs work quite well for server applications.
single reference type
no operator overloading
garbage collection
no parameterized types
I've often wished for some of the items above, but in the spirit if KISS (keep is simple, stupid), Java wins for me.
I do not think they care. Java support in MSIE only affects applets and has no effect on applications, for which most sane people would use Sun's or IBM's Java 2 JVMs.
I guess the answer for which you're looking here is a really big "yes?" Duh, lots of companies use Java, just not the outdated and unsupported Microsoft Java tools.
end of line
I highly recommend Program Devleopment in Java: Abstraction, Specification, and Object-Oriented Design. It used to be written with examples in a language called "CLU," which was a generic teaching language. All of the time-worn concepts still apply even though it's now written with examples in Java. This book is awesome. I am so glad that a friend recommended it to me!
It's also the software engineering book used for undergraduate studies at MIT. If you can get your hands on one of the old copies of the CLU-based book, that's even better.
end of line
Re: ALL YOUR BLAZEMONGER ARE BELONG TO US!
on
An Amiga Round-up
·
· Score: 1
Re:Awaiting the Arrival of AmigaOS x86
on
An Amiga Round-up
·
· Score: 1
"Clean and efficient code?" Well, sometimes, yes. Are you not familiar with the Guru? Run some programs with Enforcer to see how clean they are.:-)
Don't think that I won't buy a copy of this if/when it is released, but aside from being efficient, because they had to be, I don't think that all the programs I loved were necessarily clean.
For those not familiar with Amiga programming, Enforcer is a program that provides some memory protection of system areas on the Amiga. Using this with Mungwall (to write "MUNGEWALL!" or something like that to all unallocated memory) was about as close to having memory protection and Purify as I can recall on the 680x0 Amiga.
With comments like "cheap programmers are the only shortage," I begin to wonder why some people would think this, whether true of not. When I graduated from college with a computer engineering degree in 1995, the going rate for a new-hire programmer was about $33,000 to $40,000 per year, and this was for programmers I considered highly skilled if lacking experience. As time went by, and the Internet boom hit, I saw my salary increase greatly, and considered myself lucky to be working in this field. I loved doing my work, and companies would pay a lot to have me work for them.
During this time, I heard stories from a friend and coworker (a very talented programmer and designer) of how is brother, while still in school in the San Francisco Bay Area was making as much as we were for a part-time job. My friend told me that his brother was quite talented, and of course, there is a big difference in the cost of living between Stanford and Austin, but it was always amazing for me to hear of the salaries that companies, mostly dot-coms, were paying for even inexperienced programmers.
Naturally, because my wife was a recruiter during this time when companies could not find enough talent on their own, I found a new job (that I really love!) I heard plenty of stories from her about programmers would believed that the world was theirs for the asking. "How much are you currently making?" she would ask a candidate. "$50,000, but I want a job for at least $80,000," would be a typical response from someone with less than two years of experience. Another situation would involve a team lead at a large company in (in pink buildings) who was looking for a new job in part because his company would not increase his pay above that of a college new-hire who worked for him.
Now, one of the things that a former employer planned to do was recruit programmers from India, which is quite conceivable since the president of the company is a long-time resident and naturalized U.S. citizen from India. Why would this be something that makes money? I believe because the expectations of domestic job-seekers rose so sharply, many companies were willing to deal with the paperwork, legal work, etc. of hiring H1B programmers.
Maybe the complaint above should be modified to "ego-maniacal, overpriced programmers are the only real shortage."
As a side note, can someone recently from India comment on my neighbor's statement that two of the most popular activities of youth in India are computer programming and chess playing?
This was already posted to Slashdot. Anyway, in Austin, there was a real shortage: companies could not hire as many software developers as they wanted. However, the situation is now reversed. The artificial demand from the surge of incoming venture capital has now passed, leaving neighbors and acquaintances without jobs.
I'm happy that my company survived so I don't have to go looking for a job in the now saturated market.
I should analyze a sample of the sound to be certain, but most of the fan noise I hear sounds like white noise to me, which is not monotone at all, so I think we're safe as long as it's not loud.
Samael has a point. It is different from the point I was making about the airbag deployment. I stated that sending information about the deployment could just as well send GPS coordinates.
Sameal's point is that it is much easier to track a vehicle if it sends GPS coordinates as part of normal activity. I have to agree. There are some cases where this is desirable, too, such as when a thief takes one's car, or if a person goes missing. I could also have such a system on my person or in my wallet if I desired. I'm perfectly happy to use traditional vehicle security and theft insurance, and I'm willing to rely on traditional means of search and rescue in order to avoid the technological eye watching where I go and slicing off another bit of my privacy.
I still, however, believe that Mr. McNealy's assertion concerning his airbag is false.
It's important to let the right people have the right information, but it's more important to know when that information is needed. The GPS tracking system doesn't need to send information all the time to be able to notify the watchers where one's airbag deployed.
"I have agreed to let my car company, for instance, track my every move through GPS satellites. Some people might consider that an invasion of privacy, but I find it comforting to know that, should my air bag deploy, they know where I am and can send help."
I agree. I also believe it makes obvious the fact that "directed" research, opposed to "pure" research, is not all some would want it to be. Some may have viewed the genome mapping project as "directed" research towards the goal of finding simple mappings from genes to proteins; however, we have not gained so much the goal of this "directed" research, but we have discovered a lot more about how our genome really does work. It's a complicated mess, but we wouldn't have know this if we had not tried to decode it. Setting expectations on any project is quite important so that those who like to poo-poo scientific research are not armed with arguments of the ineffectiveness of even "directed" research.
If the IETF has been working on this for a while, then they should be able to contest it via prior art. From what I have read, this is not the case, which means that unless someone in IETF working group looked at the Walid patent, this implementation should not be considered in way "novel" as it was developed independently so quickly.
Proving that an IETF collaborator didn't copy the patented idea may be difficult to do, but I doubt anyone would have persued the idea knowing it was patented.
Anyway, it seems like a very logical step to decide to use an internationalization standard to solve the problem, and not very "novel" anyway.
I'm not sure which part of your post if funnier. The part about VSS being more reliable and easier to use than CVS or the part about the Gnomes. IMO VSS might work well for one person to keep track of changes, but it's just so slow and so annoying that I'm glad my company decided to leave it behind. I really did not like the fact that it would tell me that a file was checked out on "G:\" wherever that may be on our network. Maybe it's just configured wrong out of the box, but it was a nightmare to use. I don't think it understood the difference between a client and server since it used path names as if they were all on the same machine.
I've used CVS for work in the past and currently use it for non-career development, and it works much better that way. Plus it works much better than VSS did a) with geographically distributed clients and b) on multiple platforms.
Why would one not say that we are evolved from rock? Many would say that the first life did evolve from non-living matter (e.g. rock) and, thus, we are descended from that. I believe one of Carl Sagan's favorite lines was, "We are the stuff of stars."
Re: "the reason companies and governments are being forced into these drastic actions"
Don't forget that corporations also have a responsibility not to devise draconian methods of content protection. It is such behavior that "forces" us to copy every possible piece of media. It is the same type of behavior that spurs boycotts.
Your post makes the possibly erroneous assumption that companies and governments would not take this action except that they are "losing" money. Instead, consider that they are doing it out of greed, self interest, and increasing shareholder value. In other words, they have a responsibility to someone not to lose control of they content they control, but they do need a lesson in not alienating a large portion of their constituency.
Similarly because we have the right to challenge this type of control that we also have the responsibility to fight it.
OO isn't something you plug into your software development system the way you put a faster processor into your computer. Instead it's a different way of approaching your problem space. From this perspective, it becomes much more like religion so why do we bother discussing it? Because we have to. If I design a system in an OO way, then those using my APIs had better learn to like them. However, arguing that ridiculous points like those in the article above isn't going to get you anywhere towards this goal in a software development organization. Liskov's book provides ample support for how object abstraction can help software. The subjects discussed in that book above show why OO is good, but do not forget that many ideas can be applied in non "00" languages. Liskov talks a lot about abstraction, which can be used in any programming language.
Sheesh.
Go ahead and moderate this message down. It's just a troll---the same as this entire thread.
Jeremy corrected me above in that the card number usually is not needed. However, one case for which it is needed is when there is a partial shipment of an order, and the remainder must be reauthorized. Some (at least those with which I am familiar) only allow one charge per authorization, so the card number is needed to charge for the second part of the order.
They need to keep your card number around for at least a while. If you are dealing with an online merchant, the merchant is not allowed to charge your card until items are shipped. However, the merchant will authorize your card immediately, or at least pretty quickly. In addition, the merchant may need to credit you account in the future for whatever reason. At any rate, the merchant needs to hold onto your card number for some time. Here's what typically happens:
You check out for a new game on Tuesday.
The merchant authorizes your card to make sure that it can charge the $43.64 that the game costs. Note that there is no charge yet, but the merchant has reserved $43.64 for it to take later when it ships the game to you.
On Wednesday, the company ships the game to you.
On Thursday, the warehouse updates the accounting system so that it knows the game has shipped.
Thursday evening, the company charges the $43.64 that it reserved early during the card authorization.
Monday comes, and you receive Virtual Barbie instead of Tom Braider. What's the difference? You tell me, but you wanted Tom Braider, so you call the company.
Their customer service representatives apologize and promise to credit your account for the $43.64.
Ten minutes later, the credit to your account is performed, and you don't have to give your card number again. Plus, the customer service rep never has to know your card number because it is already in the merchant's database, and access to the actual number is, hopefully, tightly controlled.
The point is that the company needs your card to be able to process monies later. There is a point at which the liability of keeping card numbers exceeds the usefulness gained, and apparently many companies have chosen that time poorly. I imagine that those who do purge records from their main systems keep the card numbers for at least as long as they would typically provide a money-back return to the customer.
Also note that online merchants are not the only ones who keep these records. All companies follow a similar process, but online companies always have their systems connected to the Internet in some way, which makes them more obvious targets.
How could this possibly have been moderated up? The first idea of possibly taking over Rambus is interesting, but to follow that up by suggesting the assassination of the company executives is reprehensible.
Yes, I did see the smiley.
No, I didn't think it was funny.
As for the worthy idea, the market capitalization of Rambus is $6,220.69 million with $64 3/8 per share. That's about 96 million shares on the market. To takeover Rambus, would have to pay over $3 billion dollars, and then somehow incorporate Rambus into another business so as not to get sued by the rest of the shareholders and get investigated by the SEC.
One of my friends created this drug use/abuse permission form. It should be quite handy for those California Meth-heads mentioned in the story.
"I see programmers who start their day by stirring meth into their cup of
coffee," said the Rev. Katherine O'Connell, a clinical psychologist and
interfaith minister in Capitola, Calif., who has treated thousands of high-tech
workers, politicians and executives for drug addiction since 1970.
I found these two paragraphs from the article particularly interesting. Because the three companies below have the nerve to try to dismiss Rambus' claims of IP rights to SDRAM, Rambus might withhold licensing of the disputed patents? Sounds as if they are damned if they do and damned if the don't.
I'm guessing it was said in order to scare other companies from joining the suit against Rambus since they cannot hope to win all these suits against SDRAM makers if their combined legal strength is wielded. "Let those other companies take the risk of not getting licensed. We do, afterall have responsibilities to our stockholders."
Hopefully, the RAM makers will see what Rambus has done and never, ever trust them again!
As a result, the company has sued DRAM makers Hyundai, Infineon, and Micron for patent infringement, and in turn has been countersued by Hyundai and Micron.
A Rambus spokeswoman last week added greater weight to the outcome of the suits, saying that the company may refuse to license any of the three memory makers if it prevails in its court case.
Slashdot Mirror
After programming in C++ and Java each for several years, I can only say that C++ is the more complicated of the two. I do not like using Swing (Java's standard GUI components), but I haven't tried them for just over two years now, and it may now be much improved. For the server-side work I do now, Java beats C++ hands down for ease of use.
All of the following and more make Java simpler, though they cost a little bit in flexiblity and speed. However, server-side Java (forget about Swing and how slow it is) performs quite well for me. Today's PCs seem to do a good job running Java. I've been pleasantly surprised by just how much better JIT was over non-JIT and again by how much better Sun's Hotspot JVM and IBM's JVM are than earlier JIT JVMs. Special hardware might be useful for embeded devices, but mainstream CPUs work quite well for server applications.
- single reference type
- no operator overloading
- garbage collection
- no parameterized types
I've often wished for some of the items above, but in the spirit if KISS (keep is simple, stupid), Java wins for me.end of line
end of line
I guess the answer for which you're looking here is a really big "yes?" Duh, lots of companies use Java, just not the outdated and unsupported Microsoft Java tools. end of line
It's also the software engineering book used for undergraduate studies at MIT. If you can get your hands on one of the old copies of the CLU-based book, that's even better.
end of line
ALL YOUR BLAZEMONGER ARE BELONG TO US!
Don't think that I won't buy a copy of this if/when it is released, but aside from being efficient, because they had to be, I don't think that all the programs I loved were necessarily clean.
For those not familiar with Amiga programming, Enforcer is a program that provides some memory protection of system areas on the Amiga. Using this with Mungwall (to write "MUNGEWALL!" or something like that to all unallocated memory) was about as close to having memory protection and Purify as I can recall on the 680x0 Amiga.
end of line
During this time, I heard stories from a friend and coworker (a very talented programmer and designer) of how is brother, while still in school in the San Francisco Bay Area was making as much as we were for a part-time job. My friend told me that his brother was quite talented, and of course, there is a big difference in the cost of living between Stanford and Austin, but it was always amazing for me to hear of the salaries that companies, mostly dot-coms, were paying for even inexperienced programmers.
Naturally, because my wife was a recruiter during this time when companies could not find enough talent on their own, I found a new job (that I really love!) I heard plenty of stories from her about programmers would believed that the world was theirs for the asking. "How much are you currently making?" she would ask a candidate. "$50,000, but I want a job for at least $80,000," would be a typical response from someone with less than two years of experience. Another situation would involve a team lead at a large company in (in pink buildings) who was looking for a new job in part because his company would not increase his pay above that of a college new-hire who worked for him.
Now, one of the things that a former employer planned to do was recruit programmers from India, which is quite conceivable since the president of the company is a long-time resident and naturalized U.S. citizen from India. Why would this be something that makes money? I believe because the expectations of domestic job-seekers rose so sharply, many companies were willing to deal with the paperwork, legal work, etc. of hiring H1B programmers.
Maybe the complaint above should be modified to "ego-maniacal, overpriced programmers are the only real shortage."
As a side note, can someone recently from India comment on my neighbor's statement that two of the most popular activities of youth in India are computer programming and chess playing?
end of line
I'm happy that my company survived so I don't have to go looking for a job in the now saturated market.
end of line
I should analyze a sample of the sound to be certain, but most of the fan noise I hear sounds like white noise to me, which is not monotone at all, so I think we're safe as long as it's not loud.
Sameal's point is that it is much easier to track a vehicle if it sends GPS coordinates as part of normal activity. I have to agree. There are some cases where this is desirable, too, such as when a thief takes one's car, or if a person goes missing. I could also have such a system on my person or in my wallet if I desired. I'm perfectly happy to use traditional vehicle security and theft insurance, and I'm willing to rely on traditional means of search and rescue in order to avoid the technological eye watching where I go and slicing off another bit of my privacy.
I still, however, believe that Mr. McNealy's assertion concerning his airbag is false.
I agree. I also believe it makes obvious the fact that "directed" research, opposed to "pure" research, is not all some would want it to be. Some may have viewed the genome mapping project as "directed" research towards the goal of finding simple mappings from genes to proteins; however, we have not gained so much the goal of this "directed" research, but we have discovered a lot more about how our genome really does work. It's a complicated mess, but we wouldn't have know this if we had not tried to decode it. Setting expectations on any project is quite important so that those who like to poo-poo scientific research are not armed with arguments of the ineffectiveness of even "directed" research.
Proving that an IETF collaborator didn't copy the patented idea may be difficult to do, but I doubt anyone would have persued the idea knowing it was patented.
Anyway, it seems like a very logical step to decide to use an internationalization standard to solve the problem, and not very "novel" anyway.
I'm not sure which part of your post if funnier. The part about VSS being more reliable and easier to use than CVS or the part about the Gnomes. IMO VSS might work well for one person to keep track of changes, but it's just so slow and so annoying that I'm glad my company decided to leave it behind. I really did not like the fact that it would tell me that a file was checked out on "G:\" wherever that may be on our network. Maybe it's just configured wrong out of the box, but it was a nightmare to use. I don't think it understood the difference between a client and server since it used path names as if they were all on the same machine.
I've used CVS for work in the past and currently use it for non-career development, and it works much better that way. Plus it works much better than VSS did a) with geographically distributed clients and b) on multiple platforms.
It is a
C u l t.
Why would one not say that we are evolved from rock? Many would say that the first life did evolve from non-living matter (e.g. rock) and, thus, we are descended from that. I believe one of Carl Sagan's favorite lines was, "We are the stuff of stars."
Re: "the reason companies and governments are being forced into these drastic actions"
Don't forget that corporations also have a responsibility not to devise draconian methods of content protection. It is such behavior that "forces" us to copy every possible piece of media. It is the same type of behavior that spurs boycotts.
Your post makes the possibly erroneous assumption that companies and governments would not take this action except that they are "losing" money. Instead, consider that they are doing it out of greed, self interest, and increasing shareholder value. In other words, they have a responsibility to someone not to lose control of they content they control, but they do need a lesson in not alienating a large portion of their constituency.
Similarly because we have the right to challenge this type of control that we also have the responsibility to fight it.
OO isn't something you plug into your software development system the way you put a faster processor into your computer. Instead it's a different way of approaching your problem space. From this perspective, it becomes much more like religion so why do we bother discussing it? Because we have to. If I design a system in an OO way, then those using my APIs had better learn to like them. However, arguing that ridiculous points like those in the article above isn't going to get you anywhere towards this goal in a software development organization. Liskov's book provides ample support for how object abstraction can help software. The subjects discussed in that book above show why OO is good, but do not forget that many ideas can be applied in non "00" languages. Liskov talks a lot about abstraction, which can be used in any programming language.
Sheesh.
Go ahead and moderate this message down. It's just a troll---the same as this entire thread.
Jeremy corrected me above in that the card number usually is not needed. However, one case for which it is needed is when there is a partial shipment of an order, and the remainder must be reauthorized. Some (at least those with which I am familiar) only allow one charge per authorization, so the card number is needed to charge for the second part of the order.
- You check out for a new game on Tuesday.
- The merchant authorizes your card to make sure that it can charge the $43.64 that the game costs. Note that there is no charge yet, but the merchant has reserved $43.64 for it to take later when it ships the game to you.
- On Wednesday, the company ships the game to you.
- On Thursday, the warehouse updates the accounting system so that it knows the game has shipped.
- Thursday evening, the company charges the $43.64 that it reserved early during the card authorization.
- Monday comes, and you receive Virtual Barbie instead of Tom Braider. What's the difference? You tell me, but you wanted Tom Braider, so you call the company.
- Their customer service representatives apologize and promise to credit your account for the $43.64.
- Ten minutes later, the credit to your account is performed, and you don't have to give your card number again. Plus, the customer service rep never has to know your card number because it is already in the merchant's database, and access to the actual number is, hopefully, tightly controlled.
The point is that the company needs your card to be able to process monies later. There is a point at which the liability of keeping card numbers exceeds the usefulness gained, and apparently many companies have chosen that time poorly. I imagine that those who do purge records from their main systems keep the card numbers for at least as long as they would typically provide a money-back return to the customer. Also note that online merchants are not the only ones who keep these records. All companies follow a similar process, but online companies always have their systems connected to the Internet in some way, which makes them more obvious targets.Yes, I did see the smiley.
No, I didn't think it was funny.
As for the worthy idea, the market capitalization of Rambus is $6,220.69 million with $64 3/8 per share. That's about 96 million shares on the market. To takeover Rambus, would have to pay over $3 billion dollars, and then somehow incorporate Rambus into another business so as not to get sued by the rest of the shareholders and get investigated by the SEC.
Unfortunately, there's a lot of prior art for this.
I'm guessing it was said in order to scare other companies from joining the suit against Rambus since they cannot hope to win all these suits against SDRAM makers if their combined legal strength is wielded. "Let those other companies take the risk of not getting licensed. We do, afterall have responsibilities to our stockholders."
Hopefully, the RAM makers will see what Rambus has done and never, ever trust them again!
Duh?