blogsavy.com · Domains · Slashdot Mirror

Re:Chapter 10 - Large Projects by Anonymous Coward · 2008-03-17 10:02 · Score: -1 · on Advanced Rails

I wouldn't call them "horror stories". They're more like brutally honest, real-world analysis of how well (or poorly, to be more correct) Ruby on Rails tends to fare for larger projects.

Two insightful articles I've seen about this topic are:
7 reasons I switched back to PHP after 2 years on Rails
Others are leaving Ruby on Rails, as well. And its not going well.

Re:Much Ado About Nothing... by Anonymous Coward · 2008-02-07 14:17 · Score: 0 · on The Future of XML

Keep the Web in the browser, please.
http://pinderkent.blogsavy.com/archives/81

I was reading today about Pyro Desktop. As the Pyro homepage states: Pyro is a new kind of desktop environment for Linux built on Mozilla Firefox. Its goal is to enable true integration between the Web and modern desktop computing. By merging the Web with the desktop, Pyro offers the first big step toward a new future for the Web and the applications built for it.

This sort of desktop integration makes me feel uneasy. The first problem I see with it is that it's unnecessary. Current web browsers work just fine as they are, for the most part. Some of them could be slimmed down somewhat, but ones like Opera and Konqueror function quite well. Konqueror, for instance, integrates well into the entire KDE desktop environment without being obtrusive.

The second problem I see is that it promotes bad habits. In fact, this second problem may be the most significant problems. Directly under the "Imagine..." line of the page, we see the following: Single programming environment for the whole desktop. Now that makes me feel very uneasy.

Time and time again the browser has been shown to be an inadequate application development platform. That hasn't stopped various people, groups and companies from putting together rather complex Web-based software products. However, one common trend we find with such applications is that they pale in comparison to native desktop applications written in a language such as C++. Developing a reliable, quality Web-based application is often more time consuming than developing a similar application using C++, Visual Basic, or Java.

I haven't been very impressed with most of the Web-based applications I've used so far. The native equivalents have essentially always been far more reliable, performant, and enjoyable to use. So the last thing I'd like to see is more Web-based apps, and fewer native apps. I'd much rather see it go the other way, with more apps written using languages like Python and Ruby, and making use of native GUI toolkits like GTK+ and Qt.

I don't see myself using this sort of software. It seems more like a step backwards than a step forwards. The Web is best suited to a browser. The desktop should remain a place for native applications.

Re:Much Ado About Nothing... by Anonymous Coward · 2008-02-07 14:17 · Score: 0 · on The Future of XML

Keep the Web in the browser, please.
http://pinderkent.blogsavy.com/archives/81

I was reading today about Pyro Desktop. As the Pyro homepage states: Pyro is a new kind of desktop environment for Linux built on Mozilla Firefox. Its goal is to enable true integration between the Web and modern desktop computing. By merging the Web with the desktop, Pyro offers the first big step toward a new future for the Web and the applications built for it.

This sort of desktop integration makes me feel uneasy. The first problem I see with it is that it's unnecessary. Current web browsers work just fine as they are, for the most part. Some of them could be slimmed down somewhat, but ones like Opera and Konqueror function quite well. Konqueror, for instance, integrates well into the entire KDE desktop environment without being obtrusive.

The second problem I see is that it promotes bad habits. In fact, this second problem may be the most significant problems. Directly under the "Imagine..." line of the page, we see the following: Single programming environment for the whole desktop. Now that makes me feel very uneasy.

Time and time again the browser has been shown to be an inadequate application development platform. That hasn't stopped various people, groups and companies from putting together rather complex Web-based software products. However, one common trend we find with such applications is that they pale in comparison to native desktop applications written in a language such as C++. Developing a reliable, quality Web-based application is often more time consuming than developing a similar application using C++, Visual Basic, or Java.

I haven't been very impressed with most of the Web-based applications I've used so far. The native equivalents have essentially always been far more reliable, performant, and enjoyable to use. So the last thing I'd like to see is more Web-based apps, and fewer native apps. I'd much rather see it go the other way, with more apps written using languages like Python and Ruby, and making use of native GUI toolkits like GTK+ and Qt.

I don't see myself using this sort of software. It seems more like a step backwards than a step forwards. The Web is best suited to a browser. The desktop should remain a place for native applications.

Re:Merry Christmas! by Anonymous Coward · 2008-01-20 23:39 · Score: 1, Interesting · on perl6 and Parrot 0.5.2 Released

I'm very happy to see something productive out of the Parrot community. They've promised some great things, and we've been waiting a long time to use their offerings. Some people in the community (see article below) have started to doubt the Parrot project's usefulness, but maybe this cool Perl6 development will make them re-think their stance.

Will Parrot ever truly deliver? (http://pinderkent.blogsavy.com/archives/124)

Earlier today I was reading an article about Parrot. Parrot is, as stated on the projects Web site, a virtual machine designed to efficiently compile and execute bytecode for dynamic languages. Parrot currently hosts a variety of language implementations in various stages of completion, including Tcl, Javascript, Ruby, Lua, Scheme, PHP, Python, Perl 6, APL, and a .NET bytecode translator.

So Parrot does sound like an interesting piece of technology. Its understandable how a common runtime for scripting languages could prove beneficial. But will it ever be a platform suitable for serious, production usage? I have my doubts.

Parrot has been under active development for quite some time now. The initial 0.0.1 release was made on September 10, 2001. During 2007, weve seen a release every month or so. So a lot of effort has been put into Parrot over the past six years. It has surpassed one of the major stumbling blocks with many Open Source projects, in that it has managed to build at least some development momentum. Unfortunately for its supporters, Parrot has never really seemed to catch on. I think there are a number of reasons for this.

Stability is probably the first problem. I dont mean stability in terms of the runtime crashing, or anything of that sort. Im talking about concept stability. There has always seemed to be a relatively large amount of change between releases. While this is good, in that there are improvements being made and new ideas being implemented, this causes problems for users who want to build reliably upon Parrot. Individuals and businesses often do not, or cannot, invest the time and effort to track a continually-moving target like Parrot.

The language implementations for Parrot, while many in number, have been of limited use. Looking at the status messages of some of the most promising and practical language implementations shows why this might be the case. Such messages include:

Incomplete - but all examples and test cases are working. (Amber for Parrot)
Most of the samples work. (BASIC/compiler)
Has been broken for a long time. (BASIC/interpreter)
Parser is pretty complete. Generates PIR for basic Ruby programs (Cardinal, Ruby CVS Head 1.9 implementation)
Functioning, all samples working, lacks IO routines (Cola)
Working for some simple forms. Due to some broken features, most of the bootstrapping code has been commented out. (Common Lisp)
Functioning for handcrafted test cases. Loading frozen state is currently broken. Far from complete. (Parrot m4)
This project has been abandoned. Any takers? (Pint, an experimental PHP implementation)
Passes nearly 25% of tcls (lightly converted) test suite, using a Test::More like harness. (Tcl)

So while there are many interesting language implementation projects for smaller or more obscure languages that have reached further stages of completion, the ones that were most likely to be of practical use seem to be lacking. Now, this is understandable. Maintaining a suitably complete Ruby, Python, Perl or Tcl implementati