Вы рассматриваете короткую перспективу, языку требуется время, чтобы ассимилировать новые понятия из других языков, это нормально. Зато в результате подобных процессов обмена формируется межнациональная языковая прослойка, понятная на любом языке. В качестве примера у нас есть латинский язык, уши которого до сих пор торчат повсюду.
Естественные языки и так стремятся к упрощению, от них со временем отваливаются сложные правила и исключения, пока это не сильно вредит основной функции языка. История знает и намеренное упрощение языков, тот же русский тому пример. Не вижу задач для AI в данном процессе, непонятно, зачем что-то выдумывать. Думаю, для жвал и клювов наши современные языки не очень подходят, конечно. Это, наверное, проблема.
Я не живу в США, и в плане смысла серьёзной разницы здесь не чувствую. Теоретически, разница такая же, как в активном залоге: Perfect предполагает указание на важность времени совершения (или последовательности), которые явно определены, а Simple ставит акцент на непосредственно факте, в общем случае умалчивая о конкретном промежутке времени. То есть perfect звучит более определённо, но это всё нюансировка.
Это просто Future Perfect в пассивном залоге, то есть: "перед этим" аппарат "отманеврируют", чтобы обеспеить более высокую температуру на переднем "UPS".
Когда вам наскучат относительно банальные ходы, количество итераций резко пойдёт вверх. И тут уже решать вам, либо прокачивать теорию и снижать вариативность, проще и быстрее приходя к намеченному звучанию, либо тратить кратно больше времени на перебор, но иметь возможность набрести на какой-нибудь особо оригинальный ход, который 99.9% слушателей никогда не оценит.
Интересно, насколько будет жизнеспособной структура, в которой нейроны испускают световой импульс ненаправленно, а окружающие детектируют этот импульс параллельно с обычным функционированием. Сложность ненаправленности: во-первых, требуется больше энергии на излучение, во-вторых, оно будет активировать очень много нейронов в ближайшей окрестности, но не иметь возможности активировать что-либо дальше. Преимущество в сочетании быстрых и слабых локальных световых сигналов с проверенной временем текущей структурой. Ну, и это хотя бы приблизительно понятно, как реализовать на практике.
Если уж мы мечтаем, то генную инженерию также можно рассматривать в контексте киборгизации: вместо повреждённых линий спинного мозга могут быть проложены надёжные синтетические линии, которые будут эффективно срастаться с генномодифицированной нейронной сетью в любой точке подключения.
У меня обычно возникает вопрос, зачем писать статью, а не как это делать. В мире полно хороших статей, особенно на английском языке, фактологически я вряд ли смогу лучше, а доносить какие-то свои мнения безотносительно фактов не очень интересно.
Я когда-то в 2018 году тоже развлекался pose transfer (GAN + OpenPose). Очень радует, как развивается индустрия, и в плане разрешения, и в плане временной стабильности.
Самый важный фактор, а именно конечная стоимость электроэнергии от таких реакторов, пока не определён, а без приемлемого ценника, увы, можно долго рассуждать о плюсах, но так и не увидеть массового внедрения до конца своих дней. Хотелось бы верить.
Вполне понятно, почему и зачем появились темплейты и различные методы работы с памятью, я тоже считаю эти приобретения полезными для более высокоуровневого языка. Посыл моего предыдущего сообщения касался скорее сложности синтаксиса, а не набора фич как такового. Я, в принципе, не очень горю желанием разводить холивары на тему языка, на котором практически не пишу, каждый кодит как он хочет. Просто, по моему скромному мнению, синтаксис имеет значение. Например возьмём из доки пример с async и чуток его упростим:
X x;
auto a = std::async(&X::foo, &x, 42, "Hello");
a.wait();
Во многих других высокоуровневых языках такая же конструкция будет записана в виде:
await x.foo(42, "Hello")
Функционально разницы между этими двумя кусками практически никакой, синтаксически же -- пропасть. В связи с этим можно порассуждать об управлении памятью, скорости исполнения, легаси и прочих истоках языка, но это не отменяет факта, что я, как программист, слабо знакомый с C++, считаю первый вариант более уродливым, нежели второй, а потому менее склонен обращаться к такому языку, если у меня есть выбор.
Вполне разумно. Хочу уточнить только, что функциональное программирование, чистые функции и композиция вместо наследования -- это, в целом, весьма популярный подход к архитектуре ПО, применимый далеко не только к C++.
К сожалению, локально на уровне страны самые действенные меры -- они же самые антидемократичные. Либо жёсткий локдаун и contact tracing, как в Китае, либо единовременная поголовная вакцинация. И даже это будет временным решением, требующим постоянного контроля властей, т.к. есть другие страны, где вирус будет продолжать мутировать. А на глобальном уровне -- надеяться, что мир будет в достаточной мере привит до того, как вирус станет невосприимчивым к текущим вакцинам.
Если бы это был "C с классами", было бы значительно легче жить. Как раз к сложности синтаксиса C++ максимальное число претензий у C-программистов. Проще игнорировать классы и продолжать писать на чистом C, чем разбираться с тем обилием сущностей, которое появилось в C++ и её стандартной библиотеке. Лично я с большой неохотой фикшу что-то в OpenSource на C++, т.к. "не осилил" весь этот праздник жизни. Я не считаю язык C++ по умолчанию чем-то плохим, но лично для меня инструмент, который должен бы инкапсулировать сложность внутри своих механизмов, сам её и создаёт.
Судя по тому, что Вы написали в посте, у меня выиграть гринкард шансов на пару порядков больше, чем повторить всё вот это. Но обе вероятности из разряда "это произойдёт, но не с тобой".
Вы рассматриваете короткую перспективу, языку требуется время, чтобы ассимилировать новые понятия из других языков, это нормально. Зато в результате подобных процессов обмена формируется межнациональная языковая прослойка, понятная на любом языке. В качестве примера у нас есть латинский язык, уши которого до сих пор торчат повсюду.
Естественные языки и так стремятся к упрощению, от них со временем отваливаются сложные правила и исключения, пока это не сильно вредит основной функции языка. История знает и намеренное упрощение языков, тот же русский тому пример. Не вижу задач для AI в данном процессе, непонятно, зачем что-то выдумывать. Думаю, для жвал и клювов наши современные языки не очень подходят, конечно. Это, наверное, проблема.
Я не живу в США, и в плане смысла серьёзной разницы здесь не чувствую. Теоретически, разница такая же, как в активном залоге: Perfect предполагает указание на важность времени совершения (или последовательности), которые явно определены, а Simple ставит акцент на непосредственно факте, в общем случае умалчивая о конкретном промежутке времени. То есть perfect звучит более определённо, но это всё нюансировка.
Это просто Future Perfect в пассивном залоге, то есть: "перед этим" аппарат "отманеврируют", чтобы обеспеить более высокую температуру на переднем "UPS".
Когда вам наскучат относительно банальные ходы, количество итераций резко пойдёт вверх. И тут уже решать вам, либо прокачивать теорию и снижать вариативность, проще и быстрее приходя к намеченному звучанию, либо тратить кратно больше времени на перебор, но иметь возможность набрести на какой-нибудь особо оригинальный ход, который 99.9% слушателей никогда не оценит.
Вы просто не умеете его готовить.
Интересно, насколько будет жизнеспособной структура, в которой нейроны испускают световой импульс ненаправленно, а окружающие детектируют этот импульс параллельно с обычным функционированием. Сложность ненаправленности: во-первых, требуется больше энергии на излучение, во-вторых, оно будет активировать очень много нейронов в ближайшей окрестности, но не иметь возможности активировать что-либо дальше. Преимущество в сочетании быстрых и слабых локальных световых сигналов с проверенной временем текущей структурой. Ну, и это хотя бы приблизительно понятно, как реализовать на практике.
Чего мне не хватает, чтобы уехать? Американской визы.
Если уж мы мечтаем, то генную инженерию также можно рассматривать в контексте киборгизации: вместо повреждённых линий спинного мозга могут быть проложены надёжные синтетические линии, которые будут эффективно срастаться с генномодифицированной нейронной сетью в любой точке подключения.
У меня обычно возникает вопрос, зачем писать статью, а не как это делать. В мире полно хороших статей, особенно на английском языке, фактологически я вряд ли смогу лучше, а доносить какие-то свои мнения безотносительно фактов не очень интересно.
Я когда-то в 2018 году тоже развлекался pose transfer (GAN + OpenPose). Очень радует, как развивается индустрия, и в плане разрешения, и в плане временной стабильности.
Самый важный фактор, а именно конечная стоимость электроэнергии от таких реакторов, пока не определён, а без приемлемого ценника, увы, можно долго рассуждать о плюсах, но так и не увидеть массового внедрения до конца своих дней. Хотелось бы верить.
Сильно зависит от реализации. Для javascript, например, не принципиально.
Спасибо, интересно. Быстро просмотрел картиночки в статье, весьма обнадёживает, буду следить за развитием корутин в плюсах.
Вполне понятно, почему и зачем появились темплейты и различные методы работы с памятью, я тоже считаю эти приобретения полезными для более высокоуровневого языка. Посыл моего предыдущего сообщения касался скорее сложности синтаксиса, а не набора фич как такового. Я, в принципе, не очень горю желанием разводить холивары на тему языка, на котором практически не пишу, каждый кодит как он хочет. Просто, по моему скромному мнению, синтаксис имеет значение. Например возьмём из доки пример с async и чуток его упростим:
Во многих других высокоуровневых языках такая же конструкция будет записана в виде:
Функционально разницы между этими двумя кусками практически никакой, синтаксически же -- пропасть. В связи с этим можно порассуждать об управлении памятью, скорости исполнения, легаси и прочих истоках языка, но это не отменяет факта, что я, как программист, слабо знакомый с C++, считаю первый вариант более уродливым, нежели второй, а потому менее склонен обращаться к такому языку, если у меня есть выбор.
Вполне разумно. Хочу уточнить только, что функциональное программирование, чистые функции и композиция вместо наследования -- это, в целом, весьма популярный подход к архитектуре ПО, применимый далеко не только к C++.
К сожалению, локально на уровне страны самые действенные меры -- они же самые антидемократичные. Либо жёсткий локдаун и contact tracing, как в Китае, либо единовременная поголовная вакцинация. И даже это будет временным решением, требующим постоянного контроля властей, т.к. есть другие страны, где вирус будет продолжать мутировать. А на глобальном уровне -- надеяться, что мир будет в достаточной мере привит до того, как вирус станет невосприимчивым к текущим вакцинам.
Если бы это был "C с классами", было бы значительно легче жить. Как раз к сложности синтаксиса C++ максимальное число претензий у C-программистов. Проще игнорировать классы и продолжать писать на чистом C, чем разбираться с тем обилием сущностей, которое появилось в C++ и её стандартной библиотеке. Лично я с большой неохотой фикшу что-то в OpenSource на C++, т.к. "не осилил" весь этот праздник жизни. Я не считаю язык C++ по умолчанию чем-то плохим, но лично для меня инструмент, который должен бы инкапсулировать сложность внутри своих механизмов, сам её и создаёт.
Судя по тому, что Вы написали в посте, у меня выиграть гринкард шансов на пару порядков больше, чем повторить всё вот это. Но обе вероятности из разряда "это произойдёт, но не с тобой".
Заметили отсылочку? Поздравляю.