[erlang-questions] suggestion: shorthand functions

[Mahesh Paolini-Subramanya]

Ah, you misunderstand.
I'm not running around saying Perl Now! Perl Forever!
Instead, what we do is separate the problem domains (to the extent possible, of course).  
There is some set of functionality in the erlang application that needs to be exposed to our business processes - think "add a user", "disable a client", "add billing credits", etc.
These are encapsulated and exposed via escript, and then embedded in perl via 'system' / 'qx' / backquotes / whatever.
The same applies for activities like "rebalance node", "move user to debug node", etc. :-)

cheers
Mahesh Paolini-Subramanya
That Tall Bald Indian Guy...
Google+  | Blog   | Twitter  | LinkedIn

On Jan 15, 2013, at 5:22 AM, Yurii Rashkovskii <yrashk@REDACTED> wrote:

> 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
> That Tall Bald Indian Guy...
> Google+  | Blog   | Twitter  | LinkedIn
> 
> On Jan 11, 2013, at 9:55 AM, Garrett Smith <g...@REDACTED> wrote:
> 
>> On Fri, Jan 11, 2013 at 8:18 AM, Raimo Niskanen
>> <raimo+erlan...@REDACTED> 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
>> http://erlang.org/mailman/listinfo/erlang-questions
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130115/aa6d72b6/attachment.htm>