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 needed to learn it.
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 order decidability, at the end of the day.)
In practice, building everyday, run of the mill programs terminates in a reasonable time. The undecidability means that the time isn't guaranteed; we must be prepared to wait arbitrarily long for a compilation, and to forcibly terminate it it we feel that it seems like it won't complete. And when we do that, we have no proof that it wouldn't have completed. But, so what; if a file that should take seconds to compile takes 15 minutes (i.e. that particular case is decidable), we still regard that as a problem. Why on Earth is it taking 15 minutes? Either something is wrong, or we have to adjust our expectation for that file.
I will say that Lisp macros are more obviously undecidable than some of the other things here, because they're obviously arbitrary Lisp code. It isn't a surprise when someone says that a Lisp function could loop forever.
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.
Going off on a tangent: I dislike standard sluggification algorithms; they’re far too fond of throwing away useful parts of the title, like small words in some or turning C++ into just c in almost all cases. parsing-c-is-literally-undecidable would be so much better as parsing-c++-is-literally-undecidable (but note that Amazon S3’s HTTP server has a broken implementation of + in file names that they refuse to fix; with that exception, using + in the URL is perfectly safe everywhere I know of) or even parsing-cpp-is-literally-undecidable (you might choose this manually) or parsing-c-plus-plus-is-literally-undecidable (a sluggifier might produce this).
ruby did not go the python way and have only have a couple ways to solve a problem. There may not be quite as many ways to solve something as perl allows but it's still allows for a lot of options.
Comments
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 needed to learn it.
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 order decidability, at the end of the day.)
In practice, building everyday, run of the mill programs terminates in a reasonable time. The undecidability means that the time isn't guaranteed; we must be prepared to wait arbitrarily long for a compilation, and to forcibly terminate it it we feel that it seems like it won't complete. And when we do that, we have no proof that it wouldn't have completed. But, so what; if a file that should take seconds to compile takes 15 minutes (i.e. that particular case is decidable), we still regard that as a problem. Why on Earth is it taking 15 minutes? Either something is wrong, or we have to adjust our expectation for that file.
I will say that Lisp macros are more obviously undecidable than some of the other things here, because they're obviously arbitrary Lisp code. It isn't a surprise when someone says that a Lisp function could loop forever.
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.
The statement about Perl came from an interview with him I read.
Guido was a designer of ABC.
He implemented it. The designers were Leo Geurts, Lambert Meertens, and Steven Pemberton. (Quoting Wikipedia.)
Yeah, Perl was released in late 1987, Python in early 1991.
So the design of Python wouldn't have been influenced by long experience with Perl.
The influences go both ways: Perl's object-orientation model was actually inspired by Python's.
I ... believe I said that.
I must not have read that far? hmm
Going off on a tangent: I dislike standard sluggification algorithms; they’re far too fond of throwing away useful parts of the title, like small words in some or turning C++ into just c in almost all cases. parsing-c-is-literally-undecidable would be so much better as parsing-c++-is-literally-undecidable (but note that Amazon S3’s HTTP server has a broken implementation of + in file names that they refuse to fix; with that exception, using + in the URL is perfectly safe everywhere I know of) or even parsing-cpp-is-literally-undecidable (you might choose this manually) or parsing-c-plus-plus-is-literally-undecidable (a sluggifier might produce this).
ruby did not go the python way and have only have a couple ways to solve a problem. There may not be quite as many ways to solve something as perl allows but it's still allows for a lot of options.
In python there are also lots of ways to do things, but usually only one obvious one. The same, I think, goes for Ruby.