从Perl切换到Python的演示
短篇故事:
我正在寻找有关从Perl切换到Python的演示文稿/好的文章。
更长的故事:
我是硬件设计小组的程序员/嵌入式硬件工程师。几年前,我说服我的同事使用Perl编写脚本(而不是将批处理文件,Excel,Matlab和TCL混合在一起)。从那时起,我本人已从Perl切换到Python,并对这一变化感到非常高兴。我想以某种方式说服我的同事们遵循我的道路,但是我需要一些好点来说服他们。这些不能像繁重的程序员伏都教那样具有更好的反射功能(与我自己不同,这里的大多数人是EE毕业生,而不是程序员)。
有任何想法吗 ?关于该主题的好文章/演示文稿?也许有人已经做到了,可以分享一些技巧。
笔记:
该主题在同一主题上,但不太符合我的要求。
解决方案
我们是出于什么原因而偏爱Python而不是Perl?是什么让我们如此快乐?同事对Perl感到不满意吗?如果是这样,那么Perl是什么让他们感到困难,并且在Python中可能会更好?
说服他们的唯一方法就是向他们展示可能的利益。恕我直言,这些往往是非常主观和个人的。
如果我们不能改变非技术经理对如何从一种语言更改为另一种语言的想法,那么我们就没有资格提出更改建议或者领导更改。
我们必须有充分的理由说明为什么它比已经存在的更好,并且"我更喜欢该语法"或者" Google使用它"在财务上甚至从技术上都是无效的原因。
这是一个巨大的转换,我们需要自己想知道为什么这样做是有意义的。
如何说服人们Python比Perl更好?
在Python中比在Perl中更成功。
当他们问我们为什么如此成功时,请警告他们,他们必须跳出框框思考。在揭示我们成功的秘诀之前,请确保他们确实想要改进。 [有些人不想改善,他们想发牢骚;尝试不要启用它们。]
除非我们获得更大的成功,否则我们什么都没有显示。 "说服他们的好点"是我们个人的成功故事。
启动" Python的救援"时刻的私人列表。在实际组织中获得实际胜利的每个Python都是无可争议的。
每天,我们都希望寻找一个整洁,可写博客的成功案例。
询问同事他们是否仍然可以阅读几个月前写的Perl脚本,或者他们是否可以阅读和理解彼此的脚本。 Python的关键一件事是可读性强。还向他们展示如何使用Python在Perl中完成所有的好工作。向他们展示Python文档。向他们展示与Perl相比,Python OO如何更好地集成到该语言中。
如果我们向经理提出建议,请提及有关如何更轻松地维护的部分。他可能会要求所有人立即切换。
当两种语言具有相似的功能时,将大量代码从一种相似的语言重写为另一种语言没有任何好处。也许我们应该专注于编写更好的Perl代码。也许学会使用技巧,或者购买Perl Best Practices和Perl Medic的副本,然后将其分发给同事。而且,如果我们担心Perl不能像Python那样完全不是面向对象的,请使用Moose(而且我认为,与Perl相比,Python在功能编程部门中缺乏)。
在回应下面的评论时,我还要说的是,没有必要强迫同事学习和掌握一种与我们正在使用的语言具有相似功能的语言。
现在,如果有一些公司需要的库,或者公司需要的库在Perl中不可用(或者质量要差得多),那么在Python中可用,然后继续进行切换或者添加其他语言。
我认为我们需要的第一个答案是"为什么要让他们切换到Python?"的答案,这是只有我们才能提供的答案。
从帖子的总体语气来看,我倾向于怀疑它可能主要是"哦!我发现了这种很酷的新语言,并想与所有人分享它的酷劲!"或者,或者,"最后,我可以用它来摆脱Perl的束缚..."如果是这样,那么我们为什么还要关心其他人的个人偏好是否与个人偏好相同?如果仅仅是"我们都触摸彼此的代码",那么为什么个人喜好超过其他所有人的呢?
如果OTOH,我们认为通过切换有实际的技术原因和明显的好处,那么我们需要以具体的方式确定这些好处(实际的Python代码演示它们是这样做的一种方法,但不是唯一的方法)并将其呈现给同事,看看我们是否可以说服他们,这将是一个不错的选择。
请小心,以免最终导致"混合批处理文件,Excel,Matlab和TCL的怪异混合"过渡到Perl,Python和其他任何引起关注的混合语言。
埃里克·雷蒙德(Eric S. Raymond)撰写了一篇有趣的文章/文章,介绍了他在Python方面的经验,这是非常有利的。
在编写工作代码时:
When you're writing working code nearly as fast as you can type and your misstep rate is near zero, it generally means you've achieved mastery of the language. But that didn't make sense, because it was still day one and I was regularly pausing to look up new language and library features! This was my first clue that, in Python, I was actually dealing with an exceptionally good design. Most languages have so much friction and awkwardness built into their design that you learn most of their feature set long before your misstep rate drops anywhere near zero. Python was the first general-purpose language I'd ever used that reversed this process.
关于元类黑客:
To say I was astonished would have been positively wallowing in understatement. It's remarkable enough when implementations of simple techniques work exactly as expected the first time; but my first metaclass hack in a new language, six days from a cold standing start? Even if we stipulate that I am a fairly talented hacker, this is an amazing testament to Python's clarity and elegance of design. There was simply no way I could have pulled off a coup like this in Perl, even with my vastly greater experience level in that language. It was at this point I realized I was probably leaving Perl behind.
对于听说过Raymond的任何人以及编写Python的任何人来说,绝对值得一读。他具有丰富的Perl经验(以及一般的大量编码经验),因此他对Python的热烈回顾对其背后具有一定的影响。
对不起。我只是冒犯了我们将Perl当作基本的东西对待。和Python一样,是进化的下一步。现在,我可以将其放在胸前了。
评估两者的特征(和局限性)差异。
Perl具有常量,多行匿名函数和自动生存功能,但是python具有更好的默认对象方向。
评估更换团队/朋友的成本/收益。使用不同语言的专业化对团队可能是一件好事,或者可能浪费资源。
消除Perl和Python背后的神话。
当然,请享受我们使用的任何语言。