快捷编程语言我错过了什么吗？
我看到越来越多的在线项目需要额外的“短”语法来生成底层代码（通常是 HTML 和 JS），每次我看到另一个弹出窗口时，我都想知道我是否遗漏了一些东西。
当在不同的团队成员（设计师等）之间传递项目时，他们必须重新学习 HTML 和 JS 等基本语言，那么学习和记住这些短代码所花费的额外时间肯定会浪费吗？
问题点：YAML 用于生成模板和项目（例如）CoffeeScript 用于生成 Javascript。我只是想知道其他 Stackoverflow 人员是否认为这种精细的抽象级别有重大好处，或者考虑到基础技术的改进（我认为 HTML5 / CSS），这些类型的项目是否有生命周期/JQuery）在这里。标记语言的发展还不足以真正保证这些吗？
意识到这本身并不是一个真正的问题，但有兴趣听到社区的观点。我确信在创建自生成代码时，这些类型的项目确实有充分的理由，但除此之外，我很困惑 - 许多人每天都在使用它们。这股潮流值得追随吗？
I'm seeing a rise in the number of projects online that require additional "short" syntax to generate underlying code (commonly HTML and JS), and every time I see another pop up I wonder if I'm missing something.
Surely the additional time taken to learn and remember these shortcodes is lost when passing projects between different team members (designers et al) who then have to relearn basic languages such as HTML and JS?
Point in question: YAML being used for generating templates, and projects (such as) CoffeeScript used to generate Javascript. I'm just wondering if other Stackoverflow folk think that there's major benefits to this granular level of abstraction, or if there's a feeling that these types of projects have any lifespan, considering the improvements in the base technologies (I'm thinking HTML5 / CSS / JQuery) here. Have markup languages not evolved enough to really warrant these?
Realise this isn't really a question as such, but would be interested to hear the community viewpoint. I'm sure there are genuinely good reasons for these types of projects when creating self generating code, but outside of that, I'm puzzled - with many folks using them day to day. Is this a bandwagon worth jumping on?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
就我个人而言，我认为这不值得，因为您可以在 javascript 中执行的大多数操作已经被 jQuery 等库简化了。至于它们的寿命，很难说。但是，只要您了解 javascript，并且了解代码输出，那么转移到不使用 CoffeeScript 的新项目就很简单，只需随身携带输出代码即可。
Personally I don't think that it's worth it as most things you can do in javascript are already simplified by libraries such as jQuery. As far as their lifespan goes it's hard to tell. However, as long as you know javascript, and you understand the code output, moving to a new project that isn't using CoffeeScript for example is a simple matter of taking the output code with you.
任何足够复杂的程序都包含 Lisp 的实现。
这是 Lisp 和朋友们多年来宣扬的理念。基本上，不鼓励您使用“原始”语言编写任何应用程序逻辑。原始语言是通用的、低级的，因此您的逻辑很快就会变得冗长，并被支持语言本身所需的大量代码所污染。
相反，创建一个最适合您的应用程序的 DSL 并编写您的逻辑，仅此而已DSL 中的逻辑。将所有讨厌的语言细节隐藏在 DSL 后面。这使得逻辑更容易改进和支持。
另一方面，在我看来，Coffescript、Groovy 等都是错误的选择。他们基本上是在尝试创建新的通用语言，但具有“更好”的语法，但这并不能解决根本问题 - 这些语言仍然描述抽象计算而不是您的问题域。一种更高效的方法是拥有一种非常基本的底层语言和一个完善的宏工具，可以简化 DLS 的创建。这就是 Lisp 本身的工作原理，这种方法的另一个例子是 Haxe/Neko。
Any sufficiently complicated program contains an implementation of Lisp.
This is the ideology that Lisp and friends promote over many years. Basically, you're discouraged to code any application logic in a "raw" language. Raw languages are universal and low level, so your logic quickly gets verbose and contaminated with lots of code needed to support the language itself.
Instead, create a DSL that suits your application best and code your logic, and nothing but the logic, in this DSL. Hide all nasty language details behind the DSL. This makes the logic much easier to improve and support.
On the other side, things like Coffescript, Groovy etc are IMO the wrong way to go. They are basically trying to create new universal languages but with a "better" syntax, however, this doesn't solve the fundamental problem - these languages still describe abstract calculations rather than your problem domain. A more productive way is to have a very basic underlying language and a well-developed macro facility that would simplify creating DLSs. This is how lisp itself works, another example of this approach is Haxe/Neko.
在我看来，我更喜欢 jQuery，因为它可以编写简短的 JS 指令，并防止每个人都夸大最终产品。我不喜欢 CSS 框架，因为我们正在构建巨大的门户，而您并不总是需要隐藏在其中的所有内容。我更喜欢根据一些常见规则编写模块化 CSS，例如使用clearfix 进行清除和使用 css 重置。 :)
In my opinion I prefer jQuery for writing short JS instructions and prevent everyone from bloating the final product. I don't like css frameworks because we are building huge portals and you don't always need all of the stuff hidden inside these. I prefer writing modular css based on some common rules like using clearfix for clearing an using a css reset. :)