Комментарии 377
Автор, вы в названии языка опечатались здесь:
Использование Rust извне
Не хочется Вас огорчать и расстраивать, но в языке Яист чего-то «своего» придумали чуть более, чем нисколько.
Если чего-то никогда не встречали, никогда не стесняйтесь поискать в интернете.
Если чего-то никогда не встречали, никогда не стесняйтесь поискать в интернете.
Далее следует объявление переменной, которое совмещено с инициализацией и размещено прямо в коде. Ну а как еще, не делать же отдельную секцию переменных, как в восьмидесятых. Тогда угрюмые колхозники писали все переменные в строго выделенном месте, чтобы потом их в этом месте найти.
Казалось бы, при чем тут ник автора…
Насчет фигурных скобочек и точки с запятой соглашусь, это родовая травма C, неизвестно зачем тянущаяся во все языки с тех пор.
Ну правда, почему в Обероне догадались, а в Rust все получилось вот так?
Красота в глазах смотрящего, как известно, или, другими словами, на вкус и цвет товарищей нет.
А вам таки не нравится объявление в коде?
Не смущает что в Rust можно написать
let a = 5;
let a = 6;
и это 2 различных переменных
Безотносительно того где это может применяться и нафига это нужно (в макросах это может быть полезно), объявления перед кодом принципиально такого не предоставят.
Не смущает что в Rust можно написать
let a = 5;
let a = 6;
и это 2 различных переменных
Безотносительно того где это может применяться и нафига это нужно (в макросах это может быть полезно), объявления перед кодом принципиально такого не предоставят.
Чем вам так неугодны скобки, и что, по-вашему мнению, лучше них? BEGIN-END? Отступы?
Как показывает опыт Python, отступов вполне достаточно, а точка с запятой вполне может быть необязательна (очень-очень редко действительно надо писать несколько выражений на одной строке).
Не то что неугодны, просто можно и без них. А если без чего-то можно обойтись, то лучше так и сделать.
Не то что неугодны, просто можно и без них. А если без чего-то можно обойтись, то лучше так и сделать.
Много, долго и счастливо живу с питоном, но иногда бывает страшно что отступишь на четыре пробела меньше и потом долго будешь искать где ты оступился
Аналогично в C-like, не напишешь фигурные скобки после if или цикла и долго ищешь, где ты оступился. Посмотрите серию статей про CppCat, в каждой третьей такие ошибки.
Это другое, со скобками достаточно приучить себя ставить их всегда после if b т.д… Невозможно приучить себя ставить правильное число пробелов или табуляций.
Простите, не согласен категорически. Какая разница, ставить скобочки или отступы?
Скобочки, они жирнее. Видны лучше на старости лет.
Тонко!
Вообще, я даже не знаю, насколько я шутил. Лично у меня глубокий импринтинг на фигурные скобочки, а в питоне терпеть не могу искать ошибки из-за табов/пробелов.
В бытность свою питонистом ни разу не натыкался на ошибки из-за отступов.
а нельзя в редакторе символ пробела заменить на точку, как это сделано в ворде в режиме разметки?
А почему бы сразу в языке не заменить? Ведь пробел не видно, а точку будет видно.
И не на точку, а на позитивный внятный юникодный символ, скажем, “⇒”. И не умеешь настраивать клавиатуру — нет и пряничков.
Пользуясь случаем, должен сказать: блистательно написано и абсолютно по делу.
Пользуясь случаем, должен сказать: блистательно написано и абсолютно по делу.
Любые комплименты в сторону маргиналов, имеющих отношение к Oberon, на хабре караются, так что будьте осторожны, правильно выдерживайте линию партии.
Да мне как-то в целом на мнение здешней хипстующей школоты en mass — насрать, а вот приятному человеку сообщить, что он молодец — всегда почитал за должное.
Да и вообще, я убийц языков, типа раста, повидал миллион, но побеждает всегда что-то рожденное в сарае за два часа. В КОБОЛ вон вбухали бабла сколько, а что получилось? И ведь тоже анонсировался убийца всего.
Ни один более-менее серьезный си/плюс программист из числа моих знакомых не рассматривает пока раст как что-то жизнеспособное на уровне чуть выше, чем «клево, я на выходных поигрался, пора обратно за работу».
Да и вообще, я убийц языков, типа раста, повидал миллион, но побеждает всегда что-то рожденное в сарае за два часа. В КОБОЛ вон вбухали бабла сколько, а что получилось? И ведь тоже анонсировался убийца всего.
Ни один более-менее серьезный си/плюс программист из числа моих знакомых не рассматривает пока раст как что-то жизнеспособное на уровне чуть выше, чем «клево, я на выходных поигрался, пора обратно за работу».
Скобки (ну то есть begin-end, я не сишник) я ставлю сразу после того, как написал if или там while. Их можно написать заранее.
Отступы — нельзя.
Поэтому я идеи с отступами боюсь. Но я не пробовал — может, оно вполне удобно и боюсь я зря.
Отступы — нельзя.
Поэтому я идеи с отступами боюсь. Но я не пробовал — может, оно вполне удобно и боюсь я зря.
Странная у вас какая-то идея, что отступы надо писать. Уверяю вас, никто не сидит и не расставляет вручную нужное количество пробелов, нажимая пробел 4-8-12 раз.
Хм, а ведь вы правы. IDE ставит курсор сразу туда, куда нужно.
Иногда, правда, я в самом деле вручную нажимаю пробел :). Но редко, очень редко — и обычно потому, что опять забыл, как там авто-отбивка вызывается.
Иногда, правда, я в самом деле вручную нажимаю пробел :). Но редко, очень редко — и обычно потому, что опять забыл, как там авто-отбивка вызывается.
У некоторых IDE (не будем показывать пальцем в лидеров индустрии) вообще странная мания ломать отступы при вставке из буфера. Со скобками в этом плане проще — код автоматом форматируется по скобкам.
Простите, не согласен категорически. Какая разница, ставить скобочки или отступы?
Тем, что автоматический выравниватель кода понимает первое, но не понимает второе.
А зачем он нужен, если код уже выровнен?
Код — это же не статический текст в книге, который по факту «выровнен» или «не выровнен». Он меняется, иногда серьёзно. Куски кода выделяются в функции, перемещаются из функции в функцию, блоки обрамляются if-условиями, и т.п. Если в каком-нибудь C++ я могу просто поставить скобки вокруг нового скопа и запустить форматтер (который сразу учтёт новый отступ, разобьёт слишком длинные строки на части и т.п.), то в python мне приходится делать это всё руками.
Вините свою IDE, а не Python. Найти наибольший общий отступ выделенного куска кода и заменить его на другой — не rocket science.
В случае C++ я могу обойтись без умных IDE, достаточно простого редактора и clang-format.
У меня, например, разработка ведётся на удалённом сервере, и код проще всего писать именно там (там все хедеры, доступы к тестовым сервисам и т.п.). IDE в таких средах не особо удобны. Мне вполне хватает emacs и различных внешних утилит.
У меня, например, разработка ведётся на удалённом сервере, и код проще всего писать именно там (там все хедеры, доступы к тестовым сервисам и т.п.). IDE в таких средах не особо удобны. Мне вполне хватает emacs и различных внешних утилит.
Не вижу причин не деталь так же на питоне — подогнать блок табом до нужного количества отступов и какой-нибудь форматтер типа github.com/google/yapf
простого редактора
Мне вполне хватает emacs
Как раз в Emacs подобное (умный индент с поддержкой на уровне синтаксиса языка) не является особой проблемой.
Я не работал с IDE на Python — в pycharm, судя по описанию , есть автоформатирование.
Я не вижу теоретических препятствий к тому, чтобы работало как в C++ только сначала подогнать блок табом под нужый уровень вложености. Насколько я знаю есть и реформат при вставке:
Я не вижу теоретических препятствий к тому, чтобы работало как в C++ только сначала подогнать блок табом под нужый уровень вложености. Насколько я знаю есть и реформат при вставке:
Reformat on paste Use this drop-down list to specify how to place pasted code blocks. The available options are: – None — The pasted code is inserted at the caret location as plain text without any reformatting or indenting.
– Indent Block — The pasted code block is positioned at the proper indentation level, according to the current Code Style Settings, but its inner structure is not changed.
– Indent Each Line- Each line of the pasted code block is positioned at the proper indentation level, according to the current Code Style Settings.
– Reformat Block- The pasted code block is reformatted according to the current Code Style Settings.
И оно (форматирование при вставке) вполне работает. Если я перед блоком поставить, например, условие на предыдущей строке, то pycharm/idea автоматически идущий следом кусок переформатировать не будет, т. к. не может угадать, к чему относится добавленное условие (к одной строке, к 5 строкам или максимально длинному участку). Поэтому есть операция surround with (ctrl+shift+j в классической раскладке), действующая на выделенный блок и обрамляющая его выбранной операцией с переформатированием кода, естественно (срабатывает ли при этом autowrap — не знаю, я им не пользуюсь).
У плагина для scala есть автоперевод java->scala при вставке, что уж там.
У плагина для scala есть автоперевод java->scala при вставке, что уж там.
Я постоянно работаю в Pycharm и могу заявить, что с помощью него я менял размер табов в кривом исходном файлике. Было у нас куча исходников, в которых блоки разделялись не по 4 пробела, а по 1. Так вот такие исходники я приводил к нормальному виду так:
1. открываем этот файлик в Pycharm
2. Ctrl + A
3. Ctrl + X
4. Ctrl + V
Уровень вложенности блоков был 3-4 примерно, и все чудесно ложилось по новым правилам и интерпретировалось без ошибок. Даже править не пришлось.
1. открываем этот файлик в Pycharm
2. Ctrl + A
3. Ctrl + X
4. Ctrl + V
Уровень вложенности блоков был 3-4 примерно, и все чудесно ложилось по новым правилам и интерпретировалось без ошибок. Даже править не пришлось.
Это лечится код стайлом, запрещающем писать как-то иначе. И со временем это вживается в подкорку мозга, и ты забываешь, что можно их и не ставить.
В крайнем случае, это лечится статическим анализатором, в котором прописана выдача ошибки на написание if без скобок.
В крайнем случае, это лечится статическим анализатором, в котором прописана выдача ошибки на написание if без скобок.
Ну вот уже начинается привлечение посторонних инструментов, линтеры, код-стайлы, статические анализаторы.
Да, открывающую фигурную скобку со временем приучаешься писать всегда, и это хорошая практика. Ну так и отступы тоже делаешь всегда.
Да, открывающую фигурную скобку со временем приучаешься писать всегда, и это хорошая практика. Ну так и отступы тоже делаешь всегда.
Я вообще совсем не первый год пишу на языке с фигурными скобками, но стараюсь их не ставить там, где можно этого не делать.
Грамматикой Rust запрещено тело условных операторов, не заключенное в блок. Проблемы нет.
Они стали популярны не просто так.
Скобочки (особенно в сочетании с отступами) делают код гораздо более наглядным и логически разделенным.
BEGIN-END плохо выполняют эту роль, потому как по написанию сливаются с самим кодом.
А отступы без скобочек не так наглядны и иногда порождают проблемы, которые описаны в комментарии выше
Скобочки (особенно в сочетании с отступами) делают код гораздо более наглядным и логически разделенным.
BEGIN-END плохо выполняют эту роль, потому как по написанию сливаются с самим кодом.
А отступы без скобочек не так наглядны и иногда порождают проблемы, которые описаны в комментарии выше
Вы все хорошо говорите, убедительно, только расскажите, как вы {измеряете наглядность и логическую разделенность? В чем}? В сантиметрах или в попугаях?
А BEGIN-END не сливаются с кодом, так же как не сливаются с вашим комментарием.
А BEGIN-END не сливаются с кодом, так же как не сливаются с вашим комментарием.
Cливается, так как использует тот же самый набор символов. К примеру:
begin;
int beginningBegin = 25;
int endd = 34;
if (beginningBegin > endd)
then
begin
beginningBegin -= beginningBegin;
endd = endd — beginningBegin;
end;
beginningBegin = 45;
end;
begin;
int beginningBegin = 25;
int endd = 34;
if (beginningBegin > endd)
then
begin
beginningBegin -= beginningBegin;
endd = endd — beginningBegin;
end;
beginningBegin = 45;
end;
Почему-то в примере не увидел ни одного BEGIN
Отступы сделайте (не первый урок по программированию ж ей богу) и ничего сливаться у вас не будет:
Но вообще, я предпочитаю Python-стиль, как не дублирующий скобками/BEGIN-END и так имеющуются структуру и логику. Если у вас отступы отдельно живут, а скобки отдельно и вы считаете, что скобки помогают избежать проблем, а ваш код так и остаётся с кривыми отступами, хочу вас заверить, что такой код нужно считать ущербным и нужно исправлять отступы. Итого, имея скобки как средство языка и отступы для красоты — вам приходится делать двойную работу.
begin;
int beginningBegin = 25;
int endd = 34;
if (beginningBegin > endd) then
begin
beginningBegin -= beginningBegin;
endd = endd — beginningBegin;
end;
beginningBegin = 45;
end;
Но вообще, я предпочитаю Python-стиль, как не дублирующий скобками/BEGIN-END и так имеющуются структуру и логику. Если у вас отступы отдельно живут, а скобки отдельно и вы считаете, что скобки помогают избежать проблем, а ваш код так и остаётся с кривыми отступами, хочу вас заверить, что такой код нужно считать ущербным и нужно исправлять отступы. Итого, имея скобки как средство языка и отступы для красоты — вам приходится делать двойную работу.
Соглашусь. Тоже всегда использую аргумент про двойную работу как объяснение отступов в питоне.
>вам приходится делать двойную работу
В теории — да, на практике — нет. Любой адекватный редактор любого популярного языка сам проставляет отступы, если они нужны. Согласен, что по факту двойная работа выполняется, но уже не вами, а IDE.
Проблема скобок надуманна, это особенно понимаешь, если много пишешь на языке с ними и на языке без них — скорость написания кода совершенно одинаковая… по крайней мере, у меня.
В теории — да, на практике — нет. Любой адекватный редактор любого популярного языка сам проставляет отступы, если они нужны. Согласен, что по факту двойная работа выполняется, но уже не вами, а IDE.
Проблема скобок надуманна, это особенно понимаешь, если много пишешь на языке с ними и на языке без них — скорость написания кода совершенно одинаковая… по крайней мере, у меня.
Лично мне (!) проще читать (!) код без лишних знаков (а скобки при должных отступах нужны только компилятору). Я согласен, что скобки — не такая уж и глобальная проблема, при желании можно даже простой скрипт написать, который будет транслировать из синтаксиса без скобок в синтаксис со скобками, но лично я не вижу никакого преимущества в скобках, поэтому считаю их лишними.
Пожалуйста напишите! желательно на питоне :)
Искренне не понимаю почему со всеми этими «холиварами» никто такой скрипт не накалял.
Если в сишечке можно будет писать с отступами то с радостью возьмусь за её изучение.
Я вот что подумал а нельзя ли в самом питоне избавить от скобочек? да-да там тоже есть. "[]", "{}", "()"
Пришлось бы правда придумывать директивы обновления начала списка всё равно. От этого никуда не деться, но ведь с функциями мы же не ругаемся. Можно было бы сделать так:
def — объявление function
del — объявление list. И сделать чтобы каждая следующая строчка с отступом была элементом этого list, чтобы ещё и запятые убрать.
А не незя так. :( понятно почему.
Я это к чему — вообще в сишечке скобки были созданы не для людей, а для компилятора — чтобы ему было проще искать эти самые блоки, а не искать последовательность символов. А людям некоторым просто удобно когда можно некоторые вещи располагать в одну строку.
Мне например Очень хочется синестезии этих двух способов в одно:
если хочется написать несколько функции в одной строке — будь добр отдели их скобками и точками с запятыми; хочется в много строчье — исчезает надобность в разделении. В принципе в питоне это уже почти работает ( у меня не получилось определить две функции на одной строке, но можно определить несколько команд в одну функцию на одной строке. Хотя может если почитать доку (то чего я ни разу в жизни не делал) )
Искренне не понимаю почему со всеми этими «холиварами» никто такой скрипт не накалял.
Если в сишечке можно будет писать с отступами то с радостью возьмусь за её изучение.
Я вот что подумал а нельзя ли в самом питоне избавить от скобочек? да-да там тоже есть. "[]", "{}", "()"
Пришлось бы правда придумывать директивы обновления начала списка всё равно. От этого никуда не деться, но ведь с функциями мы же не ругаемся. Можно было бы сделать так:
def — объявление function
del — объявление list. И сделать чтобы каждая следующая строчка с отступом была элементом этого list, чтобы ещё и запятые убрать.
А не незя так. :( понятно почему.
Я это к чему — вообще в сишечке скобки были созданы не для людей, а для компилятора — чтобы ему было проще искать эти самые блоки, а не искать последовательность символов. А людям некоторым просто удобно когда можно некоторые вещи располагать в одну строку.
Мне например Очень хочется синестезии этих двух способов в одно:
если хочется написать несколько функции в одной строке — будь добр отдели их скобками и точками с запятыми; хочется в много строчье — исчезает надобность в разделении. В принципе в питоне это уже почти работает ( у меня не получилось определить две функции на одной строке, но можно определить несколько команд в одну функцию на одной строке. Хотя может если почитать доку (то чего я ни разу в жизни не делал) )
Мне например Очень хочется синестезии этих двух способов в одно: если хочется написать несколько функции в одной строке — будь добр отдели их скобками и точками с запятыми; хочется в много строчье — исчезает надобность в разделении.
… и коллеги по команде вас проклинают.
Спустя 3 года я выложил на гитхаб утилиту которая рисует фигурные скобочки по отступам для Си :)
(ссылку кушает хабр :(… sergey6661313/cacb)
(ссылку кушает хабр :(… sergey6661313/cacb)
Для пользователей VIM скобочки {} также удобны тем, что можно легко выполнять операции, скажем, над их содержимым
yiB — (yank inner block) скопировать внутренности {}
yiB — (yank inner block) скопировать внутренности {}
Пишу в VIM уже 8 лет, на Python — 6 и вот как-то обходился
d<N>d или визуальным выделением через v. Хороший Python код очень редко требует копирования больших объёмов (в том числе и из-за того, что большинство методов вмещаются в 1 экран кода), в отличие от {}-образных.Эээ, а какая связь между количеством кода в методе и тем, используются для структурирования скобки или отступы?
В небольших методах, скажем, до 10 строк легко используется комбинация, например,
d4d, которая вырезает 4 строки в буфер. Именно в этом контексте я привёл уточнение про маленькие блоки кода.Хороший Python код очень редко требует копирования больших объёмов (в том числе и из-за того, что большинство методов вмещаются в 1 экран кода)
Вы хотите сказать, что у языков со структурированием скобками в хорошем коде методы занимают больше места, чем в Питоне?
Минимум на две строки больше, чем в питоне (это строки с открывающейся и закрывающейся скобками).
P.S. Я сам никого не минусую, но если кто-то хочет обменяться минусами — вы хоть намекните кому я задолжал.
P.S. Я сам никого не минусую, но если кто-то хочет обменяться минусами — вы хоть намекните кому я задолжал.
Во-первых, на одну (потому что открывающую скобку можно держать на одной строчке с декларацией).
Во-вторых, когда копируется код метода, скобки включать не надо (копируется тело), поэтому все равно не понятно отличие.
Во-вторых, когда копируется код метода, скобки включать не надо (копируется тело), поэтому все равно не понятно отличие.
Я изначально описывал не отличие Python от {}-языков, а то, что копирование с Python не является никакой проблемой в VIM несмотря на то, что в Python нет скобок. Более того комбинацию
d<N>d можно использовать в любом коде.
Ага, только для
Проще и универсальнее было бы использование привязки, которая выделяет непрерывный блок кода, в котором каждая линия имеет такой же или бо́льший отступ относительно линии, на которой стоит курсор. Это аналог
d<N>d нужно знать N. Не говорите мне про relativenumber: во‐первых, мне не нравиться занимать свободное пространство когда есть более удобные способы сделать то же самое. Во‐вторых, relativenumber не поможет вам, если конца метода не видно на экране (нет, это не обязательно значит, что метод большой).Проще и универсальнее было бы использование привязки, которая выделяет непрерывный блок кода, в котором каждая линия имеет такой же или бо́льший отступ относительно линии, на которой стоит курсор. Это аналог
iB для Python, так же хорошо работающий для других языков, если авторы не забывали ставить отступы. Из‐за автоформатирования в каждом первом редакторе кода отсутствие отступов — большая редкость.Ладно, при желании есть vim-indent-object плагин и шорткат будет
vii.В случае с египетскими скобками (кажется, самый популярный сейчас стиль), то на одну больше в худшем случае, часто на ноль. На две строки больше обычно только в телах функций.
Кроме того, вспомните PEP8. Две пустых строки до и после метода или класса на верхнем уровне, одна на любом другом (в обоих случаях — с некоторыми исключениями, на верхнем уровне редкими). А куча пустых строк для отделения логических уровней в любом языке, если метод‐таки перевалил за 10 строк (а часто и меньше), ещё сильнее уменьшают разницу. Засуньте туда ещё документацию, которая имеет относительно одинаковые размеры вне зависимости от языка (обычно могут только добавится/убраться предупреждения вида «метод выделяет память, не забудьте освободить»), и разница в размерах методов перестанет фактически зависеть от скобочек.
На размеры методов гораздо больше влияет наличие различных выразительных средств (типа list comprehension), уровень абстракции, наличие GC.
Кроме того, вспомните PEP8. Две пустых строки до и после метода или класса на верхнем уровне, одна на любом другом (в обоих случаях — с некоторыми исключениями, на верхнем уровне редкими). А куча пустых строк для отделения логических уровней в любом языке, если метод‐таки перевалил за 10 строк (а часто и меньше), ещё сильнее уменьшают разницу. Засуньте туда ещё документацию, которая имеет относительно одинаковые размеры вне зависимости от языка (обычно могут только добавится/убраться предупреждения вида «метод выделяет память, не забудьте освободить»), и разница в размерах методов перестанет фактически зависеть от скобочек.
На размеры методов гораздо больше влияет наличие различных выразительных средств (типа list comprehension), уровень абстракции, наличие GC.
>> как-то обходился d-N-d
Для этого нужно ещё перепрыгнуть на первую строку.
diB работает из любого места.
Странно отрицать очевидное удобство
Для этого нужно ещё перепрыгнуть на первую строку.
diB работает из любого места.
Странно отрицать очевидное удобство
Как я уже говорил в этом треде, на вкус на цвет. Как по мне — так код на Python ничуть не менее нагляден и логически разделен, чем код на любом C-like.
А чем вам не нравятся фигурные скобочки и точка с запятой?
Про скобки я могу только одно сказать — в текущем множестве общедоступных для ввода с любой клавиатуры символов (т.е. ASCII) их мало. Даже для шаблонов пришлось взять «угловые», которые мешаются с «больше-меньше», что не есть хорошо для компиляторов. Реально нужно не меньше 5 видов скобок.
А что касается точки с запятой — это разделитель между выражениями. Да, конечно можно попробовать исхитриться и без нее, но для меня это вполне естественный атрибут программы. Как минимум — способ визуально разделить программу на части. Это вообще малоизученная тема, точная семантика точек с запятыми и запятых «плавает» от языка к языку и даже внутри одного языка от конструкции к конструкции; но тем интереснее будет ее изучить.
Про скобки я могу только одно сказать — в текущем множестве общедоступных для ввода с любой клавиатуры символов (т.е. ASCII) их мало. Даже для шаблонов пришлось взять «угловые», которые мешаются с «больше-меньше», что не есть хорошо для компиляторов. Реально нужно не меньше 5 видов скобок.
А что касается точки с запятой — это разделитель между выражениями. Да, конечно можно попробовать исхитриться и без нее, но для меня это вполне естественный атрибут программы. Как минимум — способ визуально разделить программу на части. Это вообще малоизученная тема, точная семантика точек с запятыми и запятых «плавает» от языка к языку и даже внутри одного языка от конструкции к конструкции; но тем интереснее будет ее изучить.
Я уже написал комментом выше: habrahabr.ru/post/258391/?reply_to=8428269#comment_8428245
А зачем разделять выражения, перевод на новую строку плохо с этим справляется?
Я не говорю, что скобки вообще плохо. Просто для отделения блоков достаточно отступов. Вот если бы фигурные скобки не были заняты под блоки, их можно было бы для шаблонов использовать:)
Я не говорю, что скобки вообще плохо. Просто для отделения блоков достаточно отступов. Вот если бы фигурные скобки не были заняты под блоки, их можно было бы для шаблонов использовать:)
Ну это наверное дело привычки… мне вот не нравится программирование на отступах:) (хотя я разумеется в своих программах на С++ строго придерживаюсь одного из стилей выравнивания кода — Allman_style)
Мне нравится чтобы все элементы программы были «осязаемы». С пробелами такая проблема — а сколько их нужно использовать для отступа? Один, два, четыре, что с табуляцией, в разных редакторах табуляция соответствует разному числу пробелов… Что если я ошибусь на один пробел в большой длинной программе… Пробелы невидимы, и если на них повешена какая-то семантика, то получается, что я не могу точно видеть часть своей программы, как-то так:)
Хотя возможно вы и правы, спорить не буду:)
Мне нравится чтобы все элементы программы были «осязаемы». С пробелами такая проблема — а сколько их нужно использовать для отступа? Один, два, четыре, что с табуляцией, в разных редакторах табуляция соответствует разному числу пробелов… Что если я ошибусь на один пробел в большой длинной программе… Пробелы невидимы, и если на них повешена какая-то семантика, то получается, что я не могу точно видеть часть своей программы, как-то так:)
Хотя возможно вы и правы, спорить не буду:)
4 пробела — стандарт де-факто. Размер табуляции в любом приличном редакторе выставляется в настройках.
А если кто-нибудь по слепоте поставит три? Как поведет себя компилятор?
Серьезно? Вы же не ставите по слепоте круглые скобки вместо фигурных.
Серьезно. Пробелы невидимы, и по слепоте три от четерых или четыре от пяти можно и не отличить:) Особенно если идет не код одного блока в столбик, а завершение сразу нескольких блоков.
Ну вообще приличные редакторы, как я уже говорил, позволяют не заниматься такой ерундой, как ручной подсчет количества пробелов. Для увеличения и уменьшения уровня отступа есть хоткеи (обычно tab/shift+tab).
Вы же все равно ставите отступы, хотя и используете фигурные скобки, правильно?
Вы же все равно ставите отступы, хотя и используете фигурные скобки, правильно?
Да конечно. Я же говорю что это скорее психологический момент. В тех же Rust и Go мне например не нравится навязывание «египетского» стиля скобок как единственно возможного.
Безотносительно конкретного стиля скобок — насмотревшись мешанины стилей, а точнее, отсутствие хоть какого-то стиля в пределах одной страницы кода, считаю добром навязывание любого стиля как единственно возможного.
Меньше возможностей выражения своего внутреннего мира путём (отсутствия) форматирования кода — меньше проблем, больше порядка!
Меньше возможностей выражения своего внутреннего мира путём (отсутствия) форматирования кода — меньше проблем, больше порядка!
Как нефиг делать. Регулярно в XCode улетаю на 1 пробел вправо или влево, а потом туплю, почему это меня пытается поправить автоформатер.
Мне нравится чтобы все элементы программы были «осязаемы».
Привыкните так привыкните по другому потом сравните. Вон автор статьи привык повторять название процедуры после каждого END
Мне нравится чтобы все элементы программы были «осязаемы».
Извиняюсь за башорг, но bash.im/quote/406030
Перевод строки как разделитель, мне кажется, плох тем, что придется в одну строку писать все выражения, даже если они километровые, что приводит к плохой читаемости оных. Конечно, тут можно возразить, что само по себе наличие таких выражений — тревожный звоночек, однако все же бывают исключения.
Есть такие вещи, как знаки переноса, в человеческой речи они тоже есть. В Python для этого в конце строки достаточно поставить
\ или воспользоваться услугами круглых скобок. Примеры:a = MyComplexClass("one", "two three four five...")\
.do_something()
a = (MyComplexClass("one", "two three four five...")
.do_something()
)
something_really_long_long_long_long = ComplexSomethingLikeJavaPeopleLike(
1, 2, 3
)
А вы все о том же:) Эх не хакер вы, не хакер…
Многие могут не сразу понять, но в обычной жизни, вне рамок критических статей надо всеми силами топить за Rust. Просто потому, что он станет врагом С++. Это как в квартире, зараженной клопами, надо завести тараканов, как естественных врагов.
У него уже есть серьезный недостаток — практически неверифицируемый компилятор: он при чистой сборке качает бинарный stage0 rustc, т. к. компилятор раста написан на расте. А до раннего rustc, написанного на ocaml'е больше 4к промежуточных сборок.
В общем, для ответственных применений практически невозможно убедиться в том, что в код компилятора не добавляются отсутствующие в исходниках закладки при сборке. Если оно и взлетит, то до появления альтернативного компилятора в некоторых областях оно неприменимо, как и java. Только кресты, только хардкор.
В общем, для ответственных применений практически невозможно убедиться в том, что в код компилятора не добавляются отсутствующие в исходниках закладки при сборке. Если оно и взлетит, то до появления альтернативного компилятора в некоторых областях оно неприменимо, как и java. Только кресты, только хардкор.
Компилятор Си делает то же самое, в чём проблема?
Компиляторов C чуть больше одного. Соответственно используя два разных компилятора C (clang/gcc/tcc/whatever) можно провести кроссвалидацию: что stage1 собранный, например, gcc и tcc приводят к одинаковым stage3, а значит, что в валидируемом компиляторе скрытых (не присутствующих в исходниках) закладок нет.
Если в случае раста писать компилятор на подмножестве языка, для которого будет иной компилятор, то такая кроссвалидация тоже будет возможна. Но это явно не актуальные вещи при разговоре о версии 1.0.
Лично мне интересно, насколько rust будет удобен для bare-metal targets. Из интересного нашёл проект zinc.rs
Если в случае раста писать компилятор на подмножестве языка, для которого будет иной компилятор, то такая кроссвалидация тоже будет возможна. Но это явно не актуальные вещи при разговоре о версии 1.0.
Лично мне интересно, насколько rust будет удобен для bare-metal targets. Из интересного нашёл проект zinc.rs
Понятно.
Да, на это время надо. Для Си тоже не сразу много компиляторов появилось. В целом, увидеть альтернативную реализацию было бы круто — известно, что компилятор у Раста внутри местами очень страшный, да и какие-то глобально нерешённые вопросы есть.
А про bare-metal — регулярно вижу в IRC и на Reddit людей, программирующих микроконтроллеры на Расте. zinc.rs-то это больше фреймворк, а в принципе libcore — это используемая без аллокатора часть стандартной библиотеки. Достаточно немаленькая часть, для голого железа подходящая. Если интересно, могу попробовать конкретные статьи найти.
Да, на это время надо. Для Си тоже не сразу много компиляторов появилось. В целом, увидеть альтернативную реализацию было бы круто — известно, что компилятор у Раста внутри местами очень страшный, да и какие-то глобально нерешённые вопросы есть.
А про bare-metal — регулярно вижу в IRC и на Reddit людей, программирующих микроконтроллеры на Расте. zinc.rs-то это больше фреймворк, а в принципе libcore — это используемая без аллокатора часть стандартной библиотеки. Достаточно немаленькая часть, для голого железа подходящая. Если интересно, могу попробовать конкретные статьи найти.
# gcc и tcc приводят к одинаковым stage3
Т.е. никогда, *.h и ABI — разные.
Т.е. никогда, *.h и ABI — разные.
Почему у gcc stage1, собранного gcc, и gcc stage1, собранного tcc, будет разный ABI (на выходе компиляции тем и другим)? Они ж из одних и тех же исходников gcc собираются?
Странные мимокрокодилы прошлись минусами, но так и не осилили ответить, почему две сборки binutils+gcc (собранные из одних и тех же исходников с одинаковыми параметрами, но разными компиляторами) должны при компиляции и линковке одного и того же исходника с одинаковыми параметрами должны давать разный результат (в том числе, использовать разный ABI)? При условии отсутствия скрытых закладок, конечно.
<internet-white-knighting>
Я думаю, они просто не поняли из объяснений, что сравнивается в при diverse double-compiling.
Пусть C(s) = b обозначает применение компилятора C к исходнику s с получением бинарной программы b.
Теперь, у нас есть компилятор gcc версии 2 в бинарном виде (gcc2); есть исходники gcc версии 3 (gcc3); и есть другой компилятор, tcc версии 1, в бинарном виде (tcc1).
Теперь мы два раза компилируем gcc3:
gcc2(gcc3) = gcc3-gcc
tcc1(gcc3) = gcc3-tcc
Эти две программы очевидно могут быть различными, иметь разный ABI, и так далее. Но суть в том, что у них должно быть идентичное поведение. Если в gcc2 есть закладка, то поведение gcc3-gcc и gcc3-tcc должно отличаться.
Поэтому делают ещё один проход, собирая одну и ту же программу под одну и ту же архитектуру, используя (предполагаемо) один и тот же алгоритм:
gcc3-gcc(gcc3) = gcc3-gcc x 2
gcc3-tcc(gcc3) = gcc3-tcc x 2
Вот теперь полученные программы должны совпадать побитово (при соблюдении ряда условий на сам компилятор gcc, типа независимости выдачи от фаз Луны). Если они не совпадают, то здесь определённо что-то нечисто.
</internet-white-knighting>
У Rust нет альтернативного бинарного компилятора для бутстрепа. Так что для подобной верификации остаётся только мучительный путь — компилировать исходники вручную, получив чистую копию, лишённую закладок.
Я думаю, они просто не поняли из объяснений, что сравнивается в при diverse double-compiling.
Пусть C(s) = b обозначает применение компилятора C к исходнику s с получением бинарной программы b.
Теперь, у нас есть компилятор gcc версии 2 в бинарном виде (gcc2); есть исходники gcc версии 3 (gcc3); и есть другой компилятор, tcc версии 1, в бинарном виде (tcc1).
Теперь мы два раза компилируем gcc3:
gcc2(gcc3) = gcc3-gcc
tcc1(gcc3) = gcc3-tcc
Эти две программы очевидно могут быть различными, иметь разный ABI, и так далее. Но суть в том, что у них должно быть идентичное поведение. Если в gcc2 есть закладка, то поведение gcc3-gcc и gcc3-tcc должно отличаться.
Поэтому делают ещё один проход, собирая одну и ту же программу под одну и ту же архитектуру, используя (предполагаемо) один и тот же алгоритм:
gcc3-gcc(gcc3) = gcc3-gcc x 2
gcc3-tcc(gcc3) = gcc3-tcc x 2
Вот теперь полученные программы должны совпадать побитово (при соблюдении ряда условий на сам компилятор gcc, типа независимости выдачи от фаз Луны). Если они не совпадают, то здесь определённо что-то нечисто.
</internet-white-knighting>
У Rust нет альтернативного бинарного компилятора для бутстрепа. Так что для подобной верификации остаётся только мучительный путь — компилировать исходники вручную, получив чистую копию, лишённую закладок.
(с) К.О.
… У Rust нет альтернативного бинарного компилятора для бутстрепа
Я ответил, что у gcc — тоже нет альтернативы… clang — может быти использован для бутстрапа, но мы же закладки ищем?! или только возможность получить бинарные копии? В инкладах операционных систем отрабатывается какой компилятор сейчас их компилирует и эта информация протягивается по стайджам, можно подшаманить между ними, но мы же доказывает отсутствие закладок?!
tcc уже не в состоянии скомпилировать gcc, a так бы было интересно, 32 битный ABI 2000х на 64 битной платформе, мог бы быть условием не включать закладки, доказательство отсутсвия срабатывания, которое мы бы получили в этом эксперименте — только для очистки совести.
Ни один компилятор не несет описание всех сред на которых он может быть развернут, ему скармливают описания этой среды, разное ABI, у меня на компе два 32 и 64(в разных каталогах, можно поставить еще + делать кроссплатформенные среды), которое будет скормлено — зависит от начального компилятора и ключей при начале построения., по этому…
… Но суть в том, что у них должно быть идентичное поведение.
— сильно сильное требование, недоступное даже с ключем -O0, но нам нужен же -O2 (как минимум?) Суть разного ABI — РАЗНОЕ поведение, (как пример: codingadventures.me/2015/03/13/c-tail-recursion-using-64-bit-variables не всегда умеет разварачивать хвостовую рекурсию).
… Поэтому делают ещё один проход, собирая одну и ту же программу под одну и ту же архитектуру, используя (предполагаемо) один и тот же алгоритм
— еще раз огорчу (упростим, даже одним компилятором) на старте имея разный ABI: одну и ту же программу не получим (разные ветви #if#else), (архитектуру?) мы выбрали разную, ((предполагаемо) один и тот же алгоритм) гарантированно разные алгоритмы (различие в количесве бит, регистров, разные оптимизации )
Но, таки, да, если одним и тем же компилятором компилировать одну и туже программу на той же архитектуре, (предполагаемо) получим одни и те же объектные файлы. (если компилятор не подмешивает случайные данные, для секурности, или версионности)
… У Rust нет альтернативного бинарного компилятора для бутстрепа
Я ответил, что у gcc — тоже нет альтернативы… clang — может быти использован для бутстрапа, но мы же закладки ищем?! или только возможность получить бинарные копии? В инкладах операционных систем отрабатывается какой компилятор сейчас их компилирует и эта информация протягивается по стайджам, можно подшаманить между ними, но мы же доказывает отсутствие закладок?!
tcc уже не в состоянии скомпилировать gcc, a так бы было интересно, 32 битный ABI 2000х на 64 битной платформе, мог бы быть условием не включать закладки, доказательство отсутсвия срабатывания, которое мы бы получили в этом эксперименте — только для очистки совести.
Ни один компилятор не несет описание всех сред на которых он может быть развернут, ему скармливают описания этой среды, разное ABI, у меня на компе два 32 и 64(в разных каталогах, можно поставить еще + делать кроссплатформенные среды), которое будет скормлено — зависит от начального компилятора и ключей при начале построения., по этому…
… Но суть в том, что у них должно быть идентичное поведение.
— сильно сильное требование, недоступное даже с ключем -O0, но нам нужен же -O2 (как минимум?) Суть разного ABI — РАЗНОЕ поведение, (как пример: codingadventures.me/2015/03/13/c-tail-recursion-using-64-bit-variables не всегда умеет разварачивать хвостовую рекурсию).
… Поэтому делают ещё один проход, собирая одну и ту же программу под одну и ту же архитектуру, используя (предполагаемо) один и тот же алгоритм
— еще раз огорчу (упростим, даже одним компилятором) на старте имея разный ABI: одну и ту же программу не получим (разные ветви #if#else), (архитектуру?) мы выбрали разную, ((предполагаемо) один и тот же алгоритм) гарантированно разные алгоритмы (различие в количесве бит, регистров, разные оптимизации )
Но, таки, да, если одним и тем же компилятором компилировать одну и туже программу на той же архитектуре, (предполагаемо) получим одни и те же объектные файлы. (если компилятор не подмешивает случайные данные, для секурности, или версионности)
В инкладах операционных систем отрабатывается какой компилятор сейчас их компилирует и эта информация протягивается по стайджам, можно подшаманить между ними, но мы же доказывает отсутствие закладок?!Закладок в компиляторе. Содержимое инклюдов — это проблемы операционной системы. Точно так же закладка в драйвере файловой системы — это не проблема компилятора и не покрывается DDC-тестом.
Суть разного ABI — РАЗНОЕ поведениеВажно наблюдаемое поведение.
(архитектуру?) мы выбрали разнуюДля DDC-теста должны выбирать одинаковую. Иначе конечно же результаты двойной компиляции будут отличаться, лол.
))) Вы, просто, бальзам моего сердца, такое чувство от родственной души! Ваш, К.О.
Великолепно!
"… Закладок в компиляторе..." — проведя неполное тестирование, на «специально настроенной среде», мы можем утвеждать их отсутствие! Встраивайся сколько хочешь. Главное — не менять собираемый образ компилятора.
"… Важно наблюдаемое поведение...", на специально настроенной среде — просто не достижимо в современных «троянцах»!
Великолепно!
"… Закладок в компиляторе..." — проведя неполное тестирование, на «специально настроенной среде», мы можем утвеждать их отсутствие! Встраивайся сколько хочешь. Главное — не менять собираемый образ компилятора.
"… Важно наблюдаемое поведение...", на специально настроенной среде — просто не достижимо в современных «троянцах»!
Из серии новейших яистов мне более всего как язык симпатичен dlang.
Это херня какая-то, а не статья.
Конечно, данный комент это просто забавный способ передать мои ощущения от прочтения статьи. Через призму моего опыта я воспринимал то или иное предложение, которое встречал в процессе прочтения. Конечно, какие-то особенности я упустил. Но цель была немного не в этом.
Конечно, данный комент это просто забавный способ передать мои ощущения от прочтения статьи. Через призму моего опыта я воспринимал то или иное предложение, которое встречал в процессе прочтения. Конечно, какие-то особенности я упустил. Но цель была немного не в этом.
Просто из праздного интереса, а каков был путь автора в изучении и использовании языков? Например, я начинал с PHP (тогда только вышла версия 4) / JS, потом lua и Си, потом С++. Это из того, на чём были большие проекты, мелочь не считается.
Pascal изучал в школе.
Работал на freepascal, oberon (модификация), на последней работе java, js, ибо прижал кризис :)
Вне работы go, dart, вот, на раст смотрю внимательно.
Еще на actionScript что-то делал, не помню уже.
Работал на freepascal, oberon (модификация), на последней работе java, js, ибо прижал кризис :)
Вне работы go, dart, вот, на раст смотрю внимательно.
Еще на actionScript что-то делал, не помню уже.
А. Собственно, все понятно — вы на си и крестах не писали.
Что понятно? Не писал на Си — не мужик?
Это не я сказал. Но оценивать откровенно низкоуровневый язык не имея с опыта работы с подобными — верный путь к фэйлу. Да и оценивать язык по синтаксису — паршивая идея.
На Обероне операционные системы пишут, я разбирал их исходники. Достаточно низкоуровнево? Или надо ниже? Или надо строго на Си писать, чтобы пройти Ваш фейсконтроль?
А синтаксис отличная штука для первичной оценки, первые этапы боли я получу, выписывая кренделя с исходником. А вы говорите — паршивая идея. Как же поступить? Кто же прав?
А синтаксис отличная штука для первичной оценки, первые этапы боли я получу, выписывая кренделя с исходником. А вы говорите — паршивая идея. Как же поступить? Кто же прав?
М. И что? Вон МС на C# ОС писали. Или Mirage, в котором OCaml-а 90%. Низкоуровневыми это их не делает.
А правы, скорей всего, авторы Rust-a, которые делают хороший, годный язык для людей, которые годами писали на C/C++.
А правы, скорей всего, авторы Rust-a, которые делают хороший, годный язык для людей, которые годами писали на C/C++.
Минусуют, очевидно, люди, совершенно не разбирающиеся в истории ИТ, и скорее всего, есть какая-то сложность в понимании того, что есть синтаксис. Процитирую: «Синтаксические единицы являются одновременно и основными смысловыми понятиями любого языка: модуль, класс, блок, функция, процедура, метод, оператор, выражение. Ну а что, если не система понятий и их количество, может характеризовать сложность языка.»
Вы про одноименную систему, предназначенную для исполнения программ на нём (написанную Виртом)?
По-моему, если для языка нужна своя ОС — это фигня какая-то, простите.
По-моему, если для языка нужна своя ОС — это фигня какая-то, простите.
По-моему, если для языка нужна своя ОС — это фигня какая-то, простите.
Речь шла о том, что на Обероне можно писать ОС. И все остальное тоже можно. Если вы из этого делаете вывод, процитированный выше, то вам надо всерьез задуматься о возможной дислексии.
Ну я попытался понять, о каких ОС на Обероне идёт речь, и нашёл в Википедии следующее:
Из вас же ничего, кроме оскорблений, не вытянешь.
Если вы по одной фразе диагностируете у собеседника болезнь, то вам надо всерьёз задуматься о чём-то похуже.
В 1989 году в Швейцарской высшей технической школе Цюриха (ETH) была выпущена первая реализация Оберона для процессоров семейства NS32000. Он был создан в качестве компонента операционной среды Оберон.
Из вас же ничего, кроме оскорблений, не вытянешь.
Если вы из этого делаете вывод, процитированный выше, то вам надо всерьез задуматься о возможной дислексии.
Если вы по одной фразе диагностируете у собеседника болезнь, то вам надо всерьёз задуматься о чём-то похуже.
Вы как-то плохо искали. А какой поисковый запрос вы использовали?
Рекомендую Вам обратить внимание на ссылку www.projectoberon.com
я тут погуглил
Рекомендую Вам обратить внимание на ссылку www.projectoberon.com
Вы попытались что-то понять, назвав то, что я сказал, фигней? RLY?
Мне кажется, Вы уже совсем непростительные вольности себе позволяете со словами оппонента.
Поясните пожалуйста, если не трудно, логическую цепочку по переходу от тезиса
Поясните пожалуйста, если не трудно, логическую цепочку по переходу от тезиса
На Обероне операционные системы пишутк тезису
если для языка нужна своя ОС — это фигня какая-тоа господа плюсанувшие ваш комментарий могут присоединиться к формулированию логической цепочки.
Или вот, на Обероне микроконтроллеры для БПЛА программируют, я сам покупал девборду и программировал. Достаточно низкоуровнево? Или надо ниже? Компилировал Оберон в двоичный (и троичный) код. Ниже?
Вообще, мне не хочется вас расстраивать, но Оберон никому особо не нужен и забыт. На данный момент, мне кажется, вполне заслуженно. У нас уже есть куча отличных языков высокого уровня на любой вкус, под любую задачу и любую платформу.
Ну, мы помним, значит не забыт. А вы и дальше стреляйте себе в ноги, вас же не расстраиваетесь от такого, ведь в жизни низкоуровневого программиста главное challenge. И высокий порог вхождения, чтобы конкурентов поменьше.
… И каждый день появляются все более новые и более отличные языки-однодневки…
Стоп. Вы сказали, что для оценки низкоуровневых языков надо поработать на низком уровне. Вам говорят, что опыт такой работы есть. А вы начинаете переобуваться на ходу и подменять тезисы (вместо «поработай низкоуровнево» теперь «Оберон забыт»). Нехорошо так делать. В приличных обществах за такое канделябром, знаете ли.
Не, не поймите неправильно, я подумывал продолжить про низкоуровневость и семантику. Но потом вспомнил, что не разговариваю с фанатиками, сказал, что хотел и ушел заниматься делом.
То есть вы только несете чушь, а отвечать за нее не привыкли.
В данном случае от этого не будет ни удовольствия, ни толка.
Я лучше пойду упаковку HLS timed metadata для erlyvideo дописывать.
Я лучше пойду упаковку HLS timed metadata для erlyvideo дописывать.
Срезал
За столом разговор пошел дружнее, стали уж вроде и забывать про Глеба
Капустина… И тут он попер на кандидата.
— В какой области выявляете себя? — спросил он.
— Где работаю, что ли? — не понял кандидат.
— Да.
— На филфаке.
— Философия?
— Не совсем… Ну, можно и так сказать.
— Необходимая вещь. — Глебу нужно было, чтоб была — философия. Он
оживился. — Ну, и как насчет первичности?
— Какой первичности? — опять не понял кандидат. И внимательно
посмотрел на Глеба, И все посмотрели на Глеба.
— Первичности духа и материи. — Глеб бросил перчатку. Глеб как бы
стал в небрежную позу и ждал, когда перчатку поднимут.
Кандидат поднял перчатку.
— Как всегда, — сказал он с улыбкой. — Материя первична…
— А дух?
— А дух — потом. А что?
— Это входит в минимум? — Глеб тоже улыбался. — Вы извините, мы
тут… далеко от общественных центров, поговорить хочется, но не особенно-то
разбежишься — не с кем. Как сейчас философия определяет понятие
невесомости?
— Как всегда определяла. Почему — сейчас?
— Но явление-то открыто недавно. — Глеб улыбнулся прямо в глаза
кандидату. — Поэтому я и спрашиваю. Натурфилософия, допустим, определит это
так, стратегическая философия — совершенно иначе…
— Да нет такой философии — стратегической! — заволновался кандидат.
— Вы о чем вообще-то?
— Да, но есть диалектика природы, — спокойно, при общем внимании
продолжал Глеб. — А природу определяет философия. В качестве одного из
элементов природы недавно обнаружена невесомость. Поэтому я и спрашиваю:
растерянности не наблюдается среди философов?
Кандидат искренне засмеялся. Но засмеялся один...
Так, в своём понимании мира я не разуверился, теперь опишу, ради чего оно было.
Каждый инструмент должен быть на своём месте. Например, lua хорош декларативным стилем и гибкостью в структуре кода. Очень круто для небольших скриптов в играх, описании GUI, гибких конфигураций. К тому же сегменту можно отнести js.
Си — необходимое зло, которое живёт даже там, где ничего другого нет. Но вот C++ — швейцарский армейский нож на низком уровне бытия. Он не всегда есть там, где есть си, зато позволяет сделать приемлемый API для работы. C++ может быть и ужасен, и прекрасен, зависит от продуманности каждой отдельной библиотеки.
Есть и третья сторона, когда скрипты нужны вчера, увидит их никто, но должно работать. В таких условиях применяется perl, python, tcl и подобное.
Есть ещё и специфические отрасли, требующие какой-то специальный язык…
Rust я отношу ко второй категории, кандидат на апгрейд швейцарского армейского ножа. Пока только кандидат. Заменит он в моём арсенале С++ или нет — можно будет решать после хотя бы 50к строк рабочего кода. А в остальном — не стоит рассматривать микробов в молоток.
Каждый инструмент должен быть на своём месте. Например, lua хорош декларативным стилем и гибкостью в структуре кода. Очень круто для небольших скриптов в играх, описании GUI, гибких конфигураций. К тому же сегменту можно отнести js.
Си — необходимое зло, которое живёт даже там, где ничего другого нет. Но вот C++ — швейцарский армейский нож на низком уровне бытия. Он не всегда есть там, где есть си, зато позволяет сделать приемлемый API для работы. C++ может быть и ужасен, и прекрасен, зависит от продуманности каждой отдельной библиотеки.
Есть и третья сторона, когда скрипты нужны вчера, увидит их никто, но должно работать. В таких условиях применяется perl, python, tcl и подобное.
Есть ещё и специфические отрасли, требующие какой-то специальный язык…
Rust я отношу ко второй категории, кандидат на апгрейд швейцарского армейского ножа. Пока только кандидат. Заменит он в моём арсенале С++ или нет — можно будет решать после хотя бы 50к строк рабочего кода. А в остальном — не стоит рассматривать микробов в молоток.
lua удобен для использования с большим ядром, написанным на «ужасном» С++. Вы же не заставите гейм-дизайнера изучать С++, к тому же модульность языка никакая, дизайнер всё вам там порушит. И перекомпиляция безумная совершенно. Для языков типа Оберона lua теряет свои качества, так как на Обероне можно и ядро написать, и модульно скриптики пописать.
А так же теряется существенная кодовая база сообщества C/C++, что в низкоуровневой разработке игр вызывает неслабые тормоза в развитии проекта. Плавали, знаем. Если приделать к молотку лупу, всё равно на микроскоп похоже мало.
При всём моем (молчаливом) непринятии Rust, вот такие статьи его выставляют только в лучшем свете. Хотя, может, так и предполагалось? Многоходовочка, однако :)
Ну в целом понятно, что я не мог негативно отозваться о Rust, как инструменте, потому что дальше HelloWorld я не работал с ним (я же не такой, как противники Оберона, который ловит клеветы от людей, которые его даже не использовали).
Поэтому я описывал свои мысли по поводу того, что видел.
Возможно, это пойдет на пользу, если верить в то, что негативный пеар — все равно пеар.
Зато это хороший годный способ рассказать, как оно в Обероне.
Поэтому я описывал свои мысли по поводу того, что видел.
Возможно, это пойдет на пользу, если верить в то, что негативный пеар — все равно пеар.
Зато это хороший годный способ рассказать, как оно в Обероне.
Впечатление о языке Яист после прочтения статьи
Да, если бы не Яист, Оберон уже давно бы потеснил С с С++, ага.
Автор, прошу Вас, меньше воды и капризов, больше практики и глубины.
Автор, прошу Вас, меньше воды и капризов, больше практики и глубины.
Ну, с глубиной все понятно, результаты углубления в статье описаны. С практикой тоже все в порядке. А в плане потенциальной успешности Оберона показателен факт абсолютно идентичного мнения большинства участников бесед. Среди них, и правда, Оберон не будет популярен.
Так вы хоть одну статью об Обероне напишите, чтобы это проверить.
Я вот тоже с удовольствием почитал бы статью об Обероне, о его фичах. Вот только автор (судя по предыдущей дискуссии) считает что фичи — это плохо, а хорошо то что в Обероне их нет. А как писать о том чего нет?
Мы у оберонщиков под пытками выяснили, что в Обероне есть какая-то «типа рефлексия» — возможность получать процедуру по имени процедуры и имени модуля… Кто знает, может там еще есть что-то интересненькое…
Мы у оберонщиков под пытками выяснили, что в Обероне есть какая-то «типа рефлексия» — возможность получать процедуру по имени процедуры и имени модуля… Кто знает, может там еще есть что-то интересненькое…
Про статью об Обероне вы угадали совершенно точно. Кроме шуток.
Я всегда говорю — на Обероне денег не заработаешь в силу его крайней простоты, поэтому он неинтересен для серьёзных рыночных игроков. Навороченная IDE для преодоления костылей не нужна, толстые амазон-книги тоже не нужны, может изучаться даже пятиклассниками — предмета для разговора нет.
А раз предмета нет, то и писать статью не о чем. Писать надо о конкретных продуктах на Обероне. Не знаю, будет ли интересен на хабре опыт переноса среды BlackBox с WinAPI на кроссплатформенный SDL, вот я бы про это написал.
Я всегда говорю — на Обероне денег не заработаешь в силу его крайней простоты, поэтому он неинтересен для серьёзных рыночных игроков. Навороченная IDE для преодоления костылей не нужна, толстые амазон-книги тоже не нужны, может изучаться даже пятиклассниками — предмета для разговора нет.
А раз предмета нет, то и писать статью не о чем. Писать надо о конкретных продуктах на Обероне. Не знаю, будет ли интересен на хабре опыт переноса среды BlackBox с WinAPI на кроссплатформенный SDL, вот я бы про это написал.
Я всегда говорю — на Обероне денег не заработаешь в силу его крайней простоты, поэтому он неинтересен для серьёзных рыночных игроков. Навороченная IDE для преодоления костылей не нужна, толстые амазон-книги тоже не нужны, может изучаться даже пятиклассниками — предмета для разговора нет.
Почему он тогда не используется теми «серьезными рыночными игроками», которым важно быстро и надежно разработать свой продукт? Или используется? Тогда можно имена-названия?
Вопрос хороший. Вспомните про Borland, которая отлично поднялась на однопроходном компиляторе паскаля, например. Потом на эту же поляну подтянулись монстры индустрии и завалили её своими продуктами. Вам же всё равно, на чём писать, лишь бы дали бесплатную инфраструктуру, ну а им всё равно, на чём деньги зарабатывать, вот так оно и пошло.
Теперь под мощью этих продуктов, например, у меня ноут трещит, Unity3d крэшится, винда ресурсы жрёт, я теряю время на ожидании, пока система соизволит открыть контекстное окошко или там gimp запустится. Но это мелочи. Главное, чтобы вам было удобно с фигурными скобками, лямбдами и форычем.
А там, где нужна истинная надёжность, на круглые скобки смотрят в последнюю очередь. Спутники там, или АЭС. Имён не раскрою, зачем? Рынок сделал свой выбор.
Теперь под мощью этих продуктов, например, у меня ноут трещит, Unity3d крэшится, винда ресурсы жрёт, я теряю время на ожидании, пока система соизволит открыть контекстное окошко или там gimp запустится. Но это мелочи. Главное, чтобы вам было удобно с фигурными скобками, лямбдами и форычем.
А там, где нужна истинная надёжность, на круглые скобки смотрят в последнюю очередь. Спутники там, или АЭС. Имён не раскрою, зачем? Рынок сделал свой выбор.
Вам же всё равно, на чём писать, лишь бы дали бесплатную инфраструктуру,
Очевидно, нет. Мне совершенно не все равно, на чем писать, у меня есть вполне конкретный набор требований к тем языкам и технологиям, которые я использую в продуктиве.
Вы ведь не готовы самостоятельно написать веб-клиент, так ведь? Он должен быть в стеке. И так далее.
Веб-не веб, а вот, скажем, карманную реализацию SOAP я уже писал, хотя в стеке она есть.
Но в общем случае это вопрос не готовности, а потребности. Зачем каждый раз писать свой велосипед, если его уже кто-то написал до меня, и это известная и поддерживаемая реализация?
(и нет, речь идет не о стеке, а о доступных инструментах)
Но в общем случае это вопрос не готовности, а потребности. Зачем каждый раз писать свой велосипед, если его уже кто-то написал до меня, и это известная и поддерживаемая реализация?
(и нет, речь идет не о стеке, а о доступных инструментах)
Я и говорю, ваш разумный выбор обусловлен наличием бесплатной инфраструктуры. Кто-то должен вложить миллионы, как Sun в Java, и вам тогда не придётся велосипедить и тратиться на поддержание стандарта. Это хороший, разумный выбор, который, однако, не основан на качествах формального аппарата.
А кто-то что-то сказал про «бесплатную»?
Но очевидно, что если какая-то технология не предоставляет инструментов для решения типовых задач, которые мне предстоят на проекте, у меня должны быть очень веские причины ей все равно воспользоваться (и, заметим, такие случаи в моей практике есть).
Что возвращает нас к вопросу — что бы я выиграл от использования Оберона в своем следующем проекте?
Но очевидно, что если какая-то технология не предоставляет инструментов для решения типовых задач, которые мне предстоят на проекте, у меня должны быть очень веские причины ей все равно воспользоваться (и, заметим, такие случаи в моей практике есть).
Что возвращает нас к вопросу — что бы я выиграл от использования Оберона в своем следующем проекте?
Компилятор стоит денег. Библиотеки стоят денег. Документация стоит денег. Поддержка комьюнити стоит денег. Все критики формального аппарата Оберона так или иначе обращаются к этим аргументам, потому что иметь доступ ко всем этим вещам критично для зарплаты. Раз никто не подготовил для них богатую и развитую инфраструктуру, то это значит, что Оберон плохой. Никто не обращает внимания на тот факт, что рыночным игрокам до лампочки, куда вкладываться. Вложилась же Sun в устаревший уже на тот момент виртовский P-code.
А на ваш вопрос я ответить не могу, ведь я не знаю, что у вас за проект.
Общие же соображения таковы:
1) кадровый вопрос. Изучить Оберон легко, поэтому вливание новых людей в проект на Обероне не потребует особых усилий.
2) надёжность. На Обероне сложно писать ненадёжный код, даже новичкам. Жёсткие правила приучают к аккуратности.
3) минимальный период отладки. На Обероне можно писать сразу правильный код, не затрачивая время на отладку. Написал — и сразу в продакшЫн. Тестирование, конечно, нужно, но оно больше для лечения от самых глупых ошибок.
4) не надо скриптовалок. Отличная модульность позволяет безопасно писать скрипты на самом Обероне.
5) прозрачность архитектуры. Отсутствие вытребенек в формальном аппарате освобождает мозг, вы занимаетесь исключительно задачей, а не изучением туториалов по особенностям однострочных литералов какого-нибудь сишарпа.
6) чувство железа. Вы пишете MODULE END и программный модуль превращается в бинарный код без оговорок. Вот текст модуля, вот его бинарник. Вы создаёте систему на уровне текста и ровно так же она выглядит в бинарном виде. Загрузили, выгрузили. Всё видно, всё на кончиках пальцев. Знаю людей, которым это ценно, да и сам такой.
А на ваш вопрос я ответить не могу, ведь я не знаю, что у вас за проект.
Общие же соображения таковы:
1) кадровый вопрос. Изучить Оберон легко, поэтому вливание новых людей в проект на Обероне не потребует особых усилий.
2) надёжность. На Обероне сложно писать ненадёжный код, даже новичкам. Жёсткие правила приучают к аккуратности.
3) минимальный период отладки. На Обероне можно писать сразу правильный код, не затрачивая время на отладку. Написал — и сразу в продакшЫн. Тестирование, конечно, нужно, но оно больше для лечения от самых глупых ошибок.
4) не надо скриптовалок. Отличная модульность позволяет безопасно писать скрипты на самом Обероне.
5) прозрачность архитектуры. Отсутствие вытребенек в формальном аппарате освобождает мозг, вы занимаетесь исключительно задачей, а не изучением туториалов по особенностям однострочных литералов какого-нибудь сишарпа.
6) чувство железа. Вы пишете MODULE END и программный модуль превращается в бинарный код без оговорок. Вот текст модуля, вот его бинарник. Вы создаёте систему на уровне текста и ровно так же она выглядит в бинарном виде. Загрузили, выгрузили. Всё видно, всё на кончиках пальцев. Знаю людей, которым это ценно, да и сам такой.
1) кадровый вопрос. Изучить Оберон легко, поэтому вливание новых людей в проект на Обероне не потребует особых усилий.
2) надёжность. На Обероне сложно писать ненадёжный код, даже новичкам. Жёсткие правила приучают к аккуратности.
3) минимальный период отладки. На Обероне можно писать сразу правильный код, не затрачивая время на отладку. Написал — и сразу в продакшЫн. Тестирование, конечно, нужно, но оно больше для лечения от самых глупых ошибок.
Если это так, то разработка на Обероне должна быть быстрее и дешевле, чем на других языках. Следовательно, эта разработка должна быть дешевле. Следовательно, должны быть компании-разработчики, которые почувствуют эту выгоду и применят Оберон для ее получения.
Можете привести пример хотя бы одной?
Понимаете, не бывает так, чтобы был простой, понятный, надежный (в наше время это очень важный критерий) инструмент, и никто на рынке (включая стартапы, которые хлебом не корми, дай что-нибудь нишевое использовать) им не пользовался.
PS и все-таки, можно привести пример хотя бы одной особенности Оберона, которая (а) повышает надежнось и (б) позволяет писать сразу правильный код — точнее, запрещает писать неправильный?
Примеров? Да пожалуйста. У меня когда-то был смартфон Portege G-900, так в нём был эмулятор Java от компании Esmertec, написанный на Обероне. www.computer-museum.ru/histsoft/oberon.htm
Компания Oberon Microsystems делала систему управления ГЭС на Амазонке.
Российские беспилотники летают на Обероне. На АЭС и конвейерном производстве внедряют.
Но как вкладываться в Оберон? Вы посмотрите на Хабр, тут комьюнити такое, что за отклонение от линии партии забьют ногами. Всё, история идёт дальше, рынок поделен, умы отформатированы. Процитирую давнишний тезис: «В последние годы ИТ-индустрия насильно превращает университеты в ремесленные училища.». И это так. Сейчас нужны ремесленники, выпускники ИТ-техникумов и больше ничего. Ну а Хабр наглядно демонстрирует именно ремесленное мышление.
Компания Oberon Microsystems делала систему управления ГЭС на Амазонке.
Российские беспилотники летают на Обероне. На АЭС и конвейерном производстве внедряют.
Но как вкладываться в Оберон? Вы посмотрите на Хабр, тут комьюнити такое, что за отклонение от линии партии забьют ногами. Всё, история идёт дальше, рынок поделен, умы отформатированы. Процитирую давнишний тезис: «В последние годы ИТ-индустрия насильно превращает университеты в ремесленные училища.». И это так. Сейчас нужны ремесленники, выпускники ИТ-техникумов и больше ничего. Ну а Хабр наглядно демонстрирует именно ремесленное мышление.
Компания Oberon Microsystems делала систему управления ГЭС на Амазонке.
Российские беспилотники летают на Обероне. На АЭС и конвейерном производстве внедряют.
Ну то есть исключительно производственные системы, правильно?
Но как вкладываться в Оберон? Вы посмотрите на Хабр, тут комьюнити такое, что за отклонение от линии партии забьют ногами.
А какая вам разница, что на Хабре пишут? Когда я запускаю свой проект, я ориентируюсь на себя и свою команду. А уж прагматичному западному рынку тем более плевать на нашу песочницу.
>Ну то есть исключительно производственные системы, правильно?
Никто не мешает написать игру на Обероне.
>А какая вам разница, что на Хабре пишут?
Хабр это лишь пример косности мышления. Когда продукт продавлен на рынок, то люди его начнут поддерживать автоматически. Если бы Sun продавливала Оберон или создатели языка Си не решали бы проблему программирования на ассемблере, у вас бы таких вопросов не возникало. Но продавили нечто совсем другое.
Никто не мешает написать игру на Обероне.
>А какая вам разница, что на Хабре пишут?
Хабр это лишь пример косности мышления. Когда продукт продавлен на рынок, то люди его начнут поддерживать автоматически. Если бы Sun продавливала Оберон или создатели языка Си не решали бы проблему программирования на ассемблере, у вас бы таких вопросов не возникало. Но продавили нечто совсем другое.
Никто не мешает написать игру на Обероне.
«Никто не мешает» — еще само по себе не аргумент. Как я говорил выше, должна быть мотивация так сделать.
Я там выше просил привести конкретный пример того, что делает Оберон таким, как вы его описываете.
Когда продукт продавлен на рынок, то люди его начнут поддерживать автоматически.
… а если продукт хороший, то люди тоже начнут им пользоваться. Например, Octopus, про который вы вряд ли слышали, и который, в отличие от BuildMaster, не занимается активным пиаром, но при этом прекрасно внедряется.
Вы задаётесь вопросом, что делает Оберон таким, как я его описываю?
Таким его сделал один инженер.
Таким его сделал один инженер.
Я задаюсь вопросом «что из функциональности Оберона гарантирует декларируемые вами характеристики».
У формального аппарата нет «функциональности». Формальный аппарат призван формализовывать концепции предметной области, а не «функционировать». Ваш вопрос некорректен, я не могу на него ответить.
Эээ. Тут меня есть сразу два вопроса.
(я сразу оговорюсь: особенность — это то, чего в других языках нет, или реализовано радикально иначе, или не в полной мере)
- какую предметную область формализует формальный аппарат языка Оберон?
- мне же не лень и переформулировать: какие особенности формального аппарата языка Оберон обеспечивают декларируемые вами характеристики этого языка (например, надежность и минимальный период отладки)
(я сразу оговорюсь: особенность — это то, чего в других языках нет, или реализовано радикально иначе, или не в полной мере)
Оберон — это язык общего назначения, на нём можно формализовать любые концепции.
Надёжность языка обеспечивается компактностью (не примитивностью!) синтаксиса. Эта особенность наглядно представлена графиком <www.uni-vologda.ac.ru/cs/syntax/graph.gif>, который я интерпретирую следующим образом: майнстримные ЯП движутся в направлении повышения возможностей на выходе, а оберон движется в направлении уменьшения ошибок на входе. Это та самая регистрация сложности на старте, о чём писал Дейкстра.
Преимущества Оберона не в наличии волшебных фичей, а в отсутствии лишних, малозначимых, вторичных.
Надёжность языка обеспечивается компактностью (не примитивностью!) синтаксиса. Эта особенность наглядно представлена графиком <www.uni-vologda.ac.ru/cs/syntax/graph.gif>, который я интерпретирую следующим образом: майнстримные ЯП движутся в направлении повышения возможностей на выходе, а оберон движется в направлении уменьшения ошибок на входе. Это та самая регистрация сложности на старте, о чём писал Дейкстра.
Преимущества Оберона не в наличии волшебных фичей, а в отсутствии лишних, малозначимых, вторичных.
Надёжность языка обеспечивается компактностью (не примитивностью!) синтаксиса.
Пожалуйста, аргументируйте этот тезис. Если вас послушать, то получается, что любой язык с компактным синтаксисом надежен.
Эта особенность наглядно представлена графиком <www.uni-vologda.ac.ru/cs/syntax/graph.gif>, который я интерпретирую следующим образом: майнстримные ЯП движутся в направлении повышения возможностей на выходе, а оберон движется в направлении уменьшения ошибок на входе.
На чем основана ваша интерпретация? На графике нет ничего о количестве ошибок — только отношение числа лексем ко времени.
Преимущества Оберона не в наличии волшебных фичей, а в отсутствии лишних, малозначимых, вторичных.
Пожалуйста, приведите пример «лишней» фичи, существующей в мэйнстримных языках, отсутствие которой в Обероне повышает надежность разработанного на нем ПО, при этом не теряя необходимой разработчику функциональности.
Компактность синтаксиса влияет на надёжность следующим образом. Программы пишет человек, используя формальный аппарат. Но возможности человека ограничены. Если аппарат раздут, количество понятий в нём велико, а отношения между понятиями не слишком наглядны, то допустить ошибку гораздо легче.
Конечно же, на надёжность влияет не только компактность синтаксиса. Про синтаксис я говорю, потому что есть анализ Свердлова.
Моя интерпретация основана на изучении текстов Вирта и Дейкстры, а так же на личном опыте программирования на Обероне. Я задавался вопросом — нафига выбрасывать это всё из языка. Опробовал в деле и получил ответ.
«Лишняя фича» — дженерики, например. Вирту задавали вопрос про дженерики, он ответил в том смысле, что дженерики плодят неконтролируемый код, что может снизить надёжность. И я с ним согласен, ведь я не вижу сгенерированного кода, а значит, не могу за него отвечать.
Конечно же, на надёжность влияет не только компактность синтаксиса. Про синтаксис я говорю, потому что есть анализ Свердлова.
Моя интерпретация основана на изучении текстов Вирта и Дейкстры, а так же на личном опыте программирования на Обероне. Я задавался вопросом — нафига выбрасывать это всё из языка. Опробовал в деле и получил ответ.
«Лишняя фича» — дженерики, например. Вирту задавали вопрос про дженерики, он ответил в том смысле, что дженерики плодят неконтролируемый код, что может снизить надёжность. И я с ним согласен, ведь я не вижу сгенерированного кода, а значит, не могу за него отвечать.
Компактность синтаксиса влияет на надёжность следующим образом. Программы пишет человек, используя формальный аппарат. Но возможности человека ограничены. Если аппарат раздут, количество понятий в нём велико, а отношения между понятиями не слишком наглядны, то допустить ошибку гораздо легче.
Верно и обратное: если количество понятий в аппарате слишком мало, то каждое понятие слишком многозначно. Следовательно, должен быть диапазон между «слишком мало» и «слишком много».
Про синтаксис я говорю, потому что есть анализ Свердлова.
Ссылку?
«Лишняя фича» — дженерики, например. Вирту задавали вопрос про дженерики, он ответил в том смысле, что дженерики плодят неконтролируемый код, что может снизить надёжность. И я с ним согласен, ведь я не вижу сгенерированного кода, а значит, не могу за него отвечать.
Прекрасно. Чем вы предлагаете заменить дженерики, чтобы написать код работы с коллекцией (например, стеком) единожды, он работал с элементами любого типа, и при этом сохранялась строгая типизация?
Надёжность языка обеспечивается компактностью (не примитивностью!) синтаксиса
Нет ли языков с более компактным синтаксисом? (LISP, Smalltalk, Brainfuck)
Если какую-то синтаксическую конструкцию где-то можно реализовать как функцию, меняет ли это принипиально дело?
Почему «вытребенька» foreach ненадежна вот так:
foreach(var customer in customers){
Console.WriteLine(customer.Name);
}
Но надежна вот так:
customers.ForEach( customer => Console.WriteLine(customer.Name))
Почему дублирование кода надежнее чем использование готовых конструкций?
Каждый умный человек на хабре неустано вспоминая brainfuck, забывает про понятие turing tarpit. Oberon не входит в число языков, которые можно причислить к tarpit.
Я не настолько умный, чтобы знать это понятие. Не затруднит ли вас пояснить свою точку зрения на остальные вопросы и языки (например можно мысленно вычистить brainfuck из коммента и ответить на него).
Smalltalk и Оберон обсуждали/сравнивали в треде про Smalltalk habrahabr.ru/company/flprog/blog/257611
А Lisp это же просто удобное описание AST-деревьев. Программировать деревья это классно, компиляторы любят AST, а вот про людей я не уверен. Вот почитайте про проект коллеги, он вам расскажет, как оно, работать на уровне AST habrahabr.ru/post/252677
А Lisp это же просто удобное описание AST-деревьев. Программировать деревья это классно, компиляторы любят AST, а вот про людей я не уверен. Вот почитайте про проект коллеги, он вам расскажет, как оно, работать на уровне AST habrahabr.ru/post/252677
вот кстати, напомнили еще про одну вытребеньку — with
То есть поддерживается контроль за закрытием файла — невозможно забыть его закрыть и невозможно его использовать после закрытия.
Как в Обероне с этим?
Можно было бы не использовать спецконструкцию а просто сделать библиотечный метод:
with( var f = openFile())
{
f.Write("foo");
}
То есть поддерживается контроль за закрытием файла — невозможно забыть его закрыть и невозможно его использовать после закрытия.
Как в Обероне с этим?
Можно было бы не использовать спецконструкцию а просто сделать библиотечный метод:
openFile().With(f => f.Write("foo"));
Теперь под мощью этих продуктов, например, у меня ноут трещит
Никогда не понимал, что в наши дни стоит купить ноут по мощнее? Моему ноуту два года, он легкий, компактный, держит пол дня от батареи и не тормозит когда я запускаю на нем ide, какой нибудь box в vagrant напичканный серверами, фотошоп и браузер. Моему компу три года, и он тоже не тормозит ни при каких типичных рабочих ситуациях. И все это не стоило мне каких то космических денег, бук половину ЗП, комп еще дешевле бука (разумеется только системник).
Из каких соображений вы отказываете себе в удобстве?
Чтобы решить проблемы запуска, достаточно поставить SSD, ведь дисковая подсистема реальный тормоз.
У вас SSD?
Если нет, озвучьте, если нетрудно, следующие параметры:
1) сколько времени проходит от холодного (после перезагрузки) старта системы до открытия рабочего стола?
2) сколько времени уходит на то, чтобы после появления рабочего стола (а это признак готовности системы к работе) открыть страничку в браузере и перейти на адрес habrahabr.ru?
У вас SSD?
Если нет, озвучьте, если нетрудно, следующие параметры:
1) сколько времени проходит от холодного (после перезагрузки) старта системы до открытия рабочего стола?
2) сколько времени уходит на то, чтобы после появления рабочего стола (а это признак готовности системы к работе) открыть страничку в браузере и перейти на адрес habrahabr.ru?
Коллега, я удивлен, что каждый ваш комментарий получает минус, ведь на хабре стоит ограничение на употребление минусов для каждого пользователя. Однако, может быть и правда Вы говорите то, что не по душе сообществу.
Напишите. Серьёзно, я бы почитал.
А мне пока нравится выбранный формат статей. Про Оберон писать нечего, в целом.
яист с оператором unsafe направлен на безопасность
ПаЦтаЛом :D
Да и в целом, отличная легкая статья. Читается на одном дыхании.
Спасибо.
Смысыл начальной фразы сохранится если её заменить на: «неожиданно вы понимаете, что вам бы чего попроще»
плюсовые разработчики наоборот очень страдают при переходе на подобноые языки. Недалеко ходить взять джаву. Нормальных шаблонов нет, лямбды с какими-то престранными скопами, указатель на функцию нет (что уж говорить про указатель на метод), константы и те не причудливые и тд и тп.
плюсовые разработчики наоборот очень страдают при переходе на подобноые языки. Недалеко ходить взять джаву. Нормальных шаблонов нет, лямбды с какими-то престранными скопами, указатель на функцию нет (что уж говорить про указатель на метод), константы и те не причудливые и тд и тп.
Модели памяти автор уделил целый подраздел. Остальное тоже в статье есть.
И потом, значение имеет все. В первую очередь текст программ, кроме которого у программиста ничего нет. Если бы синтаксис не имел смысла, он был бы взаимозаменяемым, или настраиваемым под пользователя в IDE. Так что Вам следует быть аккуратнее в своих высказываниях.
И потом, значение имеет все. В первую очередь текст программ, кроме которого у программиста ничего нет. Если бы синтаксис не имел смысла, он был бы взаимозаменяемым, или настраиваемым под пользователя в IDE. Так что Вам следует быть аккуратнее в своих высказываниях.
Такие то потуги обокакать раст. Автора жаль.
Вот ведь, читал — думал, щас дочитаю, напишу коммент типа «Чо сказать-то хотел?» Но дочитал, увидел ник автора — и вопрос как-то сам собой отпал.
Далее следует объявление переменной, которое совмещено с инициализацией и размещено прямо в коде. Ну а как еще, не делать же отдельную секцию переменных, как в восьмидесятых. Тогда угрюмые колхозники писали все переменные в строго выделенном месте, чтобы потом их в этом месте найти. Вот так ограничивали свободу выражения творческих личностей. Принуждали к порядку. Хорошо, что мы избавились от этого пережитка.
С моей точки зрения переменная, это второстепенная деталь реализации и очень хорошо, когда ее пишут по месту первого использования.
— сразу понятно где и зачем она нужна
— этот кусок кода легко выделить в отдельный метод, если надо (не надо одновременно копировать из двух мест)
— не надо куда-то перемещаться смотреть ее объявление (а может Оберон надо ввести подобие дублирования имени метода после END — при каждом использовании переменной введсти обязательное дублирование ее описания?)
— нельзя случайно ее использовать (например присвоить туда значение) до той строки, где она объявлена — если она имеет смысл в цикле, то и область видимости будет в цикле
Оберон действительно производит впечатление языка, где порядок ради порядка. Еще можно потребовать идентификаторы упорядочивать по алфавиту…
Не надо так отчаянно защищать свое мировоззрение, на него никто не посягает.
Мне кажется, это проекция :). Я просто изложил свое видение вопроса. Мне было бы интересно если бы вы со мной аргументированно не согласились, но вы не привели ни одного аргумента. Как жаль.
Может напишете позитивную статью про Оберон?
Может напишете позитивную статью про Оберон?
Это замкнутый круг. Без общей системы координат (которой нет) мы так и будет друг с другом спорить до бесконечности. Я уже 10 лет в сообществе Оберона, каждый Ваш аргумент мне знаком, практически идентичный можно найти в предыдущих обсуждениях. Я понял контрпродуктивность этой движухи, поэтому теперь просто пишу статьи про странный мир вокруг меня. Это не считая того, что собеседники часто вообще считают себя лучше меня буквально, в личностном плане, и их общение со мной складывается по шаблонам дворовой борьбы за доминирование. Многие считают, что это весело. В итоге все вырождается либо в выяснение, у кого больше опыт работы, кто пилил более хардкорные продукты или кто более умело может составить логически непротиворечивое предложение из нужных оскорбительных слов.
В какой вариант вы хотите выродить эту ветку?
В какой вариант вы хотите выродить эту ветку?
Например, если вы уже написали стройно труктурированную статью «почему мне нравится Оберон» можно дать на нее ссылку.
Или можно просто игнорировать сообщения, которые вам кажется глупыми.
Мне кажется в такой форме статьи и ваши ответы только поддерживают движуху про которую вы говорите, что она неправильная.
Или можно просто игнорировать сообщения, которые вам кажется глупыми.
Мне кажется в такой форме статьи и ваши ответы только поддерживают движуху про которую вы говорите, что она неправильная.
Это Уловка-22, как бы хорошо и правильно я не говорил про Оберон, неприязнь сообщества будет расти, и формат моих постов не при чем, в треде можно найти откровенно хамские комментарии в мой адрес, которые были одобрены многими людьми. Потому единственный объективный факт состоит в том, что ИТ-сообществу en masse Оберон не нравится уже сейчас. Вы же не будете с этим фактом спорить?
Приведите пример позитивного поста про Оберон (не путать с негативными постами про другие языки в ставнении с Обероном), который вызвал такую реацию?
Есть ли какое-то объяснение тому, что именно посты про оберон собирают негатив (вы выше привели пост про Смолток, в обсуждении которого упоминался Оберон, и дискуссия была в довольно приличной манере, хотя стороны друг друга явно не понимали).
Есть ли какое-то объяснение тому, что именно посты про оберон собирают негатив (вы выше привели пост про Смолток, в обсуждении которого упоминался Оберон, и дискуссия была в довольно приличной манере, хотя стороны друг друга явно не понимали).
Посты про Оберон ломают мем «Оберон забыт». Людям неприятно, когда их привычное мировоззрение даёт трещину. Ведь эффект confirmation bias работает для всех одинаково, программист ты или нет.
Для программистов ситуация ещё хуже, ведь они привыкли работать с формальными системами и абсолютными исполнителями. Любое поползновение к изменению точки зрения грозит разрушением картины мира. Поэтому требуется срочно восстановить статус-кво, вытеснить минусованием оппов в серый предел и забыть как страшный сон (казалось бы причём тут мозговед и страшный тролль проф. Савельев?).
Я про это говорю совершенно серьёзно, потому что мои посты про то, что даёт оберон-подход, встречают обструкцию вида «оберон не лучше того, к чему мы привыкли, вы всё врёте». Другими словами, я про Фому, а мне про Ерёму.
Дейкстра был прав.
Для программистов ситуация ещё хуже, ведь они привыкли работать с формальными системами и абсолютными исполнителями. Любое поползновение к изменению точки зрения грозит разрушением картины мира. Поэтому требуется срочно восстановить статус-кво, вытеснить минусованием оппов в серый предел и забыть как страшный сон (казалось бы причём тут мозговед и страшный тролль проф. Савельев?).
Я про это говорю совершенно серьёзно, потому что мои посты про то, что даёт оберон-подход, встречают обструкцию вида «оберон не лучше того, к чему мы привыкли, вы всё врёте». Другими словами, я про Фому, а мне про Ерёму.
Дейкстра был прав.
Посты про Оберон ломают мем «Оберон забыт».
Я не думаю, что Оберон занимает хоть какое-то место в голове присутствующего здесь большинства. Сомневаюсь в существовании такого мема.
Любое поползновение к изменению точки зрения грозит разрушением картины мира.
Я вот пока не вижу какой-то особой мирровозренческой ценности в Обероне. По крайней мере, описанной в ваших постах. Гораздо необычнее монады в Haskell или «все есть объект» в Smalltalk, или минималистичный подход LISP.
Я про это говорю совершенно серьёзно, потому что мои посты про то, что даёт оберон-подход, встречают обструкцию вида «оберон не лучше того, к чему мы привыкли, вы всё врёте».
А где, собственно, посты про то, что дает Оберон — подход? Я пока вижу только общие слова (прошерстил по тегу «Оберон»). Где пост проиллюстрированный примерами кода на Обероне?
У меня вопрос скорее по Оберону (хотя топик не совсем про него, но тем не менее).
Скажите пожалуйста, если в нем все переменные нужно объявлять в начале функции, то я не могу объявить счетчик для цикла так, чтобы он был виден только внутри цикла?
В С89 в основном это очень раздражает.
Скажите пожалуйста, если в нем все переменные нужно объявлять в начале функции, то я не могу объявить счетчик для цикла так, чтобы он был виден только внутри цикла?
В С89 в основном это очень раздражает.
Такой фичи в Обероне нет.
Вот кстати, казалось бы. Почему ее нет?
Ее преимущества понятны. Какие у нее недостатки, которые отражались бы на качестве результирующего ПО?
Ее преимущества понятны. Какие у нее недостатки, которые отражались бы на качестве результирующего ПО?
Потому что циклы со счетчиком это лишняя фича, потому что цикл со счетчиком устарел и отлично эмулируется циклом с предусловием. А у него нет никакого счетчика.
Ага, то есть нет не локальных для цикла переменных, а вообще циклов со счетчиком. А вы не приведете пример цикла с предусловием?
Циклы с пред- и пост-условиями проходят в курсе школьной информатики, извините.
Мне в школе не преподавали информатику, вот печаль. Впрочем, проблема-то не в этом, а в том, чтобы определение, используемое одним собеседником, совпадало с определением, используемым другим собеседником. После прочтения определения из википедии у меня лично возник вопрос: каким, все-таки, образом в Обероне предлагается решить типовую задачу «для каждого элемента из коллекции напечатать название на экране выполнить то или иное действие» (менее типовой вариант: повторить действие k раз)?
(лучше, конечно, сразу с примерами кода)
(лучше, конечно, сразу с примерами кода)
Эта типовая задача проистекает из архитектурного решения, использующего коллекции.
Если у вас гетерогенная структура построена на шине сообщений, то коллекции вам просто не нужны, посылайте агентам сообщения.
Даже если взять коллекцию. Как вы отработаете ситуацию, когда ваше действие возможно будет применить только к одному элементу коллекции, а остальные не смогут этого сделать? Как вы отработаете ситуацию, когда нужно применить действие не к каждому элементу коллекции? Это совершенно типовые задачи на выборочную коммуникацию.
Если у вас гетерогенная структура построена на шине сообщений, то коллекции вам просто не нужны, посылайте агентам сообщения.
Даже если взять коллекцию. Как вы отработаете ситуацию, когда ваше действие возможно будет применить только к одному элементу коллекции, а остальные не смогут этого сделать? Как вы отработаете ситуацию, когда нужно применить действие не к каждому элементу коллекции? Это совершенно типовые задачи на выборочную коммуникацию.
Если у вас гетерогенная структура построена на шине сообщений, то коллекции вам просто не нужны, посылайте агентам сообщения.
А агенты бывают только поштучно? В той же акке
children — это коллекция, и сообщения туда шлются через forEach.Как вы отработаете ситуацию, когда ваше действие возможно будет применить только к одному элементу коллекции, а остальные не смогут этого сделать?
В зависимости от постановки задачи — либо обработкой ошибочной ситуации, либо пропуском объекта.
Как вы отработаете ситуацию, когда нужно применить действие не к каждому элементу коллекции?
Условием (а что, это какая-то проблема?).
Если у вас гетерогенная структура построена на шине сообщений, то коллекции вам просто не нужны, посылайте агентам сообщения.
Никаких гетерогенных структур и шин. Просто в предметной области есть что-то содержащие в себе элементы. Например вы пишете приложение адресную книжку и вам надо выполнят различные действия с ее элементами.
Мне кажется тут есть некое фнудаментальное различие в подходах типа mappers vs packers: я вижу программу как реализаию некоторой модели придметной области, вы составляете ее из программных деталей типа «шин» и «агентов».
Например модель предметной области телефонная книжка:
// запись телефонной книжки это имя и номер телефона
class PhoneBookRecord {
string Name;
string Phone;
}
// Телефонная книжка содержит в себе записи
class PhoneBook {
List<PhoneBookRecord> Records = new List<PhoneBookRecord>();
}
А теперь какой-нибудь просто агоритм
// преобразование телефонной книжки в HTML
string convertToHtml(PhoneBook phonebook)
{
// это соединенная через тег
последовательность html предствалений записей
return String.Join("
", phonebook.Records.Select(convertToHtml));
}
// преобразование записи в HTML
string convertToHtml(PhoneBookRecord record)
{
// искейпинг опускаем
return String.Format("<b>{0}</b>: {1}", record.Name, record.Phone);
}
Здесь исходник очень близок к описанию задачи — никаких агентов и шин.
Если мне вдруг захочется поменять список на массив или SQL базу данных, я вполне себе смогу переделать эту деталь без переделки остальных частей.
Хотелось бы в качестве примера решение на Обероне.
Товарищ с десятилетним опытом в оберон-коммьюнити каждый раз категорически отказывается код переводить, потому что либо примеры синтетические, либо и ежу понятно, что на обероне удобнее будет. Так что не ждите, кина не будет.
Пока я трачу время на перевод, вы потратите его на придумывание «экспертной оценки читаемости и выразительности». Мне это не надо. Если Вам надо, вы и переводите, поди, неглупый человек сможет осилить Оберон.
То есть тратить время на сотню комментариев за десять дней — это можно, а кусочек кода показать — всё, приехали?
Минуточку, это вам как раз и надо. Судя по вашим статьям, текстам и постам, ваша цель — показать, какой оберон замечательный по сравнению с нынешним унылым мейнстримом. Возможно, так оно и есть, мы же априори не знаем. Ну так продемонстрируйте же это, покажите, какой профит мы получим при решении наших задач, сподвигните на дальнейшее изучение, а не отделывайтесь посылами в стиле «кому надо, тот сам всё узнает», потому что то, что мы тут пока увидели, как-то не вдохновляет. В общем, критикуя — предлагайте.
Мне это не надо. Если Вам надо
Минуточку, это вам как раз и надо. Судя по вашим статьям, текстам и постам, ваша цель — показать, какой оберон замечательный по сравнению с нынешним унылым мейнстримом. Возможно, так оно и есть, мы же априори не знаем. Ну так продемонстрируйте же это, покажите, какой профит мы получим при решении наших задач, сподвигните на дальнейшее изучение, а не отделывайтесь посылами в стиле «кому надо, тот сам всё узнает», потому что то, что мы тут пока увидели, как-то не вдохновляет. В общем, критикуя — предлагайте.
Вопрос только в том, что тратить моё время на комментарии нужно мне, а тратить моё время на код нужно Вам. Субъект и объект меняются местами. Такое положение дел меня не устраивает, конечно.
Я же предложил, изучайте Оберон. Вы что, не заметили, как я это предложил? Если у Вас возникнут вопросы в процессе изучения, я готов помочь. А предоставлять свои услуги по предоставлению Вам объекта оценки, признавая Вашу роль оценщика я не хочу, уж извините. Это проигрышная позиция. Еще и время потрачу.
Ваше право написать статью про Оберон и собрать за неё кучу плюсов. Там заодно и оцените.
Я же предложил, изучайте Оберон. Вы что, не заметили, как я это предложил? Если у Вас возникнут вопросы в процессе изучения, я готов помочь. А предоставлять свои услуги по предоставлению Вам объекта оценки, признавая Вашу роль оценщика я не хочу, уж извините. Это проигрышная позиция. Еще и время потрачу.
Ваше право написать статью про Оберон и собрать за неё кучу плюсов. Там заодно и оцените.
Можно поинтересоваться, для чего вам нужно тратить время на статьи по оберону и их активное комментирование?
Для этого мне, в свою очередь, желательны свидетельства того, что оное изучение будет стоить потраченного времени ;) Пока я их не вижу. А вот для, гм, яиста увидел, и пока не разочаровался.
Чего это? Роли равноправны, каждый показывает код на своём языке и сравнивает с кодом на чужом, при этом сторон может быть сколько угодно.
Я же предложил, изучайте Оберон.
Для этого мне, в свою очередь, желательны свидетельства того, что оное изучение будет стоить потраченного времени ;) Пока я их не вижу. А вот для, гм, яиста увидел, и пока не разочаровался.
признавая Вашу роль оценщика
Чего это? Роли равноправны, каждый показывает код на своём языке и сравнивает с кодом на чужом, при этом сторон может быть сколько угодно.
Ну и чтобы не быть голословным, приведу аналог на идиоматически и синтаксически далёком хаскеле:
data PhoneBookRecord = PBR String String
data PhoneBook = PB [PhoneBookRecord]
pbToHtml (PB records) = unwords $ map pbrToHtml records
pbrToHtml (PBR name phone) = Text.printf "<b>%s</b>: %s" name phone
Мне просто нравится писать статьи про Оберон, я оберонщик-графоман.
Ну вот желательные свидетельства вы оцените из мнения коллег. Я там сверху описал алгоритм изучения языка. Коллеги мнение свое высказали. Теперь очередь за описанием языка.
Ну вот желательные свидетельства вы оцените из мнения коллег. Я там сверху описал алгоритм изучения языка. Коллеги мнение свое высказали. Теперь очередь за описанием языка.
Ну вот осилю я его (Оберон), переведу, получится хуже и нечитаемее. Это потому, что Оберон плохой, или потому, что я его неправильно осилил?
Очевидно ж. Если правильно осилите — переведёте и увидите, что стало-то лучше и читаемее!
Я там спросил, в чем «читаемость» измеряется, мне минусов накидали, так что я у Вас не буду этого спрашивать.
Это, очевидно, субъективная метрика. А вы чего-то другого ожидали?
Но я, кстати, даже не читаемость в этой ветке обсуждал, мне было интересно, как принципиально Оберон решает задачу обхода коллекции.
Но я, кстати, даже не читаемость в этой ветке обсуждал, мне было интересно, как принципиально Оберон решает задачу обхода коллекции.
То есть говоря о читаемости Вы предлагаете писать код ради того чтобы узнать содержимое Вашей головы? Вы серьезно? А потом Ваша голова скажет, что Оберон — фигня, вот это ценность, ради этого стоит писать код.
По факту, ваш вопрос некорректен, потому что в Обероне нет понятия коллекций. Коллекция — это обобщенное название некоторых видов структур данных. Структуры данных типа коллекций могут быть описаны на языке Оберон, равно как и любые другие структуры.
По факту, ваш вопрос некорректен, потому что в Обероне нет понятия коллекций. Коллекция — это обобщенное название некоторых видов структур данных. Структуры данных типа коллекций могут быть описаны на языке Оберон, равно как и любые другие структуры.
По факту, ваш вопрос некорректен, потому что в Обероне нет понятия коллекций. Коллекция — это обобщенное название некоторых видов структур данных. Структуры данных типа коллекций могут быть описаны на языке Оберон, равно как и любые другие структуры.
Выше уже описывали задачу в прикладных терминах (например, как телефонный справочник и записи в нем). Предположим, что для какой-то операции нужно пройти по всем записям (порядок обхода пока не обсуждаем) и выполнить какое-то действие. Как это делается в мейнстриме (скажем, на C#) — выше уже показано.
А на Обероне?
Я ничего про оберон не знаю, но вот обход коллекции
А вообще на rosettacode почему-то удивительно мало примеров кода на обероне.
А вообще на rosettacode почему-то удивительно мало примеров кода на обероне.
Спасибо, выглядит предсказуемо.
Собственно, вопрос к адептам Оберона очень прост: что язык и результирующий код выигрывают от того, что программист обязан объявить переменную, выступающую индексом массива (она же, фактически, счетчик в данном примере) в заголовке процедуры?
Собственно, вопрос к адептам Оберона очень прост: что язык и результирующий код выигрывают от того, что программист обязан объявить переменную, выступающую индексом массива (она же, фактически, счетчик в данном примере) в заголовке процедуры?
А что, они утверждали, что выигрывает? Я просто весь этот дикий холивар в голове одновременно удерживать. Увидел ваш вопрос — и стало интересно, залез на розетту. Я так думаю — программист ничего не выигрывает и инчего не проигрывает. Какая по большому счёт разница где объявлять переменные? Если того требует синтаксис языка — то нормальная IDE должна подсказать, что такой переменной пока нету и предложить её создать.
Вот моя точка зрения
В кратце — более осмысленный скоп.
+ чем более эксотичный язык, тем меньше вероятность что будет нормальная IDE. Например автоматический инструмент рефакторинга который перенесет кусок кода с использованными переменными другое место. А в случае локального декларирования это сделать проще.
В кратце — более осмысленный скоп.
// какой-то код
// здесь нельзя ошибочно использовать переменную I
for(var i in myArray1)
{
// здесь можно использовать i
}
// здесь нельзя по ошибке использовать I
for(var i in myArray1)
{
// здесь можно использовать i
}
// здесь нельзя по ошибке использовать I
+ чем более эксотичный язык, тем меньше вероятность что будет нормальная IDE. Например автоматический инструмент рефакторинга который перенесет кусок кода с использованными переменными другое место. А в случае локального декларирования это сделать проще.
Ну слушайте, мы сначала обсуждали for со счетчиком, а теперь перешли вообще к форычу. Вы уж определитесь.
Ну и в целом, если я объявил переменную i до двух циклов, то переменная i в цикле 1 и в цикле 2 свое отработала, дальше я могу ее использовать, как захочу. Например, посмотрю, какой элемент оказался последним в списке после цикла 1 и после цикла 2. Таким образом, само собой получается, что все переменные лучше размещать до любого использования.
Не говоря уже о том, что в невырожденных циклах с обобщенным булевым условием это условие может быть на «счетчик», на накопленный результат, на промежуточные результаты, на ошибку, и все это в одном цикле, который должен мне что-нибудь эффективно разобрать или выбрать.
Вот, почитайте про цикл Дейкстры и его развитие, оцените концептуальное расстояние от тупого пробега по массиву элементов два раза, как в Вашем примере. ru.wikipedia.org/wiki/%D0%A6%D0%B8%D0%BA%D0%BB_(%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)#.D0.A6.D0.B8.D0.BA.D0.BB_.D0.94.D0.B5.D0.B9.D0.BA.D1.81.D1.82.D1.80.D1.8B (привет, отсутствие разметки)
Ну и в целом, если я объявил переменную i до двух циклов, то переменная i в цикле 1 и в цикле 2 свое отработала, дальше я могу ее использовать, как захочу. Например, посмотрю, какой элемент оказался последним в списке после цикла 1 и после цикла 2. Таким образом, само собой получается, что все переменные лучше размещать до любого использования.
Не говоря уже о том, что в невырожденных циклах с обобщенным булевым условием это условие может быть на «счетчик», на накопленный результат, на промежуточные результаты, на ошибку, и все это в одном цикле, который должен мне что-нибудь эффективно разобрать или выбрать.
Вот, почитайте про цикл Дейкстры и его развитие, оцените концептуальное расстояние от тупого пробега по массиву элементов два раза, как в Вашем примере. ru.wikipedia.org/wiki/%D0%A6%D0%B8%D0%BA%D0%BB_(%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)#.D0.A6.D0.B8.D0.BA.D0.BB_.D0.94.D0.B5.D0.B9.D0.BA.D1.81.D1.82.D1.80.D1.8B (привет, отсутствие разметки)
В данном кокретном аспекте совершенно все равно какая кокретно конструкция используется, главное что есть ограниченный скоп и меньше вероятности сделать некоторые виды ошибок.
Циклы дейкстры совершеено пофиг в разрезе того, где декларировать переменную.
Почему обход массива два раза — тупой? Между этими бзодами вполне может быть код модифицирующий массив?
Циклы дейкстры совершеено пофиг в разрезе того, где декларировать переменную.
Почему обход массива два раза — тупой? Между этими бзодами вполне может быть код модифицирующий массив?
Ограниченный скоп означает, что у вас в коде кандидат на вынос в отдельный метод или хотя бы замыкание. А там свой скоуп.
То есть, если Вы все-таки меняете изначальный вопрос про внутренний счетчик цикла на вопрос про скоупы вообще, то желательно хотя бы предупредить об этом всех собеседников.
А в Обероне скоуп описывается процедурой/модулем, никаких других скоупов нет. Но процедуры могут быть вложенные, что позволяет выражать вложенные скоупы. А помимо процедур они не нужны нигде.
То есть, если Вы все-таки меняете изначальный вопрос про внутренний счетчик цикла на вопрос про скоупы вообще, то желательно хотя бы предупредить об этом всех собеседников.
А в Обероне скоуп описывается процедурой/модулем, никаких других скоупов нет. Но процедуры могут быть вложенные, что позволяет выражать вложенные скоупы. А помимо процедур они не нужны нигде.
Ограниченный скоп означает, что у вас в коде кандидат на вынос в отдельный метод или хотя бы замыкание. А там свой скоуп.
Я с этим согласен, но практически так никто не делает — я думаю можно взять любой достаточно большой код и там будет практически всегда логический скоуп переменной меньше чем вся функция.
Когда мы захотим этот кусок кода вынести в отдельную функцию нам будет легче копировать непрерывный кусок, чем два несвязанных.
Оберон, как я понял, не поддерживает замыканий en.wikipedia.org/wiki/First-class_function#Language_support
То есть, если Вы все-таки меняете изначальный вопрос про внутренний счетчик цикла на вопрос про скоупы вообще, то желательно хотя бы предупредить об этом всех собеседников.
Посмотрите эту ветку комментариев повнимательнее (начиная с ответа habrahabr.ru/users/asm0dey). Она вообще не относится к счетчикам циклов, а относится к скоупам. Мое сообщение содержит слово скоуп в самом начале.
Да, вы правы. С другой стороны можно вынести каждый из этих циклов в отдельную процедуру и вероятность ошибки поуменьшится, наверное…
Сильно ухудшается читаемость. Вот пример на C#:
Navigator01 nav = GetComponent ();
nav.enabled = false;
ConstantForce force = GetComponent ();
force.enabled = false;
Death01 death = GetComponent ();
death.Play ();
Поток управления перемешан с объявлением переменных, читать такое крайне тяжко. Конечно, можно объявить переменные раньше, одним блоком (специального места для объявления нет, поэтому объявлять можно где угодно, повышая вероятность неаккуратного использования). Но зачем, ведь язык попустительствует, надо пользоваться возможностями.
Navigator01 nav = GetComponent ();
nav.enabled = false;
ConstantForce force = GetComponent ();
force.enabled = false;
Death01 death = GetComponent ();
death.Play ();
Поток управления перемешан с объявлением переменных, читать такое крайне тяжко. Конечно, можно объявить переменные раньше, одним блоком (специального места для объявления нет, поэтому объявлять можно где угодно, повышая вероятность неаккуратного использования). Но зачем, ведь язык попустительствует, надо пользоваться возможностями.
Я думаю, просто непривычно — для меня такой код вполне читаем. + еще я обычно использую вывод типов:
var navigator = GetComponent ();
navigator.enabled = false;
var force = GetComponent ();
force.enabled = false;
var death = GetComponent ();
death.Play ();
Еще можно тип объявить посреди вызовов. И тут же его реализовать. А в Яисте можно даже два одноименных биндинга подряд объявить, вон до чего дошел прогресс. Больше лапши.
«А в чём измеряется читаемость?» ©
Когда переменная существует внутри всей функции, а не ровно в том месте, где она используется, эта вероятность ничуть не снижается.
объявлять можно где угодно, повышая вероятность неаккуратного использования
Когда переменная существует внутри всей функции, а не ровно в том месте, где она используется, эта вероятность ничуть не снижается.
Вот ровно для этого и сделали вывод типов — чтобы такой код читался легче. Вот вам F#:
(другое дело, что все эти
let nav = GetComponent()
nav.Disable()
let force = GetComponent()
force.Disable()
let death = GetComponent()
death.Play()
(другое дело, что все эти
GetComponent давно и прочно вытесняются DI, но это уже нюансы; в конце концов, я же не телепат, чтобы знать, что там на самом деле внутри)То есть, люди создали проблему, потому что хотелось лапши и не принудиловки, а потом еще пару релизов решают проблемы с последствиями первой проблемы. А ведь достаточно было не создавать проблем.
Делай сейчас, думай потом. Вот об этом и статья.
Делай сейчас, думай потом. Вот об этом и статья.
Давайте обсудим почему вы считаете это лапшой. Поясните в чем тут лапшистость? Статический контроль типов на месте, за использованием переменной больше контроля.
Это лапша строго потому, что для выяснения существования переменной в определенной строке кода мне придется прочитать весь код, со всеми его скоупами и как в лапше пойти по следам отдельной макаронины-переменной, которую кто-то засунул не в тот скоуп не в тот момент, а потом ее заменили на такую же, такого же типа с тем же именем, но в верхнем скоупе, и третий человек перепутал i и i и ожидает значения совсем не там где оно должно быть.
Вы видите, это даже описать трудно, а вы хотите так программировать и еще меня потом заставят ваш код читать и чинить.
Вы видите, это даже описать трудно, а вы хотите так программировать и еще меня потом заставят ваш код читать и чинить.
Вероятно я с вами соглашусь что где-то это мешает делать методы большого размера. Лично я считаю методы большого размера злом.
То есть когда объявление и использование переменной напрочь разделены, и чтобы подглядеть, откуда какая берётся и какого она типа, нужно туда-сюда мотаться между блоком объявления и основным кодом, это не лапша?
В чем именно вы видите проблему?
Никто ведь не заставляет писать, как вы выражаетесь «лапшу», можно делать и явное определение сверху — только можно делать и не так, когда нужно получить локальные области видимости, неявную типизацию и многие другие вещи, которые в итоге делают код намного более читаемым.
Я уже неоднократно спрашивал: в чем выигрыш от решения, которое принуждает программиста определять все переменные в одном месте?
Никто ведь не заставляет писать, как вы выражаетесь «лапшу», можно делать и явное определение сверху — только можно делать и не так, когда нужно получить локальные области видимости, неявную типизацию и многие другие вещи, которые в итоге делают код намного более читаемым.
Я уже неоднократно спрашивал: в чем выигрыш от решения, которое принуждает программиста определять все переменные в одном месте?
То есть отсуствие поиска макаронины не является для Вас выигрышем? Вам и сейчас хорошо. Это в целом подтверждает мои слова о том, что вы не то что не видите, вы не понимаете проблемы. Для вас не проблема, что вся индустрия пишет лапшу, ведь лично мне можно и не писать лапшу. А потом разбираться в коде 95% лапшеписателей. А что, ведь это все в ногу идут, а я не в ногу.
То есть отсуствие поиска макаронины не является для Вас выигрышем?
А я не вижу ситуации, в которой «поиск макаронины» возникает из-за произвольных определений переменных. Переопределение переменной во внутреннем скоупе — штука не такая частая (скажем, в C# ее нет).
Мне в моей жизни много раз приходилось разбирать отвратительный код — и большую часть времени он был отвратительным из-за того, что использовались слишком большие области видимости, а не слишком маленькие.
Давайте просто разберем по пунктам. Вот у нас есть строчка кода внутри некоторой процедуры/функции/метода. В этой строчке используется некий
x. Что вы хотите о нем знать, что заставляет вас «разбирать лапшу»?Вы не видите, ну ок, Вы правы. У вас на руках статистика с хорошей выборкой. И вообще, вы мыслите логично, рационально и даже позитивно, все будет хорошо, баги починятся, новые не появятся, всегда будет возможность починить баг, даже в чужом коде. Всегда будут умные люди работать, профессионалы не ошибаются, состояние отрасли хорошее.
Я правильно понимаю, что вы опять не готовы разбирать конкретный случай, так и оставим очередное ваше утверждение неподтвержденным?
Какая по большому счёт разница где объявлять переменные?
Вообще — достаточно большая. Про скоупы уже все обсудили, но есть и еще один занятный аспект — предварительное объявление переменных (при статической типизации, конечно) плохо сочетается с выводимыми или неявными типами.
(ну и наконец, предварительное объявление никак не сочетается с неизменяемыми значениями, но это уже следствие строго императивной концепции языка)
плохо сочетается с выводимыми или неявными типами.
Предсказываю, что выводимые и неявные типы для оберонщиков, это злостная ересь: все переменные должны быть описаны в отдельном списочке, все типы должны быть явно продекларированы, все ENDы должны снабжаться указанием на соответствующие BEGINы и вообще порядок учета требует.
Типы должны указываться явно, да. Но при этом наследование никто не отменял и указатели на абстракцию тоже.
Вообще, в Обероне принцип «явное лучше неявного» соблюдается достаточно хорошо. В отличие от.
И еще просьба, поубавьте накал вангования сарказм, а то потом будете ныть, что Вам хамят в ответ.
Вообще, в Обероне принцип «явное лучше неявного» соблюдается достаточно хорошо. В отличие от.
И еще просьба, поубавьте накал вангования сарказм, а то потом будете ныть, что Вам хамят в ответ.
Извините :). Я, кстати, не согласен с принципом «Явное лучше неявного». Мне вот кажется, что хорошие умолчания лучше. Если явно обозначать все, то труднее отличить необычные ситуации.
Достаточно ли? В обероне сборщик мусора, который неявно освобождает память. В отличие от.
Вы можете явно не использовать динамическую память, и потому будете уверены, что сборщик не работает. А уж обвинять Оберон в недетерменированности сборщика мусора это перегиб, но вы не против перегнуть, если надо, да?
Где вы увидели обвинения? В моём сообщении нет никаких эмоциональных оценок. Лишь указание на факты с просьбой быть последовательнее. А то неявные типы — плохо, неявная память — хорошо. Придирки к GC — перегиб, придирки к СКОБОЧКАМ — нормально. Написать десять строк кода — некогда и всё равно не оцените, написать тыщу строк комментов — чё б нет. Просите конструктивности, а сами в ответ на конкретику съезжаете на демагогии.
Обвинение это не эмоциональная оценка, это уверенное связывание факта с объектом обсуждения, и последующая негативная оценка этого факта.
То есть сборщик мусора все понимают что такое, все знают, что в Обероне такая модель памяти и все равно вы говорите, что «сборщик мусора в обероне, в отличие от».
Ну тупейшая манипуляция, с невинными глазкаме, «а чо я, я лишь спросил». Не лишь.
Вам нужно писать на Обероне, вот и все. А то так ничего и не поймете. Закончу затратную по количеству минусов беседу с вами. Помните, знать путь и пройти его — не одно и то же.
То есть сборщик мусора все понимают что такое, все знают, что в Обероне такая модель памяти и все равно вы говорите, что «сборщик мусора в обероне, в отличие от».
Ну тупейшая манипуляция, с невинными глазкаме, «а чо я, я лишь спросил». Не лишь.
Вам нужно писать на Обероне, вот и все. А то так ничего и не поймете. Закончу затратную по количеству минусов беседу с вами. Помните, знать путь и пройти его — не одно и то же.
Ещё раз.
Явное лучше неявного, так?
В обероне неявное управление памятью, так?
В C, C++, расте — явное, так?
Почему вы упорно обходите этот момент, когда говорите, какой же оберон хороший и концептуальный, «в отличие от»?
P.S. «А то так ничего и не поймете» — кто бы говорил о манипуляциях, ага. А вам нужно лечиться уринотерапией, а кто её хает — тоже ничего не понимают, и даже не хотят попробовать.
Явное лучше неявного, так?
В обероне неявное управление памятью, так?
В C, C++, расте — явное, так?
Почему вы упорно обходите этот момент, когда говорите, какой же оберон хороший и концептуальный, «в отличие от»?
P.S. «А то так ничего и не поймете» — кто бы говорил о манипуляциях, ага. А вам нужно лечиться уринотерапией, а кто её хает — тоже ничего не понимают, и даже не хотят попробовать.
Вы бы знали, сколько противников даже у того примитивного и убогого варианта вывода типов, который появился в 8й джаве…
Пока вы задаёте конструктивные вопросы, остальные месят адептов Оберона в минуса. В таких условиях разговаривать конструктивно технически невозможно, движок хабра попросту не даст.
Вообще-то как раз движок хабра уменьшает последствия «таких условий» — один юзер может поставить другому юзеру не больше одного минуса, поэтому после того, как все присутствующие «отметились» в карме, динамика резко меняется.
Ну и да, вот вы тоже почему-то предпочитаете обсуждать конструктивность беседы, а не конструктивно отвечать на конструктивные вопросы.
Ну и да, вот вы тоже почему-то предпочитаете обсуждать конструктивность беседы, а не конструктивно отвечать на конструктивные вопросы.
Присутствующим в треде не нужна конструктивность, а нужно поскорее вытеснить неприятное в серый предел. С каждым увеличением срока возможного комментария мне это становится всё очевиднее. Уже неважно, что ты говоришь — главное, рефлекс на тебя выработан.
Ну а раз сообществу в целом (я не про отдельных собеседников) не нужна конструктивность, то мне — тем более.
Ну а раз сообществу в целом (я не про отдельных собеседников) не нужна конструктивность, то мне — тем более.
Мы опять возвращаемся к Уловке-22, ситуация, в которой под обязательный негативный исход просто придумываются аргументы нужного уровня и в нужном контексте.
Будешь писать долго и вдумчиво — накидают обезьяньих претензий к орфографии и сольют.
Будешь писать динамично — накидают портянок-ответов, а за неотвеченный вопрос сольют.
Будешь писать отрывисто и кратко — скажут, что троллишь и не конструктивно объясняешь.
Попытаешься сменить направление беседы замечаниями — скажут что не отвечаешь по делу и сольют.
Ответишь на откровенно неверный вопрос — заведут в ловушку и сольют.
Потому что отношение к Оберону было понятно еще пару лет назад, после статей Богатырева и некоторых других. Оберон — неприятен. Принципы, на которых он основан — неприятны. Критика мейнстрима, которая вытекает из этих принципов — неприятна. Даже обсуждение — неприятно, потому что приходится признавать за оппонентом возможность быть правым.
А еще по очевидным причинам, мнение об Обероне необходимо озвучивать каким-то людям. И они тоже — неприятны. Уберите. Кончились минусы — груби и матерись в комментах. Все равно за это ничего не будет. Этих — можно.
А мы будем на Яисте писать.
Будешь писать долго и вдумчиво — накидают обезьяньих претензий к орфографии и сольют.
Будешь писать динамично — накидают портянок-ответов, а за неотвеченный вопрос сольют.
Будешь писать отрывисто и кратко — скажут, что троллишь и не конструктивно объясняешь.
Попытаешься сменить направление беседы замечаниями — скажут что не отвечаешь по делу и сольют.
Ответишь на откровенно неверный вопрос — заведут в ловушку и сольют.
Потому что отношение к Оберону было понятно еще пару лет назад, после статей Богатырева и некоторых других. Оберон — неприятен. Принципы, на которых он основан — неприятны. Критика мейнстрима, которая вытекает из этих принципов — неприятна. Даже обсуждение — неприятно, потому что приходится признавать за оппонентом возможность быть правым.
А еще по очевидным причинам, мнение об Обероне необходимо озвучивать каким-то людям. И они тоже — неприятны. Уберите. Кончились минусы — груби и матерись в комментах. Все равно за это ничего не будет. Этих — можно.
А мы будем на Яисте писать.
Ну о чем я и предупреждал, слова маркеры «выглядит предсказуемо» и «адепты».
Уважаемый, вы же не адепт C#/Java/что там у вас?
Уважаемый, вы же не адепт C#/Java/что там у вас?
Почему бы всесто этих слов не написать код? Слова-то вы пишете? Вот тестовая задача, я написал на C#, yuuri написал на Haskell, напишите на Оберон и мы поймем какой он.
Прежде всего меня волнует не код, а коррекные формулировки. Если я вижу, что люди не говорят со мной на одном языке, я не буду развивать явно ошибочную тему. Понимаете? Я вот работал с «родным» языком задачи, а мои оппоненты с Обероном не работали. Поэтому я понимаю, что нужно сделать, а Вы не понимаете, что формулировка «обход коллекции в обероне» неверна. Я дам Вам код, Вы не найдете ожидаемого и назовете Оберон дерьмом, я это уже сто раз проходил, меня это не устраивает. Я стараюсь Вам объяснить, что Вы задаете неверные вопросы и получаю за это ограничение на количество ответов в час. Это просто охренеть какой конструктивный подход, но я же понимаю, люди из мейнстрима вот так мыслят и не считают, что могут в таких простых вещах говорить неправильные вещи. Поэтому и предлагаю, сначала освойте мой язык, как я освоил Ваш, а потом поговорим предметно.
> Прежде всего меня волнует не код, а коррекные формулировки
Вам описана задача. Сформулируйте ее решение на языке Оберон в любых удобных для вас терминах, а мы посчитаем лексемы и посмотрим соблюдается ли разделение между логикой и представлением.
Вам описана задача. Сформулируйте ее решение на языке Оберон в любых удобных для вас терминах, а мы посчитаем лексемы и посмотрим соблюдается ли разделение между логикой и представлением.
А почему вы решили, что вы говорите в корректных формулировках? Массив – вполне себе колекция, как обходить его в обероне, уже показали. Хаскель и прочие ФЯ – совсем не мейнстрим (как бы мне того ни хотелось), но там это тоже можно. Все говорят на одном языке, только вы на другом, и правильный почему-то ваш?
Я так понимаю, вы перешли к откровенным передергиваниям.
Очевидно, вы с коллегами говорите на одном языке, а я на другом. Я ваш язык понимаю, а вы мой — нет. Я же сам об этом пишу. Только там не было утверждения о том, что только мой язык правильный, это вы придумали. Просто недопонимание. Поумерьте агрессию и может договоримся до чего-то плодотворного. Вашу картину мира никто не трогает, не надо так ее защищать.
Просто есть точка зрения, в которой ваша картина мира это просто вермишель терминов непонятной даже вам самим этимологии. А вы ими рассуждаете, вопросы задаете. С шутками-прибаутками, с кармосливом и ощущением общности. После такого вам давать код, подводить его под обсуждение дилетантами. Не, такой сценарий не заслуживает усилий.
Очевидно, вы с коллегами говорите на одном языке, а я на другом. Я ваш язык понимаю, а вы мой — нет. Я же сам об этом пишу. Только там не было утверждения о том, что только мой язык правильный, это вы придумали. Просто недопонимание. Поумерьте агрессию и может договоримся до чего-то плодотворного. Вашу картину мира никто не трогает, не надо так ее защищать.
Просто есть точка зрения, в которой ваша картина мира это просто вермишель терминов непонятной даже вам самим этимологии. А вы ими рассуждаете, вопросы задаете. С шутками-прибаутками, с кармосливом и ощущением общности. После такого вам давать код, подводить его под обсуждение дилетантами. Не, такой сценарий не заслуживает усилий.
подводить его под обсуждение дилетантами
Srsly?
RLY, я имею все основания сомневаться, что Вы профессионально писали на Обероне хоть что-то. И конечно, Ваш огромный опыт на вашем не сектантском языке хоть и важен для общей эрудиции, он не поможет вам за пару суток стать профессионалом в Обероне. В общем, как-то так. Если вы не можете принять этот факт, то эта ветка скатится в оскорбления и фаллометрию, типа «оберонщик не может показать код на обероне, хаха». Вы сами скатили беседу в такой формат, ведь масса определяет движение.
А я и не говорю, что я профессионал в Обероне. Но когда для того, чтобы оценить применимость языка к простейшей прикладной задаче, нужно быть профессионалом в этом языке — что-то в системе не так.
Процитирую Дейкстру: «На наше формирование большое влияние оказывают инструменты, которые мы используем, в частности: формализмы, которые мы используем, формируют наш образ мышления лучшим или худшим образом, и это значит, что мы должны быть чрезвычайно осторожны в выборе того, чему учить и чему учиться, потому что разучиться потом совершенно невозможно.»
Вы _уже_ думаете определённым образом. Матрица вашего мышления неминуемо подчиняет себе логику ваших рассуждений. Серьёзно, Оберон из немного другой матрицы, поэтому нет смысла просто рассматривать тексты на Обероне. Там, наверное, должны быть задействованы какие-то другие области мозга. Я про это говорю уверенно, потому что программирую на сишарпе и на обероне, и реально ощущаю разницу.
Вы _уже_ думаете определённым образом. Матрица вашего мышления неминуемо подчиняет себе логику ваших рассуждений. Серьёзно, Оберон из немного другой матрицы, поэтому нет смысла просто рассматривать тексты на Обероне. Там, наверное, должны быть задействованы какие-то другие области мозга. Я про это говорю уверенно, потому что программирую на сишарпе и на обероне, и реально ощущаю разницу.
Вы хотите сказать, что человек, который много пишет на C#, не способен понять Оберон? Странно.
Ну и да, вы не рассматриваете тот мелкий факт, что я не только на C# писал и пишу.
Ну и да, вы не рассматриваете тот мелкий факт, что я не только на C# писал и пишу.
Да, именно это я и хочу сказать. Потому что когда в сишарпе требуются обязательные скобочки в if или однострочный литерал надо завершать обязательной точкой с запятой, для меня это необъяснимый медицинский факт, признак другой ментальной вселенной, где вещи делаются не потому что так надо, а потому что так захотелось левой пятке в понедельник (провокация хаоса, так сказать).
А как вы разделяете «так надо» и «так захотелось»? Для меня вот принудительное определение переменных — это необъяснимое требование, а не «так надо» (потому что я так и не увидил за ним обоснования).
При этом, надо заметить, я не считаю, что обязательные скобочки или обязательная точка с запятой — это верх гениальности решения (потому что я пишу на языках, где ни то, ни другое не нужно), я просто считаю, что есть вещи важнее. Обычно если я не понимаю поведение языка, на котором я пишу, я ищу его описание и предысторию — иногда это помогает понять.
При этом, надо заметить, я не считаю, что обязательные скобочки или обязательная точка с запятой — это верх гениальности решения (потому что я пишу на языках, где ни то, ни другое не нужно), я просто считаю, что есть вещи важнее. Обычно если я не понимаю поведение языка, на котором я пишу, я ищу его описание и предысторию — иногда это помогает понять.
формализмы, которые мы используем, формируют наш образ мышления лучшим или худшим образом
Какие формализмы есть в Oberon, которых нет в C#?
Вы знаете, после знакомства с хаскелем, лиспом, прологом, эрлангом, фортом — и прочими воплощениями других парадигм — значимой разницы между обероном, паскалем, си, фортраном не особо-то и видно. Если уж и ломать матрицу мышления, то чем-то принципиально новым, а не старыми процедуроциклопеременными в новой упаковке.
Лично я отказываюсь продолжать общение, ибо заминусовали. Кукарекать, когда разрешат, я не собираюсь. Самоорганизуйтесь дальше сами.
Ну и не кукарекайте, останется два голосочка из-подс той стороны.
Тут некоторые задают вполне адекватные вопросы, общение идёт вполне конструктивно, чисто из уважения к ним сообщаю свою теперешнюю позицию. Вот, собс-но, и всё. Всегда есть выбор, приспособиться и не высовываться, либо же покинуть поляну.
Это Вы так наслаждаетесь своим численным преимуществом?
О да, один против двух ваших аккаунтов. Ужас-ужас. Численное преимущество.
А если серьезно — вас (один или двое, не важно; если считать по аккаунтам, то и троих) по результатам нескольких тредов уже никто не воспринимает. Здесь фанатиков не любят.
А если серьезно — вас (один или двое, не важно; если считать по аккаунтам, то и троих) по результатам нескольких тредов уже никто не воспринимает. Здесь фанатиков не любят.
Отучаемся говорить за всех.
Воспринимают, да ещё и как. Мощное неравнодушие ко всему, что написано. Если бы не воспринимали, тут стояла бы тишина. Но нет, хоть что напиши — про свой опыт, примеры кода или даже Дейкстру процитируй, набегут и заминусуют. Так себя профессионалы не ведут. Это поведение школоты, получившей возможность.
Ну, в отношении циклов со счетчиком (FOR i:=a TO x BY step DO END;) мнение Н. Вирта и сообщества неоднозначное. Он есть, по соображениям обратной совместимости. Я его просто никогда не использовал намеренно, а компилируется он зачастую в инструкции, аналогичные циклу WHILE, который и есть цикл с предусловием.
WHILE ~file.eof DO Log.String(file.Read()) END WHILE ch#"x" DO Console.ReadChar() END аналог FOR i:=a; WHILE i<=x DO INC(i, step) END;
И так далее.
Почему он так называется, потому что есть предусловие, то есть такое условие дальнейшего выполнения, которое проверяется перед выполнением тела цикла. Соответственно цикл может выполниться ноль и более раз.
Аналогично цикл с постусловием.
Но вообще, Оберон тут как пример, такие циклы не зависят от языка и много где еще есть.
WHILE ~file.eof DO Log.String(file.Read()) END WHILE ch#"x" DO Console.ReadChar() END аналог FOR i:=a; WHILE i<=x DO INC(i, step) END;
И так далее.
Почему он так называется, потому что есть предусловие, то есть такое условие дальнейшего выполнения, которое проверяется перед выполнением тела цикла. Соответственно цикл может выполниться ноль и более раз.
Аналогично цикл с постусловием.
Но вообще, Оберон тут как пример, такие циклы не зависят от языка и много где еще есть.
аналог FOR i:=a; WHILE i<=x DO INC(i, step) END;
Не является ли второй цикл тоже циклом со счетчиком — счетчик то есть? А если он есть не было бы лучше чтобы он имел смысл только внутри цикла?
Ага, цикл со счетчиком все-таки есть. Возвращаемся к вопросу: чем вредны локальные для такого цикла счетчики?
Локальный, т.е. объявляемый непосредственно перед циклом? Объявление внутри цикла смысла не имеет, потому что вычисление начального значения может происходить как раз перед циклом. И ради такой частности усложнять компилятор? Хм.
Мне кажется, компиляторы и нужны для того, чтобы сделать жизнь проще… Усложняем компилятор, упрощаем себе жизнь.
Да, конечно, усложняя компилятор, мы придвигаем наш формальный аппарат поближе к предметной области и сокращаем какие-то издержки. Но не слишком ли велика цена такого приближения? И какие можно здесь найти минусы?
1) цена разработки и поддержки компилятора сильно возрастает. Может ли сообщество хабра поднять собственный компилятор такого масштаба — думаю, ответ очевиден — конечно же, не может, ведь для этого нужны серьёзные деньги. Импортозамещение сразу же проседает.
2) стоимость обучения специалиста растёт, хотя можно сказать, что пусть учится вечерами, в промежутке между курсовыми и заработками в макдональдсе.
3) ответственность, вы не имеете права на ошибку, ведь на ваш ЯП как средство производства будут завязано много задач.
Итак, мы приходим к выводу, что приближение к предметной области могут позволить себе только большие западные компании с оборотом в миллиарды долларов. А мы можем только поддержать их бизнес, используя предоставленные нам средства производства софта.
Как-то так.
P.S. меня тут заминусовали, видимо я был неосторожен в оборотах, и могу кукарекать из своего гетто только раз в пять минут. Это сильно выбивает из контекста обсуждения, поэтому я, пожалуй, покину сей приятный тред, хотя и жаль, ведь споры помогают увидеть собственные слабые места.
1) цена разработки и поддержки компилятора сильно возрастает. Может ли сообщество хабра поднять собственный компилятор такого масштаба — думаю, ответ очевиден — конечно же, не может, ведь для этого нужны серьёзные деньги. Импортозамещение сразу же проседает.
2) стоимость обучения специалиста растёт, хотя можно сказать, что пусть учится вечерами, в промежутке между курсовыми и заработками в макдональдсе.
3) ответственность, вы не имеете права на ошибку, ведь на ваш ЯП как средство производства будут завязано много задач.
Итак, мы приходим к выводу, что приближение к предметной области могут позволить себе только большие западные компании с оборотом в миллиарды долларов. А мы можем только поддержать их бизнес, используя предоставленные нам средства производства софта.
Как-то так.
P.S. меня тут заминусовали, видимо я был неосторожен в оборотах, и могу кукарекать из своего гетто только раз в пять минут. Это сильно выбивает из контекста обсуждения, поэтому я, пожалуй, покину сей приятный тред, хотя и жаль, ведь споры помогают увидеть собственные слабые места.
цена разработки и поддержки компилятора сильно возрастает. Может ли сообщество хабра поднять собственный компилятор такого масштаба — думаю, ответ очевиден — конечно же, не может, ведь для этого нужны серьёзные деньги. Импортозамещение сразу же проседает.
Согласен сложный компилятор сделать сложнее чем простой. Компилятор, как мне кажется, не самое сложное. Самое сложное — экосистема.
стоимость обучения специалиста растёт, хотя можно сказать, что пусть учится вечерами, в промежутке между курсовыми и заработками в макдональдсе.
Не согласен, как правило, чем более высокий уровень языка тем проще научаиться писать на нем программы. Форт проще чем C# но найчиться писать на нем программы сложнее. Написать foreach проще чем каждый раз писать while.
ответственность, вы не имеете права на ошибку, ведь на ваш ЯП как средство производства будут завязано много задач.
Вот это я не понял.
Компилятор разрабатывается один раз, а код пишется миллионы. До сих пор речь шла о том, что лишних фич в Обероне нет потому, что они вредны. Внезапно выясняется, что их нет потому, что нет денег на их разработку?
Итак, мы приходим к выводу, что приближение к предметной области могут позволить себе только большие западные компании с оборотом в миллиарды долларов
Кстати, несогласен. Если посмотреть на языки очень много сделно не корпорациями — ruby, python, nemerle. У нас тоже была какая-то мелкая конторка, котоаря писала компилятор C++ — читал историю в PC Magazine, кажется.
Далее, есть же Open Source — причем все куски стека и генераторы парсеров и виртуальные машины.
Позитивные люстрации.
Локальный — т.е. видимый только и исключительно в цикле. А то, что вычисление начального значения происходит перед циклом — это как раз недостаток цикла с предусловием по сравнению с «классическим»
И да, я спрашивал, в чем вред такого решения для результирующего ПО?
for.И да, я спрашивал, в чем вред такого решения для результирующего ПО?
Напишите статью, в которой код на Rust и код на Обероне будет решать одни и те же задачи. С удовольствием почитаю.
Вот хотя бы даже из детсадовских — обедающие философы, потоки, увеличивающие аккумулятор (http://carol-nichols.com/2014/07/14/ruby-rust-concurrency/), та же игра «угадайка», тот же hexdump, я не знаю.
Вот хотя бы даже из детсадовских — обедающие философы, потоки, увеличивающие аккумулятор (http://carol-nichols.com/2014/07/14/ruby-rust-concurrency/), та же игра «угадайка», тот же hexdump, я не знаю.
С удовольствием напишу любую статью по Вашему заказу, можете в личке мне написать интересующие Вас темы, а я Вам цену озвучу. Вам как удобнее, почасовая оплата или полностью за весь выполненный заказ?
Хамство — это обязательное требование к разработчику на Обероне? =\
Это не хамство, это коммерческое предложение.
Это, как большинство ваших комментариев, именно хамство. И, как уже тут писали, это создаёт не очень хорошую репутацию и языку Оберон, потому что, сё, что с ним ассоциируется, например, у меня — это ваши едкие комментарии в духе «Я — Д'Артаньян, а все вокруг — пидорасы».
Вы, кстати, зачем с разных аккаунтов пишите?
Вы, кстати, зачем с разных аккаунтов пишите?
А сколько Вам за эту статью заплатили, если не секрет?
Одно непонятно — за что же так не любите Oberon?
Очевидно же, что после таких вот «объективных» и «арментированных» статей у многих людей сложится негативное отношение. Объективно к автору статьи, но ведь в конечном счете пострадает язык (который ни в чем не виноват).
Очевидно же, что после таких вот «объективных» и «арментированных» статей у многих людей сложится негативное отношение. Объективно к автору статьи, но ведь в конечном счете пострадает язык (который ни в чем не виноват).
Автор удивительно передал мои несформировавшиеся подсознательные впечатления от статей нахваливающих Rust с примерами кода на нём же.
А скажите Go и Python как вам?
А скажите Go и Python как вам?
Очевидно, для ОПа всё, что не Оберон — некачественно, ненадёжной, через чур усложнено и т.д.
Go относительно хороший, не считая проклятые скобочки.
А питон странный, не возникло желания его юзать. Но идея со значимыми отступами мне не ок, я их не вижу, а они важны. Диссонанс.
А питон странный, не возникло желания его юзать. Но идея со значимыми отступами мне не ок, я их не вижу, а они важны. Диссонанс.
Про отступы: любой современный редактор вам их может подсвечивать разными способами. Например: серые вертикальные полосочки, связывающие начало и конец блока. Ну а если у вас длинная простыня, то begin и end вам тоже не сильно помогут.
Пробелы тоже не видны и при этом важны в (почти) любом языке, диссонанс!
к вопросу об избирательной слепоте…
Статья уровня хабра: автор до$%ался до СКОБОЧЕК и ни слова не сказал о фичах языка.
Пост в котором выясняется, что OberonForGood и его тролли-виртуалы не умеют в оберон.
Умеют виртуозно, просто мы недостойны того, чтобы нам это демонстрировали.
Только-только появился ещё пользователь kisybi, подозрительно похожий на прокурораочередного виртуала по стилю поста. Посмотрим, как будет общаться. Вдруг исправится =)
Но там в посте хотя бы есть куски кода из project oberon.
Но там в посте хотя бы есть куски кода из project oberon.
Второй пост по языку, и все та же желчь и раздражение. Я когда-то научился писать на уровне хобби на Ruby только потому, что люди, которые писали о нем, они светилися от счастья, что могут дать другим возможность насладиться открывшейся им тайной. Высмеять другие языки, поиздеваться над Rust, рассказать о мухах, которые никогда не ошибаются? Какое там, мы как хиппи, мир во всем мире, вот вам косячок с Ruby, и вы забудете о всех проблемах.
Но зачем, если «Мне это не надо. Если Вам надо, вы и переводите, поди, неглупый человек сможет осилить Оберон» и «с html мы могем все». Вы специально топите язык в потоках желчи и злости, или так само по себе выходит?
Но зачем, если «Мне это не надо. Если Вам надо, вы и переводите, поди, неглупый человек сможет осилить Оберон» и «с html мы могем все». Вы специально топите язык в потоках желчи и злости, или так само по себе выходит?
По мере прочтения комментариев почему то в голове стала проявляться фраза «systemd на oberon-е».
«Проклятие» фигурных скобочек