14.05.2015 12:01
OberonForGood 466 32609 Источник
Каждому иногда приходится размышлять над тем, что же происходит в ИТ, как оно будет дальше развиваться, и как потом с этим жить. Хотелось бы этим постом ответить на статью «Мысли об идеальном языке программирования».

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

Типичная ошибка бытового экстраполирования. Одна фича хорошо, две фичи хорошо-хорошо, а если сто фич в язык добавим, по инерции кажется, будто станет 100?хорошо. Линейный, а лучше экспоненциальный рост количества фич в языке и стандартной библиотеке, вот рецепт счастья настоящих суровых программистов промышленного уровня в 2015-м году.

А про всякие картиночки типа этой мало кто вспоминает, а если и вспоминают, то думают о них только плохое. Потому что справедливое возмущение. Потому что негодование. Потому что как это так, разве можно выкидывать из языка фичи, разве можно отказаться от foreach? И вообще, что это за развитие такое, если фичи исчезают? Совместимость теряется. Пометьте уже @Deprecated как @Deprecated.

С другой стороны, возникают вопросы. Все ли читали огромный language reference своего любимого языка от корки до корки? А если читали, то сколько процентов запомнили? Так ли нужно иметь стопицот видов циклов? Действительно ли нужно каждое полюбившееся толпе библиотечное решение внедрять в язык?

Обладание идеальным исполнителем и практическое отсутствие сопромата (про порядок сложности только на собеседованиях вспоминают) привело софтверную индустрию к состоянию, в котором магистральным течением в рассуждениях является экспансия. А если точнее, не экспансия, а эксплозия. Борьба со сложностью задач сложностью инструментов, с помощью которых эти задачи решаются. Конечно, многие от этого выигрывают. Зарплаты растут. Что еще нужно?

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

Конечно, во всем этом можно найти позитивные устремления, которые по факту остаются такими же виртуальными, какими они предстают перед компилятором.

Могут возразить, что в реальности, у самых крутых языков есть стандартизация, экспертные комиссии, которые выполняют невообразимо глубокую проработки проблем индустрии. Но что это за проблемы? Не те ли, которые были созданы на предыдущей итерации стандартизации и экспертизы?

А в остальном, все как всегда, индустрия ИТ идет вслед за бизнес-тенденциями, реализуя аутентичные средства решения проблем бизнеса методом суслика просто потому, что бизнесу нужен минимально значимый продукт. Постепенно это приводит к тому, что и сам ИТ-бизнес становится минимально значимым. Когда и где компании вырывались в лидеры, потому что потратили 80% ресурсов проекта на архитектуру, а 20% ресурсов на разработку? Уже смешно, не правда ли?

Интересно, что и когда должно произойти в мире, чтобы эксплозия остановилась? Может быть, коллапс экономики? Нельзя такого желать, это смерть и страдания многих людей, будет уже не до ИТ. Может, метеорит? Хорошее, годное средство против гегемонов. Но мы же в 21-м веке, умные образованные люди. Стремимся к научному и формальному мышлению. Может, надо желать эволюционного скачка человеческого вида? Но это долго, а компьютеры способно выполнить ошибочный код за наносекунды. Сколько раз они его выполнят, прежде чем сознательность человека алгоритмического повысится на 1%? Сколько еще раз упадут спутники и заглохнут двигатели Боинга после выхода за пределы сишного массива?

А вы в курсе, что ПО для спутников пишут на Модуле? На той самой, из 80-х, которую Никлаус Вирт создал, просто отсекая все лишнее. Ребята из Excelsior Jet до сих пор поддерживают свой XDS, значит это кому-то надо. Значит, спутники, не прощающие ошибок, поощряют Модулу?

А что можно противопоставить тем, кто не поощряет? Ничего. Надо искать ниши, бегать по норам, как млекопитающие в позднюю эпоху динозавров. У динозавров доминирование, и никому уже нет дела до ваших алгоритмов и циклов Дейкстры. Ну и что, что мозг (два мозга) размером с орех, ведь все работает. Процессы идут, контракты заключаются. И не то чтобы сильно хотелось контрактов. Хочется, конечно, принуждение голодом для всех одинаковое.

Никто не принуждает к Оберону. Особенно в школах. Особенно в начальных классах. Не нужно учить Оберону с начальных классов. И школьники с алгоритмическим мышлением не нужны. И простой язык не нужен. И миллионы готовых алгоритмистов не нужны. А кому они нужны, за копейки-то? А как иначе, за что тут много платить, ведь просто все, такое я и сам сделаю. Где там моя книжечка «Программирование для непрограммистов»? Еще научим на свою голову понимать алгоритмы и дадим простой язык, так они ведь все без нас начнут программировать. Не очень радужно. А потом не захотят писать на Java. Скажут, некачественно сделано, провалы в концепциях видеть начнут. Лишние фичи критиковать. Нехорошо это. Как говорится, после изучения Оберона, изучение любого другого языка это изучение его (другого языка) недостатков.

Как же так, язык простой, компилятор еще проще. И операционная система получается простая.

image

И интерфейс пользователя простой. А страничка проекта вообще простая. Все это довольно просто, по-спартански. И платка FPGA такая же. Простые вещи не привлекают внимания.

И эта статья никак не является призывом взять и пересесть на Оберон. Как говорил Никлаус Вирт:
Многие люди относятся к стилям и языкам программирования как к религиозным конфессиям: если вы принадлежите к одной из них, то не можете принадлежать к другой. Но это ложная аналогия, и она сознательно поддерживается по причинам коммерческого порядка.

А после того, как вы закроете этот невзрачный текст, которому явно не хватает внятной и серьезной аргументации, и вообще, что курил автор, почитайте эту статью, она про простоту: issuu.com/xcelljournal/docs/xcell_journal_issue_91/30?e

Комментарии (466)


  1. StrangerInRed
    14.05.2015 15:05
    #8417501
    +5

    Любит же Никлаус Вирт begin/end«ы, если бы не они было бы торт. После 4х лет изучения pascal, С в плане синтаксиса был глотком свежего воздуха. А вообще любой язык программирования приводит мысли в порядок. Можно изучать хоть pascal, хоть C, хоть brainfuck. Unix тоже был очень очень простой.


    1. OberonForGood Автор
      14.05.2015 15:20
      #8417531

      Но ведь операторные скобки сейчас расставляет IDE. А например в вашей статье про Brainfuck VM длинные квалификаторы, длиннее, чем слово BEGIN, но вы не стали их сокращать.


      1. StrangerInRed
        14.05.2015 16:02
        #8417623

        Ну а причем тут длинные квалификаторы? Тут вопрос именно в эстетической составляющей части блока. Длинные имена функций, это результат отсутсвия плюсовых namespace в С. Представьте себе инициализацию массива в виде «begin_init_array from 1 to 1000 step 10 end_init_array». Но это всего лишь дело вкуса. Кому-то нравится одно, кому-то нравится другое. Мне просто не нравятся begin end в блоках, но я же не говорю что никто не должен пользоватся языком, потому что он мне не нравится. Это всего лишь имхо.


        1. OberonForGood Автор
          14.05.2015 17:05
          #8417771
          -14

          С моей точки зрения эстетически приятнее когда код плотный, аккуратно разбит на иерархические блоки.
          С этой точки зрения код на Обероне мне приятнее, чем разреженный код на Java, где пустого места на единицу площади иногда больше, чем кода.

          Пример



          1. Encircled
            14.05.2015 17:14
            #8417783

            Если добавить комментарии и пустые строки, то любой текст станет разряженным :)
            А так пишите хоть без пробелов, джаве то все равно


            1. OberonForGood Автор
              14.05.2015 17:22
              #8417801
              +1

              Стайл-гайдам не все равно, они советуют писать именно так. Разделять пустотой объявления и действия, переносить скобку после объявления на новую строку. И так далее.


              1. Encircled
                14.05.2015 17:27
                #8417811

                Конечно, и благодаря этому вы получаете более высокую читаемость кода. Но в реальном коде не будет «пустого места на единицу площади иногда больше, чем кода», не надо перегибать палку.


                1. OberonForGood Автор
                  14.05.2015 17:31
                  #8417823
                  -3

                  Напомню, речь изначально шла о том, что в Обероне, например, не нужно пустое пространство для разделения, так как эту роль выполняют ключевые слова (которые не нравятся многим), которые выглядят особенно. «Глаз цепляется», знаете такое выражение?


                  1. NeoCode
                    14.05.2015 17:50
                    #8417873
                    +2

                    Это есть такая эпичная тема на rsdn: Синтаксический оверхед Про нее даже на Лурке написано…


                    1. OberonForGood Автор
                      14.05.2015 17:54
                      #8417885
                      +1

                      Ага, читал такую. Сергей Губанов, уважаемый оберонщик.


                  1. EndUser
                    14.05.2015 18:05
                    #8417911
                    +4

                    Я помню, что при изучении Си я имел такой стиль (кстати, вполне культурный K&R), что при просмотре экзерсиза на Паскале я долго плавал взглядом по экрану ища и собирая смысл в кучу. Было такое ощущение, что смысл есть, но он распылён по всей площади экрана с добавлением гигантских лакун.

                    Это необычное ощущение, когда один и тот же простенький численный метод на Си умещается в фокусе глаза, а на Паскале требует этими глазами дико вращать (и скроллиться к тому же).

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

                    После этого я решил, что вопрос колебания плотности информации на экране (в известных пределах. Я не говорю про Ифкуиль) — это вопрос мимолётной привычки, и полагается смотреть в языке совсем на другое.


                    1. StrangerInRed
                      14.05.2015 18:21
                      #8417949
                      -4

                      Тогда по читабельности и компактности obj-c всех превзошел.

                      view.makeScale(2.0).thenAfter(0.5).moveXY(100, 50).animate(1.0);
или 
[myAppObject.theArray insertObject:myAppObject.objectToInsert atIndex:0];


          1. KvanTTT
            15.05.2015 00:09
            #8418391

            Пустые строки, да еще и лишние (т.к. очевидные) комментарии.


          1. OberonForGood Автор
            20.05.2015 16:05
            #8427025
            -2

            Скриншот кода на Обероне вызывает неконтролируемое минусоизвержение.


        1. Alexeyslav
          15.05.2015 10:34
          #8418863

          Без подсветки синтаксиса они конечно мешаются, но никаких проблем!


      1. ApeCoder
        14.05.2015 16:38
        #8417725
        +28

        Операторные скобки надо не только писать ЗАПЯТАЯ но и читать ТОЧКА Символы более визуально отличны от слов ЗАПЯТАЯ занимают меньше места ЗАПЯТАЯ и создают меньше шума ТОЧКА Мне ЗАПЯТАЯ например ЗАПЯТАЯ нравится вообще без операторных скобок ТИРЕ как в Питоне или F# ТОЧКА :)


        1. OberonForGood Автор
          14.05.2015 17:08
          #8417775

          Если бесшумно записать фразу с парой циклов и if на Java в одну строчку, будет ли она понятнее, чем ваш пример?


          1. ApeCoder
            14.05.2015 17:31
            #8417821
            +1

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


            1. OberonForGood Автор
              14.05.2015 17:37
              #8417835
              +1

              О чем еще спорить, как не о вкусах :)

              for (Refer refer: list){if (refer != null && refer.isNotEmpty()){if (id.length() != 0) id.append("-"); id.append(refer.getId());if (hierarchy.length() != 0) hierarchy.insert(0, " / ");hierarchy.insert(0, name); name = refer.getName();}}

              WHILE ch # 0X DO WHILE (ch > 0X) & (ch < 0FCX) DO INC(ad, ORD(ch)); INC(ref); RefNum(ref, d); IF ad > codePos THEN RETURN pos END; INC(pos, d); S.GET(ref, ch) END; IF ch = 0FCX THEN INC(ref); RefNum(ref, d); RefName(ref, name); S.GET(ref, ch) END; WHILE ch >= 0FDX DO (* skip variables *) INC(ref); RefCh(ref, ch); IF ch = 10X THEN INC(ref, 4) END; RefNum(ref, d); RefName(ref, name); S.GET(ref, ch) END END;


            1. MacIn
              14.05.2015 17:38
              #8417843
              +3

              Отсутствие разбиения по строкам — подтасовка ;)


          1. topa
            20.05.2015 14:32
            #8426899
            -1

            Да кто ж Вас, блин, учил писать кучу кода в одну строчку?! Что в примере выше, что в примере ниже!

            И дело вовсе не во вкусах, такой код не удобно ни читать, ни редактировать.


            1. OberonForGood Автор
              20.05.2015 16:03
              #8427023
              -1

              1) Второй пример синтетический.
              2) В Обероне это удобно.
              3) Дело во вкусах.


              1. topa
                20.05.2015 16:45
                #8427075
                +3

                Почему в Обероне становится удобным то, что неудобно во всех остальных языках?
                Намного ли удобнее увидеть присваивание значения переменной, которое находится в середине строки между других операций? Не это ли есть снижение читаемости кода? Почему в Обероне это удобно?
                Длинное выражение между THEN и END каким-то образом избежит возникновения горизонтальной полосы прокрутки? Или Вы разобьете его на две строки, сделав чтение кода еще менее удобным?

                Если есть преимущества у написания кода в строку (включая те особенные для Оберона, о которых Вы говорите), которые могут компенсировать потерю читаемости и удобства редактирования кода — расскажите о них, иначе ваши слова о вкусах совершенно пусты.


                1. OberonForGood Автор
                  20.05.2015 17:00
                  #8427101

                  Вы говорите «неудобно». Я говорю «удобно». Вы не верите мне, а я вам. Вы исходите из своих вкусов, я из своих. Непонятно, с чего сыр-бор? Почему вам станет удобно, если было неудобно? Я не знаю. А вы в чем удобство измеряете? В сантиметрах? Удобно это сколько? 13 cм? Или 26 см?


                1. akastargazer
                  20.05.2015 17:06
                  #8427113

                  Добавлю остроты — ещё удобнее читать компактный пропорциональный шрифт, а моноширинный зря расходует пространство экрана. И это не троллинг, а личный опыт. Я раньше программировал с моноширинным с синтаксической подсветкой, но постепенно перешёл на пропорциональный с архитектурной подсветкой. Патриотичный PT Sans прекрасно подходит для кодирования.


                  1. Alexeyslav
                    20.05.2015 17:25
                    #8427155
                    +1

                    Моноширинный используют потому что отступы строго прогнозируемые, а в пропорциональном — как повезет, выравнивать код «столбцами» очень трудно в текстовом редакторе.


                    1. akastargazer
                      20.05.2015 17:45
                      #8427183
                      -2

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

                      Почему-то картинка не видна
                      hsto.org/files/2ad/e5f/bfe/2ade5fbfe2a4482baf0b01a9aa784612.png


                      1. Alexeyslav
                        20.05.2015 21:39
                        #8427417
                        +4

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

                        Теги пропадают в коментариях когда карма ниже нуля.


                      1. VenomBlood
                        21.05.2015 00:44
                        #8427557
                        +7

                        st = v.t.ThisSetter();?
                        И эти люди говорят мне о методологии написания хорошего кода?


        1. MacIn
          14.05.2015 17:38
          #8417841
          +4

          Да, да, расскажите нам, что { читается легче, и выделяет блок лучше, чем begin.
          Замечу, что ваш пример — спорный, потому что в норме слова-границы блока стоят на отдельных строках. Т.е. тот, кто пишет в виде begin abc def ghi end (ваш пример) — сам себе злобный буратино. Если уж сравнивать, то

          if()
{
  abc;
  def;
  ghi;
}
else
{
  abc;
  def;
}

          и
          if .. then
begin
  abc;
  def;
  ghi;
end
else 
begin
  abc;
  def;
end;


          Вообще, это такая вкусовщина…


          1. ApeCoder
            14.05.2015 17:53
            #8417881
            +7

            Думаю, что нет. Просто
            if (x > y) {
            BECIN;
            EMD
            }

            Читается проще чем

            IF (x>y)
            BEGIN
            BECIN
            EMD
            END

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

            Отсутствие отступов не подтасовка если отступы управляются человеком. Человек может ошибиться.


            1. MacIn
              14.05.2015 18:04
              #8417903
              +4

              Отсутствие отступов не подтасовка если отступы управляются человеком. Человек может ошибиться.

              Извините за грубость, но без отступов это просто г-нокод. Мешанина, которую нереально разобрать — тут и подсветка не поможет.

              Плюс в вашем примере (если говорить не о «полнотекстовых» языках вообще, а именно о паскале и его производных), отличие в ";" в случае оператора. Плюс в этих язык традиционен camelcase. Сравните, например:

              if x > y then
              begin
              Becin;
              Emd();
              end;

              Прочесть все же легче.


              1. ApeCoder
                14.05.2015 18:15
                #8417939
                +2

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

                Лучше всего когда скобок вообще нет, а есть только оступы — нечему рассогласовываться. Но если они все-таки есть, то лучше что их было труднее спутать с остальными словами.


                1. MacIn
                  14.05.2015 18:22
                  #8417951

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

                  Если есть единый style guide, то не вижу причин.


                  1. ApeCoder
                    14.05.2015 18:31
                    #8417973

                    Если есть единый стайлгайд И софт который это проверяет или автоматически переформатирует. Кстати как с эти у Оберона?


                    1. MacIn
                      14.05.2015 19:06
                      #8418029

                      Не, я скорее про Вирта с его begin/end ами, которые наиболее известны в Паскале, против {} в других языках, чем про конретно Oberon.


              1. akastargazer
                15.05.2015 10:33
                #8418859

                А можно ещё
                IF x > y THEN
                Becin;
                Emd()
                END;


            1. Alexeyslav
              15.05.2015 10:55
              #8418903
              -1

              Вообще в программировании ценится не скорость считывания программы с экрана…

              Зато автоматическое выравнивание никогда не ошибается.

              Я бы вообще представлял программы в 3-х мерном виде(активный уровень на переднем плане) в виде дерева. там никакие скобки не нужны были бы. Всякие эти скобочки, выравнивание — оно нужно только для возможности редактирования текста программы в простых плоских редакторах. Если создать такой софт, где программа редактировалась бы на объектном уровне — все эти заморочки с отступами и скобками просто не нужны были бы.


              1. oberon87
                15.05.2015 11:06
                #8418917

                Движение в эту сторону есть, как мне кажется cyberleninka.ru/article/n/razrabotka-mnogoyazykovogo-redaktora-na-osnove-semanticheskoy-modeli-programmy.pdf
                При этом, что интересно, оберон взят за один из базовых представлений.


                1. Alexeyslav
                  15.05.2015 11:09
                  #8418927

                  Да, это несомненно хорошо. Идея просто витала в воздухе, но жаль что это реализуют только сейчас.


          1. mayorovp
            15.05.2015 07:10
            #8418585

            Вот тут вы и показали основную проблему Паскаля. Писал на нем 5 лет — но за все это время так и не смог подобрать правильного способа написания конструкции «end else begin», которая бы нормально читалась хотя бы мною же :)


            1. akastargazer
              15.05.2015 07:56
              #8418617

              Паскаль давно устарел, есть же Оберон.


            1. merlin-vrn
              15.05.2015 21:36
              #8420069
              +1

              Такая конструкция и в си ужасно выглядит — как разбазаривание пространства в духе

              }
              else
              {


              1. mayorovp
                15.05.2015 21:58
                #8420087

                Скобки и else хотя бы разного размера — сразу видно что где. И редактор их зачастую разным цветом подсвечивает, что тоже помогает.


                1. Alexeyslav
                  18.05.2015 08:21
                  #8421667

                  Когда разный цвет подсветки, то слова будут заметнее и контрастнее.


                  1. mayorovp
                    18.05.2015 18:52
                    #8422687

                    К сожалению, в паскалеподобных языках все три слова попадают в категорию ключевых слов. Я не видел еще ни одного редактора, который умел бы подсвечивать ключевые слова разными цветами.


                    1. Alexeyslav
                      19.05.2015 09:17
                      #8424383

                      «Notepad++» и ему подобные — настраивается синтаксис в том числе и группы ключевых слов. Под паскаль не пробовал, но давно настраивал его под ассемблер PIC и AVR контроллеров с выделением разным цветом групп команд и даже макросов.


            1. MacIn
              18.05.2015 19:13
              #8422727

              У нас приняли такие правила:

              1)
              if <condition> then op1 else op2;

              2)
              if <condition> then begin op1; op2; end else begin op3; op4; end;

              if <condition> then op1;

              Как вариант — begin op1; op2; end else begin end

              Главное — размещать все на отдельных строках, тогда ключевые слова не сливаются в кашу, даже когда идет подряд end else begin они не сливаются. Если выделять блоки begin end дополнительным отступом, разница между блоком и else еще виднее.
              Плюс никогда не ставить ничего на той же строке, что и if.

              Друзья, только у меня поломаны блоки — source и block quote?


              1. mayorovp
                18.05.2015 19:22
                #8422741

                Вы имеете в виду вот так?

                if condition
  then
    begin
      op1;
      op2;
    end
  else
    begin
      op3;
      op4;
    end;


                Да, я тоже в итоге пришел к такому. Но сколько же места на экране оно занимает… Особенно при 50 строках на экране. Надеюсь, хотя бы последняя проблема сегодня перестала быть актуальной у большинства паскальщиков!


                1. Mrrl
                  18.05.2015 19:26
                  #8422749

                  Так 25 же строк было! Или даже 24. Откуда в CGA/EGA 50?


                  1. mayorovp
                    18.05.2015 19:32
                    #8422759

                    При чем тут CGA/EGA? Я олимпиады уже в основном под Windows писал (кроме старого комп. класса в ЮУрГУ во втором корпусе, где были бездисковые рабочие станции под DOS — но даже там 50 строк были доступны).

                    Только вот регламент был еще старый, и Delphi в списке разрешенных сред разработки не было. Только Free Pascal (или даже Turbo Pascal), и что-то такое же текстоворежимное для С++.


                  1. MacIn
                    18.05.2015 20:16
                    #8423637

                    Надо еще постараться, чтобы встретить EGA. Последний раз работал с EGA еще до выхода W95.


                    1. Mrrl
                      18.05.2015 20:59
                      #8423695

                      Я тоже. И Паскаль я в последний раз видел тогда же.


                      1. MacIn
                        18.05.2015 21:43
                        #8423753

                        2006г первый курс универа — во весь рост.


                1. MacIn
                  18.05.2015 20:15
                  #8423633

                  Да, это почти последний вариант. Но не совсем.
                  if then
                  else
                  остальные части — с отступами. Т.е if и else на одном уровне. Можно и begin..end на том же уровне, но так все же похуже.
                  Отчего в моем сообщении не работает source тэг… судя по вашему комментарию, он не только у меня не виден.

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


                1. Alexeyslav
                  19.05.2015 09:21
                  #8424387

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


                  1. Mrrl
                    19.05.2015 09:32
                    #8424401
                    +2

                    Но ведь при работе со сложным кодом очень полезно, если он будет виден одновременно — чтобы можно было разбираться во взаимосвязях и отслеживать варианты исполнения, не гоняя текст вверх-вниз. Конечно, тот, кто его писал, всё это и так помнит, но надо же позаботиться и о тех, кто будет читать?


                    1. Alexeyslav
                      19.05.2015 13:15
                      #8424877

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


                1. akastargazer
                  19.05.2015 10:48
                  #8424549

                  На Обероне:

                  IF condition THEN
                  op1; op2
                  ELSE
                  op3; op4
                  END;


                  1. MacIn
                    19.05.2015 18:04
                    #8425563

                    Напомнило Бейсик:

                    IF condition THEN
                    op1: op2
                    ELSE
                    op3: op4
                    END IF


                    1. MacIn
                      20.05.2015 16:41
                      #8427071

                      Отчего минусите-то? Разница рельно только в двоеточии и «END IF»


                      1. Alexeyslav
                        20.05.2015 16:51
                        #8427081

                        Видимо, слово «Бейсик» по отношению к языкам программирования для многих считается ругательным…


                      1. akastargazer
                        20.05.2015 16:59
                        #8427097

                        На хабре отклонение от линии партии карается.


                      1. OberonForGood Автор
                        20.05.2015 17:01
                        #8427105
                        -2

                        Это стремление сделать ваш комментарий прозрачным, чтобы его не было видно.


        1. OberonForGood Автор
          20.05.2015 16:06
          #8427027

          Шутки за 28.


  1. MichaelBorisov
    14.05.2015 15:53
    #8417603
    +6

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

    Фичи можно и нужно выкидывать не только из языков программирования, а вообще из всего. Если они затратны в реализации и мало полезны на практике.

    Взять сетевые протоколы. Взять тот же IPv4. Хорошая, вроде бы, идея — реализовать фрагментацию пакетов. Но опыт работы интернета показал, что фрагментация — зло, она или не реализована у некоторых абонентов, или реализована криво (и это создает уязвимости), или реализована хорошо, но с огромными затратами ресурсов (память, процессор). А теперь, если вернуться к исходному положению и еще раз подумать, нужна ли вообще эта фрагментация, если она дается такой ценой? И люди пришли к твердому «нет»: не нужна. И в IPv6 ее выкинули (хотя, к сожалению, не до конца).

    И так во всем. Overengineering — бич современного мира технологий. Но люди учатся на ошибках, приходят к пониманию того, что лучше сделать проще. Технологии становятся проще, и за счет этого совершеннее, там, где это возможно. По-видимому языки программирования — это то направление, которое находится далеко не в конце своего развития. Отсюда и недостатки многих существующих языков. Трудно найти тот минимально необходимый набор возможностей языка, который имел бы приемлемую цену в реализации и давал при этом большую пользу в облегчении программирования. Но люди трудятся над этой задачей. Тут нужны годы опыта всего сообщества. Когда-нибудь найдутся лучшие решения.


    1. StrangerInRed
      14.05.2015 15:59
      #8417615
      +1

      Да уже сталкивались с этим же, во время войны RISC и CIST. В итоге обернули второе под первое и все.


    1. NeoCode
      14.05.2015 17:36
      #8417833

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


      1. EndUser
        15.05.2015 07:21
        #8418595

        По теореме Гёделя о неполноте, для любого языка программирования всё равно будут встречаться задачи, неописуемые этим языком. Поэтому языки и развиваются ;-)

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

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


  1. RPG18
    14.05.2015 16:06
    #8417639
    +3

    Глава «Новый выстрел „Серебряной пули нет“» Брукса из его Мифический-человека месяц начинается с гениальной цитаты Александра Поупа:

    Кто хочет увидеть образец совершенства,
    Тот мечтает о том, чего никогда не было, нет и не будет.


  1. Duduka
    14.05.2015 16:10
    #8417645
    +2

    compact-programming.narod.ru/Index.htm
    В одном флаконе, и зачем так гневаться, ну не осталось инженеров в IT, значит так и надо.


    1. NeoCode
      14.05.2015 17:32
      #8417825

      О, олдскульный сайтик на народе… они еще существуют:) Когда-то давно во времена диалапа я по крупицам собирал интересную информацию с таких вот страничек…


  1. max-kuznetsov
    14.05.2015 16:23
    #8417673
    +5

    Я наблюдал развитие средств разработки последние два десятка лет. И меня не покидает смутное сомнение. Средства разработки становятся «как бы проще»: не надо выделять память и потом следить за её освобождением, не надо думать, на что указывает указатель, не надо даже скобки расставлять… Но вот объём знаний, который должен иметь разработчик, чтобы сделать действительно серьёзный продукт, от этого нисколько не уменьшается. И даже наоборот, растёт чуть ли не по экспоненте. Каждая среда разработки, каждый фреймворк вносят свои абстракции, и на первый взгляд всё работает. Но наступает момент, когда абстракция начинает трещать по всем швам. И тогда приходится лезть в глубины того же фреймворка и смотреть, что у него не так с той же памятью, с теми же указателями…

    Т.е. простота и удобство инструментария не отменяет знаний глубин взаимодействия софта и железа.

    И по мере того, как эта истина проявлялась, возникал вопрос: почему? Моё ощущение, что разработчики сред разработки в определённый момент начали гонку за студентами и топ-менеджерами, приучая их именно к своему детищу. Когда я был студентом, были популярны C++ и Delphi. Потом стала набирать популярность Java, потом появился C#. Как бизнес набросился на RAD-разработку! Это же целый прорыв: за мизерные деньги можно было сделать свой http-сервер! И как потом бизнес-сообщество приняло .NET!..

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

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


    1. ApeCoder
      14.05.2015 16:42
      #8417735
      +4

      > Но в целом легче программистам от этого не стало

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


      1. max-kuznetsov
        15.05.2015 09:53
        #8418773
        +2

        Я не сказал, что продвинутые инструменты — это плохо. Я сказал, что трудозатраты не стали меньше, они перераспределились: вместо того, чтобы возиться с памятью, программист теперь учит, что такое управляемый код, как работает GC и как его приручить, чтобы программа работала оптимально. При этом пониманием того, как выделяется память при работе программы, программист всё равно должен обладать. Т.е. вместо того, чтобы тратить время и силы на поиск уязвимостей в своём коде и учиться писать свой код правильно, программист теперь тратит время и силы на получение кучи дополнительных знаний и навыков, а потом ищет уязвимости и в своём коде, и в коде фреймворка.

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

        Я знал программистов, которые писали на Delphi, и когда пришёл .NET, они не смогли найти себе хорошее место работы, поскольку не понимали разницы в абстракциях Delphi и C#. И я знаю проекты, которые программисты не смогли в нужный момент перевести с Delphi на C#, из-за чего бизнес их владельцев серьёзно пострадал.

        Инструменты и сторонние решения — это хорошо, но с существенными ограничениями.


        1. FiresShadow
          15.05.2015 11:09
          #8418923
          +1

          вместо того, чтобы возиться с памятью, программист теперь учит, что такое управляемый код, как работает GC

          Как по мне, изучить принцип работы сборщика мусора гораздо проще, чем best practices работы с памятью и методы поиска багов из-за неправильной работы с памятью. Это ж ещё нужно догадаться, что баг именно в ошибке работы с памятью, когда метод одного класса вышел за пределы массива и переписывает данные другого класса, причём с периодичностью 1 раз на 100 запусков. Так что трудозатраты при работе с памятью, имхо, всё же уменьшились.


      1. Alexeyslav
        15.05.2015 11:08
        #8418919
        +1

        В итоге все работает по принципу — «не трожь не упадёт». Очень уж много костылей и взаимно компенсирующихся ошибок приходится вводить чтобы всё работало так как задумано. Этого не пришлось бы делать в случае разработки с нуля, без фреймворков и вдумчивым проектированием. Но бизнесу надо здесь и сейчас, ну подумаешь что внутри оно работает благодаря магии и чистой случайности, главное как выглядит снаружи.
        Посмотрите на математиков/физиков — практически у каждого свой наработанный и вылизанный до идеала фреймворк с которым они и работают. Ситуации когда у них что-то рушится по причине неправильной работы фреймворка очень редки. А всё от чего — они не спешат сломя голову и у них практически всё формализовано до последнего символа, опечатки чисто по невнимательности при наборе текста.


        1. ApeCoder
          15.05.2015 12:25
          #8419093
          +1

          > Но бизнесу надо здесь и сейчас

          Соответственно, с их точки зрения использование Фреймворков лучше


          1. Alexeyslav
            15.05.2015 15:14
            #8419413

            А дыры залатывать это когда нибудь потом, и вообще «вы обещали что оно будет работать — чините бесплатно».


            1. Fedcomp
              15.05.2015 16:09
              #8419565
              +2

              Дыры залатывать, да и сильно потом переделывать как раз потом придется на самописном фреймворке. В код которого широкая общественность не глядела, код которого к best practices никто никогда не приведет. Как раз таки потому что «нужно здесь и сейчас», а потом времени на это не будет, будет другой проект/новая фича


              1. akastargazer
                15.05.2015 16:28
                #8419603
                +1

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


                1. Duduka
                  15.05.2015 17:47
                  #8419807

                  А есть язык который не «протухает»?! Единственное будущее программистов — переписывание программ под новые реалии (протоколы, топологии, устойства,… языки).


                  1. akastargazer
                    15.05.2015 17:57
                    #8419825
                    +1

                    Есть, и этот язык называется Оберон :)


                    1. qw1
                      15.05.2015 18:02
                      #8419833

                      И FORTRAN


                      1. akastargazer
                        15.05.2015 18:03
                        #8419835

                        Фортран вечен!


                        1. Duduka
                          15.05.2015 18:11
                          #8419851
                          +2

                          FORTRAN IV, FORTRAN 66, FORTRAN 77 (или имели в виду RATFOR?), FORTRAN 90… или FORTRAN 2003!?
                          Оберон 1/2/active/CP.../7 где вечен?! Кончайте стебаться, тем более над этими зомби…


        1. Mrrl
          15.05.2015 15:41
          #8419487
          +2

          Посмотрите на математиков/физиков — практически у каждого свой наработанный и вылизанный до идеала фреймворк с которым они и работают. Ситуации когда у них что-то рушится по причине неправильной работы фреймворка очень редки. А всё от чего — они не спешат сломя голову

          Не уверен… Постоянно возникают новые задачи, для которых нужны новые структуры, методы, расширение библиотеки. Часто оказывается, что в давно готовом и работающем классе чего-то не предусмотрели — и нужно либо писать что-то в обход этого места, либо дорабатывать класс. В последнем случае свойство «наработанный и вылизанный до идеала» нарушается. А надо идти вперёд — задача не ждёт, а впереди ещё следующие развития. Для которых пока совершенно неизвестно, какие ещё функции потребуются. По сравнению с R&D то, что здесь пишут про бизнес — идеал качества и продуманности.


        1. intet
          15.05.2015 15:44
          #8419499
          +1

          Программы написанные физиками/математиками настолько вылизаны до идеала, так что они не публикуют их в приложении к статьям. Ибо им просто банально стыдно, за написанный код.


          1. max-kuznetsov
            15.05.2015 15:51
            #8419517
            +1

            Нет, им не стыдно. Это я как физик говорю. Просто их программы настолько специфичны, что представляют интерес только для узкого круга их коллег. А вылизаны проги, действительно, до мельчайших деталей. Иначе расчёты просто не сходятся.

            Хотя понятие качества у них, конечно, своё.


            1. intet
              15.05.2015 15:58
              #8419539
              +1

              Странно. Совсем недавно была статья, насколько все плохо с научным софтом. Софт пишут непрофессионалы в программировании и он не самого высокого качества.


              1. max-kuznetsov
                15.05.2015 16:06
                #8419555

                Это Вы о статье про британских учёных? Да, слышали-слышали об их открытиях…

                Вот, целый ворох:
                ссылка
                ссылка
                ссылка


              1. akastargazer
                15.05.2015 16:08
                #8419563
                +1

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

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


                1. intet
                  15.05.2015 17:21
                  #8419733
                  +1

                  Ученые используют очень ограниченный набор возможностей языка. Для них язык не становится сложнее или легче с появление рефлексии, так как они ее просто не встретят. Так же с большуй частью нововведений. Ученым они просто не попадутся на глаза и не будут мешать или помогать.
                  Зато например лямбды упрощают жизнь, хотя и являются довольно сложными для понимания возможностями языка.


            1. Mrrl
              15.05.2015 16:05
              #8419551
              +1

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


              1. Alexeyslav
                18.05.2015 08:28
                #8421671

                Это вполне возможно и математикой не отрицается. Возможно, эти части формул просто слабо влияют на результат.


                1. Mrrl
                  18.05.2015 09:22
                  #8421711

                  Просто там используются итерационные методы :) Движение на каждом шаге идёт слегка в другом направлении, но сходится всё равно к той же точке.


    1. FiresShadow
      15.05.2015 08:22
      #8418639
      +2

      Споэльски в своей статье про протекающие абстракции описал точку зрения, схожую с вашей. Однако я больше склоняюсь к высказыванию Эрика Эванса на этот счёт: «Рутинная деятельность должна быть автоматизирована. Автоматизация того, что должно быть трудом программиста, контрпродуктивно». Если инструмент автоматизирует то, в чём нужна свобода манёвра, то он ограничивает свободу действий программиста. Если абстракция инструмента протекает, то программисту приходится залезать в его внутренности. Если в инструменте есть баги, программисту приходится прикручивать костыли. Я думаю, что проблема может быть в недоработанности, недостаточной документации, плохой архитектуре инструментов, а не в их сложности. Например, современные ORM не имеют утилит для анализа запросов и автоматической генерации индексов, не умеют оптимизировать запросы, поэтому иногда приходится при помощи профилировщика смотреть, какой sql код они генерируют. Но если исправить эти и некоторые другие недоработки, то ORM станет более сложным, но более удобным инструментом, и программистам, использующим его, не будет необходимости знать sql. Таким образом, имхо, проблема не в сложности инструментов, а в их недоработках или изъянах.


      1. max-kuznetsov
        15.05.2015 10:04
        #8418793
        +2

        Развитие ORM — вещь неизбежная, и не скажу, что это плохо. Но я всё же пойду и разберусь, как эти новые штуки работают изнутри, и заставлю своих проггеров выучить sql. Чтобы, когда ORM стуканёт на каком-то запросе, мы могли быстро поставить заплатку. А когда стуканёт у Вас, мы могли с этого поиметь ещё и дополнительную денюжку.


        1. FiresShadow
          15.05.2015 10:18
          #8418821

          Кажется, вы меня немного не поняли. Я не говорил, что гарантированно наступит светлое будущее, когда ORM ни разу не «стуканет». Я говорил, что если ORM будет настолько хороша, что никогда не «стуканет», то рядовому программисту не будет необходимости знать подробности её работы. Многие не знают как устроена файловая система, но успешно ей пользуются. Файловая система — хорошая, не протекающая абстракция.


          1. akastargazer
            15.05.2015 10:22
            #8418827
            +3

            К сожалению, ORM никогда не будет настолько хороша. Причина банальна — концептуальную сложность предметной области невозможно полностью охватить механическим маппером, ведь концепции декларативного SQL и объектной модели разные. Поэтому у вас постоянно будет проседать либо сложность (просто, но быстро), либо производительность (сложно, но медленно).


            1. FiresShadow
              15.05.2015 10:29
              #8418845

              В XIX веке некоторые примерно также объясняли невозможность полёта на Луну. Или, может быть, дело не в этом, и вы просто пророк?


              1. akastargazer
                15.05.2015 11:59
                #8419031
                +1

                Наступил век XXI, но до сих пор никто не понимает, как справляться с нарастающей сложностью. Это, кстати, не я сказал, а Дейкстра.


            1. FiresShadow
              15.05.2015 11:35
              #8418985

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


              1. akastargazer
                15.05.2015 11:55
                #8419019
                +1

                Я уже пояснил.
                > концепции декларативного SQL и объектной модели разные


                1. FiresShadow
                  15.05.2015 12:25
                  #8419091

                  Всё равно не понимаю, «стуканёт», как глагол в будущем времени, предполагает некое действие в будущем. Какое действие? Я не спорю, концепции реляционного SQL и объектной модели разные, но при чём тут принципиальная невозможность ORM когда-либо стать инструментом, для использования которого знание глубинных принципов его работы не являлось бы обязательным навыком? Различие в концепциях является лишь причиной, мешающей полностью абстрагироваться от самого существования базы данных, но не более того.

                  Почти любой инструмент предполагает выполнение некоторых обязательных требований. Для сборщика мусора, например, это требование не делать циклических ссылок между объектами. Но это не значит, что все инструменты — протекающие абстракции. Но современные ORM, даже при соблюдении всех подразумевающихся требований, всё равно обязывают знать как они работают: часто нужно увидеть sql-запрос, сгенерированный где-то в недрах ORM и посмотреть, какого индекса не хватает, потому что ORM не может сама создавать индексы. А если бы ORM сама заботилась об индексах и генерировала оптимальные запросы, то такой необходимости не было бы.


                  1. akastargazer
                    15.05.2015 13:17
                    #8419175
                    +2

                    Разные концепции — это сова и глобус. Натяните сову на глобус и где-то что-то порвётся или треснет.

                    Разные концепции заставляют использовать разные формальные аппараты. А у формального аппарата есть ограничения.

                    Если бы ORM решала все проблемы, то абстрагирование от сервера БД было бы полным и вас бы не беспокоили особенности генерации SQL-запросов. Но вам приходится учитывать особенности реляционной модели вручную.


                    1. FiresShadow
                      15.05.2015 13:51
                      #8419243

                      Если бы ORM решала все проблемы, то абстрагирование от сервера БД было бы полным и вас бы не беспокоили особенности генерации SQL-запросов.

                      Согласен с тем, что если абстрагирование от сервера БД было бы полным, то не беспокоили бы особенности генерации SQL-запросов. Не согласен с тем, что полное абстрагирование от реляционной БД — единственно возможное решение проблемы необходимости отслеживания получившихся SQL-запросов.

                      Вы говорите нечто похожее на «трава зелёная, потому что африканские дети голодают». В том что африканские дети голодают, сомнений нет, но при чём тут трава? В том, что концепции реляционного SQL и объектной модели разные, сомнений нет, но при чём тут принципиальная невозможность ORM когда-либо стать инструментом, для использования которого знание глубинных принципов его работы не являлось бы обязательным навыком?


                      1. akastargazer
                        15.05.2015 14:25
                        #8419297
                        +2

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

                        Проблемы ORM описаны даже в википедии, поэтому не буду про них говорить технически. Попробую рассуждать концептуально.

                        Реляционная и объектная модели дают нам язык для описания прикладных сущностей. В чём их отличия?

                        Реляционная модель даёт мощные средства для работы со множествами. С помощью реляционных выражений мы легко определяем любые множества любых сущностей.

                        Объектная модель используется для декомпозиции предметной области. С помощью ООП мы моделируем сущности предметной области и отношения между ними.

                        Но, какие средства даёт нам ООП для работы со множествами? Ответ — никаких, если не считать понятия класса (кстати, в недавнем обсуждении Smalltalk был выдвинут странный тезис, что для ООП классы не нужны, хотя объект в ООП всегда определяется через множество, которому он принадлежит, пусть даже в языке нет слова class).

                        Поэтому в аспекте работы со множествами объектная модель всегда отстаёт от реляционной. То, что вы делаете одним SQL-запросом, преобразуется в тонну объектного кода (пусть даже скрытого в ORM-прослойке).

                        И обратная ситуация, ваш автоматический объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами, поэтому всегда остаётся вероятность ручного вмешательства.


                        1. FiresShadow
                          15.05.2015 15:19
                          #8419423
                          -2

                          ваш автоматический объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами

                          Почему никогда не сможет? Это ваше утверждение хоть как-то связано с тем, что вы до этого написали? Или вы это просто так утверждаете, «без связки»? Если всё-таки связано и по-вашему не сможет, потому что концепции разные, то я отвечу, что программа, написанная на языке концепции логической парадигмы, совершенно спокойно может быть транслирована в программу в процедурной парадигме. Хотя в процедурной парадигме и есть понятия, отсутствующие в логической: например, понятия переменных и функций. Почему из логической в процедурную легко, а из объектно-ориентированной в реляционную ну никак? Запрос к бд, написанный на ООП языке, неплохо транслируется в реляционный SQL. Да, есть некоторые ограничения: нужно использовать методы Where(), Select() и прочее. Да, SQL запрос не всегда получается оптимальным. Но почему он не оптимален? Индекса например не хватает. Давайте научим ORM создавать индексы. Или не оптимален, потому что ORM не поддерживает иерархические запросы. Давайте её и этому научим. Назовите хотя бы одну принципиально нерешаемую проблему, которая мешает ORM всегда эффективно работать со множествами. Или опишите пожалуйста одним предложением причину, почему «объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами», (например, «не сможет, потому что сову на глобус натянуть невозможно») но только чтобы между причиной и следствием была логическая связь.


                          1. akastargazer
                            15.05.2015 15:33
                            #8419457

                            «никогда не сможет всегда», читайте внимательнее.

                            Да, есть некоторые ограничения: нужно использовать методы Where(), Select() и прочее.
                            То есть, вы в императивный язык тащите декларативные куски, чтобы склеить концептуальный разлом.

                            Давайте научим ORM создавать индексы.
                            Что здесь сложного и почему вы про это говорите сейчас, когда существуют тонны ORM-фреймворков?

                            Да, SQL это не логический язык, а декларативный.

                            Если вы не хотите обсуждать на концептуальном уровне, читайте тогда технические вещи: en.wikipedia.org/wiki/Object-relational_impedance_mismatch


                            1. FiresShadow
                              15.05.2015 16:29
                              #8419607
                              +1

                              Я вас просил назвать причину, по которой ORM в некоторых случаях не сможет сгенерировать оптимальный sql-запрос, а вы вместо этого начали мне в сто-пятьсотый раз доказывать, что есть различие в концепциях реляционной БД и ООП, даже ссылку скинули. Я много раз повторял: «Я не спорю, концепции реляционного SQL и объектной модели разные, но при чём тут принципиальная невозможность ORM когда-либо стать инструментом, для использования которого знание глубинных принципов его работы не являлось бы обязательным навыком?», а вы опять включили свою заезженную пластинку. Из этого делаю вывод, что вы либо избирательно не читаете то что я пишу, либо докопаться до истины для вас не главное. В любом случае не вижу никакого смысла убеждать вас далее.


                              1. akastargazer
                                15.05.2015 16:35
                                #8419615
                                -1

                                Причина проста — у вас не хватит денег на такой красивый ORM.


                            1. sferrka
                              17.05.2015 13:03
                              #8421181
                              +2

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

                              where и select можность использовать в любом языке, функциональном в том числе:

                              (where (select Model1) :name "example")


                              Как это мешает существованию ORM, какой тут концептуальный разлом?


          1. max-kuznetsov
            15.05.2015 11:56
            #8419021

            Файловая система — хорошая, не протекающая абстракция.


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

            Есть замечательный закон Джилба:
            Любая система, зависящая от человеческой надежности, ненадежна.


            То же самое касается ORM. ORM стуканёт. Вопрос только в том, при каких обстоятельствах это произойдёт и какой ущерб это принесёт. И если система, использующая ORM, спроектирована с учётом этих моментов, эта система может быть надёжнее самой ORM. А если нет, то чей-то бизнес оказывается в прямой зависимости от чужого кода.


            1. FiresShadow
              15.05.2015 12:46
              #8419133
              +1

              с разрушением дисковой памяти

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


              1. akastargazer
                15.05.2015 13:21
                #8419179
                +1

                Если у вас есть хорошо спроектированный формальный аппарат, то необходимое количество знаний резко уменьшается. Оберон именно про это.

                Если формальный аппарат спроектирован плохо\недальновидно, то новые задачи предметной области станут болотом, где увязают усилия разработчиков. Потребуются новые понятия, чтобы закрыть лакуны в старых, а новые понятия это всегда лавинообразный рост взаимосвязей, приводящий к комбинаторному взрыву. В итоге спутник падает.


  1. ilmirus
    14.05.2015 16:44
    #8417741
    +8

    Прошу прощения, но я не согласен с автором, хотя и поддерживаю некоторые его аргументы.

    При всем уважении в профессору Вирту, его оценка сложности языков программирования основана на правилах грамматики, то есть, говоря по-простому, оценивает лишь синтаксис, не затрагивая семантику. Однако, проблема в том, что семантику сложно, а в большинстве случаев невозможно оценить в цифрах. Я уже не говорю о том, что само понятие «семантика» _немного_ расплывчато. Тем не менее, я следую понятию семантики из википедии: ru.wikipedia.org/wiki/%D0%A1%D0%B5%D0%BC%D0%B0%D0%BD%D1%82%D0%B8%D0%BA%D0%B0_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29

    Таким образом, семантически следующие конструкции эквивалентны (JS):
    1) for(var i in [1,2,3]) { sum += 2*i }
    2) [1,2,3].map(function(a) {return 2*a}).reduce(function(a, b) { return a+b }, 0)

    Так же как и следуюшие (С++):
    1) for (int i = 0; i < vec.size(); i++) { sum += i*2 }
    2) for (auto i = vec.begin(); i != vec.end(); ++i) { sum += *i * 2 }
    3) std::for_each(vec.begin(), vec.end(), [](int i) { sum += i*2 }

    Однако, в С++, результирующий ассемблерный код будет одинаков (в релиз версии). Что в случае JS? Ээээ. Ну… В V8 уж точно нет. Но я сейчас не об этом (и да, я утрирую).

    Так вот. Какая разница, сколько синтаксических фич у языка!? Главное, какая у языка семантика, то есть сколько различных смыслов можно описать на языке. И если у языка столько различных семантических фич, сколько, например, у С++, то он будет сложен, но и областей применения у него будет больше, чем, например, у JS.

    Другой вопрос, на рассмотрение которого, у сожалению, формат комментария маловат — это как раз области применения. Я покручу у виска, если кто-либо всерьез предложит программировать микроконтроллеры на JS (такое уже было трижды на моей памяти), или будет парсить сайты (один раз, то есть производительность не важна) на чистом C. Кроме того, области применения постоянно возникают и исчезают. Кто десять лет назад задумывался о вычислениях на GPU? Но сейчас это реальность. И где язык, заточенный под GPU? Есть, конечно, попытки пришить собаке пятую ногу, например, С с новыми ключевыми словами и несовместимый ни с одним существующим компилятором, Фортран, С и С++ с новыми прагмами, но ни одного нового языка.

    А теперь у меня вопрос к вам, автор. Как можно добавить поддержку GPU в Оберон, не усложняя его? Или она уже есть?


    1. OberonForGood Автор
      14.05.2015 17:19
      #8417789
      +3

      Хотелось бы уточнить, что автором графика является не Н. Вирт, это просто его заслуги отображени на картинке зеленой линией.
      Исходный текст тут www.uni-vologda.ac.ru/cs/syntax/ariphm.htm
      В последующих обсуждениях автору картинки предлагали считать уже примитивы AST. Но так как грамматика для человека, а AST для компилятора, то я бы оставил именно грамматику показателем динамики усложнения языка (не сравнительной сложности, а просто сложности). Есть же объективные пределы человеческого мозга, что и сколько надо держать в памяти. Каждый раз, добавляя ключевое слово в язык, вы повышаете нагрузку на мозг.

      Не работал с вычислениями на GPU, но читал о них.
      Насколько я понимаю, ключевых особенностей несколько: необходимость передавать данные в память/из памяти GPU, необходимость поддерживать структуры, пригодные для массово-параллельной обработки набора значений за одну инструкцию, необходимость эффективного управления тысячами вычислительных циклов на каждом маленьком ядре GPU. Вполне очевидно, что возникает необходимость в отдельном DSL, возможно, на базе Оберона. Но совмещать концепции в одном языке, как мне кажется, будет контрпродуктивно. То есть, гетерогенный язык это трудно. А вот гетерогенные компоненты составить уже возможно. Линковщик разберет продукт компиляции кода для CPU и GPU и что-то сможет предпринять. Но это мои частные рассуждения.


      1. ilmirus
        14.05.2015 17:50
        #8417871
        +3

        Спасибо за информацию. Значит, Вирт не автор этого исследования. Буду знать.

        Кстати, я не вижу на картинке Лиспа, у которого то ли 2, то ли 3 грамматических правила…

        Насчет языков: О Харухи, как я с вами согласен! Это настолько разные концепции, что пришивать пятую ногу к существующим языкам — значит ограничивать возможности GPU. Именно поэтому я говорю, что нужен новый язык для GPU, отстаньте вы от старичка Фортрана. Но рынок уже рассудил, что лучше пускать отдельные циклы на GPU, а не пытаться переписать всю программу на новом языке. И это можно понять. Таков мир, к сожалению.


      1. Yuuri
        24.05.2015 17:23
        #8431747
        +5

        Для такой логики в обероне что-то многовато ключевых слов (вроде бы 32, тогда как, наприме, в хаскеле, который хронически считают сложным, — около 25). Навскидку — зачем MOD, DIV, AND, OR, которые даже не расширяют язык новыми конструкциями, а всего лишь являются слегка замаскированными функциями; разве нельзя было сделать их библиотечными, зачем усложнять язык?


        1. oberon87
          26.05.2015 01:09
          #8433845
          -6

          Вам из погреба виднее.


    1. MuLLtiQ
      14.05.2015 20:14
      #8418101

      1) for(var i in [1,2,3]) { sum += 2*i }
      2) [1,2,3].map(function(a) {return 2*a}).reduce(function(a, b) { return a+b }, 0)

      Первый пункт некорректен, вы получите «6» вместо 12. Можно использовать ES6:
      var sum = 0; for (let i of [1, 2, 3]) sum += 2 * i;
var sum = [1, 2, 3].map(a => 2 * a).reduce((a, b) => a + b, 0)


      1. ilmirus
        15.05.2015 01:37
        #8418503

        Согласен.


  1. NeoCode
    14.05.2015 17:21
    #8417797
    +7

    Самый простой язык это не оберон, а brainfuck — всего 4 оператора и ничего больше. И разумеется, на нем можно писать программы. Но нужно ли?
    Фичи — это не просто какой-то «синтаксический сахар» (вообще странное словосочетание:) ), это нечто, дающее новые возможности.

    Например, рефлексия. Она есть в обероне? А это необходимая фича для автоматического связывания кода программы с внешними данными (например сериализация в xml). Разумеется, это можно сделать вручную — не забыв аккуратно прописать для каждого поля каждой структуры процедуру чтения и процедуру записи. Все можно сделать вручную. Более того, любую программу можно написать на ассемблере и даже в машинных кодах вручную. Но нужно ли?

    Или те же самые шаблоны и метапрограмминг. Да, это следующий уровень программирования, и конечно, он может быть проэмулирован вручную — аккуратным написанием тех же векторов, списков и алгоритмов для каждого типа. Но зачем, если есть удобный инструмент под названием «метапрограммирование»? То что он в С++ поехал не в ту степь — да, это нужно пофиксить (и ввести новые фичи, специально спроектированные для решения задач, для которых в С++ используют метапрограммирование на шаблонах), но зачем отказываться?

    В той статье я не затронул многие вещи. Например, особенности добавления фич в современные языки. В большинстве случаев они добавляются бессистемно и, что самое печальное, они слабо связаны между собой. Вот это реально проблема. А количество фич — оно вполне разумно во всех существующих языках, я еще не встречал такого языка чтобы можно было запутаться в его синтаксисе. И стремиться их минимизировать вообще странно, это всего лишь инструменты — удобные инструменты для решения соответствующих задач; какой смысл например при создании чего-то (строительстве дома или там космического корабля) стремиться ограничить себя в инструментах???


    1. OberonForGood Автор
      14.05.2015 17:29
      #8417815
      -5

      Это не сравнительный график языков, это совмещенные графики динамики эксплозии синтаксиса. Но и простоту с примитивностью путать не стоит.

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

      Это разные подходы. В ситуации незнания кто-то предпочитает «делать» фичи, а кто-то выбирает «не делать» фичи. Ну а рассудил всех рынок. Деятельные люди там в почете.


      1. NeoCode
        14.05.2015 17:48
        #8417863
        +1

        Как рефлексия может работать в компонентах, если от компилятора требуется например связать объект с его строковым именем (которое известно только на этапе компиляции) и предоставить эту информацию другим частям программы? Тут или рефлексия, или ручками прописывать — других вариантов нет.

        Шаблоны при правильной реализации никакой связи с кодом не лишают. Даже обычный оператор присваивания — это шаблон, потому что в конечном итоге для целых чисел вызывается один набор ассемблерных команд, для float — другой, а для строк вообще третий. Вы же не утверждаете что оператор присваивания лишает вас связи с кодом?

        «Никто не знает, насколько та или иная фича нужна в языке» — почему же, практикующие программисты знают. Я приводил в пример Буст — это все не с потолка придумано, а для решения конкретных задач. Другое дело, что идеологически многое там — не полноценные фичи, а мегакостыли на костылях… Могу еще из своей жизни привести пример: я регулярно и достаточно давно заношу в evernote разные идеи по языковым фичам, возникающие из реальной практики. Таких записей сотни…


        1. OberonForGood Автор
          14.05.2015 18:04
          #8417907

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

          Без цифр это просто мнения более уважаемых и более практикующих коллег. Мы доверяем их выбору, который они не с потолка придумали, а для решения своих конкретных задач. Глубоко проработали и передали сообществу.
          А что если
          А что если это не проверенные мнения, а просто маркетинговые ходы по превращению модных плюшек в инвестиции и приток целевой аудитории?


          1. NeoCode
            14.05.2015 18:23
            #8417957
            +6

            Boost это некоммерческая разработка. GСС тоже (в gcc можно посмотреть например gcc.gnu.org/onlinedocs/gcc/C-Extensions.html и gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Extensions.html — тоже много интересного). Языки D и Nim тоже некоммерческие. Go — продукт Гугла, но истоки в системе Plan9 и ее языках Alef и Limbo. Rust — продукт Мозиллы, но они для себя разрабатывают, и продукт полностью открытый. Нет, я не склонен увязывать сюда коммерцию, сейчас вообще почти все языки и IDE бесплатные.

            По рефлексии — если компилятору известно чуть больше, это уже языковая фича. Конкретные применения этой фичи (например запись в xml, json, binary) — это действительно должно быть в библиотеках, но если в компиляторе нет ничего для базовой поддержки — то остаются только нагромождения костылей (как это и есть в С++). Одна маленькая фича в компиляторе позволит выкинуть множество неестественных и ненадежных нагромождений в библиотечном и прикладном коде. В этом и смысл языковых фич.

            О балансе — в С++ нарушением баланса (ИМХО конечно) являются не сами шаблоны, а метапрограммирование на них. А сами шаблоны вполне сбалансированы. По изначальному замыслу предполагалось, что шаблоны будут вот для таких конструкций

            template<class T, int N>
struct Array
{
  T data[N];
};

            а не для написания полноценных парсеров времени компиляции (boost.spirit) или compile-time коллекций типов и операций над ними (boost.mpl). Но то, что эти библиотеки появились, и что ими, несмотря на сложности, пользуются — признак того, что соответствующие возможности реально востребованы.


            1. OberonForGood Автор
              14.05.2015 20:18
              #8418111

              Подождите, что подразумевается под «языковая фича»?


              1. NeoCode
                14.05.2015 20:26
                #8418117
                +2

                Как обычно — то что встроено непосредственно в язык и поддерживается компилятором. Например, операторы if/else. Для сравнения, операторы консольного ввода/вывода (всякие printf, println, WriteLine) — это библиотечные возможности, компилятор о них не знает.


                1. OberonForGood Автор
                  14.05.2015 21:29
                  #8418185
                  +2

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


                  1. NeoCode
                    14.05.2015 22:04
                    #8418231
                    +5

                    Я считаю, что компилятор соответствует языку (иначе это уже компилятор другого языка, пусть и очень похожего). То что в жизни компиляторы не всегда соответствуют стандартам языков — это вообще говоря проблема, а не нормальное явление. Сами посудите: вот переходите вы на новый компилятор — а программа не компилируется или не так работает. Оно вам надо?
                    В общем, такого категорически не должно быть. Поэтому лучше, чтобы все фичи были официально задокументированы в стандарте языка, и — что не менее важно — чтобы не было никаких фич, не описанных в стандарте.


                    1. oberon87
                      14.05.2015 22:43
                      #8418267

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


                      1. NeoCode
                        14.05.2015 23:16
                        #8418343
                        +1

                        Потому что нужно писать — и компиляторы, и документацию — как следует, а не как попало. Простота языка — это перекладывание проблем на плечи пользователей, все чего нет в языке им придется допиливать вручную. А сложность языка — это результат того, что во-первых, не все бывает сразу ясно (когда создавался С++ многие вещи были еще неочевидны, в Java и C# их учли), во-вторых — страх сломать «обратную совместимость». Сейчас уже более-менее все очевидно по фичам, ну и делать нужно с нуля, а не издеваться над С++.


                        1. oberon87
                          15.05.2015 00:08
                          #8418387

                          Я вот тут ради проверки своей версии реальности попробовал реализовать фреймворк для одного из диалектов Оберона. Чуть более сложный, но в целом, одно и то же, минимум фич языка. Так вот, это реально сложная задача. По крайней мере, для меня. Реально, для старого, изученного языка, с минимумом сумеречных зон, написать с нуля рантайм, по готовым лекалам это трудно. Конечно, можно сказать, что в крутых конторах типа оракла сидят намного более умные люди, и они уж точно напишут с нуля хорошо. Но как мы видим, получается все равно не очень.

                          Простоты достичь непросто.


                    1. OberonForGood Автор
                      14.05.2015 22:55
                      #8418287
                      +1

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


                      1. NeoCode
                        14.05.2015 23:09
                        #8418313

                        Простота их тоже порождает. Вот brainfuck прост до безобразия, а попробуйте ка на нем написать хоть что-то серьезное без ошибок:)))


                        1. OberonForGood Автор
                          14.05.2015 23:10
                          #8418319
                          -2

                          Это не простота, это примитивность, трясина


                          1. NeoCode
                            14.05.2015 23:18
                            #8418349
                            +3

                            Ответил выше: простота языка — это перекладывание проблем на плечи пользователей, все чего нет в языке им придется допиливать вручную. Все равно придется, только вместо единой реализации в языке будет 100500 кривых реализаций «на местах».


                            1. OberonForGood Автор
                              14.05.2015 23:22
                              #8418355
                              +1

                              Ну так все равно будут ошибки, какая разница? Более того, компонент сменить можно, а язык уже не поменяешь так легко.


                              1. OberonForGood Автор
                                14.05.2015 23:25
                                #8418359
                                +2

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


                                1. VenomBlood
                                  15.05.2015 00:48
                                  #8418433

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


                                  1. MacIn
                                    15.05.2015 00:59
                                    #8418447
                                    +4

                                    Это тоже может найти свое применение. Например, в разных платформах будет один и тот же язык (основные конструкции), но специфичные части будут отличаться. В итоге можно переучить человека, знающего реализацию под одну платформу для другой.

                                    «в каждом проекте свой язык» можно сказать и про тот же C++ — в зависимости от того, какими библиотеками пользуются. Команда, использующая какой-нибудь MFC не быстро найдет общий язык с использующими Qt.


                                    1. VenomBlood
                                      15.05.2015 01:07
                                      #8418461

                                      Это же чистый overengineering. Сейчас синтаксис работает одинакого и предсказуемо в любом проекте на распространенных языках программирования. Когда я пишу foreach я знаю во что это развернется и понимаю как это работает, к этому есть документация. Для каждой фичи есть подробные описания и разборы ошибок и узких мест на всяких stackoverflow.
                                      Добавление стандартизированного синтаксического сахара — это как раз упрощает ПО, а использование чего-то низкоуровневого и тем более с самописным синтаксисом — усложняет. Взять те же async/await и итераторы в C#. Да, фича сложнее чем осознать как работает for или if, но поняв один раз — можно использовать на любом проекте и код получается гораздо более читабельный и простой. И не надо городить каждый раз костыли для эмуляции этих фич.


                                      1. MacIn
                                        15.05.2015 03:40
                                        #8418537
                                        +1

                                        Да нет, это реализуется не так уж сложно.
                                        Я немного не это имею в виду. Допустим, у вас есть ряд проектов, совершенно различных, но разрабатываемых одной командой. И этим проектам нужны внутренние языки. Скриптовые. Сейчас у нас в команде есть 3-4 разных языка, каждый из которых трудится в качестве скриптового в отдельной программе. Да, они похожи. Настолько же, насколько походи Java, PHP, Basic и C — т.е. условно. Человек, который должен работать с этими скриптами, должен знать все 4 языка.
                                        А могло быть иначе: язык один, но модульный, к нему в зависимости от необходимости, могут подключаться нужные модули, реализующие операторы, функции или даже целые конструкции, которые позволяют этому языку работать с конкретной программой, к которой он прикручен.

                                        но поняв один раз — можно использовать на любом проекте и код получается гораздо более читабельный и простой
                                        Вы точно так же можете сказать про, ну, например, boost.asio. Однако в каком-нибудь другом проекте будет использоваться другая библиотека, и знание этой, стандартной по сути, вам не поможет. Т.е. такой язык, с минимумом встроенного, тоже модульный. Не по части синтаксиса.


                                        1. VenomBlood
                                          15.05.2015 04:13
                                          #8418545
                                          -1

                                          Как DSL — вполне возможно, хотя и сейчас хватает средств для создания своих DSL'ек. Но как мейнстрим язык программирования (то, на чем пишется основной код) — такое не надо.


                                  1. OberonForGood Автор
                                    15.05.2015 08:00
                                    #8418619
                                    -1

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


                                    1. VenomBlood
                                      15.05.2015 08:05
                                      #8418623
                                      +1

                                      Плюс хоть 10 фич в год — они везде одинаковые, а тут не «одна фича» а каждый барин будет делать себе свои фичи. Никакой проблемы «монолитности» нету, язык один и все им пользуются одинакого. Если я вижу foreach — я знаю как он работает в любой программе на определенном языке. Если я вижу лямбды — я тоже знаю как они работают. А тут foreach у каждого свой. А такие вещи как async/await вообще половина «баринов» реализует через одно место просто в силу их сложности. И никакого формального описания тут не будет, точнее будет одно маленькое описание и неопределенное число приложений неопределенного качества.

                                      В обероне, вроде, даже, foreach нету, который добавили уже в самые консервативные языки. Хотя может тут не прав.


                                      1. OberonForGood Автор
                                        15.05.2015 08:22
                                        #8418637
                                        -4

                                        Foreach не нужен.

                                        А вообще, вас же не волнует, что библиотеки про IO например могут различаться. Зачем же вы стремитесь так контролировать модульный язык? Он по определению модульный, со всеми плюсами и минусами.

                                        А такие вещи как async/await вообще половина «баринов» реализует через одно место просто в силу их сложности.
                                        Кажется, это называется патернализм, когда надежда на решение крупных проблем возлагается субъектом на Отца-корпорацию, у которой сил уж точно хватит. Не хватает, как мы видим. А если и дальше языки усложнять, то и не хватит никогда.


                                        1. VenomBlood
                                          15.05.2015 08:24
                                          #8418643
                                          +3

                                          Foreach не нужен.
                                          А чем он мешает? Может еще и лямбды не нужны? async/await не нужен? А шаблоны/Generic'и? Так мы до ассемблера скатимся.
                                          Foreach удобен когда есть коллекция с неизвестным числом элементов. Например:
                                          foreach(var file in Directory.EnumerateAllFiles(...)) и вообще итераторы сами по себе очень удобны т.к. обеспечивают ленивые вычисления без всяких заморочек.

                                          IO обычно есть в стандартной библиотеке (по крайней мере для тех языков с которыми я работал во всех случаях для базового IO использовалась стандартная библиотека).


                                          1. OberonForGood Автор
                                            15.05.2015 08:30
                                            #8418649
                                            -1

                                            Мы не скатимся. Скатимся — это вульгаризация рассуждений про лишние сущности. Либо рассуждения, либо вульгаризация.

                                            Аргумент «чем он мешает?» ставит вас в позицию человека, который сначала втыкает в язык фичу, а потом начинает искать оправдания. Как оверпотребление в супермаркетах. Извините.


                                            1. VenomBlood
                                              15.05.2015 08:32
                                              #8418651
                                              +2

                                              Т.е. вреда нету? Польза есть и она очевидна, так почему бы не сделать foreach?
                                              Так вы предлагаете серьезно чтоли убрать Generics/Templates? Или я чего-то не понял?

                                              «Скатимся» — это потому что сейчас я например с использованием всяких «синтаксических сахаров» пишу UI приложение с нормальным UI на асинхронных операциях, с многопоточностью и кучей других плюшек за условно день, а если это убрать то писать я его буду условную неделю — оно мне надо, спрашивается? И работодателю моему не надо, и заказчику тоже не надо.


                                              1. OberonForGood Автор
                                                15.05.2015 08:49
                                                #8418675

                                                Вред очевиден, лишняя сущность, лишнее слово, лишние правила работы особого итератора. Есть понятие цикла с постусловием, с предусловием, безусловного, а тут нам подсовывают какой-то foreach с мутной семантикой. Для foreach достаточно библиотечного уровня. В языке — не нужен.


                                                1. VenomBlood
                                                  15.05.2015 08:51
                                                  #8418679
                                                  +6

                                                  А зачем циклы с предусловием/постусловием? Это лишняя сущность, лишнее слово, лишние правила. Есть понятие goto и есть if, а тут нам подсовывают какие-то циклы с мутной семантикой.


                                                  1. OberonForGood Автор
                                                    15.05.2015 08:55
                                                    #8418687
                                                    +1

                                                    Дейкстра установил переход к таким конструкциям как качественный переход, если по-колхозному, циклы до, после и внутри себя оставляют инварианты, на которые опирается структура программы, а foreach это что? Какая за ним качественная характеристика?


                                                    1. VenomBlood
                                                      15.05.2015 08:58
                                                      #8418697
                                                      +3

                                                      Так а зачем ключевое слово то? Циклы хорошо, делайте их goto и if. А то foreach же тоже цикл по сути, и ему ключевое слово нельзя, а for'у можно.


                                                      1. akastargazer
                                                        15.05.2015 10:25
                                                        #8418831

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


                                                        1. VenomBlood
                                                          15.05.2015 20:35
                                                          #8419989
                                                          +3

                                                          Вообще то знаю.


                                              1. OberonForGood Автор
                                                15.05.2015 08:51
                                                #8418681
                                                +1

                                                Про аргументы бизнеса я упоминал в статье, их вес в рассуждениях еще нужно обосновать. Метод суслика, да-да.


                                                1. VenomBlood
                                                  15.05.2015 08:54
                                                  #8418683
                                                  +2

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


                                                  1. OberonForGood Автор
                                                    15.05.2015 08:56
                                                    #8418691
                                                    -3

                                                    Работа ума уровня простейших, как поменьше потратить энергии и побольше впитать бульона и соседей. Бзнс.


                                                  1. akastargazer
                                                    15.05.2015 10:26
                                                    #8418835
                                                    -1

                                                    А спутники падают.


                                                    1. VenomBlood
                                                      15.05.2015 20:35
                                                      #8419991
                                                      +2

                                                      Спутники падают из за ошибок, а ошибки делают люди и делают они их в любом языке.


                                                      1. akastargazer
                                                        15.05.2015 21:06
                                                        #8420027

                                                        Можно двигаться по пути минимизации ошибок. Человеческий фактор можно ослабить.


                                                        1. VenomBlood
                                                          15.05.2015 22:44
                                                          #8420163

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


                                          1. OberonForGood Автор
                                            15.05.2015 08:44
                                            #8418667

                                            Вообще, аргумент про «скатимся в ассемблер» пригоден, чтобы выставить оппонента недалеким фанатом, который и не заметит, как выкинул из языка вообще все. Зачем такой аргумент нужен в беседе культурных людей не очень понятно.


                                            1. VenomBlood
                                              15.05.2015 08:45
                                              #8418671

                                              Вы на вопрос не ответли. Generic'и нужно выкидывать?


                                              1. StrangerInRed
                                                15.05.2015 08:55
                                                #8418689
                                                -1

                                                Еще регулярки выкенем, форматтеры строки. Таких примеров миллион.


                                                1. VenomBlood
                                                  15.05.2015 09:01
                                                  #8418705

                                                  И классы выкинуть надо, а то что за дела, лишних сущностей повводили, даже goto теперь никто не использует. Не порядок.


                                                  1. akastargazer
                                                    15.05.2015 10:27
                                                    #8418837

                                                    В обероне классов нет, а ООП есть. Чудеса, да и только :)


                                              1. OberonForGood Автор
                                                15.05.2015 08:57
                                                #8418693
                                                -6

                                                Их не нужно было вводить, теперь уже не выкинешь, такие правила игры.


                                                1. VenomBlood
                                                  15.05.2015 09:00
                                                  #8418703
                                                  +3

                                                  Ну так бы сразу и сказали, сразу ответили на все вопросы. Только вот подозреваю что людей пользующих например async/await раз в неделю в C# (уж не говоря о Templates в C++, например) больше чем людей которые вообще слышали про оберон. Почему? Потому что есть языки которые все критикуют и есть языки которыми никто не пользуется.


                                                  1. OberonForGood Автор
                                                    15.05.2015 09:04
                                                    #8418711
                                                    +1

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


                                                    1. VenomBlood
                                                      15.05.2015 09:07
                                                      #8418715
                                                      +2

                                                      Ахаха. Ваш любимый язык не используют не потому что он ни на что не годится, а потому что мировой заговор заставляет людей писать на C++/C#/Java/etc. Наверное где-то есть карательные отряды которые сажают приверженцов оберона в психушку? Как же иначе объяснить что у него нету последователей, ведь не может же это быть потому что концепция не верна, верно?


                                                      1. OberonForGood Автор
                                                        15.05.2015 09:20
                                                        #8418733
                                                        -3

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


                                                      1. akastargazer
                                                        15.05.2015 10:28
                                                        #8418839
                                                        +1

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


                                                1. StrangerInRed
                                                  15.05.2015 09:02
                                                  #8418707

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


                                                  1. OberonForGood Автор
                                                    15.05.2015 09:06
                                                    #8418713
                                                    +1

                                                    Компилить очень быстро, потому что сделано просто и понятно. Так что нет, не выкинем.


                                                    1. StrangerInRed
                                                      15.05.2015 09:09
                                                      #8418721

                                                      По утверждению Вирта[9], разработчики языка Java за несколько лет до её создания «изучили исходные коды Оберона и, в частности, исходные коды обероновских сборщиков мусора. Потом они испортили Оберон синтаксисом Си и назвали получившееся словом Java».


                                                      Просто и понятно оно сделано в vala которой транслируется в С. Или в obj-c который транслируется в С. То что вы не видели background оберона — не значит, что там все просто и понятно.


                                                      1. OberonForGood Автор
                                                        15.05.2015 09:17
                                                        #8418729
                                                        +1

                                                        Боюсь спросить, а Вы его видели?


                                                      1. akastargazer
                                                        15.05.2015 10:30
                                                        #8418849
                                                        +1

                                                        Система Оберон была написана за три года двумя частично занятыми людьми:

                                                        «Мы начали разработку системы в конце 1985 года, а программирование — в начале 1986 года на нашей рабочей станции Lilith и ее языке Модула-2. Сначала был создан кросс-компилятор, а за ним — модули внутреннего ядра вместе с необходимыми средствами тестирования и загрузки. Одновременно шла разработка системы отображения и текстовой системы без возможности их тестирования, конечно.

                                                        Мы поняли, насколько отсутствие отладчика и, более того, компилятора может
                                                        способствовать тщательному программированию. (Это действительно так, в чем
                                                        убедился один из нас, когда примерно в то же самое время и примерно в тех же условиях писал компиляторы языка С. — Прим. перев.)

                                                        Затем последовал перевод компилятора на язык Оберон. Это было сделано
                                                        стремительно, потому что оригинал был написан с намерением последующего
                                                        перевода. После его проверки на целевом компьютере Ceres вместе со средствами
                                                        редактирования текста пуповина Lilith могла быть отрезана. Система Оберон, по
                                                        крайней мере, ее черновая версия, стала реальной. Это случилось примерно в середине 1987 года; после этого было опубликовано ее описание.

                                                        Завершение системы заняло еще год, ушедший на объединение рабочих станций в сеть для передачи файлов, на средства централизованной печати и на инструменты поддержки. Наша цель — завершить систему в три года — была достигнута. В середине 1988 года система была представлена более широкому сообществу пользователей, и можно было начать работу над приложениями. Была разработана почтовая служба, добавлена графическая система и продолжены различные работы по общим системам подготовки документов. Средство отображения было расширено так, чтобы работать с любым экраном, включая цветной.

                                                        Одновременно на основе опыта использования системы совершенствовались отдельные ее части. С 1989 года в наших вводных курсах программирования язык
                                                        Модула-2 был заменен языком Оберон.»

                                                        Никлаус Вирт, Юрг Гуткнехт. «Разработка операционной системы и компилятора. Проект Оберон»


                                                    1. VenomBlood
                                                      15.05.2015 09:10
                                                      #8418723
                                                      -1

                                                      А будет еще быстрее. И запоминать меньше ключевых слов придется!
                                                      Я думаю вообще нужно писать для машины Поста. 6 команд и чиселки, вам должно понравится!


                                                      1. OberonForGood Автор
                                                        15.05.2015 09:22
                                                        #8418735
                                                        -5

                                                        Мы благодарны за ваш отклик. Ваше мнение очень важно для нашего сообщества.


                                                      1. akastargazer
                                                        15.05.2015 10:31
                                                        #8418853
                                                        +1

                                                        В Оксфорде преподают студентам именно Оберон. Видимо, там чего-то не знают, чего знаете вы.


                                                        1. MuLLtiQ
                                                          15.05.2015 10:51
                                                          #8418895

                                                          А первый язык у них Haskell, вообще-то :)


                                                        1. MuLLtiQ
                                                          15.05.2015 11:23
                                                          #8418959

                                                          Оберон там преподают ровно по той же причине, по которой у нас в школах и на первых курсах в большинстве университетов Паскаль и Delphi преподают.
                                                          Эх, а уж сколько ПО было создано на Delphi в свое время, еще на борландовской семерке :)


                                                          1. akastargazer
                                                            15.05.2015 11:35
                                                            #8418987
                                                            +1

                                                            Вы знаете, там в Оксфорде, Оберон преподают вторым языком. А первым у них Хаскель :)


                                                            1. akastargazer
                                                              15.05.2015 11:39
                                                              #8418993
                                                              +1

                                                              P.S. да, сказали уже :)

                                                              Хаскель + Оберон = хорошая база для понимания. Вот почему у нас с Паскаля на Оберон не перейдут, в толк взять не могу.


                                                        1. VenomBlood
                                                          15.05.2015 20:37
                                                          #8419993

                                                          Ну а как это противоречит? Просто примитивненький язык который прост для начальных стадий обучения программированию, в школе/универе — самое то. Это же не значит что он годен для продакшн программирования.


                                                          1. akastargazer
                                                            15.05.2015 21:07
                                                            #8420029
                                                            -3

                                                            Браво. Наконец-то я это услышал.

                                                            Управление беспилотниками, это не продакшн? Система управления ГЭС на Амазонке — не продакшн?

                                                            Ах да. Сайтики, вот настоящий продакшн.


                                                            1. OberonForGood Автор
                                                              15.05.2015 22:05
                                                              #8420107
                                                              -3

                                                              Спутники, спутники еще.


                                                            1. VenomBlood
                                                              15.05.2015 22:46
                                                              #8420171
                                                              +1

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


                                                              1. akastargazer
                                                                15.05.2015 23:46
                                                                #8420233

                                                                Бахвалитесь? По-моему, это не совсем то слово, которое следует использовать в приятной беседе. Я не совсем понимаю, неужели одно упоминание Оберона уже вас оскорбляет? Если так, то вам пора к врачу.

                                                                Назвать Оберон «примитивным» означает показать свой низкий уровень образованности, уж извините. Такие познания в ИТ даже на техникум не тянут, одна радость — foreach знать. И, что особенно важно, писать слово production без акцента.

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


                                                                1. VenomBlood
                                                                  15.05.2015 23:51
                                                                  #8420241

                                                                  Оскорбляет? Нет конечно, меня вообще тяжело оскорбить. Скорее я бы сказал меня это забавляет. А язык конечно примитивный, синтаксис уровня 90-х — начала 2000х, но никак не уровня 2015 года.

                                                                  Борланд заказывала виртуальную джава-машину оберонщикам
                                                                  Это как раз подтверждает мое высказывание про 1.5 человека. Где сейчас борланд? И где сейчас оберон? Посмотрите количество вакансий по оберону, ну или количество конференций где о нем говорят. Теперь сравните с Java/C#/C++. Вероятно вам потребуется точность double чтобы выразить отношение.


                                                                  1. akastargazer
                                                                    16.05.2015 00:12
                                                                    #8420251
                                                                    +2

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


                                                                    1. VenomBlood
                                                                      16.05.2015 00:15
                                                                      #8420253

                                                                      Вы же понимаете что этот аргумент бессмысленный так как неопровержим. Его можно применить к чему угодно и сказать что лучше жить в пещерах и забросить науку но «миллионы мух же не могут ошибаться».
                                                                      Я пока не увидел ни одного аргумента почему оберон лучше чем любой из TOP 5 языков. Писать кода на нем больше надо, ошибку допустить легче, высокоуровневых примитивов нету — так чем он лучше то? Тем что его проще выучить? Так инструкции к машине Поста еще проще выучить, ну или brainfuck — тоже просто понять. Только вот писать на нах не просто.

                                                                      Я вот замечательно вижу как async/await экономит мне полотна кода и уровни вложенности и код получается компактный и простой. Так же вижу как мне аналогичным образом помогают встроенынные в язык итераторы, не говоря уже о Generic'ах, которые экономят тонну времени и предостерегают от кучи потенциальных ошибок. А тут пре предлагают отказаться от всего этого и ничего в замен не предлагают.


                                                                      1. akastargazer
                                                                        16.05.2015 13:29
                                                                        #8420583

                                                                        Он не «лучше», он другой. Стоит с другой стороны. Не там, где вы привыкли.


                                                                        1. VenomBlood
                                                                          16.05.2015 22:39
                                                                          #8420919

                                                                          Для mainstream он хуже, я уже объяснил почему. А что дает взамен? Если взамен он дает только то что он «другой» — то он точно никому не нужен.


                                                                          1. akastargazer
                                                                            17.05.2015 11:17
                                                                            #8421099

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

                                                                            Ведь всё можно легко подсчитать. Как именно экономятся усилия программиста. Я для оберона вёл статистику работы — и получалось, что именно на набор кода, клики и возню мышкой тратится совсем небольшая часть времени. Львиная часть трудозатрат идёт на обдумывания. Когда проблема понятна, кодирование быстрое и продуктивное.

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

                                                                            Теперь, что оберон-методология даёт взамен. Избавление от ошибок на самом старте — это очень и очень дорогая вещь. Сложность надо регистрировать в самом начале, про это ещё Дейкстра говорил. Майнстрим идёт по другому пути — наращивая мускулы на выходе и подпирая костылями результат. Чтоб как-нибудь, но работало. В общем, вы костыли и принимаете за «достижения».


                                                                            1. VenomBlood
                                                                              17.05.2015 11:20
                                                                              #8421101

                                                                              Ведь всё можно легко подсчитать. Как именно экономятся усилия программиста. Я для оберона вёл статистику работы — и получалось, что именно на набор кода, клики и возню мышкой тратится совсем небольшая часть времени. Львиная часть трудозатрат идёт на обдумывания. Когда проблема понятна, кодирование быстрое и продуктивное.
                                                                              Вы когда нибудь сравнивали например асинхронную работу с итераторами через async/await/yield/foreach и без всего этого? Особенно если идет несколько continuation'ов. Растет не просто количество кода, растет его сложность, увеличивается шанс допустить ошибку, растет время на понимание кода (а читают его гораздо чаще чем пишут).
                                                                              Избавление от ошибок на самом старте — это очень и очень дорогая вещь.
                                                                              Так он не избавляет от ошибок, а привносит их, потому что вместо пользования более высокоуровневыми примитивами языка приходится вручную все делать.

                                                                              что именно на набор кода, клики и возню мышкой тратится совсем небольшая часть времени
                                                                              Это даже, я бы сказал, смешной аргумент (у меня улыбку вызвало). Так может все же ассемблер? Все равно на «набор кода» меньше времени тратится, а то что будет тратиться горзадо больше времени на обдумывание того как правильно и красиво сделать все низкоуровневыми примитивами — это ничего, это мы выкинем из рассмотрения, связанные с этим ошибки тоже.

                                                                              Вы уж определитесь, он «лучше» или «другой», а то каментом выше был «другой», еще сейчас уже «лучше».


                                                                              1. akastargazer
                                                                                17.05.2015 11:28
                                                                                #8421107

                                                                                Асинхронная работа, прекрасно. А вы про активные объекты слышали? Если нет, к чему эти загибы?

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

                                                                                Без метрик это всё пустые слова и попытки раздуть из мухи слона.

                                                                                Высокоуровневые примитивы уводят нас от железа и приближают к предметной области, это верно. Про это тоже Дейкстра писал. Следующий шаг на этом пути — наглухо завесить сборку мусора тоннами динамических сущностей, посмотрите, как работает сервер майнкрафта, например. Или, например, регулярные крэши среды, написанной на С++. Всё это в XXI веке, да-да.


                                                                                1. VenomBlood
                                                                                  17.05.2015 11:34
                                                                                  #8421113
                                                                                  +3

                                                                                  Следующий шаг на этом пути — наглухо завесить сборку мусора тоннами динамических сущностей,… Или, например, регулярные крэши среды, написанной на С++.
                                                                                  Это всего лишь неумение использовать инструменты. Сборка мусора очень помогает в 99% случаев, важно просто уметь выделить тот 1% случаев когда надо писать код с оглядкой на то как она работает или писать код в среде без GC. Это управление сложностью. Мы красим стену валиком, и подкрашиваем кисточкой те места, куда валик не достает, это делает нас более продуктивными. Говорить то что «валик не везде может покрасить» поэтому давайте везде красить кисточкой — странно. Да, покрасить кисточкой можно, но зачем? Оставим ее только для тех мест, где более высокоуровневые инструменты не справляются.
                                                                                  Метрики приведите. Статистику работы. Числа. Ведь работа программиста выражается именно в том, сколько дела он сделает за определённое количество нажатий клавиш.
                                                                                  Совершенно нет. Работа в том сколько человек сделает за определенное время (не важно сколько он кнопок нажал), насколько качественно будет система работать, насколько быстро сможет другой человек в ней разобраться, и прочее подобное. foreach не просто сокращает количество строк кода — он уменьшает сложность, с которой нам приходится работать.


                                                                                  1. akastargazer
                                                                                    17.05.2015 11:40
                                                                                    #8421119

                                                                                    Да, расскажите про неумение использовать инструменты создателям Unity3d, например.

                                                                                    Сначала мне говорят про человеческий фактор, мол человек всегда делает ошибки. Теперь оказывается, что человеку подсовывают такие инструменты, с помощью которых можно делать ошибки. И мы приходим к выводу, что «сам дурак», раз не смог!

                                                                                    Детский сад.

                                                                                    >Совершенно нет. Работа в том сколько человек сделает за определенное время (не важно сколько он кнопок нажал)

                                                                                    А он как это делает, силой мысли? :)))))
                                                                                    Если вы одну и ту же задачу сделаете за 10 и за 100 обращений к средствам ввода, то во втором случае потратите больше времени и утомитесь больше. А если вести статистику на многих проектах, то можно оценить, сколько времени уходило на кодирование различных концепций и это можно будет сравнивать для разных ЯП.

                                                                                    Так что пока у вас не будет метрики, то разговаривать об «экономии форыча» не вижу смысла.


                                                                                    1. VenomBlood
                                                                                      17.05.2015 11:43
                                                                                      #8421121

                                                                                      Сначала мне говорят про человеческий фактор, мол человек всегда делает ошибки. Теперь оказывается, что человеку подсовывают такие инструменты, с помощью которых можно делать ошибки.
                                                                                      Как раз создаются инструменты с которыми все сложнее и сложнее выстрелить себе в ногу.
                                                                                      Совершенно нет. Работа в том сколько человек сделает за определенное время (не важно сколько он кнопок нажал)А он как это делает, силой мысли? :)))))
                                                                                      Это шутка или вы не понимаете что количество нажатых кнопок значения не имеет? Оно, к слову, на более высокоуровневом языке будет меньше, так что тут вы тоже проиграли. Значение имеет время, и чем более низкоуровневый язык — тем больше времени тратится на то, чтобы придумать как написать код для той или иной задачи.


                                                                                      1. akastargazer
                                                                                        17.05.2015 11:54
                                                                                        #8421127

                                                                                        Вы путаете простоту с примитивностью. Как раз на хорошо проработанном формальном аппарате времени на придумывание тратится очень мало, это я вам заявляю совершенно ответственно. Вы освобождаете свой мозг от всяких вытребенек и занимаетесь общей архитектурой — которая, как ни странно, языковонезависима. А потом подходите к компу и просто делаете, без ошибок и без последующей отладки.


                                                                                        1. VenomBlood
                                                                                          17.05.2015 11:57
                                                                                          #8421129
                                                                                          +2

                                                                                          По моему как раз вы путаете простоту с примитивностью, выкидывая принятые людьми высокоуровневые примитивы.

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

                                                                                          Еще раз повторю — давайте подождем, пока оберон наберет хоть 10% рынка с таким подходом выкидывания всего полезного что было придумано за последние годы. Как только наберет (с текущей идиологией) — я поменяю свое мнение.


                                                                                          1. akastargazer
                                                                                            17.05.2015 12:02
                                                                                            #8421133

                                                                                            Оберон не выкидывает полезное :) Например, полноценное ООП в язык было введено минимальными усилиями. Я же говорю, вы плохо представляете себе ситуацию и совсем не знаете истории ИТ :)

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

                                                                                            Ну и ваше мнение меня не сильно интересует. Меняете вы его или нет — мне до лампочки.


                                                                                            1. VenomBlood
                                                                                              17.05.2015 12:04
                                                                                              #8421135

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

                                                                                              Я же говорю, вы плохо представляете себе ситуацию и совсем не знаете истории ИТ :)
                                                                                              Как и весь рынок, да? Вы в меньшинстве, если что.
                                                                                              Я понял, рынок не прав, вы правы, весь мир в заговоре и делает сложные ненужные вещи, производители антивирусов пишут вирусы, а производители лекарств делают людей больными. А как же иначе, им же надо деньги зарабатывать одурачивая всех.


                                                                                              1. OberonForGood Автор
                                                                                                18.05.2015 11:36
                                                                                                #8421891
                                                                                                -4

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


                                                                                                1. VenomBlood
                                                                                                  18.05.2015 19:49
                                                                                                  #8423597

                                                                                                  Да нет, я просто указываю на очевидные ошибки и провалы в концепции, язык без развития (концепция которого отвергает развитие фич) — обречен изначально на провал.


                                                                                          1. OberonForGood Автор
                                                                                            18.05.2015 11:33
                                                                                            #8421889
                                                                                            -3

                                                                                            Everything should be made as simple as possible, but no simpler.

                                                                                            А про 10% рынка можно посмотреть на количество минусов к положительным комментариям про Оберон. Рынок не хочет Оберон, и силами многих тел демонстрирует этот факт.


                                                                                            1. VenomBlood
                                                                                              18.05.2015 19:50
                                                                                              #8423599

                                                                                              Вот именно, оберон в этом случае way too much simpler.


                                                                                              1. OberonForGood Автор
                                                                                                19.05.2015 10:23
                                                                                                #8424477
                                                                                                -1

                                                                                                Ваша гипотеза не верифицируема.


                                                                                                1. VenomBlood
                                                                                                  19.05.2015 20:47
                                                                                                  #8425887

                                                                                                  Так же как и ваша, это в любом случае субъективно, до тех пор пока нет критерия «прост но не проще чем надо», а когда такие критерии появятся то и фраза самыл потеряет.
                                                                                                  Но только вот мое утверждение разделяет рынок, и есть объективные факторы типа сложности кода, по которым оберон проигрывает.


                                                                                                  1. OberonForGood Автор
                                                                                                    19.05.2015 22:04
                                                                                                    #8426031
                                                                                                    -1

                                                                                                    Да, Вы всегда правы.


                                                                                    1. marked-one
                                                                                      17.05.2015 12:33
                                                                                      #8421163

                                                                                      Небольшая справка: сам движок Unity3d написан на C++. C#/UnityScript — это скрипты. Они вызываются из C++ кода.


                                                                                      1. VenomBlood
                                                                                        17.05.2015 12:38
                                                                                        #8421165

                                                                                        Тут ниже ответили что C++ тоже, цитирую: «движется в мусорку», так что этим людям без разницы, полагаю. Язык почти за 20 лет не смог отвоевать хоть сколько значительную часть рынка, когда более молодые (но «неправильные», как утверждают тут оберонщики) языки это сделать успели. О чем еще говорить…


                                                                                        1. Duduka
                                                                                          17.05.2015 13:37
                                                                                          #8421197

                                                                                          A говорит нужно о вашей компетентности: все языки рождаются, используются и умирают, вы, приведя список диалектов разных языков, попросили указать их направление, если сами компании стоящие за ними не в курсе, хабр должен включить свой отдел «телепататов и машину времени»? К вашему сведению те языки развиваются компаниями и это единственная причина того что они еще не загнулись, а не список фич. А приведя список диалектов, языков, которые сами имею длинную вереницу неудач… «C» очень долго не мог завоевать рынок ( занятый :) фортраном, коболом и паскалем, аду сделали паскатеподобной из-за того, что на рынке было больше паскальщиков, чем сишников ) «С++98» долго переносился пока не вышел, и потом еще долго в полном обьеме не поддерживался, да и дальше, диалектов было больше стандартов. Если Вы думаете, что до сих пор все еще пользуются всеми теми диалектами, то у меня для вас грустная новость: все языки умирают. Да и с диезами, все туманно — его отдали OSS — очень грозный знак, если МС не будет за ними, то его конец будет быстрее чем обычно. Ява — где новая машина, будет ли девятка, когда?!


                                                                                          1. VenomBlood
                                                                                            17.05.2015 22:47
                                                                                            #8421499
                                                                                            +1

                                                                                            Первый оберон был выпущен почти 30 лет назад, ровестник C++, последний оберон был выпущен почти 20 лет назад, раньше чем C#, ровестник Java. Только вот до сих пор рынок он не завоевал. Так что в вашей фразе «языки рождаются, используются и умирают» я полагаю оберон находится на последней стадии, поиспользоваться он так и не успел, как многие другие он только родился и умер. С++ — как развитие C, а первая версия C появилась 43 года назад, популярность росла и даже сейчас многие проекты (например curiosity, раз вы любите космос) написан на C, и никуда уходить язык не собирается в ближайшее время.
                                                                                            О вашей компетентности говорит желание оживить труп, который был закопан рынком.
                                                                                            Кроме того языки рождаются, используются и умирают, и отдают свое место новым языкам в которых еще больше возможностей, новые концепции и фичи, упрощающие написание кода и экономящие время, дегенерации в сторону отброса всех фич замечено небыло.


                                                                                            1. Duduka
                                                                                              18.05.2015 05:13
                                                                                              #8421633

                                                                                              Я где-то упоминал об желании оживить труп оберона? Нет, я среагировал на целую ветку несусветного бреда. В конце которого Вы заявили, что фичи могут сделать язык популярным, оставалось только уточнить список, и покинутого — воскресить ;))) кста забить язык фичами не самое сложное у оберона есть заброшенная ветка оберон -> c (ОО). Только никто этим пользоваться не будет, пока за спиной проекта не появятся деньги.
                                                                                              Фич ?! Серьезно, а я думал, глупый, что надежность компилятора, проработанность библиотеки, эффективная среда — залог эффективного программирования!!! О, позор на мою лысую голову! (не, вы серьезно считаете, что проблема в фичах, а не в том, что фичами прикрывают непрерывный бета-тест-режим компилятора и ОС?)


                                                                                              1. VenomBlood
                                                                                                18.05.2015 05:16
                                                                                                #8421635
                                                                                                -1

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


                                                                                                1. Duduka
                                                                                                  18.05.2015 05:42
                                                                                                  #8421637

                                                                                                  Большинство фич Диезы/Явы из хаскеля, и эйфиль, теперь прикручивают. Как-то прородителям не сильно помогло их фичастое/университетское прошлое.


                                                                                                  1. VenomBlood
                                                                                                    18.05.2015 06:30
                                                                                                    #8421643

                                                                                                    Вы читаете перед тем как отвечать? Я написал что фичи — это необходимое, до определенной степени, условие, но не достаточное.


                                                                                                    1. Duduka
                                                                                                      18.05.2015 08:37
                                                                                                      #8421673

                                                                                                      Вы снова нарываетесь на вопрос, что же САМОЕ достаточное?


                                                                                                      1. VenomBlood
                                                                                                        18.05.2015 19:45
                                                                                                        #8423585

                                                                                                        А что такое «самое достаточное»? Достаточное оно и есть достаточное, но я не могу привести конкретное «достаточное», мы вроде говорим о необходимом.


                                                                                                        1. Duduka
                                                                                                          19.05.2015 04:17
                                                                                                          #8424189

                                                                                                          Нет, Вы, пока, поминали только разную мишуру, хотя на дворе не-праздник. Список, Сестра!


                                                                                                          1. VenomBlood
                                                                                                            19.05.2015 05:09
                                                                                                            #8424213
                                                                                                            +1

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


                                                                                        1. marked-one
                                                                                          17.05.2015 15:19
                                                                                          #8421247
                                                                                          +1

                                                                                          Это было к фразе

                                                                                          Да, расскажите про неумение использовать инструменты создателям Unity3d, например.
                                                                                          , которая следовала в ответ на Ваш коммент про GC, который следовал в ответ на коммент про регулярные креши решений на C++ в доме, который построил Джек.

                                                                                          По обсуждению как-то ничего и не хочу особо говорить. Господа оберонщики либо знатные тролли, либо сильно заблуждаются.


                                                                                        1. akastargazer
                                                                                          19.05.2015 11:12
                                                                                          #8424617

                                                                                          Оберонщики не утверждают, что другие языки «неправильные». Вам привели сравнительный анализ сложности синтаксиса, на котором видно, что майнстримные языки движутся по пути наращивания возможностей, а виртовская линия движется по пути упрощения, отбрасывания малосущественных возможностей.

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

                                                                                          Второй путь следует идеологии, озвученной Э. Дейкстрой — регистрация и управление сложностью в самом начале.

                                                                                          А вы примитивизируете дискуссию, сводя к бинарности «они дураки, мы умные».

                                                                                          Когда Java строится на заведомо устаревшей технологии P-кода, только потому, что Гослинг ничего кроме неё не знал, то это не значит, что Java завоевала рынок благодаря своей успешности. После P-кода были более совершенные решения, но вы про них не знаете, потому что миллионы денег были вложены в рекламу Java.


                                                                                          1. VenomBlood
                                                                                            19.05.2015 20:50
                                                                                            #8425901
                                                                                            +1

                                                                                            Сложность синтаксиса — это та вещь, которую освоил 1 раз. А вот если синтаксис примитивен — то приходится отсутствие этой «сложности синтаксиса» компенсировать более сложными конструкциями в коде, которые у всех разные, отсюда больше ошибок и больше затрат на разработку и поддержку.


                                                                                            1. ApeCoder
                                                                                              20.05.2015 08:59
                                                                                              #8426351

                                                                                              Например, в smalltalk if — это не специальная синтакическая конструкция, а метод объекта Boolean. Он уже готовый стандартный, но тем не менее не является частью синтаксиса.


                                                                                              1. HandleX
                                                                                                20.05.2015 17:02
                                                                                                #8427109

                                                                                                Условные переходы и циклы в Smalltalk суть очень красивая реализация на базовом уровне замыканий. Т.е. именно замыкания лежат в основе не только прекрасного var := aValue ifTrue: [expression1] ifFalse: [expression2], но и восхитительного 3 timesRepeat: [Sound bell. Time waitForSeconds: 1]. Т.е. во втором примере мы не видим никакого «конструктора цикла», чтобы пропикать 3 раза в динамик, а просто экземпляру SmallInteger=3 посылается сообщение #timesRepeat:, в котором аргументом служит экземпляр BlockClosure=[Sound bell. Time waitForSeconds: 1]. Т.е. реализация замыканий на базовом уровне дала Смолтоку невероятную элегантность и силу. Другим остаётся фапать на новомодные лямбды и проч., а Смолтоку уже больше 30 лет, очень жаль, что он не очень популярен.


                                                                                      1. akastargazer
                                                                                        19.05.2015 11:02
                                                                                        #8424583

                                                                                        Совершенно верно. Unity3d ещё и JS-скрипты поддерживает (хотя для использования делегатов, приходится на С# переключаться, хе-хе), но это в XXI веке не даёт объяснения, почему после загрузки террайна среда не может выйти без крэша. 20 лет назад это было объяснимо, 10 лет назад это считалось позором, ну а сейчас это просто диагноз.


                                                                                        1. marked-one
                                                                                          19.05.2015 13:38
                                                                                          #8424925

                                                                                          Существует ли аналог Unity3d, написанный на Оберон? С удовольствием попробую.


                                                                                          1. akastargazer
                                                                                            19.05.2015 14:02
                                                                                            #8424991

                                                                                            Unity3d развивается вот уже 10 лет, в него вложены миллионы долларов, это серьёзная платформа. Вложите миллионы долларов в аналог Unity3d на Обероне и будет вам другая серьёзная платформа. Кроме шуток. Ядро на Обероне, скриптование на Обероне, расширяемость, быстродействие и надёжность гарантируются.


                                                                                            1. marked-one
                                                                                              19.05.2015 14:24
                                                                                              #8425035

                                                                                              Ну вот, читаем Википедию:

                                                                                              Unity Technologies was founded in 2004 by David Helgason (CEO), Nicholas Francis (CCO), and Joachim Ante (CTO) in Copenhagen, Denmark after their first game, GooBall, failed to gain success. The three recognized the value in engine and tools development and set out to create an engine that any and all could use for an affordable price. Unity Technologies has received funding from the likes of Sequoia Capital, WestSummit Capital, and iGlobe Partners.

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


                                                                                              1. akastargazer
                                                                                                19.05.2015 14:49
                                                                                                #8425107

                                                                                                Где я говорил про нишу? Вы что-то путаете. Вы спрашиваете, почему нет аналога Unity3d на Обероне. Я вам отвечаю — что сейчас планка входа на рынок слишком высока, без серьёзных инвестиций «написать» это невозможно.


                                                                                                1. marked-one
                                                                                                  19.05.2015 15:29
                                                                                                  #8425173
                                                                                                  +1

                                                                                                  Отговорки это все. Аналога Unity3d на Обероне нет ровно потому, что никто не хочет его делать. Почему? Потому что «нужны миллионы». А вот они взяли и сделали Unity3d. И миллионы получили. И сейчас, думаю, уже свои собственные миллионы имеют.

                                                                                                  Так что вот взяли бы и начали писать движок на Обероне. Получили бы минимальный рабочий результат, чтобы можно было показать инвесторам. Нашли бы грамотного продажника в команду, который умеет работать с инвесторами. И так далее. А не ныть тут про «нужно вложить миллионы». Если оно того стоит — миллионы вложат. Это бизнес. Иначе Вам дорога в политику, там деньги по другим принципам распределяют.


                                                                                                  1. OberonForGood Автор
                                                                                                    19.05.2015 15:31
                                                                                                    #8425177
                                                                                                    -2

                                                                                                    А вот они взяли и сделали Unity3d.
                                                                                                    А что они при этом кушали?


                                                                                                    1. marked-one
                                                                                                      19.05.2015 15:52
                                                                                                      #8425211

                                                                                                      Я думаю, у них на тот момент имелись достаточные средства для старта бизнеса. Иначе бы бизнеса и не было. Уж как минимум себе на еду они точно должны были иметь деньги.


                                                                                                    1. akastargazer
                                                                                                      19.05.2015 15:52
                                                                                                      #8425213

                                                                                                      Интересно, что первая версия Unity использовала физический симулятор NovodeX (позже известный как PhysX), а этот самый NovodeX раскручивался с 2000 года в Швейцарии, на базе ETH Zurich: www.inf.ethz.ch/department/spin-offs.html

                                                                                                      Интересно посмотреть, с чего швейцарцы начинали свой спинофф, см. 1993 год :)


                                                                                                      1. marked-one
                                                                                                        19.05.2015 16:27
                                                                                                        #8425329

                                                                                                        Насколько я понял Вашу ссылку, ETH Zurich — это университет, который так или иначе помогал начинать бизнес разным компаниям по спин-офф модели, в том числе Oberon microsystems AG в 93-м и NovodeX AG в 2000-м. Так что Unity к Оберону никакого отношения не имеет.


                                                                                                        1. akastargazer
                                                                                                          19.05.2015 16:50
                                                                                                          #8425393

                                                                                                          Я и не говорил, что Unity имеет отношение к Оберону.


                                                                                                  1. akastargazer
                                                                                                    19.05.2015 15:35
                                                                                                    #8425185

                                                                                                    Сделать «ещё один» Unity? Это глупо, ведь уже есть один такой. Если не нравится юнити — берите UE. И куча других движков. Это же бизнес, в закрытую дверь ломятся только дураки.


                                                                                                    1. marked-one
                                                                                                      19.05.2015 15:49
                                                                                                      #8425209

                                                                                                      UE не на Обероне!


                                                                            1. qw1
                                                                              17.05.2015 14:08
                                                                              #8421215
                                                                              +1

                                                                              Теперь, что оберон-методология даёт взамен. Избавление от ошибок на самом старте — это очень и очень дорогая вещь.

                                                                              Вы смешиваете язык и методологию. Оберон не предназначен для «гибких» проектов, как не предназначены фортран и ПЛ/1. Любое изменение — это 30% бюджета и дополнительные полгода работы («понимаете, мы уже перфокарты пробили, перебивать их — ручной тяжкий труд» — это об отсутствии дженериков, когда при заведении новой структуры данных алгоритмы надо копипастить и под неё). Понятно, что на современном быстро меняющемся рынке бизнес-задач оберонщики плохо выглядят в сравнении с быстрыми парнями, которые «тяп-ляп и в продакшен».

                                                                              С другой стороны, кто мешает вдумчиво, неспешно и без ошибок писать большой проект на c++ или c# (последний, когда не требуется real-time управления, например в каком-нибудь планировании или расчётах погоды). Но тут оберонщики отхватывают рынок, потому что дистанцируются от быстрых говнокодеров, и вешают на себя ярлык: медленно, дорого, вдумчиво и надёжно. Понятно, что и на такое спрос есть, только язык тут ни при чём.


                                                                              1. akastargazer
                                                                                19.05.2015 11:23
                                                                                #8424647

                                                                                Я намеренно написал «оберон-методология», чтобы отделить формальный аппарат от самой методологии.

                                                                                >это об отсутствии дженериков, когда при заведении новой структуры данных алгоритмы надо копипастить и под неё)
                                                                                Ну что вы. Гетерогенные структуры, родовая шина сообщений и другие приёмы позволяют спокойно расширять и модифицировать систему. Опять критика оберона мимо кассы.


                                                                    1. ApeCoder
                                                                      17.05.2015 10:18
                                                                      #8421089
                                                                      +2

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


                                                                      1. akastargazer
                                                                        17.05.2015 11:23
                                                                        #8421103

                                                                        Метафора подвергает критике массовое некритичное сознание, только и всего. «Так делают все — поэтому это правильно» — сказал однажды один очень умный лемминг. Майнстрим делает деньги на сложности (на средствах преодоления сложности), это очевидно для всех, кто пристально наблюдает за развитием ИТ ну хотя бы со времени появления MS-DOS.

                                                                        Создавать и культвирировать сложность, в том числе и для топ-специалистов в ИТ, ведь ощущение собственной незаменимости крайне важно. Отсюда и постоянный поиск средств, «как бы меньше писать кода», ведь изначальная сложность не побеждена.


                                                                        1. qw1
                                                                          17.05.2015 14:26
                                                                          #8421221
                                                                          +1

                                                                          Заказчику фиолетово, что там культивируют IT-шники, но он готов платить в 10 раз больше, если задачу сделают в 5 раз быстрее с тем же уровнем надёжности.

                                                                          Только вся сложность не от языка, а от предметной области. Если в задаче 300 сущностей и 9000 связей, хочешь-не хочешь это всё придётся описать в коде, в данных или в DSL.

                                                                          Странно, что оберонщики, как профессионалы в борьбе со сложностью, не хотят тут сорвать денег. Ощущение, что боятся выходить из своей башни из слоновой кости, где они пилят АЭС для спутников, и запачкать руки о реальный мир, где рулят всякие php и java.


                                                                          1. OberonForGood Автор
                                                                            18.05.2015 11:43
                                                                            #8421905
                                                                            -1

                                                                            Вы же не взяли Оберон для решения задач. Вы вообще его не знаете. Как контрибутор в Оберон вы ноль. И таких овер 99%. О чем тут вообще рассуждать? О том, что несколько человек не решили столько задач, сколько решил полумиллион рыночных джавистов и пхпистов и поэтому они лохисидят в башне? Свои задачи мы решили, раз до сих пор с голоду не умерли.


                                                                            1. qw1
                                                                              18.05.2015 14:38
                                                                              #8422231
                                                                              +2

                                                                              Я не против попробовать. Посоветуйте какой-нибудь мануал по настройке среды и любой туториал по основам создания веб-приложений в обероне.


                                                                              1. OberonForGood Автор
                                                                                19.05.2015 10:24
                                                                                #8424479
                                                                                -1

                                                                                Клиент-сайд или сервер-сайд?


                                                                                1. qw1
                                                                                  19.05.2015 13:09
                                                                                  #8424865

                                                                                  фулл-стек. хочу сравнить с asp.net mvc5


                                                                                  1. OberonForGood Автор
                                                                                    19.05.2015 15:08
                                                                                    #8425145

                                                                                    Серверная часть

                                                                                    oberoncore.ru/blackbox/environment
                                                                                    Сборка БлэкБокс — IDE+рантайм в составе есть компоненты по работе с файлами, сетью, Sql, и прочим.

                                                                                    bitbucket.org/oberoncore/mysql
                                                                                    MySQL драйвер

                                                                                    bitbucket.org/petryxa/o3-waf
                                                                                    Веб-фреймворк с демонстрационным примером внутри.

                                                                                    Клиентская часть:
                                                                                    github.com/vladfolts/oberonjs
                                                                                    компилятор оберона в js

                                                                                    Ну и гугл в помощь.


                                                                                    1. qw1
                                                                                      19.05.2015 22:13
                                                                                      #8426043
                                                                                      +2

                                                                                      Спасибо, посмотрел. Первое, что вспомнилось — TCP/IP и веб-сервер на ZX-Spectrum, на ассемблере Z80, затем Borland Pascal 1.0 под CP/M

                                                                                      Понятно, что фичи не нужны. Но отказаться от инициализации массива списком это слишком…

                                                                                      Скрытый текст
                                                                                      	PROCEDURE Deposit*;
		VAR pat: ARRAY 32 OF INTEGER;
	BEGIN
		pat[0] := 000000000H; pat[1] := 0DCDDDD5DH;
		pat[2] := 0BABBBB3BH; pat[3] := 076777777H;
		pat[4] := 0EEEEEE6EH; pat[5] := 0DCDDDD5DH;
		pat[6] := 0BABBBB3BH; pat[7] := 076777777H;
		pat[8] := 0EEEEEE6EH; pat[9] := 0DCDDDD5DH;
		pat[10] := 0BABBBB3BH; pat[11] := 076777777H;
		pat[12] := 0EEEEEE6EH; pat[13] := 0DCDDDD5DH;
		pat[14] := 0BABBBB3BH; pat[15] := 076777777H;
		pat[16] := 0EEEEEE6EH; pat[17] := 0DCDDDD5DH;
		pat[18] := 0BABBBB3BH; pat[19] := 076777777H;
		pat[20] := 0EEEEEE6EH; pat[21] := 0DCDDDD5DH;
		pat[22] := 0BABBBB3BH; pat[23] := 076777777H;
		pat[24] := 0EEEEEE6EH; pat[25] := 0DCDDDD5DH;
		pat[26] := 0BABBBB3BH; pat[27] := 076777777H;
		pat[28] := 0EEEEEE6EH; pat[29] := 0DCDDDD5DH;
		pat[30] := 0BABBBB3BH; pat[31] := 000000000H;


                                                                                      1. OberonForGood Автор
                                                                                        19.05.2015 22:25
                                                                                        #8426065
                                                                                        -1

                                                                                        Если вам предложат попрограммировать на Обероне, вы скажете «Фи. А где тут бесплатная инфраструктура, которую построила большая западная компания за сто миллионов денег?».


                                                                                        1. qw1
                                                                                          19.05.2015 22:41
                                                                                          #8426083
                                                                                          +2

                                                                                          Ваша последняя цитата похожа на развод на «слабo».
                                                                                          Не, я могу пописать на 6502 с тремя регистрами и 2kb RAM, но результат удивит лишь гиков, остальные не впечатлятся от получившегося продукта. Какой-либо причины браться за оберон, помимо ностальгии, я не нашёл.

                                                                                          Кстати, в дефолтной настройке дефолтная IDE BlackBox даже не делает auto-indent (и неизвестно, умеет ли). Поэтому смелое заявление "операторные скобки сейчас расставляет IDE" (не говоря о раскраске синтаксиса) это из разряда мечтаний.


                                                                                          1. OberonForGood Автор
                                                                                            19.05.2015 23:00
                                                                                            #8426105

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


                                                                                      1. MacIn
                                                                                        19.05.2015 23:17
                                                                                        #8426121
                                                                                        +1

                                                                                        Это напоминает о старом Бейсике, в котором можно было массив задать списком при помощи оператора DATA, а потом одним оператором считать его в массив.


                                                                          1. akastargazer
                                                                            19.05.2015 15:21
                                                                            #8425157
                                                                            -1

                                                                            Если вам предложат попрограммировать на Обероне, вы скажете «Фи. А где тут бесплатная инфраструктура, которую построила большая западная компания за сто миллионов денег?». Хотя нет, не скажете. Оппоненты боятся признать, что сидят на плечах серьёзных рыночных игроков и все рассуждения про «реальный мир» опираются на серьёзные деньги, вложенные кем-то другим, а не на технологическое или концептуальное совершенство.


                                                                            1. qw1
                                                                              20.05.2015 01:55
                                                                              #8426233
                                                                              +1

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


                                                                              1. akastargazer
                                                                                20.05.2015 08:34
                                                                                #8426333

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


                                                                              1. OberonForGood Автор
                                                                                20.05.2015 09:27
                                                                                #8426385

                                                                                Здесь я попрошу доказать, что ЯП и его экосистема аналогичны электроэнергии, а не станкам, Вы смените тему, накинув пару новых претензий, а ваша ложная аналогия так и останется висеть в интернетах, возможно ее даже плюсанут, она ведь такая яркая.

                                                                                Как и ваши слова про «махровый» cgi, хотя там очевидно cgi не основной функциональный элемент, а контейнер сервлетов основной, используемый в разных серверах приложений на той же джаве до сих пор.

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

                                                                                Это делает меня думать, что за Вас тоже думает рынок.


                                                                                1. ApeCoder
                                                                                  20.05.2015 09:41
                                                                                  #8426401
                                                                                  +2

                                                                                  Не было ли каких-то языков разработанных некорпорациями которые несмотря ни на что взлетели, причем выше и быстрее чем оберон?

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

                                                                                  Просто надо выбрать какую-то нишу и обеспечить там лучший набор «батареек».

                                                                                  Так взлетел php — кривой и нелогичный, но подходящий для простого веба.

                                                                                  Так же взлетели python и ruby. Сейчас, похоже, взлетает Rust.

                                                                                  Потом из этой ниши можно атаковать другие.

                                                                                  Для кого Оберон сейчас?


                                                                                  1. akastargazer
                                                                                    20.05.2015 09:49
                                                                                    #8426411
                                                                                    -1

                                                                                    Ну да, люди согласны на кривое, потому что надо «здесь и сейчас». Это нормально. Вот это и есть истинно рыночный подход.
                                                                                    Про последующие затраты на исправление кривизны изначально никто не думает. Ну и малоответственные сайты, здесь кривизна вполне допустима, ведь это не АЭС и не спутники. Залипла страничка у пользователя, какое вам дело? Ведь деньги за сайт вы уже получили.


                                                                                    1. ApeCoder
                                                                                      20.05.2015 10:28
                                                                                      #8426467

                                                                                      > Про последующие затраты на исправление кривизны изначально никто не думает

                                                                                      Думает. Проще сразу начать получать доход, потом исправить кривизну. Вы, кстати, знакомы с концепцией MVP и Lean Startup?

                                                                                      Возможно кривизна будет в каком-то уже другом коде — так как часть этого выкинут за ненадобностью.


                                                                                      1. akastargazer
                                                                                        20.05.2015 10:39
                                                                                        #8426483

                                                                                        Кривизна и адаптация\эволюция разные вещи.

                                                                                        Вопрос в другом. Почему вы не можете быстро написать правильно работающий код? Что мешает? И зачем «исправлять потом», почему нельзя «сразу»?


                                                                                        1. ApeCoder
                                                                                          20.05.2015 10:51
                                                                                          #8426511
                                                                                          +2

                                                                                          > Почему вы не можете быстро написать правильно работающий код?

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

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

                                                                                          Петя и Вася получили заказ на сайтик.

                                                                                          Петя начал писать на Обероне, а Вася взял говый CMS на PHP и изменил там пару строчек.

                                                                                          Васин заказчик уже рубит бабло на сайте, хотя у него периодически случаются ошибки.
                                                                                          Петин ждет решения на Обероне.

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

                                                                                          Петин заказчик ждет решения на Обероне.

                                                                                          Васин зачазчик продолжает рубить бабло.

                                                                                          Петин заказчик получил решение на Обероне и говорит пользователям: «Cмотрите, у меня самый надежный сайтик в мире!»
                                                                                          А пользователи такие: «а нас не парит — у Васи сайтик нас устраивает, хоить и показывает Error 500 раз в неделю, а про твой мы не знаем, да и нам влом еще где-то регистрироваться»


                                                                                          1. akastargazer
                                                                                            20.05.2015 11:11
                                                                                            #8426537
                                                                                            -1

                                                                                            То есть, вы подтверждаете, что в XXI веке программист не способен быстро писать правильный код. Даже удобный форыч с мощной бесплатной инфраструктурой ценой в стомиллионыденег не спасает. Консерватория гнилая, так и запишем.


                                                                                            1. ApeCoder
                                                                                              20.05.2015 11:15
                                                                                              #8426543
                                                                                              +1

                                                                                              Поправлю, не такой правильный код он напишет быстрее в любой консерватории.


                                                                                              1. akastargazer
                                                                                                20.05.2015 11:19
                                                                                                #8426551
                                                                                                -1

                                                                                                >Петя начал писать на Обероне, а Вася взял говый CMS на PHP и изменил там пару строчек.
                                                                                                Почему Петя не взял готовый CMS? Полагаю, у Пети заказ от банковской системы и ему выставили совершенно другие требования.


                                                                                                1. ApeCoder
                                                                                                  20.05.2015 11:23
                                                                                                  #8426555
                                                                                                  +2

                                                                                                  То есть решение использовать Оберон в условиях Васи было бы глупостью? Для его условий Оберон не подходит?


                                                                                                  1. akastargazer
                                                                                                    20.05.2015 11:36
                                                                                                    #8426579

                                                                                                    В условиях Васи подходит PHP, он его и взял, почему это глупость?

                                                                                                    Вы априори полагаете, что для Оберона нет CMS, поэтому в вашей задаче у Васи преимущество. Но мы же в ИТ, где повторное использование есть краеугольный камень индустрии. Стоит Пете один раз написать толковую CMS на Обероне, как преимущество Васи сильно просядет. А как только Петя сумеет создать комьюнити, то Вася начнёт беспокоиться.


                                                                                                    1. ApeCoder
                                                                                                      20.05.2015 11:49
                                                                                                      #8426597
                                                                                                      +1

                                                                                                      > В условиях Васи подходит PHP, он его и взял, почему это глупость?

                                                                                                      Не просядет — Пете надо поддерживать CMS писать для нее модули и т.д. За это время у Васи будет выбор из кучи других CMS и возможность быстро и дешево нанять Вань без обучения Оберону.

                                                                                                      Пока Петя не докажет, что его Оберон заруливает php по скорости разработки он будет выбирать php для Васиных задач.


                                                                                                      1. akastargazer
                                                                                                        20.05.2015 12:14
                                                                                                        #8426639
                                                                                                        -1

                                                                                                        Надеюсь, вы понимаете, что спор ни о чём. Ведь сравнивать разные заделы попросту нелогично. Сравнивать скорость и качество тоже нельзя. А тем более расстояние до предметной области. PHP ближе к вебстраничкам, поэтому его легко использовать. Сравнивать PHP и Оберон нельзя, потому что PHP написан на Си, и правильнее будет сравнить с ним PHP, написанный на Обероне.


                                                                                                        1. ApeCoder
                                                                                                          20.05.2015 12:26
                                                                                                          #8426669
                                                                                                          +1

                                                                                                          Сравнивать можно, мы сравнили и пришли к одному и тому же выводу: в конкретном случае трудоемкость решения задачи на Обероне такова, что лучше взять готовое, хотя и менее надежное. Существуют задачи для которых надежность менее существенна чем скорость разработки (примем пока на веру тезис, что Оберон уделывает все остальное по нажежности).

                                                                                                          Вероятнее всего, таких задач большинство.


                                                                                                          1. akastargazer
                                                                                                            20.05.2015 12:37
                                                                                                            #8426687
                                                                                                            -1

                                                                                                            Вы сравниваете тёплое с мягким. Возможно, вы не знаете, что PHP написан на Си.


                                                                                                            1. ApeCoder
                                                                                                              20.05.2015 12:43
                                                                                                              #8426707

                                                                                                              Что из этого следует?


                                                                                                              1. akastargazer
                                                                                                                20.05.2015 12:50
                                                                                                                #8426723
                                                                                                                -1

                                                                                                                Покажите кучу CMS-ок, написанных на Си.


                                                                                                                1. ApeCoder
                                                                                                                  20.05.2015 12:54
                                                                                                                  #8426735
                                                                                                                  +3

                                                                                                                  Почему я должен ее показать? Для написания CMS я не буду использовать C. Мой поинт именно в этом.


                                                                                                                  1. akastargazer
                                                                                                                    20.05.2015 13:18
                                                                                                                    #8426771

                                                                                                                    Вы говорите, что концептуально совершенный язык людям не нужен, а нужно решать проблемы предметной области. Это так.
                                                                                                                    Интерпретатор PHP можно написать и на Обероне. Но зачем писать CMS на Обероне, мне непонятно.


                                                                                                                    1. akastargazer
                                                                                                                      20.05.2015 13:31
                                                                                                                      #8426791

                                                                                                                      Да, кстати. Вам привели ссылку на веб-фреймворк компании, созданной в 1998 году. В то время PHP только набирал обороты и, в общем-то, можно было сравнивать. Так вот, эти люди быстренько соорудили себе на обероне небольшой спокойный бизнес на обслуживании серьёзных компаний. Как раз, где требовалась надёжность. Почему компания Siemens AG не выбрала PHP, я не знаю.

                                                                                                                      Сейчас-то да, много воды утекло. Интерес в другом, как оберонщикам это удавалось.

                                                                                                                      P.S. Почему-то встраивание ссылки работает здесь через пень-колоду, отнимая моё время. Вот ссылка: www.o3-software.de/en/Company.xhtml


                                                                                                                      1. ApeCoder
                                                                                                                        20.05.2015 13:40
                                                                                                                        #8426807

                                                                                                                        Сайт хреновый — по нему совершенно не понятно, для кого они это сделали и в чем достоинства именно их FW. Нет примеров кода. Сравните, например, websharper.com


                                                                                                                    1. ApeCoder
                                                                                                                      20.05.2015 13:35
                                                                                                                      #8426797
                                                                                                                      +2

                                                                                                                      Если написать интерпретатор php на обероне и написать CMS на php то результат будет менее надежный, чем если написать CMS на обероне так как мы принимаем допущение, что программы Обероне более надежные чем на PHP


                                                                                  1. akastargazer
                                                                                    20.05.2015 10:02
                                                                                    #8426423
                                                                                    -2

                                                                                    Почему вы не вспомнили, как выстрелил Turbo Pascal? Именно виртовская простота дала фирме Borland конкурентное преимущество. Потом на поляну доползли монстры индустрии и завалили её своими продуктами (кстати, если внимательно посмотреть на историю ИТ, то станет заметно, как швейцарские разработки стреляют далеко вперёд, а индустрия медленным шагом дотягивается до них спустя годы и годы).

                                                                                    Оберон сейчас, например, в российских беспилотниках используется.


                                                                                    1. ApeCoder
                                                                                      20.05.2015 10:32
                                                                                      #8426477
                                                                                      +4

                                                                                      Я не уверен что Turbo Pascal выстрелил именно из-за паскаля, а не из за турбо среды. Turbo C и Turbo Assembler тоже выстрелили. Это раз.

                                                                                      Во-вторых, простота бывает разная. Бывает концептуальная простота, бывает простота использования. Например brainfuck и forth концептуально очень простые, а пользоваться сложно.

                                                                                      foreach пользоваться просто.

                                                                                      Если вы так интересуетесь надежностью, не могли бы вы сравнить подход Оберона с тем, что используется в Эйфеле, например. Как у оберона с Design By Contract?


                                                                                      1. akastargazer
                                                                                        20.05.2015 11:05
                                                                                        #8426527

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

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

                                                                                        foreach прост, конечно. Вот я в Unity вытаскиваю список материалов и прохожу по нему форычем, чтоб отыскать нужный. Просто? Да. Удобно? Да. Но есть ещё более простой способ — послать сообщение. Тогда форыч не понадобится. Но идеология инструментария такова, что в ней посылать сообщения накладно. Дешевле использовать форыч. И вы используете и используете списки объектов с форычем для доступа к сущностям. Вывод на первый взгляд парадоксален — если вам часто приходится использовать форыч, то у вас что-то не то с архитектурой.

                                                                                        Насчёт контрактов, почитайте документацию к любому модулю из комплекта BlackBox Component Builder. Позволю себе процитировать:

                                                                                        PROCEDURE (v: View) HandleViewMsg- (f: Frame; VAR msg: Message)
                                                                                        NEW, EMPTY
                                                                                        Message handler for view messages.
                                                                                        HandleViewMsg is called locally.
                                                                                        HandleViewMsg is implemented in views which support marks (e.g., selection marks), and in views which support different frame contents for the same view (a rare case).

                                                                                        Pre
                                                                                        f # NIL guaranteed
                                                                                        f.view = v guaranteed
                                                                                        v.context # NIL guaranteed
                                                                                        msg.view = v OR msg.view = NIL guaranteed

                                                                                        Вот этот вот раздел Pre описывает предусловия обработчика HandleViewMsg. Есть ещё и постусловия. Вся среда построена на этом. Контрактное программирование, на практике это реализуется банальными ассертами на входе в процедуру и на выходе. И это реально работает, как только вы продерётесь через все ассерты, то можно считать, что система будет функционировать без неожиданностей.

                                                                                        en.wikipedia.org/wiki/Design_by_contract всё это работает в Обероне.
                                                                                        Контракты модулей описываются формально, среда их верифицирует, поддержка инвариантов en.wikipedia.org/wiki/Invariant_(computer_science) в наличии.


                                                                                        1. ApeCoder
                                                                                          20.05.2015 11:13
                                                                                          #8426539

                                                                                          > foreach прост, конечно. Вот я в Unity вытаскиваю список материалов и прохожу по нему форычем, чтоб отыскать нужный. Просто? Да. Удобно? Да. Но есть ещё более простой способ — послать сообщение.

                                                                                          Это как? А если у вас другая задача, например, просто сконвертировать весь список в html?


                                                                                          1. akastargazer
                                                                                            20.05.2015 11:29
                                                                                            #8426565

                                                                                            Я сделаю WHILE с охраной условий и сконвертирую. foreach — читается «для каждого», а мне может понадобиться не для каждого. форыч не нужен.


                                                                                            1. ApeCoder
                                                                                              20.05.2015 11:45
                                                                                              #8426589

                                                                                              Если не для каждого, то либо Where либо для каждого — но условие внутри.
                                                                                              В-общем, альтернативно — тупой копипаст кода.


                                                                                              1. akastargazer
                                                                                                20.05.2015 11:53
                                                                                                #8426603

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

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

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

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

                                                                                                Вот так работает концептуальная простота. А форыч — костыль для решения проблем примитивной структуры. Вот чем отличается простота от примитивности.


                                                                                                1. ApeCoder
                                                                                                  20.05.2015 12:01
                                                                                                  #8426621

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

                                                                                                  Что вы понимаете под списком и почему они не понадобятся?

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

                                                                                                  Например, надо написать код который генерирует html для коллекции сотрудников. Я не очень представляю как это решать так чтобы не было лишнего кода (который будет повторяться в нескольких местах), foreach или метода/функции, получающий метод/функцию как аргумент.

                                                                                                  Вот foreach в smalltalk


                                                                                                  1. akastargazer
                                                                                                    20.05.2015 12:25
                                                                                                    #8426659

                                                                                                    Bus.SendMessage, или View.HandleMessage.

                                                                                                    Вы мыслите в рамках «элементов», поэтому вам нужно приспособление, чтобы дотянуться до каждого элемента. Это и есть проблема в архитектуре, порождающая ненужную сложность, преодолеваемую форычем.

                                                                                                    Не надо думать про «элементы». Посылайте сообщение в среду, пусть объекты сами добавляются в структуру HTML. Ах, ваши объекты этого не умеют? Добавьте им такое поведение, что сложного? Ах, вам только один раз? Тогда достаточно WHILE, форыч опять не нужен.


                                                                                                    1. ApeCoder
                                                                                                      20.05.2015 12:31
                                                                                                      #8426675

                                                                                                      Это как «сами» вы про разделения UI и Business logic слышали?

                                                                                                      Внутри View.Handle message как будет происходить обход коллекции?


                                                                                                      1. akastargazer
                                                                                                        20.05.2015 12:42
                                                                                                        #8426705

                                                                                                        Среда BlackBox Component Builder выпущена в 1994 году, и являет собой образец отделения интерфейса от прикладной логики. Так что я немного в курсе. А вот вы зачем-то напрямую обрабатываете список сотрудников.

                                                                                                        >Внутри View.Handle message как будет происходить обход коллекции?
                                                                                                        Зависит от целей и от реализации. Объект может передать сообщение дальше, вызвав HandleMessage у вложенного, а может и банальным WHILE. В любом случае, это не та ситуация, когда форыч используют по триста раз на дню, так что вопрос не в тему.


                                                                                                        1. ApeCoder
                                                                                                          20.05.2015 12:51
                                                                                                          #8426729
                                                                                                          +1

                                                                                                          Итого for each не выкидывается в просто перепрятывается из одного места в другое. И приходится дулировать логику foreach внутри while.

                                                                                                          Можно улучшать только то, что используется триста раз на дню? Вон в питоне решили по другому, вместо foreach выкинули for. Нужен for — делай foreach по range.

                                                                                                          Кстати, вот это дублирование отключаемое:

                                                                                                          PROCEDURE Draw* (f : Figure);
BEGIN
   f.if.draw(f);
END Draw; // <- Нахрена в такой маленькой функции еще раз писать ее имя?



                                                                                                          1. akastargazer
                                                                                                            20.05.2015 13:08
                                                                                                            #8426759

                                                                                                            foreach это тот же цикл for, только без счётчика. Как только чуть усложняется задача, то foreach превращается в цикл while. Чем изучать особенности foreach, достаточно автоматически применять while.

                                                                                                            Сколько раз в день вы применяете foreach? Боюсь, экономия по сравнению с while получается слабенькая, а если с усложнением, то и вовсе никакой.

                                                                                                            Кроме этого, foreach это, по сути, способ коммуникации с пачкой объектов. С помощью форыча вы вручную строите обмен сообщениями.

                                                                                                            Насчёт имени Draw, скажу по опыту — так нагляднее. На маленькой процедуре, конечно, неощутимо, но когда работаешь над реальным проектом, то чувствуешь.


                                                                                                            1. ApeCoder
                                                                                                              20.05.2015 13:31
                                                                                                              #8426793

                                                                                                              > foreach это тот же цикл for, только без счётчика. Как только чуть усложняется задача, то foreach превращается в цикл while. Чем изучать особенности foreach, достаточно автоматически применять while.

                                                                                                              Или в дополняется комбинаци с where

                                                                                                              > Сколько раз в день вы применяете foreach?

                                                                                                              Я работаю с несколькими языками, в одном я его использую гораздо чаще чем whil в другом нет for each зато есть конструкция эквивалентная where + for each для базы данных.

                                                                                                              > Боюсь, экономия по сравнению с while получается слабенькая, а если с усложнением, то и вовсе никакой.

                                                                                                              Это экономит мозг, потому, что сводится к частному случаю while подпадающему под определеннвй паттерн.

                                                                                                              > Кроме этого, foreach это, по сути, способ коммуникации с пачкой объектов. С помощью форыча вы вручную строите обмен сообщениями.

                                                                                                              Это сообщение для объекта-коллекции.

                                                                                                              > Насчёт имени Draw, скажу по опыту — так нагляднее. На маленькой процедуре, конечно, неощутимо, но когда работаешь над реальным проектом, то чувствуешь.

                                                                                                              Скажу по опыту, что писать только маленькие процедуры можно. И с foreach так делаеть проще


                                                                                                              1. akastargazer
                                                                                                                20.05.2015 13:44
                                                                                                                #8426817

                                                                                                                Ну так сколько раз в день вы используете foreach?


                                                                                                                1. ApeCoder
                                                                                                                  20.05.2015 13:56
                                                                                                                  #8426841

                                                                                                                  Пишу от 0 до нескольких раз.

                                                                                                                  Читаю почаще.

                                                                                                                  Читаю код с while и сожалею, что нет foreach в этом языке — еще чаще.


                                                                                                                  1. akastargazer
                                                                                                                    20.05.2015 14:03
                                                                                                                    #8426863

                                                                                                                    Я так и думал. Спор о преимуществах foreach свёлся к объективной неочевидности и неощутимости этих самых преимуществ.

                                                                                                                    Субъективно на уровне вкусовщины можно говорить всё, что угодно. Со своей колокольни могу сказать, что читаю и пишу код как с while, так и с foreach и сожалею, что приходится иметь в виду ещё и foreach. Лишняя нагрузка на мозг.


                                                                                                                    1. ApeCoder
                                                                                                                      20.05.2015 14:08
                                                                                                                      #8426867

                                                                                                                      Как его иметь ввиду? Это просто частный случай while. В случае while который совпадает с этим частным случаем нам надо его внимательно прочитать и убедиться что он подходит под паттерн, а в случае foreach этот паттерн явно назван.


                                                                                                                      1. akastargazer
                                                                                                                        20.05.2015 14:50
                                                                                                                        #8426925

                                                                                                                        Именно так и иметь в виду.

                                                                                                                        Для while всё единообразно. Один шаблон на всё. Мозгу так легче работать. Особенно это хорошо ощущается в конце рабочего дня или поздно вечером, когда наступает непроходимый тупняк. Лишние шаблоны только запутывают.

                                                                                                                        Если у меня строго один while, я всегда смотрю только на охрану цикла. Если же нет, то приходится держать в голове ещё и особый синтаксис foreach — со этими кошмарными break и continue.


                                                                                                                        1. ApeCoder
                                                                                                                          20.05.2015 15:14
                                                                                                                          #8426955

                                                                                                                          что такое «охрана цикла»? Что за язык, в котором у foreach есть break и continue, а у while нет?

                                                                                                                          Напишите как вы видите аналог этого кода:

                                                                                                                          C#

                                                                                                                          foreach (var client in Clients.Where(x =>  x.Balance > 100))
{
    Console.WriteLine(string.Format("Client: {0} Balance: {1} ", client.FullName, client.Balance);
}


                                                                                                                          Powershell

                                                                                                                          clients | where Balance -gt 100 | foreach { "Client: $($_.FullName) Balance:$($_.Balance)" }


                                                                                                                          F#
                                                                                                                          clients |> seq.filter (fun x ->  x.Balance > 100) |> Seq.iter (fun x -> sprintf "%A %A" x.FullName x.Balance}


                                                                                                                          1. akastargazer
                                                                                                                            20.05.2015 15:27
                                                                                                                            #8426969
                                                                                                                            -3

                                                                                                                            Что за язык, где цикл можно прервать с break и continue? Закапывайте.


                                                                                                                    1. qw1
                                                                                                                      20.05.2015 19:14
                                                                                                                      #8427273
                                                                                                                      +1

                                                                                                                      Спор о преимуществах foreach свёлся к объективной неочевидности и неощутимости этих самых преимуществ.


                                                                                                                      Преимущество foreach перед while огромно.
                                                                                                                      У while очень легко неправильно сдвинуть итератор (например, сделать j++ вместо i++) и впасть в бесконечный цикл. Поэтому конструкции while нужно читать очень внимательно при ревью кода. Для foreach есть уверенность, что с итераторами программист не накосячил.


                                                                                                          1. Alexeyslav
                                                                                                            20.05.2015 13:35
                                                                                                            #8426795

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


                                                                                                            1. ApeCoder
                                                                                                              20.05.2015 13:43
                                                                                                              #8426811

                                                                                                              Моя точка зрения, заключается в том, что если возникла необходимость в такой фиче, значит пора рефакторить


                                                                                                            1. akastargazer
                                                                                                              20.05.2015 13:57
                                                                                                              #8426845
                                                                                                              +1

                                                                                                              Ну это считается за ограничение области видимости передаваемых переменных. Да и визуально, нагляднее получается — вот он END Draw; торчит, его глазами хорошо видно.
                                                                                                              В сишарпе, например, приходится тратить дополнительные усилия, чтоб отыскивать конец метода среди этих плохо различимых фигурных скобочек.


                                                                                                              1. ApeCoder
                                                                                                                20.05.2015 19:53
                                                                                                                #8427313
                                                                                                                +1

                                                                                                                Если с отступами все нормально и метод умещается на экран, то никакой проблемы нет. В питоне и F# вот вообще никаких фигурных скобочек


                                                                                                              1. qw1
                                                                                                                20.05.2015 20:14
                                                                                                                #8427335

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

                                                                                                                Да уж, прямо так сложно навести мышь на закрывающую скобку, чтобы IDE вывела шапку, к чему эта скобка относится…


                                                                                                                1. ApeCoder
                                                                                                                  20.05.2015 20:29
                                                                                                                  #8427353
                                                                                                                  +3

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


                                                                                                  1. HandleX
                                                                                                    20.05.2015 17:45
                                                                                                    #8427185

                                                                                                    Все ветвления, циклы и обходы коллекций в Смолток реализованы замыканиями, которые дали не только #do:, но прекрасные #ifTrue:ifFalse:, #timesRepeat:, #whileTrue:, #select:, #collect;, #select:thenCollect: и иже с ними. Невероятная сила и красота замыканий в Смолтоке.


                                                                              1. akastargazer
                                                                                20.05.2015 09:44
                                                                                #8426403

                                                                                Компания Sun вложила стомиллионовденег в устаревший P-код, просто потому что Гослинг не знал другой технологии. Но вам про это не сказала, и многие думают, что байт-код представляет из себя технологическое совершенство. И продолжила вкладывать в развитие костылей, потому что без инвестиций эти станки тупо бы загнулись.

                                                                                В Оберон не стали вкладывать по простой причине — на конкурентном поле лучше иметь свою историю, а не виртовскую. Вот и весь секрет «неуспешности» Оберона. Подсмотреть идеи — всегда пожалуйста, но говорить о преемственности — никогда.


                                                                        1. ApeCoder
                                                                          17.05.2015 23:39
                                                                          #8421533
                                                                          -1

                                                                          Несмотря на это, мейнстрим, как он есть, лучше приспособлен для решения массовых задач. Например, слепить мелкий сайтик из подпиленного распрострененного CMS и найти под него дешевый хостинг проще на php.

                                                                          У мух мушиные задачи. Если их кормить шашлыком, например, они долго не протянут.


                                                                  1. oberon87
                                                                    16.05.2015 12:16
                                                                    #8420523

                                                                    На последнем JPoint упоминали Оберон. У кого разум открыт, те помнят. За остальных думает кто-то другой, хэдхантер там, или модный блоггер.


                                                                    1. VenomBlood
                                                                      16.05.2015 22:40
                                                                      #8420921

                                                                      За остальных думает рынок, да. А с «открытым разумом» и пустым кошельком далеко не уедешь.


                                                                      1. OberonForGood Автор
                                                                        16.05.2015 23:51
                                                                        #8420971

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


                                                                        1. VenomBlood
                                                                          17.05.2015 10:41
                                                                          #8421095

                                                                          И на портяжении многих лет негодяй рынок так и не хочет принять такое божественное творение как «оберон». Вот неудача. Не хочет рынок отказываться от дженериков и foreach'ей, не хочет выкидывать все хорошее, как жаль. Ну чтож, остается только смириться, улыбнуться оберону и продолжать кодить на языках с foreach'ами.


                                                                          1. akastargazer
                                                                            17.05.2015 11:34
                                                                            #8421111

                                                                            Рынок не «не принял» Оберон, история ИТ в этом плане очень интересна. Рынок взял из него всё самое ценное, и продолжает черпать до сих пор.


                                                                            1. VenomBlood
                                                                              17.05.2015 11:36
                                                                              #8421117

                                                                              Ну вы уж определитесь. То «рынок думает за них» — идет в разрез с вашей идеологией потому что ее критикуют, то рынок не «не принял» оберон. Сложно говорить о чем то когда вы каждые 5 минут меняете точку зрения.
                                                                              Сам оберон как язык — отвергнут рынком как неконкурентноспособный. А идеи хорошие есть во всем, почему бы их не взять?


                                                                              1. akastargazer
                                                                                17.05.2015 11:45
                                                                                #8421123

                                                                                Вы просто читайте внимательнее, что вам пишут и не домысливайте за людей. Почитайте историю ИТ, чисто для общего развития — узнаете, как выстрелил Паскаль у Борланд. Рынку нужна сложность, ведь на преодолении сложности можно сделать больше денег. А как только наступает понимание, что одними костылями не обойдёшься, то возникают такие вещи, как Go language inspired by Oberon.


                                                                                1. VenomBlood
                                                                                  17.05.2015 11:48
                                                                                  #8421125

                                                                                  Ок, если вы так правы — вернемся к разговору когда оберон наконец отхватит ну хотябы 10% рынка. Это было бы показателем успеха. Правда у меня ощущение что это не случится никогда, разве что в оберон наконец добавят высокоуровневые примитивы, тогда у него будут шансы.


                                                                                  1. Duduka
                                                                                    17.05.2015 12:21
                                                                                    #8421151

                                                                                    Правда?! Можно список необходимых примитивов, таки добавлю до оберону.


                                                                                    1. VenomBlood
                                                                                      17.05.2015 12:23
                                                                                      #8421153
                                                                                      +1

                                                                                      См. в сторону движения C++17, Java 9, C# 6.0.


                                                                                      1. Duduka
                                                                                        17.05.2015 12:30
                                                                                        #8421157
                                                                                        -2

                                                                                        они — как и все остальные языки движутся в мусорку. очень ценный список :(


                                                                                        1. VenomBlood
                                                                                          17.05.2015 12:32
                                                                                          #8421161
                                                                                          +1

                                                                                          Ок, вам виднее.


                                                                                      1. OberonForGood Автор
                                                                                        18.05.2015 11:25
                                                                                        #8421869
                                                                                        +1

                                                                                        Насмешили. В Java9 только-только появятся модули, которые в Обероне уже 20 лет. Вы кажется, вообще в теме не разбираетесь.


                                                                                        1. VenomBlood
                                                                                          18.05.2015 19:46
                                                                                          #8423589
                                                                                          +1

                                                                                          Зато в этих языках есть тонны других фичей которых нету в обероне. А вы тут одну привели и считаете что это что-то опровергает? Смешно.


                                                                                          1. OberonForGood Автор
                                                                                            19.05.2015 10:27
                                                                                            #8424497
                                                                                            -2

                                                                                            Ах да, форыч.
                                                                                            Ну Ваше мнение понятно, вы противник оберон-подхода и сторонник мейнстрим-подхода. Эта позиция обдуманная, взвешенная, и совершенно не зависит от конъюнктуры рынка. И разум открытый у Вас. ;)


                                                                                            1. VenomBlood
                                                                                              19.05.2015 20:53
                                                                                              #8425905

                                                                                              Итераторы, дженерики, async/await, замыкания, атрибуты — это только малый пример того что реально сильно экономит время и сложность. foreach — это достаточно простой синтаксический сахар, хотя и очень удобный.
                                                                                              Конечно у тех, кто стремится переложить ненужные заботы на железо — разум закрытый, у полутора оберонщиков разум открыт, но, как жаль, весь остальной мир их не принимает. Корпорации не хотят зарабатывать деньги, а люди не хотят быть более продуктивны, все от закрытого разума.


                                                                                    1. intet
                                                                                      17.05.2015 23:10
                                                                                      #8421515

                                                                                      Чем вас например не устраивает generics в составе языка? По мимо всего прочего они выполняют очень важную функцию — не дают запихивать в таблицы, словари, самописные классы объекты не подходящего класса. А нормальная среда разработки укажет на ошибку еще в процессе написания кода. В ином случае разработчику придется тратить время в поисках ошибки во время отладки, а это гораздо дороже по времени.


                                                                                      1. OberonForGood Автор
                                                                                        18.05.2015 11:28
                                                                                        #8421879
                                                                                        +1

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


                                                                                        1. intet
                                                                                          18.05.2015 12:22
                                                                                          #8421985

                                                                                          Дженерики обеспечивают дополнительную проверку кода. Чем больше проверок будет выполнять ide/компилятор, а не программист тем выше производительность программиста.


                                                                                  1. OberonForGood Автор
                                                                                    18.05.2015 11:44
                                                                                    #8421911

                                                                                    Когда лично Вы начнете писать на Обероне в продакшн, тогда и отхватит.


                                                                                    1. VenomBlood
                                                                                      18.05.2015 19:51
                                                                                      #8423603

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


                                                                                      1. OberonForGood Автор
                                                                                        19.05.2015 10:28
                                                                                        #8424499
                                                                                        -2

                                                                                        Ну в общем ясно, вы рассуждаете о том, о чем ничего не знаете.
                                                                                        Пишите лучше на диезе habrahabr.ru/post/258249


                                                                                        1. VenomBlood
                                                                                          19.05.2015 20:55
                                                                                          #8425913
                                                                                          +1

                                                                                          Очень хороший аргумент. Когда язык то до современного уровня дотянете? Когда дотянете — может и начну писать.


                                                                                          1. OberonForGood Автор
                                                                                            19.05.2015 22:05
                                                                                            #8426033
                                                                                            -2

                                                                                            Вы всегда правы.


                                                                                      1. akastargazer
                                                                                        19.05.2015 10:55
                                                                                        #8424569

                                                                                        Рынок завоёвывают не техническим совершенством, а сотнями миллионами долларов, вложенных в рекламу. Запомните это.


                                                                                        1. VenomBlood
                                                                                          19.05.2015 20:54
                                                                                          #8425907

                                                                                          Можно вложить миллиард долларов в лажу, и ничего из этого не выйдет. Если изначально продукт — фигня, то и миллиард не поможет. А если продукт стоящий — инвесторы найдутся, ведь на стоящем продукте можно и 100 миллионов и 10 миллиардов отбить назад с процентами.


                                                                                          1. OberonForGood Автор
                                                                                            19.05.2015 22:05
                                                                                            #8426035
                                                                                            -2

                                                                                            Вы всегда правы.


                                                                                          1. akastargazer
                                                                                            20.05.2015 08:39
                                                                                            #8426339
                                                                                            -1

                                                                                            И 100 триллиардов, конечно. Ваша твёрдая вера в непогрешимость рынка священна. Мне остаётся почтительно умолкнуть.


                                                                                            1. VenomBlood
                                                                                              20.05.2015 21:35
                                                                                              #8427413
                                                                                              +2

                                                                                              В рынок не нужно верить, он просто работает. Вне зависимости от веры в него. Веру обычно требует то, что не работает.


                                                  1. akastargazer
                                                    15.05.2015 10:29
                                                    #8418847

                                                    Вы пробовали компилить оберон-программы?


        1. Duduka
          15.05.2015 05:34
          #8418563
          +1

          Автокод Эльбрус. Эль-76. Принципы построения языка и руководство к использованию
          r2vr.ru/doku.php?id=эль-76

          Не путайте кастыли мелкомяхких и кривых реализаций языков программирования и синтаксический сахар. Все уже было придумано до нас.


      1. FiresShadow
        15.05.2015 07:43
        #8418609
        +3

        А рефлексия не нужна в составе языка.

        IOC-container, Mock-объекты, Dynamic Proxy, ORM в своей реализации используют рефлексию. И если уметь ими пользоваться, то они избавляют от рутинной работы. Также, рефлексия может быть полезна при написании своих мини-фреймворков. Например, передать лямбда-выражением переменную, а рефлексией получить её имя для логирования и рефлексией установить значение этой переменной. Конечно, рутинную работу можно проделать и самому, но быстрее и проще воспользоваться инструментом.

        Борьба со сложностью задач сложностью инструментов, с помощью которых эти задачи решаются. Конечно, многие от этого выигрывают. Зарплаты растут.

        Это наивное детское представление о мире. Зарплата не зависит ни от пользы работы, ни от её сложности. Она зависит от того, за какую зарплату другие люди согласны делать ту же самую работу. Даже если все программисты сговорятся и не будут использовать сложные инструменты, но при этом автоматизировать процессы всё равно будет выгоднее, чем делать вручную, то зарплаты не изменятся. Кроме того, заказчику безразлично, с использованием каких инструментов написана программа. Ему важна лишь скорость написания, стоимость сопровождения, надёжность, цена и актуальность тех задач, которые решает программа. И эти факторы (помимо актуальности задач) успешнее достигаются, как ни странно, квалифицированными программистами, владеющими нужными инструментами. Конечно, можно рутинную работу и вручную делать, но скорость написания упадёт и стоимость сопровождения увеличится. Поэтому нанять одного квалифицированного программиста выгоднее, чем парочку неквалифицированных (даже если они согласны работать только за большую зарплату). Кроме того, квалифицированные спецы зачастую способны делать то, что неквалифицированные не способны сделать в принципе. Поэтому у них и зарплата выше, и дело вовсе не в мировом заговоре программистов, специально делающих сложные инструменты.


        1. OberonForGood Автор
          15.05.2015 08:24
          #8418641
          +1

          Вы процитировали мою фразу о том, что рефлексия не нужна в составе языка.
          Далее вы рассуждаете так, как будто я отрицаю необходимость рефлексии вообще. Это неверно. Библиотечных функций достаточно, на самом деле. Даже лучше, если такой хитрый механизм будет изолирован от языка, все равно почти никогда корпорации не угадают с набором примитивов.


          1. FiresShadow
            15.05.2015 09:03
            #8418709
            +1

            Библиотечных функций достаточно, на самом деле. Даже лучше, если такой хитрый механизм будет изолирован от языка

            Hibernate — родоначальник современных ORM, был написан энтузиастами в рамках опенсорсного проекта. Я не силён в истории, но уверен что с IOC-контейнером, Mock-объектами, Dynamic Proxy была примерно такая же история. Это стало возможно благодаря тому, что в языке была такая фича, как рефлексия. Это теперь для вас это библиотечная функция. Но чтобы их написание было возможно, эта фича в языке была необходима. Кроме того, рефлексия нужна и рядовым программистам. Например, сейчас я делаю удобную предобработку вызовов сервисов на общей шине, используя Dynamic Proxy, в Interceptor-е вызываю нужную функцию при помощи постороения ExpressionTree. Проще было бы вызвать через рефлексию, но тогда быстродействие просядет. Если бы в языке не было ни рефлексии, ни ExpressionTree, то пришлось бы вручную писать класс-обёртку вокруг каждого сервиса, проксируя вызов каждого метода.


            1. OberonForGood Автор
              15.05.2015 09:28
              #8418743
              -3

              Влияние больших экосистем настолько велико, что искажает смысл и определение некоторых понятий. Вы сейчас описали рефлексию в java-мире, речь же шла про рефлексию вообще.


          1. NeoCode
            15.05.2015 11:48
            #8419007
            +4

            Какие корпорации? Давайте отделим техническую дискуссию от всех этих теорий заговора, здесь им не место. Рефлексия — это естественный механизм получения метаинформации от компилятора. Если поддержки компилятора нет — то и рефлексии нет, и НИКАКАЯ библиотека не способна извлечь информацию, которой у нее нет и быть не может, пока компилятор ее не предоставит. Неужели это так сложно понять?


            1. OberonForGood Автор
              15.05.2015 12:00
              #8419035
              +1

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


              1. NeoCode
                15.05.2015 12:15
                #8419065
                +5

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


                1. oberon87
                  15.05.2015 12:22
                  #8419081
                  -2

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


                  1. NeoCode
                    15.05.2015 14:37
                    #8419311

                    Язык без компилятора это просто никому не нужная абстракция. Вы вероятно в понятие «язык» включаете и базовые возможности (собственно язык в моем понимании), и стандартную библиотеку. Я же намеренно разделяю эти понятия, потому что это реально разные вещи.


                    1. oberon87
                      16.05.2015 12:19
                      #8420527
                      -2

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


                1. OberonForGood Автор
                  15.05.2015 12:27
                  #8419097

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


                  1. intet
                    15.05.2015 14:39
                    #8419315
                    +1

                    Непонятно, что значит

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


                    1. OberonForGood Автор
                      15.05.2015 14:47
                      #8419333

                      Ну и где тут разделение сущностей? Описание языка описывает ровно то, что должно, сам язык. Проблема в том, что кто-то в язык готов запихнуть все подряд, а кто-то нет.
                      При этом реальное отношение разных проблем к языку никакого значения не имеет, мы же заботимся о многом сразу, в итоге все равно ничего не получается.
                      Помимо compile time еще runtime, и еще linktime, которые не обязаны быть оговорены в описании языка. Если вы в языке описываете, как компилятор будет двигать и паковать байты, то всё, закапывайте, у вас байты с уровня железа просочились на абстрактный уровень описания языка. Если компилятор оставил линкеру метаинформацию, это еще не значит, что в языке появилась интроспекция.
                      Давайте все же разделять сущности.


                    1. akastargazer
                      15.05.2015 15:17
                      #8419421
                      +1

                      Как только мы абстрагируем формальный аппарат («язык», о как прав был Дейкстра, говоря, что называть язык программирования языком неправильно!) от конкретного исполнителя, то перестаём видеть компилятор. Остаются лишь требования к среде выполнения (которая не обязана зависеть от аппаратуры).


                      1. intet
                        15.05.2015 15:41
                        #8419489

                        Как тогда называть 'язык программирования'? Да и что в него входит? Правила синтаксиса+ набор стандартных библиотек и требований к среде выполнения или что-то еще?


                        1. akastargazer
                          15.05.2015 15:55
                          #8419527
                          +1

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

                          www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html
                          www.beroal.in.ua/article/dijkstra/ewd854.html


                        1. OberonForGood Автор
                          15.05.2015 15:55
                          #8419533
                          +1

                          Экосистема.


                          1. intet
                            15.05.2015 17:29
                            #8419749

                            Если под 'языком программирования' подразумевать экосистему, то любой более менее используемый язык стремиться усложняется по мере использования.
                            Его начинают использовать для какой-либо деятельности. Программы разрастаются. Из них выделяют библиотеки. Самые часто используемые библиотеки становятся стандартными и входят тем самым в 'язык'. Простым 'язык' может оставаться только если не используется.


                            1. akastargazer
                              15.05.2015 18:00
                              #8419829
                              +1

                              Простым (но не примитивным!) язык может остаться, если концепции, в нём формализованные, проработаны очень тщательно.


                              1. intet
                                15.05.2015 20:10
                                #8419969

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


                                1. akastargazer
                                  15.05.2015 21:09
                                  #8420031
                                  +1

                                  Нет необходимости следовать моде и втыкать всё новые фичи в язык. Вы прекрасно сможете строить хороший софт и без вытребенек.


                                  1. intet
                                    15.05.2015 21:28
                                    #8420063
                                    +4

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


                                    1. VenomBlood
                                      15.05.2015 22:48
                                      #8420175

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


                                    1. akastargazer
                                      15.05.2015 23:34
                                      #8420219
                                      +1

                                      Предметных областей бесчисленное множество. Вам не хватит фантазии на все фичи, а если и хватит, то компилятор лопнет. Ну а если компилятор выдержит, вряд ли ваша голова осилит их все держать :)


                                      1. VenomBlood
                                        15.05.2015 23:53
                                        #8420247

                                        Никто предметные области не пихает в языки. Generics/lambdas/итераторы/замыкания/асинхронная обработка — это все применимо во всех предметных областях и сильно упрощает жизнь, разве что есть особенность для низкоуровневого ПО где своя некоторая специфика, но и не пишут низкоуровневое на Java/C#.


                            1. Duduka
                              15.05.2015 18:03
                              #8419837

                              Нет, у Дейкстры — появляется новый уровень абстракции(новый ассемблер, новый язык...). То болото в которое мы угодили — это результат интегрирования разных уровней в одном языке, на базе одного синтаксиса ( например — LINQ прикольный костыль, или интерпретатор printf в 'с', одновременно массивы и std::vector в c++)


                        1. max-kuznetsov
                          15.05.2015 15:58
                          #8419541

                          Бьёрн Страуструп:
                          «Язык программирования служит двум связанным между собой целям: он является выразительным средством программиста для указания действий, которые надо выполнить, а также набором концепций, которыми пользуется программист при решении проблемы.»


                  1. NeoCode
                    15.05.2015 14:39
                    #8419319

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


                    1. OberonForGood Автор
                      15.05.2015 14:49
                      #8419339

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


                      1. StrangerInRed
                        15.05.2015 14:52
                        #8419357

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


                        1. OberonForGood Автор
                          15.05.2015 15:32
                          #8419453

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


                          1. intet
                            15.05.2015 15:35
                            #8419461

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


                          1. StrangerInRed
                            15.05.2015 15:35
                            #8419465

                            Это смотря какие микроконтроллеры. Попробуйте java на машинах с меньшей памятью, чем знимает jvm. И все язык языком, но вы просто не сможете ее использовать, хотя процессор будет являться полноценным.


                      1. NeoCode
                        15.05.2015 15:47
                        #8419511

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


                  1. NeoCode
                    15.05.2015 14:44
                    #8419327

                    И кстати, первый раз сталкиваюсь с такой терминологией

                    добыть процедуру по имени

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


                    1. OberonForGood Автор
                      15.05.2015 14:51
                      #8419347

                      Да.


                      1. NeoCode
                        15.05.2015 15:45
                        #8419503

                        Можете привести пример на обероне как это делается?


                        1. OberonForGood Автор
                          15.05.2015 16:02
                          #8419547

                          В системе есть модуль Dialog. У него есть процедура Call со строковым параметром. Вызываем Dialog.Call(«Kernel.Beep»)
                          Строка разбивается на имя модуля и имя процедуры, в списке модулей ищется экземпляр типа Module с именем «Kernel», соответствующий модулю Kernel, потом у этого экземпляра в списке экспортированных процедур ищется процедура «Beep», адрес которой присваивается процедурной переменной того же типа, что и Beep, и потом происходит вызов этой переменной процедурного типа.

                          По теме имеем, что в описании языка ни слова про рефлексию, а она есть.


                          1. akastargazer
                            15.05.2015 16:21
                            #8419587
                            +1

                            Паазвольте. Oberon Language Reference всегда включает в себя раздел с требованиями к среде выполнения. То бишь, по Дейкстре, к абстрактному компьютеру, машинным кодом к которому является данный ЯП.

                            А в требованиях к среде выполнения, кроме всего прочего, есть и такое (для примера, из LR CP):

                            Appendix D: Mandatory Requirements for Environment

                            The Component Pascal definition implicitly relies on four fundamental assumptions.

                            1) There exists some run-time type information that allows to check the dynamic type of an object. This is necessary to implement type tests and type guards.


                            1. oberon87
                              15.05.2015 16:45
                              #8419643

                              Проверка типа обусловлена наличием WITH и IS, разве нет? При этом можно и без рефлексии такое реализовать.


                          1. NeoCode
                            15.05.2015 16:24
                            #8419597

                            Спасибо, интересно. Но это не рефлексия, а динамическая загрузка библиотек (будущий boost.dll), тоже важная фича, но другое.


                            1. oberon87
                              15.05.2015 16:44
                              #8419635

                              Нет, это не динамическая загрузка. Читайте внимательнее.


                              1. NeoCode
                                15.05.2015 17:12
                                #8419701

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


                          1. qw1
                            15.05.2015 16:26
                            #8419599

                            Но ведь рефлексия так и работает в java/c#
                            Компилятор оставляет мета-информацию, а через функции стандартной бублиотеки можно найти и использовать эту информацию.

                            myObject.GetType().GetMethod("SomeMethod").Invoke(myObject, paramsArray);
typeof(myType).GetMethod("SomeStaticMethod").Invoke(paramsArray);


                            Никаких встроенных в язык синтаксических конструкций.
                            Чем это хуже/лучше Оберона?


                            1. akastargazer
                              15.05.2015 16:31
                              #8419609

                              Неудивительно, что много похожего, ведь Sun внимательно смотрела на Оберон перед постройкой Java, а Microsoft для построения дотнета приглашала лучших оберонщиков.


                              1. mayorovp
                                15.05.2015 16:46
                                #8419645
                                +2

                                В таком случае имеем вопрос — о чем вообще тут спор? Если в C# и Java рефлексия взята из Оберона, то какая еще рефлексия существует и критикуется в этой ветке?


                                1. qw1
                                  15.05.2015 17:38
                                  #8419787

                                  Например, LISP, LUA или JS, где методы лежат в обычной структуре данных, работа с которой не отличается от работы с обычными данными. Я правильно понимаю защитников оберона, что именно такой доступ к методам — зло?


                                  1. OberonForGood Автор
                                    15.05.2015 22:09
                                    #8420117

                                    Защитники оберона нигде не высказывались о том, что такой-то конкретный способ доступа к методам — зло.
                                    В данной ветке обсуждения оппоненты выясняют обоснования для принадлежности той или иной фичи непосредственно к языку программирования.


                            1. OberonForGood Автор
                              15.05.2015 16:49
                              #8419653
                              -2

                              Никто не сравнивает, просто речь шла о том, что считать рефлексией в языке, а что — рефлексией внеязыковой, и существует ли такая.
                              По мне, это как прямая и имплицитная зависимости. И то, и другое зависимости, но есть нюансы.


          1. merlin-vrn
            15.05.2015 22:05
            #8420109

            Почему вы TCL не проповедуете? Там правил именно что языка — пол-страницы, остальное библиотека. И можете сами себе сделать хоть язык с русскоязычными ключевыми словами, хоть что.


        1. OberonForGood Автор
          15.05.2015 08:28
          #8418645
          +1

          И эти факторы (помимо актуальности задач) успешнее достигаются, как ни странно, квалифицированными программистами, владеющими нужными инструментами.
          Это т.н. систематическая ошибка выжившего. Ни вы, ни я не знаем реальных раскладок вложений ресурсов в продвижение на начальных этапах таких языков как Java или С++ (Микрософт по слухам вкладывалась в его продвижение с самого начала Windows), то, что они благодаря скрытым механизмам выжили и получили ресурсы на полноценное развитие не делает их более пригодными для решения задач. Даже квалифицированными программистами. Очень позитивный сценарий вы описали.


          1. FiresShadow
            15.05.2015 09:09
            #8418719

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

            То, что инструменты при грамотном использовании ускоряют разработку — факт, проверенный на практике. Попробуйте каждый раз вручную мапить результаты запроса к бд на ваши объекты или искать чужие ошибки работы с памятью в С++.


            1. OberonForGood Автор
              15.05.2015 09:30
              #8418749
              -1

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


            1. akastargazer
              15.05.2015 09:55
              #8418777

              Грамотно спроектированный формализм не порождает «чужих ошибок работы с памятью», а следовательно, избавляет вас от лишней работы по преодолению дополнительной сложности.


    1. Alexeyslav
      15.05.2015 11:25
      #8418965
      +1

      Не ограничить а минимизировать. Вот было бы замечательно если помимо 6-гранных болтов и гаек были бы треугольные и например 5 или деже 7-гранные. Для каждого типа гаек надо иметь отдельный инструмент… и тут кто-то придумывает 8-гранную гайку с неравномерно распределенными гранями… под неё выпускается целая серия инструментов, а в мастерских появляется еще один ящик с инструментом.
      И по какому-то недоразумению, все механизмы начинают клепать как минимум с 3-мя видами гаек, а какие 3 из 21 узнаете когда начнёте его ремонтировать.


  1. Mixim333
    14.05.2015 19:11
    #8418035

    Сам пишу на C# и считаю, что этот язык вполне развит и не содержит особых излишеств, хотя сейчас становится все страшнее и страшнее от того, что с ним делают, что в него добавляют. Как-то читал статью про один из многочисленных ЯП, компилятор каждой версии которого собиралась с помощью предыдущей версии (на чем была написана 1 версия не помню) — вот это действительно излишество и увеличение синтаксического сахара с каждой новой версией.

    Для меня основными критериями по выбору IDE для себя являются: «прожорливость» (сколько системных ресурсов требует) и отсутствие не нужных «красивостей», поэтому собственные проекты пишу в MonoDevelop (простая, быстрая, стабильная IDE, которая лично у меня ни разу не отжирала больше 100Мб оперативки), а на работе в силу устоявшихся корпоративных стандартов — VisualStudio (порой сжирает до 3Гб).


    1. akastargazer
      14.05.2015 21:54
      #8418217
      -1

      Спартанский BlackBox Component Builder по нетребовательности к ресурсам бежит далеко впереди MonoDevelop (на компе стоят оба, могу сравнивать). Правда BlackBox настолько суров, что не каждый избалованный программист может в него (хотя сделан он по заветам Дж. Раскина, монотонный интерфейс, гипертексты, вот это всё).


      1. akastargazer
        15.05.2015 09:56
        #8418781
        +1

        Минусуют, очевидно, избалованные программисты :)


    1. stepik777
      17.05.2015 12:58
      #8421175

      Как-то читал статью про один из многочисленных ЯП, компилятор каждой версии которого собиралась с помощью предыдущей версии (на чем была написана 1 версия не помню) — вот это действительно излишество и увеличение синтаксического сахара с каждой новой версией.
      Как связано наличие синтаксического сахара, с тем как разрабатывается компилятор? По такой модели разрабатывается Раст (первая версия была написана на OCaml), но из него как раз наоборот со временем выпилили много фич и синтаксического сахара.


  1. Error1024
    14.05.2015 20:16
    #8418107
    +3

    Я последнее время заметил возрождение и интереса к классическим Pascal, Oberon, Smalltalk, видимо некоторые люди уже успели разочароваться в C++/Java/Etc. Хотя, возможно показалось.


    1. StrangerInRed
      14.05.2015 20:39
      #8418129
      -3

      Напишите такой коммент в профильный хаб С++ иди Java. Такой себе хабрасуицид будет.


      1. Error1024
        14.05.2015 20:57
        #8418151
        +3

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


        1. akastargazer
          14.05.2015 21:55
          #8418219
          +6

          Это же хабр, тут за отклонение от линии партии могут в бетон утоптать.


          1. Error1024
            14.05.2015 22:18
            #8418243
            +2

            Потихоньку утаптывают, но это не повод не высказывать своё мнение.


          1. OberonForGood Автор
            14.05.2015 22:59
            #8418291
            +1

            Саморегуляция.


    1. NeoCode
      14.05.2015 22:24
      #8418247
      +1

      Нет, не думаю. Просто некоторые старые языки — такие например как Smalltalk — могут содержать немало интересных идей, поэтому иногда здесь появляются статьи, и мы их с удовольствием читаем…


      1. oberon87
        14.05.2015 23:05
        #8418303

        Как раз недавно обсуждали Smalltalk. Думаю, дело даже не в идеях, их можно сколько угодно выдумать, а в условиях существования андеграундных экосистем типа оберон- или смоллток-сообществ. Со стороны лучше видно ситуацию в отрасли, потому что бизнес-процессы не затягивают в бездумную гонку за возможностями и усложнением. Есть время подумать, скажем так.
        Выше уже приводили пример на аналитические выкладки Губанова про синтаксис.


  1. barabanus
    15.05.2015 04:08
    #8418541
    +1

    Если говорить о простом языке высокого уровня, то я бы привел в пример Lua. Если взять типы данных, то там их минимум — числа, строки, функции, таблицы. При этом таблица — это и ассоциативный массив, и линейный массив, и объект с методами и полями. Нужна фича из другого языка? Написал сверху несколько строк.


  1. TelnovOleg
    15.05.2015 08:17
    #8418635
    +3

    Мне кажется что многие люди подсознательно ставят знак равенства между понятиями «простой» и «легкий». Вот например язык Forth обладает очень простым синтаксисом. Фактически в нем вся программа это просто набор слов (под которыми скрыт аналог вызова функции с неявной передачей параметров через стек). Но вот написать на нем достаточно большую программу занятие далеко не легкое.
    Простые по синтаксису языки позволяют гораздо лучше контролировать производимые действия на низком уровне, т.е. мы можем детально разобрать применяемый алгоритм, распределение памяти, затраты машинного времени и прочее. Но оборотной стороной является необходимость писать очень много кода несущественного для основного алгоритма задачи, но требуемого для связки низкоуровневых инструкций. Так в Forth нужно тратить силы на манипуляции с порядном данных в стеке, а в Oberon следить за вложенностью циклов и выходом индексов за границы массивов, в то время как весь полезный алгоритм можно описать парой или тройкой комбинаций MapReduce.
    Но с другой стороны, понять какой-то кусок современной программы на Lisp, JavaScript или Java/C# без понимания что скрыто за применяемыми абстракциями практически невозможно. А уж тем более затруднительно оценить ресурсоемкость таких программ. Наверно поэтому языки со сборкой мусора очень трудно проникают в программирование систем реального времени.
    Фактически наличие дополнительных синтаксических конструкций приводит к проблеме любого DSL. Он вроде бы облегчает написание, пока задача укладывается в его возможности и хорошо ложится на его конструкции, но совсем не упрощает поиск причин проблем возникающих в скрытом слое или реализацию задач не вписывающихся в его парадигму.
    А так как, семантика решаемых задач практически бесконечна, то и лавину фреймворков, «сахарных» конструкций, библиотек API и прочее, прочее, прочее… остановить вряд ли возможно.
    Но, может быть, решение не в рамках создания универсальных языков, вынуждающих или писать много низкоуровневого кода или изучать внутреннее строение монструозных фреймворков? Почему не возложить на среду разработки генерацию любого промежуточного кода («промежуточный» — это код связанный с передачей и преобразованием данных от одного модуля или функции к другим). Возражения о не оптимальности кода созданного автоматически это лишь признак плохого проектирования системы автогенерации. А нам лишь нужен язык достаточно простой для автоматизации типовых операций, передачи параметров, комбинирования функций и построению сложных объектов из более простых (т.е. с упором на контейнеры, а не наследуемые объекты). И тогда, основной алгоритмы задачи можно описать очень просто, а вся сложность перенесется на логический вывод автогенерируемого кода.


    1. oberon87
      15.05.2015 10:51
      #8418897

      Любая, даже малая генерация кода лишает вас контроля над кодом. Генерацию SQL когда-то тоже считали прорывом, но быстро наткнулись на то, что лучше писать руками.


      1. NeoCode
        15.05.2015 11:35
        #8418981

        Если делать генерацию кода как следует, то все будет ОК. Просто до сих пор нормально никто не сделал, делали тупо «в лоб». Как минимум, при генерации кода обязательно должна создаваться метаинформация о связи генерирующего и сгенерированного кода, и активно использоваться при отладке и даже при редактировании кода.


        1. TelnovOleg
          15.05.2015 12:11
          #8419061

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


      1. TelnovOleg
        15.05.2015 12:07
        #8419051

        Просто на сегодняшний момент все известные мне системы кодогенерации работают просто как трансляторы из одной формальной модели в другую, совершенно не занимаясь оптимизациями. Т.е. фактически они работают как макроязыки. Что приводит либо к необходимости написания сложной и подробной первоначальной модели (а тогда и упрощение от такого средства сомнительна), либо к избыточности и неэффективности порождаемого кода.
        Именно из-за формального подхода падает эффективность различных ORM, когда запрос работающий с несколькими объектами превращается в тормозного монстра из мешанины мелких SQL запросов. Хотя если написать такой запрос с учетом всех возможностей SQL, то размер и производительность улучшаются на порядок. А всего лишь надо, чтобы система могла произвести не только синтаксический, и даже не только семантический, но и логический разбор входного кода и произвела его оптимизацию (например, абстрактно, вместо двух одинаковых циклов по разным полям объединила эти запросы в один)
        И так со всем остальным. Все в выводе кода, что можно описать в виде логических правил на языке типа Пролога, должно быть описано и выводится автоматом, а не заставлять программиста писать тонны связующего кода.
        За мной должно остаться только придумывание общего алгоритма, выбор дополнительных функциональных блоков, возможность внести изменения в сгенерированный код и интерфейс.
        Причем язык должен быть спроектирован так, что мои изменения встраиваются в базу фактов и учитываются при новом логическом выводе. Например, если автогенератор применил алгоритм сортировки пузырьком, а я изменил на сортировку вставками, то в следующий раз он тоже отсортирует также. Если я определил дополнительный блок проверки прав доступа к базе, то он должен автоматически встроиться во все места где происходит доступ, без необходимости мне писать вручную хоть строчку.
        Т.е. моя формула нового даже не языка, а среды разработки = минимальный синтаксис + аспектное программирование + логическое программирование + неявная передача параметров с их автоподстановкой.
        Вот такие вот фантазии :)


      1. mayorovp
        15.05.2015 16:35
        #8419617

        Извиняюсь, но кто наткнулся? Я за последние несколько лет писал на «сыром» SQL только рекурсивные запросы и частично миграции — для всего же остального я не вижу никаких отличий между сгенерированным кодом и написанным руками в плане производительности (хотя проверяю скорость работы генерированных запросов регулярно).


        1. akastargazer
          15.05.2015 16:44
          #8419639

          Что же мешает вам использовать сгенерированные рекурсивные запросы?


          1. mayorovp
            15.05.2015 16:47
            #8419647

            Ничего кроме отсутствия генератора.


            1. akastargazer
              15.05.2015 16:49
              #8419655
              +1

              Значит, лучше всё-таки руками.


              1. mayorovp
                15.05.2015 16:52
                #8419663

                Рекурсивные запросы — да. Но их приходится писать не чаще, чем раз в год.


  1. GarryC
    15.05.2015 09:34
    #8418753
    +3

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


    1. akastargazer
      15.05.2015 10:17
      #8418819
      +1

      Несмотря на интенсивное развитие ИТ, главный вопрос всегда стоит ребром: как быстро и аккуратно строить надёжные расширяемые системы? С одной стороны у нас компьютер, возможностей которого никогда не хватает; а с другой стороны бесконечно сложные предметные области.

      Здесь можно увидеть два варианта:

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

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

      Есть ещё и третий вариант, «каждый язык для своей предметной области», но это уже скорее к DSL относится.


  1. stepik777
    17.05.2015 12:46
    #8421171
    -1

    «Совершенство достигается не тогда, когда уже нечего прибавить, но когда уже ничего нельзя отнять»
    Антуан де Сент-Экзюпери


    1. qw1
      17.05.2015 14:29
      #8421223
      +1

      brainfuck, машина тьюринга — совершенны ))