OberonCore

В тех редких случаях, когда я пользуюсь Офисом, я не пользуюсь тулбаром.
А одна моя хорошая знакомая, которая владеет этим самым Офисом профессионально, не то что тулбаром, но и мышью редко пользуется... (из-за этого много "мата" я от неё услышал, когда посадил за Опен Офис )

Ну, присоединённые процедуры, ассоциированные процедуры - как хотите назовите... Главное - есть формальное обозначение ассоциации оппераций к структурам данных...


Первое множество - выделенный фрагмент? Тогда - пардон, но "множество значений" какого типа (класса,множества)? :о)


Если "5"-ки находятся по разным адресам, то они уже индивидуальности имеют и идентификаторы у этих значений - их адреса (в простейшем случае). Другое дело - как мы интерпретируем эти разные "5"-ки в нашей модели.
А про "посылку сообщений" - звыняйте, собираетесь Вы или нет "посылать им сообщения" - зависит от выбранного языка. Конкретно в Смолтоке никого не интересует собираетесь или нет - Вы ОБЯЗАНЫ это делать. По-другому, там просто - никак!... :о)

К сожалению, программы в основном делаются не для профессионалов. Поэтому тулбары всё-таки нужны, так как на порядок снижают порог вхождения в программу...
Ну а для профессионалов нужно оставить возможность пользоваться хот-кеями и убирать тулбары...

Совершенно надуманно. Никак тулбары не снижают порог вхождения. Посмотрите на Adobe InDesign (PageMaker) там тоже тулбаров полно, однако без знания принципов вёрстки, хрен вам они чем помогут. А в итоге потом они всё равно далеко не так интенсивно используются, так как очень много различных "хоткеев" с которыми значительно быстрее получается.

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

Вот эти вот идентичности порою так вымагают :о(
Вот понадобилось мне на C# проверить равенство содержимого двух массивов списков, так операции == != проверяют именно их идентичности, а не содержимое, в отличие от Хаскелла, например, где нет такого понятия, как объекты с идентичностями...
Пришлось склепать самодельную проверку с циклом :о(

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

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

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

В сложных компилятор скажет, что не хватает return, но не наоборот.



Ну и что? Есть к чему стремиться.

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

Реальной пользы все равно нет и не будет, т. к. компилятор не может думать. Думает программист. И если он написал ошибочный код на КП, он работать не будет (про RETURN). А "нормальный" компилятор С++ выдаст предупреждение, которое:
- ошибочно и будет проигнорировано;
- просто будет проигнорировано в силу привычки;
- все же поможет, если компилятор угадал, а программист обратил внимание;
- т.е. в большинстве случаев ошибочный код будет работать.

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



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



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

Если бы компилятор могу думать, он бы освободил программиста от его работы.
Понятие "тупой" к комп-й программе не применимо.

Сортировал один завалявшийся набор электронных книг.
Книга Г. Шильд "C# Учебный курс", изд-во Питер.
Из вводной части:
"СОЗДАНИЕ ЯЗЫКА С - НАЧАЛО СОВРЕМЕННОЙ ЭРЫ ПРОГРАММИРОВАНИЯ.
... К моменту появления С более ранние языки, самым известным из которых является Паскаль, использовались достаточно успешно, но именно язык С определил начало современной эры программирования...
--- далее вполне нормальный абзац про роль перехода к структурному пр-ю ---
Именно С стал первым структурным языком, в котором успешно сочетались мощность, элегантность и выразительность. Такие его свойства, как краткость и лёгкий в использовании синтаксис в сочетании с принципом, согласно которому ответственность за возможные ошибки возлагается на программиста, а не на язык, быстро нашли множество сторонников. Сегодня мы считаем эти качества само собой разумеющимися, но тогда в С впервые были воплощены великолепные новые возможности, так необходимые программистам.
...

ПОЯВЛЕНИЕ ООП И СОЗДАНИЕ ЯЗЫКА С++
В конце 70-х гг. настал момент, когда многие проекты достигли максимального размера, доступного для обработки с помощью языка структурного программирования С. Теперь требовались новые подходы, и для решения этой проблемы было создано ООП. А поскольку С, являвшийся в то время самым распространённым языком, не поддерживал ООП, возникла необходимость создания его ОО-версии.
"

Вот такое вот пиплу скармливается. По совокупности невежества и корыстного умысла, как обычно, переписывается история.

И Джоэл Сполски туда-же. http://www.joelonsoftware.com/items/2006/08/01.html Я его даже уважал за весьма адекватные статьи Но вот про обязательность поддержки в языке возможности на лету реализовывать тела анонимных процедур , это уж перебор! Много лишних телодвижений видите-ли, что-бы ещё и писать реализацию процедур где-то по-человечески.
Что самое интересное, эту возможность уже включили в Delphi 2009 http://bdntv.codegear.com/pix/PawelGlow ... hi2009.pdf и сослались на статью Сполски.
Хотя, под конец статьи говорится про занятный приём MapReduce.

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

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

Лично у меня одна большая претензия к "писать реализацию процедур где-то" - надо придумывать имя для этой процедуры. Причем чем проще функция (x * 1.5), тем сложнее это сделать. Так что возможность действительно восребована.

А у меня претензия к "писать реализацию процедур где попало": при обратном процессе (то есть, чтении) разбираться с этим аморфным кодом крайне сложно.

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

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

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