Internet sales has been treated like mail-order for a long while. The standard there has been, you collect sales tax for residents of states/counties in which you have an office.. It's a decent compromise because if you set up shop, then you already have to deal w/ employment taxation in that region, so knowing the laws in that region is not as burdensome.
I don't recall, however, whether it is the billing address or the shipping address that is used for calculation.
This idea of universal region tax collection is just ludicrous for the same reasons it never flew for mail-order.
If billing is collected based on shipment address, what about web services that have NO shipment address! What about purchases made through pay-pal? Other than through eBay/etc, there is NO associated shipment address, and in fact no billing address (you just have an email address). If I purchase software online, I don't provide a billing address. What state is my taxation from?
Try downloading a ringtone sold by sprint on a verizion phone. It doesn't work. Not because the song isn't compatible but because they will put up money road blocks into the way to force you to pay.
Just as an FYI.. I happen to work in the cell phone content industry. The reasons you can't easily purchase the same content on different phones is manifold. And only 25% of it has to do with billing limitations. Every cell phone is it's own universe, and could care less about the standards used by other cell phone companies. Then throw in the fact that cell phone makers are another layer of complexity in terms of what protocols they support. Then add the many types of billing models that cell phone companies employ (pay-as-you-go v.s. monthly bill). Then take the fact that cell phone companies change their protocols on average twice a year.
As a content provider, the liability is such that it is best to simply exclude phones that physically support the particular piece of content, but have one of the many pieces of the puzzle missing. The probability of a user ultimately not figuring out how to get the data correctly is too high and thus the probability of wasting money on a tech-support-call makes that sale not worth it.
There are 10's of thousands of phone combinations out there (ignore the latent US).
The software and network industry use to be like this. Lots of choice, really hard to provide across-the-board solutions. This recognition causes people to flock to the perceived winner like mad birds. So if there is an internet firm that manages to demonstrate cost effective models for content production, you had better believe that the entire producer industry will migrate in that direction. Consumer choice be damned.
Does the overhead of a GUI system justify losing it in favor of administrating via a CLI?
Others' have posted properly things that would answer this.. I will add the following. A server's service is something that needs three things: an environment sufficient to complete it's task, a point of configuration, and a point of monitoring.
Presumably the configuration and monitoring are independent aspects of the operation of a service. Thus in an ideal application, the environment requirements are independent of those of the configuration and monitoring.
Whether a UNIX dot-file, a windows bracketed ".ini" file, a windows-registry, a java RMI remote configuration, or a database is used, the mechanism by which you administer those settings is still independent.
The simplest fashion in which you have have a service provide administrative and monitoring is a web service.. There is zero need for a custom GUI client. The rendering of HTML and the processing of HTTP headers is so trivial that you almost never require external libraries to facilitate it. There are c, java and perl libraries that make it a no-brainer.
Unreal Tournament, for example uses a web service as the administrative interface to configure a UT server. Most routers or even printers these days have built in web servers.
The only problem is that each service would require having a separate server port.. Which I admit is a non trivial thing to reconcile..
Aggregated environments like tomcat or jBoss in the java world make it easy to plug a server into an environment.. In both environments you dynamically add/remove services in a central web GUI.
The idea is that you legitimately can charge people based on their ability to pay. A small company gets the service much cheaper than a larger company because there are fewer seats.
Economicly there's nothing wrong with it.. A larger company can afford to pay more for the same service that a smaller company can; you're just normally allowed to discrimiate pricing.
Another justification is that w/ client-installed software, you can charge per seat.. But w/ server software there is only ever one seat.. Imagine if MS office could be installed as a web service.. There would literally only ever be a single copy of web-MS-office ever sold.. One guy with a big server and a public grant would install it, and the world could use it for free...
When http 1'st become popular, companies I worked for seriously had to consider the ramifications to webifying per-seat licensed software (as only a single webguy user would ever consume a seat). Databases that charged per seat, version control systems that charged per seat, etc.. These tools had intricate designs to more than the number of licensed users to actually use a system, but have a max concurrent useage. Single-web-user violated all of that. And consequently, many of those software packages have changed their licensing model.
Commercial databases, now, for example, are charged based on the expected number of users that are likely to serve (what use to be individual login licenses). A realistic metric would be to have some vender-specific benchmark, where higher numbers mean higher throughput and thus greater concurrent usage == higher price. However, it turned out that the most politically correct way to do it was to assume that each CPU could simultaneously serve a separate person (even though it really has nothing to do w/ anything), and thus that was a reliable metric for scaled processing power.
Again, all it is is the ability to charge small companies less than larger companies. Oracle needs to recoup their investment dollars somehow; they simply don't sell enough volume to charge $39.95 per copy, so they have to look at the economic horizon.. The law of deminishing returns.. The higher the price, the lower the number of sales... If you are limited to a single price point, then there is exactly one spot at any given time that represents a maximization of profit (or minimization of loss). BUT, if you can charge more for people that are willing to pay more (essentially having multiple price-points), you dramatically increase the profitability.
Now the whole point is slowly becoming moot, as whenever there is a big industry of over-priced server software, there is a group willing to fund an open-source effort to match the functionality.
Well, I don't do a lot of GUI design.. Mostly HTML generation through servlets (or some other language structure).
From that, most of my code is layered separately between UI and application. In fact all HTML generation comes from JSP pages.. And even more, most of the HTML in that is segregated stle-sheets + JSP2.0-tag files (not to be confused w/ jsp-includes). And further, the basic framework of a JSP page is built from a sitemesh template (opensymphony.org). which means the content jsp page literally has the most trivial boiler-plate HTML, and body tags.. Just about everything else is abstracted from the content page.. As a result a JSP content page for me (the center-piece of a web page) is only a series of tag-imports, http-request fetches, and invocations of some tag-widgets.
If I wanted to abstract it one step further, really the JSP page itself is just a customizeble orientation of widgets (like the awt GUI widgets). I could use an XML file to represent what widgets are used in what fashion.. (Of course the complexity of how many of the widgets are used probably means this isn't practical). But to some degree, I've used XML descriptions of java beans to define how those beans should be rendered (mapping bean names to widget types and also associating i18n key names all in one place).
The positive is that I have well formed XML-like structured html, very small components which deal only with the relevent task.. The negative is that these tools aren't very standard (jsp2.0 tag files are very new and I rarely ever see people use them, etc). Thus there is a serious learning curve to anyone that I hand the project over to.
The big advantage is I've separated concerns.. The date-time widget is fully self-contained and represents how to render a form field and associated java-script popups necessary to have a full user experience.. As well as tieing in the associated help messages. There is a minimal coupling.. The widget conforms to an application-specific API of field-descriptive data. The content jsp page adheres to this same API and knows of the particular types of widgets, but knows nothing about the content itself. The application (spring-MVC, struts, webwork, etc) cares only about acquiring and processing certain specific pieces of data, and handing them off to the appropriate processing layers (which in tern only care about their relevant dependencies).
To do the same thing in AWT, you'd need the equivalent of templateable/style-sheetable forms. You could use factories and mutators configured through IoC. This allows the entity which wants the functionality of a frame to delegate the rendering to someone else.
I've always been frustrated that I haven't found an XML description language for java GUIs.
Other posters have explained this better than I, and the links will as well I'm sure.
But the idea is that in spring/pico/nanno/etc the configuration description is a deployment issue, not an application issue.. It's like editing/etc/X11/xorg.conf. By merely twiddling fields in a sample xml-configuration, you can dramatically alter what the entire product does. Mixing and matching sorters, data-repositories, inter-process communication tools, etc. It also allows a trivially easy way of mixing matching default values.. Is the default a simple string or a JNDI-looked up value, or the result of calling some factory object. You can easily switch between these forms of configuration by adjusting the spring.xml file.
And as for generating a stock/base/initial spring.xml file, there are xdoclet tools that will build them.
Then on the other extreme, you groups AOP w/ spring+hibernate.. evil evil man.
I find myself in the situation that when I move on to bigger and more profitable projects, my legacy code gets taken over by outsourced Indian groups, and the shere number of buzz words involved is enough to make their heads explode I should think.
Dependency injection has NOTHING to do w/ weak or strict type-safety (and, in fact, a concrete class is not required at all.. reflective interface handlers often can facilitate service needs). And if you use dyna-beans, then neither the producer or consumer ever even need an interface.
Your example shows the exact flaw in coding that Inversion of Control (through setter/constructor injection) solves.
Namely that you explicitly had to configure your dependencies. Yes, due to weak-types in such languages you could take almost any arbitrary code and plug it in to fullfill the server.. The fact still remains your code explicitly configured it.
The idea of Inversion of Control is that the thing that needs a service should NEVER configure that service. It's the law of demiter. If I want to use some thing, I shouldn't need to know that it in turn uses something else. If I have to configure both the thing that I want to use AND the thing that it wants to use, then eventually all my code is convoluted (doing and configuring crap that has nothing to do with what I'm actually trying to do).
If you simply take a step back and have something that uses the service configure the service, you'd still have to point some code to the thing that configured the service, so you're just moving the problem around (which is what your example does).
Inversion of control allows you to define the entire application modularly where each module only cares about capabilities of external modules (not their configurations nor their nested dependencies). In your example, the type-weak language merely requires the positional arguments to be compatible (which, I agree is a very powerful thing.. Perl's "grep", "map" and "sort" commands are incredible). In java, it would require an explicit class (interface or conctrete).
When you build your application this way, and you generalize your inter-component communication as genericly as possible (yes perl,ruby,python can much more easily genralize a service), then you can plug pieces together that were never originally meant to work together.
Another very important aspect of IoC is that you can easily test each piece separately, as instead of an application-confired container, you have a testing-configured container which performs appropriate configurations suitable for testing and unit-isolation.
With setter and constructor injection and through the use of interfaces, you facilitate mocking of 3'rd party services such that you completely skip all the complexity of side components and focuses very specificly on what a single component is doing.. You can test 'what would this module do if it's dependency returned something unexpected'.
If you have a perl module that internally uses some other class, how could you easily test interaction with the other class (say a IO::File). Typically you create test files. But what about when it's a database or a web site.. Your unit tests get more and more complicated. Especially if what the module is doing has is really independent of the fact that it's using a URL or database.
If instead the module was fully configured externally (no default configuration w/ zero-arg constructors or default package global variables), then you would be assured that you have full control over the environment of the module in question.
Thanks to these types of interactions, the power of object-orientation can be exploited while at the same time using singletons (essentially context-specific global variables; an otherwise anti-pattern). This has a trade-off of faster execution time at the cost of a higher memory usage and slower startup time. The fact that IoC usually has a non-neglegable setup time often means that we lean towards singletons (which has implications on code design).
Finally, the code you showed is fine for alternating configurations.. And for small tasks, the overhead of IoC is simply not justified. IoC really comes into it's own in very large p
I don't see how you missed the part where I talked about consolidated languages in java.. My foremer company specifically ported VBScript TO java so we didn't have to work in that god-awful VB environment natively.. We kept all our legacy crap in VBScript, and did all new development in Java/JSP. We used an emulation of the COM-API to transfer data back and forth between the two environments..
A VM has nothing to do with the language on top of it. Python, Java and.Net all have byte-code mock-assembly VMs. They happen to more easily decompile back into their native language (no idea about.NET), but the multitude of available alternative languages is more than enough to second guess your comment.
Except that iPod Photo is to iTune download like Hard drive is to MS Windows license.
MS would like to think that they can tax hard drives (and in many cases have done so successfully).. But the idea is that the HD is more versitile.
iPod photo does pod-casts, and videos.. There are cheap products which legally let you rip DVDs and put them on your iPod.
60G iPod is a GREAT USB drive, since unlike my book-bag, I almost always have my iPod w/ me (and trust me, I have a bookbag w/ me almost everywhere).
The concept of anti-correlated economic goods is always an interesting topic. People making more money means LESS people shop at walmart or buy potatoes. Here, making a more versitle iPod means less people use their trade store.
Personally I was shocked when iPod made the photo.. They swore up and down that they were only going to make AAC-based products.. And frustratingly I understood why. No radio, no games, no PDA.. These all distract from the big money maker focus. My wife, for example, got a blackberry.. You know what she does on it all day long? Play solitaire.. No phone calls, no PDA PIM data. Just solitaire. Same concept.
That being said, I'm sure Q1-06 will be a high revenue period for the music industry when all those gift cards are cashed in.
The only real question here is whether Apple makes money on the iPod or not. Often device makers sell their hardware at a discount so they can entice people into the lucrative long-term software titles (console games is the most prevalent here). If Apple is only breaking even w/ iPod sales, then this is truely bad news for them.. Otherwise, go suck it music industry.
Re:Interpreted Versus Compiled
on
Java Is So 90s
·
· Score: 4, Interesting
I'll grant that Java requires a significant learning curve.. But not for people that have been initiated into the computer-science field.. Java was specifically meant to have a low-learning curve... For EXISTING programmers of the langauges of it's day.. C, C++, and friends.
But this is a misnomer.. Take a person off the street and teach him a "hello world" program in python or basic.. He'll say "Wow, I'm a programmer now!!".
Then ask him to synchronize two credit card databases of different structures with it. Ops, learning curve!
It's a damn-simple thing to do, but you needed to learn an API, and a bunch of underlying concepts first.
Same thing with java.. It is designed rigidly so that the programmer can make assumptions that make their life easier. You have to explicitly manage errors for one.. Doing so means whenever you change the form of data, you are forced to think about it to make sure that the data has exchanged correctly. In Python, perl, numbers become strings become floats become triggers based on how you tickle the data (not necessarily access). These are simply two different assumptions about the significance of the data. If I wanted to have refactor a perl object definition (say change a method name), it would be damn near impossible to do. I couldn't just perform a text-search for the method name because it would probably overlap w/ other methods that had similar names.. But in Java, that rigidity means I can clearly know exactly who uses this exact method.
If you're writing small apps and your definitions are distinct enough this isn't a problem.. But in my 15 years of programming, I've had to do a lot of refactoring, and in c or perl-type languages, I almost always resorted to work-arounds instead of true data-migration; as it just wasn't worth it.
I perfectly agree w/ KISS.. But Simple and concise are not the same thing... Perl/Python/Ruby provides conciseness (saying a lot with a little), but at the expense of convoluted code (your rails project has the name of a method mean several different things). Java provides preciseness (and of course the ability to shoot yourself in the foot by being non simple, non-concise and non-precise). You are able to be concise in Java if you make use of rails-like-APIs.. Essentially modularize/aspectize your code so that the complexity is held elsewhere to define a type of work.. Then you concisely write the core of your application. Hibernate + xdoclet or attributes provides an example of this.. EJB provides a means of isolation of units-of-work in a way that is scaleable, clusterable, and safe all at once.. (Not that I ever use EJBs directly; but there are plenty of EJB-like services). This is not to say that RAILS can't be made similarly.. But to my knowledge you are still choosing a particular framework, and don't have a lot of flexibilty to alter those large units-of-work outside of the original author's inception.
I've regularly hooked together many open-source units-of-work in ways that I'd never seen done before, and Java has always made this not only easy, but reliable (providing thread-safe, classloader independent, order-of-execution-safe, work-flows out of the box). Of course almost all of my units of work live inside of a serlvet engine.. Rolling your own main means that your mileage may vary.
The link you provided is more or less marketing sugar. I've not directly used.NET (as I boycott MS products), but have written a few.mono one-offs to test the water.
What I do understand of.NET is that is is exactly a rip-off of Java. Essentially defining a byte-code JVM, but not directly specifying a compileable language. C#, VB.NET and others being mere compileable front-ends.. But in that respect beanshell, groovy and jpython are exactly comparable to VB.NET as alternate syntax languages. JSP is pretty close except that it often compiles to intermediate java files.. But the net effect is virtually the same.
Yes MS will provide full fledged IDE's for each of their languages, so you'll have 1'st tier support for them. And yes, there is an impeedence matching that needs to occur between a type of programmer and a language (VB , or VBScript potentially being more suited to non-programmer types) so you do want a plethora of syntaxes. COBOL.NET anyone?
The real question is whether there is something fundamentally new that.NET provides. The next real question is whether the experience of end-users facilitates the adoption of one over the other..
Fundamentally I see no advantage of.NET over the JVM. The syntax of both languages are co-evolving. The API support is mere circumstantial as APIs come and go as standard practices (URL supplants File. JDBC/ODBC supplants File. XPath supplants reg-ex, characterset/Locale supplants String, ResourceBundles supplant config-files, etc.).
Java's main stay is Linux support. Secondarily cross-platform support. (As I would say most java applications run on linux so the cross-platform aspect is in fact of secondary interest)..NET's main stay is that RAD tools as would be used in MS Office products will utilize it. I see a lot of business types that learned a little excel and think they're the shiz-nick (still operating on a decentralized model along w/ all the synchronization problems that come; email being the main communication/versioning tool). Those that can "glue" together two Office documents using VBA.NET will be the hero of the executive suite. Thus facilitating that is a desireable goal both at MS and 3'rd parties. Thus.NET is more directly tied to lucrative revenue and has greater potential.
Java is a back-end tool used by server-types (and a scant few client-apps), so gets less coverage.. And thus could be defunded by organizations.. It has greater risks.
My conclusion is that w/ the exception of cross-platform and existing tool-sets that support MS-Office, it's primarily a form-over-function argument.
Re:Java programmers are more expensive
on
Java Is So 90s
·
· Score: 1
Others' have already mentioned jakarta.apache.org.. Name one thing that doesn't have a free open-source API in either perl or java. apache.org, sourceforge, java.net, opensymphony, jboss-group, codeweaver.. The list goes on and on over VERY well supported capability group networks.
Who cares about open-source applications. We want them all written in raw c w/ highly optimized, impossible to read code that only geniouses can tinker with. I want "ls", "grep", "awk", "pine", and "X" running under highly optimized dangerous but stable code.. These are things I use, and don't want 3'rd parties putting their muddy fingers in.
But when I code business-rules (for billing, cell-phone routing, email generation, etc), I want something adaptive, clean, reliable, flexible and open.. Perl's great for hacked apps or glue, but Java bar-none for the business rules. When you're writing business rules, you don't want hacked together applications, you want clean APIs that have been well tested, but can be opened up so you can w/ zero concern determine precisely the use-cases of each method or class.
Nicely organized perl CPAN stuff is great, usually very well thought out, but a lot of it are thin wrappers around c-libraries, and are thus subject to all sorts of deployment problems. "php" and other ASP-style programing languages are horrific in terms of code-coverage and structure. It's very hard to run analysis tools on your application to determine what is used where, how, and how-often. Refactoring is a nightmare.
Again, for one off "scripts" that are inter-machine accessible, php is great, and easier to use than a perl cgi (including apache mod_perl). If you want to connect data between two core applications or perform some filter, they're fine. But applications that make decisions that affect peoples lives scare me when they're hacked together w/ impedence mismatched parts.
The key thing to remember is that a truly private company has a direct incentive to make things cost-effectively.
You miss the whole point.. In a truely private "industry".. There is competition for consumers.. Each corporation MUST minimize costs, as that's the only way to maximize profit (technology, timing, etc help but are less reliabile). But the eact opposite is true of ANY government contract job. That "industry" works by a completely differnet set of rules. Yes there is competition, but only for the initial bid.. After that, there is a trick called "cost ovrerruns". The government will pay ALL over-runs, because they're in it too deep.. They can't afford to back out and switch to a competator.
Imagine being a software programing and KNOWING that your boss can't fire you, but pays you by the hour.. How long is that bug going to take to fix?
The incentives are completely out of wack. The gov-contract-industry is supposed to correctly estimate how cheaply they can do something.. Then their goal is to ahead-of-time estimate every innacurancy in the government-contract plan.. Each gov-err in their specification will require a renegotiation of the price, and almost always at a hansome profit for the contractor.. So the contractor that can find the most flaws in the specification knows they can reduce their estimatd bid the most, and ultimately turn the highest profit.
Then, when the contract is being fullfilled, the company has trade-offs.. Money-based trade-offs.. At any given point, they can choose to do something money-efficiently or not.. The determining factor is whether the gov will pick up the tab for the extra cost or not. And if the contractor can get the service done for cheaper than they know the government can track, all the better.
The end result is that the project will DEFINITELY cost more than anoter space shuttle mission the 1'st couple times; look at all the libability coverage; they can't just go out there with untested stuff. (NASA could, but a private firm couldn't).
In the long run, space industry has to be purely based on a high-volume consumer demanded, competatively offered industry.. Otherwise, somebody is getting the shaft.
Hell, it stands on more known TANGIBLE historical data than quantum physics (or evolution, for that matter).
Be careful w/ the word tangible. The bible is as tangible as my morning oat meal. But the words on it are too smooth to really feel. What the bible is is basically a natural-science Journal of authors long dead and editors alive and very well. It represents a form of "common sense" (which is historically considered an insult) of do's and don'ts for "God, the World, and You". But this is about as relevant as a similar book written by Dr Phil. Both have very charismatic roots, and make sense to the common man. But would you go to war over something that Dr Phil said in a book? Many Muslims would, and historically, many Christians have (namely the divine authority of the Pope).
So why is teaching creationism or ID unscientific? Because it's about as useful as teaching about Santa Clause to encourage the idea that children should be good all year and force their parents to be consumers during Christmas time. You'd likely find greater ethical value in encouraging biblical beliefs, but it's the same thing. There is no basis for following the arbitrary doctrine of Santa Clause, and likewise the Doctrine of any of the THOUSANDS of Christian denominatinos in the US. I'm sure that you would be offended if we arbitrarily decided to read from the Koran to school across the country because there was some "common sense" wisdom emparted by a couple phrases.
Science is (as most side posters have stated) a validatable system. ID and creationism are inherently the opposite (faith based).. But modern empirical evidence shows that you absolutely can not trust religious figureheads.. Maybe their ideas, or those common to a majority of them, but individuals have time and time again shown to have mislead their flock, and been personally corrupted by the fame and power afforded to them. And the problem is that the Bible was written over a thousand years.. So nobody has inherent understanding of the poetry recited in each epoc.. You NEED scholars in the field to interpret the texts for you. But each of the Modern Christian religions is polluted w/ 2 thousand years of political corruption w/in the competing powers that were.. Rome was the greatest polluter of the Christian lineage. Virtually all of the non Jewish dates that are celebrated in modern Christianity are perversions injected by Rome and their aftermath (most noteably Sunday as the day of worship.. Look it up some time, no apostle ever worshiped on Sunday). The books that were chosen to be included as the new testiment themselves were perverted due to the agenda of the people of the day.. Not that there were any more truthful books that really should have been included, but that there was so much crack-pot writing, that it was decietful to suggest that those books that presented an agenda were divinely significant. The reality was that there were many competing philosophies post Jesus. Many having completely incompatible messages for how you should live your life. Look at the Egnostics as one small example; they were systematically erradicated.
I do not claim that the Bible and that creationism is not valid, correct, historically accurate or even devine.. I claim that it is founded on completely reprehensible Scientific principles. Unreproduceable, pollitically filtered, post-event documented (in many cases 30 to 100 years later). If this is what we're trying to teach our children, then we will fall even further behind the rest of the world w/ our children.
If and when the atoms "collapse", the reaction will be endothermic, not exothermic - you'll cool the surrounding matter, not cook it.
I'm speaking out my ass here, because I don't know what is involved beyond the high-level article and these slash posts.. But If a system could produce an unstable sub-ground-state in these "hydrinos", then this is a very good thing that they "collapse" endothermicly. Think of it as an energy sponge.
Place unstablely cold hydrinos into a luke-warm environment; cooling that environment. Then enact the magical black-box process to extract that energy. If the exothermic portion is hot enough, and the endothermic portion is cold enough, you have a tremendously efficient heat-exchanger.
Take a fission reactor. If the endothermic reaction was significant enough, you could use the hydrino fluid as one of the cooling stages. You could sap energy efficiently from low-level heat of geothermic events.
I have no idea of the dynamics of this system, but my point was merely that an endothermic side-effect is quite possibly a very good thing.
The consequence of this is that, at runtime, an ArrrayList of integers is indistinguishable from an ArrayList of strings.
Except that you can't extract the contents of List as a string w/o down-casting the ArrayList to "List".
While the hidden assertion below is only syntactic convinience: List foo = findFooList(); int x = foo.get(0);
The following is very powerful: interface FooManager { Out getX(In in); }
Often trivial interface code allows for the lack of type-safety and a proliferation of run-time-errors-in-the-making.
So: class MyComparator implements Predicate
{
int someParam; MyComparator(int p) { this.someParam=p; }
public boolean evaluate(P p)
{
return p.isValueTrue(someParam);
} }
class Foo {
Predicate myPredicate;
public void setPredicate(Predicate myPredicate)
{ this.myPredicate = myPreciate; }... }
If you enforce generics, produce compiler-warnings when generics aren't utilizied, or have an editor which can specify that user-defined generics are not being utilized, then the above code is much more type-safe. Foo can be extended beyond MyPredicate, it doesn't even need to extend or even be aware of MyPredicate to be used by Foo, yet it's much more runtime safe then by just allowing a non-generified "Comparator". Now if only java1.5 standard library defined Predicate. I used jakarta's commons-collections and friends, but as of this time they aren't generified so I've literally had to roll my own; but that's the bueaty of open-source APIs.
That makes GC cache-hostile. I agree, except that a good generational copier shouldn't traverse beyond the most recently allocated memory.. Even as freshly allocated-and-not-yet-released memory exceeds the nursury size it merely gets lumped into the next generation.. This means that it won't even be looked at for many dozens or hundreds of garbage collects.
It is only when that particular generation gets refreshed (because that generation is too full to accept the previously younger generations over-spill) that it's memory pages will be touched.
By putting all the reference handles in a tight continugous space, you also reduce the "touching" of too many pages for the purposes of GC analysis.
Compared to an allocator slab alloc/free, you have two possibilities: external referencing where a tight continuous space of free-pointer/size data-structures lives (memory handles) and the untouched pages of heap-space, or inlined linked-lists of free an allocated allocation chunks. In the case of inlined, then the process of walking a map on a single alloc and or free is likely to do similar degrees of damage as a minor GC to the CPU cache. If, for example, you use a "best-fit" algorithm, or even a buddy-system, you're going to dance around a non-trivial number of pages that are highly likely to not be in the cache (because they weren't directly in use by the application, and have statistical randomness as to where the traversals take them).
And don't forget the extreme overhead of compactification. Buddy systems aren't too bad (though I haven't worked closely w/ them), but fitting algorithms can be pretty bad.
I would agree however that in practice, I've seen more swaps of death from competing java processes than from any other architecture system.
America is more than anti-science. American culture in the broadest terms has become very anti-intellectual, which is really a super-set of being anti-science.
It's actually pretty obvious what happened. The US was the underdog and had to work extra hard to make it's place in the world.. We had the advantage of natural resources and geographic isolation from waring neighbors. There were some major world wars which devistated the former world-kings. And as arms dealers during those wars, the US accumulated all the wealth for those wars. The combination of blood-money and the need for hyper-industrialization (directly fed by the blood-money) meant that post WWII, we were in a prime position to be the economic basis for the world. We had greater naval world-wide presence than the UK by the end of WWII (the previous century's benchmark for economic might).
The continued war effort post WWII meant a great economic stimulous in research and development well into the 80's for the US.
Then something happened. The WWII work-horse retired.. And the wealthy hiers took the throne.
It is common for the children of self-made men to fail. The difference between nobility and neuveous-riche is that old-money comes w/ generations of class, style, and upbringing.. Such that even if you came onto economic hard-ships, you'd still have a manner in which to bring your children up that would be to their benifit.. The neuveous-riche, on the other hand represents an immature/undisciplined life-style. While a person can command self discipline, this doesn't mean they have the knowledge or capability of raising a child to become just as successful. Knowing and teaching are totally independent attributes.
Thus successive generations from the WWII American era have grown further and further from our successful period of excellence. Science which was new, subsidized, exciting and over-promising was now just a lot of hard work. Oh, and don't forget, we're rich now... We have video games, TV, exciting cars, excellent looking women and other social objectives. We're a society catered to via consumerism (customer is always right). We're a society sold to for conviniences (my every inconvenience can be convenienced by spending another dollar).
How then can this same society harbor this paradox.. Live for conveninence/excitement, but suffer for details. Children have no paradox.. Screw school; school is a social platform. Teenagers have no paradox, screw homework; art/passion/self-expression is a way-of-life. 20-somethings have no paradox. Self-righteousness coupled w/ an already glossy/forgotten education represents some specific endeavor that will make money and get those long-sought-after toys. 30-somethings don't have a paradox.. They're already parents, and envolved w/ the joys of pampering their newborns w/ the same destructive cycle.
My personal injection into mathematics/science had a lot to do with the fact that I wasn't distracted as a youth by social entanglements.. Moreover I was socially rejected, so even if I wanted social interaction it wasn't available (though I'm sure if I took better care of my personal appearance, my life would have turned out radically differently (for the worse I'm sure)). It was the fact that I could devote hours at a time to mathematics that I was able to learn it.. And at each stage of development I wasn't behind, so when new topics were presented, I could obsorb them in the context of my prior knowledge, as opposed to others would never fully learned past material and merely looked at the new material as expected frustrations of lacking comprehension, eventual forgetting of test material and ultimately irrelevance of the topic all together (I'm going to be a dancer, so why do I care about electrons and protons????)
I had my flounderings in college, being cought up in the do-it-yourself linux craze (plus video games and eventually girls; oh the years I'd waited for them). So I found myself in the same situation in college that I'd scof
If you want to think God did some stuff, go for it. Knock yourself out, man.
I can't believe nobody has mentioned the obvious yet.
We went to war w/ Afghanistan on one principle.. Forget 9/11.. We were in negotiations w/ the Taliban for the relase of Bin Laden; We could easily have invaded just those camps.. The Taliban could not possibly have stopped us.. No.. We dismantled the Taliban on one stated premise: That they were rejecting modern logic and science for an ancient self-involved religion. It was our moral duty to dismantle this oppressive regeme.
How then can this same group of American believers reject science in favor of an even more ancient religion? Because they are hypocrits.. They don't care that the Taliban rejects modern society, modern freedoms, and modern science.. No.. They are offended that they reject Ancient Christianity.
And as the point, most Christianity and some sects of Judaism are no different than fundamentalist Islam.. And should be treated by enlighted people no less harshly.
Scoff or be offended if you will (I speak to the general audience, not the parent author), reflect on your feeling of distaste when we see religious stagnancy in the taliban (distroying all ancient artifacts and works of greatness that do not promote the glory of Allah as told by an epileptic war monger named Mohammud). But reflect on the compulsion to turn back the clock of the past 100 years by re-injecting ancient debates of cosmic philosphy (the natural sciences).
Science is about empirical evidence.. Religion is only RECENTLY defined in terms on non-empirical evidence.. Once apon a time, religion was ONLY defined by the presence of very visible "miracles".. To a pesant, a mirical was as much proof as one could ever hope for as to a validation to a philosophy (namely the bullshit that this guy talks about is more believable because he can walk on water). Now we don't witness miricals, but instead put them in movies, or call them "everyday miricals".. We don't witness them, because we have a more expansive world-view.. Being able to read the accumulated wisdom of most of history prevents us from being dazzeled by magician parlor tricks.. Thus we don't place added weight to whatever philosophy they expouse. We look at them as entertainers and nothing more.
Modern religion is nothing like ancient religion. The fact that 230 years ago we as a nation could unanimously declare that religion wasn't necessary as the foundation of a government was an incredible step.. Government necessitated a moral basis in days of old.. The divine right of Kings, the divine lineage of pharos' emperors, etc.
I believe it was hobbes that spoke of the clean-slate of a new born child.. There is no God in a new born.. It is burned into the child by the parents and more importantly, the peers. We are in an anti-empiracal period of religion. God has not made his presence known for the past 1,500 years (Mohammud being the last major proclaimed profit). The only "experience" we have left w/ religion is that of legends retold. And how hard can it be to believe that a story retold over 5,000 years has gone unembellsihed.. And with each new chapter in the story, you must outdo the legends of the past. Surely a consistent God would not go absent for 40% of the entire span of human existence; relying on story telling and a proveably corrupt religious institution to imprint the legend.
My point in this late-night rant is that allowing a resurgence of experience-lacking "faith" to turn back the clock of progress is regretable at best.
It is irrelevant whether Darwin is on the right track or not.. Science doesn't care.. It is based purely on reproducable evidence and logical/mathmatical models that reliably predict as-yet-unexperienced events. If survival of the fittest or even Lamarks self-directed genetic mutation can demonstrate reliable predictions then to Hell w/ God. Quite directly meaning that the topic of God must manifest itself in some human experience fo
Excellent response.. Except for the modern version of closet religion. I on occasion find myself in this same situation; Religion is ok for a personal perversion, but I don't dare defend or expouse it. But this is perverse to Religions' very nature. To have a personal religion is like having a personal war. War is meant to affect others', religion is about expansive coersive community (it is at the heart of what is morality, and moral imperitives).
Again, I perfectly empathise with your position. But I feel compelled to bring out the very important distinction in our modern times that Religion is not something that can be shelved like a book that you might some day get to.
While you can indeed ignore it most of your life, then suddently find it when you're sick and elderly, this is an affront to the very notion of the sacred.
I struggle with this from time to time in my life.. Bouncing back and forth between Egnostic, atheistic, harshly-critical of spirituality, and back to submissive spirituality. I feel personally flawed by this fact. Pleasing no entity, and rather offending all. But don't hold the delusion that spirituatility is quietly maintained. As Pascal might argue, God's existence necessitates a certain culpability.. If he exists and you weren't fervently on his side, then you will ultimately be judged against him.
My favorite croud displeaser is the "Jesus is either Mad, Bad or God" debate. While we'd like to think of our religious basis as a set of good ideas, ultimately the roots of religion were either devine or destructive. The "good parts" of religion are often quantifiable in science, and the social sciences often have a harsh perspective on how to act most socially morally.
My most hated modern comment is that the US was based off Judao-Christian laws, which is as far from the truth as possible. The three closest laws are "don't kill", "don't steal" and "don't lie". But you can lawfully take what isn't yours via law-suites, you can lie so long as not to a grand jury, and you can kill so long as the state has sanctioned it. No other cultural law exists (even religious holidays have been sacrified to the modern Gods of prosperity).
I too was brought up Catholic, and find it hard to reconcile my in-built instincts w/ modern society.. What makes it easy is that my aged father has taken the extreme religious position; clearly defining the stagnant past w/ the modern.
As a warning.. To whatever degree you find spirituality seductive, such as a santa-clause style upbringing for your children (e.g. an external entity providing direction, discipline, morality, safe monoculturalism), be aware of the limitations.. The limitations of your own personal faith, and the narrow-mindedness necessary to subjigate yourself and your family.
I'm not discouraging, but more prostelitising the accountability necessary for such a willful choice in life-style.
First I noticed that some of my code was cut-off due to less-thans.. bugger.
Thanks to the foresite of java 1.0, the need for generics has not existed until only recently
In what manner? I haven't seen any benefits besides the lack of a need now to cast.
Well, I admit that Java 1.5 generics was a more of a show than a real implementation. The only thing it does is generate really wierd exceptions when you pull from a generalized class. For example.
List foo = new ArrayList(); foo.add(null); List bar = foo; int 5 = bar.get(0);
I've scratched my head on that one. Hibernate can return List but contain a single row w/ a null.. So I have to perform if (foo == null || foo.get(0) == null) { return 0; } return ((Integer)foo.get(0));
The Collections class has lots of type-checkers, but they ONLY work if you are the one that instantes the collections.. I haven't found any 3'rd party tools which do post-facto validation of type-safety in a collection. I've had to roll my own.
Other than this specific issue w/ accessing external libraries, I really love the type-safety enforcement w/in my own internal libraries thanks to generics.
Something that was severely lacking in C++ (due to multi-inheretance)
Multiple inheritance shouldn't have anything to do with it.
Shouldn't, but due to performance, does. Perl makes use of hierarchical arrays of package names to implement MI. This can be an analysis nightmare as you have to know the order in which the super-classes were defined (in a subclass) in order to determine which conflicting super method will be invoked. It's also a performance nightmare. Method calls become linear nested traversals of array-lists. Additionally most implementations of OO in Perl make use of a hash-map.. Essentially all fields are virtual (potentially conflicting between alternate class definitions).
In C++ you have to fiddle w/ virtual inheretance and can't make arbitrary inheretance.. If you get a 3'rd party library, it's possible that you physically can't composite multiple classes (due to collisions and lack of declared virtual inheretance). The requirement to declare a method as virtual is both a positive and negative.. Great for explicit definition of an OO heirarchy, horrible for extending classes beyond what the original author conceived (e.g. 3'rd party libraries). I don't recall if C++ has the equivalent of Java's final modifier.. I've found it to be incredibly frustrating (in terms of preventing prevention of code-reuse). In Java "final" is useless except on 1'st class objects like "String" which have JVM optimizations. A good JVM can determine the "final" attribute at runtime based on whether anything actually overloads the method or not. In C++ such an optimization isn't possible, so there is a serious performance advantage to not declaring a method as virtual. It's the difference between a c-style direct function call and an indirection-table lookup (or two).
In Java, MI is ommited purely for OO elegance. Thanks to heavy use of interfaces (and runtime optimizations of interfaces into static method invocations where possible) you get all the advantages of MI w/ none of the complexities and limitations. The ONLY thing MI provides (and you correctly pointed out) is the lack of code-reuse. BUT, this is actually a blessing in disguise. Take the following example:
class BaseWebPage {
Foo utilityA(...);
Bar utilityB(...);
abstract void drawPage(...); }
OO here is purely for utilitarian purposes. But how about class PageA {
UtilityA utilityA; void setUtilityA(UtilityA ua) { utilityA = ua; }
UtilityB utilityB; void setUtilityB(UtilityB ub) { utilityB = ub; }
void drawPage(...) { utilityA.doA(...); utilityB.doB(...); } }
This latter code is MORE OO than the foremore. Here you can swap out what utility A actually is.
Um, except for the whole operator part. Operators are pure syntactic sugar. There are an enormous number of meta-languages around java; bean-sh, groovy and others which alter the syntactic sugar. Moreoever, Java has demonstrated that best-practices eventually get syntactic sugar enhancements in later versions. Look at auto-boxing, for example. Integer bar(..) {.. } int foo(..) { return bar(..); } int Integer are auto converted as pure syntactic sugar. So now Map map; map.put(1 + map.get(key)); is feasible (increment value in map). To favor your point and disfavor mine, "toString" IS an operator in Java.. Namely it overloads the "+" symbol. Integer i; Bar b; String s; File f; return s + i + b + f; This is syntactic sugar for: return new StringBuffer().append(s).append(i).append(b.toStri ng()).append(f.toString()).toString(); Probably just calls toString on s and i as well; it's compiler specific. --- The point is that operators are visual queues.. They can be nice, but they have to be balanced against abuse. Java specifically looked at the level of operator overloading available to C++ and decided against them, with the one exception of defining the plus operator. No, then there'd be a method called add. Again, syntactic sugar. Functionally identical. The two forms of operation are dramatically different: printf("[%i]\n", val); cout.print(val.toString()); But the latter is functionally identical to "cout I sure as heck would like to be able to say a + b instead of a.add(b), especially as the latter to me seems more like a += b than returning the sum without a side effect. Agreed. Java isn't very consistent in it's core API method naming conventions. map.add(.) mutates the object which stringBuffer.add(.) returns an immutable value-object. This is SUNs fault and hasn't been corrected yet. Though Java-Bean specification does a very nice job of this with get/set prefixes though "verb" methods are a mixed bag. Same w/ any language. You can't write an equivalent to printf in Java because you can't have a variable length parameter list. Sorry, dated. System.out.printf("[%i,%s]\n",var1, var2); has worked since verion 1.5. In fact you have an i18n version: Locale l; System.out.printf(l, "%i", var); You now have a much more powerful version of the "..." parameter.. Namely type safe: void foo(Integer... args) void bar(Foo... arrgs) PLUS the multi-parameter autoboxes arrays, multi-parameters, and collections. Integer[] ints; foo(ints); foo(1,2,new Integer(3)); Set sints; foo(sints); all works just fine. std::max class Util {
public static Number max(Comparable... comparables)
{
if (comparables == null || comparables.length == 0)
{ throw new InvalidArgumentException("empty set"); }
Comparable maxComparable = comparables[0];
for (Comparable c : comparables)
{
if (maxComparable.compareTo(c) > 0) { maxComparable = c; }
}
return maxComparable;
} Done! And thanks to auto-boxing, works with ALL primitives.. And even if it didn't.. If you were doing this in Java 1.4 Util.max(new Character(c1), new Character(c2)); Thanks to the foresite of java 1.0, the need for generics has not existed until only recently.. And that was only for type-safety, not for generalization.. Namely all collections take generic Objects.. Something that was severely lacking in C++ (due to multi-inheretance). Any specific capabilities use interfaces or interface markers (like clone or serializable). Moreo
Difference is in handling 3'rd party libraries.. You have have the most talented C programmers in the world, but if you use a 3'rd party driver that didn't properly check fro null malloc, you're FUBAR.. Especially if you thought you could trust this 3'rd party.
Presumably this is less of an issue for C++ since you have exception handling. But if you were writing a web server in C or C++ how could you garuntee that the entire web server wouldn't crash when a developer imported code which caused a CORE dump.
In Java or even perl, you just wrap the outermost invocation w/ try {... } catch (Throwable t) { LOG.error("bad worker", e); }.
This is an incredibly powerful statement. I'm saying I don't care what you did, I'm starting from fresh on the next web page load. It's almost declaritive. To a small degree you can do this in C++ (except for derefing null pointers).
If you were designing an OS, would you seriously blame the stability of your system on bad 3'rd party programmers? Oh wait, MS does this!!!!!
No, you make it so that it's impossible for the programmer to make your system look bad. In UNIX a bad program can at worst slow the machine down, but even then, a sys-admin can limit it's damage in the future (ulimit, etc). The "UNIX" API was designed by incredibly intelligent programmers, as you advocate all applications should be written by. But most applications are collections of unwieldy libraries, since we want to facilitate modular code reuse (don't reinvent the wheel every time, or we'll never get past the 70's software wise). Ideally each application module would live in a separate execution environment where they can't cause damage, but this isn't practical (yet). The best we have today is RPC/CORBA/COM, SOAP, HTTP. At least in these environments you can make a network call, and handle the error message anyway you like. Thus you have the ability to be crash-resistent.
Of course making an RPC call in C for every string-filtering function-call is insane, so we'd prefer to have some language level assurance.
Programmers have lost sight of eloquence; tell me, why are you programming something in 100 megs when it could take, umm, A FEW HUNDRED KILOBYTES.
Are modern programmers (myself included....) so bad that we need literally hundreds of megabytes of overhead to protect our dumb ass's from ourselves? Are we so out of touch with the machines we proclaim dominance over (or at least a good working relationship with) that we need to abstract ourselves 838,860,800 Bits away from our machines?
This is a legitimate question.. The answer is that because anything can pass in "c" for code, it is impossible to validate and anylize the code correctly.. The best you can do is use heuristics. If you have, say a pointer to a function being passed around, and god forbid that you convert it to a void (sym void) or whatever the proper syntax was (I forget).. Then your analysis tools can not extend beyond that point.
Perl and other symbolic languages have the same problem. C++ is a little better, but you can still write C code in C++, so the tool isn't fool proof.
Why do I care? Because of the refactoring capabilities of modern programming IDE's. (Eclipse/Idea). I can perform a "safe delete" on a function or variable because the code can be anylized and determine precisely if anybody actually uses it (though reflection/aspected/bytecode-modification does put a tiny wrinkle on that). As a backup, to handle reflective invocations which would cause run-time failure, I can extend the usage-search to include strings in xml files or JSP files. Granted, this doesn't resolve dynamically constructed field names '"get" + methodName'. Renaming classes, renaming methods, renaming variables, fields, etc, are important for refactoring and the migration of code. When you work on large collaborative environments you have two options.. Maintain backward compatibility (explicitly defining cut-off points), or refactoring all code that touches your API. W/ refactoring tools, this is a mouse-click away.
Moreover, my IDE can tell me if code is garunteed to generate a null pointer.. If nothing in the associated libraries can possibly return a null pointer (determined by literally searching for all sub-classes found in any 3'rd party library and anylizing their byte-code), then the editor knows that an immediate dereference after acquiring a value from a method call is safe.. If not, my IDE highlights the line as a probable error. That is absolutely impossible in a c/binary set of external libraries. Especially shared libraries.
Now it's technically possible to deploy a Java application w/ a different set of libraries (especially if up upgrade those libraries after compilation), so it's not fool proof. But if you're interfacing w/ 3'rd party libraries you should probably have a rudimentary set of parameter/result validation code. But w/in your own library this technique is very powerful.
Another incredibly useful tool is hack-removal.. Packages should minimize inter-package communication (and thereby inter-package dependency). W/ Analysis tools you can graphically determine the degree of inter-package relationship. And on a case by case basis determine if the design should be refactorered to remove the reference/dependency/etc. Ideally you shouldn't have bi-directional dependency. As you're coding, it's entirely likely that you'll make these bidirectional associations out of convinience or lack of consideration. But a post-facto code analysis is instrumental in weeding out these bad design issues.
While this is possible to a certain degree in C, and a larger degree in C++, it is hard to do, and I've found few tools that do this in a reasonable manner. "source_navigator" by RedHat was ok, but wasn't very easy to use (at least w/ my editors of choice).
The key is that "it compiles ship it" is less of a joke in Java than almost any other language. And THIS is why companies make use of Java for enterprise applications.
Slashdot Mirror
Internet sales has been treated like mail-order for a long while. The standard there has been, you collect sales tax for residents of states/counties in which you have an office.. It's a decent compromise because if you set up shop, then you already have to deal w/ employment taxation in that region, so knowing the laws in that region is not as burdensome.
I don't recall, however, whether it is the billing address or the shipping address that is used for calculation.
This idea of universal region tax collection is just ludicrous for the same reasons it never flew for mail-order.
If billing is collected based on shipment address, what about web services that have NO shipment address! What about purchases made through pay-pal? Other than through eBay/etc, there is NO associated shipment address, and in fact no billing address (you just have an email address). If I purchase software online, I don't provide a billing address. What state is my taxation from?
Try downloading a ringtone sold by sprint on a verizion phone. It doesn't work. Not because the song isn't compatible but because they will put up money road blocks into the way to force you to pay.
Just as an FYI.. I happen to work in the cell phone content industry. The reasons you can't easily purchase the same content on different phones is manifold. And only 25% of it has to do with billing limitations. Every cell phone is it's own universe, and could care less about the standards used by other cell phone companies. Then throw in the fact that cell phone makers are another layer of complexity in terms of what protocols they support. Then add the many types of billing models that cell phone companies employ (pay-as-you-go v.s. monthly bill). Then take the fact that cell phone companies change their protocols on average twice a year.
As a content provider, the liability is such that it is best to simply exclude phones that physically support the particular piece of content, but have one of the many pieces of the puzzle missing. The probability of a user ultimately not figuring out how to get the data correctly is too high and thus the probability of wasting money on a tech-support-call makes that sale not worth it.
There are 10's of thousands of phone combinations out there (ignore the latent US).
The software and network industry use to be like this. Lots of choice, really hard to provide across-the-board solutions. This recognition causes people to flock to the perceived winner like mad birds. So if there is an internet firm that manages to demonstrate cost effective models for content production, you had better believe that the entire producer industry will migrate in that direction. Consumer choice be damned.
For better or worse.
Does the overhead of a GUI system justify losing it in favor of administrating via a CLI?
Others' have posted properly things that would answer this.. I will add the following. A server's service is something that needs three things: an environment sufficient to complete it's task, a point of configuration, and a point of monitoring.
Presumably the configuration and monitoring are independent aspects of the operation of a service. Thus in an ideal application, the environment requirements are independent of those of the configuration and monitoring.
Whether a UNIX dot-file, a windows bracketed ".ini" file, a windows-registry, a java RMI remote configuration, or a database is used, the mechanism by which you administer those settings is still independent.
The simplest fashion in which you have have a service provide administrative and monitoring is a web service.. There is zero need for a custom GUI client. The rendering of HTML and the processing of HTTP headers is so trivial that you almost never require external libraries to facilitate it. There are c, java and perl libraries that make it a no-brainer.
Unreal Tournament, for example uses a web service as the administrative interface to configure a UT server. Most routers or even printers these days have built in web servers.
The only problem is that each service would require having a separate server port.. Which I admit is a non trivial thing to reconcile..
Aggregated environments like tomcat or jBoss in the java world make it easy to plug a server into an environment.. In both environments you dynamically add/remove services in a central web GUI.
The idea is that you legitimately can charge people based on their ability to pay. A small company gets the service much cheaper than a larger company because there are fewer seats.
Economicly there's nothing wrong with it.. A larger company can afford to pay more for the same service that a smaller company can; you're just normally allowed to discrimiate pricing.
Another justification is that w/ client-installed software, you can charge per seat.. But w/ server software there is only ever one seat.. Imagine if MS office could be installed as a web service.. There would literally only ever be a single copy of web-MS-office ever sold.. One guy with a big server and a public grant would install it, and the world could use it for free...
When http 1'st become popular, companies I worked for seriously had to consider the ramifications to webifying per-seat licensed software (as only a single webguy user would ever consume a seat). Databases that charged per seat, version control systems that charged per seat, etc.. These tools had intricate designs to more than the number of licensed users to actually use a system, but have a max concurrent useage. Single-web-user violated all of that. And consequently, many of those software packages have changed their licensing model.
Commercial databases, now, for example, are charged based on the expected number of users that are likely to serve (what use to be individual login licenses). A realistic metric would be to have some vender-specific benchmark, where higher numbers mean higher throughput and thus greater concurrent usage == higher price. However, it turned out that the most politically correct way to do it was to assume that each CPU could simultaneously serve a separate person (even though it really has nothing to do w/ anything), and thus that was a reliable metric for scaled processing power.
Again, all it is is the ability to charge small companies less than larger companies. Oracle needs to recoup their investment dollars somehow; they simply don't sell enough volume to charge $39.95 per copy, so they have to look at the economic horizon.. The law of deminishing returns.. The higher the price, the lower the number of sales... If you are limited to a single price point, then there is exactly one spot at any given time that represents a maximization of profit (or minimization of loss). BUT, if you can charge more for people that are willing to pay more (essentially having multiple price-points), you dramatically increase the profitability.
Now the whole point is slowly becoming moot, as whenever there is a big industry of over-priced server software, there is a group willing to fund an open-source effort to match the functionality.
Well, I don't do a lot of GUI design.. Mostly HTML generation through servlets (or some other language structure).
From that, most of my code is layered separately between UI and application. In fact all HTML generation comes from JSP pages.. And even more, most of the HTML in that is segregated stle-sheets + JSP2.0-tag files (not to be confused w/ jsp-includes). And further, the basic framework of a JSP page is built from a sitemesh template (opensymphony.org). which means the content jsp page literally has the most trivial boiler-plate HTML, and body tags.. Just about everything else is abstracted from the content page.. As a result a JSP content page for me (the center-piece of a web page) is only a series of tag-imports, http-request fetches, and invocations of some tag-widgets.
If I wanted to abstract it one step further, really the JSP page itself is just a customizeble orientation of widgets (like the awt GUI widgets). I could use an XML file to represent what widgets are used in what fashion.. (Of course the complexity of how many of the widgets are used probably means this isn't practical). But to some degree, I've used XML descriptions of java beans to define how those beans should be rendered (mapping bean names to widget types and also associating i18n key names all in one place).
The positive is that I have well formed XML-like structured html, very small components which deal only with the relevent task.. The negative is that these tools aren't very standard (jsp2.0 tag files are very new and I rarely ever see people use them, etc). Thus there is a serious learning curve to anyone that I hand the project over to.
The big advantage is I've separated concerns.. The date-time widget is fully self-contained and represents how to render a form field and associated java-script popups necessary to have a full user experience.. As well as tieing in the associated help messages. There is a minimal coupling.. The widget conforms to an application-specific API of field-descriptive data. The content jsp page adheres to this same API and knows of the particular types of widgets, but knows nothing about the content itself. The application (spring-MVC, struts, webwork, etc) cares only about acquiring and processing certain specific pieces of data, and handing them off to the appropriate processing layers (which in tern only care about their relevant dependencies).
To do the same thing in AWT, you'd need the equivalent of templateable/style-sheetable forms. You could use factories and mutators configured through IoC. This allows the entity which wants the functionality of a frame to delegate the rendering to someone else.
I've always been frustrated that I haven't found an XML description language for java GUIs.
Other posters have explained this better than I, and the links will as well I'm sure.
/etc/X11/xorg.conf. By merely twiddling fields in a sample xml-configuration, you can dramatically alter what the entire product does. Mixing and matching sorters, data-repositories, inter-process communication tools, etc. It also allows a trivially easy way of mixing matching default values.. Is the default a simple string or a JNDI-looked up value, or the result of calling some factory object. You can easily switch between these forms of configuration by adjusting the spring.xml file.
But the idea is that in spring/pico/nanno/etc the configuration description is a deployment issue, not an application issue.. It's like editing
And as for generating a stock/base/initial spring.xml file, there are xdoclet tools that will build them.
Aack.. You got me at both ends..
j2ee != jboss/websphere..
EJB == jboss/websphere.
j2ee incluedes servlets (tomcat), mail, encryption and transactions..
Then on the other extreme, you groups AOP w/ spring+hibernate.. evil evil man.
I find myself in the situation that when I move on to bigger and more profitable projects, my legacy code gets taken over by outsourced Indian groups, and the shere number of buzz words involved is enough to make their heads explode I should think.
I'm sorry, but you are incorrect.
Dependency injection has NOTHING to do w/ weak or strict type-safety (and, in fact, a concrete class is not required at all.. reflective interface handlers often can facilitate service needs). And if you use dyna-beans, then neither the producer or consumer ever even need an interface.
Your example shows the exact flaw in coding that Inversion of Control (through setter/constructor injection) solves.
Namely that you explicitly had to configure your dependencies. Yes, due to weak-types in such languages you could take almost any arbitrary code and plug it in to fullfill the server.. The fact still remains your code explicitly configured it.
The idea of Inversion of Control is that the thing that needs a service should NEVER configure that service. It's the law of demiter. If I want to use some thing, I shouldn't need to know that it in turn uses something else. If I have to configure both the thing that I want to use AND the thing that it wants to use, then eventually all my code is convoluted (doing and configuring crap that has nothing to do with what I'm actually trying to do).
If you simply take a step back and have something that uses the service configure the service, you'd still have to point some code to the thing that configured the service, so you're just moving the problem around (which is what your example does).
Inversion of control allows you to define the entire application modularly where each module only cares about capabilities of external modules (not their configurations nor their nested dependencies). In your example, the type-weak language merely requires the positional arguments to be compatible (which, I agree is a very powerful thing.. Perl's "grep", "map" and "sort" commands are incredible). In java, it would require an explicit class (interface or conctrete).
When you build your application this way, and you generalize your inter-component communication as genericly as possible (yes perl,ruby,python can much more easily genralize a service), then you can plug pieces together that were never originally meant to work together.
Another very important aspect of IoC is that you can easily test each piece separately, as instead of an application-confired container, you have a testing-configured container which performs appropriate configurations suitable for testing and unit-isolation.
With setter and constructor injection and through the use of interfaces, you facilitate mocking of 3'rd party services such that you completely skip all the complexity of side components and focuses very specificly on what a single component is doing.. You can test 'what would this module do if it's dependency returned something unexpected'.
If you have a perl module that internally uses some other class, how could you easily test interaction with the other class (say a IO::File). Typically you create test files. But what about when it's a database or a web site.. Your unit tests get more and more complicated. Especially if what the module is doing has is really independent of the fact that it's using a URL or database.
If instead the module was fully configured externally (no default configuration w/ zero-arg constructors or default package global variables), then you would be assured that you have full control over the environment of the module in question.
Thanks to these types of interactions, the power of object-orientation can be exploited while at the same time using singletons (essentially context-specific global variables; an otherwise anti-pattern). This has a trade-off of faster execution time at the cost of a higher memory usage and slower startup time. The fact that IoC usually has a non-neglegable setup time often means that we lean towards singletons (which has implications on code design).
Finally, the code you showed is fine for alternating configurations.. And for small tasks, the overhead of IoC is simply not justified. IoC really comes into it's own in very large p
With JVM, I am stuck with Java.
.Net all have byte-code mock-assembly VMs. They happen to more easily decompile back into their native language (no idea about .NET), but the multitude of available alternative languages is more than enough to second guess your comment.
I don't see how you missed the part where I talked about consolidated languages in java.. My foremer company specifically ported VBScript TO java so we didn't have to work in that god-awful VB environment natively.. We kept all our legacy crap in VBScript, and did all new development in Java/JSP. We used an emulation of the COM-API to transfer data back and forth between the two environments..
A VM has nothing to do with the language on top of it. Python, Java and
Except that iPod Photo is to iTune download like Hard drive is to MS Windows license.
MS would like to think that they can tax hard drives (and in many cases have done so successfully).. But the idea is that the HD is more versitile.
iPod photo does pod-casts, and videos.. There are cheap products which legally let you rip DVDs and put them on your iPod.
60G iPod is a GREAT USB drive, since unlike my book-bag, I almost always have my iPod w/ me (and trust me, I have a bookbag w/ me almost everywhere).
The concept of anti-correlated economic goods is always an interesting topic. People making more money means LESS people shop at walmart or buy potatoes. Here, making a more versitle iPod means less people use their trade store.
Personally I was shocked when iPod made the photo.. They swore up and down that they were only going to make AAC-based products.. And frustratingly I understood why. No radio, no games, no PDA.. These all distract from the big money maker focus. My wife, for example, got a blackberry.. You know what she does on it all day long? Play solitaire.. No phone calls, no PDA PIM data. Just solitaire. Same concept.
That being said, I'm sure Q1-06 will be a high revenue period for the music industry when all those gift cards are cashed in.
The only real question here is whether Apple makes money on the iPod or not. Often device makers sell their hardware at a discount so they can entice people into the lucrative long-term software titles (console games is the most prevalent here). If Apple is only breaking even w/ iPod sales, then this is truely bad news for them.. Otherwise, go suck it music industry.
I'll grant that Java requires a significant learning curve.. But not for people that have been initiated into the computer-science field.. Java was specifically meant to have a low-learning curve... For EXISTING programmers of the langauges of it's day.. C, C++, and friends.
But this is a misnomer.. Take a person off the street and teach him a "hello world" program in python or basic.. He'll say "Wow, I'm a programmer now!!".
Then ask him to synchronize two credit card databases of different structures with it. Ops, learning curve!
It's a damn-simple thing to do, but you needed to learn an API, and a bunch of underlying concepts first.
Same thing with java.. It is designed rigidly so that the programmer can make assumptions that make their life easier. You have to explicitly manage errors for one.. Doing so means whenever you change the form of data, you are forced to think about it to make sure that the data has exchanged correctly. In Python, perl, numbers become strings become floats become triggers based on how you tickle the data (not necessarily access). These are simply two different assumptions about the significance of the data. If I wanted to have refactor a perl object definition (say change a method name), it would be damn near impossible to do. I couldn't just perform a text-search for the method name because it would probably overlap w/ other methods that had similar names.. But in Java, that rigidity means I can clearly know exactly who uses this exact method.
If you're writing small apps and your definitions are distinct enough this isn't a problem.. But in my 15 years of programming, I've had to do a lot of refactoring, and in c or perl-type languages, I almost always resorted to work-arounds instead of true data-migration; as it just wasn't worth it.
I perfectly agree w/ KISS.. But Simple and concise are not the same thing... Perl/Python/Ruby provides conciseness (saying a lot with a little), but at the expense of convoluted code (your rails project has the name of a method mean several different things). Java provides preciseness (and of course the ability to shoot yourself in the foot by being non simple, non-concise and non-precise). You are able to be concise in Java if you make use of rails-like-APIs.. Essentially modularize/aspectize your code so that the complexity is held elsewhere to define a type of work.. Then you concisely write the core of your application. Hibernate + xdoclet or attributes provides an example of this.. EJB provides a means of isolation of units-of-work in a way that is scaleable, clusterable, and safe all at once.. (Not that I ever use EJBs directly; but there are plenty of EJB-like services). This is not to say that RAILS can't be made similarly.. But to my knowledge you are still choosing a particular framework, and don't have a lot of flexibilty to alter those large units-of-work outside of the original author's inception.
I've regularly hooked together many open-source units-of-work in ways that I'd never seen done before, and Java has always made this not only easy, but reliable (providing thread-safe, classloader independent, order-of-execution-safe, work-flows out of the box). Of course almost all of my units of work live inside of a serlvet engine.. Rolling your own main means that your mileage may vary.
The link you provided is more or less marketing sugar. I've not directly used .NET (as I boycott MS products), but have written a few .mono one-offs to test the water.
.NET is that is is exactly a rip-off of Java. Essentially defining a byte-code JVM, but not directly specifying a compileable language. C#, VB.NET and others being mere compileable front-ends.. But in that respect beanshell, groovy and jpython are exactly comparable to VB.NET as alternate syntax languages. JSP is pretty close except that it often compiles to intermediate java files.. But the net effect is virtually the same.
.NET provides. The next real question is whether the experience of end-users facilitates the adoption of one over the other..
.NET over the JVM. The syntax of both languages are co-evolving. The API support is mere circumstantial as APIs come and go as standard practices (URL supplants File. JDBC/ODBC supplants File. XPath supplants reg-ex, characterset/Locale supplants String, ResourceBundles supplant config-files, etc.).
.NET's main stay is that RAD tools as would be used in MS Office products will utilize it. I see a lot of business types that learned a little excel and think they're the shiz-nick (still operating on a decentralized model along w/ all the synchronization problems that come; email being the main communication/versioning tool). Those that can "glue" together two Office documents using VBA.NET will be the hero of the executive suite. Thus facilitating that is a desireable goal both at MS and 3'rd parties. Thus .NET is more directly tied to lucrative revenue and has greater potential.
What I do understand of
Yes MS will provide full fledged IDE's for each of their languages, so you'll have 1'st tier support for them. And yes, there is an impeedence matching that needs to occur between a type of programmer and a language (VB , or VBScript potentially being more suited to non-programmer types) so you do want a plethora of syntaxes. COBOL.NET anyone?
The real question is whether there is something fundamentally new that
Fundamentally I see no advantage of
Java's main stay is Linux support. Secondarily cross-platform support. (As I would say most java applications run on linux so the cross-platform aspect is in fact of secondary interest).
Java is a back-end tool used by server-types (and a scant few client-apps), so gets less coverage.. And thus could be defunded by organizations.. It has greater risks.
My conclusion is that w/ the exception of cross-platform and existing tool-sets that support MS-Office, it's primarily a form-over-function argument.
Others' have already mentioned jakarta.apache.org.. Name one thing that doesn't have a free open-source API in either perl or java. apache.org, sourceforge, java.net, opensymphony, jboss-group, codeweaver.. The list goes on and on over VERY well supported capability group networks.
Who cares about open-source applications. We want them all written in raw c w/ highly optimized, impossible to read code that only geniouses can tinker with. I want "ls", "grep", "awk", "pine", and "X" running under highly optimized dangerous but stable code.. These are things I use, and don't want 3'rd parties putting their muddy fingers in.
But when I code business-rules (for billing, cell-phone routing, email generation, etc), I want something adaptive, clean, reliable, flexible and open.. Perl's great for hacked apps or glue, but Java bar-none for the business rules. When you're writing business rules, you don't want hacked together applications, you want clean APIs that have been well tested, but can be opened up so you can w/ zero concern determine precisely the use-cases of each method or class.
Nicely organized perl CPAN stuff is great, usually very well thought out, but a lot of it are thin wrappers around c-libraries, and are thus subject to all sorts of deployment problems. "php" and other ASP-style programing languages are horrific in terms of code-coverage and structure. It's very hard to run analysis tools on your application to determine what is used where, how, and how-often. Refactoring is a nightmare.
Again, for one off "scripts" that are inter-machine accessible, php is great, and easier to use than a perl cgi (including apache mod_perl). If you want to connect data between two core applications or perform some filter, they're fine. But applications that make decisions that affect peoples lives scare me when they're hacked together w/ impedence mismatched parts.
The key thing to remember is that a truly private company has a direct incentive to make things cost-effectively.
You miss the whole point.. In a truely private "industry".. There is competition for consumers.. Each corporation MUST minimize costs, as that's the only way to maximize profit (technology, timing, etc help but are less reliabile). But the eact opposite is true of ANY government contract job. That "industry" works by a completely differnet set of rules. Yes there is competition, but only for the initial bid.. After that, there is a trick called "cost ovrerruns". The government will pay ALL over-runs, because they're in it too deep.. They can't afford to back out and switch to a competator.
Imagine being a software programing and KNOWING that your boss can't fire you, but pays you by the hour.. How long is that bug going to take to fix?
The incentives are completely out of wack. The gov-contract-industry is supposed to correctly estimate how cheaply they can do something.. Then their goal is to ahead-of-time estimate every innacurancy in the government-contract plan.. Each gov-err in their specification will require a renegotiation of the price, and almost always at a hansome profit for the contractor.. So the contractor that can find the most flaws in the specification knows they can reduce their estimatd bid the most, and ultimately turn the highest profit.
Then, when the contract is being fullfilled, the company has trade-offs.. Money-based trade-offs.. At any given point, they can choose to do something money-efficiently or not.. The determining factor is whether the gov will pick up the tab for the extra cost or not. And if the contractor can get the service done for cheaper than they know the government can track, all the better.
The end result is that the project will DEFINITELY cost more than anoter space shuttle mission the 1'st couple times; look at all the libability coverage; they can't just go out there with untested stuff. (NASA could, but a private firm couldn't).
In the long run, space industry has to be purely based on a high-volume consumer demanded, competatively offered industry.. Otherwise, somebody is getting the shaft.
Hell, it stands on more known TANGIBLE historical data than quantum physics (or evolution, for that matter).
Be careful w/ the word tangible. The bible is as tangible as my morning oat meal. But the words on it are too smooth to really feel. What the bible is is basically a natural-science Journal of authors long dead and editors alive and very well. It represents a form of "common sense" (which is historically considered an insult) of do's and don'ts for "God, the World, and You". But this is about as relevant as a similar book written by Dr Phil. Both have very charismatic roots, and make sense to the common man. But would you go to war over something that Dr Phil said in a book? Many Muslims would, and historically, many Christians have (namely the divine authority of the Pope).
So why is teaching creationism or ID unscientific? Because it's about as useful as teaching about Santa Clause to encourage the idea that children should be good all year and force their parents to be consumers during Christmas time. You'd likely find greater ethical value in encouraging biblical beliefs, but it's the same thing. There is no basis for following the arbitrary doctrine of Santa Clause, and likewise the Doctrine of any of the THOUSANDS of Christian denominatinos in the US. I'm sure that you would be offended if we arbitrarily decided to read from the Koran to school across the country because there was some "common sense" wisdom emparted by a couple phrases.
Science is (as most side posters have stated) a validatable system. ID and creationism are inherently the opposite (faith based).. But modern empirical evidence shows that you absolutely can not trust religious figureheads.. Maybe their ideas, or those common to a majority of them, but individuals have time and time again shown to have mislead their flock, and been personally corrupted by the fame and power afforded to them. And the problem is that the Bible was written over a thousand years.. So nobody has inherent understanding of the poetry recited in each epoc.. You NEED scholars in the field to interpret the texts for you. But each of the Modern Christian religions is polluted w/ 2 thousand years of political corruption w/in the competing powers that were.. Rome was the greatest polluter of the Christian lineage. Virtually all of the non Jewish dates that are celebrated in modern Christianity are perversions injected by Rome and their aftermath (most noteably Sunday as the day of worship.. Look it up some time, no apostle ever worshiped on Sunday). The books that were chosen to be included as the new testiment themselves were perverted due to the agenda of the people of the day.. Not that there were any more truthful books that really should have been included, but that there was so much crack-pot writing, that it was decietful to suggest that those books that presented an agenda were divinely significant. The reality was that there were many competing philosophies post Jesus. Many having completely incompatible messages for how you should live your life. Look at the Egnostics as one small example; they were systematically erradicated.
I do not claim that the Bible and that creationism is not valid, correct, historically accurate or even devine.. I claim that it is founded on completely reprehensible Scientific principles. Unreproduceable, pollitically filtered, post-event documented (in many cases 30 to 100 years later). If this is what we're trying to teach our children, then we will fall even further behind the rest of the world w/ our children.
If and when the atoms "collapse", the reaction will be endothermic, not exothermic - you'll cool the surrounding matter, not cook it.
I'm speaking out my ass here, because I don't know what is involved beyond the high-level article and these slash posts.. But If a system could produce an unstable sub-ground-state in these "hydrinos", then this is a very good thing that they "collapse" endothermicly. Think of it as an energy sponge.
Place unstablely cold hydrinos into a luke-warm environment; cooling that environment. Then enact the magical black-box process to extract that energy. If the exothermic portion is hot enough, and the endothermic portion is cold enough, you have a tremendously efficient heat-exchanger.
Take a fission reactor. If the endothermic reaction was significant enough, you could use the hydrino fluid as one of the cooling stages. You could sap energy efficiently from low-level heat of geothermic events.
I have no idea of the dynamics of this system, but my point was merely that an endothermic side-effect is quite possibly a very good thing.
Except that you can't extract the contents of List as a string w/o down-casting the ArrayList to "List".
While the hidden assertion below is only syntactic convinience:
List foo = findFooList();
int x = foo.get(0);
The following is very powerful:
interface FooManager { Out getX(In in); }
Often trivial interface code allows for the lack of type-safety and a proliferation of run-time-errors-in-the-making.
So:
class MyComparator implements Predicate
{
int someParam; MyComparator(int p) { this.someParam=p; }
public boolean evaluate(P p)
{
return p.isValueTrue(someParam);
}
}
class Foo
{
Predicate myPredicate;
public void setPredicate(Predicate myPredicate)
{ this.myPredicate = myPreciate; }
}
If you enforce generics, produce compiler-warnings when generics aren't utilizied, or have an editor which can specify that user-defined generics are not being utilized, then the above code is much more type-safe. Foo can be extended beyond MyPredicate, it doesn't even need to extend or even be aware of MyPredicate to be used by Foo, yet it's much more runtime safe then by just allowing a non-generified "Comparator". Now if only java1.5 standard library defined Predicate. I used jakarta's commons-collections and friends, but as of this time they aren't generified so I've literally had to roll my own; but that's the bueaty of open-source APIs.
That makes GC cache-hostile.
I agree, except that a good generational copier shouldn't traverse beyond the most recently allocated memory.. Even as freshly allocated-and-not-yet-released memory exceeds the nursury size it merely gets lumped into the next generation.. This means that it won't even be looked at for many dozens or hundreds of garbage collects.
It is only when that particular generation gets refreshed (because that generation is too full to accept the previously younger generations over-spill) that it's memory pages will be touched.
By putting all the reference handles in a tight continugous space, you also reduce the "touching" of too many pages for the purposes of GC analysis.
Compared to an allocator slab alloc/free, you have two possibilities: external referencing where a tight continuous space of free-pointer/size data-structures lives (memory handles) and the untouched pages of heap-space, or inlined linked-lists of free an allocated allocation chunks. In the case of inlined, then the process of walking a map on a single alloc and or free is likely to do similar degrees of damage as a minor GC to the CPU cache. If, for example, you use a "best-fit" algorithm, or even a buddy-system, you're going to dance around a non-trivial number of pages that are highly likely to not be in the cache (because they weren't directly in use by the application, and have statistical randomness as to where the traversals take them).
And don't forget the extreme overhead of compactification. Buddy systems aren't too bad (though I haven't worked closely w/ them), but fitting algorithms can be pretty bad.
I would agree however that in practice, I've seen more swaps of death from competing java processes than from any other architecture system.
America is more than anti-science. American culture in the broadest terms has become very anti-intellectual, which is really a super-set of being anti-science.
It's actually pretty obvious what happened. The US was the underdog and had to work extra hard to make it's place in the world.. We had the advantage of natural resources and geographic isolation from waring neighbors. There were some major world wars which devistated the former world-kings. And as arms dealers during those wars, the US accumulated all the wealth for those wars. The combination of blood-money and the need for hyper-industrialization (directly fed by the blood-money) meant that post WWII, we were in a prime position to be the economic basis for the world. We had greater naval world-wide presence than the UK by the end of WWII (the previous century's benchmark for economic might).
The continued war effort post WWII meant a great economic stimulous in research and development well into the 80's for the US.
Then something happened. The WWII work-horse retired.. And the wealthy hiers took the throne.
It is common for the children of self-made men to fail. The difference between nobility and neuveous-riche is that old-money comes w/ generations of class, style, and upbringing.. Such that even if you came onto economic hard-ships, you'd still have a manner in which to bring your children up that would be to their benifit.. The neuveous-riche, on the other hand represents an immature/undisciplined life-style. While a person can command self discipline, this doesn't mean they have the knowledge or capability of raising a child to become just as successful. Knowing and teaching are totally independent attributes.
Thus successive generations from the WWII American era have grown further and further from our successful period of excellence. Science which was new, subsidized, exciting and over-promising was now just a lot of hard work. Oh, and don't forget, we're rich now... We have video games, TV, exciting cars, excellent looking women and other social objectives. We're a society catered to via consumerism (customer is always right). We're a society sold to for conviniences (my every inconvenience can be convenienced by spending another dollar).
How then can this same society harbor this paradox.. Live for conveninence/excitement, but suffer for details. Children have no paradox.. Screw school; school is a social platform. Teenagers have no paradox, screw homework; art/passion/self-expression is a way-of-life. 20-somethings have no paradox. Self-righteousness coupled w/ an already glossy/forgotten education represents some specific endeavor that will make money and get those long-sought-after toys. 30-somethings don't have a paradox.. They're already parents, and envolved w/ the joys of pampering their newborns w/ the same destructive cycle.
My personal injection into mathematics/science had a lot to do with the fact that I wasn't distracted as a youth by social entanglements.. Moreover I was socially rejected, so even if I wanted social interaction it wasn't available (though I'm sure if I took better care of my personal appearance, my life would have turned out radically differently (for the worse I'm sure)). It was the fact that I could devote hours at a time to mathematics that I was able to learn it.. And at each stage of development I wasn't behind, so when new topics were presented, I could obsorb them in the context of my prior knowledge, as opposed to others would never fully learned past material and merely looked at the new material as expected frustrations of lacking comprehension, eventual forgetting of test material and ultimately irrelevance of the topic all together (I'm going to be a dancer, so why do I care about electrons and protons????)
I had my flounderings in college, being cought up in the do-it-yourself linux craze (plus video games and eventually girls; oh the years I'd waited for them). So I found myself in the same situation in college that I'd scof
If you want to think God did some stuff, go for it. Knock yourself out, man.
I can't believe nobody has mentioned the obvious yet.
We went to war w/ Afghanistan on one principle.. Forget 9/11.. We were in negotiations w/ the Taliban for the relase of Bin Laden; We could easily have invaded just those camps.. The Taliban could not possibly have stopped us.. No.. We dismantled the Taliban on one stated premise: That they were rejecting modern logic and science for an ancient self-involved religion. It was our moral duty to dismantle this oppressive regeme.
How then can this same group of American believers reject science in favor of an even more ancient religion? Because they are hypocrits.. They don't care that the Taliban rejects modern society, modern freedoms, and modern science.. No.. They are offended that they reject Ancient Christianity.
And as the point, most Christianity and some sects of Judaism are no different than fundamentalist Islam.. And should be treated by enlighted people no less harshly.
Scoff or be offended if you will (I speak to the general audience, not the parent author), reflect on your feeling of distaste when we see religious stagnancy in the taliban (distroying all ancient artifacts and works of greatness that do not promote the glory of Allah as told by an epileptic war monger named Mohammud). But reflect on the compulsion to turn back the clock of the past 100 years by re-injecting ancient debates of cosmic philosphy (the natural sciences).
Science is about empirical evidence.. Religion is only RECENTLY defined in terms on non-empirical evidence.. Once apon a time, religion was ONLY defined by the presence of very visible "miracles".. To a pesant, a mirical was as much proof as one could ever hope for as to a validation to a philosophy (namely the bullshit that this guy talks about is more believable because he can walk on water). Now we don't witness miricals, but instead put them in movies, or call them "everyday miricals".. We don't witness them, because we have a more expansive world-view.. Being able to read the accumulated wisdom of most of history prevents us from being dazzeled by magician parlor tricks.. Thus we don't place added weight to whatever philosophy they expouse. We look at them as entertainers and nothing more.
Modern religion is nothing like ancient religion. The fact that 230 years ago we as a nation could unanimously declare that religion wasn't necessary as the foundation of a government was an incredible step.. Government necessitated a moral basis in days of old.. The divine right of Kings, the divine lineage of pharos' emperors, etc.
I believe it was hobbes that spoke of the clean-slate of a new born child.. There is no God in a new born.. It is burned into the child by the parents and more importantly, the peers. We are in an anti-empiracal period of religion. God has not made his presence known for the past 1,500 years (Mohammud being the last major proclaimed profit). The only "experience" we have left w/ religion is that of legends retold. And how hard can it be to believe that a story retold over 5,000 years has gone unembellsihed.. And with each new chapter in the story, you must outdo the legends of the past. Surely a consistent God would not go absent for 40% of the entire span of human existence; relying on story telling and a proveably corrupt religious institution to imprint the legend.
My point in this late-night rant is that allowing a resurgence of experience-lacking "faith" to turn back the clock of progress is regretable at best.
It is irrelevant whether Darwin is on the right track or not.. Science doesn't care.. It is based purely on reproducable evidence and logical/mathmatical models that reliably predict as-yet-unexperienced events. If survival of the fittest or even Lamarks self-directed genetic mutation can demonstrate reliable predictions then to Hell w/ God. Quite directly meaning that the topic of God must manifest itself in some human experience fo
Excellent response.. Except for the modern version of closet religion. I on occasion find myself in this same situation; Religion is ok for a personal perversion, but I don't dare defend or expouse it. But this is perverse to Religions' very nature. To have a personal religion is like having a personal war. War is meant to affect others', religion is about expansive coersive community (it is at the heart of what is morality, and moral imperitives).
Again, I perfectly empathise with your position. But I feel compelled to bring out the very important distinction in our modern times that Religion is not something that can be shelved like a book that you might some day get to.
While you can indeed ignore it most of your life, then suddently find it when you're sick and elderly, this is an affront to the very notion of the sacred.
I struggle with this from time to time in my life.. Bouncing back and forth between Egnostic, atheistic, harshly-critical of spirituality, and back to submissive spirituality. I feel personally flawed by this fact. Pleasing no entity, and rather offending all. But don't hold the delusion that spirituatility is quietly maintained. As Pascal might argue, God's existence necessitates a certain culpability.. If he exists and you weren't fervently on his side, then you will ultimately be judged against him.
My favorite croud displeaser is the "Jesus is either Mad, Bad or God" debate. While we'd like to think of our religious basis as a set of good ideas, ultimately the roots of religion were either devine or destructive. The "good parts" of religion are often quantifiable in science, and the social sciences often have a harsh perspective on how to act most socially morally.
My most hated modern comment is that the US was based off Judao-Christian laws, which is as far from the truth as possible. The three closest laws are "don't kill", "don't steal" and "don't lie". But you can lawfully take what isn't yours via law-suites, you can lie so long as not to a grand jury, and you can kill so long as the state has sanctioned it. No other cultural law exists (even religious holidays have been sacrified to the modern Gods of prosperity).
I too was brought up Catholic, and find it hard to reconcile my in-built instincts w/ modern society.. What makes it easy is that my aged father has taken the extreme religious position; clearly defining the stagnant past w/ the modern.
As a warning.. To whatever degree you find spirituality seductive, such as a santa-clause style upbringing for your children (e.g. an external entity providing direction, discipline, morality, safe monoculturalism), be aware of the limitations.. The limitations of your own personal faith, and the narrow-mindedness necessary to subjigate yourself and your family.
I'm not discouraging, but more prostelitising the accountability necessary for such a willful choice in life-style.
First I noticed that some of my code was cut-off due to less-thans.. bugger.
Thanks to the foresite of java 1.0, the need for generics has not existed until only recently
In what manner? I haven't seen any benefits besides the lack of a need now to cast.
Well, I admit that Java 1.5 generics was a more of a show than a real implementation. The only thing it does is generate really wierd exceptions when you pull from a generalized class. For example.
List foo = new ArrayList();
foo.add(null);
List bar = foo;
int 5 = bar.get(0);
I've scratched my head on that one. Hibernate can return List but contain a single row w/ a null.. So I have to perform
if (foo == null || foo.get(0) == null) { return 0; }
return ((Integer)foo.get(0));
The Collections class has lots of type-checkers, but they ONLY work if you are the one that instantes the collections.. I haven't found any 3'rd party tools which do post-facto validation of type-safety in a collection. I've had to roll my own.
Other than this specific issue w/ accessing external libraries, I really love the type-safety enforcement w/in my own internal libraries thanks to generics.
Something that was severely lacking in C++ (due to multi-inheretance)
Multiple inheritance shouldn't have anything to do with it.
Shouldn't, but due to performance, does. Perl makes use of hierarchical arrays of package names to implement MI. This can be an analysis nightmare as you have to know the order in which the super-classes were defined (in a subclass) in order to determine which conflicting super method will be invoked. It's also a performance nightmare. Method calls become linear nested traversals of array-lists. Additionally most implementations of OO in Perl make use of a hash-map.. Essentially all fields are virtual (potentially conflicting between alternate class definitions).
In C++ you have to fiddle w/ virtual inheretance and can't make arbitrary inheretance.. If you get a 3'rd party library, it's possible that you physically can't composite multiple classes (due to collisions and lack of declared virtual inheretance). The requirement to declare a method as virtual is both a positive and negative.. Great for explicit definition of an OO heirarchy, horrible for extending classes beyond what the original author conceived (e.g. 3'rd party libraries). I don't recall if C++ has the equivalent of Java's final modifier.. I've found it to be incredibly frustrating (in terms of preventing prevention of code-reuse). In Java "final" is useless except on 1'st class objects like "String" which have JVM optimizations. A good JVM can determine the "final" attribute at runtime based on whether anything actually overloads the method or not. In C++ such an optimization isn't possible, so there is a serious performance advantage to not declaring a method as virtual. It's the difference between a c-style direct function call and an indirection-table lookup (or two).
In Java, MI is ommited purely for OO elegance. Thanks to heavy use of interfaces (and runtime optimizations of interfaces into static method invocations where possible) you get all the advantages of MI w/ none of the complexities and limitations. The ONLY thing MI provides (and you correctly pointed out) is the lack of code-reuse. BUT, this is actually a blessing in disguise. Take the following example:
class BaseWebPage
{
Foo utilityA(...);
Bar utilityB(...);
abstract void drawPage(...);
}
OO here is purely for utilitarian purposes. But how about
class PageA
{
UtilityA utilityA; void setUtilityA(UtilityA ua) { utilityA = ua; }
UtilityB utilityB; void setUtilityB(UtilityB ub) { utilityB = ub; }
void drawPage(...) { utilityA.doA(...); utilityB.doB(...); }
}
This latter code is MORE OO than the foremore. Here you can swap out what utility A actually is.
Um, except for the whole operator part. .. } ... args) ... arrgs) ... comparables)
Operators are pure syntactic sugar. There are an enormous number of meta-languages around java; bean-sh, groovy and others which alter the syntactic sugar.
Moreoever, Java has demonstrated that best-practices eventually get syntactic sugar enhancements in later versions.
Look at auto-boxing, for example.
Integer bar(..) {
int foo(..) { return bar(..); }
int Integer are auto converted as pure syntactic sugar.
So now
Map map;
map.put(1 + map.get(key));
is feasible (increment value in map).
To favor your point and disfavor mine, "toString" IS an operator in Java.. Namely it overloads the "+" symbol.
Integer i;
Bar b;
String s;
File f;
return s + i + b + f;
This is syntactic sugar for:
return new StringBuffer().append(s).append(i).append(b.toStri ng()).append(f.toString()).toString();
Probably just calls toString on s and i as well; it's compiler specific.
---
The point is that operators are visual queues.. They can be nice, but they have to be balanced against abuse.
Java specifically looked at the level of operator overloading available to C++ and decided against them, with the one exception of defining the plus operator.
No, then there'd be a method called add.
Again, syntactic sugar. Functionally identical. The two forms of operation are dramatically different:
printf("[%i]\n", val);
cout.print(val.toString());
But the latter is functionally identical to "cout I sure as heck would like to be able to say a + b instead of a.add(b), especially as the latter to me seems more like a += b than returning the sum without a side effect.
Agreed. Java isn't very consistent in it's core API method naming conventions. map.add(.) mutates the object which stringBuffer.add(.) returns an immutable value-object. This is SUNs fault and hasn't been corrected yet. Though Java-Bean specification does a very nice job of this with get/set prefixes though "verb" methods are a mixed bag. Same w/ any language.
You can't write an equivalent to printf in Java because you can't have a variable length parameter list.
Sorry, dated.
System.out.printf("[%i,%s]\n",var1, var2);
has worked since verion 1.5. In fact you have an i18n version:
Locale l;
System.out.printf(l, "%i", var);
You now have a much more powerful version of the "..." parameter.. Namely type safe:
void foo(Integer
void bar(Foo
PLUS the multi-parameter autoboxes arrays, multi-parameters, and collections.
Integer[] ints;
foo(ints);
foo(1,2,new Integer(3));
Set sints;
foo(sints);
all works just fine.
std::max
class Util
{
public static Number max(Comparable
{
if (comparables == null || comparables.length == 0)
{ throw new InvalidArgumentException("empty set"); }
Comparable maxComparable = comparables[0];
for (Comparable c : comparables)
{
if (maxComparable.compareTo(c) > 0) { maxComparable = c; }
}
return maxComparable;
}
Done! And thanks to auto-boxing, works with ALL primitives.. And even if it didn't.. If you were doing this in Java 1.4
Util.max(new Character(c1), new Character(c2));
Thanks to the foresite of java 1.0, the need for generics has not existed until only recently.. And that was only for type-safety, not for generalization.. Namely all collections take generic Objects.. Something that was severely lacking in C++ (due to multi-inheretance). Any specific capabilities use interfaces or interface markers (like clone or serializable).
Moreo
Difference is in handling 3'rd party libraries.. You have have the most talented C programmers in the world, but if you use a 3'rd party driver that didn't properly check fro null malloc, you're FUBAR.. Especially if you thought you could trust this 3'rd party.
... } catch (Throwable t) { LOG.error("bad worker", e); }.
Presumably this is less of an issue for C++ since you have exception handling. But if you were writing a web server in C or C++ how could you garuntee that the entire web server wouldn't crash when a developer imported code which caused a CORE dump.
In Java or even perl, you just wrap the outermost invocation w/ try {
This is an incredibly powerful statement. I'm saying I don't care what you did, I'm starting from fresh on the next web page load. It's almost declaritive. To a small degree you can do this in C++ (except for derefing null pointers).
If you were designing an OS, would you seriously blame the stability of your system on bad 3'rd party programmers? Oh wait, MS does this!!!!!
No, you make it so that it's impossible for the programmer to make your system look bad. In UNIX a bad program can at worst slow the machine down, but even then, a sys-admin can limit it's damage in the future (ulimit, etc). The "UNIX" API was designed by incredibly intelligent programmers, as you advocate all applications should be written by. But most applications are collections of unwieldy libraries, since we want to facilitate modular code reuse (don't reinvent the wheel every time, or we'll never get past the 70's software wise). Ideally each application module would live in a separate execution environment where they can't cause damage, but this isn't practical (yet). The best we have today is RPC/CORBA/COM, SOAP, HTTP. At least in these environments you can make a network call, and handle the error message anyway you like. Thus you have the ability to be crash-resistent.
Of course making an RPC call in C for every string-filtering function-call is insane, so we'd prefer to have some language level assurance.
Programmers have lost sight of eloquence; tell me, why are you programming something in 100 megs when it could take, umm, A FEW HUNDRED KILOBYTES.
Are modern programmers (myself included....) so bad that we need literally hundreds of megabytes of overhead to protect our dumb ass's from ourselves? Are we so out of touch with the machines we proclaim dominance over (or at least a good working relationship with) that we need to abstract ourselves 838,860,800 Bits away from our machines?
This is a legitimate question.. The answer is that because anything can pass in "c" for code, it is impossible to validate and anylize the code correctly.. The best you can do is use heuristics. If you have, say a pointer to a function being passed around, and god forbid that you convert it to a void (sym void) or whatever the proper syntax was (I forget).. Then your analysis tools can not extend beyond that point.
Perl and other symbolic languages have the same problem. C++ is a little better, but you can still write C code in C++, so the tool isn't fool proof.
Why do I care? Because of the refactoring capabilities of modern programming IDE's. (Eclipse/Idea). I can perform a "safe delete" on a function or variable because the code can be anylized and determine precisely if anybody actually uses it (though reflection/aspected/bytecode-modification does put a tiny wrinkle on that). As a backup, to handle reflective invocations which would cause run-time failure, I can extend the usage-search to include strings in xml files or JSP files. Granted, this doesn't resolve dynamically constructed field names '"get" + methodName'. Renaming classes, renaming methods, renaming variables, fields, etc, are important for refactoring and the migration of code. When you work on large collaborative environments you have two options.. Maintain backward compatibility (explicitly defining cut-off points), or refactoring all code that touches your API. W/ refactoring tools, this is a mouse-click away.
Moreover, my IDE can tell me if code is garunteed to generate a null pointer.. If nothing in the associated libraries can possibly return a null pointer (determined by literally searching for all sub-classes found in any 3'rd party library and anylizing their byte-code), then the editor knows that an immediate dereference after acquiring a value from a method call is safe.. If not, my IDE highlights the line as a probable error. That is absolutely impossible in a c/binary set of external libraries. Especially shared libraries.
Now it's technically possible to deploy a Java application w/ a different set of libraries (especially if up upgrade those libraries after compilation), so it's not fool proof. But if you're interfacing w/ 3'rd party libraries you should probably have a rudimentary set of parameter/result validation code. But w/in your own library this technique is very powerful.
Another incredibly useful tool is hack-removal.. Packages should minimize inter-package communication (and thereby inter-package dependency). W/ Analysis tools you can graphically determine the degree of inter-package relationship. And on a case by case basis determine if the design should be refactorered to remove the reference/dependency/etc. Ideally you shouldn't have bi-directional dependency. As you're coding, it's entirely likely that you'll make these bidirectional associations out of convinience or lack of consideration. But a post-facto code analysis is instrumental in weeding out these bad design issues.
While this is possible to a certain degree in C, and a larger degree in C++, it is hard to do, and I've found few tools that do this in a reasonable manner. "source_navigator" by RedHat was ok, but wasn't very easy to use (at least w/ my editors of choice).
The key is that "it compiles ship it" is less of a joke in Java than almost any other language. And THIS is why companies make use of Java for enterprise applications.