[...]Familiar idioms in Perl, Python, JavaScript, and C# « Jon Udell[...]…

List<Dictionary> l = es.events.Where(delegate (EventStore.evt evt) { return (evt.categories != null); }).SelectMany(delegate (EventStore.evt evt) { return evt.categories.Split(new char[] { ‘,’ }); }, delegate (EventStore.evt evt, string tag) { return new { evt = evt, tag = tag }; }).GroupBy(delegate(h__TransparentIdentifier0 h__TransparentIdentifier0){
return h__TransparentIdentifier0.tag;}, delegate (f__AnonymousType0 h__TransparentIdentifier0)
{return h__TransparentIdentifier0.tag;}). OrderByDescending<IGrouping, int>(delegate (IGrouping occurrences) { return occurrences.Count(); }).Select<IGrouping, Dictionary>(delegate (IGrouping occurrences) { Dictionary g__initLocal1 = new Dictionary(); g__initLocal1.Add(occurrences.Key, occurrences.Count());
return g__initLocal1; }).ToList<Dictionary>();

Whoa.

select new Dictionary() {{ occurances.Key, occurances.Count() }};

The mutable nature of Javascript reminds me a bit of Lisp and Prototype. Used Lisp a fair amount in school. Prototype was more dynamic sort of object-oriented language built around instance prototypes rather than static classes, and presented in a paper around 1990. (Good luck finding the paper, as “Prototype” is not a good search term.)

> I am a bit more fond of isolation through
> use of namespaces, and prefer to add a bit
> more room for reuse. Make what you want of
> the difference.

Your JS example and Chris Hollander’s C# example further sharpen my point in comment 2: mapping old habits onto new languages tends to obscure what makes those new languages special.

In order to actually return a List<Dictionary<string,int>>, however, I couldn’t just ToList() the query, but instead had to enumerate it and build the return value.

var tagquery =
  from evt in es.events
    where evt.categories != null
    from tag in evt.categories.Split(',')
    group tag by tag into occurrences
    orderby occurrences.Count() descending
    select new
      {
      tag = occurrences.Key,
      count = occurrences.Count()
      };

var tagcloud = new List<Dictionary>();
foreach (var result in tagquery)
  {
  var dict = new Dictionary()
     { { result.tag, result.count } };
  tagcloud.Add(dict);
  }
return tagcloud;

I have used this approach sparingly because I’m not good at visualizing what goes on inside a LINQ query. With my more old-fashioned style I can step through everything in the debugger and understand things better.

var sortedTagDict =
from evt in esevents
from tag in evt.categories.Split(‘,’)
group tag by tag into occurances
orderby occurances.Count() descending
select new {
tag = occurances.Key,
count = occurances.Count() };

I am a bit more fond of isolation through use of namespaces, and prefer to add a bit more room for reuse. Make what you want of the difference.

I’ve thought about it for a few days now, and the answer doesn’t seem simple. On the one hand, there is the well known correlation between bug count and LOC, whereas on the other, the newer, more compact version of the code in question requires a greater understanding of Javascript on the part of the maintainer in order to modify the code.

I’m leaning towards “more maintainable”, due to potentially reduced bug count, and therefore the less maintenance likely required, but it’s a very good and slightly troubling question. :)

Curious: Do you think the 30 lines is as (or more) readable/maintainable by others? By your future self even?