Go Contracts – Draft Design - <AUTHOR> https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md <comment><USER2> This is too similar to interfaces for me and seems like it would only add to the complexity of the language, documentation, and compile time for a small increase in generic code.

One of Go's core strengths is simplicity. I've personally witnessed both C and Python programmers jump right into Go projects with minimal assistance. Learning new packages is absurdly easy because the code is so simple and documentation practically generates itself. I worry that widespread use of this feature would negatively impact the language in that regard.

Lacking a true "generics" feature has had an influence that people tend to overlook, which is that the Go community is less reliant on dependencies. One of Go's proverbs is "A little copying is better than a little dependency" [0]. The ecosystem is better documented and healthier because of it, avoiding the require("left-pad") world of the dependency abyss.

The language lends itself to being used for smaller, more concise code bases where things are written with specific and narrowly-defined purpose. It implicitly discourages "Architecture Astronauts" [1] and that strength shouldn't be overlooked or sacrificed for a few new container options.

[0] [https://go-proverbs.github.io/](https://go-proverbs.github.io/)

[1] [https://www.joelonsoftware.com/2001/04/21/dont-let- architect...](https://www.joelonsoftware.com/2001/04/21/dont-let-architecture- astronauts-scare-you/)

<comment><USER3> Agreed. What I don't get is why people try to change Go all time instead of simply using different languages for different problems. If you absolutely need generics in a project, there are a ton of languages out there that will fit your bill.

<comment><USER2> Yeah, for me Go is a specialized tool mostly for dealing with IO. The entire standard library and all of the builtin types are really designed for IO- centric applications which is why it's a natural fit for servers/microservices. Small, narrowly defined applications that mostly coordinate via sockets and serialization and it does those things really well.

In those worlds you're more likely to move data between logical units in JSON or Protobufs (both of which Go is good for) than to need proper generics so I don't understand the push from this subset of the community.

As far as container types and data structures, look at the number of well built storage solutions that don't seem encumbered by the lack of generics at all like: boltdb, bleve, BadgerDB, InfluxDB, etc.

<comment><USER3> What I really like about Go is the consistency of their tooling. gofmt, godoc, the GOPATH convention, single binary deployments. I like all of that.

Maybe we could port some of those ideas to other languages so that Go programmers will feel at home :)

<comment><USER4> Static compiling, common across all OSes before it became an option alongside dynamic linking.

Fast compile times, already being enjoyed by many with Turbo Pascal for MS- DOS, or Object Pascal for Mac OS, among other languages with similar support for modules.

Godoc, javadoc did it first.

Gofmt, indent was one of the first and every IDE has done it since ages.

Other languages already have those ideas.

</comment></comment></comment></comment></comment><comment><USER5> It seems as a proposal to overlap interfaces a lot.

\- Interfaces gather methods. The concrete type referenced through an interface doesn't need to know about the interface. Interfaces can be used to decouple operations from the details of the thing being operated upon.

\- Contracts gather methods. The concrete type referenced through a contract doesn't need to know about the contract. Contracts can be used to decouple operations from the details of the thing being operated upon.

Disjunction: Interfaces are resolved at runtime and result in indirect calls. Contracts are resolved at compile time and their contract-nature is lost in object code, they just become direct calls. Oh and contracts can do operators.

It feels to me like the risk here is not more syntax but less orthogonality. There will be two features competing to be the standard way to do the contract-like things.

<comment><USER6> This is because interfaces and contracts are conceptually similar. They both give you a way to abstract over a concrete implementation of some set of operations. That in turn lets you use multiple different types that support those operations.

However, they operate at different times. Interfaces are a runtime abstraction and contracts are at compile time. Interfaces are dynamic and contracts are static. This manifests itself in important ways:

* Contracts give you a way to enforce homogeneity where interfaces permit heterogeneity. Say you want a function that takes a list of objects that you can call `Foo()` on. If you define that function as accepting a list of some Fooer _interface_ , then the list you get at runtime may contain a mixture of all sorts of different types of objects, all of which implement Fooer. If your function excepts a list of a generic type implementing a Fooer _contract_ then at runtime you get a list of objects all of the _same_ type, one which supports supports Fooer.

* Because of the above, there is a runtime overhead to working with interfaces. When you pass a concrete type to something expecting in interface, that value needs to be boxed. When invoke a method on it, you need some amount of dynamic or virtual dispatch at runtime. With contracts, you can generate code at compile time that calls directly into the chosen type because you know at compile time exactly which _concrete_ type has been chosen.

So I think you're right to point out the similarities. But I think having both and having them be similar is a good thing. It lowers the cognitive load while giving more things users can express. I don't think the features will compete any more than interfaces and generics compete in other languages.

There are analogues of this elsewhere. C++ basically recapitulated this same history decades ago. Initially it only had virtual methods but no generics. You would see collection libraries that tried to define collections of arbitrary types using interfaces, but it never quite worked right. A list of ints isn't really a _subclass_ of List<T> even though there is some polymorphism going on. Templates resolved that.

Likewise, Java added generics because interfaces were not sufficiently expressive.

Rust has traits and trait _objects_. The two features are very similar and reuse a lot of mechanism, but also let you do different things. Traits are basically like contracts and are instantiated and specialized at compile time with no runtime overhead. Trait objects are like interfaces or vtables. They give you runtime polymorphism at the cost of some performance.

<comment><USER7> > However, they operate at different times.

This seems like it would be solvable by simply allowing interfaces to constrain generic parameters. Something like:

        func foo(type A Comparable, B OtherIface, C /* unconstrained */)(a A, b B) C {
            ...
        }

You'd need to allow for type parameters on interfaces, of course:

       func lookup(type A Indexable(B), B Hashable)(set A, idx B) {
           ...
       }

But there's no need, IMO, to separate interfaces and contracts.

<comment><USER8> How do u do something like a graph tho, that involves two types (nodes and edges)?

<comment><USER7>
        Graph(N,E)

What's the problem you see?

<comment><USER9> afaik there's no such thing as an interface for multiple types in Go; i.e. you can have (the equivalent of) `Foo implements Comparable` but not `Bar, Baz implement ConvertFromTo`. `Graph(N, E)` mentions two types, so you can't really express it as an interface, at least not in current Go.

<comment><USER7> But this is a single interface, with two parameters. It's effectively just a function that returns an interface type.

         Graph(N, E)

specialized with

         Graph(int, int)

is roughly equivalent to:

         interface Graph_int_int

<comment><USER9> ah, that makes sense! but what about something like

        ConvertFromTo(F,T)

? i mean, we need a single method

        func convert(f F) T

but where should it go (which type should implement it)?

<comment><USER7> The issue there has nothing to do with generics. You need overloading for what you want (and, IMO, overloading is a bad idea). Don't write code that way. Since conversion is rarely a generic pattern anyways, you just pass a conversion function in.

         func processStuff(type U, V)(a U, b V, convert func(U) V){
             bleh(a, convert(b))
         }

         processStuff(123, "foo", strconv.Itoa)

Adding the parts needed to do generic conversion functions is not a great idea. That way lies madness and SFINAE.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Some people here seem to not like the similarity to interfaces, but I think, it should be even more like interfaces. In fact, I like the interface syntax even better than the contract syntax. And the type parameter list pollutes the otherwise very clean syntax in my opinion.

So you might ask what I am suggesting. AFAIK there are two major problems preventing interfaces to be used as generics:

1\. There is no way to require the methods of builtin types aka operators.

2\. Compile-time type safety is very limited

The reason why interfaces have no access to operators and other language features is that the language is kinda rough around the edges. And I really don't want to hurt anybody with this statement. I love the language, but I think there are some things that aren't perfect.

For example, just imagine every array/slice would have a method (e.g. Position(int)) that would be the equivalent of the square brackets and the square brackets would be just some syntactic sugar like

      arrayA[0] == arrayA.Position(0)

Same thing for operators like +

      x := 1
      x + 2 == x.Addition(2)

It would eliminate a lot of cases that make contracts necessary. In essence, it would mean that you could actually address built-in types in interfaces.

The second problem is related to the type parameter list. In my opinion, it would be better to simply put those types on extra lines like:

      type T Generic
      func Print(s []T) {
        // function body
      }

I mean, there should be no problem in making them available for more than one function and it would definitely clean up the function signature and look more Go-like.

<comment><USER11> Agreed, though I think the syntax problem (too many parens) could be made more readable and Go-like by emphasizing the generic aspect and making it stand out visually -- leaving no doubt that you're in a section that's generic, and perhaps dissuading overuse by making it noisy. Perhaps something like:

      generic func(T, U) Map(slice []T, mapper func(T) U) []U

For "contracts":

      type Set generic interface(T comparable) {
        Push(T)
        Pop() T
      }

Every time you want to refer to a generic type you'd have to use the generic keyword, which encourages use of concrete types:

      type IntSet generic Set(int)

This is more or less how Modula-3 does it. Generics have dedicated syntax with a "generic" keyword.

</comment></comment><comment><USER12> If you poke around the files ending with .go2 here[0], you can see some examples of contracts/generics being used. This linked review is a prototype of the implementation for the proposal.

[0] [https://go-review.googlesource.com/c/go/+/187317](https://go- review.googlesource.com/c/go/+/187317)

<comment><USER13> This is why even the most basic form of generics would be amazing for reducing boilerplate: [https://go- review.googlesource.com/c/go/+/187317/3/src/go/pa...](https://go- review.googlesource.com/c/go/+/187317/3/src/go/parser/testdata/set.go2)

</comment></comment><comment><USER14> I haven't been following these proposals and I want generics of some kind in Go (I've had my fill of code generation), but good God does the proposed syntax of using parentheses for yet another thing (in addition to method receiver, parameters, return types, logical grouping, arguments) make the language suddenly feel cluttered and hard to read.

<comment><USER15> And it is basically notation noise. The idea is to inform the compiler as to which type names are generic.

       // proposed
       func Print2(type T1, T2)(s1 []T1, s2 []T2) { ... }

vs

       // less noise
       func Print2(s1 []'T1, s2 []'T2) { ... }

This proposal does -not- seem to be informed by the same 'outer space' mindset that gave us the Go language. A reminder that mere capitalization in Go language informs visibility and access.

Beyond mere syntax issues, the semantics of generics itself is adding huge complexity to what is a very capable and accessible 80% language.

<comment><USER16> I really don't think generics (or contracts) will benefit the language. Most people who miss it are just missing the collection frameworks from Java/C#, and there are solutions to this anyway. (go:generate being one of them if you really need collections for X types).

I did miss generics when I first started writing Go, but after doing so for about a year at work and 2 years before that, I don't find me missing them at all.

<comment><USER17> I have the exact same feeling. I was using generics extensively in C# particularly. I don't miss them at all after having spent a lot of time working with and understanding Go. I can't help but feel it will just make the language far less attractive in the long run.

<comment><USER16> Yeah I believe so as well. All languages having the same features would also be a downside. Just make a choice and stand by it. (Like Haskell, they are not pressured into doing things just because Java does so).

<comment><USER18> _Like Haskell, they are not pressured into doing things just because Java does so_

I do not mean this as a criticism of Haskell, but Haskell has _a lot_ of GHC- specific language extensions:

[https://downloads.haskell.org/~ghc/latest/docs/html/users_gu...](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html)

I am not sure it qualifies as making a choice and standing by it.

</comment></comment></comment></comment></comment></comment><comment><USER19> It is interesting to compare the mostly negative reception here with the more postivive over at reddit.com/r/golang [1]

Granted, that community in average probably contains more "Go fans". There was no lack of criticism at the try proposal over there though.

1: [https://www.reddit.com/r/golang/comments/cifdwf/the_updated_...](https://www.reddit.com/r/golang/comments/cifdwf/the_updated_and_simplified_draft_design_for_go_2?sort=confidence)

</comment><comment><USER20> I read through this yesterday and I'm fairly confused about all that.

1\. This is a long proposal. Excluding the implementation/issues/comparison parts, it clocks in at 7700 words. Compared to the 27k-word long Go spec, this is epic. I know the proposal is more verbose than the eventual spec (if accepted), but still... 2\. There are some valid points in Nate Finch's criticism of the previous proposal ([https://npf.io/2018/09/go2-contracts-go- too-far/](https://npf.io/2018/09/go2-contracts-go-too-far/)). Be it philosophical arguments or just plain syntax ones - like writing `func (...)(...)(...)` in function declarations.

I don't know. I'd like some form of generics in the language, but I'm not sure if complex designs like this are likely to be embraced by the community.

<comment><USER21> I think the complexity / length is a good indication as to why there's resistance to adding generics to Go; frequently, Java generics are cited since (and this is from the top of my head) it almost doubled the size of both the Java spec and its implementations (compiler, runtime). That is a lot of complexity to manage, and runs counter to what I believe is the current mindset of the Go language.

And in Java it didn't stop there; the people (person?) behind generics moved on to create Scala, a language with even more features and a notoriously complicated 25-step compilation process (see [https://typelevel.org/scala/docs/phases.html](https://typelevel.org/scala/docs/phases.html)) (compare with Java's six phases [https://www.javatpoint.com/compiler- phases](https://www.javatpoint.com/compiler-phases) and Go's... three? Not sure, I found [https://getstream.io/blog/how-a-go-program-compiles-down- to-...](https://getstream.io/blog/how-a-go-program-compiles-down-to-machine- code/)).

edit: Actually most of my knowledge comes from [https://news.ycombinator.com/item?id=9622417](https://news.ycombinator.com/item?id=9622417), I had bookmarked it.

<comment><USER22> > And in Java it didn't stop there; the people (person?) behind generics moved > on to create Scala, a language with even more features and a notoriously > complicated 25-step compilation process

What does this have to do with anything? Scala is complex to compile for reasons far, far beyond generics. Are generics somehow _guilty by association_ because an engineer who was once involved in an implementation of them went on to build some other complex thing?

</comment></comment></comment><comment><USER23> I don't like this at all. This is a classic example of a feature where, in the right hands its very powerful, but in the wrong hands it will ruin the simplicity of the logic it touches. Go's magic was really in its ability to be placed in the wrong hands and still end up with a serviceable program.

<comment><USER24> I find the position that the real solution to incompetence is to just give people blunt knives to be utterly unsatisfactory. If someone cannot understand how exceptions work for example I have a hard time seeing how removing this massive burden from their minds will result in good outcomes. Being easy to use for people that probably would be better off doing something else is not a solid design principle.

Java went down this route, ah, we will remove operator overloading, that will make it simpler, because nobody can ever write a function named equals which does not do what you expect it to... and the end result is horrible and does not prevent people from doing amazingly dumb things.

<comment><USER25> To quote Rob Pike:

>The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.

If Google, with its intensive algorithmic interviews, can't manage to hire people capable of understanding something like:

      func max(T: Comparable)(a, b T) {
        if a < b {
          return b
        } else {
          return a }
        }
      }

And why we'd prefer that over having to rewrite the function for int8, int16, int32, int64, uint8, uint16..., then what hope is there for anybody else?

<comment><USER23> The funny thing is; your code has a syntax error (two, actually).

Its dumb to nitpick, but its symbolic of the problem; even if you're so sure that you have no mistakes, that what you've written is well designed and will work well... you're probably wrong. Even the simplest blocks of code will have issues, and the language should do everything it can to help this.

No one likes to be told that all they deserve is a blunt knife, but frankly, it's more true than it isn't. I'll gladly wield that blunt knife if it means I get to build awesome products that don't break at 2am.

(Edit) I made a mistake in my analysis of your code; there's actually three errors. Everyone makes mistakes. Our tools shouldn't encourage us to make more.

<comment><USER25> Now imagine if I'd copy-pasted that code for every builtin int and float type; there'd be ~ 36 errors.

<comment><USER23> That's a fair point, but it harkens back to the argument we see a lot for generics; "we'd have to repeat that 5 times for int8, int16, int32, int64, and just int, not to mention floats!".

I think there's a problem of complexity with that core argument. Why are you replicating this function 5 times? Why not just use `int`? Or just `float`? In other words, you're creating a solution that is (probably) too complex, and to manage that complexity you're asking for more language complexity. How about we attack the root of the issue: why is the solution so complex? Can we reduce that complexity?

More often than not, we can. Developers tend to over-engineer things, and Go's type system is a forcing function toward simplicity. Every once in a while, we run into a problem that would benefit from generics. But its _very_ rare. The cost of "having" generics in every situation, including many where you don't need them, far outweighs the cost of being forced to grab `interface{}` or `reflect` in the very few situations where you don't have them. The problem is: It's not as obvious that this cost is higher. That's the challenge the Go team has had over the past few years; convincing us, who hold a loaded gun pointed straight at our foot, to not pull the trigger and turn this language into Java2.

</comment></comment></comment></comment></comment></comment><comment><USER26> I still think that, for the most part, Go doesn't need contracts (yet). I think it's common, coming from the object oriented world, to expect polymorphism to be intrinsically tied to method overloading. But it doesn't have to be.

Of the 12 examples at the end of the draft, there is only one real contract used, `comparable`, which could be easily done without contracts (but with generics) by passing in an extra argument `lessThanOrEqual func(T, T) bool`.

The other kind of contract is harder to do without contracts, as it is the contract which combines all numeric types. However, most of the examples would be possible to write, albeit a little more messily, with a parameter `toDouble f(T) double`. Alternatively, we could go the route of baking in a few special contracts into the language, such as a numeric contract, just like how map and slice are baked in polymorphic structures.

What do we gain from writing code this way? It leaves the Go language with more freedom from the future. Everyone agrees Go needs polymorphism. So add polymorphism. But as we can't agree on contracts, we can just leave it out. We'll get 90% of the benefits upfront, and then we can wait and see what are the actual edge cases we run into with contracts, and decide where to go from there.

<comment><USER27> _I think it 's common, coming from the object oriented world, to expect polymorphism to be intrinsically tied to method overloading. But it doesn't have to be._

Please provide some examples. For example, I don't think polymorphism in direct variable references is all that good.

 _It leaves the Go language with more freedom from the future. Everyone agrees Go needs polymorphism. So add polymorphism._

This statement confuses me. Go has polymorphism.

<comment><USER26> If you go and look at the Map/Reduce/Filter, Channels, Containers, and Append sections of the examples, there isn't any use of contracts. All that is required for those sections to work is to declare a type parameter, and then allow that parameter to be filled by any type, but still typecheck that all of the variables with the same parameter are the same type at the calling site. There's no need to have a contract for which methods can be called on the type, because we don't need to call any methods or access any fields. In my experience, this fills most use cases. It allows generic data structures, and generic functions over those structures.

If you need a little bit of behavior for those types, such as for a TreeMap data structure or a Sort function, Go's higher order functions make this possible without contracts, by passing in functions. The draft's Containers section uses this approach to construct a TreeMap. The SliceFn function, described in the Sort section, also uses this approach:

        func SliceFn(type Elem)(s []Elem, f func(Elem, Elem) bool) {
         Sort(sliceFn(Elem){s, f})
        }

Although this does use method overloading via contracts in implementation (via Sort), it doesn't need it. I expect that Go's existing interfaces (which yes, are a form of polymorphism, mea culpa) + unbounded parametric polymorphism are enough to solve 90% of Go's current issues.

The more complex cases are still possible to handle with parametrically polymorphic structs containing functions. Yes, that's bad code, but we'd be able to look for this use case, judge how often it occurs, and use it's use cases as data to inform further discussions on contracts.

The only case I struggle to easily deal with is the numeric case. My solution doesn't allow generic numeric functions, although I think there's room to explore that in more detail.

<comment><USER27> _If you go and look at the Map /Reduce/Filter, Channels, Containers, and Append sections of the examples, there isn't any use of contracts._

I see. I'm of the opinion that the Go team might be more cautious and introduce a more limited form of generics first, which seems in line with what you're saying.

 _In my experience, this fills most use cases. It allows generic data structures, and generic functions over those structures._

How would one make something like ConcurrentMap? Perhaps some operations on a map could be exposed and "overridden?"

<comment><USER26> It would be simple to write a ConcurrentMap.

What is more difficult is writing a function which accepts both ConcurrentMaps and TreeMaps. In Java, they would both inherit from Map. In this proposal(/Rust/Haskell) they would implement the same contract(/trait/interface). In my proposal... there isn't an elegant solution.

In some cases, you can write the function to be generic over an insertion function `insert func(T)`, if all you need is assertion, and then you can pass `treeMap.insert` as the parameter. If you really truly need to be generic over the entire `Map` interface, that is one of the cases that I claim only takes up 10% of the cases. In that case, you could define a type which contains all of the functions a Map needs, and then you could construct that and manually pass that in.

This can be viewed as a desugaring of contracts. One implementation that contracts could have would be to, at runtime, construct and pass a value containing the functions that the contract specified are possible.

<comment><USER28> It's "typeclass", not "interface". Though it works similar and is, in fact, just a way to define a constraint.

As of your described way of desugaring the contract, looks way too cluttered. It's exactly the reason why Reader and ReaderT exist in Haskell. Even though the proposal's contract syntax doesn't look very beautiful, it's still drastically better than keeping track of drilled structs of functions, the latter will become a mess really really fast, so having a way to conveniently constraint the accepted types while having a full-blown parametric polymorphism is essential for a modern language. Not sure exactly why anyone would be against that.

<comment><USER26> Sigh, I really need to read my posts before submitting. You're right, of course it's typeclass.

The whole point is to implement the bare bones of a parametric polymorphic system without constraining further development of the language. Additionally, it discourages complexity and requires explicitness, two goals of Go.

As far as my description of desugaring the contract, that is literally how Haskell implements typeclasses.

<comment><USER28> Well, yeah, Reader is that kind of thing.

I guess that the complexity people are concerned about is that once you implement a parametric polymorphism, HKTs are inevitable and that probably requires some brain flexing in order to get the meaning of a structure, which defeats the main purpose that is being explicit and simple. Pretty much a deadlock. I now understand why the community is so in odds with the parametric polymorphism as the concept but I'm also sure that simplicity of use and convenience of writing a robust solution is the two things that require it. You can't keep your head near the sand and avoid HKTs when you want flexibility and you can't allow that type of polymorphism whilst striving for what's Go trying to do.

While understanding the both standpoints, though, I still hope that Go will get parametric polymorphism as it's just so much more pleasant and convenient than carrying around a mess of structures to be explicit no matter the costs.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> The proposal has a very short statement about implementation. If you think about this very carfully, you realize that part of the compilation speed of go allows you to compile a single package into code without having to leak out all of you abstractions.

If you have contracts/generics then you need to have un-compiled code as part of your exports. Which is a huge break from the current approach.

<comment><USER6> Yeah, I'm _very_ interested in how they plan to integrate this into separate compilation. My understanding from C++ and C# is that this is a hard problem.

<comment><USER30> In Rust, we end up storing the necessary metadata inside of the pre-compiled library, so that when you use it from another library, the compiler knows how to do the right thing.

</comment></comment></comment><comment><USER31> Why "Contracts" and not "Generics"? To make it less contentious, maybe, or to manage expectations?

<comment><USER32> golang likes to reinvent the wheel and call it something else. We've already seen it with exceptions (which they called "panics"). Contracts already mean something else (see contracts in C++, C#, D, etc.).

What they're proposing here are basically trait bounded generics. They just don't want to use the word "generics" because of the following attitude:

"The key point here is our programmers are Googlers, they're not researchers. They're typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They're not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."

<comment><USER33> Man you Go haters LOOOVE to trot out that quote from 2014.

But you know what, go _is_ easy to learn, and that's been awesome in my experience. I can (and have) hired people who have never written go, and they're productive in a week or two.

<comment><USER32> That's not really a good metric to target. They can be productive in a week, and because the language is very weak and verbose, you'll end up with a messy code base. I see this all the time at an employer.

<comment><USER33> ....in Go?

</comment></comment></comment></comment></comment><comment><USER34> This is really bike-shed-y, but:

I'm disappointed they didn't go with «» or similar to set apart type parameters. The answer in the doc is that they "couldn't bring ourselves to require non-ascii", but there's an easy way to handle this without _requiring_ non-ascii characters: let "(type …)" and "«…»" be syntactically identical, and have gofmt change the former to the latter. Basically everyone uses gofmt all the time, so all the code everyone reads would use the more visually distinctive syntax, but it would be easy to type using ascii only.

<comment><USER35> Why not just << and >> then?

<comment><USER34> That doesn't work for the same reason that < and > don't work, right? They are existing operators in the language, so the parser would need unbounded lookahead. Using a different set of characters is unambiguous (and additionally is more compact).

</comment></comment></comment><comment><USER36> I think the examples at the end of the document really show the power of the proposal.

But, there are some aspects that will make code appear more complex or challenging to read. It will certainly make it more challenging for beginners.

Appearance of the code with type switches and issue with the idea of Iterator and doing something two different ways were the only parts that stood out to me besides increased complexity

</comment><comment><USER37> "Although functions may have multiple type parameters, they may only have a single contract."

Anyone else find this limitation a bit disappointing? Seems like a somewhat arbitrary restriction that limits the usefulness of this feature. I hope it doesn't take another 10 years for this to be changed...

<comment><USER38> it looks like contracts are composable the same way interfaces are so I don't know how much of a limitation this will be in practice.

<comment><USER37> So I am a bit unclear on this from the proposal.

Composing contracts is a slightly more verbose fix for allowing multiple contracts for a given type (just make a composed contract and specify that).

Using composed contracts, allowed:

        func Foo(type T PrintStringer)(s T) {...}

I read this as, while a function can have multiple type parameters, only one contract can be specified _in total_.

Not allowed (function uses "setter" and "stringer"):

        func Bar(type B setter, S stringer)(box B, item S) {...}

Maybe I'm misunderstanding though.

In other languages with parametric polymorphism, the real re-use comes in by allowing functions like Bar to be used for any combination of "constraint implementing" types.

<comment><USER22> > Maybe I'm misunderstanding though.

As I read it, while you can't do:

        func Bar(type B setter, S stringer)(box B, item S) {...}

directly, you accomplish the same thing via

        contract SetterStringer(B, S) {
            setter(B)
            stringer(S)
        }
        func Bar(type B, S SetterStringer)(box B, item S) {...}

so in practice it's basically the same thing, you just have to explicitly specify the contract the function conforms to via a composition of the two other contracts.

<comment><USER37> This is a good point.

So maybe my concern is more a verboseness issue rather than expressiveness.

That said, it would be nice if there was some commentary on whether an implementation like Swift's was considered and ruled out for some reason. As it reads now, I stand by my original comment that this restriction seems a bit arbitrary.

<comment><USER22> I'd be very interested in that as well, and I agree it seems verbose simply for the sake of maintaining a one-one func-contract correspondence.

Maybe there's some trade-off I'm not seeing here, though.

</comment></comment></comment></comment></comment></comment><comment><USER39> I cannot fully express the frustration I deeply feel with people constantly proposing changes to Go that will turn it into something that is no longer Go!

I know where this specific proposal is coming from, but I feel that Robert and Ian are being pushed by the constant noise made by people coming from other languages, people who like those who made the horrible "try" proposal, seem to be trying really hard to ruin Go by turning it into yet another complex monster.

Not a day goes by without someone making a new proposal that is trying to change the very thing that made Go so unique and lovable!

All the proposals that has been made so far exists in several of the other popular programming languages. Use one of those if you really want the added complexity - leave Go just the way it is!

</comment><comment><USER40> I am totally against generics, if you want generics, go to Python, or somewhere else that allows them. The beauty in Go is that it is static, and generics are not strict. I agree with wybiral [1]. This only serves to add complexity that gains very little, and opens Go to being less strict and there for less reliable and more problematic at compile time .

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

edit: changed "strict" to "static"

</comment><comment><USER41> Took me a while to realize that this is not about "contracts" the way this concept is generally understood, but Go's versions of generics.

</comment><comment><USER42> I really see no reason for these. The difference could be easily seen in the types themselves. I've posted that elsewhere but you could have an

      func thing(stuff _.T, stuff2 _.k)

      Or

      func thing(stuff g.K)

And so on.

Also want to point out that there is a LOT of Golang code that is being shipped and used in the world and none of it uses generics. Do we really need them?

<comment><USER43> A lot of assembly code was being shipped before we had better languages. That's no reason to be stuck with a type system of the previous millennium.

<comment><USER42> I honestly think generics are like oop. Vastly overestimated.

</comment></comment></comment><comment><USER44> > Type assertions and switches

I find it especially unorthogonal that you can type switch on generic parameters like they are interfaces. If I have a method that takes interface parameters, should I just always use generic (unboxed) parameters instead?

</comment><comment><USER45> Why not extend the interface ? It would be less of an interface and more of a generic but may provide easier upgrade path, wouldn't it ?

<comment><USER46> There's a whole section in the document literally titled "Why not use interfaces instead of contracts?"

</comment></comment><comment><USER47> How (and when) does a Draft Design become a Proposal to be discussed officially on GitHub?

</comment><comment><USER48> tbh I just want sum types but whatever</comment>


Wikileaks: Police Arrested Movie Pirate As "A Personal Favor" To Movie Official - <AUTHOR> http://torrentfreak.com/wikileaks-police-arrested-movie-pirate-as-a-personal-favor-to-movie-official-110430/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Torrentfreak+%28Torrentfreak%29 <comment><USER2> I hope by now those on HN skeptical of Wikileaks have been sufficiently won over.

<comment><USER3> How so? Those that have argued against Wikileaks on here have argued against the 'shotgun' approach to releasing all of the cables regardless of whether or not they contain incriminating evidence.

How is finding bad things within the deluge of cables going to win someone with that opinion over?

<comment><USER2> I think the reason Wikileaks has not filtered the cables (aside from some minor redacting to avoid putting lives at risk) is to retain credibility as an unbiased reporting organization.

We have learned that (in the case of the Iraq/Afghanistan releases), much of what was deemed "secret" was done so simply to prevent embarrassing info from entering the public domain. In other words, for propaganda reasons. There was not any national security or safety reason to keep the information secret.

Filtering the cables to reflect what one group deems "incriminating" would be just another form of propaganda, something Wikileaks does not wish to engage in.

<comment><USER4> > Filtering the cables to reflect what one group deems "incriminating" would > be just another form of propaganda, something Wikileaks does not wish to > engage in.

Exactly. And it is certainly news to me that anyone here on HN is critical of WikiLeaks as they have done what any journalists do: by shining a light on the worlds most powerful for the benefit of all of us. There is no real difference between how WikiLeaks or The NY Times achieve their goals, except WikiLeaks is not beholden to anyone, so the have more credibility. Unlike Bill Keller and the NYTimes, they don't work with the White House to see if it is OK to print something. Because they are a stateless entity, they are able to break more stories than any news agency, and this year have broken more than all of them combined. But they have done so at great personal sacrifice. Julian Assange (and WikiLeaks) whatever your personal feeling are about them, have made an enormous personal sacrifices so that we may all benefit. Aside from the usual arguments that have been soundly debunked about the dangers of mass dumping un-redacted documents, what fault could anyone at HN possibly have with WL?

<comment><USER2> Well said. Bill Keller has really lost a lot of credibility as a journalist with his ad hominem attacks against Assanage and tabloidesque coverage of many matters relating to Wikileaks.

</comment></comment></comment></comment></comment><comment><USER5> I have heard unverifiable stories of similar "personal favors" in San Francisco, too. Not to mention the legal wild-west that is China and India...

</comment><comment><USER6> He committed the crime,and was successfully prosecuted for it. The personal favor was not the arrest, it was assigning an agent or two to investigate the case.

This is not much different from asking your cop friend to give a ticket to your neighbor for parking too far out into the street, or asking the zoning board to investigate a neighbor's unapproved addition.

<comment><USER7> > He committed the crime

Unless I misread the article, camming was not a crime where he lived at the time he was arrested. What the article describes is the police harassing someone because someone with lots of resources asked politely for an illegal favor. Or, to put it more bluntly, the police decided it was OK to break the law because the MPAA asked for it.</comment></comment>


Ivan Chisov - <AUTHOR> https://en.wikipedia.org/wiki/Ivan_Chisov <comment><USER3> There is also [https://en.wikipedia.org/wiki/Vesna_Vulovi%C4%87](https://en.wikipedia.org/wiki/Vesna_Vulovi%C4%87)

<comment><USER4> That's a really depressing read

</comment></comment><comment><USER5> Very interesting story.

Totally unrelated, but when I was 20 I witnessed a friend of mine hit a curb while riding his crotch rocket at over 110mph. He flew for a good 75 to 100 feet in the air and landed on very-long (uncut) damp grass. Concrete surrounded the small portion of grass (located between the sidewalk and the parking lot). Anyways, he was knocked out, life-flighted, and I thought he was surely dead. He ended up with nothing more than a bruised rib, released 12 hours later. Oh, and a totaled motorcycle + life-flight bill :).

When the cops came to try to gather evidence of street racing or other type activities we pulled the routine of "yeah we didn't see what happened - <USER2> looking the other way unfortunately, officer". He had suffered enough for that episode.

</comment><comment><USER6> Reminds me of an American but I can't remember who that survived a severe thunderstorm?

<comment><USER7> William Rankin ?

[https://en.m.wikipedia.org/wiki/William_Rankin](https://en.m.wikipedia.org/wiki/William_Rankin)

<comment><USER8> I wonder if I'm the future that might become a sport like BASE jumping.

<comment><USER9> While BASE jumping is dangerous it's not nearly 100% suicidal so probably not.

</comment></comment></comment></comment><comment><USER10> I perhaps wonder if he survived due to his unconcious state. Similar concept to how drunk drivers generally suffer less injuries due to their body being relaxed upon impact.

</comment><comment><USER11> > for a month his condition was considered critical. Despite his injuries, he > was able to fly again three months later.

Wow, that's dedication. He had the perfect excuse to not fight and he went back into a super-dangerous job.

I guess the war and flying in combat missions can be the most exciting thing for some people in these (often) rural people's lives. Plus the need to defend your country/people from a very real threat.

<comment><USER12> Worth noting, this was still early in 1942 when the NKVD would shoot you in broad daylight for openly expressing sentiments that were not irrationally patriotic.

<comment><USER13> Don't know why this is downvoted. It was indeed probably safer in a plane than back home with the NKVD.

<comment><USER14> The NKVD was more than present at the front. The 'V' part of their name points to their _military_ mission.

<comment><USER15> V for Vnutrennih (Interior)

[https://en.wikipedia.org/wiki/NKVD](https://en.wikipedia.org/wiki/NKVD)

</comment></comment></comment></comment></comment><comment><USER16> So, I see this is a hot topic on hn. So I recommend [http://www.greenharbor.com/fffolder/ffresearch.html](http://www.greenharbor.com/fffolder/ffresearch.html)

While this is exciting, it is not singular.

</comment><comment><USER17> Is it possible to maintain consciousness jumping from that heigh without another air supply?

<comment><USER18> > Due to the thin atmosphere at that altitude, however, he lost consciousness > and was unable to pull the rip cord.

<comment><USER17> Well that is what made me ask. I was wondering if it was possible at all.

<comment><USER19> It's possible for climbers (though a climber doesn't experience the _rapid_ decompression that a jumper would).

Mount Everest at 29,028 feet is significantly higher than the 23,000 foot fall that Ivan Chisov survived, yet a few rare people have climbed Everest without oxygen:

"Reinhold Messner championed the cause for ascending Mount Everest without supplementary oxygen. In 1978, he reached the summit of Everest with Habeler. This was the first time anyone had been that high without supplemental oxygen and Messner and Habeler achieved what certain doctors, specialists, and mountaineers thought impossible."[1]

Messner went on to climb all fourteen eight-thousanders (the 14 mountains that are more than 8,000 metres or 26,247 feet) without supplemental oxygen.

[1] [https://en.m.wikipedia.org/wiki/Reinhold_Messner](https://en.m.wikipedia.org/wiki/Reinhold_Messner)

<comment><USER17> I wonder how they felt / were they really struggling / miserable or largely unaffected?

<comment><USER20> They were miserable, mountaineers however are used to misery and suffering it is part of the activity.

The hard part is that you become much slower, weaker and you judgement is impaired. Also different people have different ability to adopt. Except for Sherpa who have evolutionary adaptation, in normal population there are not that many people who can do it even if they trained their whole life.

No oxygen climbing if you can do it is in some way safer. You go faster, you do not depend on heavy canisters. You do not need to stock upper camps with oxygen. All of this minimizes objective danger(avalanche, serac falls etc) the shorter you are up the safer you are.

<comment><USER21> I read that Everest climbers start with as many as 70 tents. Most are to hold supplies (and other tents) at progressively higher/smaller camps, eventually resulting in the last tent at the highest camp before the attempt on the peak.

So dozens of trips are taken to ferry tents/supplies up to the next camp. Which add risk for every hour on the mountain.

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> I'm wondering if the snow cushioned his fall.</comment>


Ink: React for interactive command-line apps - <AUTHOR> https://github.com/vadimdemedes/ink# <comment><USER2> Some time ago I built a (terminal) text editor and one of the challenges is to implement the renderer which is normally done by messing with termios and changing some terminal parameters - as this is "device"-dependent there exist databases like terminfo and abstraction-layers like curses which give you an API similar to "Write this text at position x/y in green".

However curses and terminfo are big programs and most terminals they support are not in use anymore, so if one is OK with supporting just 99.9 (and not 99.999 like curses)% of modern terminals (say xterm, linux-console, st, urxvt, $otherterm), it is feasible to roll your own or use an alternative like e.g. termbox ([https://github.com/nsf/termbox](https://github.com/nsf/termbox)).

It provides a simple API like "write Unicode-Char to position x/y in specific $style" and some utility functions to setup the terminal (e.g. one has to consider how to react to window-size (== terminal rows/cols size) events). You can then write your app similar to a game-loop like the following:

      while state['should_run']:
        render(state)
        update(state)
        get_input(state)

I think such an API is pretty nice to work with - this is different to the React approach, but for writing terminal GUIs like text editors it worked pretty well for me.

Many (native) games use a similar approach when rendering menu's and stuff and although there are terrible ones most menus of games look pretty slick.

<comment><USER3> (just to emphasize, I think parent understands this)

The render function here can be stateful, React vdom-style: diff with previous output, efficiently update output based on the perf characteristics of a terminal. But it's an entirely separate domain, which is great for the developer.

</comment></comment><comment><USER4> Surprised to see that this doesn't use ncurses at all. I was really hoping to see something that brought the painlessness of using React to building an ncurses textual interface.

Seeing that it doesn't use ncurses, I'm suspicious of how it does re-draws. I'd imagine the naive thing of just redrawing every bit of text on the screen for every reactive event would work, but be pretty slow. Of course, if they're doing something smarter than this, I'd be interested to hear how it's done.

<comment><USER5> If you keep an internal representation of the terminal (which you should totally do when building a terminal toolkit), you can just update whatever changed. It is not hard with cursor positioning sequences.

<comment><USER6> This is what [n]curses does, since decades ago.

<comment><USER5> Well, my point is that everyone can do this, ncurses is no black magic :)

</comment></comment></comment></comment><comment><USER7> If anyone is interested in using _actual_ React for the same purposes, check out react-blessed: [https://github.com/Yomguithereal/react- blessed](https://github.com/Yomguithereal/react-blessed)

<comment><USER8> Given it's barely updated and only has official support for React 0.14... it's not really something I'd recommend.

Shame too, it has the potential to be great.

<comment><USER7> It not being the latest version if React is hardly a major issue. You miss out on some of the latest optimizations, but the API hasn't changed.

<comment><USER9> Which is actually a really good argument for avoiding this project - if it's so easy to stay compatible, then... stay compatible. Feels like a dead project if it's so far out of date.

</comment></comment></comment></comment><comment><USER10> What ever happened to terminal "apps" being streams of text? Is just the JS ecosystem that does this or are others seeing the same trend?

<comment><USER11> vi's initial release date is from 1976. Maybe you could ask someone who used it back then whatever happened to terminal apps being streams of text? :)

This is an interesting idea; a React-like layer to something like ncurses could be super useful and encourage more command line apps. Doing this in JS seems like a waste though...

<comment><USER12> I'm hopeful that someone will add a terminal mode interface to VSCode. In theory, this would allow it to even run without Electron (using just NodeJS). The team was shrewd enough not to expose too many internals through the extension interface in the original design, so it's not intractable (at least not as high up on the scale of intractability as making non-breaking changes to Firefox).

</comment></comment></comment><comment><USER13> Would it be possible to write an editor in Ink?

<comment><USER14> Right now, you can't even know the height or width of the terminal. So, I think you would need to start there.

[https://github.com/vadimdemedes/ink/issues/5](https://github.com/vadimdemedes/ink/issues/5)

</comment></comment><comment><USER15> What terminal emulator is being used in that image?

<comment><USER16> Answered in the issue tracker: [https://github.com/vadimdemedes/ink/issues/10](https://github.com/vadimdemedes/ink/issues/10)

</comment></comment><comment><USER17> Nice project but why using REACT for this as REACT is designed for dom manipulation

<comment><USER18> Well, no it isn't. ReactDOM is designed for consuming the output of React and constructing a DOM-based UI. React itself is fundamentally a reconciliation engine. This is why we've seen React move to such places as React Native (React for native iOS and Android interfaces), React-UMG (React for constructing interfaces in Unreal Engine's Unreal Motion Graphics), React-PDF for generating PDFs, the list goes on. You can view more here:

[https://github.com/chentsulin/awesome-react- renderer](https://github.com/chentsulin/awesome-react-renderer)

<comment><USER19> > React itself is fundamentally a reconciliation engine.

Do you know of any good articles / books / videos that talk more about this idea?

<comment><USER20> Yeah - my React/Redux links list has a big section of articles that talk about React's implementation, including both articles that dig into the actual React source and implementation, and many "build-a-mini React" articles: [https://github.com/markerikson/react-redux- links/blob/master...](https://github.com/markerikson/react-redux- links/blob/master/react-implementation.md) .

<comment><USER19> Thank you!</comment></comment></comment></comment></comment>


Apple Wants To Block You From Using Your iPhone Camera At Live Events/Concerts - <AUTHOR> http://www.redmondpie.com/apple-wants-to-block-you-from-using-your-iphone-camera-at-live-eventsconcerts/

<comment><USER2> > A new Apple patent will put an end to recording events

Patent does not put an end to anything. First it must be implemented, second, even if implemented this will only work at these events where technology is actually put to use.

And patenting something does not imply company really _wants_ to do that. I guess some stuff got patented exactly just to stop others from doing something.

</comment><comment><USER3> Bit of a difference between patenting something and it actually turning up in iOS as a "feature"

</comment><comment><USER4> Consider another use for this idea: it would allow governments to prevent all those photos/videos of rights violations that we've been seeing a lot of lately.

<comment><USER5> How about another?

It would mean I can stand behind people at a concert or other live event and actually be able to see the act rather than 3000 phone screens lighting up the arena

<comment><USER6> Nope, not everyone has got an iPhone. Androids will blow your arena.

</comment></comment></comment><comment><USER7> > something that could cost more than just letting people record the event > itself and sharing it on their websites.

What, $1+ ? Honestly the only people that lose out from you taking a shitty mobile recording of a concert are those who are standing behind you.

But yeah, DRM on your camera? Awful precedent and a great reason to root/jailbreak if ever there was one.

<comment> X-Istence Why root and jailbreak? The whole premise is based upon IR light being received and interpreted by the phone. IR filters are easy to come by, get an IR filter, stuck it to your phone, problem solved.

<comment><USER7> True, true!

</comment></comment></comment><comment><USER8> Some weeks ago world's famous best living drummer Jack Jack Dejohnette gave a performance in my city which i also attended. Somewhere along the second song, he suddenly stopped and wanted from audience to stop recording/filming by saying: " Please respect the artist and their work".

There are some use cases for this, but like in every new feature of technology its open to misuse. My vote is against adding that kind of feature because artists already earning most of their money from concert attendees not losing from non-attendees.

Or may be Apple made an app store type control system for Event/concert organizers. For example an organizer can apply for a specific venue/time/place for switching off all ios devices (via icloud) and Apple do the job for them.

<comment><USER6> Nope, this way, your photo app would be dependent on the internet, wich is a really stupid idea Apple would never do. In other words, what if I switched off the internet from my iPhone before the organizer applies for the "event store", do you think my photo app will tell me : "Oops no internet connection, you can't take photos, we don't know if this place has applied or not for the block"

</comment></comment><comment><USER9> How long after release do you think it will take for IR filters for the IPhone will be on sale by 3rd parties?

<comment><USER10> Or IR dongles that can be programmed to add spam messages to photos.

</comment></comment><comment><USER11> As a regular concertgoer, I support this 100%. I went to see the show, not the back of 100 phones held aloft.

<comment><USER12> So what you actually want is a way for a camera on a phone to be fired without lighting up the screen.

<comment><USER11> And also, without people holding it up in front of me.

It's not just a problem with gigs. Here in London we have a thing called Secret Cinema, who organize showings of classic films in unlikely locations. It used to be cool. Nowadays it's full of people who are only there so they can Tweet about being there, they aren't engaged in the experience at all, it feels like being in a room full of zombies, and not in a good way. If people have forgotten how to live in the moment, they need to be reminded.

<comment><USER6> I understand you completely, but this is an apple patent, so it's likely that this feature will only be available for iPhones. And again, who the f __k is apple to tell me I can't take photos if I want to.

<comment><USER11> In this scenario Apple aren't telling you anything. The owner of the venue and/or the performer are.

<comment><USER6> It's the iPhone who is preventing you, because Apple made it possible, so here's the scenario : "Organizer : Hey apple, block this guy from taking videos of my event" Apple : Oh no problem, he'll just see dead fish instead ROFL"

If the organizer does not want you to take videos, you should still be able to, but if you do or don't, it should be your decision not apple's. So who is telling you what to not film?

</comment></comment></comment></comment></comment></comment><comment><USER13> Actually patent means _they control the right to do this_.

It doesn't mean they're implementing it. Hell, they could be _suing people who try to do this_ and making it less likely to be used by others.

It could be just a random defensive patent.

</comment><comment><USER14> More worrisome, it could be used to block political speech and the recording of embarrassing or retaliatory actions taken by regimes around the world. I really hope Apple is merely filing a defensive patent here.

</comment><comment> X-Istence It won't be long before someone starts selling ghost armour with an IR filter in it. Cover the entire phone and infrared is no longer an issue.

</comment><comment><USER15> Has anything of value been posted from this spam site with its troll headlines?

</comment><comment><USER6> So now I'll use their API to create my infrared device, and block all of you from taking photos of the eiffel tour.

</comment><comment><USER16> No, no, no. I thought we'd killed this at reddit and assumed it wouldn't be reposted here. It's just a patent. This happened last week or earlier and has already been discussed here. :/</comment>


Google to stop listening in temporarily after data leak - <AUTHOR> https://www.businessinsider.com/google-stops-audio-reviews-europe-privacy-concerns-2019-8 <comment><USER2> I always keep my ad-blocker off by default, because in general I want to support websites that show ads, except when they get in my way. I had my ad- blocker deactivated when I visited this link, and this is what I saw:

[https://ibb.co/BTkP6TL](https://ibb.co/BTkP6TL)

(huge pop-up telling me to deactivate my ad-blocker in order to read the article, even if it was already deactivated).

Ironically, I then activated my ad-blocker for that website and the popup went away. Such idiotic practices.</comment>


Ask HN: College business model? - <AUTHOR>

Regularly we see posts regarding higher education considering deflation of educational value, questioning the return value of tuition investment, etc.
We often see good business advise here. Do you have any visions of alternative business models for higher education in the modern world?
What would it cost to run a school with lecturers fully dedicated to teaching?
In 2007 we were two CS lecturers trying to start a private software engineering college in one of the smallest countries of this world where you had to move abroad to get a CS degree. Lots of interest among the local businesses looking forward to hire well educated software engineers. Graduates abroad were far from all inclined to return.
We managed one course in discrete math in a rented classroom. Then funding negotiations stalled. <comment><USER2> Right now college still has too much residual cachet. New MBAs realize they just got hosed, but high school juniors still obsess over what school they will get into. It will take some time before you have a significant number of people looking for alternatives that they are willing to fund. It's a bit of a chicken and the egg problem.

We probably have to eliminate lectures. It's terribly inefficient. Course content needs to be converted into video clips / scannable web content. Get the best teachers in each field and have them create the course content. Everyone else should just be DIALOGUING with students. Answering their questions, listening to understand when they don't understand something, etc.

In terms of business models, you're lucky you are in CS where degrees don't matter. Medicine and law are in bed with the government so the status quo won't change for a long time.

My Dad was a college president for awhile but didn't like how slow things moved or the pain-in-the-ass faculty. One of the things he is doing now is one-on-one mentoring and it works-- much fewer people, but they tend to really excel in their fields.

You can also think about it this way. If I spend 15k/yr in tuition the bureaucracy takes that vast majority of that. The bureaucracy that provides almost no real value! So imagine if you had 10 students that you mentored for 10k/yr with zero overheard... That would be a great deal for both of you! You send them articles and books to read and then dialogue with them individually or in small groups. This does work but you have to really sell the idea to people of an alternative education.

The problem is that as higher education has become disconnected from reality many teachers simply don't know how to function outside of the bubble, who knows how to solve that one...

<comment><AUTHOR> ...yes, a hard nut to crack. Solutions has to come from outside the bubble as I see it.

</comment></comment><comment><USER3> I may be the least qualified person to be giving you advice here, but one thing that jumps out to me is that your first could was on discrete math. If your local business wanted to hire software engineers and you're a very small country, perhaps you should begin by focusing on something more practical and general. Doing so would bring a more immediate benefit to your investors. Then once you had some basic courses in place you could begin offering higher- quality education, and more theoretical classes.

<comment><AUTHOR> I get your points, thanks, but one thing we never wanted to comprise was quality. An education is often once in a lifetime, so I think one deserves the best possible.

<comment><USER3> Sorry, quality was the wrong word. I don't mean to say you should the quality of your teaching, I mean you should focus on a more practical subject rather than something that you may see as a subject taught at "the best schools". Let me use food as an analogy. I see discrete mathematics as a spice. Yes, it's essential for a complete gourmet meal. But why offer a spice before the main staple? Sure it's a high-quality spice, but you're trying to sell it to people who don't have bread.

Honestly, if I need software engineers in a small country, and you asked me to invest in your school, I'd withdraw all funding the second I found out your first and only (at the time) class was on discrete mathematics. To me that seems completely irrelevant to what your investors need.

<comment><AUTHOR> Perhaps you nailed a major problem:

Education should not give employers what they want.

Education should give the graduate the best possible odds for a fulfilling professional lifetime.

</comment></comment></comment></comment><comment><USER4> It doesn't sound like there's anything wrong with your model; you just need to continue your funding negotiations.

If you've got two lecturers, what are the major expenses? Salaries, and rent for the classroom? How big is the gap between (enrollment x tuition fees) and expenses? What kind of enrollment would it take to get "ramen profitable"?

<comment><AUTHOR> Thank you. I do believe we had a viable model. Perhaps other disturbing factors were too difficult. What interests me is rethinking the educational model in the large maybe catching new opportunities.

<comment><USER4> Why did you give up? It sounds like you were on the way to profitability.

If you want to do it on a larger scale, the trick would be to a) sign on sufficient lecturers of sufficient quality, b) obtain the proper facilities, and c) attract enough students. In terms of c), I imagine that it might behoove you to talk to talk to the unemployment office in your country; I know that here in Norway there are a lot of funds available for retraining of out- of-work workers.

<comment><AUTHOR> _Ja riktigt ja! Ja ikke sant!_ In fact I live in Norway now :-) But I am danish :-0

The short version of a complicated story: we pretty much gave up on the country - The Faroe Islands. No funding of the kind you are talking about. And overall a non progressive culture.

I see I ought to further investigate the possibilities here in Norway.

</comment></comment></comment></comment><comment><USER5> I can't speak for everyone, but in regard to CS, I, and many of my colleagues, learned most of our trade from books, experience, and each other.

I never really found much utility for lecturers in CS classes in college. I learned just as well--if not better--from a good book.

<comment><AUTHOR> I learned most on my own too. But that's not for everyone I believe. Some are better off guided. Then there are lecturers and there are lecturers. What I mean is that the scale of performance in lectures varies extremely wildly. And how could it be different. As a lecturer you are often very much on your own. You (hopefully) have good subject credentials and that is what you are hired on. But no one really cares for how you perform pedagogically.</comment></comment>


Going to a graveyard had profound effect on me - <AUTHOR> Nobody in my immediate family is dead so I don't automatically get negative thoughts whenever I happen to pass by one in a car. It's just another fact of life for me. One time I tagged along with someone else and went to one.
When I went there I saw small identical tombstones all the way to horizon, front, left and right.
Many feelings came over and it wasn't sadness. I felt all my worries become a joke, suddenly I felt free.
- All hate for others gone
- All things I felt mattered a lot, such as career. Etc, lost interest an instant
- Suddenly a wave of gratitude
like i was reborn and just happy to be here. Whatever I got was good enough.
I'm learning some religions recommend going to graveyard often, is there any research on psychological benefits of visiting graveyards? <comment><USER2> Thanks for this awesome submission, so lovely to read.

Personally, I dont seem to have a fear of death like a lot of people do - hearing/reading people talk about how it's a huge fear to be dealt with in life, maybe the biggest, is always weird for me. (It also seems the major factor behind religions - telling you that you don't actually die after death, don't worry about it!)

My maternal grandparents lived on a quiet road in Wales with a large and beautiful cemetery at the end of it, a few houses down. It's very green and lovely, a nice place to go for walks, which I did from before I can remember.

I wonder if the two are connected.

Here's some pics of the cemetery [https://www.geograph.org.uk/stuff/list.php?title=The+Mumbles...](https://www.geograph.org.uk/stuff/list.php?title=The+Mumbles+%3A+Oystermouth+Cemetery&gridref=SS6088)

</comment><comment><USER3> This state of mind, from being around the evidence of death .. may well be both good and not unusual.

There's quite a lot of evidence that dissociation induced by drugs like psylocybin in controlled circumstances help terminally ill people come to terms with impending death. A state of mediation on the fundamental mortality we face is useful.

Also this (unrelated) [https://www.theguardian.com/society/2020/jul/25/death- anxiet...](https://www.theguardian.com/society/2020/jul/25/death-anxiety-body- bags-catastrophic-thinking-and-facing-the-inevitable)

Stoics might call it a sense of resignation. Quiet acceptance. Luis Prima had the outlook I like best: enjoy yourself, it's later than you think.

[https://youtu.be/n7VT2EHa0b4](https://youtu.be/n7VT2EHa0b4)

<comment><AUTHOR> Another way I just came up with to describe is like you are in a subway and you have to get somewhere, but you need to switch multiple trains in a complex maze of trains that expand your entire city. You're trying to catch the right train and worried you may take the wrong train or direction and end up at the wrong place, it's stressful experience but then you realize hey no matter what train you take all trains stop here eventually more or less in the same amount of time and suddenly you feel you don't have to worry about if you are going in the right direction, now you can chill and enjoy the ride instead of worrying if you're going in the right direction; or worry about doing things perfectly.

<comment><USER3> To use your analogy, our fears relate wholly to the risk of the crash, and consequences of the wrong station arrived at.

The inevitability of arriving is not the problem. Nor in fact, is the likelihood of a crash high, but its true there are aspects to what we see of others "arriving" which cause disquiet. Unfortunately, unlike the NY subway, you cannot jump over the gate backwards, and nobody who has exited the subway has been able to tell us what its like beyond the station.

But the train, keeps on rollin' rollin' down the track and I'm stuck in here at Folsom..

</comment></comment></comment><comment><USER4> I felt a similar calm after walking to a convenience store in NYC and passing the refrigerated semi-trailers parked outside Mt. Sinai West. I'd forgotten to take my route that avoided passing the hospital.

It's chilling (no pun intended) but also seemed like a wake-up call to what really matters in life.

To think that one day, I might just end up as a pile of human flesh in a semi- trailer.

My state of balance is having worked hard enough to feel somewhat accomplished and looking back on my life and thinking "heck, I've done some things many haven't or that I thought I'd never do. Sucks to die, but hey it's been an interesting ride so far."

My biggest fear is regretting that I didn't try hard enough. I disagree with many of Anthony Bourdain's opinions and life decisions, but this kind of fear is something I deeply connect with.

</comment><comment><AUTHOR> Another way I just came up with to describe is like you are in a subway and you have to get somewhere, but you need to switch multiple trains in a complex maze of trains that expand your entire city. You're trying to catch the right train and worried you may take the wrong train or direction and end up at the wrong place, it's stressful experience but then you realize hey no matter what train you take all trains stop here eventually more or less in the same amount of time and suddenly you feel you don't have to worry about if you are going in the right direction, now you can chill and enjoy the ride instead of worrying if you're going in the right direction; or worry about doing things perfectly.

</comment><comment><USER5> In regard to religion or spirituality, the old desert fathers/mystics used to say that one should always have a remembrance of death instilled in front of their mind. You see this line of thinking in the ascetisicm of Orthodox Christians, particularly so in the book called _The Philokalia_. But otherwise, here's an excerpt that you might like on the above note: [https://cassianus.tumblr.com/post/621365961792143360/we- shou...](https://cassianus.tumblr.com/post/621365961792143360/we-should-never- lack-the-contemplation-of-death)

<comment><AUTHOR> Another way I just came up with to describe is like you are in a subway and you have to get somewhere, but you need to switch multiple trains in a complex maze of trains that expand your entire city. You're trying to catch the right train and worried you may take the wrong train or direction and end up at the wrong place, it's stressful experience but then you realize hey no matter what train you take all trains stop here eventually more or less in the same amount of time and suddenly you feel you don't have to worry about if you are going in the right direction, now you can chill and enjoy the ride instead of worrying if you're going in the right direction; or worry about doing things perfectly.

</comment></comment><comment><USER6> I believe Buddhism talks a lot about death and that we're all dying every moment to put things in perspective.

</comment><comment><USER7> I think about death every day, which means I think about life every day. I don't think about it in a "morbid" way.

Every day I wake up is a bonus for me, an opportunity to make things, live experiences, and be better: a better son, brother, uncle, colleague, friend, human.

Death where I live is different. When someone dies, hundreds of people go to the funeral. They'll support the family with their presence, the logistics, catering, transportation, and an organization forms for a few days to completely solve any problem the family might face to allow them to deal with the death. People will self organize in rotations, bring necessities, transport other people to their destinations, etc.

Those who knew the person of course will come, some will fly in, some will take days off to be present. It doesn't have to be family. For example, colleagues or professional relations of someone who lost their father will come to the funeral. Family friends, neighbors, people who've worked with the person twenty years ago, childhood friends of their children will come. People who go to funerals also bring people with them who did not know the family. There's a funeral motorcade.

If the person who dies had a "good" family, by good family I mean children who were nice with people, honorable, and helped others, a cemetery can get too small.

If the person was in a line of work that involved knowing many people, like in the armed forces, again: their colleagues and their families will go.

If the person was hospitalized, it's common for colleagues or acquaintances of the person's children to come and visit, introduce themeselves, chat the parent, bring things, ask if the person needs anything.

One of the common things here is that children get exposed to death at a very, very early age. They get exposed to it mostly from a religious stand point, and not in a "your mom is in heaven looking at us", but more like "people die, and if they did good things when they were alive they go to heaven, if not they go to hell". But they do get exposed to it. They are taken to funerals, and marriages, and baby celebrations, and generally speaking, all the above also is valid for marriages. Hundreds of people will flock in.

So the rapport to life, sickness, and death is a bit intertwined and they're all present in people's minds with varying degrees.

In the place where my parents are from, it's different since we're not the same ethnicity or have the same relation to religion, or religion in the first place, as the majority. It is not uncommon to have tombs of people right in front of houses, or in piazzas where people in the summer go to cool off, eat ice cream, and play guitar and sing, with kids playing around. I've always seen it as a way to include these people in living activities, so that their body may have left this place, but their memory nonetheless still is intact.</comment>


Lavender's Soothing Scent Could Be More Than Just Folk Medicine - <AUTHOR> https://www.nytimes.com/2018/10/23/science/lavender-scent-anxiety.html <comment><USER2> I was also impressed by the studies out of Germany on Silexan, which is a lavender extract taken orally. The clinical trials took it head-to-head with lorazepam, which is a benzodiazepine like Valium. It held up remarkably well, with similar levels of anxiety relief. So the effects are not limited to olfactory use.

I'm a psychiatrist, and I have prescribed it a few times for patients that I treat. There's a version of it available in the US called CalmAid that is identified as the same isolate in Silexan.

International Journal of Psychiatry in Clinical Practice. 2013. 10.3109/13651501.2013.813555

Journal of Clinical Psychopharmacology. 2017. 10.1097/jcp.0000000000000615

Frontiers in Pharmacology. 2017. 10.3389/fphar.2017.00280

Edit: added info on an RCT, a meta-analysis, and some work on the mechanism of action

<comment><USER3> Links to the above articles:

[https://www.tandfonline.com/doi/abs/10.3109/13651501.2013.81...](https://www.tandfonline.com/doi/abs/10.3109/13651501.2013.813555)

[https://journals.lww.com/psychopharmacology/Citation/2017/02...](https://journals.lww.com/psychopharmacology/Citation/2017/02000/Lavender_Oil_Preparation__Silexan__for_Treating.29.aspx)

[https://www.frontiersin.org/articles/10.3389/fphar.2017.0028...](https://www.frontiersin.org/articles/10.3389/fphar.2017.00280/full)

Also, more articles relating to lavender oil preparation and treatment of anxiety:

[https://www.ncbi.nlm.nih.gov/pubmed/20512042](https://www.ncbi.nlm.nih.gov/pubmed/20512042)

[https://www.ncbi.nlm.nih.gov/pubmed/24456909](https://www.ncbi.nlm.nih.gov/pubmed/24456909)

<comment><USER4> A neat fact is that you can put any DOI at the end of doi.org/ and it will (never has failed me) redirect you right to the landing page of the paper the the DOI is a reference for.

So a paper with a DOI of 10.3109/13651501.2013.813555 can be reached by going to: doi.org/10.3109/13651501.2013.813555

</comment></comment></comment><comment><USER5> I was in the psych ward a little while back and had an absolute _breakdown_ while I was there. They had security put me in the observation room behind the nurse's station, which is just like a room with thick glass on three sides and curtains on the outside and a mattress on the floor. I was losing my shit. When I finally calmed down around 2 AM, a nurse came in with a little bottle of lavender essential oil. She asked if she could put it on my pillow. I had the best sleep of my time spent on the ward, and started using it when I was discharged. I had wonderful dreams, I was calm in the morning, I was comforted, I felt safe.

<comment><USER6> If anyone is interested in experiencing this (sans psych ward melt down) lavender sachets to put in your pillow are really _very_ nice.

<comment><USER7> Hops (as in the beer ingredient) are also a traditional sleep aid to put in your pillow.

<comment><USER8> On the topic of traditional sleep aids, I found chamomile capsules [0] to be a safe and effective sleep aid. I previously worked exclusively overnight and tried many herbal supplements, finally settling on chamomile as my favourite.

[0] [https://www.amazon.com/Natures-Way-Chamomile-Flowers- Capsule...](https://www.amazon.com/Natures-Way-Chamomile-Flowers- Capsules/dp/B0006U3QJQ)

</comment></comment></comment></comment><comment><USER9> My wife had a very stressful and painful delivery with our first. During her 3 day recovery at Kasier, our nurses provided a lavender treatment (oil on a cotton ball) to help reduce her stress and calm her heart-rate. Our nurses had provided us with a patient information sheet that Kaiser had prepared specifically for this situation.

The key here is this was a very targeted and prescribed treatment performed by trained professional staff with a lavender oil product intended for use in a hospital. Not some huckster MLM agent that selling good knows what.

<comment><USER10> Can't there be an in-between? I shouldn't have to be admitted to a hospital to experience the beneficial effects of lavender treatment.

<comment><USER11> Given lavender's known negative effects on developing boys, I think it should only be available in a medical environment, or extensively labeled and regulated.

If this destroys the oily-MLM huns, that would be a side benefit.

<comment><USER12> There are no known negative effects on developing boys. See my comments down- thread. The "studies" purporting to show hormonal effects were extremely low- quality, and have not been reproduced. Other more recent studies are only in- vitro, and in-vitro hormonal effects do not translate well in living humans.

Besides, lavender shares a chemical makeup with many other common herbs and foods, or combinations thereof, and nobody is claiming that those disrupt our hormones. The whole hypothesis doesn't pass the smell test.

</comment></comment></comment></comment><comment><USER13> When i was working on a project in Tunisia, i saw lots of the locals walking around in the morning with little sprigs of rosemary (which grows everywhere there) and taking sniffs of it as they commuted.

When I asked about it, they mentioned it was like a morning coffee, they felt it woke them up, and "got their brain firing".

I gave it a go, and (n=1) it definitely felt like a pick me up. I grow rosemary in my garden now, and every morning as I am getting ready for work I will grab a bit and smell away.

<comment><USER6> Also a popular remedy in Chinese medicine.

</comment></comment><comment><USER14> Curious if it could be related to the hormone disruption properties of lavender.

[https://www.endocrine.org/news-room/2018/chemicals-in- lavend...](https://www.endocrine.org/news-room/2018/chemicals-in-lavender-and- tea-tree-oil-appear-to-be-hormone-disruptors)

<comment><USER12> AFAIK there is not yet any evidence showing hormone disruption from lavender in people. There is some recent research showing effects in vitro (including the report you cited), but nothing in actual humans.

The hypothesis is highly questionable to begin with, simply because the chemicals in lavender that show hormone disruption in vitro (almost all of them terpenes in the latest studies) are ubiquitous in nature, being present in hundreds of other widely consumed foods and herbs, often in high concentrations. Nature has surrounded us with these chemicals, and we've evolved in their presence. It would be really odd for lavender to cause problems, and not any of the other plants that contain the same substances.

The 2007 report (by Henley et al) that kicked off the whole panic over lavender and tea tree oil is a textbook case of poor quality pseudo-research that should never have been published. It had a sample size of three. That's right, three. It was neither blinded nor controlled in any way. It was simply a doctor who thought he noticed a decrease in gynecomastia among three kids after they stopped using some products that might have contained lavender or tea tree oil. If you want to know what's wrong with scientific publishing and reporting nowadays, reading about this case is a great place to start [1].

1 - [https://roberttisserand.com/2013/02/lavender-oil-is-not- estr...](https://roberttisserand.com/2013/02/lavender-oil-is-not-estrogenic/)

<comment><USER15> Does the 2013 rebuttal study in that link tell us anything about the safety of ingesting lavender extract (e.g. like the Silexan studies given above)? Wouldn't that involve much higher absorption than topical application?

Update: OK, weirdly enough, Tisserand seems to be highly involved in the aromatherapy industry per their own website, and the study [0] seems to involve researchers from the "Research Institute for Fragrance Materials" which sounds suspiciously like an industry-related group - is this reputable at all??

[0] [http://journals.sagepub.com/doi/abs/10.1177/1091581812472209](http://journals.sagepub.com/doi/abs/10.1177/1091581812472209)

<comment><USER12> I think this is one of those situations where most of the people who care enough to debate are those with an economic interest. Like perfumers. Conflict of interest is possible I suppose, but Tisserand's rebuttal seems well reasoned regardless, and he provides a list of other rebuttals from other people.

> _Does the 2013 rebuttal study in that link tell us anything about the safety > of ingesting lavender extract?_

No, only topical application, albeit in far greater quantities than is seen in typical usage.

> _Wouldn 't that involve much higher absorption than topical application?_

No, not necessarily. Silexan is delivered in 80mg doses. Higher levels of the same chemicals can easily be delivered by common foods. For example, a dish that's well seasoned with thyme or coriander can easily contain far more than 80 mg of linalool, and a few other ingredients would easily provide the same terpenoid profile as found in lavender, just as if you were to eat a large amount of lavender oil. Lavender really isn't anything special.

</comment></comment></comment></comment><comment><USER16> I can tell you that cutting lavender, bowing with a blade under a flaming sun, isn't soothing at all :) Ditto throwing tons of lavender with a fork in the distillation tank next to the blazing fire :)

</comment><comment><USER17> Soothing? I have a disgust of all things lavender, and I don't appreciate being subjected to the aroma when colleagues use lavender products. I wonder if there's a connection between my visceral reaction and my general lack of ability to relax.

<comment><USER18> Entirely possible. Think of cilantro that tastes and smells like soap for some people. Contrary to popular belief, we do not all perceive the world in the same ways.

"This may be traced to the OR6A2 gene, an olfactory receptor able to bind many of the aldehydes implicated in the herb's very particular smell. Perhaps those with a specific variation in the gene are particularly sensitive to its soapiness."

[http://mentalfloss.com/article/91060/why-does-cilantro- taste...](http://mentalfloss.com/article/91060/why-does-cilantro-taste-soap- some-people)

[https://flavourjournal.biomedcentral.com/articles/10.1186/20...](https://flavourjournal.biomedcentral.com/articles/10.1186/2044-7248-1-8)

<comment><USER19> Perhaps there is a genetic or allergy response to lavender. I have allergies and the smell of lavender makes me want to sneeze. :\

</comment></comment></comment><comment><USER20> Terpenes like linalool are also found in other popular plants. I hope to see our understanding of these substances continue to grow.

<comment><USER21> Including cannabis, which contributes to the variety of strains with differing smells, tastes, and psychoactive effects.

<comment><USER22> And the origin of the lawsuit against La Croix, iirc. I saw headlines describing insecticide in La Croix, and read them and went, oh, that's in beer.

</comment></comment></comment><comment><USER23> Dr. Angie Lillehei from Minnesota also studied lavender and sleep in her 2014 study: [https://www.ncbi.nlm.nih.gov/pubmed/26133206](https://www.ncbi.nlm.nih.gov/pubmed/26133206)

She now sells sleep patches: [https://www.noctilessence.com/](https://www.noctilessence.com/)

</comment><comment><USER24> I understand why there are drug and medical experiments / studies using mice, but why is something like this done with mice and not humans?

</comment><comment><USER25> Wow, a small-sample-size mouse study.

<comment><USER26> While I'm not particularly hopeful for actual positive outcome of a larger study I must ask: isn't this how studies are supposed to be done?

You devise a hypothesis, you confirm it as good as you can in an experiment and document the procedure. Someone else then peer reviews your study and finds any potential mistakes, if the research looks promising enough an independent research team will devise a larger study with more funding to verify the claims, repeat this X times until some sort of conclusion can be made.

Again, I'm partial against this study but at least it's a study.

<comment><USER27> >if the research looks promising enough

I would replace promising with profitable.</comment></comment></comment>


Practical Lessons in Peer Code Review - <AUTHOR> http://blog.salsitasoft.com/practical-lessons-in-peer-code-review/

<comment><USER2> > If you are including third-party code in your patch, > commit it separately.

Sometimes I'll do that with changes that involve new service client libraries. First commit will have the new library fooservice_client along with its config files and such. Once that gets deployed I can open up a production console and verify that the app can query the service and display the results. Then a followup commit will contain the actual change that I want to make - "query foo service for a list of bars and display them" \- and I'll put a note about how the connection credentials and setup have already been verified.

Of course that depends on an environment with more or less continuous deployment. If deploys are two weeks apart this approach is just going to take to long to get anything done.

</comment><comment><USER3> My recommendations when checking in a new feature or substantial change:

1\. Meet in person

2\. The coder should _print_ out copies of the diffed code for each attendee

3\. Have roles in the meeting - someone to read the code, someone to capture bugs + severity, and the rest are there to review the code

4\. Coder takes documented defects, fixes them and reports back to the group with diffs.

5\. Metrics can be kept, used as feedback to improve process.

Usually 4-5 people are sufficient for a large chunk of functionality.

Is this process slower than gerrit? yes. Do you get better feedback, and better understanding (at a team level) of the code base? yes.

I haven't seen software that really emulates this experience - there is an interesting opportunity here.

<comment><USER4> This is very much a cultural thing. I don't necessarily agree that you get better feedback or better understanding through an in-person meeting.

In my experience tools like gerrit allow developers to learn and review at their own pace, and provide well-articulated, thought-out feedback.

Note also that a large amount of modern development still occurs on mailing lists.

It's all about culture.

</comment></comment><comment><USER5> "It is instructive to consider pair programming, which is a fairly popular practice and adds an overhead of 100% to all development time, as the baseline for code review effort."

I couldn't disagree with this line more. I've frequently seen it halve the amount of development time.</comment>


The Unprecedented East China Sea Oil Spill - <AUTHOR> https://www.theatlantic.com/technology/archive/2018/01/the-oil-spill-that-wasnt/550820/?single_page=true <comment><USER2> _Condensate, on the other hand, is a gas amid the heat and pressure down there. Bring it up to the surface and it condenses into liquid._

So it's a gas at high pressure, but a liquid at atmospheric pressure? I hardly think so! I would understand if it was liquid underground, but turned to gas when we let it vent, then turned liquid again once cooled.

This article is entirely about the definition of condensate, but still doesn't explain what it is:

[https://www.reuters.com/article/us-oil-condensate/u-s-oil- in...](https://www.reuters.com/article/us-oil-condensate/u-s-oil-industrys- billion-dollar-question-what-is-condensate-idUSKCN0HX0BU20141008)

Although it does contain another baffling oil fact:

 _the Texas Railroad Commission, which oversees the Eagle Ford and Permian basins that account for most condensate output_

In Texas, oil production is regulated by the Railroad Commission. Of course.</comment>


Live-Tweeting the Police Scanner: A Defense by Wayne Chang of Crashlytics - <AUTHOR> http://bostinno.streetwise.co/2013/04/22/live-tweeting-the-police-scanner-a-defense-by-wayne-chang-of-crashlytics/ <comment><USER2> Err, there's not exactly much of a defense:

"I decided to keep going but without sharing location information. But hater's gonna hate, right?"

You might think this sounds snarky, or is a sarcastic summation - but if you read the (very brief) article, this is actually the sum total of the defense provided.</comment>


Show HN: Multi-armed bandit optimisation service - <AUTHOR> https://contextshift.io/ <comment><AUTHOR> Hi HN,

I'm looking for help validating an idea for a product that provides multi- armed bandit optimisation over an API. The idea is that client sites will provide impression and conversion events to our API, which provides recommendations about which variant to display, optimising performance over time.

I think this could be useful to businesses that currently use A/B testing but am trying to understand if an API on its own is useful enough to be a standalone product.

Please have a look at the site and let me know if it's clear what the product is and if you think it'd be useful. I'd also appreciate any advice on how to validate an idea like this, how to identify problems this kind of product to solve, etc. Thank you!</comment>


Consciousness, coming to a machine near you. - <AUTHOR> http://www.theprojectspot.com/post/consciousness-coming-to-a-machine-near-you/12

<comment><USER2> The article lacks substance and makes a few logical blunders. I was expecting a good read given the title, but was disappointed.

 _"For example, is an earthworm conscious? Even this is hard question to ask but it's probably quite safe to assume it doesn't."_ There is no basis for this assumption and the first part of the article relies on it being true.

<http://plato.stanford.edu/entries/consciousness/#2>

The author then goes on to contradict himself by concluding - _"One of the most fascinating things about consciousness is that we don't have any way of telling if anyone else is really conscious. For all we know everyone around us could just be acting unknowingly on inputs they're receiving from their sensory inputs. If we ever did create a conscious robot we would never really know if it was truly conscious or just acting in a way that made it seem conscious. Being able to merely say you're conscious doesn't make it so."_

So why then did u assume that the earthworm doesn't have consciousness?

</comment><comment><USER3> Another article kind of assuming that cousciousness is a subproduct of the brain.

Our current Physics' models are fundamentally excluding Consciousness. That's what's creating the fundamental problem.

Check Rober Penrose ideas for more: <http://en.wikipedia.org/wiki/Roger_Penrose></comment>