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).
A weird thing about being 50 is that there are programming languages that I've used regularly for longer than some of the software developers I work with have been alive. I first wrote BASIC code in the 1980s. The first time I wrote an expression evaluator--a fairly standard programming puzzle or homework--was in 1990. I wrote it in Pascal for an undergraduate homework assignment. I first wrote perl in the early 1990s, when it was still perl 4.036 (5.38.2 now). I first wrote java in 1995-ish, when it was still java 1.0 (1.21 now). I first wrote scala, which I still use for most things today, in 2013-ish, when it was still scala 2.8 (3.4.0 now). At various times I've been "fluent" in 8086 assembly, BASIC, C, Pascal, perl, python, java, scala; and passable in LISP/Scheme, Prolog, old school Mathematica, (early days) Objective C, matlab/octave, and R. I've written a few lines of Fortran and more than a few lines of COBOL that I ran in a production system once. I could probably write a bit of Haskell if pressed but for some reason I really dislike its syntax so I've never been enthusiastic about learning it well. I've experimented with Clean, Flix, Curry, Unison, Factor, and Joy and learned bits and pieces of each of those. I'm trying to decide whether I should try learning Idris, Agda, and/or Lean. I'm pretty sure I'm forgetting a few languages. Bit of 6502 assembly long ago. Bit of Unix/Linux shell scripting languages (old enough to have lived and breathed tcsh before switching to bash; I use fish now mostly).
When I say passable: in graduate school I wrote a Prolog interpreter in java (including parsing source code or REPL input), within which I could run the classic examples like append or (very simple) symbolic differentiation/integration. As an undergraduate I wrote a Mathematica program to solve the word recognition problem for context-free formal languages. But I'd need some study time to be able to write these languages again.
I don't know what the hell prompted me to reminisce about programming languages. I hope it doesn't come off as a humblebrag but rather like old guy spinning yarns. I think I've been through so many because I'm never quite happy with any one of them and because I've had a varied career that started when I was pretty young.
I guess I'm also half hoping to find people on here who have similar interests so I'm going to riddle this post with hashtags:
Once upon a time, I used to take an active part in the #CPAN Pull Request Challenge (and later in the Pull Request Club). When addresssing Perl::Critic violations in my assignment for the month, one violation which tended to crop up often was stringy eval. Generally, this is something to be avoided. But how? In the post below I discuss recommended best practices and some other options.
Whatever happened to Perl? Back in the day it was wildly popular and was used all over the place. Then there was supposed to be a big rewrite for Perl 6 and that's the last I've ever heard of it. No news, no releases, nothing. For me Python came in and ate Perl's lunch, so I don't miss it at all. Python is better in every way for me. Honestly Perl was a horrible language, but still interesting to see it die so suddenly.
Zurück in Leipzig vom Deutschen #Perl Workshop #gpw2024 in #FrankfurtM. Geschafft, aber mit vielen netten Begegnungen, einigen Anregungen und einer konkreten Lösung für ein Problem, an dem ich zuvor stundenlang erfolg- und scheinbar aussichtslos geforscht hatte. 🎉
Danke an die Organisatoren! Bis nächstes Jahr in #München! 👋
@fbievan You can use a programming language like #PHP, or maybe #Perl if you're feeling a bit more adventurous! No #Python though, and no #Javascript either. Those are the devil's languages.
Incredible research at BlackHat Asia today by Tong Liu and team from the Institute of Information Engineering, Chinese Academy of Sciences (在iie.ac.cn 的电子邮件经过验证)
A dozen+ RCEs on popular LLM framework libraries like LangChain and LlamaIndex - used in lots of chat-assisted apps including GitHub. These guys got a reverse shell in two prompts, and even managed to exploit SetUID for full root on the underlying VM!
1/ Once you look past syntax and "paradigms", many programming languages (Java, Python, Racket, …) share a common semantic core. But students seem to understand it very poorly, which leads to endless confusion (as often seen on here). What to do? ↵ https://blog.brownplt.org/2024/04/12/behavior-misconceptions.html
@shriramk (Fun fact about #Perl, skip this if you value your sanity... functions can (but need not) have formal parameter types, but they do not have formal parameter names. Rather, the array @_aliases the parameters, which of course has the result that lvalue parameters are magically INOUT whereas rvalue parameters are IN and there's no way for the function to know which are which. But convention is for a function prologue to parallel-assign all the parameters to lexicals. 1/2
You get formal named or nameless positional lexical parameters passed by value, with defaults for optional parameters and the ability to “slurp” remaining values into an array or a hash of key/value pairs.
dreamed that different programming language's objects/classes felt like physical objects: Java objects felt like old AT&T phones: heavy, old electronics in a black Bakelite® enclosure.
🐫 #NaData de hoje, mas em 2005, a comunidade #Perl no Brasil era ativa e anunciava a realização de um workshop de programação no litoral de SP, gratuito e com 100 vagas. A promoção era do Perl Mongers Brasil com apoio da Fatec de Praia Grande e do Linux-PG.
My take-away was pretty much: "Guys, this timekeeping stuff is so hard, you have no idea."
So what I learned, really, was never try to roll your own #time library. People who have worked on it for years say it's basically impossible. Use their code; at least it will be less wrong than whatever you would have come up with.
Next month will be the 10th anniversary of #Perl v5.20, which added experimental signatures, postderef and key/value slices.
I've installed a copy of Perl v5.20 so that I can start testing my CPAN modules with the updated syntax. (I try to support Perl versions from the past ten years.)
It'll be refreshing not to write code like it's 1999.