Our field isn't quite "artificial intelligence" – it's "cognitive automation" - <AUTHOR> https://twitter.com/fchollet/status/1214392496375025664 <comment><USER3> As usual, the monks know what the laity doesn't, and aren't particularly afraid to talk about it. Also as usual, there's still a yawning gap between what domain experts are up to and what non-domain experts think they're up to.

That this is true in AI is not surprising; humility comes from knowing that my domain expertise in some fields (and thus a clearer picture of 'what's really going on') is guaranteed to be crippled in other fields. Knowing that by being in some knowledge in-groups requires me to also be in some knowledge out- groups is the beginnings of a sane approach to the world.

<comment><USER4> The author is just correcting a misnomer. It is not really accurate to say that machine learning is intelligent at all, so why label it as such? It's confusing for everyone and leads to great misunderstandings.

<comment><USER5> Machine learning is a particular narrow result of studying the wider field of artificial intelligence. Just as expert systems, or rdf knowledge representation, or first order logic reasoners, or planning systems - none of them are 'intelligent' but all of them are research results coming from (and being studing in) the discipline of studying how intelligence works and how can something like it be approached artificially.

There's lots in the field of AI that is _not_ 'cognitive automation' \- many currently popular things and use cases are, but that's not correcting a misnomer, that's a separate term for a separate (and more narrow) thing - <USER2> if that narrower thing constitutes the most relevant and most useful part of current AI research.

A classic definition of intelligence (Legg&Hutter) is "Intelligence measures an agent's ability to achieve goals in a wide range of environments". That's a worthwhile goal to study even if (obviously) our artificial sytems are not yet even close to human level according to that criteria; and while it is roughly in the same direction as 'cognitive automation', it's less limited and not entirely the same.

For example, 'cognitive automation' pretty much assumes a fixed task to execute/automate, and excludes all the nuances of agentive behavior and motivation, but these are important subtopics in the field of AI.

But I am willing to concede that very many people _are_ explicitly working only on the subfield of 'cognitive automation' and that it would be clearer if these people (but not all AI researchers) explicitly said so.

<comment><USER6> > _Machine learning is a particular narrow result of studying the wider field > of artificial intelligence._

I beg to differ, at least as far as terms go now. Neural networks lived in the "field" of machine learning along with Kernel machines and miscellaneous prediction systems circa the early 2000s. Neural network today are known as AI because ... why? Basically, the histories I've read and remember say that the only difference is now neural networks are successful enough they don't have to hide behind a more "narrow" term - or alternately, the hype train now prefers a more ambitious term. I mean, the Machine Learning reddit is one go- to place for actual researchers to discussion neural nets. Everyone now talks about these as AI because the terms have essentially merged.

> _A classic definition of intelligence (Legg &Hutter) is "Intelligence > measures an agent's ability to achieve goals in a wide range of > environments"._

Machine learning mostly became AI through neural nets looking really good - but none of that involve them become more oriented to goals, is anything, less so. It was far more - high dimensional curve can actually get you a whole lot and when you do well, you can call it AI.

<comment><USER5> What do you mean by "today are known as AI" and "became AI" ?

Neural networks have always been part of AI, machine learning has always been a subfield of AI, all these things are terms within the field of AI since the day they were invented, there never was a single day in history when those things had not been part of AI field.

Neural networks were part of AI field also back when neural nets were _not_ looking really good - e.g. the 1969 Minsky's book "Perceptrons", which was a description of neural networks of the time and a big critique about their limitations - that was an AI publication by an AI researcher on AI topics.

Your implication that an algorithm needs to do well so that "you can call it AI" is ridiculous and false. First, _no_ algorithm should be called AI, AI is a term that refers to a scientific field of study, not particular instances of software or particular classes of algorithms. Second, the field of AI describes (and has invented) lots and lots of trivial algorithms that approximate some particular aspect of intelligent-like behavior.

Lots of things that now have branched into separate fields were developed during AI research in e.g. 1950s - e.g. all decision making studies (including things that are not ubiquitous such as minmax algorithm in game theory), planning and scheduling algorithms, etc all are subfields of AI. Study of knowledge representation is a subfield of AI; Probabilistic reasoning such as Kalman filters is part of AI; automated logic reasoning algorithms are one more narrow subfield of AI, etc.

<comment><USER7> I think what parent poster means was that for people who don't know better "neural networks === AI". For people who now a bit more, there is bunch of other stuff than just neural networks, and neural networks are not some god sent solution for AI.

</comment></comment></comment></comment></comment></comment><comment><USER8> I think it is also important to remember that intelligence isn't clearly defined. It seems a lot of people interpret it in different ways and the definition is closer to pornography (I know it when I see it).

I often see two camps, one that defines intelligence to be more human like. Limiting it to really cetaceans and hominids. Maybe including ravens. The other group gives too vague of a definition.

Personally, I do not see a problem with having lots of bins. I don't think many disagree that intelligence is a continuum. So why restrict it to very high level bins? Because that's the vernacular usage? I for one vote for the many bin and continuum approach. In this I think you could say that ML has some extremely low level form of intelligence, but I would generally say lower level than that of an ant. In that respect, a multi agent system with the intelligence surpassing that of ants I believe would be extremely impressive.

<comment><USER9> >So why restrict it to very high level bins?

I don't think it's a quantitative issue (the level of the bin). It's a qualitative issue. When people say that ML lacks intelligence what they're saying is that it lacks robustness, common sense, agent like behaviour, the ability to reason and so on.

Intelligence (in humans or animals) does not appear to be just data driven pattern matching. I think we can say this with some confidence given that even the fanciest ML algorithm still hopelessly sucks at performing tasks that are trivial even for barely intelligent animals.

<comment><USER10> > Intelligence (in humans or animals) does not appear to be just data driven > pattern matching. I think we can say this with some confidence given that > even the fanciest ML algorithm still hopelessly sucks at performing tasks > that are trivial even for barely intelligent animals.

Do you mind expanding on this? A lot of the tasks primitive animals can be replicated by Deep RL algorithms given the same environment.

Humans adapt to sensor information, memory and a reward/penalty system just like RL. We're just much more advanced and have sophisticated systems to sense and act.

<comment><USER9> >A lot of the tasks primitive animals can be replicated by Deep RL _algorithms given the same environment_.

Highlighted the last part because this is the key difference. Humans and animals can navigate unknown and unstructured and open-ended environments. You can identify a dangerous predator without having to see ten thousand images of mauled bodies.

Humans and animals can generalise in a way that is robust and independent from 'data' because they understand what they see. RL algorithms have no understanding of the world. If you let an RL system play breakout but you resize the paddle by five pixels and tilt it by 2 degrees it cannot play the game.

Daniel Dennett helped popularise the notion of _Umwelt_ , which is losely translated someone's self-centered world as subjectively perceived by an organism and filled with meaning and a notion of how the agent relates to it. It's distinct from an objective 'environment' that everyone shares.

Machines lack this notion, they have no real concept of anything, even the fanciest algorithms. Which is also why conversational agents have only really made advances on one front, which is understanding sound and turning text into nice soundwaves. They have made virtually no progress in understanding irony, or ambiguity or anything that requires having an understanding of the human _Umwelt_. We don't even have any idea how the mind constructs this sort of interior representation of the world at all, and my prediction is we're not going to if we continue to talk about layers of neurons instead of talking about what the possible structure of a human or animal mind is.

<comment><USER11> Well, what if you trained on the unbelievable amount of data that enters the human brain?

Like, say inputting years of high definition video, audio, proprioception, introspection, debug and error logs, data from a bunch of other sensors, etc. Then put that in a really tight loop with high precision motion and audio output devices, and keep learning. Also do it on a really fast computer with lots of memory. Also make the code itself an output.

If thats not enough, you could always try self replicating to try to create more successful versions over million year timescales.

<comment><USER9> That's trivially true in the sense that this is how we can only assume humans and animals came to be but I don't think there's any guarantee that this can be replicated in a silicon-based software architecture which is very different from analog and chemical biological organisms. Today already energy and computional costs are high with model computation cost going into five or six figures even in just one domain.

But more importantly, I think the problem with this approach is that it's essentially a hail mary of sorts with potentially zero scientific insight into how the brain and the mind works. It's a little bit like behaviourism before the cognitive revolution with AI models being the equivalent of a Skinner box.

<comment><USER11> I don't know the history of it and am not an expert in the field, but it seems to me that it's valid to call the things ML can already do "intelligence" in a generalized sense, and that there is nothing categorically different between that and human intelligence, it's just a matter of how complicated humans are.

That seems like a problem you can sort of throw hardware at for a while until it gets good enough to help you figure out how to make something smarter.

<comment><USER12> I think there is little evidence to suggest that neural networks and human minds behave in the same way modulo complexity.

In science there is a tendency to come up with models of the world - simplifications which we can observe and quantify - and then fall into the trap thinking that these models explain the world.

While neural networks are inspired by biological neural connections between synapses and neurons, the converse that neural networks are therefor intelligent does not hold.

<comment><USER11> I'm not suggesting NNs should be considered intelligent because of their inspiration from biology. Just that they should be considered intelligent because of what they are currently capable of (though that is way less intelligent than humans or animals of course).

But it seems like there is a plausible path to increasing their "intelligence" by dumping more data and hardware at them.

Like GPT2 shows quite a surprising amount of structural complexity even though it's very dumb in other ways – it feels like if you could pump a million times more data into it you'd get something that seemed really quite intelligent.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> I see a lot of AI engineers who seem concerned with this particular issue, which I never really understand.

Is it because of a perception that most regular people are likely overestimating the speed of which AI is going to overtake human intelligence? Or more about corp management wanting miracles that aren't possible?

Why does this matter and always seem to be talked about?

<comment><USER14> Because there's a history of overhyping ML/AI (whatever you want to call it) leading to AI winters. Winter in this case being kind of like a recession in economic terms - most research funding dries up, etc. We essentially had one of those winters from the late 80s until about a dozen years ago. A lot of laymen now think of AI as being "magic" that can do anything and that's not a good thing when the reality turns out to be different.

At this point I don't think we'll see an AI winter as deep as some of the previous ones. But we could certainly see an AI Fall.

<comment><USER15> >> Because there's a history of overhyping ML/AI (whatever you want to call it) leading to AI winters.

Note that past AI winters have not occurred because of overhyping _machine learning_. They occurred because of overhyping of _symbolic AI_ that had nothing to do with machine learning. For example, the last AI winter at the end of the '80s happened because of the overhyping of expert systems- which of course are not machine learning systems.

Machine learning is not all, not even most, of AI, historically. It's the dominant trend right now, but it was not the dominant trend in the past. The dominant trend until the 1980's was symbolic reasoning.

<comment><USER16> But symbolic reasoning mostly worked, did it not? However, its Achilles heel was that for it to be useful, it's necessary to distill a lot of domain knowledge into a format that can be processed by an expert system. That means, writing 10s upon thousands of rows of "if then then that".

Machine learning is different in that it is more amenable to distilling those rules from the data automatically. It is successful where symbolic reasoning failed because it can go from the raw data. A good portion of machine learning research is in new ways to preprocess and format data into a structure that can be further consumed by linear algebra, which turns out to be a lot easier and practical than figure out a huge database of sensible first order predicate logic statements.

If ML techniques can be used to feed symbolic systems, the latter would show promise again, which is already happening in recent trends in causal inference and graph networks. The marriage of these two fields is inevitable, and has already started.

<comment><USER17> > That means, writing 10s upon thousands of rows of "if then then that".

LOL.. It's full of ifs.. [1]

[1] [https://qph.fs.quoracdn.net/main- qimg-89cfa17ca63ddac683e04f...](https://qph.fs.quoracdn.net/main- qimg-89cfa17ca63ddac683e04f0852336e47.webp)

</comment></comment></comment></comment></comment><comment><USER18> Brilliant observation.

And it's even harder than this.

The problem is not that we have a problem. The problem is that we have problems. So the solution is not finding a solution to a problem. The solution is finding a metasolution that is valid across time and tribes. Bam! the challenge of being an intelligent being in this universe. No way we can automate that. Only mimic a portion of it and call it intelligence doesn't make it really intelligent.

<comment><USER19> FWIW, check out the Gödel machine:

[https://en.wikipedia.org/wiki/G%C3%B6del_machine](https://en.wikipedia.org/wiki/G%C3%B6del_machine)

[http://people.idsia.ch/~juergen/goedelmachine.html](http://people.idsia.ch/~juergen/goedelmachine.html)

> No way we can automate that.

It's a very very interesting question. Personally I believe that "automaton" is _almost_ the opposite of "being". But that's just me, not science or other authority. Certainly, somewhere between virus and human _something_ comes into being (no pun intended.) I don't know of any non-metaphysical argument that we couldn't find some _other_ way to create non-biological general AI.

I think we could genetically engineer human DNA to create wetware G"A"I but I put the "artificial" in quotes to indicate that I'm not saying whether that would count as AI or not. I know of a few efforts to create "Daleks" out of human brain organoids, but I don't think anyone has gone beyond the speculative/hype stage with it so far.

<comment><USER20> I was waiting for somebody to goerdlize that

</comment></comment></comment><comment> GuB-42 From the Merriam-Webster dictionary.

Definition of cognitive 1 : of, relating to, being, or involving conscious intellectual activity (such as thinking, reasoning, or remembering) 2 : based on or capable of being reduced to empirical factual knowledge

Using "cognitive" instead of "intelligence" puts the emphasis on data processing rather that adaptability, which may be a bit more in line with how things are done today. However, it doesn't addresses the core of the debate. The usual "[technology] isn't [AI/cognitive automation] because it can't do [thing humans do], it is just [thing computers do]". Both terms relate to consciousness, and are generally considered fundamentally human qualities.

I think there is simply no way out of that debate. Maybe use a term that it sounds completely unrelated to human activity, maybe something like "Big Data Statistical Matching".

</comment><comment><USER21> Intelligence doesn't have a lot of scientific ground either. It's pretty hard to define what intelligence is, or at least have a scientific definition that is precise enough. The Turing Test is only a measure, it doesn't help to reach a definition.

Practical research will always hit a ceiling if scientists cannot try to define what they're looking for.

Even machine learning is not a good definition. There are other attemps, like "sophisticated statistics" or "statistical prediction".

Kudos for this tweet.

</comment><comment><USER22> There has been a lot of debate about the state of AI in recent weeks on Twitter (see #AIDebate). A lot of it was about naming. It occurred to me that very opinionated people had no idea what people in the community are actually doing, and so the whole excercise seemed like a learning experience for them, which seems to be a good thing.

The goals of AI (which Google trends classifies as "field of study" - I think that captures it quite well) haven't changed in decades - to reverse engineer the miracle of human cognition. A certain number of people (like the teams of Yoshua Bengio or Demis Hassabis) have the clear mission to work on just that. The progress in this area is much slower than the perception of the last 5-10 years would suggest. It was just that work from the 90s and 2000s were put to test and quickly outperformed other approaches - symbolic or what we now call "classic machine learning" (e.g. in speech recognition, image classification/detection, machine translation, Information retrieval). All these areas had important and valuable applications in industry and have sucked up a lot of money.

But this is only a tiny part of what human cognition entails. Areas around memory, reasoning, consciousness etc. are completely unsolved. Where are we on a scale of 0 to 1000 of solving the problem? Perhaps somewhere between 20 and 50, nobody knows. AI is a north star, and it is a weird development that people have started to call it "AI" again (it felt totally weird about 3-4 years ago when this happened).

So, I think the field is still rightly called "AI". Call the current state of it "system 1", "differential programming", "deep learning" or whatever.

</comment><comment><USER23> Well said. The definition of intelligence is bastardized for virtually all current AI applications. They are glorified statistical heuristics / stochastic descent as has been mentioned before. The key to approaching actual intelligence as we know it, will be a system that can dynamically model its environment and actors in it, since even insects are able to do this to some extent.

</comment><comment><USER17> When did Machine Learning become Artificial General Intelligence?

When did SVMs become AI?

I'm going to take the dissenting viewpoint here. I think AI as it is being sold today (e.g. the Deep Learning).. is bullshit. It's the new snake oil.

Everyone is pouring in all this money because of FOMO (Fear of Missing Out).

Yes, it's producing some fancy new toys. Beating the best human player at Go. Or doing some facial recognition. Or winning at StarCraft.

But I don't even see the point at mastering Chess past a certain level, and I'm certainly not going to bother with mastering a RTS game like StarCraft.

The scary thing is if some military planner thinks the StarCraft AI is sufficiently smart enough, to put on military weapons systems, and used to hunt down other humans.

Now, if we keep AI to be for these constrained things, then yes, it can produce more toys and products, that can be sold. It's the next evolution in smart products. Corporate America can keep cranking out new and evolved products to sell, and slap an AI sticker on it.

And have you noticed? Everyone is slapping an AI sticker on everything. It's like Microsoft and the .Net branding, or Sun and the Java branding all over again. But this time, everyone is calling their little algorithm, AI.

But beyond that, it's just another gimmick.

Deep Learning is an advanced form of OCR. Facial Recognition is an advanced form of OCR of the face. Do we consider OCR to be AI these days? No, we don't. We just think of it as a wonky pattern recognition engine, that half the time doesn't work, and the other half is frustrating enough, that we just type it out ourselves. In fact, OCR uses a neural network algorithm.

It's not an evolution that we need, in order to achieve AI. It's a revolution. And nothing I've seen so far, has convinced me that it can be achieved. In the meanwhile, if you're a newly certified 'AI Expert', then cash in as much as you can. But.. Beware. Winter is coming.

<comment><USER24> > When did xyz became AI

When it started to become a buzzword for PR and more investors money.

</comment></comment><comment><USER25> Recently I've been reading a lot about AI and ML.

It's quite clear to me what ML is - solving classification and regression problems. There are some fuzzy edges, but that's true of any discipline. Maybe you invoke Mitchell's definition and say "well, it's improving on a task" (as many introductions to ML do) but that's completely out of step with what people actually treat as ML.

There are lots of interesting "learning automation" areas that we're neglecting - symbolic reasoning being the glaring one for me.

AI just seems like a nonsense term to me. Maybe it'd be better if we stopped using it.

</comment><comment><USER26> Following the recent "AI Debate" between Yoshua Bengio and Gary Marcus [0], there was a lot of discussion about the exact definition (or redefinition even, as some argued) of some labels like "deep learning" and "symbol" (what do we mean exactly by these?), I find that it is quite relevant to this discussion.

[0] [https://www.youtube.com/watch?v=EeqwFjqFvJA](https://www.youtube.com/watch?v=EeqwFjqFvJA)

</comment><comment><USER27> I don't really agree, and think the misnomer should be applied in the opposite direction: AI should be called 'adaptive algorithms' and it should be just another tool the box of CS people.

We're not doing anything that we were not before.

There is no new paradigm shift. There is no AI. There's just a slightly new approach to solving problems. That's it. There's somer really nice improvements in computer vision ... and a few other things ...

... but all this talk of 'intelligence' etc. should be brushed aside, it's misleading to everyone.

There will be no 'general AI' with our current approaches for a whole variety of reasons.

I'm embarrassed at how so many intelligent colleagues drink the kool-aid on this.

Take classical ML: it was hyped for a while, now it's not as exciting as 'Deep Learning'. Well, in few years, I think that DL will be there as well: just a tool in the toolbox.

</comment><comment><USER15> >> Our field isn't quite "artificial intelligence"

True, but so what? We call it AI and that's that, really. We've been calling it that for 70 years now and it's never been a problem.

And let's be absolutely clear that it's not the _name_ that's confusing the public but the way that industry luminaries promise autonomous cars and robotic maids in the next -3 years, or the way that the technology press -the _technology_ press- can't get its shit together to figure out the difference between "machine learning", "deep learning" and "AI" as fields of research and as category labels. Of _course_ the lay public is going to be confused if people who are paid to elucidate complex concepts make a mess of it.

<comment><USER6> > " _True, but so what? We call it AI and that 's that, really. We've been > calling it that for 70 years now and it's never been a problem._"

That isn't even ... _true_. AI became "machine learning" in the late 90s/early 2000s and that change happened because the chorus of criticism of "artificial intelligence" had become extremely loud and a less ambitious term served as a refuge.

<comment><USER15> AI was renamed into many things in the '80s and '90s, for example "Intelligent Systems" or "Adaptive Systems" etc, and that indeed was done to dissociate research from the bad rep that had accrued for AI. But "machine learning" has been the name of a sub-field of AI since the 1950's and it's never stood for the whole, at least not in conferences, papers or any kind of activity of the field.

For example- two of the (still) major conferences in the field are AAAI and IJCAI: the conference of the "Association for the Advancement of Artificial Intelligence" and the "International Joint Conferences of Artificial Intelligence". Neither of those is in any way, shape or form a conference for machine learning only and neither uses machine learning a byname for AI. By contrast, machine learning has its own journal(s actually) and there are specific conferences dedicated to machine learning and deep learning (NeurIPs and ICLR).

Additionally, there are many sub-fields of AI that are not machine learning, in name or function: intelligent agents, classical planning, reasoning, knowledge engineering etc etc.

The only confusion between "AI" and "machine learning" exists in the minds of tech journalists and the people who get their AI news exclusively from the tech press.

P.S. As a side note, the name for what the tech press is doing, referring to the field of AI as "machine learning", is "synecdoche": naming the whole by the name of the part.

</comment></comment></comment><comment><USER28> François Chollet's discussion with Lex Fridman (first half) is an interesting one on AGI - Video - [https://youtu.be/Bo8MY4JpiXE](https://youtu.be/Bo8MY4JpiXE)

</comment><comment><USER29> One thing I find strange is how much we emphasize the artificial nature of the intelligence. AI and automation always occurs in the context of human processes. Nothing is truly autonomous, so why design it as if human involvement is a failure? We can easily design artifacts to enhance human intelligence or team intelligence. Why the focus on the machine part and not the overall system that functionally accomplishes the desired work?

<comment><USER6> > _One thing I find strange is how much we emphasize the artificial nature of > the intelligence._

We really don't know what intelligence (sans qualifications) is. AI has been a term for effort emulate what we roughly think of as "intelligent" behavior. It's far from successful so far and the lack of a "theory of intelligence" is probably part of that. But it's pretty clear what "AI" researchers and systems are doing now is far from intelligence.

> _AI and automation always occurs in the context of human processes. Nothing > is truly autonomous, so why design it as if human involvement is a failure?_

This argument makes as much sense as "we'll never exceed the speed of light, why act like faster transportation matters". An automated factory still requires some maintenance but it's creation certainly is significant.

> _We can easily design artifacts to enhance human intelligence or team > intelligence. Why the focus on the machine part and not the overall system > that functionally accomplishes the desired work?_

Both approaches matter and since there's really nothing keeping people from doing both of these, people pursue each separately. Moreover, I'd say AI research could do well to cross-pollinate with human-computer interaction theory.

But overall, you seem to just not understand why automation matters - automation has brought vast productivity in a variety of fields. It may or may not be possible other further fields but if it is, it will transform the world equivalently.

</comment></comment><comment><USER30> I'd rather call it cognition imitation if you insist to associate it with cognition or intelligence. In fact it's just brute-force statistics.

<comment><USER31> Are we so sure human cognition isn't this too?

</comment></comment><comment><USER32> I have been wondering why we don't use the term "synthetic intelligence": [https://enki.org/2019/08/18/artificial-intelligence-is-a- dum...](https://enki.org/2019/08/18/artificial-intelligence-is-a-dumb-term/)

<comment><USER14> That just replaces the first word with what is essentially a synonym. It's the second word "intelligence" that's the issue.

<comment><USER32> "artificial" and "synthetic" aren't exactly synonyms in my mind. If I synthesize glucose, there is nothing artificial about it. It just didn't come from a process developed by evolution. Conversely, artificial leather is nothing like real leather.

I'll have to think about that some more.

<comment><USER33> But again, it's the "intelligence" part that's the misnomer. Except for John Carmack, no one's trying to invent general intelligence. Every single bit of work is merely automating tasks that _when performed by humans_ requires intelligence... except that too is a misnomer because as humans we literally can't do anything, no matter how mundane, without it "requiring intelligence".

</comment></comment></comment></comment><comment><USER34> Cognitive automation is a bit much, progressive pattern matching is more accurate.

</comment><comment><USER35> In my opinion, even calling it "cognitive" is too generous.

What makes it "cognitive" instead of just "normal" automation? Because it's dealing with information rather than the physical world?

I think a better term is statistical or digital automation.

</comment><comment><USER36> All programming is, is the reification of decision making.

</comment><comment><USER37> I like this comment:

>At the end of the day, "AI" is just glorified statistics (running on increasingly powerful computers).

<comment><USER38> Depends on what you mean by "AI". SageMaker / GCP / Azure / other ez-bake business "AI", sure.

Alas at the forefront, it's much harder to attribute GAN and Transformer performance to statistics.

</comment></comment><comment><USER39> Nope. It's just pattern recognition.

<comment><USER40> What is? I assume you mean machine learning? Ok... What about one shot learning like lake and tabembauns bpl? What about optimal resource allocation in auctions? Is this recognising patterns in event spaces larger than the number of atoms in the universe?

</comment></comment><comment><USER41> I think a better term you are contrasting it with is artificial mind, not artificial intelligence.

</comment><comment><USER42> Call it whatever you want, I don't care. It's working and improving year over year.

</comment><comment><USER43> nobody likes "artificial intelligence". laypeople are scared of it. the media blames it for all evils. it brings connotations of frankenstein, arrogant atheism, etc. it's reasonable to want to hide behind a different term.

</comment><comment><USER44> When machines transcend beyond their programmed limitations to shape their environment in their own image, then they become truly intelligent.

<comment><USER45> Why would a non-human intelligence necessarily have a drive to "shape their environment?" Maybe a non-human intelligence would discover the inevitable end of the habitable universe and opt to just do nothing?

<comment><USER46> Nobody's going to pay for AWS hours for a lazy robot. They'll keep changing it does something. The human drive, which is not essentially rational, will give birth to the machine drive, which won't be rational either.

</comment></comment></comment><comment><USER47> I hear this a lot: "Wellll, Machine Learning isn't TRUE artificial intelligence..."

Seriously people: are you THAT insecure? I realize it is a cutthroat hiring market and companies are stuffing extra zeroes onto signing bonuses to get anyone with an AI background, so maybe there is lots of jealousy and FOMO. I dunno, but it seems awfully gatekeep-y all of a sudden.

</comment><comment><USER48> It's curve fitting.

<comment><USER49> It seems unclear if your brain is also curve fitting. Time will tell hopefully.

</comment></comment><comment><USER50> not even, it's multivariate regression analysis optimization

<comment><USER51> It is automated (not _automatic_ ) cognition using multivariate regression techniques, after all, there is something to automate.

<comment><USER52> I think many take issue with the use of the word "cognition" in that definition.

</comment></comment></comment><comment><USER53> it's automation

Edit: artificial automation

Edit: computer science

Edit: pseudo science?</comment>


Did Microsoft steal its fonts from the Turkish army? (2012) - <AUTHOR> http://rodrik.typepad.com/dani_rodriks_weblog/2012/10/did-microsoft-steal-its-fonts-from-the-turkish-army.html <comment><USER2> The fabricated evidence in a show trial against Turkish Army officers was accepted as genuine by the kangaroo court. Forensic analysis by the defense which found references to the Calibri font, introduced with Windows Vista and used as the new default font of Office 2007, was ignored by the court. The circumstances of the case set up a logical dichotomy: either the evidence was forged in an attempt to frame the defendants, or the Turkish Army had possession of fonts in 2003 that were supposedly invented by Microsoft in 2004.

So if the answer to the question posed by the headline is "no" (as is implied), then the Turkish court did not provide fair and impartial justice. It is a _reductio ad absurdum_ argument against the guilt of the defendants.

</comment><comment><USER3> This is why, in spite of generally being happy that the recent coup attempt failed, I am deeply concerned about what happens next. Six thousand arrested within a day or so of the failed coup? When we don't even really know what happened, yet? Erdogan and company are using it as an excuse to clean house. No investigation has been done, and I fear nothing resembling justice will occur. Turkey, meanwhile, edges closer to a dictatorship.

</comment><comment><USER4> Terrible and misleading headline.

<comment><USER5> What would you suggest instead?

<comment><USER6> 'Evidence' for Turkish 2003 coup plan predates publication of used font.

Font metadata proves 2003 Turkish coup plan evidence was faked.

<comment><USER7> That would be a good subtitle:

Did Microsoft steal its fonts from the Turkish army?: Font metadata proves 2003 Turkish coup plan evidence was faked.</comment></comment></comment></comment>


Show HN: BitHubLab, Search for projects on all the major Git platforms - <AUTHOR> https://bithublab.org/ <comment><USER2> This is very cool. If you start to hit API rate limits for these services, you can try using the Sourcegraph API (email me email@example.com and I can make sure your API key isn't rate-limited). Sourcegraph indexes all of these Git platforms and has a search API: [https://about.sourcegraph.com/docs/features/api](https://about.sourcegraph.com/docs/features/api).

<comment><USER3> Does Sourcegraph not already have this feature? Do they plan to?

<comment><USER2> (Sourcegraph CEO here.) Yes, Sourcegraph does support this, with a caveat. You can query Sourcegraph for things like "repo:saml2" at [https://sourcegraph.com/search?q=repo%3Asaml2](https://sourcegraph.com/search?q=repo%3Asaml2) to find matching repositories. But currently we limit the number of matching repositories for interactive queries on Sourcegraph.com, so you need to use a sufficiently distinct query term.

This is because we built Sourcegraph for the more common code search use case: searching for text/regexp matches across all the code that matters to me (up to ~30k repositories). That's something that devs inside companies with large codebases do 5-20+ times per day.

As it turns out, searching across millions of open-source repositories is a less common use case (overall), only needed 0-3 times per week on average. We want to support this use case better, too, but it's not our priority based on what we've learned from devs.

Interestingly, some people look at Sourcegraph and say "I don't think code search is very useful" because they are thinking of the open-source code search use case. Anyone who's worked at Google/Facebook or a company that has Sourcegraph/OpenGrok/Hound/etc. understands that code search is super valuable. It is amazing to be able to search across all the code that matters to you in 1.5 seconds with a single hotkey (for me, it's alt-tab to Chrome, ctrl+L, src<TAB>, because I'm using our browser extension: [https://about.sourcegraph.com/docs/features/browser- extensio...](https://about.sourcegraph.com/docs/features/browser-extension)).

</comment></comment></comment><comment><USER4> Mildly annoying nitpick:

The name is BitHubLab (Bitbucket, Github, Gitlab) yet the checkboxes in the bottom are in Github - Gitlab - Bitbucket order.

As if the name is HubLabBit rather than BitHubLab

</comment><comment><USER5> I love the logo. Beware those platforms might go after you for trademark violation.

(I'd personally argue you're making a joke and it should be protected under parody, but no one ever actually wants to go on a legal fight over a logo).

Really good concept though. Good work.

</comment><comment><USER6> This is really neat, and as the GitHub acquisition moves forward, I suspect a lot of Microsoft's competitors will move elsewhere, so this will be handy.

What about self-hosting though? If you run your own GitLab, how would you get listed on your search engine? Is that something you've looked at?

<comment><USER7> My thought exactly. For something that can easily be self-hosted, I feel a focus on a handful of "major platforms" is the wrong approach. Already people in this thread are saying that smaller well-known instances are "not major enough" which I disagree with.

</comment></comment><comment><USER8> Other than Github's icon, I had no idea what the icons for the other check boxes were. I figured it out, but I would recommend using the name rather than icon especially since the names aren't long. I also recommend to start with them all checked by default then let people filter later.

<comment><USER9> At very least, give the images titles, so when you hover you get a nice tooltip. Also, give them alts so I can still tell which is which if I'm using a browser without images.

</comment></comment><comment><USER10> Haha! Love the logo!

In terms of use: the search results seem good when searching a specific thing, but results can be a bit less useful when searching something generic like "python directory utility".

I'm not sure I can see myself using this over Google or the package ecosystems for the various languages and frameworks I use

PS: in isakkeyten's comment the implied name based on order of checkboxes is "HubLabBit", which I actually like better as a name as it rolls off the tongue a little better IMO.

</comment><comment><USER11> [https://i.imgur.com/OpHwOvU.png](https://i.imgur.com/OpHwOvU.png)

The checkboxes are pixelated (this is FF) and rather hard to distinguish from the logos. Oddly, at first, I was looking at the logos from right to left and I was confused what the last and third to last logos were, hah.

It would be cool if the logos themselves were the checkboxes, with a darker version for checked and lightened version for unchecked (and all should be checked by default).

<comment><USER12> Yeah, looks odd in FF with GTK too[0]. Not pixelated, but weirdly scaled none the less.

[0] [https://screenshots.firefox.com/xZsGtZme1muvymp8/bithublab.o...](https://screenshots.firefox.com/xZsGtZme1muvymp8/bithublab.org)

<comment><USER13> Same on FF Windows.

[https://screenshots.firefox.com/Ia3sklj6tRlO6kgP/bithublab.o...](https://screenshots.firefox.com/Ia3sklj6tRlO6kgP/bithublab.org)

</comment></comment></comment><comment><USER14> > on all the major Git platforms

missing notabug.org and savannah

<comment><USER15> those are not major git platforms

<comment><USER14> well there are thousands of users and repositories instead of millions, but I think they are still relevant.

</comment></comment></comment><comment><USER16> Just wondering why BitBucket option isn't enabled by default?

<comment><USER17> Yeah, that threw me for a loop. I searched for one of my repos on BitBucket and was left scratching my head until I saw the (bizarre-looking) unchecked checkbox. At the very least, it should be made more clear that BitBucket isn't being searched by default...particularly since it's the first name in the portmanteau!

</comment></comment><comment><USER18> Awesome stuff! Great timing too. Code Search is super useful and there are a bunch of folks already going after this space. Sourcegraph, CodePilot.ai, Searchcode.com, and many more! Happy to see something so light and elegant for the use case. Good work!

<comment><AUTHOR> Thanks, it's a simple layer on top of the existing APIs and search interfaces so it's not nearly as feature complete as those other services(that would require actually crawling and indexing). I made it just for fun but who knows, might be worth expanding on.

<comment><USER19> What's the front end? I've been thinking of building something similar, but I'm bad at front-end tech.

<comment><AUTHOR> The frontend is reactjs. Very simple.

</comment></comment></comment></comment><comment><USER20> Oh this is just what I was looking for! It would be cool to have a "GitHub" like interface that shows you repos from gitea, gogs, basically anywhere there's a hosted repo on the internet, not just from a centralized git hosting website

</comment><comment><USER21> nice tool, nice timing, might be useful with all the moving projects. pls consider adding the title attribute to the images for screen readers and users who don't know the logos.

<comment><AUTHOR> Noted, thanks for pointing that out I hadn't thought of the accessibility element.

</comment></comment><comment><USER22> Slightly tangent, I really hope these kind of things enable us to do more with code already written:

* Like I should be able to query based on signature of the function rather than just banking on its name.

* I want to see how different projects use this particular package- what are its most used methods; how any of its types are constructed.

* What are the best practices for using a particular package etc

</comment><comment><USER23> The checkboxes under the search bar does not look like checkboxes but a series of logos of platforms. I was left wondering what ticked boxes meant.

Cool project.

</comment><comment><USER24> Something for the backlog: I enjoy the explore/discovery feature of GitHub - aggregating that into one site would be great.

</comment><comment><USER25> I wonder if it's possible to automaticaly have a mirror of my GitHub repositories to GitLab, or GitBucket.

<comment><USER26> Gitlab has mirroring as an option.

</comment></comment><comment><USER27> > You need to enable JavaScript to run this app.

Sigh.

</comment><comment><USER28> Very nice. Maybe you should include stars and last commit date in the search results, or even as filters.

</comment><comment><USER29> Has a typo: "repisitories"

Also, didn't found one of my repositories hosted publicly on github since years.

</comment><comment><USER30> > You need to enable JavaScript to run this app.

Okay, it's a first iteration, but this would be ideal to provide some functioning homepage and otherwise potentially do server-side stuff and not require client-side JavaScript just to see text and HTML forms and submit them.

</comment><comment><USER31> Right on the day that Microsoft acquires Gitlab :-)

<comment><USER32> It is not coincidence. The page has been created today!

<comment><AUTHOR> Yeah I made this in reaction to the news. Glad I got it together quickly!

</comment></comment></comment><comment><USER33> Needs more ChiselApp ! ;-)</comment>


Having smart people in groups doesn't necessarily make groups smart - <AUTHOR> http://www.psychologytoday.com/print/50075

<comment><USER2> Business management was my major in college. Management science revolves around this type of thing.

All you really need to remember is that "a group is not a team". You can put people in groups all you want, but that does not mean they act as a team.

Groups result in each member behaving more effectively and efficiently, but the sum of their work is not much, if at all, greater than their individual productivity.

Teams, on the other hand, have a synergy that result in a much greater performance (outputs) as a team than each member inputs individually.</comment>


Digital Twins Are Reinventing Innovation - <AUTHOR> https://sloanreview.mit.edu/article/how-digital-twins-are-reinventing-innovation/ <comment><USER2> "Reinventing Innovation" is an absurdly vacuous phrase.

<comment><USER3> We need to innovate on reinvention.

</comment></comment><comment><USER4> Disclosure: My company, Pathmind, works in a space adjacent to digital twins.

Digital twins are an interesting idea that, like "cognitive computing", is easily abused by marketing, and will probably rake in a lot of consulting fees for people like the authors of this piece (Accenture Research) and companies like IBM.

The essence of a digital twin is a simulation complex enough to be useful in making predictions in the real world. (That's the "twin" part.) Making complex simulations, as you might imagine, is difficult. It requires effort, deep domain knowledge (rare talent), good feedback mechanisms with the real situation in question, and some means of managing that complexity.

Digital twins do exist in deployment. What differentiates them from, say, any old machine-learning model you might use for predictions is that a "digital twin" is probably used for a more complex task than just classification. That is, it's probably used to direct the actions of a system. The words imply a larger solution.

So one thing you see is simulations that embed machine-learning models and predict what actions to take in a given state. Think of it like AlphaGo applied to business scenarios.

What are the pitfalls? Real-world data in these environments is non-stationary and messy, so signal may be low, or the ways you find signal might change over time.

To make the "digital twin" useful you are probably integrating with large software systems not entirely in your control, which may be hard to reason about (ERP systems like SAP).

The digital twin idea, insofar as it includes large parametric models that depend on algorithms like deep reinforcement learning, matters now, because those models are able to find structure in complexity, and make ever more accurate predictions about what to do. That is, we're able to identify optimal actions in more complex situations, with techniques more sophisticated than expert systems.

All that aside, this sort of thing is already getting deployed under the right circumstances, and you could argue that it is the future of a lot of business operations in supply chain and manufacturing.

<comment><USER5> Very interesting. Do you have a sense of which businesses are working in digital twinning successfully?

<comment><USER4> We see it up and down the supply chain, from manufacturing to warehouses to transport nodes.

<comment><USER5> Cool! What companies do the twinning? Is it handled in-house by the companies applying it or are they partnering with specialists?

<comment><USER6> Companies like GE, SAP, Mathworks, Dassault, PTC and Siemens all have digital twin platforms used by major manufacturers. Initially there was a period (2003 -2013) where twin systems were built my specialist media developers using 3rd party authoring tools and integrating with different system simulation tools. While this still happens for specialist or niche projects (or sometimes on very large projects with specific deadlines that require outsourced help). Increasingly most manufacturers build digital twins directy from design assets (CAD, CAM, Systems simulations etc) as part of the in-house product development process using extensions to their existing design and simulation tooling.

<comment><USER4> @ptrott2017 - i'd love to speak with you about this. please ping me at chris at pathmind dot com if you're open to a conversation.

</comment></comment></comment></comment></comment></comment><comment><USER7> I believe Digital Twin was crowned buzzword of the 2019 by Gartner

<comment><USER8> I thought the article would be about the Winklevoss brothers.

</comment></comment><comment><USER9> In the era of "all digital", one must be very careful to make the future anew, not a copy of the past.

Our models of system are only a pale reproduction of how those systems work, rendering designs that are tuned by those "evil twins" bound by our current understanding of the system which can be lacking sometimes.

Nevertheless, in engineering, notably aerospace for example, those digital twins are crucial to make better parts, as thrusters for example, do not allow for continuous measurements of temperature (everything burns there).

It rendered hardware system design far more agile.

Yet the concepts to build a novel hardware is not encoded in this simulation.

Another example of "future is past, repeated" is machine learning. Carrying encoded stereotypes in predictions.

As we try to model everything with some notable failures, such as economy, let's just be aware of the limitations of those models.

</comment><comment><USER10> Interesting that the authors don't mention the book Mirror Worlds ([https://en.wikipedia.org/wiki/Mirror_world](https://en.wikipedia.org/wiki/Mirror_world)), but the last line of the article does make an allusion to it.

</comment><comment><USER3> It's called a cookie.

[https://black-mirror.fandom.com/wiki/Cookie](https://black- mirror.fandom.com/wiki/Cookie)

</comment><comment><USER11> Interesting take. I think it's hard for some companies to imagine how transformative the technology can be. This is a good starting point.</comment>


Car detection algorithm - <AUTHOR> https://github.com/hjptriplebee/car_detection_counting <comment><USER2> If it meets the guidelines, this might make a good 'Show HN'. Show HN guidelines: [https://news.ycombinator.com/showhn.html](https://news.ycombinator.com/showhn.html)</comment>


Does Free Software cost jobs? - <AUTHOR> http://blogs.computerworlduk.com/spannermans-edublog/2011/11/does-free-software-cost-jobs/index.htm

<comment><USER2> Hopefully, else it probably isn't benefitting the economy.

The industrial revolution killed millions of jobs by creating technology that made the jobs uncompetitive. No point in paying a person to push a cart of coal when you could have a steam engine do that.

That said the industrial revolution created millions of jobs by creating technology that required new jobs. No point in paying a person to design steam engines if no one uses steam engines.

The key to the economy is balance between production and consumption. By the time Henry Ford rolled around enough improvements to the production side had been made that we needed a 5 day 8 hour work week so that we'd have a chance to consume all the good we were producing.

My personal sentiments are that we need to rethink the work week in order to increase consumption and provide balance to the massive amount of goods and services we're now producing.</comment>


Show HN: VHDL pseudo random generator tutorial (three parts) - <AUTHOR> http://www.fpgasite.net/2016/08/09/pseudo-random-generator-tutorial/ <comment><USER2> For some reason I am redirected to [http://www.fpgasite.net/wp-admin/setup- config.php](http://www.fpgasite.net/wp-admin/setup-config.php) (even when visiting the root).

<comment><AUTHOR> Hi,

I was in the middle of putting my FPGA site in its own domain (fpgasite.net). Previously it was on a free domain from Wordpress.

I had some difficulties during the transition. It should be OK now. Thanks for letting me know, I hope you won't have any issues accessing the site now.</comment></comment>


Ask HN:  Is this idea any good? - <AUTHOR>

I don't have a blog or anything, so I'll just ask it here.
The idea is "Earth Food."  It's essentially a packet of dirt.  But it's marketed as "a specific blend of nitrates, soil, microbes, and seeds meant to nourish the planet."  Kind of a fun gimmicky gift you give to someone "green"... a bag of dirt that they can throw on the ground anywhere they want.  The wrapping is that "plastic made out of corn" stuff, so the whole thing is 100% biodegradable!  ...also available in larger sizes.
I just like the concept of selling dirt.  I really think it could work.  Bobbleheads make money, and they're not:  1) green.  2) cheap as dirt to product and 3) funny.
What do you guys think of this marketing hack? <comment><USER2> How is removing dirt, that is capable of sustaining life in its present form, and using resources to package it, using fuels to potentially ship it, and displacing it to probably a landfill (people will probably throw them out once the novelty wears off) green by any stretch of the imagination? Also using corn (which can be either food or fuel) and tying it up with a gag gift isn't very green.

<comment><AUTHOR> Because it's greener than buying some other gift. It's greener than most things you could buy. But, anyway, it's not really a "green product" so much as "to be marketed as green."

I personally think the whole green thing is ridiculous. People just need to stop making more people.

</comment></comment><comment><USER3> Err, I find it odd. If I received a packet of dirt from a friend I would be amused, but it would probably end pouring it all over his head. Just kidding... or not.

But, if I had to choose a green gift it would rather be a baby tree or seeds to plant. So maybe you can add these to your dirt packages for a small fee ;)

<comment><AUTHOR> Ah... how about this twist:

Now with seeds! Everybody loves seeds! Basically you take the pouch and toss it somewhere and see what you get.

<comment><USER3> Well, how about, a pack of dirt with mystery seeds. What will you get?

I think this would be more attractive as a gift (as long as the chosen plants are nice) than just the dirt. I would include general instructions on how to take care of the plant (so the seeds manage to grow) without saying what plant or flower it is. A nice surprise for your green friends :)

<comment><AUTHOR> I like this idea... that's what I was getting at, only worded poorly.

</comment></comment></comment></comment><comment><USER4> Wildflower propagators make small golf-ball sized balls of dirt with native flower seeds in them, to be tossed into empty lots and other likely places. The idea is that the seed is protected until rain melts the dirtball, and then it can sprout and has a starting batch of nutrient right there.

You could probably sell those, and work some gimicky advertising off the "dirtball" name. You could probably get some wildflower propagators to make them for you for free, if you gave back to their organization from each sale.

</comment><comment><USER5> No, I doubt this could ever be a real business. Even if it catches on, you'd have to sell millions of these dirt packets to ever make any money. There was a thread on HN about a condom key chain business that failed for this reason. Even though they sold thousands of them, it doesn't add up to much when you only make a few pennies per unit.

</comment><comment><USER6> Cute idea, but it sounds like a nasty way of introducing non-native microbes and insects to new places and would likely do far more long-term harm than good.

</comment><comment><USER7> Maybe you could sell them to vacuum salesmen.

<comment><AUTHOR> I lolled

</comment></comment><comment><USER8> Would you be satisfied if it was only as successful as the Pet Rock?

</comment><comment><USER9> My pet rock was getting hungry!

</comment><comment><USER10> i would be highly surprised if it didn't already exist

<comment><USER11> always a good sign.

My suggestion is to go for it - whats the worst that could happen?</comment></comment>


Ask HN: What do you use to clean text data for ML/DL? - <AUTHOR> <comment><USER2> I guess you mean preparing CSV files for another format, in order to load it in some ML code?

Vim. It can easily handle large multi gigabyte text files.

For batching: head, tail, awk, grep -- the good old command line gems. They have hardly been beaten in speed.

If you mean "clean" in terms of some standarization (thinking of natural language recognition), I hardly can imagine there is a single tool which covers all use cases...</comment>


Old Line Banker Puts $1 Million Into P2P Lender Prosper  - <AUTHOR> http://www.techcrunch.com/2009/11/10/old-line-banker-puts-1-million-into-p2p-lender-prosper/ <comment><USER2> That's pretty interesting that he'd put his money into Prosper rather than Lending Club (lendingclub.com). Maybe as a company it's currently more profitable, but for investors (ie. people making the P2P loans), its far more risky than lending club.

I just started up using lending club, and I chose it over prosper because of lending club's more rigorous screening process for who can obtain loans (must have a 660 credit score to qualify for even the lowest grade loans). As such, lending club loans have a far lower default rate across the board (Prosper indicates a >20% charge-off rate -- that's 20% of loans becoming unrecoverable losses. Lending club has a year-to-year default rate of only ~5% for even its lowest-grade loans).

Anyone else doing P2P lending?</comment>


Why Generics? - <AUTHOR> https://blog.golang.org/why-generics <comment><USER3> Maybe this is unfair, but it'd be great if the Go devs could just say "generics will work similarly to [C# / Java / Swift / D / whatever], except that we'll address [problems] with [adjustments]".

Rather than going through this whole rigmarole of resisting adding generics too early because all existing implementations are bad, then slowly reinventing the wheel from scratch, then finally ending up with something pretty similar to one of those other languages anyway.

It's OK not to make something completely new and different. It'd be useful to explicitly say which language(s) you're borrowing from because you can then more clearly call out the differences and explain the reasons for them.

<comment><USER4> > because all existing implementations are bad

I'm also not sure why in OOP-land, generics are this crazy experimental weird feature, when in functional languages, people figured out how to implement parametric polymorphism (the original term for generics) in quite reasonable ways. I get that subtyping adds some complexity, but overall I don't understand why such a basic way to build abstractions is so controversial in (some) OOP languages. If anyone has some context on why this is more difficult to have in Java-like languages, I'd be curious to hear it.

<comment><USER5> Inheritance makes generics difficult.

For instance, if A < B (B extends A), What is the relationship betwern Array[A] and Array[B]?

If you are just reading the array, you would want Array[A] < Array[B]. If you are writing to the array, you would want Array[B]<Array[A]. If you are doing both, you want Array[A] to have no relation to Array[B].

This problem doesn't come up in ML style languages because they do not make use of inheritence.

<comment><USER6> It comes up in Scala. The solution is to have notation to specify the variance of types.

<comment><USER7> I think it is Gilad Bracha that said, when the decision was made to include only covariance in Dart, that variance flies in the face of programmer's intuition.

He's right. It's easy to understand one level of variance: you can replace a return type by a subtype and a parameter type by a supertype. (I wouldn't be surprised that many programmer don't undestand this.)

Two levels already requires some deep thinking (assuming definition-site variance: `List<Object>` or `List<String>` as a return type / parameter type, was is allowed to replace it?

More than that? (`List<List<String>>`) Hahaha, good luck.

And by the way, Java has notations to specify the variance of type, but only at the use-site, which is different from doing it at the definition site (both enable expressing things the other can't do... but you can actually have both, as I think is the case in Kotlin, though there are some limitations).

<comment><USER8> I'm not really sure what you mean. Variance just changes what is and is not a subtype/supertype. If List is covariant then List<T> is a subtype of List<U> if T is a subtype of U. So then, by induction, List<List<T>> is a subtype of List<List<U>> if T is a subtype of U. I'm not sure what's hilariously hard to follow here...

<comment><USER7> Good point, it's a bad example because we assume we're just combining covariance which is intuitive.

Nevertheless, I have a point because:

1\. Things get harder with contravariance. 2\. Things get harder when you mix covariance and contravariance.

The prototypical covariance class is Producer<T> (with method produce() returning T) while for contravariance that's Consumer<T> (with method consume taking a T as parameter).

Assume each class has a superclass (Consumer0<T> and Producer0<T>) and a subclass (Consumer2<T> and Producer2<T>). Assume V extends U extends T.

Can you list the subclasses and superclasses of Consumer<Producer<U>>?

Personally, I have to think carefully about this for a minute or so, and I've been there before a couple times.

This is not an especially complex scenario either. I've seen things get worse in practice.

<comment><USER8> Ah, I can figure it out pretty easily for that example too but probably only because I am pretty familiar with variance and you chose really generous names. I personally find the reasoning about variance becomes a lot easier if you stop thinking about the definitions and start thinking about what you should be able to do. A producer of a subtype is technically also producing the supertype. A consumer of a supertype can totally consume the subtype.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER9> Generics with Reflection was the first gut check I experienced while working after completing college and getting an ASP.NET job. Like 2-3 weeks into said job.

Had to do an application that dealt with 4-5 forms (can't remember). Like 300 fields on the bigger ones, smaller ones 50ish. I started out on one that was mid-200. I'm coding the way I was taught in school: object set object properties based on txtWhatever.Text. Like 240ish times. I can't remember how many lines of code were in this code behind, but it was substantial.

I turn it in, it works. Go me, let me go on to the next one. The senior guy on the team does one of the smaller forms. But he uses generics and reflection to basically iterate over all of the fields on the form and sets them to the ephemeral properties on this generic object in like 8-9 lines of code. Then there was the rendering code that was vaguely similar.

Added bonus: 99% of his code behind could be copy and pasted over to the newer forms and handle all of the work related to getting/setting form values. After the code proved to work for a few weeks, replaced the massive code behind with call to his code (passing in the form object and the generic to be set and used later) with the same result and one area to manage code and it isn't an insanely large code behind file (got better with not one filing everything in time too).

Not saying generics and/or reflection are a silver bullet (I don't feel they are. Rarely so do they end up being the thing I go for), but it was definitely eye opening that straying from "see spot run" code could be advantageous. And that I wasn't "good to go" already.

</comment><comment><USER10> Chiming in here as a Swift dev - I find its generics system incredibly helpful and end up writing something that uses generics about once a month. To those Go programmers who think they will never use them - it's worth a little learning, and once you do you will find more ways to use them to make your code more applicable.

<comment><USER11> Chiming in as a fervent Go dev that's also a huge fan of generics: Generics are awesome, but always seem to add a ton of complexity. Everyone starts with just "oh, `func Reverse(slice []T)` is so obvious" kind of thing, but that's like saying `fmt.Println("Hello World")` is simple. It's simple cause you are doing a simple thing.

That said, I do want generics to come to Go, just... with an emphasis on what Go is, not just "here, let's replicate X's generics in Go". I am interested in the contracts implementation.

<comment><USER12> > Generics are awesome, but always seem to add a ton of complexity

The team I work in use generics all the time and I'm not sure what complexity you are referring to. Care to elaborate? Is it some edge cases or are you talking about from a compiler perspective or something else?

To me, not having generics is like saying let's skip handling bools and just store them in strings as "true" or "false". It's such a weird thing from my point of view.

<comment><USER11> Compiler perspective (fast compiles are a core part of Go, IMO), various tradeoffs(fast compile? fast runtime? binary size? Pick 1 or 2), and seeing code bases that get out of control with generics and such.

Note that, for all of that, I'm still in favor of adding generics in Go, as I do see the value they can add. I'm just pointing out that "bashing" on Go devs on not knowing what generics are or how they can be useful is both non- productive and probably generally wrong. Plenty of us are saying "Man, if I had generics, this would have been less code/cleaner/more reusable!", just the other various tradeoffs outweigh the actual cost of using a different language. Go's ability to drop a very junior dev (or just one that has never use Go) into a codebase and have them be almost immediately productive is incredible.

<comment><USER13> > various tradeoffs(fast compile? fast runtime? binary size? Pick 1 or 2)

Interfaces are boxed already, so you've paid the price without having type safety. Simply treat a polymorphic function as if it accepted interface{}.

</comment></comment></comment></comment></comment><comment><USER14> The decision to overload parentheses to express generic type is the only part of this spec I find nauseating. It doesn't scan well, and doesn't have a precedent in any major generic implementation I'm aware of. <, [, @-annotation... I don't care. Just don't mush it into the function declaration with the same syntax that encloses parameter.

<comment><USER15> Agreed, specifically it creates ambiguities in parsing (for computers but worse: for humans). Given Foo(x), you can't tell if it's a function call or a generic type without knowing what x refers to. You need context from afar to disambiguate.

<comment><USER16> You can tell if it's a function call or a generic type based on where it is used; the local context. Function calls are either statements or expressions. Types appear in declarations.

<comment><USER17>
        a := Bar(baz)(buzz)

Is Bar a `func(some) func(thing) other` or is it a `func(type T)(some) other`? You need to know what "baz" is to be able to tell.

<comment><USER18> Yeah, it's ambiguous, but be realistic: how often are you calling a function with a function return _just_ to invoke that directly?

You usually won't see much of either sinice the type argument is only necessary when it can't be inferred.

<comment><USER19> In Haskell this happens every time you call a function with two or more arguments.

</comment></comment></comment></comment></comment></comment><comment><USER20> That time of week to rehash all the Go Generics comments!

[https://hn.algolia.com/?query=generics&sort=byPopularity&pre...](https://hn.algolia.com/?query=generics&sort=byPopularity&prefix&page=0&dateRange=all&type=story)

<comment><USER21> sort by date: [https://hn.algolia.com/?query=generics&sort=byDate&prefix&pa...](https://hn.algolia.com/?query=generics&sort=byDate&prefix&page=0&dateRange=all&type=story)

</comment></comment><comment><USER22>
        Go 3: Why HKT?
        Go 4: Why homoiconicity?
        Go 5: Why uniqueness and borrowing?

<comment><USER23> What is HKT?

<comment><USER24> I'll give the 'why' rather than the 'what'. In most mainstream languages you take a List<Int> and substitute for List<X> without changing the implementation of List. But there's another substitution you could have made, which is L<Int>. HKT allows you to parametrise L over Int, in the same way you were able to parametrise List over Int.

<comment><USER25> Thanks for the practical, plain English definition. As someone many years out of school, it is appreciated.

</comment></comment></comment></comment><comment><USER26> Personally, I prefer the current interfaces-based solution to generics. It's a little verbose, but keeps the language simple.

However, I think that the people we should be listening most are the ones developing huge projects in Go, like Kubernetes. Would having generics with this new contracts thing make it easier to develop and maintain e.g. Kubernetes? I'm truly curious.

<comment><USER27> Kubernetes is a transpiled Java project, so yeah, Java-like features would definitely make it easier :P

I think idiomatic golang works pretty well without generics in most cases, the big problem for me is that functional programming is essentially impossible without them.

<comment><USER28> Can you provide some resources on what makes you think Kubernetes is a transpiled Java project?

That's definitely not the case from what I know/understand...

<comment><USER29> There is a talk about it you can find here: [https://fosdem.org/2019/schedule/event/kubernetesclusterfuck...](https://fosdem.org/2019/schedule/event/kubernetesclusterfuck/)

</comment></comment></comment></comment><comment><USER30> Generics and interfaces go hand in hand IMO, especially in an application with heavy emphasis on data persistence. This way you can compose a class of some interfaces, pass it to a persistence layer (using a generic constraint of something common to all inputs of that layer), and then the persistence layer can check for all the interface types it cares about saving and pass those pieces off to whatever lower-level piece of code handles that one thing.

Generics enable you to avoid having 10 slightly different implementations of the same thing (even if dependencies are shared, you're still going to have 10 copies of plumbing without generics). Being wise about when and when NOT to use generics is to me the most important factor.

In our shop we tend to not introduce a new generic class/method until something gets painful (unless it's plainly obvious from the beginning). Because of this we usually begin to notice and reason about patterns in our code that seem common enough to warrant refactoring and whether the complexity of a generic implementation would be worth lowering the maintenance burden of copy/pasting said pattern all over the place. It's a case by case decision.

Having generics available at least allows us to make that decision for ourselves.

</comment><comment><USER31> The examples I'd like to see worked out fully, which he mentions in passing, are encapsulation of concurrency patterns (parallelization, work queues, cancelling, etc.). It's not that big a deal to write Max as a function or even inline, whereas there are serious practical pitfalls and common mistakes when doing real work with channels. It would be a lot more effective to fix these by writing library code rather than writing Gophercon presentations.

</comment><comment><USER32> Why generics, indeed?

There must be an answer to this, but I've never seen a good response to why they aren't implementing parametric types and (single-parameter) typeclasses instead.

Simplicity? Yes, but generics are hardly any simpler.

<comment><USER33> For me, generics make api designer's life harder, but api user's life easier. A good enough reason for me.

</comment></comment><comment><USER34> It might be fun to share my viewpoint from an angle that's probably fairly unique.

I've started a number of large, highly deployed Go projects: Terraform, Vault, Packer, Consul, Nomad, and numerous libraries and other things. I started a company that employs hundreds of full time Go developers. Go has been one of our primary languages since Go 1.0 (and I used it prior to that).

Let me start by saying that there are _definitely_ cases where generics are the right answer. Usually when I talk about generics people tend to assume I disagree with the whole concept of generics but I certainly do not. Generics are useful and solve real problems.

Adding this paragraph after I already wrote the rest: this whole comment ended up sounding super negative. I'm voicing concerns! But, I think that the design proposal is exciting and I am interested to see where it goes. There are definitely places generics would be helpful to us, so please don't take my negativity too strongly.

## Technical Impact

Having written these numerous large, complex systems, I believe there are less than 10 instances where generics would've been super helpful. There are hundreds of more times where it would've been kind of nice but probably didn't justify the complexity of implementation or understanding.

This latter part is what worries me. I've worked in environments that use a language with generics as a primary language. It's very easy to have an N=2 or N=3 case and jump to generics as the right way to abstract that duplication. In reality, the right answer here is probably to just copy and paste the code because the knowledge complexity of using generics (for both producer and consumer) doesn't justify it, in my opinion.

As a technical leader, I'm not sure how to wrestle with this. Its easy today because generics just don't exist so you have to find a way around it. But for a 150+-sized org of Go developers, how do we have guidelines around when to use generics? I don't know yet. I guess that bleeds into human impact so...

## Human Impact!

Something that is AMAZING about Go today is that you can hire a junior developer with no experience with Go nor any job history, have them read a few resources (Tour of Go, Go Spec, Effective Go), and have them committing meaningful changes to a Go project within a week.

I don't say this as a hypothetical, this has happened numerous times in practice at our company. We don't force or push any new hires to do this, but Go is so approachable that it just happens.

I love it! It's so cool to see the satisfaction of a new engineer making a change so quickly. I've been told its been really helpful for self-confidence and feeling like a valuable member of a team quickly.

The Go contract design document is about 1/3rd the word count of the entire Go language spec. It isn't a simple document to understand. I had to re-read a few sections to understand what was going on, and I've used languages with generics in a job-setting and have also been a "professional" Go dev for 9 years.

So what worries me about this is technical merits aside, what impact does this have on learning the language and making an impact on existing codebases quickly?

I really like what Ian said about attempting to put the burden of complexity on the _author_ using generics, and not the _consumer_ calling that function. I think that's an important design goal. I'm interested to see how that works out but I'm a bit pessimistic about it.

\---

I have other viewpoints on generics but those are the two primary ones that stand out to me when I think about this proposal going forward.

<comment><USER35> I see the use for generics _all the time_. I came from Ruby, where we have enumerable so you get standard constructs like map, find, first, last, each_cons, etc. Because Go lacks them, people constantly reimplement these things with less intention-revealed code using ad hoc for loops. Ugh.

Thus you see very little use of collection pipelining in Go. [https://martinfowler.com/articles/collection- pipeline/](https://martinfowler.com/articles/collection-pipeline/)

Generics are such a powerful and useful idea. Bring it on.

<comment><USER36> Your parent is quite familiar with Ruby. :)

</comment></comment></comment><comment><USER37> Mixed feelings about this. One of my favorite things about Go is that it's a small and relatively simple language. It's a "fast enough" language without the steep learning curve of Rust. Too many features that make sense individually could change the calculus to "might as well use Rust".

<comment><USER38> I'm not so sure about the "steep learning curve of Rust" stereotype anymore. If you are comfortable with low-level programming languages in general, in a few days you can get yourself started fairly quickly with Rust to the point where you will still battle with compiler re: borrowing and related things, but will be able to write functional code. Coming from pure Python/JS will be tough, but it will be the same with any other low-level language.

<comment><USER37> My work is a Ruby/JS shop, and we have some Go in production as well. We definitely need a little hand holding to ramp anybody new up on the Go codebases. In many cases our devs haven't used types, pointers or any equivalent of goroutines & channels. I've written just barely enough Rust to say there are even more concepts that would be new to my team.

Even with Go being comparitvely simpler, I could go either way on whether it was the right choice to add it to the stack.

<comment><USER39> > In many cases our devs haven't used types, pointers or any equivalent of > goroutines & channels.

How do you manage to get a job as a developer without having ever learned this stuff?

Are these people that are just self taught straight to javascript / ruby?

I mean, are CS course nowadays so bad that students come out of them without understanding things like type-theory, pointers etc

<comment><USER37> To be honest, this response feels a bit aggressive and dismissive to me.

Many of my coworkers (myself included) entered the profession through bootcamps. Others came up during the PHP/Wordpress to Ruby/Rails era of web development, and never had a reason to learn languages like C++ or Java. I don't think there's anything to make fun of, or apologize for in this scenario.

</comment></comment></comment></comment></comment><comment><USER40> I hope this doesn't happen. I love golang because it is simple and easy to read. Both will go away when generic programmer start to write unreadable meta-programming class which "you don't need to understand, just use them".

I admire golang devs for being opinionated and stand up for the core lines of their language so far.

I see generic as renouncing these principles.

<comment><USER41> This. If I really need generics I'll use a different language.

<comment><USER42> This reminds me the discussion about first version of iPhone how so many people were advocating why adding copy&paste functionality was a bad idea.

<comment><USER43> More like people were advocating against the shitty Copy&Paste phones used to have.

When it came out, it was possible to C&P pictures to emails and other fancy stuff that wasn't possible before.

<comment><USER42> I'm quite sure that was possible on android from the beginning.

</comment></comment></comment></comment></comment><comment><USER44> Go has generics. What it actually lacks is user-defined generics.

Which shows the absurdity of the situation. The fact that it has generics demonstrates that generics are a useful and important feature. And yet they think their provided generics cover every possible use-case of generics that you will reasonably need in to use in Go.

<comment><USER11> And yet, the core devs have never said they don't want generics, only they didn't want a poor implementation.

Also, there's a bit of hilarity about commenting this on a blog.golang.org where the first sentence is "This article is about what it would mean to add generics to Go, and why I think we should do it." being posted by a core Go dev....

</comment></comment><comment><USER45> Not certain I like that this is now valid Go:

        func Foo (type T) (t T) (t T, err error) { … }

Seems like an awful lot of parentheses in a single line!

It's a bit tricky to read, because 'generic function' here means something subtly different from what 'generic function' means in CLOS …

<comment><USER46> It's not more parentheses than in a method definition:

        func (a A) Foo(x int) (n int, err error) { … }

Also your line isn't formatted properly. It should be:

        func Foo(type T)(t T) (t T, err error) { … }

</comment></comment><comment><USER47> As a functional leaning programmer, I think it's striking that the resulting draft is essentially a curried function whose first parameter is the type!

        func Reverse (type Element) (s []Element) {
            first := 0
            last := len(s) - <USER2>
            for first < last {
                s[first], s[last] = s[last], s[first]
                first++
                last--
            }
        }

This is later called like:

        Reverse(int)(s)

Which if this were a curried function, would also be callable like:

        Reverse(int, s)

Now I wonder if facilities for currying functions might be a higher level addition that could result in the same thing (so long sa we can pass bare types, which is part of this change as well).

<comment><USER48> I hate to tell you, but you're on your way to dependent types.

</comment></comment><comment><USER49> I have two comments to make about this proposaL:

1\. The type should indicate a generic, not a new syntax. This is better because it is easier to parse for the human eye. For example:

      func Reverse(first _T, second _T)

2\. Since all of what generics are is a compile-time code generator, I suggest that Golang forces developers to explicitly list what types are using the generic:

      generics(Add) = {int, string, car, food}
      func Add(first _T, second _T)

This list can be added to, after importing the package:

      Import "thing"

      generics(thing.Add) += {stuff}

This makes code very explicit about its generic functions. It also allow readers to understand exactly where the function is used.

</comment><comment><USER50> If I'm understanding correctly, contracts are a way to implement compile time duck typing? If that's the case I think its a pretty neat twist on generics.

</comment><comment><USER51> One of the things I like most about this is that Ian includes the simple mistake in the first function. It's a bit humbling and acknowledges the fact that even the best of us often make trivial mistakes. It also helps make the point that even the simplest code needs a basic test and adds another argument in favor of generics on the premise of duplicating tests.

</comment><comment><USER52> I feel pretty good reading this. I like that you can write listMyType := List(MyType). I'm still a bit dubious about contracts; they're so similar to interfaces. If there was a way to derive or relate a contract to an interface that would help me.

</comment><comment><USER53> This process took way too long. I've already moved back to Python3 and am super happy with it. The truth is most software doesn't really need the performance benefit Golang offers and you can code up something in Python in at least half to a third of the time it would take in Golang. Aside from agility, there's one other benefit that imo matters a lot: reduced LoC. If there's one thing I've learned in my career, it's that you can never really have too few lines of code, provided it achieves the same result as a hypothetical more verbose alternative.

I will admit though that I miss Go's CSP implementation and error-handling convention. Maybe I'll come back to it in the future after they add generics and fix the dependency system.

<comment><USER48> Can I sell you some Pony: [https://www.ponylang.io/](https://www.ponylang.io/)

</comment></comment><comment><USER54> Such a succinct article. I wish journalists could explain things this well.

</comment><comment><USER55> I think another area of Go that could use improvements is a more portable standard library optimised for embedded and OS dev. A lot of people want to use Go as a "systems language" and do drivers etc. in it. But the standard library don't have good support for freestanding, or at least it's not a priority. C and Rust and other languages designed for usage in a non-hosted environment have very clear delineated areas of runtime that requires assembly, manual interfaces for IO/memory allocation etc. Go's runtime by default assumes the presence of an operating system.

<comment><USER56> "Go's runtime by default assumes the presence of an operating system."

It also assumes the existence of several megabytes of runtime and enough RAM to feasibly use GC, which if nothing else is probably a real mess when it comes to drivers.

What you probably need, rather than being a second-class citizen of the main Go language indefinitely, is a separate dialect that is close to Go, but can go its own way if it makes sense, like: [https://tinygo.org/](https://tinygo.org/)

<comment><USER55> There is nothing wrong with GC. There exist plenty of network stacks in production that are written entirely in Go (See Docker/Kubernetes et alia). There are also operating systems that have GCs, such as Oberon or the few C# OSes written by MSFT and others. As long as care is taken to isolate hard real-time requirements when needed, a GC is perfectly fine. There is a real advantage to Rust's style of explicitly marking no_std. After all, what's the point of using stuff like tinygo (other than for performance/resource reasons) if it cannot run most of the existing Go libraries?

</comment></comment></comment><comment><USER57> This looks as an strategy to keep people (and HN) talking about Go.

</comment><comment><USER58> why are people obsessed with simplicity? there's a quotation my Einstein that I like to keep in mind: "make things as simple as they can be but no simpler". the implication being that if you make things too simple then you actually break things. lack of generics makes for software that's actually more complex than it needs to be. Take for example Swift: lots of complex features (protocols, all manner of functional transformations, generics, enums, structs, iterators, objects with many method qualifiers, etc) but really nice and efficient to program in.

<comment><USER59> I have yet to find one practical application for generics in the apps I've built in Go.

<comment><USER58> That's because you write a particular kind of program. Notice that there are no good ORMs or numerical libraries. Both of these are use cases for generics. Of course it doesn't help that the go community is convinced that ORMs are evil (which is just posthoc rationalization for being unable to write one).

<comment><USER59> Developers think ORMs are evil because they've had horrible experiences with ORMs in general. I'm one of them. The only ORM that I enjoyed using was Dapper, and it's barely an ORM.

<comment><USER60> Dapper really is such a weird edge case. You still write all the sql, all it does is the conversion from a type to the input parameters and the returned rows into objects where the row names match the parameters of the class. Frankly I feel like that's the right way to build ORMs in all languages that have the facilities to manage it (and maybe those that don't you pass in a function pointer to do the dumping of rows into type for you)

<comment><USER61> The sqlx package is a similar Go wrapper around SQL. Very handy for scanning into structs.

</comment></comment></comment></comment></comment></comment><comment><USER48> " _This article is about what it would mean to add generics to Go, and why I think we should do it. I 'll also touch on an update to a possible design for adding generics to Go...._"

This is a situation where _who_ is making the proposal is more important than the proposal.

" _By Ian Lance Taylor_ "

Oh. Ok. I guess it's worth reading then...

</comment><comment><USER62> The proposed syntax feels like a caricature to me. That something like this could be easily possible:

        func (c Connection) Read(type T Writeable)(into *T) (int, error) {

This is quite securely inside shark-jumping territory.

Also; I haven't seen Rob Pike's name really anywhere in these blog posts or discussions, or on any recent Go blog entry. Is he still involved with the Go project day-to-day? I always got the impression that he was one of the bigger anti-generics voices on the team internally.

<comment><USER63> As far as I can tell, the latest proposal draft forbids type parameterized methods. One must admit the type parameter to the receiver or define a type parameterized function. I am making no claims about your broader point, only clarifying that your example is not permitted by the proposal draft. See [https://go.googlesource.com/proposal/+/4a54a00950b56dd009648...](https://go.googlesource.com/proposal/+/4a54a00950b56dd0096482d0edae46969d7432a6/design/go2draft- contracts.md#methods-may-not-take-additional-type-arguments)

</comment></comment><comment><USER64> I do not think generics should be added to Go. It does minimalism and it does it tolerably well. Yet I enjoy using generics in other programming languages. If I had my druthers I'd be in Haskell-land in more than my spare time.

Hence, my modest proposal: Add generics, but make it a brand-new programming language with a totally different name.

Sadly, the name Blub is already taken. I propose we call it Glop. Or perhaps: Gong.</comment>


Tell HN: Reddit Is Down - <AUTHOR> Noticed it just now - earlier thought it might be a sudden block, but IIDRN (https://www.isitdownrightnow.com/reddit.com.html) shows Reddit as being down for ~25 minutes. <comment><USER2> It's standard maintenance: [https://twitter.com/redditstatus/status/1131439761627893761](https://twitter.com/redditstatus/status/1131439761627893761)

<comment><AUTHOR> Was thinking on the same lines, thanks for the confirmation.

</comment></comment><comment><USER3> You'd be surprised how often it happens... to work</comment>


Ask HN: GitHub or Gitlab - <AUTHOR> Migrating from an existing Git provider, curious what other folks have to say.<p>We're a building a SaaS app with no open source components at the moment. <comment><USER2> We currently use Bitbucket (do not recommend) and we're evaluating GitLab.

First impression is that it's a great package. The only downside for us is that we have a lot of legacy baggage, mostly rather opinionated build tools set up the way we liked it. Getting that to work with GitLab, which itself has a very opinionated view of the CI/CD pipeline is a bit of effort. But for a greenfield project I would go with GitLab in a second!

GitLab is a "batteries included" kind of tool. They've put together a lot of excellent stuff and integrated different tools very well together. For example, we need to perform security scans on our code and artifacts and GitLab offers that with minimal effort and awesome integrations into your pull request (which they call merge requests) mechanism.

Some may not like their approach, especially if they already have something that doesn't quite fit. But if you're starting from scratch, you really should give them a chance. They really know what they're doing ;-)

<comment><USER3> GitLab Community Advocate here. Thanks for the feedback, I am happy to hear that you like our product. Since you are still evaulating GitLab, please let me know if you need any assistance or help regarding other features.

<comment><USER2> Thanks. Your support department has been quite active in responding to the issues I've had. But thanks for reaching out :)

</comment></comment></comment><comment><USER4> I have been enjoying Gitlab's built-in continuous integration service. If your app does not already use something else for continuous integration, it might be worthwhile to try out.

</comment><comment><USER5> Gitlab all the way, as others have mentioned the CI pipeline is easy to setup. Another feature which is great is the Docker registry at the repository level.

</comment><comment><USER6> @GitLab Way too cool than GH, no need for separate special branch for html publishing, free private repos.

<comment><USER7> GitLab is great but I believe it depends on the need of the project, here are a few examples of the things that might an issue

On GitLab CE, you don't have the possibility to see the history of edited comments.

Indeed, if you need to manage a community or even to simply have full traceability, this is an important feature that is missing.

Furthermore, the ability to approve an MR is something that I miss using GitLab.

<comment><USER2> GitLab has the ability to require merge requests

<comment><USER7> The ability to require, not to approve if I'm not mistaken.

</comment></comment></comment></comment><comment><USER8> [https://gitee.com](https://gitee.com)

<comment><USER9> Everything is copied from GitHub down to the icons. Also, badly copied.</comment></comment>


Clojure Conj Reading List - <AUTHOR> http://sigusr2.net/2010/Oct/24/clojure-conj-reading-list.html <comment><USER2> How to Solve It: A New Aspect of Mathematical Method is a really good book. It was suggested to me by the best high school prof I ever had.

Other awesome books this teacher suggested were: Infinity Beyond the beyond the beyond, The Education of T.C. Mits and The Einstein Theory of Relativity: A Trip to the Fourth Dimension, all written by Lilian Lieber and illustrated by her husband Hugh Gray Lieber. These books were just reprinted recently go check them out.

<comment><USER3> Yes, How to Solve It is great. It is worth a re-read every year or so since it provides a baseline framework for thinking about things clearly.

</comment></comment><comment><USER4> I read "How to Solve it by Computer" by R G Dromey, which is based on Polya's book is excellent too. Solving HTSIBC problems in Clojure may teach one a lot of Clojure IMHO.</comment>


Ask HN: What does the cutting edge of AI-chatbots look like as of Oct 2017? - <AUTHOR> What does the cutting edge look like in conversation with a human?
What progress might we expect over the next few years?
I'm wondering how far are we away from chatbots that can serve as equally engaging over text as real friends (https://replika.ai/) or as equally effective as therapists (https://x2.ai/). <comment><USER2> There are two threads I am thinking of in response to your question.

One of them is "chatbots aimed at helping people with some utilitarian way in a particular domain" where I think the interesting thing is being able to ask good questions.

Imagine a nutrition tracking application where you take a picture of some food. If you took a picture of a burrito it cannot see what is inside. If you force people to fill out a detailed form, you won't get compliance. If you can ask people one or two chosen questions you can shrink the error bars on the nutrition parameters.

The other one, which you seem to be interested in, is chatbots that play an emotional role and for that I think you should look at video game characters, particularly in the "visual novel" genre and video games that incorporate a "visual novel" element such as this series

[https://www.youtube.com/watch?v=BjhgDvbmK5k](https://www.youtube.com/watch?v=BjhgDvbmK5k)

The long and short of it is that this kind of game can get you into intense emotional relationships with characters and sometimes when you get the "bad ending" you might be depressed by it for a day or two. I like the VR angle because characters like that could be "too close" or "too far away" for comfort.</comment>


Ask HN: What is the best open-source microblogging platform? - <AUTHOR>

For any startup in the microblogging field <comment><USER2> Not sure if it is the best, but here's tent.io. <https://github.com/tent/tent.io>

</comment><comment><USER3> One of the architects of Tent (<https://tent.io>) here. Happy to answer any questions about Tent (the protocol), tentd (the reference server implementation), tentstatus (the reference client app), and the rest of the ecosystem.</comment>