Google Taps StackOverflow as Official Android Dev Support - <AUTHOR> http://www.readwriteweb.com/archives/stackoverflow-android-support.php

<comment><USER2> Another nail in the coffin of Google Groups as a useful method of communication.

<comment><USER3> Apples and oranges. I don't see SO as being useful for prolonged discussion, not does it convey any sense of a close-knit community.

Also, I get Google Group messages in my Thunderbird in-box so I don't have to keep checking to see if there's anything new and I can filter, save, highlight items as I see fit. I much prefer mailing lists over bulletin boards, and SO is much like the latter.

</comment></comment><comment><USER4> And then someone started <http://www.forceclose.com/> for Android questions using StackExchange

<comment><USER5> I have a feeling that forceclose is targetting the AOSP style builds and users, such as Cyanogen Mod. I hardly think official Android support will ever touch that segment of the community.

<comment><USER4> I have no idea what any of that means :)

<comment><USER6> AOSP = Android Open Source Project. He's suggesting that forceclose is more to help people modify the Android operating system than to help people write Android applications.

<comment><USER4> Thanks. I'm unfamiliar with the Android dev landscape and only posted it since I saw it on Twitter earlier and thought it was related.

</comment></comment></comment></comment></comment><comment><USER7> Stackoverflow is supposedly one of the more popular Q&A sites for IPhone developers:

<http://blog.stackoverflow.com/2009/06/podcast-57/>

 _...Stack Overflow has become a very popular destination for iPhone development. This is completely accidental, but it is a valid reflection of the vibrant and growing iPhone development community. If you're an iPhone developer, check out the Mobile Orchard website and podcast, which even has a best of Stack Overflow for iPhone developers!..._

</comment><comment><USER8> I remember reading that StackOverflow was built on the .NET platform.

If that is correct, it is interesting that Google would not just give up on Google groups, but move to a solution that is built on top of Microsoft's platform

<comment><USER9> Why would it matter what stack the platform is using?

(Which reminds me, does Hotmail still run on Solaris?)

<comment><USER8> clearly, it matters to you since you're bringing up the question of Hotmail. Btw Hotmail was acquired by Microsoft and Microsoft began porting it to Windows many years ago. They never intended to keep it running on a non- windows platform.

<comment><USER10> You make it sound as though google bought stackoverflow, that is not the case, they are merely buying branding for a set of tags on stackoverflow (something that adobe and red-gate have already done).

<comment><USER8> I'm sure no one thinks that Google bought the company.

Google had a choice of multiple solutions. They chose the one that was built on .NET. Clearly, the primary reason they picked StackOverflow is because they like the solution provided by StackOverflow (and this doesn't say that Google would prefer .NET themselves, in fact, it is safe to assume that they wouldn't)

My point is that this decision is just another example of how anti-msft people are wrong when they say that .NET/Windows is not a good or viable platform

<comment><USER11> I wouldn't construe this as an endorsement of the platform. More of an endorsement of the execution.</comment></comment></comment></comment></comment></comment>


Charging for our product originally hurt but ultimately saved our startup - <AUTHOR> https://medium.com/initialized-capital/how-charging-for-our-product-originally-hurt-but-ultimately-saved-our-startup-391e69ae42ba <comment><USER2> > We didn't want to teach ourselves how to find money-losing customers

This!!!

Coming from the travel business. I remember this vividly.

You acquire a customer that is not loyal to your product even for 3 seconds for 1$ and you make 0.8$ out of that customer.

Building a customer acquisition strategy that will work in the long run and will make you money is such a key realization.

Even if it takes you longer and seems like you are moving slower, you should not be tempted.

At one point, we saw a 200% increase in users over the course of two weeks due to some "growth hacks". Those ended up just costing money in server and engineering costs. None of the customers actually stuck with the product for the long run.

<comment><USER3> 100% agreed. Eventually, most companies come down to people being willing to put money down in exchange for something they value. And then doing that again and again over the course of the relationship.

So many entrepreneurs are really building _products_ , not _businesses_. They want to be insulated by money while working on making their perfect thing. And I get that. Building is fun. It's scary to put yourself and your product out there. And it's hugely unpleasant to have that fail.

But until we try for real, we'll never truly know what works. The sooner and more often we try for real, the more likely we are to find what works.

<comment><USER4> >So many entrepreneurs are really building products, not businesses.

This!

</comment></comment></comment><comment><USER5> >Around 2012, we and a whole cohort of other startups — Simple, Plastc, Swyp, Coin, Final, Stratos, Clinkle, and others — were getting card-issuing companies off the ground.

Let's play a game I like to call "Supporting Character in Thor: Ragnarok, or FinTech Startup?"

</comment><comment><USER6> Generally a client does not have any reason to use your product until they have some skin in the game. They are more than happy to try a free product, but probably will never actually utilize it. And the ones that are on the free plan will be a pain point. If a client or customer is unwilling to spend any money on your product/service there are two options: They are cheap and will never be paying customers, or your sales people are bad at their jobs.

That is slightly hyperbolic, but in my personal experience dead on.

<comment><USER7> Skin in the game doesn't _have_ to mean money. In an enterprise sales context, for example, if a company is going to commit a lot of employee time to an eval or workshop, that may be sufficient. You also presumably have sales reps who can gauge how serious the prospect is. But, definitely, if all you're talking about is a web signup, then there's no skin in the game.

</comment></comment><comment><USER8> I think there is a sense of "if I pay, it probably has a value so said company can charge a customer, and it is likely said company will not to fail so soon." Not that this is always true, but with a reasonable trial and active customer support team, I think a starter plan is never a bad idea at all. Making a paid plan also means the company has to work double harder now to deliver a better product and a better customer experience, unlike IMO a free tool has the "we will get there eventually, let's test with free users first."

<comment><USER9> I'm debating the merits of this right now. For the moment, I'm not charging for my beta. I have received some good feedback so far, but people haven't been as active using it as I would like.

I'm wondering whether it would be better to find a smaller number of people willing to pay for the product and really tailor the experience to them.

<comment><USER10> I would argue yes, find a smaller number of paying customers and tailor the experience to them. It's incredible difficult to get paying customers, and if you can get some, then you can begin the journey of expanding your feature set / distribution channels / promotions to reach other customers.

It's kind of like the idea of focusing on fewer people who love you, vs lots of people who just like you, where love = paying customers :)

</comment></comment></comment><comment><USER11> Hi everyone! [https://www.truelinkfinancial.com/careers](https://www.truelinkfinancial.com/careers) :)

</comment><comment><USER12> Hi, how are your "Personalized plans using sophisticated data analysis" protected from extrinsic fraud and extreme drops in value?

</comment><comment><USER13> Unless you control the market, you don't set the price, the market does.

<comment><USER14> You set your price, and if you do it wrong, you miss the market.

<comment><USER13> So if I clap my hands, and the sun rises, I made the sun rise (sarcasm)</comment></comment></comment>


A gentle introduction to Prolog (2013) - <AUTHOR> https://bernardopires.com/2013/10/try-logic-programming-a-gentle-introduction-to-prolog/ <comment><USER2> I studied Prolog in college (3rd CS year course, 2003).

I concluded it didn't deliver on its promise.

The promise was that, as in the article, you 'Say what you want, not how you want it done.'

In practice, once you start writing non-trivial programs, you run into situations where they take ages to run, as Prolog does its search in the background.

So, you have to start using all these languages features to control and optimize the search, such as: [https://en.wikipedia.org/wiki/Cut_(logic_programming)](https://en.wikipedia.org/wiki/Cut_\(logic_programming\))

And you end up spending a lot of time reasoning about the _how_ that it said you didn't have to care about.

I concluded that, as a result of performance issues, the core Prolog abstraction 'leaks' too frequently for it to be worthwhile. ([https://en.wikipedia.org/wiki/Leaky_abstraction](https://en.wikipedia.org/wiki/Leaky_abstraction))

Its a great promise, if a smarter language or implementation could achieve it, but overall I concluded that if I was going to have to spend all this time reasoning about the _how_ anyway, I might as well just deal with that up- front, rather than after-the-fact.

I'd love to hear a contrasting opinion (I got pretty good at it, but only over months, not years, of use). But I suspect this is the reason why Prolog didn't make it. It looks good at the start, but it doesn't deliver.

<comment><USER3> In my opinion, Prolog is a horrible programming language. BUT... The idea of logical programming has much promise. Not for programming, but for running queries on a knowledge base. In fact, unification / lambda calculus is arguably the only way you can make complex logical deductions without a brute force approach (you could also use machine learning, but that would not scale for queries with many variables).

The only problem is, the domain in which this is useful is fairly small, and requires an explicitly defined knowledge base, whereas things like machine learning are very flexible and cover a broad variety of domains pretty well. One area I think it holds promise for is in games - imagine characters being able to make deductions about the world around them, and react appropriately - beyond things like behavior trees (which also do not scale once you have many complex rules interacting).

So...in my opinion it is a little bit like SQL. You would not use SQL to write an application (I hope!).

<comment><USER4> _The idea of logical programming has much promise. Not for programming, but for running queries on a knowledge base._

You might want to take a look at Datalog [0]:

 _Datalog is a declarative logic programming language that syntactically is a subset of Prolog. It is often used as a query language for deductive databases. In recent years, Datalog has found new application in data integration, information extraction, networking, program analysis, security, and cloud computing._

An example of this in real-world use would be in Rich Hickey's Datomic [1]:

 _Datomic is a distributed database and implementation of Datalog on Clojure. It has ACID transactions, joins, a logical query language—Datalog._

[0] [https://en.wikipedia.org/wiki/Datalog](https://en.wikipedia.org/wiki/Datalog) [1] [https://en.wikipedia.org/wiki/Datomic](https://en.wikipedia.org/wiki/Datomic)

<comment><USER5> I've tried to get started with datablog a few times, but haven't yet been able to find a useful, Free/open software system that seems practical _and_ has a good practical/hands-on tutorial?

I'm thinking there ought to be something with usefulness comparable to sqlite or at the very least Berkley DB? But I've yet to find it.

</comment></comment></comment></comment><comment><USER6> At last, I have something to add to a HN thread.

I used prolog professionally quite a bit back in the early 2000s. IBM had a product, Tivoli Enterprise Console, that was used to filter, aggregate, and correlate events from their monitoring toolset at the time. All of the rules for event routing and filtering were written in an extended version of prolog.

The system was quite powerful at the time, and I found rule writing to be really intuitive once I wrapped my head around the concepts.

IBM eventually sunsetted TEC in favor of a similar product they acquired when they bought Netcool, but I'll bet there are still a few organizations out there still using it.

<comment> david-given I had a Prolog course at university; it was interesting, but... very weird. (There's a joke that writing a compiler in Prolog is trivially easy; but writing a compiler in Prolog that does anything other than say 'No.' when given an invalid program is infeasibly hard.)

I generally found that while getting Prolog to do cool things was fairly straightforward, getting Prolog to do cool things _quickly_ involved knowing precisely where to put cut operators, and that was basically black magic. But it's been a while.

BTW, our Prolog lecturer wrote a theorem prover in it. That's pretty straightforward; we all wrote theorem provers in it as an exercise; but _his_ theorem prover had a polished MacOS GUI, and _that_ was also written in Prolog. He was writing low-level MacOS stuff in raw Prolog. To this day I still have no idea how.

<comment><USER7> > There's a joke that writing a compiler in Prolog is trivially easy; but > writing a compiler in Prolog that does anything other than say 'No.' when > given an invalid program is infeasibly hard.

I realize you said this was a joke, but still... A compiler in Prolog might look like this:

      compile(Input, Output) :-
          parse(Input, AST),
          process(AST, Output).

and this does, indeed, just answer "no" or "false" when it fails. But you can improve it by just doing something like this:

      compile(Input, Output) :-
          (   parse(Input, AST)          % if parsing succeeds...
          ->  process(AST, Output)       % ... then process the AST...
          ;   writeln('syntax error')    % ... otherwise report an error
          ).

Or you can just use exceptions, which also exist in Prolog. Of course you'd need to collect data (line, column, expected next construct) during parsing in order to make the error message nicer.

> I generally found that while getting Prolog to do cool things was fairly > straightforward, getting Prolog to do cool things quickly involved knowing > precisely where to put cut operators, and that was basically black magic.

The cut is indeed complex, and for historical reasons it's taught too early and emphasized too much by almost all Prolog classes and books. For example, most resources would tell you to write the example above as:

      compile(Input, Output) :-
          parse(Input, AST),
          !,    % commit to this choice if parsing succeeded
          process(AST, Output).
      compile(_Input, _Output) :-
          % we get here by funky implicit control flow if parsing failed
          writeln('syntax error').

It's not that hard to understand the cut once you have a good understanding of normal Prolog execution, but yes, that has to come first. And once you understand how it works, you can often find better solutions that do not use the cut.

As for writing "low-level" code like GUIs, you just use your Prolog system's foreign function interface....

<comment> david-given As I say, it's been years. I don't recall -> and ; at all. (Was there ever a time when they weren't in the language?) They look much nicer than cut and the implicit control flow.

I am, actually, right now struggling with priority-and-constraint-based register allocation and instruction selection for a compiler backend. It is _so_ the right kind of problem for Prolog.

<comment><USER8> There's nothing funny about ';': it's just 'or'. Combined with '->', which means 'then', it essentially comes to behave like an 'else'.

';' has been in the language since the beginning, and I'm pretty sure '->' was too, but can't say for sure.

<comment><USER7> I think -> is newer, but it's in ISO Prolog, which came out in 1995. So it's rather likely that the OP learned Prolog at a time when -> existed but teaching resources had not caught up. Not sure if that's the case even now.

<comment><USER8> I learned Prolog back in 1997, so it may have existed in the implementations I used back then. Must see if I can find an implementation of HU Prolog from back then. I also used SWI Prolog from back then, and I'd expect that was more up to date.

Edit: mention SWI Prolog.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I've seen multiple examples of prolog over the years. From looking at them, one gets the idea that you must hardcode all your data into your program and the only UI is a somewhat odd shell, with no way to actually send input in or get output out. It gives the impression of a neat idea that is a cool academic toy but not a practical language for real-world use. I think that it would be helpful if more prolog intros had a simple example that read a CSV file or JSON object or something, processed it using the defined rules, and output the results to text or HTML file. That's a minor thing, but I think that it would give a better impression and get more people interested and trying it.

Of course intros to other languages may gloss over I/O as well, but with mainstream imperative languages (that aren't oriented to defining and querying data), it's more well known or assumed that the standard I/O patterns apply.

<comment><USER10> >> I think that it would be helpful if more prolog intros had a simple example that read a CSV file or JSON object or something, processed it using the defined rules, and output the results to text or HTML file.

You're right about that and I don't think it's a minor thing. One reason is that most tutorials have a hard enough time going through everything you need to know before you can start parsing json and writing out to file, without getting stuck in infinite recursion etc. so the nitty-gritty of day-to-day programming work is often left as an exercise for the reader.

On the other hand, I have the feeling that many people check out Prolog to see how it's different then go looking for the way to do the usual things in it. This may be the wrong approach. Prolog has some advanced features and those are "the whole point" about the language. If all you'll ever need to do is process some csv, there's probably no point in going through all the hard work to learn Prolog- you can do it in another language rather more easily.

That said, the Swi-Prolog homepage has a link to a good tutorial on creating web applications with it that I recommend to anyone interested in that sort of thing:

[http://www.swi-prolog.org/](http://www.swi-prolog.org/)

It's under the "Tutorials" header. Unfortunately my phone's ISP is blocking it so I can't link directly to it. Harumph.

<comment><USER11> Here's the link ("Prolog Web Applications"):

[https://www.metalevel.at/prolog/web.html](https://www.metalevel.at/prolog/web.html)

<comment><USER7> That's just a short collection of resources, not a tutorial. The actual tutorial linked from [http://www.swi-prolog.org/](http://www.swi-prolog.org/) -> _Tutorials_ -> _Web applications_ is [http://www.pathwayslms.com/swipltuts/html/index.html](http://www.pathwayslms.com/swipltuts/html/index.html)

<comment><USER11> This appears to be limited to explaining the server side, which is only a tiny fraction of actual web applications. In practice, the client side is often equally important, or even more so than the server side.

</comment></comment></comment></comment></comment><comment><USER12> I'll add my default recommendation that I provide in every intro to Prolog thread: The best book to learn is "Prolog Programming for Artificial Intelligence". The intro part is great and the AI parts are also excellent. I think "Art of Prolog" and "Craft of Prolog" should be next in that order.

I fully support the choice of SWI-Prolog by the author of the post. SWI also has good interfaces to other programming languages, I've only used the Java- bridge though but I think Prolog mostly shines if you mix it with another language. I tihnk a good next step would be researching definite clause grammars and constraint programming as those are the (imo) best use cases for Prolog. If you're mostly interested in constraint solvers I recommend eclipse (not the IDE, very unfortunate naming): [http://www.eclipseclp.org/](http://www.eclipseclp.org/)

I think Prolog is a great language to train your brain if that makes any sense. It's quite nice to write a Soduku solver and the like in it even though you can get better performance in other languages. Whenever I write Prolog it takes a bit for my brain to readjust which I feel is a pretty good sign as it means you're working in a different paradigm.

<comment><USER10> For those interested in AI I would add "AI algorithms, Data structres, and idioms in Prolog, Lisp and Java":

[http://wps.aw.com/wps/media/objects/5771/5909832/PDF/Luger_0...](http://wps.aw.com/wps/media/objects/5771/5909832/PDF/Luger_0136070477_1.pdf)

In fact I'd recommend that to anyone, regardless of interest in AI- it's a great programming textbook all around and accessible to anyone who knows at least one of the three languages (coughjavacough).

</comment></comment><comment><USER13> A little known fact is that Microsoft actually used an embedded Prolog interpreter for network configuration in Windows NT:

[http://web.archive.org/web/20040603192757/research.microsoft...](http://web.archive.org/web/20040603192757/research.microsoft.com/research/dtg/davidhov/pap.htm)

<comment><USER14> And its first version was developed on a Macintosh, too! Thanks for the link. Been some good history lessons on Microsoft recently that keep tripping me out.

</comment></comment><comment><USER3> Personally, Prolog was the biggest "woah" moment for me in learning programming languages.

If anybody wants a challenging and enlightening programming exercise, I recommend writing your own prolog[esque] interpreter.

Surprisingly it still has not been used much in games (well, actually not that surprising given how time consuming and risky it is). I made a stab at [1] but ended up taking more time than I had budget for. One thing I suspect may be using it is the game 1935 [2], although they are vague on the details.

[1] [https://www.youtube.com/watch?v=2EHKDP2_ky0](https://www.youtube.com/watch?v=2EHKDP2_ky0) [2] [https://mollyrocket.com/news_0023.html](https://mollyrocket.com/news_0023.html)

</comment><comment><USER15> I learned Prolog in some university courses but I'm gutted that I haven't had a single chance to use it in my professional life. I've given some thought to what kind of projects would it be suitable for.

The other day I was playing Sid Meier's Civilization and realized that the rule engine for games like that would be a very good fit for a Prolog-like logic programming language (using an embedded interpreter). Prolog would allow adding new rules without touching the old ones, e.g. add a new rule for, say, defensive bonus would be just a single new line in the code base.

<comment><USER16> Prolog is very useful for decision and optimization problems. There are a ton of those available in the world. For example a lot of scheduling problems are relatively tractable with logic programming and a total bear in imperative/oo

<comment><USER17> On the other hand, I have first had experience of two companies who used C to solve these problems due to performance and maintenance of the logic. One in classroom scheduling, the other in hospital staff scheduling. Both of these are some of the examples most cited as useful. I still have The Art of Promoting on the shelf next to me. Fun but useless.

</comment></comment></comment><comment><USER18> Unification + backtracking is really, really, really really cute. Makes you think very abstractly, so much that it made me feel that haskell was verbose (not trying to be hyperbolic here).

A nice book I've read recently is Ivan Bratko's [https://ailab.si/ivan/novice.php](https://ailab.si/ivan/novice.php)

Try to grab a 2nd hand one or a library with it on shelves (probably stacking dust). The basics are covered, then graph search, state space, tricks like diff-list (pretty unforeseen use of prolog semantics tbh), a bit of nlp.

Very* cool

<comment><USER19> And the scary thing is that one can do even better: [https://billwadge.wordpress.com/2016/01/18/extensional- highe...](https://billwadge.wordpress.com/2016/01/18/extensional-higher-order- prolog/) [https://github.com/acharal/hopes](https://github.com/acharal/hopes)

<comment><USER14> Neat tools. Have you seen any attempts to model HOL in FOL for verification in FOL? There's a FOL down to assembly verified prover and stack. It's ACL2-like. I also found a paper doing HOL-to-FOL conversion with that tool modeled and proven in HOL. Doing HOL in FOL or HOL-to-FOL converter in FOL seems like a short-cut to verified, proof stack.

If the shortcut is doable at all. The HOL-to-FOL gave me some excitement about this. It just wasn't done entirely in FOL itself.

<comment><USER19> Haven't seen it, but I'll check it out. Thanks for the pointer.

<comment><USER14> Forgot to add the link so you can see what such a process might look like. Here's slides and a paper on one that merged HOL and ACL2. But it verified that in HOL4, not ACL2.

[https://www.cs.utexas.edu/~hunt/FMCAD/FMCAD06/presentations/...](https://www.cs.utexas.edu/~hunt/FMCAD/FMCAD06/presentations/FMCAD-2006-Wednesday/Session2-Hunt.pdf)

[http://www.ccs.neu.edu/home/pete/acl206/papers/gordon.pdf](http://www.ccs.neu.edu/home/pete/acl206/papers/gordon.pdf)

</comment></comment></comment></comment></comment><comment><USER20> I am always puzzled why Curry which is Haskell + Prolog in one unified packet has never taken off. Combining the advantages of functional and logic programming paradigms seems to have so many interesting applications.

Admittedly, Curry is an academic language, not 100% production ready.

[http://curry-language.org/](http://curry-language.org/)

<comment><USER21> Mercury is another programming language that combines Prolog plus functional programming that probably doesn't get as much attention as it deserves [https://mercurylang.org/](https://mercurylang.org/)

<comment><USER22> With a build system like that, it gets exactly as much attention as it deserves... D:

Do a ./configure --help, and try to figure out what the best "grade"(s) to build is/are.

I've been meaning to try Mercury for years, but after this, there's no chance I'm going to try writing anything in it. What other crufty unusable insanity have they built in there?

<comment><USER21> It is a bit obscure. I let it build the ones it wants to build by default. This gives me the flexibility of deciding later when building Mercury programs what I want as a backend.

This blog post describes some of them: [https://adventuresinmercury.blogspot.co.nz/2011/11/making- gr...](https://adventuresinmercury.blogspot.co.nz/2011/11/making-grade.html)

</comment></comment></comment></comment><comment><USER23> I feel like people are somewhat aware of prolog but it's cousin datalog that's a db query language is much less widely known. I don't have too much experience with it but it seems like one of the technologies of the past that's superior to current alternatives but for some reason didn't take off.

<comment><USER24> The ideas of datalog are making a slow comeback. For example, datalog is a query language for Datomic DB.

<comment><USER25> Datalog is also quite actively used in ontology based data access where Datalog rules are used as mappings between databases and ontologies (see e.g. [1]). Variants and extensions of Datalog is also research actively in the field of answer set programming[2], with many usable implementations.

[1] - [http://ontop.inf.unibz.it/](http://ontop.inf.unibz.it/) [2] - [https://en.m.wikipedia.org/wiki/Answer_set_programming](https://en.m.wikipedia.org/wiki/Answer_set_programming)

</comment></comment></comment><comment><USER26> Is Prolog good for assignment problems (assigning guests to rooms or people to beds) when there are soft constraints?

I asked twice on StackOverflow [0][1] and had the question declined each time.

[0]: [http://stackoverflow.com/questions/36148764/weak-rules-in- pr...](http://stackoverflow.com/questions/36148764/weak-rules-in-prolog) [1]: [http://stackoverflow.com/questions/37610341/assigning- people...](http://stackoverflow.com/questions/37610341/assigning-people-to- beds-approaches-to-automate)

<comment><USER27> Prolog normally finds a solution, and if you decline it, a new solution, and so on until it can't find any more solutions. If you pay careful attention to your program, you can make it so that it finds ones that satisfy soft constraints first, and then solutions that don't satisfy them.

This is what the replies in [0] suggested. Prolog isn't exactly intended for preferring some solutions over others, but it has predictable solution generation that can be used to prescribe priority.

That's a lot of mental work, but the code is succinct. If you want to get by without flow diagrams, your best bet is to generate and optimize a cost function, and that can be done in any language.

</comment></comment><comment><USER28> I'm always happy to see Prolog get some love. Learning it in a university course really expanded my mind, similar to when I first tried FP with ML in another course.

I went to a talk about MicroKanran, another logic programming language, which is embeddable in host languages. I think it shows a lot of promise for implementing decision engines. The biggest downside is that it can be tough to reason about the runtime characteristics of nontrivial programs, right about at the point where the paradigm starts to be really useful for modeling complex problems. It takes some experience to know how to write it efficiently.

</comment><comment><USER29> Prolog looks really useful for solving real world problems. Why doesn't it get used more?

And can you interface to it using Python or some more mainstream languages?

<comment><USER21> It's popular to embed a prolog in Lisp languages. For example Picolisp and Shen. I wrote a post comparing Shen's Prolog support to SWI Prolog recently: [https://bluishcoder.co.nz/2016/08/30/kicking-the-tires-of- sh...](https://bluishcoder.co.nz/2016/08/30/kicking-the-tires-of-shen- prolog.html)

<comment><USER30> Is the license for Shen still that you own a copy of Tarver's book?

<comment><USER21> There's a BSD licensed open source version, all linked from [http://shenlanguage.org/download_form.html](http://shenlanguage.org/download_form.html)

That's what I used for my post. There's "Shen Professional" which is a closed source subscription based product getting rapid development [http://shenlanguage.org/professional.html](http://shenlanguage.org/professional.html)

I have not used "Shen Professional" though.

<comment><USER30> That's good news...curious if he has any customers for the professional version. I'm sure it's a great product, I'm just not aware of too many people who would depend on something that niche' for production work. Maybe niche production work :)

</comment></comment></comment></comment></comment><comment><USER31> How many prolog programmers does it take to change a lightbulb?

No.

<comment><USER32> How many Lisp programmers does it take to change a lightbulb?

Ans. 1. (1)

Ans 2. I'll tell you after I've debugged and can run a macro I'm writing for this.

Ans 3. nil

</comment></comment><comment><USER33> Prolog is only appropriate for certain kinds of programs, long time ago I programmed in prolog and it was a very difficult task when the problem was not about matching and unification.

For me Lisp was much more appropiate and easy to program. Forward chaining and unification is not enough for certain class of algorithms, sometime you need backward chaining, probabilistic inference and many other ideas that are not easily translated in prolog. I remember some discussion about the semantic of clauses. For example misil(ready), is this about the misil is already ready, or that you are going to prepare the misil, etc. I find that concurrency and paralelism in prolog are not easy. In the book "on Lisp" by P. Grahan there is a prolog interpreter in Lisp, this can be interesting for somebody wishing to learn prolog.

Edit,Added, erlang was inspired by prolog, so learning prolog will help you learn erlang, but if you are a ruby type elixir is your best option.

</comment><comment><USER21> A system written using SWI Prolog is apparently used in a large number of NZ stock exchange trades [https://dtai.cs.kuleuven.be/CHR/files/Elston_SecuritEase.pdf](https://dtai.cs.kuleuven.be/CHR/files/Elston_SecuritEase.pdf)

</comment><comment><USER34> If you're interested in logic programming, Mozart/oz offers a better deal than raw prolog for practical problems. The reason is that you can express various search strategies using the concept of "computation spaces" in Mozart.

</comment><comment><USER35> Instead of learning one language every year, learn new programming paradigms. The logic programming paradigm is not implemented by many languages, so, might be interesting to learn.

</comment><comment><USER36> This helped explain a lot about how and why Prolog works. The coolest thing? That's only a tiny percent of the language, but it's already enough to start solving problems.

For those of you looking for prolog out in the real world, a surprising number of languages contain embedded interpreters for it. Mostly Lisps.

Perhaps most famously, picolisp uses a tiny, lisp-syntax prolog called pilog as a query languages for its built in database. Yes, it has a built in database. Picolisp is weird.

<comment><USER4> _a surprising number of languages contain embedded interpreters for it. Mostly Lisps._

Also, Smalltalks (seriously).

<comment><USER37> Yes, my first exposure to Prolog was the toy version included with Smalltalk/V in the late 1980s.

</comment></comment></comment><comment><USER10> I've been using Prolog since 2008 ish, on and off, with more time spent using it in the last couple of years. I've written my degree and Masters dissertations in Prolog, using different Prologs for each. I code all my personnal stuff in Prolog.

If I could condense the experience of those last few years with Prolog in one sentence it would be this one: "Prolog is not your friend".

It's not an "easy" language to learn- it's not javascript but with first-order abstractions, it's not Java with a different VM. You need to grok a fair few things about both the theory behind it -in other words, first-order logic- and the implementation decisions taken to make it efficient. For instance- clause selection order or, yep, the cut. You need to understand how this works and, ahem, cut yourself too many times until you get the message. Well, I had to, anyway.

There's a bunch of stuff you (or at least, I) never have to think about in day-to-day programming work, such as depth-first search and how it can go infinite. Then you need to get some experience with your chosen Prolog interpreter and learn its idiosyncracies [1].

There are rewards. [plug] My Masters dissertation [2] is a novel algorithm that learns a grammar from unannotated text. Because it produces a grammar in Prolog's Definite Clause Grammars notation, and because Prolog can interpret DCGs as first-order logic theories, these grammars are also logic programs that model the algorithm's input. I process some text, spit out a grammar and then _without needing a separate compiler_ I run this grammar backwards to generate new strings, or the normal way to parse them. [/plug]

There's a point in the Prolog learning curve where you risk baldness from pulling out your own hair. Once past that point... it keeps hurting you, but the things you can do with it, it's bit like magic. Or maybe it's Stockholm syndrome :)

I've seen many criticisms of Prolog (some that are repeated in this thread). Eight years in I haven't seen one single line of criticism that still makes sense after you've used the language for a few years.

So to me the real problem with Prolog is that it hurts you so much that most people give up before they really figure it out.

Oh and- should you pick Prolog up never forget this: The dynamic database is _evil_.

[1] [http://www.swi-prolog.org/pldoc/man?section=jitindex](http://www.swi- prolog.org/pldoc/man?section=jitindex)

Just a few days ago I was working on something I thought was best tackled using dynamic predicates (written to the database) rather than an in-memory list. My program took _hours_ to process some data, until I noticed I was querying a compound term for its _second_ argument. Just switching arguments brought the processing time down to five minutes on the same data. Did I mention the dynamic db is evil?

[2] [https://github.com/stassa/THELEMA](https://github.com/stassa/THELEMA)

</comment><comment><USER38> Prolog was part of a course I took at RIT back in the late 90s.

I ended up using it a few times since then in a professional setting to handle filling out extremely complex forms.

I even build a module on CPAN to handle creating Prolog facts from Perl data structures.

</comment><comment><USER39> I remember Borland Turbo Prolog. But it was so long ago that I lost the disk it was on.

<comment><USER40> Its descendant, "Visual Prolog"[0], appears to have a free edition for personal use[1].

[0] [https://en.wikipedia.org/wiki/Visual_Prolog](https://en.wikipedia.org/wiki/Visual_Prolog) " _Visual Prolog, also formerly known as PDC Prolog and Turbo Prolog, is a strongly typed object-oriented extension of Prolog. As Turbo Prolog it was marketed by Borland, but it is now developed and marketed by the Danish firm Prolog Development Center (PDC) that originally developed it._ "

[1] [http://www.visual-prolog.com/vip/download/default.htm](http://www.visual- prolog.com/vip/download/default.htm)

</comment></comment><comment><USER41> A good post but (2013)</comment>


New machine could one day replace anesthesiologists - <AUTHOR> http://www.washingtonpost.com/business/economy/new-machine-could-one-day-replace-anesthesiologists/2015/05/11/92e8a42c-f424-11e4-b2f3-af5479e6bbdd_story.html?tid=HP_more?tid=HP_more <comment><USER2> Non-anesthesiologist ICU physician here so slight bias should be noted.

I'm a huge fan of this. Machine will be much more anal about minor issues that some anesthesiologists / CRNAs may ignore. Additionally, this will greatly bring down costs for healthy routine procedures that need sedation. Machines don't "get bored" and if things fall out of parameters they happily yell to get attention. Properly coded they should also not make medication errors. Additionally, they should be able to record data and find patterns in patients that unexpectedly don't do well.

Michael Jackson would probably still be alive if a machine had been used to help monitor his propofol!

Dialysis, for example, used to be a much more manual process. Now, it is mostly driven by nurses and machines. Heck, people even do self-directed dialysis at home.

This isn't the end of anesthesiology by any means. The more difficult patients such as those who are obese or have a bunch of health problems will still need more aggressive observations. However, I suspect these machines will move into bigger and bigger surgeries to help assist the gas-passers provide safer analgesia and sedation.

Just like robotic assisted surgery became too popular too fast and outcomes suffered, I suspect these type of machines will not be trouble-free. How long before the HN articles about one of these being hacked start appearing? Nevertheless, medical machines like this with tight feedback loops are essential for improving the safety and efficiency in the future practice of medicine.

</comment><comment><USER3> From the name, I used to think that anesthesiologists just "put people to sleep" or stopped patient's pain.

My view is now different. Their job (for what I'm told) is also to keep people alive and stable. They administer drugs and employ machines and techniques to control body temperature, blood pressure, oxygen levels, heart rate and others. Sometimes it's a simple colonoscopy (like in the article), but other times they are treating people who just had a stroke or a bad accident. They have to react in seconds to the response they SEE on the patient (data coming from machines, but also body movement, change in skin color, eye movement, bleeding, and many subtle changes), connecting knowledge and years of experience. It's also an art to be able to put tubes and needles on all kinds of "strangely" shaped bodies (specially in old people).

A more precise title would be "new machine could one day replace some anesthesiologists". I think it's going to take a while before we can trust machines to keep us alive during emergencies and operations.

<comment><USER4> My sister is an anesthesiologists. She sometimes anesthetize heart or brain surgery patients without putting them to sleep, because they're too old or unhealthy but need the surgery asap. These people normally cannot come back to life from anesthesia, which is just making someone dead by stopping heartbeat and respiratory functions with anesthetic agents and then animating them with machines. So the creepy state of having your heart worked out while you're awake. I believe this is something that can be fully automated by a machine in the future.

But she also holds the hand of a child to calm her while preparing her to a scary surgery, or talks to relatives waiting outside of intensive care, sometimes tells people that they lost their loved one, or a miracle just happened and they're good.

<comment><USER5> >These people normally cannot come back to life from anesthesia, which is just making someone dead by stopping heartbeat and respiratory functions with anesthetic agents and then animating them with machines.

Hearts do not stop beating during ordinary general anaesthesia.

<comment><USER4> You're right. My bad.

</comment></comment></comment></comment><comment><USER3> "But now, after the procedure, she said she saw a potential upside, too: There was no human error, either."

I knew it. Programmers are not human.

<comment><USER6> I'm saddened by the glorified view on non human systems. When they'll reach a large scale enough, there will be too-complex conditions, confusion and bad (contextually optimal) decisions and ordering, just like what happen to humans.

<comment><USER7> Code can reach close enough to perfection for errors to pretty much not happen with a process like that NASA coding team

</comment></comment></comment><comment><USER8> The technology that goes into a self driving car is possibly far more sophisticated than this new machine. Anesthesiologists must have lobbied hard to stop this machine from a more wide spread usage. However the writing on the wall is clear. Machines in many cases are better than Doctors and they will continue to become better more rapidly than say Doctors with their experience. I wish US FDA gives a chance to these innovations and slowly tackle the rising healthcare costs.

<comment><USER9> Yes, some standard procedures on ASA1 patiens do not require a lot of sophistication. However do not underestimate how hard anesthesiology is, while 90% routine, 10% is incredibly complex stressfull scenarios in trauma/emergency, surgical complications, adverse events. Its much more than just heart rate, RR, oxymetry etc. Its knowledge about medicine interactions, organ systems, physiological systems and the skill to perform under immense pressure (trying to provide a permanent airway through facial trauma or large bore IV access for fluid replacements on a patient in volumetric shock) And while uncommon it can happen during standard procedures in ASA1 patients. I'd rather have the anesthesiologist close please.

As a quick sedation system these sound wonderfull though, for example for resetting joint dislocations in the OR where all emergency staff and equipment is already in place.

<comment><USER10> ASA1 == American Society of Anesthesiologists physical status classification system "Healthy person", e.g. [https://en.wikipedia.org/wiki/ASA_physical_status_classifica...](https://en.wikipedia.org/wiki/ASA_physical_status_classification_system)

With an increasingly graying population in the US, rdudekul's hopes ... well, I suppose if you can decrease e.g. the ASA 1 need for anesthesiologists while they're still on tap if things go south, it'll overall help. But it's probably not going to get big, and will create triage like situations where people will needlessly die when there's no anesthesiologist to spare.

</comment></comment></comment><comment><USER11> As someone who has "been under" a few times, I am torn on this. I like the idea of less errors due to a computer, but there is something comforting about knowing that a human expert is "at the wheel".

I know it is irrational, but I feel similar about airplanes and cars -- much more comfortable when you know there is a human at the helm.

Maybe it is the mortal peril part of the equation.

<comment><USER12> I could foresee a setup like airline pilots - the autopilot truly does most of the work, but humans monitor and are available in case of emergencies.

</comment></comment><comment><USER13> If the machine could detect the awareness well enough then it could reduce the terrifying "accidental awareness" during surgery:

[http://www.iflscience.com/health-and-medicine/large-study- ex...](http://www.iflscience.com/health-and-medicine/large-study-explores-how- often-patients-wake-during-surgery)

[http://www.dailymail.co.uk/news/article-2750201/Three- patien...](http://www.dailymail.co.uk/news/article-2750201/Three-patients- week-report-waking-operation-Accidental-awareness-occurs-not-given- anaesthetic.html)

</comment><comment><USER14> so does the machine also open the patients airway and safely insert the breathing tube ?

<comment><USER15> Or answer codes, sign out medication, or take the patient their consent forms? It's cool, but no replacement for a person.

<comment><USER16> The article is telling specifically that the machine is already replacing a person in some circumstances.

The kind of circumstances that it can manage are not going to shrink.</comment></comment></comment>


Tail Recursion Tactics: Fibonacci - <AUTHOR> https://blog.des.io/posts/2018-03-08-fibonacci.html <comment><USER2> Silly question: Both this post and the earlier one linked from it show that a manually written loop easily beats the tail-recursive version. That is, Go doesn't seem to do tail recursion optimization. In which case, why bother with all of this?

<comment> phoe-krk All of these versions are correct in theory, and the Go example in here is because Go is easily readable as a lingua franca. This whole post can be easily translated to other languages, including ones that do tail call optimization.

Also note that, despite Go having no TCO, the author has nonetheless managed to get a huge improvement over the naïve case by using proper tail recursion.

</comment></comment><comment><USER3> I love your explanation of how to arrive at the vector transformation function. You might enjoy reading an article I wrote a few years ago that touches on maxtrix/vector computation of linear recurrences: [http://aperiodical.com/2014/06/discovering-integer- sequences...](http://aperiodical.com/2014/06/discovering-integer-sequences-by- dealing-cards/)

Not as detailed as your post though. Thanks for a great write up!

<comment><AUTHOR> Thanks for the feedback and sharing your article. I also find the matrix solution so satisfying especially when the eignenvalues come out as the golden ratio. I would really like to do a write-up on the intuition behind this and what it means to approach a linear recurrence as a vector space, solving with a matrix and the characteristic equation.

</comment></comment><comment><USER4> If you're computing Fibonacci numbers using only addition, no matter how clever your recursion, you will always lose out to algorithms that use multiplication. [https://www.nayuki.io/page/fast-fibonacci- algorithms](https://www.nayuki.io/page/fast-fibonacci-algorithms)

<comment><USER5> Exactly. And fibonacci numbers also have a closed form which can be (in theory) evaluated in O(1):

[http://austinrochford.com/posts/2013-11-01-generating- functi...](http://austinrochford.com/posts/2013-11-01-generating-functions- and-fibonacci-numbers.html)

<comment><USER4> The number of digits in the nth Fibonacci number grows linearly with n, so you can't compute these digits in O(1). The fastest algorithms, described in the link I gave, have complexity O(n * something) where "something" grows much slower than n and depends on the bigint multiplication algorithm used.

<comment><USER5> The matrix exponentiation algorithm in the link you sent is O(log(n)). Yes, this might seem strange because the output (F_n) itself has n bits. But in practice most of the implementations would use long integers for output, so log(F_n) < 64 for these implementations.

<comment><USER4> The article I linked has code examples in four languages, all use bigints, not longs.

</comment></comment></comment></comment></comment><comment><USER6> Tail call optimization is a clever, but even in functional languages, twisting your code around to use tail calls is often a code smell. Most uses of tail recursion would be better-served by using some higher-order functions. The reason is that when you write something tail recursively, it's sort of like rolling your own iteration.

This is particularly true because many platforms don't supply tail call optimization, but do supply higher-order function.

For example, Python 3:

        import functools
        import itertools

        def fib(n):
            def get_next(i):
                a, b = i
                return (b, a + b)

            a, b = functools.reduce(
                get_next,
                itertools.repeat(None, n),
                (0, 1),
            )

            return b

This does come out a bit hacky in Python, because Python doesn't have a builtin higher-order function that does something like this:

        def generate(get_next, c):
            while True:
                yield c
                c = get_next(c)

But many (most?) functional languages have such a function. With that function built in, the code would look something like:

        import itertools

        def fib(n):
            def get_next(i):
                a, b = i
                return (b, a + b)

            a, b = next(itertools.islice(
                generate(get_next, (0, 1)),
                n,
            ))

            return b

Further, most functional languages have a builtin function that gets the nth item in the sequence, which is what `next` and `itertools.islice` are doing above:

        def nth(seq, n):
            return next(itertools.islice(seq, n))

If that were built in also, we get:

        def fib(n):
            def get_next(i):
                a, b = i
                return (b, a + b)

            a, b = nth(generate(get_next, (0, 1)), n)

            return b

This gives us some pretty terse code built only of composable builtin pieces, and ostensibly these higher-order functions are written in a lower-level language and highly optimized. This is cleaner than rolling your own tail recursion in a lot of ways.

<comment><USER7> Poked around on the google[0]:

      def fib(n):
        a, b = 0, 1
        for _ in range(n):
            a, b = b, a + b
        return b

No itertools, not overly complex, no tail recursion.

If you were careful of the scoping rules something like foo(get_next(i) for i in whatever()) could be made to work without too much trouble (also without itertools) if you needed a sequence. Probably just throw a lambda in there instead of get_next and python would be happy, too lazy to work it out.

[0][http://www.koderdojo.com/blog/python-fibonacci-number- genera...](http://www.koderdojo.com/blog/python-fibonacci-number-generator)

\--edit--

Actually, I think this function gives the wrong result for 0 and maybe 1, just copypasta'd the code so blame them...

<comment><USER6> I think this is the correct way to do this in a Python codebase where procedural programming is the dominant paradigm, but that's not really what my previous post is about.

EDIT: Also c'mon man. This is not a problem that you need to Google. :P

</comment></comment></comment><comment><USER8> Interesting article with great formatting, I hope there will be more! Blogs like this and YouTube channels like 3Blue1Brown make maths more tangible.

<comment><AUTHOR> Thank you for the feedback, I'm glad you found it interesting!

</comment></comment><comment><USER9> [https://wiki.haskell.org/The_Fibonacci_sequence](https://wiki.haskell.org/The_Fibonacci_sequence)

<comment><USER10> The canonical zipWith solution is a thing of beauty.

<comment><USER11> I agree. The scanl version is even more elegant:

      fibs = 0 : scanl (+) 1 fibs

Replacing 0 with 2 yields the Lucas numbers:

      lucas = 2 : scanl (+) 1 lucas

</comment></comment></comment><comment><USER12> Unfortunate, that your results for `n = 90` are completely useless, since F_90 > 2^32 which is the size of int.

Also, you could have shown a method which is O(log n), namely [[F(n+1) F(n)], [F(n) F(n-1)]] equals [[1, 1] [1, 0]] raised to the power of n.

<comment><AUTHOR> Actually F_90 < 2^64. Golang ints are minimum 32bits and can be 64bits so my results were not completely useless at all ;)

Indeed you can compute Fibonacci numbers (and other linear recurrences) with matrix exponentiation, or with a closed-form equation like the Binet Formula - but I limited the scope of this article to tail recursion.

Binet Formula: [http://mathworld.wolfram.com/BinetsFibonacciNumberFormula.ht...](http://mathworld.wolfram.com/BinetsFibonacciNumberFormula.html)

<comment><USER13> You can implement matrix exponentiation recursively however.

<comment><USER14> > You can implement matrix exponentiation recursively however.

And tail recursively, and – going full circle – you can convert that tail recursion into iteration (see [1] for example, using techniques described in [2]).

[1] Iterative fast-power implementation in Python [https://github.com/tmoertel/practice/blob/master/libraries/t...](https://github.com/tmoertel/practice/blob/master/libraries/tomlib.py#L143)

[2] Recursion to Iteration, Part 1: The Simple Method, secret features, and accumulators [http://blog.moertel.com/posts/2013-05-11-recursive-to- iterat...](http://blog.moertel.com/posts/2013-05-11-recursive-to- iterative.html)

</comment></comment></comment></comment><comment><USER15> Great post, please add RSS for at least one subscriber!

<comment><AUTHOR> I'm flattered! I added an rss feed for you: [https://blog.des.io/rss.xml](https://blog.des.io/rss.xml)

<comment><USER16> Many thanks, and very very nice article. I used to spend time reading about linear recurrences and all things fibonacci. I stopped but this reminds me I should go back into it.

</comment></comment></comment><comment><USER17> Would be neat to see how the vector version works using successive squares.

</comment><comment><USER18> When I see func FibTailVecSum(n int) int { if n < 2 ... and func FibTailVec(acc int, a int, b int) (int, int) { if acc == 1 { I go full Terry Pratchett and began to yell Guards! Guards! I mean, these are perfect examples of Elixir guards. Is there a similar functionality in Go?</comment>


Colorize Old Photos with DeOldify - <AUTHOR> https://www.gradio.app/hub/hub-deoldify <comment><USER2> In 1937, my grandpa went on a cycling trip through Germany, Austria, and Italy, then back to the UK.

My mum made a photo website about it, including links to some hotels that are still operating.

[http://drmarionb.free.fr/1937CyclingTour/](http://drmarionb.free.fr/1937CyclingTour/)

Some of these photos look amazing when colourised using DeOldify, via MyHeritage. I hope that my mum will update the page soon with the colourised versions side by side!

</comment><comment><AUTHOR> Built this interface using the Gradio[1] library. Forked the DeOldify[2] model on github.

[1]: [https://github.com/gradio-app/gradio](https://github.com/gradio- app/gradio) [2]: [https://github.com/jantic/DeOldify](https://github.com/jantic/DeOldify)

<comment><USER3> Any chance of sorting out your landing page?

It's still hanging 12 hours after the original comments here.

</comment></comment><comment><USER4> It seems to have been met with the Hug of Death? (I'm seeing a 504 gateway timeout)

Also, the first link on the DeOldify github page [1], runs much quicker than 30-40 seconds so something seems less than optimal about this implementation.

[1] [https://deepai.org/machine-learning- model/colorizer](https://deepai.org/machine-learning-model/colorizer)

<comment><USER5> I'm getting errors too, it does look like the site is down. Thanks for the deepai.org link.

Running this on photos from yesterday's 1940s.nyc post ([https://news.ycombinator.com/item?id=24152108](https://news.ycombinator.com/item?id=24152108)) is really fun!

</comment></comment><comment><USER6> It's down. Not sure if this is the same, but there's this page to try DeOldify online: [https://www.myheritage.com/incolor](https://www.myheritage.com/incolor)

<comment><USER7> oh that is so mean. They let you upload first, then they ask you to sign up to see it. There goes one more fake email in their database.

<comment><USER6> sorry, fwiw I would not have posted it if they required you to click on a verify link in the email.

</comment></comment></comment><comment><USER8> I clicked the link but keep being met with a blank screen? Maybe it's not optimised for mobile?

<comment><USER9> I'm seeing the same on a 30" desktop screen... It sounds interesting, so I'm bookmarking to look later.

<comment><USER10> Same here, Mojave and Chrome.

</comment></comment></comment><comment><USER11> Can someone merge this with [https://1940s.nyc/](https://1940s.nyc/) :)

</comment><comment><USER12> i love the name "DeOldify"</comment>


Cosmologist claims Universe may not be expanding (2013) - <AUTHOR> https://www.nature.com/news/cosmologist-claims-universe-may-not-be-expanding-1.13379 <comment><USER3> I know Christoff Wetterich! From the time of my Ph.D. when we were working the Renormalization Group. I met him a few times, we were working on similar things but in different groups, we were "competitors" if you wish. Funny to see him cited in HackerNews. He is certainly a respectable physicists, but that can be said for many others. I have not read the cited article, it is in my field, so I could understand it if my memory worked well, but after 20 years from my Ph.D. I am too rusted now.

</comment><comment><USER4> The central concept behind Christof Wetterich's proposal is scale invariance: Imagine you try to measure the size of the universe with a yard stick. If you measure that the universe is expanding, you can't be sure that it really is the universe expanding, or maybe just your yard stick shrinking.

This is true in so-called scale invariant theories. These theories do not contain any intrinsic length scale. The moment your theory contains a fundamental length l you break scale invariance. In this case you are able to compare your yard stick to the length l to find out if your yard stick was shrinking or the universe really is expanding.

Our present model of the world still contains a few fundamental length scales (such as the Planck length, or a length scale associated to the nuclear force), but people such as Christof Wetterich are building models that try to get rid of (some of) these fundamental length scales. A major approach in this direction is asymptotically safe quantum gravity, that also led Christof Wetterich and Mikhail Shaposhnikov to the most precise prediction of the Higgs mass prior to the Higgs' discovery in 2009, see [https://arxiv.org/abs/0912.0208](https://arxiv.org/abs/0912.0208).

<comment><USER5> But the yardstick argument assumes uniform expansion. Small scale structure like our yardstick is held together by electromagnetic forces which counteracts the expansive force. That's my understanding anyway.

If we create a light year long line of yardsticks then we would expect the line to expand faster than the yardsticks that make it up. Locally this would look like growing gaps between the yardsticks. we never used the fact that the line was a light year long. So let's just put two yardsticks next to each other in a vacuum. They drift apart and eventually so far they are not part of each others' observable universes.

<comment><USER6> That's accurate. Metric expansion only dominates loosely bound structures on a scale beyond individual galalxies. The yardstick, solar system, and Milky Way are all on scales too small, and are too strongly bound, for metric expansion to have an impact. Galaxy clusters and the space between galaxies however, are impacted.

</comment></comment></comment><comment><USER7> This is (2013). Christof Wetterich continued research, his current theory is called emergent scale symmetry: [https://arxiv.org/abs/1705.00552](https://arxiv.org/abs/1705.00552). It got peer-reviewed and published at Physical Reviews D, the leading journal on cosmology.

</comment><comment><USER8> Interesting take on things. There's value in thinking about equivalent models that allow potentially entrenched assumptions to be set aside. Worth mentioning that the kilogram has since been defined more robustly than the way mentioned in the article. [https://www.sciencealert.com/it-s-official-the- definition-of...](https://www.sciencealert.com/it-s-official-the-definition- of-a-kilogram-has-changed)

</comment><comment><USER9> > The idea may be plausible, but it comes with a big problem: it can't be > tested.

Doesn't that imply that the accepted model can't be tested? I mean, in the sense of distinguishing it from this one.

<comment><USER10> Not a physicist, but I recall reading that there is enough empirical evidence to support the current model of expanding universe.

<comment><USER11> I always wonder about that. I remember very specifically learning 40(?) years ago that the expansion was slowing, supposedly proven by some sort of red shift in light. That is now out of favor, but a few more new facts just might swing things the other way again.

<comment><USER7> Accelerating universe is supported by supernova data. We have incomparably more supernova data compared to the past. Discovery of accelerating universe was mainly due to radically scaling up supernova discovery process.

<comment><USER12> Yes, but that's still dependent on a differential velocity model for the origin of redshift. This paper changes that core assumption, meaning the same data can be interpreted to have a radically different meaning.

Afaik, we have no direct observations of galaxies moving away from us - <USER2> such enormous distances we have not had enough time since the start of observations to actually see a galaxy recede.

<comment><USER13> No, the origin of the cosmological redshift is not proposed to be due to differences in velocity, but metric expansion.

<comment><USER14> ... which causes a change in relative velocities

<comment><USER13> That makes it sound like cosmological redshift is a form of Doppler shift. In reality, the target object emits light towards us with little Doppler shift as it will have experienced little acceleration in its reference frame. The light becomes redshifted as it moves through the universe while the universe is expanding, effectively stretching out the wavelength of the light.

The change in wavelength is exactly proportional to the increase in size of the universe during the time of flight, and it is not directly related to speed of recession except in common and inaccurate discussion. The link to relative velocity (if that concept makes sense for objects in widely separated and unrelated reference frames) is model dependent, while the metric expansion measurement is directly measured.

<comment><USER14> Ok. I was under the impression that expansion had no effect on local phenomena because local phenomena always counteract expansion. But if you view light more as a wave instead of a particle then could see the argument that the light is locally stretched if there is no force keeping it from being stretched e.g. gravity or energy.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER15> Within galaxies, however, gravity dominates dark energy expansion, right? If so, with enough measurement accuracy shouldn't we be able to look for standard candles within our galaxy that either show or don't show said mass differences while compensating for any shift due to relative motion? I'd think that given enough accuracy we'd have something that's testable eventually.

</comment><comment><USER16> Reminds me of my funny notes in a childhood diary. I had a personal pet theory that Dinosaurs were so huge because they were not as heavy as we assumed them to be. Imagining what it felt like to be a dino was a steady staple for boring afternoons.

<comment><USER17> Maybe they're big because they're a lot closer than we realize.

</comment></comment><comment><USER18> Wouldn't the gravitational pull increase? For example you would see less gravitational lensing in older galaxy clusters.

<comment><USER19> I think it's worse than that: it looks to me like this model will either not predict what it's claimed to predict, or will violate local stress-energy conservation.

Basically, if stress-energy is locally conserved, particle masses can't just increase out of nowhere: the energy that goes into the increasing masses has to come from somewhere, and so the overall energy, which is what drives the dynamics of the universe, doesn't change, so the model can't predict anything different from standard cosmology.

OTOH, if stress-energy is not locally conserved, then we should be able to observe such violations of conservation. But no such observation has ever been made: we have extremely strong evidence of local stress-energy conservation.

<comment><USER20> I can see your point, but is the introduction of dark energy in the current favored model better? Instead of having an energy coming from nowhere that increases particle mass, we have something coming from nowhere that expands space.

<comment><USER19> _> Instead of having an energy coming from nowhere that increases particle mass, we have something coming from nowhere that expands space._

Dark energy does not "come from nowhere". It's locally conserved everywhere. It has to be: the covariant derivative of the metric is identically zero, and the "stress-energy tensor" of dark energy is just a constant times the metric.

</comment></comment></comment></comment><comment><USER21> The universe isn't expanding. It's everything in it that's shrinking!

<comment><USER22> Strange that your comment is being downvoted, because it's a good summary of the article!

For instance size of hydrogen atom is inversely proportional to the mass of electron [1], so with heavier electrons, sizes of atoms shrink.

And in general in units where planks constant and speed of light are equal to one, mass is measured in 1/length.

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

</comment></comment><comment><USER23> This seems testable enough... The speed of light isn't in question here, so the frequency is the yardstick. Can't we just record the frequencies given off by the elements every hundred years or so and see that they are the same?

<comment><USER12> That's true, as with this cosmology light evidently isn't affected by the increase in rest mass, as photons are massless. If this cosmology affected relativistic mass, then light would also be affected and would not be seemingly redshifted by the mass gain mechanism.

So, yeah, we should be able to measure a gradual emission spectrum shift here on Earth with current methods - we can measure energies of photons to very high precision, and you'd likely only need a few years of data to prove or disprove the hypothetical cosmology.

<comment><USER24> We should do it then. Maybe nobody ever looked because we assumed these things to be invariant.

</comment></comment></comment><comment><USER25> What are the theories on what we think the edge of the universe looks like? What does it even mean? Will we just hit an invisible wall like in a video game? Or do we think it's curved around the edge? Or what?

If it's expanding, what is it expanding into?

<comment><USER26> This is something that has always intrigued me. What could possibly contain the universe? Another universe perhaps?

<comment><USER27> I think such a thing is difficult to comprehend except maybe mathematically. We are our universe and our universe is us.

</comment></comment></comment><comment><USER28> We observe from a far distant star the red shifted spectrum. This is explained by the expansion of the galaxy and the expanding room between us and this star. So the photons coming from there have a red-shifted and hence lesser engery. What has happend to the energy of the photon? Where's it gone to?

<comment><USER29> I think the theory is suggesting that the photon was emitted with less energy.

<comment><USER30> I think the question is that if the current accepted theory for the redshift is correct, then where has the energy gone?

</comment></comment></comment><comment><USER31> I can't see why the article would say the effect is not measurable. We are trying to contrast two explanations: In one, galaxies are receding and the expansion of space in the intervening distance red shifts the spectra. In the other masses are changing (globally?) as some rate, changing the spectra.

The best modern atomic clocks depend on atomic spectra, a shift in which would be evidence for or against this model.

Given the precision of modern atomic clocks (<10^-17)[1] and the fact that the galactic spectral shifts are significant at large distances this seems plausible. I don't have precise #'s to do the calculations at hand so maybe I've made an error.

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

<comment><USER32> But if our atomic clocks' frequency is changing, how would you tell? You can't use a more precise clock; we don't have one. You'd have to do something like measure how far light travels in the same time. But if our length measurements are changing too... do they cancel? Or could we still tell?

<comment><USER33> What you would need to determine is whether a dimensionless quantity is changing.

[https://en.wikipedia.org/wiki/Fine- structure_constant#Is_the...](https://en.wikipedia.org/wiki/Fine- structure_constant#Is_the_fine-structure_constant_actually_constant)?

If the fine structure constant α is found to change, then would only be able to say that the relationship among the speed of light c, the elementary charge e, and the Planck constant ħ are changing, but IMO if we discovered that (say) α changed from .007300… to its present value of .007297…, we would not be able to then say "the speed of light changed (and the elementary charge and Planck constant remained the same)"

…but as a matter of practicality, scientists could feel free to _use_ a different value for c in the past (and the present value for the elementary charge and Planck constant), if that is the most convenient way to accommodate a change in α. It wouldn't surprise me in the least if holding c and ħ constant is better for astronomers and holding e and ħ constant are better for particle physicists.

(Saying that ħ changes would be similar to saying that mass changes, or at least, the units of ħ include mass, and the Planck constant "is the basis for the definition of the kilogram." in the SI system [well, technically, this is not the case until next month. Right now the kilogram is still defined by the physical "international prototype kilogram" object, but the above quote is from wikipedia])

However, while the best experiments are consistent with changing α, the change in α is constrained to be WAY less than it would need to be to explain cosmological red shift observations.

</comment></comment></comment><comment><USER34> There is also the opposite scenario, the Big Rip: [https://www.youtube.com/watch?v=gEyXTQ9do-c](https://www.youtube.com/watch?v=gEyXTQ9do-c)

</comment><comment><USER35> Kind of related to something that I've been chewing on:

I've read things (outside of the OP) that say the universe is expanding and also speeding up it's expansion, as neighbors exert less of a pull on each other the further spread out things get. However, that gravitational pull is still there -- will it at any point slow down the expansion and retract back inwards?

<comment><USER19> _> that gravitational pull is still there -- will it at any point slow down the expansion and retract back inwards?_

No. If we are talking about the current best model we have of the universe, the dark energy density (which is what drives the acceleration of the expansion) is constant in time, while the density of matter (which is what causes the expansion to decelerate) decreases with time. Up until a few billion years ago, the expansion was decelerating, because the density of matter was high enough to dominate. But since a few billion years ago, the density of matter has been small enough that the dark energy dominates, and that is never expected to change.

<comment><USER36> Though to be fair, our expectations on what dark energy will do aren't very well grounded.

We already have inflation and dark energy but no good reason to expect either of them to be there _at all_. Like, the book on dark energy I've seen go: "here are a bunch of pretty good guesses", thats not a field full of confidence in its expectations (though admittedly the book is 9 years old by now).

<comment><USER19> _> We already have inflation and dark energy but no good reason to expect either of them to be there at all._

I have seen plenty of heuristic arguments for why we should expect inflation to be there, but I'm not really qualified to judge. None of them seem to have convinced enough physicists to be considered standard.

For the cosmological constant, I think it depends on what you consider the "natural" condition to be. The simplest way to derive the Einstein Field Equation is to start from the Einstein-Hilbert Lagrangian and vary it with respect to the metric. The justification for using the Einstein-Hilbert Lagrangian is that it contains the only scalar which contains up to second derivatives of the metric and is quadratic in the metric and its derivative, namely, the Ricci scalar. But that statement is not actually true: there's another obvious scalar that meets this requirement, namely a constant. So the most "natural" version of the Einstein Field Equation contains the cosmological constant: it should be there on theoretical grounds, and that means "dark energy" should be there as well.

Of course that also raises another problem, which is indeed one we don't have a good answer to at present: why is the cosmological constant so small?

</comment></comment></comment></comment><comment><USER37> Wouldn't this theory rule out dark energy since I believe dark energy is used to explain an accelerating, expanding universe?

<comment><USER38> Yes, I think that's the point.

</comment></comment><comment><USER39> > Conversely, if the particles were to become lighter, the frequencies would > become redshifted.

> If all masses were once lower, and had been constantly increasing, the > colours of old galaxies would look redshifted

Can anyone explain this apparent contradiction?

<comment><USER40> If all masses were once lower, and had been constantly increasing, then those galaxies are now blue-shifted, and blue shifted is what we have come to think of as normal. But billions of years ago, when they were lighter, they were emitting photons that, to us now, in the present, seem red-shifted. They seem redshifted because they come from the past, when things were lighter.

<comment><USER41> Or in very straightforward terms:

lightweight is red, heavy is blue

If everything constantly grows heavier then the past is red and the future is blue.

</comment></comment></comment><comment><USER42> >Instead, the Big Bang stretches out in the past over an essentially infinite period of time.

So the timeline according to this theory is [Big Bang] - >[Inflation] - >[Increase in mass] & we're seeing the redshift from that?

Head hurts, I love it.

</comment><comment><USER43> Alvie would be pleased to know that Brooklyn is not expanding.

</comment><comment><USER44> Does this mean that G is not contant? And would it throw away all our calculations of distances of galaxies in the known Univers?

</comment><comment><USER45> We know there is an equivalence between mass an energy.

Does this view imply that new energy is appearing in the universe?

<comment><USER46> The _traditional_ view is that the universe is expanding due to "dark energy", which does presume that yes, new energy is appearing in the universe all the time (at extremely low amounts, but over galactic distances it adds up to cause expansion)

<comment><USER45> I suppose you are right, I didn't though about that. I find the implications surprising.

Does that means that the universe can't be considered a closed system and entropy increasing is not unavoidable?

</comment></comment></comment><comment><USER47> As my imagination, the Big Bang is the collision of two universes in the past.

<comment><USER48> "The ekpyrotic theory hypothesizes that the origin of the observable universe occurred when two parallel branes collided." \- [https://en.wikipedia.org/wiki/Brane_cosmology#Models_of_bran...](https://en.wikipedia.org/wiki/Brane_cosmology#Models_of_brane_cosmology)

<comment><USER47> Only a collision between super massive materials could produce such huge larger energy as we see in Big Bang.

<comment><USER48> Like a cyclical interaction with a neighbor brane which is essentially another universe? Because that's the ekpyrotic universe model. And it fits with your imagination.

<comment><USER47> What is "ekpyrotic" ? Google Translate can't translate it, sorry.

<comment><USER48> The first hit from DuckDuckGo for 'ekpyrotic' is the Wikipedia page [https://en.wikipedia.org/wiki/Ekpyrotic_universe](https://en.wikipedia.org/wiki/Ekpyrotic_universe) . It describes the reason Steinhardt created that word as the name for the model.

The Steinhardt and Turok preprint is at [https://arxiv.org/abs/hep- th/0111030](https://arxiv.org/abs/hep-th/0111030) , published in the journal Science at [http://science.sciencemag.org/content/296/5572/1436.full](http://science.sciencemag.org/content/296/5572/1436.full) .

> We propose a cosmological model in which the universe undergoes an endless > sequence of cosmic epochs each beginning with a 'bang' and ending in a > 'crunch.' The temperature and density are finite at each transition from > crunch to bang. Instead of having an inflationary epoch, each cycle includes > a period of slow accelerated expansion (as recently observed) followed by > slow contraction. The combination produces the homogeneity, flatness, > density fluctuations and energy needed to begin the next cycle.

See also [https://en.wikipedia.org/wiki/Paul_Steinhardt#Cyclic/ekpyrot...](https://en.wikipedia.org/wiki/Paul_Steinhardt#Cyclic/ekpyrotic_theory_of_the_universe) .

</comment></comment></comment></comment></comment></comment><comment><USER49> What does the Universe expand into?

<comment><USER50> Nothing. The concept seems foreign because we're always in something, but there is definitionally nothing the Universe can expand into. If it's easier to conceptualize, just think of 'expansion' as a short way of saying 'distances are getting longer'.

<comment><USER49> So does it mean that everything in the Universe is getting bigger but since everything is getting bigger we don't know it because relative sizes are the same?

</comment></comment></comment><comment><USER51> could this help explain the mass of the several copies of the kilogram drifting apart?</comment>


Building an internet search engine. Can someone review it? - <AUTHOR> https://deepsearch.tsignal.io <comment><USER2> This should be on page 1.

Would need to thoroughly test this to truly evaluate but based on quick glance, a few coments/suggestions:

       [ ] results should be numbered
       [ ] purpose of "relevant domains" not clear
       [ ] ranking methodology should be explained, e.g., stackoverflow and wikipedia being more heavily weighted
       [ ] need to attach tld when using inurl, e.g. inurl:-wikipedia does not work
       [ ] open source the code, like gigablast
       [ ] does not appear to be "internet" search engine i.e. only searches web
       [ ] provide export of list all results to CSV or some open text based format making ranking irrelevant and enabling user to resort according to own criteria
       [ ] what is the name of the crawler and do some sites block it
       [ ] publish the rate limits on queries if any

Overall it looks very nice i.e. simplicity of design compared to other alternative public web search engines and faster than some.

EDIT: Found blog post at [https://medium.com/tsignal](https://medium.com/tsignal) with more info.</comment>


Building 3d stuff for the web with CSS [video] - <AUTHOR> http://www.youtube.com/watch?v=0ZxFwNgc0e0

<comment><AUTHOR> Here's the link to the tool: <http://felipenmoura.org/projects/root3d/></comment>


How Apple Will Become the Most Valuable Company in America - <AUTHOR> http://www.theatlantic.com/business/archive/2010/12/how-apple-will-become-the-most-valuable-company-in-america/68120/

<comment><USER3> Better title for this article: Apple Will Become the Most Valuable Company in America

The "how" in this article boils down to "by being worth more than the other companies in America."

</comment><comment><USER4> It wouldn't surprise me....I'm not really a fan of apple, and I have bought 2 iphones, 2 ipod touches (lost the 1st one), and an iPad in the last year. As soon as the ipad with facetime comes out, I'm buying two.

<comment><USER5> "I'm not really a fan of apple", what will you buy when you ARE an Apple fan? Becoming an Apple fan happens slowly but surely - 2 years ago I'd never have thought I'd be typing on a MacBook.

</comment></comment><comment><USER6> Id like to know how many developers buying macs is actually due to it being a must for iPhone development? i must be very uncool or may be i just dont "get it" if I prefer to save good 500-1000 bucks buying a dell (with ubuntu) that is a good 20% more powerful than the latest MBP...

<comment><USER7> Uh, So you're saying that the draw to develop for the platform is driving Mac sales? Are you aware how marginal developers really are? There aren't many, but you probably know a lot of them, and encounter many on this site. I suppose you imagine everyone in the world who thinks differently than you must have been forced or are stupid.

<comment><USER8> There's no need for that tone. You misunderstood the question - <USER2> was just asking why macs were so popular among developers.

</comment></comment></comment><comment><USER9> Over last 5 years, Apple's net income increased 7x, growing from $2 billion to $14 billion. Over this same period, Microsoft grew its net income only 1.5x, from $13 billion to $19 billion. While it is amazing that Apple is almost worth $300 billion, it is truly staggering that Microsoft is still worth $240 billion.</comment>


Google Translate's 'Sinister Religious Prophecies', Demystified - <AUTHOR> https://www.skynettoday.com/briefs/google-nmt-prophecies <comment><AUTHOR> By the way , as mentioned in this a few more general recent articles about the state of NLP worth reading are: [http://deliprao.com/archives/301](http://deliprao.com/archives/301) [https://www.skynettoday.com/editorials/state_of_nmt](https://www.skynettoday.com/editorials/state_of_nmt)</comment>


Some thoughts on how we might get from where we're at now to a Second Civil War - <AUTHOR> http://foreignpolicy.com/2017/10/10/some-thoughts-on-how-we-might-get-from-where-were-at-now-to-a-second-civil-war/ <comment><USER2> this guy is basically just repackaging class warfare and passing it off as "OMG civil war is coming I was in the army for 20 years you gotta listen to me."

And yet he completely misses ACTUAL threats to the integrity of our republic: erosion of faith in our federal institutions.

The FBI has lost all credibility because of Comey and the clintons.

The Justice Department is in the process of losing credibility with Sessions lack of action, and previously, with Lynch meeting with former president clinton.

faith in the effectiveness of Congress and the Senate is at an all time low, basically due to their incompetence on both sides.

faith in the neutrality of the Supreme Court is slowly dwindling with Gingsburg's anti-trump rhetoric during the election.

Faith in the major media instutions is completely gone because they keep lying about pretty much everything for ratings.

Faith in the president is very low among his non-supporters.

theres more. funny how the author completely misses all of them.</comment>


TIOBE Index: Swift enters the top 10 for the first time - happy-go-lucky http://www.tiobe.com/tiobe-index/ <comment><AUTHOR> Delphi back in Top 10 is also worth noting :)</comment>


Typo: A programming language that runs in Haskell's type system - <AUTHOR> https://github.com/seliopou/typo

<comment><USER2> Author here. Besides creating Typo as an exercise in implementing a language, it's also the punchline to a seven-year-old joke[1] about implementing RSA in Haskell's type system, which I did:

      https://github.com/seliopou/typo/blob/master/examples/rsa.typo

Hopefully I'll have the time next week to write a blog post explaining how the encoding of functions work, as well as a cool transformation I employed to make the translation simpler than it otherwise would be.

Until then, enjoy!

[1]: [http://article.gmane.org/gmane.comp.lang.haskell.general/132...](http://article.gmane.org/gmane.comp.lang.haskell.general/13223)

</comment><comment><USER3> I always assumed haskell's type system would eventually just turn into prolog.

<comment><USER4> I've always hoped some language would have a prolog type system. Just today, I was pointed to liquid types [1,2] in haskell-cafe, and they look really promising in that respect. But the idea of having my compiler bail with a nice error message when I try:

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

fibPlus :: (int LESSTHAN 30) -> (int LESSTHAN 500000) fibPlus x = fibs !! x + 100

Is definitely too good to be true.

[1][http://goto.ucsd.edu/~rjhala/liquid/liquid_types.pdf](http://goto.ucsd.edu/~rjhala/liquid/liquid_types.pdf) [2][http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/](http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/)

<comment><USER5> Hindley-Milner style type inference, which is done by MLs and is similar to what is done in Haskell, uses unification, which is a large part of how Prolog reasons, to determine if two types with still unknown subparts can be the same. You can do surprisingly complex things in these type systems.

For a more complex type system that does similar things and allows a lot more reasoning in the type system, you could take a look at Agda. This is a Haskell-like language with a fully dependent type system, i.e., types can contain arbitrary language terms. This has the downside of being not-quite- Turing-complete, as you want to be able to decidably typecheck. However, it is powerful enough that its type system is often used to automate proofs about both programming language theory and more ordinary math.

</comment></comment></comment><comment><USER6> Don't you think an example where the type system has a visible impact would be appropriate? As it is now, none of the examples show anything that doesn't look like vanilla lisp. I think what makes the Haskell type system nice to use is inference along with type assertions. Do you have type assertions, or is the implementation of types behind the scenes until a type mismatch occurs?

<comment><USER7> I think maybe you misunderstood what the language does. It is compiled not to Haskell itself, but to the type system. No Haskell code is executed when using the interpreter (well, apart from the interpreter's itself), but it is Haskell's types that are... executed? checked? It's as is you made a program using C++ templates, not C++.

Here you have some examples (although it requires some knowledge of Haskell): [http://www.haskell.org/haskellwiki/Type_arithmetic](http://www.haskell.org/haskellwiki/Type_arithmetic)

<comment><USER6> I think wishful thinking twisted the title in my head, into reading of a lisp with a type system like Haskell's.

<comment><USER7> This may be near your wishes: [http://docs.racket-lang.org/ts- guide/](http://docs.racket-lang.org/ts-guide/)

</comment></comment></comment></comment><comment><USER8> Perhaps now C++ will have some company in the club of languages that people mock for having Turing-completeness in their type system.

<comment><USER9> Well, it depends on what you mean by "Haskell's" type system. The standard Haskell type system, as defined by the Haskell 98 spec, is decidable (and hence not Turing complete).

Thus Typo uses a number of GHC-specific type system extensions, one of which has "Undecidable" in its name. They're hidden in Prelude.hs.

        {-# LANGUAGE NoImplicitPrelude #-}
        {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
        {-# LANGUAGE FlexibleInstances, UndecidableInstances #-}
        {-# LANGUAGE OverlappingInstances #-}

It's very common to use _some_ extensions, but AFAIK pretty rare to use _UndecidableInstances_. I'm not actually sure what it does.

<comment><USER4> [http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/type-...](http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/type- class-extensions.html#undecidable-instances) has a decent explanation.

<comment><USER2> UndecidableInstances a.k.a. YouDecidableInstances.

While I was writing the Prelude, I messed up one of the definitions and ghc kept blowing the context stack limit. So I tried it with -fcontext-stack=5000, figuring it wasn't my bug but just a consequence of the inefficient encoding I was using. The type system ended up allocating upwards of 4 gigs before I killed it.

</comment></comment></comment></comment><comment><USER10> In the github description there is a typo: 'Langauge Features'.

A typo on typo's presentation. On purpose? :)

<comment><USER11> I submitted a pull request, and just now I noticed other three identical requests. So I submitted a Github feature request to warn on overlapping contributions, probably along with a few others...

</comment></comment><comment><USER12> Oleg is a beast.</comment>


Show HN: Morning Reader 3 – Curated technology and blockchain news - <AUTHOR> https://morningreader.com <comment><AUTHOR> Hi there! We've just launched Morning Reader 3, a simple, stress-free way to keep up with technology and blockchain news. Would love to hear your feedback! Thanks.</comment>