Mirrors: Design Principles for Meta-level Facilities of Object-Oriented Programming Languages
february 2012 by avdi
Thought-provoking read on using Mirrors for language reflection, via @joshsusser
metaprogramming
reflection
oo
oop
programming
languages
self
smalltalk
clos
lisp
c#
java
february 2012 by avdi
JDK 7: New Interfaces, Classes, Enums, and Methods
april 2011 by avdi
A rundown of some of the lesser-known additions to Java 7.
development
java
april 2011 by avdi
NetBeans Community News
january 2011 by avdi
Boy, Oracle's just batting 1000 these days.
ruby
oracle
java
netbeans
development
january 2011 by avdi
How we use IRC at Last.fm
january 2009 by avdi
How we use IRC at Last.fm. With IRCCat, an elegant Java IRC bot that accepts Twitter-like messages to a network port (generally sent using netcat) and directs them to a user or channel.
irc
irccat
java
lastfm
nc
netcat
richardjones
from google
january 2009 by avdi
Protocol buffers: the early reviews are in
july 2008 by avdi
Google (my current employer) has finally open sourced protocol buffers, the data interchange format we use for internal server-to-server communication. The blogosphere’s response? “No wireless. Less space than a Nomad. Lame.”
Aaaaanyway…
Protocol buffers are “just” cross-platform data structures. All you have to write is the schema (a .proto file), then generate bindings in C++, Java, or Python. (Or Haskell. Or Perl.) The .proto file is just a schema; it doesn’t contain any data except default values. All getting and setting is done in code. The serialized over-the-wire format is designed to minimize network traffic, and deserialization (especially in C++) is designed to maximize performance. I can’t begin to describe how much effort Google spends maximizing performance at every level. We would tear down our data centers and rewire them with $500 ethernet cables if you could prove that it would reduce latency by 1%.
Besides being blindingly fast, protocol buffers have lots of neat features. A zero-size PB returns default values. You can nest PBs inside each other. And most importantly, PBs are both backward and forward compatible, which means you can upgrade servers gradually and they can still talk to each other in the interim. (When you have as many machines as Google has, it’s always the interim somewhere.)
Comparisons to other data formats was, I suppose, inevitable. Old-timers may remember ASN.1 or IIOP. Kids these days seem to compare everything to XML or JSON. They’re actually closer to Facebook’s Thrift (written by ex-Googlers) or SQL Server’s TDS. Protocol buffers won’t kill XML (no matter how much you wish they would), nor will they replace JSON, ASN.1, or carrier pigeon. But they’re simple and they’re fast and they scale like crazy, and that’s the way Google likes it.
unfiled
asn.1
c++
google
java
json
programming
python
scalability
xml
from google
Aaaaanyway…
Protocol buffers are “just” cross-platform data structures. All you have to write is the schema (a .proto file), then generate bindings in C++, Java, or Python. (Or Haskell. Or Perl.) The .proto file is just a schema; it doesn’t contain any data except default values. All getting and setting is done in code. The serialized over-the-wire format is designed to minimize network traffic, and deserialization (especially in C++) is designed to maximize performance. I can’t begin to describe how much effort Google spends maximizing performance at every level. We would tear down our data centers and rewire them with $500 ethernet cables if you could prove that it would reduce latency by 1%.
Besides being blindingly fast, protocol buffers have lots of neat features. A zero-size PB returns default values. You can nest PBs inside each other. And most importantly, PBs are both backward and forward compatible, which means you can upgrade servers gradually and they can still talk to each other in the interim. (When you have as many machines as Google has, it’s always the interim somewhere.)
Comparisons to other data formats was, I suppose, inevitable. Old-timers may remember ASN.1 or IIOP. Kids these days seem to compare everything to XML or JSON. They’re actually closer to Facebook’s Thrift (written by ex-Googlers) or SQL Server’s TDS. Protocol buffers won’t kill XML (no matter how much you wish they would), nor will they replace JSON, ASN.1, or carrier pigeon. But they’re simple and they’re fast and they scale like crazy, and that’s the way Google likes it.
july 2008 by avdi
Data structure traversal with Tom
april 2008 by avdi
Strategies provide a nice mecanism for operations that require data structure traversal. This post presents a brief overview of the strategies implementation in Tom.StrategiesTom incorporates the concept of strategy which provides a nice way to perform operations that traverse heterogeneous data structures. These operations could be complete/partial tree transformations or queries.The paper The Essence of Strategic Programming by Ralf Lämmel, Eelco Visser and Joost Visser gives a very nice implementation-independent definition for the concept. From this paper:The key idea underlying strategic programming is the separation of problem-specific ingredients of traversal functionality (i.e., basic actions) and reusable traversal schemes (i.e., traversal control).This paragraph mentions two very interesting characteristics of strategic programming: the separation of problem-specific code from traversal code and the use of reusable traversal schemes. ExampleThe following example , taken from the Wikipedia entry for the Visitor pattern, shows how strategies are used to print the parts of a data structure.Given the following definitions:module Cars imports String abstract syntax Wheel = Wheel(name:String) Engine = Engine() Body = Body() Wheels = Wheels(Wheel*) Vehicle = Car(engine:Engine,body:Body,wheels:Wheels)We can write the following strategy to print all the parts of a Car:%strategy PrintStrategy() extends Identity(){ visit Wheel { Wheel(name) -> { System.out.println("Visiting " + `name+ " wheel"); } } visit Engine { Engine() -> {System.out.println("Visiting engine");} } visit Body { Body() -> {System.out.println("Visiting body");} } visit Vehicle { Car(_,_,_) -> { System.out.println("Visiting Car"); } } }We can apply this strategy the following way:public static void main(String[] a) throws Exception { Vehicle v = `Car(Engine(), Body(), Wheels(Wheel("front left"), Wheel("front right"), Wheel("back left"), Wheel("back right"))); `TopDown(PrintStrategy()).visit(v);}Running this program shows:Visiting CarVisiting engineVisiting bodyVisiting front left wheelVisiting front right wheelVisiting back left wheelVisiting back right wheelAs shown in this example, the problem-specific code is located in the definition of PrintStrategy and the traversal code is reused from the existing TopDown strategy. The ability of switching traversal schemes is very powerful, for example say that we want to print the parts of the data structure starting with the leafs. We can reuse the existing BottomUp strategy the following way:...`BottomUp(PrintStrategy()).visit(v);This program shows:Visiting engineVisiting bodyVisiting front left wheelVisiting front right wheelVisiting back left wheelVisiting back right wheelVisiting Car Just scratch the surface A very detailed explanation of this feature is provided in the Introduction to strategies and Strategies in practice sections of the Tom manual.Also there're several incarnations of this concept in other languages and platforms. For more information check the The Essence of Strategic Programming paper.
java
tom
from google
april 2008 by avdi
related tags
abstraction ⊕ ajax ⊕ algorithms ⊕ amqp ⊕ An ⊕ analysis ⊕ antlr ⊕ aop ⊕ api ⊕ architecture ⊕ art ⊕ articles ⊕ artificial ⊕ asn.1 ⊕ aspectj ⊕ aspects ⊕ assembly ⊕ atom ⊕ blogging ⊕ blogs ⊕ books ⊕ c ⊕ c# ⊕ c++ ⊕ charts ⊕ clos ⊕ cms ⊕ code ⊕ collaboration ⊕ comparison ⊕ compiler ⊕ composite ⊕ computer ⊕ concurrency ⊕ console ⊕ continuations ⊕ contract ⊕ cross-reference ⊕ csp ⊕ css ⊕ data ⊕ database ⊕ dbc ⊕ debug ⊕ description-logic ⊕ design ⊕ development ⊕ directory ⊕ distributed ⊕ documentation ⊕ dom ⊕ domain ⊕ dotnet ⊕ Dynamic_Languages ⊕ eclipse ⊕ editor ⊕ emacs ⊕ emacs-like ⊕ engine ⊕ enterprise ⊕ entropy ⊕ extensions ⊕ framework ⊕ frameworks ⊕ functional ⊕ game ⊕ generator ⊕ generic ⊕ generics ⊕ google ⊕ graphics ⊕ groovy ⊕ haskell ⊕ hosting ⊕ howto ⊕ html ⊕ humor ⊕ in ⊕ inference ⊕ inteligence ⊕ interface ⊕ interop ⊕ interpreter ⊕ irc ⊕ irccat ⊕ java ⊖ javascript ⊕ jsf ⊕ json ⊕ jvm ⊕ language ⊕ languages ⊕ lastfm ⊕ learning ⊕ libraries ⊕ library ⊕ linux ⊕ lisp ⊕ literate ⊕ math ⊕ mda ⊕ messaging ⊕ metadata ⊕ metaprogramming ⊕ methodology ⊕ microkernel ⊕ ml ⊕ model ⊕ modeling ⊕ nc ⊕ netbeans ⊕ netcat ⊕ network ⊕ ontology ⊕ oo ⊕ oodbms ⊕ oop ⊕ opensource ⊕ opinion ⊕ oracle ⊕ owl ⊕ parser ⊕ patterns ⊕ perl ⊕ php ⊕ pipelines ⊕ programming ⊕ publishing ⊕ python ⊕ query ⊕ rails ⊕ randomness ⊕ rdf ⊕ reasoner ⊕ reference ⊕ reflection ⊕ reporting ⊕ reports ⊕ research ⊕ rest ⊕ review ⊕ richardjones ⊕ ruby ⊕ saxon ⊕ scala ⊕ scalability ⊕ scheme ⊕ science ⊕ search ⊕ self ⊕ semantic ⊕ sequence ⊕ server ⊕ smalltalk ⊕ social ⊕ software ⊕ source ⊕ sparql ⊕ standard ⊕ stl ⊕ storage ⊕ stripes ⊕ sucks ⊕ tags ⊕ tcl ⊕ Technology ⊕ Technology/Dynamic_Languages ⊕ Technology/Java ⊕ Technology/Ruby ⊕ templates ⊕ testing ⊕ to-read ⊕ tom ⊕ tool ⊕ tools ⊕ toys ⊕ tutorial ⊕ tutorials ⊕ uml ⊕ unfiled ⊕ visualization ⊕ vm ⊕ web ⊕ wicket ⊕ wiki ⊕ written ⊕ xhtml ⊕ xml ⊕ xpath ⊕ xproc ⊕ xquery ⊕ xsl ⊕ xslt ⊕Copy this bookmark: