otabdeveloper

Full-blown scripting languages are a poor fit for livecoding. (Which is really what shell commands are for.)

I had to go and write one: http://tkatchev.bitbucket.org/tab/

> So, then, best non-JVM alternate language for backend servers?

The vast, vast majority of 'backend servers' are written in C++. (Those that aren't are legacy that was written in C.)

P.S. Of course, for some people when they say 'backend' they really mean 'anything not Javascript'. In that case PHP is the world's most popular backend language, and that would be just silly.

P.P.S. The disconnect of the online discussion bubble with reality always shocks me. D? Go? Seriously?

Up until a just few years ago the Internet was fueled by extensive growth: router manufacturers (among others) made profits by selling to people who had never bought routers before.

This has all but ended now, and people shopping for their second or third router will be making different decisions.

> ...it's the gigabytes of RAM they consume

We'd need a sandboxing and module system for Javascript to solve this. A problem that is both technically complex and not 'sexy', so don't hold your breath.

> That's why Firefox users left it for Chrome.

No, the real reason is Google's highly aggressive 'bundling' (i.e. crapware) strategy.

> Does that mean that one can use system threads as frivolously as goroutines (e.g. spawning new thread for each incoming request)?

Yes. In fact, under Linux oftentimes spawning a thread and then running a system call can be faster than just running a system call.

> Conventional C++ wisdom advices against it.

With 32 bit CPU's you might run out of virtual memory quickly, since each thread allocates virtual memory for its stack.

With 64 bit CPU's there are no issues. (Also never forget that virtual memory isn't real memory, it's just a page counter.)

> ...but without the invisible man in the sky.

'天', "Heaven", is literally a pictogram of the 'invisible man in the sky'.

The ancient Chinese were monotheist, and Confucius was no exception.

Trying the fit modern norms over historical people and cultures that existed 3000 years ago silly, don't do that.

Lua has been the standard extension language in gamedev and adtech for years and years.

The "really lazy desktop app" choice is Qt, not Visual Basic.

Visual Basic hasn't really existed for decades.

> Who here honestly thought neural networks were going to be a dominant force in board game AI?

https://en.wikipedia.org/wiki/Universal_approximation_theore...

Neural networks are an algorithmically simple way to approximate any mathematical function. So, really, why _wouldn't_ you think this?

Ultimately, almost all boardgames can be reduced to mathematical functions.

> Most cyrillic-writing countries have both a "typewriter" and "phonetic" keyboard variants.

No, only Bulgaria uses the (insane, IMO) 'phonetic cyrillic qwerty' keyboard layout.

The reason why unboxed arithmetic and inlined function calls matter is that they allow for data locality, i.e., better control over cache and memory access patterns.

> Remember when software didn't need updates almost every day?

I'm old enough that I actually do remember those days. Back then we had "works best with Internet Explorer" and MS Office viruses. I don't want to go back to that world, rolling updates make the world better for everyone.

Seems unnecessarily complicated.

A script like this gets you 95% of the way there:

  mkdir AppDir
  mkdir AppDir/bin
  mkdir AppDir/data
  
  cp $INSTALLDIR/app AppDir/bin
  cp -r $INSTALLDIR/data AppDir
  cp `ldd AppDir/bin/app | grep -o '\W/[^ ]*'` AppDir/bin
  
  cat << "EOF" > AppDir/app
  #!/bin/bash
  SCRIPT_PATH=$(dirname $(readlink -f $0))
  $SCRIPT_PATH/bin/ld-*.so.2 --library-path $SCRIPT_PATH/bin $SCRIPT_PATH/bin/app $* 
  EOF

(Sometimes I wonder if people make a big mystery of Linux app distribution on purpose, to discourage distribution outside of proper, secure channels.)

"All or nothing" is not how risk management works in the real world.

P.S. 'Network security' is just a specific case of risk management.

Most of the bad stuff in glibc is due to bad API's, not to bad programming languages. (E.g., non-reentrant functions with global state, functions that deliberately crash on incorrect input, poor separation between standard library functions and non-standard but commonly accepted ones, poor separation between stuff that's needed for C and stuff that wraps kernel/syscall functionality, etc.)

Parts of it probably should be replaced with safer implementations, but as long as you're going for 100% compatibility you're still putting lipstick on a pig.

This would have been OK if HTTPS truly did increase security.

In reality, however, the sensitive part is the 'who' and 'when', not the 'what'. HTTPS makes sense for hiding passwords or bank data, for everything else it's mostly pointless.

(If you've watched any police procedural shows you've noticed that they don't need wiretaps to make an arrest, a destination phone number and time is all that's needed.)

>I'm curious what makes you say that.

The experience of migrating to DVCS's. (Anecdotal, I know, but still...)

>...but with git you're pretty much stuck with the "standard feature branching" workflow.

Git is a loose collection of file manipulation utilities, it can be cobbled together to support even the most insane workflows.

hg came before git, you have your network effect backwards.

The reason git ended up overtaking mercurial is because git is more flexible. Programmers for closed-source enterprise projects worldwide flocked to git because git can be massaged into any existing development process almost painlessly.

Mercurial, in contrast, is "opinionated".

(Before you mention github -- the timeline here is also backwards, github became the de-facto standard riding on the coattails of git's success.)

After Rule 110 nothing can surprise me about Turing completeness anymore.

> You won't find such a new language. Most languages in use are already known to be Turing-complete.

I beg to differ: http://tkatchev.bitbucket.org/tab/

(Sorry for the shameless self-promotion, but you're wrong that nothing new can be invented.)

> statically typed, memory safe, no VM programming languages that retains most of the advantages of dynamically typed languages

Those requirements contradict themselves in numerous ways. As always, engineering tradeoffs are paramount.

As for "statically typed, memory safe, no VM" -- C++ fits all those perfectly. (Provided you put in the effort of learning C++. There's another tradeoff you'd need to keep in mind.)

If you want usable tags, then you first need a good ontology hierarchy.

Inventing good ontologies is a problem that's orders of magnitude harder than a problem of making a filesystem hierarchy searchable. Look at Wikipedia -- despite all this time and all this truly immense planet-size effort, they still haven't figured out a good categorization system!

Chips already have chips in them today.

See Intel's AMT, baseband processors in phones, controllers in disks, etc.

Not surprising at all given that they haven't yet figured out what their product is.

(Note: if your product is an OS, then your customers are OEM's, not regular people. Haven't heard of _any_ efforts by Jolla to court OEM's.)

Google spends a _lot_ more on PR.

(In a literal sense, by giving out free cool technology, for example.)

> This page works best in Megacorp (c) Browser!

I thought we were past this sort of thing, no?

> but in practice it should always be combined with a calibration algorithm (which add a trivial O(n) cost to the process).

Why not just use logistic regression at this point? The only benefit of Naive Bayes over logistic regression is that Naive Bayes is simpler to code.

No, not quite. _All_ classification algorithms use "reasoning on the average". (A.k.a. "statistics".)

Naive Bayes is a poor classifier because it ignores conditional dependency: when having feature A raises the odds, having feature also B raises the odds, but having features A and B together lowers the odds.