Будущее Делфи?

← →
test © (2009-04-02 17:42) [40]

Kostafey © (02.04.09 17:40) [38]
Учат программирование, язык только как иллюстрация.

← →
Городской Шаман (2009-04-02 18:20) [41]

> Kostafey © (02.04.09 17:40) [38]
>
> А алгоритм - это да, он и в Африке алгоритм,
> согласен :)

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

А для алгоритмов достаточно книжечки на 200 страниц, чтобы бы быть профи. Алгоритмы больше все таки математика, чем программирование.

← →
DVM © (2009-04-02 19:29) [42]

> Городской Шаман (02.04.09 18:20) [41]

> А для алгоритмов достаточно книжечки на 200 страниц, чтобы
> бы быть профи

Сразу Кнут с его томами почему то вспомнился.

← →
Кто б сомневался © (2009-04-02 19:38) [43]

> test © (02.04.09 17:28) [34]
>
> Кто б сомневался © (02.04.09 17:16) [31]
> Изменится в чем?
> Ты знаеш как будет развиваться отрасль в целом?

Нет не знаю, но увидеть тендецию - к чему все идет, думаю любой сможет.
И вероятность здесь очень высока.

← →
Копир © (2009-04-02 19:44) [44]

>kaif (02.04.09 02:22) [8] :
>Eraser © (02.04.09 02:27) [9] :
>Игорь Шевченко © (02.04.09 02:46) [10] :

Я тоже тащусь от "языка Delphi".

Ну что поделать, когда визуальные компоненты и библиотека
RX в каком-то смысле действительно заменяет "язык".

Кликнул мышкой и стал календарь.
Кликнул дважды - глядишь и тут же сервер на продажу.

Молодые респонденты или никогда не знали (скорее всего),
что такое язык программирования "Pascal".

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

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

В этом смысле ув.господин DMM прав.

← →
Игорь Шевченко © (2009-04-02 19:49) [45]

Kostafey © (02.04.09 17:40) [38]

Философия одна и та же. Найди, плз, 10 отличий именно в философии языка между C/C++, Delphi, Java и C#

← →
Игорь Шевченко © (2009-04-02 19:50) [46]

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

Это как ?

← →
Копир © (2009-04-02 20:04) [47]

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

От арабского языка, например.

Первое отличие: это своеобразие иероглифов.

Совокупность Begin ... End сумеет заметить только
очень продвинутый переводчик.

Второе отличие в том, что можно сколько угодно взывать
к Аллаху в СМИ. Эти взывания, наверное (или возможно)
не приведут ни к какому действию.

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

Действия программиста и в 90-е, и в нулевые годы, и сейчас,
почти в десятые годы нового века. Они всегда сопряжены с конкретной
задачей. С бухгалтерской, с купеческой, с хакерской, с буржуйской...

Не нам судить.

Программисту платят деньги.
Он реализует проект, который был заказан.

Какие проблемы?

← →
TUser © (2009-04-02 20:29) [48]

> Ega23 © (02.04.09 17:23) [32]
>
>
> > В ближайшие лет 15 думаю все измениться окончательно.
>
>
> Раньше. Вот БАК запустят - и КС сразу настанет.
>

сам Хиггс мешает

http://elementy.ru/news?newsid=431042

:)

оффтопик: Олег, а ты аську читаешь?

← →
Alkid © (2009-04-02 20:31) [49]

> Городской Шаман (02.04.09 16:24) [21]
> Не потеснили. Просто для ниши корпоративного ПО были созданы
> более соответствующие технологии как Java и .ПТУ.

Потеснили. В качестве примера приведу тот факт, что прошлая версия продукта, разрабатываемого в нашем отделе была написана на 100% на С++, а нынешнюю версию разрабатывают на C#.

> C++ мощный и удобный язык, но не походит для студенческо-
> бардачной разработки. А вот то же приложение написанное
> студентами на .ПТУ, криво, глючно и тормознуто, но как-то
> работать будет. Что чаще всего и достаточно для бизнеса.

Не вижу разницы в бардачной разработке на С++ и на C#, с той лишь разницей, что на С++ будет AV и утечки памяти, а на C# будет NullReferenceException и не будет утечки памяти. Хороший же код на обоих языках требует высокой квалификации разработчиков.

← →
blackman © (2009-04-02 20:38) [50]

Философия одна, а написание, оформление, выделением памяти и со строковыми и ... все разное.
А философия конечно одна. Двух и быть не может.
Французский, английский, русский тоже в чем-то похожи.
Но учить нужно отдельно. Потом легче.
Только диалекты освоить и переводчиком будешь:)

Копир © (02.04.09 20:04) [47]
Программисту платят деньги. Он реализует проект, который был заказан.
Какие проблемы?
Никаких, кроме упорного труда.

← →
Копир © (2009-04-02 20:50) [51]

>blackman © (02.04.09 20:38) [50] :

Юрий, я понял и проникся.

Вы знаете, иной раз гораздо легче утопить себя в традиционной ветке, нежели
потом топиться в ветках выделенных :))

← →
Городской Шаман (2009-04-02 20:54) [52]

> Игорь Шевченко © (02.04.09 19:50) [46]

Ну например в C++ нет делегатов(замыканий) на уровне языка (есть сторонний плагин на templat-ах). И вы видели как спроектирована MFC с её картой сообщений и прочими извратами? Самый яркий пример.

← →
Alkid © (2009-04-02 21:03) [53]

> Копир © (02.04.09 20:04) [47]
> Программисту платят деньги.
> Он реализует проект, который был заказан.
>
> Какие проблемы?

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

← →
Kostafey © (2009-04-02 21:25) [54]

> [45] Игорь Шевченко © (02.04.09 19:49)
>Философия одна и та же. Найди, плз, 10 отличий именно в философии языка между C/C++, Delphi, Java и C#

10 отличий не потяну. Лишь 2-3 :).

Ну для меня ключевое отличие - это работа со
ссылочными типами.
В С++ все ссылки, указатели описывается явно.
В свое время переходя на Java сначала было
непривычно. Все (за исключением базовых типов) -
есть ссылки.

Другое ключевое отличие Java/C# vs С/С++ это
крайне строгая типизация.
Delphi/Pascal тут где-то по середине будет.

Еще неприятность - невозможно передать функцию
в качестве параметра. В С++ и Pascal это враз.

← →
Kostafey © (2009-04-02 21:27) [55]

> [44] Копир © (02.04.09 19:44)
> [47] Копир © (02.04.09 20:04)

<offtop>
Что курим? Я тоже так хочу! :)
</offtop>

← →
@!!ex © (2009-04-02 21:27) [56]

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

Это немножко заблуждение.
Пример MFC и VCL. VCL грамотно реализовать в рамках C++ насколько я понимаю нельзя(билдер не в счет, там вообще непонятно что за язык, адская смесь какая-то)

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

← →
AndreyV © (2009-04-02 21:35) [57]

> [48] TUser © (02.04.09 20:29)
> > Раньше. Вот БАК запустят - и КС сразу настанет.
>
> сам Хиггс мешает
> http://elementy.ru/news?newsid=431042
> :)

Славные грибочки уродятся. Сотрудники ЦЕРН решили сами продегустировать выращенный к 1-му апреля пробный урожай.:)

← →
blackman © (2009-04-02 21:55) [58]

AndreyV © (02.04.09 21:35) [57]
Апрель наступил и это есть хорошо!
Песня Булата Окуджавы такая есть
Мама, мама, это я дежурный. Я дежурный по апрелю
http://articles.org.ru/cn/showdetail.php?cid=5553
Это лучше чем спор о будущем :)

← →
Alkid © (2009-04-02 22:13) [59]

> @!!ex © (02.04.09 21:27) [56]
> Это немножко заблуждение.
> Пример MFC и VCL. VCL грамотно реализовать в рамках C++
> насколько я понимаю нельзя(билдер не в счет, там вообще
> непонятно что за язык, адская смесь какая-то)

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

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

Не спорю, выбор технологии имеет значение, но он не обуславливает успех.
А некоторые тут (не буду пальцем показывать), утверждают, что если программа пишется на С++ - то это означает, что программа серьезная и качественная. А если на .NET, то не иначе как студенческая поделка.

← →
oxffff © (2009-04-02 22:16) [60]

> Alkid © (02.04.09 20:31) [49]
> Не вижу разницы в бардачной разработке на С++ и на C#, с
> той лишь разницей, что на С++ будет AV и утечки памяти,
> а на C# будет NullReferenceException и не будет утечки памяти.

Это не правда.

> Хороший же код на обоих языках требует высокой квалификации
> разработчиков.

Я бы сказал, что написать хороший код на .NET нужно очень очень очень сильно постараться. Поскольку достижимость объектов не всегда очевидна.
Создал объект, создал делегат на его метод, передал его(делегат) другому объекту. Вызвал как ты(пользователь) думаешь явный финализатор.
Прибил на него ссылку. Но другая ссылка то на него висит через делегат.
Забыл удалить из списка делегатов. Вот тебе не mem leak, а хуже.
Повисший кусок памяти, + нет никакого AV, если конечно метод обернутый в делегат не проверит is disposed.
А теперь скажи много так делать будут, проверять is disposed?

Минус первый.
Разработчик должен помнить куда он что передал. И не дай бог. Чтобы переданный объект ктонибудь не клонировал(а если мы клонируем тот самый делегат, то оследить будет ой как сложно, только спец. средства которых что-то много стало появляться для .NET)

Минус второй.
Для того чтобы сделать код безопасным придется повтрять в каждом коде метода IF is disposed {raise exception(Finalized object state")};
Интересно как скоро они добавят это в стандарт. В качестве каконибудь атрибута класса. По типу при генерации native кода метода,если у класса есть атрибут GenerateCheckForDisposedState, добавить предикат на проверку валидности.
Я могу даже эту идею им продать. Если никто из .ПТУ разработчиков об этом еще не догадался. IMHO.

← →
Alkid © (2009-04-02 22:23) [61]

> oxffff © (02.04.09 22:16) [60]
> Это не правда.

Конечно неправда :) На .NET можно устроить утечку памяти, на C# можно даже AV сбацать, благо unsafe никто не отменял. Но в общем и целом утечка памяти для .NET приложений - это очень редкая птица.

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

Может быть я не занимался столь сложными и запутанными программами на C#, которые тебе приходилось писать, но подобных проблем у меня ни разу не возникло.

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

← →
Internal Tracking (2009-04-02 22:27) [62]

> > > Раньше. Вот БАК запустят - и КС сразу настанет.
> >
> > сам Хиггс мешает
> > http://elementy.ru/news?newsid=431042
> > :)

Первое апреля. Блин а я поверил....

← →
oxffff © (2009-04-02 22:33) [63]

> Alkid © (02.04.09 22:23) [61]
>
> Может быть я не занимался столь сложными и запутанными программами
> на C#, которые тебе приходилось писать, но подобных проблем
> у меня ни разу не возникло.

Приветствую тебя. :)
Несмотря на то, что у меня есть и оба издания Рихтера по .NET, которые я прочитал и ECMA 335, ECMA 334, которые я тоже читал в рамках общего развития и читал также Expert .NET IL Assembler также оба.
Я скажу честно, работа с С#, Nemerle и другими .NET языками меня пока обошли стороной.
IL Asm и IL Dasm смотрел. Интересно.

Я сейчас больше как то по ABAP.

Хочу отметить, что в C# некоторые конструкции в плане выразительности меня очень очень сильно привлекают.
И я бы желал такое уже в Delphi сейчас.
А также не generics, а concepts из следующего стандарта по С++
в native Delphi.

← →
ZeroDivide © (2009-04-02 22:38) [64]

Delphi - фарева!

← →
oxffff © (2009-04-02 22:42) [65]

> А также не generics, а concepts из следующего стандарта
> по С++
> в native Delphi.

А об этом на мой вопрос один из разработчиков компилятора Delphi ответил, (я привел ему доводы по поводу недостатков generics для native платформ).
Возможно concepts в delphi в Delphi.

Естествено C++ template для очень сильно усложнит и замедлит генерацию native кода, придется существенно расширить набор generic IL команд для всех операторов. + не будет никакой гарантии в полной безопасности этого кода. Поэтому generics + constraints очень удобное сочетание для .NET.

← →
Alkid © (2009-04-02 22:43) [66]

> oxffff © (02.04.09 22:33) [63]
> Приветствую тебя. :)

Я тоже тебя очень рад видеть :)

> Несмотря на то, что у меня есть и оба издания Рихтера по
> .NET, которые я прочитал и ECMA 335, ECMA 334, которые я
> тоже читал в рамках общего развития и читал также Expert
> .NET IL Assembler также оба.
> Я скажу честно, работа с С#, Nemerle и другими .NET языками
> меня пока обошли стороной.
> IL Asm и IL Dasm смотрел. Интересно.

Ну, у меня ситуация несколько обратная - я в кишки .NET-у особо не залезал, но и для личных проектов и на работе использую достаточно активно. Сейчас, например, пишу интерпретатор одного экспериментального декларативного языка. Сильно оценил итераторы и сборщик мусора. Кстати, там же я создавал структуры данных со столь запутанной системой ссылок, что без GC никогда бы не распутал. По идее в них должны были проявиться описанные тобой проблемы, но нет - все работает замечательно.

← →
Alkid © (2009-04-02 22:45) [67]

> oxffff © (02.04.09 22:42) [65]
> Естествено C++ template для очень сильно усложнит и замедлит
> генерацию native кода, придется существенно расширить набор
> generic IL команд для всех операторов. + не будет никакой
> гарантии в полной безопасности этого кода. Поэтому generics
> + constraints очень удобное сочетание для .NET.

Обоснуй. C++ template раскрывается еще на этапе компиляции, причем не JIT. Почему там должен получаться небезопасный код?

← →
oxffff © (2009-04-02 22:48) [68]

> По идее в них должны были проявиться описанные тобой проблемы,
> но нет - все работает замечательно.

Можешь проверить?
Честно у меня больше уйдет на синтаксис на С# чем на сам алгоритм.
5000 пар объктов. Один из которых master - содержит делегат на другой. И прибить все root ссылки на slave объекты.

> Alkid © (02.04.09 22:45) [67]
>
> > oxffff © (02.04.09 22:42) [65]
> > Естествено C++ template для очень сильно усложнит и замедлит
>
> > генерацию native кода, придется существенно расширить
> набор
> > generic IL команд для всех операторов. + не будет никакой
>
> > гарантии в полной безопасности этого кода. Поэтому generics
>
> > + constraints очень удобное сочетание для .NET.
>
> Обоснуй. C++ template раскрывается еще на этапе компиляции,
> причем не JIT. Почему там должен получаться небезопасный
> код?

Почему С++ template нет в .NET?
Потому что это очень сильно бы усложнило бы IL набор и саму форму генерации кода.
В .NET assign IL команда является обобщенной(Не нужно указывать тип явно). Однако при генерации IL кода ты не можешь присвоить тип A типу Б, если они не совместимы. Но для этого они придумали хитрый трюк. Зачем делать небезопасный код. Давай классифируемым типы по контрактам(constraints). И сделаем проверку в run time минимальной.

Если бы такой код был допустим (а эта проверка осуществлялась run time), то нельзя гарантировать того, типы совместимы, поэтому такой код был бы в их терминологии Unverifible и не было гарантии того, что что типы совместимы, а если нет то нужно было отрыть по reflection impilict или explicit метод в run time. А это накладно.
В противном случае выдать ошибку.
Для операторов для унарных и бинарных операторов нужно было тоже делать generic IL иснструкции(которые сейчас такими не являются), и также при инстанцировании делать ковыряние reflection на наличие перегруженного метода для этих операторов и не дай бог там еще будет неоднозначный выбор. В их терминологии такой код не является верифицируемым. И сильно усложнил был транслятор IL кода в native.

> [58] blackman © (02.04.09 21:55)
> AndreyV © (02.04.09 21:35) [57]
> Апрель наступил и это есть хорошо!
> Песня Булата Окуджавы такая есть
> Мама, мама, это я дежурный. Я дежурный по апрелю
> http://articles.org.ru/cn/showdetail.php?cid=5553
> Это лучше чем спор о будущем :)

Апрель - хорошо, и песня хорошая, и завтра обещают +10 и ясно, и ещё - весна не оффтопик!:)

← →
Городской Шаман (2009-04-02 23:11) [71]

> @!!ex © (02.04.09 21:27) [56]

Ну почему, последняя реализация WxWidgets, та которая 2-я. Отлично реализовали динамическую линковку событий. Там конечно сделано через шаманство с шаблонами, но работает, причем чистый С++ (но очень не советую пытаться понять как это работает, такого изврата даже на говнокоде не найдёшь).

> oxffff © (02.04.09 23:03) [69]

То есть если ты такое было возможно

ClassA<TypeA,TypeB>
....
TypeA a;
TypeB b;

a=a+b;

Первое встретили бы а и b, блин нет же виртульных методов (по типу equals)да и быть не может для оператора ADD. Лезем в reflection смотрим сигнатуру метода оператора add в типе TypeA с параметром TypeB и возвращаемым значением TypeA. Нету. Ищем с произвольным возращаемым значением. Нашли. Но с возращаемым значением типа TypeC.
Теперь ищем impilicit оператор для TypeC в преобразованием в TypeA.
Не нашли. Сообщили об ошибке в run time. Код небезопасный. Прервали работу поскольку ошибка инстанцирования параметризованного класса.
Некоторые компиляторы вроде сами генерируют код класса, если встречают инстаницрование generic класса в compile time. Некоторые такого не делают, а предоставляют .net сделать за них в run time.

> Некоторые компиляторы вроде сами генерируют код класса,

Вообще то IL код то будет у них идентичен. :)
Точнее в сборку добавляют описание класса.

Городской Шаман (02.04.09 20:54) [52]

> Ну например в C++ нет делегатов(замыканий) на уровне языка
> (есть сторонний плагин на templat-ах). И вы видели как спроектирована
> MFC с её картой сообщений и прочими извратами? Самый яркий
> пример.

А причем тут "архитектура приложений" ? Какое отношение имеет реализация конкретных механизмов к архитектуре ?
Один и тот же проект был написан на С и на С++ (ну так вышло), в С нет виртуальных методов, они были успешно эмулированы на С, как таблицы указателей на функции (примерно также, как карты сообщений в MFC, механизмы достаточно похожи).
Но архитектура приложения осталась без изменений.

Ты вообще хоть какое-то разумное объяснение своим словам про архитектуру можешь дать или с тобой просто бесполезно разговаривать на серьезные темы и кроме ламерского флейма от тебя ничего не добиться ?

Kostafey © (02.04.09 21:25) [54]

Это не философия, это детали реализации.

Пратта читать. Наизусть, до полного и окончательного просветления. Книжку звать "Языки программирования, разработки и реализация". Хоть она и древняя, но довольно фундаментальная и полезная для понимания отличий в философиях языков.

Вот у prolog (Lisp, APL) и у Delphi (C, C++, Java) действительно разная философия...

← →
Городской Шаман (2009-04-03 00:22) [77]

Удалено модератором

> Игорь Шевченко

Архитектура приложения осталась без изменений?
Приложение будучи построено на разных языковых элементах является архитетурно другим.
А неполная эмуляция элементов другого языка или даже подхода не наделяет язык этим элементом. Поскольку в при полной эмуляции
Знаете ли с таким вашим подходом можно даже договорится, до
Что все парадигмы языков программирования архитектурно идентичны поскольку могут быть реализованы с помощью множества 0 и 1 и логических элементов-операторов над этим множеством.

Да и может не стоить путать философию языка программирования с парадигмой программирования.
Почитайте на досуге wiki парадигма программирования.

P.S. Попахивает беспределом на форуме.

> Поскольку в при полной эмуляции

элемент будет неотъемлемой частью языка. Поэтому эмуляция косвенного вызова в одном случае через ручную таблицу, а во втором за счет средств языка является решением проблемы позднего связывания и требует различных затрат со строны программиста.
Но это два архитектурно разных решения. Поскольку организация позднего связывания может в других языках строится не через слоты таблицу,
а за счет run time name resolve.

oxffff © (03.04.09 00:49) [78]

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

Осталась... Ты Фаулера на досуге почитай, про архитектуру приложений. Потому продолжим нашу увлекательную дискуссию.

Реймонда еще можешь почитать, который Эрик.

А у меня, извини, бисерный заводик закрылся.

Будущее Делфи? Найти похожие ветки