I agree perfectly with yours arguments.<div><br></div><div>Another (killer) advantage to have a C UBF implementation is that any high level language (Perl, Python, Ruby, OCaml ...) could easily reuse it with glue engine like SWIG.</div>
<div> </div><div>So back to my wish : anyone to start the work on full C implementation of UBF with me?</div><div><br></div><div>Y.<br><br><div class="gmail_quote">On Thu, Jul 10, 2008 at 1:42 AM, Christian S <<a href="mailto:chsu79@gmail.com">chsu79@gmail.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">> I looked at UBF a long time ago and I thought it was a very<br>
> interesting idea. What I was wondering is why there seems to have been<br>
> so little apparent interest in this (i.e. why hasn't it transitioned<br>
> from the POC).<br>
<br>
</div>As long as we are a bit cynical in this thread, I'll share some of my cynism.<br>
<br>
I think UBF has got no attention because the skill (in the bottom 95%<br>
of programmers) at using parser generators and parsing is low, people<br>
go as far as splitting text on a delimiter character (or regexp<br>
pattern), they maybe do this further on the results, but that's it. If<br>
more is needed, they bring in XML, because DOM parsers doesnt<br>
intimidated the ego the same way a tool you dont know will do.<br>
<br>
UBF, the transport format, can only really be appreciated if you know<br>
and directly see that it is easy to implement (comparingly). If you<br>
can see that it is very feature competent, that it has very un-muddled<br>
data types, the plain list, the tuple, integers, strings, symbols,<br>
8bit binary blobs (without silly base64 tricks). There is no XML<br>
schema on top to bring you elementary data types that all<br>
machine-to-machine transport _will_ need.<br>
<br>
UBF, the protocol contract language, can only really be appreciated if<br>
you get to the next level of understanding publicly exposed protocols,<br>
implementing them, maintaining them, documenting them, designing them.<br>
  So much about programming against an interface is "can i say this<br>
right now?", or, "what do i need to say before what i really want?".<br>
You dont see many interfaces targeting this kind of specification, all<br>
you get is that they're going to throw IllegalStateException if the<br>
programmer bothered to check premises explicitly, otherwise you will<br>
likely get a NullPointerException and no guarantees about how valid<br>
the internal state of the object is now.<br>
<br>
<br>
Sorry for my rant.   ... ranting is too much fun.<br>
<div><div></div><div class="Wj3C7c">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>