I love Perl. 💜 It's the language I know best, at the moment, because I have been using it since 1995, as a career Perl programmer.

However, I rather like Ruby, because it's very Perlish, has first class PCRE, and is concise and clean, and DWIM. Most importantly, it has a cleaner OOP syntax, with a "class" keyword built-in, unlike Perl, whose OOP is a bolted-on afterthought, bless her dirty soul.

Python is okay, but it's built-in support for List Comprehension is super awesome! List Comprehensions make code even more elegant and pithy than Perl, by natively providing a construct that is roll-your-own in Perl, like OO.

Also, Python's NumPy and SciPy libraries gave it an early lead in the field of Machine Learning, a place that should rightfully have belonged to Perl, notorious for how easily it can slice, dice and munge text.

#perl #ruby #python #programming #programminglanguages #machinelearning

I didn’t realize that was part of the official #GitHub Desktop package.

They’re gonna have an interesting time when #Apple makes good on its five-year-old deprecation of #Perl from #macOS: TidBITS.com/2019/06/25/apple-t…

#PHP and #Python 2.7 already got the axe.

Current macOS #Sonoma 14.6.1 ships with #Bash 3.2.57 (deprecated in favor of #Zsh), Python 3.9.6, Perl 5.34.1, #Ruby 2.6.10, and #Tcl 8.5.9, all of which issue deprecation warnings on startup.

Apple to Deprecate Scripting Languages in Future Versions of macOS - TidBITS

Apple says future versions of macOS won’t include a number of open-source scripting languages. The impact of this change will vary depending on the audience, but it will affect more people than you might think.

^{Curtis Wilcox (TidBITS Publishing Inc.)}

We got ourselves a #remote job. Not my team, but I can answer questions about the company. I've been here 6.5 years which probably tells you all you need to know.

Preferred skills

Programming skills (#Ruby, #Python, #Perl, etc.)
Experience working w/ Puppet
Windows sysadmin
Large scale infra experience
Knowledge of DC management, sys management, and monitoring, networking & security
Tech Support experience in an open source company

#fedihire

thegravityapp.com/shared/job?c…

Now Hiring: Perforce Software, Technical Support Engineer, Puppet - Remote - US

Role: Technical Support Engineer, Puppet Location: Remote - US Shift: 9:00 AM to 6:00 PM PST Perforce is a community of collaborative experts, problem solvers, and possibility seekers who believe work should be both challenging and fun.

^{www.thegravityapp.com}

A few thoughts on Programming languages

Just a few thoughts on programming languages that have been rattling around in my head this week, but which don’t each merit a full blog post. The main theme is that the culture behind each programming language leads to some interesting choices, as is the case with spoken languages.

This week I started learning how to program in Rust. Even though I’m using the project-based Command-Line Rust to learn, the author still went with the traditional “Hello, world!” project for the first intro to the language. I was also working on a Go project last week and so it immediately stood out to me that (at least as taught by this author) Rust has the print! macro that allows you to succinctly print to the command line. By contrast, Go requires importing fmt before you can print. This was the first topic that was swirling around in my head this week. What makes language designers choose whether printing output (one of the most basic things a program can do) is built-in or requires an import. I even remember back when I was learning Java in undergrad (I think it was Java 1.8, but I don’t remember) we had to use the savitch library just to get program input (another very basic computer program concept). As I thought about it, I wondered if it has to do with thoughts around compilation and whether the language designers think you’re mostly making user-interactive programs or libraries? It makes sense to me that scripting languages like Python, Ruby, and Perl would have print built-in since you always have to have the interpreter along with you, so all the basics should be there. (The original Batteries Included Python promise, for example) But perhaps the Go developers thought you wouldn’t always be printing to the command line so a more efficient binary could be compiled by forcing you to import the functionality? I’m not entirely sure.

The next thing I started thinking about, again due to learning Rust, was the mutability of variables. In most languages I’ve come across (I think all, except Haskell) all variables are mutable by default. It almost seems pointless to have a non-mutable variable. I understand why many languages have the concept of a “contanst” modifier/keyword. Unlike normal variables, THIS ONE does not change. But the opposite seems so weird since most of what we often do in programming involves changing the value in a variable. Perhaps as I learn more about Rust, I’ll understand their reasoning, but this seems completely backwards to me.

Both Rust and Golang use structs to organize variables where Ruby, Python, and Java use objects. But when both Go and Rust allow you to “attach” methods/functions to structs – is there a true distinction between object-oriented programming and struct-based programming? It seems like it’s just semantics (in the generic sense of the word) – at least at the level at which I program. The only difference I can see is that structs don’t have inheritance, although Go’s “types” solve some of the same problems.

Today’s (the day I’m writing this, not the day it’s going to be posted) shower thought was about programming language versions. On one end you have Java (I think now on version 22) and C# (now at version 12). On the other you have Python and Ruby (both at version 3). Perl essentially stopped at 5 with Perl 6 evolving into Raku. I don’t know what Java is up to. But I think C# is actually using the versions correctly – I’ve heard that each version introduces completely different ways of doing things and that the way you program C# depends strongly on when you jumped in. This is why Python is probably never moving to v4 unless they need to make some kind of huge change. Rust is an outlier with year-based versions. I guess that’s fine, but doesn’t tell you anything like a proper semantic versioning could.

Finally, I know that Rust is the newest of all the programming languages I’ve learned, but I really love how new projects are started. Python isn’t horrible, but it’s currently suffering from a lots of ideas, none of which has complete market share. You could do a simple virtual environment or you could do a more complex virtual environment/lock file situation with Poetry. (And there are about another half dozen variations on these two themes) But Rust….Rust deserves a chef’s kiss. When you start a new project with “cargo new project-name”, not only does it set up your directory structure, but it does a whole bunch of great setup tasks. It creates your Cargo.toml file (with Python, which only really started supporting toml files at the project level a few years ago, you need to look at documentation to figure out what goes in there) so that you have all the basics in there already. But it doesn’t stop there! It also, in a nod to modern programming, creates a git repository AND a gitignore file. It’s a thing of beauty. I would absolutely love for Python to move in this direction officially (not through a random user choice) for their defaults. Even “go mod init” could benefit from setting up a git repo and a git ignore (since the toml is not how Go works – I think they would probably best set up a README.md since Go’s default packaging is through git repos).

#Go #Golang #perl #python #Ruby #rust

wp.me/p5cs3g-4HT

How Programming Languages Got Their Names

#haskell #java #kotlin #python #ruby #rust

kylehigginson.medium.com/how-p…

How Programming Languages Got Their Names - Kyle Higginson - Medium

Have you ever wondered how the likes of Python or Java got their names? Let’s take a look at some programming languages and the story behind how they were named. Before we start — If you’re curious…

^{Kyle Higginson (Medium)}

I really appreciate today’s #PerlAdventCalendar by @jjatria: perladvent.org/2023/2023-12-24…

On this #ChristmasEve, maybe the #Perl kids and the #Kotlin kids and the #Ruby kids and the #Java kids and the #Python kids and the #RakuLang kids and the #GoLang kids and the #Rust kids and the #PHP kids and the #JavaScript kids and the #Csharp kids and all the other kids I can’t fit into a #Mastodon character limit can all play and have fun with each others’ toys.

Peace on Earth, y’all. 🎁

Hello! I'm a senior software developer looking for a role where I can help users succeed. I have 17 years of experience running the gamut from #Perl to #Python to #Ruby to #Go. I love to make relational databases sit up and dance. I've been in the financial and fintech space recently, as well as devprod/infra.

I'm open to full time W-2 or short term consulting.

Email me: pete@petekeen.net or DM me here if you'd to chat about how I can help.

pkn.me/resume

#FediHire #consulting

Résumé | Pete Keen

^{Pete Keen}

Webmentions: how I used 1990s technology to avoid writing JavaScript.

> When I started building websites over 20 years ago, I used Perl and CGI to run simple scripts, like a guestbook (I wrote my own). I prefer Ruby these days—and Perl has deprecated CGI—but could that approach still work? I thought it would be fun to try. It turns out it does work!

Please like/boost/reply to help me load test! 😁

joshuawood.net/webmentions

#Blog #IndieWeb #Webmentions #Jekyll #Ruby #Perl #CGI

Webmentions

Have you heard of webmentions? They’re similar to pingbacks—but modern—and allow websites to notify each other about different types of activity (like replies on social media). As of 2017, the protocol is a W3C recommendation.

^{Joshua Wood}

@Perl I’m glad mastodon.online/@vwbusguy/1112… works for you, but I feel pity for when you come back to it later.

It’s nothing to do with #Perl and everything to do with shitty #regex possible in almost any #programming language.

Though it’s true that Perl’s reputation took a lot of damage from shitty developers filling the world with shitty #regexes in their shitty Perl code. So you’re in a big group, albeit via #Ruby.

Scott Williams 🐧

2023-10-10 20:05:37

Some have said that I am capable of writing #perl in any language. Behold my #Ruby. #programming #regex

Tooting the horn since it's been a while: I'm the lead maintainer for the Ruby passkeys organization, and we're actively looking for help: github.com/ruby-passkeys#help-…

If you'd like to help make sure that Ruby apps are future-proofed from the start *and* markedly improve everyone's security, please reach out!

#passkeys #security #ruby #RubyOnRails #OSS #passwordless

Ruby passkeys

Focused on making passkeys the standard for authentication in the Ruby ecosystem - Ruby passkeys

^GitHub

Are you a #Ruby, #Python, #PHP, #Perl or #Java developer, curious about #RakuLang, it's features and it's communities?

Join us for @rakuconf 2023 in Riga this August!

We're a friendly and inclusive #community, happy to teach you Raku, and would love to have you around! ❤️ 🦋

conf.raku.org

The Raku Conference 2023

^{conf.raku.org}

#Python, #Ruby, #Perl, and other #scripting runtimes have been deprecated since #macOS #Catalina 10.15 in 2019: developer.apple.com/documentat…

#PHP was removed entirely in #Monterey 12.0 in 2021: techgenyz.com/2021/06/18/macos…

#Python 2.7 was removed in Monterey 12.3 in 2022: developer.apple.com/documentat…

Plan accordingly for the rest to go without much warning.

macOS 12 Monterey update will no longer have built-in PHP

Apple launched the macOS 12 Monterey update almost a week back; that will not have built-in PHP. Developers need to install it manually

^{Bipasha Mandal (Techgenyz)}

@rrwo @profoundlynerdy @stargazersmith @Perl Indeed, #Perl, #Python, #Ruby, and other scripting language runtimes have been deprecated by #Apple since #macOS #Catalina 10.15. #PHP and #Python 2 are already gone. developer.apple.com/documentat…

So you shouldn't ship anything that relies on them without either packaging them yourself or requiring the user to install them as a third-party dependency.

The Mac #Homebrew `brew` package manager has to worry about this too as they're based on Ruby.