嘿所有，这更像是一个哲学问题。我已经写了我的第一个网络应用程序，一个波士顿活动日历在http://bloozit.com我用Python编写它，我很高兴它的简单性，但是，我的Python包含大量的HTML，CSS和Javascript，就像炖鱼头和浮在其中的眼球一样。
然后我在使用Lisp的Web应用程序上看到了这个教程：http://www.adampetersen.se/articles/lispweb.htm我读过Lisp并在Lisp中编写了一些软件，所以我不是Paul Graham，但我对它很熟悉。对我来说非常吸引人的一件事是作者如何从Lisp生成HTML和Javascript，使整个事情变得美观和同质。
问题是，现实世界中的同质性有多大价值？每当出现任何问题时，您必须在Firebug中加载页面，然后您将查看生成的HTML，CSS和Javascript，而不是Lisp源，因此您必须将映射保存在脑中。 Lisp提供的同质性是否真的可以解决任何问题，或者只是解决问题的壁纸，最终会再次出现在下游？
如果有人在那里实际尝试了这两种方法，我真的喜欢听到你的消息！
答案 0 :(得分：5)
好吧，我花了一年时间用parenscript和ht-ajax进行编码，最终放弃了，只是手动生成了javascript（仍在服务器上使用hunchentoot）。我发现结果更具可预测性，正如你在问题中暗示的那样，这使得在使用firebug时弄清楚发生了什么变得容易得多。 （我也转而使用jquery，这比ht-ajax要好得多，但这并不是你所要求的。）
那就是说，我大量推荐cl-who（http://weitz.de/cl-who/），它使HTML的动态生成更加整洁。
答案 1 :(得分：4)
问题是，现实世界中的同质性有多大价值？
可能相当重要：看看现在所有做服务器端Javascript的人。 Javascript在任何方面都不是最高级的，它对服务器端代码的库支持并不是那么好，但使用它有很大的收获。
每当出现任何问题时，您必须在Firebug中加载页面，
取决于“任何事物”是什么。我实际上不记得上次我打开Firebug以查看出现了什么问题 - 我当然已经完成了相关的阶段，但也有很多时候它不是。
例如，如果你从s-exps生成你的CSS，那么你的CSS问题可能只会让你需要查看“编译好的”CSS以寻找奇怪的语法问题（比如IE6技巧）。如果您只是查看页面并确定需要额外的边框，那么您可以添加(:border 1)并完成它。 （当然，如果你处理它来生成一整套CSS规则来为客户服务，那么它就是一个更大的胜利。）
另一种思考方式：在极少数情况下，我需要在使用现代网络应用程序时拔出数据包嗅探器和反汇编程序。是的，它很糟糕，但有了很好的图书馆，它也是非常罕见的。我不想整天编写低级代码，只是为了避免在我需要这种级别的信息的情况下切换到数据包嗅探器的阻抗不匹配。
这假定您希望并且可以达到您正在编写（V）HLL代码的级别。 Common Lisp在C语言中无法击败C，如果你只是想用HTML编写一个简单的博客，那么你就不会在那里找到最佳点：Rails已经非常擅长这种事情了。但是有大量的实验性编程，能够更改一个标志并在客户端而不是服务器上运行代码是有用的。
然后你会看到生成的HTML，CSS和Javascript，而不是Lisp源代码，因此你必须掌握映射。 Lisp提供的同质性是否真的可以解决任何问题，或者只是解决问题的壁纸，最终会再次出现在下游？
我已经编写了所有Lisp和所有Javascript网络应用程序，我认为我现在能给出的最好答案是：可以。我使用了Parenscript，主要的问题是Parenscript是一种Lisp-y语言，但它不是Common Lisp，也不是你可以在服务器端使用的任何其他完整语言。 （如果有一个Common Lisp到Javascript编译器，就像GWT用于Java，那就太棒了。不过，我没有看到有人认真地试图制作一个。）所以你仍然可以看到，两种语言。
在这方面，Javascript今天好一点，因为你可以在两个地方运行完全相同的代码。它不是相当理想，因为您的服务器端Javascript可能具有您无法保证将在客户端存在的功能（除非您将用户限制为，例如，最新版本的Firefox）。如果您像我一样，您不希望将服务器代码限制为恰好在每个浏览器中运行的JS，因此您的服务器端JS和客户端JS将是微妙的不同。这不是一个破坏者 - 它仍然相当不错 - 但它仍然是两种略有不同的语言。
我认为如果有一个程序可以使用最新的Javascript（1.8.5）编写的代码，并生成在任何浏览器中运行的旧式Javascript，那将是非常酷的。我不认为这样的程序存在，但我不知道它有多难。
有Javascript的Scheme实现，因此使用Scheme的情况可能更好。我应该调查一下这几天。
当我不得不使用与我的客户端语言（Javascript）完全不同的服务器端语言时，我常常感到沮丧。但是当我不得不使用比Lisp更低级的语言时（我们大多数都是这样），我也很沮丧。更像是Lisp，或者更像Javascript，这是一个更大的胜利吗？我不知道。我希望我没有必要选择。
答案 2 :(得分：1)
如果你正在做类似parenscript的事情，那么Javascript实际上与css和html分开。听起来好像做得很好。但是，我没有经历过这样的例子。我没有尝试过parenscript，但鲁珀特的回答并没有说得好。我个人使用coffescript，而不是将现有语言映射到javascript构建一个更好的语言。你知道它会产生什么，因为它非常干净地映射到javascript，这使得调试变得容易。
如果您只想将应用程序中的值插入到javascript中，那么原则与为html和css执行操作类似。下面我将谈谈我作为Ruby Web开发人员的经验以及haskell Web框架Yesod的贡献者 - 但我认为它可以概括为任何语言的Web开发。
将html模板视为用于生成html的DSL。在标签名称（或其他语言/系统制作标签名称函数调用）之前放置一堆冒号真的是对DSL的改进吗？显然，它是一种可以轻松操作模板的语言，而不是让模板语言更好。
lisp代码不需要关闭标记，但模板没有理由。 HAML是一种非常强大的DRY模板语言，最初用ruby编写，其概念现已移植到其他语言中，还有其他模板语言具有不同的语法，可以维护基于空白的布局而不是写入的重要概念结束标签。我对HAML的问题在于它完全放弃了html语法。我觉得它是HAML而不是代码中的鞋子。在Yesod Web框架中，我们采用了HAML概念，但使用了正常的html语法DRY-我们称之为hamlet。
在代码中生成所有 html的原因之一是因为将模板片段的直接粘贴到代码中可能很麻烦 - 我们已经很好地解决了这个问题在哈姆雷特中使用haskell的quasiquotes-在其他语言中你可能需要一个函数调用和一个多行字符串，根据多行字符串语法，这在不同程度上更麻烦。
这些概念与css同样适用。 HAML用户使用SASS或SCSS（我们现在也基本上移植到Yesod）。 Here are python equivalents
因此，模板代表了一种免费的语法，即代码无法匹配的html。 如果模板允许您调用生成html的辅助函数，那么您没有失去太多的力量。
从代码生成html，css和js的一个方面是将它们组合在一起并与应用程序逻辑交互的简单方法。例如，如果您想要一个使用javascript日历弹出窗口的日期字段，则需要一些html，css和js一起工作 - 并且您希望它们位于源中彼此相邻的位置，但是在html页面中彼此远离，或者在客户端接收时在单独的文件中。在Yesod中，我们有widgets来完成代码或3个单独文件。在HAML中，可以将同一模板的部分声明为html，javascript或css，但如果您想以更智能的方式组合它们，则需要您自己的框架或应用程序中的帮助程序。
答案 3 :(得分：1)
这不是一个强烈的意见的答案，但根本问题是HTML和CSS是可怕的（1）。也没有做到它应该做的事情。 Javascript更好，经常被用于服务以弥补这两者的缺点（2），但它不是一个理想的解决方案（3）。结果，需要服务器端语言来生成HTML和CSS，这进一步使混乱变得复杂。最简单的Web应用程序需要编程不少于四种不同的语言，这是可笑的。
所以，是的，您希望拥有一种可靠的语言而不是其他语言，这是可以理解的，但只要您编写生成HTML / CSS的代码，您就必须关注细节HTML和CSS，然后你只是戴着连指手套，当你去弹钢琴时可能会（读“可能”）干扰。如果你的Lisp代码看起来像这样：（：body（：div（：@（：style（：border“1”）））（：p“hello”））），那么你并没有真正解决问题困扰你的人
就我个人而言，我认为我们需要别的东西代替我们现在所拥有的汤，并且它应该编译到HTML / CSS / JS，但让用户免于他们的顾虑。 C编译为汇编但C程序员从未在其自己的编写代码中看到它编译的STA，MOV，LDX操作码。而且，如果它受欢迎，那么浏览器可以直接支持它。无论如何，这只是一个想法。微光。
祝你好运，
Chris Perkins
medialab.com
（1）HTML文档是包含图像，脚本，样式表等的复合文档，都存储在其他文件中。但HTML文档无法做到的一件事是流畅地嵌入另一个HTML文档 - 这是它最需要的一件事。 iframes / object标签是固定大小，都会对SEO产生负面影响。这个简单的任务通常是在许多网站上使用像PHP这样的服务器端语言的唯一原因。
你不需要我告诉你CSS有多糟糕。
（2）示例比比皆是：LESS（lesscss.org），document.write，AJAX等。
（3）Javascript DOM和CSS规则之间的阻抗不匹配几乎令人难以置信。 div中有多少高度（scrollHeight，offsetHeight，clientHeight等）？可能是4个或更多？有多少可以通过CSS寻址？ 0或1。 此外，虽然Javascript可以插入很多漏洞，但它通常是以牺牲SEO为代价的。