Придут ли на смену статически типизированным языкам языки с динамической типизацией?

Точнее спецификатор типа (type-specifier), по крайней мере так написано в стандарте.

Придут ли на смену статически типизированным языкам языки с динамической типизацией?

Я ниже написал, что имел ввиду.
Добавлю лишь, что вы правы и неявный тип var в C# это близкий аналог auto.

Придут ли на смену статически типизированным языкам языки с динамической типизацией?

Все верно на этапе компиляции явно определяется тип инициализирующего значения.
И С++ по прежнему остается языком со статической типизацией, потому что auto это тоже тип.

А насчет динамичности я не успел развернуть мысль, это было больше стёбное выражение, говорящее о том, что новом стандарте и так упростил многое до безумия, куда еще проще, а главное зачем?

Придут ли на смену статически типизированным языкам языки с динамической типизацией?

Или вот более реальный пример:

#include <iostream>
#include <array>

template<class T, class... Tail>
auto make_array(T thead, Tail... tail) -> std::array<T, 1 + sizeof...(Tail)>
{
     std::array<T, 1 + sizeof...(Tail)> array = {thead, tail ...};
     return array;
};

int main() {
    auto array = make_array(1, 2, 3);

    for (auto i : array)
        std::cout << i*i << std::endl;

	return 0;
}

По-моему очень даже динамично, не находите?

Придут ли на смену статически типизированным языкам языки с динамической типизацией?

С++ тоже развивается.

Если раньше приходилось писать так:

vector<int>::const_iterator i = vec.begin();

while (i != vec.cend()) {
   /..
   i++;
}

То сейчас можно уже не указывать тип:

auto i = vec.begin();

while (i != vec.cend()) {
   /..
   i++;
}

А перебор коллекций вообще упрощен до смешного:

for(int &i : vec) i *= i;

или:

array<int, 3> arr = {1, 2, 3};

for (auto i : arr) i *= i;

Про Smart pointer's, Lambda's, Tuple's и пр. тоже не стоит забывать.

JavaScript на сервере, 1ms на трансформацию

Начальство тоже когда были программистами.

JavaScript на сервере, 1ms на трансформацию

JSON — это формат обмена данными, к организации когда он никакого отношения не имеет. Но вы наверное имеете ввиду само представление данных.
У меня как раз есть модуль для генерации CSS из словаря, думаю добавить еще HTML.

JavaScript на сервере, 1ms на трансформацию

Это же шаблонизатор, не более, он мог быть написан на любом языке, просто в этом случае серверный язык JS.

JavaScript на сервере, 1ms на трансформацию

В данном случае никакой логики нет.
Просто я не понял что вы имеете ввиду под хранением функционала (копия куска кода aka Here document)?

JavaScript на сервере, 1ms на трансформацию

А для чего вообще хранить логику в шаблоне?

JavaScript на сервере, 1ms на трансформацию

Если честно Использование set и get выглядит очень избыточно, по сравнению с возможным решением:

<#:tag _name="a" _action="mail" _params="foo,bar">link</tag:#>

Результат:
<а httр://mail.ru?foo=1&bar=2">link</а>

Параметры foo и bar берутся либо из:
— функции (имя функции прописывается как _fn=«some_function»)
— наследуются от родительского элемента
— переменных окружений
— явно назначаются (если задать значение параметру типа foo=1, то так и будет)

Если параметра нет и его значение явно не задано, то название параметра не будет выведено.

Понимаем декораторы в Python'e, шаг за шагом. Шаг 1

Видимо тем, что остальные статьи заканчивались на первом примере этого поста.
Иными словами автор выбрал несколько иной подход, сперва привел итоговый пример, а затем разложил все по полочкам, так сказать сохранил интригу и не дал заснуть.

Рельсы сошли с рельс: Почему я переписываю Archaeopteryx на CoffeeScript

не читать*

Рельсы сошли с рельс: Почему я переписываю Archaeopteryx на CoffeeScript

Это не «багофича», а неявное приведение типа из объектного к элементарному.
А происходит это из-за неявного вызова метода valueOf().
Такую ситуацию можно самому смоделировать:

var object = {
	a: 1,
	b: 2,
	valueOf: function () {
		return this.a + this.b;
	}
};

alert(+object) //3

Обо всем этом написано в спецификации, просто большинство людей считают что ее можно читать, мол язык простой и так все понятно, а что не понятно списывают на глюки языка.

Рельсы сошли с рельс: Почему я переписываю Archaeopteryx на CoffeeScript

По поводу редакторов для CoffeeScript, в корне не согласен.
Во всех продуктах jetBrains c недавних пор реализована полная поддержка, точно такая же как и для JavaScript. Причем полностью совместима с API Node.

Рельсы сошли с рельс: Почему я переписываю Archaeopteryx на CoffeeScript

В тихоря минусонуть карму герои, обосновать хватит знаний?

Рельсы сошли с рельс: Почему я переписываю Archaeopteryx на CoffeeScript

Видел я это видео, ничего нового нового не узнал. Для тех кто-то более или менее знаком с языком такие вещи не кажутся сюрпризами.

А сравнивать CoffeeScript и JavaScript по этому видео вообще не корректно, потому что +[] и там и там транзитивно нулю.

Рельсы сошли с рельс: Почему я переписываю Archaeopteryx на CoffeeScript

А какие у JavaScript проблемы?

Fabric — пара прикладных рецептов

Еще для подобных задач хорошо зарекомендовал себя pexpect

Fabric — пара прикладных рецептов

Прежде всего поставьте fabric и, впредь, ставьте её везде (если, вдруг, Вы ещё так не делаете)!

А еще, ставьте везде MS-DOS даже если он вам не нужен.
Ну правда, аргументируйте как-то, почему все Python-разработчики должны уставить этот модуль.