91–100 of 127 posts
Earlier quoted context omitted.
I don't think the language design influence of Perl on Python was as strong as you imply. (Not that there's no influence.) Certainly the influence on Ruby was larger. Also, I seem to recall the Perl5 object model was influenced by Python.
The influences go both ways: Perl's object-orientation model was actually inspired by Python's.
C++ is also undecidable, by the way: http://blog.reverberate.org/2013/08/parsing-c-is-literally-u... Perl was a great language design lab experiment. They gave people 20 ways to do any simple thing, and then Matz and Guido looked to see which ways became popular and designed great languages that allow only those ways and maybe 1-2 more that are highly frowned upon. I'm almost as glad Perl exists as I am that I never…
Lisp is also undecidable simply because the body of a (defmacro ...) form can do anything, including getting into a loop and not terminating. Programming in general is undecidable even if the compiling of the language isn't. Whether or not a program gets to the executable stage may be decidable in some language, but whether that program terminates and calculates the correct result isn't. (So what good is the first or…
As far as "undecidable", its a feature and one of the reasons why it still remains faster than most other dynamic scripting languages.
You know there was that recent Stackoverflow analysis that concluded that Perl was the most disliked programming language? It got me to thinking about how Perl managed to become quite so profoundly disliked, and I remembered these papers and thought that maybe things like this are the reason.
Perl used to have fans with meetups and so on. I've not heard of these for a long time. IMO three things killed Perl, leaving it as an unpopular legacy husk: - loss of ecosystem. The high points for Perl were CGI.pm and its use as a "super awk" by sysadmins. The first was obliterated by other ecosystems, better and worse: PHP, Rails, Node, Go, and so on. The second was obliterated by "servers are cattle not pets": pe…
Perl is awesome. I bring in 90k+ a year making a living on perl while only working remotely ( and living in a small city where the avg household income is Honestly, the only reason python "won" was because google picked it up for internal use (and that was only because of the perl5/6 debacle since why pick perl5 since 6 would be coming out by next Christmas?) As far as "undecidable", its a feature and one of the reas…
Python's genius was to force programmers to indent their code, making sure it had at least a modicum of structure.
You know there was that recent Stackoverflow analysis that concluded that Perl was the most disliked programming language? It got me to thinking about how Perl managed to become quite so profoundly disliked, and I remembered these papers and thought that maybe things like this are the reason.
Perl used to have fans with meetups and so on. I've not heard of these for a long time. IMO three things killed Perl, leaving it as an unpopular legacy husk: - loss of ecosystem. The high points for Perl were CGI.pm and its use as a "super awk" by sysadmins. The first was obliterated by other ecosystems, better and worse: PHP, Rails, Node, Go, and so on. The second was obliterated by "servers are cattle not pets": pe…
If you haven't, I suggest reading through https://pragprog.com/book/swperl/modern-perl-fourth-edition
http://www.oilshell.org/blog/2016/10/20.html
Parsing POSIX shell is not undecideable, but bash adds a construct that relies on dynamic parsing, much like Perl.
(I cite this Perl article and the C++ one in this thread. And there is another one about parsing GNU Make.)
FWIW, Larry Wall has mentioned many times that Perl 6 fixes this problem. So he very much views it as a language design flaw. I don't think you can argue that it's not.
I watched 3 or more videos on Perl 6 and he's mentioned it at least twice.
Earlier quoted context omitted.
> Yes, "$foo=7" is literally 1 character longer than "foo=7" which seems to violate terseness. (This is the example you seem to always gravitate back to.) For the 2nd time, I'm stressing that I already agree with that definition. However, that wasn't what I was talking about. People unfamiliar with a language that happens to have "ArrayList" spelled out is not as terse as "@". I gravitate back to sigils because your…
>I gravitate back to sigils because your point, that sigils' terseness contributed majorly to Perl's decline, I didn't tie sigils to the "decline" -- I tied it to the survey's "dislike" . I also didn't claim Perl sigils is what drove Python/Ruby adoption. I never claimed a logical cause and effect between sigils and Perl's decline. Indeed, the Rust language adds a whole new taxonomy of sigils[1] and it's on the upswi…
When you quoted someone saying "how Perl managed to become quite so profoundly disliked" and said "the conspicuous reasons seem to be a combination of: 1) PERL's usage of sigils," I took that to mean you were saying that sigils were a major reason that Perl isn't well-liked by as many people anymore. I'm sorry if that was a misunderstanding.
> Because special non-obvious symbols that "don't explain themselves" are perceived as terse.
The Merriam-Webster definition of 'terse' is 'using few words: devoid of superfluity.' It is not a synonym for noisy. 'my @list' is terser than 'List list,' but both are wordier than better-liked-than-Perl languages like Python, Ruby, and Javascript, which is where Perl's mindshare went (I've been taking that last part as a given). I'm not claiming Perl isn't terse, I'm just saying that it was nonsensical to say that 'PERL's usage of sigils [...] makes code compact and terse.' Compared to C#, sure, but Perl was never competing with C#, and most of the mindshare it used to have didn't go to C#, so it's not really relevant. If the extra terseness (not noisiness) afforded by using sigils was a major reason for Perl's unpopularity, then Python, Ruby, and Javascript's popularity is very strange.
print while ();
for line in fileinput.input():
print(line)
Sigils being ugly and Perl being too terse might both be problems it has, but they're different issues.
Earlier quoted context omitted.
> Yes, "$foo=7" is literally 1 character longer than "foo=7" which seems to violate terseness. (This is the example you seem to always gravitate back to.) For the 2nd time, I'm stressing that I already agree with that definition. However, that wasn't what I was talking about. People unfamiliar with a language that happens to have "ArrayList" spelled out is not as terse as "@". I gravitate back to sigils because your…
>I gravitate back to sigils because your point, that sigils' terseness contributed majorly to Perl's decline, I didn't tie sigils to the "decline" -- I tied it to the survey's "dislike" . I also didn't claim Perl sigils is what drove Python/Ruby adoption. I never claimed a logical cause and effect between sigils and Perl's decline. Indeed, the Rust language adds a whole new taxonomy of sigils[1] and it's on the upswi…
We in fact removed these sigils from Rust because user feedback was extremely negative about them, and ' still gets a lot of complaints. Nobody has come up with something better though.
Earlier quoted context omitted.
So? It's not that uncommon for highly dynamic languages to do this. Lisp macros for example depend on being able to run arbitrary code at compile-time.
Is it? (I honestly have no idea about Lisp.) It isn't just about being able to do stuff at compile time: In Perl's case, as I understand it, you can't determine if a string of text is a valid (in the sense of generating an AST!) Perl program without executing it. This precludes things like reliable syntax highlighting . Languages can include meta-programming/macro facilities without effecting whether or not the parse…