[erlang-questions] fyi: Google protocol buffers
Thu Jul 10 12:37:15 CEST 2008
I agree perfectly with yours arguments.
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.
So back to my wish : anyone to start the work on full C implementation of
UBF with me?
On Thu, Jul 10, 2008 at 1:42 AM, Christian S <> wrote:
> > I looked at UBF a long time ago and I thought it was a very
> > interesting idea. What I was wondering is why there seems to have been
> > so little apparent interest in this (i.e. why hasn't it transitioned
> > from the POC).
> As long as we are a bit cynical in this thread, I'll share some of my
> I think UBF has got no attention because the skill (in the bottom 95%
> of programmers) at using parser generators and parsing is low, people
> go as far as splitting text on a delimiter character (or regexp
> pattern), they maybe do this further on the results, but that's it. If
> more is needed, they bring in XML, because DOM parsers doesnt
> intimidated the ego the same way a tool you dont know will do.
> UBF, the transport format, can only really be appreciated if you know
> and directly see that it is easy to implement (comparingly). If you
> can see that it is very feature competent, that it has very un-muddled
> data types, the plain list, the tuple, integers, strings, symbols,
> 8bit binary blobs (without silly base64 tricks). There is no XML
> schema on top to bring you elementary data types that all
> machine-to-machine transport _will_ need.
> UBF, the protocol contract language, can only really be appreciated if
> you get to the next level of understanding publicly exposed protocols,
> implementing them, maintaining them, documenting them, designing them.
> So much about programming against an interface is "can i say this
> right now?", or, "what do i need to say before what i really want?".
> You dont see many interfaces targeting this kind of specification, all
> you get is that they're going to throw IllegalStateException if the
> programmer bothered to check premises explicitly, otherwise you will
> likely get a NullPointerException and no guarantees about how valid
> the internal state of the object is now.
> Sorry for my rant. ... ranting is too much fun.
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions