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

Возглавляется этим же «Гвидо ван Россумом», который не знает:
зачем был нужен reduce() (аналог foldr из Haskell) и поэтому убрал его в какую-то задницу стд библиотеки;
не знает о tail call: [1]
и вообще, судя по убожеству грамматики пейсона, в дизайне ЯП не особенно рубит:
Язык объективно хуёвый, одно выстраивание стейтментов в лябмдах с сайдэффектами (пусть даже и локальными) с помощью логических операторов чего стоит.
Полное отсутствие выбора один-из-многих, по типу МЛ-паттернов или хотя бы няшного switch.
Хуеватый скоупинг, добавленный в язык явно не сразу.
ВНЕЗАПНО статические переменные, статичность которых зависит от способа инициализации
Убожественная система типов.
Нельзя доопределять операторы, поэтому прощайте нормальные DSL. Плюсы-хуюсы и битовые смещения рано или поздно кончатся, да и убого это — перегружать арифметические операторы.
Нет стандарта капитализации при регистрозависимых идентификаторах.
И многое другое!
CPython, «официальная» реализация, тоже сляпана кое-как; есть альтернативные (с нуля писанные типа PyPy — быстрее CPython в десятки раз на мелких программах и лишь изредка тормознее на больших — или форки типа Stackless, который, кстати, выбрали для Eve Online).
Для ветки 2.x (стандартной de facto) операции с юникодными строками представляют из себя захватывающий квест.
Нет возможности написать что-то многотредное по-человечески и без изъёбств. Программы на Python с гуем всегда будут блокировать ввод пользователя до выполнения ближайшей фоновой операции. FAIL.

Байтоёбство включает в себя:
1) Императивный стиль программирования как начало байтоёбского пути.
2) Дрочка на машинно-ориентированные типы данных (собственно, основной симптом байтоёбства) и последующее за ней закономерное возмездие байтомудакам в виде big endian vs. little-endian, особенности обработки чисел с плавающей точкой и.т.д.
3) Предтерминальные стадии байтоёбства - интринсикоёбство и его более тяжёлая форма - инлайн-ассемблероёбство. Подсадка начинается с убеждённости поциента в необходимости ручками использовать SIMD -инструкции.
4) Терминальная стадия, как итог п.3, тру-ассемблероёбство и "хроническая низкоуровневая оптимизация головного мозга"
В нашем мире, к счастью, подобные симптомы с распространением java, C# и прочей "замещающей терапии" встречаются реже, однако остались две отрасли, входящие в зону риска:
1) Гейдев. Байтоёбство в гейдеве берёт своё начало в 70х-80х, поскольку именно тогда зародилась традиция байтоёбства в геймдеве. Обязаны этим, в основном, восьмибитным соснолям и домашним компьютерам, которые, обладая малым объёмом ОЗУ и имея скудные средства программирования, требовали делать на них ёба-игры. Эта традиция продолжилась и далее, всё благодаря тем же консолям, на которых консолерабы должны были выпускать игры 5 лет, задрачивая их убогие байтоёбские архитектуры по полной. К сожалению, подобная практика перешла и на ПК, где байтоёбство, в общем-то не так оправдано. К слову байтоёбам-игроделам дали шанс выбраться из этой трясины в 2002 году, когда майкрософт запилила дуднет и менеджед дайректикс к нему. Но байтоёбы остались верны своим указателям, плюсам и байтоёбской оптимизации. Зашоренность, верность привычкам, безыдейность, десу.
2) Эмбеддед. Причины почти всё те же, что и в гейдеве. Маломощное железо, пара сотен байт озу, деревянные игрушки, прибитые к полу и.т.д. К этому прибавляется огромное количество разных железок разномастных архитектур, для которых нет толковых тулчейнов. Из хорошего - в последние годы байтоёбство в этой сфере потихоньку излечивается, спасибо дядям из ARM co ltd, сделавшим свою архитектуру более менее распространённым стандартом среди всех архитектур и огромному количеству появившихся фреймворков и компиляторов языков для этой платформы.

Так же распространено ложное утверждение что байтоёбство крайне необходимо в системном программировании. На самом деле этого легко избежать. Рассмотрим среднестатистическую аппаратную платформу. Краеугольными камнями любой аппаратной платформы являются:
1) Процессорная архитектура
2) Memory map - адресное пространство, в которое отображаются RAM, ROM и внешние устройства
3) Протоколы управления этими самыми внешними устройствами.
Так вот, всё вышеперечисленное вполне можно вполне декларативно описать обычным конфигурационным файлом, не прибегая к программированию вовсе. Затем, скормить этот файл генератору платформ и на выходе получить готовый фреймворк-скелет нашей операционной системы, доступ к которому можно получить из любого языка программирования. Вот так вот просто, если бы байтоёбство гологного моска не мешало.

Я кончил.

Я считаю, что разработчик - тот кто может решать практические задачи и получать за это деньги. Эрик Мейер - разработчик. Саймон Пейтон Джонс - разработчик. Филип Уодлер и Пол Худак - разработчики. А а данный подфорум целиком состоит из теоретизирующих задротов, которые никогда не достигнут таких высот и не заработают столько денег, как Саймон или Эрик.
Причем фундаментальная ошибка заключается в отнесении себя к некой категории "быдла". Дело в том, что разработка ПО никогда не являлась самоцелью. Использование быдлоязыка или некрасивого архитектурного решения оправдано до тех пор, пока его применение находит отражение в потребительских качествах продукта, и имеет тем большую ценность, чем большей аудитории улучшение потребительских качеств будет доступно и понятно. Т.е. я хочу сказать, что продукт должен быть наоборот максимально небыдло-ориентирован, учитывать его интересы, сделан под него. Это касается и разработки средств и библиотек, а также к выбора средств разработки. Монадическое IO , написанная на Хаскелле и работающее на нищебродских компах обладает гораздо большим рыночным потенциалом, чем какая-нибудь астральная фигня из лиспа типа CPS. Если эта еще и интегрируется с Agda2 а также имеет маркетинговую поддержку от производителя, но позволяет разработчикам самостоятельно зарабатывать на верификации (т.е. не писать горы юнит тестов) - то её потенциал еще выше. Деньги всегда были и будут в "небыдло-технологиях". Так что учите Curry и Coq, вся ваша императивная хуита и клиппед понос никому даром не нужны.

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

Из рассуждений.

>Покажи-ка мне для начала, как ты напишешь на джаве библиотеку контейнеров.

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

В нормальных языках это делается созданием экземпляра аппликативного функтора. В лиспоговне мапкаром. Как ты это сделаешь в джаве? Без лямбд? Давай, давай, пидарас, вперед, можешь начинать хуячить свои фабрики, не стесняйся. Заодно не забудь адаптеры под стандартные контейнеры вроде List-а нахуячить, может быть увидим как ты на ковариантности соснёшь. И чтобы без лапши, клоун, блядь, ональный.
---
Не осилили. Не осилил C++, С#, Пистон... Может быть кроличья нора глубже чем кажется?

Москва,32 года, из них вся сознательная деятельность в ИТ.
Руководящая деятельность более 12 лет в разных направлениях.
В прошлом кадровый офицер, могу подчиняться и могу подчинять.
Был и программистом, были и собственные коробочные продукты.
Был и Сис - Админом, содержал большие парки машин.
Знаком практически со всем ПО и железом.
Руководил проектами. Есть свои проекты. Техническим Директором лет 6..
Креативен и Амбициозен.

Включусь в ИНТЕРЕСНУЮ и мотивированную работу, выстрою ИТ,
можно стартапы (если финансируемые, перспективные, интересные).
В принципе без большой разницы отрасль, главное интерес к работе и прибыль от проекта,
как учередителям, так и участникам.

Бумажно - волокитные проекты с протиранием штанов не предлагать.
Искателям руководителей, которые будут в лицо пахать за всех исполнителей, тоже просьба мимо.
Интересует ЗАРАБАТЫВАНИЕ денег ИНТЕРЕСНЫМ способом, способ не сильно имеет значение.
Оклад от 150т. бонусы, вкусности, акции компании приветсвуются. 89104508135 Александр.

Он не нужен.

Библиотека контейнеров, чтобы делать map по ним. Экономить две строчки с for, чтобы можно было вместо этого написать в одну строчку, но с длинной лямбдой. Об этом я и говорил:
>писяют кипятком от возможности написать в с помощью каких-нибудь IEnumerable и лямбд в строку в 120 символов то, что на яве требует аж 4 строки
Иметь возможность писать map в 120 символов и одну строчку, вместо 4 строчек и 140 символов. Дальше - пустота. Хороший проект для корпорации, когда неизвестно, что еще в язык вставить, а денег все еще много.
Если тебе не повезло родиться интровертом, найди себе хобби, отличное от программирования. Не знаю, Платона там осиль, он тоже идеалист. Или аниме.

> 120 символов и одну строчку
> 4 строчек и 140 символов.

Слушай, строчкопидор, ты заебал.

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

Пойду куплю себе моник 1920.

А кто не согласен с семеном, тот слушает попсу. LabView декларативная штука, и нравится девушкам, рекомендую. Или VHDL. Там строки тоже короткие, но можно и длинными, декларативно, и при этом нужная вещь, появится какое-то удовлетворение от работы, пропадет агрессивность и тревога. Хотя я знаю декларативный язык, где приняты макароны - язык формул экселя. Так что эксель и бери сразу 23". Зачем у газет существуют колонки? Читать вертикальный текст удобнее. Нормальные дизайнеры это понимают.
Но если читать вертикальный текст удобнее, зачем писать горизонтально?
Панк может порезать джинсы, аноним - аватаркофажить, а что может сделать программист с подобными стремлениями? Для начала выучить лисп, но потом окажется, что это простой язык, который знает любой, и как истинному хипстеру приходится менять моду. Я периодически наблюдаю этих людей на разных стадиях, все почему-то пишут одинаковый write-only код, а уж язык любой, в котором к range можно применить лямбду, питон, F# или Scala - особой разницы нет, везде скриптоподобные макаронины (автор кода естественно считает себя непонятым, как считает себя непонятым панк). Длинные имена переменных, о которых автор прочитал в Розентале, не помогают.
Это не синоним декларативности; рабочий код что на эрланге, что на VHDL пишется не вширь, даже на лиспе придумали свое выравнивание, чтобы сделать удобно людям. Это проблема начинащих функциональщиков (т.е. джуниоров, не работавших в команде), которым некому дать по рукам - начальник почему-то требует Java с редакторами, проводящими поля по 80 символов. Догадаться самому зачем это не позволяет низкий социальный интеллект.

---

> cube :: PrimitiveStream Triangle (Vec3 (Vertex Float), Vec3 (Vertex Float), Vec2 (Vertex Float))
> cube = mconcat [sidePosX, sideNegX, sidePosY, sideNegY, sidePosZ, sideNegZ]

> sidePosX = toGPUStream TriangleStrip $ zip3 [1:.0:.0:.(), 1:.1:.0:.(), 1:.0:.1:.(), 1:.1:.1:.()] (repeat (1:.0:.0:.())) uvCoords
> sideNegX = toGPUStream TriangleStrip $ zip3 [0:.0:.1:.(), 0:.1:.1:.(), 0:.0:.0:.(), 0:.1:.0:.()] (repeat ((-1):.0:.0:.())) uvCoords
> sidePosY = toGPUStream TriangleStrip $ zip3 [0:.1:.1:.(), 1:.1:.1:.(), 0:.1:.0:.(), 1:.1:.0:.()] (repeat (0:.1:.0:.())) uvCoords
> sideNegY = toGPUStream TriangleStrip $ zip3 [0:.0:.0:.(), 1:.0:.0:.(), 0:.0:.1:.(), 1:.0:.1:.()] (repeat (0:.(-1):.0:.())) uvCoords
> sidePosZ = toGPUStream TriangleStrip $ zip3 [1:.0:.1:.(), 1:.1:.1:.(), 0:.0:.1:.(), 0:.1:.1:.()] (repeat (0:.0:.1:.())) uvCoords
> sideNegZ = toGPUStream TriangleStrip $ zip3 [0:.0:.0:.(), 0:.1:.0:.(), 1:.0:.0:.(), 1:.1:.0:.()] (repeat (0:.0:.(-1):.())) uvCoords

ФУНКЦИОНАЛЬНАЯ ПАРАДИГМА

---

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

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

Вот тут и начинается самое интересное: с одной стороны язык для опытного разработчика больше не является предметом фапа и изучения, единственное требование к нему - возможность записать программу в категориях, максимально близким к тем, которыми он мыслит. С другой - мышление опытного разработчика гораздо более абстрактно и высокоуровнево, чем мышление джуниора, следовательно, язык должен иметь средства выражения этих абстракций. В этот момент многие разработчики перерастают свой инструмент. Более удачливые переходят на другой, более развитый. Менее удачливые, у которых нет такой возможности, вообще перестают программировать, аргументируя это тем, что программирование - тупое, однообразное занятие, и становятся аналитиками или архитекторами (т.е. фактически тоже меняют инструмент - убогий негибкий язык программирования на гибкий и удобный документ microsoft word). Восторга джуниоров ни те ни другие как правило не разделяют, просто первые говорят, что LANG_A - убогое говно, а LANG_B - крутой инструмент для опытных программистов, а вторые говорят, что LANG_A - это нормальный инструмент для подчинённых им обезьянок, а применения для LANG_B они не видят, поскольку ни они сами, ни их обезьянки этим инструментом не владеют.

И последний вопрос - что же происходит, если LANG_B попадает в руки джуниора? А ничего не происходит, потому что он просто еще не понимает назначение всех этих абстракций и в лучшем случае программирует на LANG_B как на LANG_A (обычно более мощные языки позволяют писать на них как на менее мощных, обратное неверно). Я сам неоднократно встречал студентов, изучавших lisp и prolog в университете (да, сейчас это норма, в моё время никаких лиспов в росийских университетов не было) и совершенно не понимающих, к чему все эти знания. Какого же было их удивление, когда я показывал им как то, чему их пытались учить, применяется на практике, как это позволяет делать более грамотную декомпозицию программы, писать более сопровождаемый код, где лежат пределы выразительности используемого нами языка и как программу можно было бы записать если бы язык был более выразителен.

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

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

Можно написать классы объектов, там где они необходимы и наполнить их методами. Опять же, всё ради структурирования кода, для вполне сносной и быстрой навигации по разрастающейся выгребной яме проекта.

Можно вооружиться профайлером, раскурить исходники ядра фреймворка, который вам предписало начальство, и частично переписать его, снизив время выполнения этого хитросплетения пиздеца на 80%. Вырезать конфиг веб-приложений, сделанный в xml. Уничтожить миллионы вызовов __call() и call_user_func(), от которых кровоточат глаза. Большинство макак знает, что обычное веб-приложение на похапэ инициализируется каждый раз с нуля. Поэтому уменьшить на 90% время инициализации - это очень хорошая идея.

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

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

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

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

Можно придти к мысли, что mysql с её слоупочными table locks и transactional safety и с её возможностью масштабирования только при помощи анальных расширителей не очень-то, собственно, и нужна в большинстве задач. Потратить 2 месяца и перенести огромную смердящую кучу наваленных друг на друга небольших пакетиков с говном на mongodb, на небольшой, но няшный кластер из нескольких replica sets по тройке лёгких машин. Ощутить невесомое изящество, с которой она похрустывает сотнями тысяч записей, прелесть schema-free и отсутствие дрожи в коленях, когда раньше ты запускал alter table на рабочей копии бд, глубокой ночью, потому что оно кладёт сервер на час-другой. А потом часами напролёт в умилении смотреть на графики munin, которые резко перебежали из погранично-красной зоны в самый низ зелёной. Финально включить eaccelerator и наслаждаться запасом в сотни запросов в секунду на отдельно взятом сервере начального уровня.

Можно дополнительно озаботиться настройкой nginx, убрать из конфига логгирование для файлопомойки, включить пяток жизненно-важных параметров, указать нормальные значения для буферов. Окончательно уничтожить апач, для которого был прописан reverse proxy для некоторых урлов. Выкинуть SATA-винты на помойку. Поставить дополнительно недорогих SSD и развернуть на них кэш для самой мелкой статики.

Только это всё не нужно. Ваш сайт, результат вашей работы никогда не получит хоть какой-то нагрузки. Когда на ресурс заходит 10 человек в день, а 90% хитов совершают боты гугла, можно хуярить страницы на 50, и даже на 150 SQL-запросов, ведь все таблицы бд влезают в оперативку, и страница даже на каком-нибудь позапрошлогоднем zend framework без твиков соберётся менее, чем за секунду. Да какой там фреймворк! Какой там MVC! Проще дёргать по необходимости разнородные готовые куски, часть кода бросить голодным доширак-макакам, и склеить всё воедино лишь-бы-работало спагетти-кодом. Ведь проект нужно было сдать ещё вчера, а завтра он будет навсегда забыт. И останется крутиться на задрипанном, надолго предоплаченном vps, в cron которому прописана ежедневная перезагрузка.

Я кончил.

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

Чему будет равно i после выполнения следующих операций:

if(t) cout<<"true", i=15;
if(!t)cout<<"false", i=20;

если t=true? t=false?

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

То, что сообщество скобканутых и лямбдафагов в целом неадекватно — общеизвестный и неоспоримый факт. Интереснее тут другое.
Что первично? Маргинальные ли языки изначально притягивают к себе потенциально нестабильных личностей? Или же, наоборот, погружение в омуты говна аппликативных функторов и кластеров метапарадигм расшатывают психику новообращённых сектантов?

Все просто. Гораздо проще, чем вы думаете, бедняши.

Маргинальные языки и маргинальные технологии привлекают два типа личностей - низкоранговых-низкопримативных и высокоранговых-высокопримативных. Только эти типы людей способны мыслить вне рамок, навязываемых обществом.
Оба типа, с точки зрения среднестатистического человека - маргиналы. Кстати, первых намного больше, чем вторых, но они на фоне вторых не особо заметны. Вторые так заметны именно потому, что их очень мало; их вообще мало, но в IT-тусовке - особенно, в силу специфики области(среднестатистический IT-шник - интроверт, дигитал и социофоб).

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

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

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

Комбинаторы. Впервые понятие комбинатора и основанная на нём теория были сформулированы М.И. Шейнфинкелем ещё до появления лямбда-исчисления. Вскоре после этого аналогичные результаты были получены Карри, независимо от Шейнфинкеля и Чёрча. (Когда Карри ознакомился с работами Шейнфинкеля, он предпринял попытку с ним связаться, но к этому времени Шейнфинкель оказался в психиатрической лечебнице.)

Моисей (Моше) Исаевич (Ильич) Шейнфинкель (4 сентября, 1889 Екатеринославль (ныне Днепропетровск, Украина) – 1942, Москва), русский логик и математик, известный как изобретатель комбинаторной логики. С 1914 по 1924 стажировался в Гёттингенском университете под руководством Давида Гильберта. 7 декабря 1920 г. он, выступая перед коллегами, изложил концепцию комбинаторной логики. Его доклад, опубликованный в 1924 (в обработке Бемаиа), положил начало исследованиям Карри и Чёрча в области оснований математики. В 1929, Шейнфинкель предложил вариант решения проблемы разрешения для некоторых частных случаев формул узкого исчисления предикатов; впервые указал систему аксиом, достаточную для вывода всех тождественно истинных импликативных (содержащих единственную связку «о») формул.
Шейнфинкелем разработана формальная система, позволяющая избегать использования связанных переменных. Его система была по существу эквивалентна комбинаторной логике, основанной на комбинаторах B, C, I, K и S. Шейнфинкелю удалось показать, что система может быть сокращена лишь до K и S, и изложить доказательство того, что такой вариант системы так же полон, как и логика предикатов.
Его работа также показала, что функции двух или более аргументов может быть заменена функцией принимающий лишь один аргумент. Механизм такой замены упрощает работу как в терминах комбинаторной логики, так и лямбда-исчисления и позднее назван каррированием, в честь Хаскелла Карри.
В 1927 году он был признан психически больным и помещён в психиатрическую лечебницу. Его последующая жизнь прошла в нищете, и он умер в Москве, где то в 1942 году. Его бумаги были пущены соседями на растопку.

Т.е. после некоторого http://en.wikipedia.org/wiki/Denial ты таки признал, что проблема в самом языке, а не в тех, кто на нём пишет. И пусть пока ты еще не взял под контроль свой баттхёрт, но уже начал немного думать, это хорошо.

>Ну вообще перед тем как их удалить могут понадобиться какие-то дополнительные, не связанные с освобождением и даже деинициализацией действия. Как пример почему нельзя.
Q: Зачем нужны виртуальные деструкторы?
A: Чтобы не было утечек, коллизий и прочего андефайнед барахла при попытке поиграться с полиморфизмом.
Q: Почему тогда в каждой второй программе на С++ всё равно есть учеки, и почему в джаве их нет, не смотря на то, что деструкторы там вовсе не используются?
A: (почему-то на моё замечение о полиморфизме): То есть, пусть у тебя B - потомок A, и sizeof(B)>sizeof(A) (т.е. в B у тебя дополнительные поля определены) Если деструктор невиртуальный, то после присвоединня A foo = B и уничтожения someA будет вызван деструктор A, а поля, соответствующие B освобождены не будут, это хуево. Если деструктор виртуальный, вызовется деструктор B.
Q: Почему нельзя выделять и освобождать память одним блоком при множественном наследовании? Почему нельзя автоматизировать задачу освобождения памяти при агрегации - ведь стратегия одна - удалить все агрегированные объекты?

Ты не заметил, что речь идёт именно про управление паматью? Т.е. есть проблема - утечки, от которых предлагается избавляться с помощью виртуальных деструкторов. Мой тезис в том, что все, что все операции по управлению паматью, которые приходится делать в виртуальных деструкторах вручную могут быть автоматизированы. Более того, никакой RAII и никакие виртуальные деструкроры не спасут от реальной проблемы, связанной с тем, что объект, созданный в одном месте программы надо передавать в другое место программы. Именно для этого в плюсах велосипедится подсчет ссылок, в более современных языках используются точные мусоросборники, т.к. они обладают большей пропускной способоностью.
>Ты путаеш дилдо с хуем. Есть стековые переменные, есть размещаемые в динамической памяти. Подробнее в гугол.
Нет, дружочек, это ты опять что-то попутал (или вообще не знал). Для освобождения памяти, занимаемой стековой переменной, вообще не нужны никакие деструкторы. Ты же еще не забыл, что мы говорим про управление памятью?

Добавлено (31.03.2011, 23:03)
---------------------------------------------

У bool есть два значения true, false, правила приведения к bool и от bool описаны в стандарте.

А кто делает предположения об этом абстрактном типе ССЗБ.

Шесть месяцев назад я нашёл в Интернете книжку "Dive into Python". Странная книжка, толстая, да ещё на не русском языке. Усердно прочитал её, методично и вдумываясь, но таки ничего и не понял. Но что-то не отпускало меня - я пошёл на python.org и стал изучать стандартную библиотеку, старательно, скурпулёзно, от корки до корки. Гугля примеры кода, я наткнулся на пост в блоге одного гуру, где было написано про PEP8. То, что рассказывал этот умудрённый опытом кодер, настолько впечатлило меня, что я словно в припадке безумия бросился зубрить эту конвенцию по написанию питоньего кода. У меня тряслись руки, по телу прокатывали волны возбуждения, я, можно сказать, бился в экстазе всё это время - и теперь могу процитировать наизусть любой пункт, даже если меня разбудить посреди глубокой ночи.

Как меня это все бесит.

Я бы убрал явный доступ к указателям. Пускай они были бы, но в явном виде программисту запретил бы к ним доступ. Зачем они вообще нужны, кроме как выстрелить себе в ногу и для говноWinAPI? Тыкать в байтики? В явном виде опять же программист может обойтись и без этого. Заменить прослойкой. Зачем массивы, когда есть векторы в STL? А тип char? Тоже лесом. В 21 веке он добавляет только проблем. Хотя без этих вещей C++ превратится в такое гавно прослоек и абстрактного месива(шаблоны, STL, Boost), что лучше уйти к пистону. Но дебилов будет меньше значительно в этом мире. Хотя нет, количество не уменьшится. Это все равно, что нанести косметику на страшную рожу.
Вечером м.б. допишу еще. Много чего бы убрал, абстрагировал. А узнав про необходимость виртуальных деструкторов класса я вообще заплакал =(

Ваши мнения?

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