pig-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Utkarsh Srivastava <utka...@yahoo-inc.com>
Subject Re: Jaql reactions?
Date Sat, 08 Dec 2007 02:43:50 GMT
Hi Ted,

> I get the impression that Jaql is tied less to JSON than it appears at
> first.  In particular, it looked to me like the on-disk format of  
> data files
> could be more flexible.  Certainly adding an abstraction layer for any
> record reader would be trivial.  Similarly, there is nothing that  
> says or
> requires that they actually pass around JSON encoded strings  
> internally and
> there are several statements that imply that they actually pass  
> around data
> structures whose only relationship to JSON is of data to a  
> printable form.

JSON is a serialization format. As regards the data model that it  
tries to capture, I think Pig, Jaql, and various programming  
languages use the same: atomic values, and lists and maps. Hence you  
are right: JSON can be left out of our discussion.

>>> A) specific and direct access to map/reduce in a functional  
>>> programming
>>> syntax.
>> If a language has primitives for per-record processing, grouping, and
>> group-wise aggregation, which both Pig and Jaql do, then direct
>> access to map-reduce is just syntactic sugar on top of these  
>> primitives.
> Hmmm.... The key-word here is functional.  Jaql is a higher-order  
> functional

Ah, sorry! I had totally missed that your emphasis was on functional.  
Jaql does seem to have a functional flavor since the map function is  
specified as the value for a key in the data itself. However, how  
close they are to a full functional language is not clear. We will  
try to clarify this by communicating with the Jaql developers.

As regards Pig, as Ben said, I don't think becoming a full-fledged  
functional programming language is on our roadmap simply because we  
haven't seen uses for it yet (unless of course, our community votes  


View raw message