<<<предыдущий список следующий>>>

Это - копия документа, находившегося на http://dz.ru. Авторские права, если не указано иначе, принадлежат Дмитрию Завалишину и/или Евгении Завалишиной. Все изменения, внесенные мной, находятся в этой рамочке.Пожалуйста, прочитайте disclaimer.


13 Марта 1999

В форуме ("отзывы" слева) идет дискуссия - "сечет ли dz в языках". :-) Как всегда, основой такой дискуссии служит факт несогласия читателя с каким-либо из моих тезисов. :-) Это забавно, хотя, конечно, я действительно весьма много говорю про ОО. И мало, скажем, про функциональное программирование, или там логическое.

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

Вернемся же к языкам.

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

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

Этот самый event-driven интерфейс сам по себе, между прочим, признание факта ограниченности чисто процедурного подхода к жизни. Обратим внимание, что замена процедур на замыкания или списки хрен чего меняет. А вот замена на объекты, гадина, меняет. Изменила, то есть. Подлая жизнь вывернула руки и заставила ввести объект "окно". А не замыкание "окно" и не предикат "окно". Правда, еще и нити, если честно, нужны, но по минимуму хватает и ОО. Хотя бы такого, убогого.

Так что у меня предложение к ценителям Лиспа и Схемы - напрягаться не на ОО, а на процедурные языки, а перед лицом ОО расслабиться, ибо неизбежно. :-) Да и, главное, зачем - инкапсуляция в пояс давит? Или полиморфизм?

Эпатирую? Ну, иначе, собственно, скучно. :-)

PS: Кстати, я протестую против того, чтобы называть SQL языком наравне C ++, к примеру. Как только от него оторвут саму СУБД, я буду за. Надо отдавать себе отчет в том, что повсеместное применение термина "язык" к SQL не дает права не понимать условность такого обобщения.

Реклама
   


Форум CPS Порой, осваивая какой-нибудь новый программный продукт, ты бессильно смотришь в экран и просто ничего не можешь понять. В такие моменты хочется покрыть чуть ли не матом всех этих кровопийц-разработчиков до седьмого колена включительно, невзирая на личности, звучные имена и регалии. Однако теперь есть в русском Интернете место, где многие технические (и не только технические) проблемы, связанные с программным обеспечением, реально могут обрести долгожданное решение. Это место - WEB-конференции на сайте компании CPS.

ПРОГРАММНЫМ ПРОДУКТАМ ПОСВЯЩАЕТСЯ!

 

   

В форуме: "Примерно 60% secureбагов - именно из-за плохой реализации _строк_..."

... в языке Си. Точнее, из-за отсутствия оных в ём. Точнее, из-за отсутствия механизма реализации таких вещей силами пользователя. То есть из-за отсутствия инкапсуляции. То есть из-за того, что Си - не ОО язык.

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

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

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

Человек, не подменяй собой процессор. (C) я.

Кстати, Вадим Гапонов вот тут хорошо высказался, мне понравилось.

Форум: "Денис, представьте себе, как замедлится работа, если с каждой строкой тягать ее длину и при каждом strcpy/strcmp/printf/etc ее проверять, а при каждой модификации строки - пересчитывать."

Я проверял. Никак, практически. Мало того, я как-то сделал класс string и, торопясь, не написал ему copy on write. То есть на КАЖДОЕ копирование строки (вызов и возврат функций, к примеру) выполнялись маллоки и strcpy безо всякой необходимости. Отмечу - программа В ОСНОВНОМ занималась обработкой строк в памяти.

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

Эффект едва поддался измерению. Сисколлы (напр. time() в OS/2) жрали несравнимо больше.

Число strcpy при переходе к классу string падает, кстати, а пойнтеры передаются одинаково быстро, на что они ни указывают. Пересчитывать длину при модификации - это ОДНА команда процессора, между прочим. А именно add/inc/dec, в основном. Реже - sub.

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

Но. Если выигрыш от ОО есть, не обязательно наличие потерь в скорости.

И, кстати, я люблю софт, который работает правильно, а не тот, который ошибается быстро. А вы? :-)

Вот чего бывает.

   
From: Udalov Andrey
Subject: Американцы на пепелаце

Доброго!

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

http://www.rotaryrocket.com/
http://www.rotaryrocket.com/tec/designp.html

:))

Best regards,
Андрей Удалов

 

Интересно, задумывались ли они о разработке гравицапы. :-)

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

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

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

Как-то дюже волшебно все это выглядит, право. Хотя, конечно, так хочется верить в чудеса... :-)