randomdata

I'm not sure that was popular, though (as in something the majority of the population believed in). Grandma in Poducksville almost certainly had no idea. She would have known about Google doing the same, though, as it was blasted all over the news constantly for a while.

It's about the customer recognizing the product as something they are ready to buy, which is associated with the dictionary definition for shipped "(of a product) be made available for purchase."

It falls apart slightly in that the customer technically starts buying the product on day one, while it is still just a glimmer in someone's eye, but "shipping" referring to the point where the customer says "Yes, that is what I wanted" is close enough to stay within the intent of recognizing something available for purchase methinks.

> If you’ve given users the best software ever

Of course, in context, the users aren't your customer. They may be someone else's customer, but that wouldn't be shipped by your hand. Your delivery is limited to your customer.

Do they? As a non-American just watching in, I got the impression that Trump won on this very issue, promising that "Christian family values" would bring about a reversal. That was certainly the message, when taken at face value (I understand many believe that it is trying to mask other motives), that made it out of the USA, at least. That suggests to me that the concern is there.

I expect most people do understand the impact, but, much like climate change, don't know how to actually bring about the change that is needed without infringing on the life they want to live.

Technically it is an impossible bar as it, like AI, is a forever moving target. When chess was still considered AI, the Turing Test was considered the bar for AGI. Now passing the Turing Test is considered AI and chess is basic computing. Soon GPT and the like will just be basic computing and the AGI bar you can image now will become the next AI, and AGI whatever next forward-looking goal there is at that point. Lather, rinse, repeat.

To understand the missing gaps you have left open. I assume you took the time to respond to the original comment because you wanted others to understand you. But, with those gaps still open, we don't yet. If my assumption is wrong, I'll accept it, but then if you don't want to interact why bring your personal musings here and not to your private journal?

> I think I've been clear enough

Okay. Perhaps you could explain your interpretation of my questions towards you to help me understand how I didn't make myself clear when asking them? I had hoped my questions and associated explanations made clear what I didn't understand, but obviously not. Happy to rephrase it in a way that is clear once I have a grasp of what is missing.

> You're welcome to share your own definition of AI

I could try if you wish, but under what specific context? Words and terms often change in meaning when the situation around them changes. There is almost never just one definition.

Implying that humans don't produce humans, or that human intelligence is artificial?

> It's not exactly the same, it's a subcategory.

So, again, for what reason would anyone take the time to call it "artificial intelligence"/"AI" when, as a subcategory, the intent is already captured by "intelligence"? Terms need to have useful meaning to stand up, and we are still not clear on where you see "artificial" as being useful.

Perhaps the problem here is that you misunderstood the original question? It asked how you would define "AI" as a single term, not how you would define "artificial" and "intelligence" independently. I think you've done a reasonable job of the latter, but that doesn't justify the "AI moniker" as described originally.

> You seem to be using "artificial" as "mock", as in "seems like but isn't".

I don't remember using it at all, unless you mean where I asked you what "artificial" adds to the term. What are you referring to here, exactly?

If artificial intelligence is exactly the same as intelligence, then wouldn't we just call that intelligence? People won't use words if there is no useful meaning conveyed. I am not sure you have made clear what useful information is found within "artificial".

> I'd assumed "and not natural / created" was a given

And, really, what does it mean to be not natural or created in this context anyway? The dictionary definition is kind of hand wavy to begin with, leaving whether humans with intelligence are natural or created up to interpretation.

How does that differ from intelligence? (Assuming you were actually trying to answer the question)

Influenced by the same person who influenced C, at least, but it is nearly a straight up clone of Newsqueak, with a dash of Oberon, combined with a will to be more Zen than Python.

If you follow the bouncing ball of influence through Newsqueak, Limbo, et al. I'm sure you make it to C. But then why stop there? What about B, BCPL, etc.?

It did ask why the law wouldn't want to enforced? In other words, why would Americans have laws if they don't actually want them? I'm not of that country, so I am interested to learn about the culture. Amid the diatribe, I do think you eventually gave a reasonable answer to the question, for what it is worth.

> I think it's perfectly fair to ask you whether or not that's your position.

Again, I am not American, so I'm not sure it would be reasonable for me to even have a position. I don't have the necessary context. I did note that in a democracy the people get to choose what they want for themselves. But that is said simply as the generally accepted definition of democracy, like the sky is generally accepted as being blue.

But, even if I were American and for some reason had a position, why would I share? Let's say, for the sake of discussion, I really do believe that people shouldn't be up in the middle of the night to see the dark sky. Why would I tell you that? It would be in bad faith to subject you to it.

If relevant, I might share the fact that the sky is blue, and if based on that you also come to the conclusion that people shouldn't see the dark sky, cool, but that's for you to decide based on the known state of the world, not some evangelical nonsense sputtering out of me. There is no logical place for that.

You don't say... What I don't understand how you ended up writing so many words without taking the time to understand. How does one end up there?

> then you are taking the position that people have no fundamental right to enjoy their sexual and romantic lives and that this area is fair game for arbitrary legislation.

If I said the sky is blue, do you think I am taking the position that nighthawks don't deserve to stay up late to see the dark night sky? I don't exactly follow your logic. Perhaps you could explain it for us? Frankly, I'm not sure why I would take a "position" in the first place. That seems like a pointless waste of time.

If it takes appreciable amount of time, money, and effort to no longer agree to something everyone already agrees that they no longer want to agree to, the people really need to step back and think about they they are making it so hard on themselves for no reason. Granted, we're talking about people who did agree to outlaw sodomy, so perhaps not the sharpest tools in the shed. But, still, how did the tools end up so dull?

I could, but why would I? Then I'd be among the very people I'm questioning, which would then question why I would need to question myself? You've not thought this through, have you?

> and that governments can pass arbitrary laws restricting sex

Yes, technically a democracy can pass whatever arbitrary laws it wants. Laws are not some magical force, just agreements people have made.

> Any law banning heterosexual sex would surely be struck down as unconstitutional.

Only if the people are willing to uphold the constitution. It too is not some magical force, just another agreement people have made.

> You, presumably, would be the lone voice in the wilderness insisting that the crazy law ought to be enforced on democratic grounds.

Under a democracy, the law is to the will of the people. Why do the people of the USA want sodomy laws in the first place?

You might be right that that the USA is well on its way to having a dictator who can become the lone voice who controls all, without concern for what the public wants, but that is not the current state of affairs and that individual most certainly won't be me.

Yes, I would equally question the logic of a population who thought that was a good idea.

> Most constitutional democracies recognise, one way or another, that there are limits to what can be legislated circumscribed by people's fundamental rights.

Sure, it is not unusual for a population to instil safeguards to protect themselves should they become too focused on a particular issue without considering the bigger picture. Of course, the very same population can throw it all away at will.

But we're still talking about a population who, even if they have forgotten the bigger picture, have enacted and maintain desire to retain laws around sodomy. What is going on there?

I'm not so sure about that. Python is a DSL for connecting C functions together. Whereas the biggest criticism of Go (gc, at least, but fair to say it has become synonymous with Go) is around its poor C-interop.

In fact, because of that limitation, Go has developed a bit of a "rewrite those C functions in Go" attitude. While that doesn't indicate that Go is a better C (that's subjective anyway), it does indicate that they are found on the same playground. You're probably not going to rewrite Linux in Go, which might be what you are grasping at, but that's not where C ends. Not even close.

You may have a point about Java. Griesemer was a founding member, after all.

It is terrifying that the public want such laws in the first place, but that is the democratic right for them to choose, I guess.

Exactly. Thanks for reiterating.

> Anyway, why do Go fans always reach for the Haskell strawman in discussions like this?

What's a Go fan? Someone who thinks that Go blows? That is as bizarre as becoming enamoured by a language. What leads one to have feelings about a language anyway? It is an impossible to understand concept for me.

> Even JavaScript, Python and Java are not allergic to adding modern features like iterator map/filter/etc.

In what world are patterns from the 1960s "modern"? Do you consider selt belts in cars to also be a modern feature?

Me neither, but I've never actually tired to look. In honesty, have you? It is not exactly to the faint of heart to study. I suspect only Google is willing to go to the necessary depts. But, if you know of something otherwise, I'm sure we're all interested in the details.

> This defense of Go is REALLY common but as far as I can tell is purely based on myth.

1. Defence? Are you in some kind of fight...? That doesn't make any sense.

2. Myth? Are you confusing the hypothesis on which Go was built with results of experimentation? It very well may be that the hypothesis didn't stand up to experimentation, but what does that have to with our discussion? Furthermore, if you really want to change the subject to talk about that, why have you failed to tell us anything about the details of experimentation?

1. If you have a pet sum type definition, let it be known. But traditionally, a sum type is better known as a discriminated or tagged union. So far, this is what we understand Pascal offers: A union type that discriminates its subtypes by an enumerated value.

2. The tag that discriminates the type within the union (or whatever your explanation above ends ups calling it) is, in implementation, generated by a process that assigns a number to each entity; something also true of Rust. This is undeniable, as proven by the use of Ord and mem::discriminant. If you have another name for that numberer, if not an enumerator, let it be known.

It allows that in theory, at least, certainly. That's the whole reason for its existence. But in practice, developers become enamoured with the language and start to forget about the problem. If that weren't a problem we'd all be using Haskell, but back in the real world.

Toggle switches are for giving instructions to a machine. Programming languages are a higher level abstraction over the toggle switches so that the intent of the toggling can be communicated with other people. You don't just write code, run it through the machine, and then throw it away. Other people, and probably even yourself, will read what was written again and again and again. The language is very much for people first and foremost, with the side effect of also being understandable by machine.

> I think it is just a bad language.

It is – nobody is suggesting otherwise – but you didn't answer the question. Are you writing Go with Go syntax, or another language with Go syntax? Perhaps the best way to answer, if it is that you just didn't know how, is to post some sample code that you find to be obnoxious and tedious and we can see if it is that way because of Go, or if it is because you are trying to use patterns from other languages that don't fit the language.

Realistically, there is no such thing as a wrong choice, only different tradeoffs. I assume "wrong" here means wishing you made different tradeoffs later on. But will you feel real consequences if that happens, or just a casual feeling of "I wish I'd have done it differently, but oh well" in passing?

> What limitations do either of them have when scaling?

What, specifically, are you trying to scale? What scale-related problems do your customers have?

Do you even have a product yet? If no, perhaps the best tradeoff you can make right now is the one that compels you to get started instead of worrying about it? Ask yourself: Will you be more apt to actually build it if you choose Go, Rust, or perhaps with another tool entirely? It doesn't matter if X is the unquestionably best choice if you never get around to using it.

You might still want to be mindful of what risk there may be. I expect you can tell me what risks there are if you chose Brainfuck, and I expect you would tell me that is a risk too great. But, without understanding your problem in depth to know what nuance needs to be considered, there is probably no meaningful risk difference between Rust and Go.

Legend has it that Go was conceived while waiting for a C++ program to compile, if that's what you are thinking of?

But I'm not sure it matters. Go was created to test the theory, not because a theory was proven. It didn't have to be successful. It may be that the studies didn't happen even within Google, although that is our greatest chance. We do know Google actually cares about data, unlike programmers.

That said, since Go was released it seems every other language has tried to copy it with their own twist, so while that may not come from a place of evidence, it would appear that the feeling of increased productivity[1] was felt.

[1] Or something adjacent. Focusing on engineering isn't necessarily about productivity. You can't discount productivity, but it is not the top engineering concern, especially in a place like Google.

This is the exact same thing, except in addition to the tag there is also a data component. Yes, this is the more traditional representation of sum types, but having an "undefined" data component is still identifiable as a sum type. It is the tag that makes the union a sum type.

In Typescript terms, which I think illustrates this well, it is conceptually the difference between:

   { kind: 0 } | { kind: 1 }

   { kind: 0; data: T } | { kind: 1; data: U }

> They are an enumeration of discrete values

Yes, the "tag" is populated with an enumerator. There is an enumerator involved, that it is certain, but it is outside of the type system as the user sees it. It's just an integer generated to serve as an identifier – an identifier like seen in the above examples – but provided automatically. The additional information you can gain from it, like exhaustive matching, comes at the type level, not the number itself.

> Rust conflates the 'enum' keyword with sum types.

Right, because it too uses an enumerator to generate the tag value. Like Ord(foo) before, you can access the enumerated in Rust with something like

    mem::discriminant(&foo)

Do people actually care that much about languages? I mean, we're here writing English, which is a complete dumpster fire. Go is undeniable perfection compared to the horror that is English. Clearly you and I don't care that much about languages.

I expect people like Go because of its tooling (what also saves English), which was a million miles ahead of the pack when it first came out. Granted, everyone else took notice, so the gap has started to narrow.

> It feels like it fights any attempt at using it to do things optimally or quickly.

Serious question: Is that because you are trying to write code in another language with Go syntax? Go unquestionably requires a unique mental model that doesn't transfer from other languages; even those that appear similar on the surface. Because of that, I posit that it is a really hard language to learn. It is easy to get something working, but I mean truly learn it.

While every programming language requires its own mental model, Go seems to take it to another level (before reaching a completely different paradigm). I expect that is because its lack of features prevents you from papering over "misuse" like is possible in other, more featureful languages, so you feel it right away instead of gradually being able build the right mental model.

The purpose of creating yet another language with Go was to break from what everyone else was doing, to see if a "simple" language would stop developers from playing with fun language toys all day to instead focus on actual engineering.

Arguably it was successful in that.