Slashdot Mirror
LAMP Grid Application Server, No More J2EE
An anonymous reader writes "Check out this blog entry in Loosely Coupled about ActiveGrid's new open source Grid Application Server based on the LAMP (Linux, Apache, MySQL, PHP/Python/Perl) stack. Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE."
so how about google cache:
: ww w.looselycoupled.com/blog/lc00aa00074.html+lc00aa0 0074.html&hl=en
http://66.102.9.104/search?q=cache:AXRoWhcH5UIJ
moo
Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE.
What the hell do you base that peice of tripe on? Why lets compare an incomplete system cobled together on top of PHP to a mature Java based solution which is currently being used in hundreds of thousands of enterprise sites daily throughout the world. Yeah, I can see how LAMP just kicks J2EE's ass on that one.
Seriously, overhype much?
Not provocative at all that. No. Not in the slightest.
I'm sure the flamewar that no doubt follows is merely a figment of our collective imaginations.
ooooooh! What does this button do? - DeeDee, Dexters Lab.
To summarize TFA:
"Here is a new application server, that is not really an application server, but that does not matter as noone really needs an application server"
- Frist psot
Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE."
Thats like me saying, "Not to offend you, but check out goatse.cx!"
ITS JUST NOT POSSIBLE TO HAVE IT BOTH WAYS!
time is a perception of a being's consciousness
time is your 6th sense, the wierd ones are 7+
Could not RTFA ... site is jammed...
But I guess to each his own. Only time will tell which architecture was worth its own salt.
Meanwhile, I do confess that I have more experience with a LAMP stack, which IMHO is easier to install and develop on.
Your Opinion Will Vary
So you are basically saying: Throw more hardware at an inherently slow platform (LAMP) than to use highly optimized J2EE-servers with s state-of-the-art hotspot compiler?
Seriously, is the flame war the new source if income? I mean, it sure increases the number of banner views. Let's report on a new emacs-version, citing it as "far less potent than the newer VI. also notepad K1CK$ aSS".
Slashdotters help me with this; on the right I have an over-engineered J2EE with a dozen of work arounds that are over hyped like EJB facades and dozens of frameworks that are difficult to learn and slow (..and kinky, every one and their mom developed a framework), and there are no free (as in beer) quality servers (I know JBoss but good luck without the documentation), on the extreme left I have LAMP, a loosely coupled system, PHP is popular but lets admit it is an ugly hack just looking at PHP5 reconfirms my believe that PHP didn't handle it fast growth properly, in the middle there is Microsoft which I hate and don't want to consider., I want a decent middle ware, that is cross platform, fast, and well documented, free as in beer (and preferably as in speech also).
Some muppet posts a blog and immediately hundreds of millions of dollars investment and countless man hours of work on a mature, strongly adopted platform become irrevelevant. This is pure flamebait.
The only thing this indicates to me is that Grid/LAMP is going to struggle to gain acceptance in the enterprise because it proponents are idiots.
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
For the majority of enterprise projects I've worked on, we wouldn't event consider a platform that didn't perform Two Phase Commits (MySQL) nor supported distributed transactions. This stuff still has a long way to go before it's to be taken seriously.
Can you use Postgres instead of MySQL in LAMP, without extreme pain?
--
Wiki de Ciencia Ficcion y Fantasia
Not to start another PHP vs. Java flame war, but it looks like LAMP is starting to grow up, and that it is much better suited for next generation applications than J2EE
(emphasis mine)
Remember, folks, Java is more than just J2EE and J2EE is only a part of Java. There are many enterprise applications written without the cancer that is J2EE. There a great number of alternative frameworks for building enterprise applications.
Personally, I feel that J2EE justifies itself because the bloat of a J2EE server means you have to have multiple instances to support an equivalent load a non-J2EE solution could handle on a single server.
Works in that you can build slashdot on it OR in the sense of building enterprise applications?
"I think this line is mostly filler"
What in the hell do these two have to do with each other?
Before any liberals are tempted to mod up one of my comments, a word of warning: I'm actually making fun of you.
are we going to win this one too? Just like we have with the War on Terrorism, War on Drugs, etc.
Hope they don't run this on a LAMP server...
w w.looselycoupled.com/blog/lc00aa00074.html+&hl=en& lr=&strip=1
Anyway, here is TFA:
http://66.102.9.104/search?q=cache:AXRoWhcH5UIJ:w
first: i'm not a coward... ;)
;)
;)
I'm miojo (at) javafree.com.br
second: Is this blog hosted at a LAMP suite? Because I'm not getting the site openned here in my browser...
where is the scalability ?
BTW, i'm a Java/J2EE programmer...
"Of course, calling its platform an application server is something of a marketing ploy since, as Peter has explained, an application server is the last thing you need. What ActiveGrid is really providing is a highly tuned "text pump" to occupy the fabric/bus space in a transaction-intensive enterprise data center."
"I think this line is mostly filler"
I tried every online translator I could, however the article still comes out as absolute gibberish.
What with the concurrent text pump synergies, next languages, impedance mismatches and grid quantum antipolarity trilithium subspace continuums, I got a bit lost.
Anyone understand what they're peddling?
Classical Liberalism: All your base are belong to you.
...but doesn't it seem a little silly to base computational applications on what is essentially a glorified webserver? Sure, use LAMP for your shopping cart, but enterprise applications are more than just shopping carts.
.NET applications were never designed with grids in mind" - well, I can't speak for .NET, but J2EE is designed for clustering and distribution. Have you seen EJBs? EJBs are designed for interaction across computers.
"There is no impedance mismatch, everything talks SOAP/HTTP" - well, yes, that's great, but you shouldn't be talking SOAP/HTTP internally. There are faster means of communication, so use them.
"Apparently what is needed is a language/environment that is loosely typed in order to encapsulate XML well and that can efficiently process text" - only on input and output. In intermediary stages, you should be using a much more efficient format. If you're doing something clever, it's going to involve much more than just plain old text.
"J2EE and
RTFA and you'll see that LAMP is being pushed for "text-pumping". Why aren't they saying it's any good for anything else? Because it most likely isn't.
Like car accidents, most hardware problems are due to driver error.
But with any scripting language, you have to run the application to catch even trivial bugs like misspelled methods and incorrect argument types.
I'm sure scripting languages have their place, but I've NEVER written a large script, without eventually wishing that I'd originally used a strict language. Scripts are great for fast turnaround, but only if you don't mind chasing trivial bugs that a compiler should have caught. I want a language that's tighter than a straightjacket.
but Emacs kicks the crap out of vi...
-G
Ok, I had already spent a modpoint in this topic, but I realized it is better to speak up to defend your position than to stand on the sides and give out points to "your" team.
Article is Slashdotted, so I can't comment on the content, but just to reply to some of the posts that will defenitely come up, because they ALWAYS come up when Java is discussed-
EJB are bloated etc:
J2EE is does NOT equal Enterprise Javabeans. J2EE contains classes for lots of things. XML processing, messages, web servers, database connectivity, etc. You don't have to use EJB. Lots of Java developers don't like EJB because they are too cumbersome, and there are plenty of alternatives. Check out for instance O'Reillys recent book Better, Faster, Lighter Java.
Java is slow:
Startup time for the JVM is still slow yes. This rarely matters for a web/application server. When it comes to running, it is plenty enough.
It isn't open source:
So what. It's close enough.
Ok, that over with, was this darn topic necessary? I like both LAMP and Java. They have their uses, why did the poster and the article have to turn this into a confrontation?
Being bitter is drinking poison and hoping someone else will die
Do you need all those EJBs? What for? In some environments it makes sense to use EJBs but in most Servlet Container + POJOs is a better and simpler way to go, IMO.
Consider replacing your EJBs with POJOs. Should not be a difficult task.
Check out this blog entry in Loosely Coupled about ActiveGrid's new open source Grid Application Server based on the LAMP (Linux, Apache, MySQL, PHP/Python/Perl) stack.
I love marketing hype like this.
One sure sign of marketing hype is to quote a venture capitalist on technology. That's why we all don't own a Segway, despite its claimed "future".
Second of all, a technical paper shouldn't be based around a press release that quotes the same venture capitalist. Not too many technologists will take that seriously.
Next, don't bring the NetDynamics CTO near me. Maybe he's a good guy and all, but in my experience, NetDynamics was one fucked up product. And this was before AND after Sun gobbled them up. It was like the Marketeers and Experimentationalists got into it, forgot that it was supposed to be an enterprise product, and screwed it to hell.
Finally, a combination of Perl, PHP, and Python for a complicated enterprise app isn't going to win any awards - damn, how many specialists does one need?
Finally, I'm not going to be running my payroll on a core of MySQL, PHP, Python, and Perl. And which version of Apache? 1.3 or 2.0? Perl 6? Why isn't ksh in there?
I love people that seamingly have ZERO large, enterprise-class application experience telling those who do how to do it.
While I like Java, I have never been the greatest fan of J2EE for web applications, it's just over engineered.
.NET, and we know what platforms, or rather platform, that is supported on. The added bonus in that case is that it is dead easy to create a web application accessing the same systems. Try that with LAMP!
But J2EE does more than just web apps. It's strength is being a business application server with Swing GUI front-end, the only competition in that field is
A fairer comparison would be LAMP and JSP/JDBC pure web apps. In which case in terms of number of instalations LAMP will always win because JSP doesn't play well in the $6.95/month massive multihosting game. But for business users, this is a moot point.
There you have it. Enjoy.
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
Use Lisp. Seriously. It's one of the oldest languages out there, but it has features that other languages can only dream of (in fact, when other languages improve, they almost invariably get closer to Lisp).
The language is well-documented. Implementations range from simple interpreters to complex, optimizing compilers (they are on par with C, and sometimes outperform it). It has packages for many purposes, enough to implement Yahoo! Store at any rate.
People complain about the parentheses (some say LISP is short for Lots of Irritating Superfluous Parentheses). That's a valid point. In C syntax, at least there's variation. Besides parentheses there are curly braces, straight brackets, commas, semicolons, etc. Seriously, the parentheses make for a very simple and consistent syntax.
Lisp allows you to program in whichever paradigm suits you best (pick the right one for the task at hand). Functional, object oriented, imperative, it's all there. It's macro system is so powerful it lets you basically generate programs, rather than writing them. Add garbage collection, higher order functions, dynamic typing (although static typing can be used for performance), arbitrary precision arithmetic (integers are not limited to 32 bits), multiple inheritance, and tail call optimization (recursion in constant space), and you have a language that blows all others out of the water.
Why does nobody use it? Fear, uncertainty and doubt. People think it died with AI. People think its old, so it won't be up to modern tasks. People can't get over the parentheses. The boss won't approve it. Nobody else uses it, so it's hard to get support. Any number of reasons.
Please correct me if I got my facts wrong.
Substitute Postgres or whatever to taste, but that just fucks up a perfectly good acronym, so we'll pretend MySQL is a placeholder for $REAL_DATABASE of your choice.
Opportunity knocks. Karma hunts you down.
(nt stands for no-text)
I just got myself some new asbestos underwear. Of course LAMP is better suited for next-generation applications than Java.
And your karma whoring panties I see.
Why "of course"?
Am I alone in wondering exactly what a "next-generation application" is anyway?
What qualities or requirements define a "next-generation application", other than it not having been developed yet?
Anyhow, it was my take on the article that the use of 'P' languages was incidental, it was the grid concept and the horizontal scaling. The 'P' languages just happen to be part of a readily available set of tools for implementing this idea.
"Not to start a flamewar, but you java developpers are a foul smelling, foul tasting bunch!"
Ummm, last time I saw that I called it development.
The reason for using an OO language is to get you to work with objects and encapsulation. There's a really good reason to do any large enterprise level application using objects. That is that the app is being designed to last longer than one year. That means that during it's life back-end systems are going to change, customer requirements are going to change, and new requirements are going to be introduced.
If you haven't properly separated out all of the portions of your code then when they come back and say "can you give us these two functions running on PDA's?" you're gonna be SOL.
(I spent a year building a system and they promised to transition one of the back-end systems to a whole new platform by the end of the job. They never succeeded but we developed against the old system and the new so it didn't slow us down one bit. THAT'S why you take the time to do OO work.)
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
Why don't we have the good guys here at /. find some enterprising J2EE coders to redo /. as a J2EE application. If it takes more servers to run the J2EE app then LAMP wins. If it takes less servers to run the new /. then J2EE wins. End of discussion.
There are all sorts of "flawed" technologies that win in the marketplace over aesthetically superior rivals.
The question would be:
Is the PHP solution such a sufficient improvement that IT shops world wide will throw away millions of hours of J2EE training, development, and maintenance in order to satisfy the purists?
I seriously doubt it. How many more ways do you need to solve the same problem?
Yeah? Well I think you're overrated too.
I didn't even know there was a PHP and Java flamewar going on! Where do I enlist?
No seriously, it is like comparing apples and oranges. PHP and the wonderous LAMP stack (I have just heard about it, so that is the first stumbling block for its adoption! many companies like to be fast followers) might be able to do what Java does if you look at output, it might even be quick, but that has nothing to do with the costs and development and staffing that real people with real money care about.
Java has a huge demand in industry that is being met with huge interest in terms of capable candidates which is proven by the number of successful and *bearing in mind this isn't a flamewar!* well written open source project out there.
The level of Java competency in the industry is growing enormously as a result, which is a good thing. PHP is also good, and I like PHP, lets not get things mixed up here.
[snip = list of reasons why people choose java, which was boring even me]
Also J2EE is *the* platform for applications running for thousands of users, on machines with 90+ GB of ram, and 24 processors just to handle the data requirements.
Oracle love J2EE. Oracle is a fairly decent enterprise (not just performance, but support and board level confidence) db to say the least.
Now, LAMP might be lovely, but why even pitch it against anything, dear LAMP community, just be, don't try and compare it against anything.
FUD et al.
PS: erm, nerr nerr? u sux0r? pwned? I am loosing my touch at this internet name calling gaff, time to retire.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
This month's meeting at my local Java user's group there was an impressive demo on Ruby on Rails. The presenter built a blogging application live in front of the group, literally in 10 minutes or so. Prior to this demo I had pretty much written Ruby off "just another alternative to perl or python" but I have to say that Rails looks really impressive, enough so that I'm taking a closer look at Ruby.
One of the guys in our user's group, Chris Nelson, is building a similar framework for Java - called Trails. He also built a blogging application live during the meeting. It took him a bit longer - perhaps 15-20 minutes. It was impressive as well, although I will say that for Trails you need to know a fair amount about Hibernate and Tapestry. Realize that he's been working on this only for a few months and suddenly you see that this work is very impressive too.
Anyone interested in developing web apps might want to check these projects out - very impressive stuff!
You can prototype - or simply develop - most things as quick in Java as in any "P" language; the only exception I can think of being a GUI interface, in that respect Tk kicks Swing's butt. Personaly I don't like the Ps much, I prefer the T - as in Tcl - for scripting. That language kicks any Ps ass when it comes to design, though it can't win on available libraries. (which I never missed yet, all the important ones are there if you know where to look)
Besides, rapid prototyping is overrated for all but impressing your manager or client. If you need to protoype you clearly do not understand the problem at hand and if you do prototype for the above given reason, you manager will make you use the prototype as base for production development. This means you spend the same amount of time as if you'd started properly straight away (and told him/her and their required demos to get lost for a few weeks) but end up with an inferior product because you are contantly hacking around the shortcuts you took to make that rapid prototype.
The two are just very different beasts and there is a clear case when a proper OO language with clear contracts and inheritence is the best tool for the job. Unfortunately, web apps aren't the best example of such a case and that makes this comparison flawed, not the language in question itself!
beowulf vs. ActiveGrids... fanboys, take your corners.
J2EE is not about the OS, server or database. It's a specification. JBoss (JBass.. heh), Geronimo, Welogic and many others are implementations of it. Some are certified, some are not, like Resin.
You can run it on many os's, including linux. Apache is making one of the J2EE servers. I'm not sure where databases came into all of this, since it's fairly independent. I.e. w/ jboss, there are data mappings for all of these servers, if you decide to use EJB, which is part of the spec, but not a requirement to use. The last thing is the big ol' P.
J2EE is a set of technology specs. Things like XML manipulations (JAXB, JAXM), communication "stuff", like SOAP, JMS and JMX, database abstractions, like EJB using JDO, CMP, BMP.. "web stuff", though you can do your own protocols, with the servlet spec. Last I checked, the closes to a spec I've seen is p5ee, which had an interesting run. You had options of what to use, maybe too many, in p5ee, but that was about it. It would have been nice to see a tight binding between everything.
Anyway.. the LAM in LAMP is irrelivant in this article. I can use Linux, Apache and MySQL with J2EE if I so desired.
-
ping -f 255.255.255.255 # if only
Grid Application Server based on the LAMP
So does that make it a GAS LAMP?
*ta dit boom*
So let's look at the requirements for today's corporate applications ... Given these requirements, Java does not fare very well. Apparently what is needed is a language/environment that is loosely typed in order to encapsulate XML well and that can efficiently process text. It should be very well suited for specifying control flow. And it should be a thin veneer over the operating system.
So we came from string programming roots, we developed OOP and AOP, and now... now we go back to string programming because of xml parsing?
I find this a worrying trend, you have to understand, an application is state, and behaviour.
This is trying to tie an application into a 'thin veneer' over an operating system, which seems a bit worrying for an app that will cost a few million to develop in the right circles.
Be reducing all the benefits of OOP (huge and varied, numerous and wonderful) we seek to define our crowining enterprise applications with an approach from the 70's that would pioneer the use of string processing programming constructs over highly developed and structured powerful programming tools.
The program isn't the code, it isn't the data, it is the design, the behaviour, the organisation, the people understanding it. All of this becomes very alien to us when we go this route.
Humanising code is key to developing the kind of applications this company has now touted.
What is looselycoupled? Anyone read it regularly? is it a valid news source? Is this some free advertising for a fad?
I am almost tempted to read more about the LAMP, but I just have a knowing feeling it will be another 'cure all' product.
Yep, tick tick, oops, missed one, back to step 1.
#hostfile 0.0.0.0 primidi.com 0.0.0.0 www.primidi.com 0.0.0.0 radio.weblogs.com
If you look at the Global Grid Forum you will see that a derivative of SOAP (first OGSA, now WS-RF) is used as the underpinnings of the proposed Grid architecture.
Just because it is being pushed there and in OASIS does not mean that is is the right approach. Nor is EJB, IMO. EJB is designed to do distributed transactions against something that may or may not be a relational database. Grid stuff is very often computation against a large datastore; potentially chained stuff. It is not classic three tier J2EE.
It seems to me we need something like network pipes, where you can construct pipelines of computation and have the resource manager place parts of the pipe on the right machines. There is some work in the OGSA-DAI working group looking at this.
If you look at what currently goes on in development land, you see that there is always a race against the competition. Whoever gets the feature first takes the cake. Requirements are changing rapidly, and it all needs to be ready yesterday. I interpret "next-generation applications" as meaning applications that fit these circumstances.
Seen in that light, the Ps have a distinct advantage over Java. Programs are often more concise, shortening development. The Ps are more flexible than Java's stringent object-oriented model, making it easier to adapt to changing requirements. This makes them a better fit for next-generation requirements.
Please correct me if I got my facts wrong.
A lot of J2EE is about scalability, not efficiency.
Which means that it can scale up by throwing more hardware at the problem, but the amount of hardware you need for any particular task is higher than with other solutions.
Which is what you expect when you let hardware vendors (Sun, IBM) design the spec.
Also you may find that it will take a lot of effort to get your EJB solution working, at which point you pull in consultants. Like IBM.
The good news: Apache Geronimon. Free, documented. 'nuff said.
Java is comparatively heavy, forces you into an object-oriented paradigm, has static typing, and doesn't lend itself well for rapid prototyping and development.
Leaving asside the arguments about OO and static typing, you're going to have to explain what you mean by that last assertion, as I could've sworn that I've been doing just that for the last 5.5 years.
It's official. Most of you are morons.
Ah yes, the standard "if you don't agree with me you don't know what you're talking about" argument. Try pulling your head of your arse.
You want to knock together a simple web site (eg Slashdot or a simple eCommerce site) then go for your "Ps". If you want to do anything more sophisticated then you would be insane to use PHP or Perl.
And, of course, if you don't agree with me then you must be wrong :-P
Bad analogies are like waxing a monkey with a rainbow.
He's saying: use a suite of highly-optimized tools (the various LAMP components, most of which are fast and all of which can be replaced with alternatives as necessary) rather than throw more hardware at an inherently slow platform (Java).
It's all pretty much a matter of what you were brought up with. On the other hand, I'm working for a household-name client now that's banned Java across the board because they got sick of the 'buy more chips' solution to performance problems. Acceptable platforms: LAMP and
Whence? Hence. Whither? Thither.
Slashdot realy does need some way of letting readers give a measurable opinion on the stories. This way I could set my slashdot account to ignore crap like this.
This story is just a link to the submitters blog rant (no I didn't RTFA).
Sindri Traustason.
Nobody knows _just_ C++. Nobody knows _just_ Ruby or _just_ LISP or (barring a few teens just starting out) _just_ PHP or Perl.
But there is a huge population (I know because I interview them) that knows _just_ Java and often _just_ J2EE. Their entire skillset is invested there. The only response they can reasonably have to other languages / frameworks is 'no, it would be better to use Java'. What else are they going to say?
They aren't going to shop around and maybe pause for a year or two to get a general background in programming, they're going to use Java, plain and simple. It's common sense.
Welcome to the marketplace -- standardization brings some efficiency at the cost of some flexibility.
Disclaimers: there are of course many good programmers who do use Java as one tool among many. However, the vast horde of Java-only people, good and bad, who were trained a few years ago is going to have a big effect for a long time.
Whence? Hence. Whither? Thither.
J2EE is not a part of Java it's just að collection of standardized APIs and programs for Java.
Sindri Traustason.
MySQL isn't suitable for 'enterprise' - you'd really need PostgreSQL. I tried for years to use MySQL in that manner before giving up and trying PostgreSQL. Wish I had done so earlier.
I've always found that proper use of OO makes things easier to change and adapt.
It's the 'proper use' bit that's tricky. It requires a bit of design and planning rather than just cranking up the editor and coding to the metal.
Finally, a break from the Sun tax. Yeah, you know the one -- the one that makes you pour hundreds and hundreds of wasted man-hours into using poorly written programs with little or no documentation. What can you expect from crappy code written by scientists and corporations? I'll happily use code written by hobbyists any day, no matter what News for Nerds declares. Honestly, I know most of you agree with me!
Forget about clunky PHP, try Mason instead. And use whichever db makes sense for you - for us it's often Oracle but then we've got the DBAs and experience to make use of it (oh and the licences...).
And sometimes Java (even J2EE) makes more sense than working in Perl. Which is why we do that too.
Choose the kit of parts that suits your application needs and the skills of your developers. And think about avoiding lock-in to a closed-source vendor. That has always seemed like a big risk for a project.
"we demand rigidly defined areas of doubt and uncertainty!"
"They are there to prevent trolls from stretching the width of the page by inserting silly long strings of text that lack breaks."
Since they're just URL links anyway, they could just wrap it anyway, since its a link.
Even "Microsoft Outlook" has figured out how to handle that.
You were mistaken. Which is odd, since memory shouldn't be a problem for you
The above poster doesn't know anything about html, so his/hers post is unreadable garbage, here's his/hers post with couple of html tags:
Originally written by giuntag (833437):You'd think that a person who wants to flame "news" item about a subject like this would understand a bit of easy mark-up language.
Why do you mod facts to trolls?
Ouch. Think of the insights we would miss if Slashdot would have a spelling checker...
That's a bit unfair. The previous poster said "Only people who don't really know anything besides Java", not "all people who use mainly Java".
I think it's fair to say that knowing only thing in a category (e.g. one programming language) significantly reduces a person's competence to make comparisons in that field (e.g. between languages).
Not to start another emacs vs. vi flamewar, but it looks like emacs is starting to grow up, and that it is much better suited for next generation application-development than vi.
Am I alone in wondering exactly what a "next-generation application" is anyway?
.
Oh dear, I knew this question was going to come up, but I didn't expect it so soon.
Ummmmm, ok, look, when two applications love each other very much. .
KFG
And you know PHP is on its way out when you have experts in the field writing MVC frameworks in Java like Bonjovi.
Apache
Mason:HTML
Postgresql
That's how I like my fire. Much more capable than MySQL or PHP.
So who do people compare LAMP to J2EE? Because they are both application development approaches that are crawling with cheap plentiful labor. Any dweeb can set up LAMP with a minimal understanding of reliability, security, or fundamental concepts. Please do not construe this as a statement that all LAMP developers are dweebs. But the entry barrier is low.
Similarly the entry barrier to J2EE can be artificially low because all you need is a certificate to wave around and some PHB will hire you. My work has hired a series of J2EE developer contract houses and they are without question the dumbest bunch of assholes I've ever worked with in my life. They are fundamentally clueless on how to write good code, but they are just so cheap!
The entry barrier to Mason and Postgresql are much higher. Not because they suck, but because of what they can do and what they can't do. Once you get started it's pretty amazing what you can do.
It's the higher entry barrier that helps insure that the developers you do get are better qualified in terms of fundamentals, security, and reliability.
Oh yeah, PHP and J2EE are different beasts. You would be better off comparing J2EE and mod_perl variants for a more similar architecture.
The "light" part of the application is the user interface. That should always be as light as possible.
The "heavy" part of the application is what does all of the back-end work. Database manipulation, messaging, legacy-system communication and integration, calculations, life cycle management, etc.
The fact is that customers hardly ever know what they want when you start developing. Development is a continuous feedback cycle where you show some, get new requirements, and show some more.
So, maybe you save a week or two of development time using one of the P's instead of good OO design and Java. What happens when they come back a month later and say can you hook in system X to this? What happens when the small system unexpectedly takes off and they need to add in 150+ more concurrent users?
Strong design should not be looked at as an extra expense. Strong design should be looked at as future proofing.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
I was in a similar position a couple of months ago. Then I found Spring Framework. A very nice middleware/framework for J2EE servers. It doesn't use EJB at all and is much cleaner and easier to use. It still requires a J2EE container, but since it doesn't use any EJB it is much faster. Very impressive and saved me when I had two weeks to delivery.
And yes, its free (as in beer).
ah, the eternal dynamic/productive/high-level/slow vs static/unproductive/low-level/fast debacle.
Nice to see the Lisp vs C flame still going strong these days... :)
Nice to see too both have many intelectual descendents which are very good on their own.
And finally, nice to see that both sides of the same coin have seen such widespread adoption to this day, proof that more than one way of thinking is a good thing.
I don't feel like it...
We're working on a sortof big (for us) management platform. We looked at J2EE and said "Ugh, too complicated". In order to make things flexible and modular we ended up implementing a lot of the J2EE stuff ourselves (name service, home/remote bindings, deployment descriptors). Now I look back at J2EE and say "Ok, so that's what all that stuff is for". (To be honest, I'm not sure from a project-success point of view we made a mistake, since we didn't have any J2EE expertice in house, and weren't going to get any more warm bodies).
It's sort like Corba, or History. Those who don't understand it are doomed to repeat it.
-- ac at work
I've recently been involved with developing J2EE applications for our company's intranet. Well, it is very difficult to develop distributed web-based applications, simply because there are hundreds of details to take of.
For application servers alone, one has to know the peculiarities of each application server, its custom settings, its XML schemas and option files, its architecture, what databases it supports, how it supports each database, what other persistence options there are, its directories structure, and many other minute but critical details.
For J2EE, one has to know which framework to use, the logic behind each framework, how the framework connects to the database, how the framework is used by the application server and how compatible the two are, how the application server's persistency capabilities can work with the framework, each framework's options and configuration XML schemas, files and location of files, and many other things.
Then, for the client part (i.e. the web page), you have to know all the tag libraries and tags, the parameters of each tag, the syntax of each tag, the attributes, the attributes' value types and ranges, the details of its usage (when you need to use its one) etc.
And if you are gonna use a workflow engine with all that, you need to know how the workflow engine works, what persistence options the workflow engine has, the API, how to manage users (relative to the security of the application server, of the back-end databases, of the framework, of the HTTP connection and of Java), how to manage logons, how compatible the workflow is with the workflow patterns, if the workflow can run under the application server etc...
And beyond all that, one has to know the details of the databases: if and how transactions are supported, if and how row locking is supported, if automatically generated ids are supported, if there are blobs, if there is text search into blobs, how the database separates different instances (either by user or by db name), all the differents between the SQL of one to the other, etc.
Then there is the peculiarities of each IDE, the options available, the Java libraries to use etc.
Well, THATS A LOT OF STUFF.
It is a domain which is far larger than that of desktop applications, even with the same functionality. With desktop apps, all I need is how to know is the language, a few protocols like HTTP and maybe the database details. But with J2EE, the knowledge domain is far larger and much more discontinuous: there are too many details that are totally different between themselves, so it is too difficult for the individual to handle by him/herself.
The difficulty of developing J2EE applications comes from the fact that J2EE is actually no application model, but rather a set of classes to assist towards building web/distributed apps. That is why there are so many frameworks out there (I've counted at least 31).
Does LAMP solve all of this?
Ultimately, the programmer shouldn't have to worry about all that stuff. After all, a web application is just like any other application: there is the view (the HTML client), the model (the database) and the controllers (the business logic). In my opinion, J2EE shouldn't have moved away from the classic MVC pattern.
If LAMP development is easier than J2EE, that it might worth a try.
Sorry, but how is that a stack? It is neither a stack in the programmatic sense (LIFO), nor a layered 'stack' of protocols (TCP/IP).
I have not heard a multi-tiered architecture referred to as a 'stack' before - is this usage common, or is the poster pulling words out of his ass?
MVC is a pattern, not a framework. You can speak of UI framework using MVC or PAC or whatever pattern.
And no -- Java/J2EE is not on its way out. Beans? Maybe. But I really did not hear _any_ experts in the enterprise world bitching about Java and J2EE itself. Surely, no one of them ever mentioned using Python or PHP or anything like that to develop a serious system.
which seems a bit worrying for an app that will cost a few million to develop
;-)
Which is exactly the point. If you need to spend millions to develop a product which to your customer does little more than the "cheap" product ("Which color do you want the database to be? Pink!"), then there is no need for time consuming layers over layers of J2EE apps.
Some information-providing thing like a forum does not need distributed transactions. I bet most of these distributed systems also fall over when actually put under stress and unusual input, just like their PHP cousins.
Of course it would be nice if PHP grew up a bit, but people who use it don't feel the need yet.
It's fine if you can throw millions of $ at your enterprise level solution, you will lock out competition, need more and more specialized programmers and will choose to ignore the crowd of LAMP users.
This stuff costs money and nerves, and if your customer can pay it more power to you
I'm still trying to figure out what people mean by 'social skills' here.
I used to be a LAMP developer but now that I have done a very nice hosted application in WebObjects I really don't want to go back to LAMP. Until you have tried WebObjects you will not understand the beauty and productivity that is WebObjects. And, it is very cheap too! The more I read about how JAVA is trying to fix J2EE etc., with Hibernate, Struts, etc., the more it is trying to be like WebObjects. Give WebObjects a try and you too will go eureka!
Mind | Body | Spirit | Cash
1) MySQL sucks as database. Sure it is fast but Postgresql will provide way more flexibility and power.
2) PHP is horrible for anything large scale. It is hard to maintain code almost all the time. Java tends to be easier for that.
It is just as suitable for rapid prototyping as anything else if you know how to use it.
May I suggest that it is not just as suitable if you have to prototype something that has to work with someone elses code and framework?
I'm still trying to figure out what people mean by 'social skills' here.
http://news.com.com/Start-up+pitches+high-end+Web+ apps+on+the+cheap/2100-7345_3-5458483.html
Who cares... go learn some business, in the long term these debates are pointless. Companies use whatever their situation and the market dictates (vendor support, availability of personnel and other resources) to get business done. Businesses could care less about the minutiae of the respective language grammars and your ability to induct whatever semantics they afford. Hey, that's life, get used to it.
Have a look at Rod Johnson's somewhat repetitive but still quite insightful book about the lightweight container movement.
nope, those are optional components, GNU isn't.
"LAMP" is marketing-speak and not a platform, and anyone posting to /. should know better. What are they really talking about?
Linux (well, you could just as easily use BSD)
Apache (well you could use another free webserver or an appserver like Zope)
Mysql (well you could use Postgres)
Php/Perl/Python (well PHP is just plain awful and there are other alternatives anyway).
Firstly, mysql may be fine for small applications, but is pretty rotten as databases go. When I have used it in the past it really begins to suffer from lock starvation as you scale to more and more read and write contention. As free databases go, postgres has been superior in my experience.
Really what people mean when they talk about "Lamp" is "open source n-tier architecture" or "open-source middleware with a database".
Not to say that Java is all bad and the Ps are all perfect, but Java is a flawed language, and people are slowly waking up to this.
What, exaxctly is flawed with Java? Is it becuse Sun will not "Open Source" it? Is it becuse it only supports single-parent inheritance? Why is it flawed?
Having been in the corporate software development world for a good many years now, I have seen many languages come and go. When I think of all of the fads (i.e. PowerBuilder, Focus, ADA, etc.); Java seems to be one of the few which will stand the test of time (i.e. COBOL, Fortran, and RPG).
Also: What other language can give a software developer such a wide and diverse spectrum of development? Smart cards, cell phones, PDAs, Video Games, Business Applications -- using Linux, Unix, Windows, Mainframe, Midrange, etc. etc.
It's to create a framework of sorts for creating parallelized code right? I love PHP, but despite the myriad of bindings for it, it's still something you code in a script that executes on the fly via Apache right? Or more specifically, you can't do this from
$bash>php myscript.php
and run an application. If so then how can you fit running parallized (albeit computation heavy) applications via Apache or any httpd?
Have a script call another script on a different node running apache?
Java is flawed? How, exactly? You do mean "flawed" as in "broken", right? Or do you mean "flawed" as in "doesn't handle every possible thing that might ever need to be handled, now and forever"?
I do know one thing...the systems my company develops and sells could never be written in a "P" language. We tried perl and PHP and both failed miserably. Java works quite well, however. So from our perspective, Java is not flawed.
Everyone here should check out what we are doing with java right now (interesting)! http://www.ambientengine.info
I'm being responsible... I refuse to comment on this story.
The story may have some merit, it may not.
However, I simply refuse to enter into a conversation that has clearly, despite the ignorant "I don't want to start a flame war" prefix, turned into a flamewar.
Everyone, be responsible. Move on... nothing to see here.
bash-3.00$ uname -a
SunOS panda 5.10 Generic sun4u sparc SUNW,Ultra-2
Why, oh why, do I want to step into this? I dunno, it's Monday and I'm cranky, and I've used a few different languages, including LISP, in my time. Forgive me.
...(some say LISP is short for Lots of Irritating Superfluous Parentheses). That's a valid point. In C syntax, at least there's variation. Besides parentheses there are curly braces, straight brackets, commas, semicolons, etc. Seriously, the parentheses make for a very simple and consistent syntax.
when other languages improve, they almost invariably get closer to Lisp
Except in one crucial (and rather obvious) regard: they never adapt the lexical model of LISP. It was an experiment that people have learned from. It is sad that it has taken this long for the power of dynamic languages to re-emerge in popular languages like Perl, Python, and Ruby, but better late than never.
To me, this sounds like someone trying to justify using binary numbers instead of base ten. I mean, why confuse things with ten arbitrary symbols when two are clearly sufficient? Why not go to base one and shave off another superfluous symbol?
An overly "simple and consistent" syntax does not yield a rich expressive environment for human brains. I do respect LISP as a language, but I'll be damned if I can reliably tell the difference between a string of 8 parentheses and a string of 9 without interactive editor support, and that seriously hampers code legibility. LISP also fails its readers by imposing prefix notation for every operation. If that's how we taught math from the first grade on up, and if talked like Yoda we all did, that would be great. The language should be adapted to my mind's kinks, not vice versa.
Excuse me, but wanting to start a flamewar right under all you XML hacks, where do you come off with the remarks that Spring is the savior of Java. Actually where is any java in your XML engine. You aren't half as good of a software engineer as some of these LAMP guys you sorry XML Jockey.
.
For goodness sacks would you XML weenies get your head out and realize that XML is just a way of doing spaghetti code!! Since it is highly structured in it's format you confuse that with highly structure in purpose or function. GET REAL.
EJB's and J2EE is a very good spec that is matured, and is being improved so that lame idiots can even use it at some level. But the more XML you add the more inconsistent your server become.
All you XML weenies can say is, "look it's decoupled". BS!! it is tightly coupled you are just too blind to see. If I want to add a feature or a function or a new algorithm you can't do it with XML, in java I could. Just because you don't have to recompile doesn't mean the it's decoupled. Actually if you don't write your XML correctly you will never know until you try and run the system. How much of a Kludge is that. VS. I write Java compile find a syntax error and fix, recompile cleanly, jar and deploy. There is a 99% chance my code will work, unless some XML jockey screwed up the tag
Now having some history with PHP and JSP, as soon as PHP can perform at a level equal to basic running on a TRS-80 then I will think it's an up and coming contender to, well, Visual Basic, and a few years later maybe it will catch up to Java. But for all you lamers...I mean Lampers (or is it Lampoons?), maybe you should learn how to program then you might understand a little more about Java. But please stop thinking just because you can write a system in 30 minutes that you are some hot shot. You systems don't scale, and you can't maintain them. Lord help you if there is a bug in your code, cause then you'll have to actually use some analytical analysis to understand the issues. (I'm sorry were those too big of words?) How about this, go to college, get a degree, listen to the instructor and don't cheat by using the internet to find some nice expert to do your homework.
I had to work with that tool once upon a time. Nightmare. Anyone remember spider classes?
Not to troll, by why MySQL? and not postgres, is there still anything that mysql does better than postgres?
Have they added support for:
more than one concurrent connection.
ANSIish sql syntax.
triggers.
object orientated data.
etc...
to MySQL yet?
If so how long ago, and woudln't it be better to use a more thourerly tested database server like, umm... postgress?
thank God the internet isn't a human right.
Supports everything I need but comes with a shitty editor.
http://saveie6.com/
Call it LAMPX and I'll help start the port.
X because all data streams are in XML and XSLT is used to transform data streams.
thank God the internet isn't a human right.
Lots of flames here, but through the burning embers I just want to point out that using Hibernate and Spring is not supposed to be an excuse to use XML - it just so happens that XML is the glue that these packages use to do their work. I personally could care less if it were a binary format or a CSV file. Love it or hate it, .net uses a lot of XML metadata as well. Arguably in the Java community, XML probably gets a worse wrap simply because it doesn't have the tools that .net does to obsfucate the XML glue from the developer as they desire. XDoclet and AOP is a step in the right direction. I can definitely empathize with your complaints about XML from a Java background. But I think when looking at Spring, Hibernate, Struts, or any Java tool that uses XML metadata for configuration/persistence of application state - that unless you are looking to do some serious hacking of the package that would require that you denature the glue it uses, blissful ignorance is probably beneficial. The aforementioned packages work as advertised by their development teams - even if they do use XML.
The fact that you can take ANY code snippet and put it into a "module" doesn't really get you anything.
You can create a Perl "module" that is simply one piece of code you call a ton of times. You can do the same with JavaScript too.
You can also really create a perl Module that can be invoked and used by bunches of other Perl code. The reason for the stricter Module is that it has rules for being incoporated into Perl and should provide strict type-checking, input validation, and error handling.
This is where the real Module idea comes in. It's not OO "hype" it's as you said good coding practice. It also means that you have to think of a module as a Module and have public, protected, and private sections in it and do real checking and error handling.
Yeah it's more work, but it makes it work.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
For large scale projects, I use Java. It is great Object oriented language that I can use to the fullest extent. I can get very close to that MVC pattern that is soo useful in large-scale projects. I don't use EJBs -- not needed them yet. I use the JMS, WebServices, JSP/Servlets, etc. We connect to a real database (DB2). J2EE offers a completely different scale with work with. You can do everything from simple web applications to clustered app servers at several levels.
For smaller stuff, I like LAMP fairly well. It is simple and easy to get started, although not great for larger projects (code reuse, management, scaleability). MySQL, again, nice and fast for small stuff. I perfer PostgreSQL because of the power and flexibility. I'm trying to move more towards PostgreSQL especially after recent changes in licensing with MySQL. For these projects in general, I like PHP over Perl for webpages. Perl is still great for admin tools on the console or for confusing the heck out of folks not familiar with your code. PHP is simple and made for website based applications. Again, I'm not going down that path if I know it will grow into a huge project.
The deal is, they are tools. The both have their strengths and weaknesses. Evaluate your needs, and choose the best tool for the job. I use both and love both -- but choose wisely.
SPAM solution made easy: 1 spammer, 5 cords of rope, 5 hourses, and fireworks. Be creative.
blah, blah, blah! Don't you proof-read before posting?
I want a decent middle ware, that is cross platform, fast, and well documented, free as in beer (and preferably as in speech also).
That's Java.
You're right! its so nice that if I need to add any feature to the JRE that all I have to do is pull up the source code and start changing what I want. No... wait...
Java is useful if you intend to treat most developers like lego blocks.
;).
.
;) ). Or they don't care - it's just a job after all - that's what they got the java certification for.
Example scenario: you have one main guru programmer who writes the program in Human Language (e.g. English). And you have the other much cheaper developers (in-house or off-shore) who compile that to Java. After that the guru programmer(s) can move on to other stuff whilst the interchangeable and cheap programmers maintain it.
You appear to NEED a fair sized team for lots of Java stuff, which if done in some other language can be done by just one to three people. This can be considered a minus or a plus. Coz in many organizations if you are a Boss of 20 people, you outrank a Boss of 3 people (and probably get paid more too) - which is why MS has its uses
I find Java stuff to have a lot of "make-work" stuff. You need all these layers and layers of stuff because you have all these layers and layers of other stuff. And often these layers and layers of stuff _don't_help_very_much_ - diminishing returns. Sure it is more "organized", but now you have to change 3 different files to make one change, or something like that (e.g. code, data, metadata)
Whereas the LAMP style stuff is relatively simple - O/S, Webserver, Database, Programming Language. So what if it isn't N-Tier, or have "Enterprise Java Beans" or have built-in caching or some other buzzword, very often you don't need that stuff - you run out of bandwidth, or hit some other limit first. If you keep things simple you can often easily scale the webservers (and appservers) horizontally (keep adding them). So the bottleneck is usually the DB, and there are many known solutions for that.
You probably end up with similar scaling limits with a Java solution anyway (except the Java solution typically has more layers, complexity and work).
The disadvantage of the LAMP stuff is while you only need a very small team (of one sometimes), since after all the guru programmer codes most of it; the problem is if the guru programmer gets bored or wants to do something else, you have a problem - who's there to maintain it? The "lego brick" programmers may not be able to handle the job. So you need to get another guru programmer who costs as much and is just as likely to get bored.
The lego brick Java programmers don't seem to get bored maybe because they get the feeling of satisfaction coz they are definitely doing lots of work and achieving a "lot" - (remember there are lots of layers to glue together- N-tier
Last but not least of all - it may not even matter at all whether you go LAMP or J2EE.
Coz amongst the most important bunch on the team are the graphic design/art people. It doesn't matter to the client or PHB how cruddy the architecture is - if the software _looks_ great, you are more than 50% done. It doesn't matter if your architecture handles up to 1000 transactions a second on an el-cheapo dell server, and scales very well. If the widgets look ugly you're unlikely to win the project.
After all not many can tell whether a software/system architecture is ugly or not. Whereas very many can agree and tell you immediately that a widget/icon/colour/layout is ugly. And that includes the people in charge of approving stuff.
Just like you don't use Oracle to handle a simple little db holding some responses to a recent questionnaire or for a quick little conference, I would not use MySQL for a big data warehouse or SAP deployment. Silly db admins have gotten it into their head that DBs at all levels should be compared equally. That is simply not true. Use what's appropriate where it's appropriate. Don't use C for a quick data analysis tool (try Excel first), and don't develop full enterprise apps using cobbled together MS-Office solutions.
...tizzyd
I work for a small (lt 1500 employees) non-tech (real estate management) company. They needed a developer to build a web-based front-end to a database. Small, fast, and _now_ were the requirements. I used PHP.
I used to work for a slightly larger (gt 5000) researh firm. They needed a cross-department application to handle account transactions on a large cluster. Robust, maintainable, and within the next year or so were the requirement. I worked on a team to build a Java-based solution.
Bottom line: use what's best for the job at hand. There's no use tying yourself to a particular platform or a particular method. I may be young at this, but I think I've learned by now that good development practices carry over no matter what OS, webserver, database, or language you are using.
Use what you need to get the job done. There's enough religion in the world. We don't need it in IT.
While it's nice to have a single server solution, a scalable two-server solution that performed just as slow as the first, is a more sensible choice, because you can always add more hardware when you need it, with no re-programming and little re-configuring.
Remember, hardware is cheap, labor is not, even where I live, with 4$/hour IT people.
Python is a dynamically typed, strongly typed language. This in contrast to C, a weakly typed statically typed language, or Java, a strongly typed statically typed PITA^Wlanguage.
...now, go write yourself another LAMP blog tool. I have work to do.
The general argument is that external static checkers can do a better job than the compiler, and can be implemented for any language - including Python. The other part is test-driven development - your unit tests will catch faults the compiler won't, and relying on the compiler to catch your errors for you may well be unsafe because it only catches a small class of errors.
:-)
... people write large tools / apps in Perl. Whether this as such works is something I don't care to argue.
Myself, I think that's reasonable, but there's also value in static typing. Python looks like it'll be getting optional type checks for function calls eventually, and I'll definitely like that.
The main large, successful Python code base that comes to mind is Zope/Plone. It certainly works
As for Perl and PHP, I frankly think both are a different class. Python is a real language, though it can and often is used for scripting. PHP is a web scripting language, and does its job well - but IMO not much else. PHP5 looks a bit more like a real language, but not enough for me. As for Perl
I do think Python has real validity for large projects. Even if you prefer to implement in C# or Java, Python can let you prototype and redesign it much faster. Once you have your prototype ready, you can code it up in C# or Java with much less pain caused by unexpected changes, refactoring, etc. In fact, with Jython you can even have a runnable app that's half written in Java and half in Python. The same may soon be true in C# with IronPython.
By choice, that's how I'd go. Prototype in Python, and as/if/when necessary translate to C#/Java.
I've used Python for a number of "large scripts" - small applications - and found it to work very well. Perl, on the other hand, has made me regret everything I've ever written in it, and PHP hasn't been all that much better. With Python I've had excellent results using tests and static checking.
Arghhh!
-h-e-l-p-
What if the applications are gay, though?
Agreed - I've found static type checking more of a frustrating hinderance than a help in C++. I can't speak for C#, which is still on my to-learn list, or Java, which I've learned just enough of to know I don't want to use it in most of my apps.
To my mind, static type checking encourages the dangerous assuption that 'if it compiles it'll work'. Compilers only do a tiny subset of the static checking they could, and do so in a very myopic way. I favour the use of a full-fledged static checker that can view the entire codebase, and a good set of tests instead.
That's not to say that static typing done right (which C# may well be) isn't useful, it's just to me it's only a half measure that I can live without. I'll be writing my tests no matter what language I use.
To the OP of this subthread: I think you'll find that good Python programmers are in many cases far more pedantic than C++ or maybe (again, I lack the experience to know) C# programmers. Of course, Python does give you more rope to hang yourself with if you feel the need - but then in a way so does C++, given the pain of refactoring a bad design.
I worked on both. Or rather I was somewhat involved in 2 mission critical application including full databases and a whole lot of small internal and external websites.
So far the money/fun/job security/supply of work have all been better for the small tiny jobs.
I am getting sick and tired of every idiot like you who thinks IT is always the big jobs. The people on the ground, you the sales people and other office grinders who you are there to support are often best served with small websites that help them do 1 task a lot faster.
Recently I have worked on several jobs that reduced several man years for departments at a cost of a week of my salery. You couldn't even buy a database license for that.
Not everything requires transactions. In fact I have been able to upgrade the speed on many a mission critical app by simply switching off unneeded safe guards. Transactions are only needed if it can fail. If it can't or it doens't matter then don't bother.
Many internal apps are nothing more then getting pieces of data out of several sources, combining them and displaying them. Exactly wich part requires transactions?
If you never worked in a business were they had two systems wich didn't talk to each other yet data from both was needed for daily business needs then you either work in heaven or you never bothered about the real business needs of your employer. I see them a lot. You got on your resume "developed large account system for X" I got on my resume "saved company X 3 fulltime salaries in 1 week". Sad thing? You are probably easier employed then me. IT likes big spending.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
and you know you are wrong :)
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Personally, I'm placing my hopes on Python and IronPython. Python, because while a very far from perfect language it's heading in the right direction - OOP without the overly formalised pain, flexible enough to use functional ideas too, etc.
.NET library base from Python, integrate Python even more easily into larger projects, and make Python even more able to call out to other languages to accomplish things better done in them (such as R for stats, or Haskell for hardcore functional code).
IronPython should be interesting because it should make it easier to use the entire
I, too, have seen more real "enterpreise" work actually get done with older languages - in my case a really scary 1983 4GL called Plain English - than with most "modern" languages.
But it's really "the eternal dynamic/productive/high-level/faster (LISP) vs static/unproductive/low-level/slower (Java) debacle."
References: Lisp as an Alternative to Java[HTML] or Lisp as an Alternative to Java[PDF]
Don't forget XDoclet. Add a few comments and a few templates and your POJO will create its own access layer. This could be anything from a simple DAO to a EJB.
Something else that's been overlooked - hibernate is not only compatible with jboss, it's actually funded by it now. The idea is that hibernate handles local storage and jboss wraps it with an EJB layer. If you're small enough to run everything locally you should be able to use XDoclet to create trivial "pass-through" EJB classes. It's then a trivial matter to switch to JBoss as your needs grow.
For every complex problem there is an answer that is clear, simple, and wrong. -- H L Mencken
Anyone with experience realizes that, if you use J2EE, you're too busy to learn anything else, especially all of LAMP. Nobody uses both and STILL knows them both.
If I want to add a feature or a function or a new algorithm you can't do it with XML, in java I could.
Do you even know what you're talking about?
Had you used a logical rule-based system, not only would there be no RDBMS impedance mismatch, but the changes could be implemented by merely resolving the rule sets of the two systems.
really. I don't have the uris now, but google plone developer book...
It's better to be the foot on the boot than the face on the pavement. ~~ tkx Kadin2048
They could do that or do what Tiny URL does internally.
BTW The URL: tag does insert spaces.
Guys,
I thought we had all finally agreed that LAMP=Linux+Apache+MySql+Python/Perl/PHP/ PostgreSQL !?!?!
It's extremenly frustrating that PostgreSQL is continually left out of technologies such as this. It's a mature, stable alternative and is (IMHO) the best open source database option out there.
MySQL only beats it in the marketing department. Judging by the results (and those on the part of a certain Redmond company), perhaps marketing is more important than a quality product anyway.
sigh...
I use Seaside with VisualWorks Smalltalk
You'll note their website is a smalltalk web server.
"Why does nobody use it? Fear, uncertainty and doubt. People think it died with AI. People think its old, so it won't be up to modern tasks. People can't get over the parentheses. The boss won't approve it. Nobody else uses it, so it's hard to get support. Any number of reasons."
The intelligence community uses Lisp.
What if the applications are gay, though?
Infiltrate, recruit and employ surrogates, of course. Not that I'd trust a gay application in my box, they probably have a viruses.
(Do I *really* have to use extreme sarcasm tags on the above?)
Ok, to take your initial question somewhat seriously (although I refuse to refrain from being sardonic), a "next generation" application is the next piece of crap we're going to write that we'll tout as being the saviour of mankind (and probably the dolphins as well), to replace that last piece of crap we wrote and touted as being the saviour of mankind (and the dolphins, of course), but will now tout as being a tool of the devil that will only bring pain and sorrow to cute kittens if you refuse to upgrade.
KFG
If java were "close enough" to open source I would be able to use it. But, since its locked up with an abnoxious license, there is no freebsd/amd64 jdk. C, C++, python, perl, ruby, php, ocaml and more are readily available to me, but java is not. I can use IBMs jikes compiler to compile java, but I have nowhere to run it. Hooray for java's wonderful portability.
And these are bad things?
I do agree with you, however, that PERL (the only P language I have experience with) is great for quick applications. But there is no way on G-d's Earth I would use it for enterprise (50 000+ LoC) worthy applications. I'll stick with Java.
But that's just my opinion...
--- "We've always been at war with Eastasia."
The author of the article speaks of how applications servers "solve the big corporate impedance mismatch and arbitrate connections to overwhelmed back-end resources".
I have news for him:
Those companies relabelled their products as "Application Servers" and went on to sell their products to that deep pool of IT fools to which I refer above.
Is the performance. Admittedly, its still very young, but its really slow, and is quite a memory hog. Maybe when they make some attempts at cleaning up the code and making it more effecient it will be good, but right now its not useful. What good is making a web app quickly if it can't be used because its so slow and bloated?
All of those are nice, but when I was looking around at solutions for a kind of document management solution, I found all of the Zope sites I tried were kind of sluggish. If your main goal is to satisfy customers then response time has got to be a factor.
Java has everything you listed, and multiple frameworks to boot - if your J2EE people are so far behind, perhaps they should just be writing servlets, or using Tapestry or Spring or IDE's that help you put together standard J2EE components more quickly.
Plenty of people in the Java worls are doing just fine with Agile development practices, thanks - Zope has no exclusivity there.
In the end for my own project I'm using Nukes on JBoss.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Less smelling!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
J2EE is what our nationwide corporation runs for all of its back-end and front-end enterprise applications. J2EE is highly robust, scalable, and reliable platform that has the extremely valuable benefit of allowing a multitude of different clients and systems to interact without a hitch. LAMP is meant for cute personal websites. The person who posted this article doesn't have a damn clue what he is talking about at all.
But Emacs has a VI emulator and is therefore a superset. :-)
"There is more worth loving than we have strength to love." - Brian Jay Stanley
"LISP also fails its readers by imposing prefix notation for every operation. If that's how we taught math from the first grade on up, and if talked like Yoda we all did, that would be great."
We do. You just don't recognize it.
You're given operand, operand, operator.
The stacking form in which grade school examples are given doesn't make this obvious, but that's the way the eyes and brain do it.
Rails is another interesting Open Source database development platform-but it isn't strictly "LAMP"(uses Ruby instead of Perl/Python/PHP-though I suspect we'll see a Python version soon).
My favorite line in the article:
"J2EE as a fear-driven technology choice made by higher powers"
Zope is too slow to be useful, it REQUIRES you to run an http accelerator in front of it to be even mildly useful. But even then, every dynamic page still has to be requested from zope, which is insanely slow. Using squid and zope makes an iffy, not quite right solution, requiring stupid hacks to get zope to see the IP correctly, and ends up still being slower than just plain old apache+php, nevermind something fast like resin.
Seeing all this about this kicks ass over this rhetoric it is too bad Apple decided to curtail the original WebObjects into Java and not provide WebObjects ObjC and the full-power of EOF and all the extensive frameworks.
Hopefully, they'll release it and rejuvenate their Enteprise presence, but who knows.
This is a joke, right?
But it's not even the 1st of April!
What important stuff does it lack?
And you assume that all database needs in the enterprise are the same?
Sure there are situations where MySQL isn't the best (in the enterprise), but there are many situations (in the same enterprise) where MySQL would excel.
You know, I was about to continue my arguments, but I've just hopped over to your blog. I can see I would be talking to a wall. You have your opinions formed, and they're as solid as fact I'm sure.
/Not for internal use/
Is there any LAMP implementation of a Portal? I am convinced that standardized reusable portlets will eventually replace desktop applications. I might support a LAMP platform if there was a freely available solution that included a Portal component that supported WSRP (Web Services for Remote Portlets) and something similar to JSR 168, the Java portlet standard.
look you insensitive clods, j2ee takes a special place of reviling and hatred in the heart of the true denziens of the linux underworld for a simple reason.
:)
j2ee is lock in. its opting for a dark evil-you-know, its embracing a chosen path. once you start adding frameworks, your down the path of adding even more frameworks and theres no where to march but onwards.
in general, the best hope for the rebellion is on loosely coupled. in the context of the web, with the constant promise of agents and what not, loose coupling and late bindings are the only thing that make sense. static types are so 1988. the LAMP "architecture", by nature of being so apache-centric, is slightly less bound, even if the underlying code is single purpose hackery.
activegrid promises one of the integral elements of what is truly needed: a transactional grid system to fabric different apps. conventional databases are overly limited, what active grid is promising is a more persistent active-object oriented approach.
we need a coordination language which bridges the loosely-coupled/static type boundary. which bridges the language barrier.
codehaus has a couple Active[SubName] projects of interest. Some really amazing work at integrating and coallescing a real coordination language, but very java specific for the most part. i have a big fetish for ActiveSpaces and its SEDA approach. ultimately the java specific killed the prospects for me (performance suspicions), otherwise its very beautiful.
it amazes me just how short-sighted and short-reaching all these comments are. way for the poster to turn a very foresighted richly influenced piece of technology into a petty bickering flamewar. insensitive clod.
well, there goes my moderation...
as always,
myren
they never adapt the lexical model of LISP
Ever heard of something called XML?
As Tim Bray points out, "XML does a lousy job of what Lisp S-expressions could do decades ago."
Value judgements aside, we can at least all agree that it's trivial to interconvert lexically between a LISP expression and an XML expression.
Further discussion on the C2 Wiki.
I'm using LAPP (Linux + Apache + PHP + Postgresql) for http://www.coku.com/ ,
may be I should also add memcached http://www.danga.com/memcached/.
D Moon
I'm a farmer in silicon valley. My labtop is my hoe.
"Lets compare a hypothetical wrecked Porsche to a working Hyundai?"
I have nothing against LISP, being one of its early implementors back in the 1970s.
Many languages, for example XML, are lexically and conceptually derivative of LISP. It's a very versatile framework for exploring language design, precisely because its own footprint is so small.
But by the same token (sorry, no pun intended) there is essentially nothing to motivate the use of LISP in an application context. LISP itself is the barest of frameworks. Saying that you're going to deliver a solution in LISP is tantamount to saying that you plan to write it from scratch.
Better to say, "I'm going to implement it in Common Lisp + CLOS". Then at least you'd be starting with an object system and a packaging mechanism. Sort of like Java without any defined packages. That still sounds somehow a bit pathetic.
That raises an important question. Why haven't LISP or SmallTalk attracted a greater range of capabilities, given that frameworks such as the above have been around for so long? Why aren't they at least comparable to Java in terms of deployment? After all, they're all equally expressive and equally portable in a fundamental sense.
I can only speculate that the reason has something to do with the stability of the abstractions stacked above the language itself. That's what makes Java different, and that arguably is why Sun has committed to guide its development via the Java Community Process rather than leaving it wide open.
I hate Java, please please please build a J2EE like container for python or ruby make sure it has everything I have listed above.
Couldn't you use Jython or even possibly Groovy within a container to get what you want?
In another post I read about something called "Ruby On Rails" which might be something like what you are looking for (though I doubt it offers the complete package Java has at the moment as you noted).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Java people are scary... kinda like ipod owners. Ofcourse, most java developers are probably ipod owners... Dot com all day long. I'm sure glad I haven't wasted too much personal time puking up java.
I wrote the site in my sig; it's all Apache + Tomcat + Spring + Hibernate + MySql.
Anything based on mysql is a joke.
I still must use MySQL because a few OS projects have not implemented support for it yet, but they are slowly moving towards this.
Not everything can be accomplished with a sub-query -- sometimes a join or union is needed.
SPAM solution made easy: 1 spammer, 5 cords of rope, 5 hourses, and fireworks. Be creative.
Now that the blog post is back up from being /.ed, I've had a chance to read it. My $.02: What a load of rhetorical crap. Not to be a troll or anything, but what the hell is "a highly tuned 'text pump' to occupy the fabric/bus space in a transaction-intensive enterprise data center"?! Now perhaps their software is the shiznit or whatever kids say these days, but based on that post, and based on the thin content on their site (I didn't bother with the white paper -- I hate loading PDFs unnecessarily), it sounds like a lot of buzz over mostly nothing.
If someone has to announce that what they've done is revolutionary, it's not.
putfwd.com - 1GB Free file storage with a twist
So far the money/fun/job security/supply of work have all been better for the small tiny jobs.
So, what did you use? Perl/PHP with MySQL? I'm curious. I work only with small companies and the work is more enjoyable than I imagine it would be within a large-scale project. Perl and MySQL seem to fit my clients' needs, though PHP has become an unavoidable add-on recently :-(
PHP vs. Java flame /.ters in defending such and such languages doesn't come down to a fair bit of insecurity most of the time. At the end of the day, as a developer, the technologies listed on your resume are one of your best assets for job/money/quality career.
Whenever I read that kind of thread I wonder if all the energy spent by
Reading someone hammering the languages you've spent month or years on is like reading somone saying that your experience is worth nothing! Therefore you want to reply and defend it.
The whole point is that those arguements could be most interesting but they seem to be tainted most of the time.
.kill b honi soit qui mal y pense
How can a statement that says J2EE is irrelevent be considered anything but the deliberate start of a flame war?
Whatever drug you're on, send me some.
Sorry, but that's just not true, at least not in the sense of headcount based on Java vs. LAMP as the only factor.
In most cases I've been around, the language choice is largely irrelevent (the grandparent's post about all the little nitpicky details it claims you need to learn is interesting, but ultimately just plain wrong). How the project is managed is the big factor...are the requirements and designs constantly being modified, or are they clear and relatively static? A competent Java programmer and a competent PHP programmer can whip the same application out in about the same amount of time if they both use the standard tools supplied with the language and any well-known frameworks that make sense for the app.
I can't stop laughing. Enough said
it's so obvious that the slashdot post is paid for? Don't ya love it when.... Response to that post ends up slamming the product?
Actually WebSphere is darned impressive as far as scalability goes. It even runs on the mainframe, one place supports 2million hits/day. Not bad.
"There are 20 million Indian code monkeys whom we've trained only in J2EE, Java and EJB: if you want to outsource to India for $5/hour, you'd better be ready to get the results in Java."
Need to incorporate the accounts-payable system of a newly-acquired firm? No problem, smoke a little "J" and then rewrite the 600-or-so accounts-payable objects. Now that's really smokin'. And true job security.
Just like you don't use Oracle to handle a simple little db holding some responses to a recent questionnaire or for a quick little conference, I would not use MySQL for a big data warehouse or SAP deployment.
Sure you do, if you work at a company that has an enterprise license for Oracle (or MS SQL Server), one or two servers for small relatively trivial databases like this, and that you realize that the app could grow beyond single/n5 users, or have a lot of combined knowledge and code regarding Oracle (triggers, esp. instead of triggers, are kind of nice).
C for data analysis? How about awk?
C'mon mods! That was insightful. Emacs is a very popular app, and it's mostly written in Lisp.
Please correct me if I got my facts wrong.
ActiveGrid appears not yet ready to be acceptable for IT departments. But this is still a welcome development. Other enterprise technologies (.NET and J2EE) have their benefits and disadvantages, but an open source based middleware technology helps.
0 4.php) is not sufficient to compete with .NET and J2EE and win the mindspace of "mainstream" developers (of business applications), IT departments, CEOs and other decision makers. Decision makers want their jobs safe and they always choose what they perceive to be "safe" technologies (safe for their jobs). It is perhaps understandable, but what is required is to win some mindspace. How to achieve that? It cannot be after 10 years, but may be, in 2 years.
But $3M funding (http://www.activegrid.com/news/pressrelease-1117
Have you ever seen ads for the 11-O'Clock news? A sure fire way to eat more and lose weight, something you have in your home that will kill your kids, and you're getting cancer from something in your town. Stay tuned 'till 11:25 for more details.
It's only done because it works. Keeping the pageview count low on these stories is the only way to stop them. Skip the next one.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Lisp needs an application server like Zope. Zope has driven many to learn Python so they can create Zope products.
The Yahoo! Store was written in Lisp and they credited their time-to-market to being able to do it in Lisp. Who knows what they used for a web environment?
For some reason Yahoo is moving to python, IIRC.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
It uses a markup language, runs on top of Java, and supports a whole mess of nice automatic stuff to boot.
Of course, it's not free. But it is pretty nice.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
Shouldn't the acronym in use for this stack be LAMPPP ?
Here's two...
http://del.icio.us/ (probably Perl, probably MySQL)
http://flickr.com/ (PHP / MySQL)
what a rubbish post. has slashdot turned into a kiddies flamebait board or what? Sheesh, grow up script kiddies, and wake up to the fact your stupid embedded scripting languages will never make the grade in serious enterprise applications. If otherwise you are seriously deluding yourselves.
Linux
Apache
Mod_perl
PostgreSQL
Flame away, but MySQL only barely qualifies as a database in my opinion. Now that they finally have transactions, the little bit of speed advantage they had over PostgreSQL on very large tables (> hundreds of thousands of tuples) has probably been lost. I hope someone reruns the benchmarks.
This is just pure BULL... LAMP might be good but we can;t just say that it'll take over J2EE in that aspect, it might but let's be realistic here. And hell I'm taking Programming for IT right now and they're using J2SE, i know it ain't the J2EE but I can relate, if it's gonna take over then why is the college not teaching LAMP?! Oh so insightful, I believe that J2EE will be around for much more longer time, since it has a lot more support from communities and it does WORK... BTW, I don't know much about LAMP tho, just read a bit and it doesn;t seem like anything worthy for the hype to be all this bad.
May
I don't want to start a flamewar but...
.NET doesn't come close in popularity. Python? I work for one of the biggest enterprise environments in the world (General Motors) and most people here, if asked, would tell you 'Python' is a snake. PHP? I'd lose my job if I wrote even one web application here in PHP. Why bother? If you absolutely must code in some messed up mixture of HTML and some C-clone use JSP (a subset of J2EE), it does all PHP does plus more. MySQL? If you want something free use Postgre, if you have money Oracle is the way to go. If you want explanations on this just write a complex nested query in MySQL and then do it in Oracle, you'll see what I mean.
... no offense or anything (seriously). We don't want to start a flamewar. (no seriously)
The heat against Java on Slashdot never dies. It makes me wonder. Java is the technology that is used by far in more enterprise environments than any other web application development framework.
Is it because Slashdot authors are truely concerned and support only 'Free' (as in speech) technologies and don't want the 'evil' that is Java taking over the market? Possibly. There sure are a lot of ads for proprietary software on the site, though.
Alas, look into the Address Bar and one can see:
http://linux.slashdot.org/comments.pl?
They wrote this thing in PERL?! Honestly consider the fact, that the people from Slashdot haven't written a line code in a 'real' enterprise framework in their life. The result? Someone who thinks 'PHP' and 'J2EE' are equivalent technologies.