Parallel programming is incredibly hard to do right, only novice programmers in the field will claim otherwise. Consider race/starve conditions, the fact that parallel programs are very hard to debug, hard to test. On top of that the can of worm called thread/process synchronization, which in modern architectures with processor caches etc. have not become any easier. You cannot change the property of an object and rely on another thread picking it up, even after a protected section. The other cpu may just have that propertys memory content in its own cache. Declaring every property of our program volatile is clearly not the way, as it would defeit the benefits of running in parallel in the first case.
On the other hand many of us are already programming parallel threads/processes when we program for an application server. The typical web application server will handle a number of concurrent requests, but will serialize access to the relevant common object, namely the session abstraction.
High end database systems have been doing parallel execution of queries for years. Clearly this is a very good abstraction as we don't even have to know that its taking place.
A very common pattern seen in programs is looping through an array or list to do something, like e.g. a transform or performing specific actions on select items. Most of the time we just want the work done and don't really care whether it is done in parallel or serialized, only our programming language forces us to do the latter.
Closures is a (small) step on the road to taking advantage of multiple CPUs and -cores. Microsoft LINQ (to objects) actually brings the parallel traversal of in-memory collections within reach for common developers.
We need to know the theory behind parallel programming to understand concepts such as "volatile" variables etc, but we shouldn't need to be concerned with the complexities in every single line of code.
I have a feeling that the statically typed high level languages will have an advantage here. Consider Java/.NET which uses a JIT compiler on the target architecture. Doing static analysis on a program with respect to the target architecture will be easier if the optimizer/compiler actually knows the types during JITing.
That used to be more difficult on IIS, but IIS version 6 (which comes with server 2003 and XP) uses configuration stored in file called metabase.xml.
As the name indicates this is an xml file (not a strange hybrid apache httpd style config file). The GUI management (MMS management console plugin) is merely a way to edit this file, like Webmin for Apache.
That translates into easier management by tools and scripts. Think xslt, xpath, installation scripts etc.
Changes to the xml file can be set to take effect immediately, removing the need to restart the server. IIS will "drain" processes using the old configuration by not dispatching any more requests and terminating them when they have finished processing the requests. At the same time IIS starts new processes up to handle new requests using the new configuration. The result is uninterrupted service, even when doing config changes. And that can be triggered by simply editing or overwriting the config file.
It's a long time since Java executed byte-code interpreted. The.NET languages never did. True, the code is distributed as byte-code, but is compiled prior to first execution.
That's very well put. I agree with everything in your post. As a Java developer/architect I experienced the very issues you raised myself. The most notable sample of over-engineering is perhaps EJB, especially the entity beans (stateless sessionbeans I still find somewhat useful).
Then there's the checked exception disaster. This is actually the only sample where Sun seems to have put something experimental in there before having harvested experience with it in other experimental languages.
The hard thing about the over-engineering is that it's actually very difficult to disagree with the objective. EJBs sounded like a good idea at the time. Checked exceptions still have a lot of followers. Calendars sound like a cool idea too: Once and for all solve the timezone and date artitmetic confusion. It's just that a language is not only theory about what might be useful. A real-life language has to pass the test of time (and less than stellar developers). The practices that emerge, the real life problems may eventually kill the theory.
What I was saying is that PHP approaches from the directly opposite direction. PHP was pragmatic from the onset. When a feature was needed, the language was just extended with a new facility. "Are people having problems building dynamic SQLs and becoming vulnerable to SQL injection attacks? I have an idea. I think it's... lets call it MAGIC QUOTES!". And "After all, every web page needs to access the URL parameters. Why not just expose them as automatic variables?".
That's why I find it unlikely that the cultures will ever unite. I find that both approaches have their problems. I actually prefer the middle way on this. The totally understand why Hibernate, Spring et.el. are having such a success now.
I know, a swing GUI is certainly not the best performing GUI. However, with the "hackish" feel I was referring to the developer experience. From a developer perspective Swing is actually quite well engineered. PHP is not. PHP came to be the way it is by accident.
As such Java and PHP come from quite different cultural backgrounds. What I'm saying is that I have a very hard time imagining Java and PHP as a happy couple.
PHP is probably one of the best (worst) examples of what a language would look like if it was designed and developed incrementally in an open source community. It's hack upon hack upon hack. It's backward compatibility breaking changes is just about every point(!) release. Register_globals enyone? Magic quotes? Ambivalence towards types/objects - "type hinting". Arguably (and freely admitted by the designers) PHP is *not* a well designed language. It's a pragmatic ooops kind of language whose main advantage is a large (albeit somewhat amateurish) user base, and free availability.
Java on the other hand - if anything - tends to be over-engineered. Swing is actually more flexible than even.NET Windows Forms (which was designed later). It's easier to combine widgets, e.g. put textboxes inside tree nodes, etc. Swing may be a little slow, but nothing Java has ever had that "hackish" feel to it. It's always well thought out. Same thing could be said about JSF, JDO and certainly EJB.
Sun has always taken great care of minimizing BC breaking changes. Sun has always taken pride in being a little on the conservative side, i.e. only introduce well understood technologies. This has been received well by the enterprise developer community. PHP is nowhere near that yet. There's still tons of BC breaking changes in store for PHP developers when PHP finally will get namespaces, unicode support etc.
To put it simple, the primary virtues of Java is nowhere to be found in PHP. And frankly, if PHP is the way a language looks like when it's designed by an open source community, open sourcing Java would possibly destroy it. A model like eclipse where it's formally open sourced but in reality still maintained by a single, competent organization might work, though.
No, it's *not* an interpreted language. The C# compiler (or VB or J# or Eiffel or...) will compile into Intermediate Language. This language was never intended to be interpreted. In fact, no interpreter exists for this language (well, not publicly from MS anyway).
Upon first execution the IL is compiled to machine instructions on the target architecture. This code is then executed, and then kept in a private cache so that the next execution will not have to repeat the compilation
ASP.NET is incredibly productive
on
JSF vs ASP.net
·
· Score: 1
I'm a little concerned about the maturity of JSF, especially as Microsoft has just raised the bar (nov 7th
last year) with the latest release of ASP.NET. The 2.0 release made up for some of the errors by omission
from 1.x. But more importantly 2.0 also introduced a number of new concepts which really boost ASP.NET
development:
MasterPages. Page templating ensures consistent page layout throughout the site, without the hassle of a centralized dispatcher logic like e.g. a front controller.
WebParts. Makes creating portal websites and/or -pages a no-brainer (well, once you get a grasp on the
concepts involved). Drag&drop works in all common browsers. The user can rearrange webparts, collapse/expand
individual parts, add from a catalog, hide/remove parts, export/import to/from local files, link properties
across parts. For the developer creating a webpart involves roughly the same effort as creating a page with
the same functionality.
Declarative Localization. Finally lets you do those multilingual sites without cluttering the pages with
conditionals or code to retrieve text values. Localization is declarative: The tags are adorned with a meta
attribute which specifies a resource key. The lookup/substitution is completely automated. You are still
working with the markup in your default language. Alternative languages are specified in external resource
(xml) files. These may alter any attribute, e.g. image urls, text etc.
Caching. Fine-grained control over output caching (page and pagelet caching). This includes declaratively
setting up cache dependencies to invalidate the cache. Database systems (Oracle and SQL Server) can even be
set to invalidate the caches automatically (event based) when the result of a query would change because of a
database change. Other caching options inclused application managed caching and resultset caching.
Themes/Skins. Lets you declaratively alter select properties of controls across the site. You can think
of themes like server-side style sheets. Being server-side they can alter properties of server-side controls.
One theme may choose to not use paging in GridViews, while another theme may choose to enable paging with a
pagesize of 20 for all GridViews.
Multiple compilation/deployment options. In one end of the spectrum you can deploy fully precompiled
sites, in the other you can deploy sourcefiles and leave all compilation up to the webserver. There are
pro/cons indicators of each model.
Adaptive Rendering. Serves same purpose as renderkits. Lets you specify alternative rendering for
specific devices. In 2.0 this has meant that the former special "mobile controls" for WML has been folded into mainstream ASP.NET.
Asynchronous Webpages. Some web pages needs to call upon external resources, e.g. webservices. Some of
these calls make take a long time (seconds). Tieing up the thread/process of the webserver while the
page/model waits for the request will lead to decreased scalability. Asynchronous pages will let you
relinquish the thread. When the external, asynchronous call returns, another thread is dispatched again to
complete the processing.
Membership Controls/-Providers. A number of standard controls for creating a membership sites: Login,
CreateUserWizard, LoginView (showing alternative content based on login status and/or roles belonged to),
LoginName, PasswordRecovery. All of these controls are fully customizable, i.e. you can take full control of
the rendered xhtml. The controls includes membership specific functionality. The controls work their magic by
integrating with a Membership Provider. You can go with one of the two supplied, or implement your own.
Integrated Personalization. Choice of theme, language, webpart customizations etc. are by default
integra
For your information it is a flaw in *MySQL* that allows a script to store binary code in a BLOB (not a problem) and afterwards dump the content to an OS file named *.dll (some problem) and finally execute the damned file (big problem).
I'm sorry, but this is exclusively a problem with bad admins (weak passwords) and MySQL bugs.
Which doesn't prevent them from selling copies of your software. It just means they can't pass the same permissions on to anyone else.
But it does. non-transferable means that MS can not pass it on. Non-sublicenseable means that they can't allow anyone else to use the product (but you must agree to license to everybody else).
Mind you - this license only covers the implementation. I think you are likening it to GPL where you have to license back a product that *uses* the licensed material (the whole product). This license does not state that; you only have to offer the implementation for everybody else. A mail-product that uses this your implementation will not have to be licensed back.
It certaintly looks more like a standard safeguard, that will prevent anyone implementing this scheme to take out a patent for a specific implementation. That's a good thing.
Slashdot Mirror
Parallel programming is incredibly hard to do right, only novice programmers in the field will claim otherwise. Consider race/starve conditions, the fact that parallel programs are very hard to debug, hard to test. On top of that the can of worm called thread/process synchronization, which in modern architectures with processor caches etc. have not become any easier. You cannot change the property of an object and rely on another thread picking it up, even after a protected section. The other cpu may just have that propertys memory content in its own cache. Declaring every property of our program volatile is clearly not the way, as it would defeit the benefits of running in parallel in the first case.
On the other hand many of us are already programming parallel threads/processes when we program for an application server. The typical web application server will handle a number of concurrent requests, but will serialize access to the relevant common object, namely the session abstraction.
High end database systems have been doing parallel execution of queries for years. Clearly this is a very good abstraction as we don't even have to know that its taking place.
A very common pattern seen in programs is looping through an array or list to do something, like e.g. a transform or performing specific actions on select items. Most of the time we just want the work done and don't really care whether it is done in parallel or serialized, only our programming language forces us to do the latter.
Closures is a (small) step on the road to taking advantage of multiple CPUs and -cores. Microsoft LINQ (to objects) actually brings the parallel traversal of in-memory collections within reach for common developers.
We need to know the theory behind parallel programming to understand concepts such as "volatile" variables etc, but we shouldn't need to be concerned with the complexities in every single line of code.
I have a feeling that the statically typed high level languages will have an advantage here. Consider Java/.NET which uses a JIT compiler on the target architecture. Doing static analysis on a program with respect to the target architecture will be easier if the optimizer/compiler actually knows the types during JITing.
That used to be more difficult on IIS, but IIS version 6 (which comes with server 2003 and XP) uses configuration stored in file called metabase.xml. As the name indicates this is an xml file (not a strange hybrid apache httpd style config file). The GUI management (MMS management console plugin) is merely a way to edit this file, like Webmin for Apache. That translates into easier management by tools and scripts. Think xslt, xpath, installation scripts etc. Changes to the xml file can be set to take effect immediately, removing the need to restart the server. IIS will "drain" processes using the old configuration by not dispatching any more requests and terminating them when they have finished processing the requests. At the same time IIS starts new processes up to handle new requests using the new configuration. The result is uninterrupted service, even when doing config changes. And that can be triggered by simply editing or overwriting the config file.
It's a long time since Java executed byte-code interpreted. The .NET languages never did. True, the code is distributed as byte-code, but is compiled prior to first execution.
That's very well put. I agree with everything in your post. As a Java developer/architect I experienced the very issues you raised myself. The most notable sample of over-engineering is perhaps EJB, especially the entity beans (stateless sessionbeans I still find somewhat useful).
... lets call it MAGIC QUOTES!". And "After all, every web page needs to access the URL parameters. Why not just expose them as automatic variables?".
Then there's the checked exception disaster. This is actually the only sample where Sun seems to have put something experimental in there before having harvested experience with it in other experimental languages.
The hard thing about the over-engineering is that it's actually very difficult to disagree with the objective. EJBs sounded like a good idea at the time. Checked exceptions still have a lot of followers. Calendars sound like a cool idea too: Once and for all solve the timezone and date artitmetic confusion. It's just that a language is not only theory about what might be useful. A real-life language has to pass the test of time (and less than stellar developers). The practices that emerge, the real life problems may eventually kill the theory.
What I was saying is that PHP approaches from the directly opposite direction. PHP was pragmatic from the onset. When a feature was needed, the language was just extended with a new facility. "Are people having problems building dynamic SQLs and becoming vulnerable to SQL injection attacks? I have an idea. I think it's
That's why I find it unlikely that the cultures will ever unite. I find that both approaches have their problems. I actually prefer the middle way on this. The totally understand why Hibernate, Spring et.el. are having such a success now.
I know, a swing GUI is certainly not the best performing GUI. However, with the "hackish" feel I was referring to the developer experience. From a developer perspective Swing is actually quite well engineered. PHP is not. PHP came to be the way it is by accident.
As such Java and PHP come from quite different cultural backgrounds. What I'm saying is that I have a very hard time imagining Java and PHP as a happy couple.
Agreed. Ruby would be a much better mach for Java. Ruby has a very clean, conceptually strong core. In this regard it has much in common with Java.
PHP is probably one of the best (worst) examples of what a language would look like if it was designed and developed incrementally in an open source community. It's hack upon hack upon hack. It's backward compatibility breaking changes is just about every point(!) release. Register_globals enyone? Magic quotes? Ambivalence towards types/objects - "type hinting". Arguably (and freely admitted by the designers) PHP is *not* a well designed language. It's a pragmatic ooops kind of language whose main advantage is a large (albeit somewhat amateurish) user base, and free availability. Java on the other hand - if anything - tends to be over-engineered. Swing is actually more flexible than even .NET Windows Forms (which was designed later). It's easier to combine widgets, e.g. put textboxes inside tree nodes, etc. Swing may be a little slow, but nothing Java has ever had that "hackish" feel to it. It's always well thought out. Same thing could be said about JSF, JDO and certainly EJB.
Sun has always taken great care of minimizing BC breaking changes. Sun has always taken pride in being a little on the conservative side, i.e. only introduce well understood technologies. This has been received well by the enterprise developer community. PHP is nowhere near that yet. There's still tons of BC breaking changes in store for PHP developers when PHP finally will get namespaces, unicode support etc.
To put it simple, the primary virtues of Java is nowhere to be found in PHP. And frankly, if PHP is the way a language looks like when it's designed by an open source community, open sourcing Java would possibly destroy it. A model like eclipse where it's formally open sourced but in reality still maintained by a single, competent organization might work, though.
No, it's *not* an interpreted language. The C# compiler (or VB or J# or Eiffel or ...) will compile into Intermediate Language. This language was never intended to be interpreted. In fact, no interpreter exists for this language (well, not publicly from MS anyway).
Upon first execution the IL is compiled to machine instructions on the target architecture. This code is then executed, and then kept in a private cache so that the next execution will not have to repeat the compilation
MasterPages. Page templating ensures consistent page layout throughout the site, without the hassle of a centralized dispatcher logic like e.g. a front controller.
WebParts. Makes creating portal websites and/or -pages a no-brainer (well, once you get a grasp on the concepts involved). Drag&drop works in all common browsers. The user can rearrange webparts, collapse/expand individual parts, add from a catalog, hide/remove parts, export/import to/from local files, link properties across parts. For the developer creating a webpart involves roughly the same effort as creating a page with the same functionality.
Declarative Localization. Finally lets you do those multilingual sites without cluttering the pages with conditionals or code to retrieve text values. Localization is declarative: The tags are adorned with a meta attribute which specifies a resource key. The lookup/substitution is completely automated. You are still working with the markup in your default language. Alternative languages are specified in external resource (xml) files. These may alter any attribute, e.g. image urls, text etc.
Caching. Fine-grained control over output caching (page and pagelet caching). This includes declaratively setting up cache dependencies to invalidate the cache. Database systems (Oracle and SQL Server) can even be set to invalidate the caches automatically (event based) when the result of a query would change because of a database change. Other caching options inclused application managed caching and resultset caching.
Themes/Skins. Lets you declaratively alter select properties of controls across the site. You can think of themes like server-side style sheets. Being server-side they can alter properties of server-side controls. One theme may choose to not use paging in GridViews, while another theme may choose to enable paging with a pagesize of 20 for all GridViews.
Multiple compilation/deployment options. In one end of the spectrum you can deploy fully precompiled sites, in the other you can deploy sourcefiles and leave all compilation up to the webserver. There are pro/cons indicators of each model.
Adaptive Rendering. Serves same purpose as renderkits. Lets you specify alternative rendering for specific devices. In 2.0 this has meant that the former special "mobile controls" for WML has been folded into mainstream ASP.NET.
Asynchronous Webpages. Some web pages needs to call upon external resources, e.g. webservices. Some of these calls make take a long time (seconds). Tieing up the thread/process of the webserver while the page/model waits for the request will lead to decreased scalability. Asynchronous pages will let you relinquish the thread. When the external, asynchronous call returns, another thread is dispatched again to complete the processing.
Membership Controls/-Providers. A number of standard controls for creating a membership sites: Login, CreateUserWizard, LoginView (showing alternative content based on login status and/or roles belonged to), LoginName, PasswordRecovery. All of these controls are fully customizable, i.e. you can take full control of the rendered xhtml. The controls includes membership specific functionality. The controls work their magic by integrating with a Membership Provider. You can go with one of the two supplied, or implement your own.
Integrated Personalization. Choice of theme, language, webpart customizations etc. are by default integra
For your information it is a flaw in *MySQL* that allows a script to store binary code in a BLOB (not a problem) and afterwards dump the content to an OS file named *.dll (some problem) and finally execute the damned file (big problem). I'm sorry, but this is exclusively a problem with bad admins (weak passwords) and MySQL bugs.
This is the Virus. You are owned!
Do tell then, how do you change screen resolution?
Which doesn't prevent them from selling copies of your software. It just means they can't pass the same permissions on to anyone else. But it does. non-transferable means that MS can not pass it on. Non-sublicenseable means that they can't allow anyone else to use the product (but you must agree to license to everybody else). Mind you - this license only covers the implementation. I think you are likening it to GPL where you have to license back a product that *uses* the licensed material (the whole product). This license does not state that; you only have to offer the implementation for everybody else. A mail-product that uses this your implementation will not have to be licensed back. It certaintly looks more like a standard safeguard, that will prevent anyone implementing this scheme to take out a patent for a specific implementation. That's a good thing.
Indeed I believe you are misreading it. The license you grant Microsoft is *non-transferable* and *non-sublicenseable*.
However, Microsoft may *use* your product.