> What else would you use to power the configuration gui frontend?

Perl?

seanhunter a day ago | parent | next [-]

For some reason I’m not allowed to respond to the child comment so I’m putting this here:

Perl 5 was released in 1994. Palo Alto Networks was founded in 2005, so Perl 5 was certainly available when they built their first products and would have been a superior choice to either PHP or Perl 4.

▲

ExoticPearTree a day ago | parent [-]

When discussing programming languages, you need to take into consideration how easy it is to find developers with experience on a certain language.

Sure, you can do web apps in Perl with Catalyst or other frameworks, but the PHP developers are easier to find.

And then, after you develop entire GUIs in a language, it is a herculean effort to port that to another.

And lastly, JavaScript has its own issues too.

▲

j16sdiz 18 hours ago | parent | next [-]

We were talking about early 2000s.

Perl 5 was the language of choice for CGI in that era, but PHP borrowed some of perl syntax and quickly displaced Perl in web usage.

Some perl programmers migrated to Embperl, but it didn't gain much momentum.

▲

Dylan16807 a day ago | parent | prev [-]

We're talking about an html GUI right? That's not herculean to port between languages.

▲

redundantly 21 hours ago | parent [-]

The difficult part isn't rendering the UI, it's the work that's done between the UI and the back end components/services that's difficult. PHP is used for more than just web pages.

▲

Dylan16807 18 hours ago | parent [-]

But that glue is pretty straightforward and you only have to convert one page at a time.

▲

ExoticPearTree 11 hours ago | parent [-]

I don’t think you ever went through something like this ever.

It is a huge effort even migrating from one PHP framework to another.

Coming back to your point, there is no single “page” to be migrated one at a time.

▲

Dylan16807 9 hours ago | parent [-]

It's just the configuration pages. It's not the core of the product and doesn't need to be a perfect clone.

Is there a reason one URL at a time wouldn't work?

▲

ExoticPearTree 5 hours ago | parent [-]

My last comment on this: it is not "one URL" or "just configuration pages", it is an entire application, it does not have distinct "pages" that can be replaced with something written in a different programming language.

You can always take a look at the UI of a PAN device and use your browser in developer mode to see how it works and understand the concept of a web application.

	▲	Dylan16807 an hour ago \| parent [-]
		> You can always take a look at the UI of a PAN device I do not have a PAN device. > it is not "one URL" I never implied it was. > it is an entire application, it does not have distinct "pages" > the concept of a web application Those are usually written in javascript and the client part could stay the same. If anything that kind of design makes it easier to replace the backend one URL at a time becasue the responses from the backend are simpler. If they have something where the UI state is kept on the server and is relayed to the browser, that would be difficult to do anything with. But that's an especially terrible design that causes other problems, so if you're accusing them of having a design that bad please be explicit.

▲

topham a day ago | parent | prev | next [-]

You win.

Perl 4 specifically of course though.

	▲	nocman 5 hours ago \| parent [-]
		> Perl 4 specifically of course though. Not in 2005. Perl 5 all the way, baby!

▲

bigbuppo a day ago | parent | prev [-]

That's for mission-critical load-bearing infrastructure hidden behind modernized interfaces. Nobody has touched that script in 33 years.