What property of multiplication allows this technique? [video] - <AUTHOR> https://digg.com/video/math-whiz-explains-how-russians-do-multiplication-and-it-might-change-the-way-you-calculate-things <comment><USER2> Are you genuinely asking? Or is that your title for the video?

In case you are genuinely asking, here's a link[0] to a post I wrote a while ago proving that it works, and generalising to powers of numbers (critical for cryptography) and powers of matrices.

I've submitted it as a separate post[1].

[0] [http://www.solipsys.co.uk/new/RussianPeasantMultiplication.h...](http://www.solipsys.co.uk/new/RussianPeasantMultiplication.html?tb07hn)

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

<comment><AUTHOR> Thank you. It seems that it isn't really a property of multiplication per se but simply an algorithm for solving multiplication equations.

<comment><USER2> I don't really know what you're asking, and without knowing anything more about you and your background, it's not possible to tailor an explanation.

There are various properties required of the things you're working on, and of the calculation you want to perform, but those properties aren't limited to multiplication. Having said that, not everything has the necessary properties, so as I say, I'm not sure what you're asking.</comment></comment></comment>


From Java to Go, and Back Again (2016) - <AUTHOR> https://opencredo.com/java-go-back/ <comment><USER2> Java is crufty, but it's the best general purpose language I know. There's hardly anything you can't build in Java.

"Casual" Java programmers usually miss the most important feature, what really makes it possible to do almost anything in Java. Reflection and runtime code generation. Every time I look at Go this ends up being a problem, worse than lack of generics. A lot of Java libraries use these features under the hood to make things like JPA and JSON serialization work.

Nothing I'm aware of comes close to Java in this, where you can redefine the language and rewrite compiled code at runtime while still maintaining execution and memory safety. Java agents, annotation processors, and libraries like JavaAssist, ByteBuddy, and ASM make seemingly impossible things pretty easy to write.

This is why annotations are used for everything in Java. They're often just tags used to find targets for rewriting code at runtime.

I was trying to write a thin ORM for Go and quickly found out it was impossible to do what I needed without blowing a bunch of nasty generated source files into the build. In Java, I can give the developer a nice clean interface and just generate the code when the app starts. Go forces you to expose all this to the user of your library

<comment><USER3> > There's hardly anything you can't build in Java.

I do bare metal/low level embedded, kernel drivers, and occasionally shared libraries. Java is useless for practically all of my typical use cases.

<comment><USER4> Technically speaking you can build these things in Java. JNode is an OS written entirely in Java, including the drivers. You probably meant "drivers for linux/windows" though and yes, there it's not so useful.

You can also make shared libraries with Java these days. Look at SubstrateVM. It turns Java code into a .so file that doesn't depend on the JVM, compiled ahead of time, with a C API exported.

<comment><USER3> Yes, there's very little in software development that's strictly impossible. Practicality is another matter.

> Look at SubstrateVM. It turns Java code into a .so file that doesn't depend > on the JVM, compiled ahead of time, with a C API exported.

Thanks, will do. I've been mostly eyeing Webassembly for some "cross-platform shared object" use cases.

</comment></comment></comment></comment><comment><USER5> I think the author hits the nail on the head here:

>Almost all the tricks I've built up over the years for creating embedded DSLs in Java or Ruby or Clojure are simply unavailable.

>...if there's one complaint I've heard consistently from my fellow developers over the years, it's that they can't understand my code until they also understand the set of abstractions I've introduced

"Tricks" are lovely for personal projects, but no one wants to trawl through them at 3am when the server has gone down. Go removes a lot of tricks, and that makes people sad, but it makes total sense for a language design for large teams. You can still use Go for one-man projects, of course (I do), but don't expect it to be as whimsical an experience as using Ruby or Lisp.

<comment><USER6> In what job does one trawl through code at 3am?

<comment><USER7> When you're oncall and something broke.

<comment><USER8> You are on call for coding? What kind of job is that? This sort of things should be really really rare.

If it happens in any regularity, then tricky abstractions are not the main problem. Apparent lack of QA and overall quality is.

<comment><USER7> Point is that it broke and you're trying to figure out why and how to get it fixed. Sometimes looking at the code is the most expeditious way to get there.

<comment><USER9> > _Point is that it broke and you're trying to figure out why and how to get > it fixed_

Yeah, but the point was made to support an argument (that code should have fewer abstractions so that it's faster to grasp any part while reading in a hurry, as opposed to more abstractions so that it's shorter and more generic, even if that means having to study the big picture to get what some smaller part of code does).

Now, if devs routinely had to quickly understand some local code at 3am to fix bugs, as per the example, then sure, fewer abstractions and more clear local code would be better.

But since your example is contrived, where does that leave the main argument?

</comment></comment></comment></comment></comment></comment><comment><USER10> The post is spot on and certainly mirrors some of my own experiences using Go and Java.

Java is a wonderful language with a terrible culture. Choosing Go or even Kotlin over Java is liberating because it allows an engineer to escape the cultural baggage that comes with Java.

What kinds of baggage? The type of baggage that blindly demands using magical frameworks like Spring and JPA or worse engages in best practices chants as they implement 45 interfaces and create thousands of excess classes because SOLID and DDD said to do so. Yes, I'm exaggerating some but this is a real problem on Java teams.

I sincerely hope that a culture adjustment is included in the Java 11 release.

<comment><USER11> Honestly, Spring and JPA are largely what brought me back to Java. There's complexity there for sure, but those are very productive tools that are also very flexible. I don't waste much time on configuration, testing (even testing Spring Data JPA repositories) is easy and requires almost no configuration or external tooling, essential things like JSON serialization, request validation, fine grained control over error responses, database transactions, async tasks, and message queues all pretty much work out of the box and just let me get shit done. There might be a lot of overengineering going on under the hood, but as far as my code is concerned there's little to no inheritance and even interfaces typically aren't needed. It's mostly just object composition.

And if I didn't want the magic, projects like Dropwizard and Vert.x are there. But I'd rather have the most productive out of the box experience possible.

</comment></comment><comment><USER12> Honest question,but am I the only one who find really hard to read and follow quite big golang projects?

Maybe is true that I can understand what is happening in every single line of code in my screen, what I found really hard is to understand how those line interact with the rest of the code base.

I honestly believe that there are some part of the code base that should manage the low level stuff like managing files, writing to buffers or interact with the file system and other part that should compose/manage/move those low level parts.

Using go and its focus on "simplicity" it feels like these basic abstraction fall apart and that in every part of the code base I can find something doing quite low level stuff.

I find go quite good for small, self contained projects but honestly I believe that big projects like docker could benefit more from a more structured approach.

Am I the only one feeling this pain?

<comment><USER13> You're definitely not the only one. It's a very strange phenomenon: Golang developers insist their language is boring and uber-simple but every non- trivial Go codebase I've encountered has been anything but. It seems like the end result always involves a bad reinvention of exceptions using panic/recover, code that isn't type safe that has too many curly brackets... and lots and lots of code generation. Combined with immature tooling the result is horrifying. I'm by no means a Go expert and perhaps I'm just unlucky but that's been my experience. I certainly no longer volunteer dive into strange Go codebases like I might do with Java.

At this point I have to wonder if in 10 years the Golangers will actually find themselves in a good place. I don't see these codebases aging well at all.

</comment></comment><comment><USER14> Language wars aside, I liked this:

 __ _Returning to Java (and Kotlin) development after a couple of months of Go development, [...] I discovered the value of a certain sort of "plain speaking" in code._ __

This resonates with me. I 've spent 1 year+ in each of C, C++, C#, PHP, Java, Python, and JS. There are obvious benefits to taking advantage of a platform's strengths, but the "plain" code has merits too. Easier to reason about, often more maintainable, faster to ramp up new team members, etc.

<comment><USER15> In my experience, Java suffers from this the most because often CS teaches the tools/techniques, but not how/when to use them. For example, the number of times I've seen an interface with only one implementation is ridiculous. (Yes, I know interfaces have other advantages, no I don't think they're worth the trade-off of making debugging harder until you get to boundaries where that sort of abstraction is a real win.)

Simpler code almost always wins. Predicting the future is hard, refactoring simple code that does the minimum it needs to is comparatively easy. Don't write what-if code, YAGNI.

<comment><USER16> Why is having only one implementation for an interface bad? It neatly organizes all your code and doesn't make debugging harder at all.

<comment><USER17> How does having FooService and FooServiceImpl help with code organization at all? It brings nothing but unnecessary noise.

<comment><USER18> It's test-friendly. The code may not have explicitly defined second implementation, but a simple "@Mock FooService" declaration in a test.

<comment><USER15> This is a fair point, however in practice there's solution for that (Mockito, as long as the class isn't final). Which is how it should be. Your code shouldn't be untestable, on the other hand you shouldn't have to go out of your way to make it testable by adding more cruft.

<comment><USER18> I don't think the design should be based on the requirement to use Mockito library and it's not the only and not always the most convenient way to provide a test implementation. So, no, it's not how it should be.

</comment></comment></comment></comment></comment></comment></comment><comment><USER19> When I was a Java programmer I used to build my own abstractions. I can understand the complaint

> ...if there's one complaint I've heard consistently from > my fellow > developers over the years, it's that they can't > understand my code until > they also understand the set of > abstractions I've introduced"

Now I mostly use Scala in an FP style I find I reuse abstractions. The abstraction I want almost always exists in a library. Monads, applicatives, monoids, etc. actually work for code reuse, and this makes it much easier to read code. When I look at a code base such as http4s ([https://http4s.org](https://http4s.org)) I find I can read it without much difficulty even though I'm not familiar with the code.

So my contention is you can reduce expressivity to make code easier to read, or you can increase expressivity so that truly reusable abstractions can be created. (You basically need higher-kinded types in addition to the usual FP abstractions.)

<comment><USER20> yeah, it's not "either C# with a better language and less ecosystem, or java"... you can use scala and get something more powerful than C# and still get the java ecosystem. I suspect I will be using scala as my main language for some time to come

</comment></comment><comment><USER21> From Java to Go, and never back, for Go programs use much less memory, warn-up much faster, need much less code lines to implement and compile much faster. Beside happier developer experience, my App Engine apps also save much money by using Go.

<comment><USER22> Probably the number one thing I have always hated about Java is its build tools. Maven has never really made any sense to me and I simply don't want to have to deal with XML in 2018. Gradle requires me to use a totally different programming language just to write configuration. Ant is somehow more confusing than Maven but less standardized (and is almost useless without Ivy). It's been a few years since I wrote any Java so maybe there is something newer and better, but I just can't bring myself to go back to the misery of reading through that shit just to get a project to compile.

With Go it feels like all you need is a dependency manager and maybe a Makefile for more complex builds.

<comment><USER23> > Gradle requires me to use a totally different programming language just to > write configuration

There's an alternative to using Apache Groovy for writing Gradle config scripts: [https://blog.gradle.org/kotlin-meets- gradle](https://blog.gradle.org/kotlin-meets-gradle) . If you also use Kotlin instead of Java for your software on the JVM then you can stick to one language for everything.

</comment></comment></comment><comment><USER24> >I found myself more willing to consider that the concrete and immediate expression of some piece of program logic might serve better than trying to pull out a more generic version of the same logic that might never be re-used in practice.

This is the YAGNI principle in XP - "you ain't gonna need it": [https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)

</comment><comment><USER16> People are always saying that spring boot has too much "behind the scenes magic". What behind the scenes magic? Spring boot barely does anything fancy.

It builds an xml dependency tree of your classes. That's not hard to understand.

Everything it does is well documented on their site as well.

Is @component and @restcontroller and @requestmapping really that hard to understand?

<comment><USER11> Yeah, it's a little weird. Metaprogramming is apparently only a virtue if you're using a dynamic language. Personally I like being able to throw @Repository on an Interface and get paginated CRUD operations for free. I like being able to take any JPQL query, put it in an @Query annotation, and if I decided I want sorting and pagination later, I just change the return type to Page<T> and add an extra parameter for the pagination info. I like being able to write unit tests against those repositories by just adding a @DataJpaTest annotation to my test class. This stuff saves a considerable amount of time, and it's certainly better than the experience I've had in Go or even in Python with Flask.

<comment><USER25> > Personally I like being able to throw @Repository on an Interface and get > paginated CRUD operations for free.

If it doesn't work how you expect / want it to work, now what? With a library I can go the declaration and see what's going on and what I might be able to do. With annotation magic I have no choice but to go to google where my choices will be diving into extremely verbose and not particularly well written documentation or cargo culting based on stack overflow answers.

<comment><USER11> You can still just configure and use Hibernate or JDBC directly. Although I wouldn't be surprised if it was also possible to add your own custom implementation with different methods on the repository. It's by far the most flexible and extensible framework I have worked with.

</comment></comment></comment></comment><comment><USER26> The part I'm not sure about is easy to read and understand. Like the map example is much easier to read and understand in my opinion.

So I wonder, having a smaller vocabulary, it might make learning the language easier. And maybe your first pass on a new piece of code is quicker to read. But after that first pass, or once you've learned the expanded vocabulary, wouldn't it now be even easier to read? And not using it would just make things redundant and appear like noise.

It's like reading: "He felt a deep attachment that was unique and stronger then any other to her." And then you learn about "love". Now from that point on, I'd rather read "He loved her." Seem just easier to read once you know the concept.

</comment><comment><USER27> > While Go does support passing around functions (and this is occasionally > useful), it doesn't really support the use of functions to build up > composable abstractions that feel like extensions to the language. It > favours the concrete, inline expression of logic, with function calls acting > primarily as a mechanism for structured programming.

I see what the Author is getting at, but he's missing the primary mechanism Go uses for this: Interfaces. This is hard to explain in the abstract, so here's an example I gave in a talk once: (bit.ly/1mBisa6)

Suppose we are building a new podcast platform which dynamically splices advertisements into mp3s. We will do this with an HTTP server. In Go you do:

        f, err := os.Open("somefile")
        ...
        http.ServeContent(w, r, "", time.Now(), f)

ServeContent takes an io.ReadSeeker. Now we build a Splice function:

        func Splice(
            src io.ReadSeeker,
            splice map[time.Duration]io.ReadSeeker,
        ) (io.ReadSeeker, error)

Used like this:

        f1, _ := os.Open("/tmp/1.mp3")
        f2, _ := os.Open("/tmp/2.mp3")
        f3, _ := os.Open("/tmp/3.mp3")
        final, _ := mp3.Splice(f1, map[time.Duration]io.ReadSeeker{
            time.Second * 5:  f2,
            time.Second * 10: f3,
        })

Splice uses two additional functions. First the MultiReadSeeker, which simply concatenates ReadSeekers:

        func NewMultiReadSeeker(
            readSeekers ...io.ReadSeeker,
        ) io.ReadSeeker

Next the SectionReadSeeker, which gives you a section of a ReadSeeker:

        func NewSectionReadSeeker(
            src io.ReadSeeker,
            offset, length int64,
        ) io.ReadSeeker

So it ends up being:

        final := NewMultiReadSeeker(
            NewSectionReadSeeker(f1, 0, A),
            f2,
            NewSectionReadSeeker(f1, A, B-A),
            f3,
            NewSectionReadSeeker(f1, B, C-B),
        )

So it's pretty straightforward. There are some really powerful ramifications from these abstractions:

1\. The file is never built in its totality in memory. Rather we are representing the operations in a lazy fashion that only get executed when you use them.

2\. The ReadSeeker supports seeking, which means we can resume from the browser, or seek to the end and skip the middle bits. With the go HTTP library we basically get this for free.

3\. Lots of things use these interfaces. For example if I want to write this to disk, I can just io.Copy it. Or suppose I want to use this as another source for a second splicing. It's ReadSeekers all the way down, so I can do that with no changes. With some tinkering I'm pretty sure you could hook this up to S3 too.

<comment><USER28> Closures is also a big win for passing around functions.

<comment><USER21> All Go functions are closures.

</comment></comment></comment><comment><USER29> >Go's lack of generics means that you have to write mapStringToString as a mapper between collections of two fixed types – you can't write a generic map from an array of T to an array of R, as you can in almost any other strongly- typed modern language.

That's not true. Here's their example written to be more generic:

      func mapThingToThing(inSlice interface{}, mapperFn interface{}) []interface{} {
      	mapper := reflect.ValueOf(mapperFn)
      	input := reflect.ValueOf(inSlice)
      	output := make([]interface{}, input.Len())
      	for i := 0; i < input.Len(); i++ {
      		item := input.Index(i)
      		output[i] = mapper.Call([]reflect.Value{item})[0]
      	}
      	return output
      }

and calling:

      fn := func(item string) string {
      	return item + "!"
      }
      res := mapThingToThing([]string{"a", "b", "c"}, fn)
      for _, item := range res {
      	fmt.Printf("item = %+v\n", item)
      }

I didn't say it was pretty or good, but it can be done. Really confused by the downvotes.

<comment><USER30> Well technically this is reflection which is something else than generics. You say "that's not true" but it IS true that go lack generics (or metaprogramming in general). You point out that it supports reflection which is something else... it is a bit like coding in Python, you loose compile time type safety.

<comment><USER29> No, it's not generics, but it enables you to write a generic function, which is what the article claimed was not possible in Go.

</comment></comment></comment><comment><USER31> He never left Java.

</comment><comment><USER32> There is a bug in a code listing in the article:

val exclaimed = strings.map { it + "!" }

Should be

val exclaimed = plain.map { it + "!" }

<comment><USER33> I'm glad you confirmed this. I don't know much about Go but I do know programming. My gut told me there was a mistake but imposter syndrome kicked in and I assumed Go had some non-intuitive proximity rules like 'it' refers to the last iterable in scope or something.

I have mentioned this before but the reason I like Java so much is the mature and cohesive ecosystem. Every single problem has been solved in Java and all the solutions look similar so you can readily pick them up. I don't find that to be the case in other languages.

</comment></comment><comment><USER34> TLDR; writing code in Go is boring and clunky, reading other people's code is pleasant and easy.</comment>


The doodle theorem, and beyond - <AUTHOR> http://chalkdustmagazine.com/features/the-doodle-theorem-and-beyond/ <comment><USER2> I expected this to be the traditional dusty introduction to the lovely but well worn Königsberg problem, but found the exposition lively and engaging even as someone who has seen this many times before. A lovely piece of work!

</comment><comment><USER3> this is cool but I do get annoyed when an explanatory piece explicitly divides the audience according to who does and doesn't know the trick and says of the latter "at this point some of you will be spluttering"... well-written in general but it is important not to alienate people who don't get it yet.

<comment><USER4> I was really confused at his example here, so I drew this:

[http://i.imgur.com/NBVPiCE.png](http://i.imgur.com/NBVPiCE.png)

then I realized that his example was meant to be interpreted as a single disconnected graph, rather than two separate examples.

</comment></comment><comment><USER5> Cache link: [http://webcache.googleusercontent.com/search?q=cache:chalkdu...](http://webcache.googleusercontent.com/search?q=cache:chalkdustmagazine.com/features/the- doodle-theorem-and-beyond/&num=1&safe=off&strip=1&vwsrc=0)

<comment><USER6> Half the article is useless without the images

[http://archive.is/Ox8GQ](http://archive.is/Ox8GQ)</comment></comment>


Show HN: Cloakwork – Zero Knowledge team collaboration suite - <AUTHOR> https://cloakwork.io/ <comment><USER2> " We're not going to give the whole game away" so security through obscurity. Trust us, if we say crypto three times it must be secure, crypto, crypto, crypto!

</comment><comment><USER3> Some screenshots would be nice There are quite a few encrypted collaboration suites now, you will need either a better UI or a really good enterprise sales team.</comment>


Trip report: Fall ISO C++ standards meeting - <AUTHOR> https://herbsutter.com/2018/11/13/trip-report-fall-iso-c-standards-meeting-san-diego/ <comment><USER2> [http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2018/p090...](http://www.open- std.org/jtc1/sc22/wg21/docs/papers/2018/p0907r4.html#survey), concludes

 _"the only machine the author could find using non-two's complement are made by Unisys, and no counter-example was brought by any member of the C++ standards committee. Nowadays Unisys emulates their old architecture using x86 CPUs with attached FPGAs for customers who have legacy applications which they've been unable to migrate. These applications are unlikely to be well served by modern C++, signed integers are the least of their problem. Post- modern C++ should focus on serving its existing users well, and incoming users should be blissfully unaware of integer esoterica."_

That led to the decision that _"Signed Integers are Two's Complement"_ in C++ 20.

That makes it too easy to write portable code :-)

<comment><USER3> "Post-modern" C++? Finally someone admits that the language was all a huge prank.

<comment><USER4> C++ is more like a drug - having used it makes it impossible to go back to C.

<comment><USER5> It is absolutely possible. I did C++ development as a regular job years ago, now I'm coding in C (for that type of coding).

What will get you off the C++ drug easily is Lisp.

Once I discovered Lisp, C++ had no place in my "personal spectrum" any more, but C (including the C-like subset of C++) still did. Well, it wasn't so sudden, mind you. More like: the more Lisp I knew, the less interest I had in C++.

(Idiotic lambda implementations and whatnot will not woo me back, sorry.)

<comment><USER6> Sorry if this is a hated question - but are all Lisp the same rats nest of parenthesis?

ive always been interested in Lisp but that is so ugly - i would a JavaScript/Ruby/Python method chaining to 5 levels of nested parenthesis

<comment><USER7> I implemented a compile-time test framework in Gambit Scheme in 7 lines of code, and Python's yield in about 20 or so.

[http://billsix.github.io/bug.html#_make_generator](http://billsix.github.io/bug.html#_make_generator)

Lisp code has few wasted moves. Programming in it does require changing your mindset of syntactic beauty. And once your mindset changes, you can make whatever syntax you want.

Perhaps the biggest hurdle is that the code is not best read linearly. The reader must understand the order of evaluation, which follows very simple rules, in order to understand the code correctly. That hurdle is definitely worth the jump.

<comment><USER8> > Perhaps the biggest hurdle is that the code is not best read linearly. The > reader must understand the order of evaluation, which follows very simple > rules, in order to understand the code correctly.

Could you please give some details about how the order of evaluation differs from, say, C? Thanks!

<comment><USER7> They are very similar. They are both applicative-order, meaning that the arguments to a procedure are evaluated before the procedure is applied.

The evaluation of a lambda results in a function value, which captures the enclosing scope, but the procedure is not yet applied to anything.

But the main difference that I've seen anecdotally is that imperative programmers as a whole tend to get confused by nested expressions, or lets just say they prefer sequential statements over nested expressions. My assumption is that they don't fully understand the order of evaluation in their language of choice.

<comment><USER5> Scheme and C evaluation rules are very similar: in both languages, the order of evaluation of function arguments is unspecified.

Common Lisp is left to right, so that (list (inc i) (inc i) (inc i)) will reliably produce (1 2 3) if i starts at zero.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Looks like switching to regular releases of the standard 10 (!) years ago, and all the work they put into proposal workflow, has really paid off.

C++ stagnated for a long time, but IMO Boost's metaprogramming reinvigorated the language and community.

Now they are following through with concepts, metaprograms that can do everything runtime programs can do, and soon reflection. Wow.

</comment><comment><USER10> I'm really exited for the addition of ranges to C++20. Ranges are objects that contain both a start and an end iterator. So you can simplify the APIs of functions that take start and end iterators as separate arguments.

<comment><USER11> It's been a long journey; the first version of Boost.Range dates back to 2003. It's been understood for a long time that functions taking iterator pairs compose very poorly, but as always, the devil is in the details. But compared to modern composable abstractions such as Rust iterators, the STL paradigm feels positively archaic.

</comment></comment><comment><USER12> Does anyone have examples of well-written modern C++ code out there? I used to consider myself a C++ expert like circa 2011 but it's advanced to so quickly that it's almost like a foreign language to me... (though I have tried to keep up a bit... but it's hard without nontrivial examples)

<comment><USER10> Effective Modern C++ by Scott Meyer is a good tour of new features in the language. I highly recommend it. It's maybe a little too in-the-weeds in some parts but you can just skim those.

It only goes up to C++14 but there's not all that much that's new in C++17. C++20 looks like it's going to be a bigger update, hopefully Scott will come out with a new revision of Effective C++ to address the changes.

<comment><USER13> Unfortunately, that's not likely: [http://scottmeyers.blogspot.com/2015/12/good-to- go.html](http://scottmeyers.blogspot.com/2015/12/good-to-go.html)

</comment></comment></comment><comment><USER14> C++20 must be exciting with ranges, concepts, modules and easier metaprogramming.

Are there any numbers/graphs on how many proposals are being submitted over time? I feel like they are exploding.

<comment><USER15> > This week's meeting was extraordinary. The pre-meeting mailing had 274 > papers, about twice as many as any previous meeting, and we had 180 people > attending, making this the largest C++ committee meeting ever.

[https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_...](https://www.reddit.com/r/cpp/comments/9vwvbz/2018_san_diego_iso_c_committee_trip_report_ranges/)

</comment></comment><comment><USER16> I'm very excited to see Ranges and Concepts being adopted, since this makes writing and working with templated code that deals with containers much easier.

</comment><comment><USER17> > at this meeting we decided to target merging Networking into C++ for soon > post-C++20 (i.e., targeting C++23).

It'll be nearing a decade of "next release" now as it's own TS and near two decades of proposal since TR2.

Edit: The Reddit trip report lists 23 as optimistic and 26 as the conservative.

</comment><comment><USER18> The concept syntax is actually somewhat pleasant. The previous one was such a monstrosity.

</comment><comment><USER19> Is it not time that specifications for additional features for C++ came with a test-suite? Preferably something shared via git somewhere that people can contribute to.

Would make bootstrapping some of these new features to a usable level much quicker.

Speaking as a dev that needs features to span 3 major compilers (clang/gcc/vs) before I can use them.

<comment><USER20> You can buy a ISO C or ISO C++ certification suite.

[http://www.plumhall.com/suites.html](http://www.plumhall.com/suites.html)

[https://www.opengroup.org/testing/testsuites/perenial.htm](https://www.opengroup.org/testing/testsuites/perenial.htm)

[http://modena.us/](http://modena.us/)

[https://peren.com/pages/cppvs_set.htm](https://peren.com/pages/cppvs_set.htm)

Ah just needing the support across 3 major compilers!

I guess you haven't enjoyed the glory days of writing portable C, C++ or Pascal code during the 1990's.

<comment><USER19> I work on a codebase (LibreOffice) that has seen those days (and I worked through them on other projects, but thankfully without needing cross-platform support).

I note that there is some sharing of test-suites between the different compiler vendors, certainly they occasionaly run their compilers against some of each others test.

But a central shared resource that is updated by multiple people to catch edge cases would be first prize.

(And hopefully, seeded by the proposal authors, to act as a useful starting point)

</comment></comment></comment><comment><USER21> C++ is changing way too fast to be useful anymore. I spent the first 15 years of my life loving C++ but in the last 8 years or so, the C++ committee has vastly outpaced its supply lines. I've been out of the language since then and I might as well learn a new language rather than try to re-understand the differences between C++ back then and now.

The only people that can keep up are the hobbyists and the language purists. It's become a circle jerk and that's a shame because they are modernizing themselves out of existence, in my opinion. No one in real software can keep up with the biannual changes and it's getting to the point where migrating to another language like Go or Java is a lot more stable and less risky.

<comment><USER20> Then good luck keeping up with those languages as well, which release new versions every 6 months nowadays.

Programming languages are just like any other software product.

<comment><USER22> C seems to be pretty stable at least. Even if it too has a new version in the works.

<comment><USER20> C is mostly confined to UNIX derived OSes and embedded devs that won't change to anything else even at gun point.

Yet, even C just got ISO C17 this year, even though it was a minor update.

[https://www.iso.org/standard/74528.html](https://www.iso.org/standard/74528.html)

Languages either die or get updated to fulfill their customer requirements.

</comment></comment></comment></comment><comment><USER23> > _So fasten your seat belts, and stay tuned. C++ programming is likely to > evolve more, and in better ways, in the upcoming 5 years than it already has > in the past 20._

Yeah, that's the problem isn't?

You do in fact need damn seat belts to cope with all the changes to what used to be a very predictable and simple to understand language.

<comment><USER24> What? C++ has always been one of the rare languages that don't mindlessly add stuff that drives them into a corner.

<comment><USER20> C++ has this fame of being a bloated language, which it kind of is.

However it isn't really that much bigger than Java, .NET + VB/C#/F#, Python, Ada, Common Lisp,... when one looks at the size of printed language, library and implementation specifications.

It is just that others are more beginner friendly and most devs forget they have a pile of features on their own languages as well.</comment></comment></comment>


Apple Offers to Replace iPads with MacBooks in Maine State Classrooms - <AUTHOR> http://www.macrumors.com/2016/05/23/apple-replace-ipads-macbooks-classrooms/ <comment><USER2> Our PTA donated an entire array of iPads to the school. Probably $20K worth of pads/charging stands/secure carts. Took 2-3 years of saving and fundraisers to get there.

Over the last 18-24 months the classrooms have been introducing Google Docs and Chromebooks. Now the district is purchasing a mess of Chromebooks on their own. Every kid has been given their own gApps account. The iPads are going to gather dust, as far as I can tell.

I can totally understand why. The laptops are way more functional for what the kids are doing in the classroom. iOS is (finally) catching up to the needs of education with things like the multiple-login enable, but it's too little too late.

A lot of parents, myself included, are _extremely_ pissed off at the moment. Maybe we should get in on this.

</comment><comment><USER3> Our school district uses iPads with young, elementary school kids. Works out fine.

Middle and high school kids use chromebooks instead. Works out fine.

Should not be surprising or controversial that there are appropriate and inappropriate uses for technology.

For high school students, the iPad Pro is great in art class. Again not surprising.

</comment><comment><USER4> Tablets are for consumption. Computers are for creation.

It's been the case since the iPad 1 came out. Perhaps it'll change in the future, but this really shouldn't be of surprise to anyone.

<comment><USER5> Respectfully, I've "created" on every iPad I've owned since the first. I write docs in Pages, create music in GarageBand, design web site graphics in Pixelmator, and edit code in Coda (and Prompt/Emacs).

Tablets make it _easy_ to consume, but do not fool yourself into thinking that's all they can do. My iPad Pro is more capable than the laptop I owned two years ago, and costs less as well.

<comment><USER6> You're definitely an outlier though, and no one is saying that it's not possible, it's just that the interface of a tablet (or lack thereof) presents an un-necessary hurdle that needs to be overcome.

My company is responsible for a number of different school districts, and I've seen this happen at all of them, despite them being warned about the outcome beforehand.</comment></comment></comment>


An IRS employee stole identities and went on a 2-year spending spree - <AUTHOR> https://qz.com/1723855/an-irs-employee-stole-identities-went-on-spending-spree/ <comment><AUTHOR> "The complaint says the employee, who works for the tax agency as a software developer, obtained a second fraudulent credit card, which he used to fly to Montego Bay, Jamaica. A third fraudulent card was used to travel to Iceland. In a particularly brazen move, investigators say the suspect linked this card to a phony PayPal account he opened using his official IRS email address."</comment>


How To Avoid LinkedIn's Site Wide Automatic Moderation - <AUTHOR> http://blog.oktopost.com/how-to-avoid-linkedin-swam-site-wide-automatic-moderation/

<comment><AUTHOR> Njay - It's a pretty bad problem, but I think keeping tabs on your groups and making sure you are only posting relevant content (ie, if the group rules state no links, don't post links) then you have a good chance of avoiding it.

HOWEVER, if you are SWAM'd there really is no recourse. I have found that switching groups is the only solution, and it does work. Have you had issues with this?

</comment><comment><USER2> There's no real certain solution to this that could work!! At least not at the present.</comment>


Wrapping up Java 9 new Features - <AUTHOR> https://aboullaite.me/wrapping-up-java-9-new-features/ <comment><USER2> I am a C# developer. My thoughts:

\- I love that they are adding REPL. I really wish C# had this. I use IPython all the time for Python. It is very helpful to mock something up quickly or try out different features.

\- Adding private methods to an interface seems very wrong to me. An interface is just a contract without any implementation at all. I am not sure the reason behind this. Aren't abstract classes a thing in Java?

\- I was sad to see that they have not included type inference to Java yet. It is just a syntax thing, but it makes writing code feel so much less wordy. Here's an open JEP for it: [http://openjdk.java.net/jeps/286](http://openjdk.java.net/jeps/286)

<comment><USER3> As a long-time Java developer, I really hope they won't implement JEP 286. I think type inference by the compiler is a bad idea, as it results in less readable code, more bugs, and an unnecessary burden on the compiler. I think all the examples where type inference is convenient are trivial cases, but the downsides start to crop up in real-world, large code bases. So it's something that makes the easy things slightly easier and the hard the things harder.

Type inference already happens for you when you are using a good IDE, like IntelliJ IDEA. You can just use the "Introduce Variable" refactoring. And better yet, it self-documents your code with the variable's type.

<comment><USER2> > _Less readable code_

Maybe it is because we are used to our own paradigms, but the following is no less readable to me because of inference. And these are the 95% of cases.

      var index = 0;
      var name = "pwaivers";
      var names = new List<string>();
      var nameMap = new List<string, Dictionary<int, Address>>();

> _more bugs_

I have never seen a bug arise because of type inference. Do you have an example?

> _unnecessary burden on the compiler_

The compiler does a lot of work and this would probably be insignificant to add to it. However, I am totally open to learning more about this.

<comment><USER4> The examples you've given have direct values. Try:

      var index = getIndexFromSomewhere();
      var name = getHandleFromUser("peter", "waivers")

The type isn't as clear anymore.

*Edit: I'm absolutely a fan of the var syntax, having dabbled with scala. I'm just expressing what I think the original author's complaint is.

<comment><USER5> I think the code is _much_ more readable and less annoying with inference. And as for your examples, you don't _need_ to know the types - the compiler will complain if you try and use them inappropriately whether the type was explicit or not.

But the issue you have glossed over is that sometimes there is no nominal type - there is only an anonymous type, as for example returned by a LINQ query using new{}, or via monad-style combinators where you really don't want to see the type for fear of your eyes bleeding.

<comment><USER6> > I think the code is much more readable and less annoying with inference.

I concur. I've been dabbling with Java a bit again (mainly because of a hobby project in order to learn Clojure) after a pause of multiple years.

It boggles my mind that compiler inference didn't make it into the language yet. Everytime I have to declare a totally obvious type, I cringe.

</comment></comment></comment></comment></comment></comment><comment><USER7> Is jigsaw being shipped or not? (relating to [https://jaxenter.com/jigsaw- dispute-means-possible-delays-ja...](https://jaxenter.com/jigsaw-dispute- means-possible-delays-java-9-133723.html) )

<comment><USER8> Yes, the objections by IBM and Red Hat won't stop this train.

</comment></comment><comment><USER9> All of this is super cool but what I really want is async/await. Every day I wish I had it. I know everyone has some pet thing they want, but I can't imagine async/await being nothing short of a game changer for Java. Why is it never mentioned? Will it ever happen?

<comment><USER10> I can only guess, but it is in general very difficult to retrofit what is essentially green threading, coroutines, and continuations into a runtime that was built without those features. Scala has tried at least a couple of times, and as is typical of the language and community, has come up short as the original contributors lost interest or decided the problem was too hard. This includes:

* Scala's CPS compiler plugin, now deprecated and unmaintained.

* Macro-based async/await library. It's neat but has many more limitations than C#'s equivalent or Kotlin's, and hasn't had any updates in a couple of yaers.

It looks like Kotlin has recently added experimental support for async/await. That language may be your best bet for now if you want to code in this style on the JVM.

<comment><USER11> What's the difference between async/await and a future? I've only used futures, but async/await looks like exactly the same thing: You're forking a thread (green or otherwise) to do some stuff and to set a flag of some sort when it's done so you can check on it. Right?

<comment><USER10> At a high-level, async/await lets you write non-blocking code as if it were blocking. Golang has a huge advantage here because the runtime was built from the ground up so that everything is non-blocking and the language has built-in support for operations that look like they block, but underneath the hood they don't actually block a thread.

Futures are interesting, but at the end of the day they are basically not that different from callbacks. Instead of writing a function that takes a callback, you write a function that returns a future that you essentially register callbacks onto. In Java 8 this type is called a CompletionStage. In fact, in one of Scala's coursera courses they teach you how to take callback-oriented code and convert it into code that returns futures. The fact that it is so easy to convert between the two helps illustrate that futures aren't really adding much. Yes you can compose using flatMap, but, again, I don't think this makes the code that much easier to write, or, more importantly, debug and maintain.

As an example, at $lastjob I converted a blocking networking library to a non- blocking one. I started out using futures but I found that it generated a lot of Lambdas, which made debugging much harder because the stacktraces were long and incomprehensible. I ended up switching to callbacks and used named, not anonymous classes to improve readability. Not only did the code feel easier to read and debug but I got better performance out of the library due to reduced memory pressure.

</comment></comment></comment></comment><comment><USER12> Why didn't they just use OSGi, a stable, mature (16+ years old) technology for modularity, instead of re-inventing the wheel with JPMS?

<comment><USER13> Because OSGi is a pile of needless complexity for selling consulting support, the less I have to touch it the better.

<comment><USER14> Aren't you an IT consultant though? ;-)

<comment><USER13> Yes, but getting to do JEE and stuff like Websphere is already enough, I don't need to fight with OSGi as well. :)

Having written a few Eclipse plugins was already enough.

<comment><USER12> Don't let Eclipse give you a bad impression of OSGi.

There are now some very cool things that make starting a new OSGi project a lot easier:

* Declarative Services, for simplifying Component definitions (No more editing XML)

* bnd / bndtools for building your OSGified jar (No more manually editing the Manifest)

</comment></comment></comment></comment></comment><comment><USER15> > underscore character is reserved. A variable can no longer be named only '_'

Huh.... I wonder why that is?

<comment><USER12> They are going to use it to represent lambda parameters.

Please see: [http://openjdk.java.net/jeps/302](http://openjdk.java.net/jeps/302) \- Lambda Leftovers

<comment><USER15> Ah. Thanks.

</comment></comment></comment><comment><USER16> Has there been any hints of adding default parameters to Java at some point? It's one of those things I find really useful in Python or C#, but for some reason never seems to find its way into Java.

<comment><USER12> I second this. Java needs default parameter values.

</comment></comment><comment><USER17> Simple, but I am most excited to see a REPL here -- JShell. I have written so so many Tester classes when I just wanted to run a few lines of java.

<comment><USER18> I used the Groovy shell for this. Since Groovy is Java, you can paste Java code into the Groovy REPL and it works fine.

<comment><USER19> > Since Groovy is Java, you can paste Java code into the Groovy REPL and it > works fine

Did you mean Java 7 and previous versions? You certainly can't paste Java 8 code into the Apache Groovy REPL if it has lambdas because Groovy hasn't been updated for Java 8, not to speak of the new features in Java 9. My guess is the sad state of the Groovy ecosystem is probably why Oracle even created JShell.

In fact, you can't even paste Java 7 code in there and have it behave the same because of lots of little incompatibilities like the meaning of the == operator. Every Java developer should know never to paste Java code into a Groovy REPL and rely on the result for testing purposes.

Groovy isn't Java. Like Java, Groovy generates JVM code, though it typically runs slower than Java code because Groovy is a dynamically-typed language. Although it added annotations for static typing into Groovy 2, they don't work for bulk code, only isolated test cases, and the latest versions of Groovy are still written in Java, not statically-annotated Groovy.

</comment></comment></comment><comment><USER20> The HTTP/2 client is incubator only [1]. Strictly speaking it's not part of Java 9. But that's not a big deal because ALPN is part of Java 9 so you can use 3rd party clients.

[1] [http://openjdk.java.net/jeps/110](http://openjdk.java.net/jeps/110)

</comment><comment><USER21> One additional thing which is missing in the post is that AES-GCM is (finally!!) becoming usable: [http://openjdk.java.net/jeps/246](http://openjdk.java.net/jeps/246)

> performance increase is large compared to JDK 8 GA, ranging from 34x to 150x

</comment><comment><USER22> I don't see anything in there about improving interoperability with native code. Years ago there were discussions of a project to do that. Maybe that is dead - perhaps everyone interested in native code interop has already moved on.

<comment><USER23> Or value types, which would remove some of the need for native code(yes yes, I know it's coming in Java 10 which means we'll see it in 2030 or so).

<comment><USER13> C++ devs are still waiting for concepts and modules as well.

Waiting for features is not unique to Java.

<comment><USER23> Really? I'm certainly not waiting for those. If I'm using C++ it's to go wide across platforms or for performance and none of those help me much in that area.

</comment></comment></comment></comment><comment><USER24> List<String> list = new ArrayList<>(){ };

<comment><USER25> Yeah, worst example ever. They should make it harder to make inner anonymous classes, not easier. When such code is used inside JEE/CDI/Spring Beans it leads to some annoying leaks or issues with serialization.

</comment></comment><comment><USER26> Death of the Applet. Yay! Finally.</comment>


Encrypting and authenticating the whole Internet: DJB (video) - <AUTHOR> http://27c3.iphoneblog.de/recordings/4295.html <comment><USER2> This is a great talk; Bernstein is a surprisingly excellent public speaker with solid timing.

You can get most of the points he raises from the foils of previous talks on his website, but, the high points:

* DNSSEC offers DDoS attackers 30+ : 1 amplification for attack traffic; at reasonably low deployment levels, it allows a 200> node botnet to saturate most websites on the Internet. It does this while _not_ actually securing end-user DNS queries, which themselves (his point, not mine) _aren't_ what users need secured.

* Prior attempts to secure the Internet with crypto protocols have failed in predictable ways, ranging from TCPcrypt's "try to encrypt without authenticating" to DNSSEC's "try to authenticate without encrypting" to everything's "try to secure the Internet with stuff that takes a million lines of code just to express the crypto in" to "standardize protocols with crypto mechanisms that real cryptographers have declared off limits over a decade earlier".

* Your conception of the speed of public-key crypto is warped by how slow SSL is; 256 bit elliptic curve crypto, which hasn't degraded in security for almost 25 years, is so fast that you can rekey 10 million sessions every 10 minutes on standard PC hardware.

* That being the case, there's no excuse not to bake fast modern crypto into HTTP so that it's simply always there; Bernstein has created a TCP-friendly alternate transport protocol that does exactly this.

* It's a bad idea to have individual trusted roots, whether they're SSL CA's or DNS roots. Instead, bake public keys directly into URLs or hostnames ("nym-based security"), use CNAMEs and aliases to make things more user-friendly, and secure the end-user connections to the DNS instead of trying to sign every DNS record.

<comment><USER3> > Your conception of the speed of public-key crypto is warped by how slow SSL > is; 256 bit elliptic curve crypto, which hasn't degraded in security for > almost 25 years, is so fast that you can rekey 10 million sessions every 10 > minutes on standard PC hardware.

This argument implies ECC and SSL are mutually exclusive when they aren't. ECC has been a standardized part of SSL for years and there are many shipping implementations. The same thing stopping ECC in SSL from being _deployed_ is what would stop DJB's ECC-hard-coded protocol from being deployed.

I guess DJB still wants to use Curve25519, but nobody has taken any steps to make Curve25519 actually implementable by mainstream software vendors. The first necessary step is to get it approved by NIST. A second necessary step would be to get IANA identifiers reserved for its use in TLS and other protocols. The third necessary step would be for his claims about the un- patented-ness of the curves verified in a way that venders can rely on. A nice fourth step would be to have it endorsed by the NSA like the Suite B curves. IIRC, this would require some standards to slightly weaken their minimum requirements of 256-bit curves to allow this not-quite-256-bit curve.

> * That being the case, there's no excuse not to bake fast modern crypto into > HTTP so that it's simply always there; Bernstein has created a TCP-friendly > alternate transport protocol that does exactly this.

Lots of people are working on doing this using existing standards like DNSSEC, TLS, and (maybe) X.509 already. Minimal extensions of these existing standards are going to win unless they are shown to be unworkable or unless some other protocol is _soon_ shown to be obviously overwhelmingly better.

> [B]ake public keys directly into URLs or hostnames ("nym-based security"), > use CNAMEs and aliases to make things more user-friendly, and secure the > end-user connections to the DNS.

I wonder how this would work in the real world when keys are rotated and/or revoked.

<comment><USER2> NIST reviews! Official IANA identifiers for TLS! A prove-the-negative patent resolution! And, it'd sure be nice if the NSA came out and endorsed the solution!

Yeah, this is definitely an apples to apples standard compared to what DNSSEC dealt with.

I am, for the record, (a) a proponent of x509 and (in particular) TLS, (b) not a particular fan of "nym security", (c) not optimistic about any ground-up replacement of TCP. It's weird that you're arguing with me about this stuff.

But he's straight-up right about DNS security.

<comment><USER3> I'm not arguing with you (aren't you just summarizing somebody else's viewpoint?). I think it's important to see the non-technical factors that may cause a new scheme to lose out to even technically-inferior alternatives. How much value is there in a NIST or NSA rubber stamp? Well, so far MS and Mozilla have only implemented Suite B curves. How hurtful is the ECC patent FUD? Well, look at how much work Red Hat did to strip all ECC code from all the software they ship in their products. How likely is it that there will be a standard that takes off without being distributed by either Microsoft or Red Hat (or Oracle or CentOS)? What would it take to get Curve25519 used in Firefox? Well, there's not much reward for implementing a curve that isn't going to be implemented by many other browsers or servers, so it's hard to justify spending time to consider it, even ignoring the NIST/NSA/IETF/IANA angle.

<comment><USER2> I think there's zero chance any of this stuff ever gets deployed, for whatever that's worth. I think that, and that Bernstein is probably right.

</comment></comment></comment></comment></comment><comment><USER4> Mirror here (tested with VLC - File - Open Network):

<http://ha.cx/DJB.mp4>

<comment> david-sarah This seems to be 404, can you put it back up? Thanks.

<comment><USER4> I had to move it since my VPS is capped at 5mbps and it was overloaded. Ask for the link via email (in my profile).

</comment></comment></comment><comment><USER5> I can't read the video stream on linux (ubuntu 10.04). Does anyone have a direct video d/l link or something, please?

<comment><USER6> I'm pulling it down now. I can't run it either.

Because I found it interesting, and as an explanation of why I can offer no link: It's in an m3u8 file (UTF-8 m3u playlist). Which links to other playlists, apparently by bandwidth. So I grabbed the largest, and found 938 .ts links. So I'm pulling them, grabbing mplayer (not sure how I was missing it...), and I'll upload the merged result when it all finishes :)

edit: or, if you're adventurous, and can queue up just shy of 1000 videos to play nigh-seamlessly (or want to do it yourself). This should be the high quality set:

      curl -LO http://27c3.cdn.undsoversum.de/saal1/saal1_umts-000[14880-15817].ts

followed by something like this to merge them all: (from [http://www.misterhowto.com/index.php?category=Computers&...](http://www.misterhowto.com/index.php?category=Computers&subcategory=Video&article=join_with_mencoder) )

      //edit: doesn't work for me (jumpy video & audio in result), but YMMV and it's a start:
      mencoder -oac copy -ovc copy -idx -o output.ts $(ls *.ts)
      //probably needs to be streamed in somehow... Hmmmm.... been too long since I fought with mencoder, I've forgotten most of it :\

edit2: crud, none of the binaries are working properly for me. Gotta compile from source, which'll take far too long for me to do tonight, sorry! The above `curl` is about the best I can do for you right now.

</comment></comment><comment><USER7> Online vimeo presentation here:

<http://vimeo.com/18279777>

It starts roughly 13 minutes before DJB actually begins to speak, and you can't fast forward unfortunately.

</comment><comment><USER8> "Maybe some people had pointed out the problem and the fix before.."

How modest.

</comment><comment><USER9> Video seems to work fine with Quicktime open network option. Thanks for posting!</comment>


"Do Not Be a Goddamned Liar", from Sh*t My Dad Says: The Book - <AUTHOR> http://gizmodo.com/5554553/do-not-be-a-goddamned-liar-from-sht-my-dad-says-the-book?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+gizmodo%2Ffull+%28Gizmodo%29&utm_content=Google+Reader# <comment><USER2> That's quite a touching story. Now I know how to handle it if any of my kids ever disgrace the scientific method,</comment>


Can't Sleep App – Android Beta - <AUTHOR> https://cantsleepapp.com/androidbeta/ <comment><AUTHOR> Sign up to our Android beta program to get early access to Can't Sleep and a free one year annual subscription.</comment>


A dashing freeWordPress theme for (un)sophisticated bloggers - <AUTHOR> http://demo.themeisle.com/zillah/ <comment><AUTHOR> The theme can be downloaded from here : [https://www.dropbox.com/s/srlq1u..](https://www.dropbox.com/s/srlq1u..). and you have ideas for us the Github link is : [https://github.com/Codeinwp/zillah](https://github.com/Codeinwp/zillah) ( if you get it directly from the github, you aren't getting updates since the update script is added later on )</comment>


/r/IAmA set to "private" after Victoria is let go from Reddit - <AUTHOR> https://reddit.com/r/OutOfTheLoop/comments/3bw39q/why_has_riama_been_set_to_private/csq204d

<comment><USER2> Seriously thinking this was a result of the Jesse Jackson interview. Likely the new Reddit is going to cater to celebrities and politicians in such a way that the idea of AMA isn't going to be unfiltered anymore. I would expect them to sell AMAs that are wholly staged/filtered/etc just like any political press conference. With the upcoming elections its to be expected, the slant of the current reddit is very obvious and its a new SJW paradise of late.

<comment><USER3> What's odd is that it was the Jesse Jackson AMA that was the straw that broke the camel's back, so to speak. There have been _far_ worse AMAs than that. (e.g. the infamous Woody Harrelson Rampart AMA)

/r/amadisasters has a good list of them: [http://www.reddit.com/r/amadisasters](http://www.reddit.com/r/amadisasters)

EDIT: Response from Alexis: [https://np.reddit.com/r/OutOfTheLoop/comments/3bw39q/why_has...](https://np.reddit.com/r/OutOfTheLoop/comments/3bw39q/why_has_riama_been_set_to_private/csq6ekp)

<comment><USER4> I remember Microsoft's AMA. I agreed with many sentiments but felt sad for Microsoft PR in the end. If this was the final straw of "mishandled AMA's" (seriously? what does AMA stand for again? don't go there if your kind of celebrity status / personality can't handle this elegantly), I think it had to do with the sensitive nature of religion. I don't doubt Jesse Jackson's team have capacity to put some pressure on reddit. Ugh. Then again, just speculation. Part of the problem is that they aren't speaking.

</comment></comment></comment><comment><USER5> When default subs suddenly go private you know some crazyness is happening...

ETA: [https://np.reddit.com/r/SubredditDrama/comments/3bwgjf/riama...](https://np.reddit.com/r/SubredditDrama/comments/3bwgjf/riama_set_to_private_over_mod_firing/?sort=new&limit=500)

<comment><USER3> AskReddit only went private because they had legit organization issues with her gone. The other subreddits apparently are going private in solidarity.

<comment><USER6> /r/science

/r/gaming

/r/movies

/r/askreddit

/r/iama

/r/law

/r/history

/r/art

all closed for now

<comment><USER5> Interesting to see how long they stay shut

</comment></comment></comment></comment><comment><USER7> [https://np.reddit.com/r/OutOfTheLoop/comments/3bw39q/why_has...](https://np.reddit.com/r/OutOfTheLoop/comments/3bw39q/why_has_riama_been_set_to_private/)

The secret popcorn groups have some more details, but it'd be interesting to see what actually happened.

EDIT: I'm interested because people here were saying that AMA was going to be the only thing to save Reddit, and that Reddit would start selling AMA opportunities.

<comment><USER3> > _I 'm interested because people here were saying that AMA was going to be > the only thing to save Reddit, and that Reddit would start selling AMA > opportunities._

/r/IAMA was the only subreddit Reddit took seriously, to the point of giving it its own iOS app and tailored design. It's also believed that high-profile AMAs (like Obama's AMA) are the largest driver of traffic to the site. (I haven't checked the data, though.)

The firing of Victoria indicates either a) bad management who don't know what makes AMAs successful or b) Reddit has alternate plans to make AMA more marketable. The lack of notice is suspicious, though.

In the meantime, Alexis is making unfortunately snarky responses to the firing: [https://www.reddit.com/user/kn0thing](https://www.reddit.com/user/kn0thing)

<comment><USER8> Am I the only one who doesn't see Alexis's responses as snarky? Given that the userbase is going to hate him anyway for dismissing a well-liked public figure and that he's already admitted that they should've communicated better with mods, I don't see what he could do differently.

I would bet on b), BTW - the only explanation I can think of for why they would dismiss a well-liked community liaison is if they wanted to monetize AMAs and she objected.

</comment></comment></comment><comment><USER9> Reddit seems engaged in a test to see how far a company built on a community can attack that community's leaders before everything falls apart at the seams.

<comment><USER10> And vice versa.

</comment></comment><comment><USER11> Will we get all the juicy details in "I am Victoria, ex-AMA liaison. AMA."?

</comment><comment><USER12> Some of the AMA can be found on Archive [https://web.archive.org/web/20150701154352/https://www.reddi...](https://web.archive.org/web/20150701154352/https://www.reddit.com/r/IAmA/comments/3brf9s/i_am_rev_jesse_jackson_ama/)

<comment><USER13> You can also read the most popular AMAs at [http://amatranscripts.com/](http://amatranscripts.com/)

</comment></comment><comment><USER14> Shameless plug for Voat.co and the subVERSE that has been tracking all of these happenings in great detail, if you are interested in more information: [https://voat.co/v/MeanwhileOnReddit](https://voat.co/v/MeanwhileOnReddit)

</comment><comment><USER15> /r/Science is gone too.

Reddit is biting the hand that feeds it...

<comment><USER6> PLoS, the open-access science publication, was putting on an excellent series [1]. Given Victoria's role in that, her loss puts that significant scientific outreach in jeopardy. A sad casualty. It was fantastic to see the front-lines of cutting edge research getting asked, answering, and otherwise motivating a lot of really interesting public discussion. Even if they repost all that old discussion (all those links on the blog currently don't work), it won't be trivial to fill Victoria's role in the upcoming AMAs, if they hold them at all.

[1] [http://blogs.plos.org/plos/2015/06/update-on-plos-science- we...](http://blogs.plos.org/plos/2015/06/update-on-plos-science-wednesday- redditscience-ama-series-upcoming-featured-plos-authors/)

</comment></comment><comment><USER16> It seems like Reddit keeps creating news for all the wrong reasons.</comment>


Rails 2.0: Preview Release - <AUTHOR> http://weblog.rubyonrails.com/2007/9/30/rails-2-0-0-preview-release

<comment><USER2> I've been running a production app on Edge Rails (straight from SVN trunk) for about a month now and it's been all good. The new-ish REST routing enhancements are great once you get your head around it. I also like the ideas behind the performance enhancements, though I haven't had a chance to really flex them yet.

Beware though, they "yanked" out a lot of common things from rails core, so if you are upgrading an existing app you may spend quite a bit of time getting things working again.

<comment><USER3> Just follow the advice of upgrading to 1.2.3 (and soon 1.2.4) first as you'll get deprecation warnings before jumping straight into 2.0

</comment></comment><comment><USER3> Looks like a nice, solid release. Lots of fixes, lots of tweaks to make things cleaner, easier, and more flexible. Nothing game changing, but a very solid job by the core team.

</comment><comment><USER4> much as I not so much a fan of rails these days, I do like the way they have embraced HTTP in all its "glory" - its a simple solid protocol that is well known. Why not embrace it !

</comment><comment><USER5> At last Rails catches up with the web...</comment>


My Favourite Diff - <AUTHOR> https://essays.jwatzman.org/essays/favourite-diff.html <comment><USER2> Recent GCC can diagnose the situation where a switch case falls through without a /* fallthrough */ comment.[1]

C++17 has a comment-like language feature for demarcating desired fallthrough.

Fallthrough in case processing is often useful; it's just not such a great default.

In the TXR Lisp tree-case[2] construct, any case which returns the : object falls through to the next case.

This is used all over the place in the library.

\--

[2] [https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Warning- Options...](https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Warning- Options.html#index-Wimplicit-fallthrough)

[1] [https://www.nongnu.org/txr/txr- manpage.html#N-03D834A5](https://www.nongnu.org/txr/txr- manpage.html#N-03D834A5)

<comment><USER3> > _not such a great default_

This is a tangent, but it reminds me of a personal policy of mine: if I'm thinking about changing a default, I ask myself if there should be a default at all.

The consequences of having the wrong default were serious enough that it even came to my attention. So by changing the default, am I potentially exchanging one set of problems for another?

Sometimes it would be better overall if the user is forced to explicitly state which way they want it. Not always, of course, but I like to ask the question.

<comment><USER4> Right! I had a bug in a SQL statement to fetch tasks "order by priority" and then execute them in that order. A stupid mistake, but I must have looked at that code tens of times and I just couldn't spot it. The bug was that that statement found then executed the _lowest_ priority items first.

It's not clear to me that an "order by" should have a default direction. I don't know why one direction is more likely to be used than the other. Without a default, I would have been forced to think about the direction and wouldn't have had that bug.

<comment><USER5> A similar example is in a "filtering" operation. I mostly have this in functional programming where you pass a predicate to filter on. But what's the perspective of the filter? Are you filtering poison from your water, or are you sifting the water looking for gold nuggets. I prefer to use functions remove and retain (respectively) to be more explicit.

<comment><USER2> GNU Make has this naming problem too $(filter pat,list ...) and $(filter-out pat,list ...).

</comment></comment></comment></comment></comment><comment><USER6> _Often my biggest contribution isn't being the only one who is able to fix something, but being the only one who realises something is fixable._

I feel relatable. At all the placed I've worked, people realize the problem, sometime find the solution, but most of the time, they won't fix it, unless it directly affect their code/project/product. As a result, technical debt keeps bubble up and we have more and more issues.

Right now, the only thing I can do is just to keep fixing issues as I encounter them. But that's for the code, I don't have any solution for the "people" problem.

<comment><USER7> I have not worked in software for long (a year, a while ago) but my experience with agile at that time was that even if you realize that you can and should fix something, you still have do political representation to the scrum master, team lead and product manager so that an issue (sorry, user story) is created and gets prioritized (over features and other bugs) in a future sprint.

Going rogue and spending an afternoon fixing stuff without an approved US (to charge time on) was not seen well.

<comment><USER8> Unfortunately this is often the case at larger companies, unless you find a really cool manager / PM to work under who just trusts you — note this can be achieved over time.

I'm talking from personal experience of going rogue :)

</comment></comment></comment><comment><USER9> This reminded me of Raymond Chen's blurb article on his blog, The Old New Thing:

[https://devblogs.microsoft.com/oldnewthing/20110118-00/?p=11...](https://devblogs.microsoft.com/oldnewthing/20110118-00/?p=11733)

For whatever reason that heavily influenced me, and now I almost always submit patches together with my bug reports. Sometimes its a whole lot more work, but I feel like this practice pays dividends in the amount you learn as well as the comraderie it fosters with the upstream devs.

</comment><comment><USER10> One annoying thing about the war on case fallthrough at the language level is the lack of imagination.

`continue` is a thing, compliments switch's existing `break` statement usage and is overall a much better solution for explicitly specifying fallthrough then returning special objects or c#'s abuse of goto.

<comment><USER11> I think it's a pretty syntax idea but it means continue works opposite your intuition inside switch statements compared to everywhere else.

I mean you could kinda argue that switch could conceptually mean something like

        for matcher, block in cases:
            if matcher.matches(subject) or continued:
                eval block

but then continue still feels magic since it bypasses the test.

</comment></comment><comment><USER12> Since there's not much context here: the article, which I enjoyed, ends with "Be the change you want to see in the world", and shows how the author exemplified this by coding a fix to a persistent source of PHP bugs at $WORK.

<comment><USER13> And it doesn't show an actual diff.

</comment></comment><comment><USER14> As a technical aside (I know it's not the main point, but still): with the ubiquity of Git workflows employing pre-merge checking on the platform of choice (e.g. Github or a CI tool), this is rather easily done via a rule in an off-the-shelf linter. No `break` in a `case`? Can't merge it.

As a language-design aside, `switch` in general is stinky stuff. Not just with the fall-through: it also violates the regular C-style syntax for no particular reason, having a mini-syntax of its own instead.

But the most perverse thing I've seen done with `switch` is using it as `if`:

        switch (true) {
            case ($a == $b): ...
            case ($c == $d): ...
            case (itsFullMoonToday()): ...
            default: ...
        }

<comment><USER15> If that's the most perverse you've seen, I guess you haven't seen Duff's device, which mixes it with a _do…while_ loop (code copied from [http://www.catb.org/~esr/jargon/html/D/Duffs- device.html](http://www.catb.org/~esr/jargon/html/D/Duffs-device.html)):

       register n = (count + 7) / 8;      /* count > 0 assumed */

       switch (count % 8)
       {
       case 0:        do {  *to = *from++;
       case 7:              *to = *from++;
       case 6:              *to = *from++;
       case 5:              *to = *from++;
       case 4:              *to = *from++;
       case 3:              *to = *from++;
       case 2:              *to = *from++;
       case 1:              *to = *from++;
                          } while (--n > 0);
       }

<comment><USER16> I have no idea if this still works in modern C, but here's something kind of similar I've seen used in C circa 1986:

      switch (foo)
      {
        case 1:
          ...code just for case 1...
          if (0)
          {
        case 2:
            ...code just for case 2...
          }
          ...code for both case 1 and case 2...
          break;
        case 3:
          ...

      }

used when two cases have a common tail, and you have sufficient space constraints that you do not want to duplicate the common tail code, and you have sufficient time constraints (and maybe space constraints on the stack) that you don't want to put the common tail code in a subroutine and call it from both cases.

<comment><USER17> Oh my god. I've wondered about a way to do this but... this is just devious.

</comment></comment></comment></comment><comment><USER18> On the contrary, I've heard of a story where a team decided to apply some new tool to their codebase which warned about a missing break, inserted the break so the warning disappeared, _" fixed" the failing tests that now resulted_, and then upon the next release was subsequently screamed at by numerous customers for the unwanted behaviour change.

 _but in a very high-level language like PHP, there's really no reason for switch to fall through at all_

I disagree. Switch fallthrough is very useful because it can reduce code duplication, especially when the logic has a ladder-like structure. Trying to impose increasingly draconian and such arbitrary rules is only going to lead to a self-fulfilling-prophecy where all the intelligent developers will get fed up and leave, and what's left are those which will continue to create tons of bugs some other way instead.

<comment><USER19> I don't think I would quit a company over a more stringent linter.

To me, this is the same attitude that leads to safety hazards in other industries. "I don't need safety measures because -I- am not an idiot".

Even the smartest developers make dumb mistakes. If you can eliminate some of those early with minimal friction, it's worth it. The earlier you catch a mistake, the cheaper it is. Linter rules are less of a hassle than bugs in production.

<comment><USER20> The kind of person who complains about the linter is the exact reason your company needs a linter.

</comment></comment></comment><comment><USER21> I did a similar thing for Chrome back in the day, to have the compiler check an `override` annotation:

[http://neugierig.org/software/chromium/notes/2011/01/clang.h...](http://neugierig.org/software/chromium/notes/2011/01/clang.html)

</comment><comment><USER22> Just a reminder that in most compiled and JIT optimized languages with switches, this

      switch (c) {
        case 4: return 30;
        case 5: return 70;
        default: return 0;
      }

compiles to the same instructions and therefore same performance as

      if (c == 4) {
        return 30;
      }
      else if (c == 5) {
        return 70;
      }
      else {
        return 0;
      }

As a side note, it's easier to see accidental fallthroughs if you write switch statements like this.

      switch (c) {
        case 4: {
          return 30;
        } break;
        case 5: {
          return 70;
        } break;
        default: {
          return 0;
        } break;

But in my opinion, the `if` statement is more clear in both cases, and only one level of indentation instead of 2.

<comment><USER23> Are you sure? I'd guess that if the cases are an interval of consecutive integers it may do a "jmp [c]" sometime.

<comment><USER24> You're correct. Many compilers will emit jump tables if the domain is dense enough. Also, even if compiling to a bunch of conditional jumps, they'll usually emit them to require O(log N) conditional jumps (equivalent to a binary tree of nested ifs) instead of the O(N) linear arrangement suggested by the GP.

<comment><USER22> Clang compiles both switch statements and `if` statements to the same tree search code. E.g. [https://godbolt.org/z/7M_3PU](https://godbolt.org/z/7M_3PU) My point is that the optimizations you're describing for switch statements are also applied to a bunch of `if` blocks, at least in LLVM-based languages with an LLVM version from the last several years.

<comment><USER24> Sure, I didn't mean to imply that compilers never (or commonly didn't) detect that long if-chains could be optimized to jump tables, lookup tables, or if- trees. I was just answering the more narrow question the GGP was asking: if switch statements were always lowered to if-chains and never compiled to jump tables.

<comment><USER22> Ah I see, gotcha.

</comment></comment></comment></comment></comment></comment><comment> joatmon-snoo Google applies ErrorProne in the default javac toolchain to mitigate this for Java builds: [https://errorprone.info/bugpattern/FallThrough](https://errorprone.info/bugpattern/FallThrough)

</comment><comment><USER25> Recently, my coworker basically asked if he should set a TTL on a password for a job we were running. We said yeah, but our code would need changes to accommodate it before it expired and we didn't have time to make them.

I joked that we'd make a JIRA ticket that we'd repeatedly deprioritize until our code mysteriously broke in 6 months, but then my coworker actually made an Outlook reminder for when we had a month left!

I thought that was really smart, so I guess I learned a lesson about actually solving problems instead of just pointing them out like a smart ass.

</comment><comment><USER26> What did you do in cases where the fall through was desired behavior? Did the resulting code (replacing a fall through with a nested if or something?) look better or worse as a result?

The typical way to handle this at companies that don't have a static-type- checker department is to require a comment that says /* falls through */ at the end of the switch. Why was such a simple solution inappropriate here?

<comment><USER27> Because code reviews are more fallible than automatic linters, and OP had the luxury of working somewhere that the noisy people didn't fight for an anti- feature.

<comment><USER26> I wasn't talking about requiring it in code review though. The OP didn't make an automatic linter that issued a warning when you did this implicitly, he removed the ability to do it entirely. With a linter, you can add a comment, like /* falls through */ to disable the lint warning. With the OP's change you can... use a series of if-else blocks? The alternative isn't listed, which is why I asked.

Sorry about your last company, though. Sounds like it was annoying to work there!

<comment><AUTHOR> OP here.

Explicitly-annotated fallthrough was still allowed; I codified a particular annotation that the analysis tool understood and allowed. I removed _implicit_ fallthrough, but _explicit_ fallthrough can be quite useful sometimes.

</comment></comment></comment></comment><comment><USER28> Some of my favourite diffs were related to linters:

\- Linting files different from origin/master in a pre-commit hook.

\- Linting everything in CI.

\- Making the linter rules stricter (mypy does a great job of having several orthogonal strictness flags, so you can pick the set appropriate for your familiarity with the tool).

\- Implementing project-specific lint checks.

</comment><comment><USER29> Cool story.

I use Swift. It does not have default switch fallthrough. After a couple of versions, I learned about the fallthrough statement.

I remember being frustrated by it, at first, but, like so many Swift oddities, it rapidly became second nature; thus, proving out that one of the goals of Swift is to train developers to write code properly.

<comment><USER30> Go also has the same behaviour, with the fallthrough keyword. I find myself using a switch so rarely anyway...

<comment><USER20> Go has a fallthrough keyword, but you can also do case "a", "b": for simple things where two cases are the exact same.

<comment><USER29> Swift allows the same thing. In fact, Swift switch statements are powerful as all git-go. You can do things like specify ranges and whatnot.

[https://littlegreenviper.com/miscellany/swiftwater/ranges- an...](https://littlegreenviper.com/miscellany/swiftwater/ranges-and- sequences/#switchranges)

[https://docs.swift.org/swift- book/LanguageGuide/ControlFlow....](https://docs.swift.org/swift- book/LanguageGuide/ControlFlow.html#ID129)

That said, I don't use them that often. They tend to take up a lot of real estate on the screen, and introduce a fair bit of CC.

</comment></comment></comment></comment><comment><USER31> If the author discovered tslint/eslint he'd be surprised that this problem was long solved in the JS world :)

<comment><USER32> I believe this happened before tslint or eslint existed.

</comment></comment><comment><USER33> So many cases about this and that, pro and cons of switch fall-through, while Pascal was King from beginning.</comment>


Current system for SSL certs has failed hard, in principle and empirically - <AUTHOR> http://permalink.gmane.org/gmane.comp.encryption.general/14253

<comment><USER2> I am very much partial to the Perspectives way of doing SSL authentication:

<http://www.cs.cmu.edu/~perspectives/firefox.html>

I don't need to know if the guy has paid someone to sign their certificate, I need to know if that certificate has been there for longer (even if it's self- signed). It's just more valuable information than whether or not a guy has $10.

I really hope Perspectives becomes standard in all browsers, then we can slowly migrate away from central signing CAs.

</comment><comment><USER3> I think there are a lot of site owners who make the mistake of thinking that SSL is only about encryption. They see these certs as a way to prevent data snooping. It's easy to see when a browser doesn't show a little lock icon or warns about an untrusted cert. The identity management side that protects against outright website forgery is harder to police and largely hidden from end users and customers of the CA's. As a result, there is probably insufficient pressure on the CA's to pay attention to some of this stuff.

<comment><USER4> _The identity management side that protects against outright website forgery is harder to police and largely hidden from end users and customers of the CA's_

If it's hidden from end users, how the hell can it actually work?

 _As a result, there is probably insufficient pressure on the CA's to pay attention to some of this stuff._

All that matters is the one CA that pays the least attention, and I don't see how site owners have any control over that.

</comment></comment><comment><USER5> > Of 16 M IPs listening on 443, 10.8 M started SSL handshake; of those, 4.3 M > used CA-signed cert chains (slide 14). Thus, the majority of servers use > "invalid"/invalid/self-signed certs.

How many of these IPs listening on 443 are public web servers? I know of a lot of things that listen for SSL on 443 that aren't HTTP as 443 can get through firewalls easily. For all we know, there already exists an out-of-band process to validate those self-signed certs.

For example, I am one of these cases. I listen for SSL on port 443 using a self-signed cert, but all clients have that CA (and only that CA) pre-loaded.

<comment><USER5> In addition, it occurs to me that I've observed many sites that aren't security critical but seem to be running on a self-signed cert. For example, many mailing list archives seem to operate both on HTTP and HTTPS with a self- signed cert. As they are only hosting public data and clearly are happy to provide it without SSL as well, there is no security failure here.

<comment><USER6> I think you would still have to count that as a security failure. For one, you don't know why there is ssl and non-ssl - there could be content that's available over ssl and/or via login which you don't see using the "public" http url schema. The server could be set up to make this transparent to you, making it appear that ssl is superfluous. Second, even if that's the case, a broken SSL implementation is still a broken SSL implementation, even if it's protecting content that doesn't seem to need protecting.

<comment><USER5> > ...a broken SSL implementation is still a broken SSL implementation, even if > it's protecting content that doesn't seem to need protecting.

That depends on what is required of the SSL implementation. A self-signed cert which the client cannot verify still provides some protection. It is MITM- able, but casual snooping is prevented. If this is the specification, then this implementation is not broken.

Put it this way. Forget the specifics of SSL for a moment. If unencrypted data is acceptable, then in what way is having the option of weak-but-slightly- better encryption suddenly "broken"?

This analysis is flawed because it assumes that strong security was required by all who use SSL at all. Many installations use a self-signed SSL cert by default. These default configurations often remain when security is not required and therefore not configured further. I suspect that this skews the figures far enough to make this sort of analysis meaningless.

<comment><USER6> Hey rlpb,

Sorry, I tried to reply to your post about 4 times yesterday, and it never went through for some reason. I agree with what you're saying about self- signed certs being not necessarily broken. Maybe I mis-read your original message, but what I was objecting to was the idea that a site that apparently has the same content available over http and [broken] https is not a problem; I'm saying that broken is broken regardless of the content it's protecting. As to what constitutes "broken" ... I think we agree - that would be SSL. :P

</comment></comment></comment></comment></comment><comment><USER6> I've used a self-signed cert for years, and eventually I got over being annoyed at browsers for lying to users and telling me that the cert was not to be trusted. The fact is, as I'm sure most at HN know, that SSL tries to solve two problems - identity and encryption. We definitely need a better way to validate a site's identity. I hope this study provides a kick in the pants toward that end.

<comment><USER7> It's a tradeoff I guess, at the low end people don't want to provide documents, wait and pay a decent amount to get their identity verified.

Maybe it would be best to separate them, you can self sign or equivalent for encryption and the identity system can be separate.

<comment><USER8> There is little point in encrypting traffic if you can't differentiate between a man in the middle and your desired endpoint.

EX: Conceder I open encrypted connection to amazone.com which pretends to be amazon.com they open an encrypted connection to amazon.com. Amazone can now pretend to be Amazon and read all my encrypted traffic.

<comment><USER6> Users can differentiate between "amazon.com" and "amazone.com" via the browser's location bar. There's nothing stopping the owner of "amazone.com" from getting an SSL cert signed by a "trusted authority", so SSL does not help in this respect. My opinion is that conflating identity with encryption is a fundamental problem.

<comment><USER8> Some _users can differentiate_... assuming they notice.

The issue is in the real world building a system to handle both typos and hostel networks requires some form of authentication.</comment></comment></comment></comment></comment>