Ask HN: Volunteer Tech 'Job' Board? - <AUTHOR>

I am part of a non-profit organization that is looking for volunteer help in the (web) design department. We make videos about other non-profit organizations and it's really cool. Our website can be found here: http://www.goodevidence.com
Are there any tech based volunteer job boards so I can get in touch with tech folk who are looking to volunteer their time?
As you can see from the site, we are looking for someone to help us organize the information on the site from a design perspective.
Thanks. <comment><AUTHOR> Clickable link: <http://www.goodevidence.com>

I should note that the entire organization is totally volunteer run.</comment>


Pattern Matching for Java - <AUTHOR> http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.html <comment><USER2> IMO this is the biggest thing available to modern languages that Java is missing. I would absolutely love to see this, particularly pattern decomposition. I wonder if you could do it without something analogous to Scala's sealed classes though--you really want your type checker to be able to assert every match has considered every branch (without having to specify a "default" everywhere). That means you need to be able to mark classes as not- dynamically-extendible, so the type checker has the full set of subtypes available.

Edit: Just got to the bottom of the article. Looks like sealed hierarchies is exactly what they explore.

<comment><USER3> I mean, reading this article is basically a giant advertisement for Scala and its powerful pattern matching.

      functionThatReturnsAnyVal match {
        case i: Int if i > 2 => System.out.println("Greater than 2")
        case i: Int => System.out.println("Less than or equal to 2")
        case s: String => System.out.println("Hello, " + s)
        case _ =>
      }

<comment><USER4> This still seems a terrible example just to try and avoid naming an object. Isn't the comparison to:

        Object o = functionThatReturnsAnyVal();
        if (o instanceof Integer) {
            Integer i = (Integer) o;
            if (i > 2) {
               System.out.println("Greater than 2.");
            } else {
               System.out.println("Less than or equal to 2.");
            }
         } else if (o instanceof String) {
            String s = (String) s;
            System.out.println("Hello, " + s);
         }

I get that the case syntax is kinda nice, but this particular example just doesn't seem to get there for me. Roughly half the lines, which is good. None of them hard to reason about. Which makes it a wash.

Or is the comparison to something else?

<comment><USER3> In reality my function would rarely exist in the Scala world since having a weakly-typed return like that is cringeworthy to say the least. But it's better to see this in action with Scala options.

      val myOptionalVar: Option[String] = functionThatReturnsOption()

      myOptionalVar match {
        case Some(str) if str.length > 10 => System.out.println("This is a long string.")
        case Some(str) => System.out.println("This is a short string.")
        case None => System.out.println("This code would be fifteen lines of null checking in Java.")
      }

<comment><USER5> With Java 8 having Optional and Lambdas, this is no longer the case:

      final Optional<String> myOptionalVar = functionThatReturnsOptional();

      final String output = myOptionalVar
        .map(str -> str.length() > 10
          ? "This is a long string."
          : "This is a short string.")
        .orElse("This code would be fifteen lines of null checking in Java.");

      System.out.println(output);

</comment></comment></comment></comment></comment><comment><USER6> Why the fixation on pattern matching? Don't get me wrong, I enjoy the benefit it provides, but for OO code multiple dispatch is a more elegant and idiomatic way to solve the "I don't want to implement the visitor pattern" problem.

FYI, I recently found out that C# can actually do multiple dispatch

[https://blogs.msdn.microsoft.com/shawnhar/2011/04/05/visitor...](https://blogs.msdn.microsoft.com/shawnhar/2011/04/05/visitor- and-multiple-dispatch-via-c-dynamic/)

<comment><USER7> To me it seems pattern matching without possibility to actually enforce that all cases are matched seems to miss the most useful scenario:

What I want to do is create proper sum types. For some reason most OO languages were designed around the idea that being "open for extension" was a good thing. Normally if I make a base class, I want a _closed_ and _known_ set of sub classes. E.g. if I make a payment method then I want to make a Credit or Invoice kind where one requires Credit Card details and the other requires an address. In F# that's a simple sum type. In C# making a sum type is a convoluted mess of making an outer base class and private nested sub classes.

Here a sum type with the two cases plus an _exhaustive_ pattern matching switch would have solved in 10 lines what takes me 300 lines to do in C#. I think the concept of "fixed" or "closed" hierarchies is foreign enough to OO that it probably needs to be a completely separate concept from the normal types. F# shows that it can be implemented as sugar on top of the regular CLR type system. All that's needed is that some keyword such as "enum class" is converted into a sealed hierarchy of plain record classes with no methods on them. The switch statement we already have can then treat these "enum classes" specially by checking that all cases are matched.

A sketch solution for C# could look like

        enum class PaymentMethod
        {
            CreditCard(CrediCardDetails cc),
            Invoice(Address billingAddress),
        }

        // later
        switch (paymentMethod)
        {
          case CreditCard(ccdetails):
             Console.WriteLine($"Creditcard expiring {ccdetails.ExpiryDate}");
          case Invoice(addr):
             Console.WriteLine($"Bill to {addr.Name}");
        }

Writing the above in current C# would require significantly more boilerplate. This isn't the best pattern to use in all situations: but in many cases when the types are merely data carriers it doesn't make sense to put the logic _in_ the class as OO prescribes, so the FP recipe works much better.

<comment><USER6> In the C# example in the code I posted, all cases are matched. If you add a new animal subclass, that's not "explicitly" handled, it will route to the default (Animal, Animal) method.

It's equivalent of

        _ -> default_function

At the end of a pattern matching statement.

Essentially it's _impossible_ for not all the cases to be matched, as far as I can see.

<comment><USER7> Yes but making new classes map to default is what a default clause already does (which is basically what a base case in an abstract base class does with normal inheritance).

What I want is to make a new type added mean the code won't compile until it is _explicitly_ handled in all pattern matches that do not have a default clause. Basically what I'm saying is that this:

       bool HandlePayment(PaymentMethod pm) {
          switch(pm) {
             case Invoice(addr):
                  SendInvoice(addr);
                  return true;
             case CreditCard(ccdetails)
                  return PrcessCreditcard(ccdetails);
             default:
                  // What?
          }
       }

Would be a lot better if it didn't require the default, and the compiler could detect the error that occurs when someone adds a new case (BitCoin) to the types of payment method. Inheritance and abstract baseclass for the processing means that you'd do this

       bool HandlePayment(PaymentMethod pm)
       {
          return pm.Process(order);  // sends an invoice, charges credit card etc
       }

       and you simply have

       abstract class PaymentMethod { abstract bool Process(order); }
       class CreditCard : PaymentMethod {  ... }
       class Invoice : PaymentMethod {  ... }

And this is of course the regular way of writing OO, but I find it unnatural and cumbersome in many cases. It's hard to define concise descriptions of what types are actually available, and you have to write a ton of boilerplate to ensure a closed hierarchy and complete matching in all scenarios where you can't enclose the logic inside each type.

</comment></comment></comment></comment><comment><USER8> I was originally very happy to hear pattern matching was coming to C#, but I don't think it is actually that useful a feature without discriminated unions/sum types too.

<comment><USER9> What C# has now is better described as fancy form of Destructuring . Perhaps they'll add actual pattern matching in a later release.

Actually the proposed java version is better than C#'s because it allows a form of exhaustiveness checking which C# doesn't even attempt to provide for.

However they had to add the `sealed` keyword too, which does not currently exist in java

</comment></comment><comment><USER10> "How we declare the destructuring pattern in the AddNode class, or declare AddNode so that it implicitly acquires one, will be covered in a separate document."

Please use a Scala unapply() and not just constructor parameters. The former gives much more latitude to build patterns.

I have a ton more to say about all of this having written in Scala and Kotlin extensively. I'll just say that it is useful they are already thinking about new variable assignment to parts of matches and NOT concerning themselves w/ "smart casts".

</comment><comment><USER11> Pattern matching is possibly one of the most under-utilized approaches that can simplify a lot of ugly/complex logic.

<comment><USER12> On the other hand it "prettifies" bad code style - branching by dynamic casts / type comparisons.

<comment><USER11> I disagree. What's bad about that/what's the alternative?

<comment><USER13> The problem with pattern matching as I've seen it implemented is that unsafe and safe pattern matching look exactly the same (even the exact same code line can be safe or unsafe depending on context). See the bottom of [http://typelevel.org/blog/2014/11/10/why_is_adt_pattern_matc...](http://typelevel.org/blog/2014/11/10/why_is_adt_pattern_matching_allowed.html) . For this reason I tend to prefer explicit virtual methods even though they're more cumbersome.

<comment><USER11> The pattern matching I have in mind is very dynamic in nature and does not concern itself at all with some static notion the data that is being matched. Either there's a match, or there isn't. It's a very binary outcome.

<comment><USER13> That's not the important/valuable use case for what people normally refer to as "pattern matching".

<comment><USER11> I've recently found dynamic pattern matching pretty valuable to completely replace REST-like server-side APIs with a data-oriented API that gets pattern matched and dispatched based on the actual values and shapes of the data structure.

It helps almost completely avoid the /get/this /get/that /set/those explosion of API getters and setters that ultimately leads to very complex client logic that makes any notion of consistency at a distance very hard to reason about.

<comment><USER13> I really don't think you're talking about pattern matching in the usual sense. So it's probably better to use a different term.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> IMO the hierarchy of need for this goes:

1 - case classes / value classes / data classes, whatever you want to call them.

2 - match-and-bind syntax

...

11? - fancy pattern matching

This maybe says more about how much I pay attention to what's upstream in Java, but I found the fact that this is just a hypothetical proposal, in April of 2017, strangely shocking. I guess I figured it _had_ to be on the docket for a future java version already.

<comment><USER15> This is not just a hypothetical proposal, I believe there is a working prototype and a lot of thought has gone into this. More things are coming, but pattern matching is a low hanging fruit that doesn't have difficult interactions with the type system or VM. Value classes need a lot of language enhancement to be really useful, and those things are likely to land before value classes themselves.

<comment><USER16> Project Valhalla (featuring value classes) is scheduled for Java 10 — so it'll probably arrive in production around 2020.

<comment><USER15> I cannot comment on the Java release schedule, but Project Valhalla will be done when it's done, and it is not a small task. Project Amber is intended for smaller changes that may have been investigated as part of Valhalla and can be released earlier.

</comment></comment></comment></comment><comment><USER17> To me the biggest missing features are not this but:

* heredoc/multiline string/embedded interpolated strings * concise array, map, and object literal initializers. * structural/anonymous types

Simple things like multivalue return become an exercise in boilerplate in Java. As much as I like Immutables.org or @AutoValue, I should be able to return a struct or use destructuring operations at the callsite.

The hack in Java is to use annotation processors to provide nice fluent builder patterns, but really the language should have first class support for this.

<comment><USER18> > concise array, map, and object literal initializers.

[http://openjdk.java.net/jeps/269](http://openjdk.java.net/jeps/269) Just a few more month.

Still nothing for the other two, but 1/3 is better than nothing.

<comment><USER17> Those aren't new language features though, mostly just standardizing Guava conventions into the JDK.

<comment><USER18> Fair enough, but they do the job. I understand the wish of the designers to not change the syntax if a standard library extension does the job for 99% of the cases. Changing the language syntax is a far more elaborate process.

<comment><USER17> I think it gets real ugly once you need nested data structures, the readability goes down (maps of lists of maps). Also, using overloads means it's limited to small arity, e.g. 10.

Not having first class multiline literals really makes it painful to write something like React or GraphQL in Java.

One of the things I give props to MS for is having the courage to evolve C# and TypeScript at a breakneck pace. Each release of TS, they add features I've been wishing for. They seem to be listening to developer productivity issues and responding.

I under Java's desire to preserve backwards compatibility, but they end up breaking it anyway, and make design decisions based on how they can shoehorn things into the older JVMs, but each new release ends up with some issues. Witness how long it has taken folks to migrate to Java8. If we're going to wait years for major releases, then let's make them well worth the trouble when they finally arrive.

<comment><USER18> > Not having first class multiline literals really makes it painful to write > something like React or GraphQL in Java.

Certainly. And that's one of my biggest pain points with Java, but a different point in your list. One day they will exist ... one day. Hopefully.

> Witness how long it has taken folks to migrate to Java8. If we're going to > wait years for major releases, then let's make them well worth the trouble > when they finally arrive.

I've used every release since JDK 6 in production one or two month after it was released. Once that hurt me (Rhino/Nashorn), but usually it hasn't been a problem. I think people who wait until the last moment when the older versions go out of support to switch JDKs do themselves a disservice out of fear. And fear is never a good reason.

</comment></comment></comment></comment></comment></comment><comment><USER19> I'm currently thinking through the design of a pattern-matching feature for JavaScript, through a superset I'm building called LightScript[0].

I liked that this article laid out the specific options and various shades of gray that can constitute parts of "pattern matching".

I'm curious for thoughts on a syntax like this:

        x = match y:
          case > 3: () => "it's bigger than three"
          case 2: () => "it's strictly equal to two"
          case Integer: (x) => `some int smaller than two: ${x}`
          case String: (s) => `some string: ${s}`
          case Array: ([ first, ...rest ]) => `a list starting with ${first}`
          case Object: ({ a, b }) => `an object with property a: ${a}`

This is somewhat more difficult given that even when using Flow or TypeScript, there's relatively little type granularity available at runtime.

Any thoughts?

[0] [http://lightscript.org](http://lightscript.org)

</comment><comment><USER20> Would be really great to see this make it's way into the language. Here are some ways I've found to work around its absence: * adding a match() function to a common base type. So if it could have subtypes Foo(x), Bar(y, z), then the signature would look like:

      <T> T match(Function<X, T> foo, BiFunction<Y, Z, T> bar);

* in the cases where I don't have control over the common base type, I've written a builder pattern that constructs a sequence of predicate-function pairs and applies them appropriately. This looks like so:

        new PatternMatchingHelper()
        .append(Foo.class, foo -> doSomething(foo.x))
        .append(Bar.class, bar -> doSomethingElse(bar.y, bar.z))
        .otherwise(x -> fallbackValue())
        .apply(objectOfUnknownType);

The main disadvantage here is that it doesn't work well with generics, because the class objects have raw types.

You could probably extend the second approach to get something close to the arbitrary predicates that pattern matching would provide, but the syntax wouldn't be nearly a clean as having it in the language.

<comment><USER21> Just use another language if you want pattern matching so badly. Twisting Java to look like Scala doesn't do the language justice.

<comment><USER22> You act as if what op described must be the entirety of their code base. What if pattern matching is just a small part of a larger problem better solved with Java?

</comment></comment></comment><comment><USER23> Any substantial differences from Scala's implementation? From what I remember of Odersky's book it seems very similar if not identical. (Which is fine - I'm all for Java incorporating the best parts of Scala.)

<comment><USER24> The syntax looks similar, but there's no mention of an `unapply()`-type thing, which would limit the flexibility of this proposal greatly.

</comment></comment><comment><USER25> If you like pattern matching, you'll _love_ it's generalization into Prolog unification as explained in eg. [1].

[1]: [http://www.amzi.com/AdventureInProlog/a10unif.php](http://www.amzi.com/AdventureInProlog/a10unif.php)

</comment><comment><USER26> I really really like these suggestions. Especially the first parts where I have found myself writing a lot of instance-of-cast and just marvel at how much clutter it actually adds without adding more description to the code. I do also ponder if there is a limit to how much we should potentially shorten the expressions, not to make the expressions extremely dense it understanding. The last opinion is just taste though, admittedly.

</comment><comment><USER27> I feel these new language features that get grafted onto Java end up awkward and unpleasant to use. Java is still Java, and it exacts a stiff awkwardness tax for writing code in a style different from how Java OO was envisioned 15-20 years ago. The examples in the linked article look fine, but the difference between pattern matching as "possible direction" and pattern matching as "new language feature" could easily end up like the difference between Orson Welles as Charles Foster Kane and Orson Welles as Falstaff.

I wonder if Oracle could create some excitement around the platform by creating or adopting a new language as an official repla^D^D^D^D^D "new member of the family" to implicitly succeed Java just like C# replaced Visual Basic for most use cases. Java could be kept around as a sop to die-hards like VB.NET was. It's great that the JVM allows a thousand flowers to bloom, but it's not great that the only "official" choice on the JVM is a language that hasn't been able to evolve very far from its 1990s roots.

<comment><USER28> Oracle's most profitable customers are still using Java 6. That wouldn't change if they were pushing Kotlin.

<comment><USER27> I don't know Kotlin, but judging by their "Kotlin for Scala Developers" article I don't know if it would be a big enough jump to get people excited, especially since a project like this would take years to come to fruition. I think Scala is a good first try at what the successor language could be, but it has two problems: its reputation as a hard language, and the fact that it partly deserves said reputation. (Maybe if Odersky succeeds in simplifying the concepts underlying Scala as he's trying to now with Dotty, the result will be a potential Java-killer.) Oracle would have to fund a research project to choose an existing candidate and spend years developing it to fit the role it would play in the market. Which sounds very unlike Oracle, so I'm not holding my breath.

EDIT: And to your point, I think it's a bad sign if their most profitable customers think that none of the Java language updates they've released in the last ten years is worth upgrading for. The longer their customers stick with 2006-era Java, the longer they pass up Oracle's current offerings, the less attached they feel to the future of the platform, and the more likely they are to make a big change when they do make a change.

</comment></comment></comment><comment><USER29> You can do this in Java using derive4j: [https://github.com/derive4j/derive4j](https://github.com/derive4j/derive4j).

It generates code for algebraic data types which offer a typesafe interface similar to the `case` statements in languages that natively support pattern matching.

<comment><USER30> In the same way you could "do" lambdas with single method interfaces in Java pre-8. It was possible, but it was still a pain to do.

<comment><USER31> It depends. Bare minimum, in scala you have to do:

      sealed trait Either[A, B]
      final case class Left[A, B](a: A) extends Either[A, B]
      final case class Right[A, B](b: B) extends Either[A, B]

and it is still not a real sum type due to exposing subtyping (cf. [https://github.com/quasar-analytics/quasar/wiki/Faking- Sum-T...](https://github.com/quasar-analytics/quasar/wiki/Faking-Sum-Types))

with derive4j:

      @Data
      interface Either<A, B> {
        <X> X match(Function<A, X> left, Function<B, X> right);
      }

or, at your preference:

      @Data
      interface Either<A, B> {
        interface Cases<X> {
          X left(A leftValue);
          X right(B rightValue);
        }
        <X> X match(Cases<X> cases);
      }

So it is actually not much boilerplate.

The real drawback of (any) java implementation is lack of TCO.

</comment></comment></comment><comment><USER32> The syntax still looks tedious compared to Ceylon:

        if (is String name) {
            // compiler knows 'name' is String in this block
            print(name);
        }
        else {
            print("some other text");
        }

Why declare a new variable? The Ceylon syntax works great with union types too.

<comment><USER33> I had the same comment on C#'s implementation:

[https://news.ycombinator.com/item?id=12971841#12972691](https://news.ycombinator.com/item?id=12971841#12972691)

In C#, the "wanting the supertype" answer makes some sense with explicit interface implementations [0]. Java doesn't have that, and AFAIK there's no way to declare something that's visible on a supertype but not a subtype.

[0] I think it's a bad reason. But the possibility does at least exist.

</comment></comment><comment><USER34> How about...

        instanceOf x is? {
            Int { System.out.println("It's an Int"); }
            String { System.out.println("Hello, " + x); }
            _default { System.out.println("This type is not explicitly named here."); }
        }

And if you don't want the type, the value of any other method, function, or attribute could be checked by "is?" or whatever syntax token you want there.

Further tests could be saved for within those blocks to save complexity.

What's odd though is that in Java this particular example seems to want multi- method. Testing the type explicitly and acting on it is more akin to duck- typed language programming. You see this pattern pretty often in Perl for example. If I want to write in Perl, I typically reach for Perl.

<comment><USER35> It's not just the types/instanceof operator though

They're talking about making the Pattern matcher match more complex patterns.

</comment></comment><comment><USER36> Along with with Value Types [1] Java 10 could be an even more significant improvement than Java 8 was :)

[1] [http://cr.openjdk.java.net/~jrose/values/values-0.html](http://cr.openjdk.java.net/~jrose/values/values-0.html)

</comment><comment><USER37> Jeez, seems like overkill when you get that free in more modern of stacks. Move to Elixir. Pattern matching is done right and it's brilliantly designed. I understand that if you're having to maintain Java applications, but why anybody would stomach a NEW project on that behemoth is beyond me. I'm not just talking about performance, I'm talking about object topology BS, complicated libraries, etc. Java (for me now) seems like it's bolted on to the Web and simply doesn't have it's place as a Web stack. My opinion of course but with the great amount of stacks out there -- I don't get the fascination.

</comment><comment><USER38> I would love to see this land in Java. Pattern matching is one of my favorite features of Rust.

</comment><comment><USER39> There is some very cool language design work from Chinawat Isradisaikul and Andrew C. Myers at Cornell on adding very powerful matching constructs to a Java-like language.

Paper: [http://www.cs.cornell.edu/~chinawat/papers/pldi13-p343-israd...](http://www.cs.cornell.edu/~chinawat/papers/pldi13-p343-isradisaikul.pdf) Slides: [http://www.cs.cornell.edu/~chinawat/papers/chin- pldi13-slide...](http://www.cs.cornell.edu/~chinawat/papers/chin- pldi13-slides.pdf)

</comment><comment><USER40> Reading this reminded me of all the discussions that took/are taking place for pattern matching in C#[0]; reading this I had the same reactions that I did for C#: cool stuff. It's also nice to see the languages reach parity in features; I only hope the two language committees pay attention to the research/feedback that the other receives.

[0]: [https://github.com/dotnet/roslyn/issues/10153](https://github.com/dotnet/roslyn/issues/10153)

</comment><comment><USER41> "Finally, the above code is less optimizable; absent compiler heroics, it will have O(n) time complexity, even though the underlying problem is often O(1)."

Is this addressed with pattern matching?

</comment><comment><USER42> How does Vavr's (formerly Javaslang) pattern matching hold up? [http://www.vavr.io/](http://www.vavr.io/)

<comment><USER43> I already use vavr, sadly such pattern matching is not exhaustive, which is the most important feature for me.

</comment></comment><comment><USER44> Java already has simple pattern matching with exceptions (try {throw ...} catch ...). It's surprisingly ergonomic, even though it's just a hack

</comment><comment><USER45> Shameless plug: I recently wrote a similar piece exploring pattern matching in Javascript [http://jarrodkahn.com/posts/6/slug/](http://jarrodkahn.com/posts/6/slug/)

</comment><comment><USER46> Looks quite Swift-like. Seems like a big win all around for pattern matching to become more "main stream".

</comment><comment><USER47> This is nice. But I think my number one feature would be first-class relationships in object oriented languages.

</comment><comment><USER48> Am I missing something or can most of the examples just be achieved with method overloading?

<comment><USER49> Java only has single dynamic dispatch. That means it will use the method of the most specific sub-class, but will not dispatch on the runtime type of the argument, only its compile time type.

So something like:

      for(None n: expreTree.children()) {
        intMath.eval(n);
      }

will not work as expected if eval is overloaded.

</comment></comment><comment><USER50> Really great proposal. Is this conversation in relation to Java 10 or just pie in the sky?

<comment><USER51> _This is an exploratory document only and does not constitute a plan for any specific feature in any specific version of the Java Language._

I hope it does go forward, though. Really useful feature, and given the constraints of the existing language, the proposed syntax looks pretty liveable-with.

</comment></comment><comment><USER52> I honestly don't need this feature.

Am I really the only one?

Or do you all just have buckets of source code filled with if instanceof then cast just screaming for this language feature?

<comment><USER53> I have buckets of code that would be much shorter and more typesafe if it was that way at least.

</comment></comment><comment><USER54> ITT at least 3 JavaScript libraries to do this.

Also how the heck do you destructure Java objects with private fields without resorting to bean accessors?

</comment><comment><USER55> good approach taken from scala programming language. makes things simpler and shorter.

<comment><USER49> It is an old concept used in most functional languages, like ML, haskell or even Prolog via unification.

So not an invention of scala, only that is also lives on the JVM.

[http://wiki.c2.com/?PatternMatching](http://wiki.c2.com/?PatternMatching)

</comment></comment><comment><USER56> Really?! exprswitch?! Unreadable and long!

<comment><USER50> That's just a placeholder. Several times in the doc they say that the operator name needs to be explored, specifically to see if overloading 'switch' is feasible.

</comment></comment><comment><USER57> If you're interested in exploring pattern matching, I've created a Javascript/TypeScript library dedicated to it. [0]

You can see it live! [1]

[0] [https://github.com/jiaweihli/rematch](https://github.com/jiaweihli/rematch)

[1] [https://runkit.com/jiaweihli/57db70d841de7f1400d64f73](https://runkit.com/jiaweihli/57db70d841de7f1400d64f73)</comment>


Court: Homeland Security Must Disclose 'Internet Kill Switch' - <AUTHOR> http://freebeacon.com/court-homeland-security-must-disclose-internet-kill-switch/

<comment><USER2> From the article:

 _The court also found that interpreting a safety exemption to "encompass possible harm to anyone anywhere in the United States within the blast radius of a hypothetical unexploded bomb also flies in the face of repeated Supreme Court direction to read FOIA exemptions narrowly."_

Sometimes judges don't do so bad...</comment>


User engagement models – proven and emerging - syn-optic

Hello the community!
Can anyone suggest or name some of the proven or emerging models for user engagement? Or a good source to study different models for recurring usage and SaaS?
Im sure gamification is one of the key words, but is there a methodology to follow? Is there a systematic way to filter out possible models based on your desired business model or other criterias?
Cheers from San Diego, Rando <comment><AUTHOR> There's a couple I know:

1\. Engagement Pyramid: [http://www.socialmediamodels.net/social-media- overview-model...](http://www.socialmediamodels.net/social-media-overview- models-category/the-engagement-pyramid/)

2\. Hook Model: [http://www.nirandfar.com/2012/09/desire-engine- in.html](http://www.nirandfar.com/2012/09/desire-engine-in.html)

<comment> syn-optic Thanks ASquare, great video! Here is the longer version of the same presentation: [https://www.youtube.com/watch?v=qr8B3l85E5Y](https://www.youtube.com/watch?v=qr8B3l85E5Y)

Another one on this subject: [https://www.youtube.com/watch?v=YZCX- izCYMk](https://www.youtube.com/watch?v=YZCX-izCYMk)</comment></comment>


Renault will remotely lock down electric cars - <AUTHOR> https://blogs.fsfe.org/gerloff/2013/10/31/renault-will-remotely-lock-down-electric-cars/ <comment><USER3> Lengthy discussion here:

[https://news.ycombinator.com/item?id=6731894](https://news.ycombinator.com/item?id=6731894) :

        Renault ships a brickable car
        with battery DRM that you're not
        allowed to own
        (boingboing.net)

That's old enough that it's no longer possible to contribute, but there are some interesting comments there.

Other contributions of the same story:

====

[https://news.ycombinator.com/item?id=6718341](https://news.ycombinator.com/item?id=6718341) :

        Renault introduces DRM for cars
        (techdirt.com)

====

[https://news.ycombinator.com/item?id=6723522](https://news.ycombinator.com/item?id=6723522) :

        Renault introduces DRM for cars
        (techdirt.com)

====

[https://news.ycombinator.com/item?id=6729800](https://news.ycombinator.com/item?id=6729800) :

        DRM in Cars Will Drive Consumers Crazy
        (eff.org)

</comment><comment><USER4> This whole battery renting scheme is bad, that's pure greed.

<rambling> I know it's more difficult (orders of magnitude harder) than in sw but we need new startups to emerge in the automobile industry, just like Tesla. I'm french and this is one of the things I worry the most because I think we're not a country where this is possible anymore, this is a shame.

<comment><USER5> The remote disabling sounds bad, but from an economic perspective renting batteries could be good for consumers and manufacturers at the same time.

A lot of this battery stuff is very new at the moment. You look at, say, a Panasonic NCR18650 [1] and it's very affordable, but it loses 20% of its capacity after just 300 charge cycles. It depends on temprature, charge rate, depth of discharge and so on, so designers can trade off longevity for upfront cost. There are alternative battery chemistries that last longer - <USER2> manufacturers claim more than 10,000 charge cycles [2] but how do you test a manufacturer's claims that a battery will last 30 years without waiting until the technology is 30 years old? Or maybe the future is batteries getting swapped at change stations, Tesla style, so you'll end up with a different battery every day.

We consumers aren't equipped to evaluate the longevity claims of the manufacturers, so why should we take on the risk when that 30-year battery might break after 3 years? On the other hand if we pay by the month or by the mile, if it needs replacement after 3 years that's the manufacturer's problem.

In other words, renting gives the manufacturer an incentive not to cut corners, and to make sure their products are long-lasting and low maintenance, because the longer the product lasts the better the profit. Sure beats the printer ink economic model, where the manufacturers have an incentive to make cheap products that don't last long because selling more replacements means more profit.

[1] [http://industrial.panasonic.com/www- data/pdf2/ACA4000/ACA400...](http://industrial.panasonic.com/www- data/pdf2/ACA4000/ACA4000CE240.pdf) [2] [http://www.altairnano.com/wp- content/uploads/2013/01/60Ah-Da...](http://www.altairnano.com/wp- content/uploads/2013/01/60Ah-DataSheet.pdf)

<comment><USER6> But what if said manufacturer decide your car is not 'supported' anymore?

You may not even be allowed to turn to alternative battery suppliers, because it might be forbidden by contract. Their are some user protection laws in some countries (say, France), but it won't be the case everywhere.

<comment><USER7> In Australia, that's called "third line forcing" and is forbidden by law. Surely the U.S. has the same sort of laws?

<comment><USER8> From my experience, we get looked after well as consumers in Aus, and the US doesn't have near the protection we enjoy. Not sure if that's the case here, but I know it's true on the whole.

</comment></comment></comment></comment></comment><comment><USER9> How do they know they aren't stranding you and your 90 year-old grandma in the middle of the desert with no water?

How do they know they are _SAFELY_ bricking your car?

How do they know you're legally parked? That the car won't be destroyed? If the car is destroyed, will anyone continue their payments?

Is that not their problem? Do they not care? Is that what you get for being a deadbeat?

</comment><comment><USER10> >We already knew that Tesla was doing this with its cars since the company's very public spat with a journalist who reviewed one of their cars for the New York Times. Seeing the same thing in a mass market manufacturer like Renault makes clear just how dangerous this trend is.

Didn't know Tesla had a remote command to kill your car. This guy doesn't really know what he's talking about; Tesla has some kind of OnStar service going on but they have no way to physically turn your car off or have not been proven to be able to.

<comment><USER10> >bribing a Renault employee...

If that's not harder than just hacking it plain an simple...

</comment></comment><comment><USER11> Sadly this is a general trend though. In the past we used to buy things, like software. Now everything is subscription based and that sucks for consumers. Look at Billings (invoicing app) for example. It used to be reasonably priced as a download, now you have to buy a monthly subscription which ends up being much more expensive than before AND they can cut you off from your own data.

This SaaS trend is good for businesses and bad for consumers (there are advantages). It is even more evil in 'real life' as Renault is doing.

<comment><USER12> For SaaS laws that force vendors to offer the ability to export (and delete) a user's data seem inevitable in the long run though.

Given that the EU has already started on the 'right to be forgotten' issue I'd be surprised if they don't start making an issue out of this in the next couple of years.

It'll be very interesting to see what kind of effects this will have on companies like Facebook in the long term.

<comment><USER11> You are right. But even when you can export, the issue remains that a mentality is developing in which consumers have to pay a lot of money to get something that you could just purchase once in the past.

If we continue along this route we'll slowly but surely have more and more barebone devices that can't do anything on their own, but require expensive subscriptions to do, what used to be, basic things. This also takes away our rights; the Renault example is very strong, you can't drive unless you pay. I'd maybe rather pay the price for the battery and replace it when it breaks, then having to continue to pay and then be stranded 2000km from home when I forgot/couldn't pay.

</comment></comment></comment><comment><USER13> Automakers are trying hard to seize back the entitlements and perquisites they reluctantly gave up when the laws around mechanical ICE automobiles were standardized: the right to look under the hood, to maintain, to tinker, to repair, to modify, and so on. What automakers in these newer markets seem to want is something equivalent to what software corporations have: the ability not to _sell_ cars but to issue a _licence to use_ cars under strictly determined and enforced conditions.

Renault's remote lock is basically the same as Microsoft's Product Activation DRM, and even more nefarious because it applies to a physical manufactured product.

</comment><comment><USER14>
        For a long time, cars were a symbol of freedom and independence

I actually never saw cars as a symbol of freedom and independence, rather of the opposite. Both the ownership as well as the use of those vehicles is spun in so many laws that any semblance of 'freedom' and 'independence' they give is no more than imagination.

</comment><comment><USER15> It seems that with everything new technologies is going to allow in the future, we'll need a whole slew of new laws meant to stop abuses from both corporations and the government.

<comment><USER16> Why do we need new laws? Surely if people don't want this, they won't buy the cars.

<comment><USER17> * Car manufacturers: "hey saying your car is no longer supported and locking out 3rd party batteries is a great way to drive new sales."

* All car manufacturers decide to do so

* Consumer: I would like to buy a non-DRM'ed car!

* Manufacturer: If you don't like DRM cars, don't buy one with DRM! BTW, they all have DRM!

* Consumer: :(

<comment><USER16> That just means there aren't enough consumers who care about not having drm for it to be worth serving them.

</comment></comment></comment></comment><comment><USER18> TL;DR: Renault has a clause in the contract that allows them to remotely stop their EV from charging

This is an interesting issue but the article overstates the case. "... [electric cars] collect reams of data on how you use them, and send this data off to the manufacturer without your knowledge". Without your knowledge? Really?

EVs are very new technology and none of them have shown to be profitable without government support. Buyers have choices and making the trade-offs between vendors clear is always worthwhile, but this piece is not helping the debate.

<comment><USER19> " Without your knowledge? Really?"

Dunno many people who buy cars having any idea of the privacy issues of driving the nice new shiny car. Most normal people are only just realising that their entire online activity is recorded in one way or another. Cars? People don't have a clue. And why would they? Are we given data collection statements before we decide which car to buy?

I really get tired of people knowledgeable in a certain area assuming that the general population know, or should know, what they know.

No, the average punter has no idea what data their new car is sending back to base. And frankly, even as both a techie and petrol head, I don't either. I know it can happen, I know it does happen, but I have zero idea what, when or where. Sorry and all that.

(Um, seems I went off on a tangent below. Im leaving it in 'cos of the sheer effort involved.....But, you know, do stop at this point if you have a life)

What distorts public thinking even more is that a while ago politicians (UK) floated the idea that all cars should have some sort of computer fitted that can track and some how govern car use. (Safety and insurance, you understand. No, nothing to do with tracking the plebs, no, not at all. How dare the dear reader be so cynical. Shame on you!!!) On the political side, that has gone quiet. But the on the business side, its all the rage. People in general can be forgiven for thinking that because the political debate went away, so did the issue. So, no creepy tracking by government. But, the corporations are quietly implementing the strategy instead. And if government agencies want that date, one twist of the law and its all theirs.

And now as I think about it, what a clever strategy to reduce freedoms by the back door. Commerce seems to be able to do what governments could never do. In fact the genius of it is that we are happy to pay for it as a feature.

And that just cars. Look at what smartphones actually do. Not only do they track and catalog us, but we actually spend hours every single day literally filling out time sheets in the form of twitter and facebook. Imagine of a government told us to carry personal trackers and to spend a mere half hour filling out a form that told them what we did every day in even minimal detail.

All very odd to me.

Yes, I exaggerate, but hopefully to make a point.

</comment></comment><comment><USER20> Renault to customers: All your cars are belong to us!

I wonder what the customers will tell them in turn...

<comment><USER21> Renault cars have always suffered from poor quality electrics (source: my grateful local garage :-), so this will be unreliable as well. Another good reason to not buy another.

</comment></comment><comment><USER22> Anything a company _can_ control they _will_ control.

<comment><USER19> Surely we all do, unless we have specific reason for not doing so? Control the controlables, isn't that the phrase?</comment></comment>


Ask HN: What exactly *is* the definition of "toxic"? - <AUTHOR> I see the word "toxic" being used more and more in a social context, but does it have a real objective meaning, or does it simply describe things someone subjectively doesn't like? <comment><USER2> I think the reason why toxic is getting used more frequently is because it is saying "a thing I/We don't like has a viral quality".

Flamewars notoriously have that feature, like a black hole dragging in more and more participants until everybody is Hitlin-Staler.

I would <personal opinion incoming> that most modern news websites and television news channels are toxic because they make the viewers more neurotic and in a way that spreads because misery loves company.

I suspect that a ban on news would magically improve social networking. People would still talk of news but the toxicity would go way down. No exceptions, total ban.

If a nuke goes off or the zombies are coming - you'll find out somehow.

Sometimes I miss out on daylight savings time changes or something basic everybody appears to know and I'm fine with that. Some people will think this impedes some democratic process - I can't imagine what happened before 24 hr news was invented or the television, I'm sure it was a complete nightmare.

</comment><comment><USER3> "Toxic" is an _assessment_ of behavior, that covers a lot of different possible actions. The set of actions that are obviously toxic or obviously not won't be the topic of much discussion, but as we all already know interesting conversations happen at the boundaries where assessments conflict.

So, when "toxic" is used to the exclusion of actually describing what happened you have to ask yourself: why isn't the speaker communicating more clearly? Maybe they're bad at stating their point, maybe it's a loose informal conversation, or maybe they benefit from the information asymmetry.

</comment><comment><USER4> It's become a near-meaningless particle to indicate that the speaker dislikes something and wants to cast it as some great evil at the root of society's problems.

Toxic always brings forth memories of either Ninja Turtles or Swamp Thing, for me though.

</comment><comment><USER5> I think it is related to the (in)famous talk the Subversion developers held in 2008 about "Poisonous people" [https://www.youtube.com/watch?v=-F-3E8pyjFo](https://www.youtube.com/watch?v=-F-3E8pyjFo) Both terms are kind of meaningless because the allegory to toxic substances doesn't work at all. Water, salt, alcohol, DDT and lead are all toxic but in different ways. Imo, more specific terms are better like "Help Vampire," which according to some, would be a poisonous person.

</comment><comment><USER6> Something which is toxic is poisonous. In a social context, it refers to behaviors, words, actions or situations which have a similar effect on the social fabric or body politic that literal toxins do on living tissue, which encourage the spread of collectively negative or harmful behaviors.

It means exactly what it says on the tin.

<comment><USER7> The problem is not that there are not toxic ideas or words, but the term has been so (ab)used that it has lost all meaning.

It is a bit like the word fascist which used to have a specific meaning, but which has been so widely applied that it is now pretty much meaningless except as a term of abuse.

</comment></comment><comment><USER8> A reasonable definition of the current usage might be that toxic means extreme.

"This gaming community is toxic" could be read as "This gaming community is extremely obscene"

"This forum is toxic" could be read as "This forum is extremely negative"

Seems to match the usage I see anyway.

</comment><comment><USER7> While I suspect this thread is not going to last long, toxic is just another word that has lost all meaning by being applied by people to any topic they don't want to see discussed.

To answer your question toxic no longer has a real meaning outside of science and medicine.

</comment><comment><USER9> i'm not able to answer your question, but the first thing i think of when i read "toxic" on hackernews* is this:

Iseendai's "Sick systems: How to keep someone with you forever" post: [https://issendai.livejournal.com/572510.html](https://issendai.livejournal.com/572510.html)

which is about abusive and exploitative relationships / organisations / businesses / cults . probably a bit of a tangent, but perhaps a more useful one to read and think about.

* probably as a result of mentally associating hackernews ~ software jobs ~ bad software jobs ~ abusive/exploitative workplaces ~ toxic relationships ~ "toxic"

</comment><comment><USER10> in a social context I see the word toxic being used to describe behaviours that are detrimental to other members of the community, to the extent that the members of the community that do not engage in those behaviours will disassociate themselves.</comment>


What Facebook, Google Employees Really Think About Tech-Shuttle 'Hubs' - <AUTHOR> http://sfist.com/2016/07/06/heres_what_employees_of_google_appl.php <comment><USER2> > Responses From the Googleplex: . . . Many people will be incentivized to > move out of SF unless there are several hubs close [to] the current stops.

Oh no, don't move out of the City! Anything but that!

One of the chief causes of this mess is Mountain View and other cities allowing gobs of office space but hardly any additional housing.

</comment><comment><USER2> I rolled my eyes at the folks who can't walk more than five minute to their shuttle stop. But then, after I moved to the South Bay I was only 1.6 miles from my work, and during a whole year, I didn't walk it once.</comment>


GuiLite: Small, cute GUI effects you can reuse - <AUTHOR> https://github.com/idea4good/GuiLite#demo-wall <comment><USER2> If you are actually searching for tiny GUI library that can run on embedded devices and additionally supports Micropython bindings, check out [https://littlevgl.com/](https://littlevgl.com/) .

<comment><USER3> I'm also intrigued by Qt for MCU's. It looks very promising and the toolset to compliment the library is likely better than anything else for the embedded space.

[https://www.qt.io/qt-for-mcus](https://www.qt.io/qt-for-mcus)

I really wish we had open-sourced the UI framework we built for the Pebble firmware.

<comment><USER4> LittleVGL is MIT licensed.

QT is GPL and LGPLv3.

<comment><USER5> BSD vs GNU/Linux market share.

<comment><USER4> You're going to have to dumb that one down for me, if you care to explain.

My comment on the license was from an embedded perspective - if you do a bare metal product I believe adhering to *GPL becomes difficult since you have to proved the ability to update QT. Sure, there are ways to allow this but it's not straight forward.

I'm not sure why I got downvoted for my previous comment - I mean, I just posted the license types.

<comment><USER6> LGPL does not prevent you from using the library in a closed-source product, and recompile your software with a newer version of the library.

It only makes a difference if you _alter_ the library. If you plan a proprietary fork, LGPL is not for you.

<comment><USER7> Correct me if I'm wrong but all of that only applies to LGPL if you dynamically link the libraries and it doesn't apply to GPL proper at all.

When people say "embedded" they usually mean devices that run on low end bare metal hardware without an operating system (or even a memory controller!), which means nothing to provide dynamic linking, let alone the kind of end user control that the GPL philosophy is meany to promote. The vast majority of embedded software is statically linked by design so even the permissive parts of the LGPL don't apply.

<comment><USER8> No the LGPL has a clause for dealing with static linking [1]. It's more difficult to do (as the comment above us mentions).

Using static linking requires you to provide program object files which can be relinked (and re-uploaded I'd presume). This allows the user to modify the LGPL file, and then relink the original program to the updated version.

1: [https://www.gnu.org/licenses/gpl- faq.en.html](https://www.gnu.org/licenses/gpl-faq.en.html)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Did anyone notice the demo for "Animation" on the demo wall of the Git repo README? Lol and WTF

<comment><USER10> Probably a poor choice for a demo. Shouldn't be using any demo material which would cause you to pay more attention to the content than the tech.

<comment><USER11> That's just your brain on HN misery mode, where all earthly concerns bow in vague allegiance to business logic that may not even exist.

It's also wrong in principle: memorable demos remain the most culturally- significant standalone things associated with tech since the 1960s.

<comment><USER7> Those memorable demos were called things like "The Mother of all Demos" not "Cute things [...]"

<comment><USER11> Superficially 'bad' demos also work like this.

Getting people talking about your stuff because they're motivated enough to have a pineapple-on-pizza type of argument over the demo is canny and bigtechs do this deliberately.

"Did anyone notice <demo>? LOL and WTF" is why we're communicating now.

</comment></comment></comment></comment></comment><comment><USER12> I love RamTeX: [https://www.ramtex.dk/](https://www.ramtex.dk/)

Ultra minimal, designed by greybeards. No bullshit, just UI. It's amazing. If you want to build super fast, responsive and pleasure to use embedded devices, look into RamTeX library. It is not free, but its cheap. I've talked to them a few times, they're super cool people.

<comment><USER13> 404

</comment></comment><comment><USER14> Video demo:

[https://m.youtube.com/watch?v=grqXEz3bdC0](https://m.youtube.com/watch?v=grqXEz3bdC0)

</comment><comment><USER15> Anyone used [https://github.com/vurtun/nuklear](https://github.com/vurtun/nuklear) ?

<comment><USER16> I used Nuklear for a couple of project that needed a little bit of UI, it's pretty neat to add some UI to an OpenGL or similar project. It's more targeted at "game UIs" and the like tho, where the UI isn't the main component..

</comment></comment><comment><USER17> It'd be nice if you could zoom in on that Demo wall on mobile (I couldn't on Chrome on Android).

<comment><USER18> Try zooming in on something outside of the table and then scrolling to it. Worked for me with the same setup.

</comment></comment><comment><USER19> Ah, but is it pronounced Gooy-lite, or Guil-ite, like a mineral?

<comment><USER20> This time I think its the first one :)

</comment></comment><comment><USER21> Can anyone recommend a good widget layout implementation?

</comment><comment><USER22> I am guessing that the logo was generated from a website that mimics well- known logos. This is probably the best argument against using such a logo. I kept wondering why the creator wanted this to be associated with adult content.

<comment><USER23> The logo situation is basically an aftermath of a joke in the Chinese programmer circle: Somebody made a PornHub logo generator out of probably their own boredom, and others got "inspired" by it and say, "They, I can do that too with even crapper code", "They I can try out that Vue/React/[Insert whatever front-end buzz word here] on this quick 'side-project'".

After that, you end up with many of crappy logo generators posted on the Internet.

Few month later: "HELP!!! I'm building a new project and I needed a logo. But I don't know how to design one".

Then here you go.

<comment><USER24> Well as a sibling comment of yours pointed out, it's basically the original YouTube logo (used for more than a decade with slight variations) which predates PornHub. I'm sure YouTube isn't the originator either as it's not really that creative.

That some people associate the style with adult content probably says more about themselves than the style.

<comment><USER22> > That some people associate the style with adult content probably says more > about themselves than the style.

The logo is in active use and that makes it confusing. I have no interest in making moral judgments of adult content or strangers who may or may not consume it. Doing so is unproductive and off-topic.

</comment></comment></comment></comment><comment><USER25> There's quite a bit of engrish on that page. That combined with the logo doesn't really give a good first impression. That aside, it looks pretty interesting.

<comment><USER26> There's quite a few libraries by amazing Chinese developers out there with lacking English documentation, but I can at least speak for swoole and say the code is usually fantastic and worth reading through. Hell, these days I barely trust actual docs anyway</comment></comment>


California starts building high-speed rail system between LA and San Francisco - <AUTHOR> http://www.theverge.com/2015/1/5/7493159/california-high-speed-rail-system-construction-los-angeles-san-francisco

<comment><USER2> So much opposition to something other first world countries have in abundance. I guess infrastructure is communism to American right wingers, or more likely there's a very strong automobile lobby still active to block any move toward building out more rail transit. The auto and oil lobbies are historically why America has third world transportation infrastructure.</comment>


2020 YC Summer Batch - <AUTHOR> Hi guys, the batch summer of YC will be remote? <comment><USER2> Yes, I think they stated that somewhere</comment>


Commonplace Book - <AUTHOR> http://en.wikipedia.org/wiki/Commonplace_book

<comment><USER2> I had an extremely old-fashioned British English teacher in 7th grade and our biggest project was the creation of a commonplace book. I hadn't heard of it before nor since, but I still think of that project.

It seemed so random -- Page 1: recipes. Page 2: names of pet. Page 3: a family tree. And yet, it was somehow perfect. You could open any page and read something interesting. Or you could contribute some new knowledge. I feel the blogs and newsfeeds of today lack that disorganized-yet-interesting feel.

<comment><USER3> 17th century moleskine hipster diary?

</comment></comment><comment><USER4> How exactly does the commonplace book differ from a journal or ubiquitous capture? Are they simply the most interesting journals of past centuries?</comment>