Slashdot Mirror
Thinking about Rails? Think Again
wolfeon writes "In 2005, Derek Sivers of CD Baby wanted to scrap his site and perform a rewrite in Rails. He hired Jeremy Kemper, also known as bitsweat on Freenode, to help on the project. Two years later, through blood and sweat, the project was then canceled because of limitations of Rails. Rails just wasn't meant to do everything since it is very much "canned" project. Mr. Sivers has written an entry in the O'Reilly blog: 7 reasons I switched back to PHP."
What a waste of time. Evaluate and use new technology on new tasks.
One of my main customers hired a good team in Vietnam who used PHP, CSS, HTML, and Javascript. I introduced them to Rails a year ago, and they were just about instantly productive.
Deploying Rails can be a small hassle, but there are now lots of good options, including running on JRuby/Goldspike/Java app server.
Every technology out there has it's benefits. It's the job of the person planning the project to explore all of these technologies before they choose one. If you read his article, he makes no comments as to why he chose Ruby on Rails. Was he following the hype?
I've been involved in the decision making process to choose a technology for writing a site many times. Working for a University common questions we use in comparison to the technology is
1) Development time
2) Ability to integrate with LDAP or other existing technologies
3) Support (server level)
4) Documenation (For development)
5) Budget
6) Number of developers on the project
Depending on those variables it usually winds up being either PHP or Cold Fusion. Ruby on Rails has never once been a consideration. Not because it isn't a good solution, but it's never once been the best for our needs.
2 years on cocaine!? jesus fuck he can't have much of a nose left...
After twenty five years watching technology try to not suck, one note rings true from The Fine Article. The new girlfriend always seems better... at first. But over time you'll likely discover she too (as one might expect) has foibles, idiosyncrasies that annoy and sometimes downright frustrate.
If you've found a solution to a problem, consider carefully wrapping some other technology around it just because. Unfortunately my experience was that usually new technology/approaches typically were just because, usually driven by management (not always, and I'm not blaming them).
Had I known then what I know now I'd have fought harder for status quo on a lot of big projects.
You dont choose a project for a language, but a language for a project.
Heyho I didn't read the artical but if i've learnt anything (hahah like hell i have), then its planning is key. Plan your project and find a language that works, not the other way around.
- http://www.milkme.co.uk
It is all about choosing the right tool for a job. Sometimes you use a new tool and you wind up feeling like you are trying to put in a screw with a hammer. Sure it will work but not the way you want.
Sometimes you go back to the tool you know how to use best.
Keep the Classic Slashdot.
FOSS won't go away if Teh Lunis does, but Lunix certainly will.
Now given how Lunix is the flagship FOSSie product, it may turn out that Teh Lunis leaving would be a huge blow to teh FOSSies, but it won't go away entirely.
But either way... I don't see how this has anything to do with the topic.
"All the cool kids were using Rails, so I decided if I wanted to be cool, I had to completely switch to Rails in one big jump!"
why 7 reasons? seems like there was 1 -- I like PHP. after looking at the two languages, the guy learned a bit about OOP and applied it to PHP because he had previous experience with PHP and was productive with it.
how is this news?
There's a complete lack of points against Ruby in that article. And I don't say that as a fan, I don't know the langauge at all. It's just got a complete lack of any useful information to judge the usefulness of Ruby.
Reasons:
#1: Seems a very weak criticism, all languages are interchangeable really. Except some do some things much better than others.
#2: Internal management problem, not really related to Ruby specifically.
#3: Applies to every language
#4: Potential for real criticism here, but without any DATA it's completely useless
#5: Works for whatever language the author likes, again not related to Ruby
#6: Potential for more real criticism here, but again lacks any useful information
#7: Again something unrelated to Ruby specifically
From the whole list, only 2 of the reasons point to Ruby in any manner, and those are so uninformative as to be useless anyway. I think most of the blame for this lies with slashdot, as the article tries to spin it into something against Ruby when the actual article is more about a failed migration than anything else.
His only valid complaint was integration.
Why the hell would you take a system written entirely in PHP and add to it / rewrite some of it in a different technology?
I love Rails, and if I have my way I will never touch PHP again. But if I join a company who's intranet is all PHP, then by golly I'm going to use PHP!
This guy is a sensationalist and not worth the attention.
- I still have to program it
- We already knew PHP
- Rails has features I didn't use
- Rails has too many features
- I didn't really want to change my thought process
- I like my way of doing things
- How I justified trying something new.
I'm not saying that these aren't valid- save 1 and 3, maybe. But they aren't new, and aren't interesting.We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
While I do not doubt the hired programmers coding skills, I am afraid he was incompetent at planning.
It's like choosing ISAM as the DB engine in MySQL instead if InnoDB then expecting to implement [referential] integrity using your own code.
The fact that it took two years to realize imminent failure disturbs my mind. The worst thing is that this coder might have been an Open Source enthusiast that I'd expect to know better.
I am afraid no home work was done or whatever home work was done, it not good enough. The results speak for themselves.
The good old "Hmm, what do we need for this?" "Alright, let's take a look at our demands here." blah blah instead of some old fashioned Just do it(tm). What a waste.
The guy also mentions in his blog that his project/creation cdbaby.com comprises 100,000 lines of source code, which I find infinitely hilarious. Perhaps someone with his "talent" should leave the programming in the hands of people who know how to get things done properly. (His American style of getting things done vs the European's way of programming)
I can totally relate to this guy. I am going through something very similar, ableit on a slightly smaller scale.
We put a key system in Python a while back. After dealing with it for over a year, we are also going back to PHP. Everything else in the company is PHP. It just doesn't make sense to have this one Python. We can customize and improve the PHP a lot faster than the python.
-- -- Warning. Do not stare directly at the sun.
I read the article, and I believe the reasons the author switched back to PHP was because he was more comfortable with it than Ruby. If you read deeper, you'll note that he appreciated the experience in dealing with Ruby, and brought some of it back with him to PHP, but he did not think it was right for his application. Seeing this as a "OMG! Ruby replaced with PHP!" is just another fanboy reading into it what he will.
Time to calm down here, people. Just because one person sees value in another set of tools doesn't mean you will too.
"#1 - "IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN'T DO?
I might as well ask the opposite: is there anything PHP can do that Rails can't? Nope. PHP doesn't give me any reason to switch back from Rails. This entire argument doesn't mean anything.
"#3 - DON'T WANT WHAT I DON'T NEED"
It's the "not invented here" syndrome. "I didn't write it, so I don't want it, I want to use everything I wrote myself." A pretty weak argument.
I don't know the entire Rails core either. Nor do I have to. I use what I need, and that's it. Everything in Rails that I don't need, doesn't get in my way.
"#4 - IT'S SMALL AND FAST"
This statement is pretty meaningless without providing website statistics. How many visitors does he have per day?
"#6 - I LOVE SQL"
This is purely a personal thing. I like SQL for complex queries, but for simple CRUD operations on records, why should I have to type the same boilerplate code over and over and over and over again? It's much simpler to type than to type The former is easier to read and easier to write.
"#7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER"
I really don't understand what he's trying to argue here.
#2 is actually a valid point, but this isn't really Rail's fault. I can't argue to #5 as that's purely subjective.
I denno, I ditched Windows for Debian Linux over a year ago and haven't looked back since. (I'm a programmer though, so my needs are a bit different than your typical Windows user)
:-)
Then again, if this article is any indication, maybe I had better wait another year before I speak.
Peace sells, but who's buying?
I didn't realize Fetuses had such a command of the English language! This is astounding! We'll all have to rethink our positions on abortion now, obviously killing such a life form would be murder!
Client: "We'd like our site/new site to be Web 2.0 with AJAX and Rails and....
Web Designer: "This is the layout I've created with new logo, etc."
Client: "Ohhh, that's pretty, but I don't like that shade of >, could you make it >, maybe a couple shades darker, but brighter...you know what I mean?"
Web Desiger: "Sure"
Me: "Okay now what are you looking for the site to do?"
Client: "We want our site to be Search Engine Optimized, with built in Web 2.0 features."
Me: "Okay, SEO is not a problem, we have a professional copy writer on staff that handles the ad copy for the pages. What keywords you you like to target in search engines?"
Client: "Um...I want my page to be on the top of Google when they search for it..."
Me: "Okay, is your site E-commerce: meaning your actually going to be selling goods from it?"
Client: "No, just about our XYZ business. But it needs a Web 2.0 contact form so clients can email us from the web page and we can send them back a quote."
Me: Okay, so you need a contact form (standard feature on just about every site we do). What else?"
Client: "Well I need to be able to update upcoming events on a calender and news items."
Web Designer: "We can use Joomla for that."
Me: "Or we can find a news page script in Perl or PHP for that page with a nice easy to use backend. Same with an events calender. Then you can design your nice tabled based pages in Photoshop/Dreamweaver and I won't have to spend a week converting them to a CSS based Joomla template."
Client: "PERL? PHP? That's not Web 2.0. It's suppose to be Ajax and something called Ruby on Rails! That is what > says about having your web site designed!"
Me: *hands client copy of Cult Of Amateurs* And then i WANT TO SAY "Here read this and then get back to me about web 2.0. The short version: there is no such thing, it's a fancy buzzword no different than Dotcom ten years ago. Now we could everything you wanted on your site back then with CGI/PERL and now PHP and it will work.
Instead I say, with a smile: "We can make it work."
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
clearly, I am also slow.
We at slashdot are scientists, specialists and kernel hackers. Your FUD will be found out.
Think again ? no ! rush into rails learn how a good framework is built, and apply it to whatever technology you use. This is how i work, and it goes very well.
Derek admits it at the end of TFA, too bashfully. But i don't see any shame in having to go through rails to know how to write good php code.
Maybe he will like Ruby better than Rails? I heard that Ruby has less cruft that he disliked than Rails.
This is getting ridiculous.
Beware: In C++, your friends can see your privates!
So, we have a slow language, with ugly syntax. The ugly syntax is subjective, so we'll overlook it for now. We have a slow Smalltalk, but maybe the framework makes up for it. Looking at Ruby on Rails, it seems like a cheap clone of the old NeXT WebObjects (cloned as GNUstepWeb and SOPE, uses Objective-C, which is typically faster than Smalltalk), and so far behind something like Seaside it's not even funny.
So, why do people use Ruby? Or is it like Java, as Guy Steele said:
And you're right: we were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp. Aren't you happy?I am TheRaven on Soylent News
LISP.
Deleted
You know, the sad thing about all the comparisons you make is that they are all choices between bad technologies. Assembler vs. PL/I, C vs. Java, Windows vs. Linux--they're all questions like whether you want to be drawn or quartered, drowned or burned, poisoned or starved. At each of those choice points, there were better technologies available.
As for PHP vs. Ruby, both technologies suck: except for minor differences in syntax and object model, they are naively designed and implemented. After decades of research in dynamic languages and OOP, it is a testament to widespread ignorance that people would produce and use something like that.
But if I have to work with bad technologies, the one that's more popular, more mature, and more widely supported one is, relatively speaking, better. That's why I prefer to be poisoned with PHP rather than starved by Ruby: poison is quicker and less painful.
When you're writing a project you need to look at what your existing code base uses and choose something that integrates with it, or just stick with what you know. Every application our company uses is written in perl and they run great, HTML::Mason makes it a lot like PHP any way.
% print "Hello world!" isn't much different from
My wife and I ditched Windows for Linux 8 years ago at home. I stopped dual-booting and everything -- no more Windows, period. I still have to use it at work, but my wife didn't for years working in retail. One day, she had to use Windows at work and found it dreadful, I chuckled to myself.
:-)
Yes, some of us are very happy over the long term using Linux. Am I a system administrator? Yes. Do I program? Yes. Am I the average Joe Computer User? No. Does my wife get a free sysadmin with the ability to recode around bugs? Yes.
Just my $0.02, take it or leave it
- Michael T. Babcock (Yes, I blog)
- the question that scares me most,
- the one that you can never get honest information about from OS or component suppliers,
- and the one that's hardest to test because the most-used features are rarely those you expected.
Who said "prototype the thing, assuming a worst-case scenario"? No can do. With server code, this means you leave out features or spend $$$s more on hardware. And with client code such as AJAX, you know anything could break if used alongside idiot third-party widgets or when another IE patch makes Javascript even slower. You just don't know exactly where it will break in practice. So you add a lot of logging and try to spot when the next bottleneck is approaching. Worst case, it's in obfuscated, third-party modules that you can't change in practice, and you're re-factoring masses of code while angry villagers are breaking down the door. This is IMHO a risk with programming frameworks like Ruby on Rails, or MS dotNet for that matter.Reduce, reuse, cycle
thats because rails is a web FRAMEWORK not a programming language - you know RUBY is underneath it all, right?
people get too tied up with cms's that they think will do everything. code a plugin yourself (assuming a decent api is available).
#include <sig.h>
To me, Rails is about beautiful code. At my level of app-making, I don't need huge performance and blah and blerg. All i care about is nice looking and agile code, really.
But, of course, we all need to be told that apples is better than bananas.
The guy says he's got a company with many people already using PHP and all the systems being coded that way. It is only logical to continue with PHP and gradually improve the systems. Whether it makes sense to use Rails for any new projects remains a question. Why Rails anyway? But the reality is that if there is a team and they are familiar and proficient with a technology, then switching this technology to another one is tricky and risky. Are there any reasons for it in the first place?
There is no silver bullet. Many people believe that any new tech IS the silver bullet, in this case it's the Rails. But the reality is that at the end of it there will be the same mess in the code and the team will have to learn everything from scratch and then, once lots of code is done in Rails there will be yet another 'newest/greatest/shiny' thing that will come alone and will move Rails to the second shiny place.
The only thing that makes sense in any kind of situation is to find a suitable technology that works and stick to it, making sure that the team become familiar with it and once everyone is familiar and there are standards that are followed, the solutions will be created that will work. Then the real question will remain, just like it always remains: What are the business requirements?
Cheers.
You can't handle the truth.
The guy rewrote his code properly. It scares me when people make claims like "all business logic and HTML is separate". Of course it's separate, unless the author(s) of the code are hopelessly incompetent.
The guy says he 'loves SQL' but actually mixing SQL and PHP in your business logic is a necessary evil. I hate SQL and consider it bad form to mix it with application code. Active record and friends are attempts to closer map databases to the application language. A noble goal that ends up adding significant overhead and being less expressive than SQL. I've also experimented with automated query generation and concluded that anything above basic SELECT generation is impractical.
As for RAILS (which I don't like), the same criticisms could be equally applied to countless PHP frameworks. My custom framework now consists of a class loader and 3 - 4 supporting libs. There's nothing to enforce MVC or dictate how the framework is used because that itself ends up being limiting.
Longtime Slashdot reader, surprised to find my little personal blog post on Slashdot today, especially since the lead-in description framed it with the completely wrong point.
I never said "the project was cancelled because of limitations of Rails" - more like I spent two years trying to make Rails do something it wasn't meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.
That's all.
His reasons are pretty lame.
The biggest issue I'm having with rails is its lack of scaling due to a horrid threading model. We run mongrel, which can accept multiple requests per mongrel but only process one at a time due to Rails not being thread safe. So you end up having to run many many instances of mongrel on seperate ports to accept incoming requests. This wouldn't bo so bad, but the preferred methods of sending traffic to these mongrels(apache mod_proxy_balancer is what we use) have NO idea what the back end mongrels are doing. It'll happily send requests to busy mongrels when you have free ones doing absolutely nothing.
I prefer PHP, but this sounds too FUDish to support...
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
Am I the only one that's noticed that the site in question is pretty damn ugly and seems kinda primitive?
#6 - I LOVE SQL Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables. I was always fighting against Rails and its migrations hiding my beloved SQL from me.
Sounds like this guy dropped back to his default mode of putting a lot of his eggs in the database layer, which is good for speed. Some programmers handle levels of abstraction better than others. If he were to reapply Ruby/Rails again in a few years he may find his point #7 works against himself because he will have grown as a programmer.It would have been interesting had he listed technical more points of frustration. The high level of the article makes me think it's his own problem rather than any particular language -- he might not yet have the ability to conceptualize at a high enough level to understand the abstractions that Rails sits on. The source of frustration could be as simple as that.
Although he sounds convincing and said he hired one of the best Ruby programmers in the world the article is lacking substance/evidence/proof. If the hiree is one of the best, I wonder -- given his investment in Ruby/Rails -- what his take on the entire situation is right now? Where is he blogging about this? I'm sure he's not discarding Rails and his outlook on that situation might not be bleak. For all we know he might be frustrated because the the author could never get the damn concepts, kept complaining about his beloved PHP, etc. (Now somebody will link to an article where the hiree is proving me wrong -- which is great -- because I've been run once before and know what it feels like...)
The author argues that through Rail's faults he has learned which is a backhanded complement, decisively made, although he thinks it's true.
The article reads as a "I tried to use Rails without learning Rails or Ruby and gave up" story and then admits to using many of the Rails patterns in a home grown PHP solution. Well, obviously, if you are much more familiar with another language and refuse to learn the language underneath a framework, it will be hard to use that framework. Point by point:
1. There is nothing that PHP cannot do that Rails cannot do - Well of course, and there's nothing that any language can do that Common Lisp cannot do. Almost all languages implement a Turing machine and can be used to solve any computational problem. The question is code readability, syntactical sugar, and adaptability, all important concepts. Also, the community that has grown around it that builds a knowledge base and plugins and libraries.
2. Their entire company worked on PHP and integration was difficult - Sounds like they didn't understand RPC and services models. Sharing between different languages and platforms is an unfortunate fact of life. Also, it sounds like PHP was the problem here, not Rails, if interoperation was such a problem. "Interoperation" in the article is used oddly - it's actually more about transition to a new site, which has nothing to with the platform used and, if is such a heinous problem, is a problem with design of the new app.
3. Didn't need 90% of Rails - Then why use it? Also, using a tenth of something is not an argument against it if it still the best tool for the job you are doing.
4. The custom solution they jury rigged is "small and fast" - Many Rails apps are small and fast - there's no statistics or analysis here for comparison.
5. The PHP custom app was built for to their tastes - Obviously. If you write a custom app it will miraculously suit your preferences and will probably be a very good solution to your problem. Custom apps if you can do them are often a good idea, keeping in mind the downside is that you don't have a community of knowledge, don't get patches for free, etc..
6. He loves SQL - Fine, don't use ActiveRecord then. Or use ActiveRecord and make direct SQL calls. This goes against common wisdom, of course, regardless of platform, but if you really want to do it, it's there.
7. Programming languages are like girlfriends? - No idea.
The bottom line is that there are criticisms you can level at Rails or any language or framework. However, you actually have to bring facts and analysis to an argument, and this article offers neither.
Try Ruby, code up a project in it after you actually understand the language, and you'll see the draw. For instance, just an hour ago I was writing a quick script to recurse through directories and apply ReplayGain. I had a loop like this:
Later on, just on a whim, I decided I wanted it to sort the dir listing so I could judge how far it was through the process. I only had to change the first line:
A teensy tiny sript to be fair, but that's just an example that I was able to pull out of the last couple hours, I've done much larger things but it'd be hard to think of a good example. There's nine different ways to do everything, and they all work exactly like you'd expect. There's a million things that allow beautiful constructs, like lambda functions and yield statements, implict reference but easy to do deep copies, it goes on and on. The langugage is just an absolute joy to work with, and I'm saying this as a hard-line strict ANSI C++ programmer--so much so that I still find it hard to make myself use long long.
The problem is, it's so easy that it attracts people who hardly understand programming. It also makes you want to try out weird new ideas. I've never looked very hard into it, but from everything I've heard about Rails and its almost code-generation level programming I get the impression that it's a great idea that got over-engineered to Frankenstein proportions, like the first home project of any size a fledgling programmer makes. Not saying these guys are that ... just that's what it reminds me of.
One good measure I try to follow is, if you have to basically learn an entire new language to use your product, be it a framework or a word processor, unless you've purposefully designed it as a language, with all the deep thought that goes into that, you're probably doing something wrong. Really, the yardstick I try to go by is, you should only have to learn one thing to progress further, never two things at once, and it should always be apparent what directions are available. I looked over the Rails documentation and example source, and it doesn't meet that criteria.
Ruby Isn't Rails. Check out the language, it's a thing of beauty, and it allows you to do things really quickly, really easily, and most importantly, the Right Way without a lot of extra effort (an area C++ fails miserably at, unfortunately). No, it's not the fastest language by a long shot, but haven't we always said that premature optimization is the root of all evil? They can (and in all likelihood will) fix that later. Plus, given how easy it is to add inline C, which can easily interact in both directions, make calls, construct objects, etc... well, when I discovered that it was like I was banging a smoking hot woman, who to be fair is a little slow, and I found the keys to a Porche at the bottom of her vagina.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
Late in high school, some geek friends asked if I wanted to attend a course in PL/1 with them. I thought about it for a day or so, and came to the conclusion that by the time I got to the end of college and was out in the working world, PL/1 might be history. Then, when I got out into the working world I could learn whatever specific language I had to learn. I didn't take the course.
I'm not saying I call it right all the time. I was really skeptical about Java when it first came out, and it seems to have had a lot more staying power than I ever thought it would. OTOH, not only have I not had to code in PL/1, I've never even been at a company that was maintaining it.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Seaside would change the world, if only it had better support for templating.
Continuation-passing style web coding. *drool*
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Don't get me wrong - I'm no fan of Ruby. That said, Derek Sivers doesn't really say anything about Ruby here, except to complain that he doesn't understand it, doesn't know the standard library very well, didn't want to retrain his existing PHP staff, and has finally discovered how little of a difference the underlying language makes. He also makes the point that learning something teaches him things elsewhere, which makes it sound like Ruby is maybe his third language or so; he seems genuinely surprised that lessons learned in Language 1 carry on to Language 2. Next, he exposes his naïveté by calling PHP fast, and finally he cites his love of SQL as if it somehow has bearing in PHP vs Ruby.
Way to go, Derek, you're becoming less of a noob today. How it is that you got onto Slashdot with that little diary note is beyond me.
StoneCypher is Full of BS
You don't charge your clients based on the number of hours it takes to fulfill their requests?
For the perfect anti-Unix, write an OS that thinks it knows what you're doing better than you do and let it be wrong.
I use Navicat for MySQL and I really like it. They make a PostgreSQL version too
http://pgsql.navicat.com/
I see some similar things when I look at a variety of Java toolkits, some offering very OO "you can pretend you're a swing app and ignore the HTTPRequest cycle"
I worry that a decade of homebrew Perl CGI has warped my brain, but frankly, HashMaps wrapping HTTP Request parameters seems really natural to me, and if you use a Model2+ approach w/ servlet and JSP pairs, you're writing your business logic in Java, your HTML in HTML (well, JSP... and honestly, I don't think I've ever been on a team that manage to leverage real benefit from tricks to let you edit HTML in HTML editors, and make that round trip) your CSS in CSS, your Javascript in Javascript, etc etc.
I see the flow control stuff as glue language... directing a user from page to page just ISNT THAT HARD... and its the stuff that's tightly coupled to EVERYTHING, and so I long for that to be as simple and not-get-in-your-way as possible, so that you can spend your mental cycles thinking about the stuff that's actually doing the heavy lifting.
Lots of toolkits offer lots of neat bells and whistles, but most really imply you need to learn the whole language and often new paradigm of thinking about flow control. And unlike APIs and things, your flow control tends not to be isolatable, so if you get something wrong, it's going to be harder to work your way out of. (And the more-OO-ish you get for flow control, the harder it'll be to make sense of your stacktrace, since the danger is that you screwed up something when establishing in your objects, not when the actual interaction was performed...)
On the other hand, I know I tend to be resistant to new core server technologies, unless they make a SUPER clear value proposition. So I'm worried I'm going to be some crazy old curmudgeon. Still, like in TFA, the guy took some good design lessons from the new language, and then stuck with what people really know, and that makes a lot of sense to me.
SO YOU'RE GOING TO DIE: The Comic for Dealing with Death
My wife and I ditched Windows for Linux 8 years ago at home. I stopped dual-booting and everything -- no more Windows, period. I still have to use it at work, but my wife didn't for years working in retail. One day, she had to use Windows at work and found it dreadful, I chuckled to myself.
;-)
Funny, 10 years ago I ditched Windows (and OS/2) for Linux at home. I stopped dual-booting and everything -- no more Windows, period. I didn't have to use it at work because I was a college student and while I didn't have a wife, I had numerous girlfriends throughout that time period that had to use it when they were in my apartment or dorm. One day, I got a new computer and it came pre-installed with Windows XP and found it far more impressive than the kludge of shit I had been trying to do w/Linux to fit into a Windows world for the last (at the time) 6 years. I chuckled at myself for trying to hard for so many years when Microsoft actually had a product that worked for once.
Yes, some of us are very happy over the long term using both Linux and Windows. Am I a system administrator? No. Do I program? Yes. Am I the average Joe Computer User? No. Does my wife get a husband that understands the best of both worlds and a network that works happily with whatever flavor we require? Yes.
Just my $0.02, take it or leave it
Because we're not in 1985 anymore. In this day and age, languages are often (almost) exclusively selected depending on the APIs they offer. Not completly, but... Even if you're thinking about performance, that often even depends almost completly on the API you'll be using...
Languages are becoming more and more cosmetics, its all in the API.
It's like Webwork/Struts 2, but without configuration files.
http://mc4j.org/confluence/display/stripes/Home
"I was nearly killing my company in the name of blindly insisting Rails was the answer to all questions, timeframes be damned."
No folly is more costly than the folly of intolerant idealism -- winston churchill
boycott slashdot February 10th - 17th check out: altSlashdot.org
CakePHP ( http://www.cakephp.org/ ) is a framework with all the advantages of ruby on rails, but using PHP as it's language. So is a very good option for every PHP programmer who wants order, flexibility and ease of use, avoiding repetitive tasks such as CRUD and the use of helpers (i.e Html forms, Ajax) to increment productivity and maintenance. As stated on their website:
"Cake is a rapid development framework for PHP which uses commonly known design patterns like ActiveRecord, Association Data Mapping, Front Controller and MVC. Our primary goal is to provide a structured framework that enables PHP users at all levels to rapidly develop robust web applications, without any loss to flexibility."
For a nice introduction read the manual ( http://manual.cakephp.org/ ) and try the 15 minute blog tutorial, and for scripts, plugins, and a lot of community code try the bakery ( http://bakery.cakephp.org/ ).
Any programmer that wants Rails' advantages combined with PHP's flexibility, documentation, server support should try this. Greetings
What you should have said is "What's your budget?" "$XX00.00"
;-p way to much crap to bring along."
"Oh, well in that case we're going to have to skip straight to Web 3.0, the leaner meaner more efficient web! More ROI ya know!" "Really? What about 2.0?" "Oh that's what the expensive Agencies want to sell you on so they can charge millions for a website. They get the marketing magazines to interview them and hype it all up. BUT we are already ahead of the curve.... we do AJAX and MVC without all the overhead of RAILS or those other big packages... it's like buying an RV when you really just want to go to the Beach
A fool throws a stone into a well and a thousand sages can not remove it.
*stands around whistling, tapping foot and checking watch every few minutes*
"Ah, back already? That's a mighty nice cast you're sporting there! Now, what did you learn? And, what are you going to do next time your 1337 friends have a bright idea?"
If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.
Ah, the title seemed promising: someone had come to the conclusion that there is a world outside of the Rails hype-machine. Perhaps they were telling us to look into the truly innovative frameworks, such as Lift (for the Scala language), or even Ocsigen (for the OCaml language). But no. They decided to go back to PHP!? I am confused: is this story about S&M fetishes?
I have been using Ocsigen myself for a few months now. It is based on OCaml, so it's very high-level while still being extremely fast (it can be compiled into native code, comparable in speed to C++). Moreover, OCaml has very strong types, and Ocsigen leverages that type-safety to ensure the produced markup will always be Xhtml compliant and that there are no inconsistencies or broken links within a website. Heck, you can even extend that type-safety into the database access, so there is no chance that you'll be processing data the wrong way. And best of all, all mistakes are detected at compile-time! It really is a pleasure to use...
Why would you throw out perfectly good code and rewrite everything?
There's nothing wrong with PHP, especially if the current implementation does the job.
Wow, how did THAT happen? I replied to the wrong person in the post below... Eeesh, whoooops.
Sounds like a classic case of silver bullet syndrome to me. Develop software for long enough and
you will likely observe many who are afflicted with this nasty disorder. I cannot begin to tell you how many times I have been asked to implement the silver bullet, usually coincides with the vendor hosted golf game. Hundreds of thousands of dollars spent to implement a silver bullet that in most cases increases maintenance costs, bugs, performance issues etc and provides "zero" return on investment.
If it is not broke, don't fix it. In this case the author had sloppy hard to maintain php code
on the server. He finally came back to the solution that makes sense(fix the sloppy code) and drop
the silver bullet.
Got Code?
Rails was a 'framework' built on php. Php was something that is built on C, to work with web pages.
php is at the correct level (as far as the low levelness go), both upwards and downwards.
its low level enough to allow you to do anything that a web page can do, and its high level enough to be whats c to assembler in programming.
there isnt anything surprising with this.
Read radical news here
"1 - IS THERE ANYTHING RAILS/RUBY CAN DO THAT PHP CAN'T DO? ... (thinking)... NO."
Very weak argument. You twist Ruby and PHP with the same result. Works also well for other high level languages.
"2 - OUR ENTIRE COMPANY'S STUFF WAS IN PHP: DON'T UNDERESTIMATE INTEGRATION"
Why ditch existing programs anyway?? Why not just use it for new projects?
"3 - DON'T WANT WHAT I DON'T NEED
I admire the hell out of the Rails core gang that actually understand every line inside Rails itself. But I don't. And I'm sure I will never use 90% of it. [...]"
So in case you need a tool of the 90% you can consider happy that it already exists.
"[...] With my little self-made system, every line is only what's absolutely necessary. That makes me extremely happy and comfortable."
And if you need another feature you have to implement it yourself, rather than using the existing wheel which was implemented 10000 times before.
"4 - IT'S SMALL AND FAST
One little 2U LAMP server is serving up a ton of cdbaby.com traffic damn fast with hardly any load."
You rails application looks also very well after posted on slashdot.
"5 - IT'S BUILT TO MY TASTES I don't need to adapt my ways to Rails.[...]"
Fine, than don't use it.
"[...] I tell PHP exactly what I want to do, the way I want to do it, and it doesn't complain. [...] "
Well, and I tell Ruby exactly what I want to do, the way I want to do it, and it doesn't complain unless I make an error.
"[...] I was having to hack-up Rails with all kinds of plugins and mods to get it to be the multi-lingual integration to our existing 95-table database."
If you are not happy with a 3rd-party plugin then why not write your own? You said before that you like to write code for yourself which is absolutely necessary for you.
"6 - I LOVE SQL
Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables. I was always fighting against Rails and its migrations hiding my beloved SQL from me."
You can if you want. Nobody is telling you that you have to use ActiveRecord. And for migrations, you always can use the execute statement for own queries.
"7 - PROGRAMMING LANGUAGES ARE LIKE GIRLFRIENDS: THE NEW ONE IS BETTER BECAUSE *YOU* ARE BETTER [...]"
I don't fully understand this headline.
"[...] Rails was an amazing teacher. [...]"
It's a framework, not a teaching software. Every good specialized framework will tell you how to do the things the frameworks' way. Almost always you can roll your own way if you want/need.
"[...] But don't forget you wrote that PHP years ago and are unfairly discriminating against it now."
So, your code has feelings? Your code has human rights? This argument is not logical. Logical would be: What's the cost of riding the old framework and what is the cost of the new framework?
Well I did on my old PHP project. The PHP code was a mess, badly designed. The "version 2" is written in Rails / Ruby-GTK GUI, with complete revisited data structures, resulting in a far more flexible application.
Before posting such a pointless article, please think about what expectations you had when switching to Rails. Don't expect somebody is coding the project for you or convert your messy PHP stuff to nice looking Ruby stuff automatically.
If you don't want to re-do the project, you should better keep away from re-implementing it.
Everything you've said is good about Ruby also applies to Smalltalk, which uses blocks (closures) to implement all control structures, has trivial syntax (the entire language can be defined on a single piece of paper, and taught to small children with no programming experience in a few hours). It's obvious that the choice between Ruby and C++ is not necessarily simple; Ruby has higher-level abstractions, C++ has faster execution speed, so the choice depends on which is important. The question is, why would you choose Ruby over any of the following:
- OCaml
- Haskell.
- Common Lisp.
- Smalltalk.
These all have the same high-level abstractions as Ruby (more in some cases). They are all mature languages, and they are all 5-50 times faster in terms of execution speed than Ruby. I understand why you would choose a slow-and-expressive language over a fast-but-less-expressive one, but why would you choose a slow-and-expressive language over a fast-and-expressive one?Even Objective-C can do most of what you claim is great about Ruby, and some other things. For example, I have a category which allows me to send messages to arrays as if they were individual objects and have it perform a map operation in Objective-C, and I've implemented futures in the language, and yet I would still choose Smalltalk over it for anything where speed is not critical.
I would hope, by now, that everyone knows that pretty much any language is better than C++, so 'better than C++' is not much of a recommendation anymore.
I am TheRaven on Soylent News
I no longer enjoy comparative language discussions with people who haven't at least taken, or preferably taught, university-level course
in automata, grammars, compiler development, and who have programmed in a wide variety of language paradigms, e.g., you've got a really strong basis to compare Lisp to Haskell to XSLT, C to Java to Ruby, etc.
Otherwise it always seems like getting into an argument with users of a consumer product over which "brand" is better, and the reasoning in the argument is rarely compelling. The author had a project that failed. They think they know the reasons. That's all I can take from it.
-fb Everything not expressly forbidden is now mandatory.
I don't see how it's beautiful. To the untrained eye it looks like PERL. In addition, say it takes you 5 minutes to make a script in Ruby, and me 10 minutes to make that script in PHP. With the difference in processing time, eventually that 5 minutes will be gained back and then some. ... and I won't have to spend money buying another server once I get a few thousand daily visitors.
"The need to build the internet comes from something inside us, something programmed... something we can't resist."
This is his best point.
My VB coding improved immeasurably after I learned C#. And I'm not just talking VB6, I'm talking VB3 as well.
Learning a new language can teach you to do so much better in your old ones. I am *still* more productive, if you want something fast, in VB6 than I am in Java or C#. I can knock together a small cheap GUI very fast.
Of course, sometimes you do run into the limits of your chosen platform. VB6 strings are all 2-byte unicode internally, which makes dealing with UTF-8 a real pain. Then the ugly kludges start coming out.
The point of that particular quote is not that you should write slow code. It is that you should base your optimisations on measurements rather than assumptions -- so you only work on the real bottlenecks, so you know when it's "fast enough", and so you can make informed decisions if a particular optimisation would make the code significantly harder to maintain.
Yes, Ruby (like most scripting languages) lets you drop into C if you really need to... but that's a particularly extreme tradeoff. You should not start out on a Ruby project intending to do this, because it means that future Ruby programmers may not be able to maintain your code. Nor should you pick up Ruby on the basis of pie-in-the-sky promises that there'll be a new interpreter "real soon" that will be "real fast", because the developers might all die in a chain of freak accidents tomorrow. Use Ruby if it makes sense: if it's fast enough today, or if the improvement in programmer productivity is great enough that you can justify solving performance problems with expensive hardware.
Just bear in mind that you're measuring that productivity improvement against other faster scripting languages, like Perl and Python, not against C++. And bear in mind that there are more people with those other languages in their skillset, so they'll be cheaper, easier to find, and easier to replace. And bear in mind that Ruby is currently a fad, so some of the people who love it today are fad-chasers who will leave your company like a shot when the Next Big Thing turns up...
Ruby's the right tool for some jobs, but it's running a grave risk of being a victim of its own success, because when the pro-language hype is way up, so is the anti-language hype whenever anyone gets burned. Maybe you evangelists should cool off a little and prove Ruby's virtue by using it to make yourselves rich, instead of claiming that it's the best thing EVER because it, like, makes it really easy to recurse over directories, just like every other language apart from C++!
I'm not sure what you're doing in this discussion if you can't make a good guess as to what's in the recurse() function for the purposes of this discussion.
You also seem to have missed the fact that Ruby isn't Rails.
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
So, first a straw man, and then an ad hominem. Good to see your debating skills are on top form. You might find this set of weightings interesting. Two things are taken into account; the CPU time taken to run the code and the amount of code required to solve each problem, with a 1:2 weighting (concise code more important than fast code). The code complexity is determined by stripping comments and gziping the result. With these weightings, Ruby comes out ahead of two languages: Tcl and Prolog. Since Prolog is a highly domain-specific language (gorgeous for some things, a nightmare for others), and Tcl is a cruel practical joke, this doesn't seem like something to be proud of.
I am TheRaven on Soylent News
"Rails was a 'framework' built on php" ??
Rails is a framework that built on top of Ruby , don't you know that ?
before given any comment , please make sure you know what you are talking about,
otherwise, futher discussion is meaningless.
Anyone who (re)designs a web site just so they can write it in gobblydegook (or whatever) isn't making any business sense.
There may only be 2 large websites in the world written in C++ (actually there are probably more), but if you are looking to write large websites with many tools and features and dynamic contents, check out OKWS. It's a platform for written large web site/application in C++, with security and performance advantages.
Why don't you want to write in C++? It's too low level and does not have a lot of the abstractions already built in, like PHP, perl, etc... But OKWS offers those abstractions, from perl like regex and string operations, to all the CGI things you need. Plus reference counted memory and asynchronous callbacks. It's like written a big C++ application, but for the web. Really, it's not bad.
I'd just like to point out that the parent is decieving. He's not a programmer. According to his website, "Bill is employed by Century College working on developing new recruitment and retention programs." I seriously doubt that means programs in the slashdot sense.
He's just pissing in the GP poster's cornflakes; he isn't for real and should be modded appropriately. His only technical qualifications seem to be messing with his own blog, which he describes as "working on the website."
Don't take my word for it though -- follow the links and decide for yourself how technical Bill might be. I personally have formed the opinion that he's a cereal-pisser.
Here's his own list of articles with a more technical bent:
http://www.lazylightning.org/taxonomy/term/6
I have only one thing to say about Rails and that is "waiting for twitter.com..."
Here's the Java version (give or take a bit):
parseFolders(File target)
{
for (File item : Collections.sort(target.getFiles()))
if (item.isDirectory())
parseFolders(item);
else
someAction(item);
}
Here's the Perl version (give or take a bit of syntax):
sub parseFolders()
{
my $target = @_[0];
foreach my $item (sort $target->files)
{
if ($item->isDirectory) {
parseFolders($item);
} else {
action($item);
}
}
C++?
parseFolders(Folder folder)
{
folder.sortByName();
for (int i = 0 ; i folder.getItemCount() ; i++)
{
File file = folder.getFileItem(i);
if (file.isDirectory())
parseFolders(file);
else
action(file);
}
}
My point? Syntax is syntax. Evaluate a language based on it's toolkits, libraries, code maintainability and performance. Almost 90% of the time language choice doesn't matter much for single website projects with less than 25k lines of code (and I mean proper code, not hotwired bodge).
Catalyst, Baby!
http://dev.catalystframework.org/
Be heard || Be herd
Rails did not invent MVC, nor did they invent scaffolding or any of the other stuff. They didn't even make it popular. Very many people get these facts wrong. The only thing Ruby On Rails did as a first was to apply professional marketing strategies when trying to make an open source web application framework popular. They were the first to build a project website that was appealing to the eye more than anything else and they heavyly pushed the concept of the screencast, right when broadband was becoming commonplace. I'm shure almost everybody has watched that famous 'a blog in 15 minutes' screencast. This screencast alone made Rails (and the editor presented in it, Textmate) extremely popular.
Technology wise there are many frameworks and webkits that are far more mature and far more sophisticated than Rails and have been around for 6 years and more.
We suffer more in our imagination than in reality. - Seneca
I've been interested in learning at least one of those languages for a while. Usually what gets in my way is that I can't find the necessary libraries to complete whatever task I'm working on. Can you point me towards the language from your list that has:
* a rich standard library with a good reference
* a good extended library like CPAN
* easy extension in C
* good documentation
* easily available compiler, etc.
I don't mind buying a book, as long as I can get somewhere just from the online documentation. Out of the languages you mention, I got the furthest with OCaml. However, if I needed to do something simple like connect to a database and then contact a directory server using LDAP, I'd be lost.
Social scientists are inspired by theories; scientists are humbled by facts.
Doing rails is very bad... steer clear of drugs.
(The post below provides insight into the situation. It was posted as a comment to the original blog. Another thing that comes out in the comments is that Derek has some serious issues that likely exacerbated the problems.)
I'm a little reluctant to add to the wasteland that is this post and these comments, but here goes.
I'm familiar with the situation here. The deal was this: Derek was not a programmer; he was a musician. He learned some PHP and cobbled together the old CDBaby site by himself. It was good.
Then, he heard about Rails, and became infatuated with it. He proceeded to attempt a rolling rewrite of CDBaby's frontend and backend both (the backend is large, because of inter-label and digital distribution stuff) in Rails.
At this time, Derek had no experience with the following things:
* any language other than PHP
* systems integration and interoperability
* Rails
* object-orientation
* the MVC pattern
* managing a development team
Project fails. All right. As he has learned in #2, legacy compatibility trumps everything. Also, ship early and often.
As you can see in Derek's post about MySQL encodings, he's not always the clearest thinker. Even above he says that REST means POST-only destruction, which misses the point entirely.
His team was fine (mostly just Jeremy, until another developer was hired in the last months). Rails was fine. But there were a lot of things wrong with the project plan ("rewrite everything, eventually") and with the project leader, who was convinced he had found a silver bullet.
No framework saves you from your own inexperience.
Out.
wellwisher | September 23, 2007 01:47 AM
Not exactly. I actually chuckled when I saw your example, as you obviously have *no* idea about what Smalltalk is, and why your example is ridiculous in the context of the discussion.
Of course, Ruby is better than C++, closure are cool, etc, etc. But your example would work even better in Smalltalk, and the grand-parent was specifically asking about why choosing Ruby over Smalltalk.
The site is... well ugly, and I wouldn't be surprised if this was a article created only to plug your site. You need to shift your focus to design.
...well, when I discovered that it was like I was banging a smoking hot woman, who to be fair is a little slow, and I found the keys to a Porche at the bottom of her vagina.
I really can't get past that bizarre analogy, dude. Blecch. Also, why did you need the keys to the porch?
The best language to use is the one you KNOW best ... as long as it is at least up to the task for the project you have in mind ... and as long as the project needs no more programmers than you plus whoever else also knows this same language best. Yes, even the C language can be best for a project if it is what YOU know best how to code in.
If you know all the ins and outs of a language, and have a strong grasp of what all it can do (most languages can do almost anything when coded by a programmer that knows it well) and cannot do (usually this is a function of the inverse of how well you know the language), then that language can work.
Now, would that language be the most optimal for you to choose. Maybe not. If you factor in the time and effort to learn a new language well enough to know all the ins and outs of it, you very likely have added a huge amount of time to a project. Learning a new language that has more advanced tools that will let you develop faster and better is probably a good idea. BUT ... that learning process should not be tied to any immediate project. Think back to the things you did when learning the language you know best now. They were more than likely a lot smaller and more trivial than what you might contemplate doing today. That's a factor of your experience, particularly with the language (the same can also apply to the systems that will be used). Go ahead and learn a new language for the future doing smaller tasks with it, and grow them as you learn it. Use the language you still know best for the major tasks, even if it will take you longer to do them in that language than it would take for someone experienced in the new language to do it in the new one (because you are not yet that programmer experienced in the new one).
Teams needs to be homogenous. Ironically, one good programmer can do alone a lot more than a small team can do. But some projects are just too big for one programmer. When you need a team, make sure they are all experienced at about the same level in that language AND they all consider that language to be their best language. The project lead is the only exception and can be more experienced than the team, but must still consider that language his/her best.
now we need to go OSS in diesel cars
This has little to do with Ruby vs. PHP -- this is the classic second-system effect. When you do your big rewrite, you are so determined to avoid all the limitations of the first version that you keep making it more and more elaborate. You often give up, get very practical again, and create a small, useful, 3rd system.
Rails was not at fault here. The fault was expecting Rails to be a silver bullet....that just by choosing Rails, everything will happen as if by magic. They ignore the fact that Rails can't do everything. If it tried, it would become bloated to the point that people start talking about it like they talk now about Java. Writing in Ruby, clean and elegant as it is, doesn't change that fact.
Some people even act like it's the Apple IIGS.
I suggest you read Slashdot
To clean it up a little more:
Dir.entries(target).sort.each do |entry|
if File.directory?(entry)
recurse(File.join(target, entry))
else
dostuff(target)
end
end
- any language other than PHP
- systems integration and interoperability
- Rails
- object-orientation
- the MVC pattern
- managing a development team
Project fails. All right. As he has learned in #2, legacy compatibility trumps everything. Also, ship early and often. As you can see in Derek's post about MySQL encodings, he's not always the clearest thinker. Even above he says that REST means POST-only destruction, which misses the point entirely. His team was fine (mostly just Jeremy, until another developer was hired in the last months). Rails was fine. But there were a lot of things wrong with the project plan ("rewrite everything, eventually") and with the project leader, who was convinced he had found a silver bullet. No framework saves you from your own inexperience.First off, he seems to think "Rails" is some kind of programming language. He failed to see it's merely a framework for Ruby, and that if the framework was getting in his way, he could just use bare Ruby. Ruby has a few questionable spots, such as the terrible Perlish syntax, half-assed first-class functions (different namespaces for functions and other values, as in Common Lisp, unlike Scheme), and difference between blocks, methods, and such, but it's undoubtedl superior to PHP, so provided you don't depend on some PHP library or extension that's not available on Ruby, it's going to be a more productive language to work in than PHP, as long as you hire the right person.
Second, he's a buzzword bingo. "Business-logic"? Only clueless people talk like that. He probably wanted Rails because of the hype, too.
Third, he was probably thinking things the wrong way; trying to make Rails work like PHP. You can't just rewrite programs for a completely different platform; you have to redesign them as well. He fails to understand this basic principle.
Fourth, "Is there anything Rails can do, that PHP CAN'T do?" Well, and I ask, is there anything PHP can do that 6502 assembly CAN'T do?
Fifth, "I realized the language didn't matter that much." At this point I stopped reading. This guy is really clueless. If language didn't matter much, we'd all be using FORTRAN. If this guy thinks it doesn't matter whether you do C or you do Python, then he better do something else but stop programming, much less managing programmers.
I was about to say 13256278887989457651018865901401704640, but it appears this number is private property.
Not exactly. The point of the poster was how easy he could turn it into a "sorted" parse routine.
Of course, it is easy as hell in any modern language, but just don't blow his ruby bubble for now.
Did you switch the platform you were developing on, or just what you used as a desktop?
I imagine learning new APIs (and possibly languages) takes work, but switching from one GUI desktop to another is easy. All the more so as Linux desktops default to a Windows like config.
Getting back to the topic, changing the platform you are developing on for no good reason is a lot of unnecessary work.
...stupid decisions based on myth over reality. You have front end people making decisions about browser security in utter discord with back end choices made for functionality. You have redesign of existing functional systems without starting back at the design specification. You have scale failures because you didn't test your nonexistent spec. for scale.
I'm glad I don't work there.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
Linux also represents something significant. Essentially it has come to represent a set of software that does things in a standard way that multiple businesses can implement and compete in a compatible way. This is the key thing that pushed the PC architecture, competition. You can choose Ubuntu, Red Hat(Fedore/CentOS), SuSE, Debian, Mandriva, Gentoo, or any number of others, and still run the same software. You can pull one together yourself if so inclined, or use a community maintained one, and/or have commercial support. MS rode the PC platform to success because they were the only software company to support it on arbitrary hardware vendors. So powerful was this advantage that the industry essentially gave them the monopoly before any other company had a serious offering to consider under the same terms (They had it pretty well gotten by Windows 3.0). Now Linux can represent the same phenomenon, but for the operating system. In order to overcome MS, it's had to be truly Free, but there remains a healthy commercial environment around it.
XML is like violence. If it doesn't solve the problem, use more.
I have a History BA with a CS minor. I am quite familiar with C/C++, VB/A, Perl, Bash shell scripting, awk/sed, numerous database software (mostly Access in my job but also mainly MySQL with PHP) and have experience (not daily) with various other languages.
While I was trying to be "+1 Funny" and don't expect Insightful or Informative mods, I am far more experienced in technical matters (mostly for my job that's GIS) than you make me seem to be by the limited postings of that nature on my website.
So obviously Rails wasn't suited to what they wanted to do (if they are doing things right is another matter...) and they didn't realize it.
It's as if you used a knife to eat porridge: sure you can, but using a spoon might be a better idea (or you could add a fork to the knife and eat a juicy steak with french fries).
This guy isn't informative. He seems to infer that I'm not telling the truth that I've been a Linux user for 10 years (I have). He also seems to infer that because of my career choice that I don't know how to write programs.
This A/C from Illinois isn't Informative, he's just a troll and should be modded appropriately.
for file in `find . -type f`;
...
do
dostuff $file
done
or
for file in `find . -type f | sort`
do
dostuff $file
done
It's just as easy in php, or perl, or...
I'd love to know how Django compares to RoR. I like Django, though I've not written anything meaningful with it.
Right. Who wouldn't love Ruby with such obviously clear syntax as this?
Meh. That's hardly impressive, unless if someone has never seen a dynamic language.
I like Python's version better:
for root, dirs, files in os.walk('/home'):
for file in files:
do_something(file)
If you want to sort the directories as you recurse through them, add 'dirs.sort()'.
If you ask me, Ruby is like an ugly Python.
DFTT. Kthxbye.
1/3 of jokes get modded OT. If you get the joke, mod 1 in 3 insightful/interesting/underrated to restore karma balance.
... route is probably the one you know.
TC - My Photos..
If I wanted both language features and speed, I'd be opting for OCaml or GHC. Probably OCaml. Maybe Erlang if scalability was the primary concern.
When speed and scalability don't matter as much, Ruby gives me a syntax that's easy to think in. Especially if text processing is going to be a significant factor. I really don't care for the regular expression situation in any of the four languages you listed. Ruby's regular expressions still don't handle Unicode, and there's issues in certain cases with really big regular expressions, but the vast majority of day-to-day coding doesn't hit those issues.
The nice thing is, I typically deal mostly with http and friends, so mixing and matching languages is usually just a matter of http clients and servers, sending and receiving resources.
You should be able to do both with OCaml.
http://sourceforge.net/projects/ocamldap/
http://merjis.com/developers/pgocaml/
Haskell is actually used in the real world? Between the unpredictable whitespace rules, the rather ugly syntax and the fact that half of it consists of a procedural paradigm shoehorned onto a functional language I always assumed that its only use was as an example of functional programming in Programming 103.
(As for why someone would choose Ruby over it: Coding performance. Most people are more comfortable around procedural/OO languages like Ruby than the functional/procedural Haskell with its Monads.)
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
Take a look at GODI. It's not a big collection of libraries and apps like cpan, but includes the libraries you just mentioned you needed (postgres,sqlite,mysql and ldap).
http://godi.ocaml-programming.de/
...and I found the keys to a Porche at the bottom of her vagina.
Ow.
It's better to vote for what you want and not get it than to vote for what you don't want and get it.
- E. Debs
I am TheRaven on Soylent News
Well, Rails is presented as the Next Big Thing in web development and people were going on about how awesome it is and how it makes web development so much easier etc. Ruby was never presented as a web development thing, it was always Rails. On the other hand, PHP has zero credibility as a general-purpose scripting language, it's usually only seen as a web development tool. So he compared one web development environment (PHP) with another (Rails). Quite sensible, in my opinion.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)
As you may already know, every situation has its requirements; some require fast execution, others require fast prototyping, etc. My point: judging a language merit only by its execution speed is not smart.
I have come to Ruby after learning BASIC, C, C++, PHP and Perl, in that order. Ruby seems to me like an step further in my evolution as programmer. If I want execution speed, I use C. If I want development speed, I use Ruby.
Being said that, I'm really curious about the languages you mentioned. Learning Ruby helped me to widen my view about programming and languages, because Ruby itself is an hybrid of concepts taken from other languages like LISP, Smalltalk and Perl. I've _played_ with Lua, Smalltalk and Common Lisp. Haskell is in my to-do list.
I still prefer Ruby because it has all the features from those languages (all the features that I care of) and a syntax that is familiar to me, plus the amount of libraries available.
By the way, execution speed is being targeted in Ruby 2.0 (as you may already know) with YARV.
The best way to predict the future is to invent it
Thanks. After I posted I did indeed find those libraries (I posted quickly, based on what I remembered from OCaml before). It looks like OCaml is the most practical to use out of those listed based on the number of libraries available, tools, and documentation (the base documentation is quite good). I should also spend some time learning how to write OCaml extensions in C, hopefully it's as easy as writing extensions for python or ruby.
I think my standards are a little too high with something like CPAN. I don't think Ruby has anything close to CPAN, especially when it comes to documentation.
Social scientists are inspired by theories; scientists are humbled by facts.
"While being away from Ruby land, I did investigate the OCaml language
.h file, you write a similar line in OCaml and use it as if it was a
:-)
further.
I've earlier posted some information on OCaml in this group when I was just
starting to look at the OCaml language. This is a follow up after I have
gaining more experience.
I can now confidently say that Ruby and OCaml are at the absolute top of
programming languages. I'm a bit annoyed with the fact the OCaml is in fact
so good the it steals ground from Ruby. Its a bit like a Japanese
sportsmotorcycle compared to a European ditto with the nationalities
reversed.
OCaml with static linking with C object files is better suited for large
system applications than Ruby both becuase its faster and due to
distribution of runtime as exe rather than clear source files. What really
surprised me was that OCaml actually competeded with Ruby in the discipline
of rapid prototyping and still managed to produce better code than carefully
developed C++ code requiring significantly more development time.
Still many bright things are happening for Ruby and I am certainly not going
to dismiss Ruby.
I'm looking forward to see Ruby increasingly involved in building the future
Web both via integration with Apache and the support of Web Services where
Google have been kind enough to be a Ruby front runner. And this is possible
the best recognition you can get, because I can't think of a greater
application the Google.
Ruby on the other hand is class example in OO development, but what is
really great OO or not, is that you can actually write modules of 2K size
that does meaningful things and plugs seamlessly into the development
environment.
Ruby initially impressed me with huge number of highly functional but
redicously small library implementations in native Ruby. I spend hours
searching for what the rest of the a database interface because it couldn't
possibly all be in those 2.5 K.
You can also write suprisingly short programs in OCaml, but overall there is
more fuzz with getting the source file dependencies right in the makefile
which also complicates integrating third party tools not in the standard
distribution.
While Ruby is a language with one of the easiest FFI's (foreign function
interface), it is actually easier in OCaml. In fact it is so easy that
provided you stick to certain datatypes, it can be almost be neglected
whether you write a function in C or OCaml: Instead of writing a C prototype
in a
native OCaml function. Accesing OCaml in the C function requires a macro on
the argument to get the desired C type, not unlike Ruby. Callbacks the other
way around is also quite managable although not as trivial. I once looked at
an enormously complex JNI interface, only to discover that this was the new
greatly simplified JNI interface... go figure.
The OCaml syntax is not the best I've seen, so I tried to imagine all kinds
of improvements. However, once I got used to it, I still didn't quite fancy
it, but I was hard pressed coming up with anything better that would be
equally efficient. OCaml is as terse as is possible without becoming
entirely unreadable. I think you could actually mix some of Ruby's syntax
with OCamls functional concepts and get an even greater language. Must do so
one day
It appears that you actually write shorter programs in OCaml than in Ruby,
however, you also maintain separate interface files for larger programs.
I wrote a Ruby hack to convert Yacc grammar file into a Visual Parse ditto.
This included lineparsing and grabbing a name, making it upper case and add
a counter for each alternative of the rule. Ruby is a natural for these
tasks. I started out doing a manual conversion, but halfway down realized it
was actually worthwhile to write a Rubyscript just to complete the other
half. And it actually was faster
The article summary (no, I won't RTFA, not with a summary like this) suggests they have no idea that Ruby can replace PHP and that they needn't use Rails at all. They sound as if they think Ruby is Rails, and that PHP is somehow superior because the Rails framework failed them.
If this isn't the case, ban the summary writer from ever submitting again. Maybe we can get better summaries some day.
grey wolf
LET FORTRAN DIE!
Something tells me the ongoing prejudice against Perl has a lot to do with organizations (or devs, or management) taking up the latest and greatest technologies such as those being disputed in this branch. All languages are going to have their quirks, but there is a simple performance tradeoff for enduring the idiosyncrasies of Perl. Nothing matches mod_perl for performance yet, besides C itself. Java? No. RoR? No. Python? No. While all of the language alternatives in this thread may all have modernizing advantages over Perl, its hackish OOP and its questionable maintainability, many of the criticisms are based on intellectualizing the problems involved. Many times it is just that someone thinks their pet language is better for arbitrary reasons. They were taught it in school, there's a universal force that draws everything to pure Computer Science ideals, there's money in them thar buzzwords, etc.
Non-technical reasons very much outweight technical reasons to choose one language over the other.
When I was a kid, we only had one Darth.
After twenty five years watching technology try to not suck
If you've found a solution to a problem, consider carefully wrapping some other technology around it just because.
If you had been around for thirty five years instead of just 25, you would have fought the introduction of the microcomputer, the GUI, and the mouse. And frankly, you've been around long enough to have seen the conversion from C to C++. In fact, I find it interesting that you consider Windows the status quo that should be defended--there was as day, not too long ago, that it was the new thing on the block. Would you have resisted it's adoption then, simply because Windows was the new girlfriend?
I think what you mean to say is that 90% of all new developments suck. But it takes awhile to find the 10% that are truly useful, so we have to explore each development in turn. If you believe that 0%, or 100%, of new developments suck, you're going to either waste a lot of money, or stagnate.
ps If you really think we would have better off with neither the mouse nor the GUI, you need to pull your head out of your ass and take a look around--it's the 21st century, where everyone has access to a computer.
--
$tar -xvf
I was with you up until the "advancing arguments they couldn't possibly believe" bit. That is ridiculously arrogant of you to say. People do have different beliefs than you do, you know. Just because something doesn't fit through your filter, that doesn't mean it isn't perfectly logical to somebody else.
Slashdot - where whining about luck is the new way to make the world you want.
It could have been worse. We had an embedded product written in C and as far as we knew it was doing fine. Then our lead programmer discovered FORTH.
Seaside would change the world, if only it had better support for templating.
That's pretty much wrong. For once, it's trivial to implement templating in Seaside. And guess what ? there was at least two or three templates implementation for Seaside. What happened to them ? I'm not even sure they are still maintained (I'd doubt it in fact). Why ? simply because templating brought little value to Seaside.
Templating was crucial ten years ago. WebObjects was fantastic for that for example. But now, with CSS ? screw templating ! it's much, much better to have programmers outputing html via seaside and designers putting nice CSS clothes on top it.
Why better ? because if you do it like Seaside does it, eg not by directly mixing HTML code with actual program code, but by having an "HTML" api in your language that output the html... well, you have all the joy of using Seaside (Smalltalk) development environment, the refactoring tools, etc, that apply to both your code and your html. There is thus no difference between refactoring your code and refactoring the html code -- they are both smalltalk code.
when I took a real emotionless non-prejudiced look at it
That excerpt id actually the core of what I would call professionalism. You do not let fear, predjudices or infatuation with new technology drive your decisions, you instead take a dispassionate look at the problem and then apply a solution. You use the right tool for the job, regardless of your personal prefs.
Many of you will read this and say "welll Duh!". But I have been constantly shocked how little this approach seems to be used in IT. Anyone else agree/disagree?
putting the 'B' in LGBTQ+
I read the blog post, and it confused me. Nowhere do you describe what it actually was that PHP supposedly does but Rails does not. Instead, the entire blog post glorifies PHP while not specifying what "limitations" of Rails held you back.
So... what were they, in your view? I think that would clear up a lot of confusion/misunderstanding.
For the record (out of interest), I've run primarily a mix of Enlightenment with Gnome over that time period and several good KDE apps like Kopete and Amarok. There are indeed features of Windows XP I like, and I generally find its integration of its own apps to be a bit better, the performance and reliability of my desktop far outweigh those minor features Windows may have a one-up on.
Having customized my desktop menu and hot keys in Enlightenment, and having applets and Epplets installed to taste, I also find my Linux desktop(s) prettier than Windows, but some may disagree of course.
- Michael T. Babcock (Yes, I blog)
The story you describe is still all too common, and I think that is the case because, though you make some appropriate observations you actually miss some very important conclusions as well. Primarily you have concentrated on the poor technical choices and neglected the flaws in project management and execution.
While you are right in stating that in IT projects one must proceed with caution at times when choosing to implement new technologies, you have placed an over-emphasis on sticking with what is "mature", "well tested", "traditional". There are pitfalls to sticking with what works as well--in the form of missed opportunities to improve efficiency and competitiveness. The key is in WISELY choosing new technologies, and that very much involves employing real engineering principles and effective project management (all to often the latter seems to be an oxymoron, because there are too few effective software/IT project managers out there--the field is really still quite new).
You start to key in on the root cause of this disaster when you suggest "get user feedback on software early and often". If you wait until there is software for them to give feedback on you are ALREADY TOO LATE. Before one single line of code is written, or one single software licens is bought, or even one single computer purchased, you must involve the end users in a formal "requirements gathering" process. If the project is a replacement of existing infrastructure you must observe the legacy system carefully. Not only is is it important to see what functionality needs replacing, it is also important to try and pull out of the end user what they don't like about a system and to carefully observe when users are compensating for a system's shortcomings. No mattter how efficient and reliable the old system is, in my experience there are ALWAYS shortcomings that can be addressed with new technologies. Some observations I've made that are signs a system could be improved:
* The use of Microsoft Excel in normal information management processes. This is by FAR the biggest, most obvious sign that there may be a systems integration issue. Excel is a fine spreadsheet for most people so don't take it as a slight against that product itself. However, EINAFDB and EINAFRE (Excel is not a f'ing database and Excel is not a f'ing reporting engine). The same could be said if it was OO.o Calc or Gnumeric being used the same way. Hell, it is even OK to let the abuse of the desktop spreadsheet slide from time to time. The key is, are the SAME spreadsheets used ALL the time and are a part of "normal operating procedures", and to they involve little to no numerical analysis (ie. they are "data entry forms" or "data tables")? In those cases, their systems are probably sub-optimal. A spreadsheet is for crunching numbers--doing elabourate calculations--and presenting those numbers in an "all at once", interactive fashion. It can occasionally be used for ad-hoc reporting/data processing (though that is a minor abuse, it is an acceptable one). Otherwise it is like using a butterknife as a screwdriver or your shoe as a hammer--it might work "just well enough" but it can be done a lot better.
* Manual data entry, especially from data sources that were obviously sourced from electronic systems. Do the users "cut and paste" from one screen to another a lot, or sit in front of an emulated terminal and type numbers from a dot-matrix printout or a printed report faxed from another department? It is time to ask where the data originates and the nature of that originating system. Also, keep in mind that manual entry can include "semi-automated" processes. Are they manually opening an MS Office file and launching macros to complete a step in a process? After identifying those sources of data, look at data entry from handwritten, verbal or visual sources. Does the data come from a paper recording chart, clipboards carried by operators, reading instrumentation on an old control panel? If the info is really important to the client,
Ruby also still has problems with unicode support. Suprising for a language first developed in Japan.
I use python a lot, and each release seems to remove a few more warts. I also think Groovy will be sweet once it stabilizes.
Here's an interview with Derek about his decision to switch to Rails in 2005, read together these two articles make an interesting case study... http://www.oreillynet.com/ruby/blog/2005/11/migrating_to_ruby_on_rails_and.html
The original Slashdot post implies some things that are not substantiated by the actual content of the article (blog post). It sure seems as though the poster him/herself has something against Rails.
The actual blog post (and poster) imply that Rails was not designed to do things that they were trying to do. That may or may not be... but that is not the fault of Rails. If the tool was inappropriate for the project, then the project manager should have determined that before starting.
Also, while it is implied (and even stated) that Rails was not designed to do these things... nowhere is he specific about what those things actually are. Rather than berating Rails, the blog post glorifies PHP. Those are two very different things.
In introductory Business Law at my college, there was discussion of the classic case of the tavern visitor in the 1700s who stated "My horse can pisse better beer than this!" (sic) The tavern owner sued the patron for slander. (In those days most taverns made their own beer.)
The judge ruled that the statement was not slander, because the customer did not insult the tavern owner's beer at all... rather, he had complimented his horse!
There really is a big difference. So... I want to know what he does not like about Rails, since he really did not explain that.
No programming language is so inefficient that you'll notice a performance difference in a web app for thousands of daily visitors. Not PHP vs. Ruby. Not a Scheme interpreter written in Visual Basic 2.0 vs. hand tuned assembly language. Web app throughput is measured in requests per second on modern servers (usually thousands or tends of thousands, but maybe hundreds for the Scheme in VB thing), and there are 86,400 seconds in a day.
-- The act of censorship is always worse than whatever is being censored. Always.
On a practical level rather than a "my code is more beautiful than yours" level, one answer is simple: deployment. If you're writing a program that's intended to be used pretty much just by you (or other people on your dev team, perhaps), it really doesn't matter what you write it in. If you're writing a program that's going to have to be rolled out to production systems that you don't have absolute control over -- like, say, a commercial web-hosting service -- there are new issues.
Ruby is getting a lot of attention because of Rails, and Rails' attention is making it moderately easy to find web hosts that support it. It is easier to deploy a Rails application than it is to deploy a Django application, if you're taking into account "I must find a web host that supports my framework/language." If you are writing, a web app in Smalltalk using Seaside, well, not only are you definitely not shoving that out to your $8/month Dreamhost account, the chances are you're going to have to have complete control of the production side (i.e., colocation or self-hosting). Also, of course, if you're writing for a business, maintainability becomes an issue with any "obscure" language: eventually, the original development team won't be there, and if you can't replace them because the dozen other people in your area who know the language you chose are happy at the research labs they're working at, you find yourself in a very uncomfortable place. I've heard the even a kindergartner can learn Smalltalk so fast they'll be writing complete CRM systems in a week! speech, too, but in practice it seems those kindergartners are few and far between.
Frankly, deployment issues are one of the reasons I'm slinking back to PHP myself; as much as I love Rails in theory, as it turns out, in practice Rails is a sufficient resource pig that many shared hosts that claim to support Rails put serious limitations on it unless you bump up your service level. (I know I'm inviting arguments from Rails fans here, but yes, I've really looked into this.)
One thing I want to add is that lately a lot of projects have started adopting languages like Ruby because it attracts programmers who want to code in the language, not programmers who already know the language. I probably wouldn't go this direction, but given the shortage of decent programmers, it might be the only way to get some great talent on your project.
Captcha: poison
One less person telling everyone else what to do.
I mean, really. Can you imagine getting 95 legacy tables into ActiveRecord, and actually convincing AR to behave properly under load? Good luck with that.
Also, if the new app had many integration points with PHP systems, that could be a fun one to work out. You can't, to my knowledge, just include a PHP library in Ruby.
I've done projects in Rails, and I happen to detest PHP, but if a client approached me with the following tech specs:
- 95 tables
- high load
- many integration points with PHP
- possibly more than one database? (I don't know this to be the case, but with 95 tables, I suspect more than one database)
- much i18n
I would have advised against RoR.I mean, really. Use the right tool for the job. Don't use a framework that is going to be fighting you instead of helping you.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
A colleague has been learning Common Lisp and is using SBCL and it has cored on him more than a few times in the past few weeks. According to him Common Lisp is great but SBCL is not production ready and there is no free Common Lisp that is, so if we are to use a Lisp it'll probably have to be something like Allegro.
;).
/dev/null) for daemons/servers because daemons aren't supposed to output stuff". While I do agree that daemons aren't normally supposed to send stuff out via STDOUT and STDERR, that is exactly why I want such output to go to syslog (or the equivalent)! Believe me it has been helpful. Even if your code has no bugs that show up that way, you could find bugs in 3rd party libs that you use ;).
I also did try learning CL, but I personally found it hard to find out how to write production code in Lisp - most of the examples on the web are all very nice for CS stuff (e.g. run this from emacs via slime) , but not real world stuff. While you're strictly in the Lisp world everything is nice and all that - 101 ways to do "fibonacci" etc, but seems like the lisp docs are written by people who are so much smarter than I am that they probably find a lot of things so obvious that they don't list them in FAQs
Example questions I asked:
How do you compile and make an SBCL program executable? (I know now, but still...).
How do you trap and handle posix/unix signals? (not sure the ways I found are best practice)
How do you redirect STDOUT and STDERR to syslog?[1]
Any examples of production style boilerplate code?
How do I write a program that listens on UDP port X on all interfaces for packet and know which interface each packet came in from?
I'm currently using Perl and it is a lot slower than sbcl but so far it hasn't cored on me for a long while. With the exception of the last item the above sort of things are also easy or not too hard to find out (just man perlipc gives a lot of real world details).
I would like to learn a _fast_ high level language AND be able to use it to write production grade code (and no, I don't regard Java as high level, even if you program your java program to do XML and reinvent lisp badly).
[1] I do this for most of my programs. I disagree with people who say "STDOUT and STDERR should be closed (or sent to
I usually try to get it prefixed by the program name and PID (or parent PID) e.g.
Sep 22 03:07:16 host progname[1312] STDOUT: <std output here>
Sep 22 03:07:17 host progname[1312] STDERR: <std err here>
Pycaml is a Python binding for OCaml. From their website:
"If there's a native library you want to use that has a python wrapping, for very little extra cost, it can have an ocaml binding. This also means that ocaml code can import pure python modules and use them, making it ideal for using to implement test-case code on event processing systems. [Pycaml also] allows ocaml code to embed the python interpreter, define modules, classes, structures, etc."
If you want to use C and/or C++ libraries in OCaml, you can use SWIG. See SWIG's OCaml docs for details.
As for LDAP in particular, there's OcamLDAP. OCaml has many other native libraries. Check out the the OCaml Hump.
Don't fight the platform
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
On of the comments on the existing site contains this additional information:
...The deal was this: Derek was not a programmer; he was a musician.
> I'm a little reluctant to add to the wasteland that is this post
> and these comments, but here goes.
>
> He learned some PHP and cobbled together the old CDBaby site by himself.
> It was good.
> Then, he heard about Rails, and became infatuated with it. He proceeded
> to attempt a rolling rewrite of CDBaby's frontend and backend both
> (the backend is large, because of inter-label and digital distribution
> stuff) in Rails.
> At this time, Derek had no experience with the following things:
>
> * any language other than PHP
> * systems integration and interoperability
> * Rails
> * object-orientation
> * the MVC pattern
> * managing a development team
Concluding with:
> No framework saves you from your own inexperience.
Python's syntax is prettier to most people, but its library is more inconsistent. Ruby has the most consistent standard library that I know. I've been using it since 2000.
Do you think Derek could have written his new site from scratch in two months if he didn't have two huge messes behind him?
Hard to answer without understanding what it is you like about CPAN.
:)
It's a centralized place where you can find high-quality, up-to-date modules, with good documentation (or at least a reasonable synopsis) for almost anything you might want. I just spent about 5 minutes typing in everything I could think of into search.cpan.org, and got a hit for all of them, from YAML to XMPP.
I would certainly like to see more diversity of languages in the open source world. Right now it's almost all a mix of imperative, procedural, and OOP. SQL is the only exception, and a lot of people spend a lot of time trying to code around SQL as much as possible.
I think it's just difficult to justify using one of those languages, unfortunately. Most of what really matters in most projects that I've worked on is not the language at all, but:
* Easy access to all the APIs and protocols that I need to use
* documentation
* frameworks available for the problem domain, if applicable
* the database design
As an example, I think PHP is a bad language in many ways. But it doesn't affect the database design, and it scores high on all the other counts for web projects.
Thank you for your comments though. I will continue learning OCaml, and I'll give clisp a try (I'll get to the others later). I think it will help me be a better programmer, but I don't think it's very practical in the short term. I'll have to be content with that
Social scientists are inspired by theories; scientists are humbled by facts.
Your post leaves alot to be desired. Such as, for example, any useful information to back up your claims of being "naively implemented". Here's my breakdown of your post:
You know, the sad thing about all the comparisons you make is that they are all choices between bad technologies. Assembler vs. PL/I, C vs. Java, Windows vs. Linux--they're all questions like whether you want to be drawn or quartered, drowned or burned, poisoned or starved. At each of those choice points, there were better technologies available.
ANY examples? None? How am I to assume you actually have any?
As for PHP vs. Ruby, both technologies suck: except for minor differences in syntax and object model, they are naively designed and implemented.
Care to define "suck"? With a short learning curve, they allow a programmer to get started quickly, both are free, offer reasonable performance on current hardware, and offer a robust set of information processing functions.
What exactly is it that "sucks"?
After decades of research in dynamic languages and OOP, it is a testament to widespread ignorance that people would produce and use something like that.
Ignorance of.... (?) More of that "hidden information" you pretend to have, perhaps?
But if I have to work with bad technologies, the one that's more popular, more mature, and more widely supported one is, relatively speaking, better.
Ignoring unsupported adjectives like "bad", I can agree with this sentence, though it's like saying "stuff people like tends to be more popular". It's still a non-statement.
That's why I prefer to be poisoned with PHP rather than starved by Ruby: poison is quicker and less painful.
What is this sentence even saying? Your post is a pointless, information-less, indefensible set of vague insults. Why you were modded up is an exercise left to the moderator, but your post is nothing but pure troll.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Oh, and Cascade really was worse. Cycle time to correct defects was too long, and there was this unfounded assumption that software could be built like a civil-engineering project. It was just an incorrect approach, no tradeoff there. For UI-intensive systems, JAD sessions work better. As for assembler, maintaining anything of non-trivial complexity was more trouble than it was worth. Been there, had no fun. I use assembler or C where I have to, but something higher-level wherever I can. And except in some unusual circumstances, I'd rather run a server on Linux (or BSD, or Solaris, or even bloody HP/UX) than Windows. So sometimes there is such a thing as progress. But in each of these cases, there was still cost and risk in making the transition. No free lunches here. But I agree that "because it's flavor of the month" is a piss-poor reason to adopt any solution. If there's no return on investment, there's no case for change. I wonder if what you're reacting to is not the new technology, but the over-promising that its advocates used to sell it?
Get your teeth into a small slice: the cake of liberty
Having been there, I think I know what you mean.
But are you sure it's not a case of 'the devil you (and your team, h/w & s/w providers...) know'?
Like many, I heard the siren song of 4Gls, only to see my ship wrecked on the rocks of back-end debugs and broken promises of 'easy' extensions & maintenance. My ass. Oh, and sorry, I suppose that I should be using a car analogy...
All new tech brings its own unique advantages, and drawbacks.
But - some new tech offers really different and useful stuff.
Do I want to go back to coding stuff in dBase? Well, no...
But, having been bitten by 'fashion', do I really look at stuff before saying "yes, we'll do everything with this from now on", hell yes...
The title to me didn't match what I came away with from this article. To me "Do you want to foo? Think again" usually implies they are opposed to foo. In this case it really literally does mean think again.
I have written up a few apps in Ruby on Rails ridiculously quickly. But, I do agree with the article writer; independent of language, if it comes to where the implementers are fighting against limitations and language design decisions they do not like, they really should pick out a different language. In this case... well, Ruby on Rails, if they're having to fight Rails to get things done, ignore the features it uses to make things easier, that puts Ruby on equal footing with PHP overall. Then, if they are more comfortable programming in PHP, that gives PHP the edge. If I were a huge Ruby junky I'd use Ruby. If I preferred Perl, I'd use Perl. The beauty of web apps is that you get your app to emit a (HTML typically) data stream, and at that point it shouldn't matter what language it's using. (Well, it does matter due to performance.. but anyway..) Do have validation and sanity checks to avoid security problems though!
"As for PHP vs. Ruby, both technologies suck: except for minor differences in syntax and object model, they are naively designed and implemented. After decades of research in dynamic languages and OOP, it is a testament to widespread ignorance that people would produce and use something like that."
So if we have all this research on programming languages - how come it never seems to jump the gap to applied language design, let alone implementation, and why is it that for all the professional, tenured academics supposedly doing this research, it usually tends to be amateurs without any of this knowledge who take the radical step of actually sitting down and producing something usable?
Suggests that our academic system is seriously broken, doesn't it, if the people who supposedly know best how to build languages can't be bothered actually doing it?
You are not a brain: http://books.google.com/books?id=2oV61CeDx-YC
I totally agree with the AJAX part. AJAX isn't inherently bad, it was just overused. Also, coming back to the article, why is the author comparing a framework to a language? I bet he could do everything he wanted in Ruby as easily as with PHP if he hadn't used Rails (I don't know Ruby, but I know you can do it in Python without using any frameworks).
The whole article is just a bad comparison.
Send email from the afterlife! Write your e-will at Dead Man's Switch.
If we are going to swing offtopic (and that stupid troll just ticks me off anyway) We might as well hear from the great one,Mr. Bill Hicks on the subject. I always thought the man could make a better point with humor than all the debates rolled into one. http://www.youtube.com/watch?v=dJcebIEOkhY
ACs don't waste your time replying, your posts are never seen by me.
After decades of research in dynamic languages and OOP, it is a testament to widespread ignorance that people would produce and use something like that.
After a long time asking for OOP fans to objectively prove that OOP is better, I've come to the tentative conclusion that people like what fits their own personal psychology the best. I challenge anybody to objectively prove that their Silver Bullet is objectively a Silver Bullet. You can't because other people will weigh differing factors different than you. If you use raw code-size, Perl will probably win because it uses symbols in place of words and context-based shortcuts, but "readability" and modifiability may be called into question. Some people have fast eyes and slow fingers, and visa versa, so they favor different aspects of presentation and verbosity.
Nobody has ever won a language/paradigm holy-war with evidence and logic alone. Votes are all we have, and they don't settle much. Will you be the first to pull the sword out of the logic stone? I doubt it. But I welcome a hearty try...
Table-ized A.I.
Old dog. New trick.
>I understand why you would choose a slow-and-expressive language over a fast-but-less-expressive one, but why would you choose a slow-and-expressive language over a fast-and-expressive one?
Library, Library, Library, Library.
Then comes community, documentation, availability of tools.
Let me ask you a question.
Smalltalk has been around for ages. If it's so great then how come it never caught on?
evil is as evil does
I was right with you until you offered up the proposition that anyone, anywhere could learn anything from that pretentious pile of horse dung that is Andrew Keene's "Cult of the Amateur."
You want the truthiness? You can't handle the truthiness!
I've found it best to borrow frameworks from prior projects and improve on them and/or tune them to the new application, for each app has a different flavor of needs. Striving for the Ultimate Generic Framework is a lost cause. And, don't make frameworks that you cannot easily toss. Keep them small and relatively simple, even if it means a small amount of duplication.
Make judicious use of named parameters (emulate them if not supported by the lang) and associative arrays (or objects, which serve a similar purpose) so that parameters and interfaces can be expanded without busting existing calls or making long sequential parameter lists. A library that supports string lists with adjustable delimiters is also helpful for indicating things such as table column order.
Table-ized A.I.
Look, I hear what you're saying but every time I think "Ok, but I can solve this with a library." I'm very fond of Qt, where you'd do something like:
void recurse( QString dirPath ) {
QDir dir( dirPath );
QFileInfoList fileInfos = dir.entryInfoList( QDir::NoDotAndDotDot );
foreach( QFileInfo fileInfo, fileInfos ) {
if ( fileInfo.isDir() )
recurse( fileInfo.filePath() );
else if ( fileInfo.isFile() )
dostuff( fileInfo.filePath() );
}
}
To me, using a lib to make C++ easy and usable is a smaller leap than going to a whole new language. What if I have a piece of code )'d like to use in a Ruby project? It's rewrite time, baby. While with a library, I can drop in any existing code.
Live today, because you never know what tomorrow brings
I remember when I was in college and I sucked at programming... I had a software engineering professor that (for some LUNATIC reason) would not let us use #include but insisted on us using C. He seriously expected us to copy+paste every line of #included code manually. That was his idea of good software engineering. Even though I sucked hardcore at programming, Ruby made it easy for me to recurse our source tree and replace every "#delude" we put in our files with the contents of the files we meant to include.
I'm not the greatest coder by far. I lack a lot, but thanks to Ruby I was able to save my group hours and hours of work, and it was really easy for me.
You have front end people making decisions about browser security in utter discord with back end choices made for functionality
You have idiot consultants who claim to be "Experts" but are no more than hackers who probably managed to install visual Basic and make a few web pages. It's crummy to say the least. Any designer who uses IE-specific code is a wanker in my book, particularly when they come into a company, decide that there'll be a "Web Interface" to everything then ignore the fact that the company has blocked the use of IE. They're like every other idiot who does it the Gates way not because they know what they're doing, but because it's what "being a highly paid computer consultant for dummies" said to do.
There is very little use for "web-based" interfaces to anything. Any product or service with a web interface is usually a toy or gimmic.
Just out of curiosity: does anyone know if there is some framwork based on PHP5 that is comparable to Rails?
There are a couple of things I do not like about Ruby/Rails too much -- lacking Unicode support, localization not part of the core framework, HTML templates not editable with standard HTML editors.
Would some PHP framework solve these issues?
How about Java frameworks?
... can you cite some more specifics, either here, or on your blog post, about the limitations that you encountered?
"Templating was crucial ten years ago. "
I gather you don't work with graphics designers?
The templating thing is crucial in real-world web design, because of the workflow of large team web design. Consultant specs it up. Team nuts out a plan. Graphics designer goes off and makes pretty pages, gives it to the team to use.
All you have to train your designer is "Stick these sorts of things "{firstNAME} , {secondName} in the templates: and hope he has a bit of a grasp of good page design.
CSS is all good and fine, but the reality is , you the coder don't make presentation. You make the logic.
And sure Seaside does have some template engines, but if they aint supported, then good luck convincing the boss to invest in it.
Which is a shame, because Seaside really has some cool shit going on, and other than the whole templating separation of logic and presentation, it eats rails for breakfast.
Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
Assuming you're being sarcastic, The ? is simply part of the method name. It could just as easily been written is_directory. But because a question mark is allowed in method names, the convention is for methods which return a boolean to end with ?. It only looks a little odd when a parameter is passed. Parentheses are optional on method calls, so when there's no parameter you can write something like if socket.connected? which to me is pretty darn clear.
WTF? What makes you think he's from Illinois?
Well, if he's not from IL, that's at least where he was surfing from. Oh wait, I shouldn't know that being that I'm nothing but an uneducated cereal-pissing non-Slashdotesque geek -- right?
Looking at Ruby on Rails, it seems like a cheap clone of the old NeXT WebObjects
It has been a long time since I did WebObjects work, but I don't think they're particularly similar. The spirit is certainly very different.
So, why do people use Ruby?
I think there are two big crowds. One is the smart OO guys who have been suffering through Java for years. Smalltalk is not commercially viable, but Ruby is. Suddenly, they can escape all the Java idiocy. For the ones doing web stuff, and in particular the ones who have dealt with the absurdity of trying to program via large XML framework config files, Rails is a similarly big relief.
The other crowd comes from PHP and other low-rent web development. Ruby + Rails lets them get something up as quickly as in PHP, but provides them better long-term tools and something much closer to what I'd call object-oriented development. Of course, a lot of those people quickly get in over their heads in Rails, as a lot of the shoddier Rails plugins demonstrate.
So maybe it would be better if Rails were written in Smalltalk or Lisp. But Ruby it is, and it's not so bad. If Java's half-way between C++ and Lisp, then Ruby's cut the distance in half again.
Many people choose Ruby simply because it has Rails... a web framework of awesome (but probably not unique) capabilities. The combination is (usually) a winner.
Is that a good reason for choosing a language? Well, it depends on what you are trying to do. Do ANY of those other languages have good, solid, modern web frameworks that are freely and easily available? With good open-source licensing? Maybe they do, I am just asking. If so, I have never heard of them.
On the other hand, I should point out that one of the nice things about Ruby is its on-the-fly extensibility. One can extend classes and methods at any time... even runtime. No doubt that is possible with Lisp as well but I do not know about those other languages. Most OO languages need re-compiling before extensions can be made, and/or are limited to specific models of inheritance. Ruby makes use of "mixins" rather than old-style inheritance, for greater flexibility. Perhaps I am wrong... but can you tell me which of those other languages possesses all of those features? Including the web framework?
Also, unlike some other languages (Java is a good example), everything in Ruby is an Object. There are no "primitives" and then "objects" that have to be handled differently. In that way it is more internally and externally consistent than most languages.
Ruby has a rich but not bloated set of built-in methods, and is a terse but not cryptic language to use. (Examples of how few lines of Ruby code it takes to do something in comparison to other languages are all over the web, yet the syntax is easily readable.) I am only guessing, but my guess is that those other languages fail in one of those respects: i.e., in comparison each is overly verbose, has a limited set of built-in methods, or has a comparatively cryptic syntax.
Can you tell me which of those other languages possesses all of those features? Including the modern web framework? (Which of course is not a feature of the language, but IS a reason for choosing it.)
It was a cut-and-paste mistake.
I've now written two large business applications in Rails. I did the UML modelling first. Then I wrote a fully constrained RDBMS schema, normalised to 3NF, using the Rails naming conventions. Then I wrote the Rails app on top of the rigorously constrained database.
If you want multi-key uniqueness constraints, just define it in your database already! Why do you think Rails prevents you from configuring your database layer?
When I need to do transactions, I use Rails' full support for transactions. There, that wasn't so difficult, was it?
I let Rails save me hours of backbreaking labour writing conventional SQL queries. Then I use the completed application, identify the query bottlenecks (thanks to Rails' built-in profiling) and re-write the slowest of the dumb auto-created SQL using hand-written SQL, which I can get to using find_by_sql, finder_sql, etc. Rails lets you put your own SQL into the application almost anywhere.
Does my bum look big in this?
do
dostuff $file
done
Or, as a single line:
Behold, the power of the shell!
Referential integrity and unique constraints should always be enforced by the database. Why even have a database if you're not going to use it?
Perhaps I'm missing something in your post, because it sounds to me like you're advocating every application that accesses the database to enforce data integrity rules. This is a recipe for data corruption, as I'm sure you already know.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
Hour 1
...swirl
....an aqk Pinoqachole Horror Production. god bless.
Mommy, I am only 0.05 inches long, but I have all my necessary cells for reproduction. I love the sound of Dad's voice going "Uhhhhg-! Yeah, Baby!".
Every time I hear it, I wave to those other less fortunate spermatozoa. But strangely, they do not wave back...
The sound of your heart beat is my favorite rap. And Jesus LOVES me. And Ponies too!
Hour 2
Mommy, Well here I go through the Fallopian tube! Gosh!....
Hour 3
You know what Mommy, I think I have 4 cells now, including Mr. Sperm!
Hour 4
Mommy, my I am trying to glue myself to the uterus wall, but I can't seem to stick!
(Is this the "Court of The Crimson King" like Daddy was humming??)
Hour 5
You went to the doctor last week. I KNEW it! And you took those 'pills'. That is why I can't glue to the wall.
Please dear Jesu! Please help Reverend Billy-Bob ban the Birth Control Pill!
Hour 6
I can hear the sound of a bathroom! Oh! I am going down a long tube again! Whee!
OH-OH! (SPLASH!)
OMG I am in water! Mom! Please don't flush! No!
And thus folks, ends the sad story of a child, one of 7 Trillion in the naked toilet!
Please help save these eggs and sperms! And if you must spill your seed, son, make sure you are married, and it is done into the proper egg container. (Ask your mom.)
And ONLY at the proper time of month.
AND, Little Mandy? Stay away from those evil pills in the circular dispenser!
But again, writing your OWN templating engine is absolutely trivial, if you really need to do so. Yet somehow it doesn't stick with Seaside because even the ones that did write and release such templating engines ends up realizing they are more a burden than a good thing.
And frankly, if your designers don't know how to design with CSS... you have a problem.
But anyway, this whole point is moot. Even if the designer handles me some weird template page, it will be fairly trivial to take the template and stick it into Seaside -- remember, in Seaside you are not working with HTML, you work with Smalltalk code that happens to map to html.
Therefore, you usually do not use the 1:1 mapping between said code and html to create your pages/components, but rather group bits and pieces of the "html" you need as full Smalltalk methods. Yay for html refactoring ! (and that's without even talking about the components model).
Between this possibility and the components, you end up working at a high description level; you express the structure and logic of the "page", not how it looks or even which bits of html it will output. Therefore it really is no more trouble to add some pure HTML if you need to because your designer hasn't learn a damn thing in ten years than to add whatever additional divs you'd need to your high level structure in order to accommodate the cool CSS design your competent designer would have come with. I'm probably not clear enough, but believe me, templates are not the problem with Seaside. Play a bit with it, you'll see.
If you look at Smalltalk today, this question is indeed absolutely inexplicable, and when you start programming in Smalltalk you just can't understand how is it possible at all that it's not used everywhere (at the very least, it should be much, much more present than it is). It's the closest thing to an ideal programming world (ok, I probably should include lisp on a lisp machine).
That beeing said, it's sadly fairly explicable:
So basically, 1/ It was not familiar, with a quite big conceptual jump to make (procedural to true OOP) 2/ It was not easily accessible 3/ It was slow. Of those 3 reasons, the first two are very likely the reason why Smalltalk didn't take over the world. That doesn't mean it shouldn't.
There's another reason sometimes quoted about Smalltalk: That it's so great that companies just do not advertise its use: it's a competitive weapon.
The irony of course for reason #3 (slowness) is the last fad language is Ruby (which I do quite like), who happens to be magnitude slower than the slowest Smalltalk.
My conclusion is, while he might have "rewritten the stuff in PHP in 2 months", he spent > 2 years designing the app (and prototyping in rails) then he finally "typed in" the final version in PHP.
;).
No surprise it's easier, better and actually doable.
He could have even done it in perl and it would be readable by nonperl people given it's the Xth time round
But I suppose he was fluent in PHP, so "retelling the same story (with improvements)" in PHP would have been easier for him.
Every sperm is sacred!
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
...in his article of IE simply to avoid the "IE Sucks" discussion. Consultants do what consultants are paid to do. Someone owned the project scope and was responsible. That person utterly failed to reconcile things like scalability and product choice. Regardless of the merits of IE based code, the PM allowed it to be done without checking with the desktop people.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
I don't get your point.
... }' to 'for(sort <*>) { ... }' ?
.. } grep { .. } sort { ... } etc).
Is there something more special than changing in Perl
a 'for(<*>) {
(or, FWIW for(map {
You can do tricks like that in any high-level dynamic
language.
I have used Ruby and Rails (limited and recently) and Smalltalk (significantly and years ago).
Your question:
"why would you choose a slow-and-expressive language over a fast-and-expressive one?" is something I struggled with when I was choosing a language for my new web app http://www.shellshadow.com/ . I spent too much time on this choice.
My previous company was patternWare (Smalltalk and later Java app frameworks). I knew lots about frameworks. I see Ruby on Rails and say, "its nice but not near as enterprise quality and scalable as what I've built myself". But the bottom line is it is "nice" and "does what it claims for building web apps".
A retrospective on my decision for using Ruby on Rails is:
1 - I'm building a web app as "a part" of my business. Its not the whole of my business. If I build it correctly with Rails, I can always outsource a rewrite in something "more scalable" if need be. This time may never come, but I know that my web app code is very clean due to choosing Rails. Note: As a prior life in building app frameworks, I don't recommend using "magic". I use Rails for the core http request cycle and MVC separation and consider myself using Ruby for the rest of my needs.
2 - Mindshare. My new startup, shellshadow, has two other key components to my technology beside the web app. I need to easily find top talent for each of these three components.
I wanted to use Smalltalk. I also wanted to use Erlang (longer post required).
But the bottom line is I needed to find good talent that could plug into my business as I grew.
Ruby (and Rails) fits "right now". Smalltalk (and Seaside) does not. I can buy more server horsepower. Finding and scaling programmer talent is harder.
Jon
andand
What these quotes say really is that this guy doesn't know about "Technology Mapping 101". Here is what I wrote about technology mapping* about 2 years ago (incidentally that's about the same time this guy started his Ruby adventure
Every technology or framework has its own architecture. This architecture poses constrains and makes certain things easy (like using the ActiveRecord pattern in Rails) and certain things harder (like not using O/R Mapping ) so, for instance, on the case mentioned above a better technology mapping might have been RBatis (iBatis for Ruby/Rails) which lets you map SQL statements to objects. It is important to note (in Rails case) that one of the core tenets for Rails is preferring convention of configuration when you don't do that you have to work hard(er) - as you are working against the framework
Another problem with the technology mapping here was his point #2. It is a pity he only saw it in after the fact. It can be justifiable to switch everything but you've got to allow this change to occur iteratively. While I generally dislike the software architecture = building architecture metaphor, using it here does make sense: building software for an existing business (vs. greenfield development) is like building a new intersection. You have got to think about building all the detours that would allow the traffic (business) to continue to operate, sure it might run slower in the intermediate phase but it can't stop altogether.
So again, Once you have an architecture that fits your business, take a look at the technology options you have. try to choose the best fit. Whatever you choose - take a look at the implications of that technology and think about the tradeoffs you may find that you either have to adjust your architecture or change the technology altogether - if you don't you might find you waited 2 years of development effort or even more..
* Technology Mapping is one of the steps of a set of activities I identified as needed to make sure your have a solid architecture. The activities goes by the acronym SPAMMED and you can read about them more in this article and/or this presentation
copied from my blog
That's why formal logic should be law. Anyone not using formal logic and reason should be sent in for re-edumacation!
... then you can design your nice tabled based pages in Photoshop/Dreamweaver and I won't have to spend a week converting them to a CSS based Joomla template.
Why are you using tables instead of CSS? CSS can be a pain in the ass sometimes, sure, but its advantages far outweigh the trouble.
You know you could have just run gcc -E on the source files, which runs the preprocessor and (recursively) pulls in all of the included files before submitting the work, right?
I am TheRaven on Soylent News
IMHO, because of how people who use it are self-hosted in the language, like Squeak. That means there's a very steep learning curve in the sense that everything is new. Nothing is very hard, but it's all very different.
Switching from Perl to Ruby on the other hand... Ruby accepts perlisms, is written in standard text files, etc.
Of course it lacks everything that Squeak comes with, but if you've never had more how do you know what you're missing?
>> Thinking about ditching Windows for Linux? Think again.
> Now that's just flamebait. My house is 100% Linux, my work is 98% Linux, and it's truly a great thing.
Well, sure some people can do this, but most of us like to play a game now and then. Considering that there are no games on Linux, aside from the multitude of simple puzzle games and alpha-stage ugly-looking bug-ridden clones; considering that the fabled Wine doesn't run any games I actually want to play; and considering that OpenOffice is an enormous pig compared to MSOffice and can't print a letter and a proper envelope (which is all a home user usually needs it for), Linux just doesn't seem like a great deal. Sure I run Linux. In fact I run it almost all the time, because I like coding in it, but I still can't ditch the Windows XP partition because I like an occasional game.
One important thing about Rails is that it hides the SQL from you. This might be good for some purposes, but not so good if you really want to get things going. This is specifically mentioned in the article.
Always use the best tool for the job. Sure you could build a house with a spoon instead of a hammer...Of course, this is only if you are solely in charge of the project and tools. I've seen some amazing decisions from upper management regarding application development tools.
Sig it.
There are cases where every performance optimization counts. In these areas, C++ comes on top of every other language.
And almost all successful desktop apps are made in C++. For example, uTorrent, a much smaller, faster bitorrent client is made in C++. The author claims that he wanted a small footprint, no external dependencies, no further downloads.
Every tool has its usefulness...use the right tool for the right job.
Nice SDK, huge set of libraries, very good IDEs, close to C/C++ syntax-wise, interfaces with C, very fast...and you don't have to follow the J2EE specs if you don't like them.
The thing about girlfriends is that you have to be honest with yourself what you're looking for.
I ditched C++, Java, and Perl for Python 5 years ago and am extremely happy with that decision.
*sigh* back to work...
GNU Smalltalk (GST) is a file-based Smalltalk implementation, with an easy way of calling C functions. If you're coming from something like Ruby, using GST as a stepping stone to something like Squeak might make your life easier.
I am TheRaven on Soylent News
The image-based nature of smalltalk, combined with proprietary and expensive development environments, contributed to making smalltalk far less relevant today than it should have been. Largely, you cannot write a smalltalk script or library. You have to open up your image, go into smalltalk land, and keep everything in the image. Interface to the external system was an afterthought, and actively discouraged in the walled garden of smalltalk.
Even now there's not many free implementations that support scripts or small standalone executables. Possibly GNU smalltalk, but frankly it's less impressive than ruby.
Smalltalk did have a chance a while back: IBM was pushing it with VisualAge, smalltalk ISV's were popping up, it was getting popular for writing CBT software. Then came this upstart called Java, and the rest is a sad history.
Done with slashdot, done with nerds, getting a life.
Thanks. It might help. Certainly a lot of Smalltalk features like named parameters are things I keep implementing in Ruby.
You can get a paying job doing Ruby.
This is my sig. There are many like it, but this one is mine.
using obscenities in tech writing of this nature no longer makes you sound like the badass rebel you once thought you were
Nothing in the article says anything negative about Rails. Indeed, the author says toward the end, "All that being said, I'm looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning."
TFA really boils down to "If you have a large existing production system that essentially does what you want, and mostly the way you want it, its generally a bad idea to throw it out and start over just so you can use a fancy new tool that takes a completely different approach to the problem domain than the one taken by your existing tool and, more importantly, than the approach you want to take for the project."
Which is also the reason that plenty of large COBOL systems hang around, with bits and pieces in other languages added on and interfaced to them, but the main system left in COBOL and maintained there rather than reimplemented, until changes to the requirements would force a complete reimplementation even if the language didn't change.
"If it works, don't fix it."
Heh :-) Where were you 2 years ago?
Rails is also terrible in my experience at consistence and installation reproducibility. After my initial installation of Ruby, RoR, and all required gems... well, we can't reproduce it on another Windows machine and MacOSX has no better luck. Our Lead Architect upgraded RoR by one point version...and Rails could no longer start with our website. We only used the RoR standards for development, taking most everything from Dave Thomas' book. Even so I had to bugfix some of RoR for it to behave as expected (problems with RAILS_ENV and the second copy).
Similarly I'll bitch about Ruby install problems because I was developing GUIs in Ruby but once the 1.8.4 release came out, the Windows all-in-one installer no longer included Tk/Tcl. Well so much for that's that.
As with everything, I don't care if *you* want to take a day or a month to get a development environment or OS to install. Just don't call me stupid when I don't want to waste my time on that crap. If there isn't a simple, reproducible way to install the environment, what chance does distribution have?
And I'm really sorry to see it go: RoR has been great to work with! I can do so much for my customers with it, but if we have to devote 40 workhours to getting a new development environment running there's no gain except for large projects with few developers.
Please fix it, guys!
8-PP
I've seen this countless times... thankfully, a lot of you have mentioned the same things. This is simply a case of a guy that was a mediocre spaghetti code writing PHP Programmer who took 2 years to learn a more formalized, more structured Programming Language (Ruby) and its MVC oriented Framework who got a little lost along the way and decided to return to what he knows, PHP. Luckily, he is taking with him some of the more structured programming experience he gained along the way and will undoubtedly be a better programmer for the effort.
Is it a waste to take 2 years out of your life and learn better coding practices only to throw it away and go back to a less structured programming language? Yes and No... if he learned something along the way and it makes his PHP code better, more structured then it was a great lesson.
I wish him good luck and I hope others out there reading the Slashdot and Digg Article Titles don't go nuts and drop Ruby on Rails for PHP. Read the article and educate yourself.
I suspect that's why Smalltalk is "more or less dead", and Ruby is taking the world fairly much by storm.
Eivind.
Doubting the existence of evolution is like doubting the existence of China: It just shows that you're uninformed.
I am TheRaven on Soylent News
this man did really stupid thing. why did he start to rewrite his _working_ project? because ror became trendy? it's bullshit. how can anybody read this guy's comments about ror? he even doesn't understand that language is just an instrument and if you can't adopte to language semantic and syntax it doesn't mean that language is 'bad'.