[UPDATE] It appears as if my flippant remark caused upset. I am sincerely sorry that this was the case. No offense was meant.
@peteretep, you have my sincere apology. It was a flippant remark. At the time I wrote it (mid-1990s), Perl was the best way to write portable server-side code. I took the time to learn it, and got fairly good at it.
Since then, I have found my muse in other languages, but I sincerely did not want to give offense. I doubt that deleting the comment would help.
I once wrote a vital satellite maneuver orchestration software, which had to parse various files and call models. Simultaneously the scariest and proudest moment in my career, but the alternative was Fortran or C.
Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of [Perl] script than there is in ten thousand lines of C.”
The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”
Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of [Perl] script than there is in ten thousand lines of C.”
The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”
Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of [Perl] script than there is in ten thousand lines of C.”
The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of [Perl] script on a nearby whiteboard, and said: “Master programmer, consider this [Perl one-liner]. Implemented in pure C, would it not span ten thousand lines?”
The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.
“And how many hours would you require to implement and debug that C program?” asked Nubi.
“Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.”
“And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”
Upon hearing this, the programmer was enlightened.
Perl is cool but it's got a hell of a lot of cryptic operators for its syntax. They make sense after you learn them but for beginners it's clear why python gets picked up way easier. They're not having to think in symbols and stuff, it just looks more like a list of instructions rather than a mess of dollar signs and 'my' (my what? just not retrospectively intuitive...)
That said I like perl (And lately, awk/sed) a lot more for things that python is just SLOW at. Plus for systems-level scripts, considering that most linux/BSD installs you encounter on anything at all will have perl installed, let's say you encounter a router or something like that you need to work on somehow internally -- Do you even have room for another interpreter on there? Better be at least initiated in using perl if you want to hack on that. I've also recently found it really useful for rescuing an ancient database file format from the 1980s which was super handy considering other tools choked on it.
Perl might be weird, but it's logic and it makes sense. References are not automagical, but explicit, so you don't get an inconsistent function calling model. If you call a sub like `something(%h)`, it will get a copy of the hash. If you use `something(\%h)` the sub will receive a reference to access the hash instead. This is way better than Python or Java where everything is "pass-by-reference" until it isn't, and the fact a function won't modify the arguments you passed to it is basically a gentleman's agreement.
Perl is complex, but it is also rewarding when you use it for those tasks it's good at (like gluing code together and text processing).
Ive only used Perl for one story at work but I don't fully grok yet why we $ a @ or a %
Getting a hash passed by ref to a sub was a true syntactic challenge that I haven't experienced in a different language. Have to say though, using regex in Perl is chef's kiss
Because an array is a list of scalar, and an hash a map of scalars. If you want to access a scalar inside the list, you write $a[1], which means "the scalar at the first position of list @a". If it was @a[1] it would have been inconsistent, because then a @ expression would have returned a scalar and not a list.
Conversely, there's also so many things you can do in a perl (or awk/sed if performance or avoiding malloc by streaming data is necessary) oneliner in a shell script if you know some cool tricks. It's crazy how many resources are thrown into stuff like hadoop (literal ironic elephant logo) clusters to process CSV when dinky tools older than I am can zip through that data 1000x faster just by keeping it in the processor cache on my laptop
In my heart, Perl has won a long time ago. Python is nice and all, but it's too much of a jack of all trades language, that doesn't neither suck nor shine at anything.
Also, the fact you can write a Perl script, run it everywhere and just not concern yourself with versioning and stuff is beautiful. If one of my .sh script gets over 40 lines, it becomes a .pl file, that's the rule.
If Perl had offered proper OO without all that convoluted bless stuff, offered proper linting, good data-science libs like pandas, easy concurrency, ergonomical web-frameworks to beat PHP and did not get lost in the "everything will be solved by Perl 6" argument, it could have ruled as the Camel of the Web.
> proper OO without all that convoluted bless stuff
Moose[1], and more lightweight versions in Mouse[2] and Moo[3], have been around for ages by this point, almost 15 years in some cases. Unfortunately it was never made core (but something like them is supposed to be core in Perl 7), so it was always one of the "best practices" things that you had to be in contact with other people about Perl to know or read some Perl community stuff for, as it wasn't in the official docs.
> good data-science libs like pandas
To my knowledge Perl with PDL[4] was the go-to solution for bioinformatics people for a long time. I never did anything with it or Python's Pandas though, so I don't know how they compare (or more importantly, how they compared back when people actually used Perl for this stuff much).
> easy concurrency
While somewhat wonky, Perl's concurrency has been around in forms for a long time (the Coro[5] library was first released in 2001), if a bit harder to use until recently when like every other language the async/await stuff took over.
The parallelism story has always been pretty good, even if also slightly weird (the ithreads system used forks on Unix to emulate threads, but essentially it's an abstraction you can mostly ignore). Notably, the fact you actually had a threading system[6] with locks and semaphores that worked put it above Python and Ruby in that category.
> ergonomical web-frameworks to beat PHP
This took longer, but Mojolicious[7] seems to fit this category well, easily being used as simple as something like Sinatra to stuff close to Rails (IMO, and without ActiveRecord).
That's not to say Perl is perfect and should have always won out, just that I think the problems Perl experienced (and still experiences, and which recently "Perl 7" is trying to address) are more along the lines of the trade off that was made with regard to backwards compatibility and legacy support, and the effect that had long term on the community.
Perl's absolute adherence to backwards compatibility to the point that 20 year old scripts often run without issue on the latest release of the interpreter was always a boon to those that wanted stability and support. It's still used in some places (for example, where I work) as the primary scripting language for server based utilities that are expected to run in a Unix environment. The problem is that this is a trade-off that hurts more for new users and new technologies as time advances. It's great that our (literally) 20 year old scripts to clean up and do server management still function, but it's not as great that ergonomically Perl requirement to opt-in to many new features (so they don't cause old code with conflicting sub names to fail, as an example) means that there's been an ever increasing list of things you must enable in new Perl lest you deal with annoying old behavior makes it's use for new projects annoying at best. Having a good object system is only the first step, and you're right to call it out because as it was never moved to core, it never got as much use as it could have.
> Sadly it was not to be.
It is sad, because it's a nice language and I love using it most of the time, but I also feel like it wasted well over a decade of what should have been major advances because it was deemed less important than backwards compat and everybody just said "well there's a module for it, that's good enough" when it definitely wasn't sufficient. For chrissakes, Perl only got the most simplistic form of function signatures relatively recently, and what we got is far inferior to what was available and I used as a module a decade ago[8]. Perl's problems were always much deeper than not having some solution or equivalent to some nice tool or way of doing things in other languages. Those came, usually fairly quickly, it was all the other stuff that shed the users to the point that now it's hard to know if there's enough left to drive the change that's needed to keep it alive (in the sense that it's not just in bug maintenance mode).
Sorry for the rant. Obviously I'm sad about the current state of things... I've even mostly decided that I might as well do new projects in other languages, but it makes me sad that it feels like I'm doing so not because they're mostly superior at a level that's hard to compete with but because the Perl community (and this includes myself) couldn't get their shit together long enough to steal the good bits in a way that actually mattered to people looking to try a new language.
8: Function::Parameters, as in the bottom of this comment https://news.ycombinator.com/item?id=11633961, as the CPAN page does a crap job of showing it with types which is my favorite part.
>> proper OO without all that convoluted bless stuff
>
>Moose[1], and more lightweight versions in Mouse[2] and Moo[3]
I found all those frameworks, and hacking with inside-out objects to be too cumbersome and got in the way, so I just went back to blessed hashes. I liked to keep things simple.
> easy concurrency
I never got into Coro, but AnyEvent was wonderful to work with, and shaped my thinking in other languages... though you could get away with much more in Perl.
> ergonomical web-frameworks to beat PHP
I don't know how anything could be more ergonomic than Dancer (Perl's Sinatra equivalent).
> but I also feel like it wasted well over a decade of what should have been major advances
This, but thinking back at the time, I think what killed Perl was Google choosing Python. At the time, CPAN was the killer app and still had the lead vs all other higher-level languages. But then Google chose Perl instead of Python and as it was the hottest startup at the time where everyone wanted to work at, people started learning Python. Then the data scientists (except the geneticists) migrated over and NumPy, Pandas (and now TensorFlow) kept the momentum.
> I don't know how anything could be more ergonomic than Dancer (Perl's Sinatra equivalent).
My understanding it that they're very equivalent in many respects, and popped up at about the same time. Often they're mentioned together as modern options, I didn't for brevity and I'm familiar with Mojo. I think Mojolivious tries to require only core modules with optional upgrade to non-core versions if supplied. Not sure how that compares with Dancer, been a long time since I looked at it.
> I think what killed Perl was Google choosing Python.
Possibly. I saw that as the natural extension of "python is the new teaching language" stuff that started happening in colleges at around the same time, and I think that had a lot to do with it as well. I'm the end it's all about users, and new users, as old users have a natural attrition through finding other things that interest them (whether a new language or non programming pursuits) or retirement or even death. Without new users eventually the community starves. And even if you get enough new users to replace the old ones, without enough new to keep a relevant position relative to all new users, the language will be relegated to a slow decay. That is, even if perl had enough new users to replace old ones, the total programmers grew manifold over the last decades, and without a slice of that pie you're stuck as a has-been language, and eventually people leave due to the natural pull of popular and vibrant language communities.
I once worked on a two million line Perl app that provided forums and image sharing for feature phones. Remember when flip phones had a browser that defaulted to a forum of sorts? That.
I used perl years ago for all sorts of text processing and glue. I remember struggling with lists of lists. I just checked the docs[1] again to see if I've grown at all as an engineer in the last 15 years.
>Now you should be very careful that the outer bracket type is a round one, that is, a parenthesis. That's because you're assigning to an @array, so you need parentheses. If you wanted there not to be an @AoA, but rather just a reference to it, you could do something more like...
One person’s tool is another person’s livelihood, the corner stone of their professional experience, and the basis by which other people will (apparently) judge their technical expertise
The comment that upset you made a joke about their code and the tools from the late 90s. It seems you took it as a personal insult as if they were directly talking to you or about your code. It is a really odd thing over which you to get defensive. I have no horse in this race and I would never judge anyone’s expertise solely on the tools they use (given that it might not even be their choice). But between the two of you one made a very dry joke and the other got defensive for no reason when the conversation wasn’t about them.
The tools we use don’t define us. If you feel they do, please reevaluate. Perl (C, k8s, PHP, Python 2.x) are just tools. It’s like defining your identity by the brand of hammer you use.
>The tools we use don’t define us. If you feel they do, please reevaluate. Perl (C, k8s, PHP, Python 2.x) are just tools. It’s like defining your identity by the brand of hammer you use.
Maybe they shouldn't but professionally they actually do. Try to get a job using a tool you love but doesn't have widespread adoption and it's hard. X years experience using tool Y? Better have got on board earlier. Adopt something early that really takes off while you write key libraries, docs, contribute (previous times o'reilly howto books) and it can make your career.
As a class we get awfully groupthink and boosterist of our tech choices. It's not good but it's completely understandable.
Hammers are completely fungible. Two similar languages used in similar places are not. See Perl and Python. Do you really have no preference seeing jobs that specify one or the other? If so that's great - I try to be thereabouts myself too. But it's clearly not the norm and it's not as irrational as you're making out here for all I dislike it.
edit: Trying to phrase this in a pithy fashion below.
It makes zero difference to you as a carpenter if every other carpenter on earth hates your chosen brand of hammer.
It makes a world of difference to you as a programmer if your language of choice is popular or not.
I have been on both sides of hiring decisions a lot. Here's what I can tell you: a developer who has a shit load of Perl experience will be more likely to get a job at a Python shop if they show flexibility in their choices. A Python developer who bashes Perl for being a shitty terrible language will not simply because having a bad attitude is a red flag.
If you have only worked with PHP 4 for the past 20 years and have no plans to move off that language then yeah you will have a harder time. But getting defensive about it in an online discussion is a weird thing to do and honestly a red flag more than anything. The tools may define you as a professional (to some), but not as a person. Getting defensive is a personal thing. If you do it as a professional that's pretty bad. If you take professional discussions personally, in my experience you'll be very difficult as a coworker.
I write software for Apple systems. It’s modern, high-quality code, but it’s for Apple.
There are people that have never met me, and have never had any prior interactions with me, that hate (and that’s not hyperbole) me; simply because of that one fact.
I’m constantly reading stuff about Apple, and people that use/like/support/develop for Apple, that is intentionally insulting and demeaning.
I should know better, and wish you nothing but the best. Perl is a language easy to learn, and difficult to master.
> I write software for Apple systems. It’s modern, high-quality code, but it’s for Apple.
There are people that have never met me, and have never had any prior interactions with me, that hate (and that’s not hyperbole) me; simply because of that one fact.
I'm fascinated to hear this. I quite dislike Apple quite a bit as a company/entity, for a variety of pragmatic and philosophical reasons, but the idea that that would extend to their employees (let alone those working on their platform) is wild to me.
There's lots of folks with axes to grind, that are excellent spinners, and lots of people that are maybe...a bit insecure, shall we say, that eat that spin, and turn it into venom.
The old "Ford vs. Chevy" spat can get like that. People kill each other over which football teams they like.
It's easy to see why folks don't like Apple; just as it's easy to see why folks don't like every other platform.
It's just that there's a lot of really unbalanced folks out there, and even more folks who like to set those people off.
Deeply evolved back from when splitting into group A and group B could be followed by war breaking out and one lot killing the other. Thankfully these days it's more flamewars than sticks and stones.
It started around two decades ago, but I would say the "use strict if at all possible or you're doing it wrong" consensus was reached at least as long ago as 2005, being conservative. Because backwards compatibility was always seen as paramount, it never became default, but if you opted into new version features by version number[1], those advanced to enabled both new features and to turn off or warn on use of what were considered problematic features in the code. For example, a "use v5.10;" pragma would warn indirect method syntax with the assumption you never wanted that (so any new Foo("arg"); would error, so people would use Foo->new("arg"); as the sane agreed upon way it should be done), and would disable bareword filehandles (so you would need to assign them to a scalar like $FH instead of FH).
use v5.12 and later also automatically enabled strict. Perl 5.10 was released in late 2007, and 5.12 in 2010, so there was enough consensus over a decade ago to add it as the default for anyone opting into the bundle of all newer Perl features.
Thanks for that answer, very interesting to know as someone who feels like they got into perl pretty late in the game. I do appreciate it where it works for sure.
I could definitely picture programming in perl in the 90s before people commonly implemented use strict; being a complete hellscape though
Yes, and it was exacerbated by mod_perl in Apache basically working by taking a Perl script/CGI and using eval to turn it into a sub, meaning any subs defined in that script (and not a module it included) to accidentally create closures easily, which really played havoc, and so people adopted... interesting workarounds[1], all in the name of performance.
> the basis by which other people will (apparently) judge their technical expertise
You lost me here. Even if someone thinks that Perl is an unholy abomination to work with, it doesn't follow that those with expertise in it are less skilled. If anything, it seems like it implies the opposite: expertise in it is harder. The counterpart would be something like claiming that Python is a toy language, simple to use but not suitable for Real Work. This claim is the exact opposite as the Perl complaint, and it seems like _that_ would imply negative things about expertise in the language.
I cut my teeth on stuff that would have a lot of folks 'round these parts, crouching under their Uplifts, clutching their teddy-bears, peeing their pants, sucking their thumbs, and sobbing. I started off doing Machine Code and embedded stuff, back when that was still fairly new.
I am very happy to use a nice, safe, memory-avoiding, strongly-typed language like Swift as my principal language, and on a GUI system.
I don't particularly care whether or not some rando on teh Internets tubes thinks I'm a "wuss."
I doubt it. I looked them up (because I care about people, and don't actually want to hurt them), and it seems that Perl is a big part of their repertoire. Perl means a lot to them, and my flippant comment was probably taken as "calling their baby ugly."
So, @peteretep, you have my sincere apology. It was a flippant remark. At the time I wrote it (mid-1990s), Perl was the best way to write portable CGI code. I took the time to learn it, and got fairly good at it.
Since then, I have found my muse in other languages, but I sincerely did not want to give offense. I doubt that deleting the comment would help.
Some of us are veterans of the time when Perl was evangelized as the cure for everything, and the only way to sensibly think about unix programming. That led to the usual over-reaction from Perl critics and it became usual to make sharper comments about it even when you'd never used Perl.
Which all goes to show people clot up into tribes over any silly thing; and that its better not to wrap your identity too much around your tools.
Why does it feel like HN has become so incredibly sensitive? I have been reading comments here a while (13 years I think), and noticed that in the past couple of years is when critical of any piece of software, no matter how warranted or how tongue in cheek, results in comments like this. How would you have phrased the original sentiment that you wouldn’t think was nasty?
Like someone else said, 'don't take attacks on a tool you like as an attack on you.' I think theirs is the overly-sensitive reply. Why get worked up because someone doesn't like software that you do like? Bizarre.
Are you interpreting chrisseaton's comment as being in response to the original comment denigrating Perl? It seems more like it's a response to the defensive comment from petereps
Nah. Wasn't edited, but it was definitely a slap at me, personally. I touched a nerve, and was reprimanded. It was not a "fun" response, and it made me realize that I had caused offense.
Teh Internets tubes are a difficult landscape to navigate. It's almost impossible to write stuff without causing some offense.
Some folks take that as an admonition to never write anything fun. Others (like me) learn to apologize.
I'm fairly good at apologizing, as I need to do it so often. Each time, I learn to ameliorate my approach.
Just for another perspective- I read it as peter intended, a deadpan way of purposefully taking your statement literally, that you wrote code that made you scream, it wasn't Perl's fault.
I found it hilarious, but I'm a weird guy. I just can see where he is coming from where he meant it as a snide joke, not a personal attack.
This whole thread feels like a glorious exercise of Poe's Law.
I can't tell what's what, but man is it funny, to me it reads as deadpan humor by peterep with no insult intended, but obviously others read it differently.
Perspective is amazing and this has made my day from all the smiles and laughs XD
Yeah, it's weird. Even aside from different perspectives, we still get to choose how to interpret and react. "Don't take it personally" is a good way to go through life, in general.
you really make life way too hard for yourself?
why the heck would u care if random stranger is offended over a simple joke regarding a programming language?
waste of energy man
Some people are not well socialised and just like to insult programming languages, and by extension, judge and put down their users. We should extend pity to them. Or perhaps detached bemusement as in https://youtu.be/R00JE6QRbno?t=8546
Yes it is. If you write a COBOL program you're writing legacy code. Contrary to what you might think about Perl it's quickly approaching the same fate.
In university, I learned Perl out of curiousity. It was the first scripting language I tried; I was only familiar with Java, C and Scheme at the time.
After reading Programming Perl from cover-to-cover, I suddenly felt like I had superpowers. I probably would have felt the same if I'd taken the time to learn bash scripting, but that's not how it worked out.
I tried to automate everything in my life with Perl. I'd walk to class in the morning and a script had already scraped and downloaded my lecture materials and sent a print job for me. It emailed me if it couldn't find notes for one of my scheduled classes. Others would manage my assignment submissions. I wrote scrapers to detect what events on campus might offer free food.
This was the first time I felt like I could write programs that actually had the power to improve my life. It changed my perspective on what I had the power to do as a programmer. I'll always be grateful to Perl for that.
I also learned how to quickly develop a thick programmer skin by asking questions on comp.lang.perl, but that's another topic altogether.
That is what bash/pipeline programming felt like for me the first time I mastered it.
I missed the Perl boat by a few years, riding the Python2/Java wave at Uni instead, but I did encounter it a few times in legacy (read: 5-years old) code and could only marvel at its string manipulation capabilities.
I like to think of it as the extended bash that I never took the time to learn
I'm not super familiar with Perl, but I gather that it shares much of bash's, er, ergonomic hurdles.
Is there something about gaining scripting power that requires such poor usability? I resisted it for a while, but I just write all my workaday scripts in Python now, and I'm honestly a little baffled as to why I stuck with bash for so long.
I would say that Perl burst on the world about 30 years ago, and that what it allowed one to do was so compelling that it spread at tremendous speed. It was out there, it was in use, and any development had to avoid--as far as possible--breaking existing code.
It is possible to write lucid, maintainable Perl, something I have occasionally managed. It is easy to write ugly, unmaintainable Perl, and that I have too often done. If one looks at the Perl found on CPAN or in various good books on Perl, you can see how to do the former.
Perl's usability is far higher than bash and more consistent. Admittedly, there is a bit of memorisation regarding special variables, but those variables are well-documented and have a strong UNIX heritage. (and they have named versions too..)
The "future work" section of the paper covers the smearing part! The authors acknowledge that it is unknown whether the results translate to smeared paint.
This is obviously just a bit of fun, but looking at the output examples, I think the OCR used may be flawed in that it's heavily optimised to produce characters used in natural language (alpha & spaces) rather than to produce e.g. operators common in code. The number of "special characters" output is extremely small. This will bias it heavily toward producing identifiers, which will be valid in most common programming languages.
I don’t think that’s a flaw! The study is “95% of paint splatters” not “95% of random strings of ASCII characters”. If common OCR programs are optimized to produce letters and spaces, fair game!
(You would of course want a “proper” scientific study to be more rigorous about these things.)
Edit: Also, the programs in the article appear to be mostly special characters?
> I don’t think that’s a flaw! The study is “95% of paint splatters” not “95% of random strings of ASCII characters”. If common OCR programs are optimized to produce letters and spaces, fair game!
But if someone said "95% of paint splatters OCR as Welsh words" and it turned out that's because the OCR is looking for words, it doesn't say much interesting about Welsh like the title implies.
> Edit: Also, the programs in the article appear to be mostly special characters?
Look at the whole gallery though. Most of the OCR results are just a string of letters or a number. Those being valid is very mundane.
Edit: Actually if you want to make the analogy super precise, you could say "oh yeah those strings of letters are just proper nouns, which makes them valid Welsh, and of course numbers are valid Welsh"
> But if someone said "95% of paint splatters OCR as Welsh words" and it turned out that's because the OCR is looking for words, it doesn't say much interesting about Welsh like the title implies.
I think it depends on the claim, right? IMO, a more analogous statement might be "95% of paint splatters OCR as grammatically-correct Welsh sentences." Unless the software is using something like GPT-3, that finding would be notable regardless of software tuning. Even if it tells us more about Welsh grammar than it does paint splatters.
> Look at the whole gallery though. Most of the OCR results are just a string of letters or a number. Those being valid is very mundane.
> IMO, a more analogous statement might be "95% of paint splatters OCR as grammatically-correct Welsh sentences." Unless the software is using something like GPT-3, that finding would be notable regardless of software tuning. Even if it tells us more about Welsh grammar than it does paint splatters.
Well, I'd argue that "potato" is a grammatically correct sentence in most languages. (Imagine someone asked you what kind of soup you're holding.) And so is "7" and so is "Fififz".
And that's literally what's happening with Perl with the vast majority of these. It's treating a single word/number as a statement.
If you want to say something notable about grammar, you need to be generating sentences that are longer than a single noun.
yes. the paper is really just sampling the OCR software's underlying distributions, combined with perl's acceptance of a wide range of things that look like line noise.
Albeit `Const::Fast` might be considered preferable for several reasons (deeply readonly structures, variables which you can interpolate rather than barewords, etc).
It sounds like the confusion might be in declaration vs. initialization, which for language-supported consts of course have to happen at the same time. Retrofitting the concept into a language without native support for immutable bindings, you'd of course need some kind of setter on whatever object or similar you're using to encapsulate the binding and ensure it never does actually change.
I'm combining my lament about lack of "you are using a variable you didn't declare yet" error in PHP and my newly arrived at understanding of the benefits of immutable variables, and then adding to the confusion by using the "constant/const" term, which typically means "set at compile time"
In languages with a compilation step, this is true but a side effect. Really, what "const" denotes is an association between a name and a value (ie a binding, in this case an assignment, although there are other kinds of binding such as naming positional arguments in a function signature) which has to be performed when the name is declared, and which cannot be changed once made. (Hence for example in Javascript why properties of an unsealed object can still be modified even via a const binding - what's immutable isn't the value, but the association of that value with the const-declared name.)
The main issue I have with Hack is that it is a big PITA to install. Like, there's no HHVM in ArchLinux repositories (or in no other distro's repositories either), and building it is super messy. That's also why I think almost nobody is using Swift on Linux.
Nobody is going to bother with your language when it's full out there of solutions as good as yours that people can install in one second.
Most of this appears to be Perl's tolerance for "barewords" if you don't "use strict;".
I suspect this dates back to the Perl4 -> Perl5 transition, when they removed the requirement to call a subroutine using an ampersand, like &somesub could just be somesub.
Unlike, say Python, Perl doesn't require subroutines to be defined before they are called.
For reasons I don't fully understand, barewords preceded by '-' are still allowed, even with "use strict". Also allowed as hash keys like $foo{bar}=1 or (foo => "bar").
> For reasons I don't fully understand, barewords preceded by '-' are still allowed, even with "use strict".
This - the fact, rather than any justification - is documented in `perldoc perlop`:
Unary "-" performs arithmetic negation if the operand is numeric, including any string that looks like a number. If the operand is an identifier, a string consisting of a minus sign concatenated with the identifier is returned. Otherwise, if the string starts with a plus or minus, a string starting with the opposite sign is returned. One effect of these rules is that -bareword is equivalent to the string "-bareword".
Typically Perlish, that means you can do stuff like the following because, I dunno, reasons?
$ perl -E ' use strict; use warnings; say - -foo' # or -(-foo)
+foo
> Also allowed as hash keys like $foo{bar}=1 or (foo => "bar").
Quoting `perldoc perlop` again:
The "=>" operator (sometimes pronounced "fat comma") is a synonym for the comma except that it causes a word on its left to be interpreted as a string if it begins with a letter or underscore and is composed only of letters, digits and underscores. This includes operands that might otherwise be interpreted as operators, constants, single number v-strings or function calls. If in doubt about this behavior, the left operand can be quoted explicitly.
> For reasons I don't fully understand, barewords preceded by '-' are still allowed, even with "use strict".
I believe the primary motivation for this is so you can pass argument lists to subs in a key => value format without having to quote the key. For example:
someSub( -opt1 => $opt1val, -opt2 => $opt2val );
[edited for formatting, which I never seem to get right the first time]
You don't have to quote the LHS of the => operator, even if "use strict" is on. (That's the only way that it differs from a regular comma.)
> The "=>" operator (sometimes pronounced "fat comma") is a synonym for the comma except that it causes a word on its left to be interpreted as a string if it begins with a letter or underscore and is composed only of letters, digits and underscores. This includes operands that might otherwise be interpreted as operators, constants, single number v-strings or function calls. If in doubt about this behavior, the left operand can be quoted explicitly.
> Otherwise, the "=>" operator behaves exactly as the comma operator or list argument separator, according to context.
Recently I had to do some simple flat file parsing and aggregation - for some reason, I picked up Perl for a it and it was as easy and performant as ever. It just felt natural and got the job done in a few lines of code. For all the hate Perl gets, I think for specific tasks like these, it is pretty much only rivalled by Python (and compared to Perl even with strict on/avoiding magic variables etc, Python still feels verbose).
Perl is excellent for string parsing/text manipulation (makes sense as that was its original design goal). I agree on Python; "the Pythonic way" of doing things seems to result in lots of useless boilerplate.
Why are TikTok and YouTube excluded from "kids being kids" activities?
If that's what all the kids are doing then it seems that's what a kids activity has become.
I used to play with neighborhood kids quite a bit when I was younger. Now my nephew plays Fortnite almost every day with 5ish different friends. He gets way more experience socializing than I ever did.
Ultimately (I think) kids need to learn to socialize with their peers. That means they need to participate with their peers doing what their peers are doing.
> Why are TikTok and YouTube excluded from "kids being kids" activities?
Poeple in general are extremely bad at generalizing situations to match their own experiences. People get old, see younger people playing differently (new toy, new technology, new societal framework), and fail to notice that the new kind of play is still mostly the same module/class of play they had, just with a different coat of paint.
E.G. In the 80s' we used to play with k7 recorders, recording singing, pretend news casts and comedy shows. Now kids are doing youtube and tiktok, and that is exactly the same module of play, it is not some brand new thing.
Having said that, I'd like to point out that, although for the kid it is basically the same kind of play, the fact that is more public (k7 had a limited reach, just neighborhood friends, but the internet has unlimited reach) means bigger stakes, so parents should be more vigilant, it is even more crucial now that parents get involved in the kids activities to keep an eye out.
There’s a difference between socialising where you can say something dumb, and your friends will say “that was dumb haha” and everyone will move on with their lives, and socialising where you can say something dumb, someone posts it on social media, and the next day everyone at school is talking about what you did.
Ubiquitous socialising can be good but it cuts both ways, especially in an environment where you have no plausible deniability. In my opinion, people should be free to have their own thoughts, potentially get blasted for them, and move on with their lives the next day with minimal consequences. Certainly there should be no consequences coming from people that were not actually there, but just heard about it from some social media platform.
I don't know about TikTok well enough but as far as YouTube goes ... the race for eyeballs, views, even money and etc. produces some pretty skewed results / activity and carries a lot of negatives with the drive to just pump out continuous content, produce youtube drama, etc. And now all that content is out there with all the mistakes a kid will make, for the world to see, possibly forever.
Granted if a kid were to just upload fun videos... have comments off ... not interact with the community, then maybe they'd be ok? But I think all of that is not super likely as my son's friends want to be youtube stars.
When I was 10 or so, I uploaded some dumb little skits with my friends to YouTube. The videos accumulated about 2k views total, and are all gone now, and no one will ever recognize me from them.
I have kids of my own, and I think it's absolutely possible to do both. My daughter is 4 now, and loves to splash in mud and do all of that stuff. At the same time, she loves doing puzzles and art, which is still normal kid stuff.
I think the problem is that the original tweet seems to think that "coding" is only a vocational skill, and it's definitely not. When you're that age, coding is just another form of expression and exploration. It can make something useful, but it's just puzzles and fingerpaint.
That lady probably thinks programmers are the way they're depicted in Dilbert lol.
Anyways, I agree. It's another form of expression. Just like Math or Music.
But I do also agree, in part with her point, that kids should explore possibilities and be kids instead of having to worry about their vocation so young and being put on a track to become something.
Hi! I'm the author of the Perl paint-splatter paper.
"That lady" is Adrienne Porter Felt, who started as an engineer working on Google Chrome security a decade or so ago, and is now a Director of Engineering who manages a sizable chunk of the Chrome team.
I never worked with her directly, but she has a reputation as a good manager and I'm pretty sure she knows how programmers work.
> kids should explore possibilities and be kids instead of having to worry about their vocation so young and being put on a track to become something.
Yeah that's a really tough line to track. At some point they're going to develop a sense of purpose and I have no idea when or where or what or how I can nurture it.
I don't like the idea that programming is a vocational skill. Literacy and numeracy aren't. Arts and crafts skills we understand have other uses.
Programming is great for self expression, exploring new ideas, amusing people. These are great goals for kids.
If you teach a kid to program, probably they're gonna put it to use in Minecraft or Roblox, not by writing accounting software. That's good! That's no more professional software development than kids building with Legos are doing engineering.
I’ve only been a parent for five years so do with this what you will.
For us, it started at me - I had to make some big changes. When she was very little, I caught myself pushing her on a swing with my nose in my phone. Once I caught myself doing that, I broke the habit - now when we’re spending quality time together, my phone doesn’t exist.
This gives us space to do things outside, go on adventures and use our imaginations.
Devices are a huge part of her world so at other times, we either share one device and I let her quarterback or we spend an hour in bed on our own devices. I’m open about what I do on my device and she’s open about what she does on hers. In some cases, this creates an opportunity for me to teach and model. In other cases, it gives her an opportunity to teach me.
The last part has been especially important. As my girl has taught me things about her world, I’ve learned that some of my ideas about kids being kids are based on my own prejudice. I’ve caught myself expressing an overly rosy view of ‘when I was a kid’ and have tried to project that world upon her. Thankfully, my kid and I have the kind of relationship where she’s more than comfortable to tell me that I’m wrong.
My kids were raised out in the woods basically...it's tricky. When they were little they played outside quite a bit, but as they got older they just lost kind of lost interest. I think the loss of the social connection over the outdoors is some of it...they can play out there all they want but if there's nobody else out there to do the same it gets old quick.
I saw someone mention summer camp, some kind of structured mechanism to do it would help a lot i think.
I don't have kids myself but my I have nieces and nephews. They all play outside and do normal kid stuff. They get a little bit of screen time but their parents limit it.
Oldest one is 6 now, so not sure what that will be like going into their teen years. I feel like that's when it will be harder to get them offline but we will see
This. The stricter the compiler the more likely a mistake will be trivially caught by the compiler rather than be a bug that has to be hunted down in the output.
It may be easier to write in a language that isn't as strict, but it's going to take more effort to produce a *correct* result.
Given that Raku's design originally stems from the "strict" subset of Perl 5, this would never work. This only works when Perl runs in non-strict pre-5 mode (which is the default before 7.0).
Yeah, I bet you're right. My first thought was that all the different ways Raku has of letting you start entering a string literal might make up for that but, on second thought, those all need to have a corresponding closing pair so that wouldn't really help.
We should run a random number generator connected to a Perl script driving a small tentacle, set a fit function of Global Peace in the Universe, and let machine do the rest.
Well, as fun as this is, I think it really has more to do with how the OCR happens to interpret watercolor splashes as mostly characters of a charset that parse into strings in Perl. They are not "programs". Basically, anything that outputs randomish strings of ascii seems to be parseable as string values in Perl.
Good thing I gave up Perl5 years ago (after 15 years) and switched to Python. I can't even read the new Perl code, it's so obtuse. Now I like Python, it's much easier to parse because there aren't 1000 ways to do a simple thing. Perl was a write only language.
What I liked about Perl when I started using it was dictionaries, lists, regexes and CPAN. Coming from a statically typed language like C or Pascal it was freedom. Writing modules was weird, objects weird - so that meant messy code. And when they did implement something, it was always a sophisticated flavor of some rarely used programming concepts.
I feel bad about upvoting this given that I kind of agree with the tweet that this sort of responds in an inappropriate tone to (if you resonated with the message).
In a way aren't all vocational skills possibly fun, exciting and interesting? I don't really like the idea that there are "bad things" to teach. I can have fun cooking, woodworking, plumbing and even filling my taxes.
That's an excellent point. Maybe the point where it stops being "a fun thing to teach to kids" and becomes "teaching them a job" is when you force them to learn it even when they aren't having fun and don't want to because you think it will help them with a career.
I once had to learn Perl to implement an algorithm for a proof of concept. It was weird as I was only used to C like programming (and a little bit of assembly)
I once wrote an entire CMS in Perl.
I still wake up, screaming, sometimes.
[UPDATE] It appears as if my flippant remark caused upset. I am sincerely sorry that this was the case. No offense was meant.
@peteretep, you have my sincere apology. It was a flippant remark. At the time I wrote it (mid-1990s), Perl was the best way to write portable server-side code. I took the time to learn it, and got fairly good at it. Since then, I have found my muse in other languages, but I sincerely did not want to give offense. I doubt that deleting the comment would help.