undefined | Better HN

0 pointscalvinmorrison1y ago0 comments

its not that reading perl is hard, the _intent_ of the operations of often hard/unclear.

Yes its nice to write dense fancy code, however, something very boring to write like PHP is a lot of "loop over this bucket and do something with the fish in the bucket, afterwards, take the bucket and throw it into the bucket pile" that mirrors a 'human follows these steps' type.

0 comments

kamaal1y ago

In the intent department, I have had more troubles with AbstractClassFactorySingletonDispatcher type Java code, add to that dependency injection magic/madness.

I'd rather maintain Perl any day than 30 classes of Java code just to build a string.

b2gills1y ago

I once heard of a merger between a company that used Java, and another one that used Perl.

After that merger, both teams were required to make a similar change.

If I remember right, the Perl team was done before the Java team finished the design phase. Or something like that.

The best aspect of Java is that it is difficult to write extremely terrible code. The worst aspect is that it is difficult to write extremely awesome code. (If not impossible.)

lizmat1y ago

If this was about my former $work:

The company using Perl was able to double its turnover in 3 weeks.

The company using Java was still in the design phase.

Companies choose their tools depending on their internal culture. The company using Perl at the time was simply more agile.

FWIW, the company that was using Perl is now using Java mostly. And yes, the culture of the company has changed. Not sure about cause and effect.

1 more reply

wruza1y ago

I’d rather have a compiler+ide-supported testing framework that doesn’t require a tested code to be prepared for being tested in any way. Almost all boring languages are fine at writing straightforward code without ceremony, even Java.

IshKebab1y ago

Good job those aren't the only two options!

kjellsbells1y ago

Frankly I'm on Team Fish Bucket.

I am not totally convinced--well, not at all convinced, really-- that the OOP revolution made programming code better, simpler, easier to follow, than procedural code.

I suppose the argument ended up being a philosophical discussion about where State was held in a running program (hard to tell in procedural code, perhaps, and easier to tell in OOP), but after 20+ years of Java I wonder if baby hadnt disappeared down the plughole with the bathwater.

j / k navigate · click thread line to collapse