Пользователь
0,0
рейтинг
21 мая 2015 в 13:27

Разработка → «Проклятие» фигурных скобочек recovery mode

Допустим, вы крупная Компания. Занимаетесь разработкой Браузера, Почтовика и даже ОС для смартфонов. Неожиданно вы понимаете, что вам не нравится современный и мощный язык С++. Ну или нравится, но работать с ним невозможно. Бывает. И вот вы, взрослая стабильная компания решаете разработать новый язык программирования. Рецепт простой. Берете бочку денег, книжки по истории ИТ, роту программистов и грузовик МакБуков. Долго думаете, быстро кодите, разводите хайп в соцсетях (реддит, фейсбук, гитхаб). И вот, в 2015-м году вы даете сообществу The Язык. Назовем его Яист.

Язык это инструмент профессионалов. Работает по профессии — значит профессионал. Что первым делом читает профессионал при изучении нового языка? Конечно, объективное мнение коллег. Оно в основном положительное. Следом за мнением коллег профессионал читает описание языка. Больше двухсот страниц. Ох. Будет, чем убить время в метро.

Быстрый старт


Hello, World!


Самый важный этап изучения.

fn main() {
  println!("Hello, world!");
}

Что мы видим? fn, фигурные скобки, точку с запятой, println!. Это макрос, как нам поясняет автор. Строковая константа это строковая константа.

Очевидно, разработчики потрудились над сокращенным написанием ключевого слова fn. Это вам не кричащее PROCEDURE, которое писать долго, еще надо Shift зажимать. Этот пункт однозначное улучшение, по сравнению с восьмидесятыми. Функция main() возвращает ничего. Пустоту. Результат void, даже указывать не надо. Попробуйте объяснить void пятиклассникам. То-то же.
Фигурные операторные скобки. Такие скобки, как известно, экономили память на машинах 70-х. Теперь они экономят время программиста. Ему некогда писать BEGIN END, ведь 21-й век за окном. Время продуктивности.

Макрос println! обращает на себя внимание восклицательным знаком. Это вам не функция. Впрочем, о происхождении макроса мы ничего не знаем, так как полные квалификаторы сущностей не нужны. Может быть, он даже встроен в язык, ведь в примере нет никакой секции импорта (на самом деле есть, любая программа импортирует ограниченный набор из библиотеки std). Нет времени выяснять, просто println! В 90-х это бы записали как Log.String(«Hello, World!»). Лихое было время, мы выживали как могли.

Не забудьте точку с запятой. Это expression based язык программирования. Точка с запятой отделит одну скобочку от другой. Завершается процедура закрывающей скобочкой. В 90-х её завершили бы END Main. Хорошо, что те времена уже прошли.

Cargo


Карго это пакетный менеджер. Скачивает зависимости, занимается их построением. Яист предполагает культ карго. В 90-е такого не было. Тут нужно отдать должное авторам. Бочка денег была выпита не зря. Языком программирования инструмента Cargo является toml — ini на стероидах.

Примеры


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

use std::io;
fn main() {
  println!("Guess the number!");
  println!("Please input your guess.");
  let mut guess = String::new();
  io::stdin().read_line(&mut guess)
    .ok()
    .expect("Failed to read line");
  println!("You guessed: {}", guess);
}


Мы должны обработать ввод пользователя, поэтому надо использовать библиотеку io из библиотеки std. Use std::io, Luke; И снова мы стали свидетелями того, как тщательно поработали авторы языка над синтаксисом. Раньше ведь как, IMPORT StdIO, большими буквами приходилось писать. Беспощадное отношение к рукам программиста. И два двоеточия. Возможно, это как четыре плюса в символе #. Макрос println! уже видели.

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

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

String это строка. new() это new(). Потом будет io::stdin() с текущим интерфейсом и println! с возможностью автоподстановки аргументов в результирующую строку.

Развитием этого примера является генерирование рандомного числа с помощью сторонней библиотеки.

extern crate rand;


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

match guess.cmp(&secret_number) {
  Ordering::Less => println!("Too small!"),
  Ordering::Greater => println!("Too big!"),
  Ordering::Equal => println!("You win!"),
}


Метод cmp() служит для сравнения всего сравнимого. Результат сравнивается с преопределенными значениями из Enum'а c помощью оператора match. Раньше для такого был оператор CASE, условный выбор. Но теперь другие времена. Життя по-новому. Стрелочка => которую вы могли принять за составной оператор сравнения с точки зрения арабской письменности на самом деле является указателем на выражение, соответствующее варианту сопоставления.

С циклами в примере все хорошо. Есть break и continue, все как во взрослых языках. Дейкстра уже умер, можно не волноваться, что он не одобрит выход из середины цикла. Это ведь не усложняет понимание цикла. В 90-х усложняло, а сейчас люди умнее стали, и инструменты мощнее. И вообще, профессионалы не ошибаются.

Философы кушают


Структуры Philosophers Едят методом eat(). Автор плавно переходит к примеру про философов. Вводит читателя в курс дела, что есть структуры, у них есть связанные функции с параметром &self (аналог this). Это в 90-х можно было назвать связанный объект как тебе угодно, в 2015 такая фича слишком сложна для реализации. Читаем про метод new, он конструирует новый экземпляр класса. Может иметь пользовательские параметры.

Несколько философов размещаются в списке с помощью макроса vec!. Тип переменной списка мы не указываем. Но он есть.
В программу вводятся примитивы параллельного программирования.

let handles: Vec<_> = philosophers.into_iter().map(|p| {
  thread::spawn(move || {
    p.eat();
  })
}).collect();


Экономия усилий программиста во всем, в именовании методов. в синтаксисе замыканий. В отсутствии необходимости указывать тип данных. А что, и так все понятно. Это Пэ, это Век. Программирование тредов в примере опирается на мьютексы. Ну и хорошо. А то навыдумывали в 90-е всяких активных объектов. Сплошные проблемы от этого. Лучше старого доброго мьютекса ничего нет, если хочешь писать серьезный взрослый софт. Тем временем синтаксис описания импорта обрастает новыми возможностями.

use std::sync::{Mutex, Arc};


Возможности языка это краеугольный камень успеха.

Использование Яист извне


После философских обедов автор решает сфокусировать свое внимание на более приземленных вещах — на использовании Яист при построении shared library.

Это не так интересно с точки зрения программиста, ведь до сих пор функциональность shared libraries в Windows/Linux довольно убогая. Нет возможности получить информацию об интерфейсе, проблемы с кроссплатформенностью, проблемы с версионностью (точнее, отсутствие версионности, которое становится проблемой клиентского кода), авторам высокоуровневых языков приходится приземляться на уровень Cи. Некоторые языки вообще не могут так низко пасть. Но это же их проблемы. Ведь на дворе 2015-й год, а технология использования dll проверенная, надежная. У профессионалов давно есть инструменты, типа FFI. Так что не надо думать, что все технологии из семидесятых это что-то плохое. На какие укажут, те и плохие, а некоторые — хорошие. Например, модульность на уровне shared library.

#[no_mangle]
pub extern fn process() 


Это Кличка Гога Shared Library на Яисте.

Эффективный Яист



Управление памятью


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

Параметры функций


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

Тестирование


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

Условная компиляция


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

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

Документация


Она есть. Даже с HTML. Мы можем многое.

Итераторы


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

Многопоточность


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

FFI


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

Borrow and AsRef traits


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

Яист l4ngu4g3 6еЗНoГNМ



В разделе 5 описан сам язык с пояснением семантики того или иного ключевого слова. Описание довольно длинное, смешные моменты уже проявились в простых примерах. Еще среди забавных фактов можно выделить несколько:
  • все есть выражение, но мы специальным знаком можем отметить функции, которые ничего не возвращают, чувствуется глубина проработки абстрактной части
  • оператор if возвращает результат (да-да), заменяя собой тернарный оператор
  • встроенный оператор transmute, который оставляет дырку в целостности типов данных
  • яист с оператором unsafe направлен на безопасность

Владение объектами и время жизни, как фичи, возможно и простые, завязки идут на scope, затрагивая heap (из-за отсутствия сборки мусора), все это дело осложняется замыканиями, и в итоге описание концепции получается довольно сложное, и про него на Хабре напишут еще не одну статью, в попытках понять и проститьобъяснить.

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

Заключение


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

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

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

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

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

Слово «проклятие» иносказательное. Чтобы передать смысл явления. Не принимайте близко к сердцу. Мир вам.
@OberonForGood
карма
–1,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • +19
    Автор, вы в названии языка опечатались здесь:
    Использование Rust извне
    • +42
      Ещё никогда Штирлиц не был так близок к провалу.
  • –7
    Не хочется Вас огорчать и расстраивать, но в языке Яист чего-то «своего» придумали чуть более, чем нисколько.
    Если чего-то никогда не встречали, никогда не стесняйтесь поискать в интернете.
    • +25
      Вы так умны и проницательны.
    • 0
      image
  • +2
    Далее следует объявление переменной, которое совмещено с инициализацией и размещено прямо в коде. Ну а как еще, не делать же отдельную секцию переменных, как в восьмидесятых. Тогда угрюмые колхозники писали все переменные в строго выделенном месте, чтобы потом их в этом месте найти.


    Казалось бы, при чем тут ник автора…

    Насчет фигурных скобочек и точки с запятой соглашусь, это родовая травма C, неизвестно зачем тянущаяся во все языки с тех пор.
    • –10
      Ну правда, почему в Обероне догадались, а в Rust все получилось вот так?
      • +4
        Красота в глазах смотрящего, как известно, или, другими словами, на вкус и цвет товарищей нет.
        • +1
          В «малом», возможно, товарищей нет, но в «большом» на лицо тренды, мейнстрим, антимейнстрим, групповые протестные движения. Значит, в чем-то у людей мнения совпадают. Например, про язык Rust.
      • +2
        А вам таки не нравится объявление в коде?
        Не смущает что в Rust можно написать
        let a = 5;
        let a = 6;
        и это 2 различных переменных
        Безотносительно того где это может применяться и нафига это нужно (в макросах это может быть полезно), объявления перед кодом принципиально такого не предоставят.
        • 0
          Нацеленность на safety вызывает все большее доверие.
        • 0
          Ик.
          А можно тупой-тупой вопрос?
          А как обращаться к этим двум разным переменным?
          А то я как-то по имени привык…
          • 0
            Второй биндинг прячет первый. Т. е. после let a = 6 первого биндинга уже не увидите.
            • 0
              По моему эта особенность в Rust пришла прямиком из OCaml. А в OCaml она из за его repl-направленности изначальной.
    • +15
      Чем вам так неугодны скобки, и что, по-вашему мнению, лучше них? BEGIN-END? Отступы?
      • –10
        Как показывает опыт Python, отступов вполне достаточно, а точка с запятой вполне может быть необязательна (очень-очень редко действительно надо писать несколько выражений на одной строке).

        Не то что неугодны, просто можно и без них. А если без чего-то можно обойтись, то лучше так и сделать.
        • +11
          Много, долго и счастливо живу с питоном, но иногда бывает страшно что отступишь на четыре пробела меньше и потом долго будешь искать где ты оступился
          • +4
            Аналогично в C-like, не напишешь фигурные скобки после if или цикла и долго ищешь, где ты оступился. Посмотрите серию статей про CppCat, в каждой третьей такие ошибки.
            • +7
              Это другое, со скобками достаточно приучить себя ставить их всегда после if b т.д… Невозможно приучить себя ставить правильное число пробелов или табуляций.
              • +2
                Простите, не согласен категорически. Какая разница, ставить скобочки или отступы?
                • +11
                  Скобочки, они жирнее. Видны лучше на старости лет.
                  • +5
                    Тонко!
                    • +6
                      Вообще, я даже не знаю, насколько я шутил. Лично у меня глубокий импринтинг на фигурные скобочки, а в питоне терпеть не могу искать ошибки из-за табов/пробелов.
                      • +1
                        В бытность свою питонистом ни разу не натыкался на ошибки из-за отступов.
                      • +1
                        а нельзя в редакторе символ пробела заменить на точку, как это сделано в ворде в режиме разметки?
                        • +3
                          А почему бы сразу в языке не заменить? Ведь пробел не видно, а точку будет видно.
                          • –1
                            И не на точку, а на позитивный внятный юникодный символ, скажем, “⇒”. И не умеешь настраивать клавиатуру — нет и пряничков.

                            Пользуясь случаем, должен сказать: блистательно написано и абсолютно по делу.
                            • +1
                              Любые комплименты в сторону маргиналов, имеющих отношение к Oberon, на хабре караются, так что будьте осторожны, правильно выдерживайте линию партии.
                              • –3
                                Да мне как-то в целом на мнение здешней хипстующей школоты en mass — насрать, а вот приятному человеку сообщить, что он молодец — всегда почитал за должное.

                                Да и вообще, я убийц языков, типа раста, повидал миллион, но побеждает всегда что-то рожденное в сарае за два часа. В КОБОЛ вон вбухали бабла сколько, а что получилось? И ведь тоже анонсировался убийца всего.

                                Ни один более-менее серьезный си/плюс программист из числа моих знакомых не рассматривает пока раст как что-то жизнеспособное на уровне чуть выше, чем «клево, я на выходных поигрался, пора обратно за работу».
                • 0
                  Скобки (ну то есть begin-end, я не сишник) я ставлю сразу после того, как написал if или там while. Их можно написать заранее.
                  Отступы — нельзя.

                  Поэтому я идеи с отступами боюсь. Но я не пробовал — может, оно вполне удобно и боюсь я зря.
                  • +3
                    Странная у вас какая-то идея, что отступы надо писать. Уверяю вас, никто не сидит и не расставляет вручную нужное количество пробелов, нажимая пробел 4-8-12 раз.
                    • +1
                      Хм, а ведь вы правы. IDE ставит курсор сразу туда, куда нужно.
                      Иногда, правда, я в самом деле вручную нажимаю пробел :). Но редко, очень редко — и обычно потому, что опять забыл, как там авто-отбивка вызывается.
                      • +1
                        Не только IDE, такое умеют даже текстовые редакторы типа Notepad++ или mcedit из стандартного пакета mc в линуксе.
                    • +2
                      У некоторых IDE (не будем показывать пальцем в лидеров индустрии) вообще странная мания ломать отступы при вставке из буфера. Со скобками в этом плане проще — код автоматом форматируется по скобкам.
                      • –4
                        >> Со скобками в этом плане проще

                        Никакой разницы.
                • 0
                  Простите, не согласен категорически. Какая разница, ставить скобочки или отступы?

                  Тем, что автоматический выравниватель кода понимает первое, но не понимает второе.
                  • 0
                    А зачем он нужен, если код уже выровнен?
                    • +1
                      Код — это же не статический текст в книге, который по факту «выровнен» или «не выровнен». Он меняется, иногда серьёзно. Куски кода выделяются в функции, перемещаются из функции в функцию, блоки обрамляются if-условиями, и т.п. Если в каком-нибудь C++ я могу просто поставить скобки вокруг нового скопа и запустить форматтер (который сразу учтёт новый отступ, разобьёт слишком длинные строки на части и т.п.), то в python мне приходится делать это всё руками.
                      • 0
                        Вините свою IDE, а не Python. Найти наибольший общий отступ выделенного куска кода и заменить его на другой — не rocket science.
                        • 0
                          В случае C++ я могу обойтись без умных IDE, достаточно простого редактора и clang-format.
                          У меня, например, разработка ведётся на удалённом сервере, и код проще всего писать именно там (там все хедеры, доступы к тестовым сервисам и т.п.). IDE в таких средах не особо удобны. Мне вполне хватает emacs и различных внешних утилит.
                          • 0
                            Не вижу причин не деталь так же на питоне — подогнать блок табом до нужного количества отступов и какой-нибудь форматтер типа github.com/google/yapf
                          • 0
                            простого редактора
                            Мне вполне хватает emacs

                            Как раз в Emacs подобное (умный индент с поддержкой на уровне синтаксиса языка) не является особой проблемой.
                      • 0
                        Я не работал с IDE на Python — в pycharm, судя по описанию , есть автоформатирование.

                        Я не вижу теоретических препятствий к тому, чтобы работало как в 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.
                        • +1
                          И оно (форматирование при вставке) вполне работает. Если я перед блоком поставить, например, условие на предыдущей строке, то pycharm/idea автоматически идущий следом кусок переформатировать не будет, т. к. не может угадать, к чему относится добавленное условие (к одной строке, к 5 строкам или максимально длинному участку). Поэтому есть операция surround with (ctrl+shift+j в классической раскладке), действующая на выделенный блок и обрамляющая его выбранной операцией с переформатированием кода, естественно (срабатывает ли при этом autowrap — не знаю, я им не пользуюсь).

                          У плагина для scala есть автоперевод java->scala при вставке, что уж там.
                        • 0
                          Я постоянно работаю в Pycharm и могу заявить, что с помощью него я менял размер табов в кривом исходном файлике. Было у нас куча исходников, в которых блоки разделялись не по 4 пробела, а по 1. Так вот такие исходники я приводил к нормальному виду так:
                          1. открываем этот файлик в Pycharm
                          2. Ctrl + A
                          3. Ctrl + X
                          4. Ctrl + V

                          Уровень вложенности блоков был 3-4 примерно, и все чудесно ложилось по новым правилам и интерпретировалось без ошибок. Даже править не пришлось.
            • 0
              Это лечится код стайлом, запрещающем писать как-то иначе. И со временем это вживается в подкорку мозга, и ты забываешь, что можно их и не ставить.
              В крайнем случае, это лечится статическим анализатором, в котором прописана выдача ошибки на написание if без скобок.
              • +1
                Ну вот уже начинается привлечение посторонних инструментов, линтеры, код-стайлы, статические анализаторы.

                Да, открывающую фигурную скобку со временем приучаешься писать всегда, и это хорошая практика. Ну так и отступы тоже делаешь всегда.
              • 0
                Я вообще совсем не первый год пишу на языке с фигурными скобками, но стараюсь их не ставить там, где можно этого не делать.
            • +5
              Грамматикой Rust запрещено тело условных операторов, не заключенное в блок. Проблемы нет.
        • +12
          Они стали популярны не просто так.
          Скобочки (особенно в сочетании с отступами) делают код гораздо более наглядным и логически разделенным.

          BEGIN-END плохо выполняют эту роль, потому как по написанию сливаются с самим кодом.
          А отступы без скобочек не так наглядны и иногда порождают проблемы, которые описаны в комментарии выше
          • –9
            Вы все хорошо говорите, убедительно, только расскажите, как вы {измеряете наглядность и логическую разделенность? В чем}? В сантиметрах или в попугаях?

            А BEGIN-END не сливаются с кодом, так же как не сливаются с вашим комментарием.
            • +8
              Cливается, так как использует тот же самый набор символов. К примеру:

              begin;
              int beginningBegin = 25;
              int endd = 34;
              if (beginningBegin > endd)
              then
              begin
              beginningBegin -= beginningBegin;
              endd = endd — beginningBegin;
              end;
              beginningBegin = 45;
              end;
              • 0
                Почему-то в примере не увидел ни одного BEGIN
              • +2
                Отступы сделайте (не первый урок по программированию ж ей богу) и ничего сливаться у вас не будет:
                begin;
                    int beginningBegin = 25;
                    int endd = 34;
                    if (beginningBegin > endd) then 
                    begin
                        beginningBegin -= beginningBegin;
                        endd = endd — beginningBegin;
                    end;
                    beginningBegin = 45;
                end;
                


                Но вообще, я предпочитаю Python-стиль, как не дублирующий скобками/BEGIN-END и так имеющуются структуру и логику. Если у вас отступы отдельно живут, а скобки отдельно и вы считаете, что скобки помогают избежать проблем, а ваш код так и остаётся с кривыми отступами, хочу вас заверить, что такой код нужно считать ущербным и нужно исправлять отступы. Итого, имея скобки как средство языка и отступы для красоты — вам приходится делать двойную работу.
                • 0
                  Соглашусь. Тоже всегда использую аргумент про двойную работу как объяснение отступов в питоне.
                  • 0
                    Уважаемые минусующие, я не запрещаю вам выполнять двойную работу и не навязываю отступы, успокойтесь и продолжайте лепить скобочки в паре с отступами.
                • +1
                  >вам приходится делать двойную работу

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

                  Проблема скобок надуманна, это особенно понимаешь, если много пишешь на языке с ними и на языке без них — скорость написания кода совершенно одинаковая… по крайней мере, у меня.
                  • –2
                    Лично мне (!) проще читать (!) код без лишних знаков (а скобки при должных отступах нужны только компилятору). Я согласен, что скобки — не такая уж и глобальная проблема, при желании можно даже простой скрипт написать, который будет транслировать из синтаксиса без скобок в синтаксис со скобками, но лично я не вижу никакого преимущества в скобках, поэтому считаю их лишними.
            • +7
              В личной удовлетворенности от работы с кодом и в желании вечерком на нём ещё пописать.

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

              Но это субъективно всё, конечно.
              • +2
                Для пользователей VIM скобочки {} также удобны тем, что можно легко выполнять операции, скажем, над их содержимым
                yiB — (yank inner block) скопировать внутренности {}
                • +2
                  А ещё %, например.
                • –2
                  Пишу в VIM уже 8 лет, на Python — 6 и вот как-то обходился d<N>d или визуальным выделением через v. Хороший Python код очень редко требует копирования больших объёмов (в том числе и из-за того, что большинство методов вмещаются в 1 экран кода), в отличие от {}-образных.
                  • +1
                    Эээ, а какая связь между количеством кода в методе и тем, используются для структурирования скобки или отступы?
                    • 0
                      В небольших методах, скажем, до 10 строк легко используется комбинация, например, d4d, которая вырезает 4 строки в буфер. Именно в этом контексте я привёл уточнение про маленькие блоки кода.
                      • 0
                        Хороший Python код очень редко требует копирования больших объёмов (в том числе и из-за того, что большинство методов вмещаются в 1 экран кода)

                        Вы хотите сказать, что у языков со структурированием скобками в хорошем коде методы занимают больше места, чем в Питоне?
                        • –3
                          Минимум на две строки больше, чем в питоне (это строки с открывающейся и закрывающейся скобками).

                          P.S. Я сам никого не минусую, но если кто-то хочет обменяться минусами — вы хоть намекните кому я задолжал.
                          • +1
                            Во-первых, на одну (потому что открывающую скобку можно держать на одной строчке с декларацией).
                            Во-вторых, когда копируется код метода, скобки включать не надо (копируется тело), поэтому все равно не понятно отличие.
                            • 0
                              Я изначально описывал не отличие Python от {}-языков, а то, что копирование с Python не является никакой проблемой в VIM несмотря на то, что в Python нет скобок. Более того комбинацию d<N>d можно использовать в любом коде.
                              • 0
                                Ага, только для d<N>d нужно знать N. Не говорите мне про relativenumber: во‐первых, мне не нравиться занимать свободное пространство когда есть более удобные способы сделать то же самое. Во‐вторых, relativenumber не поможет вам, если конца метода не видно на экране (нет, это не обязательно значит, что метод большой).

                                Проще и универсальнее было бы использование привязки, которая выделяет непрерывный блок кода, в котором каждая линия имеет такой же или бо́льший отступ относительно линии, на которой стоит курсор. Это аналог iB для Python, так же хорошо работающий для других языков, если авторы не забывали ставить отступы. Из‐за автоформатирования в каждом первом редакторе кода отсутствие отступов — большая редкость.
                          • 0
                            В случае с египетскими скобками (кажется, самый популярный сейчас стиль), то на одну больше в худшем случае, часто на ноль. На две строки больше обычно только в телах функций.

                            Кроме того, вспомните PEP8. Две пустых строки до и после метода или класса на верхнем уровне, одна на любом другом (в обоих случаях — с некоторыми исключениями, на верхнем уровне редкими). А куча пустых строк для отделения логических уровней в любом языке, если метод‐таки перевалил за 10 строк (а часто и меньше), ещё сильнее уменьшают разницу. Засуньте туда ещё документацию, которая имеет относительно одинаковые размеры вне зависимости от языка (обычно могут только добавится/убраться предупреждения вида «метод выделяет память, не забудьте освободить»), и разница в размерах методов перестанет фактически зависеть от скобочек.

                            На размеры методов гораздо больше влияет наличие различных выразительных средств (типа list comprehension), уровень абстракции, наличие GC.
                            • 0
                              Я хочу обратить ваше внимание (я и сам не заметил как отвлёкся на эту тему), что я не ставил целью сравнения Python с чем-нибудь ещё, я говорил про VIM в случае безскобочного языка на примере Python.
                  • +2
                    >> как-то обходился d-N-d
                    Для этого нужно ещё перепрыгнуть на первую строку.
                    diB работает из любого места.
                    Странно отрицать очевидное удобство
          • +1
            Как я уже говорил в этом треде, на вкус на цвет. Как по мне — так код на Python ничуть не менее нагляден и логически разделен, чем код на любом C-like.
    • +7
      А чем вам не нравятся фигурные скобочки и точка с запятой?
      Про скобки я могу только одно сказать — в текущем множестве общедоступных для ввода с любой клавиатуры символов (т.е. ASCII) их мало. Даже для шаблонов пришлось взять «угловые», которые мешаются с «больше-меньше», что не есть хорошо для компиляторов. Реально нужно не меньше 5 видов скобок.
      А что касается точки с запятой — это разделитель между выражениями. Да, конечно можно попробовать исхитриться и без нее, но для меня это вполне естественный атрибут программы. Как минимум — способ визуально разделить программу на части. Это вообще малоизученная тема, точная семантика точек с запятыми и запятых «плавает» от языка к языку и даже внутри одного языка от конструкции к конструкции; но тем интереснее будет ее изучить.
      • +1
        Я уже написал комментом выше: habrahabr.ru/post/258391/?reply_to=8428269#comment_8428245
      • +1
        А зачем разделять выражения, перевод на новую строку плохо с этим справляется?

        Я не говорю, что скобки вообще плохо. Просто для отделения блоков достаточно отступов. Вот если бы фигурные скобки не были заняты под блоки, их можно было бы для шаблонов использовать:)
        • 0
          Ну это наверное дело привычки… мне вот не нравится программирование на отступах:) (хотя я разумеется в своих программах на С++ строго придерживаюсь одного из стилей выравнивания кода — Allman_style)
          Мне нравится чтобы все элементы программы были «осязаемы». С пробелами такая проблема — а сколько их нужно использовать для отступа? Один, два, четыре, что с табуляцией, в разных редакторах табуляция соответствует разному числу пробелов… Что если я ошибусь на один пробел в большой длинной программе… Пробелы невидимы, и если на них повешена какая-то семантика, то получается, что я не могу точно видеть часть своей программы, как-то так:)
          Хотя возможно вы и правы, спорить не буду:)
          • –3
            4 пробела — стандарт де-факто. Размер табуляции в любом приличном редакторе выставляется в настройках.
            • +3
              А если кто-нибудь по слепоте поставит три? Как поведет себя компилятор?
              • –2
                Серьезно? Вы же не ставите по слепоте круглые скобки вместо фигурных.
                • +4
                  Серьезно. Пробелы невидимы, и по слепоте три от четерых или четыре от пяти можно и не отличить:) Особенно если идет не код одного блока в столбик, а завершение сразу нескольких блоков.
                  • 0
                    Ну вообще приличные редакторы, как я уже говорил, позволяют не заниматься такой ерундой, как ручной подсчет количества пробелов. Для увеличения и уменьшения уровня отступа есть хоткеи (обычно tab/shift+tab).

                    Вы же все равно ставите отступы, хотя и используете фигурные скобки, правильно?
                    • 0
                      Да конечно. Я же говорю что это скорее психологический момент. В тех же Rust и Go мне например не нравится навязывание «египетского» стиля скобок как единственно возможного.
                      • 0
                        Безотносительно конкретного стиля скобок — насмотревшись мешанины стилей, а точнее, отсутствие хоть какого-то стиля в пределах одной страницы кода, считаю добром навязывание любого стиля как единственно возможного.
                        Меньше возможностей выражения своего внутреннего мира путём (отсутствия) форматирования кода — меньше проблем, больше порядка!
                • +1
                  Как нефиг делать. Регулярно в XCode улетаю на 1 пробел вправо или влево, а потом туплю, почему это меня пытается поправить автоформатер.
                  • +2
                    Ничего не могу сказать про XCode, но в IDEA такой проблемы нет.
                    • +1
                      *но у меня в IDEA такой проблемы нет.
                      Не обобщайте :) У кого-то и в XCode такой проблемы нет.
          • +3
            Мне нравится чтобы все элементы программы были «осязаемы».


            Привыкните так привыкните по другому потом сравните. Вон автор статьи привык повторять название процедуры после каждого END
          • +6
            Мне нравится чтобы все элементы программы были «осязаемы».

            Извиняюсь за башорг, но bash.im/quote/406030
        • 0
          Перевод строки как разделитель, мне кажется, плох тем, что придется в одну строку писать все выражения, даже если они километровые, что приводит к плохой читаемости оных. Конечно, тут можно возразить, что само по себе наличие таких выражений — тревожный звоночек, однако все же бывают исключения.
          • +4
            Есть такие вещи, как знаки переноса, в человеческой речи они тоже есть. В 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
            )
            
  • +5
    А вы все о том же:) Эх не хакер вы, не хакер…
    • –1
      В предыдущем посте уже овер 400 комментов, значит тема актуальность не теряет.
      • 0
        Хоть я и не согласен с автором, но такие темы здорово мотивируют на разработку и доведение до ума собственных идей и проектов в области создания языков программирования, за что автору спасибо.
  • +5
    Многие могут не сразу понять, но в обычной жизни, вне рамок критических статей надо всеми силами топить за Rust. Просто потому, что он станет врагом С++. Это как в квартире, зараженной клопами, надо завести тараканов, как естественных врагов.
    • +5
      Вас C++ огорчает что ли?
      • –4
        Все в машину, это же дитфуд!Нет.
        image
    • 0
      У него уже есть серьезный недостаток — практически неверифицируемый компилятор: он при чистой сборке качает бинарный stage0 rustc, т. к. компилятор раста написан на расте. А до раннего rustc, написанного на ocaml'е больше 4к промежуточных сборок.

      В общем, для ответственных применений практически невозможно убедиться в том, что в код компилятора не добавляются отсутствующие в исходниках закладки при сборке. Если оно и взлетит, то до появления альтернативного компилятора в некоторых областях оно неприменимо, как и java. Только кресты, только хардкор.
      • 0
        Компилятор Си делает то же самое, в чём проблема?
        • +2
          Компиляторов C чуть больше одного. Соответственно используя два разных компилятора C (clang/gcc/tcc/whatever) можно провести кроссвалидацию: что stage1 собранный, например, gcc и tcc приводят к одинаковым stage3, а значит, что в валидируемом компиляторе скрытых (не присутствующих в исходниках) закладок нет.

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

          Лично мне интересно, насколько rust будет удобен для bare-metal targets. Из интересного нашёл проект zinc.rs
          • +1
            Понятно.

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

            А про bare-metal — регулярно вижу в IRC и на Reddit людей, программирующих микроконтроллеры на Расте. zinc.rs-то это больше фреймворк, а в принципе libcore — это используемая без аллокатора часть стандартной библиотеки. Достаточно немаленькая часть, для голого железа подходящая. Если интересно, могу попробовать конкретные статьи найти.
            • +1
              В zinc очень понравился макрос ioreg! для описания регистров, оно тогда выглядит куда гуманнее, чем привычные сишные портянки define'ов.
          • +1
            # gcc и tcc приводят к одинаковым stage3
            Т.е. никогда, *.h и ABI — разные.
            • –3
              Почему у gcc stage1, собранного gcc, и gcc stage1, собранного tcc, будет разный ABI (на выходе компиляции тем и другим)? Они ж из одних и тех же исходников gcc собираются?
              • –1
                Странные мимокрокодилы прошлись минусами, но так и не осилили ответить, почему две сборки binutils+gcc (собранные из одних и тех же исходников с одинаковыми параметрами, но разными компиляторами) должны при компиляции и линковке одного и того же исходника с одинаковыми параметрами должны давать разный результат (в том числе, использовать разный ABI)? При условии отсутствия скрытых закладок, конечно.
                • +3
                  <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 нет альтернативного бинарного компилятора для бутстрепа. Так что для подобной верификации остаётся только мучительный путь — компилировать исходники вручную, получив чистую копию, лишённую закладок.
                  • 0
                    (с) К.О.

                    … У 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), (архитектуру?) мы выбрали разную, ((предполагаемо) один и тот же алгоритм) гарантированно разные алгоритмы (различие в количесве бит, регистров, разные оптимизации )

                    Но, таки, да, если одним и тем же компилятором компилировать одну и туже программу на той же архитектуре, (предполагаемо) получим одни и те же объектные файлы. (если компилятор не подмешивает случайные данные, для секурности, или версионности)
                    • +1
                      В инкладах операционных систем отрабатывается какой компилятор сейчас их компилирует и эта информация протягивается по стайджам, можно подшаманить между ними, но мы же доказывает отсутствие закладок?!
                      Закладок в компиляторе. Содержимое инклюдов — это проблемы операционной системы. Точно так же закладка в драйвере файловой системы — это не проблема компилятора и не покрывается DDC-тестом.

                      Суть разного ABI — РАЗНОЕ поведение
                      Важно наблюдаемое поведение.

                      (архитектуру?) мы выбрали разную
                      Для DDC-теста должны выбирать одинаковую. Иначе конечно же результаты двойной компиляции будут отличаться, лол.
                      • –2
                        ))) Вы, просто, бальзам моего сердца, такое чувство от родственной души! Ваш, К.О.

                        Великолепно!
                        "… Закладок в компиляторе..." — проведя неполное тестирование, на «специально настроенной среде», мы можем утвеждать их отсутствие! Встраивайся сколько хочешь. Главное — не менять собираемый образ компилятора.
                        "… Важно наблюдаемое поведение...", на специально настроенной среде — просто не достижимо в современных «троянцах»!
  • +3
    Из серии новейших яистов мне более всего как язык симпатичен dlang.
  • +25
    Это херня какая-то, а не статья.

    Конечно, данный комент это просто забавный способ передать мои ощущения от прочтения статьи. Через призму моего опыта я воспринимал то или иное предложение, которое встречал в процессе прочтения. Конечно, какие-то особенности я упустил. Но цель была немного не в этом.
  • +4
    Просто из праздного интереса, а каков был путь автора в изучении и использовании языков? Например, я начинал с PHP (тогда только вышла версия 4) / JS, потом lua и Си, потом С++. Это из того, на чём были большие проекты, мелочь не считается.
    • +3
      Pascal изучал в школе.
      Работал на freepascal, oberon (модификация), на последней работе java, js, ибо прижал кризис :)
      Вне работы go, dart, вот, на раст смотрю внимательно.
      Еще на actionScript что-то делал, не помню уже.
      • +13
        А. Собственно, все понятно — вы на си и крестах не писали.
        • –6
          Что понятно? Не писал на Си — не мужик?
          • +17
            Это не я сказал. Но оценивать откровенно низкоуровневый язык не имея с опыта работы с подобными — верный путь к фэйлу. Да и оценивать язык по синтаксису — паршивая идея.
            • –5
              На Обероне операционные системы пишут, я разбирал их исходники. Достаточно низкоуровнево? Или надо ниже? Или надо строго на Си писать, чтобы пройти Ваш фейсконтроль?

              А синтаксис отличная штука для первичной оценки, первые этапы боли я получу, выписывая кренделя с исходником. А вы говорите — паршивая идея. Как же поступить? Кто же прав?
              • +10
                М. И что? Вон МС на C# ОС писали. Или Mirage, в котором OCaml-а 90%. Низкоуровневыми это их не делает.

                А правы, скорей всего, авторы Rust-a, которые делают хороший, годный язык для людей, которые годами писали на C/C++.
                • –4
                  А на Обероне на ОС написана на сто процентов. Почему-то Вирта не смутила недостаточная низкоуровневость. Может, это лично Вы без Сишечки не можете, но обобщать не стоит.
              • –3
                Минусуют, очевидно, люди, совершенно не разбирающиеся в истории ИТ, и скорее всего, есть какая-то сложность в понимании того, что есть синтаксис. Процитирую: «Синтаксические единицы являются одновременно и основными смысловыми понятиями любого языка: модуль, класс, блок, функция, процедура, метод, оператор, выражение. Ну а что, если не система понятий и их количество, может характеризовать сложность языка.»
                • –4
                  Борьба мировоззрений. Скобочки победили. На данный момент.
                  • +4
                    Семантическии скобочки ничем не отличаются от begin и end. Это исключительно представление границ блока.
                    • –1
                      Мировоззрение отличается. Скобочки это всего лишь проявление. В статье описано.
              • +3
                Вы про одноименную систему, предназначенную для исполнения программ на нём (написанную Виртом)?

                По-моему, если для языка нужна своя ОС — это фигня какая-то, простите.
                • –3
                  По-моему, если для языка нужна своя ОС — это фигня какая-то, простите.

                  Речь шла о том, что на Обероне можно писать ОС. И все остальное тоже можно. Если вы из этого делаете вывод, процитированный выше, то вам надо всерьез задуматься о возможной дислексии.
                  • +2
                    Ну я попытался понять, о каких ОС на Обероне идёт речь, и нашёл в Википедии следующее:

                    В 1989 году в Швейцарской высшей технической школе Цюриха (ETH) была выпущена первая реализация Оберона для процессоров семейства NS32000. Он был создан в качестве компонента операционной среды Оберон.


                    Из вас же ничего, кроме оскорблений, не вытянешь.

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


                    Если вы по одной фразе диагностируете у собеседника болезнь, то вам надо всерьёз задуматься о чём-то похуже.
                    • –2
                      Вы как-то плохо искали. А какой поисковый запрос вы использовали?
                      я тут погуглил



                      Рекомендую Вам обратить внимание на ссылку www.projectoberon.com
                      • –1
                        Ответа я не дождусь, наверное.
                    • –2
                      Вы попытались что-то понять, назвав то, что я сказал, фигней? RLY?
                • +1
                  Мне кажется, Вы уже совсем непростительные вольности себе позволяете со словами оппонента.

                  Поясните пожалуйста, если не трудно, логическую цепочку по переходу от тезиса
                  На Обероне операционные системы пишут
                  к тезису
                  если для языка нужна своя ОС — это фигня какая-то
                  а господа плюсанувшие ваш комментарий могут присоединиться к формулированию логической цепочки.
            • +1
              Или вот, на Обероне микроконтроллеры для БПЛА программируют, я сам покупал девборду и программировал. Достаточно низкоуровнево? Или надо ниже? Компилировал Оберон в двоичный (и троичный) код. Ниже?
              • +6
                Вообще, мне не хочется вас расстраивать, но Оберон никому особо не нужен и забыт. На данный момент, мне кажется, вполне заслуженно. У нас уже есть куча отличных языков высокого уровня на любой вкус, под любую задачу и любую платформу.
                • +1
                  Ну, мы помним, значит не забыт. А вы и дальше стреляйте себе в ноги, вас же не расстраиваетесь от такого, ведь в жизни низкоуровневого программиста главное challenge. И высокий порог вхождения, чтобы конкурентов поменьше.
                  • +6
                    Считаю себя высокоуровневым программистом, челлендж — да, главное, но я лучше в темплейты и что-нибудь такое подолблюсь, если говорить о челлендже в языке. Пишу на C++, да.

                    Что я делаю не так? :)

                    Хотя не пятница ещё сегдня для таких тредов :)
                    • –2
                      Уже можно!
                • +1
                  … И каждый день появляются все более новые и более отличные языки-однодневки…
                • +5
                  Стоп. Вы сказали, что для оценки низкоуровневых языков надо поработать на низком уровне. Вам говорят, что опыт такой работы есть. А вы начинаете переобуваться на ходу и подменять тезисы (вместо «поработай низкоуровнево» теперь «Оберон забыт»). Нехорошо так делать. В приличных обществах за такое канделябром, знаете ли.
                  • +2
                    Не, не поймите неправильно, я подумывал продолжить про низкоуровневость и семантику. Но потом вспомнил, что не разговариваю с фанатиками, сказал, что хотел и ушел заниматься делом.
                    • +1
                      То есть вы только несете чушь, а отвечать за нее не привыкли.
                      • 0
                        В данном случае от этого не будет ни удовольствия, ни толка.
                        Я лучше пойду упаковку HLS timed metadata для erlyvideo дописывать.
                        • 0
                          Срезал
                          За столом разговор пошел дружнее, стали уж вроде и забывать про Глеба
                          Капустина… И тут он попер на кандидата.
                          — В какой области выявляете себя? — спросил он.
                          — Где работаю, что ли? — не понял кандидат.
                          — Да.
                          — На филфаке.
                          — Философия?
                          — Не совсем… Ну, можно и так сказать.
                          — Необходимая вещь. — Глебу нужно было, чтоб была — философия. Он
                          оживился. — Ну, и как насчет первичности?
                          — Какой первичности? — опять не понял кандидат. И внимательно
                          посмотрел на Глеба, И все посмотрели на Глеба.
                          — Первичности духа и материи. — Глеб бросил перчатку. Глеб как бы
                          стал в небрежную позу и ждал, когда перчатку поднимут.
                          Кандидат поднял перчатку.
                          — Как всегда, — сказал он с улыбкой. — Материя первична…
                          — А дух?
                          — А дух — потом. А что?
                          — Это входит в минимум? — Глеб тоже улыбался. — Вы извините, мы
                          тут… далеко от общественных центров, поговорить хочется, но не особенно-то
                          разбежишься — не с кем. Как сейчас философия определяет понятие
                          невесомости?
                          — Как всегда определяла. Почему — сейчас?
                          — Но явление-то открыто недавно. — Глеб улыбнулся прямо в глаза
                          кандидату. — Поэтому я и спрашиваю. Натурфилософия, допустим, определит это
                          так, стратегическая философия — совершенно иначе…
                          — Да нет такой философии — стратегической! — заволновался кандидат.
                          — Вы о чем вообще-то?
                          — Да, но есть диалектика природы, — спокойно, при общем внимании
                          продолжал Глеб. — А природу определяет философия. В качестве одного из
                          элементов природы недавно обнаружена невесомость. Поэтому я и спрашиваю:
                          растерянности не наблюдается среди философов?
                          Кандидат искренне засмеялся. Но засмеялся один...

    • +2
      Так, в своём понимании мира я не разуверился, теперь опишу, ради чего оно было.

      Каждый инструмент должен быть на своём месте. Например, lua хорош декларативным стилем и гибкостью в структуре кода. Очень круто для небольших скриптов в играх, описании GUI, гибких конфигураций. К тому же сегменту можно отнести js.

      Си — необходимое зло, которое живёт даже там, где ничего другого нет. Но вот C++ — швейцарский армейский нож на низком уровне бытия. Он не всегда есть там, где есть си, зато позволяет сделать приемлемый API для работы. C++ может быть и ужасен, и прекрасен, зависит от продуманности каждой отдельной библиотеки.

      Есть и третья сторона, когда скрипты нужны вчера, увидит их никто, но должно работать. В таких условиях применяется perl, python, tcl и подобное.

      Есть ещё и специфические отрасли, требующие какой-то специальный язык…

      Rust я отношу ко второй категории, кандидат на апгрейд швейцарского армейского ножа. Пока только кандидат. Заменит он в моём арсенале С++ или нет — можно будет решать после хотя бы 50к строк рабочего кода. А в остальном — не стоит рассматривать микробов в молоток.
      • 0
        lua удобен для использования с большим ядром, написанным на «ужасном» С++. Вы же не заставите гейм-дизайнера изучать С++, к тому же модульность языка никакая, дизайнер всё вам там порушит. И перекомпиляция безумная совершенно. Для языков типа Оберона lua теряет свои качества, так как на Обероне можно и ядро написать, и модульно скриптики пописать.
        • +2
          А так же теряется существенная кодовая база сообщества C/C++, что в низкоуровневой разработке игр вызывает неслабые тормоза в развитии проекта. Плавали, знаем. Если приделать к молотку лупу, всё равно на микроскоп похоже мало.
          • –5
            Речь идёт про особенности языка программирования как формального аппарата. Бесспорно, тоннаж готовых к использованию вычислений штука хорошая, но вторичная.
          • –7
            Существенная инфраструктурная база рабовладения и феодализма потерялась в свое время, и ничего.
            • –4
              Господа скучают без феодализма и рабства, судя по всему.
  • +12
    При всём моем (молчаливом) непринятии Rust, вот такие статьи его выставляют только в лучшем свете. Хотя, может, так и предполагалось? Многоходовочка, однако :)
    • –3
      Ну в целом понятно, что я не мог негативно отозваться о Rust, как инструменте, потому что дальше HelloWorld я не работал с ним (я же не такой, как противники Оберона, который ловит клеветы от людей, которые его даже не использовали).

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

      Зато это хороший годный способ рассказать, как оно в Обероне.
  • +4
    Впечатление о языке Яист после прочтения статьи

  • +12
    Да, если бы не Яист, Оберон уже давно бы потеснил С с С++, ага.
    Автор, прошу Вас, меньше воды и капризов, больше практики и глубины.
    • –4
      Ну, с глубиной все понятно, результаты углубления в статье описаны. С практикой тоже все в порядке. А в плане потенциальной успешности Оберона показателен факт абсолютно идентичного мнения большинства участников бесед. Среди них, и правда, Оберон не будет популярен.
      • +2
        Так вы хоть одну статью об Обероне напишите, чтобы это проверить.
        • +8
          Я вот тоже с удовольствием почитал бы статью об Обероне, о его фичах. Вот только автор (судя по предыдущей дискуссии) считает что фичи — это плохо, а хорошо то что в Обероне их нет. А как писать о том чего нет?
          Мы у оберонщиков под пытками выяснили, что в Обероне есть какая-то «типа рефлексия» — возможность получать процедуру по имени процедуры и имени модуля… Кто знает, может там еще есть что-то интересненькое…
          • –1
            Про статью об Обероне вы угадали совершенно точно. Кроме шуток.

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

            А раз предмета нет, то и писать статью не о чем. Писать надо о конкретных продуктах на Обероне. Не знаю, будет ли интересен на хабре опыт переноса среды BlackBox с WinAPI на кроссплатформенный SDL, вот я бы про это написал.
            • +5
              Я всегда говорю — на Обероне денег не заработаешь в силу его крайней простоты, поэтому он неинтересен для серьёзных рыночных игроков. Навороченная IDE для преодоления костылей не нужна, толстые амазон-книги тоже не нужны, может изучаться даже пятиклассниками — предмета для разговора нет.

              Почему он тогда не используется теми «серьезными рыночными игроками», которым важно быстро и надежно разработать свой продукт? Или используется? Тогда можно имена-названия?
              • –4
                Вопрос хороший. Вспомните про Borland, которая отлично поднялась на однопроходном компиляторе паскаля, например. Потом на эту же поляну подтянулись монстры индустрии и завалили её своими продуктами. Вам же всё равно, на чём писать, лишь бы дали бесплатную инфраструктуру, ну а им всё равно, на чём деньги зарабатывать, вот так оно и пошло.

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

                А там, где нужна истинная надёжность, на круглые скобки смотрят в последнюю очередь. Спутники там, или АЭС. Имён не раскрою, зачем? Рынок сделал свой выбор.
                • +3
                  Вам же всё равно, на чём писать, лишь бы дали бесплатную инфраструктуру,

                  Очевидно, нет. Мне совершенно не все равно, на чем писать, у меня есть вполне конкретный набор требований к тем языкам и технологиям, которые я использую в продуктиве.
                  • 0
                    Вы ведь не готовы самостоятельно написать веб-клиент, так ведь? Он должен быть в стеке. И так далее.
                    • +1
                      Веб-не веб, а вот, скажем, карманную реализацию SOAP я уже писал, хотя в стеке она есть.

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

                      (и нет, речь идет не о стеке, а о доступных инструментах)
                      • –1
                        Я и говорю, ваш разумный выбор обусловлен наличием бесплатной инфраструктуры. Кто-то должен вложить миллионы, как Sun в Java, и вам тогда не придётся велосипедить и тратиться на поддержание стандарта. Это хороший, разумный выбор, который, однако, не основан на качествах формального аппарата.
                        • +3
                          А кто-то что-то сказал про «бесплатную»?

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

                          Что возвращает нас к вопросу — что бы я выиграл от использования Оберона в своем следующем проекте?

                          • –2
                            Компилятор стоит денег. Библиотеки стоят денег. Документация стоит денег. Поддержка комьюнити стоит денег. Все критики формального аппарата Оберона так или иначе обращаются к этим аргументам, потому что иметь доступ ко всем этим вещам критично для зарплаты. Раз никто не подготовил для них богатую и развитую инфраструктуру, то это значит, что Оберон плохой. Никто не обращает внимания на тот факт, что рыночным игрокам до лампочки, куда вкладываться. Вложилась же Sun в устаревший уже на тот момент виртовский P-code.

                            А на ваш вопрос я ответить не могу, ведь я не знаю, что у вас за проект.

                            Общие же соображения таковы:

                            1) кадровый вопрос. Изучить Оберон легко, поэтому вливание новых людей в проект на Обероне не потребует особых усилий.
                            2) надёжность. На Обероне сложно писать ненадёжный код, даже новичкам. Жёсткие правила приучают к аккуратности.
                            3) минимальный период отладки. На Обероне можно писать сразу правильный код, не затрачивая время на отладку. Написал — и сразу в продакшЫн. Тестирование, конечно, нужно, но оно больше для лечения от самых глупых ошибок.
                            4) не надо скриптовалок. Отличная модульность позволяет безопасно писать скрипты на самом Обероне.
                            5) прозрачность архитектуры. Отсутствие вытребенек в формальном аппарате освобождает мозг, вы занимаетесь исключительно задачей, а не изучением туториалов по особенностям однострочных литералов какого-нибудь сишарпа.
                            6) чувство железа. Вы пишете MODULE END и программный модуль превращается в бинарный код без оговорок. Вот текст модуля, вот его бинарник. Вы создаёте систему на уровне текста и ровно так же она выглядит в бинарном виде. Загрузили, выгрузили. Всё видно, всё на кончиках пальцев. Знаю людей, которым это ценно, да и сам такой.
                            • +1
                              1) кадровый вопрос. Изучить Оберон легко, поэтому вливание новых людей в проект на Обероне не потребует особых усилий.
                              2) надёжность. На Обероне сложно писать ненадёжный код, даже новичкам. Жёсткие правила приучают к аккуратности.
                              3) минимальный период отладки. На Обероне можно писать сразу правильный код, не затрачивая время на отладку. Написал — и сразу в продакшЫн. Тестирование, конечно, нужно, но оно больше для лечения от самых глупых ошибок.

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

                              Можете привести пример хотя бы одной?

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

                              PS и все-таки, можно привести пример хотя бы одной особенности Оберона, которая (а) повышает надежнось и (б) позволяет писать сразу правильный код — точнее, запрещает писать неправильный?
                              • –1
                                Примеров? Да пожалуйста. У меня когда-то был смартфон Portege G-900, так в нём был эмулятор Java от компании Esmertec, написанный на Обероне. www.computer-museum.ru/histsoft/oberon.htm

                                Компания Oberon Microsystems делала систему управления ГЭС на Амазонке.

                                Российские беспилотники летают на Обероне. На АЭС и конвейерном производстве внедряют.

                                Но как вкладываться в Оберон? Вы посмотрите на Хабр, тут комьюнити такое, что за отклонение от линии партии забьют ногами. Всё, история идёт дальше, рынок поделен, умы отформатированы. Процитирую давнишний тезис: «В последние годы ИТ-индустрия насильно превращает университеты в ремесленные училища.». И это так. Сейчас нужны ремесленники, выпускники ИТ-техникумов и больше ничего. Ну а Хабр наглядно демонстрирует именно ремесленное мышление.
                                • 0
                                  Компания Oberon Microsystems делала систему управления ГЭС на Амазонке.
                                  Российские беспилотники летают на Обероне. На АЭС и конвейерном производстве внедряют.

                                  Ну то есть исключительно производственные системы, правильно?

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

                                  А какая вам разница, что на Хабре пишут? Когда я запускаю свой проект, я ориентируюсь на себя и свою команду. А уж прагматичному западному рынку тем более плевать на нашу песочницу.
                                  • 0
                                    >Ну то есть исключительно производственные системы, правильно?

                                    Никто не мешает написать игру на Обероне.

                                    >А какая вам разница, что на Хабре пишут?

                                    Хабр это лишь пример косности мышления. Когда продукт продавлен на рынок, то люди его начнут поддерживать автоматически. Если бы Sun продавливала Оберон или создатели языка Си не решали бы проблему программирования на ассемблере, у вас бы таких вопросов не возникало. Но продавили нечто совсем другое.
                                    • 0
                                      Никто не мешает написать игру на Обероне.

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

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

                                      Когда продукт продавлен на рынок, то люди его начнут поддерживать автоматически.

                                      … а если продукт хороший, то люди тоже начнут им пользоваться. Например, Octopus, про который вы вряд ли слышали, и который, в отличие от BuildMaster, не занимается активным пиаром, но при этом прекрасно внедряется.
                                      • –1
                                        Вы задаётесь вопросом, что делает Оберон таким, как я его описываю?

                                        Таким его сделал один инженер.
                                        • +1
                                          Я задаюсь вопросом «что из функциональности Оберона гарантирует декларируемые вами характеристики».
                                          • –7
                                            У формального аппарата нет «функциональности». Формальный аппарат призван формализовывать концепции предметной области, а не «функционировать». Ваш вопрос некорректен, я не могу на него ответить.
                                            • +1
                                              Эээ. Тут меня есть сразу два вопроса.

                                              1. какую предметную область формализует формальный аппарат языка Оберон?
                                              2. мне же не лень и переформулировать: какие особенности формального аппарата языка Оберон обеспечивают декларируемые вами характеристики этого языка (например, надежность и минимальный период отладки)


                                              (я сразу оговорюсь: особенность — это то, чего в других языках нет, или реализовано радикально иначе, или не в полной мере)
                                              • –6
                                                Оберон — это язык общего назначения, на нём можно формализовать любые концепции.

                                                Надёжность языка обеспечивается компактностью (не примитивностью!) синтаксиса. Эта особенность наглядно представлена графиком <www.uni-vologda.ac.ru/cs/syntax/graph.gif>, который я интерпретирую следующим образом: майнстримные ЯП движутся в направлении повышения возможностей на выходе, а оберон движется в направлении уменьшения ошибок на входе. Это та самая регистрация сложности на старте, о чём писал Дейкстра.

                                                Преимущества Оберона не в наличии волшебных фичей, а в отсутствии лишних, малозначимых, вторичных.
                                                • +7
                                                  Надёжность языка обеспечивается компактностью (не примитивностью!) синтаксиса.

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

                                                  Эта особенность наглядно представлена графиком <www.uni-vologda.ac.ru/cs/syntax/graph.gif>, который я интерпретирую следующим образом: майнстримные ЯП движутся в направлении повышения возможностей на выходе, а оберон движется в направлении уменьшения ошибок на входе.

                                                  На чем основана ваша интерпретация? На графике нет ничего о количестве ошибок — только отношение числа лексем ко времени.

                                                  Преимущества Оберона не в наличии волшебных фичей, а в отсутствии лишних, малозначимых, вторичных.

                                                  Пожалуйста, приведите пример «лишней» фичи, существующей в мэйнстримных языках, отсутствие которой в Обероне повышает надежность разработанного на нем ПО, при этом не теряя необходимой разработчику функциональности.
                                                  • –4
                                                    Компактность синтаксиса влияет на надёжность следующим образом. Программы пишет человек, используя формальный аппарат. Но возможности человека ограничены. Если аппарат раздут, количество понятий в нём велико, а отношения между понятиями не слишком наглядны, то допустить ошибку гораздо легче.

                                                    Конечно же, на надёжность влияет не только компактность синтаксиса. Про синтаксис я говорю, потому что есть анализ Свердлова.

                                                    Моя интерпретация основана на изучении текстов Вирта и Дейкстры, а так же на личном опыте программирования на Обероне. Я задавался вопросом — нафига выбрасывать это всё из языка. Опробовал в деле и получил ответ.

                                                    «Лишняя фича» — дженерики, например. Вирту задавали вопрос про дженерики, он ответил в том смысле, что дженерики плодят неконтролируемый код, что может снизить надёжность. И я с ним согласен, ведь я не вижу сгенерированного кода, а значит, не могу за него отвечать.
                                                    • +5
                                                      Если аппарат раздут, количество понятий в нём велико, а отношения между понятиями не слишком наглядны, то допустить ошибку гораздо легче.

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

                                                      дженерики плодят неконтролируемый код

                                                      Где это он неконтролируемый?

                                                      ведь я не вижу сгенерированного кода, а значит, не могу за него отвечать

                                                      Ну пишите уже на ассемблере, пожалуйста! А то ведь вы не знаете, что скрывается даже за a + 2 — может быть, целочисленное сложение, может — на FPU.

                                                      А библиотеки вам дёргать не страшно?
                                                    • +5
                                                      Компактность синтаксиса влияет на надёжность следующим образом. Программы пишет человек, используя формальный аппарат. Но возможности человека ограничены. Если аппарат раздут, количество понятий в нём велико, а отношения между понятиями не слишком наглядны, то допустить ошибку гораздо легче.

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

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

                                                      Ссылку?

                                                      «Лишняя фича» — дженерики, например. Вирту задавали вопрос про дженерики, он ответил в том смысле, что дженерики плодят неконтролируемый код, что может снизить надёжность. И я с ним согласен, ведь я не вижу сгенерированного кода, а значит, не могу за него отвечать.

                                                      Прекрасно. Чем вы предлагаете заменить дженерики, чтобы написать код работы с коллекцией (например, стеком) единожды, он работал с элементами любого типа, и при этом сохранялась строгая типизация?
                                                • +5
                                                  На любом тьюринг-полном языке можно формализовать любые концепции.

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

                                                  Ну и там просто разрабатывать приятно, на уровне типов продумал всё, написал сигнатурки, поставил undefined у всех определений, а дальше можно отключить мозг и просто писать код.
                                                • +3
                                                  Надёжность языка обеспечивается компактностью (не примитивностью!) синтаксиса


                                                  Нет ли языков с более компактным синтаксисом? (LISP, Smalltalk, Brainfuck)

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

                                                  Почему «вытребенька» foreach ненадежна вот так:
                                                  foreach(var customer in customers){
                                                      Console.WriteLine(customer.Name);
                                                  }
                                                  


                                                  Но надежна вот так:
                                                  customers.ForEach( customer => Console.WriteLine(customer.Name))
                                                  


                                                  Почему дублирование кода надежнее чем использование готовых конструкций?
                                                  • –2
                                                    Каждый умный человек на хабре неустано вспоминая brainfuck, забывает про понятие turing tarpit. Oberon не входит в число языков, которые можно причислить к tarpit.
                                                    • +2
                                                      Я не настолько умный, чтобы знать это понятие. Не затруднит ли вас пояснить свою точку зрения на остальные вопросы и языки (например можно мысленно вычистить brainfuck из коммента и ответить на него).
                                                      • –2
                                                        Smalltalk и Оберон обсуждали/сравнивали в треде про Smalltalk habrahabr.ru/company/flprog/blog/257611
                                                        А Lisp это же просто удобное описание AST-деревьев. Программировать деревья это классно, компиляторы любят AST, а вот про людей я не уверен. Вот почитайте про проект коллеги, он вам расскажет, как оно, работать на уровне AST habrahabr.ru/post/252677
                                                  • 0
                                                    Кстати, в свете предложенных вами вариантов реализации вытребенек, не могу не вспомнить про проплаченные индустрией пропозалы N4165 и N4174, после которых можно в C++ будет писать код вроде приведённого вами во втором примере, либо вообще с объектно-синтаксическим сахаром вроде
                                                    auto f = fopen(name, "r");
                                                    f->fprintf("%s %d", "foo", 10);
                                                    f->fclose();
                                                    


                                                    Но это так, оффтопик.
                                                    • 0
                                                      вот кстати, напомнили еще про одну вытребеньку — with

                                                      with( var f = openFile())
                                                      {
                                                          f.Write("foo");
                                                      }
                                                      


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

                                                      Как в Обероне с этим?

                                                      Можно было бы не использовать спецконструкцию а просто сделать библиотечный метод:
                                                      openFile().With(f => f.Write("foo"));
                                                      

                            • +5
                              1) кадровый вопрос.Изучить Оберон легко, поэтому вливание новых людей в проект на Обероне не потребует особых усилий.

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

                              2) надёжность. На Обероне сложно писать ненадёжный код, даже новичкам. Жёсткие правила приучают к аккуратности.

                              Это за счёт чего? Особенно в сочетании с пунктом 6, как сохраняется выразительность языка при этом?

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

                              Так можно и на C++ делать.

                              4) не надо скриптовалок. Отличная модульность позволяет безопасно писать скрипты на самом Обероне.

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

                              5) прозрачность архитектуры. Отсутствие вытребенек в формальном аппарате освобождает мозг

                              Что вы называете формальным аппаратом и вытребеньками в нём?

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

                              Можно изучить один раз за всю жизнь и повысить свою продуктивность на эту самую всю жизнь.

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

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

                              Ясно.
                              • –11
                                Смотрю, вас тут научили разговаривать без мата. Свечение личной яркости значительно поуменьшилось, хотя уровень вопросов по-прежнему тот.

                                Если вы не знаете, что такое формальный аппарат, почитайте Дейкстру, просветитесь. На ваши вопросы я отвечать принципиально не собираюсь.
                                • +6
                                  Я без мата умею разговаривать примерно с того же возраста, как вообще умею разговаривать. Просто сообщества разные бывают-с.

                                  Перечитайте мой вопрос: я спрашиваю, что вы назыаете формальным аппаратом в этом контексте, а не что там у кого написано.
                                  А про вытребеньки у Дейкстры, кстати, тоже есть?

                                  Ну а вообще удобно, конечно.
                                  • –8
                                    Конечно, мне удобно и это относится исключительно к составу вашей личности. Поэтому не собираюсь тратить на вас время и вам на меня не советую.
                                    • +5
                                      Интересно, когда и чем я успел вам так насолить, ну да ладно.

                                      Правда, про вытребеньки теперь не узнаю :(
                • 0
                  Теперь под мощью этих продуктов, например, у меня ноут трещит


                  Никогда не понимал, что в наши дни стоит купить ноут по мощнее? Моему ноуту два года, он легкий, компактный, держит пол дня от батареи и не тормозит когда я запускаю на нем ide, какой нибудь box в vagrant напичканный серверами, фотошоп и браузер. Моему компу три года, и он тоже не тормозит ни при каких типичных рабочих ситуациях. И все это не стоило мне каких то космических денег, бук половину ЗП, комп еще дешевле бука (разумеется только системник).

                  Из каких соображений вы отказываете себе в удобстве?
                  • 0
                    Чтобы решить проблемы запуска, достаточно поставить SSD, ведь дисковая подсистема реальный тормоз.

                    У вас SSD?

                    Если нет, озвучьте, если нетрудно, следующие параметры:

                    1) сколько времени проходит от холодного (после перезагрузки) старта системы до открытия рабочего стола?
                    2) сколько времени уходит на то, чтобы после появления рабочего стола (а это признак готовности системы к работе) открыть страничку в браузере и перейти на адрес habrahabr.ru?
                    • +1
                      Есть ноутбук с не SSD.

                      1. Сложно сказать, поэтому разобъём на два пункта:
                      1.1. От выбора в GRUB до появления приветствия менеджера логинов проходит секунд 12. Запуск PostgreSQL всяких включён, например.
                      1.2. От логина до появления рабочего стола проходит ещё секунд 10.
                      2. Смотря какой браузер запускать. Если хром — секунд 10, если FF — секунды 3-4, если личкрафты — секунд 20.

                      Но зачем заниматься бегом в мешках, я понимаю плохо, если машина перезагружается раз в полгода, например.
                    • 0
                      У меня ssd на обеих машинах. Но я не согласен, что ssd, единственный параметр, хоть и очень важный.
                • +2
                  Как лямбды и форыч вообще связаны с производительностью?
                • 0
                  Коллега, я удивлен, что каждый ваш комментарий получает минус, ведь на хабре стоит ограничение на употребление минусов для каждого пользователя. Однако, может быть и правда Вы говорите то, что не по душе сообществу.
                  • –3
                    Не пытаюсь кого-то обидеть, лишь озвучиваю собственные выводы из наблюдений за развитием ИТ-отрасли в течение последних > 20 лет.
            • 0
              Напишите. Серьёзно, я бы почитал.
        • –5
          А мне пока нравится выбранный формат статей. Про Оберон писать нечего, в целом.
  • –3
    яист с оператором unsafe направлен на безопасность

    ПаЦтаЛом :D
    Да и в целом, отличная легкая статья. Читается на одном дыхании.
    Спасибо.
  • +7
    Смысыл начальной фразы сохранится если её заменить на: «неожиданно вы понимаете, что вам бы чего попроще»

    плюсовые разработчики наоборот очень страдают при переходе на подобноые языки. Недалеко ходить взять джаву. Нормальных шаблонов нет, лямбды с какими-то престранными скопами, указатель на функцию нет (что уж говорить про указатель на метод), константы и те не причудливые и тд и тп.
    • 0
      указатель на функцию нет (что уж говорить про указатель на метод)
      функций нет вообще, указатели на методы появились в 8.
  • +16
    Слона вы не заметили (безопасное автоматическое управление памятью, безопасное параллельное программирование, производительность на уровне C). А придираетесь к скобочкам и запятым. Они никакого значения вообще не имеют, просто в большинстве современных популярных языков принят такой стиль и нет никакой веской причины отклоняться от него.
    • –3
      Модели памяти автор уделил целый подраздел. Остальное тоже в статье есть.
      И потом, значение имеет все. В первую очередь текст программ, кроме которого у программиста ничего нет. Если бы синтаксис не имел смысла, он был бы взаимозаменяемым, или настраиваемым под пользователя в IDE. Так что Вам следует быть аккуратнее в своих высказываниях.

  • +4
    Такие то потуги обокакать раст. Автора жаль.
    • –1
      Подряд две статьи с развесистым обсуждением, чего жалеть-то? Радоваться надо.
      • +2
        Ну как-то жиденько это все. До столба докопались, какого то искрометного юмора нет, одно брюзжание. Тоньше надо. И проще. И тогда люди к Вам потянутся (с).
        • –2
          Вам ли не знать, с Вашей-то кармой, как это весело, писать то, что другие боятся даже подумать.
  • +4
    Вот ведь, читал — думал, щас дочитаю, напишу коммент типа «Чо сказать-то хотел?» Но дочитал, увидел ник автора — и вопрос как-то сам собой отпал.
  • +11
    Далее следует объявление переменной, которое совмещено с инициализацией и размещено прямо в коде. Ну а как еще, не делать же отдельную секцию переменных, как в восьмидесятых. Тогда угрюмые колхозники писали все переменные в строго выделенном месте, чтобы потом их в этом месте найти. Вот так ограничивали свободу выражения творческих личностей. Принуждали к порядку. Хорошо, что мы избавились от этого пережитка.


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

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

    • –4
      Не надо так отчаянно защищать свое мировоззрение, на него никто не посягает.
      • +5
        Мне кажется, это проекция :). Я просто изложил свое видение вопроса. Мне было бы интересно если бы вы со мной аргументированно не согласились, но вы не привели ни одного аргумента. Как жаль.

        Может напишете позитивную статью про Оберон?
        • –6
          Это замкнутый круг. Без общей системы координат (которой нет) мы так и будет друг с другом спорить до бесконечности. Я уже 10 лет в сообществе Оберона, каждый Ваш аргумент мне знаком, практически идентичный можно найти в предыдущих обсуждениях. Я понял контрпродуктивность этой движухи, поэтому теперь просто пишу статьи про странный мир вокруг меня. Это не считая того, что собеседники часто вообще считают себя лучше меня буквально, в личностном плане, и их общение со мной складывается по шаблонам дворовой борьбы за доминирование. Многие считают, что это весело. В итоге все вырождается либо в выяснение, у кого больше опыт работы, кто пилил более хардкорные продукты или кто более умело может составить логически непротиворечивое предложение из нужных оскорбительных слов.
          В какой вариант вы хотите выродить эту ветку?
          • +7
            Например, если вы уже написали стройно труктурированную статью «почему мне нравится Оберон» можно дать на нее ссылку.

            Или можно просто игнорировать сообщения, которые вам кажется глупыми.

            Мне кажется в такой форме статьи и ваши ответы только поддерживают движуху про которую вы говорите, что она неправильная.
            • –3
              Это Уловка-22, как бы хорошо и правильно я не говорил про Оберон, неприязнь сообщества будет расти, и формат моих постов не при чем, в треде можно найти откровенно хамские комментарии в мой адрес, которые были одобрены многими людьми. Потому единственный объективный факт состоит в том, что ИТ-сообществу en masse Оберон не нравится уже сейчас. Вы же не будете с этим фактом спорить?
              • +4
                Приведите пример позитивного поста про Оберон (не путать с негативными постами про другие языки в ставнении с Обероном), который вызвал такую реацию?

                Есть ли какое-то объяснение тому, что именно посты про оберон собирают негатив (вы выше привели пост про Смолток, в обсуждении которого упоминался Оберон, и дискуссия была в довольно приличной манере, хотя стороны друг друга явно не понимали).
                • –3
                  Посты про Оберон ломают мем «Оберон забыт». Людям неприятно, когда их привычное мировоззрение даёт трещину. Ведь эффект confirmation bias работает для всех одинаково, программист ты или нет.

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

                  Я про это говорю совершенно серьёзно, потому что мои посты про то, что даёт оберон-подход, встречают обструкцию вида «оберон не лучше того, к чему мы привыкли, вы всё врёте». Другими словами, я про Фому, а мне про Ерёму.

                  Дейкстра был прав.
                  • +9
                    Посты про Оберон ломают мем «Оберон забыт».


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

                    Любое поползновение к изменению точки зрения грозит разрушением картины мира.


                    Я вот пока не вижу какой-то особой мирровозренческой ценности в Обероне. По крайней мере, описанной в ваших постах. Гораздо необычнее монады в Haskell или «все есть объект» в Smalltalk, или минималистичный подход LISP.

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


                    А где, собственно, посты про то, что дает Оберон — подход? Я пока вижу только общие слова (прошерстил по тегу «Оберон»). Где пост проиллюстрированный примерами кода на Обероне?

  • +2
    У меня вопрос скорее по Оберону (хотя топик не совсем про него, но тем не менее).

    Скажите пожалуйста, если в нем все переменные нужно объявлять в начале функции, то я не могу объявить счетчик для цикла так, чтобы он был виден только внутри цикла?

    В С89 в основном это очень раздражает.
    • 0
      Такой фичи в Обероне нет.
      • +3
        Вот кстати, казалось бы. Почему ее нет?

        Ее преимущества понятны. Какие у нее недостатки, которые отражались бы на качестве результирующего ПО?
        • –3
          Потому что циклы со счетчиком это лишняя фича, потому что цикл со счетчиком устарел и отлично эмулируется циклом с предусловием. А у него нет никакого счетчика.
          • +1
            Ага, то есть нет не локальных для цикла переменных, а вообще циклов со счетчиком. А вы не приведете пример цикла с предусловием?
            • –2
              Циклы с пред- и пост-условиями проходят в курсе школьной информатики, извините.
              • +3
                Мне в школе не преподавали информатику, вот печаль. Впрочем, проблема-то не в этом, а в том, чтобы определение, используемое одним собеседником, совпадало с определением, используемым другим собеседником. После прочтения определения из википедии у меня лично возник вопрос: каким, все-таки, образом в Обероне предлагается решить типовую задачу «для каждого элемента из коллекции напечатать название на экране выполнить то или иное действие» (менее типовой вариант: повторить действие k раз)?

                (лучше, конечно, сразу с примерами кода)
                • –3
                  Эта типовая задача проистекает из архитектурного решения, использующего коллекции.

                  Если у вас гетерогенная структура построена на шине сообщений, то коллекции вам просто не нужны, посылайте агентам сообщения.

                  Даже если взять коллекцию. Как вы отработаете ситуацию, когда ваше действие возможно будет применить только к одному элементу коллекции, а остальные не смогут этого сделать? Как вы отработаете ситуацию, когда нужно применить действие не к каждому элементу коллекции? Это совершенно типовые задачи на выборочную коммуникацию.
                  • +5
                    Если у вас гетерогенная структура построена на шине сообщений, то коллекции вам просто не нужны, посылайте агентам сообщения.

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

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

                    В зависимости от постановки задачи — либо обработкой ошибочной ситуации, либо пропуском объекта.

                    Как вы отработаете ситуацию, когда нужно применить действие не к каждому элементу коллекции?

                    Условием (а что, это какая-то проблема?).
                  • +2
                    Вы давно игнорируете мои неудобные вопросы и замечания, но всё-таки шины сообщений вместе с агентам слишком забавно смотрятся рядом с аргументами про близость к железу, управляемость кода и понимание, что в какие инструкции развернётся.

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

                    Не понял вопроса.

                    Как вы отработаете ситуацию, когда нужно применить действие не к каждому элементу коллекции?

                    map . filter
                  • +2
                    Если у вас гетерогенная структура построена на шине сообщений, то коллекции вам просто не нужны, посылайте агентам сообщения.


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

                    Мне кажется тут есть некое фнудаментальное различие в подходах типа 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 базу данных, я вполне себе смогу переделать эту деталь без переделки остальных частей.

                    Хотелось бы в качестве примера решение на Обероне.
                    • +3
                      Товарищ с десятилетним опытом в оберон-коммьюнити каждый раз категорически отказывается код переводить, потому что либо примеры синтетические, либо и ежу понятно, что на обероне удобнее будет. Так что не ждите, кина не будет.
                      • –6
                        Пока я трачу время на перевод, вы потратите его на придумывание «экспертной оценки читаемости и выразительности». Мне это не надо. Если Вам надо, вы и переводите, поди, неглупый человек сможет осилить Оберон.
                        • +4
                          То есть тратить время на сотню комментариев за десять дней — это можно, а кусочек кода показать — всё, приехали?
                          Мне это не надо. Если Вам надо

                          Минуточку, это вам как раз и надо. Судя по вашим статьям, текстам и постам, ваша цель — показать, какой оберон замечательный по сравнению с нынешним унылым мейнстримом. Возможно, так оно и есть, мы же априори не знаем. Ну так продемонстрируйте же это, покажите, какой профит мы получим при решении наших задач, сподвигните на дальнейшее изучение, а не отделывайтесь посылами в стиле «кому надо, тот сам всё узнает», потому что то, что мы тут пока увидели, как-то не вдохновляет. В общем, критикуя — предлагайте.
                          • –3
                            Вопрос только в том, что тратить моё время на комментарии нужно мне, а тратить моё время на код нужно Вам. Субъект и объект меняются местами. Такое положение дел меня не устраивает, конечно.

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

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

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

                              Чего это? Роли равноправны, каждый показывает код на своём языке и сравнивает с кодом на чужом, при этом сторон может быть сколько угодно.
                              • +1
                                Ну и чтобы не быть голословным, приведу аналог на идиоматически и синтаксически далёком хаскеле:
                                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
                                
                              • –2
                                Мне просто нравится писать статьи про Оберон, я оберонщик-графоман.
                                Ну вот желательные свидетельства вы оцените из мнения коллег. Я там сверху описал алгоритм изучения языка. Коллеги мнение свое высказали. Теперь очередь за описанием языка.
                        • +1
                          Ну вот осилю я его (Оберон), переведу, получится хуже и нечитаемее. Это потому, что Оберон плохой, или потому, что я его неправильно осилил?
                          • +5
                            Очевидно ж. Если правильно осилите — переведёте и увидите, что стало-то лучше и читаемее!
                          • –1
                            Я там спросил, в чем «читаемость» измеряется, мне минусов накидали, так что я у Вас не буду этого спрашивать.
                            • +2
                              Это, очевидно, субъективная метрика. А вы чего-то другого ожидали?

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

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

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

                                  А на Обероне?
                                  • 0
                                    Я ничего про оберон не знаю, но вот обход коллекции

                                    А вообще на rosettacode почему-то удивительно мало примеров кода на обероне.
                                    • +5
                                      Спасибо, выглядит предсказуемо.

                                      Собственно, вопрос к адептам Оберона очень прост: что язык и результирующий код выигрывают от того, что программист обязан объявить переменную, выступающую индексом массива (она же, фактически, счетчик в данном примере) в заголовке процедуры?
                                      • 0
                                        А что, они утверждали, что выигрывает? Я просто весь этот дикий холивар в голове одновременно удерживать. Увидел ваш вопрос — и стало интересно, залез на розетту. Я так думаю — программист ничего не выигрывает и инчего не проигрывает. Какая по большому счёт разница где объявлять переменные? Если того требует синтаксис языка — то нормальная IDE должна подсказать, что такой переменной пока нету и предложить её создать.
                                        • +1
                                          Вот моя точка зрения

                                          В кратце — более осмысленный скоп.

                                          // какой-то код
                                          // здесь нельзя ошибочно использовать переменную I
                                          for(var i in myArray1)
                                          {
                                             // здесь можно использовать i
                                          } 
                                          // здесь нельзя по ошибке использовать I
                                          for(var i in myArray1)
                                          {
                                             // здесь можно использовать i
                                          } 
                                          // здесь нельзя по ошибке использовать I
                                          


                                          + чем более эксотичный язык, тем меньше вероятность что будет нормальная IDE. Например автоматический инструмент рефакторинга который перенесет кусок кода с использованными переменными другое место. А в случае локального декларирования это сделать проще.
                                          • –2
                                            Ну слушайте, мы сначала обсуждали 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 (привет, отсутствие разметки)
                                            • +2
                                              В данном кокретном аспекте совершенно все равно какая кокретно конструкция используется, главное что есть ограниченный скоп и меньше вероятности сделать некоторые виды ошибок.

                                              Циклы дейкстры совершеено пофиг в разрезе того, где декларировать переменную.

                                              Почему обход массива два раза — тупой? Между этими бзодами вполне может быть код модифицирующий массив?
                                              • –2
                                                Ограниченный скоп означает, что у вас в коде кандидат на вынос в отдельный метод или хотя бы замыкание. А там свой скоуп.
                                                То есть, если Вы все-таки меняете изначальный вопрос про внутренний счетчик цикла на вопрос про скоупы вообще, то желательно хотя бы предупредить об этом всех собеседников.

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

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


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

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

                                                  Оберон, как я понял, не поддерживает замыканий en.wikipedia.org/wiki/First-class_function#Language_support

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


                                                  Посмотрите эту ветку комментариев повнимательнее (начиная с ответа habrahabr.ru/users/asm0dey). Она вообще не относится к счетчикам циклов, а относится к скоупам. Мое сообщение содержит слово скоуп в самом начале.
                                          • 0
                                            Да, вы правы. С другой стороны можно вынести каждый из этих циклов в отдельную процедуру и вероятность ошибки поуменьшится, наверное…
                                            • 0
                                              Их вынести становится труднее, если нет решарпера.
                                          • –2
                                            Сильно ухудшается читаемость. Вот пример на C#:

                                            Navigator01 nav = GetComponent ();
                                            nav.enabled = false;
                                            ConstantForce force = GetComponent ();
                                            force.enabled = false;
                                            Death01 death = GetComponent ();
                                            death.Play ();

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

                                              var navigator = GetComponent ();
                                               navigator.enabled = false;
                                               var force = GetComponent ();
                                               force.enabled = false;
                                               var death = GetComponent ();
                                               death.Play ();
                                              
                                              • 0
                                                Еще можно тип объявить посреди вызовов. И тут же его реализовать. А в Яисте можно даже два одноименных биндинга подряд объявить, вон до чего дошел прогресс. Больше лапши.
                                                • +4
                                                  Еще можно тип объявить посреди вызовов. И тут же его реализовать.


                                                  Да, смотрите как это легко делается:

                                                  var productQuery = 
                                                      from prod in products
                                                      select new { prod.Color, prod.Price };
                                                  
                                                  foreach (var v in productQuery)
                                                  {
                                                      Console.WriteLine("Color={0}, Price={1}", v.Color, v.Price);
                                                  }
                                                  
                                                  • –6
                                                    Лапша варится всего 7 минут. Легко.
                                            • 0
                                              «А в чём измеряется читаемость?» ©
                                              объявлять можно где угодно, повышая вероятность неаккуратного использования

                                              Когда переменная существует внутри всей функции, а не ровно в том месте, где она используется, эта вероятность ничуть не снижается.
                                            • 0
                                              Вот ровно для этого и сделали вывод типов — чтобы такой код читался легче. Вот вам F#:

                                              let nav = GetComponent()
                                              nav.Disable()
                                              let force = GetComponent()
                                              force.Disable()
                                              let death = GetComponent()
                                              death.Play()
                                              


                                              (другое дело, что все эти GetComponent давно и прочно вытесняются DI, но это уже нюансы; в конце концов, я же не телепат, чтобы знать, что там на самом деле внутри)
                                              • –3
                                                То есть, люди создали проблему, потому что хотелось лапши и не принудиловки, а потом еще пару релизов решают проблемы с последствиями первой проблемы. А ведь достаточно было не создавать проблем.
                                                Делай сейчас, думай потом. Вот об этом и статья.
                                                • 0
                                                  Давайте обсудим почему вы считаете это лапшой. Поясните в чем тут лапшистость? Статический контроль типов на месте, за использованием переменной больше контроля.
                                                  • 0
                                                    Это лапша строго потому, что для выяснения существования переменной в определенной строке кода мне придется прочитать весь код, со всеми его скоупами и как в лапше пойти по следам отдельной макаронины-переменной, которую кто-то засунул не в тот скоуп не в тот момент, а потом ее заменили на такую же, такого же типа с тем же именем, но в верхнем скоупе, и третий человек перепутал i и i и ожидает значения совсем не там где оно должно быть.

                                                    Вы видите, это даже описать трудно, а вы хотите так программировать и еще меня потом заставят ваш код читать и чинить.
                                                    • 0
                                                      Вероятно я с вами соглашусь что где-то это мешает делать методы большого размера. Лично я считаю методы большого размера злом.
                                                    • +1
                                                      То есть когда объявление и использование переменной напрочь разделены, и чтобы подглядеть, откуда какая берётся и какого она типа, нужно туда-сюда мотаться между блоком объявления и основным кодом, это не лапша?
                                                      • –1
                                                        Это организационная «проблема» (хотя как вы без опыта будете судить рассуждать, непонятно), которая уже не повлияет на алгоритмическую составляющую вашей программы. Мы же к этому стремимся, чтобы алгоритмы работали правильно.
                                                    • 0
                                                      для выяснения существования переменной в определенной строке

                                                      Зачем это выяснять? Я не могу придумать сценарий, когда компилятор бы не ругнулся, если вы даже выяснили неправильно.

                                                      Даже с перепутанными i и i, даже компиляторы так нелюбимого вами C++ умеют давать предупреждения о redeclaration.
                                                      • 0
                                                        Ну так, сначала появился косяк, а потом заплатка. Все хорошо.
                                                        • 0
                                                          Если в Обероне два раза подряд в блоке определения переменных определить одну и ту же переменную, то компилятор ругнётся? Это тоже заплатка?
                                                • 0
                                                  В чем именно вы видите проблему?

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

                                                  Я уже неоднократно спрашивал: в чем выигрыш от решения, которое принуждает программиста определять все переменные в одном месте?
                                                  • –4
                                                    То есть отсуствие поиска макаронины не является для Вас выигрышем? Вам и сейчас хорошо. Это в целом подтверждает мои слова о том, что вы не то что не видите, вы не понимаете проблемы. Для вас не проблема, что вся индустрия пишет лапшу, ведь лично мне можно и не писать лапшу. А потом разбираться в коде 95% лапшеписателей. А что, ведь это все в ногу идут, а я не в ногу.
                                                    • 0
                                                      То есть отсуствие поиска макаронины не является для Вас выигрышем?

                                                      А я не вижу ситуации, в которой «поиск макаронины» возникает из-за произвольных определений переменных. Переопределение переменной во внутреннем скоупе — штука не такая частая (скажем, в C# ее нет).

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

                                                      Давайте просто разберем по пунктам. Вот у нас есть строчка кода внутри некоторой процедуры/функции/метода. В этой строчке используется некий x. Что вы хотите о нем знать, что заставляет вас «разбирать лапшу»?
                                                      • –2
                                                        Вы не видите, ну ок, Вы правы. У вас на руках статистика с хорошей выборкой. И вообще, вы мыслите логично, рационально и даже позитивно, все будет хорошо, баги починятся, новые не появятся, всегда будет возможность починить баг, даже в чужом коде. Всегда будут умные люди работать, профессионалы не ошибаются, состояние отрасли хорошее.
                                                        • +1
                                                          Я правильно понимаю, что вы опять не готовы разбирать конкретный случай, так и оставим очередное ваше утверждение неподтвержденным?
                                                          • –1
                                                            Как и сотню ваших утверждений. Если вам интересно обсудить что-то конкретное, приходите в xmpp:oberon@conference.jabber.ru, здесь у меня нет возможности даже отформатировать код, благодаря вашим стараниям, да и желания тоже нет. Причины выше.
                                                            • +1
                                                              Прямо скажем, мои старания тут ни при чем, у меня нет возможности влиять на вашу карму.

                                                              А к моим утверждениям вы просто не задаете вопросов, так что я считаю, что они вас устраивают.
                                        • +2
                                          Какая по большому счёт разница где объявлять переменные?

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

                                          (ну и наконец, предварительное объявление никак не сочетается с неизменяемыми значениями, но это уже следствие строго императивной концепции языка)
                                          • +6
                                            плохо сочетается с выводимыми или неявными типами.


                                            Предсказываю, что выводимые и неявные типы для оберонщиков, это злостная ересь: все переменные должны быть описаны в отдельном списочке, все типы должны быть явно продекларированы, все ENDы должны снабжаться указанием на соответствующие BEGINы и вообще порядок учета требует.
                                            • –2
                                              Типы должны указываться явно, да. Но при этом наследование никто не отменял и указатели на абстракцию тоже.

                                              Вообще, в Обероне принцип «явное лучше неявного» соблюдается достаточно хорошо. В отличие от.

                                              И еще просьба, поубавьте накал вангования сарказм, а то потом будете ныть, что Вам хамят в ответ.
                                              • 0
                                                Извините :). Я, кстати, не согласен с принципом «Явное лучше неявного». Мне вот кажется, что хорошие умолчания лучше. Если явно обозначать все, то труднее отличить необычные ситуации.
                                              • 0
                                                Кому и зачем они должны указываться явно?
                                              • +1
                                                Достаточно ли? В обероне сборщик мусора, который неявно освобождает память. В отличие от.
                                                • –3
                                                  Вы можете явно не использовать динамическую память, и потому будете уверены, что сборщик не работает. А уж обвинять Оберон в недетерменированности сборщика мусора это перегиб, но вы не против перегнуть, если надо, да?
                                                  • +4
                                                    Где вы увидели обвинения? В моём сообщении нет никаких эмоциональных оценок. Лишь указание на факты с просьбой быть последовательнее. А то неявные типы — плохо, неявная память — хорошо. Придирки к GC — перегиб, придирки к СКОБОЧКАМ — нормально. Написать десять строк кода — некогда и всё равно не оцените, написать тыщу строк комментов — чё б нет. Просите конструктивности, а сами в ответ на конкретику съезжаете на демагогии.
                                                    • –3
                                                      Обвинение это не эмоциональная оценка, это уверенное связывание факта с объектом обсуждения, и последующая негативная оценка этого факта.
                                                      То есть сборщик мусора все понимают что такое, все знают, что в Обероне такая модель памяти и все равно вы говорите, что «сборщик мусора в обероне, в отличие от».
                                                      Ну тупейшая манипуляция, с невинными глазкаме, «а чо я, я лишь спросил». Не лишь.
                                                      Вам нужно писать на Обероне, вот и все. А то так ничего и не поймете. Закончу затратную по количеству минусов беседу с вами. Помните, знать путь и пройти его — не одно и то же.

                                                      • +5
                                                        Ещё раз.
                                                        Явное лучше неявного, так?
                                                        В обероне неявное управление памятью, так?
                                                        В C, C++, расте — явное, так?
                                                        Почему вы упорно обходите этот момент, когда говорите, какой же оберон хороший и концептуальный, «в отличие от»?
                                                        P.S. «А то так ничего и не поймете» — кто бы говорил о манипуляциях, ага. А вам нужно лечиться уринотерапией, а кто её хает — тоже ничего не понимают, и даже не хотят попробовать.
                                          • 0
                                            Вы бы знали, сколько противников даже у того примитивного и убогого варианта вывода типов, который появился в 8й джаве…
                                            • 0
                                              В седьмой, вы хотели сказать? Который для генериков и в обратную сторону. Или в восьмой ещё что-то прикрутили?
                                              • +1
                                                В восьмой у лямбд.
                                      • –5
                                        Пока вы задаёте конструктивные вопросы, остальные месят адептов Оберона в минуса. В таких условиях разговаривать конструктивно технически невозможно, движок хабра попросту не даст.
                                        • +2
                                          Вообще-то как раз движок хабра уменьшает последствия «таких условий» — один юзер может поставить другому юзеру не больше одного минуса, поэтому после того, как все присутствующие «отметились» в карме, динамика резко меняется.

                                          Ну и да, вот вы тоже почему-то предпочитаете обсуждать конструктивность беседы, а не конструктивно отвечать на конструктивные вопросы.
                                          • –1
                                            Присутствующим в треде не нужна конструктивность, а нужно поскорее вытеснить неприятное в серый предел. С каждым увеличением срока возможного комментария мне это становится всё очевиднее. Уже неважно, что ты говоришь — главное, рефлекс на тебя выработан.

                                            Ну а раз сообществу в целом (я не про отдельных собеседников) не нужна конструктивность, то мне — тем более.
                                            • –2
                                              Мы опять возвращаемся к Уловке-22, ситуация, в которой под обязательный негативный исход просто придумываются аргументы нужного уровня и в нужном контексте.
                                              Будешь писать долго и вдумчиво — накидают обезьяньих претензий к орфографии и сольют.
                                              Будешь писать динамично — накидают портянок-ответов, а за неотвеченный вопрос сольют.
                                              Будешь писать отрывисто и кратко — скажут, что троллишь и не конструктивно объясняешь.

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

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

                                              А мы будем на Яисте писать.
                                            • +2
                                              Задаю конкретные конструктивные вопросы, а вы от них уходите, не надо так :(

                                              Впрочем, вы скажете, что вам моя личность не нравится, поэтому я не достоин общества оберонщиков.
                                      • 0
                                        Ну о чем я и предупреждал, слова маркеры «выглядит предсказуемо» и «адепты».
                                        Уважаемый, вы же не адепт C#/Java/что там у вас?
                                        • 0
                                          Предсказуемо — потому что после чтения местной переписки и описаний языка я предположил, что цикл в нем будет выглядеть именно так.

                                          И да, я — адепт C#, и вообще .net-стека, что в этом такого?