Hacker News Reader

Comment by johnisgood | Hacker News Reader

It is kind of like PHP. Their views of PHP is still stuck at PHP 5. We have PHP 8.

Maybe it is (mine is for sure) but that's a "bitten by the dog once" case.

You got bitten and everyone around you assures you won't get bitten again, but the pain was real and you still have a scar from the event. Why bother or invest risking another bite if there are other places to be which had never bitten before.

Over my career I hated technology 3 times. First was PHP, second was Python during Python 2/3 fiasco and third was CoffeeScript.

Edit: till this day one of my favorite meme is titled "PHP: Training wheels without a bike"

A few years ago, I used BTRFS on a laptop. Single disk, no RAID of any kind, OpenSUSE (which favored BTRFS, so I expected it to be as well supported as could be had), nothing fancy. After losing the root filesystem twice, I decided that maybe I shouldn't trust BTRFS. Since then, I've been told that it's totally better now, that all the problems are with bad RAID setups, and it's safe and won't lose my data. Anyways, as I type this from a laptop running on ZFS, I remain somewhat cautious.

> Since then, I've been told that it's totally better now

I've read through some bug reports, and I assure you that BTRFS remains a horror show.

Saying that comments from the dev team "don't inspire confidence" is putting it mildly.

ZFS is the diametric opposite of this, where blog posts from the team working on it made me realise that they're moving the state of the art into new territory.

I really want to try bcachefs, I wonder if anyone has used it (with encryption, and if their encryption supports plausible deniability or not).

BTW, is ZFS on Linux good now?

Bcachfs has been removed from Linux.

https://forums.truenas.com/t/bcachefs-dropped-from-linux-6-1...

ZFS is an install option on Ubuntu. Running it taints the kernel.

ZFS on linux native encryption is kinda unmaintained at this point, so I would not recommend it.

from my experience the primary problem with PHP was not the language itself (although the design was/is somewhat quirky/inconsistent) but with the large influx of inexperienced programmers using it, creating low quality code and thus affecting the reputation of the language. same with javascript today.

i haven't heard any issues about coffeescript.

with that in mind, i'd love to hear your stories. how did you get bitten?

As someone that used Coffeescript a bunch, the problem is it's designed to make it very easy to write code, but has very little thought given to being able to understand that code again in 6 months time.

This means it's very easy to knock out an entire project in record time, but subsequently very difficult to debug/maintain/update the same project when you come back to it. It's essentially a technical debt generator.

This is why I have DEVELOPER.md. It explains why I chose X over Y, among many other things. Someone wrote a nice list: https://news.ycombinator.com/item?id=44581069.

That's a nice idea, but the problem more comes from using a language designed to help you get ideas from your head into production using the fewest possible characters results in extremely terse code.

You can say all sorts of things around "write better documentation" and so on, but step 1 really is "don't use a code golfing language"

I do not disagree. In DEVELOPER.md you are not supposed to have an intro to the language you picked.

It wasn't a horror story but a simple fact that it was layer of complexity that wasn't really helpful at all.

When code volume was small, nobody noticed, and hey "it looks nice". Some time after though, when volume increased it started to get really burdensome. I used this as a part of Rails pipeline, so it was like: write some coffeescript, compile, run - something failed - usual process.

However the code was already mangled, often source code mapping didn't want to work. When source code was found it wasn't uncommon that it caused by operator precedence or code not transpiled in a way it was intended and requiring debugging transpilation process.

At some point I suggested to migrate away from CoffeeScript toward (almost plain) JavaScript and most developers happily agreed to that. We were able to migrate big chunk automatically, rest took only few weeks to clean up. Velocity increased and people were happy they don't have to deal with it anymore.

Ultimatelly it is the truth with most of the transpilers - sooner or later you get into idiosyncracies that - if technology is not popular enough - you're left alone to solve.

ah, yes, i agree, in the end it is still javascript under the hood, and you'll reach the limit with transpilers. what about your php and python stories? :-)

PHP I worked on from v4 for couple of years. My main gripe was that it was full of idiosyncrasies, implicit knowledge, heavily inconsistent and heavy on the boilerplate. After moving to Django I felt I could finally think about logic, and not checking if this one dude didn't use non MB prefixed function on string (which - for unaware - could end up splitting utf8 char into two).

As for Python3 there was this thing that at some point Python was supposed to move from 2 to 3. This change was to bring plenty of incompatible changes, and in a way that migration was outright impossible in normal sized projects. Then community split into two parts, some said "F-- it" and held on to Python2 and some said "F-- it" and moved to other technologies. In the end Python2 was sustained for many years (originally sunset period was short) but those who moved out didn't consider it "stable tech" anymore.

I went through your exact same hate timeline. The CoffeeScript one was so bad that I was REALLY hesitant about TypeScript, but the whole "it's a superset of JS" thing won me over in the end.

I still hate PHP the most, and I very much mean PHP 5 when I say that, and have no idea what happened beyond that, and honestly the scars are so deep I don't care to find out.

It's with so many things! Some evergreens just from last week here on HN:

- Rails is horribly slow!

- Python is still stuck migrating to Python 3!

- MySQL doesn't scale!

- Haskell tooling sucks!

- io_uring is insecure!

- ... and dozens more just in the programming world. These are just off the top of my head. Probably hundreds more in the wider engineering world.

MySQL would happily clobber your data silently for decades though.

I think the situation is better now, but that was worthy criticism for a long time; like anything though, those that bought into it wholeheartedly couldn’t take the criticisms.

I wonder if there’s a word for that, seems to be a common issue.

> those that bought into it wholeheartedly couldn’t take the criticisms.

"invested"

From my perspective python3 migration is very much complete. Package managers is the evergreen mess now.

Programming languages are different. They usually can't be "repaired" once broken, because they need to maintain backwards compatibility.

This is only true if people stick to a version of a language and don't upgrade.

If you upgrade then, for example, you can't run all of your PHP 5 code in PHP 8, most of it you can but you will have to change the parts that are broken, which are the areas that are repaired in PHP 8.

Same goes for other languages like C# or Python

They are software products like anything else.

They don't "need" to maintain backwards compatibility. Several major languages have broken it by now.

Programming languages deprecate features in standard libraries all the time. As PHP did, causing many PHP 5.3 applications to fail catastrophically once the warnings added to PHP 5.4, 5.5, and 5.6 were turned into errors. Of course, maintained software rarely ever runs into this issue.

The standard libraries were the lacking part in PHP. The language itself was never a serious problem.

the work that the people in PHP did for 7 is criminally underrated

It is kind of like Perl. Their views of Perl is still stuck at CGIs of the 90's.

I still think that Perl was and is still a better language than PHP and Python. And people never had a serious look at raku because of the Perl heritage.

But that ship has sailed.

huh? that would suggest that perl has changed so much since the 90s that those views would no longer be valid.

CGIs in the 90s were written in perl 5, and perl hasn't evolved much since then. but perl was never a bad language. it had/has a quirky syntax. if you were coming from a lot of commandline work using sed, awk, tr, and many other tools to manipulate text in shell scripts, then perl made a lot of sense.

and while raku may have been a great improvement, perls reputation was tied to its syntax. the readability and writeability of the code. and that's the one thing that raku did not change significantly.

so unlike other examples i don't see how peoples views of perl could improve

I love Perl. Is Raku worth trying considering I love Perl for its performance, syntax, brevity, and so forth?

Raku feels like a different language to me, and it seems not-so-serious, maybe because of the name and their mascot (which is unfair to the language).

i haven't looked at it in detail, but if you like perl and you are looking for an interesting new language that has the spirit of perl, i'd say it is worth a try

> and perl hasn't evolved much since then

Perl (5) has been evolving, quietly. The language has had many nice additions over the years. Some of it is backporting from 6.

oh that's interesting. especially the backports. i did not consider that as realistic since perl6/raku is using an entirely new virtual machine. so maybe they are actually reimplementing ideas that are in raku but work with perl 5?

I can't speak to the degree to which Raku VM ideas are being backported. I'm not that deep into Perl. I just know that the Perl 5 language itself is still regularly enhanced, and some amount (can't give you a percentage or speak to the pedigree of all the changes,) of that is inspired by Perl 6. Perl 5 now is a great deal nicer than it was, say 10 years ago, due to these updates.

Sub signatures, defer blocks, official "class", "say", try/catch, enhanced dereference syntax, new and enhanced operators, etc. Significant language changes have been and continue appearing.

Wow. My view is stuck at php 4. Didn't even know 5 existed. I only remember Facebook making a big deal of hhvm and php 7 and laravel being considered great but not as great as rails or django.

It is worth checking out PHP for when you are building backend. I did not use Laravel because I had some issues with it (lack of flexibility in some cases) so I ended up creating my stuff from scratch. I am glad I did. It is well documented, modular, maintainable, not bloated, etc. I can give you the resources I have heavily used.

You're very kind. Thanks for the recommendation. If for some reason I have to branch out, I will check php again.

Hey, I have not recommended anything yet (besides PHP). :D

I like "PHP & MySQL: Novice to Ninja" quite a lot. I have used it more so than the other books, so I definitely recommend it. You can find the code archive (code from the book) here: https://github.com/spbooks/phpmysql7.

FWIW I recommend these books (in no particular order):

  ├── Modern PHP Security (2020).pdf
  ├── PHP 8 - OOP.pdf
  ├── PHP 8 - Quick Scripting Reference (2021).pdf
  ├── PHP 8 Programming Tips, Tricks, and Best Practices (2021).pdf
  ├── PHP MySQL - Novice to Ninja.pdf
  ├── PHP and MySQL for Advanced Learning.pdf
  ├── PHP in Action (2007).pdf
  ├── Programming PHP (2020).pdf
  └── The Art of Modern PHP 8.pdf

It’s true of most languages that have been around for a while. E.g. people who don’t write Javascript think of it as it was pre-ES6, not to mention that many people don’t write JS directly and use Typescript instead.

Same with Java, it’s somehow stuck in time in Java 6 in some people’s minds.

Reply on news.ycombinator.com