IPFire codebase is very perl-heavy. Have maintainers ever felt that such a core dependency on perl may have limited the amount of contributions the project otherwise may have got ?
Are there are any near or long term plans of moving the core or parts of IPFire away from perl, such as the UI being a completely different project ?
What are major challenges in doing this ? I may be completely mistaken and perhaps perl has never been a problem for this project, just bit restless that I can’t contribute
I agree, that Perl can inhibit people to contribute to the project. Perl isn’t a language you can easily learn.
Reasons:
“Perl is a general-purpose programming language originally developed for text manipulation and now used for a wide range of tasks including system administration, web development, network programming, GUI development, and more.
The language is intended to be practical (easy to use, efficient, complete) rather than beautiful (tiny, elegant, minimal). Its major features are that it’s easy to use, supports both procedural and object-oriented (OO) programming, has powerful built-in support for text processing, and has one of the world’s most impressive collections of third-party modules.” (from perlintro on perldoc.perl.org )
Such a language implements many theoretical constructs known in informatics ( aka computer science ).
Easy to use means an interpreter approach. This has implications for syntax and semantics.
The reasons for use in the IPFire project are ( in my humble opinion )
IPFire is a successor of IPCop. IPCop used Perl for WUI and internal programs. This means there is a bunch of code already in Perl.
To implement the functionality you need a mighty language.
For easy development ( prototyping, testing, code enhancement ) it is necessary to use a language which must not be compiled. On the other hand the interpretation should be fast.
A rewrite in another language is a great effort, including revision of the new code.
There are new parts written in Python. But this language isn’t easy, also.
In software development there are two ways to achieve a task:
Write the code newly in the language the programmer knows best and is known by potential co-workers.
Learn to comprehend existing code you want to enhance. Includes learning of the programming language.
Because 1. isn’t practical, topic 2. remains for contribution.
I have done that. I can now fix bugs and do various improvements in perl. Before I started I could just about spell perl. My hobby programming experience was pascal, basic and algol. I probably hadn’t even heard of perl.
I am definitely not an expert but I have been able to contribute to the project.
Adolf, your comments give me hope I might be able to contribute one day, though not yet given my immediate projects. I taught myself Perl from a book last year, from curiosity, but do not currently use it. I am confident I can pick it up properly based on significant experience with traditional unix tools (shell, awk, sed) into scripting languages which add interface features. I have the degree (algol included!) but never worked professionally as a programmer, never used C etc, just script useful or entertaining stuff for my own needs (over several decades). Next month I will see what “starter” projects are on the list.
One of the main reason I choose IPFire is actually because of Perl being used, I haven’t really done much Perl CGI programing for WebUI, but I think it is straightforward, no need to learn any kind of web framework to do frontend programing, it is the right tool for the work and get work done
Perl is not a bad language and so far their implementation of it (a web server facing inwards into the network only) makes the security issues behind CGI with http auth a moot point.
If you know C its not hard to pick up Perl and if you know Php you’ve been working with it all along.
