[erlang-questions] fyi: Google protocol buffers
john s wolter
Thu Jul 10 04:58:54 CEST 2008
Just to continue on Christian's comment, I see his point as a knowledge
distribution and use issue. Doctors don't know everything about Medical
Science for example. The trend to to find ways to distribute all the useful
knowledge for your by the unintended and uninformed. As more of computer
science is may easily accessible and automated more people will venture
farther into that realm.
Saying it another way, people in the 21st century will put knowledge to use
as needed. The world has generated piles of knowledge that the masses, if
you will, are going to pick from to get work done. If that means learning
about parsers they will. If that means using a menu driven programming
utility, that's how it will be accomplished.
I use these words, the knowledge distribution system needs to be improved.
Books and traditional learning such as classes are an obstacle to quick
learning for the job your working now. Google search gets what is needed
An example of this that is a distance off the subject of this list is
It is a content management system that uses templates and menu driven
choices to create a web site. You can setup an effective web commerce site
with a distinctive look in a short time with a list of features.
Those in the know will create the tools for the gold miners. The gold
miners will do the actual dirt digging. Think of this system as a way to
keep your job.
On Wed, Jul 9, 2008 at 7:42 PM, 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
John S. Wolter President
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions