探索声明式编程语言的技巧？
问题
如前所述，您有什么技巧可以帮助您理解/理解/熟悉声明式编程语言吗？
或者这只是一种情况，您必须让自己沉浸在该语言及其语法中，直到它渗透进来，直到您获得得到它的黄金时刻。 这并不是一个真正的选择，因为我不能再连续几天把自己锁在房间里，研读六本关于该主题的不同书籍（责任是什么以及全部）
所以，任何有帮助的提示或技巧当你处理声明性语言时，有什么见解可以分享吗？
PS：我个人会赞成第一个答案“闭嘴，投入工作”。
背景
我13岁时第一次开始编写代码（基本，关于我的姐妹Oric-1）。
从那时起，我接触了许多新概念和许多不同的语言，一切都在我的步伐中，我很快就占据了上风。 面向对象？ 不麻烦。 事件驱动范例？ 给我抽根熏鱼吧，我会回来吃早餐的。
猫头鹰、Mfc、ActiveX、Vb3、4、5 和 6、VB.Net、Pascal、Delphi、C、C++ & C＃。 没有人阻碍我，至少不会持续太久。
然而最近我的满分受到了一些打击。
几周前，我全身心投入到 Xaml 中，伙计们，我比游泳更沉下去。
我认为我的主要问题是它是声明性的。 我所有其他编程技能都是程序性的。 我之前在使用 MSBuild 时遇到过这个问题，我可以复制如何让 MSBuild 工作的示例，但从头开始将一些东西组合在一起会丢失。
回到 Xaml，目前我正在疯狂地尝试将触发器连接到属性并获得我需要的效果。
我可能很快就会在这里发布我的具体 Xaml 问题。 现在我正在问这个一般性的“声明式编程”问题。
PS 不，我其实没那么自大。 是的，当我第一次接触 OO 和第一次编写事件驱动的 UI（Windows 3.11 上的 VB3）时，我跌跌撞撞。
编辑
它开始深入人心，让我在这个领域走到这一步的毅力正在得到回报，它只是需要这么多的水力压裂时间！
。 。 。 我想我已经太老了，不适合做这些事了。 。 。 :)
Question
As stated, have you any tips to help grok / understand / get-your-head-around declarative programming languages?
Or is it simply a case that you’ve to immerse yourself in the language and it’s syntax, until it seeps in, until you get that golden moment where you Get It. This isn’t really an option as I can no longer lock myself in a room for days on end, poring over half a dozen different books on the subject matter (responsibilities being what they are and all)
So, any tips or tricks that helped you when you tackled declarative languages, any insights to pass on?
P.S. I’ll personally upvote the first answer that says “Shutup and put in the work”.
Background
I was 13 years old I when I first started wring code (basic, on my sisters Oric-1).
Since then I’ve worked with many new concepts and many different languages, taking all in my stride, me taking the upper hand quickly enough. Object Orientation? Not a bother. Event driven paradigms? Smoke me a kipper, I’ll be back for breakfast.
Owl, Mfc, ActiveX, Vb3, 4, 5 & 6, VB.Net, Pascal, Delphi, C, C++ & C#. None have stood in my way, at least not for very long.
However recently my perfect score has taken a bit of a battering.
A couple of weeks ago I threw myself into Xaml, and folks, I’m more sinking than swimming.
I think my main problem is that it’s declarative. All my other programming skills are procedural. I’ve hit this block before with MSBuild, I can copy examples of how to get MSBuild things working, but would be lost putting something together from scratch.
Back to Xaml, currently I’m going insane trying to wire triggers to properties and get the effect’s I need.
I may post my specific Xaml question here soon enough. For now I’m asking this general “declarative programming” question.
P.S. No, I'm not actually this cocky. Yes, I stumbled like hell the first time I hit OO and the first time I'd to write an event driven UI (VB3 on Windows 3.11).
Edit
It's starting to sink in, the tenacity that got me this far in this field is paying off, it just takes so much fracking time!
. . . I think I'm getting too old for this stuff . . . :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
在本世纪初，我不得不教一些 XSL（或 XSLT，如您所愿）:)，这确实是一个不同的世界。 然而，这是范式转变的基础：你必须意识到声明性语言确实是不同的。 我最重要的建议是继续研究其他人的解决方案，投入工作，并真正尝试停止在 FLOW 中思考。 最糟糕的是，在 XSL 中，有一个“if”和一个“else”，但通常还有另一种方法来做事情。
与学习 OO 不同，在 XSL（或者我想是任何声明性语言）中，除非以声明方式进行，否则您将无法完成您想要做的事情。
所以答案部分是，正如你所建议的，“闭嘴，做工作”，但更重要的一点是要意识到，很多工作都是让你的头脑围绕范式转变。 所以真正的答案是，“密切关注范式转变。”你必须停止在流程中思考，并开始根据可以以任何顺序触发的规则进行思考......如果它们'如果做得对，他们什么时候开火并不重要。 当你最终用规则来思考而不是当事情发生时，你就开始理解这种转变了。
I had to teach XSL (or XSLT, as you wish) a bunch at the beginning of the century :), and it's a different world, really. That, however, is the basis for the paradigm-shift: you have to realize that declarative languages really are different. The most important advice I have is to keep studying other people's solutions, put the work in, and really try to stop thinking in FLOW. The worst thing is that, in XSL, there is an "if" and an "else," but usually there's another way to do things.
Unlike learning OO, in XSL (or any declarative language, I suppose) you will not manage to do what you're trying to do unless you do it declaratively.
So the answer is in part, "shut up and do the work" as you suggest, but the more important point is to realize that a lot of the work is getting your head around the paradigm shift. So the real answer is, "keep your eyes peeled for the paradigm shift." You have to stop thinking in flow and start thinking in terms of rules that can fire in any order... if they're done right, it doesn't matter when they fire. When you are finally thinking in rules instead of WHEN stuff happens, you're beginning to grok the shift.
从真正了解该语言的人那里找到一些示例，并解释“为什么”。 学习模式和习语会产生影响。
我怀疑您正在尝试在声明性领域中做必要的事情，这意味着您按照步骤进行思考。 根据所需输入+这些输入的无状态函数写下数据流，看看是否有帮助。
尝试使用函数式或函数式语言，例如 ML 或 Scheme。
Find some examples, with explanations of the "why", from someone who really knows the language. It's learning the patterns and idioms that makes a difference.
I suspect you're trying to do imperative things in declarative land, which means you think in terms of steps. Write the dataflow down in terms of required inputs + stateless function of those inputs and see if that helps.
Try a functional or functionalesqe language like ML or Scheme.
我不知道您对 Xaml 的具体问题是什么（我自己也没有使用过），但我发现，当使用基于 XML 的技术（如 XSLT）时，一点 LISP 或 Scheme 经验可以大有帮助。 您可能想尝试使用 http://www.plt-scheme.org 免费提供的优秀方案系统。
I don't know what your specific problems with Xaml are (and I haven't used it myself) , but I've found that when using XML based technologies like XSLT, a little LISP or Scheme experience can go a long way. You might want to look at playing with the excellent scheme system available free from http://www.plt-scheme.org.
我知道这可能会让你大吃一惊。 您列出的所有这些语言确实非常相似（程序）。
一旦你明白了这一点，我强烈鼓励你学习函数式语言 也是如此。 您可能还会发现这很困难，但是学习它将对您的一般编码技能有很大帮助。 您将拥有一整套新的技巧（即使是过程语言），并且您将永远不会再害怕递归。
I can see where this may be blowing your mind. All those languages you list are indeed quite similar (procedural).
Once you get this down, I highly encourage you to learn a functional language as well. You may also find it tough going, but learning it will help your general coding skills greatly. You'll have a whole new bag of tricks (even in procedural languages), and you will never be afraid of recursion again.
考虑一下您最喜欢的“程序员无知”的烦恼。 第一个代码片段显然是程序性的。 在第二个片段中，您做出声明性声明，为了使百分比有效，它必须在 0 到 100 之间。
因此，我猜您只要满足以下条件，就可以轻松掌握声明性编程语言：你已经足够努力了... 通向几何没有捷径
Consider your favorite “programmer ignorance” pet peeve. The first code snippet is obviously procedural. In the second snippet you make a declarative statement that for the percentage to be valid it has to be between 0 and 100.
So i'd guess you'll have no trouble grokking declarative programming languages as long as you work on it hard enough... there is no royal road to geometry
与 Binary Worrier 一样，我在 C、C++、MFC 等方面有着悠久的历史，并且一直在了解 XAML、WPF 和 C#。 我顺便学习了 HTML、Javascript 和 XSLT，我认为这对我准备 XAML 有很大帮助。
XAML 背后的基本思想相当简单 - 一切都与您显示的内容有关，而不是您执行的内容。 XAML 的难点在于，需要学习大量的实现细节，并且您最终会同时学习所有这些细节，以便能够完成大部分工作。
如果问题更具体，我可能会更有帮助。
Like Binary Worrier, I had a long history with things like C, C++, MFC, etc and have been coming up to speed on XAML, WPF, and C#. I had a side trip through HTML, Javascript, and XSLT which I think helped a great deal in preparing me for XAML.
The basic idea behind XAML is fairly straightforward - it's all about what you show, not what you do. The hard part with XAML is that there is just a ton of implementation details to learn and you wind up learning them all at the same time in order to be able to get much of anything done.
I could probably be more helpful if the question was more specific.
大多数程序员对这句话反应平静。 这几乎就像……“呃？”
但对这种说法的信念导致人们难以理解其他编程范例。 这不是，而且已经很长时间没有这样了。 为了更好地理解编程，许多人可能会通过思考为什么这个说法是错误的而受益。
即使您使用纯汇编进行编程，现代处理器也会重新排列指令，执行分支预测，并尝试同时执行多个可能相互依赖的指令。 通过这种方式，他们根据逻辑依赖关系而不是顺序来思考。 序列隐喻是一个错误的概念，即一条指令在逻辑上取决于它之前的所有内容。 如果这是真的，那么推理程序的最佳方法就是检查控制流。 但事实并非如此。
不仅声明式编程不符合这个比喻，并行和异步编程也是如此。
Most programmers react with equanimity to this statement. It's almost like... "duh?"
But the belief in this statement is what causes people to have trouble understanding other programming paradigms. It's not true, and hasn't been for a very long time. To arrive at a better understanding of programming, many may benefit from thinking on why this statement is false.
Even if you programmed in pure assembly, modern processors would rearrange your instructions, perform branch prediction, and attempt to execute multiple potentially codependent instructions at the same time. In this way they think in terms of logical dependencies, not sequences. The sequence metaphor is the false notion that an instruction logically depends on everything that preceded it. If this were true, the best way to reason about programs would be to examine the control flow. But it is not true.
It's not just declarative programming that doesn't fit with this metaphor, but also parallel and asynchronous programming.
我发现“理解”一门语言的最简单方法就是开始将它专门用于您的所有编码。 对于一门全新的语言，我想说，对我来说，学习曲线大约是 2 周的编码时间，每天大约 4-5 小时。 在那之后，它突然“咔哒”一声，您可以开始减少对手册和文档的依赖。
I find the easiest way to "grok" a language is simply to start using it exclusively for all your coding. With a completely new language I would say for me the learning curve is approximately 2 weeks of coding about 4-5 hours a day. After that point it suddenly "clicks" and you can start relying less on manuals and docs.
我在大学上了一门课（编程语言）。 感觉就像我不断地将头撞到砖墙上，但课程进行到大约 3/4 时，我意识到墙已经不存在了；墙已经不存在了。 几个星期以来，我一直在为任何事情而绞尽脑汁。 这是一种非常超现实的感觉。
我想任何其他方式都不会有同样的魅力。 读哥德尔、埃舍尔、巴赫； 听很多艾默生、莱克、帕尔默和凯霍斯鲁·索拉布吉的作品； 抽点大麻，然后投入时间。
I took a class in college (Programming Languages). It pretty much felt like I was repeatedly slamming my head against a brick wall, but about 3/4 of the way through the class, I realized the wall wasn't there anymore; I had been beating my head against nothing for a few weeks. It was a pretty surreal feeling.
I think any other way won't have the same charm. Read Godel, Escher, Bach; listen to a lot of Emerson, Lake, and Palmer and Kaikhosru Sorabji; smoke some ganja, and put in the time.