Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | |
Нет, в TP была своя схема объектных модулей (юнитов). Фокус... 22.08.07 17:38 Число просмотров: 5763
Автор: crontab Статус: Незарегистрированный пользователь
|
> Ну так она в паскале и появилась из плюсов. Все более менее
> хорошие вещи в паскале (и производных) появились из C++.
Нет, в TP была своя схема объектных модулей (юнитов). Фокус был в том, что интерфейс и реализация объявлялись в одном исходном файле, а не в двух отдельных как в Си. Исходный файл состоял из двух секций - interface и implementation, и это было очень удобно. Из-за этого, правда, формат объектного модуля был специфичным, а не стандартным ".obj". Наверное в Инете можно что-то найти по этой теме.
> Что такое оптимальная перекомпиляция? Ни гугль ни яндекс не
> знают о таком.
В Си любое изменение в .h файле приводит к перекомпиляции всех модулей, которые включили этот .h. Turbo Pascal же (и Delphi) проводил минимальную необходимую перекомпиляцию - это опять же упирается в его двичные форматы. Сейчас подобные фокусы могут делать какие-то очень крутые Си-компиляторы, но в мейнстрим такая практика так и не вошла.
>
> Ну а в *NIX получится штук 20. Это не считая
> бэкапа/рестора, подключения дополнительных хайвов,
> использования удаленного реестра и пр.. Они появились не по
> прихоти - кому то это понадобилось.
>
В UNIX не получится 20, потому что они там уже есть. Бэкапы и удаленный доступ тоже получаются автоматически как с обычными файлами (tar, NFS), а в Windows для обеих функций пишутся специфичные сервисы и специфичные GUI - еще один прекрасный пример раздувания задачи из ничего.
> > использоваться стандартные функции open, read, write,
> итд,
>
> Не уверен, что это плюс. Если выбирать между чрезмерной
> перегрузкой семантики одних и тех же функций и "ожирением"
> интерфейса, я, пожалуй, выберу "ожирение". Вы же сами и
> описывали проблему с write-ом из-за его перегруженной
> семантики.
Но я уже хорошо знаком с write(), и мне не надо перечитывать документацию. В Windows же, мало того что надо помнить или же всякий раз заглядывать в документацию, плюс к этому семантика этих функций тоже нетривиальна, что тоже абсурд. Мне бы очень не хотелось загружать мозг такими пустяковыми вещами - у мозга ресурсы ограничены.
> > UNIX Registry будут работать все стандартные cmdline
>
> В описанном виде - не будут. Ибо тоже нужно делить на
> "ключи" и "значения". Все cmdline утилиты ожидают, что файл
> окажется либо директорией либо файлом. И вот
> интерфейс UR раздувается еще на несколько вызовов.
Я не понял почему нужны еще вызовы и почему утилиты не будут работать. Для утилит - это файлы, и им нет дела до того, что драйвер на самом деле отводит каждому файлу не полкило на диске, а гораздо меньше.
В статье я, правда, упустил enum, который в терминах FS на UNIX - это функции <dirent.h>, тоже знакомые. Ничего страшного.
> Вопреки
> общепринятому мнению, в майкрософте сидят СОВСЕМ не дураки
> и я уверен они обдумывают несколько возможных путей перед
> тем как принять то или иное архитектурное решение.
>
В Майкрософте сидят не дураки - это самый плохой аргумент в защиту Майкрософта. А за раздуванием API кстати, стоит маркетинговый трюк, который заставляет людей посвятить себя целиком ихним технологиям, потому что ресурсов и времени на изучения "чужих" у программиста уже не остается. Этот прием, кстати, изобрели в IBM еще до появления Windows.
>
> Ну возьмем сначала: используйте "интернет-технологии" (а
> если проект вообще не связан с сетью?), но не используйте
> XML (а как же Asynchronous JavaScript + XML - в миру AJAX,
> от которого сейчас не продыхнуть). Я совершенно согласен,
> что XML - не серебрянная пуля и не стоит его тыкать куда не
> следует, но структурированный и расширяемый XML ГОРАЗДО
> лучше *NIX-like текстовок. Что же до языка и библиотек,
> позволяющих сосредоточиться на главном - это правильно, но
> при чем здесь отказ от метапрограммирования и шаблонов? Я
> так понимаю, от них следует отказаться только потому, что в
> "правильном" Delphi их нет? И почему следует АПРИОРИ
> отказываться от COM/DCOM? Что в них такого ужасного, что их
> нельзя использовать вообще?
>
AJAX - это способ посылать HTTP запросы прямо из браузера, и XML тут вообще не при чем.
XML по сути - это формат для записи древовидных структур данных. Во-первых в нем нет необходимости когда нет дерева, и во-вторых его синтаксис избыточен. Например лиспоподобный синтаксис уже выглядел бы лучше и компактнее, его легче было бы парсить и легче редактировать вручную.
Шаблоны Си++ ухудшают читабельность, потому что их сложно понимать. Ими можно делать очень крутые фокусы, но в продакшн надо использовать в очень сдержанном количестве. Вобщем, это мнение не ново и не оригинально.
DCOM - это надстройка над RPC. Все бы ничего, но он слишком привязан к Access Rights в Windows, из-за чего возникает много мороки. Плюс его очень трудно или почти невозможно файерволить - вместо этого приходится открывать чуть ли не все порты. Нет возможности "общаться" через прокси, как в HTTP.
Майкрософт сам уже постепенно сворачивает COM/DCOM и предлагает переходить на .NET-овские технологии, которые, однако, страдают схожими недостатками.
О преимуществах HTTP: длинная история, для этого и правда нужна отдельная статья.
> Ну а цитата про "Large systems" - вообще ни к селу ни к
> городу. Все современный операционные системы и компиляторы
> - охренительно большие системы, так что же теперь
> отказаться от них, только потому, что некто из гугля
> считает это плохим?
Эта цитата о том, что большие системы должны быть разбиты на небольшие куски - вот и все. Из современных компиляторов только Си++ очень большой - так это говорит не в пользу языка. Turbo Pascal 5-ой версии занимал 70 килобайт (!), когда как сишные компиляторы - это мегабайты и даже десятки МБ.
|
|
<site updates>
|
Клиника плохого кода 22.08.07 12:55
Publisher: dl <Dmitry Leonov>
|
Клиника плохого кода
Овик Меликян http://www.melikyan.com/dalshe/
Исходный код программ, которые создают программисты во всем мире, по качеству можно разделить на четыре категории: хороший код, плохой, ужасный и с трудом компилируемый хаос.
В последнее время мне пришлось иметь дело с исходным кодом одной исключительно, адски плохо спроектированной и хаотически реализованной программы, которую в течение шести лет писали люди, едва ли имеющие отношение к программированию, если забыть об их дипломах в Computer Science из разных авторитетных университетов мира. Все что должна была делать эта программка - это копировать файлы с одной Windows-машины на другую. Эта задача была решена в 80,000 строк кода на Си++ (функциональная часть) и в 55,000 строк кода на VB (GUI часть). Компиляция порождала примерно 10 файлов: 6 EXE и 4 DLL. На одном конце устанавливались 3 системных сервиса и две COM компоненты, а на другом - 2 сервиса, одна COM компонента и собственно графический интерфейс для управления этим монстром.
...
Полный текст
|
|
ИМХО, в статье ничего нет, кроме неаргументированной рекламы... 18.03.08 12:50
Автор: Estellehtaon Статус: Незарегистрированный пользователь
|
|
ИМХО, в статье ничего нет, кроме неаргументированной рекламы unix. Понятно, что есть плохой код и хороший код. Но чтобы писать хороший код совсем необязательно отазываться от программирования под винды. В любой операционной системе можно написать как плохой, так и хороший код. Конкретных же рекомендаций нет, только их обрывки.
|
| |
Re: ИМХО, в статье ничего нет, кроме неаргументированной рекламы... 09.05.08 17:50
Автор: Линда Кайе Статус: Незарегистрированный пользователь
|
|
Верно замечено. Особенно смутил упрощённый подход к реестру и вывод из этого что уж в UNIX оно было бы намного проще. А уж как по XML автор проехался, заявив, что это всё плохо, а загадочные текстовые файлы в стиле UNIX - это хорошо. W3C тихо плачет в уголке.
|
|
Опечатка в тексте 28.08.07 09:41
Автор: n0xi0uzz <Черкасов Виктор> Статус: Member
|
Вот в этом параграфе:
"Продолжая в том же духе, шаг за гашом, анализируя свои привычки и стиль, вы сможете привести его в гораздо более удобоваримый для нас, homo sapiens, вид."
За чем шаг? ;)
|
| |
fixed, спасибо 28.08.07 10:07
Автор: dl <Dmitry Leonov>
|
|
|
| | |
очепятка "по Фрейду"? ;-) 29.08.07 16:49
Автор: leo <Леонид Юрьев> Статус: Elderman
|
|
|
|
Даже хочется поблагодарить за тему. Сам хотел поднять... 23.08.07 13:04
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Клиника плохого кода
> Овик Меликян http://www.melikyan.com/dalshe/
Даже хочется поблагодарить за тему. Сам хотел поднять подобную, но все с мыслями не соберусь.
Сначала хочется сказать о маленьком минусе статьи, чтоб не забыть - тему Виндового реестра следовало бы вынести отдельно, как и все то, что не относится к программизму в чистом виде.
Среднее арифметическое неудачный пример из-за своей простоты и специфики. Здесь я бы аппонировал следующим правилом, самым первым, которому учат новичков: Правильно выбирайте тип переменной, так, чтобы при работе программы все возможные ее значения с запасом могли храниться и участвовать в вычислениях ("int", "long", "float", "double", ...)! Но не используйте "float" везде, особенно там, где достаточно будет "int".
Если уж писать про корни квадратного уравнения, то надо быть последовательным и не останавливаться на полпути, а то в статье упоминается про idiot proof, неочевидность результата и "поводные камни", связанные, что программист (как шахматист) не предусмотрел возможные варианты. Корни не всегда могут быть действительными. "Корней нет" - это "начальная школа". Надо бы чуть доработать статью. Наверняка в интернете можно найти всю инфу, которая покажет, насколько сложно написать программу вычисления корней кв. ур. без ошибок, что у многих кодеров волосы дыбом встанут и они почуствуют себя на месте микрософтовских программистов.
Ругают статью наверняка программеры, которых задело "за живое", которые себя узнали. Я похвалю, потому что читал статью как пользователь. Точнее не пользователь, пользователи в организациях сами с кривыми программами не борятся, они сразу к автоматизаторм обращаются, когда программа ведет себя неадекватно (выдает неожиданно непредсказуемый результат) в ответ на введеную информацию, характер которой не был предусмотрен программистом.
Когда я хотел поднять аналогичную тему, то думал о чуть другом, а именно не о том, что в программе не предусмотрена реакция на "внештатные" данные и результат ее неадекватен, а о скорости ее реакции. Порой программы слишком "тормозные", причем настолько, что это шокирует. Чаще всего я сталкивался с тормознутостью экономическими баз данных.
Я когда-то школьникам рассказывал - Соверменный процессор действительно может выполнять около двух простых арифметических операций за один такт, то есть 500Мгц проц может сложить 1000000000 чисел в секунду! Если записать эти числа в столбик, то высота этого столбика получится 10000000 метров или 10 тысяч километров, если число будет примерно сантиметровой величины. Сколько нужно человеку времени, чтобы проделать такое вычисление даже если он будет вооружен калькулятором? Так вот решение на таком компьютере определенных экономических задач занимает от нескольких десятков минут до нескольких часов времени в зависимости от разработчика ПО и загруженности базы. Я уверен, что вооружившись калькулятором, я бы обогнал компьютер, хотя комп должен был бы решить эту задачу за микросекунду. Как программерам удается писать такие тормозные программы?
|
| |
Абсолютно согласен. Но у меня даже желание как-то слабо выражалось. В действительности тема хороша, но реализация заставляет рыдать (. Чего стоит, уже разчавканный в комментах "пример про среднее". Суть: плохо плохо писать о плохом ;) 23.08.07 20:54
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | |
Ну не стОит так драматизаровать. Мне думается, что не взирая... 24.08.07 12:05
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 24.08.07 12:06 Количество правок: 1
|
Ну не стОит так драматизаровать. Мне думается, что не взирая на количество любых комментариев, как минимум один из трех задумается и сделает выводы, а это не так уж и мало в рядах программеров зоны ".ru".
Я, признаюсь, как то давно книжку купил, в которой описывались и "правила хорошего тона", и предостережения от ошибок, связанных со стилем, и аргументированно, хотя и не навязчиво объяснялось почему нужно именно так или подобным образом, а другим не следует. Ну приведу самый из "детских" примеров: "Нужно быть осторожнее с классами, одним из свойств которых является указатель, особенно на динамически выделяемую память. Нужно обязательно не забыть реализовать и оператор присваивания, и иницилизацию объектом этого же класса и ...". Книжка не с собой, ее реквизиты потом могу сюда вписать.
Сам за собой не уследишь, надо у юзеров спросить - сколько раз за последний год я горорил "Тем, кто писал эту программу, надо руки поотрубать", "Вешать надо таких программеров за ноги", а бывает и другая любимая фраза "Таким гениям нужно памятник при жизни ставить". Что поделать, без некоторых программ никуда, некоторые навязывают использовать без возможности выбора альтернатив, вот и приходится всеми правдами и неправдами биться с "ветрянными мельницами" и плясать с бубнами, чтоб заставить какую-то прогу работать. Пользователь то он в программировании не рубит, а для руководителя чем программа жирнее и дольше думает, тем она круче, дороже, ценнее. Когда же сам такое видишь, то стыдно немного становится, за людей, которые, видимо, не своим делом занимаются. Давайте писать красиво, во всех отношениях. Давайте писать качественно, на совесть. Давайте думать о тех, кто потом будет использовать эту программу.
|
|
*****!!! 23.08.07 05:54 [DamNet, Heller]
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
| |
А можно подробнее? 23.08.07 16:47
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| | |
5 респектов. 24.08.07 03:39
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
| | |
Мат на форуме запрещен ). Имхо - у хороших авторов есть читатели, а у плохих - комментаторы. (т.е. кол-во сообщений кроме короткого "спасибо!" прямопропорционально кривизне статьи) 23.08.07 20:51
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | | |
С имхо - полностью не согласен. Коротко и красиво ответить не смогу, поэтому рекомендую почитать АБС "Хромая судьба". Там этот вопрос подробно рассмотрен. Там где про Сорокина 24.08.07 17:03
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| | | | |
Не согласен с несогласием ) Почитай Сократа. Тот поди постарше будет. И признан до сих пор. 15.09.07 20:38
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
| | | | | |
Не согласен с Сократом. Он Стругацких не читал. :)) Опять же, кто сказал, что Сократ умнее каждого из нас? ;) 16.09.07 00:10
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| |
лаконично и понятно 23.08.07 07:38
Автор: kstati <Евгений Борисов> Статус: Elderman
|
|
|
|
[off] Очень понравилось предложение "Компиляция порождала примерно 10 файлов: 6 EXE и 4 DLL." 22.08.07 20:27
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 23.08.07 12:14 Количество правок: 1
|
|
|
|
Ну просто отлично. Я в шоке 22.08.07 18:49
Автор: smartov Статус: Незарегистрированный пользователь
|
Ну просто отлично. Я в шоке
>>int avg(int a, int b) { return a + (b - a) / 2; }
С каких пор int при делении на 2 стал на результате всегда выдавать int. Или средним арифметическим из 1 и 2 является int? О каких чужих ошибках мы тут говорим, когда свои не видим, еще и других пытаемся учить.
Более того, вместо того, чтобы не морочить себе и читателям голову с кучей условий
float my_avg(float a, float b) { return a/2 + b/2; }
и все! Никаких 28 условий! Никакого переполнения.
Статье незачет.
|
| |
Я бы вам не доверил реализацию двоичного поиска, например -... 22.08.07 19:51
Автор: crontab Статус: Незарегистрированный пользователь
|
> float my_avg(float a, float b) { return a/2 + b/2; }
Я бы вам не доверил реализацию двоичного поиска, например - а там как раз нужно постоянно вычислять среднее двух индексов. a/2 + b/2 - это было бы катастрофой для алгоритма, который должен быть очень быстрым. А надо бы представлять вообще во что это компилируется. Незачет :)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
