How do you convince an older programmer that new programming languages aren't scary?

[sandorski]

If it's just the one guy standing in the way, Promote him. Gets him out of the way and makes him all happy with a shiny new office.

 

[hooflung]

A cobbled together mixture of perl, CGI, the mysql models, and Ajax just leads to some of the most unreadable code out there.

As for just giving up, the problem I have with this is the fact that I have no weight here. I'm just the dumb undergraduate intern and he is the test developer team member with 10+ years of experience. I'll make my case the best I can, but I get the feeling that his opinion on the matter is going to heavily sway the manager on what to do.

BTW, I've just tried to give Catalyst a shot, the stupid thing broke right out of the box from a fresh install. Yeah, super framework yah got there. (installed from the ubuntu repositories).

Now you are just whinging. Seriously. Perl can make for some of the easiest reading in the world... if it is done right. There is absolutely nothing wrong with the language as a whole. Despite being the old dog on the block Perl is just as nimble configured properly as its Python and Ruby cousins.

Moreover, Catalyst is a fine product. If it broke for you then maybe, just maybe, you need to look into refining your skills more on developmental architecture.

Ruby on Rails is a 'from the ground up' framework. There are various reasons why you don't want to refactor existing code and/or tables into it. Namely, you lose convention and are forced into a plethora of configuration. Grails is the same way. Got existing database tables? Good luck with migrations...

Not using migrations? Why the hell are you using Rails or Grails again? Expressive syntax? The ability to hustle up cheap labor because Java and .NET developers cost too much and every AS/BS degree graduate has been taught Rails? Except you will follow into the same Forking Hell with ruby when trying to multi-process, something you will almost certainly do on a sys-admin level. The only way to get around that is to use JRUBY or JYTHON. Why you using Rails again?

Just saying... maybe you don't need to retrain an old dog. Maybe the new mavrick needs to be broken in a bit. <3

I hope my post isn't antagonistic... but you definitely need to ask yourself some SA questions prior to trying to reinvent the wheel or inject new ideas into older developers ( ideas which aren't new, see Cobalt vs Java discussions circa 2000 ). Also, Perl isn't ugly if you know what you are doing and you do it right.

 

[Cogman]

Now you are just whinging. Seriously. Perl can make for some of the easiest reading in the world... if it is done right. There is absolutely nothing wrong with the language as a whole. Despite being the old dog on the block Perl is just as nimble configured properly as its Python and Ruby cousins.

Moreover, Catalyst is a fine product. If it broke for you then maybe, just maybe, you need to look into refining your skills more on developmental architecture.

Catalyst, more than any other framework, relies on a myriad of 3rd party created modules. It only takes one of them braking for the whole system to come crumbling down. The system is complex enough that even the package maintainers for ubuntu didn't get all of the links done correctly (libcatalyst-modules wasn't installed by default, it should have been. This lead to broken scripts and tools).

Hell, here's a problem that is VERY simple to solve in every other framework that I have looked at. How do you create models for an existing, remote, mysql database. If you think the answer is simple, think again. The documentation is terrible. Hell, even the guys in the catalyst IRC channel admit that the documentation for this sort of stuff sucks (they were not able to give me a solid answer).

As a whole, the perl language, like all other languages, has its strengths. Web development is NOT one of them. Hell, things that require you to use "functions" are starting to get into the realm of things that perl is not really that good at. When you start to doing OO stuff and you are in the realm of "perl sucks at this".

Every language has problems, saying that "There is absolutely nothing wrong with the language as a whole." is a vast sweeping statement that ignores a lot of issues. Some languages are just better at certain tasks than other languages.

Perl is great at quick, short scripts that do lots of string manipulation.

Ruby on Rails is a 'from the ground up' framework. There are various reasons why you don't want to refactor existing code and/or tables into it. Namely, you lose convention and are forced into a plethora of configuration. Grails is the same way. Got existing database tables? Good luck with migrations...

It depends on how poorly the tables were written. I've already ported most of our database scheme to RoR models with a fairly small amount of fiddling. Yes, if you have a big nasty mess of a database, RoR might not be the best choice, but so long as your database is reasonably configured, even it is already exists, RoR does a pretty good job.

Not using migrations? Why the hell are you using Rails or Grails again? Expressive syntax? The ability to hustle up cheap labor because Java and .NET developers cost too much and every AS/BS degree graduate has been taught Rails? Except you will follow into the same Forking Hell with ruby when trying to multi-process, something you will almost certainly do on a sys-admin level. The only way to get around that is to use JRUBY or JYTHON. Why you using Rails again?

It has a clean syntax, it is VERY well documented, it has a large amount of support. It uses a language that was built for OO design (and it shows). Take your pick. The language, the ability to produce clean and good looking code quickly is pretty powerful.

migrations isn't the only reason to use RoR. It helps, but it isn't some game changing "This is the only reason to use RoR" sort of thing.

Just saying... maybe you don't need to retrain an old dog. Maybe the new mavrick needs to be broken in a bit. <3

I hope my post isn't antagonistic... but you definitely need to ask yourself some SA questions prior to trying to reinvent the wheel or inject new ideas into older developers ( ideas which aren't new, see Cobalt vs Java discussions circa 2000 ). Also, Perl isn't ugly if you know what you are doing and you do it right.[/QUOTE]
You make the assumption that all developers will always do perl "correctly" Perl is one the easiest languages for a programmer to make ugly out there. Magic things like @_ $_ all add to the crazyness that is perl.

You can make (almost) any langauge look good. Some languages just tend to get ugly fast.

The system we have now has many unmaintainable portions. Reinventing the wheel is a necessity (Read, the point were we are adopting a new framework, that was NOT my idea.) Switching to a new framework will REQUIRE use to reinvent the wheal. Switching to catalyst (like the older developer is suggesting) will REQUIRE use to reinvent the wheel.

If we are going to reinvent the wheel anyways, why shouldn't a young maverick suggest using tools that were built from the ground up for this sort of task? Why is "use a hammer for everything" such an appealing notion?

 

[hooflung]

You can make (almost) any langauge look good. Some languages just tend to get ugly fast.

The system we have now has many unmaintainable portions. Reinventing the wheel is a necessity (Read, the point were we are adopting a new framework, that was NOT my idea.) Switching to a new framework will REQUIRE use to reinvent the wheal. Switching to catalyst (like the older developer is suggesting) will REQUIRE use to reinvent the wheel.

If we are going to reinvent the wheel anyways, why shouldn't a young maverick suggest using tools that were built from the ground up for this sort of task? Why is "use a hammer for everything" such an appealing notion?

There is a reason why CodeIgniter is one of the best PHP frameworks. It has the best documentation written by 1 group of people. The problem with Kohana, Rails, CakePHP, Django, Pylons etc is that the documentation is either too cluttered <too many hands> or that it is nonexistant.

Even if you go into the Java realm with Grails most of the <free> documentation really only covers the conventions not the configurations if you need them. At least not coherently.

Catalyst is no different, sure. And Catalyst is built with several different techs but... so is Rails. Period. The maintainers just make sure releases are all encompassing. Once you get a software package, and start using it the onus is on you to not upgrade to feature sets and do regression testing if you need to update a platform package.

How is Catalyst any different? Don't do updates. We have a Spring 2.0.x project that could be upgraded but the exhaustive testing it would take currently puts Spring 3 on a back burner. Spring 4 may be out before we try it.

If it works, don't fix it. Now, I don't necessarily disagree with you wanting to move to Rails or any of the RAD web frameworks. I champion them in nearly every case especially in regards to sys-admin. But the moral of the story is that there is nothing inherently wrong with Perl because someone wants to use Ruby. There are plenty of reasons not to use Ruby in fact. One of them is that there is no concept of an interface.

You can use Modules but you've just stepped into Ruby's way of doing things. And now you've just made sure that your application is visibility to non-ruby programmers is low. Again, what difference is it then from Perl? Go out and buy a book on adopted enterprise ready patterns and try to implement them in pure Ruby. One thing I can guarantee you is that you will be a ruby master by the time you do... because you will spend a lot of time understanding the idioms of the language.

And that puts you at the same level your Perl guy is at now. What happens when Rails is replaced by a language such as Go, you know... when google buys the governments in both the US and China and outlaw Java, Ruby and the other aging modern languages.

Food for thought, RAD web frameworks simplify the Lifecycle start-up process. You can birth something relatively quick. But it isn't always the best thing to iterate over. Honestly, you should probably use JRuby with Rails. That way you can build your objects in Java, fill work with and/or fill them with models in Rails and if you need to move to something more heavy duty (threads, proper garbage collection and Standalone Desktop App) you can reuse your components.

 

[homercles337]

Damn it, i wish this thread was about old guys that cant let Fortran/C go.

 

[Cogman]

There is a reason why CodeIgniter is one of the best PHP frameworks. It has the best documentation written by 1 group of people. The problem with Kohana, Rails, CakePHP, Django, Pylons etc is that the documentation is either too cluttered <too many hands> or that it is nonexistant.

Even if you go into the Java realm with Grails most of the <free> documentation really only covers the conventions not the configurations if you need them. At least not coherently.

Catalyst is no different, sure. And Catalyst is built with several different techs but... so is Rails. Period. The maintainers just make sure releases are all encompassing. Once you get a software package, and start using it the onus is on you to not upgrade to feature sets and do regression testing if you need to update a platform package.

What?

I've found the Rails documentation to be VERY complete and comprehensive. Anything I've wanted to do is laid right there in front of me. The same goes for just about every framework I've looked at. The only one that has some pretty terrible documentation has been Catalyst.

This comes, partially, from the fact that Catalyst took the approach of "Do as much as possible through 3rd party plugins." it also comes from the fact that nobody is really using Catalyst.

How is Catalyst any different? Don't do updates. We have a Spring 2.0.x project that could be upgraded but the exhaustive testing it would take currently puts Spring 3 on a back burner. Spring 4 may be out before we try it.

If it works, don't fix it. Now, I don't necessarily disagree with you wanting to move to Rails or any of the RAD web frameworks. I champion them in nearly every case especially in regards to sys-admin. But the moral of the story is that there is nothing inherently wrong with Perl because someone wants to use Ruby. There are plenty of reasons not to use Ruby in fact. One of them is that there is no concept of an interface.

Picking a framework PURELY because it is a Perl framework is wrong. That is essentially the only reason he has voiced for wanting to use Catalyst and why Rails is scary.

Right tool for the right job.

When something gets so cluttered that nobody can maintain it, it is time to rework things.

You can use Modules but you've just stepped into Ruby's way of doing things. And now you've just made sure that your application is visibility to non-ruby programmers is low. Again, what difference is it then from Perl? Go out and buy a book on adopted enterprise ready patterns and try to implement them in pure Ruby. One thing I can guarantee you is that you will be a ruby master by the time you do... because you will spend a lot of time understanding the idioms of the language.

I have no idea what point you were trying to put across with this paragraph.

And that puts you at the same level your Perl guy is at now. What happens when Rails is replaced by a language such as Go, you know... when google buys the governments in both the US and China and outlaw Java, Ruby and the other aging modern languages.

What happens when rails gets replaced by another framework? If our rails application has degraded to the point of being unmaintainable and we need a new framework, then I'll look through all frameworks that are available, regardless of language, and pick the best one.

If, on the other hand, our application can still be maintained and updated, then I wouldn't suggest any sorts of changes.

I choose the wrong career if I can't switch to a new programming language quickly.

Food for thought, RAD web frameworks simplify the Lifecycle start-up process. You can birth something relatively quick. But it isn't always the best thing to iterate over. Honestly, you should probably use JRuby with Rails. That way you can build your objects in Java, fill work with and/or fill them with models in Rails and if you need to move to something more heavy duty (threads, proper garbage collection and Standalone Desktop App) you can reuse your components.

JRuby would be overkill. There really isn't a good reason for a smallish project like this to use a language like that.



For the job of rewriting a webpage, catalyst is not the right tool for the job. There are so many other frameworks that simply do a better job. (with my preference being rails).

 

[KIAman]

The short answer is, you can't.

You might think twice before you completely dismiss away a dinosaur programmer's ideas. There is a reason why he is in his position. Instead of expecting him to change and look from your point of view, engage him and live through his point of view. Once you truly understand the technology and thought process and justifications behind the reasoning, then you can start challenging him on some of the gaps.

Don't bring in new "languages" to debunk him. Approach him with the angle of logic and reasoning beyond language.

 

[Cogman]

The short answer is, you can't.

You might think twice before you completely dismiss away a dinosaur programmer's ideas. There is a reason why he is in his position. Instead of expecting him to change and look from your point of view, engage him and live through his point of view. Once you truly understand the technology and thought process and justifications behind the reasoning, then you can start challenging him on some of the gaps.

Don't bring in new "languages" to debunk him. Approach him with the angle of logic and reasoning beyond language.

The job is functional test development. This web framework thing is a side project that has sprung up because we are in sort of at a down point and our current framework sucks.

From my conversations with him, it is pretty safe to assume that he doesn't really have experience with web development.

While he could run circles around me when it comes to exactly how our test system works (he certainly knows his stuff there), I've got a leg up on him when it comes to web development stuff.

There is a good chance that he won't be working directly with the web development (it is usually shunted out to contractors and interns).

 

[beginner99]

Ruby on Rails is a 'from the ground up' framework. There are various reasons why you don't want to refactor existing code and/or tables into it. Namely, you lose convention and are forced into a plethora of configuration. Grails is the same way. Got existing database tables? Good luck with migrations...

Well if you go from Perl to grails you would code from the ground up anyway. The database is no problem at least in grails. You can configure it to your needs. I did do it once.
Grails uses Hibernate for ORM and if you want or need to, you can do just everything you could with plain hibernate.
This is also documented that's why I could do it easily.