4 ms·

hey, you are that dude who wrote the catalyst book (http://www.packtpub.com/catalyst-perl-web-application/book http://www.packtpub.com/catalyst-perl-web-applica

by systems 19y ago

hey, you are that dude who wrote the catalyst book (http://www.packtpub.com/catalyst-perl-web-application/book http://www.packtpub.com/catalyst-perl-web-application/book) Nice to see you're into hacker news, anyway. I would like to recommend Groovy and Grails, the main advantage of these over Perl/Catalyst for me was portability, Groovy/Grails or GG just work better on windows and SQL Server 2005. They were way easier to install, run and getting started with. For example with Perl/Catalyst, Perl doesn't have a DBD::MSSql, I think one can use JDBC or DBD::JDBC, but JDBC is at version 0.1 and DBD::JDBC is also old DBD::Sybase, is well Sybase! DB support of GG via hibernate is just way more robust. Java have many many more active projects which GG relies on and can depend on. Perl's CPAN is for sure fantastic, but CPAN is just not as portable as Java's project, so with GG you know, and I know, that it will run on windows, with Perl, there is no guaranty Finally the moral is, with open source, you really have to consider a project popularity. Project that are too centralized, that do not rely on other popular project are doomed to get in your way! Catalyst relies on CPAN modules, this alone, assure me it is a better option than RoR, because a lot more people are working on the different pieces idependently, the work is better distributed, DBD::JDBC is usefull for a lot more project, not only Catalyst, this suggest it will better survive and evolve, RoR is full stack, so do evolve it will add a lot more work for its developer, and its open source, so no guaranty you will find one to do the work! GG situation is even better than catalyst, it relies on an even more popular and solid foundation. New Open Source Poject should always trie to introduce the least amount of new code! I do believe that the future for Ruby, Tcl, Python and Perl should be on either Parrot or the JVM this will make it easier for new project to rely on other people's work, will improve portability etc ... I will not drop Perl/Catalyst from my knowledge efforts, I very strongly believe in the Perl community, and that the current problems will be solved in ways that will even push Perl beyond Java Hope i was clear

jrockway 19y ago
> hey, you are that dude who wrote the catalyst book yup :) Anyway, I agree that Perl on Windows is painful. Most of the developers use UNIX variants, so naturally support on the UNIX side is going to be better. Basically, I think it's best to take the path of least resistance. If using Windows is important to you, you'll have fewer problems if you use the Microsoft stack. If Perl is important to you, you should just use UNIX. It's a shame that we have to make compromises like this, but sometimes you just need to get your work done :) But anyway, I've used DBD::Sybase with modern versions of SQL Server. It worked fine to get a UNIX application to talk to a remote SQL Server instance and call stored procedures. DBIx::Class also works.
- systems 19y ago
  I never really understood the importance of portability until I got this job I work in the business applications group in the IT department in a non-it multinational company I don't have a say, or least not much of it, on waht OS or DB engine, we can use, there is a different IT infrastructure team that deals with this, and honesly this is a relief, I dont have to worry about backups and stuff like this. I try to be a an open source proponent, and try to introduce or slip in OOS application. But if that application won't work on windows, SqlServer and IIS. I will never be able to make the case for it and push it. Maybe after I successfully introduce few OOS business apps and Dev framework, I can start to make a call for a linux server, but not before.

by systems 19y ago

jrockway 19y ago

> hey, you are that dude who wrote the catalyst book yup :) Anyway, I agree that Perl on Windows is painful. Most of the developers use UNIX variants, so naturally support on the UNIX side is going to be better. Basically, I think it's best to take the path of least resistance. If using Windows is important to you, you'll have fewer problems if you use the Microsoft stack. If Perl is important to you, you should just use UNIX. It's a shame that we have to make compromises like this, but sometimes you just need to get your work done :) But anyway, I've used DBD::Sybase with modern versions of SQL Server. It worked fine to get a UNIX application to talk to a remote SQL Server instance and call stored procedures. DBIx::Class also works.

systems 19y ago
I never really understood the importance of portability until I got this job I work in the business applications group in the IT department in a non-it multinational company I don't have a say, or least not much of it, on waht OS or DB engine, we can use, there is a different IT infrastructure team that deals with this, and honesly this is a relief, I dont have to worry about backups and stuff like this. I try to be a an open source proponent, and try to introduce or slip in OOS application. But if that application won't work on windows, SqlServer and IIS. I will never be able to make the case for it and push it. Maybe after I successfully introduce few OOS business apps and Dev framework, I can start to make a call for a linux server, but not before.