singlepost

Рефакторинг, Джава и Руби. << На главную или назад  

Паскаль мертв?
В последнее времяо паскале стали как то забывать. Сейчас уже никто не гордится что кодит под Delphi, уже не так слышны вопли типа Pascal Forever!, или Speed is Delphi.С 2007 года в турнирах ACM на Pascal-e уже не пишут…
Что это? начало конца?
Лично мне Object Pascal очень нравится. Я понимаю что это далеко не С++. Но кто сказал что С++ идеален? Есть определенный круг задач, где Delphi является лучшим решением.

Pascal не альтернатива С++. С++языккоторый должен знать каждый программист.Но профессионал должен всегда подбирать инструментарий адекватный проблеме. Зачем палить по вороне из Ракеты ПВО? Не проще ли взять воздушку? Сэкономив при этоми свои силы,и средства заказчика и бесценное время…

Позиционируя Pascal вмире языков программирования, я ставлю его сразу за С++. А кто еще достоин?Java? C его псевдопереносимостью и идиотским сборщиком мусора? Лучше написать прогу, котораябыстро работает хотя бы в одной OS, чем писать монстра который запускается 500 мин… о visual basic я вообще не буду говорить.

Прошу всех читателей оставить в коментах свое мнение относительноязыка Pascal, фирмыBorland (котрая является единственным конкурентом Microsoft в этом сегменте), и прдукта Delphi в частности.

P.S.
Вопрос для размышления: А что было бы если Microsoft поддерживалObject Pascal (как яву например)?

152 ответов в теме “Рефакторинг, Джава и Руби.”

  1. 136
    Жека Кирпичев ответил:

    По-моему, в Фаулере, как и в "Паттернах", читать особо нечего – эти книги нужны только ради терминологии, чтобы сказать "А теперь сделаем extract superclass" или "А тут у нас абстрактная фабрика".

  2. 135
    Людмила Уланова ответил:

    Без рефакторинга жить нельзя, ИМХО.
    Всем советую почитать Фаулера. :)

    (P.S. Тоже увидела интересную тему в конце списка, решила приподнять :) )

  3. 134
    Олег Андреев ответил:

    Да и конверсия пропертей в методы тоже не требуется. Но вот то, о чем ты говоришь, это скорее из области макросов. Это есть в емаксе, текстмейте и других редаторах. Т.е. нечто, случающееся по хоткею. У текстмейта, к примеру, очень богатые возможности чтобы за секунду делать extract variable. Просто я такими вещами не пользуюсь: программа рисуется пару часов на бумажке, так что лишние секунды на кодирование потратить не проблема. И концентрация тоже не пропадает.

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

  4. 133
    Жека Кирпичев ответил:

    Я скорее даже веду речь не столько о "тяжеловесных" рефакторингах, а о куче полезных мелочей, которые помогают не задумываться вообще ни о чем, кроме главного.
    //www.jetbrains.com/idea/features/refactoring.html
    //www.jetbrains.com/idea/documentation/intentio...

    Кстати в Руби отпадает необходимость в таких вещах как Use interface where possible, это бесспорно хорошо.

  5. 132
    Жека Кирпичев ответил:

    Насчет extract variable – я его в 90% случаев делаю когда у меня b.get().f(5) написано всего 1 раз и я хочу использовать его второй раз – и делаю это за 1 секунду вместо 5 секунд (cut-n-paste + написать объявление переменной) вручную. Хочется, чтобы такие операции были незаметными, и 5 секунд вместо 1 в пылу кодирования играют огромную роль – 1 секунда проходит на уровне рефлексов, а 5 секунд снижают концентрацию еще секунд на 10.

  6. 131
    Олег Андреев ответил:

    Смотрю вот это:
    //www.refactoring.com/catalog/index.html

    и пока не вижу примера, когда нужно и возможно автоматическое преобразование кода.

  7. 130
    Олег Андреев ответил:

    Я не про плохо/не плохо, а про рефакторинг. Расскажи подробнее, мне интересно.

    Вот про a.foo(b.get().f(5)); и c.bar(b.get().f(5)); Речь о том, чтобы в переменную запихнуть b.get().f(5)? Приведи пример реального кода, а то мне кажется, что необходимость в автозамене такой ерунды может возникнуть, если ты, написав второй раз в коде "b.get().f(5)", не выделил оба таких вызова в переменную или метод сразу, а подождал пока их станет 10 во всех местах.

    Т.е. я пока не улавливаю необходимость в крутых автозаменах по всему проекту (даже джава-).

  8. 129
    Олег Андреев ответил:

    Дело в том, что интерфейс у объектов в джаве реализован через 1) вызов методов 2) чтение пропертей 3) запись пропертей. Это отражено в JNI и в рефлексиях. Когда ты пишешь языковой мост из JavaScript в Java, тебе нужно учитывать все три интерфейса (у нас для пропертей даже отдельные траверсеры были: в джаве и плюсах). Сейчас я прикинул, сколько кода пропало бы если б не было пропертей и получилось 33%.

    В то же время у руби интерфейс объекта реализован через единственный obj.send(message, *args), что существенно облегчает жизнь. Например, мост Erlang-Ruby Юра Рашковский нахачил за одну ночь. Потому что у них идеологически похожие интерфейсы: посылка сообщений. Хотя инфраструктуры языков еще более далекие друг от друга, чем у плюсов, джаваскрипта и джавы.

    //novemberain.com/2007/5/6/make-things-easier

  9. 128
    Жека Кирпичев ответил:

    Драй-то драем, но если у меня вся программа про Юзеров, к примеру, то концепция User неизбежно встретится в коде много раз, как ни выдраивайся.
    Extract variable нужен настолько часто, что я даже затрудняюсь подобрать примеры :) Написано что-то типа a.foo(b.getAnything().f(5)); понадобилось сделать еще и c.bar(b.getAnything().f(5)). Сделал extract variable.
    В общем, предлагаю свернуть дискуссию: раз у меня опыта в Руби нет, а у тебя есть, то тебе виднее, плохо там (опять же, тебе) без рефакторинга или не плохо :) Мне бы в java было без него очень плохо.

  10. 127
    Евгений Михайлин ответил:

    Олег, я не очень разобрал вот это "А еще нам удалось бы сэкономить 33% кода, если бы в Джаве не было дурацкого понятия property"
    Можно подробнее?

  11. 126
    Олег Андреев ответил:

    К тестам рефакторинг имеет такое отношение: Find & Replace in project (с регэкспами, разумеется) может в паре мест поранить приложение. Тесты выявят эти места.

    Насколько мне известно, в руби очень нечасто приходится менять что-то в 1000 мест. Все-таки DRY на то и DRY.

    Впрочем, тем злостным рефакторингом, о котором ты говоришь, я никогдане занимался. Если ты подробно расскажешь когда, зачем и как происходит extract variable или add constructor parameter, буду счастлив услышать (лучше в новой теме).

  12. 125
    Жека Кирпичев ответил:

    Насчет "рефакторинг элементарно делается вручную" не согласен; с какой это стати? Какое отношение он вообще имеет к тестам?
    Если мне надо переименовать какой-то символ, который используется в 1000 мест, а еще в 10000 мест есть символ, который просто называется так же, то какое же тут "элементарно"? Вручную никак, автозаменой тоже никак. Да есть и куча других рефакторингов кроме rename, и даже замедление в 7 раз – от 1 секунды с помощью IDE до 7 секунд вручную для какого-нибудь extract variable или add constructor parameter – я бы почувствовал очень значительно.
    Есть и рефакторинги посложнее, которые IDE делает пару секунд, а у меня уйдет минут 5-30 как минимум.

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

  13. 124
    Олег Андреев ответил:

    Отладчик есть (ruby-debug), рефакторинг элементарно делается вручную. Есть еще несколько IDE, где все сделано а-ля Джава.

    Суть в том, что Руби — один из немногих языков, где возможно писать автоматические тесты быстро и легко. Соответственно, иметь покрытие кода тестами 100% не проблематично, а следовательно, дебаг и автоматический рефакторинг (тот, который исправляет символы по всему проекту) нужны очень-очень редко: тесты достаточно подробные чтобы выяснить где роется проблема.

    Поэтому IDE не нужны. Достаточно иметь терминал, текстовый редактор (TextMate, например) и тесты.

    //rspec.rubyforge.org/
    //dannorth.net/2007/06/introducing-rbehave

  14. 123
    Жека Кирпичев ответил:

    IDE не нужны? Неужели руби не нужен отладчик и рефакторинг?

  15. 122
    Олег Андреев ответил:

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

    А поиск методов, установка колбэков и передача аргументов производились в Джаве. И там как раз не помешало бы иметь более гибкую рефлексию.

  16. 121
    Олег Андреев ответил:

    А еще нам удалось бы сэкономить 33% кода, если бы в Джаве не было дурацкого понятия property (ни в виде публичных переменных, ни в виде специальных сеттеров-геттеров, как в Actionscript 3 или, может быть, в новых версиях джавы).

  17. 120
    Евгений Михайлин ответил:

    простой-то он простой,только неудобный нефига

  18. 119
    Олег Андреев ответил:

    JNI как раз простой как пень, все самое интересное было в самой Джаве.

    IDE руби не нужны, это его преимущество, в этом весь смысл.

    build-процесс всегда зависит от проекта и к особенностям языка отношения не имеет. В джаве – ант или мейкфайлы, в руби – рейк или вообще какой-нить админский руби-скрипт.

    Волшебный рефлекшн в руби такой:
    1) Все — объект.
    2) Класс объекта — тоже объект.
    3) Класс класса — тоже.
    4) Вызов метода = посылка сообщения. Можно вызывать несуществующие методы и ловить их в специальном методе method_missing.
    5) Пропертис нет. Если нужно, есть методы вида prop() и prop=()
    6) Все объекты — открытые: можно добавить/переопределить/удалить любой метод из класса или отдельного объекта.
    7) У любого объекта можно посмотреть список закрытых/открытых методов, внутренних переменных.

    Ну и до кучи:

    //vkontakte.ru/groups.php?act=s&gid=2850
    //vkontakte.ru/wall.php?gid=2850&st=140 (крутить назад)

  19. 118
    Жека Кирпичев ответил:

    Я на руби смотрел немного, он мне тоже весьма понравился; вроде для него даже есть хорошие IDE или плагины к IDE. Надо будет попробовать.

    Под интероперабельностью я имею в виду коллег по проекту, proprietary библиотеки и build-процесс: в принципе антом можно что угодно собирать, но удобно им собирать именно джавские проекты.

    А что за волшебный рефлекшн в руби?

  20. 117
    Евгений Михайлин ответил:

    ну в качестве оправдания любой статически типизированный язык вряд ли сможет обладать рефлексией уровня dynamic языка.
    PS JNI это такая хрень, которая действительно взрывает мозг. Хоть я и не люблю мелкомягких, но их Platform Invoke в разы удобнее.

  21. 116
    Олег Андреев ответил:

    На паттерны попрошу не наезжать :-) В рубине паттерны очень мило реализуются. Другое дело, в Джаве некоторые паттерны используют из-за недостатка динамики.

    Жека, поясни насчет "интероперабельности с чужим java-кодом". Если речь идет о коллегах по проекту, то все понятно; если речь о полезных либах, то совсем слабый аргумент. Для рубина, си, питона и перла почти всегда находится отличный аналог нужной либы.

    Рефлекия в Джаве — жуткий костыль по сравнению с рубином. Я знаю это очень хорошо, так как писал мост JavaScript—(JNI)—Java. Там рефлексии и кодогенерации (в смысле, генерации байткода on demand) хватает сполна. Писать мост JavaScript—Ruby было бы стократ проще и веселее.

    Кстати, важное отличие Питона от Руби: питон навязывает идею о том, что все нужно сделать неким единственно верным путем. Рубин помогает решать насущные проблемы так, как удобно программисту, а не проповедникам. Отсюда — возможность писать код в разных стилях, применяя разные возможности в зависимости от задачи.

  22. 115
    Евгений Михайлин ответил:

    Если тебе нравится Scala – то я тебе скажу что Scala это приближение Жавы к Руби(шоб не сразу взорвать мозг любителям IDE и паттернов)… =)
    В итоге либы есть и там и там, ООП тем более, рефлекшн…. это же свойство JVM, если я правильно помню? То бишь набор классов для работы с понятиями Method, Field, Class, etc

  23. 114
    Жека Кирпичев ответил:

    Да, может и JVM. Не считая набора библиотек (сетевых, базоданных итп), мне нужно ООП (си мимо), рефлекшн (С++ мимо), интероперабельность с чужим java-кодом (почти все мимо) и отсутствие ограничений, заставляющих меня выбрать какую-то определенную парадигму программирования (мимо – кристально великолепные языки типа хаскелла или J).

    Кстати есть офигенный язык Scala – практически то, о чем я всегда мечтал, но сейчас пока нет времени его изучать. Он тоже на JVM и умеет все что умеет джава + функциональное программирование и некоторые другие очень нужные вещи.

  24. 113
    Жека Кирпичев ответил:

    Ну и GC конечно нужен.

  25. 112
    Олег Андреев ответил:

    Жека, ты обрисуй зачем тебе Джава нужна. Может, именно JVM, а не сам язык?

  26. 111
    Евгений Михайлин ответил:

    тот же самый Руби.Твоя проблема в ассоциации Java языка и JVM платформы. У последней применение есть. А вот смысла в первом я вижу очень мало в связи с выходом JRuby 1.0 и тем более грядущим JRuby 1.1 (когда поправят баги и будет нормальный JIT компилятор).
    То есть ты пользуешься всей мощью JVM платформы, встроенного фреймворка, чужих полезных либ, но при этом пишешь на легком и удобном языке а не вырисовываешь энтерпрайзбулшит конструкции

  27. 110
    Жека Кирпичев ответил:

    Красноречивое, но однобокое (маленькие веб-приложения). Меня это не убедило, для моих задач Java подходит превосходно и я не знаю, какой язык подошел бы лучше.

  28. 109
    Олег Андреев ответил:

    Вот здесь довольно красноречивое объяснение (2005 год):
    //moedusa.livejournal.com/821292.html?thread=22...

  29. 108
    Жека Кирпичев ответил:

    По какой же?

  30. 107
    Олег Андреев ответил:

    Чисто там, где убирают. Когда-нибудь сверлили бетонную стену для прокладывания кабеля?

    Джава — говно по другой причине, далекой от качества реализации виртуальной машины и скорости работы.

  31. 106
    Анзор Апшев ответил:

    Чисто не там где убирают, чисто там где не сорят.
    Хотя мне и нравиться писать на яве (сам процесс радует) все такиgc меня сильно напрягает. отчасти это наверное связано с тем что у меня нет большого жабовского опыта, но все таки я чувствую что это не мое

    ИМХО: на яве хорошо писать программы, хорошие программы на нем не напишешь.

  32. 105
    Олег Андреев ответил:

    Я не решил. Я вспомнил, что утечки мы наблюдали в очень специальном месте не-Sun-овской виртуальной машины (конкретно в JNI). Причем, когда тестировали сановскую, утечек не было. Вот мне и интересно: где и когда еще бывают утечки.

  33. 104
    Татьяна Флягина ответил:

    Олег
    с чего вы решили что на java(j2ee) утечек не бывает????

  34. 103
    Олег Андреев ответил:

    Нет, их разруливает мусорщик. В самых простых реализациях стоит MAX_REFERENCE_DEPTH, в руби он равен 200 (или 500, не помню точно), т.е. объект, ссылка на который стоит на расстоянии 200 объектов от рута, уничтожается при сборке мусора. Такое возможно в двух случаях: сборщик зациклился на циклической ссылке (и правильно сделал, что удалил), или объект действительно так глубоко создан и тогда в программе обнаружится nil в самый неподходящй момент.

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

    Примеры:
    1) Запущенный процесс нужно убивать явно с помощью kill -9. По таймауту или сразу – дело писателя.

    2) Все интерфейсные штучки должны явно начинаться и явно заканчиваться. Например: visible/invisible, create/delete, add/remove и т.п. Мусорщик за вас второе действие не сделает. Поэтому я и соорудил небольшой фреймворк для конечных автоматов: //vkontakte.ru/board.php?act=topic&tid=220171

    3) База данных достаточно тупая (а чтобы не была тупая, нужно все зависимости прописывать в ней, или в приложении). При ничтожении объекта из БД, все зависимости должны быть соответственно обработаны: нулифицированы внешние ключи, либо удалены зависимые данные или переподключены к другому объекту. Это тоже задача программиста, а не сборщика мусора.

    4) Самое интересное: бывают случаи, когда объект уже можно уничтожить, а ссылка на него остается. Хотя нужно, чтобы кое-какая ссылка исчезала при сборке этого объекта мусорщиком. Типичный случай: кэш объектов. Когда на объект нет ссылок ниоткуда, кроме кэша, он должен быть удален. Для этого используется понятие Слабой Ссылки: //en.wikipedia.org/wiki/Weak_reference
    Если это кажется редкоупотребимым случаем, замечу, что библиотека Papervision3D, которой я пользуюсь при создании видеоплеера, содержит такие кэши объектов со слабыми ссылками.

  35. 102
    Дима Мироводин ответил:

    Олег я так понимаю циклические ссылки?

  36. 101
    Евгений Михайлин ответил:

    по поводу отладки – use TDD, BDD.

  37. 100
    Олег Андреев ответил:

    "Утечек конечно не будет, если нет ошибок в самой реализации интерпретатора и сборщика мусора."

    Ох-ха-ха. Привести контр-пример скрипта или сами придумаете? =)

    // Это типичный пример рассуждений человека, которому уже продали GC, а он еще не читал Тьюринга и Дейкстры. Рекомендую считать, что GC спасает от 0,1% случаев утечки памяти. Чтобы остальные 99,9% держали вас в тонусе ;-)

  38. 99
    Дима Мироводин ответил:

    Татьяна

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

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

    Я кстати за что уважаю интерпретаторы, а частности .Net, так за очень хорошие средства отладки.

  39. 98
    Олег Андреев ответил:

    Наj2ee случаются утечки памяти? Мы наблюдали такое только в Skelmir-овской реализации JNI.

  40. 97
    Татьяна Флягина ответил:

    Дима Мироводин

    Но если ты кодишь на php зачем тебе отладчик???
    не корректно, мысль о том, что если пишешь скрипт на php вряд ли у тебя появиться задача связанная с утечкой памяти? (вряд ли ты будешь писать такой проект где может возникнуть утечка на пхп….тут скорее j2ee)

  41. 96
    Дима Мироводин ответил:

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

  42. 95
    Дима Мироводин ответил:

    Татьяна Флягина

    Согласен 100%. Я уже не первый раз замечаю, что многие программисты php не умеют пользоваться отладчиками… понятно что это только начинающие – но ведь это основы.

  43. 94
    Олег Андреев ответил:

    Поэтому мозги умного программиста и оупен-сорс так ценны.

  44. 93
    Татьяна Флягина ответил:

    но есть задачи когда такое отвлечение на "второстепенные задачи (например, сборщик мусора и тд)" является критично. И другая проблема: если ты привык что за тебя ето делает ВМ (и др), то написать/исправить и тд уже довольно сложно.

  45. 92
    Олег Андреев ответил:

    Чисто программистский взгляд на вещи :-) Подумайте над тем, что среди "штук, которыми всегда будут загружать ресурсы на 100%" находятся не только фенечки для конченого (конечного) пользователя, а еще и фенечки для того, чтобы сложный продукт делался быстрее и качественнее. Поэтому и придумывают всякие языки, насыщенные динамикой и жуткими тормозами. Разумеется, конкретные просчеты при разработке ВМ должны исправляться, но это не умаляет достоинства языков, которые позволяют проектировать приложение на языке поставленной задачи, не отвлекаясь на второстепенные задачи (например, сборщик мусора облегчает написание программы, хотя некоторые начинают считать, что раз есть GC, то за ресурсами следить не надо ;-)

  46. 91
    Дима Мироводин ответил:

    В свое время читал интересный топик, итак кусок :

    ==================

    Нижеследующий текст написан нашим соотечественником, работающим в микрософтовской команде компиляторов.

    Ко мне этот текст попал в конце 91го года. Он довольно старый, и старше, чем релиз .NET.

    Предлагаю обсудить.

    —————————————————————————————-

    Вы знаете, я вообще-то достаточно долго занимался разработкой компиляторов. Как-то, разговаривая с Игорем Васильевичем Поттосиным (одним из крупнейших специалистов в области оптимизирующих компиляторов) лет 15 назад — я тогда был еще молодой– я поинтересовался, с какой целью мы тратим невероятные усилия на разработку новых методов оптимизации и проч., если процессоры, согласно закону г-на Мура, становятся вдвое быстрее каждые полтора года? — обычно код, порожденный предельно тупым компилятором ("что вижу, то и пою"), медленнее оптимального ну в полтора, ну в два раза (для RISC и CISC архитектур); поскольку в скором времени "плохой" код на новой машине будет работать столь же быстро, как и хороший на старой, имеет ли смысл так упираться?

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

    И.В., безусловно, прав. Вы все помните, как здорово работал Ворд на 286. На 386 он бы просто взлетел, но эти редиски — наши коллеги из Офиса — перенесли его на Винды и сделали графическим (появилась новая вычислительная мощность — чего бы ее не занять?). Появился 486 и, казалось, Ворд снова должен взлететь, так нет, вставили туда какую-то проверку орфографии текста, которая работает всегда, и снова вычислительных ресурсов стало остро не хватать. И т.д. и т.п. Если кто-то думает, что 1.5 ГГц Пентиума-4 хватит на все случаи жизни, то он глубоко ошибается. 1.5 GHz P-4 — примерно половина того, что нужно для сжатия телевизионного сигнала в реальном времени, я уже не говорю о полноценном распознавании речи.

    Таким образом, скорость работы программы важна. Практика показывает, что если программа (серьезная, а не демонструшка в 1000 строк) работает слишком быстро, в нее немедленно добавляется какая-нибудь забавная функциональность, которая увеличивает объем продаж на 10% и съедает все ресурсы.

    Ни программы на Java, ни на C# — по 100 разных причин — не работают и никогда не будут работать столь быстро, как на Си. Ну язык левой ногой задизайнен, что тут сделаешь, — разработчики компиляторов не винованы, что создатели Жабы были в языках программирования и компиляторах ни уха ни рыла, посему там грабли разложены очень ровным слоем просто везде. Жаба, господа, это просто атас, а реализация ВМ (виртуальной машины) Саном — это песня. Смотришь, и сразу понятно, — ребята делают первую в их жизни ВМ. Ляп тут, ляп здесь, засада за углом, обломс там… Скажем все дружное спасибо фирме Сан, которая вбахала в пропаганду и распространие этого убожества несколько миллиардов баксов и таки добилась своего.
    …………..
    ======

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

    далее//rsdn.ru/Forum/message/675837.flat.1.aspx

  47. 90
    Олег Андреев ответил:

    На том, где ООП без компромиссов: Смолток, Питон, Руби. Джаву и Си++ нужно учить, но не из-за ООП.

  48. 89
    Евгений Михайлин ответил:

    да, новопрос на чем учить ООП, очень непрост на самом деле.

  49. 88
    Олег Андреев ответил:

    Джава и ООП – это не сильно пересекающиеся вещи.

  50. 87
    Евгений Михайлин ответил:

    в универе где учат ООП на 1ом курсе, предполагается что процедурное изучено в достаточном объеме в школе. Если нет – это проблемы приемной комиссии.

  51. 86
    Татьяна Флягина ответил:

    преподают?? хм, вот у нас уже первокурсники учаться на java. ООП и все дела….и про процедурное программирование уже не знают. вопрос в том: хорошо ли ето???

  52. 85
    Виктор Екимов ответил:

    Он однозначно умер, теперь его, как и старую литературу, преподают в университете

  53. 84
    Андрюшка Барыкин ответил:

    "Зачем студентов учат Дельфи 6 мне понять ОЧЕНЬ тяжело ибо он портит детей. Не зная толком, что такое класс и т.д. они кидают кнопочки на форму , ещё пару кликов и програмка готова , где то я видела этому определение: КЛИКАТЕЛЬНОЕ ПРОГРАММИРОВАНИЕ (как -то так)" – батонокидательство это называется %) Хотя в общем я согласен, только думаю, тут не важно, какая среда(VS, Delphi, Builder и т.д.), просто почему-то юзают Дельфу. Думаю, все дело в качестве программирования…

  54. 83
    Ваня Григорьев ответил:

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

  55. 82
    Светлано Курова ответил:

    Ну начнём с того , что сначала надо общие принцыпы ооп подучить, потом определится с поставленной задачейи исходя их неё выбирать язык. Зачем студентов учат Дельфи 6 мне понять ОЧЕНЬ тяжело ибо он портит детей. Не зная толком, что такое класс и т.д.они кидают кнопочки на форму , ещёпару кликов и програмка готова , где то я видела этому определение:КЛИКАТЕЛЬНОЕ ПРОГРАММИРОВАНИЕ (как -то так). Знакома с VHDL, С\С++, Delphi, VA Basic, Java. Работаю на java. Автору: факультативно её (java SE) наверное Асилишь, а вот j2EE думаю нет, учитывая специфику применения java юзают именноjee, тогда зачем вообщеучить jse калькулятор написать можно и на Delphi

  56. 81
    Guess Who ответил:

    Pascal никак не мертв, ибо Skype и еще куча мощных и полезных программ написаны на Delphi.

  57. 80
    Андрюшка Барыкин ответил:

    Евгений, слава богу, ты не похож на фанатика С++, поэтому с тобой приятно аргументированно вести беседу. :)
    Катя верно сказала, все дело в задаче, а изучать лучше языконезависимые вещи, как-то алгоритмы, технологии, платформы, подходы.
    Мне после Delphi, PHP и VB/VBA очень легко было зарюхать синтаксис C#.

    з.ы. касаемо VB/VBA, я работал с ним большей частью в связке Delphi-OLE-Excel. Excel – как средство отчета для данных из БД.

  58. 79
    Олег Андреев ответил:

    Ребята, дабы прекратить бессмысленный трёп, я вывесил две задачки. Разомните мозги на них =)

  59. 78
    Екатерина Гильман ответил:

    Абсолютно согласна с тем, что язык – это всего лишь инструмент.Но,от правильности выбранного инструмента часто и зависит успех или неудача всего проекта.
    Очень правильный пост про первоисточник – ЗАДАЧА, исходить нужно от нее.
    А выпускник-программист должен прекрасно ориентироваться в современных технологиях,принципах и парадигмах.Он должен уметь выбрать подходящий язык для реализации,опять же,исходя из ЗАДАЧИ.Я думаю,что изчить новый язык програмирования для такого специалиста не составит большого труда.
    А что касается заявлений,что С++ рулит,все остальное в топку,ребята, так нельзя.Художник не может рисовать одной краской,механик не сможет починить автомобиль одним инструментом…Должна быть альтернатива,профессионализм разработчика и определяется правильностью принятия решения.
    Так что Delphi – быть, равно как и всем остальным языкам программирования.

  60. 77
    DELETED DELETED ответил:

    Жаль, что Borland в своё время провалилась с Basic, и практически отдала монопольное право на развитие этого языка Microsoft. Теперь нет ни указателей, ни беззнаковых типов, ни инлайн-функций (макросов). Правда иногда можно обойтись и без этого. Зато радует в VB синтаксис: почти язык человека, легко читается.

  61. 76
    Евгений Михайлин ответил:

    касаемо VB (не дотнет!)- у этого языка ООП на уровне яслей. Единственное, почему он был применим – это потому что на момент появления не было удобного средства разработки под винду, писать на Win32API интерфейс было очень скучно,а Visual Basic Forms были технологией которые серьезно продвинули все это дело. Потом уже появилась делфя, потом дотнет и тд.
    Но это нефига не мешает сейчас быть недотнет VB устаревшей платформой.

    Касаемо плюсов.
    cout = console out :)
    работа с динамическими объектами – ну вообщем-то да, здесь есть масса причин для багов, но надо просто воспринимать new и delete как скобки и соблюдать их правила, а во многих местах юзать RAII.Реальные проблемы это когда скобки неочевидны – открываются в одном месте, закрываются в другом.
    Только я не понял смысла про конструктор – конструктор вызывается всегда при создании объекта. Ты имел ввиду что в Делфи нельзя размещать объекты в куче, а только в стеке?

    Касаемо неявного преобразования типов – C++более строг чем обычный C.Обычная строгая статическая типизация.

    Касаемо обучения программированию.
    Вот здесь-то как раз огромный вопрос. Как и на чем учить программированию? Здесь есть несколько точек зрения.Учить на простых языках для понимания, учить на сложных языках, чтоб наступали на грабли, учить на специально обучательных языках (aka Pascal), учить на продакшн языках (чтоб сразу изучали реально исп. технологии), наконец учить на языках с изюминкой, с интеллектуальной задумкой, идеей наконец.
    Я не знаю ответа на данный вопрос. Сам учился на Сях и наступал на грабли :)

  62. 75
    Андрюшка Барыкин ответил:

    "А вот кстати допустимость юникодных имен в яве\шарпе – зло. Потому что приходят идиоты и называют класс, скажем, по-русски. Пиши пропало." – 100п, русский язык в названиях – зло :)
    "Мне вот другое интересно – слышал от знакомых делфистов презрение к VB. Ну ладно опустим недообъектный VB6, но VB.NET в силу своей дотнет природы вполне адекватен, кроме разве что синтаксиса. Так вот на этот синтаксис и ругались." – я тебе что скажу, все таки холиворзы – это детство. Не знаю, я немного знаком и VB 6/VBA, и мне он нравится гораздо больше С++ именно таким же простым и понятным синтаксисом, как и в Дельфе. Поэтому объяснить не смогу, все индивидуально.
    "Насчет человеческих названий(именно названий) классов\методов честно не понял. Ваш класс, как хотим так и называем. Или вы про названия классов\методов в STL?" – суть в том, что в Дельфе(да и в c#) можно, не зная до этого языка, по названию функции понять, что она делает и наоборот, зная, что нужно сделать, можно примерно догадаться, как будет называться функция. Тоже самое про стандартные подключаемые модули/библиотеки.
    для сравнения, вывод на экран в консоли: Delphi: write – написать, C++: cout – хз что. Может пример и не удачный, каюсь, с С++ работал мало. Могу, наверное, за многих дельфистов сказать, что им не нравится в С++(при этом я не говорю, что мол это зло и знать его не надо), это стремный синтаксис + некоторые вольности, как-то неявное преобразование типов(Дельфа этого не допустит еще на стадии проектирования) и работа с динамическими объектами(в Дельфи нельзя работать с объектом, который не создан через конструктор). А итоге получаешь кучу плавающих и не понятных ошибок, кот. в Дельфи в принципе быть не может. :)
    C++ – мощь и вольности,
    Дельфи – простота и ограничения.
    Каждому свое.

    з.ы. Имхо, может быть Дельфи и не такой мощный как С++, но он учит программировать, за счет своих ограничений.

  63. 74
    Дима Мироводин ответил:

    2 Roman RedDy Torsten
    Уверяю тебя, кто платит за эти программы деньги, меньше всего думают на ЧЕМ они написаны :)

  64. 73
    Евгений Михайлин ответил:

    Насчет человеческих названий(именно названий) классов\методов честно не понял. Ваш класс, как хотим так и называем.Или вы про названия классов\методов в STL? Дык там вроде нормально все.А вот кстати допустимость юникодных имен в яве\шарпе – зло. Потому что приходят идиоты и называют класс, скажем,по-русски. Пиши пропало.
    Касаемо скобочек – ну да, индивидуальные.Мне вот другое интересно – слышал от знакомых делфистов презрение к VB. Ну ладно опустим недообъектныйVB6, но VB.NETв силу своей дотнет природы вполне адекватен, кроме разве что синтаксиса. Так вот на этот синтаксис и ругались.
    Прошу объяснить, ведь вроде VB куда как ближе к Делфи по синтаксису, чем к шарпам и прочим сиподобным.

  65. 72
    Андрюшка Барыкин ответил:

    Евгений, я хотел намекнуть на более приятный синтаксис в C#, по сравнению с С++, полее "человеческие" названия методов, классов и т.д.
    "Меня раздражает писать лишнее. Так вот begin end – это лишнее." – согласитесь, что это ваши индивидуальные потребности… Мне удобнее begin end, т.к. код тогда для меня более читаем, нежели со скобочками.
    "Что касается того насколько понятен код – и на дельфе можно написать ужас." – ну тут согласен. :)

  66. 71
    Евгений Михайлин ответил:

    синтаксис C#скорее слизан с явы.А явав сущности этоC++ минус те фичи которые разрабы посчитали ненужными или трудными для понимания.
    Меня раздражает писать лишнее. Так вот begin end – это лишнее.
    Что касается того насколько понятен код – и на дельфе можно написать ужас.

  67. 70
    Андрюшка Барыкин ответил:

    "Вот например, ты знаешь что в функциях нельзя возвратить пользовательский тип данных. Только встроенные типы и указательные." – ??? ты про тип функции? Ну тогда это еще раз подтверждает вышесказанные слова "Если тебе не нравится этот язык – скорее всего ты просто не умеешь им пользоваться".
    "я уж не говорю про кривой синтаксис begin/end, if/then/else – где там нужно ставтить ;, а где нет." – простите, а вы адепт какого языка?
    Знаете, вот честно, много слышал нареканий про Дельфи, но про синтаксис все обычно замолкают, т.к. это имхо одна из фишек Дельфи – максимально приближенный к человеческому синтаксис. Так что вы выразили всего лишь ваше чисто субъективное мнение.
    "Один синтаксис работы с указателями заставляет ужаснутся." – поясните? Хотя вообще указатели – это зло, по признанию многих. Если задачу можно решить без указателей, то это стоит сделать именно так. Да и реально, не так уж и много задач, где использование указателей критично.
    "Этот язык вызывает только отвращение, он не удобен, на нем нельзя нормально выразить мысли." – опять же чисто субъективное мнение. Пример удобного языка в студию с комментариями. Если уж говорить об удобстве, то имхо тут вообще почти все сосут у Паскаля/Дельфи. Недаром разработчик C# пришел в MS из Борланда, синтитаксис C# такой же приятный, как и у Дельфы. Повторюсь, дельфишный код можно понять без комментариев, чего не скажешь, например, про сишную помойку кода.
    "Так сказать не даром на этом языке не написано ни одного стоящего современного программного продукта." – суслика видишь? Нет? А он есть!

  68. 69
    Роман Торстэн ответил:

    Дима Мироводин
    2 июл 2007 в 10:54
    Сегмент рынка Delphi в России.
    1. Локальные клиентские программы/ShareWare – total commander, tha bat, WinOrganizer. Сегмент думаю понятен ?
    —-
    TC – написан на делфи ??? Офигеть, я в шоке. Пойду искать новый манагер (хотя чего искать, у меня же есть Фар :) .
    ну а про зе бат я как в воду глядел, от него прямо ваняет чем-то, оказывается дельфей.

  69. 68
    Роман Торстэн ответил:

    Андрей Megabyte Барыкин
    5 июл 2007 в 9:02
    Бугага. Читай выше пост №63, последнее предложение. ;)
    ——
    и че ?
    Я вот учился на паскале 4 года назал, сейчас вот по учебе опять были по нему задания, 5 лаб сделал за пару часов, без особого напряга.
    Я говорю про то что это тупой язык.
    Вот например, ты знаешь что в функциях нельзя возвратить пользовательский тип данных. Только встроенные типы и указательные.
    я уж не говорю про кривой синтаксис begin/end, if/then/else – где там нужно ставтить ;, а где нет. Один синтаксис работы с указателями заставляет ужаснутся. Этот язык вызывает только отвращение, он не удобен, на нем нельзя нормально выразить мысли.

    Так сказать не даром на этом языке не написано ни одного стоящего современного программного продукта.

  70. 67
    Евгений Михайлин ответил:

    to Дима Мироводин
    с первыми 2 сегментами согласен, c третьим согласен на данный момент, но по-моему на 5 лет загадать тяжело ситуацию в нем.
    По поводу шаровары на дотнете – ну вообщем-то да,с стандартизацией присутствия .net framework будет куда проще работать.
    to Юрий YZ Жуков
    Паскаль был действительно создан очень умным человеком для конкретной цели – обучения и он эту цель успешно выполнил (и до сих пор выполняет). Делфи это относительно удачная попытка расширить функционал до коммерческого применения. Но тут следует заметить, что еще непонятно, чем эта удача заработана – удобностью IDE Делфи (на тот момент) ну и либами типа VCL или же именно ООП языком.
    Множество проектов к примеру было сделано на C++ Builder, единственное что его реально погубило – это не очень хорошее следование стандарту C++ (хотя на 100 процентов ему никто не следует) и политика борланда.

  71. 66
    Андрюшка Барыкин ответил:

    Бугага. Читай выше пост №63, последнее предложение. ;)

  72. 65
    Роман Торстэн ответил:

    Наконец-то !!! Как я давно ждал, когда эта падла, сделанная недопрограммистом для недопрограммистов, сдохнет.

  73. 64
    Просто Михаил ответил:

    С чего это он мёртв? Как гворил мыщьх, любую задачу можно решить на любом языке программирования, другой вопрос – каким образом. И с Pascal/Delphi можно творить чудеса, главное чтобы руки не кривые.

  74. 63
    Андрюшка Барыкин ответил:

    Тоже верно ;)

  75. 62
    Юрий Жуков ответил:

    Хм… Господа! Вот я не понимал никогда, к чему эти споры?
    Большинство существующих языков было создано умными людьми. Наверное, более умными, чем большинство из нас, обсуждающих сегодня эту тему. Естественно, каждый язык создавался с определенными целями.
    Вероятнее всего, будет правильным утверждение:
    Если тебе не нравится этот язык – скорее всего ты просто не умеешь им пользоваться.

  76. 61
    Владимир Веревкин ответил:

    >длинный синтаксис
    Есть способы ускорить написание кода, если это поможет:
    1. Чтобы быстро поставить Begin/End, нужно набрать bg и затем Ctrl+J.
    Точно стандартную комбинацию не помню, у меня переопределена на bg. Настраивается в Tools – Editor Options – Source Options – Edit Code Templates.
    2. Чтобы автоматом создать все несозданные методы из объявления класса/объекта, нажми Ctrl+Shift+C.
    3. Чтобы перемещаться из имплементации метода к его заголовку используй клмбинацию Ctrl+Shift+Up|Down.
    4. Чтобы вывести список доступных объектов/переменных/констант/свойств, нажми Ctrl+Space.
    5. Чтобы вывести список аргументов используемой функции нажми Ctrl+Shift+Space внутри скобок.

  77. 60
    DELETED DELETED ответил:

    Delphi – отличный современный продукт. Единственное, что раздражает – длинный синтаксис.

  78. 59
    Дима Мироводин ответил:

    Да для сервера приложений конечно delphi использовать можно, cobra не знаю, думаю com/dcom приимущественнее. Но в своей практики таких проектов не встречал :( в основном это была java.

    PS. Советую прочитать про успехи .net в shareWare бизнесе на //rsdn.ru/forum/Message.aspx?mid=2514591&on...

  79. 58
    Андрюшка Барыкин ответил:

    Насчет 3-хзвенки. Не знаю, но там, по-моему, вполне можно писать полноценные приложения, благо есть поддержка COM и CORBA(хотя и не сильно эффективно).
    Да и своими глазами видел один крупный проект кампании EOS, у которой в клиентах Гос.Дума и Генеральная прокуратура, а в партнерах MicroSoft и Oracle. Пакетная(с подключаемыми модулями), универсальная(самонастраиваемая) информационная система по учету кадров, работала с гетерогенными БД(Oracle и Microsoft). В 2005-м году разве что новую версию на Delphi 2005 переносили с 7-ки.
    Это из крупных проектов, про мелкие и средние молчу…

  80. 57
    Дима Мироводин ответил:

    Сегмент рынка Delphi в России.
    1. Локальные клиентские программы/ShareWare – total commander, tha bat, WinOrganizer. Сегмент думаю понятен ?
    2. Программы для пользователя, с использованием Субд – домашние бухгалтерии, всякие коталогизаторы и т.д. и т.п. Думаю что 80% домашних финансов/каталогов CD/DVD написано именно с использованием Delphi + ado/FireBird. Плюс к этому всякие прайс листы, учет товаров для ларька и т.д. :)
    3. В связке с промышленными субд(mssql/oracle). Тут наверное 70% рынка программ, которые пишут в россии для автоматизации предприятия (бухгалтерия/склад/рестораны/гостиницы/кассы/терминалы оплаты мобильных систем) написаны с использованием delphi.

    Вот таким я вижу сектор ранка Delphi и собственно object pascal сегодня и еще на 5 лет вперед.

    PS> новые проекты открывают на delphi и в качестве аутсорсинга да же сегодня.
    PPS > на данным помент delphi мертв для web'а / серверной части в трехзвенке и как вариант программинга на dotnet.

  81. 56
    Денис Рысцов ответил:

    Ссылки про WPF, в детстве Avalon, советую смотреть ролик на youtub'е
    //vkontakte.ru/board.php?act=topic&tid=38924
    //vkontakte.ru/board.php?act=topic&tid=131775

  82. 55
    Андрюшка Барыкин ответил:

    "1) смешанный подход еще хуже чем чисто процедурный. Потому что второй означает лишь программирование в процедурном стиле и ничего более, то первый как раз таки ведет к кривому пониманию ООП. Сам таким страдал поначалу. " – странно, но мне это наоборот помогло плавно перейти на ООП, и вообще использовать ООП там, где это действительно удобно и необходимо! Что я не так делал?
    3) Но C++ как язык мощнее чем делфи, потому что он мультипарадигмен.
    На тему с++ VS Pascal/Delphi былр много Холиворзов.Может он и мощнее, только опять же, сколько не спрашивали про задачи, которые нельзя сделать на Дельфи(ну разве что драйверы, и то народ делал. но это уже изврат, согласен), а можно на С++. Ну лан, тут можно долго холиварить…
    4) Авалон не видел, честно. А вот про фенечки хотел бы поподробнее, так и не понял, чего там есть такого, чего нет в VCL и множестве написанных сторонних компонентов под Дельфи, коих множество.

    Последнее: к профессионализму надо стремиться. А если человек с мозгами, то он поймет, когдо надо апргрейдить свои знания.
    Умиляли товарищи, которые года 3 назад писали, что на Дельфи не написать более-менее серьезного проекта под БД, когда пришел 1-й раз программистом работать 1.5 года назад, то увидел такие проекты На Дельфи, за которые некоторые возможно никогда не сядут.

  83. 54
    Виктор Веретнов ответил:

    Скажу что Паскаль, не умрет никогда, даже если на нем не будут программировать как на Паскале, то есть такая среда как Дельфи. Эт ведб отчасти тоже паскаль…

    Он умер, но не совсем…паскаль так сказать эволюционировал….

  84. 53
    Евгений Михайлин ответил:

    to Андрей Megabyte Барыкин
    1) смешанный подход еще хуже чем чисто процедурный. Потому что второй означает лишь программирование в процедурном стиле и ничего более, то первый как раз таки ведет к кривому пониманию ООП. Сам таким страдал поначалу.
    2) RAD это всего лишь часть хорошей IDE. Важная часть. Но есть куча других фич которые делают работу удобной. Взять хотя бы рефакторинг? Нет, серьезно после Inellij IDEA за студией-то противно работать, не то что за делфовской IDE. Пока мы остаемся в рамках OnButtonClick все нормально, но как только приходится писать длинный код – противно. Впрочем, о вкусах не спорят.
    3) задачи, где критичным по скорости является C++?исключительно по скорости такие вряд ли найдутся. Все-таки нейтив он и в Африке нейтив код.Но C++ как язык мощнее чем делфи, потому что он мультипарадигмен. Соотвественно если нам пофиг на скорость мы пишем на дотнете, яве, руби, <вставить свое>, если не пофиг – на плюсах. Быстро по скоростии отностительно удобно, благо язык фичавый всеж таки (относительно потому что надо больше думать головой). Тяжело писать код? Да, тяжело. Ну дык и нефиг дилетантов сажать на те задачи, где требуется хорошая оптимизация. А в остальных случаях вполне хорош managed код.
    4) Объективность устаревания VCL? Ну посмотрите что-ли на Avalon, на программирование GUI на вообщем-то диалекте XML, на возможности для получения красивого гуя.Разумеется это все фенечки, но эти фенечки в ближайшем будущем будут делать рынок.
    И последнее. Я понимаю профессионалов, которые пишут на делфе, потому что они отлично энают свой инструмент.Но я непонимаю новичков, которые бросаются изучить делфи, не понимая, что к тому времени когда они смогут сделать более менее серьезный проект, вакансий почти не будет, а те что останутся – там нужен опыт от N лет и проч.
    Плохо щас на рынке труда человеку который знает только делфю и при этом новичок, то есть без опыта, без дорогого резюме и тд.

  85. 52
    Евгений Михайлин ответил:

    to Дима Мироводин
    дайте для начала определение WINDOWS-сегмента рынка.По спектру решаемых задач.
    PSв былые времена этот самый рынок Win32 приложений (не в России естессно), если имеется ввиду декстопконтролировался VB. Теперь он контролируется VB.NET.
    Посмотрите на статистику проектов.

  86. 51
    Дима Мироводин ответил:

    "Потому что он не развивается раз и потому что есть более удобные среды разработки два. Какие? Дотнет, java."

    Среды разработки – согласен. Динамика – согласен.Но простите какие ниши занимают dot net и java в WINDOWS сегменте рынка ???

    Еще раз утверждаю, нужно сравнивать спортсменов с своей категории ;)

    А то, тут половина народа, еще толком не поработав на рынке программинга, кричит что ruby, java -лучше … delphi.Это тож самое что сравнивать балет и бокс – кто лучше… бред. Еще раз сравниваем object pascal/delphi в сегменте win32 платформы !!!

  87. 50
    Александр Карпов ответил:

    А есть просто WinAPI + визуальный редактор к GUI :) Точнее лучшее решение по компактности — диалоги в ресурсах, это самый маленький вариант.

  88. 49
    Владимир Веревкин ответил:

    Насчёт размера проги с GUI – если нужна действительно маленькая прога, есть библиотека KOL, нормальная такая замена VCL :)

  89. 48
    Андрюшка Барыкин ответил:

    "а это на самом деле обычное мышление при переходе с процедурки на ООП (особенно если на процедурке писали долго)." – эмм, ну как бы не совсем с процедурки, от смешанного ООП и ПРоцедурного.
    "Если нужна скорость разработки – то лучше писать на упомянутых выше платформах." – не согласен. Качество ИДЕ – имхо только ваше личное мнение. Дельфи полностью поддерживает принцип разработки RAD, с помощью VCL это делать крайне удобно. :)
    "Там где очень очень нужна скорость исполнения -то плюсы остаются лучшими." – эмм, ну может быть и так. Назовите задачу, где критичным(по скорости) было бы написание на С++, а не на Дельфи? Просто интересно.
    "Куда деть делфи, если VCL уже объективно устарел?" – в чем выражается объективность устаревания VCL? Чтотакого удивительно нового есть в других компонентных библиотеках, чего нет в VCL?
    "Теперь по поводу делфи дот нет. Совершенно бесполезная вещь." – а вот тут поддерживаю. Лучшая версия – это 7, и это не только мое мнение. Сам для программирования под .NET изучаю C#.
    "Я всегда был против языкового фанатизма." – поддерживаю. Просто меня забавляют люди, которые уже неколько лет подрят мне пытаются что-то доказать, что я прогаю на "не правильном" и не модном языке… %) Когда потребовалось изучить новое, тогда и изучил. Но если придется выбирать на чем прогать, то выберу Дельфу, ибо на ней я это делаю лучше всего!

  90. 47
    Александр Карпов ответил:

    >> Delphi НЕЛЮБЛЮ, слишком раздутый код собирает
    >Я спокойно напишу Delphi-приложение в 4КБ.
    >И знаю человека, который может написать приложение на Дельфи в 500 байт.
    >А ты, сможешь на компактном си написать такое? :)

    На Сях без проблем (убираем стандартные либы, оставляем тока winapi, а также выравнивание файла делаем 0.5К), на асме тоже. Делфи тут не причем.
    Я имел ввиде делфи как VCL. На VCL ты ничего компактного с GUI не сделаешь. Именно это я имел ввиду. Как я уже говорил я имею претензии тока к делфи как VCL, сам паскаль мне вполне симпатичен.

    И во вторых :) Я на си напишу "приложение" (кавычки ибо функций мало у такого монстра будет), размером от килобайта (0.5к – MZ+PE заголовок и еще 0.5k – секция кода.), если приложение в 0.5к – это вообще прикольно, однако оно, скорее всего, может работать не под всеми версиями windows, ибо слишком маленькое выравнивание секций в файле + какието еще хитрости — не факт, что поддерживается такое везде :)

  91. 46
    Евгений Михайлин ответил:

    "Правда после него я впервые для себя понял, что чистое ООП – это ппц. :) На каждую фенечку свой класс, в итоге в более-менее серьезном проекте крайне сложно разобратся в коде. Хотя может я один такой."
    а это на самом деле обычное мышление при переходе с процедурки на ООП (особенно если на процедурке писали долго). Вот особенно PHPисты щас мучаются.
    "Кстати, Кобол же включен в языки, поддерживаемые .NET. "
    это не развитие языка (как платформы) Кобол. (так же как и Delphi.NET не развитие делфи, а полный идиотизм). Это новый синтаксис приделанный к платформе дот нет ради пиара в случае кобола, и в силу рынка в случае с делфи (борланд, а сейчас уже code gears).
    "поясните, честно не понимаю?" – какие нововведения кроме перехода на дотнет произошли в делфи за последние года (о дотнет я скажу попозже)? Вот-вот.Почему он мертв? Я считаю мертвым делфи как платформу для разработки широкого плана.Потому что он не развивается раз и потому что есть более удобные среды разработки два. Какие? Дотнет, java. Сейчас уже можно говорить и о динамике (тот же руби, да и динамика на jvm неплоха).А что делфи? Делфи попал в вилку. Если нужна скорость разработки – то лучше писать на упомянутых выше платформах. Там где очень очень нужна скорость исполнения -то плюсы остаются лучшими. Куда деть делфи, если VCL уже объективно устарел?Если сама IDEDelphiустарела. Потому что жавовские IDE, да и студия 2005 куда как удобнее.
    Нет, конечно можно считать язык живым, пока на нем хоть кто-нибудь пишет. На коболе, на фортране, на аде пишут.Есть задачи где они хорошо применимы. Есть задачи где хорошо применим делфи. Но в общем, в массе что? Делфи уже не язык масс, которым он был раньше. Тому подтверждение – стремительное сокращение числа вакансий.Вот о чем я говорю, когда говорю язык мертв.
    Теперь по поводу делфи дот нет. Совершенно бесполезная вещь. Потому что синтаксис шарпа проще,а нативный код быстрее чемmanaged. Поэтому .net-кодеры пишут на шарпе или на vb, а делфисты продолжают писать под native.
    Я всегда был против языкового фанатизма. Вчера один язык, сегодня рулит другой, завтра третий. Есть задача. Есть инженер ее решающий.Так вот разве не хорошо ли, что инструменты инженера улучшились? Разумеется есть много людей которые пишут на делфи и довольны. Но не надо при этом кричать что Делфи живее всех жив, что у него мало конкурентов и тд и тп.

  92. 45
    Владимир Веревкин ответил:

    А вот ещё мне кажется, что выпуская новые IDE для C*, мэнэджэры не учитывают потребностей программистов :) Да пусть они хоть тысячами их выпускают (как компиляторы под .NET), народ разумный потянется к тому, что удобнее. Разве что сложнее отыскать будет эти более удобные средства =) Плюс то, чем щас восхищаются сионисты, в большинстве случаев было уже в 7 делфи :)

  93. 44
    Анзор Апшев ответил:

    >Чем мне Паскаль/Дельфи нравится – это единственный язык, код >проектов, написанных на нем, можно понять без камментов. %
    Согласен

  94. 43
    Андрюшка Барыкин ответил:

    "ообще нужно быть проще и писать на том, что лучше знаеш, при этом держать руку на пульсе технологий…" – подписываюсь!

  95. 42
    Олег Андреев ответил:

    Дима Мироводин дело говорит.

  96. 41
    Дима Мироводин ответил:

    На счёт развития языка… хм спорно. Языки обычно разрабатываются под конкретные задачи. Как то : простота мат-е моделирование (фортран), удобная работа с множествами (SQL), назкоуровневое взаимодействие с железом (asm) и т.д. и т.п.
    Т.е. прежде всего ЗАДАЧА, а уже потом язык программирования. Язык, IDE – это прежде всего инструмент.
    Требуется решать новые задачи – появляются новые инструменты (языки/IDE),развиваются старые. Нету новых задач – нет развития языка.
    Все очень просто. За эволюцию отвечает как раз задачи. Была задача распилить дерево – изобрели пилу, забивать – гвозди вот и молоток. Хотя если вбухивать уйму $ в язык/технологию – ее легко навязать всему миру, и народ будет забивать гвозди стамеской :) Вообще нужно быть проще и писать на том, что лучше знаеш, при этом держать руку на пульсе технологий…

  97. 40
    Андрюшка Барыкин ответил:

    "Делфи как среда разработки для новых проектов – мертва." – бугага. Простите, но если вы не применяете Дльфи, это ничего не значит. как тут уже сказали, что у Связки Дельфи+СУБД не такие уж сильные конкуренты. Это благодаря многочисленным поддерживаемым технологиям доступа.
    "Что касаемо поддержки старых – то знаете, есть много банковских систем времен 60х-70x, написанных на Коболе и их тоже надо поддерживать. Что из этого следует что Кобол жив?"- наверное стоит различать одноразовые(применяемые для нужд одной компании) проекты и серьезные многофункциональные настраиваемые проекты, на которых сидят конторы поболее Мелкого банка. Кстати, Кобол же включен в языки, поддерживаемые .NET. По-вашему он как раз развивается %)
    "В делфи нет инноваций, он не развивается. А язык который не развивается -мертв." – поясните, честно не понимаю?

    з.ы. Хотя мне с#, в отличие от С++, нравится больше. Правда после него я впервые для себя понял, что чистое ООП – это ппц. :) На каждую фенечку свой класс, в итоге в более-менее серьезном проекте крайне сложно разобратся в коде. Хотя может я один такой.
    Чем мне Паскаль/Дельфи нравится – это единственный язык, код проектов, написанных на нем, можно понять без камментов. %)

  98. 39
    Денис Рысцов ответил:

    Виктор, C# эволюционирует – существует уже три версии языка, да и cpp тоже, но медленнее. За эволюцию первого отвечает компания, второго комитет. А кто отвечает за паскаль?

  99. 38
    Павел Иванов ответил:

    если вы про Паскаля, то он вправду умер. =) что же до языка, то нехнаю, я с него начинал. и даже вполне нормальные игрушки писал… не, он нужен. я постоянно вижу, как маленькие программеры с него начинают свой путь. в общем forever!

  100. 37
    Виктор Матузенко ответил:

    > В делфи нет инноваций, он не развивается. А язык который не развивается -мертв.

    А какие инновации сейчас в C# и C++ ? По вашему определению все языки мертвы.

  101. 36
    Евгений Михайлин ответил:

    Делфи как среда разработки для новых проектов – мертва. Что касаемо поддержки старых – то знаете,есть много банковских систем времен 60х-70x, написанных на Коболе и их тоже надо поддерживать. Что из этого следует что Кобол жив?
    В делфи нет инноваций, он не развивается. А язык который не развивается -мертв.

  102. 35
    Женя Финкельштейн ответил:

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

  103. 34
    Владимир Веревкин ответил:

    ИМХО
    Как среда программирования паскаль умер.
    Как язык программирования ObjectPascal жив, сам кодирую на дэфли. Что в языке нравится – более гибкий и строгий синтаксис, в отличие от сишника. Что не нравится – как и все языки постепенно заходит в идеологический тупик, так как сам язык не развивается. Хотелось бы собрать небольшую команду небезразличных людей для анализа, что же всётаки нужно от языка/среды, какими должны быть языки/среды будующего, и продвинуть как следует эту тему :)

  104. 33
    Дима Мироводин ответил:

    На данный момент очень много успешных коммерческих проектов для win32api реализовано на связке Delphi/СУБД, как следствие огромное количество наработок – компоненты/модули/библиотеки. Это что касается прикладного программирования. Второй момент – ShareWare, тут такая же ситуация. По этому язык/IDE в качестве средства разработки для win32api просуществует еще долго. Думаю лет 5-7. До тех пор, пока не будет полнейшего засилия web и тонких клиентов, для всех типов приложений. Уж больно большая у него нише, и не такая бурно развивающаяся, как допустим web технологии. На данный момент в нише прикладного программирования, автоматизации предприятийи т.д. я альтернативы не вижу. И если делать новый проект с толстым клиентом, я бы выбрал delphi.

    Как вариант изучения в вузе – основы 1 семестр Да. полностью ориентироваться на delphi – нет.

  105. 32
    Тёма Демура ответил:

    Паскалю спасибо, второй язык, который я выучил и разобрался в программировании…
    Pascal Forever!!!

  106. 31
    Денис Боровиков ответил:

    Вижу тут подняли вопрос каким языкам нужно учить студентов в университете. Ответ – никаким. У нас на кафедре делают так: вначале учать простой алгоритмике на паскале (т.к. не надо осбо заострять внимание на синтаксисе), затем идет скудный ознакомительный курс Delphi и C++. Это все тупизм полный, но для тех кто не прогал очень эффективно. Параллельно читается курс ООП в виде общих концепций, вполне адекватная весч. А дальше на мой взягяд очень разумный ход – на 3 семестре пишется курсач, причем на любую тему и на любом язык, защита курсача состоит в том, что бы ты мог объяснить почему ты выбрал именно этот язык для данной задачи и какие технологии использовались в написании. Благо предмет так и называется "Технология программирования". А читать синтаксисы языков в универе это бред.

    А насчет паскаля, то скажу, что меня он вполне устраивает. Если мне поставили задачу написать приложение под Win на unmanaged языке, что бы работало на любой машине, я бы выбрал Делфи, а не MFC/ATL и прочий треш. А вообще мне более интересны управляемые языки.

  107. 30
    Алексей Горюшин ответил:

    Его ещё учат в колледжах и даже в школах преподавать пытаются. По-моему, ему давно пора на покой. Всех его возможностей я не знаю, но знаком и с Borland и с FreePascal. Обе очень не привычные для меня, система отладки тяжеловата, и работать из под DOS тоже фонтан. Прадва, если его правильно учить, то он вполне запоминаем и работать можно. Лично мне в школе его преподавали в 11-ом классе, поэтому сами понимаете ничего серьёзного, но сейчас через год(!) всё, что проходили, вспомнил. Отсутствие графического интерфейса упрощает многое, но с ним прога и цивильнее выглядит, и пользы от неё больше. Мне на самом деле знание Pascal во многом помогло при изучении VB в инсте.

  108. 29
    Виктор Матузенко ответил:

    > Ага, в подключением всех его библиотек-то 500 байт?

    А зачем? :) Мне кроме windows и opengl ничего не нужно.
    По-поводу того, что дельфи – это только библиотеки – вы ошибаетесь. В дельфи нет шаблонов – однако все остальные сипиписьные возможности в нем присутствуют.
    Но, в С++ нет динамических массивов, нет юнитов (а лишь геморойные инклуды), property, interface'ов.

    Кстати, MFC тоже громоздко и устроено по-уродски.

  109. 28
    Алексей Злобин ответил:

    Ага, в подключением всех его библиотек-то 500 байт? Делфи это не компилятор, с помощью которого действительно можно получать компактный код, а библиотеки, котрые весят дохрена, тормознуты, и организованы очень по уродски ИМХО.

  110. 27
    Виктор Матузенко ответил:

    > Delphi НЕЛЮБЛЮ, слишком раздутый код собирает

    Я спокойно напишу Delphi-приложение в 4КБ.

    И знаю человека, который может написать приложение на Дельфи в 500 байт.

    А ты, сможешь на компактном си написать такое? :)

  111. 26
    Александр Карпов ответил:

    PS в тему будет сказано: кто не был, есть такой проект FreePascal – freepascal.org. Там есть open-source Паскаль и Делфи-совместимая штука под названием Lazarus.

  112. 25
    Александр Карпов ответил:

    Сам по себе Pascal язык как язык. Очень даже неплох в общемто (хотя мне все ж Си больше нравиться). Delphi НЕЛЮБЛЮ, слишком раздутый код собирает (а ведь можно было оптимизировать както по-другому, чтобы все было круто). Думаю врят ли Pascal в ближайшее время умрет. Конечно есть более интересные языки, к примеру Prolog, Smalltalk. Но если с чегото начинать, то пожалуй Pascal может оказаться неплохим вариантом — цельные англ.слова, понятная структура.

  113. 24
    Виктор Матузенко ответил:

    Несколько утверждений, сказанных здесь, устарели где-то на два года :)

    Смерть дельфи была связана с тем, что основные ее разработчики перешли в microsoft для разработки C#.

    Год назад от компании Borland отделилась группа программистов под названием CodeGear, которая занялась разработкой продуктов Turbo, в частности TurboDelphi:
    //turboexplorer.com/delphi
    (кстати, по той ссылке которую я дал, находится бесплатная турба. Нужно только зарегестрироваться на сайте borland и получить ключ)

    Delphi сейчас как раз расцветает, а вот C++ постепенно умирает, ибо все сейчас разрабатывают C# :)

    Поэтому все присоединяйтесь сюда
    //vkontakte.ru/club91322 :)

  114. 23
    Михаил Вехорев ответил:

    У нас в ЛЭТИ процесс образования делится на две большие группы.
    Одних с первого курса учат Pascal другие сразу Си. Ну так вот
    вся лабуда с Паскалем оканчивается на третьем курсе, так как их
    заставляют переходить на Си. Я лично на Паскале кодил, когда
    еще в колледже учился, а теперь как только Си попробовал, ну дак
    и совсем забыл что такое Паскаль. На мой взгляд он тихо отживает.
    Я думаю Паскаль можно только школьникам в курсе информатики
    преподавать, чтобы потом уже в универе они без проблем влились в
    Си, С++ и прочее подобное.

  115. 22
    Олег Андреев ответил:

    Поэтомуумный дядя Матсумото изобрел язык Руби, который не парит излишней абстракцией, но позволяет расширять и поддерживать код легко и быстро.

  116. 21
    Андрюшка Барыкин ответил:

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

  117. 20
    Михаил Голуб ответил:

    Универсальные вещи это еще та хрень на самом деле…
    Программа должна быть универсальной ровно настолько, Насколько нужно конкретно сейчас и возможно через некоторое время.
    Почему? Потому что:
    а) Предугадать все невозможно.
    б) Универсальность может и не потребоваться.
    в) Это ОЧЕНЬ СЛОЖНО, Я начитался Буча и GOF'а и решил, что буду делать абсолютно гибкие красивые архитектуры. Так вот, я завалился еще на стадии проектирования, у меня были глубокие 5-10 деревья абстракций, у меня было абстрактно абсолютно все. Абсолютно любой кусочек можно было поменять. В теории… На практике, я не осилил даже прототип . А оно там нафик не надо было.
    Я к чему это пишу. Не конкретно к посту выше. А вообще: излишняя абстракция – есть корень всех зол.

  118. 19
    Андрюшка Барыкин ответил:

    Может быть у нас области деятельности сильно отличаются, в связи с этим у каждого свое соотношение теории(алгоритмов и т.д.) и практики. Я работаю большей частью с БД, областью, где ты без теории(построение, проектирование , нормализация) не сделаешь НИЧЕГО по-настоящему серьезного и работоспособного, либо огребешь последствия хренового проектирования позже. Да и стоит учесть, что сейчас 80% прогрммных продуктов так или иначе юзат БД.
    Да проектировать не только структуру БД надо.
    Теория нужна, чтобы создавать универсальные вещи, а не жестко привязанные к конкретным условиям.
    з.ы. опять же я нигде не пишу, что не надо изучать язык. %) Просто считаю, что человек, опыт которого подкреплен теорией, более грамотный специалист, вот и все.

  119. 18
    Олег Андреев ответил:

    Алгоритмы-алгоритмы. Они составляют только 20% от вашей работы. Остальные 80% – это не теория, о самая-самая практика: конфигурация ОСи, ее процессы, настройка сетевой карты на конкретной машине, обработка XML конкретным парсером, глюки конкретного фреймворка, а главное — разработка софта в составе команды. А это из области не технической, а психологической. И этому почти нигде почти никак не учат. А этим вещам вы должны уделять большое внимание, понимать их значимость и учить их самостоятельно. Иначе — знающий алгоритм выделения дерева Дейкстры чувак, который будет неделю копаться в горе мануалов чтобы хоть как-то криво сотворить этот алгоритм не на Сишарпе (на другом не научили), а на Си или Перле под Линуксом-Дебияном.

  120. 17
    Евгения Воробьева ответил:

    Согласна с Андреем, именно этому насучат…построенпию алгоритмов….И учат не плохо, а вот как дело доходит до реализации возникают проблемы… проблемв по большей частью даже не с пониманием алгоритма а с представлением его на языке….

  121. 16
    Егор Коновалов ответил:

    вот вы про паскаль спрашиваете… а нас в универе учать ассемблеру для PDP-11 (в России был аналог СМ-3)… :-) … вот что действительно давным давно умерло :-)

  122. 15
    Андрюшка Барыкин ответил:

    Это значит, что надо ботать не синтаксис, а технологии, алгоритмы, подходы и т.д., не привязанное к конткретному языку. Это значит, что ты сможешь расписать свою задачу в виде блок-схемы и её сможет реализовать человек, рюхающий синтаксис конкретного языка. Когда ты все это будешь уметь, изучить синтаксис языка будет не трудно.
    Если ты решишь задачу абстрактно, без собственно кода, то ты ее решишь на почти любом языке. Обратное не верно в общем случае.
    з.ы. Я нигде не говорил, что не надо изучать языки. :)

  123. 14
    Михаил Голуб ответил:

    Всегда поражался, как понимают эту фразу.
    Это что означает, что нужно учить общие концепции? А язык – ваш инструмент – это типа фигня, да? Его знать не надо?

  124. 13
    Евгения Воробьева ответил:

    Да уж, Паскаль может и не мертв,но меня он скоро убьет…никак в толк не возьму зачем нас учат на этом языке, ну не понимаю я этого….

    P.S. Кто-нибудь может помочь написать программу "пятнашки" на паскаль…..ну очень надо…

  125. 12
    Андрюшка Барыкин ответил:

    Изучать надо не язык, а программирование %)

  126. 11
    Андрюшка Барыкин ответил:

    Паскаль(Дельфи) умирает с начала его появления, но все никак не умрет. Зайдите на SQL.RU и посмотрите вакансии, до сих пор можно найти работу Дельфи-программистом.
    Ниша Дельфи – это все, что связано с БД, потому что там реализована куча популярнейших технологий доступа к данным, а также можно создать хороший "дружественный" интерфейс благодаря замечательной библиотеке VCL.
    Есть такаякрупнейшая русская софтверная компания EOS, в которой я недолго проработал. У нее в клиентах Гос.Дума, Генеральная прокуратура и т.д. Пишут универсальные, максимально гибкие, настраиваемые информационные системы. Получают за поддержку своих 2-х крупных систем(Документооборот и учет кадров). Так вот Учет кадров создан на Дельфи. Это я к тому, чтр до сих пор есть куча программного кода, который надо поддерживать. Так что Дельфа не умрет. У самого сейчас основной язык на работе Дельфи, хоть и изучаю C#. Была бы возможность, все на Дельфе и делал бы.
    С сайта citforum:
    //www.citforum.ru/computer/2006-10/
    "Когда в 1968 г. проводилась конференция NATO по инженерии программного обеспечения, практически в первый раз собрались вместе люди из академии и индустрии для обсуждения проблем проектирования и разработки программного обеспечения. Представители обоих лагерей публично признались в том, что не знают, как хорошо разрабатывать программное обеспечение. Отчетливыми симптомами кризиса программного обеспечения являлись частые нарушения сроков завершения работы, перерасход средств, наличие ошибок в программах и неспособность к обучению программированию.

    Эта конференция и ее участники побудили к выполнению многочисленных исследований в конце 1960-х – начале 1970-х гг. Наиболее важный и плодотворный вклад в эти исследования внесли Эдсгер Дийкстра, Тони Хоар и Никлаус Вирт. К числу их достижений относятся аксиоматическая основа языков программирования; теория слабейших предусловий, которая привела к созданию методологии формальной разработки алгоритмов; пошаговая детализация; структурное программирование; достижения в области языков программирования: Pascal, охраняемые команды, взаимодействующие последовательные процессы.

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

    По словам американского ученого-лингвиста Бенджамина Уорфа (Benjamin Whorf), они делали акцент на простоте и красоте и полагали, что язык должен способствовать четкости мышления. Эти принципы теперь редко упоминаются в контексте программирования. Мы продаем свои программистские души, когда начинаем обучение с педагогически вредных и интеллектуально ужасных языков C и C++.

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

    Они сосредотачивались на вопросах корректности и той мысли, что программа и ее доказательство должны разрабатываться совместно, и идеи доказательства должны главенствовать в этом процессе. В настоящее же время большая часть выпускников, специализирующихся в области компьютерных наук, не знают смысла слова инвариант, хотя инвариант цикла является базисным инструментом инженерии программного обеспечения, позволяющим понимать независимые части цикла (инициализацию, условие завершения, продвижение к завершению) без потребности анализа других частей.."
    А это в вопросу про обучение на Паскале.

    з.ы. Я не призываю всех на Дельфи переходить :) Просто хоронить его рано ;)

  127. 10
    Андрей Старосветский ответил:

    Считаю, что Паскаль однозначно не устарел, всё зависит от задачи.
    Пишу на Си++, Паскале и Ассемблере. Собираю самодельную периферию для компа и для отладки взаимодействия с ней на низком уровне Паскаль подходит идеально.
    Так же обстоит и с компами, i80286 не умерли 15 лет назад, они до сих пор очень удобны в качестве контроллеров, а 486'ые до сих пор производятся для промышленной автоматики.

  128. 9
    Михаил Голуб ответил:

    Как по мне, АОП это просто новые (но старые) идеи в ООП, которые позволяют решать некоторый круг задач (так называемая сквозная функциональность) более эффективно.

    Ты кстати с очень большой вероятностью используешь АОП. Те же фильтры в веб-приложениях – это самое настоящее АОП.

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

  129. 8
    Алексей Злобин ответил:

    Михаил, тебя клинит на количестве. Из 6ти языков, которые по ходу обучения мне пришлось выучить мне реально нужен 1н, на горизонте других нет.
    По теме: паскаль мне не нравится по трём причинам.
    Во-первых очень громоздкий синтаксис.
    Во-вторых очень неудачная модель модульности.
    В-третьих крайне криво притянуто было ООП к нему (с одной стороны нет полной виртуальности в работе с памятью, с другой нет красивого включения низкоуровневых функций, как в С++).
    Насчёт университетских программ, я бы предпочёл схему: год-полтора плотного изучения чистого С, с полгода асма, около года изучения ООП на основе С++, около года на извращения типа Лиспа и Пролога, и под конец чистый объектный язык типа Руби.
    Принцип построения схемы прост: сначала излагается некоторые общие понятия программирования, это удобнее, конечно делать на паскале или бейсике, но они потом повисают мёртвым грузом. Далее сложное в С, для полноты картины асм(ну надо знать устройство проца и прочего железа, хоть и кодится 80% всего под виртуальные машины, но надо). Введение в ООП пределенно лучше на С++ проводить, ибо с простого надо начинать, может не у всех так, но мне проще было понимать ООП на его примере, с прямыми связями между объектами и областями памяти, методами и простыми фнкциями.
    Функ. и Лог. программирование… ну надо, просто чтоб соображалку поразминать…
    Ну и тяжёлое ООП под конец… Для выживших =))
    Писал пост, возник вопрос: стоит-ли вводить в программы АОП? Это реально следующий виток эволючии программирования, или временно набежавшая мода?

  130. 7
    Олег Андреев ответил:

    Студентов нужно учить на следующих языках (одновременно, по возможности):

    1. Си
    2. Руби
    3. Лисп/Ским

    Асмы, си++, джавы и сишарпы – факультативно. Паскаль – нафиг. Понятно, что стоит знать баш, перл, питон, тисиэль и еще хрен знает что, но это по ходу дела и от личного интереса.

    Почему именно эти три?

    1. Си — это более дружелюбная версия Асма. На нем удобно учиться тому, как в компутере все работает на низком уровне.
    2. Руби — это наиболее прагматичный и одновременно мощный динамический язык: на нём легко учиться ООП, причем в лучшем его проявлении. После руби понятно, что чрезмерное увлечение Джавы паттернами и классами-врапперами — от бедности языка, а не от сути задачи.
    3. Лисп — метаязык, на котором можно превосходно изучать функциональное программирование, теорию алгоритмов, разные компьютинговые проблемы в общем виде ("теоретическом"). Например, проблемы многопоточности.

    Соответственно, Си++, СиШ, Джава — из серии постановки ООП (изученного на Руби) на низкоуровневые рельсы (изученные на Си). Их знать надо, но обучать теоретическим вещам на них — неэффективно (если не вредно). Перл, Питон, Бейсик — менее мощные динамические языки по сравнению с Руби, так что их оставить для любителей.

    Вместо Лиспа можно попробовать поставить Хаскел, но я не уверен, что это хорошая идея.

    Эрланг и Ио — специальные концептуальные языки, тоже полезные для рассмотрения.

    Ну, а Паскаль сдох. Это старый язык, в котором нет нужных сегодня вещей, и которые никогда в нем не появятся (в отличие от СиШ и Джавы). И продолжать учить на нём компьютерным дисциплинам — малоэффективное занятие.

  131. 6
    Михаил Голуб ответил:

    Я предпочитаю использовать лучшие из доступных мне инструментов.

    По теме: да, Паскаль умирает. Почему умирает? Потому что выезжал он только лишь на клевой IDE – Delphi. Чувак, делавший Delphi свалил в дотнет. С 6-й версии в Дельфях полный застой. Сейчас они (Codegear) пытаются выехать, добавив поддержку .NET'а. Все. Никакой ценности у технологии нет.
    Мне его не жалко, С целью – обучать студентов программированию он успешно справлялся последние лет 30. Сейчас на смену пришли более вменяемые языки: python и ruby.

  132. 5
    Анзор Апшев ответил:

    Да?, охуительно, я рад затебя. Ништяк что выразил свое мнение относительно темы.Я желаю тебе выучить тебе эти 5 языков, а потом еще 20 которые к этому времени появятся. Цель программирования в моем понимании не в бесконечном изученииновых языков.

    Просьба ко всем: Не переходить на личности и не превращать тему в базар. если кому то я не понравился просьба оставлять мне личные сообщения, а здесь писать только то чтоу вас есть по теме.

  133. 4
    Михаил Голуб ответил:

    Не видишь смысла? Сиди на пятой точке и дальше. Через 20 лет будешь все так же знать один паскаль.
    Я вот для себя вижу языков 5 как минимум, которые мне очень хочется на нормальном уровне освоить, даже если я не буду на них писать, я освою парадигмы и приемы, которые в них используются на полную катушку. И применю эти знания в своей работе.

    Ага, только вот тому же Ruby вообще никто не помогал. Он выехал на своей прагматичности, безумной гибкости и killer app: ruby on rails. И вот такие вещи я ценю, а не рекламки от Sun, MS и IBM. Если бы в паскале было хоть что-то стоящее, он бы нашел свою нишу. Не вижу я сейчас ниши для паскаля. Разве только как еще один язык для .NET-платформы для программеров, которым лень переучиваться и использовать нормальные языки.

    Назову даже не одну, а целых две: Всем известная IBM и Питерская Jetbrains с их Intellij IDEA.

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

  134. 3
    Анзор Апшев ответил:

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

    Во первых когда компания выпкускает компилятор и VM для языка это в моем понимании называется поддержкой.

    Во вторых назови хотя бы еще одну компанию кромеBorlandпродукты которой способны составить конкуренцию Microsoftна рынке средствразработки(IDE,компиляторы и т.д.)

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

  135. 2
    Михаил Голуб ответил:

    Не хотите учить новые языки, так и скажите себе.

    А мы будем и дальше писать на языках с идиотскими сборщиками мусора и псевдопереносимостью.

    И Microsoft не поддерживает Java, более того, она выпустила свою Java (C#) после того, как получила по голове за внесение изменений в Microsoft JVM, сделав ее непереносимой.

    И еще раз перечитал ваш пост. Какой бред вы несете. Особенно про единственного конкурента в этом сегменте. Все же переспрошу, в каком сегменте?

    Прежде чем устраивать голосования в стиле:
    1. Паскаль ниипацца крут.
    2. Мне на него пох.
    3. Ф топку Паскаль
    потрудились бы расширить свой кругозор.

  136. 1
    Денис Рысцов ответил:

    Мне все равно, я не вижу разницы между Delphi, Java, C# (1,2), отчасти Cpp…
    Как языки, они очень похожи, да и задачи, которые с их помощью решаются тоже. Например, когда мне в универе дали задание написать визуализатор алгоритма сжатия LZV на Delphi, я написал его на C#, а затем портировал на Delphi в течении дня (не зная Delphi). То же самое было и с языком Java.

    Поэтому я не вижу ценности в этих языках, следовательно, мне все равно если кто-то из них умрет.

    Я точно уверен, что слышал, но не уверен в точности следующего:
    1) Borland продает бизнес связвнный с Delphi
    2) Когда-то Microsoft и Borland поделили рынок – первой Basic, второй Pascal

Клуб программистов работает уже ой-ой-ой сколько, а если поточнее, то с 2007 года.