Кресты / Говнокод #27533 Ссылка на оригинал

0

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32
  33. 33
  34. 34
  35. 35
  36. 36
  37. 37
  38. 38
  39. 39
  40. 40
  41. 41
  42. 42
  43. 43
  44. 44
  45. 45
  46. 46
  47. 47
  48. 48
  49. 49
  50. 50
  51. 51
  52. 52
  53. 53
  54. 54
  55. 55
  56. 56
  57. 57
  58. 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";
}

Какая крестопараша )))

Запостил: j123123 j123123, (Updated )

Комментарии (95) RSS

  • А можно ли тут вместо STD_FUNCTION макроса использовать обычный std::function?
    Ответить
    • #define STD_FUNCTION(a, b) typeof( a (*) b )

      Лучше наверное так этот макрос переписать
      Ответить
  • Мне не нравится этот код. Я ничего в нем не понимаю.
    Ответить
    • Ну а что тут непонятного?
      template<typename T>
      T do_op_t(T a, T b, STD_FUNCTION(T,(T,T)) op)
      {
        return op(a,b);
      }

      В данный шаблон подсовываем тип T, и он выдает функцию, которая возвращает что-то с типом T, и принимает два аргумента типа T и (указатель на функцию, возвращающую хрень с типом T и принимающую на вход два аргумента типа T).
      -------------
      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);
      }

      Данный шаблон принимает:(тип 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::pitux; // используем опцию pitux ниже по файлу или до последней }
        codespace lang::pitux {
          # используем опцию pitux между { и }
        }


        И в новом стандарте вообще бы запретили компиляцию без указания языка в файле. Пусть каждый файл начинается как using lang::cpp++25; (для старых проектов будет работать питушня вида --std=c++11 внутри файлов проектов, для новых файлов using lang:: с --std=староеговно просто будет выдавать ошибку компиляции, с --std=что-тоновое using lang:: будет в приоритете, без спецификации языка в файле будет выдаваться ошибка.

        Тогда можно будет ввести в язык островки адекватного синтаксиса.

        using lang::c++25;
        using lang::options::better_types;
        
        add : (x:int, y:int) -> int = x + y;
        
        binary : t => (t, t) -> t;
        call : t => (f:binary(t), x:t, y:t) = f(x, y);
        
        ys: [int:10] = {1,2,3,4,5,5,4,3,2,1};
        xs: [int:5] = ys[3:8];
        Ответить
        • > Когда вообще в C++ и других языках начнут делать версионирование синтаксиса?
          Тогда ещё и версионирование либ надо делать, потому что оставлять говно в либах — пускать все улучшения в синтаксисе насмарку.
          Назвать это С++ 3.0. Все увидят, насколько это лучше старого С++ 2.7 и быстро перебегут на не... Oh, wait...
          Ответить
          • > потому что оставлять говно в либах — пускать все улучшения в синтаксисе насмарку.
            А зачем? Ну будет в либе в заголовке int add(int, int);, а у меня в коде add :: (int, int) -> int для того же самого, и компилироваться будет в одно и то же.
            И будет библиотека работать и сейчас, и через 10 лет, и через 50, когда придумают более понятный синтаксис, чем в хаскеле. Может, потом какая-то добрая душа перепишет заголовочный файл, чтобы программистам его было проще читать, поскольку int add(int, int); будут понимать только стариканы-зумеры.

            А питонохолопы как раз соснули из-за того, что попытались сделать новый язык, который почти ничем не отличается от старого, но несовместим с предыдущим.
            Ответить
            • > для того же самого, и компилироваться будет в одно и то же.
              Таким образом, между "старым" синтаксисом и "новым" должно существовать как минимум инъективное отображение. Удачи описывать "адекватным" синтаксисом все элементы, которые я перечислила в комментарии ниже!
              Ответить
              • Ко-ко-ко, [](){}!
                Ко-ко-ко, auto putux -> kurica!

                > между "старым" синтаксисом и "новым" должно существовать как минимум инъективное отображение
                Вообще проблем нет.
                Можно сделать отображение из нового синтаксиса в старый, и тогда вообще можно внутренности и алгоритмы компилятора не трогать, решив все синтаксисопроблемы на уровне препроцессинга AST.

                > Удачи описывать "адекватным" синтаксисом все элементы, которые я перечислила в комментарии ниже!
                Какие в этом проблемы?
                Хаскелеподобный синтаксис удобен для того, что используется сейчас. Пусть в нём будет уродливым какая-нибудь новая питушня сейчас, потом придумают вореант получше.
                Ответить
                • > Можно сделать отображение из нового синтаксиса в старый, и тогда вообще можно внутренности и алгоритмы компилятора не трогать, решив все синтаксисопроблемы на уровне препроцессинга AST.
                  Только вот беда: как ты будешь делать отображение новых концепций в старый синтаксис? Как ты прикрутишь, няпример, концепты из C++20 в C++11 при помощи препроцессинга 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% кода будет описываться адекватно.
                    Ответить
                    • > 50 лет назад сишкосинтаксис был удобен для 90% того кода, который писали тогда
                      Не был.

                      > Сегодня хаскельный удобен для 90% современного кода, а сишный - для 10% кода
                      Неправда. Оба — говно.
                      Ответить
        • > адекватного синтаксиса
          Адекватного по мнению кого?

          И как, няпример, в "адекватный" "binary : t => (t, t) -> t" влезут нятипичные параметры, параметры со знячением по-умолчанию, шаблонные шаблонные параметры, вариадические параметры, нятипичные параметры с автовыводом типа, ограничения, концепты, явная специализация, частичная специализация, внешняя инстанциация?
          Вот как только всё это (и остальное) впихнёшь в свой "адекватный" синтаксис — получишь точня такое же говно, как и было. Только теперь вместо одняго говна будет два.

          Восклицания по типу "почему они ня могли взять и сделать просто?!" — это всего лишь последствия https://ru.wikipedia.org/wiki/Эффект_Даннинга_—_Крюгера .
          Ответить
          • >> адекватного синтаксиса
            > Адекватного по мнению кого?
            По мнению пользователей этого синтаксиса. Как минимум, по мнению тех, кто учился читать типы в сосишке по спирали и долго запоминал, чем в смысле записи константный указатель отличается от указателя на константу, а массив указателей - от указателя на массив.

            Синтаксис со стрелочкой гораздо короче, и проще описывает питушню с функциями и полиморфными типами
            call : t => (f:binary(t), x:t, y:t) -> t = f(x, y);
            
            template <typename t>
            t call (binary<t> f, t x, t y) {
              return f(x, y);
            }


            > И как, няпример, в "адекватный" "binary : t => (t, t) -> t" влезут
            Можно взять хаскелевский и как-то модифицировать под нужды крестопердоликов (может быть, по-другому, а не как у меня). Там уже есть и функции, и массивы, и шаблонные шаблонные параметры, и интерфейсы/концепты, и всё это не воняет как int *a[10].

            > как только всё это (и остальное) впихнёшь в свой "адекватный" синтаксис — получишь точня такое же говно
            На то и версионирование.
            Сишкопарашный синтаксис родился во времена, когда у императушков структурное программирование было последним достижением, а на серьёзные программы в функциональном стиле не хватало мощностей, и передача указателя на функцию сложения была наивысшим уровнем абстракции. Сишкозапись типов начинает вонять и ломаться уже на многомерных массивах и ФВП, а к нему сейчас прикручивают шаблоны и ко-ко-концепты, появляются мёртворождённый конструкции вида "auto ... -> pitux".
            Ответить
            • > Синтаксис со стрелочкой гораздо короче
              Возможня.

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

              > Можно взять хаскелевский и как-то модифицировать под нужды крестопердоликов
              ...и, как тебе уже нясколько раз попытались объяснить, получится ещё одно сложное и запутанное говно, единственное преимущество которого будет в том, что оно будет чуть-чуть более знакомо программистам ня Хаскелле.
              Ответить
              • > приведённый тобой крестовый шаблон гораздо лучше структурирован, чем куча-мала из стрелочек из скобочек
                Хорошо, можно использовать просто хаскельный синтаксис.
                call :: (Binary t, t, t) -> t
                call f x y = f (x, y)


                > каждая строчка шаблона содержит самостоятельную и изолированную его часть: список параметров, сигнатура и тело
                С точки зрения сишкораба, который мыслит исходя из крестосинтаксиса. Но всегда можно привыкнуть к лучшему.
                Не факт, что список параметров и сигнатура - объективно изолированные часть. Всё это - лишь аргументы функции, просто некоторые из них - типы, а некоторые - значения.
                И не надо придумывать между ними разницу вроде "одни вычисляются на этапе компиляции, а другие - на этапе исполнения". Грань между этим размыта. Скажем, f(2) при заинлайнивании может ничем не отличаться от инстанцирования f<2>(), а благодаря динамическому полиморфизму вполне можно передавать типы как аргументы.
                JIT вовсе рахмывает эту грань.

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

                > В твоём же "адекватном" все эти части сливаются в одну нячитаемую кашу.
                > как тебе уже нясколько раз попытались объяснить, получится ещё одно сложное и запутанное говно
                Я же несколько раз говорил, что придумают получше и добавят.

                > будет чуть-чуть более знакомо программистам ня Хаскелле.
                И программистам на крестах, когда перейдут. Если есть возможность выбрать из двух равноправных вариантов, один из которых на 80% удобнее, программисты перейдут.
                Ответить
                • А можно пример, как на этом синтаксисе выразить
                  template<template<typename> typename C, MyCoolConcept X, typename Y = void, auto Z, MyCoolConcept... TS>
                  Y foo(C<X> x, C<TS>...)

                  ?
                  Ответить
                  • Например, так
                    foo: (C:*=>*, X:MyCoolConcept, Y = void, Z:auto, TS...:MyCoolConcept) => (x: C(X), C(TS)...) -> Y


                    Кстати, про C:*=>*. В C++ можно описать только kind для параметра шаблона, который является шаблоном. Это вообще какая-то питушня. Нельзя описать питушню над контейнером интов или получить из одного параметра сразу и тип контейнера, и тип элемента.

                    Вместо того, чтобы паттерн-матчить
                    template <template <typename ElemT, ...> typename ContT> ...

                    нагородили std::stlpitux::value_type.
                    Ответить
                    • А если в качестве С передать шаблон с двумя параметрами, один из которых со значением по умолчанию, он его откинет?
                      foo(vector<int>) не должен скомпилироваться.
                      Ответить
                      • А с template<typename> typename C оно скомпилируется с std::vector<int>? Для векторушни template<typename, typename> typename C не требуется?
                        Но вообще я же просто перевёл.

                        Если надо, можно ввести синтаксис вида C:*...=>* для шаблонов или просто C:template или C:(=>), когда не важно, там шаблон от пары аргументов, шаблон от шаблона или шаблон от чёрт пойми чего.
                        Ответить
                        • > Если надо, можно ввести синтаксис вида
                          Ты только что гранату. Ещё пару десятков таких примеров — и мы получим второе крестоговно, поздравляю!
                          Ответить
                          • Да сколько можно уже?! Это будет второе крестоговно для 10% кода, а не для 90%, как сейчас.

                            Что за чёрно-белый мир, тётя Полина?
                            Нельзя совсем сделать без говна, но можно сделать так, чтобы говно приходилось на те куски кода, которые составляют редкие случаи, а мейнстрим был без говна.
                            Ответить
                            • А в современных крестах так и есть: древнее спиральное говно и сумрачные вариадические шаблонные шаблоны — это те самые 10% кода. Оставшимся 90% строчкам хватает простых и по-ня-тных синтаксических элементов.

                              То, что ты ня этом сайте видишь мозговзрывающее многоуровневое крестоговно — всего лишь следствие того, что простое и понятное крестоговно выкладывать скучня.
                              Ответить
                              • > следствие того, что простое и понятное крестоговно выкладывать скучня.
                                Это да

                                > Оставшимся 90% строчкам хватает простых и по-ня-тных синтаксических элементов.
                                Может быть потому, что сложный синтаксис затрудняет мышление, и приходится скатываться к примитивным конструкциям, которые громоздкие, но выглядят цивильно?
                                Когда простой скриптух или сложный хаскелюх пишет универсальную функцию сложения чисел, он особо не задумывается о происходящем.

                                const add = (x, y) => x+y;
                                add x y = x + y


                                У него получается сразу полиморфная функция, а в случае хаскеля - полиморфная, но даже с дофига строгой проверкой типов.

                                И на крестушне эта концепция выражается только в несколько строк, которые потом всё равно ради полиморфизма приходится перебивать на шаблон. А в хаскеле тот же "шаблон" был всегда и в одну строку.
                                Ответить
                                • > И на крестушне эта концепция выражается только в несколько строк
                                  Это всего лишь следствие применения сложного инструмента к примитивному случаю.

                                  > он особо не задумывается о происходящем
                                  И имення в этом и проблема: если тебе ня нужня задумываться о происходящем в коде, то гораздо эффективнее писать ня JS, Питоне и прочем скриптоговне.
                                  Но вот как только тебе понядобится иметь парочку разных специализаций "универсальных" функций (баняльно: функция суммирования элементов массива, которая целые числа складывает няивно, а плавающих петухов — алгоритмом Кэхэня, няпример) — скриптоговно уже ничего предоставить ня может (inb4: if isinstance(x, float): ...).
                                  Ну а когда появляются специализации шаблонов — появляется и разделение ня объявления/определения, и предварительные объявления, и внешние объявления, и частичные специализации... И так до тех пор, пока ня получим C++.
                                  Ответить
                                  • >> он особо не задумывается о происходящем
                                    > И имення в этом и проблема
                                    Нет. Проблема - когда я не задумываюсь и пишу какую-то питушню, которую потом надо будет допиливать - как int add(int, int) в C++. Проблемы нет, когда я не задумываюсь, а в языке работают полезные умолчания - как add x y = x+y в Haskell.

                                    > иметь парочку разных специализаций
                                    > скриптоговно уже ничего предоставить ня может
                                    Потому, что там нет компайл-тайм вывода типов и кодоподстановки, да. Но причём тут синтаксис?

                                    > как только тебе понядобится иметь парочку разных специализаций "универсальных" функций
                                    Можно будет реализовать через классы типов.

                                    Псевдохаскель:
                                    class MyFoldable (t a) where
                                       fold :: f a -> a
                                    instance MyFoldable [Int] where
                                       fold = foldr1 (+)
                                    instance MyFoldable [Double] where
                                       fold = foldr1 кохання
                                    Ответить
                                    • > int add(int, int)
                                      А никто так и ня пишет. В реальном коде ня C++ ты практически всегда сразу понимаешь, какая функция/структура должна быть шаблонной, а какая нят.
                                      Ну и раз уж говорить про умолчания...
                                      auto add(auto x, auto y) { return x + y; }


                                      > Но причём тут синтаксис?
                                      При том, что синтаксис должен это предусматривать.

                                      > Можно будет реализовать через классы типов.
                                      Ну вот, примитивную, базовую концепцию из C++ нячали реализовывать какими-то "классами".
                                      Ответить
                                      • > синтаксис должен это предусматривать
                                        Ну, синтаксис специализации шаблонов - это наверно меньшее, что нужно разработать при реализации специализации.

                                        > примитивную, базовую концепцию из C++ нячали реализовывать какими-то "классами".
                                        А теперь давайте алгебраические типы и паттерн-матчинг без пердолинга в C++ реализовывать.
                                        Ответить
                          • > Ещё пару десятков таких примеров — и мы получим второе крестоговно, поздравляю!
                            Хотя, не факт.

                            Как развивался C++? Давным-давно была сишка, из неё унаследовали синтаксис, куда потом добавляли новые возможности, которые только что придумали, и раньше о них не знали.

                            Как будет развиваться новый синтаксис? Все возможности уже известны (может, не мне, но ко-ко-комитету - точно), с учётом них разработают несколько вариантов синтаксиса, обкатают, исправят, выберут лучший и внесут в стандарт.

                            Это как рефакторинг, только на уровне синтаксиса.
                            Ответить
                            • > Все возможности уже известны
                              «Все, что можно было изобрести, уже изобретено», – сказал в 1899 году сотрудник Патентного ведомства США Чарльз Дуэл.
                              Ответить
                              • Какой багор ))) Ну вообще, в каждой временной точке T все существующие возможности C++ уже известны, а в некоторой T-X, X>0 - известны, но не все из них.
                                Ответить
                • Опять же, нялицо пресловутый эффект.
                  Ты просто ня понимаешь, что выразить все концепции C++ и ня получить при этом такого же монстра, какой и был, попросту нявозможня.

                  > Ну и разделять аргументы-значения и аргументы-типы - значит ограничивать мышление, какой-то пользы от этого нет.
                  Пожалуйста:
                  template<int ...Values, typename ...Types>
                  void foo(Types...) {
                  
                  }
                  
                  int main()
                  {
                      foo<1, 2, 3>(int{}, float{}, double{});
                  }

                  Осилишь такое же, но без разделения параметров-знячений и параметров-типов?

                  > придумают получше и добавят
                  Тогда чем твои предложения отличаются от зняменитого "Взять всё и поделить"?
                  Удивительня: дурачки-крестостандартизаторы ня осилили сделать адекватный синтаксис! Какой адекватный? Так пусть они и придумывают!
                  Ответить
                  • > выразить все концепции C++ и ня получить при этом такого же монстра, какой и был
                    Ну сколько можно повторять?!
                    1. Вероятность того, что в одной строке (да и даже в одном файле) понадобится описать все концепции, крайне мала.
                    2. Один синтаксис будет хорош 50 лет назад (как текущий), другой - сейчас, через 50 лет придумают что-то новое.
                    3. Если 90% кода будет выглядеть не как говно, новый синтаксис аппрувед.

                    > Осилишь такое же, но без разделения параметров-знячений и параметров-типов?
                    Ну это просто так повезло, что синтаксически описалась такая ситуация.
                    А как насчёт получения STL-коллекции и типа элемента? Кресты соснули и не смогли.

                    И ещё тут передача двух бесконечных списков, осуществлённая через скобочки разной формы. А если бы надо было передать три списка, кресты бы соснули.

                    Во-первых, если надо передавать кучу гомогенных списков, границу между которыми невозможно обозначить, надо вводить какой-то разделитель между ними, чтобы было универсально:
                    void foo(int...xs, int...ys);
                    foo(1,2,3; 4,5,6);


                    А так, можно было бы сделать
                    void foo(int ...xs, 'types...ys) {
                    }
                    
                    foo(1,2,3; int{}, float{}, double{})
                    или
                    foo(1,2,3, float{}, double{}, int{}) // ; не нужна


                    Дальше можно на этапе компиляции дедьюсить, константа ли, и на основе этого разрешать выражения вида int xs[SIZE], или нет. Тем более, что всяких constexpr понавели, и проблему как-то прощупали.
                    Ответить
                    • > Если 90% кода будет выглядеть не как говно, новый синтаксис аппрувед.
                      Только вот беда: все твои придирки, высказанные в этом треде, относятся к древнему няследию сишки, которое в 99% кода ня современных крестах ня используется.
                      Массивы — std::array, функции — std::function, указатели — std::unique_ptr или &.
                      Благодаря эим сущностям видеть сишную спиральную лапшу в современном C++-коде приходится очень редко, и 90% кода выглядит как ня говно. Ergo, по твоему же собственному определению, старый синтаксис аппрувед.

                      > Ну это просто так повезло, что синтаксически описалась такая ситуация.
                      А в твоём новом суперкрутом синтаксисе тебе придётся это поддерживать. И чтобы без говна!

                      > А как насчёт
                      Мы обсуждаем новый синтаксис, а не как что-то сделать в старом.
                      Ответить
                      • > std::function
                        Какой багор )))
                        std::function<a (*) (b,c,d)>, или как оно там, вместо (b,c,d)->a или b->c->d->a с каррированием.
                        std::array<petux, kurochka> вместо, скажем, [petux:kurochka]

                        > А в твоём новом суперкрутом синтаксисе тебе придётся это поддерживать.
                        Зачем? Зачем? Какие-то редкие случаи можно описать и в старом синтаксисе, я же как раз за универсальность.
                        > И чтобы без говна!
                        Зачем? Зачем? Какие-то редкие случаи могут быть и с говном.
                        Ну и один синтаксис может описывать лучше одну парадигму, а другой - другую.

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

                        Но вообще все эти типы, которые тут мелькали в комментариях (даже с концептами), легко можно описать с новым простым синтаксисом.
                        Питушня из нескольких комментариев выше вполне записывается как
                        foo : (Values...: int, Types...) => Types... -> void

                        И это однозначно соответствует описанной шаблонушне.

                        Смешение компайл-тайм аргументов и рантайм-аргументов - это да, это более серьёзный шаг, это уже не просто перестановка узлов в дереве.
                        Ответить
                        • > std::function<a (*) (b,c,d)>
                          std::function<a(b, c, d)>.

                          > вместо (b,c,d)->a или b->c->d->a с каррированием
                          > вместо, скажем, [petux:kurochka]
                          Ну вот, собствення, уже пошла чистая вкусовщина.

                          > Какие-то редкие случаи можно описать и в старом синтаксисе
                          Затем, что твой синтаксис должен поддерживать все концепции старого. Иняча никак ня получится сделать прозрачное использование старых библиотек, и привет, 2.7.

                          > Values...: int, Types...
                          Очень простой, понятный и однязнячный синтаксис (нет).
                          Почему-то двоеточие после "foo" ознячает список параметров шаблона, а после "Values..." — что? Тип параметра?

                          > Если кресты могут описать что-то большее только за счёт введения более удобного синтаксиса, то почему бы это не сделать?
                          Потому что синтаксис — это вторичное, в основе языка лежат его сущности и концепции. Введение нового синтаксиса может максимум добавить сахарку, но добавить "что-то большее" — нят.
                          Ответить
                          • > std::function<a(b, c, d)>.
                            > (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.

                              > Всё просто и регулярно.
                              А как в этом виде записать объявление, определение, внешнее объявление, дружественное объявление, частичную специализацию, явную специализацию, внешнюю специализацию?
                              Ответить
                              • > твой новый синтаксис будет нясовместим со старыми библиотеками. Результат — 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++ впилить подобные проверки. Оптимизатор явно их выпилит в большом количестве случаев. Ну понизится пирфоманс, скажем, на 10%, зато надёжность возрастёт на 500%.
                                      Ответить
                                    • > С STL vs C-тушня тоже так же случилось.
                                      Ну да, только 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 этим будут пользоваться и довольно активно.
                                                Ответить
                        • Ну и да, главная фишка std::function, std::array и прочих std::unique_ptr в их консистентности. Они реализованы с использованием уже существующих синтаксических элементов, они однязначны, они понятны. И это хороший подход, потому что он ня плодит новый синтаксис ня каждую новую концепцию. Более того, они однязнячно вписываются в остальной синтаксис: тебе ня нужня думать, как сделать двумерный массив, ня нужня прикидывать, как всунуть функцию в параметр. Ты работаешь с этими объектами абсолютня так же, как и со всеми остальными — и это хорошо.
                          Ответить
                          • Надо было их сделать синонимами существующих, или что-то вроде того. Иначе вышла какая-то разная питушня, которую склеили вместе скотчем.

                            Ну то есть если я пишу int x[10], должен создаться std::array<int, 10> x;
                            А сишноговённое int x[10] должно быть nonstd::unskill_carray<int, 10> x;

                            И чтобы с приходом лямбд во всех функциях появились замыкания. Со старыми бинарниками можно пробовать склеивать по именам. Скажем, в новые функции вставлять в имя какую-то питушню-маркер, а при компиляции искать в бинарнике имена с питушнёй и без, и вкомпиливать найденные.
                            Ответить
                            • > Ну то есть если я пишу int x[10], должен создаться std::array<int, 10> x;
                              > Останутся все крестовые библиотеки

                              Либо трусы надень, либо крестик сними. Ломаешь ли ты всю совместимость, изменяя поведение существующих синтаксических конструкций, либо сохраняешь совместимость со старым кодом. Поддержка legacy — один из основных источников говна в стандарте С++.
                              Ответить
                              • либо тру си надень, либо крестики сними

                                вы кажется придумали примитивные типы и анбоксинг
                                Ответить
                              • Это совместимость с сиштушнёй, с которой стандарт и так разошёлся так, что ни сишка - подмножество крестов, ни кресты - подмножество сишки. Всё равно же сломали, но можно было бы сломать с пользой.
                                Ответить
                                • Это совместимость со всеми старыми версиями крестов. Как самое базовое отличие — c-style массивы автоматически decay-ятся в *, а новые — нят.
                                  Ответить
                            • Про массивы Soul_re@ver уже сказал: изменять поведение существующих конструкций в крестах — очень большой харам.

                              > во всех функциях появились замыкания
                              Снячала сделай GC.
                              Ответить
          • 1. Когда новый синтаксис завоняет, можно будет без потери совместимости добавить более новый, который придёт в голову человеку, который про шаблоны и концепты узнал не из новостей, когда ему было 50 лет, а в школе в 12 лет.
            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++++
          Ответить
          • Никто не мешает описывать многие из этих особенностей синтаксиса как преобразования AST.

            Ну или просто создать язык, компилирующийся в 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 — это крайне примитивный язык
                JS мощнее крестов и лучше подходит как таргет для компиляции. Это не имеет никакого отношения к примитивности
                Ответить
              • > определение синтаксической корректности программы ня С++ эквивалентно проблеме останова.
                И что?
                Почему математика окрыляет математиков, но прибивает программистов к земле?
                Зачем все эти вскукареки про полноту Питуринга и питухемы питунова?
                Пока праграмисты, возомнившие себя знатоками математики, кукарекают, компилятор крестов компилирует код. Несмотря на всякие питухемы.

                > Язык, компилирующийся в C++, — это совершення безумная идея
                Вообще, в крестопитушне так уже давно живут. Каждый, кто написал на C++ хоть сколько-нибудь полезную программу (использующую ввод/вывод), писал её не на C++, а на языке, который компилируется в C++, и программа на самом C++ является валидной программой на этом языке!

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

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

                > А вот о каких попытках расширить синтаксис C++ может идти речь, если в крестах уже все скобочки перегрузили во всех местах где только можня...
                Ну я же написал, как!
                using lang::newsyntax { тут любая питушня }.

                Ну или если говорить для людей, которые понимают буквально и читают не концепции и подходы, изложенные в моих комментариях а придираются к тексту, то using std::lang::newsyntax { ... }. std-питушня остаётся за авторами стандарта, и никаких конфликтов не будет, если новый синтаксис будет лежать в std.
                Ответить
              • > C++, в противовес JS, — это огромный, древний хтонический монстр
                > создание конформного компилятора к которому — задача ничуть ня проще проектирования ракеты.

                Почему-то мне кажется что ракета будет попроще.
                Ответить
            • В десктоп-питушне так уже давно живут. Есть и куча питушни, компилирующейся в машинные коды и возможность писать для VM поновее. То есть то, о чём ты говоришь, не новость.

              Видимо, дело в том, что если на осла навесить картонный рог, бумажные крылья и покрасить в яркие цвета, он не станет мультяшной пони. Может, вместо того, чтобы пытаться кардинально переделать существующий язык (кстати, нахрена, ради названия, бренд сохранить?), стоит потратить силы на разработку нового, в котором всё будет как надо и не надо будет пердолиться с совместимостью?
              Ответить
              • > стоит потратить силы на разработку нового, в котором всё будет как надо и не надо будет пердолиться с совместимостью?
                Новых языков и так кучу наплодили зачем-то. Теперь приходится пердолиться как с совместимостью внутри одного языка, так и с несовместимостью библиотек. Но зачем?

                Почему нельзя тогда все императивные языки с ГЦ свести в один, без ГЦ - в один, все функциональные - в один, и т.п.? Хотя, дотнет смог вместить в себя и императушню с ГЦ, и функциушню. Надо использовать библиотеки между языками без пердолинга.

                Чем так сильно различаются python и JS, что я не могу без каких-либо проблем использовать библиотеки от одного в другом? Тот же движок, та же питушня с динамической питуизацией и ГЦ, единственная разница - в питоне 1+'a' бросает исключение, а в жс - возвращает '1a'.
                Ответить
            • >Ну или просто создать язык, компилирующийся в C++
              ASD_77, мы нашли твоего первого пользователя

              >В веб-питушне так уже давно живут
              То что делают в вебе отличается от того что предлагаешь ты

              >Видимо, дело в том, что в веб-мире больше более молодых людей, которые отказываются жрать говно
              Авторы ts прямо заявляют что их система типов не sound и не планируется быть таковой. Таким образом, ts специально изговнили чтобы "молодые люди отказывающиеся жрать говно" начали его адоптить. Качество жсного мейнстрим тулчейна (вебпак, бабель, тайпскирпт) настолько низкое что использовать его - это буквально жрать говно и приводить его в пример неприлично

              >И полагаться на мнение компиляторопитухов глупо, поскольку C++ делается для программистов, а не для макак-компиляторщиков
              Ты что, ни разу не работал над проектом больше 300к строк кода? Не знаешь как все в больших проектах устроено?
              Ответить
              • > Качество жсного мейнстрим тулчейна (вебпак, бабель, тайпскирпт) настолько низкое что использовать его - это буквально жрать говно и приводить его в пример неприлично
                Ну, качество крестушни (смотря как понимать этот термин) тоже не очень.
                Поведение, когда компилятор говорит про ошибку так, что её текст надо запоминать наизусть, ничем не лучше, чем поведение глючного инструмента с багами. Что там, что там придётся попердолиться, чтобы понять, что же, чёрт возьми, случилось.
                Или компиляция питушни, состоящей из старого и не очень говна под новой версией компилятора, когда надо подбирать флаги и пердолиться с файлами сборки.

                > Ты что, ни разу не работал над проектом больше 300к строк кода? Не знаешь как все в больших проектах устроено?
                А тут не проект, тут метапроект. Тут человекочас конпеляторного питуха становится человекогодом у программистов.
                Ну вот C++ уже давно хорошо работал, с введением decltype и rvalue references он уже стал достаточно универсальным, когда можно в любой момент прыгать из пространства типов в пространство переменных, и обратно, а также передавать что угодно куда угодно. Всё, после этих нововведений на C++ можно написать всё, что угодно.
                После этого надо было не втискивать новые фичи, а улучшать UX или отрефакторить конпелятороговна.
                Ответить
                • > Всё, после этих нововведений на C++ можно написать всё, что угодно.
                  Я могу разработать любой програмный продукт.(c)

                  Ня самом деле ня совсем так: после этих нововведений писать стало просто чуть проще. Как, собствення, и после любой другой версии стандарта.
                  Так, няпример, в 17-й версии сделали CTAD, без которого было весьма печальня (он сделал нянужным всё это std::make_говно(), няпример). "if constexpr" тоже можня было эмулировать, но ничуть ня проще, чем эмулировать &&-ссылки через, там, указатели.
                  Встроенные переменные (inline variable) няконец-то сделали возможным создавать полноценные header-only библиотеки, вместо ущербных огрызков.
                  Атрибуты ([[nodiscard]], [[fallthrough]]) дали очень мощный инструмент для раннего отлова ошибок (эмулировать их старыми стандартами вообще нявозможня).
                  Исправление бага с порядок вычисления аргументов няконец-то сделало возможным писать выражения вроде "std::unique_ptr(new Foo())" и ня опасаться, что в какой-то момент оно утечёт.

                  Ну и так далее, и тому подобное. Так что нят, ты няправ.
                  Ответить
                • под качеством я имею в виду направление развития и само развития.

                  Каждый кусочек говнотулчейна версионируется, и не является обратно совместимым. Это значит что в любой момент времени есть неизвестное количество версий пакетов которые совместимы, и если они несовместимы то в лучшем случае оно не соберется а в худшем надристает какого-то говна которое не работает, и тебе придется править исходник чтобы он работал с новой версией тулчейна. Что происходит в электроноговне и реакт натив говне не даже страшно представить. Ты сходил к гадалке и установил все правильные версии? Молодец, встретимся через год

                  Эгалитаризм в разработке тулинга породил просто взрыв говна. Сколько сейчас версий декоратора в бабеле? А сколько библиотек заявязаны на бабель?

                  Я думаю что это яркий пример того чего крестостандартизаторы пытаются избежать

                  >Тут человекочас конпеляторного питуха становится человекогодом у программистов.
                  Я думаю что они мыслят другими категориями
                  Ответить
        • > Когда вообще в C++ и других языках начнут делать версионирование синтаксиса?

          Предлагаю взять синтаксис лиспа, а все прочие синтаксисы делать через хуйню типа миксинов из D, которая в компилтайме принимает строку с кодом в каком-то там синтаксисе и высирает синтаксис лиспа(списки, s-выражения), который уже потом компилируется. Чтоб гомоиконность!
          Ответить
          • Так точня!
            Только всякие там миксины — лишнее переусложнение.
            Нядо так: компилятор принимает программу ня Lisp и выполняет её; программа ня Lisp выдаёт AST, в котором часть поддеревьев отмеченя как "скомпилированные", а часть — как "няскомпилированные". Дальше компилятор рекурсивно выполняет "няскомпилированные" поддеревья до тех пор, пока всё дерево ня окажется скомпилированным.
            Ответить
          • Да, давно пора.

            И ещё полезно как-то вытянуть гомоиконность в синтаксис этих языков, но чтобы смотрелось цивильно, а не как eval в жс/питоне.
            Ответить
    • https://godbolt.org/z/vde4fhrqP - можно добавить const ко всей хуйне, и тогда хуёво оптимизируется только хуйня с std::bind
      Притом она хуёво оптимизируется и в clang и в gcc и в icc, какой багор )))
      Ответить
      • bind вообще хуйня. Он устарел в день выхода стандарта, потому что там же были лямбды. Как обычно, сначали впихали bind, затем запихали лямбды и забыли выпилить bind обратно.
        Ответить
      • > хуёво оптимизируется хуйня с std::bind
        > Притом она хуёво оптимизируется и в clang и в gcc и в icc

        Подтверждаю.
        Ответить

Добавить комментарий для 1024-- Отменить ответ

Переведи на "PHP", guest!

    А не использовать ли нам bbcode?


    8