The Great Theorem Prover Showdown - <AUTHOR> https://www.hillelwayne.com/post/theorem-prover-showdown/ <comment><USER2> I'm very much not at the level of accomplishing formal proofs. But isn't his challenge different than what he's trying to prove? I guess my objection is in the category of "even if formal proofs aren't easier in FP, it doesn't matter". In particular, when people talk about the advantages of FP and "correctness", they aren't literally talking about formal provability - they're more talking about a spectrum of correctness, that the purely functional approach catches moves _more_ buggy behavior from runtime to compile-time, that the functional implementation is _more_ correct, etc.

If you adopt the strict definition of "correct", then "more" correct makes no sense, of course.

I recently ported a fairly hairy lengthy algorithm from python to scala. From something with a ton of mutability, scope confusion, exceptions serving as GOTOs for business logic - into scala pure functions. The python was inscrutable with a team of people treating it gingerly. The scala is easily refactorable and each time we take another crack at it, it shrinks into smaller and smaller code (and not by using crazy Scala) and I suspect that much of the confusing hairy complexity will disappear. I don't really know how to quantify this, but I don't think it's captured from an exercise that compares difficulty in formally proving methods in IP and FP.

So yeah... it's an awesome exercise that showed a lot, and I really want to dig more into provers, but I just don't see that his "therefore" follows, that "it's (not) easier to reason about FP than imperative".

<comment><USER3> > If you adopt the strict definition of "correct", then "more" correct makes > no sense, of course.

On the other hand, it's pretty easy to widen the scope of what you're proving correct about a program in such a way as to make it impossible for Haskell to help you. For instance, "accomplish this in O(n)" or "use less than 1 MB" or "in less than 1 second." People usually only concern themselves with the aspects of the implementation that Haskell prioritizes by surfacing as return values. But there are certainly settings where the method used is as important as getting the answer mathematically correct--in fact the rise of NoSQL shows us that there are even situations where doing the wrong thing quickly is better than aborting in the face of unrecoverable errors.

<comment><USER4> Haskell can help you with "O(n)", "less than 1MB" and many other constraints of that sort.

You should use domain-specific language embedded into it for that.

If you do that that way, Haskell can help you with particular details of the implementation with types (I think that O(n) would be easy - I did parametrization on the length circa 2008) and help you to connect your implementation and the rest of program, again, with types.

I did exactly that. From well-typed parsers for stream processing hardware to (not-so-well typed for historical reasons) strict realtime algorithms.

<comment><USER3> Link?

<comment> pseudonom- Not sure what GP is thinking of, but here's an example of embedding tools for reasoning about performance in Idris: [https://www.youtube.com/watch?v=4i7KrG1Afbk&feature=youtu.be...](https://www.youtube.com/watch?v=4i7KrG1Afbk&feature=youtu.be&t=1254)

<comment><USER3> No offense, but this is like asking to see an example of someone doing OOP in C and being handed C++.

</comment></comment></comment></comment></comment></comment><comment><USER5> I loved this passage! --

"..There was zero overlap between the provers and the bulldogs. I was expecting at least some overlap: somebody who mocked me but also provided a valid solution, or even tried but failed. But that didn't happen.

I normally assume these people are "brilliant jerks": they're assholes online, but I still have to listen to them in case they say something important. This really cracked that assumption: none of the "brilliant jerks" were willing to put any skin in the game. You don't have to listen if they have nothing to say."

<comment><USER6> I came to a similar realization a few years ago. I followed a number of people who were/are widely followed in parts of the FP community that are generally caustic, but I assumed their popularity implied that they had something useful to say. I eventually unfollowed/muted/blocked many of them because I reached a point where I realized I'm not dumb, I actually do know the domain pretty well, and I'm well regarded in that community, yet I think these people are just spewing hot air (either aggressively negative, confrontational, or self- promoting). To be honest, I don't think I've missed anything of any consequence since my block/mute/unfollow-fest. It does disappoint me when I look and see that some of these toxic personalities are still widely followed and still spewing the same garbage, even though I can't see any tangible contribution that they've made.

There are many who are good at making noise and opining, and even talking about wonderful "tech" that they are working on, but most of the "brilliant jerks" ultimately produce nothing of value and contribute nothing to the ecosystem.

</comment></comment><comment><USER7> > it's all about the heap!

This. If you only use local (i.e., stack) variables, you should be able to directly transform your code into FP using a state monad. Hence I do not think there is a large difference between the two paradigms here.

Plus: Functional Code is easier to reason about. At least for the person that does the formalization. You simply need fewer constructs (and less complicated ones). The same argument holds for parallel code, btw.

<comment><USER8> Yes! Functional or imperative programming makes no difference in his challenge problems.

Tail recursive functions and loops are the same thing. Proving a loop correct using invariants and showing (partial) correctness for a tail recursive function by (functional) induction are the same thing.

</comment></comment><comment><USER9> > Fulcrum. Given a sequence of integers, returns the index i that minimizes > |sum(seq[..i]) - sum(seq[i..])|. Does this in O(n) time and O(n) memory.

This is doable in O(n) time and O(1) memory. Sum the list once. Then start from the beginning, collecting a running total and subtracting from the sum for a running difference.

</comment><comment><USER10> The concrete examples the author is looking for, where it's easier to analyze programs according to their behavior instead of their imperative structure, is Per Martin-Löf's paper _Constructive Mathematics and Computer Programming_ (DOI: 10.1016/S0049-237X(09)70189-2). For a brief and intuitive explanation, see this post by Robert Harper on the RedPRL prototype that uses cubical computational type theory [https://existentialtype.wordpress.com/2018/01/15/popl-2018-t...](https://existentialtype.wordpress.com/2018/01/15/popl-2018-tutorial/)

You can also have your legacy cake and eat it too with this excellent recent paper on gradual typing [https://arxiv.org/pdf/1802.00061v2.pdf](https://arxiv.org/pdf/1802.00061v2.pdf)

"This allows for the introduction of new typing features to legacy languages and codebases without the enormous manual effort currently necessary to migrate code from a dynamically typed language to a fully statically typed language. Gradual typing allows exploratory programming and prototyping to be done in a forgiving, dynamically typed style, while later that code can be typed to ease readability and refactoring."

</comment><comment><USER11> Great stuff. I followed the thread when he released the challenge and enjoyed reading the comments and quibbles people had along the way.

Also, strongly agree on zero overlap between bulldogs and theorem provers. Those who were assholes didn't make a single effort to contribute productively to the discussion. A good reminder that jerks (no matter how brilliant they think of themselves) can be safely ignored.

</comment><comment><USER12> One way to see there's a lot of hot air coming from the FP crowd is to look how logicians and mathematicians write pseudocode in real papers. The "working" logician/mathematician usually writes imperative pseudocode. No eyes are batted about subroutines having side effects, structures being mutable, variables being global... sometimes they even use "goto"!

</comment><comment><USER13> "I keep hearing that it's easier to analyze pure functional code than mutable imperative code. But nobody gives rigorous arguments for this and nobody provides concrete examples."

I believe the first sentence and here is my personal justification for it (maybe it can be made into rigorous argument). I base this on my experience with Haskell, and it might be that typing and control of side effects is actually essential for the claim.

In Haskell, for the most part, results of a function depend solely on its arguments. So you can treat the inner workings of function as a black box, and only worry about the "boundary" of type information of its parameters.

Now imagine you're facing a large program and you want to estimate an effort required to make a change. In functional programs, if you look at a function, you can see the scope of what the function does from its type (its parameters). In imperative programming, a function can do anything to the system under the hood, there are no natural boundaries.

It's very similar to the real world, where you can estimate for example effort in building something, like renovating an appartment, solely based on the size of the object. You know immediately that renovating a small appartment is (most likely) less effort than building a skyscraper, because of its size. In imperative programming, we're often faced with TARDIS-type deals - bigger on the inside than on the outside.

In physics, there is divergence theorem that formalizes this notion of "you don't have to look inside the object, you can only look at what happens at the boundary". Similarly, functional programming (when done right) creates the boundary at the function level, so you can then apply this type of reasoning to it.

"I chose correctness because it was the easiest to objectively verify. I'm sure that if I posed a similar challenge about refactoring code, everybody would be telling me that "being easier to reason" isn't about refactoring, it's clearly about correctness!"

I am not sure he is right there. The setting up of the boundaries in functional programs is real. Yet, with current type systems, the boundaries are not watertight. And of course, you can always write your program in imperative style with functional programming language, without an effective boundary.

I think the OP ignores the boundary setting question, because if you want a full proof of something, then you don't need to have the boundaries. But that's what ultimately helps in understanding. Maybe if he tried to prove several different statements about the code, then the boundaries would help, because he could reuse the theorems about things delineated at the boundary.

I think working with FP correctly essentially forces you to prove statements about the code (for example, this function doesn't have side effects), and then you can reuse these small statements for formally proving something else about it. Whereas in IP, you don't build these statements, you have to build them for the formal proof explicitly. The resulting proofs, written down, will have the same lengths, but in the FP case some work might have already been done.

So what OP is saying is similar to say, well, divergence theorem is really useless, because at the end of the day, you have to correctly account for all your sources and sinks. Which is true in a way, but it is a useful theorem nonetheless.

</comment><comment><USER14> You can transform purely functional programs into imperative programs trivially.

And you can transform imperative programs into purely functional programs, e.g. by using immutable arrays to represent the heap, etc. (basically, you could write a CPU emulator in Haskell, and let your program call it).

So from a theorem proving point of view, both paradigms are equivalent.

<comment><USER15> Your reasoning is faulty for two reasons. First, the transformation may not preserve the space complexity of the input (program size). So if a transformed program is exponentially bigger than the original, it is not equivalent from the prover's perspective. Second, even if the program size is preserved, the prover needs to write the proof. Finding a proof is a non-trivial problem, and there is no general mechanized way to do it. Therefore, we rely on human practice and intuition. It is therefore possible that human reasoning would work better in one formalism than another (although the avantage, if there is one, may change in favor of one formalism or the other depending on the specific problem, too). Now, I'm not saying either of these actually occurs, and it is possible the the two are more-or-less equivalent, but if so, it is not an immediate consequence of there being a transformation from one to the other.

</comment></comment><comment><USER16> The thing is that proving small functions to be correct is often quite useless. You can cover them well enough with a set of unit tests. The big challenge are larger parts of the code, like entire classes or parts of a program. These kinds of things are very hard to prove formally. Even if you did prove them formally, the spec according to which you programmed might be wrong, or the compiler might be wrong (I've seen a variety of compiler bugs, especially larger projects uncover them). Formally proving code is like making sure that every single screw of a self-driving car is tightened to an exact torque, but then the car runs over a person anyway. It's solving the wrong problem.</comment>


Overnight success - <AUTHOR> http://sethgodin.typepad.com/seths_blog/2007/04/overnight_succe.html <comment><USER2> I don't think Seth is correct that this was about politics; and, I disagree that the publishers should try again.

First, it took the publishers over a year after the original concept to actually release an issue on something as wavering as youth trends... And, the cover does not scream "youth magazine" to me. So, I don't think it was politics that doomed this venture.

Youth today can get direct one-on-one interaction with people their own age on social networking sites. NOw, compare and contrast the magazine with MTV in the 80's.

MTV made it easy to see concerts across the country and internationally. They banded the youth together. They were about music that you could hear and bands you could see.

This magazine is supposed to be about music, but youth can hear actual music in the profiles of their MySpace friends. They don't need to trust an opinion of an older editor. The magazine cannot play music. It's a pain to flip through magazines if you're left-handed.

Do you really need a magazine to tell you, even if it's an accurate report, about the type of music people are listening to, when you can go and see what your friends are into, or see the top downloaded tracks in iTunes, and that's all that matters, really?

<comment><USER3> Vlad, I disagree with your comment about iTunes. People want choice these days (long tail economy). Thats why people get their information on the Internet.

I think magazines still have value. People need something to read in bed, on the bus and on the toilet. Until I have an iPhone that I can do this with, I will read magazines.

I think magazines are on the way out, but they still have value for now...

</comment></comment><comment><USER3> Is one week really long enough to judge if its going to be successful or not. I don't think so...

<comment><AUTHOR> Exactly my thought.

</comment></comment><comment><USER4> So much for market research. Didn't someone here say release early, test, and improve? There goes a handful of millions.</comment>


The First Ad Network For Instagram - <AUTHOR> http://instagridnetwork.com

<comment><AUTHOR> "We hate ads, and our last goal is to spam Instagram and destroy the fun and authenticity of the network for everyone. We want to push bold new ideas and develop inspiring and tasteful ways for companies to interact with their audience. "

</comment><comment><USER2> that's what all ad networks say. you want to monetize something that you didn't even create. create a new concept for app integration (or a new app entirely) because ad networks aren't innovative...

</comment><comment><USER3> brilliant idea. completely open platform for instagrid. plus it comes from the folks at sps and they have never put out a less than perfect product!</comment>


Economist.com slipping behind the paywall - <AUTHOR>

There's no permalink, but this just showed up in my inbox:
Dear Reader,
I'd like to inform you about important changes at Economist.com.
Beginning October 13th, we will be limiting access to certain sections of our site to subscribers only. Over the past few years, Economist.com has become a hub for intelligent discussion, with news commentary, blogs and an award-winning debate series. We will continue to encourage both subscribers and non-subscribers to participate in those conversations. We will also enhance the experience we offer our most loyal readers by expanding our subscribers-only features.
Currently, all content published within the last year is free of charge. Soon, only articles and commentary published prior to the last 90 days will be accessible without a subscription. The print edition contents page, which offers a convenient way to browse articles and features from the latest issue of The Economist, will also be limited to subscribers only.
Through these complementary aspects of Economist.com, we will continue to foster intelligent discussion and debate, while enhancing the value we bring to our community of subscribers.
I hope you'll continue to visit the site and enjoy all it has to offer.
Sincerely,
Ben Edwards, Publisher Economist.com <comment><AUTHOR> This is at least interesting; articles from the last 90 days are for-pay, but once that window closes, it will be available for free.

How long until there's a reverse auction or minimum clearing level for articles? It seems the future of publishing news should be: pay for immediate access, as soon as the value (utility) drops to zero, make it free. "Free after 90 days or the first 10,000 subscribers see it"

</comment><comment><USER2> Can you blame them? They offer extremely insightful analysis and great discussion; I think my print+web subscription is very much worth it.

At least give them credit for not completely closing up or charging for old material. They do honestly seem that they are trying to keep as much content available as possible.</comment>


A shell command to create JSON: jo - <AUTHOR> http://jpmens.net/2016/03/05/a-shell-command-to-create-json-jo/ <comment><USER2> Plenty of work to get result worse than a oneliner _perl -MJSON -e '...'_</comment>


Everything about Java 8 - <AUTHOR> http://www.techempower.com/blog/2013/03/26/everything-about-java-8/ <comment><USER2> I'm excited by Java 8 moreso than at least several of the previous versions. Java 7 was especially underwhelming.

The lambdas are the new hotness that everyone is aware of. But the work done on streams is almost equally impressive.

There are several other small additions and reductions in pain that, when taken as a whole, make this update significant. For example, we finally will have a native JodaTime-like replacement for Calendar, Date, and the supporting utilities. I've long considered the need to enforce external thread safety on DateFormatters to be one of the silliest design failures in Java.

Disclosure: this summary was written by a colleague of mine.

<comment><USER3> I am hacking a while now with java 8 and can say that one of the most appreciated features in my stack are lambdas. as soon as you are used to them (had the first introduction to lambda-style programming with Blocks in ObjC) you miss them so badly when they are not there (C for example).

</comment></comment><comment><USER4> As a C# developer now experimenting with Java, I still miss some things even from Java 8. Probably some have technical reasons behind, but...

\- Getters and setters, C# style. That is, instead of

        private int foo;
        public int getFoo() { return foo; }
        public void setFoo(int value) { foo = value; }

write this:

       public int Foo { get; set; }

which is both easier to write and makes code more readable and understandable.

\- Mandatory exception declarations in methods. I still don't understand why this is necessary. It ends up either leading to stupid errors (see the following example from the article)

        void appendAll(Iterable<String> values, Appendable out)
                throws IOException { // doesn't help with the error
            values.forEach(s -> {
                out.append(s); // error: can't throw IOException here
                           // Consumer.accept(T) doesn't allow it
            });
        }

, or to lots of methods just throwing Exception (bad practice, I know, but it's easy to fall in), or to useless empty try-catch on methods that won't throw an exception (because you've checked it) and don't want to add the throw declaration.

\- Modifying external variables in a lambda expression. Just as everyone is used to in Javascript, Ruby, C#... It's pretty useful, even more when you're using lamdbas for common operations such as _forEach_.

\- Operator overloading. When you're using data classes (for example, models from a database) where different instances actually point to the same object, overriding == it's more comfortable than _foo.equals(bar)_. Also, the downside of using _.equals_ is that, if _foo_ is null, you will end up with a nice NullPointerException out of nowhere.

\- Events! I'm amazed how easy is to do events in C# versus how hard (and bloated) in Java. Take this as an example: [http://scatteredcode.wordpress.com/2011/11/24/from-c-to- java...](http://scatteredcode.wordpress.com/2011/11/24/from-c-to-java-events/)

\- Pass by reference. Just as if you were passing a pointer in C. I find it surprising how few languages implement this feature, which is pretty useful...

And I'm sure I'm missing something...

Edit: added three bullet points.

<comment><USER5> I don't think there are technical reasons behind, but rather philosophical ones.

\- Getters and setters are bad design. In clean object-oriented code, the internal state of a class is not exposed to the outside. Thus, getters and setters should not be encouraged.

\- Exceptions: yes, it would be nice to be able to throw checked exceptions in that example. But the rule that they need to be declared is one of the basic design decisions Java has taken with the intention of always forcing the programmer to handle them. It won't change. (You can still fall back to unchecked exceptions if necessary.)

\- Modifying external variables: can be done with a work-around, e.g. "final int[] x" to have a modifiable int. Not sure why that is the case though.

\- Operator overloading: considered bad practice for high-reliability code. Generally, Java favors explicit statements in order to prevent mistakes.

\- Events: some of the listener stuff in the example could be moved to a library, making it smaller. But still a missing feature in Java.

\- Pass by reference: this is normally used as a workaround to create methods with multiple return values. In Java, one could again use the wrapping-array- workaround instead as in the external variables point. I'd love to be have methods with multiple return values in Java.

<comment><USER6> _Operator overloading: considered bad practice for high-reliability code. Generally, Java favors explicit statements in order to prevent mistakes._

Considered by whom?

The example gjulianm gave, where == is safe if nulls are flying around but calling .equals() on a null expression results in an exception, seems a clear counterexample.

I'd also argue that if your code is mathematical in nature, it is both quicker and more reliable to write, review, and maintain concise, mathematically natural syntax like a+b*c than verbose alternatives like a.add(b.multiply(c)).

<comment><USER7> Considered by people who have used C++ and seen some awful problems creep in because of unnecessary operator overloading.

Your last point actually highlights the problem - it is _not_ more reliable because you are assuming what "+" and "*" do.

EDIT: An old blog post about the issue: [http://cafe.elharo.com/programming/operator-overloading- cons...](http://cafe.elharo.com/programming/operator-overloading-considered- harmful/)

<comment><USER6> _Your last point actually highlights the problem - it is not more reliable because you are assuming what "+" and "_ " do.*

How is that any different to assuming what add() and multiply() do?

In many ways, I'd say the latter is worse, because it's not immediately obvious from just the function names whether the operation mutates the object it's called on or returns a new object with the result while the originals remain unchanged. Both behaviours can be useful. Both are widely used in libraries, with those exact function names. You just have to read the documentation and learn how each library you use works, which is particularly... entertaining... if your project uses multiple libraries and they don't all follow the same convention.

For + and * operators, someone already decided what the convention should be. If you just make them work like the built-in versions, the semantics are already intuitive to anyone who studied basic arithmetic at school.

Edit: I did take a look at the article you cited. It appears to be an elaborate troll, actually consisting of little more than a set of unlikely examples (I wouldn't write a function called divide() to "divide" two matrices, so why would I suddenly feel the urge to write a / operator?), a set of assertions without proof (some of which are just begging the question), and a final _ad hominem_ that conveniently discards one of the most obvious demonstrations that operator overloading can be useful on the basis that anyone making that argument just doesn't understand (and ignores counterexamples like OCaml, where basic arithmetic operators really are different for basic numerical types, which is a significant pain point in the language).

<comment><USER7> > For + and * operators, someone already decided what the convention should > be. If you just make them work like the built-in versions, the semantics are > already intuitive to anyone who studied basic arithmetic at school.

I think it's exactly this that is misleading - your intuition may not be the same as developers. I think people assume more from "+" than they would from "plus()" and if you don't think about it you may falsely assume you are using a language built-in.

I'm not saying that operator overloading can't be useful, but in C++ developers did create horrible code by using /, *, + in their classes to 1) show off that they could and 2) to save typing. If they had to name their methods, I hope there is a good chance they would have done better than divide(), multiply() etc.

Regarding the article, I agree it is somewhat guilty of hyperbole, but I don't think calling it a troll is remotely fair.

BTW I don't understand what you mean by "can be useful on the basis that anyone making that argument just doesn't understand", which makes me feel like I've wandered into a double joke ;)

<comment><USER6> Fair enough, perhaps calling the article a troll was a little harsh, as I don't know how the author intended to come across. However, the article did seem to consist of one weak argument after another: an unlikely strawman problem here, a blatant exaggeration there, a quick logical fallacy to tie them all together. I'm afraid I didn't find it a convincing case at all.

BTW, I meant my final comment to be parsed as (conveniently discards one of the most obvious demonstrations that operator overloading can be useful) (on the basis that anyone making that argument just doesn't understand). The author didn't actually explain _why_ that case was "completely different" or _what_ someone who proposed that example didn't understand so that "their opinions can be discounted".

In fact, I would suggest that his entire case about built-in operators being unambiguous even though they support multiple types can be annihilated using only the equality operator and the words "floating point": in C, you still can't tell whether the expression a==b is reasonable or almost certainly a bug without knowing the types of a and b, which AFAICS is _exactly_ analogous to the problem the author is so keen to attack with operator overloading.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Woah, that streaming abstraction looks really slick, especially given that it can be automatically parallelized.

The idea of doing a one-line parallel map-reduce that is

        collection.stream().parallel().map(operation1).reduce(operation2);

is surprisingly cool imo. And the availability of streams across the collections framework allows that they can be used in routine programming.

<comment><USER9> Yep, Java 8 starts to look a lot like Scala

<comment><USER10> It looks like C# 3 (2007)

<comment><USER11> Many C# features look a lot like Scala features (2003/4)

</comment></comment></comment></comment><comment><USER12> Massive issue here for many when it comes to Java 8 - what about Android ?

Android's dalvik is based off of Apache Harmony, which doesn't appear to be updating anymore. Does this mean no Java 8 for Android/Dalvik? Seems like it would be a major issue if so.

<comment><USER13> Google is yet to even add support for the Java 7 language constructs.

</comment></comment><comment> j-m-o As a daytime Java developer who dabbles in Scala on the side, these changes look great. The inclusion of a Joda Time style time library is long overdue as well.

I just wonder how many years before there's adoption from the general Java community.

<comment><USER11> As a daytime Scala developer who seldom uses Java anymore these changes are nice, but a far cry from what I get in Scala.

<comment><USER14> The Scala compiler takes so long in comparison to javac though

<comment><USER11> Javac also takes longer than Turbo Pascal to compile...

</comment></comment></comment></comment><comment><USER15> Java 8 looks good enough to make Java a reasonable candidate for Java.Next. Especially given that there doesn't appear to be a clear winner between the alternatives (Scala, Groovy, Clojure, Kotlin etc.).

Java 8 seems to have borrowed a lot from Guava (Optional, Function, Predicate, Supplier etc.).

Extension methods as well as default methods on interfaces would have been nice.

<comment><USER16> Mixins would be great too.

<comment><USER17> Default methods in interfaces makes them mixins.

</comment></comment></comment><comment><USER18> These changes are the first since Java5 to make a real difference to how I will program, and thus are pretty nice to see.

The sad thing is that a large part of my Java programming will involve Android, and thus I will continue living in Java5/6 land, as will numerous libraries and large parts of the Java ecosystem.

I wonder when Google will address the future of Java on Android in a substantial way? Eventually it will not be tenable to stay on a 10 year old version of a language. I hope they will seriously consider either updating their supported syntax to be compatible with Java8 or introducing some other language into the Android SDK (Go go!).

<comment><USER19> I remember some years ago when I was glad Java 5 had got some really practical new features. I didn't program in Java back then, but I wanted the language to evolve (maybe I was going to need it in the future).

Now I do program in Java 5/6 and it would be really sad if the language was still stuck in the 1.4 days.

</comment></comment><comment><USER20> The lambda and stream additions are great and long overdue, but I've pretty much adapted to using Guava to fill that gap.

So right now the thing I'm most interested in is actually the promise of better type inference. Anyone who has used a rich, type safe DSL like Hamcrest or Guava knows the pain of having to give so many type hints to the compiler, when the context provides all that the compiler should need.

</comment><comment><USER21> The inclusion of lambdas is great, but not supporting full closures severely hampers their usefulness. Instead of using lambdas to use patterns like CPS (continuation passing style) or alternative object interfaces, lambdas just save you from typing extra characters.

It is always fun to watch other languages continue to implement features that bring them closer to lisp. I wonder how much longer it will be until every language is just a lisp dialect.

They are moving in the right direction but very slowly. It is impressive though that they have been able to still innovate without breaking backwards compatibility.

<comment><USER22> > It is impressive though that they have been able to still innovate without > breaking backwards compatibility.

Indeed. The .NET IL compiler actually supports closures by generating a class with the lambda's method body as method on that class. That method takes in as parameters whatever outside variables need to be captured.

It also supports iterator continuations (e.g. "yield return") by generating an entire class which inherits off of IEnumerable and wraps your single function with all the necessary trappings to track the continuation state.

You can see this stuff by looking at C# assemblies in a free program called ILSpy[0]. Normally it'll reverse-engineer these compiler patterns, but if you uncheck all the "decompile" checkboxes in the options, it'll just straight-up translate the IL to C# and you can see the dirty tricks.

[0] <http://ilspy.net/>

<comment><USER21> C# is quite impressive, especially in comparison to Java. If it had been released earlier, wasn't owned solely by Microsoft, and supported all major platforms equally, it could have been huge, even larger than Java. If C# had reversed roles with Java a significant portion of the world would have been more productive.

<comment><USER11> C# 1.0 was very close to being an exact copy of Java. To say that if C# had been released before Java it would have been more popular is nonsensical as it started life as copy-cat Java. Without Java there wouldn't be a C#. Later versions of C# added more features much faster than Java. Many Java developers have since moved on to Scala and other JVM languages which are more expressive than C#.

</comment></comment></comment></comment><comment><USER23> Can someone please show the java guys the <Number>.TryParse(String s) from C#?

I'm convinced everytime I have to manually write the try catch clause for parse a kitten dies somewhere!

<comment><USER24> TryParse uses an out parameter. Java doesn't have that. AFAIK, the JVM has no way to represent pointers in any such fashion.

It's sort of ironic that the JVM, with it's limited Java-only bytecode has attracted so many languages, while the CLR, which is designed to handle multiple languages in an efficient manner, has relatively few.

<comment><USER25> I started to reply that Microsoft could fix that by providing high-performance CLR implementations on all the platforms the JVM runs on.

But it occurred to me that even if they did so, a lot of people wouldn't trust them to continue to support the other platforms indefinitely. The only way around that would be for them to spin off the entire .NET division.

Microsoft being Microsoft, of course, they would never do any of this.

</comment></comment></comment><comment><USER26> This looks very thorough. I appreciate the detailed coverage of lambdas as well-- this is already helping my understanding.

</comment><comment><USER27> I recently started developing in Java and the thing I find most irritating is the lack of operators overload.

<comment><USER28> Why? Sure, overloading a "+" operator can be elegant looking. But the aesthetic gain vs. maintainability doesn't seem to be worth the tradeoff 99% of the time. I certainly wouldn't want to be the one who has to debug the thing because someone accidentally side effected one of the "operands".

<comment><USER29> Nonsense. To paraphrase myself from a similar discussion on reddit:

"List.add(otherList) <\-- what does this do? Why, compared to operators, would a function name be any better than an operator? Mathematics are part of computer science, and denying basic operators for a reason like "because someone might misuse them" is like denying functions because someone may implement a sum() and call it lcm() (and then we're back to goto land). You're confusing a programmer's error (bad choice of a name/operator function) with a language feature. Just because people can write bad code it does not mean we should disallow them to write great code."

Honestly, it's about time the Java crowd stops with the mantra and starts thinking from themselves. Or at least, learn why the reason you hate operator overloading is fallacious.

<comment><USER30> It just seems an odd hill to die on. Just a minor little feature that most people would use only occasionally in their objects.

<comment><USER31> > Just a minor little feature that most people would use only occasionally in > their objects.

Yeah until you have to work with java's Bignums one day, then you start wanting to choke people to death.

<comment><USER19> Yeah, I guess it sucks if you work with Bignums. I would be happy if BigInteger and BigDecimal were promoted String-level language support: still implemented as classes, but with compiler support. They could add indexing [] for collections, but I can live with .get() and .put().

Some people seem to think that if they don't use, then it doesn't matter. In many business applications, you don't even need floating point (you just transfer data to the database and back), anyway.

Are floats and doubles "little features"?

In computer graphics, you need lots of floating point calculations. Are ints and longs "little features"?

In embedded software, you usually don't want to use resizable strings (C doesn't even have this feature built-in), because reallocations are expensive or unavailable. Are resizable strings (or containers) "little features"?

Different programs have different needs. If you haven't stumbled upon a good use case, doesn't mean that it's useless.

<comment><USER30> This same logic can be used to defend any "little feature". Language design is all about where you draw those lines.

<comment><USER19> That logic is just a starting point (just to avoid the "I don't need it, why can't you be just like me?"), not the whole thing.

Then you have to take into account a few other criteria, such as [1] internal coherence in the language, [2] difficulty in implementation (and explaining to others) [3] what your target audience is, and what they want, [4] what competitors are doing.

I think full operator overloading would hurt [2], but special-casing Bignums would not hurt [1], [2] at all (as I said, JSP EL already have +,-,*,/, etc. , String already have +, +=).

[3] This is what this thread is all about, no need to repeat :-D

And [4]... Well in this case Java is really playing catch up.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER32> Streams, lambdas and the new time API are wonderful additions to Java.

</comment><comment><USER33> Java 7 failed to excite me. Java 8 however, has many features that I can use today. Lot's of stuff from guava, cleaner anonymous classes (lamdas), trait- like interfaces, FluentIterable++ (streams)... it's a good time to be a java developer.

</comment><comment><USER34> Unless I am mistaking, Java 8 fails to address the major pain-point I have with Java: hash and array literals.

For me, one of the big wins of both Clojure and Scala is being able to handle maps, sequences, etc. conveniently.

<comment><USER35> Really? new double[] { 1.0, 2.0 }? Arrays.asList("foo", "bar")? Guava's Map builders?

Lambdas are what make operations on data structures convenient in Scala and Clojure, not saving a few characters on the handful of literals in your code.

</comment></comment><comment><USER36> I am not sure I am super excited about Java the language increasing in size. As in, the size of the body of knowledge that need to be committed to one's head to comprehend and write the code.

I am actually quite opposed to the syntax sugar features like "getters/setters from C#", "events" and what not. Java the language is already large enough. IDEs do a decent job dealing with boilerplate code. Please, no new kludgy additions to the language.

Those people that need functional features could use Scala now. Jython is there for those not liking static typing.

Why don't we just leave Java alone?

</comment><comment><USER37> The only thing I wish made it in for 8 was coroutines(MLVM project).

<comment><USER38> I'm definitely pushing for this to be added ASAP — probably won't be before 10 though. In the meantime, it would be awesome if they could get it into OpenJDK behind a flag...

<comment><USER39> There's no real work being done on this at the moment (I was involved with trying to kick start a small team with the original patch authors). We've started discussing it again, but it's looking like a case of "Real Life" getting in the way :-|. Will see if I can get the broader Adopt OpenJDK programme to take it on board.

</comment></comment></comment><comment><USER40> Incomplete lambda forms? Facepalm.

<comment><USER35> Incomplete how exactly?

</comment></comment><comment><USER41> I find Nashorn particularly interesting, as well as Node.jar: [http://insin- notes.readthedocs.org/en/latest/JavaOne2012/nas...](http://insin- notes.readthedocs.org/en/latest/JavaOne2012/nashorn_node_jpa_persistence_bof.html#node- jar-akhil-arora)

Hopefully Nashorn will give <http://ringojs.org> a boost as well.

</comment><comment><USER42> One small correction/addition: For Stream.anyMatch(), Stream.findFirst() and Stream.findAny() it is mentioned that these are short-circuiting operations. This is however also true for Stream.allMatch() and Stream.noneMatch().

<comment><AUTHOR> You're right! Thanks, I'll get that fixed up in the next batch of edits.

</comment></comment><comment><USER43> >Non-final variable capture - If a variable is assigned a new value, it can't be used within a lambda. This code does not compile:

So, it sounds like that mean no closures? That's one of my favorite tools in c#.

<comment><USER35> Everyone gets confused by this it seems. You can mutate fields in the enclosing class. You can read locals. If you really want to, you can box a local, and then mutate it inside the box. You can't mutate locals directly, because that would make lambdas significantly slower for very little benefit.

(You would not be able to do stack allocation of locals in frames that contain lambdas (unless you could prove that the lambda does not escape).)

</comment></comment><comment><USER44> Language and api wise these are nice additions, but all I can think about these days is emscripten. The JVM should support the client side out of the box, why oh why didn't Google buy Java?

<comment><USER26> I'm not sure what you mean exactly, but as mentioned in the article they've built a new JavaScript engine (to replace Rhino) to be included in Java8: <http://openjdk.java.net/jeps/174>

<comment><USER44> Just that an entire revolution is happening in the browser itself, I'd really like to be able to code Java directly with something GWT. I read recently that GWT has support for the latest html5 stuff, but complaints about compile time and lack of performance after compilation turn me off...

<comment><USER45> You should give GWT a go. Compile time is a valid complaint, though it can be mitigated by only producing a single permutation (browser specific output) while in development, rather than the default five-six. Also note that during development you usually don't compile but run in "dev mode", a browser plugin that runs against your actual Java code.

Performance after compilation is certainly not a problem, on the contrary the GWT output is very tight, especially with full obfuscation (aggressive optimizations, inlining etc.).

(I've written a complete HTML5 game engine in GWT: <http://www.webworks.dk/enginetest>)

<comment><USER46> Another valid complaint is that dev mode runs quite slow, particularly if you're developing something like a game. I read an article about how they are addressing this so that dev mode runs almost as fast as the compiled result, but can't find the link now. Maybe it's already live? Been half a year since I've used GWT.

But I second the recommendation overall. One thing I learned the hard way though, is that their widget library is pretty constraining, and a very leaky abstraction. I would consistently run up against walls using a particular widget, bang my head against it for a day or two, then scrap everything and roll my own solution. Eventually, I just used GWT to compile the core business logic of my app (which would have been a nightmare to do in JS), and did UI with the standard HTML/CSS/JS flow. Doing UI in Java is too clunky for me no matter what library I'm using though, so YMMV.

<comment><USER47> > Doing UI in Java is too clunky for me no matter what library I'm using > though, so YMMV.

For sure. C#, Java, C++ are all clunky. Maybe it's the nature of the ecosystem.

This is one thing I hate about GWT: it offers tons of upside (sprites, bundles, i18n, unit-test in JUnit IF using MVP) but the downside is in the area of big-consideration of pain point.

<comment><USER45> With GWT it is possible to pretty much build your UI in HTML and simply inject key components, with event handlers etc., into the DOM structure. You would use an HTMLPanel and add(Widget widget, String id). Few people seem to be aware of this.

I used this approach to build TeamPostgreSQL (demo at <http://teampostgresql.herokuapp.com/>), where the designer built the entire interface in HTML and I just inject GWT widgets in the right places.

</comment></comment></comment></comment></comment></comment></comment><comment><USER48> With the ability to add static methods and default implementations to an interface, what is now the _practical_ difference between that and an abstract class?

<comment><USER49> \- A class can only inherit from one abstract class, but can implement multiple interfaces.

\- An interface cannot have member variables.

<comment><USER50> Also, an abstract class can have a constructor (and instance initializers, and initialization expressions for its fields), which an interface can't. That means an abstract class can do work when it is created.

Although it's probably a good idea not to do too much work - a factory method would be better for that.

</comment></comment></comment><comment><USER51> Very interesting read. So, nothing new on the Swing side?

<comment><USER52> I can't tell if you are serious or not. Swing is dead, from my point of view. In any case, desktop programs isn't really a strength of Java.

<comment><USER17> Actually that is a case where Java really shines, as it is cross-platform

</comment></comment></comment><comment><USER53> _"Interfaces can now define static methods. "_

Twenty years for that one ; )

zomg. Another one debated at length through flamewars on Usenet and ##java. And now it's here. Feeling good : )

<comment><USER54> The number of times I've implemented something by convention due to the lack of this construct... One common use case is that I like "value objects" -- an AccountId class vs. just a String or an Integer. I usually implement them using some sort of internment internally -- WeakHashmap, Guava Interner, etc. When reading from a wire format and using value objects, one must presume the existence of a fromString(String key), fromInt, etc. method. I'd love to state explicitly that all ValueObjects have particular, generic-ified static constructors. Much cleaner. And, it avoids the cliche Java programmer shame of implementing AbstractValueObjectFactory, etc. Some static state, if isolated and properly managed, makes life easier.</comment></comment>


Ask HN: What is the best way to find a good developer for a startup - <AUTHOR>

I am trying to find a good web developer to join my startup as a CTO, which is the best way to find one? <comment><USER2> I saw a targeted facebook ad once that linked to a video of a guy pitching his company looking for a CTO. I clicked but I can't remember what the pitch was about and I didn't contact him. I liked the idea though.

My best advice is to explore your personal networks. When I'm looking for a collaborator that's my best bet.

Another thing to think about is that if you can't convince someone to build your idea then you may need to spend more time iterating on it or gathering data. Preorders from potential customers are the strongest data. If this is for a social network where you need users to make it valuable, you could get people to sign up for an email list.

</comment><comment><USER3> interview them! Before that, first, don't get a friend, but use your network to locate potential candidates. Then find someone a) close enough geographically (because relocation or worse, work visa, is hard). b) "compatible" with your way of working and thinking strategicallly. c) make sure he/she has the pragmatism needed to do a startup (at least he/she should have read Lean Startup). Worse is better. Whatever works. Do things that do not scale. d) make sure you are managing budget the same way. e) make him/her interview you too

<comment><USER4> "make him interview you too"

... or perhaps "her"

<comment><USER3> parent corrected

</comment></comment></comment><comment><USER5> There are likely events in your area where you can meet potential co-founders. Don't commit too early. My biz guy found me (tech) but we went on several "dates" over a few months.</comment>


Ask HN: How do you buy foreign domain names without an address? - <AUTHOR>

1) I would like to buy a foreign domain name, but an address in the host country is required. How do you get around this?
I know some missionaries in this country, but I don't want to get caught up in some legal misunderstanding and risk losing the domain.
2) Also, how much risk is involved in using a foreign domain? <comment><USER2> I've used <http://www.europeregistry.com/> to register foreign domain names in the past. Much like anonymous/private registration in the US, the registrar uses one of their addresses to create the record.

</comment><comment><USER3> Chances are they won't really check the address. Why not just put a fake one?

You could also look for a mail forwarding service in the jurisdiction.

Giving you a proper answer requires that we know more details– are you expecting that somebody will want to take this site down? Or is it a potentially valuable domain?

Another solution is registering under a local's name and address, and have a contractual arrangement with them limiting their rights.

You could also set up a corporation, and run the domain with the corporation. It all depends how safe you want to be.

</comment><comment><USER4> Go to something like <http://www.101domain.com> (or any of the other foreign url providers) and see if they can get it for you.

If they can't, then its not worth trying to get around the system. Just pick a different name and stop trying to be too creative with your domain name.

</comment><comment><USER5> <http://www.eurodns.com> has a solid selection of international domains and provides local addresses/affiliates to enable registration in certain countries. It's a bit expensive for some domains. But they've got a good selection and have been reliable.</comment>


How to Permanently Delete Data from Your Hard Drive - <AUTHOR> http://www.readwriteweb.com/archives/how_to_permanently_delete_data.php <comment><USER2> Recovering overwritten data from a modern hard drive is impossible. Even Peter Gutmann himself admits that in the paper that everybody cites but nobody reads.

Fill your disk with zeros (just once) and you're good to go.</comment>


Kiwi – a 68k Homebrew Computer - <AUTHOR> http://www.ist-schlau.de/ <comment><USER2> It appears that the page won't load.

Here is the most recent snapshot from the IA Wayback Machine.

[https://web.archive.org/web/20161028130628/https://www.ist-s...](https://web.archive.org/web/20161028130628/https://www.ist- schlau.de/)

</comment><comment><USER3> I wish there were kit-orderable computers of this fashion. I'd like to get my hands on something like this with a Z80 or maybe even a J11 so I can play Bell Labs in my spare time.

<comment><USER4> I always wanted to make my own processor out of ICs however I was informed this would be extremely slow in the end, so I never started making it. But it seemed fun at the time to make a 16-bit computer up from logic gates.

<comment><USER5> I still plan to make some FPGA's at some point. More likely, convince some CompSci people with high-end tools to build and FOSS the key components. Archipelago FPGA at 45-65nm was a start. I think even obsolete version at 28-45nm could have plenty of logic, memory, and speed for lots of hobbyist hardware.

</comment></comment></comment><comment><USER6> > Video Yamaha V9990 Video Display Processor

Aren't these somewhat rare? I don't think they were used in much besides a handful of late MSX add-on video cards.

<comment><USER7> Not to mention the two (!) SIDs for audio output. The only way to obtain those nowadays is to cannibalize Commodore 64s.</comment></comment>


Is Chrome OS Really "Careless"? Maybe If You're a Criminal - <AUTHOR> http://www.thechromesource.com/is-chrome-os-really-careless-maybe-if-youre-a-criminal/ <comment><USER2> Shorter Chromesource: "Honest people have nothing to fear from the police." Also, the cheque is in the mail.</comment>


Default Methods in Java 8 - <AUTHOR> http://webcache.googleusercontent.com/search?q=cache:http://blog.codefx.org/jdk/everything-about-default-methods/

<comment><USER2> Does this page look like crap on anyone else's browser? I'm on Firefox 34.

Edit: The non-cached version at [http://blog.codefx.org/jdk/everything-about- default-methods/](http://blog.codefx.org/jdk/everything-about-default- methods/) is much better.</comment>


Show HN: Readup, a social reading platform. Like HN but you must read to comment - <AUTHOR> https://readup.com/ <comment><USER2> Readup co-founder and sole developer here. Happy to answer any and all questions (especially technical ones!).

We recently completely overhauled the browser extension to use active tab instead of broad host permissions in order to be more privacy friendly. During the rewrite we also made the extension compatible with Firefox which was a big request from users.

</comment><comment><AUTHOR> Hiya folks. Bill here, CEO/co-founder of Readup. My co-founder and I are both going to be hanging around here all day today and we'd love to answer your questions and hear your feedback.

Also, we recently applied to YC (corona batch?) so let's get this conversation going. ;P</comment>


Gen Z Is Leading a New Wave of Internet Piracy - <AUTHOR> https://www.vice.com/en_us/article/884db5/gen-z-piracy-streaming-wars-disney-netflix <comment><USER2> Pretty scary how nobody bothers actually downloading the files even when they're illegally watching it. I thought the idea was to get away from the cloud based nightmares that are currently the norm...</comment>


Libraries suck - <AUTHOR> http://akkartik.name/blog/libraries

<comment><AUTHOR> The discussion of programming libraries vs. services is pretty interesting.</comment>


Ask HN: Where should I invest extra cash? - <AUTHOR> The stock market is high, i am not living in my current city (Boston) for more than 4 years, and I have extra cash. Where should I invest my money if im not going to need it for the next 4 yrs at least? <comment><USER2> Depends on how much we are talking about and what you want it to do for you, how active you want to be and your risk profile.

If you want a passive investment and lower risk, pick a mutual or possible index funds to toss the cash into. These are also nice cause you could easily add to your holdings each month and make a little money. But just expect that the risk profile being low means returns will mirror that, but the advantage is the money will grow and be pretty damn safe for when you want it.

If you want a little more active investment but still low to moderate risk (IMO), you could go with ETF's and even the purchasing of individual stocks of larger slower moving organizations that have stable returns. You won't make large returns this way, but it is risk balancing. The risk (or reward of higher returns) comes in which ETF or stock you decide to invest in, which also comes with how much time you want to devote to it. If you have a lump sum of cash, say 100k or more, you could easily turn this over to a manager and let them deal with it for you. Anything less then $50-$100k and the fees will eat into the profits too much likely, but you'd have to talk to specific managers to find out.

Lastly, while people are scared of real estate because of the crash, real estate is still the single largest method most people in this country use to gain wealth. Whether through rentals or fixing houses or through investing in others flips/rentals. You can make really good returns and get your money secured by real property. Depending on your risk/reward ratio this can have as wild as swings as the stock market, but the upside is generally better for most average consumers. Personally, this is where I place my money more and more. But in contrast, my parents are of the mindset that stocks are safe and real estate is risky (they have always felt this way), so everyone has their personal thing.

</comment><comment><USER3> Silver and gold

</comment><comment><USER4> Index funds.</comment>