Swift 3.0

Нет. Она нужна только в языках с сишными циклами,

Так а что же с:

const int n = ++m[ key ];

? Код на Swift будет?

Хотя пока скорость статичного подхода на две головы выше, ничего против него не имею как такового, непонятно только зачем новоязы делать опять такими.

Если динамическая типизация такая крутая, то как например ты обьяснишь появление и популярность языка TypeScript? Он выйгрыша в скорости не дает.

популярность языка TypeScript

LOL

Я о том что выглядит как типичный костыль а делает то что есть by design в динамических языках

Вообще-то говоря, это вся динамическая типизация выглядит как типичный костыль. «Мы не осилили реализовать статическую систему типов достаточно выразительную для того, чтобы пользоваться ей без боли, поэтому давайте вообще забьём на это и тип будет определяться в рантайме».

Да где угодно, где есть счетчики создаваемые по ключу.

Типичный код для таких ситуаций - это прошлый пример. Я жду историй про то, зачем нужно n и почему оно должно быть константным.

Я жду историй про то, зачем нужно n

А ты внимательно читал, что я написал? Затем, что если это, например, новый ID, то его надо, как ни странно, вернуть. Или если это статистика, то n может быть надо чтоб:

а) узнать первый ли это элемент; б) обновить общую сумму или рейтинг.

и почему оно должно быть константным

Не должно быть, это лично мой стиль - если переменная не будет изменяться, то я пишу const. Можешь представить, что его там не было, тем более что ты явно уже высасываешь из пальца придирки, т.к. const тут никому ничем не мешает.

Ну ладно, держи:

m[key] += 1;
const int n = m[key];

Впрочем, если ты каждый день создаёшь ID и для тебя критична длина кода, можно короче:

int* n = m[key];
*n += 1;

Это тот, который компилируется в javascript что бы запускаться на js движках? Так с чего бы ему быть быстрей.

Есть другой представитель ECMAScript -овых со статическими типами - это ActionScript (который в adobe flash и Air)
Только его изначально и создавали что бы он на пентиум III с 256 мб памяти работал.

let variable =

ахаха очередной rust, или qbasic, я не в курсе в чем разница между ними.

я не в курсе в чем разница между ними

Это потому, что ты дурачок.

в общем-то у них стандартная болезнь «языков-убивцев С++». язык - говно. да по хорошему, это не языки и были. это были мовы. чтоб не как у С++. так что процесс нормальный: надо дальше нагибать подписавшихся адептов.

m[key] += 1;
const int n = m[key];

Шикарно, два раза сходить за значением - да кому нужна эта ваша производительность.

int* n = m[key];
*n += 1;

Еще шикарней, а давайте хранить указатели, ведь кроме производительности (нам же не в падлу не побегать лишний раз по указателю) нам еще и на безопасный и простой код наплевать. Главное чтоб не было какирского ++.

я не в курсе в чем разница между этими диалектами бейсика.

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

int* n = m[key];
*n += 1;

Ну и в моем примере на С++ новый счетчик создастся автоматом. Тут же - будет тупо креш, т.к. тут нужен еще дополнительный код, которого нет.

Ну почему же, всякие питоны и жабаскрипты тоже нужны. Их предметные области не сильно пересекаются. А тут - варианты практически одних и тех же велосипедов, которые известны только потому, что их педалируют большие корпорации.

твоя ось не должна принадлежать тебе. это теперь игрушка для хипстеров и хомяков.

А тут - варианты практически одних и тех же велосипедов, которые известны только потому, что их педалируют большие корпорации.

А, ну раз ты это говоришь, тогда да.

Этот печальный факт тоже связан с зоопарком язычков... А так да - ситуация в чем-то похожая. Но язык - это гораздо более заметная штука, чем отдельная написанная на нем книжка.

Шикарно, два раза сходить за значением - да кому нужна эта ваша производительность.

Твой компилятор не умеет в оптимизацию?

а давайте хранить указатели

Не ври, в твоих юзкейзах было не хранение, а одно-двухкратное использование в пределах функции.

Ну и в моем примере на С++ новый счетчик создастся автоматом.

Это который const, чтоле?

Твой компилятор не умеет в оптимизацию?

А, так ты вообще далек от темы. Получение/создание значения по ключу из мапы - нетривиальная операция, которая не один раз дергает память. И если «твой» компилятор может убрать второй вызов - он вполне вероятно обладает ИИ. Можешь попробовать, например, посмотреть на выхлоп от:

#include <iostream>
#include <unordered_map>
using namespace std;

int main() {
    unordered_map<int, int> m;
    m[0]++;
    m[0]++;

    cout << m[0] << '\n';
}

а давайте хранить указатели

Не ври, в твоих юзкейзах было не хранение, а одно-двухкратное использование в пределах функции.

Што? (с) У меня в примере мог быть, например, unordered_map<string, int>. А на каком языке написал ты и что использовал - вопрос открытый. Если это тоже С++ - то это безграмотный, неоптимальный и опасный код. Если попытка написать на Swift - это не он.

Это который const, чтоле?

С тобой все ясно, иди в детсад, там тебя поймут и оценят. Ну и пока будешь идти, попробуй понять разницу между значением, хранимым в мапе, которое мы получаем по ссылке, и локальной переменной типа int, куда мы сохраняем результат выражения.

Ты путаешь статическую/динамическую типизацию и строгий/слабый контроль типов в динамических языках.

Ну пока Swift позиционируется «всего-то» как замена ObjectiveC, что для мира Эппла равноценно «убийце С++» :)

Судя по фрагментам кода, которые я видел сам, и по отзывам коллег, для говнокодерства приложений для айфончика Swift таки удобнее. А там посмотрим.

Ты путаешь статическую/динамическую типизацию и строгий/слабый контроль типов в динамических языках.

facepalm.jpg

Перестань умничать, у тебя всё равно не получается.

Если это тоже С++ - то это безграмотный, неоптимальный и опасный код.

Если ты собрался сразу его вернуть из функции - не вижу проблемы.

Если хочешь использовать дальше - пиши что-то вроде:

int& entry = m[key];
entry++;
const int n = entry;

Ну и пока будешь идти, попробуй понять разницу между значением, хранимым в мапе, которое мы получаем по ссылке, и локальной переменной типа int

Не, лучше ты вменяемо объясни, что за счётчик у тебя там автоматом создаётся.

Почему умничать то, это ведь на самом деле разные понятия, даже википедия везде подписывает:

Система типов: 	статическая, сильная

Ты путаешь статическую/динамическую типизацию и строгий/слабый контроль типов в динамических языках.

Забавно это слышать от того, кто про ad-hoc полиморфизм узнал только из этого треда.

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

назовём это «синдром кремниевой долины». или экономика 2.0 - изрыгающая из себя веб2.0ли, «сланцевую нефть» и прочие воздушные шары, с понтом запускаемые в небо с помощью сотен хомяков-инвесторов. а рядом еще маск свои машинки на батарейках клепает(мотор-колесо умные люди сделали, потратив тучу денег на НИОКР, а гений просто пришел и воспользовался. гений же), ну или петарды запускает.

Ты так кукарекаешь, как будто в этом что-то плохое

ну вообще, оператор «квадратная скобка» в c++ немного страдательный. то есть часто нужно узнать, есть ли, а потом использовать. было бы гораздо лучше, если бы [] возвращал ссылку на некотрый статический элемент, инициализированный как «ненужно».

Толку от статической типизации, если я могу проверить, что в функцию синуса было передано допустимое значение (от -1 до 1) только в рантайме (естественно в этих ваших С++, Java и прочих)

Функция синус - образный пример, хочу передавать только в промежутке от -1 до 1

то есть часто нужно узнать, есть ли, а потом использовать.

find

было бы гораздо лучше, если бы [] возвращал ссылку на некотрый статический элемент, инициализированный как «ненужно».

Было бы криво и костыльно. И нерабочим в общем случае. И по коду выиграша по сравнению с find не было бы.

no Xcode, no AppKit and no UIKit. There’s no Core Graphics, no Core Animation, no AVFoundation

неудивительно в общем-то. Кто с Core Graphics и особенно с Core Video работал, тот в цирке не смеётся. Оно вообще работает только потому, что Бог пока не закончил собирать всех педиков на один корабль, чтоб потопить к чертям собачьим.

не знаю, в каком «общем случае» это было бы неработоспособно. разве что общий случай включает в себя программиста на жабе, у которого в деструкторе исключения сыпятся и в штаны кто-то постоянно срёт.

разве что общий случай включает в себя программиста на жабе

Программисты на жабе в общем и целом поумнее тебя будут.

class imclass1 {
imclass1() {}
public:
static imclass1 create( data_t );
};

class imclass2 {
public:
imclass2( data_t ) {}
};

Как ты собрался для таких классов создавать «некотрый статический элемент»?

я даже не знаю, как объяснить программисту на жабе, который «поумнее будет», что такое map и unordered_map в С++. видимо это невозможно в принципе.

Еще один одаренный. Данные классы как раз для примера использования в этих контейнерах. А теперь расскажи как ты будешь создавать дефолтное значение без конструктора по-уполчанию.

#include <unordered_map>
using namespace std;

class imclass1 {
imclass1() {}
public:
static imclass1 create() { return {}; }
};

class imclass2 {
public:
imclass2( int ) {}
};

int main() {
    unordered_map<int, imclass1> m1;
    unordered_map<int, imclass2> m2;
}

Толку от статической типизации, если я могу проверить, что в функцию синуса было передано допустимое значение (от -1 до 1) только в рантайме (естественно в этих ваших С++, Java и прочих)

Арксинуса тогда уж. Но в любом случае, а что, у динамических систем типов в данном вопросе есть преимущества перед статическими?

Кстати, в планах на Swift 4, у разработчиков значится пункт для добавления системы владения ресурсами как в Rust:

- Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory ownership model to Swift is highly desired by systems programmers and folks who want predictable and deterministic performance (for example, in real time audio processing code).

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

гарантия того, что было передано число, а не строка сильно не упрощает жизнь

Это тривиальный случай, где трудно ошибится. А вот гарантия того, что передаваемый объект унаследован от одного из нужных классов - упрощает.

Так никто не обещал, что это серебряная пуля. Только это же не повод отказываться от тех преимуществ, которыми она обладает.

Забавно это слышать от того, кто про ad-hoc полиморфизм узнал только из этого треда.

Даже из этого треда не узнал, я спросил как метод value определяет какое значение ему возвращать, мне написали пример из которого понятно что в него просто указатель на эту самую переменную падает, а дальше уже понятное дело можно от этого спокойно танцевать.
«Полиморфизм» согласно википедии это просто какое то широкое понятие означающее способность одной функции обрабатывать разные типы данных - вообще не про то.

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

А на что тебе везде статический анализ?

function sum(a, b) {
   return a + b
}

def sum(a, b)
   return a + b
end

func sayHello(name: String) {
    print("Hello, \(name)!")
}
let name = CommandLine.arguments[1]
sayHello(name: name)

Вот какой тут смысл информации о типе?

Чтобы ты пораньше узнал о своей дурости^Wошибке, когда сложишь гвозди с пельменями.

Вот ты функцию написал и складываешь через нее любые типы sum(1, 3.2) sum(«крым», «наш») итд итп

def add[S: Semigroup](a: S, b: S) =
  implicitly[Semigroup[S]].add(a, b)

Я прекрасно понимаю аргументы за статические языки, но в данном случае из CommandLine просто ничего другого вернуться не может и какие вообще проблемы записать в строку NULL булеан или число.
Я может восьмибитное число хочу записать то же «Привет, 0xff!», как мне его впилить туда?

Это что за порнография?

Я прекрасно понимаю аргументы за статические языки

Нет.

Я может восьмибитное число хочу записать то же «Привет, 0xff!», как мне его впилить туда?

concat(«Привет, », hex(0xff))