Как стать автором
Обновить

Комментарии 467

НЛО прилетело и опубликовало эту надпись здесь
Но ведь операторные скобки сейчас расставляет IDE. А например в вашей статье про Brainfuck VM длинные квалификаторы, длиннее, чем слово BEGIN, но вы не стали их сокращать.
НЛО прилетело и опубликовало эту надпись здесь
С моей точки зрения эстетически приятнее когда код плотный, аккуратно разбит на иерархические блоки.
С этой точки зрения код на Обероне мне приятнее, чем разреженный код на Java, где пустого места на единицу площади иногда больше, чем кода.
Пример



Но это все вкусовщина, конечно.
Если добавить комментарии и пустые строки, то любой текст станет разряженным :)
А так пишите хоть без пробелов, джаве то все равно
Стайл-гайдам не все равно, они советуют писать именно так. Разделять пустотой объявления и действия, переносить скобку после объявления на новую строку. И так далее.
Конечно, и благодаря этому вы получаете более высокую читаемость кода. Но в реальном коде не будет «пустого места на единицу площади иногда больше, чем кода», не надо перегибать палку.
Напомню, речь изначально шла о том, что в Обероне, например, не нужно пустое пространство для разделения, так как эту роль выполняют ключевые слова (которые не нравятся многим), которые выглядят особенно. «Глаз цепляется», знаете такое выражение?
Ага, читал такую. Сергей Губанов, уважаемый оберонщик.
Я помню, что при изучении Си я имел такой стиль (кстати, вполне культурный K&R), что при просмотре экзерсиза на Паскале я долго плавал взглядом по экрану ища и собирая смысл в кучу. Было такое ощущение, что смысл есть, но он распылён по всей площади экрана с добавлением гигантских лакун.

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

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

После этого я решил, что вопрос колебания плотности информации на экране (в известных пределах. Я не говорю про Ифкуиль) — это вопрос мимолётной привычки, и полагается смотреть в языке совсем на другое.
НЛО прилетело и опубликовало эту надпись здесь
Пустые строки, да еще и лишние (т.к. очевидные) комментарии.
Скриншот кода на Обероне вызывает неконтролируемое минусоизвержение.
Неконтролируемое минусоизвержение вызывается «сравнением» несравнимого. Вы бы хоть одинаковый алгоритм привели — а то ведь сравниваете достаточно сложный алгоритм на Обероне с заготовкой кода на Java, которая пока что вообще ничего не делает!
Размер шрифта почти тот же, площадь картинки одинаковая. Ну и контраргументация минусами она да, работает. Еще по морде можно дать. Мыжпрограммисты.
Так говнокод же. IF ch = 10X THEN INC(ref, 4) END;
Почему 10? Что такое 4?
pos еще ясно что такое, а что такое переменные ad и d?
Что за магические значения 0FDX?
Об этот код любой ногу сломит, а если его переписать в читаемый вид, он тоже больше места займет. На Java (не поверите) тоже можно говнокодить и записать все в одну строчку.
А так — почитайте Макконнелла «Совершенный Код», там хорошо объяснено почему писать так как на скриншоте — зло.
Или «Чистый код», тоже хорошая книга.
Без подсветки синтаксиса они конечно мешаются, но никаких проблем!
Операторные скобки надо не только писать ЗАПЯТАЯ но и читать ТОЧКА Символы более визуально отличны от слов ЗАПЯТАЯ занимают меньше места ЗАПЯТАЯ и создают меньше шума ТОЧКА Мне ЗАПЯТАЯ например ЗАПЯТАЯ нравится вообще без операторных скобок ТИРЕ как в Питоне или F# ТОЧКА :)
Если бесшумно записать фразу с парой циклов и if на Java в одну строчку, будет ли она понятнее, чем ваш пример?
Думаю, да. Еще можно попробовать заенить все смволы арифметических операций на слова и посмотреть, насколько стало непонятней. Говорят когда-то так и писали.
О чем еще спорить, как не о вкусах :)
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) Второй пример синтетический.
2) В Обероне это удобно.
3) Дело во вкусах.
Почему в Обероне становится удобным то, что неудобно во всех остальных языках?
Намного ли удобнее увидеть присваивание значения переменной, которое находится в середине строки между других операций? Не это ли есть снижение читаемости кода? Почему в Обероне это удобно?
Длинное выражение между THEN и END каким-то образом избежит возникновения горизонтальной полосы прокрутки? Или Вы разобьете его на две строки, сделав чтение кода еще менее удобным?

Если есть преимущества у написания кода в строку (включая те особенные для Оберона, о которых Вы говорите), которые могут компенсировать потерю читаемости и удобства редактирования кода — расскажите о них, иначе ваши слова о вкусах совершенно пусты.
Вы говорите «неудобно». Я говорю «удобно». Вы не верите мне, а я вам. Вы исходите из своих вкусов, я из своих. Непонятно, с чего сыр-бор? Почему вам станет удобно, если было неудобно? Я не знаю. А вы в чем удобство измеряете? В сантиметрах? Удобно это сколько? 13 cм? Или 26 см?
Добавлю остроты — ещё удобнее читать компактный пропорциональный шрифт, а моноширинный зря расходует пространство экрана. И это не троллинг, а личный опыт. Я раньше программировал с моноширинным с синтаксической подсветкой, но постепенно перешёл на пропорциональный с архитектурной подсветкой. Патриотичный PT Sans прекрасно подходит для кодирования.
Моноширинный используют потому что отступы строго прогнозируемые, а в пропорциональном — как повезет, выравнивать код «столбцами» очень трудно в текстовом редакторе.
Почувствовал огромное облегчение, когда перестал заниматься подобным.
Теперь мои исходники выглядят примерно так:

Почему-то картинка не видна
hsto.org/files/2ad/e5f/bfe/2ade5fbfe2a4482baf0b01a9aa784612.png
о черт. сломал глаза. Но и правда, отступами в таком коде и не светит, поэтому пофиг какой шрифт использовать.

Теги пропадают в коментариях когда карма ниже нуля.
Почему же не светит. Табуляция наш друг. Плюс в текст (это составной документ, да, а не примитивный plain text) вставляются форматирующие линейки. А шрифты я перепробовал самые разные.

Так что меня всегда веселят комментарии в стиле «сломал глаза», ведь у меня реальный опыт, против сугубо теоретических рассуждений )
А меня веселят слова «ведь у меня реальный опыт».
У вас не реальный опыт, а сугубо личный опыт в конкретных условиях с ограниченным количеством сред. Его нельзя наложить на все условия и сказать что так будет правильно для всех, всегда и везде.
Ибо у меня тоже реальный опыт.
И у кого-то еще тоже реальный опыт…
Я и не говорю, что мой опыт надо накладывать на все условия :) Логика понятия «опыт» как раз конкретная. Это вы и вам подобные начинают накладывать собственный опыт на Оберон, делая ошибку, о которой вы и сказали только что.
о черт. сломал глаза.
Покритикуй Оберон со строчной буквы в начале предложения — получи +2.
Проклятый Оберон, пропади, пропади с экрана. Не могу его больше видеть.
Я даже и не думал привязывать ощущение к какому-либо языку программирования, рассмотрел этот кусок кода просто как текст. И уже на этом этапе возникли проблемы.
Привыкнув к такому стилю оформления текста программы он может и будет выглядеть красиво, но… первое впечатление незнакомого с данным стилем — отрицательное. А значит не имеет продолжения(с чего бы вдруг жевать кактус?).
st = v.t.ThisSetter();?
И эти люди говорят мне о методологии написания хорошего кода?
Бла-бла-бла, рынок так не пишет.
Да, да, расскажите нам, что { читается легче, и выделяет блок лучше, чем 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;


Вообще, это такая вкусовщина…
Думаю, что нет. Просто
if (x > y) {
BECIN;
EMD
}

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

IF (x>y)
BEGIN
BECIN
EMD
END

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

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

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

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

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

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

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

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

Если есть единый стайлгайд И софт который это проверяет или автоматически переформатирует. Кстати как с эти у Оберона?
Не, я скорее про Вирта с его begin/end ами, которые наиболее известны в Паскале, против {} в других языках, чем про конретно Oberon.

А можно ещё
IF x > y THEN
Becin;
Emd()
END;
Вообще в программировании ценится не скорость считывания программы с экрана…

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

Я бы вообще представлял программы в 3-х мерном виде(активный уровень на переднем плане) в виде дерева. там никакие скобки не нужны были бы. Всякие эти скобочки, выравнивание — оно нужно только для возможности редактирования текста программы в простых плоских редакторах. Если создать такой софт, где программа редактировалась бы на объектном уровне — все эти заморочки с отступами и скобками просто не нужны были бы.
Движение в эту сторону есть, как мне кажется cyberleninka.ru/article/n/razrabotka-mnogoyazykovogo-redaktora-na-osnove-semanticheskoy-modeli-programmy.pdf
При этом, что интересно, оберон взят за один из базовых представлений.
Да, это несомненно хорошо. Идея просто витала в воздухе, но жаль что это реализуют только сейчас.
Вот тут вы и показали основную проблему Паскаля. Писал на нем 5 лет — но за все это время так и не смог подобрать правильного способа написания конструкции «end else begin», которая бы нормально читалась хотя бы мною же :)
Паскаль давно устарел, есть же Оберон.
Такая конструкция и в си ужасно выглядит — как разбазаривание пространства в духе

}
else
{
Скобки и else хотя бы разного размера — сразу видно что где. И редактор их зачастую разным цветом подсвечивает, что тоже помогает.
Когда разный цвет подсветки, то слова будут заметнее и контрастнее.
К сожалению, в паскалеподобных языках все три слова попадают в категорию ключевых слов. Я не видел еще ни одного редактора, который умел бы подсвечивать ключевые слова разными цветами.
«Notepad++» и ему подобные — настраивается синтаксис в том числе и группы ключевых слов. Под паскаль не пробовал, но давно настраивал его под ассемблер PIC и AVR контроллеров с выделением разным цветом групп команд и даже макросов.
У нас приняли такие правила:

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?
Вы имеете в виду вот так?
if condition
  then
    begin
      op1;
      op2;
    end
  else
    begin
      op3;
      op4;
    end;


Да, я тоже в итоге пришел к такому. Но сколько же места на экране оно занимает… Особенно при 50 строках на экране. Надеюсь, хотя бы последняя проблема сегодня перестала быть актуальной у большинства паскальщиков!
Так 25 же строк было! Или даже 24. Откуда в CGA/EGA 50?
При чем тут CGA/EGA? Я олимпиады уже в основном под Windows писал (кроме старого комп. класса в ЮУрГУ во втором корпусе, где были бездисковые рабочие станции под DOS — но даже там 50 строк были доступны).

Только вот регламент был еще старый, и Delphi в списке разрешенных сред разработки не было. Только Free Pascal (или даже Turbo Pascal), и что-то такое же текстоворежимное для С++.
Надо еще постараться, чтобы встретить EGA. Последний раз работал с EGA еще до выхода W95.
Я тоже. И Паскаль я в последний раз видел тогда же.
2006г первый курс универа — во весь рост.
Да, это почти последний вариант. Но не совсем.
if then
else
остальные части — с отступами. Т.е if и else на одном уровне. Можно и begin..end на том же уровне, но так все же похуже.
Отчего в моем сообщении не работает source тэг… судя по вашему комментарию, он не только у меня не виден.

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

IF condition THEN
op1; op2
ELSE
op3; op4
END;
Напомнило Бейсик:

IF condition THEN
op1: op2
ELSE
op3: op4
END IF
Отчего минусите-то? Разница рельно только в двоеточии и «END IF»
Видимо, слово «Бейсик» по отношению к языкам программирования для многих считается ругательным…
На хабре отклонение от линии партии карается.
Это стремление сделать ваш комментарий прозрачным, чтобы его не было видно.
-1 — это еще не минус, это просто погрешность.
Шутки за 28.
Потому что как это так, разве можно выкидывать из языка фичи

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

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

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

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

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

compact-programming.narod.ru/Index.htm
В одном флаконе, и зачем так гневаться, ну не осталось инженеров в IT, значит так и надо.
О, олдскульный сайтик на народе… они еще существуют:) Когда-то давно во времена диалапа я по крупицам собирал интересную информацию с таких вот страничек…
Я наблюдал развитие средств разработки последние два десятка лет. И меня не покидает смутное сомнение. Средства разработки становятся «как бы проще»: не надо выделять память и потом следить за её освобождением, не надо думать, на что указывает указатель, не надо даже скобки расставлять… Но вот объём знаний, который должен иметь разработчик, чтобы сделать действительно серьёзный продукт, от этого нисколько не уменьшается. И даже наоборот, растёт чуть ли не по экспоненте. Каждая среда разработки, каждый фреймворк вносят свои абстракции, и на первый взгляд всё работает. Но наступает момент, когда абстракция начинает трещать по всем швам. И тогда приходится лезть в глубины того же фреймворка и смотреть, что у него не так с той же памятью, с теми же указателями…

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

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

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

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

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

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

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

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

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

Соответственно, с их точки зрения использование Фреймворков лучше
А дыры залатывать это когда нибудь потом, и вообще «вы обещали что оно будет работать — чините бесплатно».
Дыры залатывать, да и сильно потом переделывать как раз потом придется на самописном фреймворке. В код которого широкая общественность не глядела, код которого к best practices никто никогда не приведет. Как раз таки потому что «нужно здесь и сейчас», а потом времени на это не будет, будет другой проект/новая фича
А если взять «общественный» фреймворк, в котором потом появятся новые фичи, то нарастёт несовместимость и ваша codebase протухнет со временем.
А есть язык который не «протухает»?! Единственное будущее программистов — переписывание программ под новые реалии (протоколы, топологии, устойства,… языки).
Есть, и этот язык называется Оберон :)
И FORTRAN
Фортран вечен!
FORTRAN IV, FORTRAN 66, FORTRAN 77 (или имели в виду RATFOR?), FORTRAN 90… или FORTRAN 2003!?
Оберон 1/2/active/CP.../7 где вечен?! Кончайте стебаться, тем более над этими зомби…
codebase так и так протухнет со временем (т.е даже со своим фреймворком), выйдет новая версия языка например.
Посмотрите на математиков/физиков — практически у каждого свой наработанный и вылизанный до идеала фреймворк с которым они и работают. Ситуации когда у них что-то рушится по причине неправильной работы фреймворка очень редки. А всё от чего — они не спешат сломя голову

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

Хотя понятие качества у них, конечно, своё.
Странно. Совсем недавно была статья, насколько все плохо с научным софтом. Софт пишут непрофессионалы в программировании и он не самого высокого качества.
Это Вы о статье про британских учёных? Да, слышали-слышали об их открытиях…

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

Приведённый тут сравнительный анализ синтаксиса как раз показывает, что майнстрим движется по пути наращивания возможностей на выходе, а оберон движется по пути уменьшения ошибок на входе.
Ученые используют очень ограниченный набор возможностей языка. Для них язык не становится сложнее или легче с появление рефлексии, так как они ее просто не встретят. Так же с большуй частью нововведений. Ученым они просто не попадутся на глаза и не будут мешать или помогать.
Зато например лямбды упрощают жизнь, хотя и являются довольно сложными для понимания возможностями языка.
Несколько раз наблюдал, что расчёты сходятся даже при перепутанном знаке или пропущенной строчке в формулах. Правда, сходятся медленнее, чем было бы при правильных формулах. И не всегда…
Это вполне возможно и математикой не отрицается. Возможно, эти части формул просто слабо влияют на результат.
Просто там используются итерационные методы :) Движение на каждом шаге идёт слегка в другом направлении, но сходится всё равно к той же точке.
Споэльски в своей статье про протекающие абстракции описал точку зрения, схожую с вашей. Однако я больше склоняюсь к высказыванию Эрика Эванса на этот счёт: «Рутинная деятельность должна быть автоматизирована. Автоматизация того, что должно быть трудом программиста, контрпродуктивно». Если инструмент автоматизирует то, в чём нужна свобода манёвра, то он ограничивает свободу действий программиста. Если абстракция инструмента протекает, то программисту приходится залезать в его внутренности. Если в инструменте есть баги, программисту приходится прикручивать костыли. Я думаю, что проблема может быть в недоработанности, недостаточной документации, плохой архитектуре инструментов, а не в их сложности. Например, современные ORM не имеют утилит для анализа запросов и автоматической генерации индексов, не умеют оптимизировать запросы, поэтому иногда приходится при помощи профилировщика смотреть, какой sql код они генерируют. Но если исправить эти и некоторые другие недоработки, то ORM станет более сложным, но более удобным инструментом, и программистам, использующим его, не будет необходимости знать sql. Таким образом, имхо, проблема не в сложности инструментов, а в их недоработках или изъянах.
Развитие ORM — вещь неизбежная, и не скажу, что это плохо. Но я всё же пойду и разберусь, как эти новые штуки работают изнутри, и заставлю своих проггеров выучить sql. Чтобы, когда ORM стуканёт на каком-то запросе, мы могли быстро поставить заплатку. А когда стуканёт у Вас, мы могли с этого поиметь ещё и дополнительную денюжку.
Кажется, вы меня немного не поняли. Я не говорил, что гарантированно наступит светлое будущее, когда ORM ни разу не «стуканет». Я говорил, что если ORM будет настолько хороша, что никогда не «стуканет», то рядовому программисту не будет необходимости знать подробности её работы. Многие не знают как устроена файловая система, но успешно ей пользуются. Файловая система — хорошая, не протекающая абстракция.
К сожалению, ORM никогда не будет настолько хороша. Причина банальна — концептуальную сложность предметной области невозможно полностью охватить механическим маппером, ведь концепции декларативного SQL и объектной модели разные. Поэтому у вас постоянно будет проседать либо сложность (просто, но быстро), либо производительность (сложно, но медленно).
В XIX веке некоторые примерно также объясняли невозможность полёта на Луну. Или, может быть, дело не в этом, и вы просто пророк?
Наступил век XXI, но до сих пор никто не понимает, как справляться с нарастающей сложностью. Это, кстати, не я сказал, а Дейкстра.
Не могли бы вы пожалуйста немного пояснить, что в вашем понимании означает «ORM никогда не будет настолько хороша, что никогда не стуканёт»?
Я уже пояснил.
> концепции декларативного SQL и объектной модели разные
Всё равно не понимаю, «стуканёт», как глагол в будущем времени, предполагает некое действие в будущем. Какое действие? Я не спорю, концепции реляционного SQL и объектной модели разные, но при чём тут принципиальная невозможность ORM когда-либо стать инструментом, для использования которого знание глубинных принципов его работы не являлось бы обязательным навыком? Различие в концепциях является лишь причиной, мешающей полностью абстрагироваться от самого существования базы данных, но не более того.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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


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

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

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

При всем уважении в профессору Вирту, его оценка сложности языков программирования основана на правилах грамматики, то есть, говоря по-простому, оценивает лишь синтаксис, не затрагивая семантику. Однако, проблема в том, что семантику сложно, а в большинстве случаев невозможно оценить в цифрах. Я уже не говорю о том, что само понятие «семантика» _немного_ расплывчато. Тем не менее, я следую понятию семантики из википедии: 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 в Оберон, не усложняя его? Или она уже есть?

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

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

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

Насчет языков: О Харухи, как я с вами согласен! Это настолько разные концепции, что пришивать пятую ногу к существующим языкам — значит ограничивать возможности GPU. Именно поэтому я говорю, что нужен новый язык для GPU, отстаньте вы от старичка Фортрана. Но рынок уже рассудил, что лучше пускать отдельные циклы на GPU, а не пытаться переписать всю программу на новом языке. И это можно понять. Таков мир, к сожалению.
Для такой логики в обероне что-то многовато ключевых слов (вроде бы 32, тогда как, наприме, в хаскеле, который хронически считают сложным, — около 25). Навскидку — зачем MOD, DIV, AND, OR, которые даже не расширяют язык новыми конструкциями, а всего лишь являются слегка замаскированными функциями; разве нельзя было сделать их библиотечными, зачем усложнять язык?
Вам из погреба виднее.
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)

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

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

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

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

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

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

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

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

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


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

А про оператор присваивания я не совсем понял. Ведь речь идет о балансе, а не о примитивизме.
Да, оператор присваивания в конечном итоге превратится в пяток инструкций. А шаблон во сколько превратится? И кто за все это будет отвечать?
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). Но то, что эти библиотеки появились, и что ими, несмотря на сложности, пользуются — признак того, что соответствующие возможности реально востребованы.
Подождите, что подразумевается под «языковая фича»?
Как обычно — то что встроено непосредственно в язык и поддерживается компилятором. Например, операторы if/else. Для сравнения, операторы консольного ввода/вывода (всякие printf, println, WriteLine) — это библиотечные возможности, компилятор о них не знает.
Ну технически это разные вещи. Есть описание языка, есть компилятор. Иногда они друг другу соответствуют. Если язык не предусматривает конкретные интерфейсы рефлексии, но при этом их компилятор предусмотрел, и какой-то компонент для рефлексии на этом построен, то это фича библиотечная, а не языковая. И работать она будет так же, ну может отличаясь нюансами.
Я считаю, что компилятор соответствует языку (иначе это уже компилятор другого языка, пусть и очень похожего). То что в жизни компиляторы не всегда соответствуют стандартам языков — это вообще говоря проблема, а не нормальное явление. Сами посудите: вот переходите вы на новый компилятор — а программа не компилируется или не так работает. Оно вам надо?
В общем, такого категорически не должно быть. Поэтому лучше, чтобы все фичи были официально задокументированы в стандарте языка, и — что не менее важно — чтобы не было никаких фич, не описанных в стандарте.
Как Вы верно отметили, в реальности описание не соответствует компиляторам и наоборот, и каким бы подробным не было описание крутейшего языка, никогда и не будет соответствовать, потому что люди пишут. То есть, парадоксально, все знают, что будут ошибки, никто не знает, где выстрелит, но все равно делают. Мир деятельных людей. Не могут сделать правильно, и не хотят сделать просто. Поэтому, в частности, язык должен быть простым. Чтобы было меньше точек отказа даже на этапе прочтения и понимания описания языка.
Потому что нужно писать — и компиляторы, и документацию — как следует, а не как попало. Простота языка — это перекладывание проблем на плечи пользователей, все чего нет в языке им придется допиливать вручную. А сложность языка — это результат того, что во-первых, не все бывает сразу ясно (когда создавался С++ многие вещи были еще неочевидны, в Java и C# их учли), во-вторых — страх сломать «обратную совместимость». Сейчас уже более-менее все очевидно по фичам, ну и делать нужно с нуля, а не издеваться над С++.
Я вот тут ради проверки своей версии реальности попробовал реализовать фреймворк для одного из диалектов Оберона. Чуть более сложный, но в целом, одно и то же, минимум фич языка. Так вот, это реально сложная задача. По крайней мере, для меня. Реально, для старого, изученного языка, с минимумом сумеречных зон, написать с нуля рантайм, по готовым лекалам это трудно. Конечно, можно сказать, что в крутых конторах типа оракла сидят намного более умные люди, и они уж точно напишут с нуля хорошо. Но как мы видим, получается все равно не очень.

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

«в каждом проекте свой язык» можно сказать и про тот же C++ — в зависимости от того, какими библиотеками пользуются. Команда, использующая какой-нибудь MFC не быстро найдет общий язык с использующими Qt.
Это же чистый overengineering. Сейчас синтаксис работает одинакого и предсказуемо в любом проекте на распространенных языках программирования. Когда я пишу foreach я знаю во что это развернется и понимаю как это работает, к этому есть документация. Для каждой фичи есть подробные описания и разборы ошибок и узких мест на всяких stackoverflow.
Добавление стандартизированного синтаксического сахара — это как раз упрощает ПО, а использование чего-то низкоуровневого и тем более с самописным синтаксисом — усложняет. Взять те же async/await и итераторы в C#. Да, фича сложнее чем осознать как работает for или if, но поняв один раз — можно использовать на любом проекте и код получается гораздо более читабельный и простой. И не надо городить каждый раз костыли для эмуляции этих фич.
Да нет, это реализуется не так уж сложно.
Я немного не это имею в виду. Допустим, у вас есть ряд проектов, совершенно различных, но разрабатываемых одной командой. И этим проектам нужны внутренние языки. Скриптовые. Сейчас у нас в команде есть 3-4 разных языка, каждый из которых трудится в качестве скриптового в отдельной программе. Да, они похожи. Настолько же, насколько походи Java, PHP, Basic и C — т.е. условно. Человек, который должен работать с этими скриптами, должен знать все 4 языка.
А могло быть иначе: язык один, но модульный, к нему в зависимости от необходимости, могут подключаться нужные модули, реализующие операторы, функции или даже целые конструкции, которые позволяют этому языку работать с конкретной программой, к которой он прикручен.

но поняв один раз — можно использовать на любом проекте и код получается гораздо более читабельный и простой
Вы точно так же можете сказать про, ну, например, boost.asio. Однако в каком-нибудь другом проекте будет использоваться другая библиотека, и знание этой, стандартной по сути, вам не поможет. Т.е. такой язык, с минимумом встроенного, тоже модульный. Не по части синтаксиса.
Как DSL — вполне возможно, хотя и сейчас хватает средств для создания своих DSL'ек. Но как мейнстрим язык программирования (то, на чем пишется основной код) — такое не надо.
Сейчас вендоры меняют язык без вашего ведома, плюс пять фич год, а тут всего одна фича, которая законно решит абстрактную проблему монолитности синтаксиса и компилятора. Еще на уровне формального описания. Ну или хотя бы вынудит реализаторов компилятора сделать такую фичу.
Плюс хоть 10 фич в год — они везде одинаковые, а тут не «одна фича» а каждый барин будет делать себе свои фичи. Никакой проблемы «монолитности» нету, язык один и все им пользуются одинакого. Если я вижу foreach — я знаю как он работает в любой программе на определенном языке. Если я вижу лямбды — я тоже знаю как они работают. А тут foreach у каждого свой. А такие вещи как async/await вообще половина «баринов» реализует через одно место просто в силу их сложности. И никакого формального описания тут не будет, точнее будет одно маленькое описание и неопределенное число приложений неопределенного качества.

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

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

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

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

«Скатимся» — это потому что сейчас я например с использованием всяких «синтаксических сахаров» пишу UI приложение с нормальным UI на асинхронных операциях, с многопоточностью и кучей других плюшек за условно день, а если это убрать то писать я его буду условную неделю — оно мне надо, спрашивается? И работодателю моему не надо, и заказчику тоже не надо.
Вред очевиден, лишняя сущность, лишнее слово, лишние правила работы особого итератора. Есть понятие цикла с постусловием, с предусловием, безусловного, а тут нам подсовывают какой-то foreach с мутной семантикой. Для foreach достаточно библиотечного уровня. В языке — не нужен.
А зачем циклы с предусловием/постусловием? Это лишняя сущность, лишнее слово, лишние правила. Есть понятие goto и есть if, а тут нам подсовывают какие-то циклы с мутной семантикой.
Дейкстра установил переход к таким конструкциям как качественный переход, если по-колхозному, циклы до, после и внутри себя оставляют инварианты, на которые опирается структура программы, а foreach это что? Какая за ним качественная характеристика?
Так а зачем ключевое слово то? Циклы хорошо, делайте их goto и if. А то foreach же тоже цикл по сути, и ему ключевое слово нельзя, а for'у можно.
Вы же не знаете внутреннего устройства foreach, поэтому остаётся лишь гадать, что это — цикл по сути или что-то ещё.
Вообще то знаю.
Про аргументы бизнеса я упоминал в статье, их вес в рассуждениях еще нужно обосновать. Метод суслика, да-да.
Аргументы бизнеса просты и понятны. Сэкономленные деньги/время. Аргументы «уберите сущность которую я считаю лишней» — не понятны, т.к. никакой пользы из них не видно.
Работа ума уровня простейших, как поменьше потратить энергии и побольше впитать бульона и соседей. Бзнс.
А спутники падают.
Спутники падают из за ошибок, а ошибки делают люди и делают они их в любом языке.
Можно двигаться по пути минимизации ошибок. Человеческий фактор можно ослабить.
Удаление отлаженных и хорошо работающих конструкций из языка приведет к тому что люди будут писать их «от руки» и соответственно к увеличению ошибок. Так что да — надо двигаться по пути уменьшения ошибок перекладывая на компьютер и хорошо отлаженные библиотеки/компиляторы максимальное количество забот и ослабляя человеческий фактор.
Вообще, аргумент про «скатимся в ассемблер» пригоден, чтобы выставить оппонента недалеким фанатом, который и не заметит, как выкинул из языка вообще все. Зачем такой аргумент нужен в беседе культурных людей не очень понятно.
Вы на вопрос не ответли. Generic'и нужно выкидывать?
НЛО прилетело и опубликовало эту надпись здесь
И классы выкинуть надо, а то что за дела, лишних сущностей повводили, даже goto теперь никто не использует. Не порядок.
В обероне классов нет, а ООП есть. Чудеса, да и только :)
Их не нужно было вводить, теперь уже не выкинешь, такие правила игры.
Ну так бы сразу и сказали, сразу ответили на все вопросы. Только вот подозреваю что людей пользующих например async/await раз в неделю в C# (уж не говоря о Templates в C++, например) больше чем людей которые вообще слышали про оберон. Почему? Потому что есть языки которые все критикуют и есть языки которыми никто не пользуется.
Выбора у них нет, не забывайте. Никому не достался мир с нуля, приходится работать с тем, что есть, ведь принуждение голодом это сильный мотиватор. Это не повод не думать про правильное. Но, видимо, не все согласны.
Ахаха. Ваш любимый язык не используют не потому что он ни на что не годится, а потому что мировой заговор заставляет людей писать на C++/C#/Java/etc. Наверное где-то есть карательные отряды которые сажают приверженцов оберона в психушку? Как же иначе объяснить что у него нету последователей, ведь не может же это быть потому что концепция не верна, верно?
Дискуссия вырождается, судя по всему. Но покуда оберон вызывает такие эмоциональные выплески у сторонников майнстрима, имеет смысл обсуждать оберон и дальше.
Кхм, простите, причём тут мировой заговор? Вам же написали, что никто не начинает с нуля. Банальная логика не даёт связи между первоначальным заделом и каким-то сговором.
НЛО прилетело и опубликовало эту надпись здесь
Компилить очень быстро, потому что сделано просто и понятно. Так что нет, не выкинем.
НЛО прилетело и опубликовало эту надпись здесь
Боюсь спросить, а Вы его видели?
Система Оберон была написана за три года двумя частично занятыми людьми:

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

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

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

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

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

Никлаус Вирт, Юрг Гуткнехт. «Разработка операционной системы и компилятора. Проект Оберон»
А будет еще быстрее. И запоминать меньше ключевых слов придется!
Я думаю вообще нужно писать для машины Поста. 6 команд и чиселки, вам должно понравится!
Мы благодарны за ваш отклик. Ваше мнение очень важно для нашего сообщества.
В Оксфорде преподают студентам именно Оберон. Видимо, там чего-то не знают, чего знаете вы.
А первый язык у них Haskell, вообще-то :)
Оберон там преподают ровно по той же причине, по которой у нас в школах и на первых курсах в большинстве университетов Паскаль и Delphi преподают.
Эх, а уж сколько ПО было создано на Delphi в свое время, еще на борландовской семерке :)
Вы знаете, там в Оксфорде, Оберон преподают вторым языком. А первым у них Хаскель :)
P.S. да, сказали уже :)

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

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

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

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

Как там вы сказали, «полтора человека»? Борланд заказывала виртуальную джава-машину оберонщикам, которые делали её с помощью обидного для вас ЯП. Но зачем про это знать российскому программисту, верно?
.
Оскорбляет? Нет конечно, меня вообще тяжело оскорбить. Скорее я бы сказал меня это забавляет. А язык конечно примитивный, синтаксис уровня 90-х — начала 2000х, но никак не уровня 2015 года.
Борланд заказывала виртуальную джава-машину оберонщикам
Это как раз подтверждает мое высказывание про 1.5 человека. Где сейчас борланд? И где сейчас оберон? Посмотрите количество вакансий по оберону, ну или количество конференций где о нем говорят. Теперь сравните с Java/C#/C++. Вероятно вам потребуется точность double чтобы выразить отношение.
Вы хотите сказать, что столько мух одновременно ошибаться не могут?
Вы же понимаете что этот аргумент бессмысленный так как неопровержим. Его можно применить к чему угодно и сказать что лучше жить в пещерах и забросить науку но «миллионы мух же не могут ошибаться».
Я пока не увидел ни одного аргумента почему оберон лучше чем любой из TOP 5 языков. Писать кода на нем больше надо, ошибку допустить легче, высокоуровневых примитивов нету — так чем он лучше то? Тем что его проще выучить? Так инструкции к машине Поста еще проще выучить, ну или brainfuck — тоже просто понять. Только вот писать на нах не просто.

Я вот замечательно вижу как async/await экономит мне полотна кода и уровни вложенности и код получается компактный и простой. Так же вижу как мне аналогичным образом помогают встроенынные в язык итераторы, не говоря уже о Generic'ах, которые экономят тонну времени и предостерегают от кучи потенциальных ошибок. А тут пре предлагают отказаться от всего этого и ничего в замен не предлагают.
Он не «лучше», он другой. Стоит с другой стороны. Не там, где вы привыкли.
Для mainstream он хуже, я уже объяснил почему. А что дает взамен? Если взамен он дает только то что он «другой» — то он точно никому не нужен.
Ваши объяснения не имеют под собой веских оснований, поэтому мы их можем смело опустить. Масса людей легко делают выводы о вещах, в которых они не разбираются, но думают, что разбираются.

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

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

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

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

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

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

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

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

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

Детский сад.

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

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

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

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

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

Ну и ваше мнение меня не сильно интересует. Меняете вы его или нет — мне до лампочки.
У нас просто разные представления о полезности, вы считаете что умнее всех и знаете лучше куда двигаться индустрии, ок.
Я же говорю, вы плохо представляете себе ситуацию и совсем не знаете истории ИТ :)
Как и весь рынок, да? Вы в меньшинстве, если что.
Я понял, рынок не прав, вы правы, весь мир в заговоре и делает сложные ненужные вещи, производители антивирусов пишут вирусы, а производители лекарств делают людей больными. А как же иначе, им же надо деньги зарабатывать одурачивая всех.
Я смотрю, Вы наслаждаетесь собой, раз за разом повторяя, как сильно превзошли несчастный Оберон лично Вы и рынок, который думает за вас в вашей голове.
Да нет, я просто указываю на очевидные ошибки и провалы в концепции, язык без развития (концепция которого отвергает развитие фич) — обречен изначально на провал.
Everything should be made as simple as possible, but no simpler.

А про 10% рынка можно посмотреть на количество минусов к положительным комментариям про Оберон. Рынок не хочет Оберон, и силами многих тел демонстрирует этот факт.
Вот именно, оберон в этом случае way too much simpler.
Ваша гипотеза не верифицируема.
Так же как и ваша, это в любом случае субъективно, до тех пор пока нет критерия «прост но не проще чем надо», а когда такие критерии появятся то и фраза самыл потеряет.
Но только вот мое утверждение разделяет рынок, и есть объективные факторы типа сложности кода, по которым оберон проигрывает.
Да, Вы всегда правы.
Небольшая справка: сам движок Unity3d написан на C++. C#/UnityScript — это скрипты. Они вызываются из C++ кода.
Тут ниже ответили что C++ тоже, цитирую: «движется в мусорку», так что этим людям без разницы, полагаю. Язык почти за 20 лет не смог отвоевать хоть сколько значительную часть рынка, когда более молодые (но «неправильные», как утверждают тут оберонщики) языки это сделать успели. О чем еще говорить…
A говорит нужно о вашей компетентности: все языки рождаются, используются и умирают, вы, приведя список диалектов разных языков, попросили указать их направление, если сами компании стоящие за ними не в курсе, хабр должен включить свой отдел «телепататов и машину времени»? К вашему сведению те языки развиваются компаниями и это единственная причина того что они еще не загнулись, а не список фич. А приведя список диалектов, языков, которые сами имею длинную вереницу неудач… «C» очень долго не мог завоевать рынок ( занятый :) фортраном, коболом и паскалем, аду сделали паскатеподобной из-за того, что на рынке было больше паскальщиков, чем сишников ) «С++98» долго переносился пока не вышел, и потом еще долго в полном обьеме не поддерживался, да и дальше, диалектов было больше стандартов. Если Вы думаете, что до сих пор все еще пользуются всеми теми диалектами, то у меня для вас грустная новость: все языки умирают. Да и с диезами, все туманно — его отдали OSS — очень грозный знак, если МС не будет за ними, то его конец будет быстрее чем обычно. Ява — где новая машина, будет ли девятка, когда?!
Первый оберон был выпущен почти 30 лет назад, ровестник C++, последний оберон был выпущен почти 20 лет назад, раньше чем C#, ровестник Java. Только вот до сих пор рынок он не завоевал. Так что в вашей фразе «языки рождаются, используются и умирают» я полагаю оберон находится на последней стадии, поиспользоваться он так и не успел, как многие другие он только родился и умер. С++ — как развитие C, а первая версия C появилась 43 года назад, популярность росла и даже сейчас многие проекты (например curiosity, раз вы любите космос) написан на C, и никуда уходить язык не собирается в ближайшее время.
О вашей компетентности говорит желание оживить труп, который был закопан рынком.
Кроме того языки рождаются, используются и умирают, и отдают свое место новым языкам в которых еще больше возможностей, новые концепции и фичи, упрощающие написание кода и экономящие время, дегенерации в сторону отброса всех фич замечено небыло.
Я где-то упоминал об желании оживить труп оберона? Нет, я среагировал на целую ветку несусветного бреда. В конце которого Вы заявили, что фичи могут сделать язык популярным, оставалось только уточнить список, и покинутого — воскресить ;))) кста забить язык фичами не самое сложное у оберона есть заброшенная ветка оберон -> c (ОО). Только никто этим пользоваться не будет, пока за спиной проекта не появятся деньги.
Фич ?! Серьезно, а я думал, глупый, что надежность компилятора, проработанность библиотеки, эффективная среда — залог эффективного программирования!!! О, позор на мою лысую голову! (не, вы серьезно считаете, что проблема в фичах, а не в том, что фичами прикрывают непрерывный бета-тест-режим компилятора и ОС?)
Сколько бы денег не вкладывали в язык, у которого нету современных фич — популярным он не станет, максимум могут сделать вендор лок-ин и люди будут писать под конкретный девайс на языке, если этот девайс как-то зафорсируют в продажах. Фичи это безусловно не единственное, но в данном контексте сравнивая язык с фичами и обкоцаный но типа «простой» язык победит первый.
Большинство фич Диезы/Явы из хаскеля, и эйфиль, теперь прикручивают. Как-то прородителям не сильно помогло их фичастое/университетское прошлое.
Вы читаете перед тем как отвечать? Я написал что фичи — это необходимое, до определенной степени, условие, но не достаточное.
Вы снова нарываетесь на вопрос, что же САМОЕ достаточное?
А что такое «самое достаточное»? Достаточное оно и есть достаточное, но я не могу привести конкретное «достаточное», мы вроде говорим о необходимом.
Нет, Вы, пока, поминали только разную мишуру, хотя на дворе не-праздник. Список, Сестра!
Ок, мишура так мишура, рынок дурак, а люди не понимают своего счастья, каждый день пользуясь «мишурой», ассемблероберон вам в руки.
Это было к фразе
Да, расскажите про неумение использовать инструменты создателям Unity3d, например.
, которая следовала в ответ на Ваш коммент про GC, который следовал в ответ на коммент про регулярные креши решений на C++ в доме, который построил Джек.

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

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

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

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

Когда Java строится на заведомо устаревшей технологии P-кода, только потому, что Гослинг ничего кроме неё не знал, то это не значит, что Java завоевала рынок благодаря своей успешности. После P-кода были более совершенные решения, но вы про них не знаете, потому что миллионы денег были вложены в рекламу Java.
Сложность синтаксиса — это та вещь, которую освоил 1 раз. А вот если синтаксис примитивен — то приходится отсутствие этой «сложности синтаксиса» компенсировать более сложными конструкциями в коде, которые у всех разные, отсюда больше ошибок и больше затрат на разработку и поддержку.
Например, в smalltalk if — это не специальная синтакическая конструкция, а метод объекта Boolean. Он уже готовый стандартный, но тем не менее не является частью синтаксиса.
Условные переходы и циклы в 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 лет, очень жаль, что он не очень популярен.
Совершенно верно. Unity3d ещё и JS-скрипты поддерживает (хотя для использования делегатов, приходится на С# переключаться, хе-хе), но это в XXI веке не даёт объяснения, почему после загрузки террайна среда не может выйти без крэша. 20 лет назад это было объяснимо, 10 лет назад это считалось позором, ну а сейчас это просто диагноз.
Существует ли аналог Unity3d, написанный на Оберон? С удовольствием попробую.
Unity3d развивается вот уже 10 лет, в него вложены миллионы долларов, это серьёзная платформа. Вложите миллионы долларов в аналог Unity3d на Обероне и будет вам другая серьёзная платформа. Кроме шуток. Ядро на Обероне, скриптование на Обероне, расширяемость, быстродействие и надёжность гарантируются.
Ну вот, читаем Википедию:
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.

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

Так что вот взяли бы и начали писать движок на Обероне. Получили бы минимальный рабочий результат, чтобы можно было показать инвесторам. Нашли бы грамотного продажника в команду, который умеет работать с инвесторами. И так далее. А не ныть тут про «нужно вложить миллионы». Если оно того стоит — миллионы вложат. Это бизнес. Иначе Вам дорога в политику, там деньги по другим принципам распределяют.
А вот они взяли и сделали Unity3d.
А что они при этом кушали?
Я думаю, у них на тот момент имелись достаточные средства для старта бизнеса. Иначе бы бизнеса и не было. Уж как минимум себе на еду они точно должны были иметь деньги.
Интересно, что первая версия Unity использовала физический симулятор NovodeX (позже известный как PhysX), а этот самый NovodeX раскручивался с 2000 года в Швейцарии, на базе ETH Zurich: www.inf.ethz.ch/department/spin-offs.html

Интересно посмотреть, с чего швейцарцы начинали свой спинофф, см. 1993 год :)
Насколько я понял Вашу ссылку, ETH Zurich — это университет, который так или иначе помогал начинать бизнес разным компаниям по спин-офф модели, в том числе Oberon microsystems AG в 93-м и NovodeX AG в 2000-м. Так что Unity к Оберону никакого отношения не имеет.
Я и не говорил, что Unity имеет отношение к Оберону.
Сделать «ещё один» Unity? Это глупо, ведь уже есть один такой. Если не нравится юнити — берите UE. И куча других движков. Это же бизнес, в закрытую дверь ломятся только дураки.
UE не на Обероне!
Теперь, что оберон-методология даёт взамен. Избавление от ошибок на самом старте — это очень и очень дорогая вещь.

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

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

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

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

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

Странно, что оберонщики, как профессионалы в борьбе со сложностью, не хотят тут сорвать денег. Ощущение, что боятся выходить из своей башни из слоновой кости, где они пилят АЭС для спутников, и запачкать руки о реальный мир, где рулят всякие php и java.
Вы же не взяли Оберон для решения задач. Вы вообще его не знаете. Как контрибутор в Оберон вы ноль. И таких овер 99%. О чем тут вообще рассуждать? О том, что несколько человек не решили столько задач, сколько решил полумиллион рыночных джавистов и пхпистов и поэтому они лохисидят в башне? Свои задачи мы решили, раз до сих пор с голоду не умерли.
Я не против попробовать. Посоветуйте какой-нибудь мануал по настройке среды и любой туториал по основам создания веб-приложений в обероне.
Клиент-сайд или сервер-сайд?
Серверная часть

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

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

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

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

Ну и гугл в помощь.
Спасибо, посмотрел. Первое, что вспомнилось — 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;


Ну, а «web-фрейворк» — это махровый cgi, видали такие во времена первых сайтов на перле и c++
После знакомства с современными средствами без умиления на это не взглянешь, сколько нужно кода для простой страницы.
Если вам предложат попрограммировать на Обероне, вы скажете «Фи. А где тут бесплатная инфраструктура, которую построила большая западная компания за сто миллионов денег?».
Ваша последняя цитата похожа на развод на «слабó».
Не, я могу пописать на 6502 с тремя регистрами и 2kb RAM, но результат удивит лишь гиков, остальные не впечатлятся от получившегося продукта. Какой-либо причины браться за оберон, помимо ностальгии, я не нашёл.

Кстати, в дефолтной настройке дефолтная IDE BlackBox даже не делает auto-indent (и неизвестно, умеет ли). Поэтому смелое заявление "операторные скобки сейчас расставляет IDE" (не говоря о раскраске синтаксиса) это из разряда мечтаний.
Ваши намерения были ясны с самого начала ветки. Это я так, накидал вам ссылок, чтобы подтвердить свою гипотезу.
Это напоминает о старом Бейсике, в котором можно было массив задать списком при помощи оператора DATA, а потом одним оператором считать его в массив.
Ваш вопрос не имеет смысла. Веб — это вообще-то HTTP + HTML «по определению». Клиент-сайд — это браузер + javascript. Оберону тут делать просто нечего. Разумеется, речь шла о сервер-сайде.
Почитайте про Dart хотя бы.
Есть же трансляторы оберона в js :)