Delphi и велосипедирование

[Drouge]

Я программист не очень профессиональный, знаю только Delphi, но нашёл себе нишу, в которой востребована креативность. И создалось ощущение, что мой стиль программирования вообще относительно часто принят у дельфистов. Грубо говоря, под C++ написано много библиотек, а под Delphi мало, и это убивает Delphi; с другой стороны, Delphi в целом более правильный и удобный ЯП, позволяющий писать сложные алгоритмы с меньшим количеством ошибок. Отсюда предположение, что сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее; а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое. У меня это выражено в крайней степени.
Кажется на форуме нет опции спойлера? А то я бы привёл свой пример - алгоритм быстрой сортировки. Есть известный стандартный алгоритм, но я о нём не знал и сделал свой велосипед. Мой алгоритм больше по размеру, примерно в три раза медленнее и требует больше памяти, но мне кажется он по многим параметрам всё-таки предпочтительнее, поскольку более понятен.

[p51x]

Сообщение от Drouge

Грубо говоря, под C++ написано много библиотек

Может потому что его используют много где?

Сообщение от Drouge

а под Delphi мало

Чего вам не хватает под Delphi?

Сообщение от Drouge

с другой стороны, Delphi в целом более правильный и удобный ЯП

Критерии правильности и удобства назовите? А то некоторые функциональщики с вами поспорят.

Сообщение от Drouge

позволяющий писать сложные алгоритмы с меньшим количеством ошибок

Может, потому что он произошел из паскаля, который делали для обучения программированию?

Сообщение от Drouge

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

Indy навелосипедьте, не?

Сообщение от Drouge

Есть известный стандартный алгоритм, но я о нём не знал и сделал свой велосипед.

А зря. Обычно сначала люди учатся на опыте других... а потом уже велосипедят.

Сообщение от Drouge

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

Предпочтительней? У вас алгоритм проиграл по всем параметрам, которые важны..

[DeepFlake]

сишниками становятся программисты, которым проще найти библиотеки, изучить документацию и так далее; а дельфистами становятся те, кому проще изобрести велосипед а не искать готовое

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

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

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

[Drouge]

Мой велосипедный код типа быстрой сортировки. Длинный и медленный, но как мне кажется понятный:

procedure TDoubleArray.QSort1Old;
var
q:integer;
sumval, midval, tmpval: double;
tmparray1, tmparray2: tdoublearray;
begin
if count<=1 then exit;
if count=2 then begin
if fitems[1]<fitems[0] then begin tmpval:=fitems[1]; fitems[1]:=fitems[0]; fitems[0]:=tmpval; end;
exit;
end;
sumval:=0;
for q:=0 to count-1 do sumval:=sumval+fitems[q];
midval:=sumval/count;
tmparray1:=tdoublearray.create;
tmparray1.capacity:=count;
tmparray2:=tdoublearray.create;
tmparray2.capacity:=count;
for q:=0 to count-1 do if fitems[q]>midval then tmparray2.add(fitems[q]) else tmparray1.add(fitems[q]);
if tmparray1.Count=0 then begin tmparray1.free; tmparray2.free; exit; end;
if tmparray2.Count=0 then begin tmparray1.free; tmparray2.free; exit; end;
tmparray1.QSort1Old;
tmparray2.QSort1Old;
for q:=0 to tmparray1.count-1 do fitems[q]:=tmparray1.fitems[q];
for q:=0 to tmparray2.count-1 do fitems[tmparray1.count+q]:=tmparray2.fitems[q];
tmparray1.free;
tmparray2.free;
end;

[Drouge]

Сообщение от p51x

Предпочтительней? У вас алгоритм проиграл по всем параметрам, которые важны..

Вам он не кажется вполне понятным, в отличие от стандартного алгоритма быстрой сортировки?

[pu4koff]

Сообщение от Drouge

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

20 лет назад, когда я учил Delphi, сишники стебали разработчиков на этом языке именно за то, что для решения любой задачи делфисты искали готовый компонент, чтобы кинуть его на форму и он всё сделает. Делфисты же отвечали, что лучше они проверенные компоненты возьмут и сосредоточатся на решении задачи, чем как сишники будут велосипедить всё подряд. Спустя годы у нас тут обратная теория образовалась. Занимательно.

Сообщение от Drouge

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

Программы вроде бы пишутся для пользователей, а не программистов. Я должен выбрать более прожорливую и медленную программу потому что её разработчик написал тонну велосипедов, но делал это с удовольствием, глядя в окно на прекрасные закаты и попивая премиальный кофе? А более шустрая программа хуже, т.к. её недалёкий разработчик надёргал проверенные и хорошо оптимизированные open source решения, а не сидел креативил?
Ну, у некоторых брендов шмоток получается моток скотча продавать за много денег как элитный браслет, наверно и в IT такое возможно.

[NetSpace]

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

[DeepFlake]

Drouge, Мой велосипедный код типа быстрой сортировки. Длинный и медленный, но как мне кажется понятный

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

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

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

[digitalis]

Сообщение от DeepFlake

начинает думать как компьютер, короткими и простыми командами, и программирует так же.

Ну прям про меня.
Когда я перешёл из отдела нестандартного оборудования завода (там занимался проектированием управляющих систем на микросхемах, железом т.е.) в НИИ сразу в зам. гл. конструктора темы по ПО - мы с моими девчонками на ассемблере СМ-4 настрогали АСК для очень серьёзного изделия. Хотя была возможность на Фортране (Си для СМ-4 тогда на горизонте не просматривалось). Не скажу, что получилось чтобы уж элегантно, но работало.
Вторую тему делали более капитально, написав собственный микро-язык описания задачи. Но тоже - на ассемблере.

[DeepFlake]

to digitalis: я читал, что на СМ-4 прекрасно работал компилятор ETH Modula-2. Не встречались тогда с ним?