thegenius2000

He emphasized in the article that he was talking about patterns, not individuals. So there's no way you could draw the conclusion that he meant to suggest that his female colleagues were any less capable than their male counterparts.

That is preposterous. What if they're just more interested in other things? Why do you assume a priori that men and women share the same interests internally? What evidence do you have which suggests this? OR are you just making an assumption because it seems "unsexist"?

I don't mean to be offensive or inflammatory, but how is this a discovery? Yes, money and success don't buy you happiness; living in a complete community is healthy. How was this not completely obvious?

Yes, to dismiss theology along with alchemy -- in the same sentence -- as altogether useless is childish oversimplification. Rejecting Biblical faiths is one thing, but to ignore the impact the Christian worldview has had on Western science, including the life of Isaac Newton (who would never have invested time in studying the physical world if he didn't believe it had a Creator, and therefore order), either shows a gross lack of historical knowledge or poor taste. It's a pity because I agree with him otherwise about the risk taking, which was the main point of his article.

Another point is that a lingua franca is a common tongue for communication between people with different mother-tongues: not a replacement for native languages. For example in East & Central Africa Swahili is used for cross-communication, but individual ethnic groups maintain their cultural identities by holding onto their own languages. In this sense, I don't think you could easily find a developer who would struggle to understand anything (simple enough) written in Python, even though they don't use it on a day-to-day basis, so I think languages like Ruby/Python are already sufficient lingua francas for today's developers.

One more thing, maths notation is ridiculously diverse and overloaded and is in no way entirely uniform -- or even close. This is a problem when the disparity exists within a branch of maths, but an advantage when it's between very different areas, such as Analysis and Combinatorics.

I couldn't disagree more strongly. DSLs are at the heart of efficient programming because they encourage separation of concerns; that's why the Unix shell is so powerful, fundamentally it's a collection of different programming languages with well-defined interfaces for communication.

Secondly, personally speaking I've never had much difficulty understanding programming languages I'm unfamiliar with provided their syntax is sufficiently similar to those I use. For example, I've never much worked in Ruby but glancing at Crystal there's nothing really confusing about its syntax. Yes, we see new languages popping up here almost weekly, but we don't see new paradigms: usually most of the stuff here is procedural and on occasion it's functional. Furthermore, having seen the remarkable benefits the introduction of different paradigms has had for the community at large (think about a world without LISP for a moment) I for one believe we should encourage the development of new and strange ideas; most of them will fail, but every so often we might get a new world.

Very fair point, but what about the fraction of people who not only consider it an expense, but an affront to moral dignity? For example, Politico did a poll which showed that 46% of Americans believe that everyone should use the bathroom of their birth. Should their comforts be sacrificed for the sake of 0.6% of the population?

I agree, in fact taste might rightfully be defined as that which is obvious to an experienced developer in the environment. Code which simply relies on conventions and avoids complexity is often immediately elegant.

Worse even, the "once removed" notation has no notion of direction, so it's inherently ambiguous. I'm also pretty sure that less half of the people I hear using it know what it means (or tries to mean).

Why use a file tree when you have a terminal? It's been shown to be the most effective (and before you shoot, by "effective" I mean fast) way to manage files, and that way you can do advanced searching through whatever code base you're using. Plus you can access all the other awesome tools (like Git) for managing your project.

> A GUI editor can do everything a terminal based emulator can; there are lots of things a GUI editor can do that a text editor can't.

Really? I'd like to see sublime handle text manipulations with the same efficiency and precision that Vim provides.

> What is the advantage of terminal based editors? As far as I can see, ubiquity, which is made less compelling when you need a host of plugins to do the things you mention.

What about integration with the shell? It's not merely a matter of ubiquity: I don't really need a document tree when I have the entire terminal at my disposal a :sh or :wq away.

> Terminal editor enthusiasts seem to be under the effects of something like the Blub paradox, where any feature of a GUI editor described to them is dismissed with "why would I ever need that?" while anything in terminal emulator can do is considered essential.

This would be an apt description if the majority of "terminal editor enthusiasts" were as inexperienced with GUI editors as their GUI counterparts, but in fact the opposite is true. Most Vim/Emacs users tend to have hundreds of hours experience working with GUI editors, but are for some reason convinced that they (the editors) were inferior. Finally, let me give you an irrelevant (but fun) fact: PG, the original proposer of the Blub paradox, uses vi.

I don't think you've mentioned a single thing that can't be done by Emacs/Vim, with minimal customization. Personally I use Vim, which has great auto-completion (it's minimalist and extremely effective), extremely customize-able code-folding, highlighting and advanced navigation features out of the box. With a few plugins (like the NERD family, Syntastic etc.) it has all the features you mentioned, along with having insanely good performance and integration with the shell. And that's not to mention the advanced editing capabilities it has for managing text, which far exceed those available in editors like Sublime.

> By real autocompletion dropdowns, I mean dropdowns which are different from editing buffer.

Fair point, it's my biggest gripe with Vim's autocomplete--which I love. That being said when it works, it's more efficient than any other autocomplete I've seen in a text editor, since it's practically the shell's autocomplete.

> Basically you can do everything with text. You can even print out "this is a placeholder for an image of a sad green frog looking at a computer screen". But actually displaying that picture is better ;)

Once again, valid reasoning, but that's not the point. No one (at least I hope not) is seriously advocating TUI's for graphic design, we're talking about editing text, and that's where Vim excels.

Then open source the system from the beginning, so you literally lack the ability to insert secret backdoors.

> How are generics related to OOP or tool chains? Generics have a strong grounding in type theory and are used equally successfully in both OO and functional languages.

Once again, I never said there was anything wrong with generics! And I agree that Go should have them, I just don't think they are nearly necessary enough a feature to justify overlooking the numerous qualities the language has to offer. Please look at my initial comment: I never said anything negative about generics.

> More rhetoric. Please tell me how? Is there something that makes this better?

The "options" I'm referring to are Java/C++/C# and Python/Perl/Ruby/PHP. The former languages are too verbose, and cluttered, and Java requires the overhead of the JVM, C# is essentially Windows-only. The scripting languages lack typing and efficiency. Go is able to combine the performance and control advantages of low-level languages (to a high degree) with the simplicity of higher-level languages like Python. I'm not saying it's perfect, and I'm definitely not crazy enough to put it up against the functional languages (Haskell etc.). But when it comes to web applications, it looks like Go will soon be the one of the most practical choices available.

> The lesson Go seems to have learned is that, since C++ and Java burned their fingers, clearly fire is too dangerous for humans.

I think that's a little bit unfair, since Go introduces many powerful ideas not (traditionally) available in Java or C++: namely first class concurrency and functional primitives. Its handling of typing, the ability to define types not necessarily based on structs, the excellent design of interfaces are other examples. Go is an extremely powerful and expressive language that opens up the doors for programming in new paradigms, while making it easy to maintain readability and simplicity.

Fair point with the nil issue, I think that's one of Go's other weaknesses. But it does make up for that with its excellent error handling paradigm.

I clearly stated that Go is lacking on the generics front. The cliff is forced, rigid OOP and complicated tool-chains.

> Personally I couldn't live without generics, and would never choose a language that doesn't have them

I'm kind of confused here. Yes, Go needs generics, but are generics even that key a feature? I mean how often do you have to define a generic type, and how much copying does it really take? Is it a hassle? Of course. But at the end of the matter, Go much, much better when it comes to combining expressibility, efficiency, and simplicity then many of the other options available today.

Well put. Though I would add that though generics are convenient, they are not as needed nearly often enough to be a crucial missing feature in a language. Yes, it's uncanny to copy here and there, and certainly, the Go team should try and resolve this. But from where I'm standing this (i.e. generics) is one of the very few fair criticisms of Go which can be leveled from the Java, C++ or C# communities.

I'll grant that Go is lacking in generics, but IMHO, the opposite is true. Go is thriving because although not perfect, it is one of the few languages which seems to have learned lessons from the failings of C++, Java; and from the successes of the more dynamic/scripting languages (team Python, Ruby etc.). Go isn't a step down, it's a step backwards from the edge of the cliff.

Agreed, but remember that

  Language == Thought-space >= Implementation,

so you want to maximize your language's expressiveness.

Language simplicity? I disagree, Java is only agreable if you're comfortable with (1) being forced to work in an OOP-only environment and (2) using the JVM. And while you can argue for the upsides of both of these (which I believe are few and far between) they certainly add a great deal of clunky complexity, which many programmers are fleeing to Golang to avoid.

I agree with the author's request, I'm just not convinced he proposes a design. I mean I recognize see the need for some sort of generic programming, but the big question is how not why, right?

Edit: My bad. Didn't see the bottom of the page.

Exactly. In fact I have huge doubts about the usage of the term "evidence" here: literacy concerns cannot provide evidence on the time the Biblical texts were written, they simply shed light on the culture at the time. Real evidence in this context means uncovering early copies, comparing Biblical records of events with other accounts etc.

This is so true I'm loathe to add to it.

I dual boot my laptop b/w Windows and Linux because the WiFi network at my school has issues with Linux...so I'm forced to use Windows, also for games, but it's such a pain. Today it updated forcefully while I was trying to study; I tried to postpone the update but the option was grayed out. The Windows philosophy through and through is to treat users as ignorant and incompetent idiots for whom even the most basic of tasks must be performed, and who cannot make important decisions. This, IMHO, is the epitome of disrespect, and the reason I look forward with great anticipation to the day when I am able to solely operate within computing environments that afford me the same dignity as the cars I drive.

Yes, C# is sexy if you're okay being locked into Windows, Visual Studio and OOP from right-off-the-bat.

Honestly comments like these further discredit the Windows-development-community in my view.

First, a quick rant. You talk about "great tooling," and by this (I fear) you mean Visual Studio? Good libraries, by this you mean things like System.Foo.Bar.BazQux()? A "decent core language," by that you mean a pretty blatant knock-off of Java (which is an overly-bloated language in its own right)? And by "can do OOP" you mean must do, since the language forces you to embrace the paradigm? "Functional?" Without real first-class functions: without closures?

Generics? Fair point. Golang is lacking in that regard, at least for now.

But let me address the key misconception in your comment. You mention "sexiness," which in your mind is some sort of pointless quality. Here's what you're missing: biologically, we interpret sexiness as an indication of fertility. Good tools and languages aren't good because they're sexy, they're sexy because they're good. The ability to perceive, expect and demand this sexiness from tools is nothing more than a veiled desire to work in the most effective possible way. That's why people love Unix and hate Windows. That's why they leave languages like Java, C#, and C++ for Python and Go; and some (who I admire) use Haskell. It's not about elitism, the elitism is merely a by-product: the fundamental issue here is greediness, and the strength of one's desire to be as efficient as possible.

Can you clarify what you mean by "kill goroutines?" Because my understanding was if you return while inside a goroutine it get's handled by the GC immediately, and (as someone else mentioned) you can use context to send deadlines/cancellation signals to go routines.

Good point and great analogy, though I think EWD might be turning over in his grave. While the error detection built into compilers and the testing process are, in general, indispensable tools for developing stable software, a program that executes without any evidence of error is a great distance from a program that has been shown to be correct.

If the free-invite-train hasn't left the station, please count me in!

Great idea doesn't cut it -- this is freaking incredible.