sacado2

I think it's the first time I see someone call Go a modern/innovating/fast evloving language. What attracted me to this language in the first place is the fact backward compatibility is seen as a dogma in the community. It's one of its strongest selling points IMO. I have production code written in 2014 that still compiles and works perfectly without any warning from any (popular) linter.

There are many diacritics in French, and not having a key for the most frequent accentuated letters is far from optimal (for instance, the previous sentence in French would contain 5 diacritics).

Even if your code is written in English, some text still has to be written in your own language (in particular, anything the end user will happen to read). And, although you can write English from a (say) French keyboard, writing French from an English keyboard is a PITA.

> we observe that checking an alleged regex+backtrack solution is a polynomial task

That's the point I missed at first. That's good news, because I was pretty sure perl regex were accidentally Turing complete, I don't know why.

Am I missing something? I read it the other way: all CNF instances can be rewritten as regexp + backreferences, meaning re + backreferences are at least as general that SAT, not at most as. Meaning, they could be higher in the polynomial hierarchy.

Yeah, I meant it the other way, if those regexps are Turing-complete, not all of them have an equivalent CNF representation, contrarily to what the article seems to state in its first paragraph (and title).

That being said, regexps were not initially meant to be "programming languages", so I'm not sure about the "feature, not bug" part. I'd rather have a notation that would let me solve, for instance, the "HTML tag matching" problem and would be guaranteed to always terminate, than one that also lets me implement Conway's game of life.

One of the cool features of SAT problems is that they always terminate (if you're patient enough). Aren't regex, especially with backreferences, Turing-complete though? If so, they could be caught in an infinite loop, meaning they are more general than the SAT problem.

> This doesn't make sense. How can you search for a string if you're already in a string? I can't think of a realistic situation where that would be useful or even really possible.

    query = "select * from table where name like \"%foo\""

And that's where we need more journalitic (does that word exist?) writing. Even by non-journalists, I mean.

Make a long form content, start with the most important information in the first paragraph, and give more and more developments in the following paragraphs. Someone who thrives for short content will be happy with the first paragraph. Someone who want to delve into the details will ready each and every word. Heck, your first paragraph could even be a tweet containing a link to the long form.

This is clickbait taken backwards. You will get very few clicks as you already delivered the main information for free, but those who clicked will be there for a good reason.

I'm surprised by this content, because Google actually changed the web for the better in this regard. Anybody remembers the ezinearticles era? Where people kept publishing the same short articles filled with just a few keywords and nothing more, over and over again, just to get backlinks? Back then you couldn't make a search on any topic without falling on page after page of those light articles filled with keywords only.

Those article directories were eventually murdered by Google within the blink of an eye maybe a decade ago, and quite frankly on any given topic nowadays it's way easier to find good content rather than SEO filler. Google's algorithms will nowaydays favor fresh (aka published or updated recently), long content over short, "popular" (aka lots of links on it), duplicated content.

You can only add methods on types that were defined in the current package. As a consequence, you can't add methods to built-in types. But that's rarely something you want to do anyway (I can't think of a real-world situation where it would be useful), what would make sense is creating a new string type, and add methods to it:

    type myInt int

    func (mi myInt) f() myInt { ... }

It's not only about the main compiler. Go has tons of third-party tools (linters mainly) that can parse go code, because it's so easy to write one. Most of them wouldn't exist if parsing was a PITA.

I'm ready to bet that with <>, you'd introduce ambiguity in the grammar, making parsing code (and, as a consequence, writing tools for the language) much more complicated.

Just sell ugly food cheaper and people will start to buy it. In fact I wonder if there is not a huge market for someone who would say "No need to choose anymore: with 'ugly foods', you can save money and the planet"

> Maybe I’m doing something wrong, but my Go code is often littered with casts between different integer sizes and signedness.

It can actually be a feature, and one of the things that brought me to go, as you can define your own integer (or float, or string, etc.) types, thus making them incompatible with each other:

    type distance int
    type speed int
    func distFor(d distance, t time.Time) speed { ... }
    ...
    x = distFor(x, t) // Oops, that's probably a bug!

Not many languages let you do this, especially back then. But yeah, not great for exploratory programming.

I grew up with the understanding that "systems programming" is the opposite of "application programming", or, in other words, the opposite of "programs that the end user will use". So that would include the kernel, but also anything between the kernel and the end user, including compilers, servers, and so on. Yes, it's a blurry line.

Actually I think go is semantically much closer to oberon than to C.

> Maybe because you know that there's only one timezone for the UK

And that's where things start to get fun, because there are actually several timezones in the UK if you include its dependencies. I don't really know how it works in the UK because I'm French, so let's take France instead. "What time is it in France?" usually means "in metropolitan France", but now let's say you're in northern Brazil, close to the border of French Guyane. When you say "what time is it in France", do you mean "metropolitan France across the ocean", or do you mean "the closest French department a hundred miles away"?

Ada had them before Haskell, and I'm not even sure it was the first language with them.

What's a sum operation though? Is the sum of a, b and c the same thing as the sum of b, c and a?

Not only this, but blogging can also be a marketing tool, where you (or a company you're writing for) publish articles not as an end in themselves, but as a way to show you're an expert in a given domain. For SEO reasons, but not only. These blogs don't need advertisement to make money, they are the advertisement. I'm pretty sure nowadays, this is where money is in blogging. If you want to make money as a blogger, I think it's a way safer road than the advertisement-centered approach.

I totally agree it's great and tend to enjoy languages that don't provide the user with unchecked nulls. It's a cool tool, but I don't think it's worth a billion dollars. If I had to choose, I'd rather take non-mutability by default rather than compile-time enforced checking of null pointers.

> Nulls, the billion dollar mistake.

That "billion dollar mistakes" is an excellent marketing expression (nobody wants to make billion-dollar mistakes! We should avoid that null they talk about! It looks so expensive!) but I don't know how actually true it is. Do we have any kind of scientific paper that proves languages without null lead to way less expensive software than languages with null?

I'm not talking about memory unsafe languages like C or C++, but situations where, in a memory-safe language, a null pointer exception in production happened to cost a shitload of money.

I'm pretty sure I never had a nil dereferencing in production with my go code. Invalid array access, off-by-one-errors, yeah, sure, way too many, but very few languages can prevent them at compile time. But nil dereferencing? I can't remember that.

> On the other hand, same thing can be accomplished by using company-wise style enforcers

But you can't do that with open-source libraries. When I use an open source library, I can audit its code very easily, and this is not always true with other languages. The more complex the language, the harder it is to audit it. There are many C++ open source libraries (hello Boost) I can't understand because they don't use the dialects I'm used to.

Imagine we're working together and I have some text document I want you to work on and update. If I send you the text by email, I send a copy of it (the original text is still on my computer). If you modify that copy and keep it for you, I won't ever know what you did. I just used a function

    func (c Coworker) SendForUpdates(d Document) {
        ...
    }

That wouldn't make sense. You worked hard and I don't even know what you did. So, what I would expect you to do is, once you made updates on the copy, to send me back that copy by email. That would be akin to

    func (c Coworker) SendForUpdates(d Document) Document {
        ...
        return d
    }

I sent you a copy, and you returned another updated copy. That is "pass-by-value", the default, no-pointer style.

Now, let's say I think those emails back and forth and boring. Rather than sending you a copy of the text each time, I could rather use Google Docs, and send you the link to that document. Its URL, rather than a copy of its content. Now, you can just go to that URL and do the updates on the document. You don't have to send me back the document: you're working on it, not on a copy of it! Well, that URL is a reference to the document rather than the document itself, or, if you prefer, a pointer to it. So, now, the function would be

    func (c Coworker) SendForUpdates(d *Document) {
        ...
    }

And we're done, no more back-and-forth dance now! That is "pass-by-reference".

You don't only use "pass-by-reference" just to be able to check updates on the document sent, by the way. If I want to send you some text just for your information and I don't expect any kind of update, I'll use pass-by-value (the very first function). But what if I want to send you a 3 GB video? I can't send that through e-mail! Sending a copy would be totally inefficient. Once again, I'll send you a pointer, an URL to download the video:

    func (c Coworker) InformText(d Document) // d is small: pass-by-value

    func (c Coworker) InformBigVideo(v *Video) // videos are huge: pass-by-reference

Why not use pointers everywhere by default, they seem easier, right? That's basically what java and python do. Well, they can be tricky too. I gave you the URL to the link and you could work on it. Once you're done, I don't want you to modify the document anymore. I want to send it to our boss. But, how could I know you didn't keep the URL somewhere in your bookmarks? How do I know, of all the coworkers I sent the URL to, one of them doesn't keep on updating that document even when I don't want to anymore? With copies, I'm safe, do whatever the hell you want with your copy, I don't care anymore. But a reference to the original document? That can be dangerous.

I think (and this is, somehow, related to pointers) the most complicated thing in go for a beginner (and even for someone who can program but only knows higher level languages, java included) is slices.

Slices are hard to grasp, you can modify them within a function (without ever touching that weird little * and his & cousin) and they are still modified when you exit the function, but you can't do that with other values (all of them need the star operator if you want to modify them).

Plus, appending a value to the end of a slice is very cumbersome and unusual with something like

    arr = append(arr, val)

Oh, and do you remember when i said you could modify slices within functions and they are still modified in the end? This is not true with append. If you append to a slice, the new values won't be appended when you return from the function.

This thing doesn't really make sense unless you've been a C programmer in fact, and understand the concept of fixed-size arrays and reallocating memory to grow them. Otherwise, even if you can work around that weird part, it will always seem a little magical and tricky.

I'm an introvert and like to have a quiet place of my own. I work way better this way. I'm not alone in my office, though, we're 2 in the same room, and the door is always open, and everyone else in keeps his office's door open unless they need privacy. Best of both worlds.

I can't work with music/headphones. I tried, but it doesn't seem to work for me as I tend to focus on the music.

I had the same experience with that very problem. Didn't understand it before I programed it.

Absolutely. But in practice, I can't think of a problem that coulnd't be solved with OWL (or some other formalism like answer set programming) and where prolog would be the best solution (rather than more "traditional" programming languages). There are certainly a few, but not enough IMO to draw a lot of attention to prolog.

Nowadays, ontology-management systems like Protégé and SPARQL can more or less solve all problems prolog can solve, while providing higher-level formalisms and with the guarantee your query will terminate.