Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 467
Но ведь операторные скобки сейчас расставляет IDE. А например в вашей статье про Brainfuck VM длинные квалификаторы, длиннее, чем слово BEGIN, но вы не стали их сокращать.
С моей точки зрения эстетически приятнее когда код плотный, аккуратно разбит на иерархические блоки.
С этой точки зрения код на Обероне мне приятнее, чем разреженный код на Java, где пустого места на единицу площади иногда больше, чем кода.
Но это все вкусовщина, конечно.
С этой точки зрения код на Обероне мне приятнее, чем разреженный код на Java, где пустого места на единицу площади иногда больше, чем кода.
Пример
Но это все вкусовщина, конечно.
Если добавить комментарии и пустые строки, то любой текст станет разряженным :)
А так пишите хоть без пробелов, джаве то все равно
А так пишите хоть без пробелов, джаве то все равно
Стайл-гайдам не все равно, они советуют писать именно так. Разделять пустотой объявления и действия, переносить скобку после объявления на новую строку. И так далее.
Конечно, и благодаря этому вы получаете более высокую читаемость кода. Но в реальном коде не будет «пустого места на единицу площади иногда больше, чем кода», не надо перегибать палку.
Напомню, речь изначально шла о том, что в Обероне, например, не нужно пустое пространство для разделения, так как эту роль выполняют ключевые слова (которые не нравятся многим), которые выглядят особенно. «Глаз цепляется», знаете такое выражение?
Это есть такая эпичная тема на rsdn: Синтаксический оверхед Про нее даже на Лурке написано…
Я помню, что при изучении Си я имел такой стиль (кстати, вполне культурный K&R), что при просмотре экзерсиза на Паскале я долго плавал взглядом по экрану ища и собирая смысл в кучу. Было такое ощущение, что смысл есть, но он распылён по всей площади экрана с добавлением гигантских лакун.
Это необычное ощущение, когда один и тот же простенький численный метод на Си умещается в фокусе глаза, а на Паскале требует этими глазами дико вращать (и скроллиться к тому же).
Но, я тут же вспомнил, что когда ранее изучал Паскаль, я имел противоположное ощущение — код казался логичным и ясным, в то время как на Си текст того же алгоритма коллапсировал почти в точку и обязательно требовал лупу.
После этого я решил, что вопрос колебания плотности информации на экране (в известных пределах. Я не говорю про Ифкуиль) — это вопрос мимолётной привычки, и полагается смотреть в языке совсем на другое.
Это необычное ощущение, когда один и тот же простенький численный метод на Си умещается в фокусе глаза, а на Паскале требует этими глазами дико вращать (и скроллиться к тому же).
Но, я тут же вспомнил, что когда ранее изучал Паскаль, я имел противоположное ощущение — код казался логичным и ясным, в то время как на Си текст того же алгоритма коллапсировал почти в точку и обязательно требовал лупу.
После этого я решил, что вопрос колебания плотности информации на экране (в известных пределах. Я не говорю про Ифкуиль) — это вопрос мимолётной привычки, и полагается смотреть в языке совсем на другое.
Пустые строки, да еще и лишние (т.к. очевидные) комментарии.
Скриншот кода на Обероне вызывает неконтролируемое минусоизвержение.
Неконтролируемое минусоизвержение вызывается «сравнением» несравнимого. Вы бы хоть одинаковый алгоритм привели — а то ведь сравниваете достаточно сложный алгоритм на Обероне с заготовкой кода на Java, которая пока что вообще ничего не делает!
Размер шрифта почти тот же, площадь картинки одинаковая. Ну и контраргументация минусами она да, работает. Еще по морде можно дать. Мыжпрограммисты.
Так говнокод же. IF ch = 10X THEN INC(ref, 4) END;
Почему 10? Что такое 4?
pos еще ясно что такое, а что такое переменные ad и d?
Что за магические значения 0FDX?
Об этот код любой ногу сломит, а если его переписать в читаемый вид, он тоже больше места займет. На Java (не поверите) тоже можно говнокодить и записать все в одну строчку.
А так — почитайте Макконнелла «Совершенный Код», там хорошо объяснено почему писать так как на скриншоте — зло.
Почему 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) Дело во вкусах.
2) В Обероне это удобно.
3) Дело во вкусах.
Почему в Обероне становится удобным то, что неудобно во всех остальных языках?
Намного ли удобнее увидеть присваивание значения переменной, которое находится в середине строки между других операций? Не это ли есть снижение читаемости кода? Почему в Обероне это удобно?
Длинное выражение между THEN и END каким-то образом избежит возникновения горизонтальной полосы прокрутки? Или Вы разобьете его на две строки, сделав чтение кода еще менее удобным?
Если есть преимущества у написания кода в строку (включая те особенные для Оберона, о которых Вы говорите), которые могут компенсировать потерю читаемости и удобства редактирования кода — расскажите о них, иначе ваши слова о вкусах совершенно пусты.
Намного ли удобнее увидеть присваивание значения переменной, которое находится в середине строки между других операций? Не это ли есть снижение читаемости кода? Почему в Обероне это удобно?
Длинное выражение между THEN и END каким-то образом избежит возникновения горизонтальной полосы прокрутки? Или Вы разобьете его на две строки, сделав чтение кода еще менее удобным?
Если есть преимущества у написания кода в строку (включая те особенные для Оберона, о которых Вы говорите), которые могут компенсировать потерю читаемости и удобства редактирования кода — расскажите о них, иначе ваши слова о вкусах совершенно пусты.
Вы говорите «неудобно». Я говорю «удобно». Вы не верите мне, а я вам. Вы исходите из своих вкусов, я из своих. Непонятно, с чего сыр-бор? Почему вам станет удобно, если было неудобно? Я не знаю. А вы в чем удобство измеряете? В сантиметрах? Удобно это сколько? 13 cм? Или 26 см?
Добавлю остроты — ещё удобнее читать компактный пропорциональный шрифт, а моноширинный зря расходует пространство экрана. И это не троллинг, а личный опыт. Я раньше программировал с моноширинным с синтаксической подсветкой, но постепенно перешёл на пропорциональный с архитектурной подсветкой. Патриотичный PT Sans прекрасно подходит для кодирования.
Моноширинный используют потому что отступы строго прогнозируемые, а в пропорциональном — как повезет, выравнивать код «столбцами» очень трудно в текстовом редакторе.
Почувствовал огромное облегчение, когда перестал заниматься подобным.
Теперь мои исходники выглядят примерно так:
Почему-то картинка не видна
hsto.org/files/2ad/e5f/bfe/2ade5fbfe2a4482baf0b01a9aa784612.png
Теперь мои исходники выглядят примерно так:
Почему-то картинка не видна
hsto.org/files/2ad/e5f/bfe/2ade5fbfe2a4482baf0b01a9aa784612.png
о черт. сломал глаза. Но и правда, отступами в таком коде и не светит, поэтому пофиг какой шрифт использовать.
Теги пропадают в коментариях когда карма ниже нуля.
Теги пропадают в коментариях когда карма ниже нуля.
Почему же не светит. Табуляция наш друг. Плюс в текст (это составной документ, да, а не примитивный plain text) вставляются форматирующие линейки. А шрифты я перепробовал самые разные.
Так что меня всегда веселят комментарии в стиле «сломал глаза», ведь у меня реальный опыт, против сугубо теоретических рассуждений )
Так что меня всегда веселят комментарии в стиле «сломал глаза», ведь у меня реальный опыт, против сугубо теоретических рассуждений )
А меня веселят слова «ведь у меня реальный опыт».
У вас не реальный опыт, а сугубо личный опыт в конкретных условиях с ограниченным количеством сред. Его нельзя наложить на все условия и сказать что так будет правильно для всех, всегда и везде.
Ибо у меня тоже реальный опыт.
И у кого-то еще тоже реальный опыт…
У вас не реальный опыт, а сугубо личный опыт в конкретных условиях с ограниченным количеством сред. Его нельзя наложить на все условия и сказать что так будет правильно для всех, всегда и везде.
Ибо у меня тоже реальный опыт.
И у кого-то еще тоже реальный опыт…
о черт. сломал глаза.Покритикуй Оберон со строчной буквы в начале предложения — получи +2.
Проклятый Оберон, пропади, пропади с экрана. Не могу его больше видеть.
Я даже и не думал привязывать ощущение к какому-либо языку программирования, рассмотрел этот кусок кода просто как текст. И уже на этом этапе возникли проблемы.
Привыкнув к такому стилю оформления текста программы он может и будет выглядеть красиво, но… первое впечатление незнакомого с данным стилем — отрицательное. А значит не имеет продолжения(с чего бы вдруг жевать кактус?).
Привыкнув к такому стилю оформления текста программы он может и будет выглядеть красиво, но… первое впечатление незнакомого с данным стилем — отрицательное. А значит не имеет продолжения(с чего бы вдруг жевать кактус?).
st = v.t.ThisSetter();?
И эти люди говорят мне о методологии написания хорошего кода?
И эти люди говорят мне о методологии написания хорошего кода?
Да, да, расскажите нам, что { читается легче, и выделяет блок лучше, чем begin.
Замечу, что ваш пример — спорный, потому что в норме слова-границы блока стоят на отдельных строках. Т.е. тот, кто пишет в виде begin abc def ghi end (ваш пример) — сам себе злобный буратино. Если уж сравнивать, то
и
Вообще, это такая вкусовщина…
Замечу, что ваш пример — спорный, потому что в норме слова-границы блока стоят на отдельных строках. Т.е. тот, кто пишет в виде 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
Не надо парсить слова, достаточно быстро уловить начертания символов.
Отсутствие отступов не подтасовка если отступы управляются человеком. Человек может ошибиться.
if (x > y) {
BECIN;
EMD
}
Читается проще чем
IF (x>y)
BEGIN
BECIN
EMD
END
Не надо парсить слова, достаточно быстро уловить начертания символов.
Отсутствие отступов не подтасовка если отступы управляются человеком. Человек может ошибиться.
Отсутствие отступов не подтасовка если отступы управляются человеком. Человек может ошибиться.
Извините за грубость, но без отступов это просто г-нокод. Мешанина, которую нереально разобрать — тут и подсветка не поможет.
Плюс в вашем примере (если говорить не о «полнотекстовых» языках вообще, а именно о паскале и его производных), отличие в ";" в случае оператора. Плюс в этих язык традиционен camelcase. Сравните, например:
if x > y then
begin
Becin;
Emd();
end;
Прочесть все же легче.
Я имел ввиду, что человек читает отступы, а компилятор — скобки. Если их можно рассинхронизировать, то приходится читать скобки отдельно от отступов — не доверять отступам.
Лучше всего когда скобок вообще нет, а есть только оступы — нечему рассогласовываться. Но если они все-таки есть, то лучше что их было труднее спутать с остальными словами.
Лучше всего когда скобок вообще нет, а есть только оступы — нечему рассогласовываться. Но если они все-таки есть, то лучше что их было труднее спутать с остальными словами.
А можно ещё
IF x > y THEN
Becin;
Emd()
END;
IF x > y THEN
Becin;
Emd()
END;
Вообще в программировании ценится не скорость считывания программы с экрана…
Зато автоматическое выравнивание никогда не ошибается.
Я бы вообще представлял программы в 3-х мерном виде(активный уровень на переднем плане) в виде дерева. там никакие скобки не нужны были бы. Всякие эти скобочки, выравнивание — оно нужно только для возможности редактирования текста программы в простых плоских редакторах. Если создать такой софт, где программа редактировалась бы на объектном уровне — все эти заморочки с отступами и скобками просто не нужны были бы.
Зато автоматическое выравнивание никогда не ошибается.
Я бы вообще представлял программы в 3-х мерном виде(активный уровень на переднем плане) в виде дерева. там никакие скобки не нужны были бы. Всякие эти скобочки, выравнивание — оно нужно только для возможности редактирования текста программы в простых плоских редакторах. Если создать такой софт, где программа редактировалась бы на объектном уровне — все эти заморочки с отступами и скобками просто не нужны были бы.
Движение в эту сторону есть, как мне кажется cyberleninka.ru/article/n/razrabotka-mnogoyazykovogo-redaktora-na-osnove-semanticheskoy-modeli-programmy.pdf
При этом, что интересно, оберон взят за один из базовых представлений.
При этом, что интересно, оберон взят за один из базовых представлений.
Вот тут вы и показали основную проблему Паскаля. Писал на нем 5 лет — но за все это время так и не смог подобрать правильного способа написания конструкции «end else begin», которая бы нормально читалась хотя бы мною же :)
Паскаль давно устарел, есть же Оберон.
Такая конструкция и в си ужасно выглядит — как разбазаривание пространства в духе
}
else
{
}
else
{
Скобки и else хотя бы разного размера — сразу видно что где. И редактор их зачастую разным цветом подсвечивает, что тоже помогает.
У нас приняли такие правила:
1)
if <condition> then op1 else op2;
2)
if <condition> then begin op1; op2; end else begin op3; op4; end;
if <condition> then op1;
Как вариант — begin op1; op2; end else begin end
Главное — размещать все на отдельных строках, тогда ключевые слова не сливаются в кашу, даже когда идет подряд end else begin они не сливаются. Если выделять блоки begin end дополнительным отступом, разница между блоком и else еще виднее.
Плюс никогда не ставить ничего на той же строке, что и if.
Друзья, только у меня поломаны блоки — source и block quote?
1)
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?
Вы имеете в виду вот так?
Да, я тоже в итоге пришел к такому. Но сколько же места на экране оно занимает… Особенно при 50 строках на экране. Надеюсь, хотя бы последняя проблема сегодня перестала быть актуальной у большинства паскальщиков!
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), и что-то такое же текстоворежимное для С++.
Только вот регламент был еще старый, и Delphi в списке разрешенных сред разработки не было. Только Free Pascal (или даже Turbo Pascal), и что-то такое же текстоворежимное для С++.
Надо еще постараться, чтобы встретить EGA. Последний раз работал с EGA еще до выхода W95.
Да, это почти последний вариант. Но не совсем.
if then
else
остальные части — с отступами. Т.е if и else на одном уровне. Можно и begin..end на том же уровне, но так все же похуже.
Отчего в моем сообщении не работает source тэг… судя по вашему комментарию, он не только у меня не виден.
Пусть занимает сколько угодно, при ООП методы малы. Плюс у нас используется разметка блоков вертикальными линиями.
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;
Шутки за 28.
Потому что как это так, разве можно выкидывать из языка фичи
Фичи можно и нужно выкидывать не только из языков программирования, а вообще из всего. Если они затратны в реализации и мало полезны на практике.
Взять сетевые протоколы. Взять тот же IPv4. Хорошая, вроде бы, идея — реализовать фрагментацию пакетов. Но опыт работы интернета показал, что фрагментация — зло, она или не реализована у некоторых абонентов, или реализована криво (и это создает уязвимости), или реализована хорошо, но с огромными затратами ресурсов (память, процессор). А теперь, если вернуться к исходному положению и еще раз подумать, нужна ли вообще эта фрагментация, если она дается такой ценой? И люди пришли к твердому «нет»: не нужна. И в IPv6 ее выкинули (хотя, к сожалению, не до конца).
И так во всем. Overengineering — бич современного мира технологий. Но люди учатся на ошибках, приходят к пониманию того, что лучше сделать проще. Технологии становятся проще, и за счет этого совершеннее, там, где это возможно. По-видимому языки программирования — это то направление, которое находится далеко не в конце своего развития. Отсюда и недостатки многих существующих языков. Трудно найти тот минимально необходимый набор возможностей языка, который имел бы приемлемую цену в реализации и давал при этом большую пользу в облегчении программирования. Но люди трудятся над этой задачей. Тут нужны годы опыта всего сообщества. Когда-нибудь найдутся лучшие решения.
А у меня есть подозрение, что Overengineering как-то связан с нехваткой полноценных языковых фич и с неполнотой/несовершенством стандартных библиотек. Люди, закладывая универсальность в свои программы, раз за разом пишут по сути некие околобиблиотечные/околофреймворковые вещи, которые по уму должны быть как-то реализованы стандартно, чтобы их не писать, а просто брать и пользоваться… Надо будет подумать над этим.
По теореме Гёделя о неполноте, для любого языка программирования всё равно будут встречаться задачи, неописуемые этим языком. Поэтому языки и развиваются ;-)
Хорошо в математике: если есть формула — значит задача формализована и без потерь может быть переведена на любой язык, буде это Фортран или юридический контракт на португальском.
Это вам не бухгалтер, который неописует свои собственные задачи, которые мы обязаны закодировать.
Хорошо в математике: если есть формула — значит задача формализована и без потерь может быть переведена на любой язык, буде это Фортран или юридический контракт на португальском.
Это вам не бухгалтер, который неописует свои собственные задачи, которые мы обязаны закодировать.
Глава «Новый выстрел „Серебряной пули нет“» Брукса из его Мифический-человека месяц начинается с гениальной цитаты Александра Поупа:
Кто хочет увидеть образец совершенства,
Тот мечтает о том, чего никогда не было, нет и не будет.
compact-programming.narod.ru/Index.htm
В одном флаконе, и зачем так гневаться, ну не осталось инженеров в IT, значит так и надо.
В одном флаконе, и зачем так гневаться, ну не осталось инженеров в IT, значит так и надо.
Я наблюдал развитие средств разработки последние два десятка лет. И меня не покидает смутное сомнение. Средства разработки становятся «как бы проще»: не надо выделять память и потом следить за её освобождением, не надо думать, на что указывает указатель, не надо даже скобки расставлять… Но вот объём знаний, который должен иметь разработчик, чтобы сделать действительно серьёзный продукт, от этого нисколько не уменьшается. И даже наоборот, растёт чуть ли не по экспоненте. Каждая среда разработки, каждый фреймворк вносят свои абстракции, и на первый взгляд всё работает. Но наступает момент, когда абстракция начинает трещать по всем швам. И тогда приходится лезть в глубины того же фреймворка и смотреть, что у него не так с той же памятью, с теми же указателями…
Т.е. простота и удобство инструментария не отменяет знаний глубин взаимодействия софта и железа.
И по мере того, как эта истина проявлялась, возникал вопрос: почему? Моё ощущение, что разработчики сред разработки в определённый момент начали гонку за студентами и топ-менеджерами, приучая их именно к своему детищу. Когда я был студентом, были популярны C++ и Delphi. Потом стала набирать популярность Java, потом появился C#. Как бизнес набросился на RAD-разработку! Это же целый прорыв: за мизерные деньги можно было сделать свой http-сервер! И как потом бизнес-сообщество приняло .NET!..
Семя упало в плодородную почву, «простые» фреймворки заполонили головы молодёжи и топ-менеджеров. И теперь программисты должны учить не только выполнение машинного кода ядром процессора и распределение байтов в регистрах памяти, но и уйму информации о функциях используемых ими библиотек, а потом ещё и оправдываться за то, что эти библиотеки не работают так, как хотелось бы бизнесу… Как говорил Стив Балмер, «у нас не монополия, у нас рынок, а это не одно и то же».
Конечно, это не умаляет достоинства инструментов. Но в целом легче программистам от этого не стало, только трудозатраты перераспределились в сторону «непроизводительной» деятельности по саморазвитию программистов, за которую бизнес теперь не платит.
Т.е. простота и удобство инструментария не отменяет знаний глубин взаимодействия софта и железа.
И по мере того, как эта истина проявлялась, возникал вопрос: почему? Моё ощущение, что разработчики сред разработки в определённый момент начали гонку за студентами и топ-менеджерами, приучая их именно к своему детищу. Когда я был студентом, были популярны C++ и Delphi. Потом стала набирать популярность Java, потом появился C#. Как бизнес набросился на RAD-разработку! Это же целый прорыв: за мизерные деньги можно было сделать свой http-сервер! И как потом бизнес-сообщество приняло .NET!..
Семя упало в плодородную почву, «простые» фреймворки заполонили головы молодёжи и топ-менеджеров. И теперь программисты должны учить не только выполнение машинного кода ядром процессора и распределение байтов в регистрах памяти, но и уйму информации о функциях используемых ими библиотек, а потом ещё и оправдываться за то, что эти библиотеки не работают так, как хотелось бы бизнесу… Как говорил Стив Балмер, «у нас не монополия, у нас рынок, а это не одно и то же».
Конечно, это не умаляет достоинства инструментов. Но в целом легче программистам от этого не стало, только трудозатраты перераспределились в сторону «непроизводительной» деятельности по саморазвитию программистов, за которую бизнес теперь не платит.
> Но в целом легче программистам от этого не стало
Мне кажется, что стало. Как-то народ не рвется все переписывать с нуля, а спрашивает друг у друга какой фреймворк или компонент лучше использовать.
Мне кажется, что стало. Как-то народ не рвется все переписывать с нуля, а спрашивает друг у друга какой фреймворк или компонент лучше использовать.
Я не сказал, что продвинутые инструменты — это плохо. Я сказал, что трудозатраты не стали меньше, они перераспределились: вместо того, чтобы возиться с памятью, программист теперь учит, что такое управляемый код, как работает GC и как его приручить, чтобы программа работала оптимально. При этом пониманием того, как выделяется память при работе программы, программист всё равно должен обладать. Т.е. вместо того, чтобы тратить время и силы на поиск уязвимостей в своём коде и учиться писать свой код правильно, программист теперь тратит время и силы на получение кучи дополнительных знаний и навыков, а потом ищет уязвимости и в своём коде, и в коде фреймворка.
Для молодого программиста, работающего в небольшом проекте, выигрыш от использования сторонних решений вполне себе ощутим: он не умеет писать собственный оптимальный код, а используемый фреймворк на его задачах не рушится. Для бизнеса тоже сторонние решения выгодны: можно привлекать менее квалифицированный персонал, можно полагаться на протестированные за чужой счёт решения. Но всё это — тоже абстракция от реальности, и рано или поздно такая абстракция начинает рушиться.
Я знал программистов, которые писали на Delphi, и когда пришёл .NET, они не смогли найти себе хорошее место работы, поскольку не понимали разницы в абстракциях Delphi и C#. И я знаю проекты, которые программисты не смогли в нужный момент перевести с Delphi на C#, из-за чего бизнес их владельцев серьёзно пострадал.
Инструменты и сторонние решения — это хорошо, но с существенными ограничениями.
Для молодого программиста, работающего в небольшом проекте, выигрыш от использования сторонних решений вполне себе ощутим: он не умеет писать собственный оптимальный код, а используемый фреймворк на его задачах не рушится. Для бизнеса тоже сторонние решения выгодны: можно привлекать менее квалифицированный персонал, можно полагаться на протестированные за чужой счёт решения. Но всё это — тоже абстракция от реальности, и рано или поздно такая абстракция начинает рушиться.
Я знал программистов, которые писали на Delphi, и когда пришёл .NET, они не смогли найти себе хорошее место работы, поскольку не понимали разницы в абстракциях Delphi и C#. И я знаю проекты, которые программисты не смогли в нужный момент перевести с Delphi на C#, из-за чего бизнес их владельцев серьёзно пострадал.
Инструменты и сторонние решения — это хорошо, но с существенными ограничениями.
вместо того, чтобы возиться с памятью, программист теперь учит, что такое управляемый код, как работает GC
Как по мне, изучить принцип работы сборщика мусора гораздо проще, чем best practices работы с памятью и методы поиска багов из-за неправильной работы с памятью. Это ж ещё нужно догадаться, что баг именно в ошибке работы с памятью, когда метод одного класса вышел за пределы массива и переписывает данные другого класса, причём с периодичностью 1 раз на 100 запусков. Так что трудозатраты при работе с памятью, имхо, всё же уменьшились.
В итоге все работает по принципу — «не трожь не упадёт». Очень уж много костылей и взаимно компенсирующихся ошибок приходится вводить чтобы всё работало так как задумано. Этого не пришлось бы делать в случае разработки с нуля, без фреймворков и вдумчивым проектированием. Но бизнесу надо здесь и сейчас, ну подумаешь что внутри оно работает благодаря магии и чистой случайности, главное как выглядит снаружи.
Посмотрите на математиков/физиков — практически у каждого свой наработанный и вылизанный до идеала фреймворк с которым они и работают. Ситуации когда у них что-то рушится по причине неправильной работы фреймворка очень редки. А всё от чего — они не спешат сломя голову и у них практически всё формализовано до последнего символа, опечатки чисто по невнимательности при наборе текста.
Посмотрите на математиков/физиков — практически у каждого свой наработанный и вылизанный до идеала фреймворк с которым они и работают. Ситуации когда у них что-то рушится по причине неправильной работы фреймворка очень редки. А всё от чего — они не спешат сломя голову и у них практически всё формализовано до последнего символа, опечатки чисто по невнимательности при наборе текста.
> Но бизнесу надо здесь и сейчас
Соответственно, с их точки зрения использование Фреймворков лучше
Соответственно, с их точки зрения использование Фреймворков лучше
А дыры залатывать это когда нибудь потом, и вообще «вы обещали что оно будет работать — чините бесплатно».
Дыры залатывать, да и сильно потом переделывать как раз потом придется на самописном фреймворке. В код которого широкая общественность не глядела, код которого к best practices никто никогда не приведет. Как раз таки потому что «нужно здесь и сейчас», а потом времени на это не будет, будет другой проект/новая фича
А если взять «общественный» фреймворк, в котором потом появятся новые фичи, то нарастёт несовместимость и ваша codebase протухнет со временем.
Посмотрите на математиков/физиков — практически у каждого свой наработанный и вылизанный до идеала фреймворк с которым они и работают. Ситуации когда у них что-то рушится по причине неправильной работы фреймворка очень редки. А всё от чего — они не спешат сломя голову
Не уверен… Постоянно возникают новые задачи, для которых нужны новые структуры, методы, расширение библиотеки. Часто оказывается, что в давно готовом и работающем классе чего-то не предусмотрели — и нужно либо писать что-то в обход этого места, либо дорабатывать класс. В последнем случае свойство «наработанный и вылизанный до идеала» нарушается. А надо идти вперёд — задача не ждёт, а впереди ещё следующие развития. Для которых пока совершенно неизвестно, какие ещё функции потребуются. По сравнению с R&D то, что здесь пишут про бизнес — идеал качества и продуманности.
Программы написанные физиками/математиками настолько вылизаны до идеала, так что они не публикуют их в приложении к статьям. Ибо им просто банально стыдно, за написанный код.
Нет, им не стыдно. Это я как физик говорю. Просто их программы настолько специфичны, что представляют интерес только для узкого круга их коллег. А вылизаны проги, действительно, до мельчайших деталей. Иначе расчёты просто не сходятся.
Хотя понятие качества у них, конечно, своё.
Хотя понятие качества у них, конечно, своё.
Странно. Совсем недавно была статья, насколько все плохо с научным софтом. Софт пишут непрофессионалы в программировании и он не самого высокого качества.
Учёный не обязан становиться профессионалом в программировании. Следовательно, инструментарий для учёного должен быть прост настолько, насколько это возможно. Тогда количество допускаемых ошибок резко снизится или исчезнет совсем, а ведь это главное для расчётных систем.
Приведённый тут сравнительный анализ синтаксиса как раз показывает, что майнстрим движется по пути наращивания возможностей на выходе, а оберон движется по пути уменьшения ошибок на входе.
Приведённый тут сравнительный анализ синтаксиса как раз показывает, что майнстрим движется по пути наращивания возможностей на выходе, а оберон движется по пути уменьшения ошибок на входе.
Ученые используют очень ограниченный набор возможностей языка. Для них язык не становится сложнее или легче с появление рефлексии, так как они ее просто не встретят. Так же с большуй частью нововведений. Ученым они просто не попадутся на глаза и не будут мешать или помогать.
Зато например лямбды упрощают жизнь, хотя и являются довольно сложными для понимания возможностями языка.
Зато например лямбды упрощают жизнь, хотя и являются довольно сложными для понимания возможностями языка.
Несколько раз наблюдал, что расчёты сходятся даже при перепутанном знаке или пропущенной строчке в формулах. Правда, сходятся медленнее, чем было бы при правильных формулах. И не всегда…
Споэльски в своей статье про протекающие абстракции описал точку зрения, схожую с вашей. Однако я больше склоняюсь к высказыванию Эрика Эванса на этот счёт: «Рутинная деятельность должна быть автоматизирована. Автоматизация того, что должно быть трудом программиста, контрпродуктивно». Если инструмент автоматизирует то, в чём нужна свобода манёвра, то он ограничивает свободу действий программиста. Если абстракция инструмента протекает, то программисту приходится залезать в его внутренности. Если в инструменте есть баги, программисту приходится прикручивать костыли. Я думаю, что проблема может быть в недоработанности, недостаточной документации, плохой архитектуре инструментов, а не в их сложности. Например, современные ORM не имеют утилит для анализа запросов и автоматической генерации индексов, не умеют оптимизировать запросы, поэтому иногда приходится при помощи профилировщика смотреть, какой sql код они генерируют. Но если исправить эти и некоторые другие недоработки, то ORM станет более сложным, но более удобным инструментом, и программистам, использующим его, не будет необходимости знать sql. Таким образом, имхо, проблема не в сложности инструментов, а в их недоработках или изъянах.
Развитие ORM — вещь неизбежная, и не скажу, что это плохо. Но я всё же пойду и разберусь, как эти новые штуки работают изнутри, и заставлю своих проггеров выучить sql. Чтобы, когда ORM стуканёт на каком-то запросе, мы могли быстро поставить заплатку. А когда стуканёт у Вас, мы могли с этого поиметь ещё и дополнительную денюжку.
Кажется, вы меня немного не поняли. Я не говорил, что гарантированно наступит светлое будущее, когда ORM ни разу не «стуканет». Я говорил, что если ORM будет настолько хороша, что никогда не «стуканет», то рядовому программисту не будет необходимости знать подробности её работы. Многие не знают как устроена файловая система, но успешно ей пользуются. Файловая система — хорошая, не протекающая абстракция.
К сожалению, ORM никогда не будет настолько хороша. Причина банальна — концептуальную сложность предметной области невозможно полностью охватить механическим маппером, ведь концепции декларативного SQL и объектной модели разные. Поэтому у вас постоянно будет проседать либо сложность (просто, но быстро), либо производительность (сложно, но медленно).
В XIX веке некоторые примерно также объясняли невозможность полёта на Луну. Или, может быть, дело не в этом, и вы просто пророк?
Не могли бы вы пожалуйста немного пояснить, что в вашем понимании означает «ORM никогда не будет настолько хороша, что никогда не стуканёт»?
Я уже пояснил.
> концепции декларативного SQL и объектной модели разные
> концепции декларативного SQL и объектной модели разные
Всё равно не понимаю, «стуканёт», как глагол в будущем времени, предполагает некое действие в будущем. Какое действие? Я не спорю, концепции реляционного SQL и объектной модели разные, но при чём тут принципиальная невозможность ORM когда-либо стать инструментом, для использования которого знание глубинных принципов его работы не являлось бы обязательным навыком? Различие в концепциях является лишь причиной, мешающей полностью абстрагироваться от самого существования базы данных, но не более того.
Почти любой инструмент предполагает выполнение некоторых обязательных требований. Для сборщика мусора, например, это требование не делать циклических ссылок между объектами. Но это не значит, что все инструменты — протекающие абстракции. Но современные ORM, даже при соблюдении всех подразумевающихся требований, всё равно обязывают знать как они работают: часто нужно увидеть sql-запрос, сгенерированный где-то в недрах ORM и посмотреть, какого индекса не хватает, потому что ORM не может сама создавать индексы. А если бы ORM сама заботилась об индексах и генерировала оптимальные запросы, то такой необходимости не было бы.
Почти любой инструмент предполагает выполнение некоторых обязательных требований. Для сборщика мусора, например, это требование не делать циклических ссылок между объектами. Но это не значит, что все инструменты — протекающие абстракции. Но современные ORM, даже при соблюдении всех подразумевающихся требований, всё равно обязывают знать как они работают: часто нужно увидеть sql-запрос, сгенерированный где-то в недрах ORM и посмотреть, какого индекса не хватает, потому что ORM не может сама создавать индексы. А если бы ORM сама заботилась об индексах и генерировала оптимальные запросы, то такой необходимости не было бы.
Разные концепции — это сова и глобус. Натяните сову на глобус и где-то что-то порвётся или треснет.
Разные концепции заставляют использовать разные формальные аппараты. А у формального аппарата есть ограничения.
Если бы ORM решала все проблемы, то абстрагирование от сервера БД было бы полным и вас бы не беспокоили особенности генерации SQL-запросов. Но вам приходится учитывать особенности реляционной модели вручную.
Разные концепции заставляют использовать разные формальные аппараты. А у формального аппарата есть ограничения.
Если бы ORM решала все проблемы, то абстрагирование от сервера БД было бы полным и вас бы не беспокоили особенности генерации SQL-запросов. Но вам приходится учитывать особенности реляционной модели вручную.
Если бы ORM решала все проблемы, то абстрагирование от сервера БД было бы полным и вас бы не беспокоили особенности генерации SQL-запросов.
Согласен с тем, что если абстрагирование от сервера БД было бы полным, то не беспокоили бы особенности генерации SQL-запросов. Не согласен с тем, что полное абстрагирование от реляционной БД — единственно возможное решение проблемы необходимости отслеживания получившихся SQL-запросов.
Вы говорите нечто похожее на «трава зелёная, потому что африканские дети голодают». В том что африканские дети голодают, сомнений нет, но при чём тут трава? В том, что концепции реляционного SQL и объектной модели разные, сомнений нет, но при чём тут принципиальная невозможность ORM когда-либо стать инструментом, для использования которого знание глубинных принципов его работы не являлось бы обязательным навыком?
Я если и говорю «трава зелёная», то без связки «потому что» с другой концепцией, «голодающих негров». Не пытайтесь, пожалуйста, приписать мне ваши собственные мысли.
Проблемы ORM описаны даже в википедии, поэтому не буду про них говорить технически. Попробую рассуждать концептуально.
Реляционная и объектная модели дают нам язык для описания прикладных сущностей. В чём их отличия?
Реляционная модель даёт мощные средства для работы со множествами. С помощью реляционных выражений мы легко определяем любые множества любых сущностей.
Объектная модель используется для декомпозиции предметной области. С помощью ООП мы моделируем сущности предметной области и отношения между ними.
Но, какие средства даёт нам ООП для работы со множествами? Ответ — никаких, если не считать понятия класса (кстати, в недавнем обсуждении Smalltalk был выдвинут странный тезис, что для ООП классы не нужны, хотя объект в ООП всегда определяется через множество, которому он принадлежит, пусть даже в языке нет слова class).
Поэтому в аспекте работы со множествами объектная модель всегда отстаёт от реляционной. То, что вы делаете одним SQL-запросом, преобразуется в тонну объектного кода (пусть даже скрытого в ORM-прослойке).
И обратная ситуация, ваш автоматический объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами, поэтому всегда остаётся вероятность ручного вмешательства.
Проблемы ORM описаны даже в википедии, поэтому не буду про них говорить технически. Попробую рассуждать концептуально.
Реляционная и объектная модели дают нам язык для описания прикладных сущностей. В чём их отличия?
Реляционная модель даёт мощные средства для работы со множествами. С помощью реляционных выражений мы легко определяем любые множества любых сущностей.
Объектная модель используется для декомпозиции предметной области. С помощью ООП мы моделируем сущности предметной области и отношения между ними.
Но, какие средства даёт нам ООП для работы со множествами? Ответ — никаких, если не считать понятия класса (кстати, в недавнем обсуждении Smalltalk был выдвинут странный тезис, что для ООП классы не нужны, хотя объект в ООП всегда определяется через множество, которому он принадлежит, пусть даже в языке нет слова class).
Поэтому в аспекте работы со множествами объектная модель всегда отстаёт от реляционной. То, что вы делаете одним SQL-запросом, преобразуется в тонну объектного кода (пусть даже скрытого в ORM-прослойке).
И обратная ситуация, ваш автоматический объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами, поэтому всегда остаётся вероятность ручного вмешательства.
ваш автоматический объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами
Почему никогда не сможет? Это ваше утверждение хоть как-то связано с тем, что вы до этого написали? Или вы это просто так утверждаете, «без связки»? Если всё-таки связано и по-вашему не сможет, потому что концепции разные, то я отвечу, что программа, написанная на языке концепции логической парадигмы, совершенно спокойно может быть транслирована в программу в процедурной парадигме. Хотя в процедурной парадигме и есть понятия, отсутствующие в логической: например, понятия переменных и функций. Почему из логической в процедурную легко, а из объектно-ориентированной в реляционную ну никак? Запрос к бд, написанный на ООП языке, неплохо транслируется в реляционный SQL. Да, есть некоторые ограничения: нужно использовать методы Where(), Select() и прочее. Да, SQL запрос не всегда получается оптимальным. Но почему он не оптимален? Индекса например не хватает. Давайте научим ORM создавать индексы. Или не оптимален, потому что ORM не поддерживает иерархические запросы. Давайте её и этому научим. Назовите хотя бы одну принципиально нерешаемую проблему, которая мешает ORM всегда эффективно работать со множествами. Или опишите пожалуйста одним предложением причину, почему «объектный код в ORM-прослойке никогда не сможет всегда эффективно работать со множествами», (например, «не сможет, потому что сову на глобус натянуть невозможно») но только чтобы между причиной и следствием была логическая связь.
«никогда не сможет всегда», читайте внимательнее.
Да, SQL это не логический язык, а декларативный.
Если вы не хотите обсуждать на концептуальном уровне, читайте тогда технические вещи: en.wikipedia.org/wiki/Object-relational_impedance_mismatch
Да, есть некоторые ограничения: нужно использовать методы Where(), Select() и прочее.То есть, вы в императивный язык тащите декларативные куски, чтобы склеить концептуальный разлом.
Давайте научим ORM создавать индексы.Что здесь сложного и почему вы про это говорите сейчас, когда существуют тонны ORM-фреймворков?
Да, SQL это не логический язык, а декларативный.
Если вы не хотите обсуждать на концептуальном уровне, читайте тогда технические вещи: en.wikipedia.org/wiki/Object-relational_impedance_mismatch
Я вас просил назвать причину, по которой ORM в некоторых случаях не сможет сгенерировать оптимальный sql-запрос, а вы вместо этого начали мне в сто-пятьсотый раз доказывать, что есть различие в концепциях реляционной БД и ООП, даже ссылку скинули. Я много раз повторял: «Я не спорю, концепции реляционного SQL и объектной модели разные, но при чём тут принципиальная невозможность 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 в Оберон, не усложняя его? Или она уже есть?
При всем уважении в профессору Вирту, его оценка сложности языков программирования основана на правилах грамматики, то есть, говоря по-простому, оценивает лишь синтаксис, не затрагивая семантику. Однако, проблема в том, что семантику сложно, а в большинстве случаев невозможно оценить в цифрах. Я уже не говорю о том, что само понятие «семантика» _немного_ расплывчато. Тем не менее, я следую понятию семантики из википедии: 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 и что-то сможет предпринять. Но это мои частные рассуждения.
Исходный текст тут www.uni-vologda.ac.ru/cs/syntax/ariphm.htm
В последующих обсуждениях автору картинки предлагали считать уже примитивы AST. Но так как грамматика для человека, а AST для компилятора, то я бы оставил именно грамматику показателем динамики усложнения языка (не сравнительной сложности, а просто сложности). Есть же объективные пределы человеческого мозга, что и сколько надо держать в памяти. Каждый раз, добавляя ключевое слово в язык, вы повышаете нагрузку на мозг.
Не работал с вычислениями на GPU, но читал о них.
Насколько я понимаю, ключевых особенностей несколько: необходимость передавать данные в память/из памяти GPU, необходимость поддерживать структуры, пригодные для массово-параллельной обработки набора значений за одну инструкцию, необходимость эффективного управления тысячами вычислительных циклов на каждом маленьком ядре GPU. Вполне очевидно, что возникает необходимость в отдельном DSL, возможно, на базе Оберона. Но совмещать концепции в одном языке, как мне кажется, будет контрпродуктивно. То есть, гетерогенный язык это трудно. А вот гетерогенные компоненты составить уже возможно. Линковщик разберет продукт компиляции кода для CPU и GPU и что-то сможет предпринять. Но это мои частные рассуждения.
Спасибо за информацию. Значит, Вирт не автор этого исследования. Буду знать.
Кстати, я не вижу на картинке Лиспа, у которого то ли 2, то ли 3 грамматических правила…
Насчет языков: О Харухи, как я с вами согласен! Это настолько разные концепции, что пришивать пятую ногу к существующим языкам — значит ограничивать возможности GPU. Именно поэтому я говорю, что нужен новый язык для GPU, отстаньте вы от старичка Фортрана. Но рынок уже рассудил, что лучше пускать отдельные циклы на 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). Разумеется, это можно сделать вручную — не забыв аккуратно прописать для каждого поля каждой структуры процедуру чтения и процедуру записи. Все можно сделать вручную. Более того, любую программу можно написать на ассемблере и даже в машинных кодах вручную. Но нужно ли?
Или те же самые шаблоны и метапрограмминг. Да, это следующий уровень программирования, и конечно, он может быть проэмулирован вручную — аккуратным написанием тех же векторов, списков и алгоритмов для каждого типа. Но зачем, если есть удобный инструмент под названием «метапрограммирование»? То что он в С++ поехал не в ту степь — да, это нужно пофиксить (и ввести новые фичи, специально спроектированные для решения задач, для которых в С++ используют метапрограммирование на шаблонах), но зачем отказываться?
В той статье я не затронул многие вещи. Например, особенности добавления фич в современные языки. В большинстве случаев они добавляются бессистемно и, что самое печальное, они слабо связаны между собой. Вот это реально проблема. А количество фич — оно вполне разумно во всех существующих языках, я еще не встречал такого языка чтобы можно было запутаться в его синтаксисе. И стремиться их минимизировать вообще странно, это всего лишь инструменты — удобные инструменты для решения соответствующих задач; какой смысл например при создании чего-то (строительстве дома или там космического корабля) стремиться ограничить себя в инструментах???
Фичи — это не просто какой-то «синтаксический сахар» (вообще странное словосочетание:) ), это нечто, дающее новые возможности.
Например, рефлексия. Она есть в обероне? А это необходимая фича для автоматического связывания кода программы с внешними данными (например сериализация в xml). Разумеется, это можно сделать вручную — не забыв аккуратно прописать для каждого поля каждой структуры процедуру чтения и процедуру записи. Все можно сделать вручную. Более того, любую программу можно написать на ассемблере и даже в машинных кодах вручную. Но нужно ли?
Или те же самые шаблоны и метапрограмминг. Да, это следующий уровень программирования, и конечно, он может быть проэмулирован вручную — аккуратным написанием тех же векторов, списков и алгоритмов для каждого типа. Но зачем, если есть удобный инструмент под названием «метапрограммирование»? То что он в С++ поехал не в ту степь — да, это нужно пофиксить (и ввести новые фичи, специально спроектированные для решения задач, для которых в С++ используют метапрограммирование на шаблонах), но зачем отказываться?
В той статье я не затронул многие вещи. Например, особенности добавления фич в современные языки. В большинстве случаев они добавляются бессистемно и, что самое печальное, они слабо связаны между собой. Вот это реально проблема. А количество фич — оно вполне разумно во всех существующих языках, я еще не встречал такого языка чтобы можно было запутаться в его синтаксисе. И стремиться их минимизировать вообще странно, это всего лишь инструменты — удобные инструменты для решения соответствующих задач; какой смысл например при создании чего-то (строительстве дома или там космического корабля) стремиться ограничить себя в инструментах???
Это не сравнительный график языков, это совмещенные графики динамики эксплозии синтаксиса. Но и простоту с примитивностью путать не стоит.
А рефлексия не нужна в составе языка. Она отлично работает на уровне компонентов.
Шаблоны вообще лишают вас связи с реальным кодом. Для простых случаев, конечно, все работает.
Понимаете, трудно соблюсти баланс между сложностью и облегчением работы программиста. Нет ни одной реальной метрики, в числах, в графиках. Никто не знает, насколько та или иная фича нужна в языке. Поэтому нам приходится доверять мемам о том, что действительно, шаблоны «улучшают» код на Икс процентов.
Это разные подходы. В ситуации незнания кто-то предпочитает «делать» фичи, а кто-то выбирает «не делать» фичи. Ну а рассудил всех рынок. Деятельные люди там в почете.
А рефлексия не нужна в составе языка. Она отлично работает на уровне компонентов.
Шаблоны вообще лишают вас связи с реальным кодом. Для простых случаев, конечно, все работает.
Понимаете, трудно соблюсти баланс между сложностью и облегчением работы программиста. Нет ни одной реальной метрики, в числах, в графиках. Никто не знает, насколько та или иная фича нужна в языке. Поэтому нам приходится доверять мемам о том, что действительно, шаблоны «улучшают» код на Икс процентов.
Это разные подходы. В ситуации незнания кто-то предпочитает «делать» фичи, а кто-то выбирает «не делать» фичи. Ну а рассудил всех рынок. Деятельные люди там в почете.
Как рефлексия может работать в компонентах, если от компилятора требуется например связать объект с его строковым именем (которое известно только на этапе компиляции) и предоставить эту информацию другим частям программы? Тут или рефлексия, или ручками прописывать — других вариантов нет.
Шаблоны при правильной реализации никакой связи с кодом не лишают. Даже обычный оператор присваивания — это шаблон, потому что в конечном итоге для целых чисел вызывается один набор ассемблерных команд, для float — другой, а для строк вообще третий. Вы же не утверждаете что оператор присваивания лишает вас связи с кодом?
«Никто не знает, насколько та или иная фича нужна в языке» — почему же, практикующие программисты знают. Я приводил в пример Буст — это все не с потолка придумано, а для решения конкретных задач. Другое дело, что идеологически многое там — не полноценные фичи, а мегакостыли на костылях… Могу еще из своей жизни привести пример: я регулярно и достаточно давно заношу в evernote разные идеи по языковым фичам, возникающие из реальной практики. Таких записей сотни…
Шаблоны при правильной реализации никакой связи с кодом не лишают. Даже обычный оператор присваивания — это шаблон, потому что в конечном итоге для целых чисел вызывается один набор ассемблерных команд, для 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) — это действительно должно быть в библиотеках, но если в компиляторе нет ничего для базовой поддержки — то остаются только нагромождения костылей (как это и есть в С++). Одна маленькая фича в компиляторе позволит выкинуть множество неестественных и ненадежных нагромождений в библиотечном и прикладном коде. В этом и смысл языковых фич.
О балансе — в С++ нарушением баланса (ИМХО конечно) являются не сами шаблоны, а метапрограммирование на них. А сами шаблоны вполне сбалансированы. По изначальному замыслу предполагалось, что шаблоны будут вот для таких конструкций
а не для написания полноценных парсеров времени компиляции (boost.spirit) или compile-time коллекций типов и операций над ними (boost.mpl). Но то, что эти библиотеки появились, и что ими, несмотря на сложности, пользуются — признак того, что соответствующие возможности реально востребованы.
По рефлексии — если компилятору известно чуть больше, это уже языковая фича. Конкретные применения этой фичи (например запись в 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.
«в каждом проекте свой язык» можно сказать и про тот же C++ — в зависимости от того, какими библиотеками пользуются. Команда, использующая какой-нибудь MFC не быстро найдет общий язык с использующими Qt.
Это же чистый overengineering. Сейчас синтаксис работает одинакого и предсказуемо в любом проекте на распространенных языках программирования. Когда я пишу foreach я знаю во что это развернется и понимаю как это работает, к этому есть документация. Для каждой фичи есть подробные описания и разборы ошибок и узких мест на всяких stackoverflow.
Добавление стандартизированного синтаксического сахара — это как раз упрощает ПО, а использование чего-то низкоуровневого и тем более с самописным синтаксисом — усложняет. Взять те же async/await и итераторы в C#. Да, фича сложнее чем осознать как работает for или if, но поняв один раз — можно использовать на любом проекте и код получается гораздо более читабельный и простой. И не надо городить каждый раз костыли для эмуляции этих фич.
Добавление стандартизированного синтаксического сахара — это как раз упрощает ПО, а использование чего-то низкоуровневого и тем более с самописным синтаксисом — усложняет. Взять те же async/await и итераторы в C#. Да, фича сложнее чем осознать как работает for или if, но поняв один раз — можно использовать на любом проекте и код получается гораздо более читабельный и простой. И не надо городить каждый раз костыли для эмуляции этих фич.
Да нет, это реализуется не так уж сложно.
Я немного не это имею в виду. Допустим, у вас есть ряд проектов, совершенно различных, но разрабатываемых одной командой. И этим проектам нужны внутренние языки. Скриптовые. Сейчас у нас в команде есть 3-4 разных языка, каждый из которых трудится в качестве скриптового в отдельной программе. Да, они похожи. Настолько же, насколько походи Java, PHP, Basic и C — т.е. условно. Человек, который должен работать с этими скриптами, должен знать все 4 языка.
А могло быть иначе: язык один, но модульный, к нему в зависимости от необходимости, могут подключаться нужные модули, реализующие операторы, функции или даже целые конструкции, которые позволяют этому языку работать с конкретной программой, к которой он прикручен.
но поняв один раз — можно использовать на любом проекте и код получается гораздо более читабельный и простой
Вы точно так же можете сказать про, ну, например, boost.asio. Однако в каком-нибудь другом проекте будет использоваться другая библиотека, и знание этой, стандартной по сути, вам не поможет. Т.е. такой язык, с минимумом встроенного, тоже модульный. Не по части синтаксиса.
Я немного не это имею в виду. Допустим, у вас есть ряд проектов, совершенно различных, но разрабатываемых одной командой. И этим проектам нужны внутренние языки. Скриптовые. Сейчас у нас в команде есть 3-4 разных языка, каждый из которых трудится в качестве скриптового в отдельной программе. Да, они похожи. Настолько же, насколько походи Java, PHP, Basic и C — т.е. условно. Человек, который должен работать с этими скриптами, должен знать все 4 языка.
А могло быть иначе: язык один, но модульный, к нему в зависимости от необходимости, могут подключаться нужные модули, реализующие операторы, функции или даже целые конструкции, которые позволяют этому языку работать с конкретной программой, к которой он прикручен.
но поняв один раз — можно использовать на любом проекте и код получается гораздо более читабельный и простой
Вы точно так же можете сказать про, ну, например, boost.asio. Однако в каком-нибудь другом проекте будет использоваться другая библиотека, и знание этой, стандартной по сути, вам не поможет. Т.е. такой язык, с минимумом встроенного, тоже модульный. Не по части синтаксиса.
Сейчас вендоры меняют язык без вашего ведома, плюс пять фич год, а тут всего одна фича, которая законно решит абстрактную проблему монолитности синтаксиса и компилятора. Еще на уровне формального описания. Ну или хотя бы вынудит реализаторов компилятора сделать такую фичу.
Плюс хоть 10 фич в год — они везде одинаковые, а тут не «одна фича» а каждый барин будет делать себе свои фичи. Никакой проблемы «монолитности» нету, язык один и все им пользуются одинакого. Если я вижу foreach — я знаю как он работает в любой программе на определенном языке. Если я вижу лямбды — я тоже знаю как они работают. А тут foreach у каждого свой. А такие вещи как async/await вообще половина «баринов» реализует через одно место просто в силу их сложности. И никакого формального описания тут не будет, точнее будет одно маленькое описание и неопределенное число приложений неопределенного качества.
В обероне, вроде, даже, foreach нету, который добавили уже в самые консервативные языки. Хотя может тут не прав.
В обероне, вроде, даже, foreach нету, который добавили уже в самые консервативные языки. Хотя может тут не прав.
Foreach не нужен.
А вообще, вас же не волнует, что библиотеки про IO например могут различаться. Зачем же вы стремитесь так контролировать модульный язык? Он по определению модульный, со всеми плюсами и минусами.
А вообще, вас же не волнует, что библиотеки про IO например могут различаться. Зачем же вы стремитесь так контролировать модульный язык? Он по определению модульный, со всеми плюсами и минусами.
А такие вещи как async/await вообще половина «баринов» реализует через одно место просто в силу их сложности.Кажется, это называется патернализм, когда надежда на решение крупных проблем возлагается субъектом на Отца-корпорацию, у которой сил уж точно хватит. Не хватает, как мы видим. А если и дальше языки усложнять, то и не хватит никогда.
Foreach не нужен.А чем он мешает? Может еще и лямбды не нужны? async/await не нужен? А шаблоны/Generic'и? Так мы до ассемблера скатимся.
Foreach удобен когда есть коллекция с неизвестным числом элементов. Например:
foreach(var file in Directory.EnumerateAllFiles(...)) и вообще итераторы сами по себе очень удобны т.к. обеспечивают ленивые вычисления без всяких заморочек.
IO обычно есть в стандартной библиотеке (по крайней мере для тех языков с которыми я работал во всех случаях для базового IO использовалась стандартная библиотека).
Мы не скатимся. Скатимся — это вульгаризация рассуждений про лишние сущности. Либо рассуждения, либо вульгаризация.
Аргумент «чем он мешает?» ставит вас в позицию человека, который сначала втыкает в язык фичу, а потом начинает искать оправдания. Как оверпотребление в супермаркетах. Извините.
Аргумент «чем он мешает?» ставит вас в позицию человека, который сначала втыкает в язык фичу, а потом начинает искать оправдания. Как оверпотребление в супермаркетах. Извините.
Т.е. вреда нету? Польза есть и она очевидна, так почему бы не сделать foreach?
Так вы предлагаете серьезно чтоли убрать Generics/Templates? Или я чего-то не понял?
«Скатимся» — это потому что сейчас я например с использованием всяких «синтаксических сахаров» пишу UI приложение с нормальным UI на асинхронных операциях, с многопоточностью и кучей других плюшек за условно день, а если это убрать то писать я его буду условную неделю — оно мне надо, спрашивается? И работодателю моему не надо, и заказчику тоже не надо.
Так вы предлагаете серьезно чтоли убрать Generics/Templates? Или я чего-то не понял?
«Скатимся» — это потому что сейчас я например с использованием всяких «синтаксических сахаров» пишу UI приложение с нормальным UI на асинхронных операциях, с многопоточностью и кучей других плюшек за условно день, а если это убрать то писать я его буду условную неделю — оно мне надо, спрашивается? И работодателю моему не надо, и заказчику тоже не надо.
Вред очевиден, лишняя сущность, лишнее слово, лишние правила работы особого итератора. Есть понятие цикла с постусловием, с предусловием, безусловного, а тут нам подсовывают какой-то foreach с мутной семантикой. Для foreach достаточно библиотечного уровня. В языке — не нужен.
А зачем циклы с предусловием/постусловием? Это лишняя сущность, лишнее слово, лишние правила. Есть понятие goto и есть if, а тут нам подсовывают какие-то циклы с мутной семантикой.
Про аргументы бизнеса я упоминал в статье, их вес в рассуждениях еще нужно обосновать. Метод суслика, да-да.
Аргументы бизнеса просты и понятны. Сэкономленные деньги/время. Аргументы «уберите сущность которую я считаю лишней» — не понятны, т.к. никакой пользы из них не видно.
Работа ума уровня простейших, как поменьше потратить энергии и побольше впитать бульона и соседей. Бзнс.
А спутники падают.
Спутники падают из за ошибок, а ошибки делают люди и делают они их в любом языке.
Можно двигаться по пути минимизации ошибок. Человеческий фактор можно ослабить.
Удаление отлаженных и хорошо работающих конструкций из языка приведет к тому что люди будут писать их «от руки» и соответственно к увеличению ошибок. Так что да — надо двигаться по пути уменьшения ошибок перекладывая на компьютер и хорошо отлаженные библиотеки/компиляторы максимальное количество забот и ослабляя человеческий фактор.
Вообще, аргумент про «скатимся в ассемблер» пригоден, чтобы выставить оппонента недалеким фанатом, который и не заметит, как выкинул из языка вообще все. Зачем такой аргумент нужен в беседе культурных людей не очень понятно.
Вы на вопрос не ответли. Generic'и нужно выкидывать?
Их не нужно было вводить, теперь уже не выкинешь, такие правила игры.
Ну так бы сразу и сказали, сразу ответили на все вопросы. Только вот подозреваю что людей пользующих например async/await раз в неделю в C# (уж не говоря о Templates в C++, например) больше чем людей которые вообще слышали про оберон. Почему? Потому что есть языки которые все критикуют и есть языки которыми никто не пользуется.
Выбора у них нет, не забывайте. Никому не достался мир с нуля, приходится работать с тем, что есть, ведь принуждение голодом это сильный мотиватор. Это не повод не думать про правильное. Но, видимо, не все согласны.
Ахаха. Ваш любимый язык не используют не потому что он ни на что не годится, а потому что мировой заговор заставляет людей писать на C++/C#/Java/etc. Наверное где-то есть карательные отряды которые сажают приверженцов оберона в психушку? Как же иначе объяснить что у него нету последователей, ведь не может же это быть потому что концепция не верна, верно?
Дискуссия вырождается, судя по всему. Но покуда оберон вызывает такие эмоциональные выплески у сторонников майнстрима, имеет смысл обсуждать оберон и дальше.
Кхм, простите, причём тут мировой заговор? Вам же написали, что никто не начинает с нуля. Банальная логика не даёт связи между первоначальным заделом и каким-то сговором.
Компилить очень быстро, потому что сделано просто и понятно. Так что нет, не выкинем.
Боюсь спросить, а Вы его видели?
Система Оберон была написана за три года двумя частично занятыми людьми:
«Мы начали разработку системы в конце 1985 года, а программирование — в начале 1986 года на нашей рабочей станции Lilith и ее языке Модула-2. Сначала был создан кросс-компилятор, а за ним — модули внутреннего ядра вместе с необходимыми средствами тестирования и загрузки. Одновременно шла разработка системы отображения и текстовой системы без возможности их тестирования, конечно.
Мы поняли, насколько отсутствие отладчика и, более того, компилятора может
способствовать тщательному программированию. (Это действительно так, в чем
убедился один из нас, когда примерно в то же самое время и примерно в тех же условиях писал компиляторы языка С. — Прим. перев.)
Затем последовал перевод компилятора на язык Оберон. Это было сделано
стремительно, потому что оригинал был написан с намерением последующего
перевода. После его проверки на целевом компьютере Ceres вместе со средствами
редактирования текста пуповина Lilith могла быть отрезана. Система Оберон, по
крайней мере, ее черновая версия, стала реальной. Это случилось примерно в середине 1987 года; после этого было опубликовано ее описание.
Завершение системы заняло еще год, ушедший на объединение рабочих станций в сеть для передачи файлов, на средства централизованной печати и на инструменты поддержки. Наша цель — завершить систему в три года — была достигнута. В середине 1988 года система была представлена более широкому сообществу пользователей, и можно было начать работу над приложениями. Была разработана почтовая служба, добавлена графическая система и продолжены различные работы по общим системам подготовки документов. Средство отображения было расширено так, чтобы работать с любым экраном, включая цветной.
Одновременно на основе опыта использования системы совершенствовались отдельные ее части. С 1989 года в наших вводных курсах программирования язык
Модула-2 был заменен языком Оберон.»
Никлаус Вирт, Юрг Гуткнехт. «Разработка операционной системы и компилятора. Проект Оберон»
«Мы начали разработку системы в конце 1985 года, а программирование — в начале 1986 года на нашей рабочей станции Lilith и ее языке Модула-2. Сначала был создан кросс-компилятор, а за ним — модули внутреннего ядра вместе с необходимыми средствами тестирования и загрузки. Одновременно шла разработка системы отображения и текстовой системы без возможности их тестирования, конечно.
Мы поняли, насколько отсутствие отладчика и, более того, компилятора может
способствовать тщательному программированию. (Это действительно так, в чем
убедился один из нас, когда примерно в то же самое время и примерно в тех же условиях писал компиляторы языка С. — Прим. перев.)
Затем последовал перевод компилятора на язык Оберон. Это было сделано
стремительно, потому что оригинал был написан с намерением последующего
перевода. После его проверки на целевом компьютере Ceres вместе со средствами
редактирования текста пуповина Lilith могла быть отрезана. Система Оберон, по
крайней мере, ее черновая версия, стала реальной. Это случилось примерно в середине 1987 года; после этого было опубликовано ее описание.
Завершение системы заняло еще год, ушедший на объединение рабочих станций в сеть для передачи файлов, на средства централизованной печати и на инструменты поддержки. Наша цель — завершить систему в три года — была достигнута. В середине 1988 года система была представлена более широкому сообществу пользователей, и можно было начать работу над приложениями. Была разработана почтовая служба, добавлена графическая система и продолжены различные работы по общим системам подготовки документов. Средство отображения было расширено так, чтобы работать с любым экраном, включая цветной.
Одновременно на основе опыта использования системы совершенствовались отдельные ее части. С 1989 года в наших вводных курсах программирования язык
Модула-2 был заменен языком Оберон.»
Никлаус Вирт, Юрг Гуткнехт. «Разработка операционной системы и компилятора. Проект Оберон»
А будет еще быстрее. И запоминать меньше ключевых слов придется!
Я думаю вообще нужно писать для машины Поста. 6 команд и чиселки, вам должно понравится!
Я думаю вообще нужно писать для машины Поста. 6 команд и чиселки, вам должно понравится!
Мы благодарны за ваш отклик. Ваше мнение очень важно для нашего сообщества.
В Оксфорде преподают студентам именно Оберон. Видимо, там чего-то не знают, чего знаете вы.
А первый язык у них Haskell, вообще-то :)
Оберон там преподают ровно по той же причине, по которой у нас в школах и на первых курсах в большинстве университетов Паскаль и Delphi преподают.
Эх, а уж сколько ПО было создано на Delphi в свое время, еще на борландовской семерке :)
Эх, а уж сколько ПО было создано на Delphi в свое время, еще на борландовской семерке :)
Ну а как это противоречит? Просто примитивненький язык который прост для начальных стадий обучения программированию, в школе/универе — самое то. Это же не значит что он годен для продакшн программирования.
Браво. Наконец-то я это услышал.
Управление беспилотниками, это не продакшн? Система управления ГЭС на Амазонке — не продакшн?
Ах да. Сайтики, вот настоящий продакшн.
Управление беспилотниками, это не продакшн? Система управления ГЭС на Амазонке — не продакшн?
Ах да. Сайтики, вот настоящий продакшн.
Спутники, спутники еще.
Вы так бахвалитесь что полтора человека где-то использовало оберон, что я даже не знаю. А еще, знаете, COBOL используется, а в некоторых местах и фортран, по разным причинам. Они от этого перестали быть узкоспециализированными языками которые знает полтора человека? Думаю что нет.
Бахвалитесь? По-моему, это не совсем то слово, которое следует использовать в приятной беседе. Я не совсем понимаю, неужели одно упоминание Оберона уже вас оскорбляет? Если так, то вам пора к врачу.
Назвать Оберон «примитивным» означает показать свой низкий уровень образованности, уж извините. Такие познания в ИТ даже на техникум не тянут, одна радость — foreach знать. И, что особенно важно, писать слово production без акцента.
Как там вы сказали, «полтора человека»? Борланд заказывала виртуальную джава-машину оберонщикам, которые делали её с помощью обидного для вас ЯП. Но зачем про это знать российскому программисту, верно?
.
Назвать Оберон «примитивным» означает показать свой низкий уровень образованности, уж извините. Такие познания в ИТ даже на техникум не тянут, одна радость — foreach знать. И, что особенно важно, писать слово production без акцента.
Как там вы сказали, «полтора человека»? Борланд заказывала виртуальную джава-машину оберонщикам, которые делали её с помощью обидного для вас ЯП. Но зачем про это знать российскому программисту, верно?
.
Оскорбляет? Нет конечно, меня вообще тяжело оскорбить. Скорее я бы сказал меня это забавляет. А язык конечно примитивный, синтаксис уровня 90-х — начала 2000х, но никак не уровня 2015 года.
Борланд заказывала виртуальную джава-машину оберонщикамЭто как раз подтверждает мое высказывание про 1.5 человека. Где сейчас борланд? И где сейчас оберон? Посмотрите количество вакансий по оберону, ну или количество конференций где о нем говорят. Теперь сравните с Java/C#/C++. Вероятно вам потребуется точность double чтобы выразить отношение.
Вы хотите сказать, что столько мух одновременно ошибаться не могут?
Вы же понимаете что этот аргумент бессмысленный так как неопровержим. Его можно применить к чему угодно и сказать что лучше жить в пещерах и забросить науку но «миллионы мух же не могут ошибаться».
Я пока не увидел ни одного аргумента почему оберон лучше чем любой из TOP 5 языков. Писать кода на нем больше надо, ошибку допустить легче, высокоуровневых примитивов нету — так чем он лучше то? Тем что его проще выучить? Так инструкции к машине Поста еще проще выучить, ну или brainfuck — тоже просто понять. Только вот писать на нах не просто.
Я вот замечательно вижу как async/await экономит мне полотна кода и уровни вложенности и код получается компактный и простой. Так же вижу как мне аналогичным образом помогают встроенынные в язык итераторы, не говоря уже о Generic'ах, которые экономят тонну времени и предостерегают от кучи потенциальных ошибок. А тут пре предлагают отказаться от всего этого и ничего в замен не предлагают.
Я пока не увидел ни одного аргумента почему оберон лучше чем любой из TOP 5 языков. Писать кода на нем больше надо, ошибку допустить легче, высокоуровневых примитивов нету — так чем он лучше то? Тем что его проще выучить? Так инструкции к машине Поста еще проще выучить, ну или brainfuck — тоже просто понять. Только вот писать на нах не просто.
Я вот замечательно вижу как async/await экономит мне полотна кода и уровни вложенности и код получается компактный и простой. Так же вижу как мне аналогичным образом помогают встроенынные в язык итераторы, не говоря уже о Generic'ах, которые экономят тонну времени и предостерегают от кучи потенциальных ошибок. А тут пре предлагают отказаться от всего этого и ничего в замен не предлагают.
Он не «лучше», он другой. Стоит с другой стороны. Не там, где вы привыкли.
Для mainstream он хуже, я уже объяснил почему. А что дает взамен? Если взамен он дает только то что он «другой» — то он точно никому не нужен.
Ваши объяснения не имеют под собой веских оснований, поэтому мы их можем смело опустить. Масса людей легко делают выводы о вещах, в которых они не разбираются, но думают, что разбираются.
Ведь всё можно легко подсчитать. Как именно экономятся усилия программиста. Я для оберона вёл статистику работы — и получалось, что именно на набор кода, клики и возню мышкой тратится совсем небольшая часть времени. Львиная часть трудозатрат идёт на обдумывания. Когда проблема понятна, кодирование быстрое и продуктивное.
Как только вы предоставите аналогичные метрики для майнстрим-языков, появится предмет для обсуждения. Но не раньше!
Теперь, что оберон-методология даёт взамен. Избавление от ошибок на самом старте — это очень и очень дорогая вещь. Сложность надо регистрировать в самом начале, про это ещё Дейкстра говорил. Майнстрим идёт по другому пути — наращивая мускулы на выходе и подпирая костылями результат. Чтоб как-нибудь, но работало. В общем, вы костыли и принимаете за «достижения».
Ведь всё можно легко подсчитать. Как именно экономятся усилия программиста. Я для оберона вёл статистику работы — и получалось, что именно на набор кода, клики и возню мышкой тратится совсем небольшая часть времени. Львиная часть трудозатрат идёт на обдумывания. Когда проблема понятна, кодирование быстрое и продуктивное.
Как только вы предоставите аналогичные метрики для майнстрим-языков, появится предмет для обсуждения. Но не раньше!
Теперь, что оберон-методология даёт взамен. Избавление от ошибок на самом старте — это очень и очень дорогая вещь. Сложность надо регистрировать в самом начале, про это ещё Дейкстра говорил. Майнстрим идёт по другому пути — наращивая мускулы на выходе и подпирая костылями результат. Чтоб как-нибудь, но работало. В общем, вы костыли и принимаете за «достижения».
Ведь всё можно легко подсчитать. Как именно экономятся усилия программиста. Я для оберона вёл статистику работы — и получалось, что именно на набор кода, клики и возню мышкой тратится совсем небольшая часть времени. Львиная часть трудозатрат идёт на обдумывания. Когда проблема понятна, кодирование быстрое и продуктивное.Вы когда нибудь сравнивали например асинхронную работу с итераторами через async/await/yield/foreach и без всего этого? Особенно если идет несколько continuation'ов. Растет не просто количество кода, растет его сложность, увеличивается шанс допустить ошибку, растет время на понимание кода (а читают его гораздо чаще чем пишут).
Избавление от ошибок на самом старте — это очень и очень дорогая вещь.Так он не избавляет от ошибок, а привносит их, потому что вместо пользования более высокоуровневыми примитивами языка приходится вручную все делать.
что именно на набор кода, клики и возню мышкой тратится совсем небольшая часть времениЭто даже, я бы сказал, смешной аргумент (у меня улыбку вызвало). Так может все же ассемблер? Все равно на «набор кода» меньше времени тратится, а то что будет тратиться горзадо больше времени на обдумывание того как правильно и красиво сделать все низкоуровневыми примитивами — это ничего, это мы выкинем из рассмотрения, связанные с этим ошибки тоже.
Вы уж определитесь, он «лучше» или «другой», а то каментом выше был «другой», еще сейчас уже «лучше».
Асинхронная работа, прекрасно. А вы про активные объекты слышали? Если нет, к чему эти загибы?
Метрики приведите. Статистику работы. Числа. Ведь работа программиста выражается именно в том, сколько дела он сделает за определённое количество нажатий клавиш.
Без метрик это всё пустые слова и попытки раздуть из мухи слона.
Высокоуровневые примитивы уводят нас от железа и приближают к предметной области, это верно. Про это тоже Дейкстра писал. Следующий шаг на этом пути — наглухо завесить сборку мусора тоннами динамических сущностей, посмотрите, как работает сервер майнкрафта, например. Или, например, регулярные крэши среды, написанной на С++. Всё это в XXI веке, да-да.
Метрики приведите. Статистику работы. Числа. Ведь работа программиста выражается именно в том, сколько дела он сделает за определённое количество нажатий клавиш.
Без метрик это всё пустые слова и попытки раздуть из мухи слона.
Высокоуровневые примитивы уводят нас от железа и приближают к предметной области, это верно. Про это тоже Дейкстра писал. Следующий шаг на этом пути — наглухо завесить сборку мусора тоннами динамических сущностей, посмотрите, как работает сервер майнкрафта, например. Или, например, регулярные крэши среды, написанной на С++. Всё это в XXI веке, да-да.
Следующий шаг на этом пути — наглухо завесить сборку мусора тоннами динамических сущностей,… Или, например, регулярные крэши среды, написанной на С++.Это всего лишь неумение использовать инструменты. Сборка мусора очень помогает в 99% случаев, важно просто уметь выделить тот 1% случаев когда надо писать код с оглядкой на то как она работает или писать код в среде без GC. Это управление сложностью. Мы красим стену валиком, и подкрашиваем кисточкой те места, куда валик не достает, это делает нас более продуктивными. Говорить то что «валик не везде может покрасить» поэтому давайте везде красить кисточкой — странно. Да, покрасить кисточкой можно, но зачем? Оставим ее только для тех мест, где более высокоуровневые инструменты не справляются.
Метрики приведите. Статистику работы. Числа. Ведь работа программиста выражается именно в том, сколько дела он сделает за определённое количество нажатий клавиш.Совершенно нет. Работа в том сколько человек сделает за определенное время (не важно сколько он кнопок нажал), насколько качественно будет система работать, насколько быстро сможет другой человек в ней разобраться, и прочее подобное. foreach не просто сокращает количество строк кода — он уменьшает сложность, с которой нам приходится работать.
Да, расскажите про неумение использовать инструменты создателям Unity3d, например.
Сначала мне говорят про человеческий фактор, мол человек всегда делает ошибки. Теперь оказывается, что человеку подсовывают такие инструменты, с помощью которых можно делать ошибки. И мы приходим к выводу, что «сам дурак», раз не смог!
Детский сад.
>Совершенно нет. Работа в том сколько человек сделает за определенное время (не важно сколько он кнопок нажал)
А он как это делает, силой мысли? :)))))
Если вы одну и ту же задачу сделаете за 10 и за 100 обращений к средствам ввода, то во втором случае потратите больше времени и утомитесь больше. А если вести статистику на многих проектах, то можно оценить, сколько времени уходило на кодирование различных концепций и это можно будет сравнивать для разных ЯП.
Так что пока у вас не будет метрики, то разговаривать об «экономии форыча» не вижу смысла.
Сначала мне говорят про человеческий фактор, мол человек всегда делает ошибки. Теперь оказывается, что человеку подсовывают такие инструменты, с помощью которых можно делать ошибки. И мы приходим к выводу, что «сам дурак», раз не смог!
Детский сад.
>Совершенно нет. Работа в том сколько человек сделает за определенное время (не важно сколько он кнопок нажал)
А он как это делает, силой мысли? :)))))
Если вы одну и ту же задачу сделаете за 10 и за 100 обращений к средствам ввода, то во втором случае потратите больше времени и утомитесь больше. А если вести статистику на многих проектах, то можно оценить, сколько времени уходило на кодирование различных концепций и это можно будет сравнивать для разных ЯП.
Так что пока у вас не будет метрики, то разговаривать об «экономии форыча» не вижу смысла.
Сначала мне говорят про человеческий фактор, мол человек всегда делает ошибки. Теперь оказывается, что человеку подсовывают такие инструменты, с помощью которых можно делать ошибки.Как раз создаются инструменты с которыми все сложнее и сложнее выстрелить себе в ногу.
Совершенно нет. Работа в том сколько человек сделает за определенное время (не важно сколько он кнопок нажал)А он как это делает, силой мысли? :)))))Это шутка или вы не понимаете что количество нажатых кнопок значения не имеет? Оно, к слову, на более высокоуровневом языке будет меньше, так что тут вы тоже проиграли. Значение имеет время, и чем более низкоуровневый язык — тем больше времени тратится на то, чтобы придумать как написать код для той или иной задачи.
Вы путаете простоту с примитивностью. Как раз на хорошо проработанном формальном аппарате времени на придумывание тратится очень мало, это я вам заявляю совершенно ответственно. Вы освобождаете свой мозг от всяких вытребенек и занимаетесь общей архитектурой — которая, как ни странно, языковонезависима. А потом подходите к компу и просто делаете, без ошибок и без последующей отладки.
По моему как раз вы путаете простоту с примитивностью, выкидывая принятые людьми высокоуровневые примитивы.
Еще раз повторю — давайте подождем, пока оберон наберет хоть 10% рынка с таким подходом выкидывания всего полезного что было придумано за последние годы. Как только наберет (с текущей идиологией) — я поменяю свое мнение.
просто делаете, без ошибок и без последующей отладки.Какой волшебный язык, я прямо не устаю удивляться, и без ошибок, и без отладки. А кожу мою он сделает мягкой и сияющей?
Еще раз повторю — давайте подождем, пока оберон наберет хоть 10% рынка с таким подходом выкидывания всего полезного что было придумано за последние годы. Как только наберет (с текущей идиологией) — я поменяю свое мнение.
Оберон не выкидывает полезное :) Например, полноценное ООП в язык было введено минимальными усилиями. Я же говорю, вы плохо представляете себе ситуацию и совсем не знаете истории ИТ :)
А рынок — он про другое. Деньги делаются не на простоте, а на сложности. Оберон слишком простой, про него даже толстую книгу для амазона не напишешь, потому что писать не о чем. А вот для спутников или атомных станций — да, норм. Потому что реальная ответственность, а не игра с форычами.
Ну и ваше мнение меня не сильно интересует. Меняете вы его или нет — мне до лампочки.
А рынок — он про другое. Деньги делаются не на простоте, а на сложности. Оберон слишком простой, про него даже толстую книгу для амазона не напишешь, потому что писать не о чем. А вот для спутников или атомных станций — да, норм. Потому что реальная ответственность, а не игра с форычами.
Ну и ваше мнение меня не сильно интересует. Меняете вы его или нет — мне до лампочки.
У нас просто разные представления о полезности, вы считаете что умнее всех и знаете лучше куда двигаться индустрии, ок.
Я понял, рынок не прав, вы правы, весь мир в заговоре и делает сложные ненужные вещи, производители антивирусов пишут вирусы, а производители лекарств делают людей больными. А как же иначе, им же надо деньги зарабатывать одурачивая всех.
Я же говорю, вы плохо представляете себе ситуацию и совсем не знаете истории ИТ :)Как и весь рынок, да? Вы в меньшинстве, если что.
Я понял, рынок не прав, вы правы, весь мир в заговоре и делает сложные ненужные вещи, производители антивирусов пишут вирусы, а производители лекарств делают людей больными. А как же иначе, им же надо деньги зарабатывать одурачивая всех.
Everything should be made as simple as possible, but no simpler.
А про 10% рынка можно посмотреть на количество минусов к положительным комментариям про Оберон. Рынок не хочет Оберон, и силами многих тел демонстрирует этот факт.
А про 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.
Первый путь даёт много возможностей, но и много сложностей, почему и требуется масса костылей на всём технологическом цикле.
Второй путь следует идеологии, озвученной Э. Дейкстрой — регистрация и управление сложностью в самом начале.
А вы примитивизируете дискуссию, сводя к бинарности «они дураки, мы умные».
Когда 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 год :)
Интересно посмотреть, с чего швейцарцы начинали свой спинофф, см. 1993 год :)
Сделать «ещё один» Unity? Это глупо, ведь уже есть один такой. Если не нравится юнити — берите UE. И куча других движков. Это же бизнес, в закрытую дверь ломятся только дураки.
Теперь, что оберон-методология даёт взамен. Избавление от ошибок на самом старте — это очень и очень дорогая вещь.
Вы смешиваете язык и методологию. Оберон не предназначен для «гибких» проектов, как не предназначены фортран и ПЛ/1. Любое изменение — это 30% бюджета и дополнительные полгода работы («понимаете, мы уже перфокарты пробили, перебивать их — ручной тяжкий труд» — это об отсутствии дженериков, когда при заведении новой структуры данных алгоритмы надо копипастить и под неё). Понятно, что на современном быстро меняющемся рынке бизнес-задач оберонщики плохо выглядят в сравнении с быстрыми парнями, которые «тяп-ляп и в продакшен».
С другой стороны, кто мешает вдумчиво, неспешно и без ошибок писать большой проект на c++ или c# (последний, когда не требуется real-time управления, например в каком-нибудь планировании или расчётах погоды). Но тут оберонщики отхватывают рынок, потому что дистанцируются от быстрых говнокодеров, и вешают на себя ярлык: медленно, дорого, вдумчиво и надёжно. Понятно, что и на такое спрос есть, только язык тут ни при чём.
Я намеренно написал «оберон-методология», чтобы отделить формальный аппарат от самой методологии.
>это об отсутствии дженериков, когда при заведении новой структуры данных алгоритмы надо копипастить и под неё)
Ну что вы. Гетерогенные структуры, родовая шина сообщений и другие приёмы позволяют спокойно расширять и модифицировать систему. Опять критика оберона мимо кассы.
>это об отсутствии дженериков, когда при заведении новой структуры данных алгоритмы надо копипастить и под неё)
Ну что вы. Гетерогенные структуры, родовая шина сообщений и другие приёмы позволяют спокойно расширять и модифицировать систему. Опять критика оберона мимо кассы.
Вообще когда приводят эту метафору мне хочется спросить, является ли автор специалистом по пищеварению мух и точно дом он знает, что в сложившихся условиях для мухи дерьмо — не лучший из доступных выборов
Метафора подвергает критике массовое некритичное сознание, только и всего. «Так делают все — поэтому это правильно» — сказал однажды один очень умный лемминг. Майнстрим делает деньги на сложности (на средствах преодоления сложности), это очевидно для всех, кто пристально наблюдает за развитием ИТ ну хотя бы со времени появления MS-DOS.
Создавать и культвирировать сложность, в том числе и для топ-специалистов в ИТ, ведь ощущение собственной незаменимости крайне важно. Отсюда и постоянный поиск средств, «как бы меньше писать кода», ведь изначальная сложность не побеждена.
Создавать и культвирировать сложность, в том числе и для топ-специалистов в ИТ, ведь ощущение собственной незаменимости крайне важно. Отсюда и постоянный поиск средств, «как бы меньше писать кода», ведь изначальная сложность не побеждена.
Заказчику фиолетово, что там культивируют IT-шники, но он готов платить в 10 раз больше, если задачу сделают в 5 раз быстрее с тем же уровнем надёжности.
Только вся сложность не от языка, а от предметной области. Если в задаче 300 сущностей и 9000 связей, хочешь-не хочешь это всё придётся описать в коде, в данных или в DSL.
Странно, что оберонщики, как профессионалы в борьбе со сложностью, не хотят тут сорвать денег. Ощущение, что боятся выходить из своей башни из слоновой кости, где они пилят АЭС для спутников, и запачкать руки о реальный мир, где рулят всякие php и java.
Только вся сложность не от языка, а от предметной области. Если в задаче 300 сущностей и 9000 связей, хочешь-не хочешь это всё придётся описать в коде, в данных или в DSL.
Странно, что оберонщики, как профессионалы в борьбе со сложностью, не хотят тут сорвать денег. Ощущение, что боятся выходить из своей башни из слоновой кости, где они пилят АЭС для спутников, и запачкать руки о реальный мир, где рулят всякие php и java.
Вы же не взяли Оберон для решения задач. Вы вообще его не знаете. Как контрибутор в Оберон вы ноль. И таких овер 99%. О чем тут вообще рассуждать? О том, что несколько человек не решили столько задач, сколько решил полумиллион рыночных джавистов и пхпистов и поэтому они лохисидят в башне? Свои задачи мы решили, раз до сих пор с голоду не умерли.
Я не против попробовать. Посоветуйте какой-нибудь мануал по настройке среды и любой туториал по основам создания веб-приложений в обероне.
Клиент-сайд или сервер-сайд?
фулл-стек. хочу сравнить с asp.net mvc5
Серверная часть
oberoncore.ru/blackbox/environment
Сборка БлэкБокс — IDE+рантайм в составе есть компоненты по работе с файлами, сетью, Sql, и прочим.
bitbucket.org/oberoncore/mysql
MySQL драйвер
bitbucket.org/petryxa/o3-waf
Веб-фреймворк с демонстрационным примером внутри.
Клиентская часть:
github.com/vladfolts/oberonjs
компилятор оберона в js
Ну и гугл в помощь.
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
Понятно, что фичи не нужны. Но отказаться от инициализации массива списком это слишком…
Ну, а «web-фрейворк» — это махровый cgi, видали такие во времена первых сайтов на перле и c++
После знакомства с современными средствами без умиления на это не взглянешь, сколько нужно кода для простой страницы.
Понятно, что фичи не нужны. Но отказаться от инициализации массива списком это слишком…
Скрытый текст
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" (не говоря о раскраске синтаксиса) это из разряда мечтаний.
Не, я могу пописать на 6502 с тремя регистрами и 2kb RAM, но результат удивит лишь гиков, остальные не впечатлятся от получившегося продукта. Какой-либо причины браться за оберон, помимо ностальгии, я не нашёл.
Кстати, в дефолтной настройке дефолтная IDE BlackBox даже не делает auto-indent (и неизвестно, умеет ли). Поэтому смелое заявление "операторные скобки сейчас расставляет IDE" (не говоря о раскраске синтаксиса) это из разряда мечтаний.
Это напоминает о старом Бейсике, в котором можно было массив задать списком при помощи оператора DATA, а потом одним оператором считать его в массив.
Ваш вопрос не имеет смысла. Веб — это вообще-то HTTP + HTML «по определению». Клиент-сайд — это браузер + javascript. Оберону тут делать просто нечего. Разумеется, речь шла о сервер-сайде.
Если вам предложат попрограммировать на Обероне, вы скажете «Фи. А где тут бесплатная инфраструктура, которую построила большая западная компания за сто миллионов денег?». Хотя нет, не скажете. Оппоненты боятся признать, что сидят на плечах серьёзных рыночных игроков и все рассуждения про «реальный мир» опираются на серьёзные деньги, вложенные кем-то другим, а не на технологическое или концептуальное совершенство.
Ага, подключаться к электросетям и электростанциям, в которые большая компания вложила сто миллионов денег — это позор, а крутить ногами велогенератор — это концептуально и технологично.
Ну так причём здесь технологическое совершенство? Главное, чтоб западная фирма вложила свои деньги, и вы будете этим пользоваться, обеспечивая этой фирме конкурентоспособность.
Здесь я попрошу доказать, что ЯП и его экосистема аналогичны электроэнергии, а не станкам, Вы смените тему, накинув пару новых претензий, а ваша ложная аналогия так и останется висеть в интернетах, возможно ее даже плюсанут, она ведь такая яркая.
Как и ваши слова про «махровый» cgi, хотя там очевидно cgi не основной функциональный элемент, а контейнер сервлетов основной, используемый в разных серверах приложений на той же джаве до сих пор.
Ну и по остальным пунктам засада, так как вы очевидно реализовать автоиндент не хотите, но при этом представляете сложности, которые возникнут при решении задачи, сделаю предположение, что вашу позицию вы базируете на вещах, которые сделаны не вами и не за ваши деньги. Поэтому логично утверждать что вы просто болеете за победителя. В этом есть экономические преимущества, но рассматривать ваше мнение как осмысленное уже нет никаких оснований.
Это делает меня думать, что за Вас тоже думает рынок.
Как и ваши слова про «махровый» cgi, хотя там очевидно cgi не основной функциональный элемент, а контейнер сервлетов основной, используемый в разных серверах приложений на той же джаве до сих пор.
Ну и по остальным пунктам засада, так как вы очевидно реализовать автоиндент не хотите, но при этом представляете сложности, которые возникнут при решении задачи, сделаю предположение, что вашу позицию вы базируете на вещах, которые сделаны не вами и не за ваши деньги. Поэтому логично утверждать что вы просто болеете за победителя. В этом есть экономические преимущества, но рассматривать ваше мнение как осмысленное уже нет никаких оснований.
Это делает меня думать, что за Вас тоже думает рынок.
Не было ли каких-то языков разработанных некорпорациями которые несмотря ни на что взлетели, причем выше и быстрее чем оберон?
Людям нужно выпонение их конкретных задач. Коныептуально совершенный язык им не нужен. Чтобы что-то взлетело, надо чтобы зотя бы для какого-то конкретного пользователя язык решал его задачу лучше чем все остальные. Включая уже готовые экосистемы сделанные корпорациями.
Просто надо выбрать какую-то нишу и обеспечить там лучший набор «батареек».
Так взлетел php — кривой и нелогичный, но подходящий для простого веба.
Так же взлетели python и ruby. Сейчас, похоже, взлетает Rust.
Потом из этой ниши можно атаковать другие.
Для кого Оберон сейчас?
Людям нужно выпонение их конкретных задач. Коныептуально совершенный язык им не нужен. Чтобы что-то взлетело, надо чтобы зотя бы для какого-то конкретного пользователя язык решал его задачу лучше чем все остальные. Включая уже готовые экосистемы сделанные корпорациями.
Просто надо выбрать какую-то нишу и обеспечить там лучший набор «батареек».
Так взлетел php — кривой и нелогичный, но подходящий для простого веба.
Так же взлетели python и ruby. Сейчас, похоже, взлетает Rust.
Потом из этой ниши можно атаковать другие.
Для кого Оберон сейчас?
Ну да, люди согласны на кривое, потому что надо «здесь и сейчас». Это нормально. Вот это и есть истинно рыночный подход.
Про последующие затраты на исправление кривизны изначально никто не думает. Ну и малоответственные сайты, здесь кривизна вполне допустима, ведь это не АЭС и не спутники. Залипла страничка у пользователя, какое вам дело? Ведь деньги за сайт вы уже получили.
Про последующие затраты на исправление кривизны изначально никто не думает. Ну и малоответственные сайты, здесь кривизна вполне допустима, ведь это не АЭС и не спутники. Залипла страничка у пользователя, какое вам дело? Ведь деньги за сайт вы уже получили.
> Про последующие затраты на исправление кривизны изначально никто не думает
Думает. Проще сразу начать получать доход, потом исправить кривизну. Вы, кстати, знакомы с концепцией MVP и Lean Startup?
Возможно кривизна будет в каком-то уже другом коде — так как часть этого выкинут за ненадобностью.
Думает. Проще сразу начать получать доход, потом исправить кривизну. Вы, кстати, знакомы с концепцией MVP и Lean Startup?
Возможно кривизна будет в каком-то уже другом коде — так как часть этого выкинут за ненадобностью.
Кривизна и адаптация\эволюция разные вещи.
Вопрос в другом. Почему вы не можете быстро написать правильно работающий код? Что мешает? И зачем «исправлять потом», почему нельзя «сразу»?
Вопрос в другом. Почему вы не можете быстро написать правильно работающий код? Что мешает? И зачем «исправлять потом», почему нельзя «сразу»?
> Почему вы не можете быстро написать правильно работающий код?
Инструменты и практики для быстрой и правильной работы замедляют на стадии прототипа/первых версий.
Сразу нельзя потому, что это медленнее и такая правильность заказчику нужна после того, как он получит хоть как-то работающее решение (потом, вохможно, он даст нам обратную связь и мы вообще прппишем или выкинем тот код, который работал на стадии прототипа).
Петя и Вася получили заказ на сайтик.
Петя начал писать на Обероне, а Вася взял говый CMS на PHP и изменил там пару строчек.
Васин заказчик уже рубит бабло на сайте, хотя у него периодически случаются ошибки.
Петин ждет решения на Обероне.
Васин заказчик уже занял долю рынка, он про него знает, и он получил отклик от пользователей и добавил на сайтик необходимые фичи.
Петин заказчик ждет решения на Обероне.
Васин зачазчик продолжает рубить бабло.
Петин заказчик получил решение на Обероне и говорит пользователям: «Cмотрите, у меня самый надежный сайтик в мире!»
А пользователи такие: «а нас не парит — у Васи сайтик нас устраивает, хоить и показывает Error 500 раз в неделю, а про твой мы не знаем, да и нам влом еще где-то регистрироваться»
Инструменты и практики для быстрой и правильной работы замедляют на стадии прототипа/первых версий.
Сразу нельзя потому, что это медленнее и такая правильность заказчику нужна после того, как он получит хоть как-то работающее решение (потом, вохможно, он даст нам обратную связь и мы вообще прппишем или выкинем тот код, который работал на стадии прототипа).
Петя и Вася получили заказ на сайтик.
Петя начал писать на Обероне, а Вася взял говый CMS на PHP и изменил там пару строчек.
Васин заказчик уже рубит бабло на сайте, хотя у него периодически случаются ошибки.
Петин ждет решения на Обероне.
Васин заказчик уже занял долю рынка, он про него знает, и он получил отклик от пользователей и добавил на сайтик необходимые фичи.
Петин заказчик ждет решения на Обероне.
Васин зачазчик продолжает рубить бабло.
Петин заказчик получил решение на Обероне и говорит пользователям: «Cмотрите, у меня самый надежный сайтик в мире!»
А пользователи такие: «а нас не парит — у Васи сайтик нас устраивает, хоить и показывает Error 500 раз в неделю, а про твой мы не знаем, да и нам влом еще где-то регистрироваться»
То есть, вы подтверждаете, что в XXI веке программист не способен быстро писать правильный код. Даже удобный форыч с мощной бесплатной инфраструктурой ценой в стомиллионыденег не спасает. Консерватория гнилая, так и запишем.
Поправлю, не такой правильный код он напишет быстрее в любой консерватории.
>Петя начал писать на Обероне, а Вася взял говый CMS на PHP и изменил там пару строчек.
Почему Петя не взял готовый CMS? Полагаю, у Пети заказ от банковской системы и ему выставили совершенно другие требования.
Почему Петя не взял готовый CMS? Полагаю, у Пети заказ от банковской системы и ему выставили совершенно другие требования.
То есть решение использовать Оберон в условиях Васи было бы глупостью? Для его условий Оберон не подходит?
В условиях Васи подходит PHP, он его и взял, почему это глупость?
Вы априори полагаете, что для Оберона нет CMS, поэтому в вашей задаче у Васи преимущество. Но мы же в ИТ, где повторное использование есть краеугольный камень индустрии. Стоит Пете один раз написать толковую CMS на Обероне, как преимущество Васи сильно просядет. А как только Петя сумеет создать комьюнити, то Вася начнёт беспокоиться.
Вы априори полагаете, что для Оберона нет CMS, поэтому в вашей задаче у Васи преимущество. Но мы же в ИТ, где повторное использование есть краеугольный камень индустрии. Стоит Пете один раз написать толковую CMS на Обероне, как преимущество Васи сильно просядет. А как только Петя сумеет создать комьюнити, то Вася начнёт беспокоиться.
> В условиях Васи подходит PHP, он его и взял, почему это глупость?
Не просядет — Пете надо поддерживать CMS писать для нее модули и т.д. За это время у Васи будет выбор из кучи других CMS и возможность быстро и дешево нанять Вань без обучения Оберону.
Пока Петя не докажет, что его Оберон заруливает php по скорости разработки он будет выбирать php для Васиных задач.
Не просядет — Пете надо поддерживать CMS писать для нее модули и т.д. За это время у Васи будет выбор из кучи других CMS и возможность быстро и дешево нанять Вань без обучения Оберону.
Пока Петя не докажет, что его Оберон заруливает php по скорости разработки он будет выбирать php для Васиных задач.
Надеюсь, вы понимаете, что спор ни о чём. Ведь сравнивать разные заделы попросту нелогично. Сравнивать скорость и качество тоже нельзя. А тем более расстояние до предметной области. PHP ближе к вебстраничкам, поэтому его легко использовать. Сравнивать PHP и Оберон нельзя, потому что PHP написан на Си, и правильнее будет сравнить с ним PHP, написанный на Обероне.
Сравнивать можно, мы сравнили и пришли к одному и тому же выводу: в конкретном случае трудоемкость решения задачи на Обероне такова, что лучше взять готовое, хотя и менее надежное. Существуют задачи для которых надежность менее существенна чем скорость разработки (примем пока на веру тезис, что Оберон уделывает все остальное по нажежности).
Вероятнее всего, таких задач большинство.
Вероятнее всего, таких задач большинство.
Вы сравниваете тёплое с мягким. Возможно, вы не знаете, что PHP написан на Си.
Что из этого следует?
Покажите кучу CMS-ок, написанных на Си.
Почему я должен ее показать? Для написания CMS я не буду использовать C. Мой поинт именно в этом.
Вы говорите, что концептуально совершенный язык людям не нужен, а нужно решать проблемы предметной области. Это так.
Интерпретатор PHP можно написать и на Обероне. Но зачем писать CMS на Обероне, мне непонятно.
Интерпретатор PHP можно написать и на Обероне. Но зачем писать CMS на Обероне, мне непонятно.
Да, кстати. Вам привели ссылку на веб-фреймворк компании, созданной в 1998 году. В то время PHP только набирал обороты и, в общем-то, можно было сравнивать. Так вот, эти люди быстренько соорудили себе на обероне небольшой спокойный бизнес на обслуживании серьёзных компаний. Как раз, где требовалась надёжность. Почему компания Siemens AG не выбрала PHP, я не знаю.
Сейчас-то да, много воды утекло. Интерес в другом, как оберонщикам это удавалось.
P.S. Почему-то встраивание ссылки работает здесь через пень-колоду, отнимая моё время. Вот ссылка: www.o3-software.de/en/Company.xhtml
Сейчас-то да, много воды утекло. Интерес в другом, как оберонщикам это удавалось.
P.S. Почему-то встраивание ссылки работает здесь через пень-колоду, отнимая моё время. Вот ссылка: www.o3-software.de/en/Company.xhtml
Сайт хреновый — по нему совершенно не понятно, для кого они это сделали и в чем достоинства именно их FW. Нет примеров кода. Сравните, например, websharper.com
Если написать интерпретатор php на обероне и написать CMS на php то результат будет менее надежный, чем если написать CMS на обероне так как мы принимаем допущение, что программы Обероне более надежные чем на PHP
Почему вы не вспомнили, как выстрелил Turbo Pascal? Именно виртовская простота дала фирме Borland конкурентное преимущество. Потом на поляну доползли монстры индустрии и завалили её своими продуктами (кстати, если внимательно посмотреть на историю ИТ, то станет заметно, как швейцарские разработки стреляют далеко вперёд, а индустрия медленным шагом дотягивается до них спустя годы и годы).
Оберон сейчас, например, в российских беспилотниках используется.
Оберон сейчас, например, в российских беспилотниках используется.
Я не уверен что Turbo Pascal выстрелил именно из-за паскаля, а не из за турбо среды. Turbo C и Turbo Assembler тоже выстрелили. Это раз.
Во-вторых, простота бывает разная. Бывает концептуальная простота, бывает простота использования. Например brainfuck и forth концептуально очень простые, а пользоваться сложно.
foreach пользоваться просто.
Если вы так интересуетесь надежностью, не могли бы вы сравнить подход Оберона с тем, что используется в Эйфеле, например. Как у оберона с Design By Contract?
Во-вторых, простота бывает разная. Бывает концептуальная простота, бывает простота использования. Например brainfuck и forth концептуально очень простые, а пользоваться сложно.
foreach пользоваться просто.
Если вы так интересуетесь надежностью, не могли бы вы сравнить подход Оберона с тем, что используется в Эйфеле, например. Как у оберона с Design By Contract?
Да, конечно, среда тоже была отличной. Но — быстрота компиляции однопроходного компилятора на слабых компах была радикальной. Я помню те времена — пока турбосишники компилировали свою программу, я успевал в турбопаскале сделать несколько итераций исправление — запуск — отладка.
Про простоту говорить сложно. Потому что говоря о простоте, мы всегда должны понимать, что такое сложность. А сам Дейкстра незадолго перед уходом сообщил, что отрасль ИТ так и не разобралась со сложностью. Думаю, всем нам надо серьёзно отнестись к словам Дейкстры и очень аккуратно обращаться с понятием простоты.
foreach прост, конечно. Вот я в Unity вытаскиваю список материалов и прохожу по нему форычем, чтоб отыскать нужный. Просто? Да. Удобно? Да. Но есть ещё более простой способ — послать сообщение. Тогда форыч не понадобится. Но идеология инструментария такова, что в ней посылать сообщения накладно. Дешевле использовать форыч. И вы используете и используете списки объектов с форычем для доступа к сущностям. Вывод на первый взгляд парадоксален — если вам часто приходится использовать форыч, то у вас что-то не то с архитектурой.
Насчёт контрактов, почитайте документацию к любому модулю из комплекта BlackBox Component Builder. Позволю себе процитировать:
PROCEDURE (v: View) HandleViewMsg- (f: Frame; VAR msg: Message)
NEW, EMPTY
Message handler for view messages.
HandleViewMsg is called locally.
HandleViewMsg is implemented in views which support marks (e.g., selection marks), and in views which support different frame contents for the same view (a rare case).
Pre
f # NIL guaranteed
f.view = v guaranteed
v.context # NIL guaranteed
msg.view = v OR msg.view = NIL guaranteed
Вот этот вот раздел Pre описывает предусловия обработчика HandleViewMsg. Есть ещё и постусловия. Вся среда построена на этом. Контрактное программирование, на практике это реализуется банальными ассертами на входе в процедуру и на выходе. И это реально работает, как только вы продерётесь через все ассерты, то можно считать, что система будет функционировать без неожиданностей.
en.wikipedia.org/wiki/Design_by_contract всё это работает в Обероне.
Контракты модулей описываются формально, среда их верифицирует, поддержка инвариантов en.wikipedia.org/wiki/Invariant_(computer_science) в наличии.
Про простоту говорить сложно. Потому что говоря о простоте, мы всегда должны понимать, что такое сложность. А сам Дейкстра незадолго перед уходом сообщил, что отрасль ИТ так и не разобралась со сложностью. Думаю, всем нам надо серьёзно отнестись к словам Дейкстры и очень аккуратно обращаться с понятием простоты.
foreach прост, конечно. Вот я в Unity вытаскиваю список материалов и прохожу по нему форычем, чтоб отыскать нужный. Просто? Да. Удобно? Да. Но есть ещё более простой способ — послать сообщение. Тогда форыч не понадобится. Но идеология инструментария такова, что в ней посылать сообщения накладно. Дешевле использовать форыч. И вы используете и используете списки объектов с форычем для доступа к сущностям. Вывод на первый взгляд парадоксален — если вам часто приходится использовать форыч, то у вас что-то не то с архитектурой.
Насчёт контрактов, почитайте документацию к любому модулю из комплекта BlackBox Component Builder. Позволю себе процитировать:
PROCEDURE (v: View) HandleViewMsg- (f: Frame; VAR msg: Message)
NEW, EMPTY
Message handler for view messages.
HandleViewMsg is called locally.
HandleViewMsg is implemented in views which support marks (e.g., selection marks), and in views which support different frame contents for the same view (a rare case).
Pre
f # NIL guaranteed
f.view = v guaranteed
v.context # NIL guaranteed
msg.view = v OR msg.view = NIL guaranteed
Вот этот вот раздел Pre описывает предусловия обработчика HandleViewMsg. Есть ещё и постусловия. Вся среда построена на этом. Контрактное программирование, на практике это реализуется банальными ассертами на входе в процедуру и на выходе. И это реально работает, как только вы продерётесь через все ассерты, то можно считать, что система будет функционировать без неожиданностей.
en.wikipedia.org/wiki/Design_by_contract всё это работает в Обероне.
Контракты модулей описываются формально, среда их верифицирует, поддержка инвариантов en.wikipedia.org/wiki/Invariant_(computer_science) в наличии.
> foreach прост, конечно. Вот я в Unity вытаскиваю список материалов и прохожу по нему форычем, чтоб отыскать нужный. Просто? Да. Удобно? Да. Но есть ещё более простой способ — послать сообщение.
Это как? А если у вас другая задача, например, просто сконвертировать весь список в html?
Это как? А если у вас другая задача, например, просто сконвертировать весь список в html?
Я сделаю WHILE с охраной условий и сконвертирую. foreach — читается «для каждого», а мне может понадобиться не для каждого. форыч не нужен.
Если не для каждого, то либо Where либо для каждого — но условие внутри.
В-общем, альтернативно — тупой копипаст кода.
В-общем, альтернативно — тупой копипаст кода.
Ну вот, мы обсуждаем особенности механизма обхода списка разнородных сущностей, так ведь? И вы почему-то не задаётесь вопросом, для чего этот список нужен.
А ведь совсем недавно на хабре было обсуждение языка Smalltalk, где адепты Алана Кея говорили про то, что коммуникация сущностей это основа.
Так вот, чтобы заставить объекты коммуницировать, вам нужны списки и удобный механизм для работы с ними. Вы считаете, что это отличная фича и совершенно правильно считаете, надо сказать. Потому что для разнородных списков форыч удобен.
Но как только вы построите гетерогенную расширяемую систему, и будете посылать сообщения, то вам списки уже не понадобятся. А значит, надобность в форыче отпадает.
Вот так работает концептуальная простота. А форыч — костыль для решения проблем примитивной структуры. Вот чем отличается простота от примитивности.
А ведь совсем недавно на хабре было обсуждение языка Smalltalk, где адепты Алана Кея говорили про то, что коммуникация сущностей это основа.
Так вот, чтобы заставить объекты коммуницировать, вам нужны списки и удобный механизм для работы с ними. Вы считаете, что это отличная фича и совершенно правильно считаете, надо сказать. Потому что для разнородных списков форыч удобен.
Но как только вы построите гетерогенную расширяемую систему, и будете посылать сообщения, то вам списки уже не понадобятся. А значит, надобность в форыче отпадает.
Вот так работает концептуальная простота. А форыч — костыль для решения проблем примитивной структуры. Вот чем отличается простота от примитивности.
> Но как только вы построите гетерогенную расширяемую систему, и будете посылать сообщения, то вам списки уже не понадобятся. А значит, надобность в форыче отпадает.
Что вы понимаете под списком и почему они не понадобятся?
foreach обычно работает со всем что имеет элементы, мне трудно представить себе такую архитектуру где такого понятия нет. Покажите, пожалуйста, эскиз код для такой архитектуры на обероне.
Например, надо написать код который генерирует html для коллекции сотрудников. Я не очень представляю как это решать так чтобы не было лишнего кода (который будет повторяться в нескольких местах), foreach или метода/функции, получающий метод/функцию как аргумент.
Вот foreach в smalltalk
Что вы понимаете под списком и почему они не понадобятся?
foreach обычно работает со всем что имеет элементы, мне трудно представить себе такую архитектуру где такого понятия нет. Покажите, пожалуйста, эскиз код для такой архитектуры на обероне.
Например, надо написать код который генерирует html для коллекции сотрудников. Я не очень представляю как это решать так чтобы не было лишнего кода (который будет повторяться в нескольких местах), foreach или метода/функции, получающий метод/функцию как аргумент.
Вот foreach в smalltalk
Bus.SendMessage, или View.HandleMessage.
Вы мыслите в рамках «элементов», поэтому вам нужно приспособление, чтобы дотянуться до каждого элемента. Это и есть проблема в архитектуре, порождающая ненужную сложность, преодолеваемую форычем.
Не надо думать про «элементы». Посылайте сообщение в среду, пусть объекты сами добавляются в структуру HTML. Ах, ваши объекты этого не умеют? Добавьте им такое поведение, что сложного? Ах, вам только один раз? Тогда достаточно WHILE, форыч опять не нужен.
Вы мыслите в рамках «элементов», поэтому вам нужно приспособление, чтобы дотянуться до каждого элемента. Это и есть проблема в архитектуре, порождающая ненужную сложность, преодолеваемую форычем.
Не надо думать про «элементы». Посылайте сообщение в среду, пусть объекты сами добавляются в структуру HTML. Ах, ваши объекты этого не умеют? Добавьте им такое поведение, что сложного? Ах, вам только один раз? Тогда достаточно WHILE, форыч опять не нужен.
Это как «сами» вы про разделения UI и Business logic слышали?
Внутри View.Handle message как будет происходить обход коллекции?
Внутри View.Handle message как будет происходить обход коллекции?
Среда BlackBox Component Builder выпущена в 1994 году, и являет собой образец отделения интерфейса от прикладной логики. Так что я немного в курсе. А вот вы зачем-то напрямую обрабатываете список сотрудников.
>Внутри View.Handle message как будет происходить обход коллекции?
Зависит от целей и от реализации. Объект может передать сообщение дальше, вызвав HandleMessage у вложенного, а может и банальным WHILE. В любом случае, это не та ситуация, когда форыч используют по триста раз на дню, так что вопрос не в тему.
>Внутри View.Handle message как будет происходить обход коллекции?
Зависит от целей и от реализации. Объект может передать сообщение дальше, вызвав HandleMessage у вложенного, а может и банальным WHILE. В любом случае, это не та ситуация, когда форыч используют по триста раз на дню, так что вопрос не в тему.
Итого for each не выкидывается в просто перепрятывается из одного места в другое. И приходится дулировать логику foreach внутри while.
Можно улучшать только то, что используется триста раз на дню? Вон в питоне решили по другому, вместо foreach выкинули for. Нужен for — делай foreach по range.
Кстати, вот это дублирование отключаемое:
Можно улучшать только то, что используется триста раз на дню? Вон в питоне решили по другому, вместо foreach выкинули for. Нужен for — делай foreach по range.
Кстати, вот это дублирование отключаемое:
PROCEDURE Draw* (f : Figure);
BEGIN
f.if.draw(f);
END Draw; // <- Нахрена в такой маленькой функции еще раз писать ее имя?
foreach это тот же цикл for, только без счётчика. Как только чуть усложняется задача, то foreach превращается в цикл while. Чем изучать особенности foreach, достаточно автоматически применять while.
Сколько раз в день вы применяете foreach? Боюсь, экономия по сравнению с while получается слабенькая, а если с усложнением, то и вовсе никакой.
Кроме этого, foreach это, по сути, способ коммуникации с пачкой объектов. С помощью форыча вы вручную строите обмен сообщениями.
Насчёт имени Draw, скажу по опыту — так нагляднее. На маленькой процедуре, конечно, неощутимо, но когда работаешь над реальным проектом, то чувствуешь.
Сколько раз в день вы применяете foreach? Боюсь, экономия по сравнению с while получается слабенькая, а если с усложнением, то и вовсе никакой.
Кроме этого, foreach это, по сути, способ коммуникации с пачкой объектов. С помощью форыча вы вручную строите обмен сообщениями.
Насчёт имени Draw, скажу по опыту — так нагляднее. На маленькой процедуре, конечно, неощутимо, но когда работаешь над реальным проектом, то чувствуешь.
> foreach это тот же цикл for, только без счётчика. Как только чуть усложняется задача, то foreach превращается в цикл while. Чем изучать особенности foreach, достаточно автоматически применять while.
Или в дополняется комбинаци с where
> Сколько раз в день вы применяете foreach?
Я работаю с несколькими языками, в одном я его использую гораздо чаще чем whil в другом нет for each зато есть конструкция эквивалентная where + for each для базы данных.
> Боюсь, экономия по сравнению с while получается слабенькая, а если с усложнением, то и вовсе никакой.
Это экономит мозг, потому, что сводится к частному случаю while подпадающему под определеннвй паттерн.
> Кроме этого, foreach это, по сути, способ коммуникации с пачкой объектов. С помощью форыча вы вручную строите обмен сообщениями.
Это сообщение для объекта-коллекции.
> Насчёт имени Draw, скажу по опыту — так нагляднее. На маленькой процедуре, конечно, неощутимо, но когда работаешь над реальным проектом, то чувствуешь.
Скажу по опыту, что писать только маленькие процедуры можно. И с foreach так делаеть проще
Или в дополняется комбинаци с where
> Сколько раз в день вы применяете foreach?
Я работаю с несколькими языками, в одном я его использую гораздо чаще чем whil в другом нет for each зато есть конструкция эквивалентная where + for each для базы данных.
> Боюсь, экономия по сравнению с while получается слабенькая, а если с усложнением, то и вовсе никакой.
Это экономит мозг, потому, что сводится к частному случаю while подпадающему под определеннвй паттерн.
> Кроме этого, foreach это, по сути, способ коммуникации с пачкой объектов. С помощью форыча вы вручную строите обмен сообщениями.
Это сообщение для объекта-коллекции.
> Насчёт имени Draw, скажу по опыту — так нагляднее. На маленькой процедуре, конечно, неощутимо, но когда работаешь над реальным проектом, то чувствуешь.
Скажу по опыту, что писать только маленькие процедуры можно. И с foreach так делаеть проще
Ну так сколько раз в день вы используете foreach?
Пишу от 0 до нескольких раз.
Читаю почаще.
Читаю код с while и сожалею, что нет foreach в этом языке — еще чаще.
Читаю почаще.
Читаю код с while и сожалею, что нет foreach в этом языке — еще чаще.
Я так и думал. Спор о преимуществах foreach свёлся к объективной неочевидности и неощутимости этих самых преимуществ.
Субъективно на уровне вкусовщины можно говорить всё, что угодно. Со своей колокольни могу сказать, что читаю и пишу код как с while, так и с foreach и сожалею, что приходится иметь в виду ещё и foreach. Лишняя нагрузка на мозг.
Субъективно на уровне вкусовщины можно говорить всё, что угодно. Со своей колокольни могу сказать, что читаю и пишу код как с while, так и с foreach и сожалею, что приходится иметь в виду ещё и foreach. Лишняя нагрузка на мозг.
Как его иметь ввиду? Это просто частный случай while. В случае while который совпадает с этим частным случаем нам надо его внимательно прочитать и убедиться что он подходит под паттерн, а в случае foreach этот паттерн явно назван.
Именно так и иметь в виду.
Для while всё единообразно. Один шаблон на всё. Мозгу так легче работать. Особенно это хорошо ощущается в конце рабочего дня или поздно вечером, когда наступает непроходимый тупняк. Лишние шаблоны только запутывают.
Если у меня строго один while, я всегда смотрю только на охрану цикла. Если же нет, то приходится держать в голове ещё и особый синтаксис foreach — со этими кошмарными break и continue.
Для while всё единообразно. Один шаблон на всё. Мозгу так легче работать. Особенно это хорошо ощущается в конце рабочего дня или поздно вечером, когда наступает непроходимый тупняк. Лишние шаблоны только запутывают.
Если у меня строго один while, я всегда смотрю только на охрану цикла. Если же нет, то приходится держать в голове ещё и особый синтаксис foreach — со этими кошмарными break и continue.
что такое «охрана цикла»? Что за язык, в котором у foreach есть break и continue, а у while нет?
Напишите как вы видите аналог этого кода:
C#
Powershell
F#
Напишите как вы видите аналог этого кода:
C#
foreach (var client in Clients.Where(x => x.Balance > 100))
{
Console.WriteLine(string.Format("Client: {0} Balance: {1} ", client.FullName, client.Balance);
}
Powershell
clients | where Balance -gt 100 | foreach { "Client: $($_.FullName) Balance:$($_.Balance)" }
F#
clients |> seq.filter (fun x -> x.Balance > 100) |> Seq.iter (fun x -> sprintf "%A %A" x.FullName x.Balance}
Спор о преимуществах foreach свёлся к объективной неочевидности и неощутимости этих самых преимуществ.
Преимущество foreach перед while огромно.
У while очень легко неправильно сдвинуть итератор (например, сделать j++ вместо i++) и впасть в бесконечный цикл. Поэтому конструкции while нужно читать очень внимательно при ревью кода. Для foreach есть уверенность, что с итераторами программист не накосячил.
Ваши слова совершенно справедливы для языков с вытребеньками типа j++. Для простого, но мощного синтаксиса ваши аргументы не подходят, потому что на Обероне вероятность допустить ошибку очень мала. Говорю вам из реального опыта.
Я думаю, если есть итератор, его можно употребить неправильно. Foreach его вообще скрывает. То есть мы абстрагируемся от способа перебора элементов. Нам не надо постоянно копировать один и тот же по сути while
Ваши слова совершенно справедливы для языков с вытребеньками типа j++.
А вы когда массив обходите, не пишете
index := index + 1;Или как насчёт итерации по списку (
p := p.next)Если итерирование зашито в коллекцию и foreach согласовано делает инициализацию, шаг итерации и проверку конца списка, нет возможности допустить ошибку, когда программист сделал шаг в одной коллекции, а условие завершения проверил у другой.
Я так полагаю, это фича чтобы правильно детектировать уровни вложенности, если вдруг забудете поставить END или напишете лишний BEGIN которым нет пары в сложном коде. Дополнительная проверка на забывчивость.
Моя точка зрения, заключается в том, что если возникла необходимость в такой фиче, значит пора рефакторить
Ну это считается за ограничение области видимости передаваемых переменных. Да и визуально, нагляднее получается — вот он END Draw; торчит, его глазами хорошо видно.
В сишарпе, например, приходится тратить дополнительные усилия, чтоб отыскивать конец метода среди этих плохо различимых фигурных скобочек.
В сишарпе, например, приходится тратить дополнительные усилия, чтоб отыскивать конец метода среди этих плохо различимых фигурных скобочек.
Если с отступами все нормально и метод умещается на экран, то никакой проблемы нет. В питоне и F# вот вообще никаких фигурных скобочек
В сишарпе, например, приходится тратить дополнительные усилия, чтоб отыскивать конец метода среди этих плохо различимых фигурных скобочек.
Да уж, прямо так сложно навести мышь на закрывающую скобку, чтобы IDE вывела шапку, к чему эта скобка относится…
Да даже без этого они, как правило, нормально выделены отсутпами. Мне чаще приходится смотреть парные круглые скобки, если выражение не очень простое.
Что-что, мышку надо двигать, чтобы прочитать код, который УЖЕ на экране?
Вы шутите?
Лично мне лень. Но это всё понятно, без костылей в виде IDE жизни нет. А в случае с Обероном мне даже не надо мышку двигать, я сразу вижу где что.
Вы шутите?
Лично мне лень. Но это всё понятно, без костылей в виде IDE жизни нет. А в случае с Обероном мне даже не надо мышку двигать, я сразу вижу где что.
Что-что, мышку надо двигать, чтобы прочитать код, который УЖЕ на экране?
Я предпочитаю работать с кодом интерактивно. Надо — посмотрел All References, надо — перешёл на определение класса или переменной, надо — посмотрел, к чему относится закрывающая скобка.
А вы хотите, чтобы вся информация была всегда видна на экране? В принципе, можно к каждой строке вывести полный namespace (в каком модуле и функции эта строка), кто на неё ссылкается, ну и для полноты — библиотечную справку по всем ф-циям из этой строки, лениво же делать дополнительные клики.
Все ветвления, циклы и обходы коллекций в Смолток реализованы замыканиями, которые дали не только #do:, но прекрасные #ifTrue:ifFalse:, #timesRepeat:, #whileTrue:, #select:, #collect;, #select:thenCollect: и иже с ними. Невероятная сила и красота замыканий в Смолтоке.
Компания Sun вложила стомиллионовденег в устаревший P-код, просто потому что Гослинг не знал другой технологии. Но вам про это не сказала, и многие думают, что байт-код представляет из себя технологическое совершенство. И продолжила вкладывать в развитие костылей, потому что без инвестиций эти станки тупо бы загнулись.
В Оберон не стали вкладывать по простой причине — на конкурентном поле лучше иметь свою историю, а не виртовскую. Вот и весь секрет «неуспешности» Оберона. Подсмотреть идеи — всегда пожалуйста, но говорить о преемственности — никогда.
В Оберон не стали вкладывать по простой причине — на конкурентном поле лучше иметь свою историю, а не виртовскую. Вот и весь секрет «неуспешности» Оберона. Подсмотреть идеи — всегда пожалуйста, но говорить о преемственности — никогда.
Несмотря на это, мейнстрим, как он есть, лучше приспособлен для решения массовых задач. Например, слепить мелкий сайтик из подпиленного распрострененного CMS и найти под него дешевый хостинг проще на php.
У мух мушиные задачи. Если их кормить шашлыком, например, они долго не протянут.
У мух мушиные задачи. Если их кормить шашлыком, например, они долго не протянут.
На последнем JPoint упоминали Оберон. У кого разум открыт, те помнят. За остальных думает кто-то другой, хэдхантер там, или модный блоггер.
За остальных думает рынок, да. А с «открытым разумом» и пустым кошельком далеко не уедешь.
Вот я и замечаю, что на протяжении многих лет аргументы оппонентов не меняются, а теперь ясно все, это просто за них рынок думает.
И на портяжении многих лет негодяй рынок так и не хочет принять такое божественное творение как «оберон». Вот неудача. Не хочет рынок отказываться от дженериков и foreach'ей, не хочет выкидывать все хорошее, как жаль. Ну чтож, остается только смириться, улыбнуться оберону и продолжать кодить на языках с foreach'ами.
Рынок не «не принял» Оберон, история ИТ в этом плане очень интересна. Рынок взял из него всё самое ценное, и продолжает черпать до сих пор.
Ну вы уж определитесь. То «рынок думает за них» — идет в разрез с вашей идеологией потому что ее критикуют, то рынок не «не принял» оберон. Сложно говорить о чем то когда вы каждые 5 минут меняете точку зрения.
Сам оберон как язык — отвергнут рынком как неконкурентноспособный. А идеи хорошие есть во всем, почему бы их не взять?
Сам оберон как язык — отвергнут рынком как неконкурентноспособный. А идеи хорошие есть во всем, почему бы их не взять?
Вы просто читайте внимательнее, что вам пишут и не домысливайте за людей. Почитайте историю ИТ, чисто для общего развития — узнаете, как выстрелил Паскаль у Борланд. Рынку нужна сложность, ведь на преодолении сложности можно сделать больше денег. А как только наступает понимание, что одними костылями не обойдёшься, то возникают такие вещи, как Go language inspired by Oberon.
Ок, если вы так правы — вернемся к разговору когда оберон наконец отхватит ну хотябы 10% рынка. Это было бы показателем успеха. Правда у меня ощущение что это не случится никогда, разве что в оберон наконец добавят высокоуровневые примитивы, тогда у него будут шансы.
Правда?! Можно список необходимых примитивов, таки добавлю до оберону.
См. в сторону движения C++17, Java 9, C# 6.0.
они — как и все остальные языки движутся в мусорку. очень ценный список :(
Насмешили. В Java9 только-только появятся модули, которые в Обероне уже 20 лет. Вы кажется, вообще в теме не разбираетесь.
Зато в этих языках есть тонны других фичей которых нету в обероне. А вы тут одну привели и считаете что это что-то опровергает? Смешно.
Ах да, форыч.
Ну Ваше мнение понятно, вы противник оберон-подхода и сторонник мейнстрим-подхода. Эта позиция обдуманная, взвешенная, и совершенно не зависит от конъюнктуры рынка. И разум открытый у Вас. ;)
Ну Ваше мнение понятно, вы противник оберон-подхода и сторонник мейнстрим-подхода. Эта позиция обдуманная, взвешенная, и совершенно не зависит от конъюнктуры рынка. И разум открытый у Вас. ;)
Итераторы, дженерики, async/await, замыкания, атрибуты — это только малый пример того что реально сильно экономит время и сложность. foreach — это достаточно простой синтаксический сахар, хотя и очень удобный.
Конечно у тех, кто стремится переложить ненужные заботы на железо — разум закрытый, у полутора оберонщиков разум открыт, но, как жаль, весь остальной мир их не принимает. Корпорации не хотят зарабатывать деньги, а люди не хотят быть более продуктивны, все от закрытого разума.
Конечно у тех, кто стремится переложить ненужные заботы на железо — разум закрытый, у полутора оберонщиков разум открыт, но, как жаль, весь остальной мир их не принимает. Корпорации не хотят зарабатывать деньги, а люди не хотят быть более продуктивны, все от закрытого разума.
Это вы насмешили. «Модули» из Java9 — это всего лишь особая схема раскладывания исходного кода по папочкам, ей даже поддержка в компиляторе не особо и нужна.
То, что в Обероне называется «модуль», в Java называется «package» — и присутствует там с рождения, так же как и модули в Обероне.
То, что в Обероне называется «модуль», в Java называется «package» — и присутствует там с рождения, так же как и модули в Обероне.
Чем вас например не устраивает generics в составе языка? По мимо всего прочего они выполняют очень важную функцию — не дают запихивать в таблицы, словари, самописные классы объекты не подходящего класса. А нормальная среда разработки укажет на ошибку еще в процессе написания кода. В ином случае разработчику придется тратить время в поисках ошибки во время отладки, а это гораздо дороже по времени.
Когда лично Вы начнете писать на Обероне в продакшн, тогда и отхватит.
Ну значит никогда. Т.к. я начну писать только тогда когда язык станет на равне с другими и будет представлять для меня какой-то интерес. Пока что ему до других как до луны пешком.
Ну в общем ясно, вы рассуждаете о том, о чем ничего не знаете.
Пишите лучше на диезе habrahabr.ru/post/258249
Пишите лучше на диезе habrahabr.ru/post/258249
Рынок завоёвывают не техническим совершенством, а сотнями миллионами долларов, вложенных в рекламу. Запомните это.
Можно вложить миллиард долларов в лажу, и ничего из этого не выйдет. Если изначально продукт — фигня, то и миллиард не поможет. А если продукт стоящий — инвесторы найдутся, ведь на стоящем продукте можно и 100 миллионов и 10 миллиардов отбить назад с процентами.
Вы всегда правы.
И 100 триллиардов, конечно. Ваша твёрдая вера в непогрешимость рынка священна. Мне остаётся почтительно умолкнуть.
В рынок не нужно верить, он просто работает. Вне зависимости от веры в него. Веру обычно требует то, что не работает.
Да, конечно, он работает. Только не так, как вам кажется.
А он работает так как вам кажется?
Вы тут приходите и говорите «у меня есть волшебная пилюля», которая снизит число ошибок в коде и вообще сделает все хорошо. Т.е. по сути говорите что ваш язык позволит заработать больше денег (если нет — то он нафиг не нужен по определению). За счет чего он позволит заработать больше денег? Синтаксис у него дико примитивен, все фичи выкинуты, значит мне придется писать это самостоятельно, значит это повышает вероятность ошибок. Ок, может на этом языке писать быстрее получится? Нет не получится, даже наоборот — намного дольше. Может у него скорость выполнения бинарников может быть выше благодаря каким-то хитростям языка? Нет, не может. Так вопрос, в чем этот язык поможет условной компании или программисту заработать больше денег? Тем, что синтаксис легче выучить? Так программирование это синтаксис только на несколько процентов, остальное — библиотеки, паттерны, практики, алгоритмы, умение писать читаемый код и т.д… А синтаксис учится довольно быстро, так что тоже мимо. Вы утверждаете что избегаете ошибок с неправильным использованием синтаксического сахара — но это ошибки уровня новичков, человек работающий с языком допускает подобные ошибки на уровне погрешности, зато вы предлагаете весь синтаксический сахар писать руками, что уже приводит к большему числу ошибок. Я так и не вижу, где оберон мне помогает то?
Вы тут приходите и говорите «у меня есть волшебная пилюля», которая снизит число ошибок в коде и вообще сделает все хорошо. Т.е. по сути говорите что ваш язык позволит заработать больше денег (если нет — то он нафиг не нужен по определению). За счет чего он позволит заработать больше денег? Синтаксис у него дико примитивен, все фичи выкинуты, значит мне придется писать это самостоятельно, значит это повышает вероятность ошибок. Ок, может на этом языке писать быстрее получится? Нет не получится, даже наоборот — намного дольше. Может у него скорость выполнения бинарников может быть выше благодаря каким-то хитростям языка? Нет, не может. Так вопрос, в чем этот язык поможет условной компании или программисту заработать больше денег? Тем, что синтаксис легче выучить? Так программирование это синтаксис только на несколько процентов, остальное — библиотеки, паттерны, практики, алгоритмы, умение писать читаемый код и т.д… А синтаксис учится довольно быстро, так что тоже мимо. Вы утверждаете что избегаете ошибок с неправильным использованием синтаксического сахара — но это ошибки уровня новичков, человек работающий с языком допускает подобные ошибки на уровне погрешности, зато вы предлагаете весь синтаксический сахар писать руками, что уже приводит к большему числу ошибок. Я так и не вижу, где оберон мне помогает то?
Вам оберон и не может помочь, ведь вы его не используете. К чему вся эта схоластика?
Насчёт рынка, вы хотя бы историей Java поинтересуйтесь. Сколько они денег вложили в свои костыли, прежде чем продукт стал представлять из себя то, что представляет сейчас.
Ну и вы с упорством, достойным лучшего применения, продолжаете путать простоту с примитивностью.
Про волшебную пилюлю говорите только вы, про «всё хорошо». Это говорит о том, что вы не понимаете того, что вам объясняют. Дальше тратить на вас время я отказываюсь.
Скажу только, что вы делаете большую ошибку, хотя и естественную для всех программистов, которые имеют опыт только на формальных системах и бездумно переносят этот опыт на неформальные системы, такие как рынок. Подумайте об этом.
Насчёт рынка, вы хотя бы историей Java поинтересуйтесь. Сколько они денег вложили в свои костыли, прежде чем продукт стал представлять из себя то, что представляет сейчас.
Ну и вы с упорством, достойным лучшего применения, продолжаете путать простоту с примитивностью.
Про волшебную пилюлю говорите только вы, про «всё хорошо». Это говорит о том, что вы не понимаете того, что вам объясняют. Дальше тратить на вас время я отказываюсь.
Скажу только, что вы делаете большую ошибку, хотя и естественную для всех программистов, которые имеют опыт только на формальных системах и бездумно переносят этот опыт на неформальные системы, такие как рынок. Подумайте об этом.
Вам оберон и не может помочь, ведь вы его не используете.Так я и прошу описать как бы он мог мне помочь, но похоже аргументов просто нету, потому что помочь он никак не может.
продолжаете путать простоту с примитивностью.Формальное описание разницы между простотой и примитивностью в студию пожалуйста, желательно с доказательством. Мое мнение хотябы подкреплено историей, логикой работы рынка и большинством программистов, которые делают выбор в пользу богатых языков.
Скажу только, что вы делаете большую ошибку, хотя и естественную для всех программистов,Т.е. все ошибаются, один вы Д'Артаньян?
Я тут нашел лохматую тему на rsdn где аналогичный «пророк оберона» пытался толкать аналогичную чушь (http://rsdn.ru/forum/flame/1214478), тема похоже не нова, раз в несколько лет появляется новый «пророк оберона» и пытается наставить всех «на путь истинный».
Вы пробовали компилить оберон-программы?
Автокод Эльбрус. Эль-76. Принципы построения языка и руководство к использованию
r2vr.ru/doku.php?id=эль-76
Не путайте кастыли мелкомяхких и кривых реализаций языков программирования и синтаксический сахар. Все уже было придумано до нас.
r2vr.ru/doku.php?id=эль-76
Не путайте кастыли мелкомяхких и кривых реализаций языков программирования и синтаксический сахар. Все уже было придумано до нас.
А рефлексия не нужна в составе языка.
IOC-container, Mock-объекты, Dynamic Proxy, ORM в своей реализации используют рефлексию. И если уметь ими пользоваться, то они избавляют от рутинной работы. Также, рефлексия может быть полезна при написании своих мини-фреймворков. Например, передать лямбда-выражением переменную, а рефлексией получить её имя для логирования и рефлексией установить значение этой переменной. Конечно, рутинную работу можно проделать и самому, но быстрее и проще воспользоваться инструментом.
Борьба со сложностью задач сложностью инструментов, с помощью которых эти задачи решаются. Конечно, многие от этого выигрывают. Зарплаты растут.
Это наивное детское представление о мире. Зарплата не зависит ни от пользы работы, ни от её сложности. Она зависит от того, за какую зарплату другие люди согласны делать ту же самую работу. Даже если все программисты сговорятся и не будут использовать сложные инструменты, но при этом автоматизировать процессы всё равно будет выгоднее, чем делать вручную, то зарплаты не изменятся. Кроме того, заказчику безразлично, с использованием каких инструментов написана программа. Ему важна лишь скорость написания, стоимость сопровождения, надёжность, цена и актуальность тех задач, которые решает программа. И эти факторы (помимо актуальности задач) успешнее достигаются, как ни странно, квалифицированными программистами, владеющими нужными инструментами. Конечно, можно рутинную работу и вручную делать, но скорость написания упадёт и стоимость сопровождения увеличится. Поэтому нанять одного квалифицированного программиста выгоднее, чем парочку неквалифицированных (даже если они согласны работать только за большую зарплату). Кроме того, квалифицированные спецы зачастую способны делать то, что неквалифицированные не способны сделать в принципе. Поэтому у них и зарплата выше, и дело вовсе не в мировом заговоре программистов, специально делающих сложные инструменты.
Вы процитировали мою фразу о том, что рефлексия не нужна в составе языка.
Далее вы рассуждаете так, как будто я отрицаю необходимость рефлексии вообще. Это неверно. Библиотечных функций достаточно, на самом деле. Даже лучше, если такой хитрый механизм будет изолирован от языка, все равно почти никогда корпорации не угадают с набором примитивов.
Далее вы рассуждаете так, как будто я отрицаю необходимость рефлексии вообще. Это неверно. Библиотечных функций достаточно, на самом деле. Даже лучше, если такой хитрый механизм будет изолирован от языка, все равно почти никогда корпорации не угадают с набором примитивов.
Библиотечных функций достаточно, на самом деле. Даже лучше, если такой хитрый механизм будет изолирован от языка
Hibernate — родоначальник современных ORM, был написан энтузиастами в рамках опенсорсного проекта. Я не силён в истории, но уверен что с IOC-контейнером, Mock-объектами, Dynamic Proxy была примерно такая же история. Это стало возможно благодаря тому, что в языке была такая фича, как рефлексия. Это теперь для вас это библиотечная функция. Но чтобы их написание было возможно, эта фича в языке была необходима. Кроме того, рефлексия нужна и рядовым программистам. Например, сейчас я делаю удобную предобработку вызовов сервисов на общей шине, используя Dynamic Proxy, в Interceptor-е вызываю нужную функцию при помощи постороения ExpressionTree. Проще было бы вызвать через рефлексию, но тогда быстродействие просядет. Если бы в языке не было ни рефлексии, ни ExpressionTree, то пришлось бы вручную писать класс-обёртку вокруг каждого сервиса, проксируя вызов каждого метода.
Какие корпорации? Давайте отделим техническую дискуссию от всех этих теорий заговора, здесь им не место. Рефлексия — это естественный механизм получения метаинформации от компилятора. Если поддержки компилятора нет — то и рефлексии нет, и НИКАКАЯ библиотека не способна извлечь информацию, которой у нее нет и быть не может, пока компилятор ее не предоставит. Неужели это так сложно понять?
Неужели вам так сложно понять, что компилятор может быть построен таким образом, что оставляет информацию о типах и прочем в получившемся продукте компиляции без конкретной цели использования. Или цель может отличаться от вашей. А уже потом эта информация может использоваться библиотекой рефлексии. А может и не использоваться. Более того, этой информации может и не быть. Целый куст возможностей.
Вы так самоуверенно отсекаете кучу вариантов, а потом обвиняете других в непонимании. Мир интереснее, чем вам кажется.
Вы так самоуверенно отсекаете кучу вариантов, а потом обвиняете других в непонимании. Мир интереснее, чем вам кажется.
Так это и есть языковая поддержка рефлексии. Ничего другого кроме предоставления информации от компилятора и не нужно.
Ну вы продолжаете придерживаться вашего расширенного трактования языка, отталкиваясь от компилятора и его фич, а не от определения языка. Если коллега рассуждает иначе, то вы никогда друг друга не поймете.
В определении языка Оберон говорится только о необходимости добыть процедуру по имени. Но при этом никак не оговаривается, что нужно это делать средствами языка или компилятора. И это правильно, в целом. Потому что язык не резиновый.
Непонятно, что значит
Есть язык, который грубо говоря, оговаривает синтаксис кода. Есть компилятор, который выполняет некоторые действия над простым текстовым файлом и получает исполняемый файл. Если язык имеет средство что-либо делать, то компилятор обязан это реализовывать. Если компилятор реализовывает какую-либо функциональность, то эта функциональность также входит и в язык.
. Но при этом никак не оговаривается, что нужно это делать средствами языка или компилятора.
Есть язык, который грубо говоря, оговаривает синтаксис кода. Есть компилятор, который выполняет некоторые действия над простым текстовым файлом и получает исполняемый файл. Если язык имеет средство что-либо делать, то компилятор обязан это реализовывать. Если компилятор реализовывает какую-либо функциональность, то эта функциональность также входит и в язык.
Ну и где тут разделение сущностей? Описание языка описывает ровно то, что должно, сам язык. Проблема в том, что кто-то в язык готов запихнуть все подряд, а кто-то нет.
При этом реальное отношение разных проблем к языку никакого значения не имеет, мы же заботимся о многом сразу, в итоге все равно ничего не получается.
Помимо compile time еще runtime, и еще linktime, которые не обязаны быть оговорены в описании языка. Если вы в языке описываете, как компилятор будет двигать и паковать байты, то всё, закапывайте, у вас байты с уровня железа просочились на абстрактный уровень описания языка. Если компилятор оставил линкеру метаинформацию, это еще не значит, что в языке появилась интроспекция.
Давайте все же разделять сущности.
При этом реальное отношение разных проблем к языку никакого значения не имеет, мы же заботимся о многом сразу, в итоге все равно ничего не получается.
Помимо compile time еще runtime, и еще linktime, которые не обязаны быть оговорены в описании языка. Если вы в языке описываете, как компилятор будет двигать и паковать байты, то всё, закапывайте, у вас байты с уровня железа просочились на абстрактный уровень описания языка. Если компилятор оставил линкеру метаинформацию, это еще не значит, что в языке появилась интроспекция.
Давайте все же разделять сущности.
Как только мы абстрагируем формальный аппарат («язык», о как прав был Дейкстра, говоря, что называть язык программирования языком неправильно!) от конкретного исполнителя, то перестаём видеть компилятор. Остаются лишь требования к среде выполнения (которая не обязана зависеть от аппаратуры).
Как тогда называть 'язык программирования'? Да и что в него входит? Правила синтаксиса+ набор стандартных библиотек и требований к среде выполнения или что-то еще?
Это очень интересная, на мой взгляд, тема. Дейкстра рассматривал ЯП как машинный код для абстрактного вычислителя. Вот ещё тексты Дейкстры по теме:
www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html
www.beroal.in.ua/article/dijkstra/ewd854.html
www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD667.html
www.beroal.in.ua/article/dijkstra/ewd854.html
Экосистема.
Если под 'языком программирования' подразумевать экосистему, то любой более менее используемый язык стремиться усложняется по мере использования.
Его начинают использовать для какой-либо деятельности. Программы разрастаются. Из них выделяют библиотеки. Самые часто используемые библиотеки становятся стандартными и входят тем самым в 'язык'. Простым 'язык' может оставаться только если не используется.
Его начинают использовать для какой-либо деятельности. Программы разрастаются. Из них выделяют библиотеки. Самые часто используемые библиотеки становятся стандартными и входят тем самым в 'язык'. Простым 'язык' может оставаться только если не используется.
Простым (но не примитивным!) язык может остаться, если концепции, в нём формализованные, проработаны очень тщательно.
Как язык может остатся простым, если количество кода написаного на нем будет расти? Появление больших стандартных библиотек практически неизбежно, если на этом языке пишут десятки тысяч людей. Им просто надо как-то координироватся друг с другом, чтобы не писать велосипеды заново.
А ведь именно библиотеки, а не синтаксис языка составляет подавляющую часть сложности языка.
А ведь именно библиотеки, а не синтаксис языка составляет подавляющую часть сложности языка.
Нет необходимости следовать моде и втыкать всё новые фичи в язык. Вы прекрасно сможете строить хороший софт и без вытребенек.
Зато с новыми фичами вы в ряде случаев можете подсократить количество кода который требуется написать. Или просто не использовать новую фичу, если она вам не подходит.
Это как люди, которые считают владельцев авто с автоматической трансмиссией «лохами», типа «я учился ручку дергать и умею это делать, а что это он вот взял и поехал вот так». Тут то же самое «я учился без этих всяких ваших foreach, а тут вот оно — любой студент быстрее меня программирование осваивает с этими новомодными выкрутасами». К счастью, что бы они не кричали, в мейнстрим подобные языки уже никогда не попадут.
Предметных областей бесчисленное множество. Вам не хватит фантазии на все фичи, а если и хватит, то компилятор лопнет. Ну а если компилятор выдержит, вряд ли ваша голова осилит их все держать :)
Нет, у Дейкстры — появляется новый уровень абстракции(новый ассемблер, новый язык...). То болото в которое мы угодили — это результат интегрирования разных уровней в одном языке, на базе одного синтаксиса ( например — LINQ прикольный костыль, или интерпретатор printf в 'с', одновременно массивы и std::vector в c++)
Бьёрн Страуструп:
«Язык программирования служит двум связанным между собой целям: он является выразительным средством программиста для указания действий, которые надо выполнить, а также набором концепций, которыми пользуется программист при решении проблемы.»
Нет, это не правильно. На все должна быть прописана четкая спецификация, иначе мы погрязнем в несовместимостях и Undefined Behaviour.
А иначе вы погрязнете в низкоуровневых деталях реализации, которые помешают кроссплатформенности, например.
Речь идет не о деталях реализации, а о четком разграничении функциональности между слоями этой реализации — что делается в компиляторе, а что в стандартной библиотеке.
И кстати, первый раз сталкиваюсь с такой терминологией
Что вы имеете в виду? Получение ссылки на процедуру во время выполнения программы по динамической строке с именем?
добыть процедуру по имени
Что вы имеете в виду? Получение ссылки на процедуру во время выполнения программы по динамической строке с именем?
Да.
Можете привести пример на обероне как это делается?
В системе есть модуль Dialog. У него есть процедура Call со строковым параметром. Вызываем Dialog.Call(«Kernel.Beep»)
Строка разбивается на имя модуля и имя процедуры, в списке модулей ищется экземпляр типа Module с именем «Kernel», соответствующий модулю Kernel, потом у этого экземпляра в списке экспортированных процедур ищется процедура «Beep», адрес которой присваивается процедурной переменной того же типа, что и Beep, и потом происходит вызов этой переменной процедурного типа.
По теме имеем, что в описании языка ни слова про рефлексию, а она есть.
Строка разбивается на имя модуля и имя процедуры, в списке модулей ищется экземпляр типа Module с именем «Kernel», соответствующий модулю Kernel, потом у этого экземпляра в списке экспортированных процедур ищется процедура «Beep», адрес которой присваивается процедурной переменной того же типа, что и Beep, и потом происходит вызов этой переменной процедурного типа.
По теме имеем, что в описании языка ни слова про рефлексию, а она есть.
Паазвольте. Oberon Language Reference всегда включает в себя раздел с требованиями к среде выполнения. То бишь, по Дейкстре, к абстрактному компьютеру, машинным кодом к которому является данный ЯП.
А в требованиях к среде выполнения, кроме всего прочего, есть и такое (для примера, из LR CP):
А в требованиях к среде выполнения, кроме всего прочего, есть и такое (для примера, из LR CP):
Appendix D: Mandatory Requirements for Environment
The Component Pascal definition implicitly relies on four fundamental assumptions.
1) There exists some run-time type information that allows to check the dynamic type of an object. This is necessary to implement type tests and type guards.
Спасибо, интересно. Но это не рефлексия, а динамическая загрузка библиотек (будущий boost.dll), тоже важная фича, но другое.
Но ведь рефлексия так и работает в java/c#
Компилятор оставляет мета-информацию, а через функции стандартной бублиотеки можно найти и использовать эту информацию.
Никаких встроенных в язык синтаксических конструкций.
Чем это хуже/лучше Оберона?
Компилятор оставляет мета-информацию, а через функции стандартной бублиотеки можно найти и использовать эту информацию.
myObject.GetType().GetMethod("SomeMethod").Invoke(myObject, paramsArray);
typeof(myType).GetMethod("SomeStaticMethod").Invoke(paramsArray);Никаких встроенных в язык синтаксических конструкций.
Чем это хуже/лучше Оберона?
Неудивительно, что много похожего, ведь Sun внимательно смотрела на Оберон перед постройкой Java, а Microsoft для построения дотнета приглашала лучших оберонщиков.
В таком случае имеем вопрос — о чем вообще тут спор? Если в C# и Java рефлексия взята из Оберона, то какая еще рефлексия существует и критикуется в этой ветке?
Никто не сравнивает, просто речь шла о том, что считать рефлексией в языке, а что — рефлексией внеязыковой, и существует ли такая.
По мне, это как прямая и имплицитная зависимости. И то, и другое зависимости, но есть нюансы.
По мне, это как прямая и имплицитная зависимости. И то, и другое зависимости, но есть нюансы.
Почему вы TCL не проповедуете? Там правил именно что языка — пол-страницы, остальное библиотека. И можете сами себе сделать хоть язык с русскоязычными ключевыми словами, хоть что.
И эти факторы (помимо актуальности задач) успешнее достигаются, как ни странно, квалифицированными программистами, владеющими нужными инструментами.Это т.н. систематическая ошибка выжившего. Ни вы, ни я не знаем реальных раскладок вложений ресурсов в продвижение на начальных этапах таких языков как Java или С++ (Микрософт по слухам вкладывалась в его продвижение с самого начала Windows), то, что они благодаря скрытым механизмам выжили и получили ресурсы на полноценное развитие не делает их более пригодными для решения задач. Даже квалифицированными программистами. Очень позитивный сценарий вы описали.
то, что они благодаря скрытым механизмам выжили и получили ресурсы на полноценное развитие не делает их более пригодными для решения задач
То, что инструменты при грамотном использовании ускоряют разработку — факт, проверенный на практике. Попробуйте каждый раз вручную мапить результаты запроса к бд на ваши объекты или искать чужие ошибки работы с памятью в С++.
Возможно, если бы не эти сложные инструменты, итоговая архитектура была бы продумана лучше и проще. Но раз ускоряет, то что поделать.
Грамотно спроектированный формализм не порождает «чужих ошибок работы с памятью», а следовательно, избавляет вас от лишней работы по преодолению дополнительной сложности.
Не ограничить а минимизировать. Вот было бы замечательно если помимо 6-гранных болтов и гаек были бы треугольные и например 5 или деже 7-гранные. Для каждого типа гаек надо иметь отдельный инструмент… и тут кто-то придумывает 8-гранную гайку с неравномерно распределенными гранями… под неё выпускается целая серия инструментов, а в мастерских появляется еще один ящик с инструментом.
И по какому-то недоразумению, все механизмы начинают клепать как минимум с 3-мя видами гаек, а какие 3 из 21 узнаете когда начнёте его ремонтировать.
И по какому-то недоразумению, все механизмы начинают клепать как минимум с 3-мя видами гаек, а какие 3 из 21 узнаете когда начнёте его ремонтировать.
Спартанский BlackBox Component Builder по нетребовательности к ресурсам бежит далеко впереди MonoDevelop (на компе стоят оба, могу сравнивать). Правда BlackBox настолько суров, что не каждый избалованный программист может в него (хотя сделан он по заветам Дж. Раскина, монотонный интерфейс, гипертексты, вот это всё).
Я последнее время заметил возрождение и интереса к классическим Pascal, Oberon, Smalltalk, видимо некоторые люди уже успели разочароваться в C++/Java/Etc. Хотя, возможно показалось.
Нет, не думаю. Просто некоторые старые языки — такие например как Smalltalk — могут содержать немало интересных идей, поэтому иногда здесь появляются статьи, и мы их с удовольствием читаем…
Как раз недавно обсуждали Smalltalk. Думаю, дело даже не в идеях, их можно сколько угодно выдумать, а в условиях существования андеграундных экосистем типа оберон- или смоллток-сообществ. Со стороны лучше видно ситуацию в отрасли, потому что бизнес-процессы не затягивают в бездумную гонку за возможностями и усложнением. Есть время подумать, скажем так.
Выше уже приводили пример на аналитические выкладки Губанова про синтаксис.
Выше уже приводили пример на аналитические выкладки Губанова про синтаксис.
Если говорить о простом языке высокого уровня, то я бы привел в пример Lua. Если взять типы данных, то там их минимум — числа, строки, функции, таблицы. При этом таблица — это и ассоциативный массив, и линейный массив, и объект с методами и полями. Нужна фича из другого языка? Написал сверху несколько строк.
Мне кажется что многие люди подсознательно ставят знак равенства между понятиями «простой» и «легкий». Вот например язык Forth обладает очень простым синтаксисом. Фактически в нем вся программа это просто набор слов (под которыми скрыт аналог вызова функции с неявной передачей параметров через стек). Но вот написать на нем достаточно большую программу занятие далеко не легкое.
Простые по синтаксису языки позволяют гораздо лучше контролировать производимые действия на низком уровне, т.е. мы можем детально разобрать применяемый алгоритм, распределение памяти, затраты машинного времени и прочее. Но оборотной стороной является необходимость писать очень много кода несущественного для основного алгоритма задачи, но требуемого для связки низкоуровневых инструкций. Так в Forth нужно тратить силы на манипуляции с порядном данных в стеке, а в Oberon следить за вложенностью циклов и выходом индексов за границы массивов, в то время как весь полезный алгоритм можно описать парой или тройкой комбинаций MapReduce.
Но с другой стороны, понять какой-то кусок современной программы на Lisp, JavaScript или Java/C# без понимания что скрыто за применяемыми абстракциями практически невозможно. А уж тем более затруднительно оценить ресурсоемкость таких программ. Наверно поэтому языки со сборкой мусора очень трудно проникают в программирование систем реального времени.
Фактически наличие дополнительных синтаксических конструкций приводит к проблеме любого DSL. Он вроде бы облегчает написание, пока задача укладывается в его возможности и хорошо ложится на его конструкции, но совсем не упрощает поиск причин проблем возникающих в скрытом слое или реализацию задач не вписывающихся в его парадигму.
А так как, семантика решаемых задач практически бесконечна, то и лавину фреймворков, «сахарных» конструкций, библиотек API и прочее, прочее, прочее… остановить вряд ли возможно.
Но, может быть, решение не в рамках создания универсальных языков, вынуждающих или писать много низкоуровневого кода или изучать внутреннее строение монструозных фреймворков? Почему не возложить на среду разработки генерацию любого промежуточного кода («промежуточный» — это код связанный с передачей и преобразованием данных от одного модуля или функции к другим). Возражения о не оптимальности кода созданного автоматически это лишь признак плохого проектирования системы автогенерации. А нам лишь нужен язык достаточно простой для автоматизации типовых операций, передачи параметров, комбинирования функций и построению сложных объектов из более простых (т.е. с упором на контейнеры, а не наследуемые объекты). И тогда, основной алгоритмы задачи можно описать очень просто, а вся сложность перенесется на логический вывод автогенерируемого кода.
Простые по синтаксису языки позволяют гораздо лучше контролировать производимые действия на низком уровне, т.е. мы можем детально разобрать применяемый алгоритм, распределение памяти, затраты машинного времени и прочее. Но оборотной стороной является необходимость писать очень много кода несущественного для основного алгоритма задачи, но требуемого для связки низкоуровневых инструкций. Так в Forth нужно тратить силы на манипуляции с порядном данных в стеке, а в Oberon следить за вложенностью циклов и выходом индексов за границы массивов, в то время как весь полезный алгоритм можно описать парой или тройкой комбинаций MapReduce.
Но с другой стороны, понять какой-то кусок современной программы на Lisp, JavaScript или Java/C# без понимания что скрыто за применяемыми абстракциями практически невозможно. А уж тем более затруднительно оценить ресурсоемкость таких программ. Наверно поэтому языки со сборкой мусора очень трудно проникают в программирование систем реального времени.
Фактически наличие дополнительных синтаксических конструкций приводит к проблеме любого DSL. Он вроде бы облегчает написание, пока задача укладывается в его возможности и хорошо ложится на его конструкции, но совсем не упрощает поиск причин проблем возникающих в скрытом слое или реализацию задач не вписывающихся в его парадигму.
А так как, семантика решаемых задач практически бесконечна, то и лавину фреймворков, «сахарных» конструкций, библиотек API и прочее, прочее, прочее… остановить вряд ли возможно.
Но, может быть, решение не в рамках создания универсальных языков, вынуждающих или писать много низкоуровневого кода или изучать внутреннее строение монструозных фреймворков? Почему не возложить на среду разработки генерацию любого промежуточного кода («промежуточный» — это код связанный с передачей и преобразованием данных от одного модуля или функции к другим). Возражения о не оптимальности кода созданного автоматически это лишь признак плохого проектирования системы автогенерации. А нам лишь нужен язык достаточно простой для автоматизации типовых операций, передачи параметров, комбинирования функций и построению сложных объектов из более простых (т.е. с упором на контейнеры, а не наследуемые объекты). И тогда, основной алгоритмы задачи можно описать очень просто, а вся сложность перенесется на логический вывод автогенерируемого кода.
Любая, даже малая генерация кода лишает вас контроля над кодом. Генерацию SQL когда-то тоже считали прорывом, но быстро наткнулись на то, что лучше писать руками.
Если делать генерацию кода как следует, то все будет ОК. Просто до сих пор нормально никто не сделал, делали тупо «в лоб». Как минимум, при генерации кода обязательно должна создаваться метаинформация о связи генерирующего и сгенерированного кода, и активно использоваться при отладке и даже при редактировании кода.
Пока сочинял свой ответ Вы уже написали. Я с Вами полностью согласен. Пора заставить компьютер думать за меня там, где он сможет это сделать. Т.е. там где возможен логический анализ. Ведь если сейчас компиляторы оптимизируют код чуть ли не лучше профессионалов ассемблера, то почему не перенести эти подходы на более высокий уровень.
Просто на сегодняшний момент все известные мне системы кодогенерации работают просто как трансляторы из одной формальной модели в другую, совершенно не занимаясь оптимизациями. Т.е. фактически они работают как макроязыки. Что приводит либо к необходимости написания сложной и подробной первоначальной модели (а тогда и упрощение от такого средства сомнительна), либо к избыточности и неэффективности порождаемого кода.
Именно из-за формального подхода падает эффективность различных ORM, когда запрос работающий с несколькими объектами превращается в тормозного монстра из мешанины мелких SQL запросов. Хотя если написать такой запрос с учетом всех возможностей SQL, то размер и производительность улучшаются на порядок. А всего лишь надо, чтобы система могла произвести не только синтаксический, и даже не только семантический, но и логический разбор входного кода и произвела его оптимизацию (например, абстрактно, вместо двух одинаковых циклов по разным полям объединила эти запросы в один)
И так со всем остальным. Все в выводе кода, что можно описать в виде логических правил на языке типа Пролога, должно быть описано и выводится автоматом, а не заставлять программиста писать тонны связующего кода.
За мной должно остаться только придумывание общего алгоритма, выбор дополнительных функциональных блоков, возможность внести изменения в сгенерированный код и интерфейс.
Причем язык должен быть спроектирован так, что мои изменения встраиваются в базу фактов и учитываются при новом логическом выводе. Например, если автогенератор применил алгоритм сортировки пузырьком, а я изменил на сортировку вставками, то в следующий раз он тоже отсортирует также. Если я определил дополнительный блок проверки прав доступа к базе, то он должен автоматически встроиться во все места где происходит доступ, без необходимости мне писать вручную хоть строчку.
Т.е. моя формула нового даже не языка, а среды разработки = минимальный синтаксис + аспектное программирование + логическое программирование + неявная передача параметров с их автоподстановкой.
Вот такие вот фантазии :)
Именно из-за формального подхода падает эффективность различных ORM, когда запрос работающий с несколькими объектами превращается в тормозного монстра из мешанины мелких SQL запросов. Хотя если написать такой запрос с учетом всех возможностей SQL, то размер и производительность улучшаются на порядок. А всего лишь надо, чтобы система могла произвести не только синтаксический, и даже не только семантический, но и логический разбор входного кода и произвела его оптимизацию (например, абстрактно, вместо двух одинаковых циклов по разным полям объединила эти запросы в один)
И так со всем остальным. Все в выводе кода, что можно описать в виде логических правил на языке типа Пролога, должно быть описано и выводится автоматом, а не заставлять программиста писать тонны связующего кода.
За мной должно остаться только придумывание общего алгоритма, выбор дополнительных функциональных блоков, возможность внести изменения в сгенерированный код и интерфейс.
Причем язык должен быть спроектирован так, что мои изменения встраиваются в базу фактов и учитываются при новом логическом выводе. Например, если автогенератор применил алгоритм сортировки пузырьком, а я изменил на сортировку вставками, то в следующий раз он тоже отсортирует также. Если я определил дополнительный блок проверки прав доступа к базе, то он должен автоматически встроиться во все места где происходит доступ, без необходимости мне писать вручную хоть строчку.
Т.е. моя формула нового даже не языка, а среды разработки = минимальный синтаксис + аспектное программирование + логическое программирование + неявная передача параметров с их автоподстановкой.
Вот такие вот фантазии :)
Извиняюсь, но кто наткнулся? Я за последние несколько лет писал на «сыром» SQL только рекурсивные запросы и частично миграции — для всего же остального я не вижу никаких отличий между сгенерированным кодом и написанным руками в плане производительности (хотя проверяю скорость работы генерированных запросов регулярно).
А я бы предложил вспомнить еще язык APL, вот где была эталонность с точки зрения минимума символов и, соответственно, строк кода.
Правда, понять эти одно-строчные конструкции можно было не всегда и не везде, зато как компактно! Интересно, кто-нибудь его вообще использует до сих пор?
Так что, с одной стороны, «миллионы мух не могут ошибаться», а, с другой, «критерий истины-практика». А истина, как всегда, лежит посередине.
Правда, понять эти одно-строчные конструкции можно было не всегда и не везде, зато как компактно! Интересно, кто-нибудь его вообще использует до сих пор?
Так что, с одной стороны, «миллионы мух не могут ошибаться», а, с другой, «критерий истины-практика». А истина, как всегда, лежит посередине.
Несмотря на интенсивное развитие ИТ, главный вопрос всегда стоит ребром: как быстро и аккуратно строить надёжные расширяемые системы? С одной стороны у нас компьютер, возможностей которого никогда не хватает; а с другой стороны бесконечно сложные предметные области.
Здесь можно увидеть два варианта:
1) запихнуть все концепции всех предметных областей в язык, получив таким образом единый стандарт в виде гигантского монстра, поддержка и развитие которого стоит очень недёшево, а избавление от ошибок никогда не прекратится.
2) выделить из всех предметных областей только самые базовые концепции и заложить их в язык, оставив нарастающую сложность предметных областей «за бортом», в виде сменных модулей. Получаем сверхнадёжное ядро с возможностью наращивания сколь угодно сложного «мяса», не теряя при этом ощущения «железа».
Есть ещё и третий вариант, «каждый язык для своей предметной области», но это уже скорее к DSL относится.
Здесь можно увидеть два варианта:
1) запихнуть все концепции всех предметных областей в язык, получив таким образом единый стандарт в виде гигантского монстра, поддержка и развитие которого стоит очень недёшево, а избавление от ошибок никогда не прекратится.
2) выделить из всех предметных областей только самые базовые концепции и заложить их в язык, оставив нарастающую сложность предметных областей «за бортом», в виде сменных модулей. Получаем сверхнадёжное ядро с возможностью наращивания сколь угодно сложного «мяса», не теряя при этом ощущения «железа».
Есть ещё и третий вариант, «каждый язык для своей предметной области», но это уже скорее к DSL относится.
Здравствуйте, я с Обероном знаком поверхностно (читал первое описание языка — кажется, в конце 80-х, немного следил за новостями, которые довольно редки), но в университетские годы реализовывал в студенческом коллективе Модулу-2 и немного писал прикладной софт на ней. Я предварил данный комментарий этим вступлением в попытке вас заинтересовать до степени получения ответного комментария — убедить в серьёзности моих двух вопросов:
№1: Существуют ли (и, если не существуют, планируются ли кем-либо) для Оберона средства автоматизированного доказательства правильности кода? (для примера — вот недавняя история про планомерное применение такого средства к стандартным функциями Java: habrahabr.ru/post/251751)
№2: Рассматривает ли кто-либо в Оберон-сообществе идею создания «богатой» педагогической направленности системы с Обероном в качестве языка, на котором пишут код ученики? Я недавно поверхностно исследовал тему и обнаружил, что из «взрослых» ЯП (т.е. вычёркивая Scratch и подобные системы «только для детей») наиболее богато в этой роли используются JavaScript (на Khan Academy, прежде всего) и Пайтон (что, на мой взгляд, не так уж сильно отличается от JavaScript). Пояснение насчёт эпитета «богатой» — легкодоступной для детей / непрофессионалов и естественно поддерживающей социализацию учебного / творческого процесса, как и продуктивную самостоятельную работу учеников без людей-менторов / с минимальным вложением сил менторов (эти аспекты обеспечивают успех и ценность сайтов калибра Khan Academy).
№1: Существуют ли (и, если не существуют, планируются ли кем-либо) для Оберона средства автоматизированного доказательства правильности кода? (для примера — вот недавняя история про планомерное применение такого средства к стандартным функциями Java: habrahabr.ru/post/251751)
№2: Рассматривает ли кто-либо в Оберон-сообществе идею создания «богатой» педагогической направленности системы с Обероном в качестве языка, на котором пишут код ученики? Я недавно поверхностно исследовал тему и обнаружил, что из «взрослых» ЯП (т.е. вычёркивая Scratch и подобные системы «только для детей») наиболее богато в этой роли используются JavaScript (на Khan Academy, прежде всего) и Пайтон (что, на мой взгляд, не так уж сильно отличается от JavaScript). Пояснение насчёт эпитета «богатой» — легкодоступной для детей / непрофессионалов и естественно поддерживающей социализацию учебного / творческого процесса, как и продуктивную самостоятельную работу учеников без людей-менторов / с минимальным вложением сил менторов (эти аспекты обеспечивают успех и ценность сайтов калибра Khan Academy).
Пайтон (что, на мой взгляд, не так уж сильно отличается от JavaScript)
Принципиально отличается. Я не про замену скобочек выравниванием, я про такие «мелочи», на которые дети при обучении наткнутся в первую очередь: строгая типизация Пайтона — никаких тебе 'abc'+5, всё приводи руками 'abc'+str(5); продуманный подход к модульности, которой в Джаваскрипте попросту нет, файловый ввод-вывод — то, что пришло в голову навскидку. Про объектиную модель и говорить не нужно.
Спасибо, я учту — у меня с Пайтоном знакомство шапочное и не особо позитивное, но, вероятно, мне просто не повезло. Просмотрю образовательные сайты, использующие Пайтон теперь.
Сегодня начался один из бесплатных курсов по нему на Coursera. Отличный курс, и инструмент они к нему хороший придумали — CodeSculptor.
Здравствуйте.
Насколько я знаю, средства доказательства не реализованы, задача сложная, людей мало, беда любого опенсурсного сообщества.
А вот в образовании оберон не только рассматривают, но и применяют www.inr.ac.ru/~info21
Насколько я знаю, средства доказательства не реализованы, задача сложная, людей мало, беда любого опенсурсного сообщества.
А вот в образовании оберон не только рассматривают, но и применяют www.inr.ac.ru/~info21
Спасибо за информацию — я обязательно посмотрю OberonScript как возможный инструмент для онлайнового обучения, альтернативный таким сайтам с JavaScript и Python. Сейчас вспоминаю, приятель использовал для школьного программистского кружка Pascal-среду, спрошу у него, был это BlackBox или что-то другое.
Сейчас я бы рекомендовал обратить внимание на OberonJS, более современная версия браузерного оберона. github.com/vladfolts/oberonjs
Товарищ делает eberon — оберон с человеческим лицом
Спасибо, буду иметь в виду.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
О бытовом заблуждении