- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
#include <iostream>
#include <functional>
#define STD_FUNCTION(a, ...) typeof( a (*) __VA_ARGS__ )
template<typename T>
T do_op_t(T a, T b, STD_FUNCTION(T,(T,T)) op)
{
return op(a,b);
}
template
<
typename T,
STD_FUNCTION(
T,
(
T,T,
STD_FUNCTION(
T,
(T,T)
)
)
) F1,
STD_FUNCTION(
T,
(T,T)
) F2
>
T do_op_spec(T a, T b)
{
return F1(a, b, F2);
}
int add(int a, int b) { return a + b; }
int mul(int a, int b) { return a * b; }
std::function<int(int,int)> fnc = \
do_op_spec\
<
int,
do_op_t<int>,
add
>;
int main()
{
std::cout << do_op_t<int>(9, 9, add) << "\n";
std::cout << do_op_t<int>(9, 9, mul) << "\n";
std::cout << do_op_spec<int, do_op_t<int>,add>(9,9) << "\n";
std::cout << do_op_spec<int, do_op_t<int>,mul>(9,9) << "\n";
std::cout << fnc(9,9) << "\n";
}
Follow us!
Лучше наверное так этот макрос переписать
В данный шаблон подсовываем тип T, и он выдает функцию, которая возвращает что-то с типом T, и принимает два аргумента типа T и (указатель на функцию, возвращающую хрень с типом T и принимающую на вход два аргумента типа T).
-------------
Данный шаблон принимает:(тип T), (указатель на функцию, возвращающую хрень с типом T и принимающую (два аргумента типа T) и (указатель на функцию, возвращающую тип T и принимающую на вход два аргумента типа T) ) и (указатель на функцию, возвращающую тип T и принимающую два аргумента типа T).
и он генерит функцию, которая возвращает хрень с типом T и принимает два аргумента типа T.
Видишь как всё просто?
STD_FUNCTION(T, (T,T)) или typeof (T (*) (T, T)) вместо простого и понятного (T,T) -> T.
Когда вообще в C++ и других языках начнут делать версионирование синтаксиса? Конечно, не "use strict" как в JS, где потом придётся использовать "use stricter", "use the strictest" и "use as strict as hell".
Вроде бы же логичное решение. Сейчас всё равно приходится одновременно
* прописывать версию стандарта для файлов, чтобы они правильно скомпилировались,
* смотреть, как появляются новые фичи, ублюдски вставленные из-за того, что они могут ко-ко-конкурировать со старым говном,
* смотреть, как старый код плохо компилируется из-за того, что некоторое поведение всё же изменили, поскольку стандартизаторы понимают, что нельзя одновременно добавлять новые фичи, не исправляя старые баги.
Ну и сделали бы нормальные директивы.
И в новом стандарте вообще бы запретили компиляцию без указания языка в файле. Пусть каждый файл начинается как using lang::cpp++25; (для старых проектов будет работать питушня вида --std=c++11 внутри файлов проектов, для новых файлов using lang:: с --std=староеговно просто будет выдавать ошибку компиляции, с --std=что-тоновое using lang:: будет в приоритете, без спецификации языка в файле будет выдаваться ошибка.
Тогда можно будет ввести в язык островки адекватного синтаксиса.
Тогда ещё и версионирование либ надо делать, потому что оставлять говно в либах — пускать все улучшения в синтаксисе насмарку.
Назвать это С++ 3.0. Все увидят, насколько это лучше старого С++ 2.7 и быстро перебегут на не... Oh, wait...
А зачем? Ну будет в либе в заголовке int add(int, int);, а у меня в коде add :: (int, int) -> int для того же самого, и компилироваться будет в одно и то же.
И будет библиотека работать и сейчас, и через 10 лет, и через 50, когда придумают более понятный синтаксис, чем в хаскеле. Может, потом какая-то добрая душа перепишет заголовочный файл, чтобы программистам его было проще читать, поскольку int add(int, int); будут понимать только стариканы-зумеры.
А питонохолопы как раз соснули из-за того, что попытались сделать новый язык, который почти ничем не отличается от старого, но несовместим с предыдущим.
Таким образом, между "старым" синтаксисом и "новым" должно существовать как минимум инъективное отображение. Удачи описывать "адекватным" синтаксисом все элементы, которые я перечислила в комментарии ниже!
Ко-ко-ко, auto putux -> kurica!
> между "старым" синтаксисом и "новым" должно существовать как минимум инъективное отображение
Вообще проблем нет.
Можно сделать отображение из нового синтаксиса в старый, и тогда вообще можно внутренности и алгоритмы компилятора не трогать, решив все синтаксисопроблемы на уровне препроцессинга AST.
> Удачи описывать "адекватным" синтаксисом все элементы, которые я перечислила в комментарии ниже!
Какие в этом проблемы?
Хаскелеподобный синтаксис удобен для того, что используется сейчас. Пусть в нём будет уродливым какая-нибудь новая питушня сейчас, потом придумают вореант получше.
Только вот беда: как ты будешь делать отображение новых концепций в старый синтаксис? Как ты прикрутишь, няпример, концепты из C++20 в C++11 при помощи препроцессинга AST?
> Какие в этом проблемы?
Такие, что крестовый синтаксис сложен в первую очередь из-за огромного количества сложных и запутанных концепций, которые им описываются. Если ты попытаешься завернуть говно в обёртку от конфеты — оно ня прекратит вонять. Точня так же и твой новый синтаксис, как только ты попытаешься отойти от баняльных примеров и впихнуть в няго все крестовые сущности, будет абсолютня таким же говном, каким является и существующий.
А зачем? Почему Вы скатываетесь в крайности и покрываете макак, которым проще сделать auto putux -> kurica, чем подумать?
Сейчас же добавляют фичи, которые не реализуются кодом в старых версиях? Ну то есть ко-ко-концепты как-то добавляют? Значит и потом смогут.
Не обязательно все изменения реализовывать как переписывание AST, так же, как и не обязательно все изменения реализовывать как переписывание принципов в глубинах компилятора. Не обязательно также приводить AST к одному какому-то стандарту. Можно приводить к промежуточной версии, которую легче обрабатывать (скажем, привести к c++11, но с концептами и т.п.).
> как только ты попытаешься отойти от баняльных примеров и впихнуть в няго все крестовые сущности, будет абсолютня таким же говном
Сейчас крестосинтаксис - уже говно для банальных примеров современного кода. Пусть он хотя бы будет не говном для них! Никого не интересует 0.1% небанальных примеров, которые будут кодироваться говном.
Я внизу писал, что затем и нужно версионирование. 50 лет назад сишкосинтаксис был удобен для 90% того кода, который писали тогда, остальные 10% были редкими нетривиальными случаями. Сегодня хаскельный удобен для 90% современного кода, а сишный - для 10% кода, и если тупо перейти на него, то 80% кода улучшится. Через 30 лет сишкосинтаксис будет не говном для 0.1% случаев, хаскельный для 10% случаев, понадобится концептный синтаксис, его придумают и снова 80% кода будет описываться адекватно.
Не был.
> Сегодня хаскельный удобен для 90% современного кода, а сишный - для 10% кода
Неправда. Оба — говно.
Адекватного по мнению кого?
И как, няпример, в "адекватный" "binary : t => (t, t) -> t" влезут нятипичные параметры, параметры со знячением по-умолчанию, шаблонные шаблонные параметры, вариадические параметры, нятипичные параметры с автовыводом типа, ограничения, концепты, явная специализация, частичная специализация, внешняя инстанциация?
Вот как только всё это (и остальное) впихнёшь в свой "адекватный" синтаксис — получишь точня такое же говно, как и было. Только теперь вместо одняго говна будет два.
Восклицания по типу "почему они ня могли взять и сделать просто?!" — это всего лишь последствия https://ru.wikipedia.org/wiki/Эффект_Даннинга_—_Крюгера .
> Адекватного по мнению кого?
По мнению пользователей этого синтаксиса. Как минимум, по мнению тех, кто учился читать типы в сосишке по спирали и долго запоминал, чем в смысле записи константный указатель отличается от указателя на константу, а массив указателей - от указателя на массив.
Синтаксис со стрелочкой гораздо короче, и проще описывает питушню с функциями и полиморфными типами
> И как, няпример, в "адекватный" "binary : t => (t, t) -> t" влезут
Можно взять хаскелевский и как-то модифицировать под нужды крестопердоликов (может быть, по-другому, а не как у меня). Там уже есть и функции, и массивы, и шаблонные шаблонные параметры, и интерфейсы/концепты, и всё это не воняет как int *a[10].
> как только всё это (и остальное) впихнёшь в свой "адекватный" синтаксис — получишь точня такое же говно
На то и версионирование.
Сишкопарашный синтаксис родился во времена, когда у императушков структурное программирование было последним достижением, а на серьёзные программы в функциональном стиле не хватало мощностей, и передача указателя на функцию сложения была наивысшим уровнем абстракции. Сишкозапись типов начинает вонять и ломаться уже на многомерных массивах и ФВП, а к нему сейчас прикручивают шаблоны и ко-ко-концепты, появляются мёртворождённый конструкции вида "auto ... -> pitux".
Возможня.
> проще описывает питушню с функциями и полиморфными типами
Разумеется, нят. Парсить даже приведённые тобой самые примитивные псевдохаскеллевские цепочки ничуть ня проще, чем простые крестовые шаблоны. Даже более того, приведённый тобой крестовый шаблон гораздо лучше структурирован, чем куча-мала из стрелочек из скобочек, потому что каждая строчка шаблона содержит самостоятельную и изолированную его часть: список параметров, сигнатура и тело. В твоём же "адекватном" все эти части сливаются в одну нячитаемую кашу.
> Можно взять хаскелевский и как-то модифицировать под нужды крестопердоликов
...и, как тебе уже нясколько раз попытались объяснить, получится ещё одно сложное и запутанное говно, единственное преимущество которого будет в том, что оно будет чуть-чуть более знакомо программистам ня Хаскелле.
Хорошо, можно использовать просто хаскельный синтаксис.
> каждая строчка шаблона содержит самостоятельную и изолированную его часть: список параметров, сигнатура и тело
С точки зрения сишкораба, который мыслит исходя из крестосинтаксиса. Но всегда можно привыкнуть к лучшему.
Не факт, что список параметров и сигнатура - объективно изолированные часть. Всё это - лишь аргументы функции, просто некоторые из них - типы, а некоторые - значения.
И не надо придумывать между ними разницу вроде "одни вычисляются на этапе компиляции, а другие - на этапе исполнения". Грань между этим размыта. Скажем, f(2) при заинлайнивании может ничем не отличаться от инстанцирования f<2>(), а благодаря динамическому полиморфизму вполне можно передавать типы как аргументы.
JIT вовсе рахмывает эту грань.
Ну и разделять аргументы-значения и аргументы-типы - значит ограничивать мышление, какой-то пользы от этого нет.
> В твоём же "адекватном" все эти части сливаются в одну нячитаемую кашу.
> как тебе уже нясколько раз попытались объяснить, получится ещё одно сложное и запутанное говно
Я же несколько раз говорил, что придумают получше и добавят.
> будет чуть-чуть более знакомо программистам ня Хаскелле.
И программистам на крестах, когда перейдут. Если есть возможность выбрать из двух равноправных вариантов, один из которых на 80% удобнее, программисты перейдут.
?
Кстати, про C:*=>*. В C++ можно описать только kind для параметра шаблона, который является шаблоном. Это вообще какая-то питушня. Нельзя описать питушню над контейнером интов или получить из одного параметра сразу и тип контейнера, и тип элемента.
Вместо того, чтобы паттерн-матчить
нагородили std::stlpitux::value_type.
foo(vector<int>) не должен скомпилироваться.
Но вообще я же просто перевёл.
Если надо, можно ввести синтаксис вида C:*...=>* для шаблонов или просто C:template или C:(=>), когда не важно, там шаблон от пары аргументов, шаблон от шаблона или шаблон от чёрт пойми чего.
Ты только что гранату. Ещё пару десятков таких примеров — и мы получим второе крестоговно, поздравляю!
Что за чёрно-белый мир, тётя Полина?
Нельзя совсем сделать без говна, но можно сделать так, чтобы говно приходилось на те куски кода, которые составляют редкие случаи, а мейнстрим был без говна.
То, что ты ня этом сайте видишь мозговзрывающее многоуровневое крестоговно — всего лишь следствие того, что простое и понятное крестоговно выкладывать скучня.
Это да
> Оставшимся 90% строчкам хватает простых и по-ня-тных синтаксических элементов.
Может быть потому, что сложный синтаксис затрудняет мышление, и приходится скатываться к примитивным конструкциям, которые громоздкие, но выглядят цивильно?
Когда простой скриптух или сложный хаскелюх пишет универсальную функцию сложения чисел, он особо не задумывается о происходящем.
У него получается сразу полиморфная функция, а в случае хаскеля - полиморфная, но даже с дофига строгой проверкой типов.
И на крестушне эта концепция выражается только в несколько строк, которые потом всё равно ради полиморфизма приходится перебивать на шаблон. А в хаскеле тот же "шаблон" был всегда и в одну строку.
Это всего лишь следствие применения сложного инструмента к примитивному случаю.
> он особо не задумывается о происходящем
И имення в этом и проблема: если тебе ня нужня задумываться о происходящем в коде, то гораздо эффективнее писать ня JS, Питоне и прочем скриптоговне.
Но вот как только тебе понядобится иметь парочку разных специализаций "универсальных" функций (баняльно: функция суммирования элементов массива, которая целые числа складывает няивно, а плавающих петухов — алгоритмом Кэхэня, няпример) — скриптоговно уже ничего предоставить ня может (inb4: if isinstance(x, float): ...).
Ну а когда появляются специализации шаблонов — появляется и разделение ня объявления/определения, и предварительные объявления, и внешние объявления, и частичные специализации... И так до тех пор, пока ня получим C++.
> И имення в этом и проблема
Нет. Проблема - когда я не задумываюсь и пишу какую-то питушню, которую потом надо будет допиливать - как int add(int, int) в C++. Проблемы нет, когда я не задумываюсь, а в языке работают полезные умолчания - как add x y = x+y в Haskell.
> иметь парочку разных специализаций
> скриптоговно уже ничего предоставить ня может
Потому, что там нет компайл-тайм вывода типов и кодоподстановки, да. Но причём тут синтаксис?
> как только тебе понядобится иметь парочку разных специализаций "универсальных" функций
Можно будет реализовать через классы типов.
Псевдохаскель:
А никто так и ня пишет. В реальном коде ня C++ ты практически всегда сразу понимаешь, какая функция/структура должна быть шаблонной, а какая нят.
Ну и раз уж говорить про умолчания...
> Но причём тут синтаксис?
При том, что синтаксис должен это предусматривать.
> Можно будет реализовать через классы типов.
Ну вот, примитивную, базовую концепцию из C++ нячали реализовывать какими-то "классами".
Ну, синтаксис специализации шаблонов - это наверно меньшее, что нужно разработать при реализации специализации.
> примитивную, базовую концепцию из C++ нячали реализовывать какими-то "классами".
А теперь давайте алгебраические типы и паттерн-матчинг без пердолинга в C++ реализовывать.
Хотя, не факт.
Как развивался C++? Давным-давно была сишка, из неё унаследовали синтаксис, куда потом добавляли новые возможности, которые только что придумали, и раньше о них не знали.
Как будет развиваться новый синтаксис? Все возможности уже известны (может, не мне, но ко-ко-комитету - точно), с учётом них разработают несколько вариантов синтаксиса, обкатают, исправят, выберут лучший и внесут в стандарт.
Это как рефакторинг, только на уровне синтаксиса.
«Все, что можно было изобрести, уже изобретено», – сказал в 1899 году сотрудник Патентного ведомства США Чарльз Дуэл.
Ты просто ня понимаешь, что выразить все концепции C++ и ня получить при этом такого же монстра, какой и был, попросту нявозможня.
> Ну и разделять аргументы-значения и аргументы-типы - значит ограничивать мышление, какой-то пользы от этого нет.
Пожалуйста:
Осилишь такое же, но без разделения параметров-знячений и параметров-типов?
> придумают получше и добавят
Тогда чем твои предложения отличаются от зняменитого "Взять всё и поделить"?
Удивительня: дурачки-крестостандартизаторы ня осилили сделать адекватный синтаксис! Какой адекватный? Так пусть они и придумывают!
Ну сколько можно повторять?!
1. Вероятность того, что в одной строке (да и даже в одном файле) понадобится описать все концепции, крайне мала.
2. Один синтаксис будет хорош 50 лет назад (как текущий), другой - сейчас, через 50 лет придумают что-то новое.
3. Если 90% кода будет выглядеть не как говно, новый синтаксис аппрувед.
> Осилишь такое же, но без разделения параметров-знячений и параметров-типов?
Ну это просто так повезло, что синтаксически описалась такая ситуация.
А как насчёт получения STL-коллекции и типа элемента? Кресты соснули и не смогли.
И ещё тут передача двух бесконечных списков, осуществлённая через скобочки разной формы. А если бы надо было передать три списка, кресты бы соснули.
Во-первых, если надо передавать кучу гомогенных списков, границу между которыми невозможно обозначить, надо вводить какой-то разделитель между ними, чтобы было универсально:
А так, можно было бы сделать
Дальше можно на этапе компиляции дедьюсить, константа ли, и на основе этого разрешать выражения вида int xs[SIZE], или нет. Тем более, что всяких constexpr понавели, и проблему как-то прощупали.
Только вот беда: все твои придирки, высказанные в этом треде, относятся к древнему няследию сишки, которое в 99% кода ня современных крестах ня используется.
Массивы — std::array, функции — std::function, указатели — std::unique_ptr или &.
Благодаря эим сущностям видеть сишную спиральную лапшу в современном C++-коде приходится очень редко, и 90% кода выглядит как ня говно. Ergo, по твоему же собственному определению, старый синтаксис аппрувед.
> Ну это просто так повезло, что синтаксически описалась такая ситуация.
А в твоём новом суперкрутом синтаксисе тебе придётся это поддерживать. И чтобы без говна!
> А как насчёт
Мы обсуждаем новый синтаксис, а не как что-то сделать в старом.
Какой багор )))
std::function<a (*) (b,c,d)>, или как оно там, вместо (b,c,d)->a или b->c->d->a с каррированием.
std::array<petux, kurochka> вместо, скажем, [petux:kurochka]
> А в твоём новом суперкрутом синтаксисе тебе придётся это поддерживать.
Зачем? Зачем? Какие-то редкие случаи можно описать и в старом синтаксисе, я же как раз за универсальность.
> И чтобы без говна!
Зачем? Зачем? Какие-то редкие случаи могут быть и с говном.
Ну и один синтаксис может описывать лучше одну парадигму, а другой - другую.
Если кресты могут описать что-то большее только за счёт введения более удобного синтаксиса, то почему бы это не сделать?
Но вообще все эти типы, которые тут мелькали в комментариях (даже с концептами), легко можно описать с новым простым синтаксисом.
Питушня из нескольких комментариев выше вполне записывается как
И это однозначно соответствует описанной шаблонушне.
Смешение компайл-тайм аргументов и рантайм-аргументов - это да, это более серьёзный шаг, это уже не просто перестановка узлов в дереве.
std::function<a(b, c, d)>.
> вместо (b,c,d)->a или b->c->d->a с каррированием
> вместо, скажем, [petux:kurochka]
Ну вот, собствення, уже пошла чистая вкусовщина.
> Какие-то редкие случаи можно описать и в старом синтаксисе
Затем, что твой синтаксис должен поддерживать все концепции старого. Иняча никак ня получится сделать прозрачное использование старых библиотек, и привет, 2.7.
> Values...: int, Types...
Очень простой, понятный и однязнячный синтаксис (нет).
Почему-то двоеточие после "foo" ознячает список параметров шаблона, а после "Values..." — что? Тип параметра?
> Если кресты могут описать что-то большее только за счёт введения более удобного синтаксиса, то почему бы это не сделать?
Потому что синтаксис — это вторичное, в основе языка лежат его сущности и концепции. Введение нового синтаксиса может максимум добавить сахарку, но добавить "что-то большее" — нят.
> (b,c,d)->a
> вкусовщина
Джва ряда скобочек! Джва, Карл!
Функцию a(b, c, d) зачем-то кастуют в функцию ещё раз, как будто a(b, c, d) - уже не функция.
Функция от функции в таких терминах - уже монстр.
> Затем, что твой синтаксис должен поддерживать все концепции старого. Иняча никак ня получится сделать прозрачное использование старых библиотек, и привет, 2.7.
Зачем, почему? Ну будут какие-то специфичные вещи писать в старом синтаксисе.
Хотя, почему? Не всегда хитрожопый синтаксис, который использовался для реализации и определения, надо использовать при использовании.
template<питуш...ня, питуш...ня>(питуш...ня) будет описано в заголовочном файле в старом синтаксисе, а использование - foo(1,2,3)(int{},float{}) - будет в новом синтаксисе, и будет гармония.
>> Values...: int, Types...
> Очень простой, понятный и однязнячный синтаксис (нет).
> Почему-то двоеточие после "foo" ознячает список параметров шаблона, а после "Values..." — что? Тип параметра?
Двоеточие разделяет значение и его тип!
foo имеет тип (Values...: int, Types...) => Types... -> void
Values... имеет тип int. Ну, хотя, над многоточиями надо подумать. Может быть, писать Values: int... или Values...: int..., или ещё как-нибудь.
Двойная стрелка разделяет компайл-тайм-аргументы и компайл-тайм-результат функции.
Одинарная стрелка разделяет рантайп-аргументы и рантайм-результат функции.
Всё просто и регулярно.
Консистентность. То, что тебе это ня нравится — исключительня твои проблемы.
> Зачем, почему? Ну будут какие-то специфичные вещи писать в старом синтаксисе.
Затем, что иняче твой новый синтаксис будет нясовместим со старыми библиотеками. Результат — 2.7.
> Всё просто и регулярно.
А как в этом виде записать объявление, определение, внешнее объявление, дружественное объявление, частичную специализацию, явную специализацию, внешнюю специализацию?
1. Как уже говорил, не всегда хитрожопый синтаксис, который использовался для реализации и определения, надо использовать при использовании.
2. Погодите, 2.7 случился из-за того, что совместимость сломали совсем, и нельзя было написать одну половину файла на 2, а другую - на 3. Да даже один файл на 2, а другой - на 3. Я предлагаю так не делать, а включать разные фичи языка в разных частях проекта.
Старая библиотека требует себе "const char *", а у тебя в новом указатели выкинуты в угоду ссылкам (няпример). Как результат — ты ня можешь передавать объекты из своего кода в старую библиотеку, и совместимость с крахом ломается. И это только самый баняльный пример.
> Я предлагаю так не делать, а включать разные фичи языка в разных частях проекта.
Только если старая версия требует каких-то концепций, которые в новой за нянужностью выкинули, то совместимость ломается полностью, и никак это ня исправить, оставаясь в парадигме zero-cost.
В JS и вообще скриптоговне это решается просто: всем плевать ня производительность. Вон, нясколько сторонний пример: в "Kotlin" взяли да исправили billion-dollar mistake, сделав null-safety ня уровне языка... путём няявного добавления в нячало каждой функции проверки аргументов ня null. Для C++ такое решение принципиальня нядопустимо.
С STL vs C-тушня тоже так же случилось. Надо вытаскивать из STLюшни указатели и передавать старушне. Да, будут такие моменты иногда.
> оставаясь в парадигме zero-cost
> путём няявного добавления в нячало
Надо флаги. safe, unsafe и т.п.
Добавляешь флаг - и переполнение знаковых интов начинает проверяться или просто работать, например.
Добавляешь флаг - и включается режим "одна ошибка - и ты ошибся" для пердоликов, знающих все закоулки стандарта.
> в парадигме zero-cost
Когда программисты и пользователи - рабы, и их время, потраченное на борьбу с UB и последствиями UB, ничего не стоит.
Ну да, только C и C++ — это два разных языка. Никто ня планировал (в здравом уме), что все сишники возьмут да перейдут ня C++.
А вот ты планируешь, что ня новый синтаксис можня будет просто взять и перейти, ничего не ломая.
Увы, но так ня работает, и Python это показал. Казалось бы, что там такого — скобочки вокруг print поставить, пару импортов переименовать да raise по регулярке исправить, делов-то? У тебя получается то же самое: получаются някоторые моменты, которые ня работают. Результат — разбиение языка ня два нязависимых.
> Надо флаги. safe, unsafe и т.п.
А зачем? Если тебе плевать ня производительность, но ты всё равно пишешь ня C++ — ты делаешь что-то очень сильно неправильня. Не в том смысле, что ты плохой, разумеется, а в том, что ты пытаешься забивать шуруп кувалдой. Ня проще взять шуруповёрт?
> UB
Zero cost — это совершення ня про UB. Ня повторяй мантры.
> Увы, но так ня работает, и Python это показал
Питон откинул совместимость. Можно так не делать.
На новый синтаксис задания типов вполне можно перейти, даже сделать его однозначно соответствующим текущему.
Если реализовать гранулированно, то можно просто не все фичи включать за раз, какие-то редкие питушни описывать с использованием старой фичи.
> Если тебе плевать ня производительность, но ты всё равно пишешь ня C++
Так не плевать же, а просто хочется настраиваемости. И универсальности.
Некоторые UB можно спокойно конпелировать как есть, поскольку та орхетектура, для которой это было бы UB, уже либо вымерла, либо почти не встречается. Или встретится, когда программу будут компилировать через 100 лет, когда компьютеры будут в 100 раз мощнее, и потеря 5% пирфоманса никого не испугает.
Но вообще, это же язык общего назначения. Я могу на нём реализовать супероптимизированную библиотеку с вылизанным кодом, а потом написать какую-нибудь дистпечерную питушню вроде крона, где важнее не производительность, а надёжность.
Напоминаю, что серебрянной пулей можно только застрелиться.
Что меня больше всего раздражает в программистах - их странные языческие верования. Вот вроде бы представители самой точной науки, а ведут себя как суеверные бабки. И это не только башной фольклор вроде "танцев с бубном", а это вера в заклинания.
Программист верит, что если он произнесёт заклинание "проблема постанова" или "тут рудоёмкость Ё(Ы^10) литров" или "но это же не Юрик-полный язык" или "сурьмяная дуля" или "эффект Данилы-Рюмкина", то вдруг все вокруг испугаются, алгоритм перестанут реализовывать, язык забросят и всё такое.
Программист начинает со свободного мышления, но из-за того, что он в силу малого опыта пишет говнокод, на него начинают влиять окружающие. Вместе с логичными призывами не писать говнокод и какими-то здравыми мыслями программисту втирают какую-то дичь о том, что глобальные переменные и goto нельзя использовать, алгоритмы с Ё(exp(Ы)) плохие и т.п. Поскольку во входящем потоке есть полезная информация, программист начинает верить в то, что ему говорят - вместе с полезными практиками программирования он запоминает установки про проблемы постанова. Он даже не проверяет информацию, которую ему втирают.
Когда программист вырастает и начинает обучать своих будущих коллег, он переносит на их плечи изученные установки. Не важно, какое-то правило идёт от практики и имеет ограниченную область применения (и не факт, что актуально сейчас), либо от далёкой от жизни теории, всё преподносится как закон. Возникает программистское язычество с идолами, заклинаниями и нерушимыми законами.
> сурьмяная дуля
> эффект Данилы-Рюмкина
Хороший разбор секты погромистов шаманоидов, cодержащий интересные синтаксиалье находки.
По сути верно, погромист аналогично колдуну входит в состояние транса, в котором он способен общаться с духами живущими в компьютерах, на их машинном языке.
И вот эти странные повадки, комманды напоминающие заклинания «ахалай махалай», «сим салабим» и прочая «абракадабра», которой погромист задабривает компьютерных духов и демонов.
И тем самым сделав кресты ещё более монструозным и сложным говном, хотя казалось бы — куда уж больше?
Теперь, после такого гипотетического "апгрейда", чтобы понимать код ня крестах, нужно знать оба синтаксиса, причём со всеми их нюансами. Боюсь, даже те три человека, которые сейчас живут ня планете Земля и зняют современные кресты полностью, ня осилят такую радость.
> настраиваемости. И универсальности
У любого языка — как и у любого инструмента в общем — есть область применимости. Пока будет существовать больше одняго языка — какой-то из них будет удобнее использовать в области высокой производительнясти, а какой-то — в области создания веб-сайтов. Любые попытки создать серебряный язык заранее обречены ня провал, а лучшее, чего можня добиться — это сделать универсальный язык, одиняково няудобный для любых применений (см. древние ассемблеры, кроме которых ещё ничего ня было).
> язык общего назначения
"Общее нязнячение" — это просто бессмысленный в контексте обсуждения ярлык, примерня как "язык высокого уровня". Он имеет смысл только во время обсуждения всяческих DSL.
> Я могу на нём реализовать супероптимизированную библиотеку с вылизанным кодом, а потом написать какую-нибудь дистпечерную питушню вроде крона, где важнее не производительность, а надёжность.
А ещё можня взять гирю и забивать ею шурупы. Только зачем?
> даже те три человека, которые сейчас живут ня планете Земля и зняют современные кресты полностью
Взаимоисключающие параграфы?
Ну то есть сейчас на крестах пишут (N-3) человека и полностью их не знают, а тогда - вот прям раз и понадобится знать оба синтаксиса.
Ну максимум кто-то глянет на Википедии, что за питушня, когда встретится со слишком старой/новой библиотекой.
> У любого языка — как и у любого инструмента в общем — есть область применимости.
То есть у C++, где переполнение знаковых - не УБ, - это уже настолько далёкий от C++ язык с настолько далёкой от C++ областью применимости? Как только разрешили переполнение знаковых, C++ стал анскильной скриптушнёй, никому больше не нужны шаблоны, круг задач слишком изменился?
Ну что за питушня? Вам самой-то не смешно?
Существует целый спектр от C++ с более строгими правилами (например, с запретом на (1+1.0) и на (x[y]), пока не доказано, что 0 <= y < size(x)) до безопасного C++ (где UB заменены на DB). И на всём этом спектре найдутся пользователи, которым понадобится остальные фичи языка.
Ко-ко-ко! С друзьями на балах я говорю на французском, с неотёсанными холопами - на русском, научные статьи пишу на немецком, а рецепты - на латинском, и можно было бы попробовать использовать один язык, но это как взять гирю и забивать ею шурупы.
А всё почему? Потому, что Вы привыкли к текущей ситуации, где синтаксис, функциональность и область применения надёжно прибиты друг к другу. И в этом мирке считается разумным писать скрипты с долларами, прототипы - с двоеточиями и отступами, а сложную питушню - с фигурными и угловыми скобками.
Но это в общем случае неверно и просто дико. Просто пошла традиция придумывать новый синтаксис, когда хочешь создать новые фичи. Также раньше было нетривиально прикручивать разные синтаксисы к одному и тому же языку и разные языки к одному и тому же синтаксису. Поэтому создались такие болезненные ассоциации, что двоеточие - это одно, а фигурные скобки - другое.
Ну да, это же замечательная идея: взять и так чудовищно сложный язык и сделать его ещё сложнее: исключительня потому, что тип возврата перед функцией — это ня модня.
> Как только разрешили переполнение знаковых, C++ стал анскильной скриптушнёй
> Ну что за питушня? Вам самой-то не смешно?
https://en.wikipedia.org/wiki/Straw_man
Повторюсь: zero cost и UB — понятия ортогоняльные. Ня повторяй мантры.
> Потому, что Вы привыкли к текущей ситуации, где синтаксис, функциональность и область применения надёжно прибиты друг к другу. И в этом мирке считается разумным писать скрипты с долларами, прототипы - с двоеточиями и отступами, а сложную питушню - с фигурными и угловыми скобками.
Потому что синтаксис — всего лишь обёртка для функциональности, он вторичен. Создать же универсальный синтаксис, который был бы удобен везде, в принципе невозможня, поскольку в программировании слишком много различных концепций. То, что удобня и хорошо для разработчика под микроконтроллеры будет адом для фронтендера — и няоборот.
Ты попросту ня понимаешь, что каждой концепции языка всегда соответствуют какие-то элементы синтаксиса. В языке ня может существовать "фич", для которых нят соответствующего синтаксиса — иняче бы эти фичи было бы невозможня использовать. И чем больше в языке содержится концепций — тем более сложным и запутанным становится синтаксис.
Вот, няпример, в Лиспе концепций очень мало (оригиняльная статья с описанием этого языка занимала, кажется, страниц восемь), поэтому его синтаксис очень простой. И няоборот: в C++ запихали монструозное количество концепций (от низкоуровневого битонякства и до высокоуровневой параллельщины, ФП, ООП и прочих больших букв), и в результате его синтаксис превратился в перегруженное говно — исключительня из-за того, что все эти концепции нядо чем-то выражать.
Поэтому, твои мечты о Едином Языке (to rule them all), который будет поддерживать все существующие концепции (а иняче он ня будет универсальным) — всего лишь мечты. Даже если такой язык и сделать — в нём будет нястолько чудовищный синтаксис, что кресты покажутся брейнняком.
1. Концепции можно выносить в библиотеки. Например, в питоне не нужно ООП, достаточно словарей, ФВП и функций с **kwargs. А дальше
Person = Class(
name=str,
age=int,
hello=lambda self: 'hello, I am %s' % self['name']
)
he = Person('Anton', 10)
she = Person(age=20, name='Anna')
Employee = Class(
super=[Person],
salary=decimal,
hello=lambda self: 'hello, I am paid %s per year' % self['salary']
)
2. Можно впилить гомоиконность/пользовательский синтаксис и впиливать новые концепции в отдельных библиотеках по мере поступления.
Кому понадобится - напишет свою питушню на диалектах.
> в Лиспе концепций очень мало
Концепция - это "мы взяли нерасширяемый недоязык, и теперь чтобы сказать что-то почти новое, нам надо вставить туда нелогичную синтаксическую питушню"?
Как вообще в языке с ГОМОИКОННОСТЬЮ может быть меньше концепций, чем в фиксированном языке который от расширения становится говном? В языке с ГОМОИКОННОСТЬЮ бесконечное количество концепций.
> всего лишь мечты.
> в нём будет нястолько чудовищный синтаксис, что кресты покажутся брейнняком
Ну не факт. По крайней мере, для уже известных концепций всё будет проще, для новых будет гомоиконность, а потом, когда язык совсем зашкварится и устареет, просто сделают переходник и новый язык.
Исключительно потому, что эта питушня сгнивает как только пишешь что-то не самое тривиальное, из-за чего тормозит развитие языка и его пользователей.
> Straw_man
Какое-то заклинание на непонятной мове.
> подмена тезиса
Я комментарии не редактировал.
> Повторюсь: zero cost и UB — понятия ортогоняльные. Ня повторяй мантры.
Тогда о чём спорить? Пусть будут флаги, которые делают DB из UB с zero cost.
Быстрый код без UB лучше, чем быстрый код с UB. Разработка на C++ станет дешевле раза в три, мы получим либо в три раза больше новых фич, либо код в три раза стабильнее.
Однако тут не важно, zero cost, UB или ещё какая-то питушня. Флаги всё равно нужны. Пользователю C++ с задачами из круга применимости C++ может понадобиться
* компиляция под дофига платформ
* быстрый код на одной платформе
* чуть менее быстрый, но надёжный код
* очень надёжный код
* отладочная версия кода
Если в C++ по флагу не будет UB или будет вставлена проверка на nullptr этим будут пользоваться и довольно активно.
Ну то есть если я пишу int x[10], должен создаться std::array<int, 10> x;
А сишноговённое int x[10] должно быть nonstd::unskill_carray<int, 10> x;
И чтобы с приходом лямбд во всех функциях появились замыкания. Со старыми бинарниками можно пробовать склеивать по именам. Скажем, в новые функции вставлять в имя какую-то питушню-маркер, а при компиляции искать в бинарнике имена с питушнёй и без, и вкомпиливать найденные.
> Останутся все крестовые библиотеки
Либо трусы надень, либо крестик сними. Ломаешь ли ты всю совместимость, изменяя поведение существующих синтаксических конструкций, либо сохраняешь совместимость со старым кодом. Поддержка legacy — один из основных источников говна в стандарте С++.
вы кажется придумали примитивные типы и анбоксинг
> во всех функциях появились замыкания
Снячала сделай GC.
2. Каждый синтаксис будет иметь свою оптимальную точку. Для сишного это одномерные массивы и функции от пары простых аргументов. Для хаскельного это ФВП и шаблоны. Нормально использовать тот синтаксис, который будет уместен в данной конкретной ситуации, если нет какого-то одного хорошего для всего (как хаскельный сейчас). Когда у тебя куча фнукций от одного-двух интов, удобнее использовать сишный. Когда куча ФВП и полиморфных - хаскельный. Когда в традициях программирования будут главенствовать концепты, будут использовать соответствующий синтаксис для них, даже если в нём будет чуть более громоздко выражаться обычная функция типа (a,a)->a.
И надеяться, что синтаксис и правила будут актуальны 100500 лет, и к ним можно безболезненно присобачить новые фичи, оставаясь в рамках тех же правил - это уже не эффект Питуханинга - Путуюнера, это уже клиника.
Сейчас есть куча несовместимых как синтаксически, так и бинарно/концептуально языков.
А я предлагаю хотя бы только чуть синтаксически несовместимости оставить. И то, эта несовместимость будет только в головах, а компилироваться будет аж бегом.
> чем это лучше, например, чем бросить кресты и перейти на раст
Останутся все крестовые библиотеки.
> а потом на питухон когда надо быстро что-то запрототипировать
Не придётся переписывать с нуля основную версию. Можно запрототипировать, а потом отрефакторить.
У мультиязычника будет
1. рабочий прототип,
2. ничего,
3. ничего,
4. код с кучей затычек,
5. готовая программа.
У моноязычника будет
1. рабочий прототип,
2. тормозная программа с нужными возможностями,
3. программа, где только половина фич тормозит,
4. программа, где только четверть фич тормозит,
5. готовая программа.
> написать программу на лиспе, когда это понадобится, использовать хаскель, когда будет удобно
Ну вот тут не знаю. Может и правда придётся остаться на этих языках, т.к. парадигма сильно другая. Хотя, я уже давно говорил о том, что нужны сменные языки как в дотнете.
> битоёбить на ассемблере для какой-то встраиваемой петушни
А вот с ассемблерными вставками наверно проблем нет. Если ещё сделать директиву using lang::, которая притворяется комментарием, такой код можно будет компилировать и как кресты, и как ассемблер.
0. просто system/popen, внешний код видит код возврата и максимум содержание потоков (можно сделать автоматически для всех языков сразу)
1. обёртывание функций и переменных и бесшовное взаимодействие с движком языка (по умолчанию - автокаст вроде dynamic_cast, но доступна питушня вроде std::python::object
2. использование синтаксиса языка для обозначения концепций из C++ (вроде хаскелевского синтаксиса для компактного описания простых типов, который можно однозначно перевести)
лучше уже просто сделать новый фронтент для LLVM и назвать его rustc++++
C8===
Ну или просто создать язык, компилирующийся в C++. А потом, когда новый язык будут использовать все, а C++ останется только на правах ассемблера где-то в недрах компилятора, комитет всосёт его в стандарт C++ как STL и Boost, а компиляторщики просто вмёрджат в себя опенсорсные реализации.
В веб-питушне так уже давно живут. Есть и куча питушни, компилирующейся в JS, и возможность писать на ES поновее. То есть то, о чём я говорю, вполне реализуемо на практике.
Видимо, дело в том, что в веб-мире больше более молодых людей, которые отказываются жрать говно, а в крестомире больше смирившихся стариков.
И полагаться на мнение компиляторопитухов глупо, поскольку C++ делается для программистов, а не для макак-компиляторщиков, которым проще влепить пару иф-ов в коде, чтобы обработать auto pitux -> kurica, чем подумать и сделать что-то цивильное.
Нят, дело в том, что JS — это крайне примитивный язык. Безо всяких нягативных коннотаций, по уровню примитивности он стоит где-то рядом с сишкой. Поэтому и альтернятивные реализации для няго могут делать студенты в качестве лабораторной, и нядстройки вроде TS появляются.
C++, в противовес JS, — это огромный, древний хтонический монстр, создание конформного компилятора к которому — задача ничуть ня проще проектирования ракеты. Просто няпоминаю, что даже определение синтаксической корректности программы ня С++ эквивалентно проблеме останова.
Язык, компилирующийся в C++, — это совершення безумная идея, потому что тогда программисту придётся воевать ня только со своим языком, но ещё и с багами компилятора C++ (а любая крестовичка, няписавшая больше трёх строк ня C++, точня сталкивалась с багами в крестокомпиляторах).
Более того, один из главных плюсов TS — это то, что любая программа ня JS является валидной программой ня TS. С JS это работает по всё той же причине: JS — это очень простой язык, ня засранный мозголомающими концепциями. Соответствення, его можня достаточня просто расширить и получить что-то удобное.
А вот о каких попытках расширить синтаксис C++ может идти речь, если в крестах уже все скобочки перегрузили во всех местах где только можня...
JS мощнее крестов и лучше подходит как таргет для компиляции. Это не имеет никакого отношения к примитивности
И что?
Почему математика окрыляет математиков, но прибивает программистов к земле?
Зачем все эти вскукареки про полноту Питуринга и питухемы питунова?
Пока праграмисты, возомнившие себя знатоками математики, кукарекают, компилятор крестов компилирует код. Несмотря на всякие питухемы.
> Язык, компилирующийся в C++, — это совершення безумная идея
Вообще, в крестопитушне так уже давно живут. Каждый, кто написал на C++ хоть сколько-нибудь полезную программу (использующую ввод/вывод), писал её не на C++, а на языке, который компилируется в C++, и программа на самом C++ является валидной программой на этом языке!
Эта безумная идея передалась крестам ещё от сишки. Все программисты на сишке тоже пишут на промежуточном языке, который компилируется в сишку!
Эта питушня настолько популярна, что встроена в стандарт и переплелась с самой сишкой. Например, питушня stdin должна быть символом языка, компилирующегося в сишку.
> А вот о каких попытках расширить синтаксис C++ может идти речь, если в крестах уже все скобочки перегрузили во всех местах где только можня...
Ну я же написал, как!
using lang::newsyntax { тут любая питушня }.
Ну или если говорить для людей, которые понимают буквально и читают не концепции и подходы, изложенные в моих комментариях а придираются к тексту, то using std::lang::newsyntax { ... }. std-питушня остаётся за авторами стандарта, и никаких конфликтов не будет, если новый синтаксис будет лежать в std.
Это «Nim».
> создание конформного компилятора к которому — задача ничуть ня проще проектирования ракеты.
Почему-то мне кажется что ракета будет попроще.
Видимо, дело в том, что если на осла навесить картонный рог, бумажные крылья и покрасить в яркие цвета, он не станет мультяшной пони. Может, вместо того, чтобы пытаться кардинально переделать существующий язык (кстати, нахрена, ради названия, бренд сохранить?), стоит потратить силы на разработку нового, в котором всё будет как надо и не надо будет пердолиться с совместимостью?
Новых языков и так кучу наплодили зачем-то. Теперь приходится пердолиться как с совместимостью внутри одного языка, так и с несовместимостью библиотек. Но зачем?
Почему нельзя тогда все императивные языки с ГЦ свести в один, без ГЦ - в один, все функциональные - в один, и т.п.? Хотя, дотнет смог вместить в себя и императушню с ГЦ, и функциушню. Надо использовать библиотеки между языками без пердолинга.
Чем так сильно различаются python и JS, что я не могу без каких-либо проблем использовать библиотеки от одного в другом? Тот же движок, та же питушня с динамической питуизацией и ГЦ, единственная разница - в питоне 1+'a' бросает исключение, а в жс - возвращает '1a'.
ASD_77, мы нашли твоего первого пользователя
>В веб-питушне так уже давно живут
То что делают в вебе отличается от того что предлагаешь ты
>Видимо, дело в том, что в веб-мире больше более молодых людей, которые отказываются жрать говно
Авторы ts прямо заявляют что их система типов не sound и не планируется быть таковой. Таким образом, ts специально изговнили чтобы "молодые люди отказывающиеся жрать говно" начали его адоптить. Качество жсного мейнстрим тулчейна (вебпак, бабель, тайпскирпт) настолько низкое что использовать его - это буквально жрать говно и приводить его в пример неприлично
>И полагаться на мнение компиляторопитухов глупо, поскольку C++ делается для программистов, а не для макак-компиляторщиков
Ты что, ни разу не работал над проектом больше 300к строк кода? Не знаешь как все в больших проектах устроено?
Ну, качество крестушни (смотря как понимать этот термин) тоже не очень.
Поведение, когда компилятор говорит про ошибку так, что её текст надо запоминать наизусть, ничем не лучше, чем поведение глючного инструмента с багами. Что там, что там придётся попердолиться, чтобы понять, что же, чёрт возьми, случилось.
Или компиляция питушни, состоящей из старого и не очень говна под новой версией компилятора, когда надо подбирать флаги и пердолиться с файлами сборки.
> Ты что, ни разу не работал над проектом больше 300к строк кода? Не знаешь как все в больших проектах устроено?
А тут не проект, тут метапроект. Тут человекочас конпеляторного питуха становится человекогодом у программистов.
Ну вот C++ уже давно хорошо работал, с введением decltype и rvalue references он уже стал достаточно универсальным, когда можно в любой момент прыгать из пространства типов в пространство переменных, и обратно, а также передавать что угодно куда угодно. Всё, после этих нововведений на C++ можно написать всё, что угодно.
После этого надо было не втискивать новые фичи, а улучшать UX или отрефакторить конпелятороговна.
Я могу разработать любой програмный продукт.(c)
Ня самом деле ня совсем так: после этих нововведений писать стало просто чуть проще. Как, собствення, и после любой другой версии стандарта.
Так, няпример, в 17-й версии сделали CTAD, без которого было весьма печальня (он сделал нянужным всё это std::make_говно(), няпример). "if constexpr" тоже можня было эмулировать, но ничуть ня проще, чем эмулировать &&-ссылки через, там, указатели.
Встроенные переменные (inline variable) няконец-то сделали возможным создавать полноценные header-only библиотеки, вместо ущербных огрызков.
Атрибуты ([[nodiscard]], [[fallthrough]]) дали очень мощный инструмент для раннего отлова ошибок (эмулировать их старыми стандартами вообще нявозможня).
Исправление бага с порядок вычисления аргументов няконец-то сделало возможным писать выражения вроде "std::unique_ptr(new Foo())" и ня опасаться, что в какой-то момент оно утечёт.
Ну и так далее, и тому подобное. Так что нят, ты няправ.
Каждый кусочек говнотулчейна версионируется, и не является обратно совместимым. Это значит что в любой момент времени есть неизвестное количество версий пакетов которые совместимы, и если они несовместимы то в лучшем случае оно не соберется а в худшем надристает какого-то говна которое не работает, и тебе придется править исходник чтобы он работал с новой версией тулчейна. Что происходит в электроноговне и реакт натив говне не даже страшно представить. Ты сходил к гадалке и установил все правильные версии? Молодец, встретимся через год
Эгалитаризм в разработке тулинга породил просто взрыв говна. Сколько сейчас версий декоратора в бабеле? А сколько библиотек заявязаны на бабель?
Я думаю что это яркий пример того чего крестостандартизаторы пытаются избежать
>Тут человекочас конпеляторного питуха становится человекогодом у программистов.
Я думаю что они мыслят другими категориями
Предлагаю взять синтаксис лиспа, а все прочие синтаксисы делать через хуйню типа миксинов из D, которая в компилтайме принимает строку с кодом в каком-то там синтаксисе и высирает синтаксис лиспа(списки, s-выражения), который уже потом компилируется. Чтоб гомоиконность!
Только всякие там миксины — лишнее переусложнение.
Нядо так: компилятор принимает программу ня Lisp и выполняет её; программа ня Lisp выдаёт AST, в котором часть поддеревьев отмеченя как "скомпилированные", а часть — как "няскомпилированные". Дальше компилятор рекурсивно выполняет "няскомпилированные" поддеревья до тех пор, пока всё дерево ня окажется скомпилированным.
И ещё полезно как-то вытянуть гомоиконность в синтаксис этих языков, но чтобы смотрелось цивильно, а не как eval в жс/питоне.
Три вореанта одной хуйни. Лучше всего оптимизируется через лямбду. Хуйня какая-то.
Притом она хуёво оптимизируется и в clang и в gcc и в icc, какой багор )))
> Притом она хуёво оптимизируется и в clang и в gcc и в icc
Подтверждаю.