<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite">I love escripts but find myself intuitively avoiding them for a couple reasons:<br><br>- In most cases, bash is more portable and solves system level<br>problems more directly<br><br>- I don't have the escript foo required to wrench my program it into a<br>single script file</blockquote><br></div><div>Amen.</div><div>perl (bash, python, whatever) is optimally suited for orchestrating between 'application space' and 'business space', as well as orchestration across loosely coupled systems and activities.</div><div>Yes, you could force most of this into erlang-world, but to what point?  IMHO, we do live in a polyglot world, and we may as well take advantage of it…</div><div><br></div><div>Cheers</div><div><br></div><div>p.s. Mind you, there is an entirely different argument to be made about systems where you only have access to erlang (or Ada. or whatever :-)  )</div><div><br><div><div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div style="margin: 0in 0in 0.0001pt; "><font class="Apple-style-span" color="#1f497d" face="Calibri, sans-serif"><span class="Apple-style-span" style="font-size: 15px; "><b><i><div style="margin: 0px; font-style: normal; font-weight: normal; font-family: Calibri; "><a href="http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png"><b><i>Mahesh Paolini-Subramanya</i></b></a></div></i></b></span></font></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">That Tall Bald Indian Guy...</span></div></div><div style="margin: 0in 0in 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><div style="margin: 0px; font-family: Calibri; color: rgb(1, 108, 226); "><span style="text-decoration: underline; "><a href="https://plus.google.com/u/0/108074935470209044442/posts">Google+</a></span><span style="color: rgb(31, 73, 125); ">  | <a href="http://dieswaytoofast.blogspot.com/"><span style="color: rgb(1, 108, 226); ">Blog</span></a></span><span style="text-decoration: underline; "> </span><span style="color: rgb(31, 73, 125); ">  | <span style="color: rgb(1, 108, 226); "><a href="https://twitter.com/dieswaytoofast">Twitter</a></span></span><span style="color: rgb(31, 73, 125); ">  | </span><a href="http://www.linkedin.com/in/dieswaytoofast">LinkedIn</a></div></span></div></div>
</div>
<br><div><div>On Jan 11, 2013, at 9:55 AM, Garrett Smith <<a href="mailto:g@rre.tt">g@rre.tt</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen<br><<a href="mailto:raimo+erlang-questions@erix.ericsson.se">raimo+erlang-questions@erix.ericsson.se</a>> wrote:<br><blockquote type="cite">On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote:<br><blockquote type="cite">Since I've been writing a bunch of rebar.config.script code lately,<br>I've suffered the agony of trying to write concise and readable<br>code without having to do tons of copy-paste, weird unwrapping<br>funs etc.<br><br>What I think would make this sort of thing easier, and also<br>escript programming in general, is if OTP could provide some<br>modules with concise naming and let-it-fail semantics.<br><br>Just off the top of my head, I scribbled down a few functions that<br>I think would make *my* life easier. I pushed them to github to<br>get some discussion going.<br><br><a href="http://github.com/uwiger/shorthand">http://github.com/uwiger/shorthand</a><br><br>The modules are:<br><br>f.erl - shorthand functions for file.erl<br>fn.erl - ditto for filename.erl<br>e.erl - ditto for erl_eval.erl<br><br>The least beneficial is perhaps filename:erl, but my fingers and<br>eyes ache from all the filename:join(filename:dirname(F), …)<br>code.<br><br>Otherwise, I think the biggest benefit is to stick to let-it-crash<br>programming, which I find is usually the default when I write<br>scripts. The original functions are always available if you want<br>to take a closer look at return values.<br><br>(For the file:script() counterparts, I also always pass the name<br>of the script as a binding).<br><br>Comments?<br></blockquote><br>I think it is a nice idea that would improve scripting.<br><br>But how to agree on module names and content is harder. There is a limited<br>number of 1 and 2 character module names, and once in OTP they are written<br>in stone.<br></blockquote><br>Aye. I don't know how critical this use case is (scripting<br>simplification/improvements) to justify new modules in OTP space. And<br>I'm not sure there *is* a case that would be sufficiently ubiquitous.<br><br>I've resigned myself to writing little project specific<br>functions/libraries like this to deal with project specific problems.<br>E.g. this stuff drives me nuts:<br><br>{ok, X} = foo:x(),<br>{ok, Y} = foo:y(),<br>combine(X, Y)<br>...<br><br>So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get this:<br><br>combine(foo_x(), foo_y())<br><br>But who knew that I needed those particular variants? And what about<br>changes? It's my project, so I don't mind little wrappers, especially<br>since functions clarify intent.<br><br>E.g. when I see this:<br><br>ProjectFile = filename:join(ProjectDir, ProjectName)<br><br>I'll almost create a function like this:<br><br>project_filename(Dir, Name) -> filename:join(Dir, Name).<br><br><blockquote type="cite">For f.erl I miss e.g is_dir from filelib, which would introduce the notion<br>of merging old module functionality. Using the name 'fl' for filelib<br>functions would just be hard to remember.<br><br>Aliasing filename:basename to fn:base is a bit unintuitive since the<br>original Unix command is called 'basename' and for e.g file:list_dir<br>you have aliased it to f:ls (as for many other) to make them more Unix:ish.<br>I think it would be better to keep to unix command names where possible.<br>[Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).]<br></blockquote><br>It seems one could make these arguments ad nauseam. To me it's just<br>easier (and preferable frankly) to roll my own as the need arises.<br><br><blockquote type="cite">An alternative approach might be to have a helper module named 'es'<br>containing all scripting aliases...<br></blockquote><br>I love escripts but find myself intuitively avoiding them for a couple reasons:<br><br>- In most cases, bash is more portable and solves system level<br>problems more directly<br><br>- I don't have the escript foo required to wrench my program it into a<br>single script file<br><br>Setting bash aside (not Ulf's use case) the main barrier for me is in<br>the perceived complexity of getting a release-of-sorts into an<br>escript. If I could write up one of these wrapper libraries, or pull<br>it down from somewhere easily, I might use escript everywhere. It's<br>not hard to write the wrappers (you write them as you need them, it<br>takes literally less than a minute for each function) and they're<br>tailored to your requirements.<br><br>It may be trivial to package up the required bytes into an escript<br>today. If it is, I've love to know!<br><br>And I don't know how this fits into rebar specific scripting :)<br><br>Garrett<br>_______________________________________________<br>erlang-questions mailing list<br><a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>http://erlang.org/mailman/listinfo/erlang-questions<br></blockquote></div><br></div></div></body></html>