воскресенье, 15 сентября 2013 г.

Предложил своим студентам попробовать FireMonkey

Программа для V-го курса предусматривает разработку интерактивного приложения с использованием Delphi. Там "многоходовая комбинация", фактически, разработка прототипа информационной системы, на примере которой иллюстрируются реальные задачи. Построение элементов управления по метаданным БД, динамическая компоновка форм из фреймов, загружаемых отдельно, стыковка окон (docking) содержащих представления таблиц на рабочем столе (вкладка, подобно вкладке браузера) и интерактивная установка отношений master-detail меду ними, сохранение и загрузка рабочих столов через фабрики...
Много всего, "до октябрьских" точно не уложимся, до Нового Года - у некоторых шансы есть...
Подготовительный этап к этой работе занял весь предыдущий семестр: работали над унифицированным представлением метаданных. Но там Delphi практически не было, только Python, XML и SQLite.
Ранее для целей построения интерактивного приложения использовался Delphi 2007 и VCL. Сейчас - решил рискнуть, и предложил желающим попробовать создать GUI с использованием FireMonkey (FMX).
Бросилось в глаза, что об FMX никто не знал. Печально, но даже аббревиатура VCL знакома единицам. Пришлось кратко остановиться на истории развития Object Pascal в Borland и после него, разработке кроссплатформенного ПО вообще, и  идее "единой базы кода", педалируемой Embarcadero.
Мнда... Ну ладно... ;-)

Сразу же пришлось отвечать на вопросы типа "чем это лучше QT" с которым публика знакома лучше, чем с Delphi и VCL. Тут не всё так просто, тем более, что подход QT лично мне намного понятнее. Ну, не просто поверить, что "самописное" воспроизведение элементов управления в среде конкретной ОС окажется проще и стабильнее, чем использование API, предоставляемой самой ОС. Спорно это, за развитием этого, может быть, интересно понаблюдать, но вот принимать в этом участие... Но студентам - можно :-)
Посмотрим, что получится. Надеюсь один-два человека рискнут попробовать FMX по моему совету, тем более, что я пообещал в таком случае "креативный плюс".

Ну и, совершенно понятно, была поднята тема "Какую версию Delphi использовать?". Ну и что мне отвечать, господа из разлюбезного Embarcadero? ;-) Бесплатной Express-версии у вас нет, о каких-то послаблениях для студентов от вас я не слышал, вероятно, вы ожидаете, что я пойду к ректору и предложу приобрести "академическую" лицензию (кстати, а такое бывает?), поскольку то, что было куплено несколько лет назад, уже морально устарело? Как вы думаете, господа: куда меня пошлют? И зачем им это надо? И зачем мне вообще нужно это пробивать? - Ах, ну да, ну да... Совсем забыл: мне же не всё равно... :-)

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

Ну, вот вам взгляд и с другой стороны. Со стороны компании-разработчика, использующей Delphi. Найти программиста на Delphi в моём городе - настоящая проблема. Понятно, что его ещё полгода учить придётся, прежде чем он выйдет на нулевую рентабельность. Но уже просто найти - сложно. Не пользуется платформа популярностью. Не является распространённой. Уже.

Вот так-то, господа "коммерсанты" из "ведущей IT-компании". Как-то слишком уж по-зимбабвийски вы действуете. Действительно, зачем закапывать зёрна в землю, если их можно съесть прямо сейчас...

66 комментариев :

  1. Ох, бедные студенты :) Пичкают их тем, что в жизни вряд ли пригодится. Да и к плохому приучаете ;) нехорошо воровать :) Почему бы действительно PyQt не использовать? Он не такой сложный, практичный, кроссплатформенный... В общем, назовите хотя бы один плюс использования Delphi. Не нравится Qt, есть gtk, wxWidgets на худой конец. Не нравится python (щито?!?!) - есть биндинги к php, ruby, c++ накрайняк. Если раньше pascal был хорошим учебным языком, то теперь пора это пересмотреть. Кстати, а студентов не заставляете свой репозиторий для решения этой задачи вести?

    ОтветитьУдалить
    Ответы
    1. http://russian.joelonsoftware.com/Articles/BacktoBasics.html

      Удалить
    2. "Пичкают их тем, что в жизни вряд ли пригодится."
      Однако! Вы сами (зачем-то) указываете своё знание Delphi. Зачем? Зачем указывать "знание мёртвого языка"? Подчеркнуть свою "академичность"?

      Удалить
    3. Я не говорю, что Delphi мёртв, я говорю, что он умирает. Если бы я знал Cobol, его бы тоже указал ;) Программисты на нём ох как редки, хотя ещё востребованы.

      Удалить
    4. «Я не говорю, что Delphi мёртв, я говорю, что он умирает»
      -- Процесс, так сказать, несколько м-м-м... затянулся, скажем так... ;-)

      «Если бы я знал Cobol, его бы тоже указал ;)»
      -- Ну, COBOL была найдена адекватная замена ещё в 70-х - PL/1. О современных языках я не говорю. Для Delphi альтернативой пока не может выступать ни один из известных мне языков, исключая наверное, Free Pascal.

      «Программисты на нём ох как редки, хотя ещё востребованы.»
      -- Мнда... Тут не поспоришь. Востребованность, кстати, есть функция распространённости...

      Удалить
    5. >>-- Мнда... Тут не поспоришь. Востребованность, кстати, есть функция распространённости...
      Распространённость всего лишь один из аргументов функции востребованности ;)

      >>Для Delphi альтернативой пока не может выступать ни один из известных мне языков, исключая наверное, Free Pascal.
      Полегче с высказываниями :) Альтернатив море, начиная от C++ с C#, заканчивая тем же питоном. Фишка как раз в том, чтобы под задачу выбрать наиболее удачный инструмент. Не надо быть фанатом отвёртки ;)

      Удалить
    6. «-- Мнда... Тут не поспоришь. Востребованность, кстати, есть функция распространённости...
      Распространённость всего лишь один из аргументов функции востребованности ;)»
      -- Конечно :-)

      «Для Delphi альтернативой пока не может выступать ни один из известных мне языков, исключая наверное, Free Pascal.
      Полегче с высказываниями :) Альтернатив море, начиная от C++ с C#, заканчивая тем же питоном. Фишка как раз в том, чтобы под задачу выбрать наиболее удачный инструмент.»
      -- Мы же говорим в контексте обучения программированию, а не вообще :-) Это первое. Второе: IMHO в Object Pascal сочетается нативность и простота. Python - проще, но он - интерпретатор. C++ нативен, но он намного сложнее. Boo - экзотичен, Java и C# - заточены на соответствующие платформы. Ну и т.д.
      При всём богатстве выбора... (c) :-)

      Удалить
    7. >>Java и C# - заточены на соответствующие платформы
      Хм, Вы уверены??? Либо я Вас не понял, либо одно из двух.

      Удалить
    8. >C++ нативен, но он намного сложнее.
      В каком месте он сложнее? Плюс он стандартизирован.

      >Хм, Вы уверены??? Либо я Вас не понял, либо одно из двух.
      Видимо имеются в виду JRE(Java) и CLR(.NET).

      Удалить
    9. Выше я написал, что C# позволяет писать нативный код, то есть выходить из CLR.

      Удалить
    10. @Son of a gun «C++ нативен, но он намного сложнее.
      В каком месте он сложнее? Плюс он стандартизирован.»
      -- В любом месте он сложнее. Для того, чтобы убедиться - возьмите книжку по Delphi и посмотрите, сколько страниц там отводится на обсуждение непосредственно Object Pascal от идентификаторов до классов. И сравните это с объёмом соответствующей книжки по C++.
      Кстати, Вы обратили внимание, что книжек по Delphi полно, а по Object Pascal их практически не осталось? И дело здесь не в том, что Pascal якобы не стандартизирован - стандарт есть, их даже два: де-юре (ANSI) и де-факто (Delphi). Object Pascal - просто очень простой язык, хотя Embarcadero постаралось, конечно, в последние годы. Впрочем эти старания сосредоточены, в основном, на поддержке обобщённых типов и интроспекции.
      Если же говорить о C++, то про его стандарты IMHO лучше не упоминать, поскольку "стандартов" этих больше чем в случае Object Pascal. Причём, в самых неожиданных местах.
      Помню (на занятиях в ВУЗе, кстати) был забавный случай. Одну из задач я разрешил сделать на чём угодно. Один из студентов выбрал C++. В контексте задачи возникла потребность в корректном освобождении ресурсов (у меня это категорическое требование), молодой человек начал городить "лесенки" try..catch. Я ему - мол, чего мучаешься, напиши try..finally. Онм мне - что мол никакого finally в C++ нет. Я - как это нет! Лезу в MSDN (он просто под рукой был) нахожу ему finally. Только сразу обратил внимание, что он какой-то странный: не "finally", а "__finally", но VS "кушает" его с удовольствием. Стал разбираться - действительно, эта конструкция введена в C++ Microsoft. Там - она есть, а за рамками MS C++ - его нет. Microsoft им пользуется, а в стандартах этого нет. Ну и что толку в таких стандартах?
      Далее, я упомянул "мультипарадигменность" C++, которой его апологеты (есть апологеты C++, именно - апологеты, "фанаты отвёртки", если хотите, поскольку C++ это не просто ЯП, а "стиль жизни" (я бы добавил ещё - религия)) так гордятся. К чему это приводит? - А только к тому, что чтобы уверенно разбираться в коде на C++ Вам потребуется иметь представления обо всех таких парадигмах. Среди них есть и в высшей степени сомнительные - использование той же перегрузки операторов тогда, когда "это удобно". Вот и выходит - одному "удобно" писать код, он так "самовыражается", другие - вынуждены подстраиваться под его "парадигму".
      IMHO плох не C++, а подходы к его использованию.
      Добавлю, что всё сказанное - моё личное IMHO. Кроме того я за 20 с лишним лет достаточно осведомлён относительно "доводов сторон" :-)

      @Виктор Тыщенко «Выше я написал, что C# позволяет писать нативный код, то есть выходить из CLR.»
      -- Вместе с тем, за рамками .Net/Mono использовать C# не получится. А как там с .Net на AIX? А GNU Pascal там есть (http://community.freepascal.org/bboards/message?message_id=243030&forum_id=24086 см. последний ответ). Ну и драйверы устройств на C# писать не принято, ввиду требовательности к ресурсам самой платформы .Net (про Java - вообще не говорю) на Pascal - пожалуйста.

      Удалить
    11. >возьмите книжку по Delphi и посмотрите, сколько страниц там отводится на обсуждение непосредственно Object Pascal от идентификаторов до классов. И сравните это с объёмом соответствующей книжки по C++.

      Книги по в основном С++ описывают язык, а книги по дельфи - среду. Т.к дельфи это не только язык. Языку просто уделяется меньше внимания.

      >стандарт есть, их даже два: де-юре (ANSI) и де-факто (Delphi)

      И это минус.

      >Если же говорить о C++, то про его стандарты IMHO лучше не упоминать, поскольку "стандартов" этих больше чем в случае Object Pascal. Причём, в самых неожиданных местах. Помню (на занятиях в ВУЗе, кстати) был забавный случай

      Это как раз не о стандартах, а об их несоблюдении.

      >перегрузки операторов

      Не вижу минусов перегрузки операторов. Это те же методы/функции, просто форма записи другая. Может поругаться на перегрузку методов?

      Удалить
    12. «Книги по в основном С++ описывают язык, а книги по дельфи - среду. Т.к дельфи это не только язык. Языку просто уделяется меньше внимания.»
      -- Разумеется. В книгах по более простому языку ему меньше уделяется внимания.

      «стандарт есть, их даже два: де-юре (ANSI) и де-факто (Delphi)
      -- И это минус.»
      -- Тогда для C++ это же - жирный минус или, в стиле С++, "--"
      Там такого "нестандартного" не меньше.

      «Это как раз не о стандартах, а об их несоблюдении.»
      -- Ну, а я Вам про что говорю? :-) Зачем же Вы говорите о стандартизации C++, если от этих стандартов преспокойно отходят те, кто стандарты и определяет?

      «Не вижу минусов перегрузки операторов. Это те же методы/функции, просто форма записи другая. Может поругаться на перегрузку методов?»
      -- Вы не видите, а я - вижу. Проявляется это в том, что при анализе кода каждый раз приходится разбираться, что очередному "умнику" взбрело в голову отразить посредством оператора "<<"? То, что проблема стояла очень остро, нашло отражение в том, что в Java эта сомнительная возможность до сих пор не появилась, а в C# её до недавних пор не было.
      Чтобы "увидеть проблему", почитайте, например, здесь: http://ru.wikipedia.org/wiki/Перегрузка_операторов#.D0.92.D0.B0.D1.80.D0.B8.D0.B0.D0.BD.D1.82.D1.8B_.D0.B8_.D0.BF.D1.80.D0.BE.D0.B1.D0.BB.D0.B5.D0.BC.D1.8B
      Далее, ругаться с Вами я не буду, относительно перегрузки методов скажу, что злоупотреблять не следует ничем. И перегрузкой методов - в частности. Существует набор типовых случаев, когда перегрузка методов конструктивна. Выходить за эти рамки не стоит, хотя к счастью, неверное использование этой техники слишком неудобно.

      Ну и последнее, давайте не будем *здесь* разводить "священные войны". Не думаю, что они кому-то интересны. Если всё же хочется продолжить - напишите мне в личку. Почтовый адрес доступен в моём профиле.

      Удалить
    13. В догонку... Прошу прощения, я немного наврал насчёт перегрузки операторов в C#. Просто она там была так реализована, что резкого неприятия у меня никогда не вызывала. В частности, там были введены существенные ограничения на операторы, которые нельзя перегрузить: http://msdn.microsoft.com/ru-ru/library/8edha89s%28v=vs.90%29.aspx
      Такая перегрузка вполне терпима в отличие от вакханалии, устроенной в C++.

      Удалить
    14. >Разумеется. В книгах по более простому языку ему меньше уделяется внимания.

      В книге о языке всё внимание уделяется языку, какой бы простой или сложный он не был. Книги о дельфи описывают не только язык, но и среду с графикой.

      >Тогда для C++ это же - жирный минус или, в стиле С++, "--"
      Там такого "нестандартного" не меньше.

      Нестандартное - редкость и признак плохого кода, не надо выдумывать.

      >Вы не видите, а я - вижу. Проявляется это в том, что при анализе кода каждый раз приходится разбираться, что очередному "умнику" взбрело в голову отразить посредством оператора "<<"?

      Документацию читать надо, если что-то непонятно.

      >То, что проблема стояла очень остро, нашло отражение в том, что в Java эта сомнительная возможность до сих пор не появилась

      Особенный выйгрыш они получили при работе с длинной арифметикой.

      >Чтобы "увидеть проблему", почитайте, например, здесь:

      Тем не менее - не вижу. Подводные камни есть у всего, может тогда вообще не программировать?

      Удалить
    15. @Son of a gun: Пожалуйста, перестаньте *здесь* флеймить. В данной теме "C++ vs всё остальное" оффтопик.

      Удалить
    16. >Пожалуйста, перестаньте *здесь* флеймить

      Кому "флейм", а кому "обоснование позиции" =)

      >оффтопик.

      Оффтопик - это если бы мы о политике стали говорить.

      >"C++ vs всё остальное"

      Такой темы мы и не затрагивали. И я бы в ней был явно не за С++.

      Удалить
    17. :
      def harmless(x):
      """Я совершенно безобидная функция."""
      return x

      class harmful(object):
      def __repr__(self):
      __import__('subprocess').call(['mkdir', 'VERY_SUSPICIOUS'],
      shell=True,
      stderr=open(__import__('os').devnull, 'wb'))
      return """Я совершенно безобидная функция.
      Какие каталоги? Не знаю никаких каталогов.
      Вы мне что, не верите?"""

      harmless.__doc__ = harmful()
      И с питоном можно выстрелить себе в ногу ;)

      Удалить
    18. "Существует набор типовых случаев, когда перегрузка методов конструктивна."

      ИМХО - ТОЛЬКО когда "эмулируем" что-то сродни "линейной алгебре". Ну и или ПРОЧИХ понятий их математики.

      ВСЁ остальное - для перегрузки операторов - ДОЛЖНО БЫТЬ закрыто.

      Удалить
    19. @Виктор Тыщенко «И с питоном можно выстрелить себе в ногу ;)»
      -- Да Виктор, можно. Только в приведённом Вами примере Вы *явно* прицелились и выстрелили.
      Кстати, приведённый Вами код сильно напоминает саботаж. Насколько проще такое сделать в C++ можно прочитать здесь: http://ru.wikipedia.org/wiki/%D0%A1%2B%2B#.D0.9A.D1.80.D0.B8.D1.82.D0.B8.D0.BA.D0.B0
      Прошу понять меня правильно. Я не прячусь за авторитетом Википедии, мне просто действительно скучно спорить о вещах, которые для меня совершенно очевидны.
      Да, я возьмусь утверждать, что для меня C++ - плохой язык. Пожалуй, хуже него только Perl.
      Обосновать? Если обоснований, приведённых по ссылке выше недостаточно, то признаюсь, что добавить мне нечего. Для меня же указанные там вещи являются основанием прибегать к C++ только в исключительных случаях.

      @Александр Люлин «"Существует набор типовых случаев, когда перегрузка методов конструктивна."
      -- ИМХО - ТОЛЬКО когда "эмулируем" что-то сродни "линейной алгебре". Ну и или ПРОЧИХ понятий их математики.
      ВСЁ остальное - для перегрузки операторов - ДОЛЖНО БЫТЬ закрыто.»
      -- Ну... Где-то так :-)
      По крайней мере, если следовать такой формулировке, проблем, связанных с перегрузкой операций, скорее всего не случится.

      Удалить
    20. > Насколько проще такое сделать в C++ можно прочитать здесь:

      Т.е своих аргументов, серьёзнее перегрузки операторов у вас нет? Подавляющее большинство перечисленных недостатков в равной степени относятся и к дельфи. Так что ваше отношение к С++ видится мне иррациональным.

      Удалить
    21. «Т.е своих аргументов, серьёзнее перегрузки операторов у вас нет? Подавляющее большинство перечисленных недостатков в равной степени относятся и к дельфи. Так что ваше отношение к С++ видится мне иррациональным.»
      -- Уважаемый Son of a gun, я в третий (и вероятно, последний) раз прошу Вас использовать личку для обсуждения темы моего отношения к С++.
      Я просто не считаю эту тему подходящим местом для спора на этот счёт.
      Прошу Вас принять также во внимание, что мне глубоко безразлично, что и как Вам видится.

      Удалить
    22. >Уважаемый Son of a gun, я в третий (и вероятно, последний) раз прошу Вас использовать личку для обсуждения темы моего отношения к С++

      Да? Я думал мы о "недостатках С++ как языка для обучения по сравнению с дельфи" говорим. Впрочем, не хотите обсуждать - не надо. =)

      >Прошу Вас принять также во внимание, что мне глубоко безразлично, что и как Вам видится.

      Ну, это неприятно слышать.

      Удалить
    23. «Да? Я думал мы о "недостатках С++ как языка для обучения по сравнению с дельфи" говорим. Впрочем, не хотите обсуждать - не надо. =)»
      -- Так, стоп! Здесь вынужден попросить у Вас прощения.
      Признаюсь, я упустил контекст, и то, что Вы сказали, что речь о "C++ vs Pascal" идёт в контексте обучения программированию очень существенно.

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

      Удалить
    24. @Son of a gun: Я сейчас перечитал то, что писал в этой ветке и совершенно не могу понять, из чего Вы сделали вывод о моём "иррациональном отношении" к этому языку.
      Да, как я уже сказал выше, у меня сложилось ощущение, что Ваши вопросы задавались исключительно в полемических целях. Вы правда сказали об "обосновании своей позиции", но было бы неплохо, чтобы Вы её сначала обозначили.

      Моя позиция такова. C++ нецелесообразно использовать для обучения программированию, поскольку такое обучение выливается в изучение C++, который я не отношу к удачным языкам. Знакомство же с C++ необходимо и может быть обеспечено, например, в рамках спецкурса.

      В относительной сложности C++ в сравнении с Pascal можно убедиться, сравнив грамматики этих языков. Например: http://homepages.e3.net.nz/~djm/cppgrammar.html#translation-unit и http://delphi.wikia.com/wiki/Object_Pascal_Grammar.

      Удалить
    25. >Так, стоп! Здесь вынужден попросить у Вас прощения.

      Всё в порядке, не надо извиняться. Видимо, дело в недопонимании. =)

      >Я сейчас перечитал то, что писал в этой ветке и совершенно не могу понять, из чего Вы сделали вывод о моём "иррациональном отношении" к этому языку.

      Это общее впечатление. Я правда считаю, что перегрузка операторов - не аргумент, для меня это мелочь, не достойная упоминания. Далее вы привели список притензий, который был настолько общим, что большинство утверждений верно и для дельфи. Я надеялся услышать существенные недостатки, с которыми вы лично столкнулись. И сложилось впечатление что самый существенный из них - это перегрузка операторов(т.е мелочь по моим меркам), от того и вывод. Может быть я поспешил с выводом. =)

      >Вы её сначала обозначили.

      Мне просто интересно, почему дельфи(паскаль) by default считается лучшим для обучения, чем С++(С). При том что языки очень похожи, но С++ обладает приимуществами как открытый и стандартизированный, а будущее дельфи всё ещё туманно на фоне С#.

      >C++, который я не отношу к удачным языкам.

      Я тоже не считаю С++ образцовым языком. С++ монструозен, но и дельфи грешит тем же. Просто это компромиссные языки, мутировавшие из своих структурных предков. =)

      >http://delphi.wikia.com/wiki/Object_Pascal_Grammar.

      Дельфи уже не object pascal. А грамматика по ссылкам в совсем разной нотации записана, как прикажете сравнивать? Да и грамматика - это не всё. =)

      Удалить
    26. «http://delphi.wikia.com/wiki/Object_Pascal_Grammar.
      Дельфи уже не object pascal. А грамматика по ссылкам в совсем разной нотации записана, как прикажете сравнивать? Да и грамматика - это не всё. =)»
      -- Delphi это диалект Object Pascal :-)
      Вариантов описания грамматики (и Delphi в частности) в интернете очень много, предложенный к рассмотрению вариант - IMHO наиболее характерных, хотя и не учитывает последних дополнений в языке от Embarcadero. Но о них при обучении программированию речи и не идёт.
      Разница в записи грамматики - по модулю обозначений. В остальном - всё одно и то же.
      Для сравнения сложности грамматик я обычно обращаю внимание на количество определяемых символов, средствами которых описывается язык. Чем больше - тем сложнее. В случае совпадения или близости по указанной характеристики, обратил бы внимание на количество вариантов при описании каждого символа. Чем больше - тем сложнее. Таким образом, в моём представлении сложность грамматики коррелирует с количеством строк в её описании (что согласуется с утверждениями по ссылке на Википедию, которую я приводил ранее).
      Да, грамматика - это не всё. Но и не малая часть, уж точно. Особенно, в контексте обучения программированию.

      «Я сейчас перечитал то, что писал в этой ветке и совершенно не могу понять, из чего Вы сделали вывод о моём "иррациональном отношении" к этому языку.

      Это общее впечатление. Я правда считаю, что перегрузка операторов - не аргумент, для меня это мелочь, не достойная упоминания.»
      -- Совершенно напрасно считаете. Заявляю это совершенно ответственно. При обучении программированию после темы разработки алгоритмов переходят к изучению инструмента, т. е. конкретному языку. Можно не сказать о возможности перегрузки операторов вообще, можно сказать и запретить их использование, можно объяснить, почему перегружать операторы — плохо. Первые два варианта действий для меня неприемлемы, последний — то, о чём я говорил ранее: вместо изучения программирования мы начинаем разбирать причины, по которым опасные возможности не следует применять.
      Проблема ли это? Возможно, и нет. Но на это придётся тратить время, замусоривать тему, сообщать и объяснять то, что не имеет отношения к цели — обучению программированию.
      Перегрузка операторов — просто яркий пример, поскольку сомнительный решений в C++ более чем достаточно.

      Удалить
    27. «Далее вы привели список притензий, который был настолько общим, что большинство утверждений верно и для дельфи.»
      -- 1. Обучение ведётся на Pascal, а не на Delphi. Конкретно используется Free Pascal, и в школах и на начальных курасах ВУЗа. Это значит, что используются возможности стандартного Pascal, плюс классы из Object Pascal. Для обучения программированию большего не нужно.
      2. Никакого списка я не приводил. Единственно, я сослался на Википедию, где приводится критика языка C++. Вы находите, что большинство утверждений, приводимых там, справедливы и для Delphi? - Давайте конкретно рассмотрим утверждения, показавшиеся Вам таковыми, но не в контексте Delphi, а в контексте именно Pascal.

      ««Далее вы привели список притензий, который был настолько общим, что большинство утверждений верно и для дельфи.»»
      -- Часть я обозначил выше. В целом:
      1. Большая сложность языка.
      2. Обилие конструкций, синтаксически необходимых, но не нужных для обучения (например int main() - почему int? #include vs #include “ident” - в чём разница?) которые придётся объяснять.
      3. Отсутствие необходимых конструкций (try..finally) в стандарте языка.
      4. Наличие конструкций и техник, на которых требуется остановиться, чтобы мотивировать ограничение их использования.
      5. Дальнейшее применение и востребованность полученных знаний. Знания специфики C++ востребованым может оказаться только при дальнейшем применении C++. К счастью, сейчас это не самый популярный язык. С другой стороны, практически всё, что есть в Pascal, в той или иной мере присутствует и в других языках.

      «Вы её сначала обозначили.

      Мне просто интересно, почему дельфи(паскаль) by default считается лучшим для обучения, чем С++(С).»
      -- Потому, что как я обозначил выше, Pascal проще, в его стандарте отсутствуют вещи, которые при обучении программированию не востребованы и применение которых сомнительно со всех точек зрения.

      «При том что языки очень похожи, но С++ обладает приимуществами как открытый и стандартизированный»
      -- Выше я обозначил, что от "стандартизации" C++ толку почти нет (я бы сказал, что вообще нет). В обучении же программированию следование стандарту C++ IMHO вообще вредно. Например, в стандарте C++ отсутствует блок try..finally. Это заметно усложняет донесение техники освобождения ресурсов и провоцирует введение дополнительных понятий (техник, специфичных только для C++), например "умных указателей" и пр., что не требуется в случае Pascal.

      «, а будущее дельфи всё ещё туманно на фоне С#.»
      -- Будещее Delphi туманно совершенно без "фона" C#.

      «С++ монструозен, но и дельфи грешит тем же.»
      -- В каком месте "монструозен" C++ я понимаю. Где Вы нашли "моструозность" Delphi - нет. Объясните. В Delphi есть сомнительные решения, их немало, но говорить о "монструозности" я не вижу оснований.
      Далее, предлагаю здесь вообще не обсуждать Delphi, поскольку обучение ведётся на Pascal, который стандартизован в той же степени, что и C++.

      Удалить
    28. >перегружать операторы — плохо.

      На практике никогда не сталкивался с тем, что это "плохо". Даже наоборот. Кстати, тут случайно попалось на вики, что в Delphi и Free Pascal есть перегрузка операторов, так что изучать её всё равно придётся? Или я что-то не так понял?

      >Никакого списка я не приводил. Единственно, я сослался на Википедию, где приводится критика языка C++. Вы находите, что большинство утверждений, приводимых там, справедливы и для Delphi?

      Да, я говорю именно о вики:

      >Порождающее метапрограммирование трудоёмко и ограничено по возможностям

      в дельфи с этим только хуже.

      >Явная поддержка функционального программирования присутствует только в стандарте C++0x,

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

      >Абстракция Система типов обладает крайне слабыми средствами абстракции[источник?]. Некоторые отсутствующие в С++ семантические возможности могут реализовываться на уровне библиотек (такие как сборка мусора или длинная арифметика), однако для получения выгоды от них необходима

      справедливо и для дельфи.

      >Потенциал к оптимизации Из-за слабой системы типов и изобилия побочных эффектов становится крайне затруднительным эквивалентное преобразование программ,

      то же самое.

      >Эффективное управление памятью... Сборка мусора отсутствует...

      у дельфи дела с этим сильно хуже.

      >Замедление Си... В условиях узко ограниченных вычислительных ресурсов...

      то же самое.

      >Обилие конструкций, синтаксически необходимых, но не нужных для обучения (например int main() - почему int?

      Издержки низкоуровневости.

      >Дальнейшее применение и востребованность полученных знаний. Знания специфики C++ востребованым может оказаться только при дальнейшем применении C++.

      Знание специфики С++ пригодится везде. Именно С++ по большей части сформировал концепции Java и C#. К тому же С++ всё ещё один из самых популярных языков.

      >В каком месте "монструозен" C++ я понимаю. Где Вы нашли "моструозность" Delphi - нет

      А там разве нет второй объектной системы, и 11 типов строк? А отсутствие возможности создания объектов на стеке, и при этом никакой поддержки автоматического управления ресурсами? Это между тем минус огромный, никак не сравится со сложным синтаксисом или перегрузкой операторов.

      >Далее, предлагаю здесь вообще не обсуждать Delphi, поскольку обучение ведётся на Pascal, который стандартизован в той же степени, что и C++.

      Не вижу никакой ценности в Object Pascal в отрыве от Delphi. Сейчас очень много молодых языков, которые давно обошли по всем параметрам free pascal (D, Go, Vala, CL, Ocaml, Haskell, например). Если же не использовать Object Pascal после обучения, то почему бы сразу не учиться на Java/C#? Если речь не о Object Pascal, а о старом добром Pascal, то тут есть Си и это так же один из самых востребованных языков.

      Удалить
    29. «перегружать операторы — плохо.

      На практике никогда не сталкивался с тем, что это "плохо". Даже наоборот.»
      -- Ну... Скажем так, у каждого своя практика, но неуместная перегрузка операторов (всё, что выходит за рамки возможностей по перегрузке операторов C# я отношу к неуместному) создаёт объективные проблемы с восприятием кода.
      Ваш тезис о том, что "нужно читать документацию" я не могу воспринимать серьёзно, поскольку часто приходится работать со сторонним кодом, для которого документации нет вообще.

      «Кстати, тут случайно попалось на вики, что в Delphi и Free Pascal есть перегрузка операторов, так что изучать её всё равно придётся? Или я что-то не так понял?»
      -- Да, она там "местами" есть :-)
      Но в стандарте Pascal её нет. Поэтому о такй возможности не упоминается вообще, говорится иначе, что "Free Pascal это свободный компилятор для множества платформ, поддерживающий ряд расширений синтаксиса, на которых, ввиду их нестандартности мы говорить не будем и пользоваться ими тоже не будем".

      «Никакого списка я не приводил. Единственно, я сослался на Википедию, где приводится критика языка C++. Вы находите, что большинство утверждений, приводимых там, справедливы и для Delphi?

      Да, я говорю именно о вики:»
      -- Замечательно, но почему же Вы выходите из контекста обсуждения, состоящего в применимости языка в целях обучения программированию?

      «Порождающее метапрограммирование трудоёмко и ограничено по возможностям

      в дельфи с этим только хуже.»
      -- При обучении порождающее метапрограммирование не рассматривается вообще. Или рассматривается, но в рамках спецкурсов, а там другие языки. Не C++ и не Pascal.

      «Явная поддержка функционального программирования присутствует только в стандарте C++0x,

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

      «Абстракция Система типов обладает крайне слабыми средствами абстракции[источник?]. Некоторые отсутствующие в С++ семантические возможности могут реализовываться на уровне библиотек (такие как сборка мусора или длинная арифметика), однако для получения выгоды от них необходима...

      справедливо и для дельфи.»
      -- Вот это, скорее, следствие нативности :-) Со специальными типами приходится работать явно.

      «Эффективное управление памятью... Сборка мусора отсутствует...

      у дельфи дела с этим сильно хуже.»
      -- Для обучения программированию - наоборот, лучше :-)
      Кроме того, я нахожу, что управление памятью "вручную" более эффективно и предсказуемо, нежели автоматизированное. Сейчас эту позицию разделяют и в Apple и в Google. Впрочем, ARC неплох...

      Удалить
    30. «Замедление Си... В условиях узко ограниченных вычислительных ресурсов...

      то же самое.»
      -- Нет. Вы можете приспокойно использовать ООП и работу с файлами вообще с пустой секцией uses в программе. Т.е. имея в распоряжении только модуль System. В C++ же, например, работа с файлами не является частью языка. Здесь преимущества Pascal очевидны.

      «Обилие конструкций, синтаксически необходимых, но не нужных для обучения (например int main() - почему int?

      Издержки низкоуровневости.»
      -- Извините, но Pascal не менее нативен, но не требует этого.

      «Дальнейшее применение и востребованность полученных знаний. Знания специфики C++ востребованым может оказаться только при дальнейшем применении C++.

      Знание специфики С++ пригодится везде. Именно С++ по большей части сформировал концепции Java и C#.»
      -- Нет. От C++ (точнее - от C) в этих языках только некоторые синтаксические особенности. Идеологически Java ближе к Modula-2, как C# http://ru.wikipedia.org/wiki/C%2B%2B#.D0.92.D0.BB.D0.B8.D1.8F.D0.BD.D0.B8.D0.B5_.D0.B8_.D0.B0.D0.BB.D1.8C.D1.82.D0.B5.D1.80.D0.BD.D0.B0.D1.82.D0.B8.D0.B2.D1.8B.

      «В каком месте "монструозен" C++ я понимаю. Где Вы нашли "моструозность" Delphi - нет

      А там разве нет второй объектной системы, и 11 типов строк? А отсутствие возможности создания объектов на стеке»
      -- Ну, Вы выберите что-то одно... Либо две объектных системы, либо нельзя выделить в стеке :-) Классы первой категории (те, которые объявляются посредством кл. слова object) вполне могут размещаться и в стеке.
      В любом случае, обучению программированию это не мешает, а в случае вопросов объясняется элементарно (как и в случае со строками) эволюционным развитием языка.
      Далее, для выделения в Pascal (используемого для обучения) 11 типов строк нужно обладать не только фантазией, но ещё и быть ангажированным соответствующим образом. Да, я читал что-то в блогах на этот счёт, но автор так навязчиво передёргивал, что не запомнилось.

      «и при этом никакой поддержки автоматического управления ресурсами? Это между тем минус огромный»
      -- Для нативного языка это скорее плюс. Для обучения программированию и аккуратной работе с ресурсами - тем более.

      «Далее, предлагаю здесь вообще не обсуждать Delphi, поскольку обучение ведётся на Pascal, который стандартизован в той же степени, что и C++.

      Не вижу никакой ценности в Object Pascal в отрыве от Delphi.»
      -- А я - вижу. Delphi - не единственный диалект Pascal. При обучению программированию целью является демонстрация основных концепций, для чего Pascal подходит в большей степени, а C++ - в существенно меньшей.

      «Сейчас очень много молодых языков, которые давно обошли по всем параметрам free pascal (D, Go, Vala, CL, Ocaml, Haskell, например).»
      -- Обычно, после таких "сильных" утверждений приводят мотивацию, поскольку в противном случае эти утверждения воспринимаются как голословные. Кроме того, такие утверждения звучали и десять и двадцать лет назад, где над Pascal и C "возвышались" Ada, Simula и CLU, о которых сейчас никто не помнит.
      Специализированные языки лучше справляются со специализированными задачами. И жизнь их короче.

      «Если же не использовать Object Pascal после обучения, то почему бы сразу не учиться на Java/C#?»
      -- Почему уж тогда сразу не Python/Boo? - Потому, что люди должны иметь понятие о работе с ресурсами. Java и C# не нативные языки и работа с ресурсами там скрыта от программиста, что во многих случаях приводит к печальным последствиям.

      «Если речь не о Object Pascal, а о старом добром Pascal, то тут есть Си и это так же один из самых востребованных языков.»
      -- Речь идёт об Object Pascal, который используется для обучения программированию сейчас. C - язык без строгой типизации, а всё, что не типизировано (статически или динамически) - спецкурс.

      Удалить
    31. >Нет. Вы можете приспокойно использовать ООП и работу с файлами вообще с пустой секцией uses в программе. Т.е. имея в распоряжении только модуль System. В C++ же, например, работа с файлами не является частью языка. Здесь преимущества Pascal очевидны.

      Там об embedded системах, где рантайм будет мешаться. У Object Pascal здесь нет преимуществ.

      >Нет. От C++ (точнее - от C) в этих языках только некоторые синтаксические особенности. Идеологически Java ближе к Modula-2, как C#

      Как бы то ни было, после С++ Java даже учить не надо - вики, немного примеров и готово. То, что происходит "под капотом" понимается в полной мере. Причём не только на своём опыте.

      >Извините, но Pascal не менее нативен, но не требует этого.

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

      >-- Ну, Вы выберите что-то одно... Либо две объектных системы, либо нельзя выделить в стеке :-)

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

      >Далее, для выделения в Pascal (используемого для обучения) 11 типов строк нужно обладать не только фантазией, но ещё и быть ангажированным соответствующим образом

      Из статьи о новых возможностях XE4, в котором теперь единый тип для строк.

      >-- Для нативного языка это скорее плюс. Для обучения программированию и аккуратной работе с ресурсами - тем более.

      Для языка разработки - это огромный минус. Для обучения - нет. Здесь согласен.

      >При обучению программированию целью является демонстрация основных концепций, для чего Pascal подходит в большей степени, а C++ - в существенно меньшей.

      Для обучения низкоуровневому программированию чистый си или паскаль подходят лучше объектного паскаля, т.к в них меньше лишнего. Objective здесь вообще учить не нужно, оно не обязательно на таком уровне.

      >Специализированные языки лучше справляются со специализированными задачами. И жизнь их короче.

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

      >Почему уж тогда сразу не Python/Boo?

      Можно и питон, не обязательно мешать низкоуровневость и ООП.

      >C - язык без строгой типизации, а всё, что не типизировано (статически или динамически) - спецкурс.

      Так Си статически типизирован, в чём проблема? И сейчас он несравнимо востребованней паскаля.

      Удалить
    32. «Там об embedded системах, где рантайм будет мешаться. У Object Pascal здесь нет преимуществ.»
      -- Не уверен, хотя и не знаю о применениях Object Pascal в этом ключе.
      Но для обучения программированию (о котором мы с Вами говорим) отсутствие зависимостей для использования определённой функциональности - очевидный плюс.

      «Нет. От C++ (точнее - от C) в этих языках только некоторые синтаксические особенности. Идеологически Java ближе к Modula-2, как C#

      Как бы то ни было, после С++ Java даже учить не надо - вики, немного примеров и готово. То, что происходит "под капотом" понимается в полной мере. Причём не только на своём опыте»
      -- Про Ваш опыт мне ничего не известно. Мне известно, что если человек умеет программировать вообще, он сможет освоить любой язык. Поэтому, смысла в Вашем замечании не вижу.

      «Извините, но Pascal не менее нативен, но не требует этого.

      Если вам нужно объяснить низкоуровневое устройство программ, то чем может помешать объяснение кодов завершения программы?»
      -- Отвлечением на особенности C++ от основной темы, что способствует установлению "каши в голове", а не надлежащему усвоению материала. Я уже не раз говорил об этом ранее в этой теме разными словами.

      «-- Ну, Вы выберите что-то одно... Либо две объектных системы, либо нельзя выделить в стеке :-)

      И то и другое. Невозможность разместить на стеке объект современной объектной системы, в купе с отсутсвием автоматического управления ресурсами - минус архитектуры.»
      -- А чем Вам так *необходимо* "размещать в стеке объект современной объектной системы"? Вы уверены в том, что в этой ситуации требуется размещать его именно в стеке, и именно "в объекте современной объектной системы"? Что для этой цели не подойдут, к примеру, записи? Приведите пожалуйста мотивацию, поскольку в этой "фантастической" возможности я в своей практике на Delphi, с жизненной необходимостью не сталкивался.

      «Такие огрехи в системе типов С++ не прослеживаются. В этом плане С++ чище и продуманней.»
      -- Я не виду ни огрехов в Delphi, ни какой-то особенной продуманности в C++.
      Есть возможность сделать это в C++, такая же возможность есть в Object Pascal. Даже блажь "объект в стеке" может быть обеспечена средствами object.

      «Далее, для выделения в Pascal (используемого для обучения) 11 типов строк нужно обладать не только фантазией, но ещё и быть ангажированным соответствующим образом

      Из статьи о новых возможностях XE4, в котором теперь единый тип для строк.»
      -- Я говорил, что читал эту статью...

      «-- Для нативного языка это скорее плюс. Для обучения программированию и аккуратной работе с ресурсами - тем более.

      Для языка разработки - это огромный минус.»
      -- Пожалуйста - мотивируйте.
      Со своей стороны хочу напомнить, что для автоматического освобождения памяти в Delphi есть компонентная модель, интерфейсы и даже сборщики мусора (доводилось видеть такие проекты).

      Удалить
    33. «При обучению программированию целью является демонстрация основных концепций, для чего Pascal подходит в большей степени, а C++ - в существенно меньшей.

      Для обучения низкоуровневому программированию чистый си или паскаль подходят лучше объектного паскаля, т.к в них меньше лишнего. Objective здесь вообще учить не нужно, оно не обязательно на таком уровне.»
      -- Работа с ресурсами - это не низкоуровневое программирование. Это имеет прямое отношение к культуре и дисциплине программирования вообще. Далее, работа с ресурсами и ООП преподаётся в рамках единого куса, что правильно, поскольку при создании моделей и алгоритмов в их контексте привлечение абстракций в виде классов совершенно естественно и всеми приветствуется. Например, матричные вычисления, динамические структуры данных (списки, деревья и т.п).
      Для этого крайне желательно использовать один язык. И такой язык есть - это Object Pascal. В нём нет ничего лишнего, отвлекающего от сути и есть всё необходимое, чтобы проиллюстрировать все приёмы императивного программирования.

      «Специализированные языки лучше справляются со специализированными задачами. И жизнь их короче.

      Именно по этому я привёл языки общего назначения, которые уже обошли паскаль по популярности.»
      -- Они не обошли Object Pascal, ни даже просто Pascal по популярности. С точки зрения популярности, некоторые из них откровенно «птичьи» :-)
      Это не значит, что у них нет перспектив, или что эти языки — плохие. Совсем нет. Но в популярности Object Pascal они уступают существенно (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html), возможно, даже взятые вместе. Или мы с Вами сильно по-разному понимаем смысл терминов «язык общего назначения» и «популярность»?

      «Почему уж тогда сразу не Python/Boo?

      Можно и питон, не обязательно мешать низкоуровневость и ООП.»
      -- Обязательно. В противном случае, возникнет существенный пробел в образовании, а качество подготовки современных выпускников профильных ВУЗов и так, прямо скажем, не на высоте.

      «C - язык без строгой типизации, а всё, что не типизировано (статически или динамически) - спецкурс.

      Так Си статически типизирован, в чём проблема? И сейчас он несравнимо востребованней паскаля.»
      -- Я говорил о *строгой* (http://ru.wikipedia.org/wiki/Строгая_типизация), а не о статической типизации — есть заметная разница между ними. Проблема как раз в этой разнице, поскольку в C все типы совместимы по присваиванию, что для обучения программированию неприемлемо. Кроме того, в C отсутствует поддержка ООП.

      Удалить
    34. >-- Про Ваш опыт мне ничего не известно. Мне известно, что если человек умеет программировать вообще, он сможет освоить любой язык. Поэтому, смысла в Вашем замечании не вижу.

      Другое дело - насколько быстро. Ваши знания никак не помогут освоить haskell, например.

      >-- Отвлечением на особенности C++ от основной темы, что способствует установлению "каши в голове", а не надлежащему усвоению материала. Я уже не раз говорил об этом ранее в этой теме разными словами.

      Коды завершения не относятся к особенностям С++. То, что паскаль их скрывает - минус паскаля как низкоуровневого языка. В том числе для обучения.

      >Приведите пожалуйста мотивацию, поскольку в этой "фантастической" возможности я в своей практике на Delphi, с жизненной необходимостью не сталкивался.

      На практике не приходится дёргать динамическую память при использовании объекта в локальной области видимости. Это понижает вероятность ошибок и увеличивает производительность. Так же становится возможным хранить объекты в памяти одним блоком, что так же повышает производительность и позволяет оптимально использовать ресурсы.

      >Даже блажь "объект в стеке" может быть обеспечена средствами object.

      Объект, да не тот. =)

      >Со своей стороны хочу напомнить, что для автоматического освобождения памяти в Delphi есть компонентная модель, интерфейсы и даже сборщики мусора (доводилось видеть такие проекты).

      Сборщики мусора есть и для С++, а ARC интерфейсов даже близко не стоял со smart pointer'ами, это не говоря уже о лишнем описании.

      >Далее, работа с ресурсами и ООП преподаётся в рамках единого куса, что правильно

      Уверен, что совмещать ООП и низкоуровневое программирование для обучения не нужно. Тем более что ООП как абстракция ничем не лучше ФП, тогда почему ФП не совмещено в обучении с низкоуровневым программированием? А с приведёнными структурами данных легко справится язык и без ООП.

      >Они не обошли Object Pascal, ни даже просто Pascal по популярности. С точки зрения популярности, некоторые из них откровенно «птичьи» :-)

      TIOBE расчитывает рейтинги с помощью данных из поисковых систем. При этом он использует LPI, данные из которого следующие: http://lang-index.sourceforge.net/#grid

      Т.е названные мною языки находятся чуть выше уровня delphi, паскаль выше их всех. Почему паскаль популярен у поисковиков? Может потому, что его используют для обучения? =)
      Он настолько "популярен" для разработки, что его даже нет в списке языков Github(а список очень обширный). В тегах StackOverflow количество упоминаний так же крайне низко.
      Delphi же в рейтинге гитхаба проигрывает перечисленным языкам: http://blogerator.ru/uploads/pix2013/_files/redmonk-big-2013.png (чем правее тем лучше, отклонение от линии вверх - плохо).

      >в C все типы совместимы по присваиванию, что для обучения программированию неприемлемо.

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

      Удалить
    35. «-- Про Ваш опыт мне ничего не известно. Мне известно, что если человек умеет программировать вообще, он сможет освоить любой язык. Поэтому, смысла в Вашем замечании не вижу.

      Другое дело - насколько быстро. Ваши знания никак не помогут освоить haskell, например.»
      -- Интересно, что даёт Вам основания это утверждать? Откуда это Вы осведомлены о *моих* знаниях?

      «Коды завершения не относятся к особенностям С++. То, что паскаль их скрывает - минус паскаля как низкоуровневого языка. В том числе для обучения.»
      -- Pascal, как и C и C++ не являются низкоуровневыми языками (http://ru.wikipedia.org/wiki/%D0%9D%D0%B8%D0%B7%D0%BA%D0%BE%D1%83%D1%80%D0%BE%D0%B2%D0%BD%D0%B5%D0%B2%D1%8B%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F). Это не Assembler и не Forth. Давайте придерживаться общепринятой терминологии. Это примеры языков высокого уровня.
      Операции с кучей также не являются низкоуровневыми. Точнее - являются, но для языков сверхвысокого уровня, обычно снабжаемых GC, которые к этим операциям прямого доступа не имеют.
      Далее, "коды возврата" Pascal не скрывает - см. спецификацию процедуры Halt.

      «На практике не приходится дёргать динамическую память при использовании объекта в локальной области видимости. Это понижает вероятность ошибок и увеличивает производительность.»
      -- Простите, но я не понимаю, что такое «дёргать динамическую память при использовании объекта в локальной области видимости». Не «дёргайте» её, кто заставляет...
      Что понижает и что и как увеличивает?

      «Так же становится возможным хранить объекты в памяти одним блоком, что так же повышает производительность и позволяет оптимально использовать ресурсы.»
      -- Это можно и в Pascal. Примеры см., например, в реализации SDL/DeCAL.

      «Объект, да не тот. =)»
      -- Вам не угодишь... :-)
      Простите, но это всё общие слова. Приведите пример конкретной задачи где указанная Вами возможность (размещать объекты в стеке) необходима или отказ от неё ведёт к не оптимальной реализации. Пока Вы рисуете, как сами любите выражаться "сферическую проблему в вакууме". Не более того.

      «Со своей стороны хочу напомнить, что для автоматического освобождения памяти в Delphi есть компонентная модель, интерфейсы и даже сборщики мусора (доводилось видеть такие проекты).

      Сборщики мусора есть и для С++, а ARC интерфейсов даже близко не стоял со smart pointer'ами, это не говоря уже о лишнем описании.»
      -- Вы не задумывались над тем, почему тема "умных указателей" получила распространение, в основном, в C++? Почему в других языков достаточно указателей обычных? Далее, давайте не будем наши субъективные оценки подавать под видом фактов. Это я о том, что и рядом с чем не стояло. Это пустые слова и полемические приёмы. Давайте воздержимся от их применения.

      Удалить
    36. «Далее, работа с ресурсами и ООП преподаётся в рамках единого куса, что правильно

      Уверен, что совмещать ООП и низкоуровневое программирование для обучения не нужно.»
      -- Я уже говорил выше, что работа с ресурсами - это не низкоуровневое программирование. Объяснял почему. Если Вам угодно эти объяснения игнорировать, тогда попрошу Вас не повторяться с низкоуровневым программированием, поскольку убедительнее Ваши тезисы не становятся, а «ходить по кругу» мне не интересно.

      «Тем более что ООП как абстракция ничем не лучше ФП»
      -- ООП - не абстракция, а парадигма. Как и ФП. И они - для разного...

      «А с приведёнными структурами данных легко справится язык и без ООП.»
      -- Почитайте Страуструпа в его сообщении о C++, чем объектно-ориентированный язык отличается от не объектно-ориентированного. И зачем придумано ООП. Коротко: без объектов можно всегда сделать то же, что и с ними. Но с объектами программа получается проще и понятнее, а также легче поддаётся изменениям.

      «Они не обошли Object Pascal, ни даже просто Pascal по популярности. С точки зрения популярности, некоторые из них откровенно «птичьи» :-)

      TIOBE расчитывает рейтинги с помощью данных из поисковых систем.»
      -- Не думал, что основанием для своих заявлений о популярности Haskell, Ocaml, Vala и пр. Вы выбрали популярность того или иного языка на GitHub и в тэгах StackOwerflow. Простите — это не серьёзно. И даже — не смешно. Кстати, проверил — в отношении StackOwerflow Вы, мягко говоря, не совсем правы...

      «в C все типы совместимы по присваиванию, что для обучения программированию неприемлемо.

      Это не так, все типы становяться совместимы только при явном их приведении.»
      -- Вы здесь путаете C с C++, в который была добавлена строгая типизация и убрана совместимость с C.

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

      Удалить
    37. >-- Интересно, что даёт Вам основания это утверждать? Откуда это Вы осведомлены о *моих* знаниях?

      А ваши знания включают знания чистых функциональных языков? Тогда извиняюсь. =)

      >-- Вы не задумывались над тем, почему тема "умных указателей" получила распространение, в основном, в C++? Почему в других языков достаточно указателей обычных? Далее, давайте не будем наши субъективные оценки подавать под видом фактов. Это я о том, что и рядом с чем не стояло. Это пустые слова и полемические приёмы. Давайте воздержимся от их применения.

      Это потому, что для большинства современных языков такой проблемы не стоит. У них есть реализация GC. В C++ эту проблему решают с помощью смарт поинтеров, а то что они мощнее простого ARC - это факт, а не субъективная оценка(смартпоинтеры разные бывают под разные ситуации, к тому же ARC в дельфи не умеет weak ref?).

      >Простите — это не серьёзно. И даже — не смешно. Кстати, проверил — в отношении StackOwerflow Вы, мягко говоря, не совсем правы...

      У вас есть более "серьёзные" источники? А что не так в отношении "StackOverflow"?

      >-- Вы здесь путаете C с C++, в который была добавлена строгая типизация и убрана совместимость с C.

      Вы считаете что переменной "int i" в Си можно присвоить значение типа "struct T{}"? Если нет - то нам не о чём спорить: мы говорим о разных вещах. Если да - то вы ошибаетесь.

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

      Вы правы, обсуждение надо прекращать: оно сильно затянулось. =)

      Удалить
  2. Этот комментарий был удален автором.

    ОтветитьУдалить
  3. «Ох, бедные студенты :) Пичкают их тем, что в жизни вряд ли пригодится.»
    -- Очень интересно...

    «Да и к плохому приучаете ;) нехорошо воровать :)»
    -- Я не предлагаю никому воровать.

    «Почему бы действительно PyQt не использовать?»
    -- Потому, что на PyQt существенно проигрывает надлежащим образом организованной технологии разработки на Delphi, причём тем больше, чем более промышленным является решение.

    «Он не такой сложный, практичный, кроссплатформенный...»
    -- "Не такой" как что? ;-)

    «В общем, назовите хотя бы один плюс использования Delphi.»
    -- Delphi позволяет интерактивно создавать нативные приложения для Windows и ряда других платформ (хотя это пока под вопросом - понятно).
    Благодаря нативности, в реализации с использованием Delphi существует масса способов сделать её эффективной по производительности и ресурсам. Иными словами, на Delphi удобно реализовать ядро интерактивного приложения, которое может управляться скриптами Python.
    IMHO PyQt в большей степени подходит для написания более простых GUI-оболочек, что становится более очевидно, если поставить задачу обеспечить прозрачного переключения GUI-приложения с двузвенной (в Delphi за это отвечает Any/FireDAC) на многозвенную (kbmMW) архитектуру. Пока я не нашёл в рамках Python простого способа это эффективно обеспечить.
    Как-то не особенно хочется заниматься разработкой своего шлюза с интерфейсом PEP 249, обеспечивающего означенную прозрачность.
    Да и в контексте чисто элементов управления в PyQt далеко не всё так хорошо, как в Delphi. Например, реализацией текстового процессора (TRichView в Delphi) для PyQt я не обнаружил. Не говоря о том уже, что требуется DB-aware компонент.
    Но *пока* означает именно "пока". Я внимательно слежу за развитием Python и его окружения.

    «Не нравится Qt, есть gtk, wxWidgets на худой конец.»
    -- Да, есть. Но к сожалению, комплексного, эффективного в плане производительности, и простого решения вопросов к интерфейсу я не обнаружил и там.
    С дизайнером форм, кстати, тоже не всё гладко. Если в случае Delphi был широкий задел в плане компонентов, которые, на худой конец, можно было купить, то дизайнер PyQt и wxWidgets, к примеру, выглядят крайне убого в сравнении с тем, что есть в Delphi. Опять же, полностью отсутствует удобный binding с БД, в Delphi это db-aware компоненты, которые снимаю кучу головной боли по кодированию связи модели с представлением.

    «Не нравится python (щито?!?!) - есть биндинги к php, ruby, c++ накрайняк.»
    -- Python нравится гораздо больше того, что Вы обозначили в качестве альтернативы ему :-)

    «Если раньше pascal был хорошим учебным языком, то теперь пора это пересмотреть.»
    -- Почему? IMHO он и сейчас марку вполне себе держит.

    «Кстати, а студентов не заставляете свой репозиторий для решения этой задачи вести?»
    -- Заставляю :-) Для текущего потока репозиторий должен быть Subversion, следующему потоку буду рекомендовать Hg/Git/Bazaar на выбор.
    И кстати, в репозитории должна быть не только *эта* задача, но и все остальные :-)

    ОтветитьУдалить
    Ответы
    1. В догонку...
      Но Виктор, я совершенно не хочу, чтобы Вы подумали, что я "ругаю" или как-то негативно настроен к PyQt. Это отличный проект, в котором я сейчас вижу только одно, но существенное препятствие к тому, чтобы садиться и программировать: отсутствие элементов управления, связанных с данными, что создаёт излишнюю нагрузку на слой контроллера в MVC/MVP.

      Это преодолимое препятствие, но:
      1. "Допиливать" придётся немало, уж точно это не под силу одному фрилансеру
      2. Без этого использование PyQt будет чем-то похоже на web-программирование с шаблонами, сводящееся к необходимости "вручную" заполнять элементы управления Qt из модели (таблиц БД).
      И ORM здесь плохой помощник, если Вы хотите, чтобы GUI-интерфейс к БД был динамическим, т.е. чтобы одно приложение могло работать с почти любыми БД.

      Кстати, если у Вас есть какая-то информация о соответствующих фреймворках для PyQt - мне было бы очень интересно ознакомиться с ней.

      Удалить
    2. Ну и, пожалуй, самое главное я обозначу напоследок.
      Видите-ли Виктор, у меня складывается ощущение, что Вы пытаетесь сузить университетское образование до овладения конкретными практическими навыками, изучения перспективных (или кажущимися) на текущий момент фреймворков.
      Я так не думаю. Университет - не техникум и даже - не политехнический институт. Студент университета (в идеале) должен овладевать метанавыками, понимать, что откуда берётся и почему. Такой выпускник университета - не кодер (хотя и может им стать, при желании), это человек с относительно (остальных) широким кругозором, аналитическим складом ума и, пусть и базовой, но математической подготовкой.
      В свете этого, изучение принципов, на которых основаны обозначенные Вами фреймворки (PyQt, в частности) гораздо важнее, чем способы применения этих фреймворков или детали их устройства. В этом плане Delphi, который вынуждает работать на более низком уровне (и добиваться большего при этом) - IMHO более подходящий инструмент, чем Python, знакомство с которым, конечно же, также необходимо в канве скрипт-языков вообще.
      Это же касается и Pascal, как языка, с которого следует начинать изучение кодирования алгоритмов. Конечно, на скрипт-языке подмножество таких алгоритмов (я имею ввиду - управление чем-либо, GUI, устройством, например) кодировать проще, но те частности (например, работа с конкретными типами, ресурсами и т.д.) которые скрипт-язык скрывает, в Pascal "выпячены наружу" и их нельзя игнорировать.
      Освоивший Pascal органично воспользуется и Fortran и C++ и Delphi наконец. Если ему доведётся программировать на Java или C# - у него тоже не возникнет особенных проблем. Даже Assembler будет воспринят должным образом (разумеется, после освоения соответствующей системы понятий), поскольку в сущности, там нет ничего нового в сравнении с Pascal, только сильно занижен уровень операций.
      Если же переходить с управляемого кода к нативному, то проявляется целый класс явлений, которые приходится учитывать, соответствующая техника программирования кажется совершенно чуждой, и человеку проще бежать от этого, чем разбираться с ней. Такое часто случается вследствие отсутствия того базового образования, элементом которого является, в частности, применение Pascal.
      Разумеется, всё сказанное выше - моё скромное IMHO.

      Удалить
    3. Сколько буковок... В порядке стека:
      >Видите-ли Виктор, у меня складывается ощущение, что Вы пытаетесь сузить >университетское образование до овладения конкретными практическими навыками, изучения >перспективных (или кажущимися) на текущий момент фреймворков.
      Нет! Университетское образование для меня в первую очередь - умение обучаться, декомпозировать задачу и понимать что же не понятно. PyQt я предлагаю изучать потому что работать с ним проще, чем с Delphi. Его проще установить, расширить. Здесь будет меньше оверхеда на разработку - можно будет сосредоточиться именно на задаче.
      Pascal хороший язык для обучения, но не стоит с него начинать. ИМХО, что такое переменная, циклы, условия и пр. лучше изучать на python, а только на следующем курсе переходить на c++/pascal. Вот тогда-то и появится эта "техника программирования". Кстати, вкупе с ассемблером на этом же курсе будет ещё лучше.
      Ладно, главное - не убить интерес человека к программированию :) Не перегнуть палку с "хардокрностью".

      Удалить
    4. Зачем "перепиливать" Qt? Это хороший фреймворк, на нём написано дофига софта, причём не только под linux. Мне кажется, что сначала стоит разобравться как им пользоваться, а уже потом решать что нравится или не нравится. Кстати, недавно столкнулся с ПО, которое ставят моей маме на работу (она врач) - http://samson-rus.com/. Может, оно и не сопоставимо с размерами Ваших приложений, но и лет-то еиу немного :) Вырастет :) Причём, насколько я понимаю, это коммерческий проект на GPLv3 O_o.

      Удалить
    5. >>«Да и к плохому приучаете ;) нехорошо воровать :)»
      >>-- Я не предлагаю никому воровать.
      А как Вы предлагаете по-честному выполнять задание? В универе? Так там не пробиться в аудиторию. Домой покупать? Дороговато выйдет.

      >>Благодаря нативности, в реализации с использованием Delphi существует масса способов сделать её эффективной по производительности и ресурсам.
      Вам нужно материал разобрать или в продакшн выпустить?

      >>Иными словами, на Delphi удобно реализовать ядро интерактивного приложения, которое может управляться скриптами Python.
      Т.е. сделать из Delphi-программы некую платформу для выполнения Python-кода?

      >>PyQt в большей степени подходит для написания более простых GUI-оболочек.
      Как-то миру linux этого более чем достаточно. По поводу "серьёзной программы" привёл ссылку выше. К тому же элементов для Qt море. Нужен текстовый редактор? QScintilla! Даже с подсветкой синтаксиса. Есть ещё ribbon-контролы: http://qtcoder.blogspot.ru/2012/11/qtitan-ribbon-10.html (первое, что нашёл).
      Биндинг к БД: http://qt-project.org/doc/qt-4.8/qdatawidgetmapper.html#details.
      Интерфейс также, как и в Delphi, хранится в XML.

      >>следующему потоку буду рекомендовать Hg/Git/Bazaar на выбор.
      Тогда смею рекомендовать hg - он проще и логичнее, бесплатные репы можно сделать на bitbucket.org. Кстати, в качестве оффтопика: коаны гита (http://habrahabr.ru/post/175943/).

      Удалить
    6. «Сколько буковок... В порядке стека:»
      – Ну, уж сколько получилось :-)
      Пока мне интересно, я готов писать подробно.
      Вы подняли достаточно характерный спектр вопросов, и мне показалось, что на них нужно ответить подробно.

      «Видите-ли Виктор, у меня складывается ощущение, что Вы пытаетесь сузить университетское образование до овладения конкретными практическими навыками, изучения перспективных (или кажущимися) на текущий момент фреймворков.
      Нет! Университетское образование для меня в первую очередь - умение обучаться, декомпозировать задачу и понимать что же не понятно.»
      – Честно говоря я не увидел в Ваших словах ничего, что противоречит сказанному мною.

      «PyQt я предлагаю изучать потому что работать с ним проще, чем с Delphi. Его проще установить, расширить. Здесь будет меньше оверхеда на разработку - можно будет сосредоточиться именно на задаче.»
      – Ну, если Вы взялись это утверждать, то поясните: за счёт чего достгаются обозначенные Вами преимущества. Я кстати, не разделяю здесь Вашу точку зрения, хотя и готов отдать Qt должное.
      В частности, я пока не понимаю, в чём Вы видите упрощение работы с Qt в сравнении с Delphi, какие сложности в установке Delphi Вы видите, а также что препятствует (в сравнении с Qt) расширять функциональность VCL/FMX. Ну и про дополнительный «оверхед» в Delphi тоже хотелось бы получить представление.
      Пока всё означенное выглядит следствием Ваших личных предпочтений, а не объективной оценкой.

      «Pascal хороший язык для обучения, но не стоит с него начинать. ИМХО, что такое переменная, циклы, условия и пр. лучше изучать на python, а только на следующем курсе переходить на c++/pascal. Вот тогда-то и появится эта "техника программирования". Кстати, вкупе с ассемблером на этом же курсе будет ещё лучше.»
      – IMHO с Python/LUA/Ruby можно начинать изучение программирования в школах.
      Но в ВУЗе требуется больший уклон в нативность, иначе эта нативность окажется просто за рамками рассмотрения. Здесь только два варианта: C++ и Free Pascal/Delphi.
      C++ изобилует массой технических подробностей, IMHO вызванных, в большей степени, особенностями устройства и развития этого языка. В Object Pascal более прозрачный синтаксис и он объективно проще, что делает его более предпочтительным в моих глазах.

      «Ладно, главное - не убить интерес человека к программированию :) Не перегнуть палку с "хардокрностью".»
      – Если речь идёттолько о поддержке интереса к программированию, то IMHO Python будет вполне достаточно :-)

      «Зачем "перепиливать" Qt? Это хороший фреймворк, на нём написано дофига софта, причём не только под linux. Мне кажется, что сначала стоит разобравться как им пользоваться, а уже потом решать что нравится или не нравится»
      – Вообще-то я не предлагал что-либо «перепиливать» :-)

      Удалить
    7. ««Да и к плохому приучаете ;) нехорошо воровать :)»
      -- Я не предлагаю никому воровать.
      А как Вы предлагаете по-честному выполнять задание? В универе? Так там не пробиться в аудиторию. Домой покупать? Дороговато выйдет.»
      Для экспериментов, а учебный курс не предполагает большего, можно использовать Trial-версию в общем доступе.

      «Благодаря нативности, в реализации с использованием Delphi существует масса способов сделать её эффективной по производительности и ресурсам.
      Вам нужно материал разобрать или в продакшн выпустить?»
      – Разобрать материал, но так, чтобы в нём были элементы «продакшн».
      Зачем рынку «программисты» воспитанные на «академических» примерах?

      «Иными словами, на Delphi удобно реализовать ядро интерактивного приложения, которое может управляться скриптами Python.
      Т.е. сделать из Delphi-программы некую платформу для выполнения Python-кода?»
      – Да. Но всё-таки мне больше импонирует моё определение — ядро системы.
      Это Qt – платформа, или фреймворк. Поскольку ничего, кроме общей функциональности фреймворк не содержит. Предполагается, что бизнес-логика будет реализована пользователем фреймворка.
      Когда я говорю о ядре системы, я имею ввиду, что существенная часть модели предметной области реализована на Delphi, но вот управление этой реализацией, во многих случаях можно возложить на Python.

      «PyQt в большей степени подходит для написания более простых GUI-оболочек.
      Как-то миру linux этого более чем достаточно. По поводу "серьёзной программы" привёл ссылку выше.»
      – Конечно же, я внимательно изучу то, на что Вы указали.
      Вместе с тем, к PyQt у меня есть ряд вопросов, связанных с производительностью и с работой с данными.

      «К тому же элементов для Qt море. Нужен текстовый редактор?»
      – Ну, их «море» не только в Qt. Кстати, текстового процессора, функционально сравнимого с TRichView для Qt я не видел. Хотя и не исключаю, что где-то он может быть. А нам он очень даже необходим.

      «Биндинг к БД: http://qt-project.org/doc/qt-4.8/qdatawidgetmapper.html#details.»
      – Да, это очень интересно. Но там сразу бросаются в глаза некоторые архитектурные особенности. Но не факт, что это плохо.

      «Интерфейс также, как и в Delphi, хранится в XML.»
      – Ну, в Delphi совершенно нет никакой проблемы хранить «интерфейс» в XML :-)

      «следующему потоку буду рекомендовать Hg/Git/Bazaar на выбор.
      Тогда смею рекомендовать hg - он проще и логичнее, бесплатные репы можно сделать на bitbucket.org. Кстати, в качестве оффтопика: коаны гита (http://habrahabr.ru/post/175943/).»
      – Hg мне тоже больше нравится :-)
      Но IMHO — это не принципиально.

      Удалить
    8. http://store.embarcadero.ru/catalog/rubric/70 - академ. лицензии

      Удалить
    9. «http://store.embarcadero.ru/catalog/rubric/70 - академ. лицензии»
      -- Спасибо Александр.
      Только боюсь, эти академические лицензии не будут способствовать расширению популярности платформы Emabarcadero.
      Ну представьте, что в Университете есть только две аудитории с 20 компьютерами в каждой (это чушь, поскольку их намного больше, это справедливо, скорее, для школы), предположим, что решили ограничиться лицензией RAD Studio XE4 Professional (academic) по 3 241,32 руб. за штуку. Для 40 компьютеров потребуется 140 000 руб. Ну, школы у нас сразу "идут лесом", ВУЗу эта сумма, разумеется, по плечу, но вот только зачем ВУЗу платить, если можно совершенно официально взять у Microsoft бесплатно? - Правильно Александр, не зачем.

      Ну и ещё, как я уже обозначил выше. Это для аудиторий подойдут "академические лицензии", а для студентов, чтобы они могли проникнуться за своим ноутбуком преимуществами платформы Embarcadero при написании курсовых и дипломных работ? Что им предлагается? Тоже по "три рубля с носа"? Простите, но они также решат свои задачи посредством Java/C#. А "три рубля" потратят на еду, одежду, гаджеты или дискотЭку. Смею Вас заверить, именно это сейчас и имеет место.

      Поймите Александр (я смотрел на Ваше "эпическое сражение" здесь: http://habrahabr.ru/post/154607/), это не ВУЗам и не студентам нужны продукты Embarcadero - они прекрасно без них обходятся. Это Embarcadero *необходимы* ВУЗы и студенты (и школьники с их учителями, кстати), чтобы не превратиться окончательно в экзотическую платформу.

      Удалить
    10. Простите, не 140 000 руб., а 129 652,80 руб.
      Но не вижу, как это изменит общую картину ;-)

      Удалить
    11. "Это Embarcadero *необходимы* ВУЗы и студенты (и школьники с их учителями, кстати), чтобы не превратиться окончательно в экзотическую платформу."

      -- тут пожалуй - соглашусь.

      Удалить
    12. Вот, то есть возвращаясь к теме лицензий - их нет ни у ВУЗа, ни у студентов. Trial работает всего один месяц, то есть, повторюсь, честно нет вариантов выполнить задание.

      Удалить
    13. Установка PyQt занимает максимум 5 минут и делается одной командой. Установка Delphi - ещё тот геморрой: скачать (если нет дистрибутива), найти ключ, выбрать что ставить, запустить установку, скомпилить... В общем, хорошо, если в пару часов уложитесь ;) Про оверхед: я говорю про PyQt, а не про чистый Qt => я опираюсь на язык (pascal vs python). Согласитесь, что разработка на python проще ;) На Qt + C++ работа, конечно же, пойдёт тяжелее :)

      >> IMHO с Python/LUA/Ruby можно начинать изучение программирования в школах.
      Увы, не все на первом курсе умеют программировать. По поводу pascal vs C++ - пока склоняюсь, как ни странно, к C++. У нас на 5ом курсе был хардкор: нам немцы преподавали компьтерную графику на C++. Ничего, даже интересно было :) К тому же знание ОС в большей мере подразумевает уменее читать код на плюсах - всё равно придётся выучить.

      Удалить
    14. «Вот, то есть возвращаясь к теме лицензий - их нет ни у ВУЗа, ни у студентов. Trial работает всего один месяц, то есть, повторюсь, честно нет вариантов выполнить задание.»
      -- Виктор, ну давайте не будем играть в "честность" :-) "кто из вас без греха, первый брось на нее камень" (Ин.8:1)

      «Установка PyQt занимает максимум 5 минут и делается одной командой. Установка Delphi - ещё тот геморрой: скачать (если нет дистрибутива), найти ключ, выбрать что ставить, запустить установку, скомпилить... В общем, хорошо, если в пару часов уложитесь ;)»
      -- Виктор, по-моему, это не серьёзно. К тому же, мин. 20 в пределе.

      «Про оверхед: я говорю про PyQt, а не про чистый Qt = я опираюсь на язык (pascal vs python). Согласитесь, что разработка на python проще ;) На Qt + C++ работа, конечно же, пойдёт тяжелее :)»
      -- Разработка на Python проще, вместе с тем, есть серьёзные основания полагать, что одним Python и Qt дело не обойдётся, если требуется промышленное решение.

      «По поводу pascal vs C++ - пока склоняюсь, как ни странно, к C++. У нас на 5ом курсе был хардкор: нам немцы преподавали компьтерную графику на C++. Ничего, даже интересно было :) К тому же знание ОС в большей мере подразумевает уменее читать код на плюсах - всё равно придётся выучить.»
      -- "Выучить C++" - совершенно не проблема. Но программирование лучше изучать на Pascal, поскольку он, с одной стороны, позволяет проиллюстрировать всё, что есть в C++, но без "порочных наклонностей" (излишних подробностей и деталей, когда в них совершенно нет потребности).
      Кроме того, "многопарадигменность" C++, которой так хвалятся его поборники, совершенно не способствует анализу кода на этом языке. Я говорю о массовом использовании перегрузки операторов для достижения самых неожиданных целей, жонглированием пространствами имён, "фокусы" с указателями и прочие вещи, совершенно не способствующие учебному процессу. Это я к тому, что безобразный код на C++ написать много проще, чем на Pascal. А сам по себе этот язык проигрывает в простоте, пожалуй, любому другому.
      Знакомство с C++ необходимо, но уже в конце, а не в начале. И вполне можно ограничиться именно знакомством, оставив изучение на спецкурсы.
      Разумеется, всё сказанное - моё личное IMHO.

      Удалить
    15. >>-- Виктор, по-моему, это не серьёзно. К тому же, мин. 20 в пределе.
      Мда? Значит, Баркадировцы потрудились над инсталлятором. Или 20 минут это на SSD винт? :)

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

      >>А сам по себе этот язык проигрывает в простоте, пожалуй, любому другому.
      Не, есть ещё perl :) Там непонятно где регэксп, а где код :)

      C++, наверно, самый мощный инструмент. С ним можно творить тотальное добро или сеять всюду быдлокод. Причём первые пару лет работы с ним как ни крути, а добра будет всего пару капель :) Хотя макосеки вон до сих пор ничего окромя ObjectiveC не признают. В пылу споров мы забыли про новичка - C#. Там тоже есть указатели, синтаксис не так сложен как C++, но в то же время схож с ним. Там даже ассемблерные вставки реализованы! (Сам в шоке, по идее дальше CLR код выходить не должен) Кстати, я бы ещё какой-нибудь функциональный язык ввёл для срыва шаблона, но это уже отдельная история.

      А C++ всё-таки оставил, хотя бы в контексте других прикладных задач. Меня очень впечатлили лекции Яндекса для сисадминов. По-моему, там, где рассказывалось про сетевые протоколы докладчик не был уверен в своих ответах на вопросы. В итоге полез в исходники ядра, нашёл нужные строчки и показал как что есть на самом деле. Кстати, лекции очень рекомендую, особенно, "сисадминам".

      К чему я всё это? Да всё к тому же - выбор инструмента под задачу. Надо объяснить что такое массив, переменная, функция, объект, некоторые структуры данных - проще это сделать на Python. Изучить алгоритмы (например, сортировки) - концептуальнее, IMHO, на ФЯП. Работа с указателями и тут же как оно всё внутри устроено - C++ с asm вставками.

      Удалить
    16. «-- Виктор, по-моему, это не серьёзно. К тому же, мин. 20 в пределе.
      Мда? Значит, Баркадировцы потрудились над инсталлятором. Или 20 минут это на SSD винт? :)»
      -- Скорее - первое :-) Два часа было с Delphi 2007 при установке December Update на Windows XP :-)

      «-- Разработка на Python проще, вместе с тем, есть серьёзные основания полагать, что одним Python и Qt дело не обойдётся, если требуется промышленное решение.
      Если потребуется промышленное решение на помощь приходит (та-дам) C++, на котором можно написать нужную библиотеку.»
      -- В означенной ситуации и Delphi может на помощь прийти :-)
      Но к сожалению, не всё сводится к отсутствию "нужной библиотеки". Само ядро системы должно быть оптимизировано по производительности. Если это ядро - на Python, то соответствующую оптимизацию выполнить невозможно.

      «А сам по себе этот язык проигрывает в простоте, пожалуй, любому другому.
      Не, есть ещё perl :)»
      -- Не к ночи будет помянут... :-)

      «C++, наверно, самый мощный инструмент. С ним можно творить тотальное добро или сеять всюду быдлокод.»
      -- Мне, к сожалению, с добром сталкиваться не приходилось... :-)

      «В пылу споров мы забыли про новичка - C#. Там тоже есть указатели, синтаксис не так сложен как C++, но в то же время схож с ним. Там даже ассемблерные вставки реализованы!»
      -- Там те же проблемы, что и с Java. Язык отлично подходит для enterprise-решений, но он ограничивает платформой, причём сильнее, чем Java.

      «А C++ всё-таки оставил, хотя бы в контексте других прикладных задач.»
      -- Я не призываю к геноциду :-)

      «К чему я всё это? Да всё к тому же - выбор инструмента под задачу.»
      -- IMHO, это общие слова Виктор.
      Есть достаточно универсальные инструменты, комбинация которых подходит для решения большинства задач. По крайней мере, в той области, в которой я работаю.
      У меня это - Delphi (пока) и Python.

      Удалить
    17. >>Если это ядро - на Python, то соответствующую оптимизацию выполнить невозможно.
      Вот я и предлагаю вынести их в dll.

      >>-- Мне, к сожалению, с добром сталкиваться не приходилось... :-)
      Ну что Вы, Торвальдс со Столлманом творят исключительно добро :)))

      >>-- Там те же проблемы, что и с Java. Язык отлично подходит для enterprise-решений, но он ограничивает платформой, причём сильнее, чем Java.
      А в рамках учебного курса нельзя ли этим пренебречь? Либо опять же я что-то недопонимаю. Можете привести пример, где Delphi нельзя заменить C#?

      Удалить
    18. "К тому же элементов для Qt море. Нужен текстовый редактор"

      Я когда-то пытался портировать Эверест под QT И Kylix. Но бросил. Не видя перспективы.

      Удалить
    19. «"К тому же элементов для Qt море. Нужен текстовый редактор"

      Я когда-то пытался портировать Эверест под QT И Kylix. Но бросил. Не видя перспективы.»
      -- Как мне показалось, "Эверест" это скорее текстовый процессор.
      Кстати, а почему Вы не увидели перспектив? Моя организация, например, совершенно официально приобрела лицензию на TRichView. Если бы он, в сущности, не был бы единственным набором компонентов на рынке, претендующим называться текстовым процессором, у нас был бы выбор.
      В мире Linux/Qt IMHO аналогично. М.б. и Nokia проявила интерес к Вашей разработке, поскольку, как мне показалось (убедиться не было времени), у них подобного нет.

      Удалить
    20. Бросил - потому, что это проприетарная разработка.

      А работодателю - это неинтересно.

      Другое дело - если "взять идеи и написать с нуля".

      Удалить
    21. "Моя организация, например, совершенно официально приобрела лицензию на TRichView."

      -- тем более, что она стоит вполне себе "не жадно".

      TRichView - хорошая кстати разработка. Я её детально изучал.

      Удалить
    22. " поскольку, как мне показалось (убедиться не было времени), у них подобного нет."

      -- поверьте. Эверест - неплох. Он загружает, показывает и редактирует справочник БИК (банковских идентификационных кодов). С чем - не всякий Word справляется.

      Удалить
  4. >Тут не всё так просто, тем более, что подход QT лично мне намного понятнее. Ну, не просто поверить, что "самописное" воспроизведение элементов управления в среде конкретной ОС окажется проще и стабильнее, чем использование API, предоставляемой самой ОС.

    Qt не использует API, предостовляемое ОС. Он сам всё рендерит. Такое API вообще не всякая ОС может предоставить.

    >kbmMW

    Можно кратенько, пожалуйста: что это и зачем? В чём профит? =)

    ОтветитьУдалить
    Ответы
    1. Масса компонент - сами рендерят.

      Наши компоненты - ВСЕ сами рендерят.

      Удалить
  5. «Son of a gun 16 сентября 2013 г., 7:29

    Тут не всё так просто, тем более, что подход QT лично мне намного понятнее. Ну, не просто поверить, что "самописное" воспроизведение элементов управления в среде конкретной ОС окажется проще и стабильнее, чем использование API, предоставляемой самой ОС.

    Qt не использует API, предостовляемое ОС. Он сам всё рендерит. Такое API вообще не всякая ОС может предоставить.»
    -- Вы ошибаетесь (http://qt-project.org/forums/viewthread/29102/#130352):
    <<<...Соответственно, как виджеты, так и графические примитивы реализованы в Qt непосредственно через системный интерфейс каждой платформы.

    В этом нетрудно убедиться, заглянув в исходный код: на каждой платформе реализация всех графических функций заканчивается кодом, который непосредственно обращается к системному интерфейсу. Например, на Mac графические примитивы обращаются к Core Foundation.>>>

    «kbmMW

    Можно кратенько, пожалуйста: что это и зачем? В чём профит? =)»
    -- Это библиотека (http://www.components4programmers.com/products/kbmmw/), упрощающая создание приложений в многозвенной архитектуре. Две другие популярные реализации - DataSnap от Borland/Embarcadero (http://www.base.vingrad.ru/view/2766-Tehnologiya-DataSnap) и RemObjects Data Abstract (http://www.remobjects.com/da/).
    От последних отличается тем, что дешевле и в ряде мест обладает большей гибкостью. В частности, её средствами несколько проще реализовать связь с серверным приложением, реализованным на Java.

    ОтветитьУдалить
  6. >Вы ошибаетесь

    Погуглил на эту тему. Раньше Qt "эмулировал" внешний вид, используя темы. Сейчас нативные элементы используются там, где возможно. Тем не менее Qt умеет рисовать не хуже операционной системы. =)

    >Это библиотека (http://www.components4programmers.com/products/kbmmw/), упрощающая создание приложений в многозвенной архитектуре.

    Понятно, спасибо. =)

    ОтветитьУдалить