未加星标

Why I Don't Like PowerShell DSLs (and Neither Should You)

字体大小 | |
[系统(windows) 所属分类 系统(windows) | 发布者 店小二04 | 时间 2017 | 作者 红领巾 ] 0人收藏点击收藏

Why I Don't Like PowerShell DSLs (and Neither Should You)

DSLs seem to be all the rage right now in the PowerShell world. Pester has quickly become a staple in many PowerShell developer’s toolbelts and there seem to be new DSLs cropping up on a regular basis. Simplex, Pscribo, and even DSC are all examples of DSLs written in or for use in PowerShell. I’m not a big fan of DSLs and I’ll explain why.

DSL stands for Domain Specific Language, and it means a programming language designed to tackle a very “specific” problem domain. Most of the common programming languages like C#, Java, and even PowerShell are general purpose and can be used to approach a very wide variety of uses and applications. In contrast, a DSL has a narrow scope of focus. A common reason for using DSLs is that they can use more natural language that is closer to the idiom of the problem domain itself. Pester, for instance, expresses test conditions using natural language elements like “It” and “Should” to imitate the way that we think about units of code.

PowerShell DSLs come in two flavors these days - function-based and keyword-based. Function based DSLs have been around for quite some time in PowerShell, and this is how Pester is implemented. This approach typically involves using (and abusing!) standard advanced functions and positional parameters with natural language names. A basic Pester test really boils down to a function called It with a string parameter -name and a -scriptblock parameter that performs the test. Inside that scriptblock, the output of any command can be piped to a function Should which has some very special magic that performs tests on your code. Keyword-based DSLs are created using the DynamicKeyword .NET class and are relatively new, having been introduced in PowerShell v4.0. The declarative language powering Desired State Configuration was created using keywords.

PowerShell, however, revels in being general purpose. Its’ primary strenth is consistency of behavior across different managed technologies. I’m not the only one who thinks this way, evidenced by Don Jones’ article explaining the benefits of using PowerShell for systems administration. In the old days of windows we had many different automation tools at our disposal. We had command line applications like net, netsh, xcopy, robocopy, nltest. We had VBS for coverage with WMI and COM, and many GUI-based management applications offered some sort of automation capabilities in there own arena. See where I’m going with this? Just in the world of CMD we had numerous applications each with its’ own idea of how to do things. Some commands used “-“ in front of parameter names, some used “/”. Some used both! Other commands had mind-boggling numbers of parameters - just try running Robocopy /? and let me know what you think. And then commands like netsh can be run interactively and implement a new language parser outside of the CMD session. All these elements have their own learning curve which makes large-scale automation difficult and unattainable for some organizations.

PowerShell was the great equalizer in the Windows administration world and enables all manner of complex automation, but with consistent, repeatable behavior. At its’ best it abstracts the details of varied technologies away so that you can focus on the higher level needs of the task at hand. That’s why I have such a problem with DSLs. To me they feel like a return to the old way of doing things, where automation in every technology had its’ own learning curve. Even the normally sane and rational Kirk Munro has jumped on the DSL bandwagon and is now an open advocate for DSLs in PowerShell, going so far as to give a talk about them at last year’s PowerShell Summit. This is alarming and gives me nightmares of wading through context-based help menus:

netsh /?

Ok.

netsh firewall /?

Crap!

netsh advfirewall /?

Anyway, stop it with the DSLs and just scope your problems to functions and modules like a real PowerShell purist! Add a comment below if you’d like to let me know why you agree with my point of view. Otherwise, get off my lawn!

Thanks for reading!

本文系统(windows)相关术语:三级网络技术 计算机三级网络技术 网络技术基础 计算机网络技术

主题: PowerShellWindowsJavaC#
分页:12
转载请注明
本文标题:Why I Don't Like PowerShell DSLs (and Neither Should You)
本站链接:http://www.codesec.net/view/531407.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 系统(windows) | 评论(0) | 阅读(29)