Я имею мнение, что «некрофилия» - это лоровский мем, не имеющий к реальности(к коей и отношу ЯП) ни малейшего отношения ;)

А вообще, есть славная стебная группа певцов ртом «Братья Торч» с одноименным альбомом ;) Рекомендую

Не ощущаю. В договоре и ТЗ необходимо прописать все что заботит исполнителя и заказчика.

конечно не ощущаете, поэтому и пытаетесь указать мне на то что в ТЗ надо прописать вещи которые «заказчика не заботят», более того, вещи о которых заказчики «понятия не имеют»... ещё раз: в общем случае, Вы ошибаетесь

> из каких составляющих состоит это время

Из производительных и непроизводительных затрат.

Производственных и непроизводственных Вы имеете в виду?

Ну что, я так и думал... Вы не рассматриваете трудозатраты на ведение проекта, что очень плохо. Со временем будут накапливаться ошибки которые придётся устранять, и не говорите мне что при «правильном программировании» ошибок не бывает, я не видел ни разу проекта без ошибок, коль скоро он сложнее банального «калькулятора».

Разделение модулей банально позволяет изменять одну часть проекта не трогая другую, что очень ВАЖНО, так как порой регрессионное тестирование проекта целиком может занимать значительное время.

Из попыток сделать все виды интерфейсов заранее и выполнения работ в рамках договора, для решения конкретных проблем заказчика.

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

Я имею мнение, что «некрофилия» - это лоровский мем, не имеющий к реальности ни малейшего отношения ;)

ну может так оно и к лучшему :)

>А историю из жизни привел лишь как пример интероперабельности - мол, проблемы с массивами достаточно надуманы.

Я правильно понял логику: «мне не приходилось сталкиваться => проблема надумана»? Знаю альтернативные примеры, когда приходилось сталкиваться и огребать как раз на маршалинге динамических массивов из дельфи в точка-нет.

Так приведите их!

Ничего не имею против Паскаля, лишь бы меня не заставляли на нём писать.

>Так приведите их! Не надо сильных эмоций:) Вкратце, для динамических массивов не гарантируется непрерывное размещение элементов в памяти. Как они будут расположены, сильно зависит от предыстории работы с ним. Отсюда его проблемы при маршалинге (недостаточно знать адрес первого элемента) и при произвольном доступе к элементам (адрес i-го элемента не просто база + смещение). Реализация смахивает на std::deque. Насколько знаю (не спец по дельфи) подстава эта особо не афишируется.

> В 1-ом семестре на C писали: списки, стеки, длинную арифметику (на списках), стековый калькулятор (RPN), калькулятор (infix), работу с файлами, сортировки (quick sort, heap sort, merge sort),

Неплохо так, однако....

> СПбГУ (черт, скоро до деанонимизации дело дойдет ;)).

А можно где-нибудь посмотреть программу с заданиями на лабы? Это кафедра Терехова?

>Код необходимо отделять от интерфейса

1. Зависит от задачи.
2. В Gambas и это возможно.

> Это кафедра Терехова?
Да.

А можно где-нибудь посмотреть программу с заданиями на лабы?

Есть список задач на 1-ый семестр: http://tinyurl.com/yfl5vvz

>> В значительно большем удобстве.

Просто неоспоримый аргумент.

Только вот на вкус и на цвет фломастеры разные. И многим функциональные ЯП не по вкусу.

при чем тут ФП? я писал о системе типов. Вы явно даже хеллоу-уорлдов на Окамле/Хаскелле не писали, между тем, реализуйте в Паскале нормальные списки, типа [a] при этом со статической типизацией и геморроя в виде if VarType(someVariableOfVariant) = varInteger then ... , а также анонимные функции с лексическими замыканиями, кортежи, сопоставление с образцом, тогда и поговорим...

> и геморроя

и без геммороя

да, и классы типов не забудьте

> Познакомьтесь с лиспом

не пугайте поскалистов лиспом, а то они сильно пугаются =)

К моменту «борландизации» (читай выкапывания) Паскаля имела место быть Модула, потом появился Оберон.

Я так и не понял, какого хрена? Ну это примерно также, как программировать на Гофере и Миранде вместо Хаскеля, или на ML вместо SML.

Это стадия мазохизма такая?

Похоже, fpc этого недоразумения лишен (полазил по исходникам).

> Не понимаю, чего небыдлокодеры так взъелсь на паскаль? Хороший язык, простой и гибкий...

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

>в паскале нет способа описать функцию

Ну, начнем с того, что в Паскале, как и в C, кстати, функцию описать нельзя: только процедуру.

В те времена, когда разрабатывался собственно паскаль и его последователи, перечисленные тобой вещи находились очень далеко от мейнстрима. А *математический* аппарат для вывода типов, вроде вообще сделали только в конце 80-х годов.

> Ну, начнем с того, что в Паскале, как и в C, кстати, функцию описать нельзя: только процедуру.

это да, пардон, точнее даже «подпрограмму»

В те времена, когда разрабатывался собственно паскаль и его последователи, перечисленные тобой вещи находились очень далеко от мейнстрима. А *математический* аппарат для вывода типов, вроде вообще сделали только в конце 80-х годов.

таки более чем 50-тилетнему лиспу это не мешает...

+ вот тут: http://ru.wikipedia.org/wiki/Вывод_типов подробнее, с датами...

дело даже не столько в том, что чего-то нет в паскале, а в том, что это никак не сделать своими силами не правя сорц ядра компилятора, рискуя при этом поломать его к чертям + не факт, что твои «дополнения» возьмут в основную ветку => никакой эээ «кроссплатформенности», необходимость рассылать патчи для компилятора, пересобирать его с этими патчами и всё такое. а в случае закрытых делфей так вообще ппц...

>Похоже, fpc этого недоразумения лишен (полазил по исходникам).

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

Потому что повсеместно и на форумах и в продакшене встречал такую конструкцию: SetLength( _array, Length( _array ) + 1 ). В дельфях это будет довольно быстро работать, потому что он страницами память будет добавлять и старые удалять/копировать не будет.

Хех ^_^ Вы нашли друг друга, совет да любовь ^_^

> Нормальная модульность. Нету ни в C, ни в C++ (в Java, правда, есть, но у неё другие недостатки). Множества (set). Оператор with. Возможность объявлять функцию локально в теле другой функции. Второе и третье удобно, но не очень принципиально, а вот отсутствие первого и четвёртого в плюсах доводит до белого каления.

Модульность лучше чем в C, но ведь разве *.c и *.h - это не interface и implementation, только в разных файлах. Простите мои уходы в сторону Delphi. Более знаком именно с ним. И вообще простите любую неграмотность связаную с новшествами мира паскаля и делфи за последние 4 года.

sets? Там надеюсь сняли уже ограничение на 256 разных элементов?

Локальные функции по моему работают в gcc.

Зато насмотрелся на них в плюсах. Ну да, конечно, техника мощнейшая, но насчёт её оптимальности есть сильные подозрения.

Шаблоны в С++ - это ОЧЕНЬ оптимально. Это частый инлайн, куча проверок уходит с рантайма, как это было бы в С. Вычисление чего то через функцию С и аналогичный код через функтор С++ шаблонного класса имеют разную производительность. С++ быстрее (у меня) в полтора раза

> sets? Там надеюсь сняли уже ограничение на 256 разных элементов?

кстати и для меня актуальный вопрос, это ограничение недавно чуть подпортило настроение

Шаблоны в С++ - это ОЧЕНЬ оптимально.

только ОЧЕНЬ уродливо =)

И? На fpc можно сделать и локальную морду, и веб-интерфейс (в lazarus - с мышевознёй, аяксом, блекджетом и шлюхами - http://code.google.com/p/extpascal/ - даже завёл на локалхосте, пока не баловался особо ^_^), вот только с мобильниками проблема... Кстати, когда пришлось - на яву не заморачивался, а тупо сделал простенький сайтик и встроенными браузерами на него заходил ^_^ Сайтик, опять же, - cgi модуль на fpc ^_^ Правда в конечном итоге решили, что не нужно ^_^

Просто сеты есть ВЕЗДЕ.

Шаблоны уродливы когда начинается что-то сложное и вложенное. С начала все мило и стильно

Эм... В его категории только плюсы (.NET и Java - из другой оперы, да и прожорливы чрезмерно ^_^, C - не ООП, python и Ко - вообще скриптовые ^_^). То что ниши не имеет - действительно ^_^ Просто приятный и хороший _универсальный_ язык, на котором и ОС написать можно (эх, если бы линукс был на паскале Т_Т Но, история, как известно, «бы» не терпит...), и ту же веб-морду (хотя последнее, конечно, чисто для себя делал, что б попробовать ^_^ На php в разы проще ^_^). А если с ними (с плюсами) сравнивать... Не хуже.

Ха! Классно пишется сначала консольная программка, чтобы потом там же графику делать :-D Смысл, если можно всё и сразу, просто в разных модулях? Или, ах, гуй сразу делать сложно, поэтому вначале получаем результат, а потом начинаем пыхтеть над тем, что в удобных IDE решается «мышевознёй»? :-D

И в чём проблема реализовать разделение гуя от логики программы в lazarus? ^_^ Напротив - графика делается в графическом режиме, с button'ами и actionlist'ами, и в ActionXExecute проверяю, что ввёл пользователь, а результат потом «отправляю» в «рукописные» обработчики, вынесенные в другие модули ^_^ Да и консольную отдельно написать можно, только зачем так извращаться? ^_^ И, о Боже, даже библиотеку 0.о Я вот держу несколько unit'ов, связаных друг с другом, которые таскаю из проекта в проект (на линуксе - тупо симлинками :-D)

> python и Ко - вообще скриптовые ^_^

что значит «скриптовые»?

> Просто сеты есть ВЕЗДЕ.

«везде» — это где? не вижу сетов в CL

> Ха! Классно пишется сначала консольная программка, чтобы потом там же графику делать :-D Смысл, если можно всё и сразу, просто в разных модулях?

я посмотрел бы, как твоя гуёвая программа обрабатывала бы данные в фоне на сервере, где просто нет иксов...

Для серверов - без вопросов... Но пишется отдельно ^_^ И гуй к ней, опять же, свой и общение уже по TCP реализовывать - но это отдельная задача. А писать приложение изначально гуёвое, но так что сначала консольную прогу с логикой, а потом к ней прикручивать графику... Может и хорошо в плане тестирования, но извращение ^_^ А «Ха!» было к тем двум вариантам Quazar'a, которые уже всякий смысл от консолеписания сводили на нет :-D

«Скриптовые» - значит вопросы производительности и экономичности вообще в стороне и очень далеко ^_^ Удобно в каких-то областях - да, безусловно, но... Гуй на питоне - это медленно (суждение а приори) ^_^ Если не прав - тыкнете носом, поставлю - сравню ^_^

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

По поводу ТЗ и интерфейсов - забавный случай был ^_^ Попросили в маркетинговом сделать для них программку, а я занят был, сказал - «Ну, несите ТЗ, там посмотрим» ^_^ Принесли - папку с кучей рисунков форм и «рассказами» - что будет, если нажать ту, или иную кнопку :-D Как потом оказалось - пришлось даже с магнитными картами дисконтными учиться работать ^_^

Для каких-то «фундаментальных» вещей, навроде mplayer, mpg123 (только с мультимедиа так связывался, так что примеры другие сложно привести ^_^) - да, конечно... Да и ладно, вообще соглашусь - не извращение ^_^ Но, повторюсь, на fpc (и Lazarus) такое реализовать тоже легко и удобно.

Лично мне хватает разделения гуя и логики по модулям в одном проекте. По-крайней мере, когда пришлось вернуться к проекту после года отсутствия (армия ^_^) - полностью (т.е. удалил старую форму и создал новую) изменить внешний вид программы удалось меньше чем за день, с сохранением всего функционала (просто не трогал остальные юниты).

Из того что я высмотрел, память кучи делится на 8/16кб блоки, поэтому накладные расходы на GetMem() в общем невелики. С другой стороны общая логика SetLength для динамического массива все же: выделить новый кусок памяти(getmem), скопировать содержимое массива(move), освободить старый блок(freemem).

> разве *.c и *.h - это не interface и implementation, только в разных файлах.

Это _имитация_ interface и implementation. Тут даже существенно не то, что они в разных файлах (в Модуле-2, кстати, изначально так и есть - определение модуля в одном файле, реализация в другом, при том, что модульность там настоящая, я даже считаю, что так удобнее).

Хуже то, что они не являются синтаксическими конструкциями языка. Директива препроцессора #include всего лишь включает один кусок текста внутрь другого. И не более того. И *.h-файл логически _никак_ не связан с теми библиотеками, где потом будет искаться функция, прототип которой был в нём объявлен.

Из-за этой разъятости мало того, что компиляторы Паскаля всегда работали быстрее, чем того же поколения компиляторы C++ (ибо компоновщик практически по второму разу занимается поиском, который уже был сделано собственно компилятором - особо наглядным примером были выпущенные почти одновременно досовские Turbo Pascal и Turbo C++), так это ещё и может привести к труднообнаруживаемым ошибкам. В жизни это, к счастью, происходит не так часто, но несколько раз я на такие грабли наступал.

Локальные функции по моему работают в gcc.

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

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

А что вы тут срач устроили, так это было предсказуемо.

> К моменту «борландизации» (читай выкапывания) Паскаля имела место быть Модула, потом появился Оберон.

Да я, в принципе, согласен, что Borland Oberon был бы лучше, чем Borland Pascal. Но...

Старые версии Turbo Pascal появились примерно в то же время (начало 80-х), что Modula-2. К тому моменту программистов, чьё обучение начиналось с Паскаля, было уже достаточно много, а тут им предлагают инструмент, который на знакомом языке позволяет писать серьёзные программы. Лебединой песней Модулы-2 стали компиляторы линейки TopSpeed. Увы,загнулись они...

А Оберон появился, когда Borland Pascal уже триумфально шествовал по миру. И как это часто бывает, технически более совершенное решение померкло на фоне более привычного и апробированного. Хотя если бы Borland захотел и выпустил Turbo Oberon, раскрученная торговая марка могла бы сделать своё дело. Но Borland не захотел...

Некоторые вещи в Обероне вызывают сильное сомнение, например, отказ от обработки исключений. И то, что в некоторых неофициальных диалектах их ввели обратно, сомнения подтверждает...

> добавлены типы Byte/Word/

какой гад их забрать успел?

Это _имитация_ interface и implementation.

вовсе и не имитация, с чего бы?

И *.h-файл логически _никак_ не связан с теми библиотеками, где потом будет искаться функция, прототип которой был в нём объявлен.

а? что Вы имеете в виду?

FreePascal нужен

Если бы не freepascal/lazarus то не видать бы linux'a в школах, а так решены все вопросы с необходимыми программами, все лучше, чем использовать wine.

Он имеет ввиду что можно набор из Z функций обявить в N хедеров, которые реализованы в M файлах кода. С одной стороны гибкость, с другой стороны программист МОЖЕТ создать беспорядок. Или наоборот порядок описанием каждой функции в отдельном файле.

Удобство модулей паскаля - то что они self-contained даже в бинарном виде. Вот есть у вас компилированый модуль, ничего uses и вперед. Такое есть в Java, но маркетинг по самоописываемым dll раскрутила МС в дотнете. Хотя это уже было в Turbo Pascal, может ранее

а, вот так понятнее... но кто мешает делать правильно? :)

>А Оберон появился, когда Borland Pascal уже триумфально шествовал по миру.

Появился тогда, когда линейка «Турбо» не на жизнь билась с линейкой «Квиков». Только вот лозунг «все для фронта», в конечном итоге вышел боком.

Борланд могла бы получить относительно нормальный ООП еще до битвы линеек «Визуал» и Дельфи/«Билдер».

Лично мне было ясно, что дельфи - тупик, еще когда я посмотрел 5-ю версию. Поэтому, я никогда не тратил сил на ее изучение. Правда я неоднократно слышал утверждения, что вот 3-я дельфи была о-го-го. Может быть и так.

Но, наверно, самой фундаметнальной ошибкой было заигрывание с .NET'ом. После этого, вся борландовскя линейка подписала себе смертный приговор.

Заигрывать надо было бы с явой. Интегрировать свое legacy-хозяйство через JNI. Например, SWT (на котором построен eclipse) идет именно по этому пути, и имеет много плюшек в виде скорости и «нативности» гуя на целевой платформе. А потом произвести долгий и упорный процесс по ликвидации legacy кода.

Позитивные изменения, случившиеся с JVM 1.5 этому только бы способствовали. Но увы.

более того, вещи о которых заказчики «понятия не имеют»... ещё раз: в общем случае, Вы ошибаетесь

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

Вы не рассматриваете трудозатраты на ведение проекта.

Естетсвенно, я ведь для вас не тренинг по управлению проектами провожу.

Со временем будут накапливаться ошибки которые придётся устранять, и не говорите мне что при «правильном программировании» ошибок не бывает

Вы телепат?

ещё раз из практики: использование паттерна mvc позволяет существенно упростить ведение проекта

Вы мне этим паттерном mvc тычете, как будто его использование решит все проблемы. Давайте расскажите как он поможет при написании калькулятора. Какие преимущества такой подход дает модулям Moodle в которых приходится через атрибуты одного класса передавать данные другому классу визуализации.

ололо, а ведь Вы и правда ведь расшибёте лоб если Вас послать...

Снова телепатия?

ещё раз из практики: использование паттерна mvc позволяет существенно упростить ведение проекта (если его использовать с умом конечно)

Я не против mvc в принципе. Естественно её (модель) нужно применять с умом. Речь шла об отделении интерфейса от реализации, о том что этого избегать нелья. Я говорю о том, что в некоторых случаях можно. А в других о этом за вас позаботились разработчики библиотек Qt или VCL. К тому-же часто читал на ЛОРе о том что такое разделение якобы легко позволяет реализовать различные виды интерфейсов (web, WIMP). Это не так. Это сложная задача, которая под силу далеко не всем командам разработчиков. И примеров реализации этой идеи исчезающе мало. Тратить время на реализацию этой идеи глупо, эсли вы не разработчик мега GUI библиотеки.
<telepat>
И не нужно думать, что код моих программ состоит из одной функции
в одном модуле. Или из одного класса. Или что мне не известны способы
распределения работ между исполнителями.
</telepat>

>Появился тогда, когда линейка «Турбо» не на жизнь билась с линейкой «Квиков».

А разве линейка майкрософтовских «квиков» не сливала борланду по всем статьям? Равно как и вижуал-студия до шестой.

Это потом уже пришел дотнет и после 2003-й студии нельзя было смотреть обратно на дельфик. Но до этого МС плелся в хвосте, разве нет?

>разве линейка майкрософтовских «квиков» не сливала борланду по всем статьям?

Сложно сказать. Турбо Паскаль был популярнее Квик Паскаля и Квик Бейсик был популярнее Турбо Бейсика. Насчет С я не очень в курсе, вроде шли они примерно одинаково, ассемблеры примерно одинаково.

Но до этого МС плелся в хвосте, разве нет?

Нет. Просто дельфи слишком сильно залезла в область RAD. А затем произошел слив компонентного программирования различным фреймворкам, которые имели место быть в JVM и .NET