yarn/typescript and (though some days I hate it..it has gotten better) webpack largely make it feel sane(r).

That said getting to a point where I was comfortable with all three was insanely more complex and time consuming that picking up Delphi 6 was in the early 2000's.

Shrugs, the beast is what it is until someone does something better.

Disclaimer: I'm the main developer behind Signum Framework

I would like to see C#'s LINQ get an update. It seems to have been left to rot since Eric Meijer left the team. It doesn't even support the new values tuples where it's been fitted to every other part of the language:

    from (x,y) in Some((1,2))   // (x,y) will error
    select x + y;

The LINQ to SQL stuff annoys me, because while it works, it's a painful disaster to implement yourself against your own data stores. Believe me, I've tried.

Honestly, if you've seen what LINQ compiles to, it looks an awful lot like a Java 8 Stream.

Using Wikipedia's example of LINQ translation (https://en.wikipedia.org/wiki/Language_Integrated_Query#Lang...):

Written LINQ is:

    var results = from c in SomeCollection
                  where c.SomeProperty < 10
                  select new {c.SomeProperty, c.OtherProperty};

    var results =
         SomeCollection
            .Where(c => c.SomeProperty < 10)
            .Select(c => new {c.SomeProperty, c.OtherProperty});

    Stream<> results = someCollection.stream()
                                     .filter(c -> c.getSomeProperty() < 10)
                                     .map(c -> new AbstractMap.SimpleEntry<>(c.getSomeProperty(), c.getOtherProperty()));

I think Streams have more LINQ in them than most people think.

Disclaimer: it's been about a year since I've written Java 8, and this is off the top of my head (and the last time I used it, my employer's codebase had a class for pairs that was better than just SimpleEntry), so the code could be wrong.

Edit: and just for completeness... the same in Python generator expressions:

    results = ((c.some_property, c.other_property)
               for c in some_collection
               if c.some_property < 10)

    var results = from a in x
                  from b in y
                  from c in z
                  select a * b * c;

    var results = x.SelectMany(a => y.SelectMany(b => z.Select(c => a * b * c)));

That was my point. I was disagreeing with olmo's suggestion that Java "systematically ignored" LINQ.

What's your source for this claim? Because anecdotally I don't see that at all.

I also don't use LINQ to SQL at all. It's all on in-memory stuff. I pretty much never write code like this:

    var result = new List<string>();
    foreach (var item in input) 
    {
        result.Add(item.Value);
    }
    return result; 

    return items.Select(x => x.Value);

    return items
        .Where(x => IsValidKey(x.Key))
        .Select(x => x.Value);

   if (items.Any(x => x == null || x.SomeValue == null)) 
       throw new InvalidArgumentException(nameof(items));

if(items.Any(x => x?.SomeValue == null))

Most uses of where/order/select in C# I'm pretty sure is linq to objects, not sql. I very rarely see the linq proper form in any C# code neither in OSS or in my dat job.

Closest thing we have to real data, but it's been my experience in OSS and in professional life.

    dogs
       .Select(d => d.Id)
       .Where(d => d.Age > 3)
       .Skip(4)
       .Take(2)

I too find the "real" linq form mostly distracting.

Most of it boils down to plain old functional map/fold/filter/zip constructs under different names.

map/filter/reduce are just basic functional programming elements.

This allows you to compose linq expressions without computing intermediate results.

Streams bear a pretty strong resemblance to translated LINQ.

BTW I cover this in my recent book: https://www.packtpub.com/mapt/book/Application%20Development...

You could try code samples and benchmarks: https://github.com/PacktPublishing/ASP.NET-Core-1.0-High-Per...

I'm just concerned about speed. Diffing works ok for forms but charts with 1000s of elements... let's see.

As someone who has worked with D3 and React a lot, D4 makes a lot of sense.

And the name is great!

- vs -

Declaring 'how' this structure is created

selection.enter().append("div").attr("class", "bar") .style("height", function(d){ return d + "px"; }) .style(“margin-top”, function(d){ return (100 — d) + "px"; });

enter is not imperative, but what you write just afterwards is.

It's an active verb and seems to imply an imperative style. Except it's actually declarative. The problem with d3 is that it takes a declarative system and gives it an imperative-looking API.

If I write "node.enter()" it definitely looks like I'm making the node is being made to enter if you aren't well-versed in d3.

But you still "SELECT" something to look at. A SELECT statement is, by itself, sufficient to get something to happen (for results to be fetched).

On the other hand, a D3 enter() does absolutely nothing by itself. You must do further calls for it to have any impact.

This is very off topic and ridiculous.

    SELECT * FROM stuff WHERE thing=2