Форум программистов, компьютерный форум, киберфорум
Священные войны
Войти
Регистрация
Восстановить пароль
 
 
Рейтинг 4.63/16: Рейтинг темы: голосов - 16, средняя оценка - 4.63
Заблокирован
1

Delphi vs All

30.10.2012, 19:09. Показов 2961. Ответов 39
Метки нет (Все метки)

Доброе время суток.
У Delphi, немало недостатков. Например, невероятная глючность, и IDE, и сам язык и получившиеся программы, постоянно выкидывают какие-нибудь коленца, причем совершенно непредсказуемые.
Но! У Delphi есть преимущество: она предоставляет пользователю готовый набор компонент, в то время как написание проекта на "более серьезных языках", напоминает то, как если бы вы строили дом и сами бы делали кирпичи, вырезали оконные рамы, дули бы стекла для окон и так далее.
0
Programming
Эксперт
94731 / 64177 / 26122
Регистрация: 12.04.2006
Сообщений: 116,782
30.10.2012, 19:09
Ответы с готовыми решениями:

Что лучше брать Delphi XE2, Delphi XE, Delphi 7?
Привет форумчане! У меня вопрос: что лучше брать Delphi XE2, Delphi XE, Delphi 7? Как вообще...

Какие отличия Delphi 5, Delphi 6 и Delphi 7
Кто-нибудь юзал Delphi 6? Если да, то напишите, плиз, его отличия от 5-ой версии (плюсы и минусы)...

ZipForge для Delphi Xe - интерфейс стал выглядеть как в Delphi 2007
Народ!!! Помоготи!!! Установил компонент ZipForge для Delphi Xe и после этого интерфейс моей...

Как в Lazarus сделать интерфейс Delphi 2006 вместо Delphi 7?
Добрый вечер! Подскажите пожалуйста, как в Lazarus сделать интерфейс Delphi 2006 вместо Delphi 7?...

__________________
39
201 / 19 / 5
Регистрация: 27.08.2012
Сообщений: 805
30.10.2012, 19:27 2
Цитата Сообщение от доктор Брейн Посмотреть сообщение
У Delphi есть преимущество: она предоставляет пользователю готовый набор компонент
Ну я думаю, у шарпа выбор всяких компонентов будет по больше. Хотя не суть.
Думаю, вам интересно будет посмотреть эту тему - Delphi умер?
0
6000 / 2123 / 740
Регистрация: 10.12.2010
Сообщений: 5,959
Записей в блоге: 3
30.10.2012, 20:33 3
доктор Брейн, вы знаете, вот уже 7 лет на Делфи пишу, и ни разу не встречал ни одного описанного вами недостатка.

Не по теме:

Косяки того, кто кодит не в счет.

0
Заблокирован
31.10.2012, 00:22  [ТС] 4
Цитата Сообщение от HighPredator Посмотреть сообщение
доктор Брейн, вы знаете, вот уже 7 лет на Делфи пишу, и ни разу не встречал ни одного описанного вами недостатка.
Угу. Вот пример типичной программы на Delphi:
И после этого, вы говорите мне, что Delphi не глючная?
0
1561 / 1039 / 93
Регистрация: 17.04.2009
Сообщений: 2,995
31.10.2012, 12:50 5
Это типичная статья лурка, а не обычная программа на delphi
0
4197 / 1789 / 211
Регистрация: 24.11.2009
Сообщений: 27,563
31.10.2012, 16:20 6
Цитата Сообщение от доктор Брейн Посмотреть сообщение
Доброе время суток.
У Delphi, немало недостатков. Например, невероятная глючность, и IDE, и сам язык и получившиеся программы, постоянно выкидывают какие-нибудь коленца, причем совершенно непредсказуемые.
Но! У Delphi есть преимущество: она предоставляет пользователю готовый набор компонент, в то время как написание проекта на "более серьезных языках", напоминает то, как если бы вы строили дом и сами бы делали кирпичи, вырезали оконные рамы, дули бы стекла для окон и так далее.
На плюсах есть те же самые компоненты. Изготовление кирпичей? Если вдруг нет готового компонента, то программирование в делфях напоминает перепиливание брёвен на кирпичи при строительстве домны. Разумеется, деревянные кирпичи вместо шамотных сгорят, набор же компонентов минималистичен до безобразия. А на плюсах всё можно сделать, начиная с API, он универсально, но столь же минималистичен, а потому не требует веков на свое изучение перед началом программирования, как было бы, если раздуть vcl до такой же универсальности. Да и ни на один винт не влезет среда с таким vcl. Когда бороться с библиотекой не надо, то и в делфях можно писать вполне серьёзный софт, но бывает это не всегда, сказывается ограниченность библиотеки. Глюки же происходят от кривых рук прикладного программиста: даже если глючит прога, скомпиленная глючным компилятором, программист - не простой юзверь, он должен знать реализацию языка и именно он виноват в глюках, в том, что ошибочно не учёл ошибку в компиляторе. На турбопаскале, например, есть такой глюк: тип параметра-массива нельзя описывать в декларации самого параметра, а надо описать заранее, дать ему имя, а в декларации параметра это имя использовать. Глюк. Но про него надо просто знать и учитывать. И в приладе ни каких глюков не будет.
0
Эксперт Python
4453 / 1887 / 343
Регистрация: 17.03.2012
Сообщений: 9,700
Записей в блоге: 5
31.10.2012, 16:58 7
Присоединяюсь, вам сюда: Delphi умер?
Насчет того, что под Delphi, якобы, есть компоненты - предлагаю вам посчитать вот тут http://en.wikipedia.org/wiki/L... _libraries сколько есть математических библиотек под Delphi и сравнить их число с тем же под С++\С#\Java.
Это я еще не касаюсь вопроса переносимости компонентов между версиями Delphi, которая, традиционно, хреновая.

Добавлено через 7 минут
Цитата Сообщение от taras atavin Посмотреть сообщение
он должен знать реализацию языка и именно он виноват в глюках, в том, что ошибочно не учёл ошибку в компиляторе.
Фигасе логика.
0
4197 / 1789 / 211
Регистрация: 24.11.2009
Сообщений: 27,563
31.10.2012, 17:00 8
Нормальная логика. Глючный компил глючит в кривых руках, руки профессиогнала должны быть прямыми.
0
Каратель
Эксперт С++
6598 / 4017 / 401
Регистрация: 26.03.2010
Сообщений: 9,273
Записей в блоге: 1
31.10.2012, 17:04 9
Цитата Сообщение от доктор Брейн Посмотреть сообщение
о! У Delphi есть преимущество: она предоставляет пользователю готовый набор компонент, в то время как написание проекта на "более серьезных языках", напоминает то, как если бы вы строили дом и сами бы делали кирпичи, вырезали оконные рамы, дули бы стекла для окон и так далее.
да ладно! вы просто не писали на "более серьезных языках"
0
Эксперт Python
4453 / 1887 / 343
Регистрация: 17.03.2012
Сообщений: 9,700
Записей в блоге: 5
31.10.2012, 17:05 10
Цитата Сообщение от taras atavin Посмотреть сообщение
Нормальная логика.
Кэп говорит, что в глюках в компиляторе виноват писатель компилятора.
Программисту учитывать, конечно, надо, но это повод сказать справедливое "фи" на такой компилятор. Что я и делаю.

Цитата Сообщение от taras atavin Посмотреть сообщение
Глючный компил глючит в кривых руках, руки профессиогнала должны быть прямыми.
У программиста руки должны иметь обратную кривизну строго комплиментарной формы.
0
4197 / 1789 / 211
Регистрация: 24.11.2009
Сообщений: 27,563
01.11.2012, 10:56 11
Ты можешь выбрать другой компилятор, но если ты выбрал глючный, то именно ты и будешь виноват в глюках уже твоего приложения. Даже если они вытекли из ошибок в компиляторе. Потому что разработчик приложения обязан или знать все глюки компилятора заранее, или найти при тестах те из низ, которые влияют на его приложение и о которых он не знал. А если не знал и не нашёл - это ошибки уже в прикладной программе. Её можно написать без глюков и с таким компилятором, если этого не сделано, виноват её разработчик. Разработчик глючного компилятора будет виноват только в том, что из-за этих глюков выбран другой компилятор. К не профессиональным пользователям соображение о том, что если при правильном глюков бы не было, то в глюках виноват пользователь не относится, к профессиональным относится, к программистам относится всегда. Если ты программист, но начинающий, то ты учишься программировать, а процесс обучения программированию в обязательном порядке включает и обучение поиску и исправлению ошибок. Не научился? Мучай прогу дальше, пока не научишься. Разница же в том, что пользователь-не профессионал не обязан знать, как приложением, драйверами и операционной системой пользоваться правильно, а пользователь-профессионал обязан это знать, а программист обязан знать, как пользоваться средой разработки и компилятором.

Добавлено через 2 минуты
А если приладу вообще нельзя скомпилить без глюков некоторым компилятором, то её, а не компилятора, разработчик виноват уже в том, что не правильно выбрал компилятор. И всё равно он виноват в глюках прилады.

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

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

Добавлено через 5 минут
Я могу, разрабатывая модель АКОС для завода, вписать в инструкцию: "ячейки должны иметь большой объём, а их общее количество не может превышать 17000" и успокоиться, а в проге проверку на количество ячеек не предусматривать. Дурак-сталевар, или дурак-АСУшник ввёл такие размеры ячеек, что они получились по микролитру, а прога в результате сглючила? Надо было читать инструкцию, там это предусмотрено. Но если та же прога написана для установки дома и ознакомления детей с АКОСом, то мой конечный пользователь не обязан даже понимать подобные фразы в инструкциях и если при таком же вводе прога сглючила, то виноват буду уже я.

Добавлено через 8 минут
С другой стороны, если моя прога по АКОСу не способна вообще правильно считать свободную конвекцию (так и есть), а только свободно-вынужденную и в чистом виде вынужденную и при обнулении продувки и тока глючит, то именно я был бы виноват в этих глюках, не придусмотрев проверку на два ноля в исходных данных, уже не зависимо от назначения проги. Разработчик же компилятора может оставить функцию strtofloat, которая будет глючить всегда, но дополнить функцией strtofloatdef, которая глючить не будет и в глюках будет не виноват.

Добавлено через 8 минут
Если же надо бросать исключения на невалидную строку, обрабатывать их и выдавать пользователю сообщение о невалидном вводе, то постоянные глюки одной функции обходятся как минимум тремя путями:
1. Написать свою функцию, которая будет глючить только на не валидных строках.
2. Выполнить обратное преобразование и сравнить полученную строку с исходной.
3. Написать свою функцию проверки строки без возврата числа.
Глюк будет обойдён (если бы он был, в делфях эта функция на валидных строках не глючит), а задача, для которой глючная функция предназначалась будет решена другим путём.
0
Эксперт Python
4453 / 1887 / 343
Регистрация: 17.03.2012
Сообщений: 9,700
Записей в блоге: 5
01.11.2012, 10:59 12
Цитата Сообщение от taras atavin Посмотреть сообщение
Ты можешь выбрать другой компилятор
Тут зависит от обстоятельств. Далеко не всегда.

По остальному - в общем верно, что кагбэ не отменяет того факта, что глючный продукт - глючный, и виноват в этом тот, кто его написал.

Что до общего рассуждения о "прямых руках" - после вашего заявления о допустимости глобальных переменных, и о том, что "принципы не гибки", после вашего поста, в котором вы обнаружили непонимание ООП ( Немного о глобальных переменных ) - ну как-то не верится мне, что вы можете рассуждать о "прямых руках", и серьезно относиться к вашим остальным рассуждениям тоже не получается. Sorry.
0
4197 / 1789 / 211
Регистрация: 24.11.2009
Сообщений: 27,563
01.11.2012, 11:34 13
Вопрос о том, чьи именно кривые виноваты в глюках сводится к вопросам о том, должен ли пользователь глючной проги обладать специальными знаниями и можно ли при их наличии гарантированно избежать глюков. При утвердительном ответе на оба виноват пользователь, иначе непосредственный разработчик. Разработчик программ любых классов сам является пользователем инструментальных программ, но знания языков программирования и средств разработки программ являются специальными и в случае разработчика программ к способам избегания глюков можно отнести в том числе выбор других средств разработки.

Добавлено через 13 минут
Цитата Сообщение от dondublon Посмотреть сообщение
после вашего поста, в котором вы обнаружили непонимание ООП
Какое вообще область видимости переменных имеет отношение к парадигмам? Переменные ведь можно заводить в любой парадигме и даже при программировании на ассемблере, в числовых кодах и путём перетыкания штекеров, как на ЭНИАКЕ. И в любом случае может существовать понятие области видимости. Так что подобные заявления показывают, что именно ты далёк даже от начала изучения принципов ООП, так как вообще не понимаешь самого понятия парадигмы. Теперь поводу глобальных переменных. Мне однажды пришлось вынести в глобал локальную по смыслу задачи переменную ради экономии стека, пока она была локальной, стек переполнялся при первом же вызове, но существовала она в единственном экземпляре, освобождение занимаемой ею памяти до завершения всей программы было не критично, а в сравнении с динамическим данным перенос в глобал всё таки проще. А ты бы со своими принципами упёрся в то, что данное описано в подзадаче и должно храниться в локальной переменной и в то, что так как данное необходимо в течении всего времени работы подпрограммы, то хранить её в динамической переменной тоже нельзя, в итоге завалил бы проект. Кстати, была использована не объектно-ориентированная, а процедурная парадигма. Объект же по смыслу задачи был один, на меньшие объекты не делился и процедурная парадигма была выбрана обоснованно.

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

Добавлено через 8 минут
Выбор области видимости на самом деле диктуется совсем другим принципом:
Не увеличивай сложность без необходимости.
, а не
Избегай глобальных переменных.
0
Эксперт Python
4453 / 1887 / 343
Регистрация: 17.03.2012
Сообщений: 9,700
Записей в блоге: 5
01.11.2012, 11:40 14
Цитата Сообщение от taras atavin Посмотреть сообщение
Какое вообще область видимости переменных имеет отношение к парадигмам?
Эх, как бы вам сказать потактичнее. Самое непосредственное. Один из трёх столпов ООП придумали как раз, чтобы уйти от определенной области видимости, а именно - от глобальной.

Цитата Сообщение от taras atavin Посмотреть сообщение
Переменные ведь можно заводить в любой парадигме и даже при программировании на ассемблере
Эх, как бы сказать помягче... Чистое функциональное программирование (тоже парадигма) не предполагает переменных (именно переменных в программистском смысле) вообще. Оно дальше от железа, чем ООП, а асм - ближе, так что слово "даже" тут неуместно.

Цитата Сообщение от taras atavin Посмотреть сообщение
Так что подобные заявления показывают, что именно ты далёк даже от начала изучения принципов ООП, так как вообще не понимаешь самого понятия парадигмы.
Ответ от балды.

Цитата Сообщение от taras atavin Посмотреть сообщение
Мне однажды пришлось вынести в глобал локальную по смыслу задачи переменную ради экономии стека
Выделил ключевое слово.
0
4197 / 1789 / 211
Регистрация: 24.11.2009
Сообщений: 27,563
01.11.2012, 11:46 15
С парадигмой область видимости не связана вовсе. При программировании паяльником и штекерами локальную область видимости можно реализовать локальным устройством памяти отдельного вычислителя для конкретной подзадачи, а язык высокого уровня, или его диалект может не предусматривать локальных данных.
0
Эксперт Python
4453 / 1887 / 343
Регистрация: 17.03.2012
Сообщений: 9,700
Записей в блоге: 5
01.11.2012, 11:50 16
Цитата Сообщение от taras atavin Посмотреть сообщение
С парадигмой область видимости не связана вовсе. При программировании паяльником и штекерами локальную область видимости можно реализовать локальным устройством памяти отдельного вычислителя для конкретной подзадачи, а язык высокого уровня, или его диалект может не предусматривать локальных данных.
Резюме: некоторые парадигмы допускают глобалки, а некоторые только глобалки и допускают.
Каким образом из этого следует, что понятие парадигмы не связано с областью видимости?
0
4197 / 1789 / 211
Регистрация: 24.11.2009
Сообщений: 27,563
01.11.2012, 12:00 17
Цитата Сообщение от dondublon Посмотреть сообщение
Один из трёх столпов ООП придумали как раз, чтобы уйти от определенной области
Это какой? Их всего то три:
1. Инкапсуляция.
2. Полиморфизм.
3. Наследование.
Инкапсуляции - это прежде всего сокрытие кода внутри типа и относится к дальнейшему развитию идеи декомпозиции, а локальные подпрограммы внутри других подпрограмм были в процедурной парадигме. Ничего общего с областью видимости. Можно прятать и данные, это тоже будет инкапсуляция, но не доступные данные лишены смыла, а без кода данные не доступны. Так что без инкапсуляции кода нет инкапсуляции вообще. Полиморфизм - это изменение поведения при сохранении интерфейса в зависимости от фактического типа. Опять не то. Наследование есть сохранение интерфейса предка классом-потомком. Опять мимо. Область же видимости есть зависимость доступности сущности от места в программе, где пытаешься её использовать. Ни чего общего с декомпозицией на основе типов данных. Место в тексте и тип данных - разные признаки управления видимостью, а не один, сходство здесь только по форме.

Добавлено через 1 минуту
Цитата Сообщение от dondublon Посмотреть сообщение
некоторые только глобалки и допускают.
Назови хотя бы одну именно парадигму, а не язык, не допускающую локальных данных.

Добавлено через 4 минуты
Подсказка № 1: в функциональном программировании функции понимаются также, как в математики, что проводит в эту парадигму локальные данные через понятие сложных функций.
Подсказка № 2: при декларативном программировании описываются задачи, а одна задача может быть частью другой, что протаскивает в данную парадигму локальные данные через понятие подзадачи.
И отдельный вычислитель для подзадачи я уже упоминал, он протаскивает локальную область видимости и в низкоуровневое программирование. Размести переменную в локальной памяти такого вычислителя и она будет локальной на низком уровне.
0
Эксперт Python
4453 / 1887 / 343
Регистрация: 17.03.2012
Сообщений: 9,700
Записей в блоге: 5
01.11.2012, 12:04 18
Цитата Сообщение от taras atavin Посмотреть сообщение
Это какой? Их всего то три:
Инкапсуляция.

Цитата Сообщение от taras atavin Посмотреть сообщение
Инкапсуляции - это прежде всего сокрытие кода внутри типа
Не только кода, но и переменных.

Цитата Сообщение от taras atavin Посмотреть сообщение
Ничего общего с областью видимости.
Кто бы мог подумать! Не, ну правда Значит, прятать что-то внутри чего-то - это к области видимости отношения не имеет. А я-то думал...

Цитата Сообщение от taras atavin Посмотреть сообщение
Назови хотя бы одну именно парадигму, а не язык, не допускающую локальных данных.
Нет уж. Ты сделал умозаключение ("понятие парадигмы не имеют отношения к области видимости"), я попросил его вывод (как оно получилось). Так что давай, отвечай за базар, в сторону не уходи.

Добавлено через 58 секунд
Цитата Сообщение от taras atavin Посмотреть сообщение
в функциональном программировании функции понимаются также, как в математики, что проводит в эту парадигму локальные данные
Путаем данные и переменные?
0
4197 / 1789 / 211
Регистрация: 24.11.2009
Сообщений: 27,563
01.11.2012, 12:11 19
Кстати, если уж до конца следовать ООП, то всякое изменяемое данное, имеющее смысл во всей задаче должно храниться именно в глобальной переменной, как вариант - в глобальном экземпляре некоторого класса, то есть в глобальном объекте.

Добавлено через 3 минуты
Цитата Сообщение от dondublon Посмотреть сообщение
Путаем данные и переменные?
Нет. Но изменяемость, или не изменяемость данного ни как не связана с тем, в какой части задачи оно описано, а изменяемое локальное должно храниться в локальной переменной, так как локальные константы для этого не пригодны, глобал - это уже другая область видимости, а ни каких других видов данных языки программирования вообще не понимают.

Добавлено через 2 минуты
Цитата Сообщение от dondublon Посмотреть сообщение
Нет уж. Ты сделал умозаключение ("понятие парадигмы не имеют отношения к области видимости"), я попросил его вывод (как оно получилось). Так что давай, отвечай за базар, в сторону не уходи.
Сам не уходи. Количество существующих на данный момент и известных человечеству парадигм ограничено, что делает допустимой логическую индукцию. Моё умозаключение индуктивно, ты его не принимаешь, а опровергать отказываешься. Заметь: о не возможности парадигм, исключающих локальные переменные у меня ни слова, только о том, что их нет в действительности.
0
Эксперт Python
4453 / 1887 / 343
Регистрация: 17.03.2012
Сообщений: 9,700
Записей в блоге: 5
01.11.2012, 12:12 20
Цитата Сообщение от taras atavin Посмотреть сообщение
Кстати, если уж до конца следовать ООП, то всякое изменяемое данное, имеющее смысл во всей задаче должно храниться именно в глобальной переменной, как вариант - в глобальном экземпляре некоторого класса, то есть в глобальном объекте.
С чего бы?
0
IT_Exp
Эксперт
87844 / 49110 / 22898
Регистрация: 17.06.2006
Сообщений: 92,604
01.11.2012, 12:12

Заказываю контрольные, курсовые, дипломные работы и диссертации здесь.

SQL-запрос в Delphi и в Access один и тот же, но в Delphi не работает
ри обращение к базе в Access я использую код: with ADOQueryMain do begin Active:=false;...

где найти delphi c компилятором? и с чего начинать программирование в delphi?
здравствуйте, вот начинаю изучать delphi с чего начинать лучше?

Переписать часть кода с Delphi на ассемблер (ассемблерные вставки в Delphi)
Добрый вечер. Нужно сделать ассемблерные вставки в программе. Первый раз столкнулся с таким...

Почему функция работающая в Delphi 7 не работает в Delphi 2007 и в 2009 ??
Данный код работал нормально в D7: procedure TForm1.Button1Click(Sender: TObject); begin...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Опции темы

КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin® Version 3.8.9
Copyright ©2000 - 2021, vBulletin Solutions, Inc.