Статья от Ms-Rem`a, но почему то совсем недавно запостили на Interface

вот статья
Дата публикации: 16.06.2007

Довольно познавательная статья, спасибо Ms-Rem,где бы ты не был!

 

EvilsInterrupt

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

 

Код (Text):

1. Дельфи как был недоязыком, так им и остается.

Также как и С++, только в отличии от Delphi имеет меньше возможность по разработке наглядного кода. Щас вот думаю стоит ли изучать еще и C#, туда все умные идеи от других языков стекаются, только одно бесит с кроссплатформенностью у него плохо.

Единственное, что меня бесит в дельфи так это begin - end, за место кратких и лаконичных си-шных { }. На С++ я писал:

object.SetParameter(index, value[index]);

на дельфи я пишу код:

object.Parameter[index].value := Value[index];

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

из удобств что жутко нравится:

Код (Text):

1.   private
2.     { Private declarations }
3.     FObjectNumber : Cardinal;
4.  
5.   published
6.     { Published declarations }
7.     property      ObjectNumber : Cardinal  read FObjectNumber write SetObjNum;

а при использовании:

object.ObjectNumber := новое значение
или
куда надо := object.ObjectNumber;

в с++ я бы писал мало удобное:

куда нада := object.GetObjectNumber;
или
object.SetObjectNumber(новое значение);

мы с ребятами на работе, даже соревнование устраивали, писали каждый проекты на С++, потом на дельфи, потом на Java и через 2 месяца сами же пытались понять чтоже на программили. Но мы были жутко удивлены, т.к. кантора писала на Builder C++ 6.0 а получилось так, что сумели быстрее разобраться в коде написанном на дельфи.

С одним моим коллегой, так ваще курьез вышел, его прога глюкнула ночью, данных по Технико-экономическим показателям небыло и т.к. на ТЭЦ, то надо бегом приехать\разобраться\ поправить багу. Он искал ее 2 часа, за это время ему диспетчер весь мозг отрахал ))).

Щас делаем проще, думаем и если какая то часть повторяется, то выносим ее в компоненты, применяем компоненты и дельфи. Багов стало меньше, поиск все же просочившихся багов происходит быстрее. Поначалу выносили в dll, но начало получаться что появлялось очень много dll, а каждая из них начала разница в версиях - у одной проги одна версия, у другой с новой фичей. Потом начали путаться, где и какую версию лучше юзать. Вобщем пришли к выводу, что компоненты лучше.

Но системные вещи, мне на дельфи писать не удобно, потому пишу на ассемблере fasm. Но С++ я оставил на свалке истории, до тех пор пока не придумают средства по улучшению наглядности кода, то не вернусь. Но это врядли произойдет, ибо MS кидает все силы на поддержку C# ибо правильный язык, в нем многие вещи даже удобней чем на Delphi.

 

(с) ЖУРНАЛ ХАКЕР #80, АВГУСТ 2005

 

yuzvir
Нет но меня прикольнуло, почему же такой поп-ресурс запостила статью 2005 года?? )))

 

EvilsInterrupt, к сожалению, статья старая - из Х**ера, #80

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

Идея переписать рантайм, увы, не нова - просвящённые давно ей пользуются.

А по поводу производительности в ущерб надёжности - тут ассемблер вообще чемпион. О ужас, там же нет контроля стэка! И типы тоже не проверяются! ААААА! Кошмар!


upd: пока писал, опередили с ответом… =)

 

я отказался от использования дельфи, теперь только Си %)

 

При всём уважении к MsRem, его аргументы против ООП необоснованы, IMHO.
ООП-код по эффективности (т.е. размеру и скорости) не уступает (и даже превосходит) "процедурный". Если, конечно, писать, "чувствуя" компилятор (т.е. представляя, во что он превратит написанное).

Более того, в большинстве сишных проектов наблюдается попытка изобрести что-то вроде самопального ООП (пачки ф-ций, берущие указателель на одну и ту же структуру, таблицы указателей на такие ф-ции). Именования вроде Entity_Subentity..._DoSomething(), и т.п.

 

Статья хорошая. Но в ней нет ничего нового. Да и сома статья старая.
А так могу сказать, что можно написать маленькую утилиту для переделки PE файла под драйвер или другую ОС. А можно и самим ОС на дельфи написать.

То что дельфи это не до язык я не соглашусь. На нем можно сделать все, что и на СИ. Да нет там шаблонов, а перегруженные операторы появились в 2006. В Си есть свои недостатки и все об этом знают. Холи вар разводить не буду.

 

Pavia
Такие темы надо разводить, потому что всегда можно узнать, то что раньше не знал, т.к. фразы: "А на с++ так вот можно (описание фичи)", потому что книг море, а времени мало. ИТ-сфера развивается динамично и следовательно нужно средство которое бы дало краткий обзор и в тоже время несла элемент обучения, так почему бы не темы подобной этой. Ведь кто-то обязательно напишет что нить про свое средство, быть может кому-то из новичков это позволит быстрее изучить средство

 

EvilsInterrupt

Просто без комментариев, потому что если я прокомментирую твой пост, меня скорее всего забанят))))

 

_DEN_
Нет Ден, я че против? Ты главное аргумент приводи, типа пишем на дельфи так, а на си так и показывай удобство. Где это можно применить, в чем выгода и т.д) Кто знает, может я от тебя узнаю то, что раньше не знал и что позволит устранить мои текущие проблемы!

А это:
1. Возможность написания кода по работе с СУБД Oracle и чтобы код был настолько наглядный, что через неделю или отпуска суметь в этом коде разобраться не больше чем за пол-часа

позже еще одну задачку опишу, чтобы ты попробовал на си ее сделать или своем средстве

 

EvilsInterrupt

Известный факт: на С++ и С писать быстрее чем на Delphi и паскале, зато разбирать код наоборот.

Как я понимаю тебе нехватает свойств в С++. Но у MS С++ есть такое расширение, у борланда тоже вроде должно.
А как же перегрузка операторов (хотя вроде говорят появилась), шаблоны, STL? Мне без них плохо, а не без свойств.
Но много чего конечно и нехватает, но всё же у С++, С#, Delphi, ассемблера несколько разные ниши.

Ты так уверен в этом? MS и бейсик толкает. С# могуч в рантайме, но из-за этого есть и минусы (производительность например). Множественного наследования нету, друзей тоже, локальных статических переменных, хотя и плюсов дофига.

http://www.osp.ru/os/2004/07/184985/

З.Ы. Больше HollyWar тоже не буду разводить, все языки хороши для своих ниш.
Да самый большой плюс С# - Net Framework, но это не плюс языка, а плюс библиотеки.

 

жж0те не по-детски ребята, аж прослезился.

 

EvilsInterrupt
Вообще, не понимаю в чём проблема - не ленись комментировать код)

 

UbIvItS
В аттаче исходный код, хорошего программера и с комментарием!!!

 

EvilsInterrupt

Особо не вникал, но осмелюсь покритиковать.
Код действительно трудночитаем, но не вследствие плохого синтаксиса языка.
IMHO, главный минус - недостаточная структурированность.
1. не разделёны логический и интерфейсный код.
2. даже декомпозиция Button1Click() на ф-ции типа CheckTemperature, CheckPressure и т.п. существенно улучшила бы дело.
3. много hardcoded строк.
4. много повторяющегося кода.

 

green
Это человек, который хорошо шарит в автоматизации, неплохой менеджер. Писал программы на ассемблере под Dos, На С под этот Builder C++ 6.0. Программить умеет, а вот оформлять нет. Оформление кода - это замечу 50% успеха проекта!

 

Главное не комментарий, а проектирование. Иерархия классов и т.д. Назначение и работа компонентов должна быть прозрачна. Не зря по этому поводу писаны книги типа "Шаблоны проектирования". Язык только помогает правильно сделать, но всё в руках программера.

 

Booster
В точку!
Именна эта мысль меня посетила в прошлом году и я подсел на системный анализ, вещь занимательная, позволяет дисциплинировать самого себя.
После того, как я начал читать книги по UML от "великой тройки" я понял, что я программить вообще не умею.