5 Weeks of Go - <AUTHOR> http://blog.iandavis.com/2012/05/23/5-weeks-of-go/ <comment><USER2> _"Names imported from a package are accessed by using the last component of the package name as a prefix (rather than the horrendous full package prefix that you often see in Java and similar languages)"_

      import "image/color"
      x := color.RGBA{255, 255, 255, 0}

Perhaps I'm naive, but I thought you could do this in basically any language, including Java (it's been a while).

EDIT: Not sure why this was downvoted, but it's a trivial Google search[1] to show that this is indeed something that you can do in Java:

      import javax.swing.JOptionPane;

      class ImportTest {
          public static void main(String[] args) {
              JOptionPane.showMessageDialog(null, "Hi");
              System.exit(0);
          }
      }

Which, without the import, would force you to use the full name as the author alludes:

      class ImportTest {
          public static void main(String[] args) {
              javax.swing.JOptionPane.showMessageDialog(null, "Hi");
              System.exit(0);
          }
      }

I'm not intending to bash Go (it has the largest quantity of awesome features of any language I've seen in a long time), nor necessarily to defend Java. It just seems a bit disingenuous to claim that this is exceptional behavior.

[1] [http://www.leepoint.net/notes- java/language/10basics/import....](http://www.leepoint.net/notes- java/language/10basics/import.html)

<comment><AUTHOR> The difference is that javax.swing.JOptionPane is a class whereas image/color is a package containing functions and types.

x := color.RGBA{255, 255, 255, 0} is instantiating an RGBA type from the image/color package

<comment><USER3> In Java:

        import org.somelib.colors.*

        x = new RGBA(255, 255, 255, 0);

where RGBA is some class defined in the org.somelib.colors package.

<comment><USER4> I think they're looking for:

      import org.somelib.*

      x = new colors.RGBA(255, 255, 255, 0);

So you don't have to bring all the classes into scope, but you don't have to write out the full path to use them either. Just the last bit of the package- name as a qualifier.

<comment><USER5> In C# that'd be:

      using colors = org.somelib.colors;

I don't know if Java has something similar.

<comment><USER6> It doesn't.

</comment></comment></comment></comment></comment></comment><comment><USER7> I've been using Go for a performance-critical part of a production system and I've been thoroughly enjoying it. But certain things have been odd and frustrating.

One trait that I find frustrating is how pedantic Go is about types.

For example, if I have a float _x_ and an int _y_ , I can't write _x / y_ , I have to write _x / float64(y)_ †. The intent is to force awareness of type conversions that introduce subtle gotchas, but I don't see how it applies to the case _float / int_.

A better example of the same phenomenon is that alias-style types need to be explicitly cast to their aliased types, which introduces pointless noise into what would otherwise be a nice way of 'marking up' the semantic role of variables and arguments (think _type index uint_ ).

 _†Notice there is a common-or-garden 'int' but no common-or-garden 'float', apparently because one should always be aware of precision. Unfortunately, because of the alias type issue I mention above, 'type float float64' doesn't help._

<comment><USER8> > _but I don't see how it applies to the case float / int_

Does the int get converted to a float for this calculation? is sizeof(int) == sizeof(float)? Then you can lose accuracy in the conversion; MAX_INT is larger than the largest same-sized float that can be represented without rounding error.

<comment><USER7> Fair point, although for the garden-variety int (int32) and float64, this isn't the case. In an ideal world, the compiler would be smart enough to know this, and complain appropriately.

<comment><USER9> "garden-variety" int wont be int32 forever.

<comment><USER7> That's true, and it will probably change fairly soon, but there are a whole range of safe integer to float casts that will still exist even if int changes from int32 to int64.

And these safe casts should be transparent so that people who regularly do things with floats don't feel like second class citizens in the language.

<comment><USER10> The check cannot be made at compile time, only at run time, and even if it were possible to make the check at compile time it would still be a bad idea. At some point in the program's 20 year old life time, someone will decide that a number N used somewhere in the program has to become N+1, and N+1 doesn't work. It would be unacceptable for such a trivial change to break the program's compilation, and for a number to carry so much hidden state and meaning.

<comment><USER7> I'm not sure what you mean by "The check cannot be made at compile time, only at run time". Are you talking about a language other than Go? Go is statically typed.

edit: I've been talking about compile time errors that prevent potentially dangerous implicit casts from happening. I think you're talking about something else.

<comment><USER8> If int64 is the default type for int, then any int will be able to contain values not representable as a float64 (you'd need a float80 or float128 to make it work). To safely convert, a run-time check will be needed.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> _The amazing speed of the compiler means the development cycle is a fast as a scripting language even though full optimizations are always switched on._

This is a common misconception of those who work mainly in compiled languages. In some dynamic languages, you don't just have the same edit-test-debug cycle. Advanced users of dynamic languages can conduct mini edit-test-debug within all the parts of the larger scale edit-test-debug cycle.

 _Go is not object-oriented. This, in my opinion, is a massive plus for the language....In the real world, things are fuzzy and they spread across multiple conceptual boxes all at once. Is it a circle or an ellipse? Is she an employee or a homeworker? Classifying things into strict type hierarchies, although seductive, is never going to work._

Here, the author is simply wrong. This is another common misconception about OO. You don't need strict type hierarchies. You don't even need classes at all for OO.

EDIT: Other than that, an overall good review.

<comment><AUTHOR> Thanks for the comments. I take your point about OO, but I was aiming at producing a broad overview of Go which necessarily means simplifying in some parts. To 90% of developers today brought up on strongly typed languages such as Java and C#, OO means single inheritance type hierarchies.

<comment><USER2> I agree with your decision to not label Go as object-oriented; to too many people that term is simply synonymous with inheritance. But rejection of the term itself doesn't mean we should automatically reject the often-related concepts of encapsulation and polymorphism, both of which we can have without inheritance.

Specifically, you say this:

 _I can hear the die-hards screaming already about encapsulation, inheritance and polymorphism. It turns out that these things are not as important as we once thought._

And then you proceed to give examples that only attempt to refute the usefulness of type hierarchies, without addressing encapsulation and polymorphism. I'd be curious to know what facilities, if any, Go provides for these concepts.

<comment><AUTHOR> Go doesn't support polymorphic methods but supports polymorphic types through interfaces. Encapsulation is through the private/public naming convention I refer to in the blog post.

</comment></comment></comment></comment><comment><USER12> The word Go is far too overloaded in the English Language, and the difference is not always clear from context.

This title could easily have refferred to the correct meaning of 5 weeks with the programming language Go, 5 weeks playing and studying the game Go, or in a slightly colloquial usage, 5 weeks of constantly doing things and going.

And those are just the meanings that make sense in this context. It is also a verb with a wide variety of (related) meanings and forms a command part of a command in multiple computer languages (T-SQL uses Go, goto is infamous in Basic, etc).

<comment><USER13> Why is it actually called "Go"? The official FAQ just has a snarky response. [http://golang.org/doc/go_faq.html#What_is_the_origin_of_the_...](http://golang.org/doc/go_faq.html#What_is_the_origin_of_the_name) Is it really just short for "Google"?

When I searched for "why is golang called go" Google actually suggests I change "golang" to "google" which is kind of funny.

<comment><AUTHOR> I think it's a play on the word "Co" derived from "coroutine" which is the basis for concurrency in Go (which calls them Goroutines)

<comment><USER14> Indeed, _go_ is a keyword in the language, for launching said "goroutines".

</comment></comment></comment></comment><comment><USER15> I'd be interested in hearing more about the exceptions side. The usual derision is that some top level unrelated code ends up handling them, but that seems silly. A far more normal example would be a routine that has to get some resources and calls various retrieval routines which may end up accessing the filesystem, databases, or the network. Those routines could go several calls deep before throwing an exception. The top routine can then find alternatives, use cached versions, return an error etc.

I do like exceptions in Python where their use is ubiquitous and there is garbage collection. I detest checked exceptions in Java because you are forced to handle things at a level you often don't want to.

I'm 65% certain Go made a mistake not using exceptions, but would love to hear from others.

<comment><USER16> Go uses the Error type and multiple returns in the scenario you describe. Code might be something like this:

      foo, err := GetDataFromDatabase()
      if err != nil {
          foo, err = GetDataFromLocalFilesystem()
      }
      if err != nil {
          foo, err = GetDataFromNetworkFilesystem()
      }
      return foo, err

There is an exception-like mechanism called 'panic', but it shouldn't be used as a control flow tool. Panic is reserved for unrecoverable errors, not mundane situations like a failed query.

<comment><USER17> This seems extraordinarily painful. I usually have five or six stack frames between GetDataFromDatabase() and code that can _raise error dialog to user_ or _return HTTP error code_. This means every single one of those stack frames are going to duplicate this annoying if err != null sequence.

The article author is quite wrong when he says "exceptions are broken by design because they force errors to be handled at points far away from the cause". Exceptions don't force you to handle errors at any particular location; they _allow_ you to handle errors anywhere in the stack. On the other hand, return values do _force_ you to handle errors then-and-there, which 90% of the time is a half-dozen stack frames away from your handler.

<comment><USER7> We have two orthogonal tasks which traditional exception mechanisms complect together:

1\. Handling a failed assumption, which will cause the code that follows to be incorrect (I need the contents of this file to do my task, but it doesn't exist, so I can't do my task)

2\. Handling a failed operation, which there is a straightforward way of working around (if I can't write to my log file, maybe write to stderr instead instead and give up)

The trouble is that the 'inner' code doesn't know which of these a given failure is, because it is context specific. Seems like with languages like Java, the default is 1, whereas with Go it is 2. They're kind of equivalent, though, because you can always convert a !ok into a panic(...).

But certainly exceptions are the nuclear option, so it seems reasonable to me that they shouldn't be the default for common operations that can fail.

<comment><USER17> Why wouldn't you want to use exceptions for #2? I posit that it is very rare for errors like RPC failures and filesystem errors to be handled at the level of the call. 90% of the time the natural handler is several stack frames up where you can raise an error dialog or write an http error response.

Return values create endless repetitive "if error return error" code, or worse - programmers get lazy and ignore return values, producing bugs that show up only in hard-to-test-for situations like transient network failures.

<comment><USER18> Why is it rare for RPC/filesystem failures to not be handled at the level of the call?

I think its much more natural for a memcache API to return an error if the server is not reachable, and I can continue to execute the current function. Similarly, I think its more natural for a "users" API to return an error if a particular user doesn't exist so I can redirect to a signup page or something, rather than throw a UserNotExistException.

And yes, errors as return values may seem to add more code to simple examples. But I find it does wonders for clarity/readability. Using "regular" control- flow for error conditions and the "happy path" makes code much easier to follow; this is as opposed to trying to intuit the different ways control can jump from the happy path into the error handling.

Also, I find that having to write the "if error return error" makes me pause to think about how to handle errors properly. For example, if the function I'm writing literally cannot proceed I will return the error. If its a really weird place to be getting an error, write it to a log and return the error. If I can ignore errors (like the memcache example above) then I keep going.

<comment><USER17> It's rare because RPC & filesystem access is usually wrapped in a library or module which does not have any business knowledge of the task at hand. A more realistic example is your getUser() call which calls 10 stack frames down to a filesystem access, and let's say you get a filesystem error. The natural thing to do is throw an exception which goes up all 10 stack frames and gets caught by getUser(), which provides some sort of "sorry, internal error" message to the client.

The notion that typing "if error return error" through 10 stack frames makes you think more clearly is absurd. Decades of C experience has shown that lazy programmers will ignore critical error conditions and introduce hard-to-find bugs because execution plows ahead past the original error.

Whether getUser() returns an error object or throws an exception is a question of high-level API design. Sometimes UserNotExistsException makes sense, sometimes a null (or error) result makes sense. That is an entirely separate issue. Any designer with significant experience will use both approaches as appropriate.

<comment><USER18> Again, I'm not disagreeing that exceptions tend to be more terse. Exceptions optimize for writability at the expense of readability. Reading linear code that uses if statements and loops is easier than code that uses try-catches. Especially trying to come up with all the ways control could jump from happy path code to error-handling code.

You tend not to be writing all 10 methods in a particular call chain at the same time. You will be writing a few methods that call each other inside a module. You paint this as a massive timesink, and I can assure you, it definitely is not.

Lazy programmers can also have catch-all exception handlers. I don't see how exceptions help make lazy programmers perform due diligence.

That being said, there is a place for exceptions. Truly exceptional conditions such as index out of bounds, or nil pointer dereference, or some internal precondition violated, should be treated in an exceptional manner. Go does this with panics, and panics are almost never caught as part of control-flow. They tend to be caught at the root of goroutines, logged, and the goroutine killed. The HTTP library, for instance, will catch panics in any goroutine it spawns, and write a 503.

I just find it odd that people treat commonplace things as exceptional. File open failed? Could not resolve hostname? Broken TCP connection? These aren't particularly exceptional things. They are probably not a result of a bug, and so should be handled by the programmer.

<comment><USER17> We seem to be going around in circles here... You say 10 layers of _if error return error_ is not a time sink, and I say it is. I spent about a decade doing C and C++ programming before Java, and IMHO exception handling is second only to garbage collection as life-changing language improvements.

There is a key difference here: When a lazy C or Go programmer fails to check an error value, execution continues - possibly many lines or stack frames ahead before some sort of failure symptom is observable. In perverse cases this can produce silent data corruption. I spent far too much of the 90s chasing down these kinds of problems.

When a lazy programmer uses a catch-all exception handler, the error is still caught - immediately - with the full stack trace of the original problem. This is golden. Furthermore, a catch-all exception handler that prints an error message to the user/http request/whatever is often _exactly_ the right approach.

There's a lot of stupidity in the Java standard libraries, but your examples (file failure, bad hostname, broken connection) are exactly the kinds of things that should be exceptions, and are usually best caught at a high level where meaningful errors can be reported to the user.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER19> Whoa, I didn't know about being able to import packages from a URL. That is pretty slick.

<comment><USER20> It is quite neat and mighty convenient, but I sorta live in fear that at some arbitrary point the library will change and my code will just stop working. I konw this isn't a problem unique to Go and there are solutions, but the lack of explicit versioning makes me nervous. Then again, it hasn't bit me yet, and I certainly have benefitted from the ease.

<comment><USER21> One solution is to add version to url. Some examples from Google API for Golang (<http://code.google.com/p/google-api-go-client/>): code.google.com/p/google-api-go-client/tasks/v1 code.google.com/p/google-api- go-client/books/v1

<comment><USER22> This is absolutely the only right way to do this. It's very unsettling that locking to a specific revision isn't considered the default.

Depending on git master is cowboy coding at its most cavalier; build systems should prize repeatability above all else.

</comment></comment></comment></comment><comment><USER7> The tools are also really nice. "go build", "go run", "go get", etc. Building dependency management and build management built into the language - even if it is not super sophisticated yet - is a great idea.

</comment><comment><USER23> I don't understand this sentence:

> Enforcing a brace placement style and other conventions means the compiler > can be super fast.

Surely the lexical-analysis phase is not the bottleneck in compilation? (The context strongly suggests that 'other conventions' means 'other lexical conventions'.)

</comment><comment><USER4> This is a stupid question, but it's beyond difficult to search for an answer (I've really tried!):

Can I import Java libraries into Go? If I can't find a Go library to do what I need, what are my options besides messaging to another process, or (presumably) finding a equivalent C library (I don't trust my C skills enough to make wrapping something a confidence inspiring no-brainer).

Is there general language/library interop details out there any golangers could point me towards?

<comment><USER24> > Can I import Java libraries into Go?

No. Go compiles to machine code, not the JVM.

Go's built in cgo tool makes it very easy to wrap C code. See <http://golang.org/doc/articles/c_go_cgo.html>. Crucially, you can write most of the wrapper in pure Go and the C boilerplate code is generated automatically.

</comment></comment><comment><USER25> So, any chance we'll see Android using Go anytime soon?

<comment><USER15> You can run shared libraries on Android very easily. The shared libraries can do OpenGL (video) and OpenSL (sound), plus most regular libc stuff. Most of the Android APIs are exposed as Java and you can use JNI to call into the shared library (ultimately it is C). As far as I can tell you can't generate a shared library from Go so this "normal" approach is off the cards. (There are also issues like how the Dalvik garbage collector and Go GC would interact.)

To have a pure binary would effectively require a reimplementation of the framework of Dalvik and all the various classes/methods and would be a huge undertaking. It would be extremely unlikely to install on existing Android versions and would only be in a future version. Or in other words it would be many many years before you could depend on it being on Android devices even if this was done for the next Android version.

The shared library thing is the biggest problem though. Android applications are really mashups of components from the same app or others (see Activities, Services, Content Providers, Receivers). There isn't actually a main() method or equivalent. Instead the components are loaded and called as needed.

</comment></comment><comment><USER26> Could someone point out, what is the reasoning of putting types after variable names? i.e. why not `int i` instead of `var i int` ?

<comment><USER27> This is mentioned somewhere but it removes the ambiguity and bugs that can be introduced by pointer types.

Consider: int* i, j (or rather int *i, j)

<comment><USER28> Well, there's no ambiguity in this case, because "int" is a keyword, known to the compiler, and will always be interpreted as a type. But if you had something like "x*y,z", then the meaning of this would depend on whether x is a type or not.

<comment><USER29> I think this is more in reference to the common C error of:-

        int* x, y;

when you meant to declare both x and y as int pointers, here only x will be a pointer and y will be a straight int.

Obviously the go designers could have chosen to simply make this mean that both x and y are pointers, however this would be somewhat confusing for those familiar with C.

As iand says, there is a rather good article on this which goes into a lot more detail - <http://golang.org/doc/articles/gos_declaration_syntax.html>

</comment></comment></comment></comment><comment><USER30> the only thing i'm looking forward in Go is inheritance

</comment><comment><USER27> Yes, Go is different. Yes, the language designers made a lot of decisions that people will complain about [at first]. Yes, I'd [really] love to have generics (even just for simple code repeat cases).

But goodness I love writing Go. Sorry, it's hard for me to be terribly specific outside of, for some reason, I'm very productive with it and I love the standard libraries. And where they're lacking Google Code, Github and IRC/play.golang.org make up for it.

<comment><USER7> I agree that it is a pleasure to use. I also suspect that generics will be forthcoming after everyone understands the 'theory of Go' a little bit better.

Unfortunately, the standard libraries that I've sampled have felt inconsistent. Two examples I happen to remember:

1\. The _strconv_ package has a _Atoi_ (a wrapper around _ParseInt_ ) but no _Atof_ \-- instead you use _ParseFloat_ directly, and you have to give it as a second argument one of the integer _values_ '32' or '64' to set the precision it parses at (why not use an enum or two funcs?).

2\. The _bytes_ package has versions of _Index_ that search for single bytes ( _IndexByte_ ) as well as byte slices ( _Index_ ), a nice performance-friendly touch. However _Split_ only has the byte slice version. _SplitByte_ would probably be twice the speed.

If you are going to write a package to stand the test of time, _be consistent_.

 _(edit: I got Atoi the wrong way round)_

<comment><USER20> For what it's worth, I've looked into the 'Split' case, and the performance difference when specialized to the single-byte case is about 2%, which is mostly because Split already has built-in specialization for the single-byte case, which amounts to a couple extra instructions in a function whose running time is dominated by allocation.

I think they made the right choice there; the Go team seems very good about optimizing only where it matters; there's lots of low hanging fruit, but the majority of it isn't very useful fruit.

<comment><USER7> Just for fun, I just looked into it too. Which factor dominates depends on the kinds of strings; for large strings, extra instructions in the loop matter very much. I'm processing very large strings.

I did 128 runs on a byte array of length 2^24. It has delimiters placed at positions {2^i, i < 24}.

I tested my implementation against both the "bytes" package implementation, and a copy of the relevant portions of the "bytes" package (to account for any odd effects of inlining and separate compilation). I did the set of timings twice in case there was any GC.

Here's the wall time in milliseconds for the three implementations, on a 2010 Macbook Air.

mine 3313 copy 4709 bytes 5689 mine 3327 copy 4660 bytes 5660

My single-byte implementation is about 40% faster than the local version, and 70% faster than the "bytes" version. Not quite twice, but I wasn't far off.

But aside from performance, there is just consistency of interface. Once you've established a 'Byte' variant of some functions, you should do it for all the common functions.

<comment><USER20> It doesn't sound like you're using the benchmarking tools that Go provides; I'd recommend using that if you're not.

Ah, yeah, I was testing a much much smaller byte array with multiple split points. I'm not terribly surprised that in your case you've found the hand- coded byte version to be faster (though the difference is more than I would've guessed; care to post the code?) However, I'm still not sure it's merited in the standard library. Split() could pretty easily be further specialized to basically call your single byte implementation or equivalent at the cost of a handful of instructions per call. Alternately, if you know you're dealing with very large byte slices with only a few split points, it is only a couple lines of code to write a specialized version that is tuned for that. The same argument could be make for IndexByte, but I'd claim that IndexByte is a much more fundamental operation in which one more often has need for a hand-tuned assembly implementation. I wouldn't say the same for Split. There's a benefit to having fewer speed-specialized standard library calls, and I don't think splitting on a byte with performance as a primary concern happens often enough to merit another way to split on a byte in the standard library. But I'm certain that reasonable people who are smarter than me would disagree.

<comment><USER7> Sure.

Here's the implementation of the three versions: <https://gist.github.com/2821937>

Here's how I was originally benchmarking things: <https://gist.github.com/2821943>

Here's benchmarking using the Go testing package: <https://gist.github.com/2821947>

Some of the performance I was seeing on my crappy benchmarker evaporates using Go's benchmarker. But there is something else afoot. Try changing 'runs', which controls the size of the inner loop (needed to get enough digits of precision):

From "runs = 128":

      BenchmarkSplit1	       1	2478184000 ns/op
      BenchmarkSplit2	       1	2787795000 ns/op
      BenchmarkSplit3	       1	2747341000 ns/op

From "runs = 32":

      BenchmarkSplit1	1000000000	         0.62 ns/op
      BenchmarkSplit2	1000000000	         0.68 ns/op
      BenchmarkSplit3	1000000000	         0.56 ns/op

Why did it suddenly jump from 1 billion outer loops to just 1? I think there is a bug in the go benchmarker here, because if you take into account the factor-of-4 difference in work and then divide by 1 billion, it looks like the first set of ns/op _are actually correct_ and aren't being scaled correctly.

Either way, the increase in performance is now only about 10%. Which I agree, isn't anything to write home about. More bizarre is that the bytes package one is faster for runs = 32 but not for runs = 128. I can't make head or tail of _that_ , or why it should matter at all -- unless there is custom assembly in pkg/bytes that has odd properties inside that inner loop.

But this is only one half of my complaint: it's the interface that matters, and I see no good reason for having IndexByte, but no CountByte and SplitByte, contrary to what you say about which is more fundamental. Having to construct a slice containing a single byte just to call SplitByte and CountByte left me with an bad taste in my mouth.

</comment></comment></comment></comment></comment></comment><comment><USER31> I don't get why the compiler speed is such a big deal.

<http://en.wikipedia.org/wiki/Incremental_compiler></comment>


Ask HN: How do people in F1 get their job? - <AUTHOR> I'm just wondering if it's mostly through networking or are people applying to job offers? <comment><USER2> Depends on the position. The pit crew are made up of car mechanics and more senior technical/critical roles.

You'll never find a role advertised for a 'wheel changer', instead you'll need to work your way into the company as a mechanic and then move onto the race team if you're suitable.

If you have the experience then take a look on their company site, for example McLaren have various roles open:

[https://careers.mclaren.com/go/Racing/724201/?utm_source=car...](https://careers.mclaren.com/go/Racing/724201/?utm_source=careersite&_ga=1.136974128.1021946753.1471957855)</comment>


Physicists Discover Quantum Law Of Protein Folding - <AUTHOR> http://www.technologyreview.com/blog/arxiv/26421/

<comment><USER2> Read it again. The paper says that if you use a specific quantum mechanics model then you get results with several free parameters. These parameters can be tuned against 15 existing molecules and the equation gives some explanatory power of why the folding is non-Arrhenius.

Several things must occur before you can say it's real: does it apply to other molecules, what are the sources of the differences between prediction and measurement, do molecules while folding really undergo some sort of non- continuous motion and can it be detected and why hasn't it ever been seen before, and do the matching corresponding Newtonian+statistical dynamics give similar predictions?

<comment><USER3> Exactly! This high level model doesn't draw on any quantum specific phenomena and is in many ways comparable to other stochastic dynamical models that have been developed to explain the non-Arrhenius behavior of protein folding using classical Langevin theory.

To argue for the inclusion of quantum theory in explaining protein dynamics is to assert that proteins undergo classically forbidden conformational transitions. The authors of the paper have provided no evidence for such transitions nor even hypothesized about how such transitions could arise. Their only argument against a classical description of protein folding is the inability of molecular dynamics simulations to model the folding-kinetics of some proteins. Seeing as molecular dynamics force fields only provide a rough and approximate description of the forces between atoms within a protein it should be no surprise these methods can't accurately model the intricate conformational transitions in protein folding.

</comment></comment><comment><USER4> There are some extrange detals in the original paper.

For example the experimental points in the graphics do not have error bars. The x axis is 1/temperature, so the error should be small. But in the y axis I spect that the measures have a more visible error. Some of the graphics ("Protein A", "L9") have a very good theoretical fitting, so it is possible that the experimental data have very small errors. But in others graphics ("Engrailed Homeo Domain", "Trpcage(WT)") the points are scattered around the theoretical fitting, so perhaps the measures have a appreciable error or the theoretical fitting has problems.

And in the lasts graphics the fitting is not very good. In particular in "Villin Headpiece Subdomain" the fitting id horrble. I see that the experimental point lie in something like an "U" but the fit is like a shallow "^".

Another problem is that they have too many free parameters: "R" and "S" are free. And "Tc" is free too (it is an experimental value, not deduced from the model). But near the maximal point of the curve, everything is almost a parabola, so with 3 free parameters it is possible to fit almost everything. For example, for the first graphic ("Protein A") a possible fit using thee parameters is

      ln(K_1)= -7.4161 * (1000/T - 3.1469)^2 + 12.418

They have a more difficult functional dependency, but with tree free parameters it is not clear that they have the correct model.

</comment><comment><USER5> There are other quantum-bio efficiencies being studied - such as this one for best-path photosynthesis reaction chains:

<http://physicsworld.com/cws/article/news/41632>

</comment><comment><USER6> Well I'll be damned! Wow!

It seems obvious now, but I really would never have thought that quantum mechanics would matter here. I'm not sure that this simplifies anything. I wonder what D.E. Shaw research is going to do about it if this pans out? (They're the folks behind ANTON - see <http://www.deshawresearch.com/>)

<comment><USER7> "Wow!...It seems obvious now..."

What a vigorous hand-wave! How, pray tell is it obvious?

</comment></comment><comment><USER8> The idea that the mind is some sort of insanely complex, naturally evolved quantum computer is becoming increasingly credible

<comment><USER9> No, it's not. There is extremely little to suggest that it uses quantum effects for computation.

</comment></comment><comment><USER10> somebody hide this from deepak chopra before he claims it as validation to one of his open ended theories!

</comment><comment><USER11> Awesome site, thanks for the share.</comment>


Tell PG: I think NYC can now be a place to do a startup. - <AUTHOR>

Just a quick note to ask to change the location part of http://www.paulgraham.com/startupmistakes.html <comment><USER2> I fully agree. The startup community is exploding here. We have serious companies coming out of the city, a seriously diverse culture (Tech, Business, Fashion, Art, Music), leaders and mentors speaking at meetups, co-working spaces, conferences and colleges daily, and tons of VCs and Angels. So glad I moved to NYC.

<comment><USER3> I'd worry about being lean and frugal there, due to the cost of living. I bet there's some ways to save money (aside from cramming five guys into a studio apartment).

Related question: Did NYC ever get any of those miracle residential fiber connections covering the whole city? It's surprisingly hard to get broadband info w/o going through forms.

<comment><USER2> FIOS is probably the best bet although it doesn't come to our building. You can still get 20-50Mbps residential if you pay enough. It's quite easy to live cheaply here, as long as you don't live in midtown Manhattan. You can cross the water any direction and knock $1000 off your rent, and if you cram a few people in the same apartment (everyone does), then your rent can be $500-$1000 per person. On incubator funds that leaves some runway. There is a pizza place one block over from me that is open 24hrs and has $.99 slices, so food can definitely be had on the cheap, and we don't have, need, or want a car since 20 instances of everything we need is within 10 blocks from us. Dentist, Doctor, Store, Parks, River/Ocean, Gym, Restaurants, Bars, Clubs, Coffee shops.

</comment></comment></comment><comment><USER4> NYC is becoming a great place to do a startup, but is NYC the next silicon valley? I'd say no (I'm a New Yorker). Silicon Valley has always been the place to run a _techonology_ company. New York has always been about commerce, finance, fashion, art, media. NY and SV are good at 2 different things. What's happening now is _not_ that New York is becoming good at what silicon valley is good at. Its that the things New York is good at are now becoming technology enhanced, so depending on what kind of company you're building, SV could be better than NY and in some cases, NY could be better than SV.

(I'm making wide sweeping generalizations of course and they may not be valid months from now.) edit: yes that last statement was just to cover my ass. ;P

</comment><comment><USER5> Why do you need him to change it? Just show him.

</comment><comment><USER6> I hope NYC doesn't become the next silicon valley. I hope another city does. Or why not a country? The thing is we should decentralize the different powers. Yeah, leave NY to your lawyer but why not creating a new hub at a tropical place like... lets say... Brazil. A place with very low life cost and super high internet access + super nice weather where hackers could be doing their 'thing' all year long and then maybe take a plane to meet investors from NY, Europe or China..... or just skype them.

<comment><USER7> Brazil sounds good, but that's a huge country to become a hub. It would surely need to be a city within Brazil like São Paulo or Rio.

Of course it's not really something you can engineer, if it was I'd suggest New Zealand =D

</comment></comment><comment><USER8> I'm in.

But, I think the culture is fundamentally different and must be treated as such. I wish I had more to say on the matter but I'd have to think about it some more. All I'm thinking is that we can't just move the valley to the city because the city is already very established.</comment>


Down with philanthrocapitalism, says an entertaining polemic - <AUTHOR> https://www.economist.com/books-and-arts/2019/01/26/down-with-philanthrocapitalism-says-an-entertaining-polemic <comment><USER2> I read this book and, to be honest, did not enjoy it very much. It consists largely of profiles of people involved in this sort of philanthrocapitalism. The main theme seems to be that the ultra-wealthy have coopted the work of social institutions in such a way as to undermine efforts for truly revolutionary change, that is change that might threaten them. The premise is interesting but the content is pretty boring. I got tired of reading about people whom the author believes to be mislead or malicious or otherwise on the wrong path. For those interested he gave a talk at Google in Cambridge that was pretty good. [https://youtu.be/d_zt3kGW1NM](https://youtu.be/d_zt3kGW1NM)

<comment><AUTHOR> It's a worthy topic, and a solid complement to Piketty's work.

Investigating and articulating the "apparatus of justification" is helpful.

</comment></comment><comment><USER3> text version : [https://termbin.com/40fa](https://termbin.com/40fa)</comment>


Where to find a good CTO for your startup? - <AUTHOR>

What do you think is the best way to find a good CTO for your startup? ...especially after you have been established for a little while?
A friend recently asked me this question. Usually my response is to search through the people you know or have worked with and respect. Failing that to search through your extended network and base the decision upon the recommendations people get and, provided the person is able to and willing, on a trial-run period with whoever you decide to take on.
Otherwise I suggest using a specialised/alternate recruitment method to explore the niches as this works well e.g. posting an ad on your blog or an ad using SnapTalent or registering a need on YouNoodle generates excellent leads compared to the more traditional agency methods.
However, her startup is fairly established and is having problems finding suitable people. I have included text from her blog below which provides an overview with what she is looking for (from http://www.birthofastartup.com/).
Any comments, suggestions, and feedback on the experiences and thoughts of the others here is most welcome.
Thanks.
<comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment></comment><comment>--
"Skimbit now has a good size team (Joe the amazing Marketing Director and Matthieu the incredible Operations Manager), but what we really need now is a CTO.
We have a team of developers offshore, but we would like someone to really champion Skimbit from a technical perspective, with experience in scaling web applications, and in building innovative services. As we are a small team, the CTO would also have to be a lead developer (so experience with Javascript, AJAX libraries and PHP essential), and probably be involved in some front end development work too. But aaah, isn't that the joy of working for a start-up, you can be a jack-of-all-trades, and be truly an integral part of building something special.
Let me know if you or anyone you know would be appropriate. The candidate doesn't need to have been a CTO before, but is ready (and experienced enough) to be one now, at least." </comment><comment><USER2> I think what your friend's startup _really needs_ is a VP of engineering/ Chief Architect.

Once that is taken care of you can figure out what _type_ of CTO you would like to hire. Based on a paper I read, there are 4 types of CTO's between which to choose from:

1\. CTO as "Infrastructure Manager"

2\. CTO as "Big Thinker"

3\. CTO as "Technology Visionary and Operations Manager"

4\. CTO as "External-facing Technologist"

Here's a link to that paper: [pdf]

[http://www.brixtonspa.com/Career/The_Role_of_the_CTO_4Models...](http://www.brixtonspa.com/Career/The_Role_of_the_CTO_4Models.pdf)

Have you searched linkedin for current VP's, Dir. & Engineering managers? Or do you know highly technical people in other companies that can introduce you to such people?

</comment><comment><USER3> CTO's come in a couple of different favors, generally ranging from being very technical to be very 'executive'. At worst they're just an extra layer of management, at best they're the visionaries behind the products. Some code, some just talk. The cost for a good one is usually 'equity'.

<comment><AUTHOR> This is why I advocate, where possible, try-before-you-buy. It is an important decision and very costly to correctly.

With regard to people in technically expert roles (CTO\CIO\etc\etc) they really _must_ be able to walk and talk. The hardest part is getting super- talented people on board, and equity or performance related incentives in such cases is a neccessity.

</comment></comment><comment><USER4> "CTO" is a pure vanity title. It's a little silly to go looking for "the right CTO". Your friends want an evangelist product marketing manager, not a "CTO".

<comment><AUTHOR> I have yet to meet a marketing manager that builds/codes his product(s).

Maybe I should meet more marketing managers?

<comment><USER4> Lots of CTO's don't build products, either.

</comment></comment></comment><comment><USER5> Don't hire into a CxO position the way you hire a technical staff member. Imagine you are a shareholder and ask yourself where do want your company to be in x years. Then find a person who has experience in generating that sort of change for an organization

</comment><comment><USER6> CIO.com has a pretty cheap ($300) job posting section. I don't think it gets much more targeted than that.

<http://www.cio.com/solutions/careers/wanted/1>

<comment><USER4> CIO != CTO. CIO's actually do stuff.

</comment></comment><comment><USER7> Hire a lead developer. If they have the chops, promote them to CTO.

For a startup, there really isn't any other way unless you or your investors know somebody.

</comment><comment><USER8> you need to define offshore. start-ups are all about execution and disconnection between those road-mapping and those executing is a major issue. if this is China i can help you get in touch with people who can help. contact info at the bottom of this page:

<http://adsotrans.com/readme.html>

</comment><comment><USER9> Did they raise money? Angels/VCs would be my first choice for referrals since networking is so powerful.

<comment><AUTHOR> Yes. But there are many dangers to this (many a horror story of VC self- interests in appointments) and in my experience it is better to search your closest circle first before moving to the next degree of seperation.

</comment></comment><comment><USER10> Get a hacker who didn't get in YC.

<comment><USER11> As a CTO?

Most won't be interested, they rest won't be any good. :-)</comment></comment>


Apple Acquires German Eye Tracking Firm SensoMotoric Instruments - <AUTHOR> https://www.macrumors.com/2017/06/26/apple-acquires-sensomotoric-instruments/ <comment><USER2> Building out their AR division it seems like.

<comment><USER3> Looks like they're doing cool things too.[0]

[0] [https://www.theverge.com/2017/6/26/15872332/apple-arkit- ios-...](https://www.theverge.com/2017/6/26/15872332/apple-arkit- ios-11-augmented-reality-developer-excitement)</comment></comment>


The Lucas-Penrose Argument about Gödel's Theorem (2012) - <AUTHOR> http://www.iep.utm.edu/lp-argue/ <comment><USER2> Part of this discussion illustrates something about philosophy that once struck me as odd. Lucas carefully constructs a somewhat formal argument for his position, that would, if correct, rule out the computational theory of mind. One counterargument takes off from the point that Lucas' argument assumes that any computational model of a mind must be consistent, and depends on a mind being able to establish its own consistency. In response, we are told "Lucas thinks it is unlikely that an inconsistent machine could be an adequate representation of a mind." So now the careful, structured argument is reduced to a personal opinion? (The article includes some more specific variations on the theme by Lucas, but they all seem to me to be appeals to plausibility.)

To me, this seems to leave Lucas with the burden of proof, and until he or someone else can counter this objection with something more than an opinion, the argument is dead in the water. I used to wonder why philosophy would hang an elaborate argument on personal opinions, but I have come to appreciate that whenever you speculate about matters where there is insufficient evidence to settle the issue, it always comes down to opinions, though this is often overlooked in the discussion.

<comment><USER3> You are doing good philosophy here. Though: I'd be careful to move from the fact that Lucas' argument comes down to a personal opinion to the fact that all philosophy comes down to personal opinions.

I assume you already know about the concept of "commitment" in Philosophy, but I'll explain it briefly here in case anyone else comes across this comment.

Sometimes while you can't show that a fact is categorically false (given some available evidence), you can show that people who believe that fact are committed to believing other facts. In this case Lucas' own argument has committed him to the "personal opinion" that an inconsistent machine cannot be an adequate representation of mind. But his belief isn't entirely unfalsifiable. If new evidence makes him give up this belief (e.g. a rise of paraconsistent logics) he'll have to give up his original belief along with it.

<comment><USER4> It's not about personal opinions. Or rather it is, but not in an obvious way.

Human minds are clearly not consistent. Human minds are a loose collection of cobbled-together heuristics.

Logic is one of those heuristics. It has limits because ultimately "logic" ends up being not a personal opinion, but a personal experience of the truth - or otherwise - of a proposition.

Developed and trained minds have generated a heuristic of independent consensus about truths and experience, and strategies for increasing the correlation between the truth experience and the reality experience.

Less developed untrained minds have a much more naive and subjective experience of "truth."

But both work on the same foundation - a nebulous and indefinable subjective experience that is _associated_ with truth, and is typically mistaken as the definition of it.

It's impossible to "prove" truth, because the experience of deciding whether or not something is true is absolutely subjective.

Any attempt to make an objective definition will always be filtered through that subjectivity and reduced to either having that experience or not having it.

We're back to qualia, as usual. No one knows what "having an experience" really means. Until that question is answered, there are no tools for dealing with the rest.

You can argue "But what about the scientific method, and mathematical proofs?" Same answer - they're practices that generate the truth experience in trained minds. They have a better predictive record and are better at finding consistent patterns than the disjointed heuristics of untrained minds. But they still don't - and can't - prove "truth" in any kind of ultimate definitive guaranteed-to-be-objective way.

They certainly can't guarantee that the truth experience is never biased, contingent, limited, naive, circumstantial, or possibly even just plain wrong.

The implications for AI are obvious. If a machine is better at finding consistent patterns, it will appear smarter than a human. It will still be smarter even if it makes errors that are obvious to a human, because at the same time it _won 't_ be making errors that humans do make, and which are similarly "obviously wrong" to the AI.

It's the hit rate that matters, not idealised philosophical perfection.

</comment></comment></comment><comment><USER5> Penrose argument, while it can be challenged, is actually much more careful than dismissals here suggest.

For instance people talking about 'humans are not consistent', we are talking about effort directed into a well specified formal domain, and after long term reflection. So, of course, people make mistakes in mathematics all the time, but we are talking about consistency after intense review over long period of time. We write a program, and cant find the bug even if we look at it for a google years.

To the claim, 'Godel statement is not interesting relative to other statements', the goal is that to demonstrate non-algorithmic nature of _some_ human activity, which itself would be a big deal if true.

A more qualified version of the LP claim can be expressed as follows 'One of the following is true 1) The activity of humans in some formal domain(like mathematics) is inconsistent in a deep way(not routine mistakes). 2)Humans are reflective consistent, algorithmic but will never have access to the source code(a claim about limits about brain research). 3) We are reflective consistent, can access source code, but wont be able to see why the source itself is consistent.'

</comment><comment><USER6> Both the Lucas-Penrose argument and the counterarguments seem to assume that consciousness is a phenomenon within the laws of physics which arises from more fundamental laws (e.g. chemistry or quantum mechanics), which is (to me) a completely non-obvious assumption.

For example, I perceive my own thoughts rather than other people's. This implies that my own thoughts would have an additional physical property, that of being perceived by me, which the thoughts of other people lack. However, according to all up-to-date theories of physics and neurology, there is no difference between my own thoughts and other people's that would explain the presence of this additional property.

<comment><USER7> For you to perceive your thoughts doesn't require different properties to other people's thoughts. Just different values to common properties.

It's not clear why you would expect this to be inherently different from any other neurological response. For example, if I stub my toe, are you suggesting that science doesn't have an answer to why you don't feel it?

<comment><USER6> I am suggesting that the fact that I (the perceiving subject) am myself (the biological entity) rather than you (a different biological entity, but ostensibly subject to the same laws) is (a) an objective fact (b) not within the domain of science. I do not expect this fact to map to any observable physical properties.

<comment><USER7> It's because the thing generating the thoughts (you) is coupled to the thing perceiving the thoughts (you) via pathways that can carry the information. I, however, am not connected to that thing (you) via equivalent pathways.

I am, as luck would have it, connected in a more or less identical fashion to the thing creating my thoughts (me).

Physics is ok with all of that.

</comment></comment></comment></comment><comment><USER8> Refuting Lucas is very simple: Godel sentences can only be constructed for circumscribed systems, i.e. a system where you have written down _all_ of the axioms and inference rules. So the only way to circumscribe a human brain is to isolate it from its environment. As soon as you let it communicate with (say) another human brain, you can no longer Godelize it because that brain is not the system any more, it's the two communicating brains working together. _That_ system might have a Godel sentence of its own, but it's not the same as the Godel sentence of individual brains.

So if I can put you in an isolation tank and model your brain, then I can in fact (at least in principle) construct your Godel sentence and know for certain that you will never come to the realization that this outrageously complicated mess I've just constructed (the one that says of itself that you will never come to see its truth) is true, and I can feel smug about the fact that I can see that this is true and you never will. But here's the kicker: I can never gloat about my superiority to you, because as soon as I do you are no longer in isolation. You are communicating with me, and the sentence I've take great pains to construct is no longer your Godel sentence. It is the Godel sentence of you in isolation, but as soon as I tell you your Godel sentence -- indeed as soon as I (or anyone else) say _anything_ to you, my construction falls apart and I have to start over.

Ironically, far from proving that we are not machines, Lucas's argument actually goes a long way towards demonstrating that we _are_ , because coming up with examples of things that we interacting brains know to be true that a particular isolated brain will (with extremely high probability) never come to realize is not difficult. The four-color theorem, for example, is probably beyond any single isolated human brain. Indeed, the very argument you are reading now is probably beyond any single human brain because the brain that's writing it would never have come up with it had Godel and Lucas (and Turing) not paved the way.

<comment><USER9> Does your argument hold if you consider that input to the brain is limited to the reception of electromagnetic/mechanical waves through a set of sensors, being the fact that one can transmit speech (and Godel sentences) through those sensors is just a higher level abstraction?

Put in another way: Couldn't I in principle define such a circumscribed system with all axioms and inference rules by including all of those sensors and all of their possible states into the system?

<comment><USER8> Yes, of course you can. But if _you_ are _part_ of that system, then _you_ can't Godelize it. In order to Godelize a system, not only does the system need to be circumscribed, but the thing doing the Godelizing has to be _outside_ of the boundaries of the circumscription.

Let's recall the original argument:

"a mechanist formulates a particular mechanistic thesis by claiming, for example, that the human mind is a Turing machine with a given formal specification S. Lucas then refutes this thesis by producing S's Gödel sentence, which we can see is true, but the Turing machine cannot. Then, a mechanist puts forth a different thesis by claiming, for example, that the human mind is a Turing machine with formal specification S'. But then Lucas produces the Gödel sentence for S', and so on, until, presumably, the mechanist simply gives up."

When you are presented with S there are two possibilities: either S includes you, or it doesn't. If S includes you, then you can't Godelize it. If S doesn't include you, then you might be able to Godelize it, but if you present your result to the thing that S is supposed to be a model of -- indeed as soon as you interact with that thing in any way -- then S is no longer an accurate model of that system because now it is interacting with something that, by assumption, was not part of the model.

</comment></comment></comment><comment><USER10> Most interesting part was suggestion that Gödel himself agreed with Penrose argument against Strong AI. I think this will be highly contentious.

<comment><USER10> Here is the quote from Gödel supposedly supporting this:

"So the following disjunctive conclusion is inevitable: Either mathematics is incompletable in this sense, that its evident axioms can never be comprised in a finite rule, that is to say, the human mind (even within the realm of pure mathematics) infinitely surpasses the powers of any finite machine, or else there exist absolutely unsolvable diophantine problems of the type specified" . . . (Gödel 1995: 310).

</comment></comment><comment><USER11> Solomon Feferman on Penrose's Gödelian argument

[http://math.stanford.edu/~feferman/papers/penrose.pdf](http://math.stanford.edu/~feferman/papers/penrose.pdf) (PDF)

</comment><comment><USER12> 1\. If Lucas and Penrose are right, there are statements which are unequivocally true, but which cannot be proved in any known formal system. It should be possible to exhibit a few. (Extra credit if they avoid theology.)

If the only such statements are artificial Gödelian sentences, I'm afraid I'm...uninterested, in the same way Lucas is uninterested in inconsistent humans.

2\. Lucas and Penrose assert that some entities are significantly more powerful than others. To my knowledge, Lucas describes no mechanism for this. (To his credit, Penrose does, but, to my knowledge, the Bell inequality among other things means quantum mechanics is fundamentally random. That's not helpful.)

What could be the nature of such a mechanism? If it's material, it should be possible to include it in future machines. If it's not, we are in the realm of theology again.

3\. So humans are intelligent and intelligent-seeming machines only simulate intelligence. If the difference is not common, obvious, and readily meaningful, then where is the distinction? ("So what? I can't write an opera either.")

<comment><USER8> > there are statements which are unequivocally true, but which cannot be > proved in any known formal system

No. You are misunderstanding Godel's theorem. For any given formal system there exists a Godel sentence which the system cannot prove. But the Godel sentence for every system is _different_. Moreover, there is no _algorithm_ for constructing a Godel sentence. If there were, then a TM could follow that algorithm to construct its own Godel sentence.

So every formal system has a (different) Godel sentence, but there does not exist a universal Godel sentence that is unprovable by all formal systems.

<comment><USER5> Constructing the sentence is algorithmic. The key part is asserting that the sentence is true. For instance ZFC will prove that A:(ZFC cant prove GodelStatement(ZFC) OR ZFC is inconsistent).GodelStatement is an algorithmic function which takes a list of axioms in some formal framework.

Now, lets make ZFC' which is ZFC + 'ZFC is consistent'. ZFC' can prove A(as it contains ZFC) and uses the consistency of ZFC to prove A':(ZFC cant prove Godel(ZFC)) .

Similarly, a program decides a set of problems(like does this Turing machine halt or does this diophantine equation have solutions) with access to its source code will be able to algorithmically generate the problem instance on which it will not halt. You can modify the program to create a new program which will use this information, but it will be a new program.

<comment><USER8> > Constructing the sentence is algorithmic.

No, it isn't. But it's a non-trivial point.

> Similarly, a program decides a set of problems(like does this Turing machine > halt or does this diophantine equation have solutions) with access to its > source code will be able to algorithmically generate the problem instance on > which it will not halt. You can modify the program to create a new program > which will use this information, but it will be a new program.

So this all depends on what you consider a "new program". Suppose we write a program that actually does this: analyzes its own code, algorithmically produces the Godel sentence for that code, then modifies its code to include that as an axiom, forever. _That_ program is a program, and _that_ program will _also_ have a Godel sentence, but one which it cannot construct using _that_ algorithm. You need a _different_ algorithm to construct Godel sentences for programs that constructs Godel sentences on programs that don't construct Godel sentences.

The result is a hierarchy of Godel-sentence constructors. At any level in the hierarchy the procedure is algorithmic, but going from one level to the next is not. It's similar to the process of constructing the hierarchy of ordinals, which is also provably non-algorithmic.

<comment><USER5> There is a program, G, which will take as input the source code of the program, P (in some fixed language) and output Turing machine, T which doesnt halt, such that either P will fail to say T doesnt halt, or P has mistakes(claims halting for some Turing machines when they dont halt). Some programs P can algorithmically run P', P'' etc, but as long as that process is part of the source code of P, G will work.

<comment><USER8> Sure. So? How does that in any way refute what I said?

<comment><USER5> Point in my first post was that G is algorithmic. What you are referring to is the repeated extension of G which gets into issues of ordinals.

<comment><USER8> Yes, but I'm the one who made the original claim that "there is no algorithm for constructing a Godel sentence". So I'm the one who gets to say what I meant by that :-)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> _> Now suppose that we construct the Gödel sentence for this formal system. Since the Gödel sentence cannot be proven in the system, the machine will be unable to produce this sentence as a truth of arithmetic. However, a human can look and see that the Gödel sentence is true. In other words, there is at least one thing that a human mind can do that no machine can. Therefore, "a machine cannot be a complete and adequate model of the mind" (Lucas 1961: 113). In short, the human mind is not a machine._

That is not a difference between human and machine. It's a rhetorical trick at best, and an unreasonable appeal to mysticism at worst.

A human mind looking at the Gödel sentence while strictly adhering to the same formal structure could _also_ not see that the Gödel sentence is true. Conversely, a machine that is allowed to operate outside of this postulated formalism could perfectly well make an inference that the Gödel sentence is true.

The Lucas-Penrose argument boils down to a questionable attempt at a logic bomb. So by first tying the machine's hands, they argue that the machine's hand's are indeed tied, and therefore humans - who in this example have been given free rein - can do something that you explicitly disallowed machines from doing.

<comment><USER14> What formalism, if any, is the human mind subject to? Isn't our current conception of a machine that it will bound to some formalism in terms of reasoning? Are we so bound?

<comment><USER13> That's a loaded argument.

Human biology, and by extension human minds, follow a myriad of rules that are a result of biological processes being played out. Likewise "machines" also follow the rules laid out by their physical design. There is no fundamental difference in this regard, there is no new set of information-theoretical rules that comes into play when you switch to a carbon-based machinery.

> What formalism, if any, is the human mind subject to?

In the context of this argument, the mind of the human mathematician would be subject to the rules of the formal system. Since Gödel we know that such a formal system cannot be proven true inside the system itself. However, an entity that views the system from the _outside_ can potentially see it's true. There is no fundamental difference between a human mind and a hypothetical machine mind as far as the capability to come to the same conclusion is concerned. That's why Lucas took special care to specify upfront that the machine mind is prohibited from coming to that conclusion, by confining it to live within the formal system only. Yes, their argument is really that circular.

> Isn't our current conception of a machine that it will bound to some > formalism in terms of reasoning? Are we so bound?

We are not, and neither would a generally intelligent machine. The burden of proof is on Lucas/Penrose to show that a generally intelligent machine would still be bound to that formalism, at which point it would cease to be considered generally intelligent. They seem to argue that their postulate is true because the _individual components_ of such a machine are bound by those rules, but then again so are the individual components of our brains.

<comment><USER10> So your claim is that the Human mind is a physical machine and that computers are also physical machines and thus both are bound to physical laws... and this negates Penrose how?

Do you think Penrose disagrees that the Human mind is bound by physical laws??

<comment><USER13> I'm not making a claim, I argue based on what we already know. Penrose is the one claiming something here.

 _> Do you think Penrose disagrees that the Human mind is bound by physical laws??_

Yes. Having read his work in the past, I _know_ that he disagrees the human mind is bound by physical laws. This is the whole reason behind the argument they're putting forth to begin with: they postulate that humans are capable of making an inference that could not possibly be made by a machine intelligence.

However, it has never been shown that we are _not_ a machine intelligence.

<comment><USER10> Then I am sorry to say you have no idea what you are talking about. Penrose _nowhere_ claims the human mind is not bound by physical laws.

Cite one place where he says anything like this or go home.

<comment><USER15> He argues that quantum magic enables human minds to do things that formal computer systems cannot do. I'm not sure what his position is on computers that incorporate quantum magic though.

<comment><USER13> I suspect the argument _manyoso_ is setting up here is based on sophistry around the concept of "physical laws". His stance is most likely that quantum woo is part of the physical laws, in the same way a fundamentalist religious person would assert that the content of a holy book is part of the physical laws.

What I - and I hope most people - mean by the phrase is different though, it's the body of actual physical laws that have been shown scientifically.

> I'm not sure what his position is on computers that incorporate quantum > magic though.

Interesting thought experiment. I suspect he would be fine with those in theory, however since he already declared this special connection to the supernatural for humans it'd be interesting what computer components he would consider equivalent. But the beauty of his position is that, in the event of a generally intelligent computer emerging, he could always claim that any given nanoscale computing component is the silicon analogue of "quantum microtubules" (which was his woo-related organelle of choice in neurons). It's not like he ever has to prove his claims in order to be taken seriously.

<comment><USER16> > _I suspect the argument manyoso is setting up here is based on sophistry > around the concept of "physical laws". His stance is most likely that > quantum woo is part of the physical laws, in the same way a fundamentalist > religious person would assert that the content of a holy book is part of the > physical laws._

That falls far below the standard of discussion we ask users to abide by here. Please make your points directly and without such cheap insinuations.

<comment><USER13> It's not an _incorrect_ summary of his position. I agree it may not look like a totally objective characterization on my part, _but you 're saying this in a discussion where I was literally told to "go home"_, by the same user you're protecting here.

If you think my comments in their entirety detracted from the discussion, I'd like you to tell me. Otherwise I'm asking you to consider this statement in the context of both manyoso's and my comments as a whole.

This is a discussion about quantum quackery, and you're stepping in on behalf of the pro-quackery side that has no problem telling me personally that I "have no idea what" I'm "talking about", and other dismissive discourse.

<comment><USER16> I chided manyoso elsewhere. The problem with your comment was not that it incorrectly summarized anything, it's that it broke the HN guidelines by calling names ("quackery", "sophistry", "woo", "fundamentalist"). That matters far more to HN than whether Penrose is wrong about Gödel.

Commenting here requires being scrupulously civil, even when others are not. Any lower standard would lead to an unstable system.

<comment><USER13> In a discussion where one side freely makes stuff up as they go along and attempts to put the burden of proof on everybody else, I stand by these characterizations.

When someone asserts in an authoritative tone that quantum gravity is the key to unlocking consciousness at the heart of the universe, that is utter hogwash and deserves to be called out as such. You may personally not like my pointing this out, but the entire "field" of quantum consciousness is a religious movement that makes unsubstantiated claims about the nature of reality.

It actually _is_ quackery. Redefining the term 'physical laws' to include magic in order to shield an opinion from criticism _is_ actually sophistry. Insisting that spiritual convictions are factual statements about the universe is _actual_ fundamentalism. These aren't bad words wielded to hurt someone, they are supposed to convey meaning.

I never meant to denigrate anyone personally. I strongly feel that opinions must be fair game though when it comes to criticism. In doing so suppose I must come across more harshly than I intended or maybe I'm just exceptionally bad at articulating myself. Whatever my intent, it's clearly not working out all that well. It's probably a good idea for me to take a break from HN for a while.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Well, I don't think our brains work by applying "logic" when we think about Gödel's theorem (or anything else). We evolved to do pattern matching, so each of us spends decades to learn more and more sophisticated pattern matching techniques, starting from mom and dad's faces to counting things to multiplication tables to, finally, understanding Gödel's theorem (for some people).

In light of this, we can reinterpret "However, a human can look and see that the Gödel sentence is true" as:

 _When you take the best pattern matching machine nature has produced, train it with distilled essentials of centuries of mathematical geniuses, and present it with the Gödel sentence, the pattern matcher strongly signals "This looks true!"_

When viewed this way, it looks less like an inherently human-specific achievement, but more like exactly how ML algorithms work. The only difference is that ML cannot quite pull it off, so far.

</comment><comment><AUTHOR> [http://www.cs.bham.ac.uk/~mmk/papers/05-KI.html](http://www.cs.bham.ac.uk/~mmk/papers/05-KI.html) (Why is the Lucas-Penrose Argument Invalid?)

<comment><USER18> > The matter is confused by the prima facie paradoxical fact that Gödel proved > the truth of the sentence that "This sentence is not provable."

Gödel didn't prove that. He saw that it was true.

</comment></comment><comment><USER19> What if the human mind is computational, but isn't one unified system. I think most neurologists today believe the mind is composed of many loosely coupled systems communicating with each other?

<comment><USER6> A collection of loosely coupled computational systems still forms a computational system, not some fundamentally different entity.

</comment></comment><comment><USER20> Ugh, this again.

1\. Let's suppose for sake of argument that humans really can see the inherent truth of "Peano Arithmetic is consistent". That doesn't mean humans violate Gödel's Incompleteness Theorem: it could just mean that humans use axioms stronger than PA.

2\. Gödel's Incompleteness Theorem only applies to systems that are perfectly logically consistent. Not sure how Penrose didn't notice, but humans... aren't.

3\. When scientists proposed Quantum Mechanics as a replacement for Classical Mechanics, it was on them to explain how Quantum Mechanics simplified to Classical Mechanics in the common case. "Penrose Mechanics" is an even more radical departure — especially from a physics of computation standpoint, as Penrose Mechanics by definition would allow solving at least some of the problems in (ALL - R) in ~polynomial time. Penrose needs to explain how Penrose Mechanics reduces to Quantum Mechanics in the common case.

4\. Penrose proposes that (a) there exist new physics, (b) that evolution has learned to computationally exploit the new physics via microtubules, and yet (c) that humans are the only lineage to make use of this feature of microtubules, even though microtubules are found in all eukaryotic cells (from mushrooms to amoebae). From a predator-prey standpoint alone, it would seemingly be a huge evolutionary advantage to be able to compute NP or R functions in polynomial time. (That ability is not _strictly_ implied by Penrose Mechanics, but it's a very likely consequence.) Penrose needs to explain why only humans are taking advantage of the computational power of microtubules, when microtubules have existed for billions of years and across millions of species. (TL;DR: It's the pineal gland all over again.)

<comment><USER10> #1 Please show how to program a Turing machine to use "axioms stronger than PA"

#2 Please show how to program a Turing machine so that it is not logically consistent at a fundamental level?

#3 Are you questioning the viability of objective collapse theories in general? To date we have no experimental evidence of said theories, but I don't think anyone has suggested they are inconsistent with QM. Are you? If so, please show how...

#4 Show where Penrose has said humans are only species to make use of microtubules and your claims regarding Penrose' theory of objective collapse and having staggering new computational speedups are ... without any evidence. Please provide some.

The tenor of your comment suggests you find Penrose to be an idiot and missing obvious problems. Consider that perhaps you are the one misunderstanding what he is proposing and that he is not, in fact, an idiot.

<comment><USER20> 1\. Easy. Program a computer with the axioms of ZFC. Not powerful enough? Program it with ZFC+Con(ZFC). Repeat as necessary.

2\. The Turing machine itself is logically consistent. The semantic interpretation of its data need not be logically consistent: it's possible to write a computer program that prints "2+2=5" to the screen. Likewise, a human brain may be made of physics and physics may be logically consistent, but the semantics of the data in the brain (the "beliefs") need not be consistent.

3\. No, no need to reject collapse itself (though I'm more of an Everett guy). Penrose postulates the existence of a new level of physics that is _not_ Quantum Mechanics. People who aren't careful call it an extension of QM, but QM's computing model is limited to solving a small subset of NP problems (BQP) in polynomial time, and BQP is theorized to be a proper superset of P. However, Penrose's proposed physics would allow solving problems outside of NP in polynomial time. Hence, Penrose's physics IS NOT quantum physics.

4\. It is physically impossible for computers (as we understand them today) to solve problems outside of the set we call "Turing complete". Penrose claims that there's at least one problem outside that set that the human brain can nonetheless solve: checking the consistency of formal systems. If Penrose's assumption were true, computers (as we understand them today) would consequently be strictly less powerful than the human brain. The crux of Penrose's position is accepting this consequence as true, then asking how that's possible. I reject that hypercomputation of problems beyond Turing- completeness is what's happening, i.e. that humans simply hold unjustified beliefs about the answers to such problems.

I do not doubt that Penrose is an intelligent and educated person. However, his expertise is General Relativity. It's bad enough when he tries dipping his toes into Quantum Physics, but when he wades into Physics of Computation, he is no longer acting as an expert, but as an interested layman. It's only because of the authority he holds as a GR expert that his argument is treated seriously, but that authority is not actually relevant to his argument.

<comment><USER10> #1 Not easy. Prove it. Show a Turing machine programmed with ZFC that can not be modeled by a Turing machine programmed with PE. You can not do so because Turing machines are universal. The fact that you claim this is easy tells me you do not understand what a Turing machine is.

#2 See fundamental level. Penrose claims that what sets us apart from Turing machines is fundamental. But whatever, you've refuted whatever point you wanted to make by saying human's are not logically consistent. Your snark about Penrose not understanding is as empty as whatever point you were trying to make.

#3 Cite a paper showing that objective collapse gives these supposed algorithmic speedups or go home. NOTE: objective collapse theories are an active area of research and are not limited to Penrose by any means. Your claim that they are inconsistent with QM begs for evidence. Cite some or stop spreading nonsense.

#4 Your answer here is completely void of any context to the question: where Penrose says that microtubules are limited to humans. I take it you concede that he did not say any such thing?

You treat Penrose as an idiot missing obvious problems. I think it far more likely that you've misunderstood. Pity your lack of humility might make it impossible for you to understand what he actually argues rather than your strawmen.

<comment><USER20> Also: before I bother building a Turing machine that implements a proof- generator for statements in ZFC, you should do me the courtesy of showing your investment by building me a Turing machine that multiplies two integers.

Turing machines _suck_. Building a Turing machine that implements ZFC proof- generation is a project appropriate to a graduate-level paper, not something to toss off in an Internet pissing contest.

<comment><USER10> You were the one who used the phrase "easy" with regard to Turing machines and feasibility of showing them.

<comment><USER20> Fine. "Straightforward, if menial and tedious".

</comment></comment></comment></comment></comment></comment></comment><comment><USER21> Site is down. Anyone have a mirror?

</comment><comment><USER22> Franky it's irrelevant. Penrose's insistence that the human mind isn't algorithmic in the Turing sense is born from his human insecurities. But if the human mind isn't bound in such a way, than any man-made computer need not be bound either. Penrose's argument falls short of being a proper dualist argument. Furthermore Roger Penrose has not proven his claims, and they are not supported by mainstream neuroscientists. He appeals to quantum woo that he pulled out of his ass.

<comment><USER16> > _born from his human insecurities_

> _woo that he pulled out of his ass_

It's not ok to argue like this on HN, so please don't. It lowers the quality of discussion in its own right and sets off a downward spiral from others.

Edit: Actually, we've banned your account. Your comment history shows that you've broken HN's civility rule so egregiously, and so repeatedly, that we should have banned it long time ago. If you don't want to be banned on HN, you're welcome to email email@example.com and promise to follow the rules scrupulously in the future.

We detached this subthread from [https://news.ycombinator.com/item?id=14446064](https://news.ycombinator.com/item?id=14446064) and marked it off-topic.

</comment></comment><comment><USER23> > _When we notice an inconsistency within ourselves, we generally "eschew" it, > whereas "if we really were inconsistent machines, we should remain content > with our inconsistencies, and would happily affirm both halves of a > contradiction"_

I feel that only philosophers & logicians are this black-and-white. There are many people content to occupy a midpoint on the spectrum of "This fact is true"..."This fact is false"; some even will accept a range!

One fact I think we can all agree on is that philosophers are: old; white; dead; men; and wrong.

<comment><USER23> Love too get downvotes with no comments/feedback. Is this about the dead white men? I take it back. I didn't mean it. I changed my mind. I never meant for it to be taken this way. of all the possible interpretations of my words, I intended you to adopt the one where they were both witty and erudite. It's your fault you picked the wrong one. I stand by my words. I am right. Only I am right. I have seen into the heart of Man and I know its true meaning.</comment></comment>


Habitat – a massively multiplayer online role-playing game for the Commodore 64 - <AUTHOR> https://github.com/Museum-of-Art-and-Digital-Entertainment/habitat <comment><USER2> I wondered what this looked like. I found a promo video ([https://www.youtube.com/watch?v=VVpulhO3jyc](https://www.youtube.com/watch?v=VVpulhO3jyc)) and some apparently VCR-recorded gameplay ([https://www.youtube.com/watch?v=KTtIzLZGNLw](https://www.youtube.com/watch?v=KTtIzLZGNLw)).

There are some interesting notes in the file at [https://github.com/Museum-of- Art-and-Digital-Entertainment/h...](https://github.com/Museum-of-Art-and- Digital-Entertainment/habitat/blob/master/chip/habitat/docs/hostguide.t) re: architecture.

</comment><comment><USER3> The repository should really mention the origin of the source code and the license. I'm always a bit skeptical about the legality of ancient source code suddenly popping up.

The origin is mentioned in their blog post. Very nice that Fujitsu has given the rights to release the source code. There are still parts missing, so let's hope that AOL will be as generous.

[https://themade.org/posts/1701](https://themade.org/posts/1701)

<comment><USER4> I'd be surprised if AOL still had the qlink code sitting around in an easily accessible format. I think that's more of an issue than the legal problems.

<comment><USER5> Legal is the problem. They have the code. We've confirmed that fact.

</comment></comment></comment><comment><USER5> Hey gang, I'm the guy behind the MADE. I'm available to answer any specific Habitat questions you may have. Additionally, we're in #made on Freenode, where we frequently discuss ancient computers. Feel free to drop in if you have any thoughts or questions about the project.

What we really need is to start talking to AOL legal about QLink code, as we know they have the code, we just need to get it into a form we can publicly preserve. That means legal chatter time.

</comment><comment><USER6> Don't miss out on the lessons as well: [http://web.stanford.edu/class/history34q/readings/Virtual_Wo...](http://web.stanford.edu/class/history34q/readings/Virtual_Worlds/LucasfilmHabitat.html)

<comment><USER7> Reading the stories here shows how deep and rich the interactions between the players and the world were. It's basically a very retro Second Life; the original, in fact. Amazing achievement, and really funny seeing developers not 'cheat' to deal with their own mistakes and failures (e.g. trading Death's one-shot kill gun for money in a town square after Death was killed and dropped that gun, because he forgot to heal).

</comment></comment><comment><USER8> There's a great tech transfer doc here that describes the game mechanics:

[https://themade.org/posts/732](https://themade.org/posts/732)

And another post about the compiler used for Habitat:

[http://sdtimes.com/sd-times-blog-macross-6502-on- github/](http://sdtimes.com/sd-times-blog-macross-6502-on-github/)

<comment><USER2> Thanks for the link to The MADE's site. They've got a post on the open- sourcing of Habitat, too: [https://themade.org/posts/1701](https://themade.org/posts/1701)

</comment></comment><comment><USER9> Club Caribe. For people of a certain age... which is much older than the average HN reader, this was the pixellated magic of the internet. Your friends at school didn't even believe you when you tried to tell them about it.

<comment><USER10> Yep I visited it a couple times - I recall the rampant head hunting going on.

</comment></comment><comment><USER11> Great reminder for the early lessons on social media, which didn't really changed since: [http://www.shirky.com/writings/herecomeseverybody/group_enem...](http://www.shirky.com/writings/herecomeseverybody/group_enemy.html)

</comment><comment><USER12> I thought this might be a modern MMO for the C64.

</comment><comment><USER13> I remember reading about this "game" in a Danish computer magazine back in the 80's. Wanted to play it really bad, but of course there was no Internet back then, so it wasn't possible.

</comment><comment><USER14> For people who also don't know anything about it here is a video explaining a little about it [https://www.youtube.com/watch?v=VVpulhO3jyc](https://www.youtube.com/watch?v=VVpulhO3jyc)

</comment><comment><USER15> Neat, I counted 240 bytes on their zero page reserved for application state. They had 16 high speed bytes left for future expansion.

[https://github.com/Museum-of-Art-and-Digital- Entertainment/h...](https://github.com/Museum-of-Art-and-Digital- Entertainment/habitat/blob/master/habitat/Beta/Beta1.0/Source/zpage.m)

<comment><USER16> Addresses 0 and 1 are reserved for I/O on the 6510.

<comment><USER15> Oh really? What kind of I/O? Something in my foggy memory said that first word there was used to control bank switching on the GeoRam memory expansion unit.

<comment><USER16> 6 I/O pins are exposed, the first three bits are used for bank switching, the second three are for datasette control.

[https://www.c64-wiki.com/index.php/Bank_Switching#Expansion_...](https://www.c64-wiki.com/index.php/Bank_Switching#Expansion_Port)

[https://www.c64-wiki.com/index.php/Cassette_Port](https://www.c64-wiki.com/index.php/Cassette_Port)

</comment></comment></comment></comment><comment><USER17> a cursory google search shows that apparently qlink has been reverse engineered ( [http://orrtech.us/qlink/index.html](http://orrtech.us/qlink/index.html) ). I wonder if this would help them...

<comment><USER17> further google-fu shows [https://github.com/ssalevan/qlink](https://github.com/ssalevan/qlink) and [https://github.com/jasmaz/qlink](https://github.com/jasmaz/qlink) but it looks like [http://www.lyonlabs.org/commodore/qlink/](http://www.lyonlabs.org/commodore/qlink/) they really do need the original qlink software to continue the work

<comment><USER5> We use QLink Reloaded, and Jasmaz is in our IRC channel to help. The issue is that QLink uses a really byzantine system of communication with the server, where it's constantly going"57, 26, 23" and each of those numbers means a very distinct function. No one has a clue what those numbers mean, so QLink Reloaded is basically only the bits that could be reverse engineered in this black box situation.

We have modified QLink Reloaded for our purposes, though.</comment></comment></comment>


Comparison of Web Frameworks - <AUTHOR> http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks

<comment><USER2> wow. there's amazing diversity. Must be a nightmare picking one with no experience.

<comment><USER3> Yep, that is why people should not use one. The reason there are so many frameworks is because everyone for the past 15-18 years has been trying to fit the same square peg in the round hole. With the proliferation of RESTful services and RIA/Javascript application, there is no need for server side frameworks short of a small framework to expose your logic as a RESTful service.

<comment><USER4> Wow. I couldn't disagree more. Having plumbing like MVC and ORM built-in increases speed and means less code to maintain. The selection of which one (i happen to like Django) may be a toss up, but there is huge value in a server- side framework.

<comment><USER3> ORM and MVC are not the exclusive domain of a web framework. They are frameworks in and of themselves. That is the problem, people think of the data (ORM), the controller and the view framework as the same thing because they have all been lumped into these "Super Frameworks". They are not and they do not need to be. The old page-post model of web development is antiquated and the frameworks are now trying to deal with that fact by bolting AJAX on top of them and making an even bigger "Super Framework" but there is really no need and it actually pollutes the frameworks with opposing development philosophies; creating more complexity rather than reducing it. The fact of the matter is, that the server only needs RESTful endpoints and an ORM framework (if you are using an OO language). Services by definition represent server logic controllers.

As for the view, they are better served by an event driven framework than they are by MVC in which UI elements are encapsulated and message the greater system via events. I have done it the page-post way for a long time and was a resistant convert, but after building web and mobile apps the new way I have come to find that it is much cleaner and faster to pull the UI off of the server, if it had not been for the browser wars we would have been here a lot sooner.</comment></comment></comment></comment>


Show HN: My First Side Project is Live - <AUTHOR> http://cheaplyinsured.com

<comment><USER2> Kudos:

Nice design, I think it's pretty clear, and everythings got it's place which is nice. Definitely a welcome change from the advertisement riddled sites that are out there today (though you might want to consider even a little bit of addage, maybe choose one of those ad providers that emphasizes sexy looking ads)

I liked your about/info section -- solving a problem that you encountered is a good way to go into a side project.

So after browsing around for a little, some questions (I didn't browse too deeply, so questions may have been answered on the site somewhere I didn't see)

Clicking through to get a quote, the site seems merely like a referral site (just an aggregation of links to other sites by area code) -- are you considering adding any price-showing features? Like by giving people the option to report the quotes they got, or putting up some quote data, or even a rating system, people could know a little more about the comapanies they're about to click through to?

I looked for life insurance, and saw 5 companies I'd never heard of before, and clicked through to one of their sites and it looked pretty bland -- something to better inform that click-through decision would be nice

<comment><AUTHOR> >Clicking through to get a quote, the site seems merely like a referral site (just an aggregation of links to other sites by area code) -- are you considering adding any price-showing features?

At the moment I'm using a company called surehits to provide the listings, and the info they provide is very basic. I do have plans to create a far more interesting platform for connecting customers and insurers, but I decided to keep it very simple to begin with and take the project in steps. My day job keeps me busy so I didn't want to bite off too much for this side project. I've started a few other projects in the past that I didn't finish and I didn't want to do that again.

I do like and appreciate your suggestions and have copied them down - thanks!

<comment><USER2> I definitely get that, not finishing is definitely a thing that happens, congrats on finishing, and it's definitely a usable, good looking site

</comment></comment></comment><comment><AUTHOR> If you have any feedback (+/-) please let me know. I've been working on this site for the last couple of months in my spare time and am interested to hear other opinions as I'm way too close to it to be subjective at this point.</comment>


Ask HN: Selling a Technical Website - <AUTHOR>

My friend has a website that brings around 500K visitors a month all over the world and earns a decent $5K p.m. It has 1000 programming articles. Q: How much should the website be sold at? Points to consider. We have tried some online services and they are ridiculous. <comment><USER2> Consider selling to Internet Brands (<http://www.internetbrands.com/>). They look for sites with healthy organic traffic and the possibility to improve monetization. So those 500K visitors per month should come from a healthy list of keywords indexed in the major search engines and a high page rank.

Does the $5K per month come from ads, affiliate links, product sales, subscriptions? Most likely it's just AdSense, so they'd love that, since they can swap those out for direct sell ads that can be sold across multiple sites they own for a yield 20x as much as you could get from AdSense.

Is the content 100% unique? Who wrote it, and how fast is new content being added to the site? Do you have a staff of writers who are writing quality content? Or is the content user-generated? They'll want to know how much it will cost to keep the site going long term.

Typically a site this size, assuming the traffic is healthy and targeted and the revenue looks like it will keep coming in should go for 12-36x monthly earnings. By Internet Brands standards, 1000 articles is not that much, the traffic is decent, but the revenue is on the low side. Compare that to a site they own like Steve's Digicams, which has 20,000 high quality camera reviews spanning 12 years, a PR4, and revenue in the mid six figures (probably low six figures when they bought it), and for which they likely paid $1 million.

<comment><AUTHOR> Thanks for the inputs. I am almost sure the ads are from direct ad sales and the site has just 4-5 ads listed. It's a PR5 site, good user-generated content, updated daily without fail.

</comment></comment><comment><USER3> How is the 5K/month earned? Adsense? Affiliates?

Valuations for stable websites with those earnings are usually anywhere from 1x-4x annual earnings. Depends on a lot of factors of course. If you'd like a more in-depth review, send me an e-mail (myhackernewsname @ gmail.com)

<comment><AUTHOR> I think it's only direct ads and no affiliates.</comment></comment>


Huboard Is Not Free Anymore - <AUTHOR> https://huboard.com/pricing

<comment><AUTHOR> I liked the tool but I'm definitely not convinced by the pricing, especially considering the price point of competitors like Waffle.io ([https://waffle.io/#pricing](https://waffle.io/#pricing)) or the greater usability of the upcoming ZenHub ([https://www.zenhub.io/](https://www.zenhub.io/)).

I'm a tad more disappointed about the recent change of license from MIT to aGPL (nastiest thing I've had to deal with in OSS).</comment>


Green Eggs and Hash Sprinkle on the Salt and Pepper - <AUTHOR> https://achainofblocks.com/2018/11/19/encryption-vs-hashing-how-are-they-different-how-are-they-the-same/ <comment><USER2> Encryption is basically conversion of one form into other , also know as ciphered text. The encryption is basically done to hide meaning from other person except the one for which it has been written. Encryption is used to protect the confidentiality of data.

Hashing is basically conversion of string or data into shorter fixed value or key which represent the original string or data. Hashing is used in many encryption algorithms.

</comment><comment><USER3> A hash function could be considered the same as baking a loaf of bread. You start out with inputs (flour, water, yeast, etc...) and after applying the hash function (mixing + baking), you end up with an output: a loaf of bread.</comment>