In the Python web world, the debate on whether templating languages should offer programming language type abilities has reared its head again. from "Stupid templating languages", to "Not So Stupid Template Languages", "In Response to "Stupid Template Languages"", and discussed more on reddit here.
In the world of Electronic Design Automation and integrating complex EDA software tools, the EDA companies,, on the whole, have embraced TCL as their scripting tool, but sometimes I have inherited a complex design flow, where, to add control, and later flexibility within that control, proprietary initialization file formats and their parsers have grown by adding their own macro language type features and grown to need the power of something like the bash shell. Rather than ditching their proprietary lashed-together, one-off languages for something that is tried and tested and used/debugged by many - such as bash/python/Tcl/Lua they persevere by adding more capability to an in-house, one project language.
In the case of web templating the main argument is that given an intelligent web templating language, people are apt to migrate what should be business logic into the templates thereby muddying the separation of the business logic from the presentation layer. In the EDA field the problem is often the maintenance of the proprietary macro language and the proliferation of languages with which one needs to be familiar with in order to master a design environment.
I won't comment more on the web templating debate, but when it comes to initialization file formats and or initialization scripts then you should stick to pre-existing standards such as .ini files or .csv files in the simpler cases, or use pre-existing scripting languages when you need more power such as bash scripts, Python, or Tcl.
Mainly Tech projects on Python and Electronic Design Automation.
Tuesday, December 07, 2010
Subscribe to:
Post Comments (Atom)
About Me
Followers
Subscribe Now: google
Well said! Standards offer robust, perennial and convenient choices. The IT world has been evolving, albeit slowly, in this direction, and I believe it will continue to do so, because people are progressively realizing the importance of using standards.
ReplyDeletesystem like ubuntu/linux also suffer from the never ending inventiveness of people who believe that one byte saved in rarely-touched and rather short configuration file like fstab or sudoers or the like is worth the effort to define a new language, together with custom parsers and sometimes custom emitters for that format. the result is that such files are mostly wholly unreadable and unmanageable except to the expert. if you want to really manage the subtleties of your linux box, you better get prepared for gazillions of little domain-specific languages, all with their own subtle niceties and too many new and interesting ways to bork up things when the wrong character lands in the wrong place when editing the mess. shudder.
ReplyDeleteSame goes for writing elaborate command file parsers in VHDL or Verilog for testbenches, which invariably grow from simple "read" and "write" commands to supporting loops and if...thens, and binary and hex arguments etc., instead of just using the existing support in the HDL language itself.
ReplyDeleteAmen to that Marquardt!!!
ReplyDeleteI too have seen those VHDL/Verilog monstrosities! It is amazing just what a Perl/Python/Tcl script can keep up with - it is rarely the slowest part of a complex verification environment. (I wish we used scripting languages over C/C++ a bit more in verification, although Specman has some of that dynamic feel).