Live data from Hacker News

Perl 7 is going to be Perl 5.32, mostly

perl.com

501–510 of 573 posts

Re: Perl 7 is going to be Perl 5.32, mostly

#501
post #259

Earlier quoted context omitted.

Do you have a good link to learn about grammars in perl?

Perl does not have grammars (at least, not built-in). Raku (formerly known as Perl 6) does: https://docs.raku.org/language/grammar_tutorial

> Perl does not have grammars (at least, not built-in).

That's not true since v5.10 (2007). Here's a sample that matches a subset of LaTeX markup:

  $matcher = qr{
      (?&File)
   
      (?(DEFINE)
          (?     (?&Element)* )
   
          (?  \s* (?&Command)
                    |  \s* (?&Literal)
          )
   
          (?  \\ \s* (?&Literal) \s* (?&Options)? \s* (?&Args)? )
   
          (?  \[ \s* (?:(?&Option) (?:\s*,\s* (?&Option) )*)? \s* \])
   
          (?     \{ \s* (?&Element)* \s* \}  )
   
          (?   \s* [^][\$&%#_{}~^\s,]+     )
   
          (?  \s* [^][\$&%#_{}~^\s]+      )
      )
  }xms
It's nowhere near as advanced as Raku grammars (not much is), but it's there, and it's built-in.

Re: Perl 7 is going to be Perl 5.32, mostly

#502
post #403

Earlier quoted context omitted.

I feel you. I'm currently at a startup that, somewhat by accident, ended up writing their backend in PHP. Modern PHP is actually fine; it's largely avoided the issues perl has; adoption of the latest versions is quite high, and it's...fine. Not the best, not the worst, broadly comparable to other languages, and a far, far, far cry from what most people may think of when they hear "PHP". My last job used Node, the one…

I heard the "PHP is becoming like Java" argument in 2005 when PHP 5 came out. I'm surprised to hear it's still a thing. Funny enough I heard the same thing about JavaScript about 5 years ago when ES6 came out.

Haha no. Php 5 has proper class definitions. Php 7 adds a spaceship operator, use declarations (yay Perl language features), return type declarations etc. Js was still prototype based the last time I've checked.

Re: Perl 7 is going to be Perl 5.32, mostly

#503
post #420

Earlier quoted context omitted.

I wrote a quick perl script earlier today to push crt.sh results for a bunch of domains into slack. Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again: Traceback (most recent call last): File "/usr/local/bin/pip", line 11, in sys.exit(main()) File "/usr/local/lib/python3.5/dist-packages/pip/_internal/cli/main.py", line 73, in main command = create_command(cmd_name,…

I understand no one wants to deal with unexpected issues, especially when you're trying to get something done. Why not use virtual environments? You keep packages out of your system's python, and if you run into issues like above you can just recreate it: b5n:~/venv_dir$ python3 -m venv im_a_venv b5n:~/venv_dir$ . im_a_venv/bin/activate (im_a_venv)b5n:~/venv_dir$ pip install requests (im_a_venv)b5n:~/venv_dir$ pip fr…

While experienced python devs will say, yeah that'd how you should do it. The problem is that python by default isn't using virtualenvs. Consider rust or is where you need to specify global installs.

Re: Perl 7 is going to be Perl 5.32, mostly

#504
post #467
post #414

Earlier quoted context omitted.

I think shells did $ for vars first, then Perl added @ and % for arrays and hashes (and then $ was refs)

$string was in BASIC. I'm sure it's even older, though (the oldest BASIC I've used is GWBASIC).

I thought BASIC had $ at the end, not at the start? It has been a long time since those days, though.

Re: Perl 7 is going to be Perl 5.32, mostly

#505

Earlier quoted context omitted.

Moreover, a Windows .exe compiled 25 years ago will also likely just run.

25 years ago is 1995, and around the release of Windows 95, the first 32-bit version of Windows. A .exe compiled 25 years ago would probably be a 16-bit executable, and Windows stopped supporting Win16 code in Windows 7. WINE theoretically supports it, but 16-bit userspace code and a 64-bit kernel do not mix well.

> the first 32-bit version of Windows.

Windows NT was released in July, 1993. Almost exactly two years before Windows 95.

In 1997 I joined a company where I was doing Win32 coding, on a Windows NT code base that dated back to 1995. The code base also had parts targeting Windows CE client devices. (The company was an extremely early adopter of that platform; they might have done some of the development before CE was officially released in 1996. Anyway, that's another 32 bit Windows from almost 25 years ago, and less of a hack than 95.)

Re: Perl 7 is going to be Perl 5.32, mostly

#506

Earlier quoted context omitted.

I think you should revisit perl. My first job writing perl was in 2005 or 2006, and it was not a good language for an eager idiot without guidance. After a couple years, I started getting it, and it became one of my favorite languages. I think it was my coworker who told me to read https://hop.perl.plover.com/ and it blew my mind and made me start to rethink how I was approaching code. With the languages that I'd bee…

it looks to me like HOP is mostly teaching traditional LISP concepts. I could write those same functions in Javascript, and they'd be more readable

With which JavaScript version? At the time HOP was written I remember JavaScript still doing all it's for loops in C-style and there was certainly no arrow syntax to make anonymous JS functions manageable.

There were also no functional methods available, as related by the restriction to C-style for loops. (Array Iteration methods didn't appear in the spec until 2009, so I don't see how you could have map or select or anything else functional).

Re: Perl 7 is going to be Perl 5.32, mostly

#507
post #420

Earlier quoted context omitted.

I wrote a quick perl script earlier today to push crt.sh results for a bunch of domains into slack. Took about 30 minutes, far less time than messing about with why pip has broken on my desktop yet again: Traceback (most recent call last): File "/usr/local/bin/pip", line 11, in sys.exit(main()) File "/usr/local/lib/python3.5/dist-packages/pip/_internal/cli/main.py", line 73, in main command = create_command(cmd_name,…

I understand no one wants to deal with unexpected issues, especially when you're trying to get something done. Why not use virtual environments? You keep packages out of your system's python, and if you run into issues like above you can just recreate it: b5n:~/venv_dir$ python3 -m venv im_a_venv b5n:~/venv_dir$ . im_a_venv/bin/activate (im_a_venv)b5n:~/venv_dir$ pip install requests (im_a_venv)b5n:~/venv_dir$ pip fr…

The reason I use linux and perl (or sometimes bash) - it just works, I get the least number of surprises. Dependencies in perl are handled by my OS same as everything else, I don't need to maintain multiple package managers, I just bash out the script and move on

I don't write software as an end goal, I write software to accomplish my end goal.

Re: Perl 7 is going to be Perl 5.32, mostly

#508
post #176

I was part of a team that wrote significant parts of Amazon's payment processing systems in Perl in the late 90s. I really loved the language. It's object system was so flexible and powerful. Once you understood how write idiomatic perl. It was a joy to use. I'm looking forward to trying out Perl 7.

United States District Court filing system for court cases is written in perl. Horrible language filled with one liners that only makes sense in the mind of the now retired and gone programmers. Sadly, I do not know why we cannot pursue other technologies. Perl is a trap... buyers will be stuck for 30 years. Like a mortgage, but without equity or returns.

You might want to go ahead and inform those investors who bought Amazon or Booking.com stock in the early 2000s that their orders of magnitudes of returns were really no such thing.

Re: Perl 7 is going to be Perl 5.32, mostly

#509
post #314
post #130

Much as people complain about Perl, it is the language which I use when I want to have something which will run 10-20 years from now. I recently wrote a consistency checker for file archives (so that I know when bitrot sets in) in Perl, precisely because I want it to be usable for a long time ( https://github.com/jwr/ccheck ). Very happy to see a path forward for Perl 5.32.

Interesting, I've been moving away from Perl and Python and towards Rust precisely because I'm afraid of bitrot. Perl the language is stable as fuck and takes back-compat extremely seriously. The problem for me was the library ecosystem: Cpan makes it tedious to pin/vendor dependencies, and installs dependencies globally by default.

Yes, dependencies are a bit of a problem (I tried to use as few as possible in ccheck), but I'd say that the general culture of CPAN is to keep things long-term and prevent breakage, so my experience has been fairly good over the last 25 years. Something I can't say for node.js.

Re: Perl 7 is going to be Perl 5.32, mostly

#510
post #361

Earlier quoted context omitted.

Keep in mind TDD wasn't really invented yet, so it's understandable. Also, CPAN had better libraries than pip did all the way up until I last used Perl in 2015. Ofc, it depends on what you're doing. My point is, there was a reason to use Perl once upon a time ago. The alternatives back then were PHP, C, C++ (the old bad kind), BASIC, assembly, FORTRAN, and others like Smalltalk. Seeing this, it's understandable why J…

I don't know about TDD specifically but we have the Perl community to thank for setting the bar for rigorous testing back in the ealry 2000s with the numerous Test:: modules on CPAN.

Perl and CPAN definitely do not get enough flowers for their contribution to TDD.
Post reply on HN