OberonCore

Именно.
Вопрос в том, ясно ли мы понимаем, почему Оберон такой "несладкий"?

Создание новых объектов, вместо изменения старых -- это уже особенность чистого ФП Хаскелла и к замыканиям отношения не имеет. "Замкнутые" переменные можно и изменять:

Вот только мутабельные переменные не имеют никакого отношения к ФП -- это особенность императивного подхода.

Не имеют. Но и замыкания, получается, тоже не ограничиваются только ФП.

В Смолтоке блоки кода НЕ МОГУТ ОТСЫЛАТЬСЯ КАК СООБЩЕНИЯ объектам, а - только как АРГУМЕНТЫ СООБЩЕНИЙ. Или же ИМ можно сообщение посылать:

И я особо тоже.


Мне что-то вот кажется, что точнее было бы назвать это дело не "замыканием", а "вложением"...

Я про что и говорил, когда упоминал, что замыкания (под названием блоков кода или block closures) являются одним из фундаментальных кирпичиков в Смоллтоке...

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

Зато полная ясность нужна всем. Просто, к сожалению, многие этого не осознают/не осознали...

Да не в этом дело!
"сахар" и сахар нужен всем.
Только, что подразумевается по сахаром? Почему возникает в нём избыточная потребность?
Я обожаю тематику встроенных систем и систем реального времени просто потому, что здесь между мной, моим интеллектом, идеями и решениями И железом - МИНИМУМ промежуточного кода, нет чужих идей, идеологий и проектных решений которые я должен блюсти и которым должен подчиняться (буде то стандарты или принятые сообществом технологии). Я - сам себе автор всего этого. Это - классно, это - непередаваемое ощущение почти Бога (ты сам строишь хотя бы и миниатюрный мир, который своей работоспособностью и устойчивостью доказывает правильность твоих решений и заделов)... Это вселяет уверенность. Это стимулирует (потому, как всякоразных "перинок" и "сололмки" никто, для "смягчения ошибок", тоже не подложит - только твои мыслительные процессы (их, реализованный в твоём же коде, результат) обеспечивают тебе уровень комфортности и безопасности).
Пока что, объёмы памяти не позволяли реализовать огромные системы времени исполнения в таких системах. Для "сахара" места нет. Надо, что по-проще... Например, Оберон-0 там бы был - самое "то". Но, к сожалению и здесь властвует Си. К сожалению, потому, что есть масса моментиков, когда всё-таки было бы лучше иметь БОЛЕЕ безопасный язык для реализации систем... Другое дело, что ДАЖЕ на уровне привлекательности Оберона-0, естественно иметь более приятные и удобные возможности. Пусть будет строгий язык, с соответствующей семантикой элементов! Но, ребята, упираться рогом в какие-то непонятные "принципы" и упорствовать против введения в язык, например, средств инициализации структур данных при объявлении или объявлении переменных в любом месте кода или быть против рассмотрения введения безымянных (и параметризуемых) блоков кода, передаваемых в качестве аргументов функциям) - это уже просто МАРАЗМ!
Это уже - не сахар,а - доказавшее свою полезность и не наносящее какой-то там "вред" или "отступление от йоты" - средство!

"Сахара" НЕТ. Есть адекватность выбора средств к задачам в совокупности с реализованными идеологиями и парадигмами.
Будет у меня что-то встроенное с гигом ОЗУ и тремя ГГц быстродействия - почему и не попробовать на Си-шарпе поработать?...

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

Оно понятно, что профессионалы ошибок не делают.

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

Когда на блюде ворох фантиков, тык это ж смотрится красиво! Создаётся впечатление, что ребята классно поработали и завернули все возможные чихи, каждый в свой фантик. И можно здорово сократить дорогу, если взять все эти фантики и употребить по назначению. Одно не учитывается - человек не может держать в голове одновременно больше 7 фантиков ("единиц информации", 7 плюс-минус 2). Но и совсем без фантиков не может.

Получается смешная штука. Фантики имеют себестоимость, поэтому их надо продавать побольше. Чихов в жизни полно, поэтому производство фантиков никогда не закончится. А глянешь на улицу - ничо не изменилось. Люди как ходют о двух ногах, так и ходют. Как потребляют 15-20 литров кислорода в час, так и потребляют. До Марса человека забросить не смогли, мир во всём мире никому не нужен, телевизора хватает для удовлетворения всех духовных потребностей для подавляющей массы населения. Читать стали меньше, убивать больше.

Откуда берутся фантики и для каких целей - непонятно.

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


Делают.


Ну так проанализируйте и найдите золотую середину между поддержкой "правильности" в подходах и удобстве их реализации и сопровождения! Или для Вас "интеллисенс" - личный враг?


Для большинства из всех людей
Удобней камня молоток,
При забивании гвоздей.

А вообще меня здесь страшно стали раздражать противостояния всякоразные...
Иногда такое впечатление складывается, что отдельные индивидуумы сюда "заземлять" свои страхи и комплексы ходят.
Программирование, что - особая отрасль деятельности в смысле своего генезиса?
Направления, замыкающиеся в себе, "твердолобые", "закуклившиеся" в своём мироощущении и своей модели мира обречены. Нельзя самоограничиваться в развитии! Надо ХВАТАТЬ всё новопоявившиеся и пропускать через горнило и топку своего анализа и пробования, вычленять оставшееся и вкладывать в свой "талмуд", гибко видоизменяя и подстраивая его. Мы можем с водой и ребёнка выплеснуть!
Не нравится вам Си-шарп и дотНЕТ - воля ваша. Только как-то не упустите момент, что визуал-студия станет вторым турбо-борланд-паскалем!...
Я уже сейчас практически все свои алгоритмы и их логику сначала стал обкатывать в Си-шарпе, как делал до этого в Борландовских продуктах... Не в малой степени и потому, что там ДЕЙСТВИТЕЛЬНО УДОБНО работать... Кто его знает, может быть потому, что именно тиме вижул-студии много бывших борландовцев работает?...
То же самое и самого языка касается. Ну УДОБНО мне с замыканиями работать (хотя бы и в такой реализации, как в Си-шарпе!). Ну удобно мне инициализировать коллекции = new List<OfAnyType>() { именно, здесь, в, месте, их, объявления };...

Лично я сторонник объявления переменных всегда в отдельном месте. И противник смешивания фактов объявления с потоком логики в тексте. Потому как мне совсем не хочется пялиться на знаки явного импорта в том контексте, где реализуется рабочая логика. Мне нравится обнадёживающая граница между "вот тут у меня переменные" и "вот тут я ими думаю"

Ха-ха, почему сразу - "личный"? Ясен пень, когда своего интеллисенса (который между ушами) на обозрение фантиков не хватает, то без фирменного помогальника никак. Ещё вопрос, где в итоге выше производительность: при разглядывании выпадающих интеллисенсовских списков, или же в наработанном гипертекстовом автоматизме.



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

извините пожалуйста, а что такое тиме

А как этот гипертекстовый автоматизм наработать? Хочется поднять свою производительность...
team -- команда

Этот вопрос удобно решен в дельфийной среде.
Как только мне затребовалась переменная в данном участке кода, я пишу её и, оставив курсор на этой переменной, нажимаю Ctrl+Shift+V.
Среда сама в секции var данной процедуры вставит объявление.
А когда я наведу курсор на какой-нибудь объект программы, среда выставит описание что это и где объявлено, с возможностью перехода в место объявления по клику мышки.

Такое вовсе не сложно сделать в любой среде.


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


Во времена Пушкина человек в 40 лет – старик.

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

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

Я уж не говорю о таких полезных и ежедневно используемых вещах, как навигатор кода Ильи Ермакова, браузер переменных Петра Кушнира, закладки Александра Ильина. Тот самый "интеллисенс"? Неа, гипертекст!

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


"7 плюс-минус 2" - это т.н. "число Миллера", объём внимания. Физиологический, блин, предел.

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