Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Perl and Undecidability (2008)

jeffreykegler.com

Post reply on HN
Print view View original

81–90 of 127 posts

Re: Perl and Undecidability (2008)

#81

Post by jasode »

kbp wrote: post #73
jasode wrote: post #71

Earlier quoted context omitted.

>, I don't think that's a valid point about Perl's trajectory. Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. I feel you have my comments mixed up with someone else. >' ' are not used as sigils in Perl. I agree and I didn't say they were. That's 3 cases of nitpicking something I actually didn't claim. I can only assume this over-interpretation of things I didn't write is a…

> Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. Well, if you just weren't considering Python and Ruby, then aren't they counter-examples to your point? They're terser than Perl in that regard; if that's a major reason people moved away from Perl, then why did so many of them move to those languages? > I agree and I didn't say they were. Then why did you bring them up in a…

>They're terser than Perl in that regard;

Again, that wasn't the "regard" I was focused on. It wasn't strlen(Perl_syntax) to strlen(Python_syntax). It's not about counting characters. It was terseness of non-obvious meanings for symbols which reduced readability for many. 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 will see as not being as terse as "@". It's a different axis of terseness. This cognitive readability is orthogonal to whether people migrate to Python because it's 1 less character type in front of a variable name.

>Then why did you bring them up in a discussion about sigils?

I wasn't talking about sigils exclusively by that point. I was talking about overall readability and "line noise" to fill out the C# story.

Re: Perl and Undecidability (2008)

#82

Post by falsedan »

eesmith wrote: post #36
SonOfLilit wrote: post #26

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…

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.

Re: Perl and Undecidability (2008)

#83

Post by kbp »

jasode wrote: post #81
kbp wrote: post #73

Earlier quoted context omitted.

> Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. Well, if you just weren't considering Python and Ruby, then aren't they counter-examples to your point? They're terser than Perl in that regard; if that's a major reason people moved away from Perl, then why did so many of them move to those languages? > I agree and I didn't say they were. Then why did you bring them up in a…

>They're terser than Perl in that regard; Again, that wasn't the "regard" I was focused on. It wasn't strlen(Perl_syntax) to strlen(Python_syntax). It's not about counting characters. It was terseness of non-obvious meanings for symbols which reduced readability for many. 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…

> 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 point, that sigils' terseness contributed majorly to Perl's decline, was all I was objecting to. Python, Ruby, and Javascript don't spell out ArrayList either, yet those languages are now being used in most of the places where Perl used to be used. I ask again, if that was a major reason people left Perl, then why did the people who had that problem move to other languages that are even terser (ie, they don't spell out ArrayList and they don't even use sigils)?

Re: Perl and Undecidability (2008)

#84

Post by falsedan »

GuB-42 wrote: post #19
grabcocque wrote: post #2

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 is designed to make life easier for the guy who writes the code, not the one who reads it. The motto "there is more than one way to do it" is telling. It allows beginners to write code the way they are most familiar with and give experts a large toolbox to be most efficient in many situations. The trouble is that while the writer only needs to know a subset of the language, the reader has to know everything in o…

> Perl is designed to make life easier for the guy who writes the code

Whenever I write perl, I feel like the binary is actively fighting me, not helping me…

perl is designed to make simple things easy, and hard things possible. Readability is up the the programmer, and writability is up to the editor.

Re: Perl and Undecidability (2008)

#85

Post by eesmith »

dbcurtis wrote: post #59
dagw wrote: post #44

Earlier quoted context omitted.

I don't think the language design influence of Perl on Python was as strong as you imply. I think the influence was mainly in Guido looking at Perl and realizing he wanted a language that didn't look like that. I'm pretty sure the Guido has said that ALGOL 68 and Pascal was probably the biggest positive outside influences (together with some in-house language called ABC that he was using at the time)

Guido was a designer of ABC.

He implemented it. The designers were Leo Geurts, Lambert Meertens, and Steven Pemberton. (Quoting Wikipedia.)

Re: Perl and Undecidability (2008)

#86

Post by zbentley »

kazinator wrote: post #79
zbentley wrote: post #76

Earlier quoted context omitted.

I think the word "big" above is often overlooked when discussing Perl (5). For a scripting language, there are an incredibly huge number of core language features. Even compared to something like Ruby or a lisp-like language with a true templating/macro system. It's easily up there with c++ in terms of "number of (sometimes crazy) things you can do with the core language/distribution out of the box". And that's not e…

> I think core-language-feature counts are something it's better to have in moderation. If an app needs something, it will either get it from there, or failing that, from add-on packages. That only matters for fitting into a small embedded system where you can perhaps get a smaller image if you just bundle the exact set of packages that are required. Due to inter-package dependencies, that plan can easily be foiled.…

I agree about batteries-included languages, but that applies more to library-type tools, IMO, than language features. A library-type tool is something like "I need to get an md5 hash; I hope a function to do that is included with the language distribution so I don't need to go find a library!". A language feature is something in response to questions like "How do I express that I'm calling a method on an object? Or that I want to read a key out of a dictionary object? Or automatically generate code for a method when I call something that doesn't exist?". Those are sometimes implemented in terms of libraries, but are instead often implemented in the syntax and behavior of the language/runtime itself. For example, Java has a specific syntax for "call a method on an object instance or class", and that's "thing.methodname()". Sure, it could be implemented in the library style ("call_method(thing, 'methodname', args[])"), but that's typically not what people want. Perl tends to have, in my experience, an outlier surplus of language features and libraries.

I'm only arguing for moderation in the syntactic/language-feature department; I agree with you that a good, curated set of wide-ranging libraries is something that every language should have--ideally as part of the core distribution.

Re: Perl and Undecidability (2008)

#87

Post by [deleted] »

kbp wrote: post #73
jasode wrote: post #71

Earlier quoted context omitted.

>, I don't think that's a valid point about Perl's trajectory. Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. I feel you have my comments mixed up with someone else. >' ' are not used as sigils in Perl. I agree and I didn't say they were. That's 3 cases of nitpicking something I actually didn't claim. I can only assume this over-interpretation of things I didn't write is a…

> Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. Well, if you just weren't considering Python and Ruby, then aren't they counter-examples to your point? They're terser than Perl in that regard; if that's a major reason people moved away from Perl, then why did so many of them move to those languages? > I agree and I didn't say they were. Then why did you bring them up in a…

[deleted]

Re: Perl and Undecidability (2008)

#88

Post by [deleted] »

kbp wrote: post #73
jasode wrote: post #71

Earlier quoted context omitted.

>, I don't think that's a valid point about Perl's trajectory. Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. I feel you have my comments mixed up with someone else. >' ' are not used as sigils in Perl. I agree and I didn't say they were. That's 3 cases of nitpicking something I actually didn't claim. I can only assume this over-interpretation of things I didn't write is a…

> Again, the "Perl lost to Python/Ruby ... terseness" connection is your narrative, not mine. Well, if you just weren't considering Python and Ruby, then aren't they counter-examples to your point? They're terser than Perl in that regard; if that's a major reason people moved away from Perl, then why did so many of them move to those languages? > I agree and I didn't say they were. Then why did you bring them up in a…

[deleted]

Re: Perl and Undecidability (2008)

#89

Post by eesmith »

dagw wrote: post #44
eesmith wrote: post #36

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.

I don't think the language design influence of Perl on Python was as strong as you imply. I think the influence was mainly in Guido looking at Perl and realizing he wanted a language that didn't look like that. I'm pretty sure the Guido has said that ALGOL 68 and Pascal was probably the biggest positive outside influences (together with some in-house language called ABC that he was using at the time)

When you say "that didn't look like that", are you presenting a conjecture? There was only a few years between the first release of Perl and the start of Python.

van Rossum's 1993 paper at http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=51C... explicitly lists C, ABC, Modula-3, Icon, C++, and Smalltalk as influences.

The section "competitors or precursors" also includes Perl and Tcl. It does not appear these languages are influences.

Re: Perl and Undecidability (2008)

#90

Post by jasode »

kbp wrote: post #83
jasode wrote: post #81

Earlier quoted context omitted.

>They're terser than Perl in that regard; Again, that wasn't the "regard" I was focused on. It wasn't strlen(Perl_syntax) to strlen(Python_syntax). It's not about counting characters. It was terseness of non-obvious meanings for symbols which reduced readability for many. 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…

> 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 upswing in popularity. (Of course, someone will probably come along and think I claimed that "adding sigils to Rust contributed to its growing popularity".)

The decline of Perl's mindshare for new domains was totally separate from "sigils". The usage decline was a 2nd observation of why Perl topped the charts of "most disliked" languages.

>then why did the people who had that problem move to other languages that are even terser

You're asking that question because you're still focused on only one string length definition of "terse".

Let me try another way:

  strlen(Rust_code) > strlen(Python_code)
... and yet... Rust can still be perceived as more terse than Python. Why? Because special non-obvious symbols that "don't explain themselves" are perceived as terse. This leads to the paradox that adding to the text length makes it more terse. Lastly, not all opinions about Perl's reputation for terseness comes from Python/Ruby programmers.

[1] https://github.com/rust-lang/rust-wiki-backup/blob/master/Si...

Post reply on HN