[erlang-questions] suggestion: shorthand functions

[Mahesh Paolini-Subramanya]

Garrett:
	This gets perilously close to a "how and where one should be doing distributed erlang in the first place" discussion, which is an entire other can of worms :-) 

I quite agree re: spinning up nodes - adding yet another moving part to what is already perilously close to being a hairball makes my eye twitch… (mind you, I suspect this might be different in simpler scenarios, but I'd rather not go down that road in the first place…)

Cheers
p.s.  The last time I mentioned OS signal support on a Sunday morning, Nicole almost brained me w/ her coffee mug...
Mahesh Paolini-Subramanya
That Tall Bald Indian Guy...
Google+  | Blog   | Twitter  | LinkedIn

On Jan 15, 2013, at 9:24 AM, Garrett Smith <g@REDACTED> wrote:

> Hi Mahesh,
> 
> Sounds like Yuri's driver is distributed Erlang.
> 
> There are a bunch of apps out there that implement their command line
> interfaces (CLI) as distributed Erlang nodes that spin up, interact
> with another local node, then shut down. RabbitMQ does this.
> 
> I *hate* it! (anger issues)
> 
> - It's slow -- slower than *Java* for CLI operations
> 
> - It's brittle -- distributed Erlang can fail for a number of reasons
> that are hard to diagnose
> 
> - It introduces a third OS process -- epmd, a little
> single-point-of-failure devil that is the devil
> 
> I personally advocate run_erl, which exposes a shell to to_erl over
> pipes. It's trivial to send commands to an Erlang process from bash or
> Python or anything you like.
> 
> Some have criticized this approach as also being brittle. All I can
> say is that I've used this for years across thousands of servers and
> I'm very happy with it.
> 
> That said, I often spend my Sunday mornings over coffee wondering how
> OS signal support isn't supported in Erlang.
> 
> Garrett
> 
> On Tue, Jan 15, 2013 at 7:46 AM, Mahesh Paolini-Subramanya
> <mahesh@REDACTED> wrote:
>> 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/09cf65bc/attachment.htm>