我的一位教授说“语法是一种编程语言的用户界面”,像Ruby这样的语言具有很好的可读性,并且还在不断增长,但是我们看到很多程序员都能用C \ C ++高效工作,因此程序员确实对语法很重要应该可以接受吗?
我很想知道您对此的看法。
免责声明:我不是要吵架。我认为这是一个很好的讨论话题。
更新:原来这是一个很好的话题。我很高兴你们都参与其中。
我的一位教授说“语法是一种编程语言的用户界面”,像Ruby这样的语言具有很好的可读性,并且还在不断增长,但是我们看到很多程序员都能用C \ C ++高效工作,因此程序员确实对语法很重要应该可以接受吗?
我很想知道您对此的看法。
免责声明:我不是要吵架。我认为这是一个很好的讨论话题。
更新:原来这是一个很好的话题。我很高兴你们都参与其中。
Answers:
是的,它确实。如果您有疑问,请使用APL,J或Brainfuck,甚至是简单的Lisp或Forth,然后尝试了解其上所有不完全琐碎的程序。然后与Python比较。
然后将相同的Python(或Ruby,甚至C#)与Cobol或VB6之类的东西进行比较。
我并不是要说多毛的语法是不好的,而类似自然语言的语法在所有情况下都是好的。但是句法过时的语法确实有很大的不同。总而言之,您可以使用最精美的编程语言编写的所有内容,也可以作为图灵机程序编写的所有内容-但是您通常不愿意,是吗?
实际上,我认为这很重要。上面已经讨论了可读性。另一个问题可能是需要表达多少个击键来表达一个想法/算法?另一个问题是,简单的错字很难被人的眼睛捕捉到,它们会造成多大的恶作剧。
我还发现在某些情况下通过另一个计算机程序进行分析和/或生成代码片段非常有用。解析语言和/或生成正确代码的难度直接影响创建/维护此类工具所需的工作量。
我相信您的教授指的是语法糖。
语法糖是计算机科学术语,指的是一种编程语言中的语法,旨在使事物更易于阅读或表达,同时存在表达它们的替代方法。
因此,您的教授所暗示的是,用一种编程语言编写的任何代码/语法都可以用相同或什至相同的语言来表达。
罗伯特·马丁(Robert Martin)从结构化编程定理的基础上,在RailsConf 2010上的主题演讲中抽象了程序员从根本上对编程语言所做的事情:罗伯特·马丁(youTube视频,经过14分钟后,尽管我推荐整件事):
从一种编程语言到另一种编程语言,程序员所要做的只是使用不同的语法或用户界面(UI)。如果他/她正在抽象地谈论编程语言,这就是我想你的教授正在讲的内容。
因此,在本质上,语法并不重要。但是,如果您想具体一点,那么显然某些语言和语法比其他语言更适合于某些任务,因此您可以说语法很重要。
是的,没有。
语法有几个不同方面。
可读性已经被提及。
表达能力是一个有趣的案例。我将以函数传递为例,因为它是语义/句法痛苦的转折点。
让我们以C ++为例。我可以按照这种方式创建一阶函数:
class funcClass
{
int operator()(int);
}
funcClass fun;
void run_func(funcClass fun)
{
fun();
}
这个特定的习语通常在Stepanov的《编程元素》中使用。
在另一方面,我可以像模仿它的Common Lisp 此:
(defun myfunc() )
(defun run_func(fun)
(fun))
或者,在Perl中-
sub myfunc
{
}
sub run_func
{
my $func = shift;
$func->(); #syntax may be a little off.
}
或者,在Python中-
def myfunc():
pass
def run_func(f):
f()
尽管C ++示例带有某种类型的元数据,但它们基本上都具有相同的语义内容。哪种语言最能表达通过高阶函数的想法?Common Lisp几乎没有语法上的变化。C ++要求仅创建一个类以“承载”函数。Perl关于进行某种程度的区分非常简单。Python也是如此。
哪种方法最适合问题领域?哪种方法最能以“阻抗不匹配”最少的方式表达您的想法?
在我看来,可解析性非常重要。特别是,我指的是IDE能够解析和砍切语言而不会出错的功能。重新格式化很有用。令牌分隔的语言往往能很好地解析-ruby / c / pascal等。
请考虑一下-已经用每种严肃的语言创建了各种主要系统来解决现实世界中的问题。尽管语法是表达某些内容的障碍,但它是可解决的障碍。图灵等价物。
语法绝对很重要,尽管在不直观的情况下您会经常注意到它,并且会引发错误。例如,臭名昭著的“世界上的最后一个错误”笑话:
if (AlertCode = RED)
{LaunchNukes();}
if(RED = AlertCode)
永远不要编译,因为RED是恒定的(或者应该是!)
LaunchNukes
过程的引用,而从不调用它。避免危机!
RED
。如果为0,则LaunchNukes()
永远不会调用。
语法确实很重要,我可以举两个支持的例子:Dylan,它是具有更常规语法的Lisp,Liskell,是具有类似Lisp语法的Haskell。在每种情况下,都提出了一种语言的变体,该变体具有完全相同的语义,但语法却截然不同。
在Dylan的情况下,人们认为放弃s表达式而转向更传统的东西将有助于吸引更多的程序员。事实证明,语法并不是阻止程序员使用Lisp的唯一方法。
在Liskell的情况下,人们认为使用s表达式将允许更轻松地使用宏。事实证明,在Haskell中确实不需要宏,因此该实验也不起作用。
事情是这样的:如果语法对任何人都不重要,那么就不会尝试任何实验。
我认为真正重要的是API访问以及在需要时提供低级功能(例如内存控制和锁定)。大多数其他语言都包含这些功能。问题是,当您需要其他功能时,通常必须使用C之类的语言来实现它。而且,将C与您使用的语言连接起来很麻烦。
对于除 Web开发(和数学)以外的所有内容,我发现C / C ++仍然是操作系统和应用程序的语言。大多数时候,真正的多线程,预执行,跨平台应用程序开发都支持此功能。C的语法还可以。只是非常简单且相对冗长。惊人的语法并不重要。强大的功能和API的可用性确实我们都需要与其他人的代码对接(大多数时间是用C或其派生语言编写的)。
语法绝对重要。如果语言语法足够灵活以允许您为您的应用程序创建方便且可读的特定于域的语言,那将对我们非常有用。如果您对此表示怀疑,请想象一下像18世纪之前那样在平淡的拉丁语中进行代数运算,或者想象没有现在熟悉的莱布尼兹(Leibniz)表示法进行微积分。当然,微积分的文本对于新手来说是不可读的,但是通过实践,我们可以使用微积分和Leibniz表示法快速解决一类问题,这些问题需要使用经典方法进行数学计算。编程只是数学的又一小部分。靠近问题域的方便注释可以在生产率上产生巨大差异。
这是一个计算6的能力的程序:
S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
语法是最小的:
expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I'
似乎普遍认为语法是使语言变得困难的原因。正如通常所持的信念那样,事实恰恰相反。
请注意,LISP语法仅可读(如果有的话),因为它的语法比上述语法多得多。因此,如果LISP粉丝告诉您“语法无关紧要”,请要求他们这样做,然后尝试SKI演算。他们将不得不承认一点点语法毕竟还算不错。
是的,语法很重要,尽管实际上只是为了提高可读性。相比:
for i in range(10):
print(i)
(是的,是Python)
FOR(i<-RNG-<10){PRN<-i}
(是的,这是我刚刚编写的一种语言)两者将以相同的方式做完全相同的事情,但是语法不同,并且Python更易于阅读。是的,语法绝对重要。甚至“语法糖”也很重要。
@property
def year(self):
return self._date.year
比起阅读更容易
def year(self):
return self._date.year
year = property(year)
还要考虑的另一件事是,具有更好语法的编程语言更易于解析,从而使编译器更易于编写,更快且更不容易出现错误。
parse.y
Ruby中的10000 SLOC 意见不一。还有就是为什么有原因的每一个的7电流或淳生产就绪的Ruby实现的采用了相同的解析器,并且每一个是曾经尝试开发自己的Ruby实现自己的解析器失败。
简单地说:这样的语法并不重要。您可以通过它表达的语义很重要。