Object relational bridge packages commonly require code generation or xml files in order to be used. I have been working on one that doesn't use code generation or xml files.
My question is, wouldn't developers rather use purely object-based packages, if they could, rather than code generators? I believe purely object-based packages could work for most Object/relational tasks and simple compilers. The code becomes more portable and maintainable and doesn't require the extra training for use of the code generator.
What is the concensus on this? Especially in corporate development environments?
It doesn't seem to me that fraud, or people taking credit for another's work, is a problem on the internet, nor was it the concern of the paper. Not only is it NOT a problem, but I think it tells us a lot about the average integrity of the internet user, since content fraud fails to be much of a problem.
Introducing DRM to open content will only weaken its 'openness' and the DRM will be a threat to the integrity of the average internet user. I would suspect that weakening DRM and strengthening education on these issues would be more effective. Similarly, in the cases of illegal mp3 distribution, many people simply don't realize that it's unethical. Persecuting those who distribute copyrighted mp3s turns the practice into a game and causes people who wouldn't otherwise distribute or collect copyrighted mp3s to do so out of contempt for the RIAA and DRM.
The difference between an outlaw and an unethical person is that one of them is breaking a law and maybe getting away with it. Its a lot cooler to be an outlaw than simply an unethical person.
Re:A lot of people seem to be adamant against Java
on
Head First Java
·
· Score: 1
I cannot imagine how I could define interfaces completely before beginning development.
This is what thousands of people are using UML for! Then there are tools to translate the UML directly to Java. Of course, this doesn't exactly put an end to the constant refinement (but perhaps slows it down). It does let you beat your head against the wall over a much simpler code structure, rather than piles of implemented code. And without grouping your code and data into objects, I think the planning stages would become exponentially more complex.
You might be right about your 2nd point. Objects don't normally map well to relational db tables and the object-relational mapping solutions are awkward and difficult to use. In fact, since I started using OOP, I've almost stopped using more complex SQL completely.
Java proponents might say that to rely to greatly on SQL may compromise platform independence, but I don't know about that. Perhaps its just that people are scared to learn SQL.
Re:A lot of people seem to be adamant against Java
on
Head First Java
·
· Score: 1
A think that's a valid criticism as far as something that can go wrong in OOP, but yours is more an example of bad design. The method would best be either placed inside the person class (since it depends only on values from person) or the thin-wire approach would be used.
I think many OOP developers, maybe even experienced ones, would be tempted to use the fat-wire approach in this example, or they might do it by accident at first, only to change it when they want to use taxPerson in other programs.
This is just a way of thinking that OOP programmers must learn, but I wouldn't consider it to be a detriment to the language, as it forces developers to do more planning. In fact, most Java programs have their complete set of interfaces designed before development even begins.
A lot of people seem to be adamant against Java
on
Head First Java
·
· Score: 1
I've noticed on Slashdot particularly that many programmers, even the./ editors, seem a little, if not a lot, biased against Java. As someone who has been productive and happy with the language this doesn't make sense to me unless it has something to do with the corporate stigma surrounding the language. And I know its not great for desktop apps either... but come on-- cross-platform, vendor-neutral, tons of open-source support, development tools through the nose, all the apis you could ask for.
Alright, so I'm not trying to, uh, bait flame, but provided that Java works best for client-server applications, or just server-side apps, what are the major problems with Java as a platform? Or is it that Sun is not being open enough with the specifications?
This is a serious problem that I've put a lot of thought into myself, being an open-source developer. It seems like a couple of factors come into play.
Word of mouth advertising is the only real way for an independent project to get off the ground. If you have a good product, then people will use it. You can add lots of momentum by getting hosted by an organization like Apache or Tigris.org.
What it comes down to is having a stable product with a good user-interface, if applicable, good support, good distribution (not just makefiles, but rpms or installer software), good logging, etc.
The perfect book to describe all of this is Luke Hohmann's latest book Beyond Software Architecture, which I would highly recommend. It goes into great detail to explain how to develop software that people will want to use, open source or not.
Anyway, the quality of the product is first and foremost in open-source because advertising money is just not there. Most IT management are not tech-savvy and pay more attention to colorful ads than what the gurus are saying-- which makes it even harder to get the product used. The products that do get used in businesses are typically only the 'standards' like Apache or Sendmail, which have gained industry-wide acceptance.
I don't think the open-source community would let Java become polluted by anything, esp. Microsoft.
The reason for making it open source is allow people outside of Sun to play with the code. There may be better ways to improve garbage collection and just-in-time compilation that Sun employees haven't thought of or haven't had time to do.
The GUI could use some work too. Sun probably doesn't know as much about Linux as OSS developers do. If OSS developers could use their knowledge of Linux to optimize the native GUI code, then there could be another advantage to OS Java.
Sun's interpreter could then just be the reference implementation for Java. They would have a better implementation in the OS Java and not have to take the blame for any shortcomings.
Ok, I'm thinking of Java man, from the island of Java. I must have learned this from grade school and I thought that was a silly name to call a primitive man, because it was coffee, right? So it must have stuck in my head that way, that primates came from Java, and I assumed they must have migrated to Africa and elsewhere. So apparently these primitive men can build ships and navigate waters too...
I think teaching a young person LISP or Scheme would be like taking a kid who wants to learn karate and making him paint a fence instead.
The kids would say "So is this what Quake is written in?" "No, its written in C." "Can I learn C instead?" "No, Lisp will teach you the fundamentals, so you can become a better C programmer."
Then they get bored.
But then again, they're not going to sit down with a C compiler and write Quake anyway.
Maybe you're right. Its hard for me to imagine a young person learning OOP right off the bat. I didn't learn until I was about 14 or 15 and it was quite a jump from the procedural BASIC languages I was accustomed to.
For me, the mental leap from procedural to object-oriented programming was the idea that data and code are (or should always be) related. Even when I learned C++, I viewed classes as 'just another data type', or 'like structs, but with functions'.
It wasn't even until I learned Java that I realized data and code could ALWAYS be related in one way or another. With that realization, I began to do things in programming that I could never do before: reuse code on a large scale; break down the problem into its constituent problems, which is a skill that reaches beyond programming to other areas of problem-solving; and with these skills I could tackle more complex tasks without that feeling of being overwhelmed.
Often used to teach programming in educational facilities nowadays
Has all of the graphical stuff that kids would like
Cons:
Too hard... OOP is too big a learning curve when you just want to write a program that asks for your name and says "Hello, ".
API is too rooted in com sci theory, another learning curve...
I say go with python. I think kids are by nature impatient when it comes to learning something new and they want fast results. Python comes with an interpreter, so you can get immediate feedback if you type in something wrong. Plus, its free and its as complicated as you want it to be. Kids won't have to learn OOP until they come across a problem that would really benefit from it and by then they've already learned the basics of the language well.
Another thing is graphics, and I don't know if Python has an interface to the Windows graphics APIs. I think most young kids would enjoy creating graphics and games, so this would be a must-have feature for a young person's language. But screw LOGO. That was the first language I learned (in 3rd grade) and I was never so bored watching that 'turtle' move around and wondering how I could make Pac-man by rotating the turtle and making him move x pixels (not that its any easier in another language, but at least Apple II BASIC let me use my imagination more)
It doesn't seem like anyone (who isn't affiliated with a proprietary software company) is necessarily against open source as they are against the idea of the change itself. Changes in government are mostly reactionary. You need a large number of voters interested in the issue, otherwise its hardly worth the time. I believe the opponents to the open-source bills were mostly afraid to favor open-source; they weren't against it.
I should think that after putting themselves in a potentially bad marketing position in the first place, the last thing they should do is go with a slogan like "Costs more, less useful." It is respectable however that they should be so honest about their product.
But all seriousness aside, I vaguely remember an article posted on slashdot about a company named Enron that boasted of product features which a product didn't have. This could be construed as a tactic to drive up D&M holding's stock prices, as Enron employees are accused of doing. But I don't think this is the case. They are just a little frightened by the powerful fists of the media conglomerates and want to play it a little safe and probably rightfully so.
It seems like the best reason to use the enterprise edition is the 24-7 service, or at least that's the one feature that IT executives will pay big money for. Then there's the 1 year subscription to the red hat network.
Other than that, the EE features only take advantage of 2+ processor machines and IA64 architectures, which aren't necessarily essential for most business applications.
I think any reasonably talented system admin can save you the expense of the other enterprise features.
Its difficult to tell what is really going on from reading the article-- eg. what the claims really were or how it performed. But shouldn't it be up to the customer to decide if the product works or not? Hasn't it always been?
Of course, this Enron product was not a clear cut scam. Misleading the customer is one thing, and its done all the time. Outright lying is quite another thing.
(Oh good, I just checked my mail and my new Enron Penis Enlargement Pump arrived!)
Well... ok, that is a better example, but its not a very inspirational one. However, in defense of the space station, I really don't think we should make decisions based on budgets and schedules when 'charting new territory.'
And it definitely should not keep us from further exploration.
And it DEFINITELY should not keep countries from working together on future space projects. Where would any science be without the cooperation of Europe and the US and China and whoever else?
I can't wait to see the Europeans make another important scientific discovery before US does.
Space exploration isn't a football game (or soccer for the europeans, or ping-pong for the chinese:) )! Haven't we learned a lesson from Clarke's 2001 series with the Russians & Americans working together? Lets hope they pool their knowledge and are able to get the world's space program up to speed where it should be, instead of wasting time and money with dumb politics & wars. (Ok, this is starting to sound like a folk song...)
There won't be any pressure to convert from the use of one file format to another. If you have a file format that is secret, then all you have to do is make the formatting algorithm freely available.
Here's some of the fascinating new crime-stoppers they will be displaying at the show. This new firearm was invented in alternative to stun or pellet guns, to scare the perp rather than killing or injuring them.
This one was invented catch white-collar criminals off-gaurd.
Think about the construction industry as a metaphor. You have small, somewhat specialized crews that move from project to project and they have to work with other crews on each project. They also have to work with the lumber yards, supply companies, and some of them have to communicate with an architect.
Can you imagine projects of this complexity being accomplished without standards? They have standard wood sizes, standard door sizes (carpentry is riddled with standard sizes for common things, but I'm not a carpenter, so I don't know the details), standard screw & bolt sizes. Then theres the plumbling, the electricty...
All of these details need to fit together in a predictable way and these specialized groups need to communicate in order to minimize conflicts. The lumber yard doesn't have time to cut new sizes of wood for each customer and the door manufacturer can't create special-make a door for each new house.
I don't think anyone can dispute that the software industry is in a similar position-- Teams of software engineers working together on projects, the OS needs to communicate with the software, blah blah blah. Of course we need standards! Some are more necessary than others, but how will we know in a year which web standards will be essential and which won't? Its good that we're drafting standards now so we have something to work with in the future. Maybe some standards will get thrown out, maybe some won't. This might stifle some innovation, but can you really argue its necessity?
Slashdot Mirror
My question is, wouldn't developers rather use purely object-based packages, if they could, rather than code generators? I believe purely object-based packages could work for most Object/relational tasks and simple compilers. The code becomes more portable and maintainable and doesn't require the extra training for use of the code generator.
What is the concensus on this? Especially in corporate development environments?
Introducing DRM to open content will only weaken its 'openness' and the DRM will be a threat to the integrity of the average internet user. I would suspect that weakening DRM and strengthening education on these issues would be more effective. Similarly, in the cases of illegal mp3 distribution, many people simply don't realize that it's unethical. Persecuting those who distribute copyrighted mp3s turns the practice into a game and causes people who wouldn't otherwise distribute or collect copyrighted mp3s to do so out of contempt for the RIAA and DRM.
The difference between an outlaw and an unethical person is that one of them is breaking a law and maybe getting away with it. Its a lot cooler to be an outlaw than simply an unethical person.
This is what thousands of people are using UML for! Then there are tools to translate the UML directly to Java. Of course, this doesn't exactly put an end to the constant refinement (but perhaps slows it down). It does let you beat your head against the wall over a much simpler code structure, rather than piles of implemented code. And without grouping your code and data into objects, I think the planning stages would become exponentially more complex.
You might be right about your 2nd point. Objects don't normally map well to relational db tables and the object-relational mapping solutions are awkward and difficult to use. In fact, since I started using OOP, I've almost stopped using more complex SQL completely.
Java proponents might say that to rely to greatly on SQL may compromise platform independence, but I don't know about that. Perhaps its just that people are scared to learn SQL.
I think many OOP developers, maybe even experienced ones, would be tempted to use the fat-wire approach in this example, or they might do it by accident at first, only to change it when they want to use taxPerson in other programs.
This is just a way of thinking that OOP programmers must learn, but I wouldn't consider it to be a detriment to the language, as it forces developers to do more planning. In fact, most Java programs have their complete set of interfaces designed before development even begins.
Alright, so I'm not trying to, uh, bait flame, but provided that Java works best for client-server applications, or just server-side apps, what are the major problems with Java as a platform? Or is it that Sun is not being open enough with the specifications?
Word of mouth advertising is the only real way for an independent project to get off the ground. If you have a good product, then people will use it. You can add lots of momentum by getting hosted by an organization like Apache or Tigris.org.
What it comes down to is having a stable product with a good user-interface, if applicable, good support, good distribution (not just makefiles, but rpms or installer software), good logging, etc.
The perfect book to describe all of this is Luke Hohmann's latest book Beyond Software Architecture, which I would highly recommend. It goes into great detail to explain how to develop software that people will want to use, open source or not.
Anyway, the quality of the product is first and foremost in open-source because advertising money is just not there. Most IT management are not tech-savvy and pay more attention to colorful ads than what the gurus are saying-- which makes it even harder to get the product used. The products that do get used in businesses are typically only the 'standards' like Apache or Sendmail, which have gained industry-wide acceptance.
The reason for making it open source is allow people outside of Sun to play with the code. There may be better ways to improve garbage collection and just-in-time compilation that Sun employees haven't thought of or haven't had time to do.
The GUI could use some work too. Sun probably doesn't know as much about Linux as OSS developers do. If OSS developers could use their knowledge of Linux to optimize the native GUI code, then there could be another advantage to OS Java.
Sun's interpreter could then just be the reference implementation for Java. They would have a better implementation in the OS Java and not have to take the blame for any shortcomings.
Ok, I'm thinking of Java man, from the island of Java. I must have learned this from grade school and I thought that was a silly name to call a primitive man, because it was coffee, right? So it must have stuck in my head that way, that primates came from Java, and I assumed they must have migrated to Africa and elsewhere. So apparently these primitive men can build ships and navigate waters too...
Ethiopia? Didn't humans come from the Philippines?
The kids would say "So is this what Quake is written in?" "No, its written in C." "Can I learn C instead?" "No, Lisp will teach you the fundamentals, so you can become a better C programmer."
Then they get bored.
But then again, they're not going to sit down with a C compiler and write Quake anyway.
For me, the mental leap from procedural to object-oriented programming was the idea that data and code are (or should always be) related. Even when I learned C++, I viewed classes as 'just another data type', or 'like structs, but with functions'.
It wasn't even until I learned Java that I realized data and code could ALWAYS be related in one way or another. With that realization, I began to do things in programming that I could never do before: reuse code on a large scale; break down the problem into its constituent problems, which is a skill that reaches beyond programming to other areas of problem-solving; and with these skills I could tackle more complex tasks without that feeling of being overwhelmed.
- Freely available
- Often used to teach programming in educational facilities nowadays
- Has all of the graphical stuff that kids would like
Cons:- Too hard... OOP is too big a learning curve when you just want to write a program that asks for your name and says "Hello, ".
- API is too rooted in com sci theory, another learning curve...
I say go with python. I think kids are by nature impatient when it comes to learning something new and they want fast results. Python comes with an interpreter, so you can get immediate feedback if you type in something wrong. Plus, its free and its as complicated as you want it to be. Kids won't have to learn OOP until they come across a problem that would really benefit from it and by then they've already learned the basics of the language well.Another thing is graphics, and I don't know if Python has an interface to the Windows graphics APIs. I think most young kids would enjoy creating graphics and games, so this would be a must-have feature for a young person's language. But screw LOGO. That was the first language I learned (in 3rd grade) and I was never so bored watching that 'turtle' move around and wondering how I could make Pac-man by rotating the turtle and making him move x pixels (not that its any easier in another language, but at least Apple II BASIC let me use my imagination more)
It doesn't seem like anyone (who isn't affiliated with a proprietary software company) is necessarily against open source as they are against the idea of the change itself. Changes in government are mostly reactionary. You need a large number of voters interested in the issue, otherwise its hardly worth the time. I believe the opponents to the open-source bills were mostly afraid to favor open-source; they weren't against it.
But all seriousness aside, I vaguely remember an article posted on slashdot about a company named Enron that boasted of product features which a product didn't have. This could be construed as a tactic to drive up D&M holding's stock prices, as Enron employees are accused of doing. But I don't think this is the case. They are just a little frightened by the powerful fists of the media conglomerates and want to play it a little safe and probably rightfully so.
From the article, it sounds like Kurtz needs a good kick in the butt.
Other than that, the EE features only take advantage of 2+ processor machines and IA64 architectures, which aren't necessarily essential for most business applications.
I think any reasonably talented system admin can save you the expense of the other enterprise features.
Of course, this Enron product was not a clear cut scam. Misleading the customer is one thing, and its done all the time. Outright lying is quite another thing.
(Oh good, I just checked my mail and my new Enron Penis Enlargement Pump arrived!)
And it definitely should not keep us from further exploration.
And it DEFINITELY should not keep countries from working together on future space projects. Where would any science be without the cooperation of Europe and the US and China and whoever else?
Space exploration isn't a football game (or soccer for the europeans, or ping-pong for the chinese :) )! Haven't we learned a lesson from Clarke's 2001 series with the Russians & Americans working together? Lets hope they pool their knowledge and are able to get the world's space program up to speed where it should be, instead of wasting time and money with dumb politics & wars. (Ok, this is starting to sound like a folk song...)
But then again, I'm just an unfrozen caveman.*
You disgrace us all!
Is this Andrew Wiles' proof or did somebody else prove it?
This one was invented catch white-collar criminals off-gaurd.
Very interesting stuff. Check it out!
Can you imagine projects of this complexity being accomplished without standards? They have standard wood sizes, standard door sizes (carpentry is riddled with standard sizes for common things, but I'm not a carpenter, so I don't know the details), standard screw & bolt sizes. Then theres the plumbling, the electricty...
All of these details need to fit together in a predictable way and these specialized groups need to communicate in order to minimize conflicts. The lumber yard doesn't have time to cut new sizes of wood for each customer and the door manufacturer can't create special-make a door for each new house.
I don't think anyone can dispute that the software industry is in a similar position-- Teams of software engineers working together on projects, the OS needs to communicate with the software, blah blah blah. Of course we need standards! Some are more necessary than others, but how will we know in a year which web standards will be essential and which won't? Its good that we're drafting standards now so we have something to work with in the future. Maybe some standards will get thrown out, maybe some won't. This might stifle some innovation, but can you really argue its necessity?
I guess we Americans can't blame anyone for not trusting us after the whole Iraq thing. Somebody's got to police the police!