关于Guido的ITC音频采访的想法 [英] Thoughts on Guido's ITC audio interview
问题描述
Guido在IT Conversations上进行了一次很长的采访，就像Dobb博士的Python-URL最近宣布的那样。音频剪辑可用
这里：
http://www.itconversations.com/shows/detail545.html
http://www.itconversations.com/shows/detail559.html
我想评论一下这次访谈的几个部分。
Guido在他对ABC（Python的前身）和
Python的比较中提到的一件事就是ABC与ABC有着千丝万缕的联系对于它的环境（la Smalltalk），
其中Python虽然支持交互模式，但它更多地遵循了一种类似于UNIX-style的做一件好事。哲学，旨在将
与其他工具整合，而不是整个世界。
我发现可以在两者之间进行类似的比较Python和Java。 Java的启动时间很长，以至于在命令行脚本中编写用于
的小工具以及应用程序服务器的倾向是不切实际的/>
和集成开发环境表明了对单一，自包含的单语言环境的强烈偏好。另一方面，
即使在内部只有一种方法可以做到在Python中，Python
本身是开发软件的众多方法之一，而且并不坚持是完美的一种方式。你可以使用你喜欢的任何编辑器，
语言不会让你很难使用其他的b $ b程序和流程，包括操作系统如果需要的话。
根据Guido的说法，有点讽刺的是，命令行解释器
与Python的接口更是一种事后的想法，因为我的整个经历
使用Python非常关注解释器。和许多人一样，我认为，我第一次使用Python作为计算器。 =）事实上，自从发现Python以来，我一直非常不愿意学习任何没有翻译的语言
。 Ruby，Scheme，OCaml和SML / NJ已经很有趣了，因为我可以在命令行修改它们。 perl -de
42"使用起来相当令人沮丧，就像Haskell的拥抱一样。由于
无法在命令行定义新功能。
命令行界面是加快新语言速度的好方法
和库。 Python的一个优点是它允许你将一个CLI移植到一个没有设计的环境中。例如，
Jython为Java提供了一个命令行界面，这使得使用Java
更加容忍，因为您可以实时与库进行交互。 />
了解它们在运行时的行为方式。与PythonWin和COM脚本一样。
我很高兴看到IronPython设计了一个命令行解释器
，我是否需要学习我的方法.NET匆忙。
Guido对Paul Graham做了一个有趣的评论，关于格雷厄姆的九件事情使得
Lisp Lisp（可在这里：< a rel =nofollowhref =http://www.paulgraham.com/icad.htmltarget =_ blank> http://www.paulgraham.com/icad.html ） - 我有多次阅读
这篇文章，但从来没有看到
Greenspunning声称背后的微妙讽刺：为了声称一种语言正在接近Lisp，你
必须定义Lisp的含义，据称其他语言是模仿的，这就是为什么你有权使用
声明哪个？ Lisp的9（或n）属性是最重要的。我很喜欢Paul
格雷厄姆和他的论文，但我必须承认，当我听到Guido诬陷这个论点的方式时，我也不得不笑。我不太确定Python在9中有8个
，但是：声明/表达式二分法排除了＃6，并且
缺少宏排除了＃9。这些是有争议的，取决于你如何定义
的东西，但我认为Python缺乏的最明显的事情与
Lisp和Scheme（以及Ruby）是一个符号类型（＃7）。我正在尝试理解哪些符号适用于Lisp
的上下文及其嵌套的符号列表作为可执行代码。
。在类似Python的语法中，Ruby似乎有了一些创造性的符号用途，但是到目前为止我还没有看到任何非常引人注目的东西。
Guido简要总结了与其他语言的语言比较：
- Perl：类似的利基，但Perl用于正则表达式和文本处理，并且
Python用于对象，数据结构和更多通用的
编程。强制性的TMTOWTDI论证。
- PHP：在其利基市场非常成功，是为网页添加
位脚本的点解决方案。在这种情况下并不是很有用，并且很多语言设计失误。
- Java：通常的静态与动态，静态分析与单元测试
参数。 Guido说，有这么少的问题可以在编译时捕获到
，即使是最小量的单元
测试也会遇到这些问题。 盲目性[静态]
位置......逃避了我。
- C / C ++：与Java相同的论点，加上大多数程序员都没有最后是手动内存管理的
任务。
- Lisp：即使Python中没有code-equals-data，你仍然有
编译器在运行时可用，并且你可以做很多事情来将
代码视为数据，即使它们在语法上不是偶然的。
- Smalltalk：非常类似于Python，但Python更容易将
集成到使用其他语言的现有商店，主要是（IMO），因为
Smalltalk是一个自我包含的，集成的环境因此引入它的成本要高得多。
还有一些关于为什么Java似乎是这样的内存耗费的讨论。 br />
Guido将它归结为Java的花式schmancy垃圾收集技术
其堆积和线程以及坚持深远的低级别控制
超过堆中的所有poitners。具有讽刺意味的是，（C）Python的简单引用计数和周期检测似乎比Java的GC更加耗费资源，甚至更少资源。虽然大多数语言专家认为GC是一种非常好的技术。但我认为这更多地与
Java的特定GC实现有关;例如，OCaml是垃圾收集的
但是内存占用非常少。
我认为Python决定使用引用计数是一个
更糟糕的是更好：当时，引用计数已经知道不是b $ b正确的事情，但它起作用了，并且实现了很简单。
同样，动态类型与类型推断相似。似乎Guido
分享了Alan Kay的观点，即类型推断真的是正确的东西，
但是现代语言技术真的还没准备好做到主流，
而动态类型今天起作用，并且由于其冗长，可以说是比明确/清单静态类型更好的更差的b $ b解决方案。
<从写C扩展的角度来看，Guido声称痛苦（关于内存管理）的数额大约是相同的，无论你是否为
扩展了像CPython这样的引用计数语言或收集的垃圾
语言，如Java。任何有C语言扩展经验的人都想对此进行评论吗？
类型推理特别难以添加到动态类型中
语言，一般来说，如果你从一开始就有类型
推理（比如ML和Haskell）而不是尝试
以后再进行改造，我认为结果要好得多。 Guido说他们只能通过常量在Python中可靠地使用它来实现
工作，这不是很有用。
关于Ruby，Guido说，社区比Python要小得多，
并且它更像是一个更好的Perl。而不是更好的Python。我认为
，尽管Guido和Matz都声称，Ruby在这两种语言之间几乎完全依赖于
。 Guido说他不喜欢Ruby中的代码块语法
，但是并不清楚它是否是他不喜欢的语法或代码阻止自己的b
。他确实提到过，如果你喜欢Smalltalk，
你可能会喜欢Ruby，因为代码块...
发生器和迭代器是，根据到Guido，一个80％的解决方案对于人们在Ruby中使用代码块的各种事物。我认为
新提出的PEP 343提供了额外的5-10％的解决方案，也许;
很快，Python将能够另外进行资源管理迭代
模式而不使用代码块。我仍然可以想到代码块的额外
用途，我不得不想知道有多少点解决方案。 Python
将试图避免在语言中添加代码块。
这并不是说我不认为发电机或新提出的
" with"关键词是很酷的功能。
（经过审核，我意识到Guido制作了80％解决方案评论
关于发电机与继续，不是代码块。但是，生成器
比连续或块更具特异性。）
观众中有人提到CPython VM是如此坚实，他们很惊讶没有人在Python VM上实现了一个Java程序（因为
反对其他方式，就像在Jython中一样） ）。观众中的某个人通过提及一个实际的项目尝试这个来惊讶每个人，叫做
javaclass：
http://www.boddie.org.uk/python/javaclass.html
在回答有关如何创建语言，社区，成功项目的任何问题时，Guido的反应往往是相同的：他没有''' t $ / b $ b真的知道他做了什么让它发挥作用，或者让社区关注了这么长时间以来。他说，通过跟随旧项目的脚步，开始一个新项目可能不是一个好主意。如果只有我们的b $ b可以更深入地了解成功软件项目的神秘感。 ;）
干杯，
Dave
" Dave Benjamin" < RA *** @ lackingtalent.com>在消息中写道
news：slrndbrse5.71d.ra *** @ lackingtalent.com ...Guido在IT Conversations上进行了一次很长的采访，最近由Dobb博士的Python-URL宣布了！音频片段可用
[snip]
- Java：通常的静态与动态，静态分析与单元测试
参数。 Guido说，在编译时可以捕获到如此少量的问题，即使是最小量的单元测试也会遇到这些问题。 失明的那个
[静态]
位置......逃避了我。
三年前，这是一个可行的争论。两年前，它开始显示出困难。今天任何制造它的人都可能被指责在沙滩上[1]。
被忽略的是类型信息是对于其他东西有用
比编译类型检查。主要的例子是IDE（例如IntelliJ和Eclipse）使用类型信息进行重构，代码完成以及最终其他许多事情。使用IntelliJ或Eclipse的Java程序员
可以消除Python曾经拥有的优势，甚至可能超前。
在Python社区中唯一含糊不清的东西
是Bycycle Repair Man，而且，对于它来说，它很糟糕，与Eclipse相比，它很糟糕或者IntelliJ可以做到。
我同意Guido在采访中稍后的观点，即类型推断
是要走的路，它是'很难将它改装成现有的
语言。困难并不意味着不可能。
开始的地方是通过标准物品并确保所有返回
值都有意义。
我'我会在字符串库中抛出一个非常简单的例子。
index（）和find（）方法及其变体遭受了从C库继承的非显而易见性的坏b / b
案例。非常简单的替换可以解决这个问题。
---------------------- ----------
findall（[maxfind，] sub，[start，[end]]）
findall返回与sub匹配的每个子字符串的起始索引
的列表（可能是一个元组）。如果没有匹配项，
将返回一个空列表。最多返回maxfind索引。
start和end与现有的find和
索引方法具有相同的含义。
--------------------------------
此版本直观地使用if语句（一个空的
，并且只有一个常量（创建
列表）如果使用maxfind参数。它永远不会抛出
异常（除非参数列表的类型错误）。
它是一个可以干净利用的方法示例
类型推理器，而索引和查找方法不能。
[snip]
John Roth
[1]我很清楚，ostritch不会把头埋在沙子中，以避免看到令人痛苦的事情，比如推进
天敌。然而，它是一个有用的比喻。
欢呼，
戴夫
Dave Benjamin写道：Guido在他对ABC（Python的
前身）和Python的比较中提到的一件事是ABC与其环境有着千丝万缕的联系（la
Smalltalk），
让我感到惊讶的是，这是他真正提到的唯一一件事。
他没有提到ABC的理论基础， />
他只参与了ABC的实施，而其他人则完成了语言设计的全部工作。而他的主要批评是在实际任务中使用ABC，例如阅读外部文件，这是一个实用的问题。它解释了为什么有时Python的功能似乎更多是实现驱动的，而不是设计驱动的.b $ b。比如也许是使用self，但是一个例子就是切片语法，借用了语言Icon
显然。
我想当你从语言中借用一些功能但不是全部时，你需要重新评估语言设计的每个部分。例如，
行结尾处的冒号在ABC语言中提供了可读性，因为
关键字都是大写的（与python不同）。因此有效的冒号
抵消了大写单词对
可读性的一些负面影响。然而，在Python中，我根本不知道冒号真的是多么需要
才能提供可读性。还有其他问题，比如改变python是不区分大小写的，或者制作7/4 == 1.75而不是
，即使是Guido想要的一点也是如此（
http://www.linuxjournal.com/article/5028），但只有后者实现了（但是默认情况下还没有启用）。
我发现在Python和Python之间可以进行类似的比较Java的。
Java的启动时间太长，以至于编写用于命令行脚本的小型
工具是不实际的，并且应用程序
服务器和集成开发环境的倾向表明对于单一，自包含的单语言环境，强烈偏好
。
这是一个非常好的观点。是的，你从来没有听说过人们使用java来制作快速的小脚本，其中python和php非常适合
（等等）。
Guido对Paul Graham做了一个有趣的评论，关于Graham的九件事使得Lisp Lisp（可在这里找到： http://www.paulgraham.com/icad.html ） - 我多次读过这篇文章，但从未看到过背后的微妙讽刺声称
Greenspunning：为了声称一种语言正在接近Lisp，你必须定义Lisp的内容，其他语言据称是模仿的，这就要求为什么你有权声明Lisp的哪个（或n）属性最重要的问题。我非常喜欢保罗格雷厄姆和他的论文，但我必须承认，当我听到圭多诬陷这个论点的方式时，我也要笑。我不太确定Python在9中有8个，但是：语句/表达式二分法排除了＃6，而且缺少宏排除＃9。这些都是有争议的，取决于你如何定义事物，但我认为Python缺乏的最明显的事情是与Lisp和Scheme（以及Ruby）相比是一种符号类型（＃7）。我正在尝试理解哪些符号适用于Lisp的上下文，以及它作为可执行代码的嵌套符号列表。 Ruby似乎已经在Python类语法中对符号进行了一些创造性的使用，尽管到目前为止我还没有看到任何令人信服的东西。
我在本笔记中提到的其他python扩展和后代是
探索lisp有两个主要的东西，但是python没有 - ＃6
消除表达式/语句区别（至少在某些情况下
喜欢赋值）和＃9宏：
http://groups-beta.google.com/group/ ... de = print& hl = en
- Java：通常的静态与动态，静态分析与单元测试
参数。 Guido说，在编译时可以捕获到如此少量的问题，即使是最小量的单元测试也会遇到这些问题。 [静态]
位置的失明......逃脱了我。
正如其他地方所指出的，类型声明还有助于记录代码，以及大大加快程序速度。
我认为Python决定使用引用计数是更好的一个例子：当时，引用计数已经知道不是
右边事情，但它工作，实施很简单。
同样动态类型与类型推断。似乎Guido
赞同Alan Kay的观点，即类型推断确实是正确的事情，但是现代语言技术真的还没有准备好让它成为主流，而动态今天打字工作，并且由于其冗长，可以说是比明确/清单静态打字更好的更差的解决方案。
这很有趣。虽然类型推断并不总是完美的。
在某些情况下，它无法推断出类型，或者它推断出你真正想要的类型错误类型。类型推断+动态类型是一个很好的组合，可以加快你的代码速度，而不会减慢你的
编码。
类型推理特别困难添加到一个动态类型的语言，一般来说，如果你从一开始就有类型的推理（比如ML和Haskell）而不是尝试改进它，那么我认为结果要好得多。后来。
为类型推断，静态类型
语言添加动态类型更容易。
观众中有人提到CPython虚拟机是如此坚固，他们感到惊讶没有人在Python VM上实现Java程序（因为与其他方式相反，如在Jython中）。
CPython虚拟机专门针对Python而言，以及
Python的动态类型。难怪其他语言没有像java VM或.NET / Mono CLR那样构建在它上面。
有人进来观众通过提到一个实际项目尝试这个来让所有人感到惊讶，称为javaclass：
听起来它真的是将java类转换为python类，
这是非常不同的事情。提到的很多限制如：
"它运行在Python运行时，它没有安全性，
线程和即时编译器功能，人们喜欢关于
Java运行时
2005年6月25日星期六19:31:20 -0600，John Roth写道：
< blockquote class =post_quotes>
Dave Benjamin < RA *** @ lackingtalent.com>在消息中写道
新闻：slrndbrse5.71d.ra *** @ lackingtalent.com ...Guido做了很长时间的采访，可以在IT Conversations上找到，因为
最近Dobb博士的Python-URL宣布了！音频剪辑可用
[snip]
- Java：通常的静态与动态，静态分析与单元测试
参数。 Guido说，在编译时可以捕获到如此少量的问题，即使是最小量的单元测试也会遇到这些问题。 盲目的那个
[静态]
位置......逃避了我。
三年前，这是一个可行的争论。两年前，它开始显示出困难。今天任何制造它的人都可能被指责在沙子里[1]。
被忽略的是类型信息对其他东西有用
比编译类型检查。主要的例子是IDE（例如IntelliJ和Eclipse）使用类型信息进行重构，代码完成以及最终其他许多事情的方式。使用IntelliJ或Eclipse的Java程序员可以消除Python曾经拥有的优势，甚至可能继续推进。
我没有'没有使用IntelliJ或Eclipse，所以我想我必须接受你的话
它们有多棒。
[snip]我'我会在字符串库中抛出一个非常简单的例子。
index（）和find（）方法及其变体遭受了从C库继承的非显而易见性的坏情况。
确实是非显而易见的非常糟糕的情况，因为对于我而言，根本不是什么特别的非显而易见的是，你指的是
。
一个非常简单的替换会解决这个问题。
----- ---------------------------
findall（[maxfind，] sub，[start，[end]] ）findall返回匹配sub的每个
子字符串的起始索引的列表（可能是一个元组）。如果没有匹配项，则返回一个空列表。最多返回maxfind索引。 start和end具有与现有find和index方法相同的含义。
我是唯一一个有保留意见的人，在与他们做任何事情之前必须建立所有比赛的清单吗？
s =" a" * 10000000＃10 MB要搜索的数据
L = s.findall（" a"）＃很多匹配意味着L非常大
或想象一个更复杂的情况，我必须以编程方式更改我的
搜索字符串。我可能不知道我需要多少匹配，直到我找到它们并且可以分析比赛周围的文字。
对我而言似乎没有要查找所有匹配项，无论您实际想要什么，请将查找转换为生成器。然后
findall成为列表（找到），你仍然可以灵活地找到
一次匹配一个。
这个version直观地使用if语句（空列表是错误的），直接转换为for语句，可以实现为
迭代器，并且只是通过常量来降低效率（创建
list）如果使用maxfind参数。它永远不会抛出异常
（除非参数列表的类型错误）。它是一个
方法的例子，可以与类型推理器干净利用，而索引
和查找方法不能。
呃，这是怎么回事？怎样才能干净利用？为什么
找不到？
-
史蒂文。
Guido gave a good, long interview, available at IT Conversations, as was
recently announced by Dr. Dobb''s Python-URL! The audio clips are available
here:
http://www.itconversations.com/shows/detail545.html
http://www.itconversations.com/shows/detail559.html
I''d like to comment on a few parts of that interview.
One thing Guido mentions in his comparison of ABC (Python''s predecessor) and
Python is how ABC was inextricably tied to its environment (a la Smalltalk),
where Python, though it supports an interactive mode, follows more of a
UNIX-style "do one thing well" philosophy, and was designed to integrate
with other tools rather than being a whole world to its own.
I find that a similar comparison can be made between Python and Java. Java''s
startup time is so long that it is not practical for writing small tools for
use in command-line scripts, and the propensity toward application servers
and integrated development environments suggests a strong preference for a
monolithic, self-contained, single-language environments. On the other hand,
even though internally "there''s only one way to do it" in Python, Python
itself is one of many ways to develop software, and does not insist on being
the one perfect way to do it. You can use whatever editor you like, and the
language doesn''t go out of its way to make it difficult to use other
programs and processes, including the operating system if so desired.
It is a bit ironic that, according to Guido, the command-line interpreter
interface to Python was more of an afterthought, since my whole experience
with Python has very much centered around the interpreter. Like many, I
think, my first use for Python was as a calculator. =) In fact, since
discovering Python, I''ve been very resistant toward learning any language
that doesn''t have an interpreter. Ruby, Scheme, OCaml and SML/NJ have been
fun to learn because I can tinker with them at the command line. "perl -de
42" is rather frustrating to use, as is Haskell''s "hugs" due to the
inability to define new functions at the command line.
Command-line interfaces are a great way to get up to speed on new languages
and libraries. One of the advantages of Python is that it allows you to
graft a CLI onto environments that weren''t designed with one. For instance,
Jython gives Java a command-line interface, and this makes working with Java
much more tolerable since you can interact with libraries in real-time and
learn how they behave at runtime. Likewise with PythonWin and COM scripting.
I am glad to see that IronPython is designed with a command-line interpreter
as well, should I ever need to learn my way around .NET in a hurry.
Guido makes a funny jab at Paul Graham about Graham''s nine things that make
Lisp Lisp (available here: http://www.paulgraham.com/icad.html) - I had read
this essay many times but never saw the subtle irony behind claims of
"Greenspunning": in order to claim that a language is approaching Lisp, you
have to define what it is about Lisp that other languages are purportedly
emulating, and this begs the question of why you have the authority to
declare which 9 (or n) attributes of Lisp are most important. I like Paul
Graham and his essays a lot, but I must admit I had to laugh too when I
heard the way Guido framed this argument. I''m not so sure that Python has 8
out of 9, though: the statement/expression dichotomy rules out #6, and the
lack of macros rules out #9. These are arguable, depending on how you define
things, but I think the most obvious thing that Python lacks compared with
Lisp and Scheme (and also Ruby) is a symbol type (#7). I''m in the process of
trying to understand what symbols are good for, outside the context of Lisp
and its nested lists of symbols as executable code. Ruby seems to have come
up with some creative uses for symbols within Python-like syntax, though I
haven''t seen anything terribly compelling so far.
Guido briefly summarizes language comparisons with other languages:
- Perl: similar niche, but Perl is for regexes and text processing, and
Python is for objects, data structures, and more general-purpose
programming. Obligatory TMTOWTDI argument.
- PHP: very successful at its niche, being a point-solution for adding
bits of script to web pages. Not very useful outside that context, and
lots of language-design gaffes.
- Java: the usual static vs. dynamic, static analysis vs. unit testing
arguments. Guido says that there''s such a small amount of problems that
can be caught at compile time, and even the smallest amount of unit
testing would also catch these problems. "The blindness of that [static]
position... escapes me."
- C/C++: same arguments as Java, plus most programmers aren''t up to the
task of manual memory-management.
- Lisp: even though there''s no code-equals-data in Python, you still have
the compiler available at runtime, and there''s a lot you can do to treat
code as data even though they''re not syntactically idnentical.
- Smalltalk: very similar to Python, but Python is easier to integrate
into existing shops that use other languages, mainly (IMO) because
Smalltalk is a self-contained, integrated environment so the cost of
introducing it is much higher
There was also some discussion on why Java seems to be such a memory hog.
Guido chalks it up to Java''s "fancy schmancy garbage collection technology"
with its heaps and threads and insistance on far-reaching low-level control
over all the poitners in the heap. It is a bit ironic that (C)Python with its
simple reference-counting plus cycle-detection seems much less
resource-hungry than Java''s GC, even though most language experts consider
GC to be a vastly better technique. But I think this has more to do with
Java''s particular implementaion of GC; OCaml, for instance, is
garbage-collected but has a very lean memory footprint.
I think Python''s decision to use reference counting was an instance of
worse-is-better: at the time, reference counting was already known not to be
"the right thing", but it worked, and the implementation was simple.
Likewise with dynamic typing versus type inference. It seems that Guido
shares Alan Kay''s viewpoint that type inference is really "the right thing",
but modern language technology is really not ready to make it mainstream,
whereas dynamic typing works today, and is arguably a better "worse"
solution than explicit/manifest static typing due to its verbosity.
From the perspective of writing C extensions, Guido claims that the amount
of pain (regarding memory management) is about the same whether you''re
extending a reference-counted language like CPython or a garbage collected
language like Java. Anyone with experience writing C extensions want to
comment on this?
Type inferencing is especially difficult to add to a dynamically typed
language, and in general I think results are much better if you have type
inference from the very beginning (like ML and Haskell) rather than trying
to retrofit it later. Guido says that they''ve only been able to get it to
work reliably in Python with constants, which isn''t very useful.
Regarding Ruby, Guido said that the community is much smaller than Python,
and that it''s much more of a "better Perl" than a "better Python". I think
that, despite claims by both Guido and Matz, Ruby sits pretty much on the
fence betwee the two languages. Guido says he dislikes the code block syntax
in Ruby, but doesn''t make it clear whether it''s the syntax he dislikes or
the code blocks themselves. He does mention that if you like Smalltalk,
you''ll probably like Ruby because of the code blocks...
Generators and iterators are, according to Guido, an "80% solution" for the
kinds of things people use code blocks for in Ruby. I think that the
newly-proposed PEP 343 offers adds another 5-10% to the solution, perhaps;
soon, Python will be able to do resource management in addition to iteration
patterns without the use of code blocks. I can still think of additional
uses for code blocks, and I have to wonder how many "point solutions" Python
is going to gain in attempt to avoid adding code blocks to the language.
This is not to say that I don''t think generators or the newly proposed
"with" keyword are cool features to have.
(Upon review, I realize that Guido made the "80% solution" comment
regarding generators vs. continuations, not code blocks. Still, generators
are far more specific of a tool than either continuations or blocks.)
Someone in the audience mentioned that the CPython VM is so solid they''re
surprised nobody''s implemented a Java program on top of the Python VM (as
opposed to the other way around, as in Jython). Someone in the audience
surprised everyone by mentioning an actual project attempting this, called
javaclass:
http://www.boddie.org.uk/python/javaclass.html
In response to any question on how to create a language, a community, a
successful project, Guido''s response tended to be the same: he doesn''t
really know what he did that made it work, or made the community follow
Python so well and for so long. He says it''s probably not a good idea to
start a new project by following in the footsteps of an old one. If only we
could tap a bit deeper into the mystique of successful software projects. ;)
Cheers,
Dave
"Dave Benjamin" <ra***@lackingtalent.com> wrote in message
news:slrndbrse5.71d.ra***@lackingtalent.com...Guido gave a good, long interview, available at IT Conversations, as was
recently announced by Dr. Dobb''s Python-URL! The audio clips are available
[snip]
- Java: the usual static vs. dynamic, static analysis vs. unit testing
arguments. Guido says that there''s such a small amount of problems that
can be caught at compile time, and even the smallest amount of unit
testing would also catch these problems. "The blindness of that
[static]
position... escapes me."
Three years ago, this was a viable arguement. Two years ago, it was
beginning to show difficulties. Today anyone who makes it can be
accused of having their head in the sand [1].
What''s being ignored is that type information is useful for other things
than compile type checking. The major case in point is the way IDEs
such as IntelliJ and Eclipse use type information to do refactoring, code
completion and eventually numerous other things. A Java programmer
using IntelliJ or Eclipse can eliminate the advantage that Python
used to have, and possibly even pull ahead.
The only thing that is even vaguely similar in the Python community
is Bycycle Repair Man, and, to be brutal about it, it sucks in
comparison with what either Eclipse or IntelliJ can do.
I agree with Guido''s point later in the interview that type inference
is the way to go, and that it''s very difficult to retrofit it to an existing
language. Difficult does not mean impossible though. The place to
start is to go through the standard objects and make sure all return
values make sense.
I''ll throw out one very simple example in the string library. The
index() and find() methods, and their variants, suffer from a bad
case of non-obviousness inherited from the C library. A very
simple replacement would fix this.
--------------------------------
findall([maxfind,] sub, [start, [end]])
findall returns a list (possibly a tuple) of the beginning index
of each substring which matches sub. If there are no matches,
an empty list is returned. At most maxfind indexes are returned.
start and end have the same meaning as in the existing find and
index methods.
--------------------------------
This version works intuitively with if statements (an empty
list is false), goes directly into for statements, can be implemented
as an iterator, and is only less efficient by a constant (creation of
the list) if the maxfind parameter is used. It never throws an
exception (unless the parameter list has the wrong types).
Its an example of a method that can be used cleanly with a
type inferencer, while the index and find methods cannot.
[snip]
John Roth
[1] I''m well aware that ostritches do not stick their heads in
the sand to avoid looking at distressing things, such as advancing
predators. It is, however, a useful metaphor.
Cheers,
Dave
Dave Benjamin wrote:One thing Guido mentions in his comparison of ABC (Python''s predecessor) and Python is how ABC was inextricably tied to its environment (a la Smalltalk),
What surprised me was that this was the only thing he really mentioned.
He didn''t mention anything about the theoretical underpinnings of ABC,
he was only involved in the implementation of ABC, and others did all
the language design. And his main criticism is a pragmatic issue with
using the ABC in real tasks like reading external files. It explains
why sometimes Python''s features seem to be more implementation-driven
rather than design-driven. Such as perhaps the use of self, but a
counter-example is slicing syntax, borrowed from the language Icon
apparently.
I think when you borrow some features from a language but not all, you
have to re-evaluate every part of the language design. Colons at the
end of lines for example help readability in the ABC language because
keywords are all uppercase (unlike python). So the colons in effect
counteract some of the negative impact uppercase words place on
readability. In Python however, I don''t see how colons really are
needed to help readability at all. And there are other issues too such
as changing python to be case-insensitive or making 7/4 == 1.75 instead
of 1 which even Guido wanted at one point (
http://www.linuxjournal.com/article/5028 ), but only the latter was
implemented (yet not enabled by default yet).
I find that a similar comparison can be made between Python and Java. Java''s startup time is so long that it is not practical for writing small tools for use in command-line scripts, and the propensity toward application servers and integrated development environments suggests a strong preference for a monolithic, self-contained, single-language environments.
That''s a very good point. Yeah you never hear of people using java for
making quick little scripts, which python and php are really great for
(among other things).
Guido makes a funny jab at Paul Graham about Graham''s nine things that make
Lisp Lisp (available here: http://www.paulgraham.com/icad.html) - I had read
this essay many times but never saw the subtle irony behind claims of
"Greenspunning": in order to claim that a language is approaching Lisp, you
have to define what it is about Lisp that other languages are purportedly
emulating, and this begs the question of why you have the authority to
declare which 9 (or n) attributes of Lisp are most important. I like Paul
Graham and his essays a lot, but I must admit I had to laugh too when I
heard the way Guido framed this argument. I''m not so sure that Python has 8
out of 9, though: the statement/expression dichotomy rules out #6, and the
lack of macros rules out #9. These are arguable, depending on how you define
things, but I think the most obvious thing that Python lacks compared with
Lisp and Scheme (and also Ruby) is a symbol type (#7). I''m in the process of
trying to understand what symbols are good for, outside the context of Lisp
and its nested lists of symbols as executable code. Ruby seems to have come
up with some creative uses for symbols within Python-like syntax, though I
haven''t seen anything terribly compelling so far.
Other python extensions and descendants I mentioned in this note are
exploring the two main things lisp has but python doesn''t - #6
eliminating the expression/statement distinction (at least in some cases
like assignments), and #9 macros:
http://groups-beta.google.com/group/...de=print&hl=en
- Java: the usual static vs. dynamic, static analysis vs. unit testing
arguments. Guido says that there''s such a small amount of problems that
can be caught at compile time, and even the smallest amount of unit
testing would also catch these problems. "The blindness of that [static]
position... escapes me."
As pointed out elsewhere, type declarations also help with documenting
your code, as well as dramatically speeding up your program.
I think Python''s decision to use reference counting was an instance of
worse-is-better: at the time, reference counting was already known not to be
"the right thing", but it worked, and the implementation was simple.
Likewise with dynamic typing versus type inference. It seems that Guido
shares Alan Kay''s viewpoint that type inference is really "the right thing",
but modern language technology is really not ready to make it mainstream,
whereas dynamic typing works today, and is arguably a better "worse"
solution than explicit/manifest static typing due to its verbosity.
That''s very interesting. Type inference isn''t always perfect though.
There are some cases where it can''t infer the type, or it infers the
wrong type that you really want. Type inference + dynamic typing is a
good combination that can speed up your code without slowing down your
coding.
Type inferencing is especially difficult to add to a dynamically typed
language, and in general I think results are much better if you have type
inference from the very beginning (like ML and Haskell) rather than trying
to retrofit it later.
It''s easier to add dynamic typing to a type inferenced, statically typed
language.
Someone in the audience mentioned that the CPython VM is so solid they''re
surprised nobody''s implemented a Java program on top of the Python VM (as
opposed to the other way around, as in Jython).
The CPython VM is really geared specifically for the Python alone, and
Python''s dynamic typing. It''s no wonder other languages haven''t been
built upon it unlike the java VM or the .NET/Mono CLR.
Someone in the audience surprised everyone by mentioning an actual project attempting this, called
javaclass:
Sounds like it really is converting java classes to python classes,
which are very different things. Lot of limitations mentioned such as:
"It runs on the Python runtime which does not have the security,
threading and just-in-time compiler features that people enjoy about
Java runtimes"
On Sat, 25 Jun 2005 19:31:20 -0600, John Roth wrote:
"Dave Benjamin" <ra***@lackingtalent.com> wrote in message
news:slrndbrse5.71d.ra***@lackingtalent.com...Guido gave a good, long interview, available at IT Conversations, as was
recently announced by Dr. Dobb''s Python-URL! The audio clips are available
[snip]- Java: the usual static vs. dynamic, static analysis vs. unit testing
arguments. Guido says that there''s such a small amount of problems that
can be caught at compile time, and even the smallest amount of unit
testing would also catch these problems. "The blindness of that
[static]
position... escapes me."
Three years ago, this was a viable arguement. Two years ago, it was
beginning to show difficulties. Today anyone who makes it can be
accused of having their head in the sand [1].
What''s being ignored is that type information is useful for other things
than compile type checking. The major case in point is the way IDEs
such as IntelliJ and Eclipse use type information to do refactoring, code
completion and eventually numerous other things. A Java programmer
using IntelliJ or Eclipse can eliminate the advantage that Python
used to have, and possibly even pull ahead.
I haven''t used IntelliJ or Eclipse, so I guess I''ll have to take your word
for how wonderful they are.
[snip] I''ll throw out one very simple example in the string library. The
index() and find() methods, and their variants, suffer from a bad case
of non-obviousness inherited from the C library.
It must be an very bad case of non-obviousness indeed, because it isn''t
obvious to me at all what particular bit of non-obviousness it is that
you are referring to.
A very simple
replacement would fix this.
--------------------------------
findall([maxfind,] sub, [start, [end]])
findall returns a list (possibly a tuple) of the beginning index of each
substring which matches sub. If there are no matches, an empty list is
returned. At most maxfind indexes are returned. start and end have the
same meaning as in the existing find and index methods.
Am I the only one who has reservations about having to build a list of all
the matches before doing anything with them?
s = "a" * 10000000 # 10 MB of data to search
L = s.findall("a") # lots of matches means L is very large
or imagine a more complex case where I have to programmatically change my
search string as I go. I might not know how many matches I need until I
have found them and can analyse the text around the match.
Seems to me that rather than having to find all matches regardless of what
you actually want, it would be better to turn find into a generator. Then
findall becomes list(find) and you still have the flexibility of finding
matches one at a time.
This version works intuitively with if statements (an empty list is
false), goes directly into for statements, can be implemented as an
iterator, and is only less efficient by a constant (creation of the
list) if the maxfind parameter is used. It never throws an exception
(unless the parameter list has the wrong types). Its an example of a
method that can be used cleanly with a type inferencer, while the index
and find methods cannot.
Er, how does that last one work? How can findall be used cleanly? Why
can''t find?
--
Steven.
这篇关于关于Guido的ITC音频采访的想法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
