I think the most easy way to get rid of USPTO policy would be to patent "patent acceptation model" in a so subtle way they could not even detect it , or something like "a method to consume air for biological devices" (ie:breathing).
Any place for both of them ?
on
Java 1.5 vs C#
·
· Score: 3, Insightful
It's too easy to give C# an advantage about what it adds to Java and forgetting it's a 95% Java clone.
Don't forget It took 7 years of Java and a Borland expert to produce C# !
During this time, Java did conquer most of the enterprise application development market and defined a technology model based on application servers handling component lifecycles.
C# as a language,has taken most of java state of the art paradigms and added some new features which are neat but, despite its huge base library is far from Java versatility and degree of maturity.
Java 1.5 advantages
Language Features/Libraries:
Server side Programming:
Defined server side technology paradigms, with lots of implementors to handle them (open source and free ones are competing with the best commercial ones).
Client Side Programming:
Applets (which aren't dead technology if you know how to use them)
Web Start
IDE/Tools
Eclipse (which is free and open)
Management aspects
Lots of available skilled developers
Can run on any platform with a compliant JVM (if well coded)
All big database vendors have JDBC drivers
Mature technology
Java 1.5 Drawbacks
Server Side:
Web Service support are expensive to implement and non-standardized.
Very poor JSF controls
Client Side:
Swing (but SWT / Eclipse rocks)
C# advantages
Language Features:
Benefits from the.Net Jitter.
Events/Delegates model
Client Side:
Future Windows Development preferred language (along with XAML which is more about powerful UI macro-scripting)
DirectX integration
Speed (on Windows)
Server Side
ASP.Net Controls model
IDE/Tools
VS.Net (most productivity boosting IDE IMHO)
Management aspects
Still time to have plenty of Microsoft support if you have a interesting project.
C# drawbacks
Language Features
No Observable/Observer (but achievable through Events/Delegates)
Serialization limitations
Client Side
No Windows independent GUI framework. (WebForms are server-based controls)
No applets equivalent (don't event think about ActiveX)
Server Side
No detailed Infrastructural model, No best practices, No fine grained control.
IDE/Tools
No free IDEs compares to VS.Net and is really useable when you're used to commercial IDEs features. (Borland C# Builder CE is too restricted and not open source)
Management aspects
Young technology
Not that much real experts available out of Microsoft
Windows deployment only (Mono's out, but still work in progress,can't be a professional choosen.NET deployment platform yet IMHO)
So, my conclusion is that by now, both technologies are interesting but Java is the most versatile.
I would prefer C# for:Windows Programming,Attractive Web based interfaces (if an acceptable target platform is Mono or Windows),
Porting existing windows applications to Web,
Simple Self-Contained Web Services
I Would prefer Java for developing:Enterprise Applications,Complex Web Services,Highly interactive web interfaces (through applets),Multi OS client application.
For me, both languages are relevant, it's only a matter of what work has to be done and what resources are available to make it.Most of the time, technology is chosen based on a company resources capabilities!
I'm a software architect and i had to face the same problems.
I'm currently designing a GUI application that has to deal with an SNMP-manageable device that has a lot of specific features.
I decided to use a "physically" modular architecture based on MVC paradigim.
Each module (which can be dynamically loaded by the application) implements its own MVC but each controller doesn't speak directly to its model.
I use the main application as a public dispatcher which each module Model (in MVC paradigm) has to subscribe to, presenting the high-level messages they want to receive.
In an MVC way, the main application acts as a meta-controller.And i can achieve full architecture openess (each part of the application is a real plug-in)
But MVC doesn't cover the underlying window system programming model.And things can become somewhat confuse.
So, the module insertion protocol has to specify a way to handle GUI integration (like inserting menu entries into the main application menu)
Moreover,the MDI (Multiple Document Interface) programming model complicates a little bit.
(Better Not speaking about the Microsoft MFC Document/View approach !)
So, doing an efficient GUI application architecture requires integrating good OO paradigms (like MVC, plugin architecture) with often inconsistent system GUI pseudo programming model. The main problem is here.
MVC is efficient if the messages/orders between the M,V and C are of the highest possible level with detailed information associated.
IMHO,A good approach is to make autonomous,reusable GUI components which are only System GUI compliant but highly customizable (with callbacks).
Thus you can implement MVC by using a View (in MVC meaning) Adapter Object for giving a view behaviour to your GUI component, then configuring or subclassing your GUI component to insert the controller behaviour via the callbacks.
All simple interactions are held into the component, all interactions impacting application logic are transfered to the controller via the configured callbacks.
I work in a small company (ab. 50 employees) that neglected quality for a long time. By now and after more than 2 years and some important (near deadly) failures , the company is on the way to quality.
The principal reason for the failures was : no way at all to evaluate the impact of the decisions before they were taken (without asking the good people). It was only money driven decisions
Many of us (particulary i and a workmate) were aware of the total nonsense of some decisions and the impact of these decisions on our products.
For some "calm down" reasons , the CEO decided to hire a first quality manager. The objective was to become ISO-9001 (now ISO 2000) compliant (i.e. getting a better image = money:)) .
This manager did quit after less than 6 month,NO WAY TO WORK !!!!
The CEO did not let her the sufficient power to only gather the information she needed. The reason is : There was no structure at all, no processes and the concept of organizing the company respecting good sense standards was some way violating the CEO idea of its absolute control of all taken decisions.
There was another caveeat : Quality manager needed work groups for setting up company processes. And the CEO only saw the money spent by the meetings. He didn't see at all the money lost by not having structured processes at the company level.
Then a second quality manager was hired. He rapidly guessed that there was no way for us to be quality compliant in a short term.
So its first work was to give some basic quality tools (reports, ways to do) at the lower level.
Then the quality manager began to make some psychology on the CEO (manipulation is a too strong term) to slowly getting him to the idea that something was wrong at all levels, that there were another way to work and to organize the company and that without that organization , there was no way for the company to get funds from investors.
So, getting back to our sheeps , at the lower level, the Software Engeneering department was taken for the "quality experiment". And we began our first really driven project. We had no powerful tools (only 1 MS Project and noone used to it) and quite no resources allocated for the quality on the project.But with some excel spreadsheets , we built our first bug tracking system, a free UML Modeler for the design and it was already another world.
The main problem was evaluating the amount of work, and scheduling deadlines ( for the first time, the decision was given to the developers!).
The lack of experience leaded to a 1,7 factor on the expected time. Not that bad , considering we had to learn the basics of project management at the company level.
IMO,You don't have to consider quality as a "magic wand". It's long, it's hard and it has a cost. It's a company wide policy and if the high level staff is not 100% involved and convinced , the fight is already lost.
Software Quality is only the side effect of company wide quality processes adapted to the Software development.
More than tools, Quality is a question of methods and processes related to a efficient and continuous system of process control and evaluation, whatever quality system you want to take.
It needs high experimented people to drive such a transformation and a total trust between the CEO and these people.
My company still has a lot of work to become quality standard compliant but the harder is done, the CEO knows that setting up company processes is the only way to ensure a real control of the company future and to give reports that are significants and reality based.
Only after some years, there will be enough material to give a really efficient decision aid based on these reports.And the company will be able to control its future instead of rolling a dice and pray that the unweightable cost of a decision will be below the result benefit of that decision!
Quality policy gives a way to evaluate the real cost (in a global definition) of a decision and to compare it to the expected result BEFORE a decision is taken !!
But this goal can't be achieved fast, quality is somewhat the way to wisdom !!!
Don't loose the faith, and don't be aggressive.
You can't impose quality , a better way is to efficiently suggesting it and to play a game of with/without and to have really skilled people in that domain to assist you.
Slashdot Mirror
I think the most easy way to get rid of USPTO policy would be to patent "patent acceptation model" in a so subtle way they could not even detect it , or something like "a method to consume air for biological devices" (ie:breathing).
It's too easy to give C# an advantage about what it adds to Java and forgetting it's a 95% Java clone.
Don't forget It took 7 years of Java and a Borland expert to produce C# !
During this time, Java did conquer most of the enterprise application development market and defined a technology model based on application servers handling component lifecycles.
C# as a language,has taken most of java state of the art paradigms and added some new features which are neat but, despite its huge base library is far from Java versatility and degree of maturity.
Java 1.5 advantages
Java 1.5 Drawbacks
- Client Side:
- Swing (but SWT / Eclipse rocks)
C# advantages- Management aspects
- Still time to have plenty of Microsoft support if you have a interesting project.
C# drawbacksSo, my conclusion is that by now, both technologies are interesting but Java is the most versatile.
I would prefer C# for:Windows Programming ,Attractive Web based interfaces (if an acceptable target platform is Mono or Windows),
Porting existing windows applications to Web,
Simple Self-Contained Web Services
I Would prefer Java for developing:Enterprise Applications,Complex Web Services,Highly interactive web interfaces (through applets),Multi OS client application.
For me, both languages are relevant, it's only a matter of what work has to be done and what resources are available to make it.Most of the time, technology is chosen based on a company resources capabilities!
I'm currently designing a GUI application that has to deal with an SNMP-manageable device that has a lot of specific features.
I decided to use a "physically" modular architecture based on MVC paradigim.
Each module (which can be dynamically loaded by the application) implements its own MVC but each controller doesn't speak directly to its model.
I use the main application as a public dispatcher which each module Model (in MVC paradigm) has to subscribe to, presenting the high-level messages they want to receive.
In an MVC way, the main application acts as a meta-controller.And i can achieve full architecture openess (each part of the application is a real plug-in)
But MVC doesn't cover the underlying window system programming model.And things can become somewhat confuse.
So, the module insertion protocol has to specify a way to handle GUI integration (like inserting menu entries into the main application menu) Moreover,the MDI (Multiple Document Interface) programming model complicates a little bit. (Better Not speaking about the Microsoft MFC Document/View approach !)
So, doing an efficient GUI application architecture requires integrating good OO paradigms (like MVC, plugin architecture) with often inconsistent system GUI pseudo programming model. The main problem is here.
MVC is efficient if the messages/orders between the M,V and C are of the highest possible level with detailed information associated.
IMHO,A good approach is to make autonomous,reusable GUI components which are only System GUI compliant but highly customizable (with callbacks).
Thus you can implement MVC by using a View (in MVC meaning) Adapter Object for giving a view behaviour to your GUI component, then configuring or subclassing your GUI component to insert the controller behaviour via the callbacks.
All simple interactions are held into the component, all interactions impacting application logic are transfered to the controller via the configured callbacks.
I work in a small company (ab. 50 employees) that neglected quality for a long time. By now and after more than 2 years and some important (near deadly) failures , the company is on the way to quality. The principal reason for the failures was : no way at all to evaluate the impact of the decisions before they were taken (without asking the good people). It was only money driven decisions Many of us (particulary i and a workmate) were aware of the total nonsense of some decisions and the impact of these decisions on our products. For some "calm down" reasons , the CEO decided to hire a first quality manager. The objective was to become ISO-9001 (now ISO 2000) compliant (i.e. getting a better image = money :)) .
This manager did quit after less than 6 month,NO WAY TO WORK !!!!
The CEO did not let her the sufficient power to only gather the information she needed. The reason is : There was no structure at all, no processes and the concept of organizing the company respecting good sense standards was some way violating the CEO idea of its absolute control of all taken decisions.
There was another caveeat : Quality manager needed work groups for setting up company processes. And the CEO only saw the money spent by the meetings. He didn't see at all the money lost by not having structured processes at the company level.
Then a second quality manager was hired. He rapidly guessed that there was no way for us to be quality compliant in a short term.
So its first work was to give some basic quality tools (reports, ways to do) at the lower level.
Then the quality manager began to make some psychology on the CEO (manipulation is a too strong term) to slowly getting him to the idea that something was wrong at all levels, that there were another way to work and to organize the company and that without that organization , there was no way for the company to get funds from investors.
So, getting back to our sheeps , at the lower level, the Software Engeneering department was taken for the "quality experiment". And we began our first really driven project. We had no powerful tools (only 1 MS Project and noone used to it) and quite no resources allocated for the quality on the project.But with some excel spreadsheets , we built our first bug tracking system, a free UML Modeler for the design and it was already another world.
The main problem was evaluating the amount of work, and scheduling deadlines ( for the first time, the decision was given to the developers!).
The lack of experience leaded to a 1,7 factor on the expected time. Not that bad , considering we had to learn the basics of project management at the company level.
IMO,You don't have to consider quality as a "magic wand". It's long, it's hard and it has a cost. It's a company wide policy and if the high level staff is not 100% involved and convinced , the fight is already lost.
Software Quality is only the side effect of company wide quality processes adapted to the Software development.
More than tools, Quality is a question of methods and processes related to a efficient and continuous system of process control and evaluation, whatever quality system you want to take.
It needs high experimented people to drive such a transformation and a total trust between the CEO and these people.
My company still has a lot of work to become quality standard compliant but the harder is done, the CEO knows that setting up company processes is the only way to ensure a real control of the company future and to give reports that are significants and reality based.
Only after some years, there will be enough material to give a really efficient decision aid based on these reports.And the company will be able to control its future instead of rolling a dice and pray that the unweightable cost of a decision will be below the result benefit of that decision!
Quality policy gives a way to evaluate the real cost (in a global definition) of a decision and to compare it to the expected result BEFORE a decision is taken !!
But this goal can't be achieved fast, quality is somewhat the way to wisdom !!!
Don't loose the faith, and don't be aggressive.
You can't impose quality , a better way is to efficiently suggesting it and to play a game of with/without and to have really skilled people in that domain to assist you.