[erlang-questions] suggestion: shorthand functions

[Yurii Rashkovskii]

Mahesh,

This is certainly a good point about bash/perl/python/whatever, but these 
become quite useless the moment you need to talk to some erlang node from 
your escript.

Yurii.

On Friday, January 11, 2013 7:11:26 AM UTC-8, Mahesh Paolini-Subramanya 
wrote:
>
> I love escripts but find myself intuitively avoiding them for a couple 
> reasons:
>
> - In most cases, bash is more portable and solves system level
> problems more directly
>
> - I don't have the escript foo required to wrench my program it into a
> single script file
>
>
> Amen.
> 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.
> 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…
>
> Cheers
>
> 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 :-)  )
>
> *
> Mahesh Paolini-Subramanya<http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png>
> *
> That Tall Bald Indian Guy...
> Google+ <https://plus.google.com/u/0/108074935470209044442/posts>  | Blog<http://dieswaytoofast.blogspot.com/>
>    | Twitter <https://twitter.com/dieswaytoofast>  | LinkedIn<http://www.linkedin.com/in/dieswaytoofast>
>  
> On Jan 11, 2013, at 9:55 AM, Garrett Smith <g...@REDACTED <javascript:>> 
> wrote:
>
> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen
> <raimo+erlan...@REDACTED <javascript:>> wrote:
>
> On Fri, Jan 11, 2013 at 10:12:40AM +0100, Ulf Wiger wrote:
>
> Since I've been writing a bunch of rebar.config.script code lately,
> I've suffered the agony of trying to write concise and readable
> code without having to do tons of copy-paste, weird unwrapping
> funs etc.
>
> What I think would make this sort of thing easier, and also
> escript programming in general, is if OTP could provide some
> modules with concise naming and let-it-fail semantics.
>
> Just off the top of my head, I scribbled down a few functions that
> I think would make *my* life easier. I pushed them to github to
> get some discussion going.
>
> http://github.com/uwiger/shorthand
>
> The modules are:
>
> f.erl - shorthand functions for file.erl
> fn.erl - ditto for filename.erl
> e.erl - ditto for erl_eval.erl
>
> The least beneficial is perhaps filename:erl, but my fingers and
> eyes ache from all the filename:join(filename:dirname(F), …)
> code.
>
> Otherwise, I think the biggest benefit is to stick to let-it-crash
> programming, which I find is usually the default when I write
> scripts. The original functions are always available if you want
> to take a closer look at return values.
>
> (For the file:script() counterparts, I also always pass the name
> of the script as a binding).
>
> Comments?
>
>
> I think it is a nice idea that would improve scripting.
>
> But how to agree on module names and content is harder. There is a limited
> number of 1 and 2 character module names, and once in OTP they are written
> in stone.
>
>
> Aye. I don't know how critical this use case is (scripting
> simplification/improvements) to justify new modules in OTP space. And
> I'm not sure there *is* a case that would be sufficiently ubiquitous.
>
> I've resigned myself to writing little project specific
> functions/libraries like this to deal with project specific problems.
> E.g. this stuff drives me nuts:
>
> {ok, X} = foo:x(),
> {ok, Y} = foo:y(),
> combine(X, Y)
> ...
>
> So I'll write foo_x/0 and foo_y/0 with crash-on-error semantics to get 
> this:
>
> combine(foo_x(), foo_y())
>
> But who knew that I needed those particular variants? And what about
> changes? It's my project, so I don't mind little wrappers, especially
> since functions clarify intent.
>
> E.g. when I see this:
>
> ProjectFile = filename:join(ProjectDir, ProjectName)
>
> I'll almost create a function like this:
>
> project_filename(Dir, Name) -> filename:join(Dir, Name).
>
> For f.erl I miss e.g is_dir from filelib, which would introduce the notion
> of merging old module functionality. Using the name 'fl' for filelib
> functions would just be hard to remember.
>
> Aliasing filename:basename to fn:base is a bit unintuitive since the
> original Unix command is called 'basename' and for e.g file:list_dir
> you have aliased it to f:ls (as for many other) to make them more Unix:ish.
> I think it would be better to keep to unix command names where possible.
> [Wild idea: f:'-d' for filelib:is_dir, or t:'-d', or f:test(d, Path).]
>
>
> It seems one could make these arguments ad nauseam. To me it's just
> easier (and preferable frankly) to roll my own as the need arises.
>
> An alternative approach might be to have a helper module named 'es'
> containing all scripting aliases...
>
>
> I love escripts but find myself intuitively avoiding them for a couple 
> reasons:
>
> - In most cases, bash is more portable and solves system level
> problems more directly
>
> - I don't have the escript foo required to wrench my program it into a
> single script file
>
> Setting bash aside (not Ulf's use case) the main barrier for me is in
> the perceived complexity of getting a release-of-sorts into an
> escript. If I could write up one of these wrapper libraries, or pull
> it down from somewhere easily, I might use escript everywhere. It's
> not hard to write the wrappers (you write them as you need them, it
> takes literally less than a minute for each function) and they're
> tailored to your requirements.
>
> It may be trivial to package up the required bytes into an escript
> today. If it is, I've love to know!
>
> And I don't know how this fits into rebar specific scripting :)
>
> Garrett
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@REDACTED <javascript:>
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130115/35ad6cbf/attachment.htm>