Perl is 25 years old today(perldoc.perl.org)
perldoc.perl.org
Perl is 25 years old today
http://perldoc.perl.org/perlhist.html
130 comments
The V3/V4 days ended in 1994, before Java 1.0 was released.
http://perldoc.perl.org/perlhist.html
http://perldoc.perl.org/perlhist.html
I was first exposed to perl at Sun Microsystems in 1989, I started working on Java in 1992.
http://stuff.mit.edu/afs/sipb/user/marc/hotjava/doc/people.h... (top left corner)
http://stuff.mit.edu/afs/sipb/user/marc/hotjava/doc/people.h... (top left corner)
Happy Birthday, Perl :). At Crowdtilt, we are proud to have the majority of our stack Perl based. w00t w00t CPAN :)
Came here looking for someone else wishing Perl many happy returns as it reaches this august landmark.
I have been working as a programmer for 25 years and started using Perl in 1993 or so. I cannot express what it felt like to have this incredibly powerful tool that seemed to integrate all of the sed, awk, shell, and C code that I had for research. Using Perl absolutely felt like magic, particularly for analyzing text.
I love Python, Ruby, and Lua too, but Perl will always be the tool that quickly gets things up and running.
I have been working as a programmer for 25 years and started using Perl in 1993 or so. I cannot express what it felt like to have this incredibly powerful tool that seemed to integrate all of the sed, awk, shell, and C code that I had for research. Using Perl absolutely felt like magic, particularly for analyzing text.
I love Python, Ruby, and Lua too, but Perl will always be the tool that quickly gets things up and running.
I believe most mainstream languages used for web development are quite old now. And today it is matter of personal taste to choose one over another one unless you are constrained by coding standards.
To me Perl is awesome :) Too bad I do PHP for a living, but I still enjoy it when doing something for myself. Like last time I learned about web framework Mojolicious ( http://mojocasts.com/ ) and built http://gotldr.com and http://hntldr.com leveraging Mojolicious and Redis - https://github.com/hippich/perl-tldrer . It took me few evenings, but I really enjoyed tinkering it.
To me Perl is awesome :) Too bad I do PHP for a living, but I still enjoy it when doing something for myself. Like last time I learned about web framework Mojolicious ( http://mojocasts.com/ ) and built http://gotldr.com and http://hntldr.com leveraging Mojolicious and Redis - https://github.com/hippich/perl-tldrer . It took me few evenings, but I really enjoyed tinkering it.
I haven't written a single line of Perl for over a year now and can't remember much of the language - and I am sure I would not even be able to understand my own code anymore!
Perl is a very handy and powerful scripting language but it should not be considered as a durable solution. Whatever is quickly hacked using Perl should be probably rewritten in a much more structure language, especially if you plan on maintaining this code.
Perl is a very handy and powerful scripting language but it should not be considered as a durable solution. Whatever is quickly hacked using Perl should be probably rewritten in a much more structure language, especially if you plan on maintaining this code.
Of course one can also write perl with care and attention. Perl::Critic, the Moose family, and appropriate use of the CPAN really helps with that discipline.
Whatever is quickly hacked...
... in any language should probably be cleaned up if you plan on maintaining it.
... in any language should probably be cleaned up if you plan on maintaining it.
Unfortunately it looks like the interest in Perl may be fading a little according to Google trends: http://www.google.com/trends/explore#q=perl%2C%20python%2C%2... (Perl vs Python for comparison)
Please do yourself a favor and mouse over the letters indicating news headlines. :)
As always, XKCD sums up the situation: http://xkcd.com/224/
Do people really still use Perl? It seems to have yielded greatly to other languages in the past few years.
Are you joking? Most of the internet runs on Perl.
And Perl 6 is 24
Considering perl5 is only 18 years old then somethings gone very awry there :)
Perl6 is looking quite fresh considering how old you think it is. I just submitted an article I'd seen to HN which shows how a formula like...
http://news.ycombinator.com/item?id=4939204
Perl6 is looking quite fresh considering how old you think it is. I just submitted an article I'd seen to HN which shows how a formula like...
4.7kΩ ± 5%
http://news.ycombinator.com/item?id=4939204
I was just joking :)
It's interesting to me how often people cite "Unicode in code" as some sort of amazing thing. I once posted on S.O. about the idea that maybe we should have a programming language where the vast array of options in Unicode were exploited to make things like Regular Expressions more readable (avoiding the backslash plague alone would be worth it).
I got smacked down by people complaining that they didn't know how to type anything but ASCII.
Sigh.
It's interesting to me how often people cite "Unicode in code" as some sort of amazing thing. I once posted on S.O. about the idea that maybe we should have a programming language where the vast array of options in Unicode were exploited to make things like Regular Expressions more readable (avoiding the backslash plague alone would be worth it).
I got smacked down by people complaining that they didn't know how to type anything but ASCII.
Sigh.
Jokes tend to get downvoted on HN and there's been a few (to many) jokes in this HN post :( Your's the only one I didn't downvote because decided to leave a comment instead.
re: Unicode - Perl6 does already use unicode characters for some of its operators. Take the Hyperoperator »« (http://perlcabal.org/syn/S03.html#Hyper_operators):
re: Unicode - Perl6 does already use unicode characters for some of its operators. Take the Hyperoperator »« (http://perlcabal.org/syn/S03.html#Hyper_operators):
my @a = 1..5;
my @b = 6..10;
my @c = @a »*« @b; # => 6, 14, 24, 36, 50
@c>>++; # => 7, 15, 25, 37, 5Italicizing "jokes" is a very serious accusation.
should have died 20 years ago its an awful language in my opinion
This one is a real perl see --
|
\|/I vomited a little when I read that :)
I was going to downvote your comment, but then I clicked through and read the linked question and commentary.
I don't get what the issue is, I don't even know Perl and it seems pretty straightforward to me: Carp is a library with a set of mnemonic assertion functions for libraries to signal usage errors committed by their callers.
Do people just prefer one function with a bunch of fiddly little enums or something?
Do people just prefer one function with a bunch of fiddly little enums or something?
In my case I prefer sensible pragmatic names with some sort of hierarchy rather than random words from the dictionary.
People prefer what they've already learned.
Did get the point of your comment, are you are trying to convey that you have problems with the Perl philosophy- "There is more than one way to do it(TIMTOWTDI)"?
1. Yes 2. I also don't like that their naming convention doesn't reflect functionality. How would you assign carp, cluck, croak and confess functions?
You have chosen a very small topic to discuss the vast range of advantages TIMTOWDI offers.
Now bear with me for a minute while I explain you this whole thing.
Have you worked with a language where your though tool just wasn't for you? Have you felt that language was pushing down its own self believed principles down your throat? What happens when programmers face such situations? They just leave the tool and go to something else. Perl is one of those few tools that adapts to the programmer, rather than expecting the programmer adapt to it.
Now like every other design choices you can ever make, it has its own tradeoffs. Being flexible, adaptive, powerful and quick to evolve means at times you have to sacrifice a little consistency. You can sure present your arguments and your design perspective against it, but your design again will have its own trade offs.
Why so many different ways of doing things? For example why do we have something like 'map' and 'foreach' in Perl? You won't understand this when you have used and written code that leverages these keywords to their power. Its more or less like explaining why Ice cream is delicious to somebody who has never eaten it. Unless you taste it yourself won't truly understand.
Perl is quick to learn. You can learn as much Perl to do the kind of work you can do in Python/Java/whatever. But as you learn more Perl, you become productive at solving problems. You can do it quickly, with succinct code with more powerful syntactical features.
EDIT:Corrected typo.
Now bear with me for a minute while I explain you this whole thing.
Have you worked with a language where your though tool just wasn't for you? Have you felt that language was pushing down its own self believed principles down your throat? What happens when programmers face such situations? They just leave the tool and go to something else. Perl is one of those few tools that adapts to the programmer, rather than expecting the programmer adapt to it.
Now like every other design choices you can ever make, it has its own tradeoffs. Being flexible, adaptive, powerful and quick to evolve means at times you have to sacrifice a little consistency. You can sure present your arguments and your design perspective against it, but your design again will have its own trade offs.
Why so many different ways of doing things? For example why do we have something like 'map' and 'foreach' in Perl? You won't understand this when you have used and written code that leverages these keywords to their power. Its more or less like explaining why Ice cream is delicious to somebody who has never eaten it. Unless you taste it yourself won't truly understand.
Perl is quick to learn. You can learn as much Perl to do the kind of work you can do in Python/Java/whatever. But as you learn more Perl, you become productive at solving problems. You can do it quickly, with succinct code with more powerful syntactical features.
EDIT:Corrected typo.
"rage of advantages" - somehow this seems to perfectly capture TIMTOWDI ;-)
If you know enough about the standard Perl warn() and die(), it turns out:
croak(): (slang) To die[1]
confess(): to provide information, commonly[2] as one is dying[3]
carp(): To complain, often at length and of minor details[4]
cluck(): Not actually sure about this one, although 'clucking their disapproval' seems to be something of an english idiom.
So yeah, there's some logic to the choices, even if it is rather whimsical. It's a valid point to say it's not immediately obvious, but it doesn't take long (from experience) to figure what they do and out which one you want for a given situation.
[1] http://www.grammarphobia.com/blog/2012/01/croak.html
[2] Obviously some religions promote regular confession, but the 'deathbed confession' is afaik common even among the less pious/religious.
[3] https://en.wikipedia.org/wiki/Deathbed_confession
[4] http://dictionary.reference.com/browse/carping
croak(): (slang) To die[1]
confess(): to provide information, commonly[2] as one is dying[3]
carp(): To complain, often at length and of minor details[4]
cluck(): Not actually sure about this one, although 'clucking their disapproval' seems to be something of an english idiom.
So yeah, there's some logic to the choices, even if it is rather whimsical. It's a valid point to say it's not immediately obvious, but it doesn't take long (from experience) to figure what they do and out which one you want for a given situation.
[1] http://www.grammarphobia.com/blog/2012/01/croak.html
[2] Obviously some religions promote regular confession, but the 'deathbed confession' is afaik common even among the less pious/religious.
[3] https://en.wikipedia.org/wiki/Deathbed_confession
[4] http://dictionary.reference.com/browse/carping
Before i switched to Python as my general purpose language, i used to be a bit of a Perl fanatic.
I've still to come across a language that lets you get your ideas down as quickly. It's full of fantastic time savers, e.g. the for(<>) construct and the format output functionality cover a bunch of common use cases in minimal keystrokes (let me pipe in some data, analyse it, then spit it out in a clean report).
It can hurt readability but for small one offs, it often doesn't matter.
I've still to come across a language that lets you get your ideas down as quickly. It's full of fantastic time savers, e.g. the for(<>) construct and the format output functionality cover a bunch of common use cases in minimal keystrokes (let me pipe in some data, analyse it, then spit it out in a clean report).
It can hurt readability but for small one offs, it often doesn't matter.
My experience is almost exactly the opposite. Whenever I'm writing in Python I can't escape the feeling that the code is simply fragile due to missing language features. Obviously this starts with all the regex initializations (often quite distant in source from where they are applied) which make regular expressions in python just a huge mess.
Perl's autovification allows me to build a data structure at parse time with code that is trivially verifiable. Python forces me to sprinkle the code with a thousand tests for whether or not the field is initialized yet, or write extra code to define things like defaultdict instances (with syntax that I always have to look up, and which in my experience most python programmers don't understand).
Not to mention that if I want to use an OO syntax for that data structure I have to write extra code defining a class for it (and inevitably be yelled at by the pythonista security branch for all the __whatnot__ methods I forgot to define).
Python's comprehension/generator syntax is nice, though, and doesn't have a clean analog in perl. One thing it does do well is chaining up "filter" operations on aggregate data structures in a clean way. And that has value and is worth emulating. But honestly most of the rest of the language is junk compared to perl or ruby.
Perl's autovification allows me to build a data structure at parse time with code that is trivially verifiable. Python forces me to sprinkle the code with a thousand tests for whether or not the field is initialized yet, or write extra code to define things like defaultdict instances (with syntax that I always have to look up, and which in my experience most python programmers don't understand).
Not to mention that if I want to use an OO syntax for that data structure I have to write extra code defining a class for it (and inevitably be yelled at by the pythonista security branch for all the __whatnot__ methods I forgot to define).
Python's comprehension/generator syntax is nice, though, and doesn't have a clean analog in perl. One thing it does do well is chaining up "filter" operations on aggregate data structures in a clean way. And that has value and is worth emulating. But honestly most of the rest of the language is junk compared to perl or ruby.
I agree with you about the feeling of fragility, especially with defaultdicts.
As for regexes - while they are somewhat clumsy in python, they don't have to be defined distantly:
Re comprehensions: seems to me they are just Python's version of Perl's map and grep.
grep:
Now, on the autovivification note, I wonder if we can make a Python class that has the desired behaviors. Like:
As for regexes - while they are somewhat clumsy in python, they don't have to be defined distantly:
m = re.match(r'(\d{4})', buf)
if m:
print "year: %s" % m.group(1)
Re comprehensions: seems to me they are just Python's version of Perl's map and grep.
grep:
@good = grep { $_->{width} > 9 } @crates;
good = [c for c in crates if c['width'] > 9]
@squares = map { $_ * $_ } @nums;
squares = [i*i for i in nums]
Now, on the autovivification note, I wonder if we can make a Python class that has the desired behaviors. Like:
c = PerlishStruct()
c['foo'][17]['bar'] = 'baz'
You probably shouldn't do this in an inner loop: :-)
(There is some defaultdict functionality for autovivification in Python iirc.)
Yeah, they are all similar. I don't know enough Ruby to have an opinion.
m = re.match(r'(\d{4})', buf)
(There is some defaultdict functionality for autovivification in Python iirc.)
Yeah, they are all similar. I don't know enough Ruby to have an opinion.
For list comprehensions and a different style of generator, look at https://metacpan.org/module/List::Gen
And then there are a pile of modules that implement python-style generators, some using https://metacpan.org/module/Coro (co-routines implemented as threads), some using crazy hacks:
https://metacpan.org/module/Compile::Generators
https://metacpan.org/module/Coro::Generator
https://metacpan.org/module/Attribute::Generator
And then there are a pile of modules that implement python-style generators, some using https://metacpan.org/module/Coro (co-routines implemented as threads), some using crazy hacks:
https://metacpan.org/module/Compile::Generators
https://metacpan.org/module/Coro::Generator
https://metacpan.org/module/Attribute::Generator
Yeah, honestly though those fail the "clean" test for me. What I really meant isn't the computational capabilities of python generators but the way the mesh nicely with the way builtins like "in" or "all()" or "any()" work on plain old data. Reasoning about them, in general, isn't any harder than reasoning about a dict or list in the common case, and that's a feature missing from the perl equivalents which try to do it in a library. I'd feel comfortable throwing a comprehension into code intended to be maintained by a novice. I'd never inflict any of that junk on the poor maintainer.
I'm in a similar boat. I've largely switched to Python as my scripting language (except for one-liners), but I'll still defend Perl against those who dismiss it out of hand. After using it an Amazon, I've seen firsthand how productive one can be with the language; and, if you're careful (following, e.g., the guidelines in "Perl Best Practices" by Conway) it's very possible to write maintainable code as well.
I hear you on the one-liners issue. Python is unhelpful when it gets to that - there are no -n, -p, -l switches or special variables like there are in Perl and Ruby.
It's a shame really, since all the building blocks needed to implement a useful mode for writing one-liners are there. In fact, I have a work in progress module that tries to address this issue: https://github.com/gvalkov/python-oneliner
It's a shame really, since all the building blocks needed to implement a useful mode for writing one-liners are there. In fact, I have a work in progress module that tries to address this issue: https://github.com/gvalkov/python-oneliner
This is an interesting idea, but if you need an extremely terse DSL which doesn't look anything like Python and has to be learned anew,
why not just use Perl directly? Maybe for environments where you can't install Perl?
Thanks. My approach is actually pretty minimal. Just a read-print-loop (-n, -p), a few local variables (equivalents of $_, $~, $. etc) and a shorthand import syntax to take away some of the verbosity. There are other projects, such as pyp[1], that are more ambitious, but put you through a learning process.
By all means, everybody should use what they are comfortable with. Ruby and Perl allow you to write extremely terse and awesome one-liners, the likes of which will never be possible in Python. But if the first solution that pops into your head is a Python one, why not use that?
[1] http://code.google.com/p/pyp/
By all means, everybody should use what they are comfortable with. Ruby and Perl allow you to write extremely terse and awesome one-liners, the likes of which will never be possible in Python. But if the first solution that pops into your head is a Python one, why not use that?
[1] http://code.google.com/p/pyp/
I'm actually the reverse. I went to perl from python. I usually use it for system scripting and what I like about it is that it replaces bash nicely without removing the power of specialized syntax. I find it much easier to type open("program -args |") than to construct a subprocess object in python and manually extract lines from its output. On the other hand, python is pretty handy for larger programs, more than a few screens of dense perl syntax starts getting hard on the eyes.
Have you looked at APL or its derivatives like J and K? For certain types of work, and with experience, it's very terse and expressive.
J, now there's a language! The C source is written in a J like style: a wall of ascii punctuation interspersed with single char identifiers.
It looks like a fantastically expressive language, but i fear the learning curve would be too steep for my time invested to pay off - others would have to spend the same time to learn it as well, negating any code sharing / reuse in my org (we don't use J).
It looks like a fantastically expressive language, but i fear the learning curve would be too steep for my time invested to pay off - others would have to spend the same time to learn it as well, negating any code sharing / reuse in my org (we don't use J).
So why you moved to Python?
Good question.
I found others i had to share code with weren't as interested as me about writing maintainable perl code - i got really fed up with a patch work of "write only" perl scripts performing useful functions in prod. From DB maintenance tasks to general housekeeping, to work-arounds for prod app issues that never got prioritised for strategic fixes.
I found in practice python code produced by most others was easier maintained: it seemed to more or less force people to write more readable and therefore, maintainable code.
I also viewed the fact that Python was one of the premier languages across so many problem domains (Systems, DB, GUI, Web, Large data, GPU, etc.) as being a sure fire payoff for any time invested in it.
In environments this size it's not any one persons actions dictate what becomes the status quo: different groups will have different agendas and therefore priorities and views. I guess i was lucky that everyone else was either willing to give Python a go, or was easily convinced.
FWIW over the past few years it's proven to be a good choice for us. There are still O'Reilly books float about, esp between the newcomers but there's no zealous "where's my camel book!" shouts anymore.
I found others i had to share code with weren't as interested as me about writing maintainable perl code - i got really fed up with a patch work of "write only" perl scripts performing useful functions in prod. From DB maintenance tasks to general housekeeping, to work-arounds for prod app issues that never got prioritised for strategic fixes.
I found in practice python code produced by most others was easier maintained: it seemed to more or less force people to write more readable and therefore, maintainable code.
I also viewed the fact that Python was one of the premier languages across so many problem domains (Systems, DB, GUI, Web, Large data, GPU, etc.) as being a sure fire payoff for any time invested in it.
In environments this size it's not any one persons actions dictate what becomes the status quo: different groups will have different agendas and therefore priorities and views. I guess i was lucky that everyone else was either willing to give Python a go, or was easily convinced.
FWIW over the past few years it's proven to be a good choice for us. There are still O'Reilly books float about, esp between the newcomers but there's no zealous "where's my camel book!" shouts anymore.
* ... it seemed to more or less force people to write more readable and therefore, maintainable code.*
What do you mean by "readable" and how does Python seem to enforce that?
What do you mean by "readable" and how does Python seem to enforce that?
So one of perl's nicest features is it just plain, flat gets out of your way. If you want to write something some way, go ahead, perl will allow you.
This is great - you can cook something up in 5 lines that would take 15+ in Python and 50+ in C++. It also means that it's really tempting for some to abuse this ability, even for code which will be long lived.
This is great - you can cook something up in 5 lines that would take 15+ in Python and 50+ in C++. It also means that it's really tempting for some to abuse this ability, even for code which will be long lived.
I'm not sure I understand how that answers my question. Are you suggesting that Python doesn't get out of your way and that somehow its intransigence provides the benefit of somehow forcing people to write more readable code?
I don't believe Python is that inflexible (it's not), and I don't see how the limited and superficial ways in which Python pushes all code to look the same are really that meaningful.
I don't believe Python is that inflexible (it's not), and I don't see how the limited and superficial ways in which Python pushes all code to look the same are really that meaningful.
Here is another article covering a good deal of detail about Perl in its first 25 years, Its a great read: http://news.perlfoundation.org/2012/12/the-first-twenty-five...
The stats in the link are interesting. I recently discovered the Code::Statistics module (https://metacpan.org/module/Code::Statistics). It tells you the cyclomatic complexity of your code which wikipedia tells me is basically the number of possible paths through your code.
It might be fun to see that run against the Perl core.
I also like looking at the number of lines of code. If your features go up while complexity and lines of code go down -- that could be a good sign.
It might be fun to see that run against the Perl core.
I also like looking at the number of lines of code. If your features go up while complexity and lines of code go down -- that could be a good sign.
I'll raise the glass: here's to Perl, for being the first language I could actually get shit done in.
Unmaintainable? Who cared. Got shit done. Too many ways to do things? Who cared. Got shit done.
I have this totally false feeling that BACK THEN* we wrote IRC bots and we were happy. And `perl -e '"A"x800'` was the destroyer of worlds.
* - shit, I just realized I'm young.
Unmaintainable? Who cared. Got shit done. Too many ways to do things? Who cared. Got shit done.
I have this totally false feeling that BACK THEN* we wrote IRC bots and we were happy. And `perl -e '"A"x800'` was the destroyer of worlds.
* - shit, I just realized I'm young.
I like that Perl tends to do what you wanted it to do, rather than what you told it to do. Bugs in other languages are often because of vice-versa.
Twenty-five years already? Now it can retire with full benefits.
Here's Perl 1.0, published by Larry on comp.unix.sources 25 years ago ("Revision 1.0 87/12/18 13:07:40 root").
https://groups.google.com/group/comp.sources.unix/browse_frm...
https://groups.google.com/group/comp.sources.unix/browse_frm...
Perl Kit, Version 1.0
Copyright (c) 1987, Larry Wall
You may copy the perl kit in whole or in part as long
as you don't try to make money off it,
or pretend that you wrote it.Slightly self-promotion, but you can get a variety of old perl sources at http://www.etla.org/retroperl/ (collected by someone non-me, I can't remember who though)
I had thought someone had done a perl 1 release that built on modern systems, but on a quick hunt I can't find it.
I had thought someone had done a perl 1 release that built on modern systems, but on a quick hunt I can't find it.
The perl source repository quite many historic releases also, and the first few commit messages also contain the accompanying release notes.
See for example https://github.com/mirrors/perl/commit/8d063cd8450e59ea1c611... for the perl 1.0 annoucement (click on the [...] link to get the full commit message).
See for example https://github.com/mirrors/perl/commit/8d063cd8450e59ea1c611... for the perl 1.0 annoucement (click on the [...] link to get the full commit message).
ooh, cool, I didn't know that was there.
My more active interest in perl was pre-git :)
My more active interest in perl was pre-git :)
What can I say, it's time to die.
A karma 3 account.
Where are the Perl-hating trolls coming from on HN?
(I thought Guido said that it was time to stop trolling, so it isn't Python people now?)
Where are the Perl-hating trolls coming from on HN?
(I thought Guido said that it was time to stop trolling, so it isn't Python people now?)
I am puzzled why your immediate response is to blame Python.
A bit of a kneejerk reaction admittedly, but historically any post about Perl on reddit or HN garners reactions proclaiming how perl is entirely dead and how Python is objectively infinitely superior.
I am afraid Python fans have a history of trolling Perl. Pick up any Perl thread and you will see enough examples of Python people trying to forcing their principles down your throat, even if there is absolutely no context to mention it.
Hate is an emotional response that humans have ... how can you tell if the comment was trolling or simply a visceral response?
I don't hate Perl (I first learned CGI programming with it), but I do think there are better ways to write maintainable, enterprise scale software. There are two main problems with Perl (as I see it): 1) The language is so permissive that it allows newbs to write bad code but still obtain results. Habits, both good and bad are learned! 2) Perl experts seem to delight in writing code that's "tricky" (for lack of a better word). It's like a contest to see who can wring the most out of one 80-character line of code and it leads to mid-to-low functioning Perl programmers being confused.
I don't hate Perl (I first learned CGI programming with it), but I do think there are better ways to write maintainable, enterprise scale software. There are two main problems with Perl (as I see it): 1) The language is so permissive that it allows newbs to write bad code but still obtain results. Habits, both good and bad are learned! 2) Perl experts seem to delight in writing code that's "tricky" (for lack of a better word). It's like a contest to see who can wring the most out of one 80-character line of code and it leads to mid-to-low functioning Perl programmers being confused.
The modern perl5 production platform is mostly made up of modules built and maintained to intentionally make people -not- go 'wtf?' all the time.
Modern Perl and other recent books push people towards developing good habits.
The current generation of experts tend to either put our tricky in very well encapsulated CPAN modules, or comment the hell out of it, or both ... or if at all possible, stick it into a paste site somewhere for other people to go "whee!" at and do something sensible in the main codebase.
Your complaints about perl were absolutely valid a decade ago ... these days there's still some truth to them, but we've grown up a lot since then :)
Modern Perl and other recent books push people towards developing good habits.
The current generation of experts tend to either put our tricky in very well encapsulated CPAN modules, or comment the hell out of it, or both ... or if at all possible, stick it into a paste site somewhere for other people to go "whee!" at and do something sensible in the main codebase.
Your complaints about perl were absolutely valid a decade ago ... these days there's still some truth to them, but we've grown up a lot since then :)
I am a perl lover. For me, the TIMTOWTDI means mainly that I can write code the way I think. When I have an idea of a solution for a problem, I have no effort to make to translate this idea into perl because there exists always a concise syntax for it. Perl does not limit your thinking. Instead of loosing time fighting to adapt your mind to the language, you have freedom to improve your skills. The more you improves, the more you find cases where not common syntaxes appear to be useful. At the end, when you are an experienced perl programmer, you master most of the syntax "tricks" used by the others experienced perl programmers.
Hmmm ... I have found the same feeling with every language I've mastered. I never did master Perl but even if I had, I would have set it aside like most of the other languages that I have mastered when a compelling new language/tool/system came out. I try not to form an emotional relationship with my tools as it might adversely limit my adaptability.
Try Java. Java has its merits, but they mostly revolve around defending you from hundreds of current and former coworkers, not merging your mind with the machine the way Perl does.
>> The language is so permissive that it allows newbs to write bad code but still obtain results
How is this different than any other language? You can write bad code in any language. Perl might allow for more obfuscated code which really makes it harder to read - but that again reflects on the programmer - not the language. Take a look at a code in PHP, Python, C, or any language written by "newbs" and you will see poor practices used everywhere.
How is this different than any other language? You can write bad code in any language. Perl might allow for more obfuscated code which really makes it harder to read - but that again reflects on the programmer - not the language. Take a look at a code in PHP, Python, C, or any language written by "newbs" and you will see poor practices used everywhere.
>> The language is so permissive that it allows newbs to write bad code but still obtain results
I can't see any relevance for a professional choice if newbies can shoot bigger holes in their foot with a certain tool.
That is a natural result of a powerful tool.
>> Perl experts seem to delight
Anecdotal. Ten years old description of half humorous use (and exercises). Also very different from best practices even then -- and especially different from how many/most work today.
Let me also note: If Perl wasn't better in many ways, you trolls would make serious arguments instead of "experts seem to delight"... [Or as you wrote above "Twenty-five years already? Now it can retire with full benefits."]
But I'll bite a little. Perl has the best OO system of all the scripting languages (Moose). The CPAN is the gold standard for scripting languages (and probably everything else). The testing culture is afaik second to none. The same goes for Unicode support. And so on.
I can't see any relevance for a professional choice if newbies can shoot bigger holes in their foot with a certain tool.
That is a natural result of a powerful tool.
>> Perl experts seem to delight
Anecdotal. Ten years old description of half humorous use (and exercises). Also very different from best practices even then -- and especially different from how many/most work today.
Let me also note: If Perl wasn't better in many ways, you trolls would make serious arguments instead of "experts seem to delight"... [Or as you wrote above "Twenty-five years already? Now it can retire with full benefits."]
But I'll bite a little. Perl has the best OO system of all the scripting languages (Moose). The CPAN is the gold standard for scripting languages (and probably everything else). The testing culture is afaik second to none. The same goes for Unicode support. And so on.
I think there's a valid argument in the fact that it's diverse enough that you could have 2 highly experienced Perl coders who nevertheless disagree about an awful lot of things[1].
In professional environments or large projects, hopefully you're got a reasonably comprehensive style guides (or better yet, perlcritic config), but for smaller things, it can be a bit of a struggle to understand and conform to the specific style in question if you're trying to contribute to something new.
I don't think it's enough of an argument to dismiss the language though, and agree that the benefits far outweigh the somewhat-pointy learning curve.
[1] The old "Everyone uses 10% of C++, but they all have a different 10%" joke, basically.
In professional environments or large projects, hopefully you're got a reasonably comprehensive style guides (or better yet, perlcritic config), but for smaller things, it can be a bit of a struggle to understand and conform to the specific style in question if you're trying to contribute to something new.
I don't think it's enough of an argument to dismiss the language though, and agree that the benefits far outweigh the somewhat-pointy learning curve.
[1] The old "Everyone uses 10% of C++, but they all have a different 10%" joke, basically.
I respect Perl and people who use it, but this is a telling cultural artifact: http://www.ozonehouse.com/mark/periodic/
I am not posting this to bag on Perl, but just to show its fingerprint. If you find that periodic table to be funny or cool then you are a lot more likely to be happy with Perl than if it makes you shudder.
I am not posting this to bag on Perl, but just to show its fingerprint. If you find that periodic table to be funny or cool then you are a lot more likely to be happy with Perl than if it makes you shudder.
I do find it funny, but also, it's [perl 6] documentation. But I agree with your point that personal preference varies.
Just an anecdote: a startup I work with built a product on Rails 2. It has been successful beyond anyone's wildest dreams. But they have a huge mess on their hands now, and it was caused by -success- :)
Just an anecdote: a startup I work with built a product on Rails 2. It has been successful beyond anyone's wildest dreams. But they have a huge mess on their hands now, and it was caused by -success- :)
You claim to really not be aware that table is for a quite different language -- Perl 6?
That point has been made many, many times.
Edit: To the cultural question, there might be a point. I might add that I don't know Perl 6, but it seems like an insane amount of cool/fun toys (macro language like lisp with an Algol-like syntax?! If they can pull that off it is incredible.) That might say something about me and Perl people. But people I admire use both vim and Windows, so I'm not certain.
That point has been made many, many times.
Edit: To the cultural question, there might be a point. I might add that I don't know Perl 6, but it seems like an insane amount of cool/fun toys (macro language like lisp with an Algol-like syntax?! If they can pull that off it is incredible.) That might say something about me and Perl people. But people I admire use both vim and Windows, so I'm not certain.
I also think Perl 6 has some really cool and innovative ideas. Far from using it to smear Perl, I think it is more interesting than previous versions.
But you are in denial if you think that this chart isn't a reasonably representative cultural artifact of the Perl community and the Perl aesthetic. Perl 5 is not exactly poor in operators, and it is the same core community which produced both.
I don't think that Perl is bad. I am saying that Perl is very strongly what it is. And while some people won't like that aesthetic, I don't see why anyone should apologize for it.
But you are in denial if you think that this chart isn't a reasonably representative cultural artifact of the Perl community and the Perl aesthetic. Perl 5 is not exactly poor in operators, and it is the same core community which produced both.
I don't think that Perl is bad. I am saying that Perl is very strongly what it is. And while some people won't like that aesthetic, I don't see why anyone should apologize for it.
Is there really such a great difference between operators vs. class/method/function names? E.g., Math.pow() vs. ?
There's a huge difference in searchability for one.
"That is a natural result of a powerful tool."
I never claimed that Perl wasn't powerful ... in fact I think I stated the opposite. Where I work, Perl is the lingua franca of the ops team and they certainly get things done. But the newbies don't shoot holes in their foot ... they blow it clear off and often don't survive.
My comment above may be perceived as a bit trollish but I was also thinking about "thanking Perl for a job well done". I quit Perl for what I consider valid reasons (which you completely dismiss - My experience may be "anecdotal" to you, but it's still my experience) which you're clearly not going to agree with. But notice that I never said "you shouldn't use it". I'll even admit that some people accomplish a lot with it ... and that CPAN is almost the gold standard for everything (with the exception of Maven Central I think).
So keep using Perl if you want ... but hopefully now you'll understand those of us that will no longer use it and why it's popularity is declining (http://www.tiobe.com/index.php/content/paperinfo/tpci/index....). I expect I'll replace my current tools with something better (more productive/safer/maintainable) in the next 5 years since that's been a continuing pattern for me. What will you be using in 5, 10, 15 or 20 years?
I never claimed that Perl wasn't powerful ... in fact I think I stated the opposite. Where I work, Perl is the lingua franca of the ops team and they certainly get things done. But the newbies don't shoot holes in their foot ... they blow it clear off and often don't survive.
My comment above may be perceived as a bit trollish but I was also thinking about "thanking Perl for a job well done". I quit Perl for what I consider valid reasons (which you completely dismiss - My experience may be "anecdotal" to you, but it's still my experience) which you're clearly not going to agree with. But notice that I never said "you shouldn't use it". I'll even admit that some people accomplish a lot with it ... and that CPAN is almost the gold standard for everything (with the exception of Maven Central I think).
So keep using Perl if you want ... but hopefully now you'll understand those of us that will no longer use it and why it's popularity is declining (http://www.tiobe.com/index.php/content/paperinfo/tpci/index....). I expect I'll replace my current tools with something better (more productive/safer/maintainable) in the next 5 years since that's been a continuing pattern for me. What will you be using in 5, 10, 15 or 20 years?
Newbies writing code for things like (say) fiddling with directory trees should absolutely be writing unit tests, using VMs, etc. so that the worst outcome is that they waste time. Which isn't necessary if they devote some attention to properly learning the language.
>>My comment above may be perceived as a bit trollish
As I quoted, you also posted another obvious troll comment. So the shape of your ears and body odour are quite obvious through the screen...
>>My experience may be "anecdotal" to you
I just note the lack of modern references for your "non"-anecdotal claim.
I can give references to modern practices -- it is enough with the Best Practices book (it is seven years old...)
[As mst noted, the "Modern Perl" book is a very good reference.]
(Stopped reading after that.)
As I quoted, you also posted another obvious troll comment. So the shape of your ears and body odour are quite obvious through the screen...
>>My experience may be "anecdotal" to you
I just note the lack of modern references for your "non"-anecdotal claim.
I can give references to modern practices -- it is enough with the Best Practices book (it is seven years old...)
[As mst noted, the "Modern Perl" book is a very good reference.]
(Stopped reading after that.)
I thought HN is a place where people don't take everything so seriously (or maybe I should provide some emoticons not to be taken so seriously?). And I also don't understand why people always try to lump together such comments into troll/hater/(in this case)Python-enthusiast category (ever heard of sarcasm?).
I won't explain myself, smoyer's example (except the 'hate' part) pretty much sums up what I think about Perl. And yes, I believe it's a great language, although looking from a state of development of modern languages point of view, objectively speaking, it's a bit outdated language. And therefore, in my opinion, will find less and less applications in the future (and yes, Python is and will be its main competitor in many fields).
I won't explain myself, smoyer's example (except the 'hate' part) pretty much sums up what I think about Perl. And yes, I believe it's a great language, although looking from a state of development of modern languages point of view, objectively speaking, it's a bit outdated language. And therefore, in my opinion, will find less and less applications in the future (and yes, Python is and will be its main competitor in many fields).
good joke, ha ha.
I've found over the past decade or so that when I write a "perl" program I'm really writing about five lines of glue code around multiple CPAN packages. Well maybe more than 5 lines for control flow, some business-logic error handling, etc.
When I write in another language I spend a long time looking for a library like the ten I'd find in CPAN, sometimes I find one but often enough not, then a long time complaining about how if I used perl I'd have access to the perfect CPAN module and therefore already be done with the whole project, then basically reimplement the CPAN module in the smaller inferior language, then finally write glue logic to link stuff together.
I never fail to be amazed when I see pages and pages of an inadequate homemade xml parser written in an inferior language or maybe a blizzard of regex, and then hearing bragging about how in Perl the elegant alternative language code would closely resemble line noise. No, in Perl, those pages and pages of buggy code would instead closely resemble one line: "use XML::Simple;" Repeat a zillion times over.
My "perl" programs / systems actually shrink in length over time rather than expanding, which is unusual in smaller languages.
When I write in another language I spend a long time looking for a library like the ten I'd find in CPAN, sometimes I find one but often enough not, then a long time complaining about how if I used perl I'd have access to the perfect CPAN module and therefore already be done with the whole project, then basically reimplement the CPAN module in the smaller inferior language, then finally write glue logic to link stuff together.
I never fail to be amazed when I see pages and pages of an inadequate homemade xml parser written in an inferior language or maybe a blizzard of regex, and then hearing bragging about how in Perl the elegant alternative language code would closely resemble line noise. No, in Perl, those pages and pages of buggy code would instead closely resemble one line: "use XML::Simple;" Repeat a zillion times over.
My "perl" programs / systems actually shrink in length over time rather than expanding, which is unusual in smaller languages.
CPAN might be centralized, but Java libraries are far superior. This is not a pissing contest, but a fact. The java runtime makes everything else look amateurish and unprepared. Debugging, profiling, introspection and distribution, all built into the platform. Attach to any running process and analyze away. Perl is good when it works, but when it doesn't, it's cryptic stack traces and `exit -1`, nothing meaningful.
This is not a pissing contest ... but calling it a fact is also silly.
Perl has integrated debugging. Perl has pluggable runops so profilers can be attached to the platform (e.g. Devel::NYTProf). Distribution == CPAN and the 'make dist' system from ExtUtils::MakeMaker, again built in.
The introspection is -different-, perhaps, but I'm not sure I'd say it's better or worse.
Nothing meaningful? You set it to break into the debugger when that exception is thrown, and then debug it. I'm honestly not sure how this is any different an experience to in java - any java application not actively being debugged will write a stack trace to its log file and either exit or move on to the next request too, no?
Perl has integrated debugging. Perl has pluggable runops so profilers can be attached to the platform (e.g. Devel::NYTProf). Distribution == CPAN and the 'make dist' system from ExtUtils::MakeMaker, again built in.
The introspection is -different-, perhaps, but I'm not sure I'd say it's better or worse.
Nothing meaningful? You set it to break into the debugger when that exception is thrown, and then debug it. I'm honestly not sure how this is any different an experience to in java - any java application not actively being debugged will write a stack trace to its log file and either exit or move on to the next request too, no?
Not really true. Yesterday I was trying to debug resource-loading issues. In any normal programming language, you can just strace it and you'll see where the program is doing I/O and you can figure out where it's trying to load files from. But if everything is in a jar, you don't see any OS-level I/O happening when Java tries to load something, so you have to invent all-new tools just to figure things out. When you switch to Java you throw away 40 years of UNIX for a bunch of private methods implemented by summer interns at Sun 20 years ago. The third-party libraries are fine, but the core is not.
Also type erasure.
Also type erasure.
I agree but if we're comparing Java to Perl, type erasure is only slightly hacky compared to the whole 'bless' thing.
Funnily enough, they're both examples of the same problem, stitching new features onto a language that was not at all prepared for them.
Funnily enough, they're both examples of the same problem, stitching new features onto a language that was not at all prepared for them.
I never used strace even when doing C and sometimes C++ and still managed. Eclipse can't be beaten for Java, C/C++, PHP, Perl, Ruby and Python development.
EDIT: I just used "strace /usr/bin/java -jar myjar.jar" and saw what looks IO but I'm not familiar with strace output yet. It looks like a handy utility though. Can you give an example of something that you expected to see but didn't when you tried it?
EDIT: I just used "strace /usr/bin/java -jar myjar.jar" and saw what looks IO but I'm not familiar with strace output yet. It looks like a handy utility though. Can you give an example of something that you expected to see but didn't when you tried it?
While Java has many problems, I don't consider packages to be a wrong choice necessarily. Not all good choices will be introspectable with unix-y tools (like mmaping a vm's state into memory).
> Attach to any running process and analyze away.
Interesting. It never occurred to me to want this. What sort of use case is this for? It seems Perl is capable of something similar:
learn more here: https://metacpan.org/module/JJORE/Enbugger-2.013/lib/Enbugge...
Interesting. It never occurred to me to want this. What sort of use case is this for? It seems Perl is capable of something similar:
use Enbugger::OnError 'USR1';
learn more here: https://metacpan.org/module/JJORE/Enbugger-2.013/lib/Enbugge...
Or strace -p whatever, or gdb -p whatever.
Shockingly, attaching to running processes has been a feature of UNIX for decades.
Shockingly, attaching to running processes has been a feature of UNIX for decades.
Wow, that's cool! Thanks for sharing that. Does Perl also have something similar to Python's "import pdb; pdb.set_trace()", which lets you drop into a debugger at a predefined location in your code? I've been finding that really helpful.
Knowing Perl, it probably is possible, and I just never learned about it.
Knowing Perl, it probably is possible, and I just never learned about it.
... drop into a debugger at a predefined location in your code?
Add the line where you want the execution to stop:
Add the line where you want the execution to stop:
$DB::single = 1;
$ PERLDB_OPTS=NonStop perl -d program.pl
>>The java runtime makes everything else look amateurish and unprepared.
The java 'runtime' is hardly Java. Its like saying Pentium is C.
Java the language is hardly comparable with a scripting language like Perl.
The java 'runtime' is hardly Java. Its like saying Pentium is C.
Java the language is hardly comparable with a scripting language like Perl.
Seriously?
This is a fact: <opinion here>.
Java calling anyone else's stack traces is backwards and hilarious, and only going to get better in about 15 years when java finally gets lambdas.
This is a fact: <opinion here>.
Java calling anyone else's stack traces is backwards and hilarious, and only going to get better in about 15 years when java finally gets lambdas.
Counter point.
When I was at Google, the opinion among some of the SREs I knew was that Java there was better than elsewhere so you actually did get reasonable debugging stack traces, but the C++ libraries there were still significantly easier to debug problems in than the Java ones.
Yes, I know that those AbstractFactoryFactories let you produce convenient higher order abstractions, but when things go pear shaped, they can make it really hard to figure out what was supposed to be happening, let alone where it went wrong.
When I was at Google, the opinion among some of the SREs I knew was that Java there was better than elsewhere so you actually did get reasonable debugging stack traces, but the C++ libraries there were still significantly easier to debug problems in than the Java ones.
Yes, I know that those AbstractFactoryFactories let you produce convenient higher order abstractions, but when things go pear shaped, they can make it really hard to figure out what was supposed to be happening, let alone where it went wrong.
A recent amusing counter-example:
http://stackoverflow.com/questions/4185665/guava-equivalent-...
http://stackoverflow.com/questions/4185665/guava-equivalent-...
Half the point of CPAN is "installability", it is trivial to d/l and install lots of modules. There is also CPAN Testing which drastically helps portability. Can Java really compete with a Perl module that has a long list of dependencies (50+ is a pain but will work) and some code tying it together...? [That was the example in the GP post.]
With all due respect to the Java runtime (if not its memory use :-( ), it is part of a totally different ecosystem compared to the usual suspects of the scripting languages.
(And I'd argue that it is always easier to debug a scripting language than C/C++/Java, except maybe just for long running server processes.)
With all due respect to the Java runtime (if not its memory use :-( ), it is part of a totally different ecosystem compared to the usual suspects of the scripting languages.
(And I'd argue that it is always easier to debug a scripting language than C/C++/Java, except maybe just for long running server processes.)
"Can Java really compete with a Perl module that has a long list of dependencies (50+ is a pain but will work) and some code tying it together...? "
Maven does it. I'm pretty sure that all main languages have their equivalents too.
Even when I don't code in perl, when I get stuck and find there are no pre-built libraries in the language I'm using, I find myself going to CPAN... "Lets see how they did this in perl..."
Work stuff is mostly Ruby, Python and PHP. Entertainment is Clojure (mmmmm.... Lispy goodness) and Haskell ATM.
But for my own stuff I still reach for Perl. Best testing infrastructure on the planet and that, in combination with CPAN, lets me get shit done.
But for my own stuff I still reach for Perl. Best testing infrastructure on the planet and that, in combination with CPAN, lets me get shit done.
I interviewed you once ... approximately forever ago ... and you told me at the time you were just switching to using Ruby for fun stuff, while using Perl for work. I'm glad you switched back, and appreciate your excellent CPAN modules!
I have completely forgotten the interview I'm afraid - but I'm glad you're glad ;)
I like perl "expression": perlguts, bless, sv_2mortal, etc i feel we are listening the same song :)
Perl is 25. Python is 21. Lua is 19. Ruby is 17.
Interesting how I consider Perl an 'old' language, and the others new languages. I guess it says more about how revolutionary Perl was at the time and how quickly it became widespread. The only other language I know of that went from 0 to everywhere in under 5 years was Javascript.
Interesting how I consider Perl an 'old' language, and the others new languages. I guess it says more about how revolutionary Perl was at the time and how quickly it became widespread. The only other language I know of that went from 0 to everywhere in under 5 years was Javascript.
Made me look up the timeline of when languages were released:
http://en.wikipedia.org/wiki/Timeline_of_programming_languag...
Pascal is 42, C is 40. Lots of fun info on that page.
Pascal is 42, C is 40. Lots of fun info on that page.
I don't know where you can find widespread Pascal, but Fortran is 55 and is still actively used and distributed in NumPy.
It would be interesting to know if anything older than Fortran 77 is still in active use. I know that there is a lot of F77 still around, but the Fortran code I've seen at NASA is at least up to F90/F95. Someone who learned F95 or later and never wrote fixed format Fortran would be pretty lost if they had to work on F77 or, Backus forbid, F66. C, on the other hand, has changed much less, beyond the ANSI function declarations. I first used the C version that was in 6th Edition AT&T UNIX and that had some features that would look strange to modern users, such as initializers not using = signs:
int i 4;
and the assignment operators being the other way round:
a =+ 2;
The point is, when discussing the age of a language, how important is the degree of change over time? At what point is it a new language? The same is true of human languages. I can understand Shakespeare with little trouble, but I miss some points unless there are footnotes. I can get a bit of Chaucer, but far from full comprehension. Beowulf? Not a prayer. But it's all "English"...
int i 4;
and the assignment operators being the other way round:
a =+ 2;
The point is, when discussing the age of a language, how important is the degree of change over time? At what point is it a new language? The same is true of human languages. I can understand Shakespeare with little trouble, but I miss some points unless there are footnotes. I can get a bit of Chaucer, but far from full comprehension. Beowulf? Not a prayer. But it's all "English"...
COBOL.
People still run production COBOL programs, today, that were written in the 60s and 70s. They may compile it with a version of COBOL that has support for features like object oriented programming. But the programs were written decades ago, and do not use those features.
I know one person who, 10 years ago, went back to work for the same company that she had worked at 30 years prior. Among other things she found a PL/I program that not only was around, but the last commit on was hers. She asked them, "I'm the last person to touch that, and I don't even know that language any more! Why are you still running it?" The answer was, "It never broke." (Sadly that company went bankrupt in the financial crisis, so her code is probably now dead.)
Code can live forever.
People still run production COBOL programs, today, that were written in the 60s and 70s. They may compile it with a version of COBOL that has support for features like object oriented programming. But the programs were written decades ago, and do not use those features.
I know one person who, 10 years ago, went back to work for the same company that she had worked at 30 years prior. Among other things she found a PL/I program that not only was around, but the last commit on was hers. She asked them, "I'm the last person to touch that, and I don't even know that language any more! Why are you still running it?" The answer was, "It never broke." (Sadly that company went bankrupt in the financial crisis, so her code is probably now dead.)
Code can live forever.
A few years back, we bought a commercial address processing/validation library to use with .NET. I noticed it had a dependency on the .NET Fujitsu COBOL runtime. So even newer development might pull in COBOL code without even knowing it.
> It would be interesting to know if anything older than Fortran 77 is still in active use.
In active use, that's actually easy, especially in the industrial space (that's why I mentioned distributed as well as active, which gives another metric entirely)
Just about a year ago I was tasked with recovering software from a HP1000/RTE machine (driving an industrial oven in a forge), written in a Fortran dating back from before it was properly standardized.
We recovered the code through the machine's serial port, with the built in print functionality, which conveniently prepended a header along with the file's content. Together with pyserial at the other end, a few hours of hacking had a laptop listen via a PL2302 serial/USB adapter, parsed the printed header to get filename and a few metadata, and wrote content to the proper location.
The harder part was manually moving through directories, and printing the files at 1200 baud, through a terribly laggy and completely burned out 80x23 passive monitor.
Headers in the code mentioned it was actually older than me.
With a few massaging, the code actually compiled on a recent gfortran (F95!), but hte linking part was entirely different, and many proprietary symbols were missing. We went through the 30 years old documentation and found what we needed to stub them and plan how to act forward. The thing was actually quite close already to Unix and what we find on Linux these days, only much much more primitive. The code contained critical functions whose role was to compute thermal data for automation, according to various (thermodynamic and other) complex and undocumented rules, so I built a detailed plan about possible actions to take, including linking to C wrappers binding the stuff into Python, complete with a prototypal HTML5 visual status feedback of the automation system. That's when I left the project (and the job).
In active use, that's actually easy, especially in the industrial space (that's why I mentioned distributed as well as active, which gives another metric entirely)
Just about a year ago I was tasked with recovering software from a HP1000/RTE machine (driving an industrial oven in a forge), written in a Fortran dating back from before it was properly standardized.
We recovered the code through the machine's serial port, with the built in print functionality, which conveniently prepended a header along with the file's content. Together with pyserial at the other end, a few hours of hacking had a laptop listen via a PL2302 serial/USB adapter, parsed the printed header to get filename and a few metadata, and wrote content to the proper location.
The harder part was manually moving through directories, and printing the files at 1200 baud, through a terribly laggy and completely burned out 80x23 passive monitor.
Headers in the code mentioned it was actually older than me.
With a few massaging, the code actually compiled on a recent gfortran (F95!), but hte linking part was entirely different, and many proprietary symbols were missing. We went through the 30 years old documentation and found what we needed to stub them and plan how to act forward. The thing was actually quite close already to Unix and what we find on Linux these days, only much much more primitive. The code contained critical functions whose role was to compute thermal data for automation, according to various (thermodynamic and other) complex and undocumented rules, so I built a detailed plan about possible actions to take, including linking to C wrappers binding the stuff into Python, complete with a prototypal HTML5 visual status feedback of the automation system. That's when I left the project (and the job).
Ya, I have no clue either. Pascal was the first language I was originally taught (though I had been messing with QuickBasic for a few years before that). Pascal seemed to have died out in the late 90's.
Common Lisp is 28, which a year younger than C++ and not much older than Perl. So not a dinosaur language as some people think. <g>
Lisp was invented 54 years ago. The Common Lisp standard is the capstone on an unusually long and fractured history of development. Fortunately many of those good ideas have trickled down over the decades, making mainstream languages steadily less terrible, and competing proprietary implementations are no longer commonplace.
> Lisp was invented 54 years ago. The Common Lisp standard is the capstone on an unusually long and fractured history of development.
Hm. If we do this, then C++ is merely one 'capstone' on the history of Algol development, which is about as old as Lisp is.
Hm. If we do this, then C++ is merely one 'capstone' on the history of Algol development, which is about as old as Lisp is.
FORTRAN is the oldest language that is still used today. If you consider the Lisp dialects together as a single language, then Lisp would be a close second.
Scheme, for example, is a decade older than Common Lisp, but it's still commonly considered a Lisp (no pun intended).
Scheme, for example, is a decade older than Common Lisp, but it's still commonly considered a Lisp (no pun intended).
Counting the years from the time the languages entered the spotlight might be a better metric of age. Even though Python is only four years younger than Perl, it feels so much newer because it spent more time 'in the oven'.
I'd peg Python's coming of age around 2001, although I could be wrong about that. Ruby is even fresher out of the oven, not really reaching the limelight until 2006.
I'd peg Python's coming of age around 2001, although I could be wrong about that. Ruby is even fresher out of the oven, not really reaching the limelight until 2006.
JavaScript is 15.
When I took the job at Blekko they said "We do most of our stuff in perl" and I was dubious about that.
However, now that I've been exposed to V5 for a couple of years and have probably written a few thousand lines of code in it, I find its easier to write a quick hack in than Python, and it certainly has a better 'command line' feel than Java. But it wasn't until I started coding up a quick CMS type gizmo for making HTML pages that I truly "got" the power of CPAN backing it up. There is a lot of stuff there. Folks like me who gave up on the language in the V3/V4 days as "hopelessly hacky" should re-visit it.