чисто циферки. Некоторая статистика по freshmeat [собираеццо не регулярно].

pascal на fm'е действительно не очень живой.

Это сообщение отредактировал(а) Mayk - 20.12.2007, 13:17

Delphi умирает уже не первую пятилетку господа. Смотрите правде в глаза. Он всегда отставал от VS. Но признаков смерти никода не было. Более того этот самый Delphi (сейчас это Developer Studio) вытащил Борланд из долговой ямы. То есть его покупают. Вот уже 2007й вышел. Правда не в полной редакции но всё же. Не думаю что делфи когда нибудь умрёт. Это глупость. Каждый день появляються новые тихнологии с новыми языками и находяться люди которые их осваивают и дают им жизнь. Делфи же уже старичёк, у него хватает фанатов. Всё зависит от мастерства!

Ну-ну! Это совершенно разные вещи. Дженерик (в дотнет) - это особое понятие на уровне рантайма (ВМ), что кстати не отменяет шаблонов и прочих механизмов встроенной кодогенерации (всяких там макросов...) со стороны конкретного языка. Физический класс инстанцируется при первом использовании дженерика. Для reference-типов - один (ну там мож где тип тупо храниться - дотнетчики поправят   ), для value-типов - по классу для каждого (всмысле заюзали дженерик с value-типом - сгенерился класс). Причём тут интерфейсы?

Дженерики из гуд - для языков, имеющих возможность создания типа на лету (читай - имеющих ВМ/интерпретируемых/etc.).

Что касается питона - вот тоже давно нравился и нравится, но вот юзать - совсем не юзаю (за исключением waf-а  ). Почему? А фиг его почему... Прикладной уровень питона не знаю совсем   

Это сообщение отредактировал(а) Любитель - 31.3.2008, 03:39

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

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

Добавлено через 3 минуты и 16 секунд

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

duck typing рулит   , никаких дженериков и шаблонов не нужно 

Ну да - всегда можно обойтись боксингом/анбоксингом + интерфейсами + кастингами. Страдает производительность.


Протесть дженерик-коллекцию интов и обычную. Увидишь разницу.


А тут вроде наоброт - гораздо хуже. Дженерики - лишь мелкое удобство.

А где разница то?
1. В синтаксисе
2. В подсказках IDE(будет показывать, что аргумент ф-ции не object, а int).
3. В просто смешной защите от дурака(нельзя будет передать ничего, кроме int). Но здесь, если отвлечься от конкретно коллекций и перейти к чему-нибудь, что будет пользоваться не только operator=, к примеру, выставлять в требованиях некоторый интерфейс дабы с обобщёнными объектами можно было бы как-то взаимодействовать, то переписав код на интерфейсы ты получишь ту же самую "защиту от дурака", которая будет выражаться в ругани компилятора при попытке использовать объект, который не поддерживает требуемый интерфейс.

Вывод: это лишь синтаксический сахар. Вполне возможно, что in a nutshell это нечто большее, но предоставляемый ф-ционал - лишь сахар, пудра, пыль.

Примеру ради: как не используя рефлексии реализовать аналог следующего плюсового предиката?

Сразу приведу пример шарповых классов:

Этим кодом я хочу подчеркнуть, что оба типа(KeyValuePair1 и 2) НЕ имеют общего интерфейса предоставляющего доступ к value(и не могут иметь, если конечно value не превратить в банальный object - от чего убегали к тому и придём).

Это сообщение отредактировал(а) archimed7592 - 1.4.2008, 21:08

archimed7592, можно конечно и так:


В этом случае есть общий интерфейс. Код громоздкий, сам знаю   

З.Ы. в дженериках вывод типа хромает, но мелкомягкие вроде собираются что-то с этим делать (Рихтер упоминал про это).

З.Ы(2) в холиварах на винграде - как на военных заводах времён перестройки: что ни попробуют собирать, но вместо кастрюль и сковородок выходит автомат Калашникова. Так и здесь - какой язык ни начни сравнивать с другим, хоть OCaml с Haskel - всё равно в итоге перемываем кости .NET/C#... Про паскаль и С++ забыли уже.      

Ну дык я то просил без общего интерфейса . Могу уточнить: классы KeyValuePair1/2 ты никак модифицировать нельзя(пусть они библиотечные, к примеру)...


  

Ещё раз - дженерики это не механизм кодогенерации! Это возможность рантайма.

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

Добавлено через 1 минуту и 48 секунд

Йа хде?   

  

Собственно выпустив C# и Java несостоятельность Си++ уже признали. Остается только подождать, пока в Паскале не уберут запрет на операции над указателями без приведения к целому, после этого Си++ можно выносить.  Если еще и шаблоны ввести, то точно у Си++ никаких плюсов уже не будет. Конечно MS будет сопротивляться, но это ей не поможет. 

  Операции над указателями типа PChar разрешены, так легче переносить код из C++. 


  Delphi активно обменивается фичами с C#, а не С++, потому шаблонов ждать не стоит. 

с каких это пор, у них совершенно разные области применения   учи матчасть  


Паскаль? А, это-то, что пылится на одной полке с Cobol-ом?    Жуть, на нем кто-то еще пишет?  
Так что, там еще и указатели нужно к целому приводить    , так вот почему Borland никак не выпустит Delphi под 64х битную архитектуру, просто у дельфистов сразу все программы поломаются  


Вот именно "как", компилятор С++ на порядок(и вряд-ли на один  ) сложнее паскалевского, "как" не получится, получится жалкая пародия  


а они тут причем?  вообще язык С++ - свободный, он никому не принадлежит, есть его стандарт
язык паскаль - практически умер  , есть много несовместимых между собой реализаций (free pascal, delphi мож чего еще), даже набора стандартных библиотек нет  

но паскалистам этого не объяснишь, так как:

даже когда это что-то лучшее осталось в прошлом  

Я конечно понимаю, что очень хочется верить, что последний вменяемый язык на земле исчезнет, но он по-прежнему продолжает развиваться, а вот C#-Builder благополучно накрылся ибо нефиг, раз Delphi .NET есть.



Наличие или отсутствие стандартов, на Паскаль они вроде тоже были, глубоко и искренне пофигу, тем более, что язык для RAD избыточен для программирования контроллеров. Что включать в стандарт будем? Соответствуют-ли стандарту все плюсовые компиляторы еще вопрос.
Сделает кто-то Ada Studio сравнимую с Delphi и VS будут Аду массово использовать, нет значит не будут. Решают не столько качества языка сколько его поддержка крупной фирмой. Еще Fortran каким бы отстойным он по сравнению с европейским Алгол-60 ни был, в Америке цвел и пах, только из-за стараний IBM. Модула-2 может и лучше Паскаля, но где она сейчас? Только потому, что Borland не выпустила ее на рынок.
Совершенно стихийным было развитие Бейсика и современный VB это уже совсем др. язык. Куда более стихийным, чем у Паскаля, который ориентировался на Borland.



Даже если компилятор Паскаля будет работать в 10 раз медленнее, я бы не советовал гнуть пальцы по поводу короткого синтаксиса Си, т. к. первая же компиляция программки в 5000 строк просто сожрет все время, сэкономленное на наборе за все время создания программы. Так что каким местом сложность стала преимуществом мне непонятно.



Как и у сишников т. к. смещения по памяти типа адрес+4 могут стать некорректными. Причем скорее именно у сишников. Пасквилянт еще подумает перед тем, как извращаться. 

[quote]Жуть, на нем кто-то еще пишет?[quote]

Ну если вы не в курсе, то что я могу поделать. У меня вот знакомых пишущих на Си меньше, чем на Delphi.



Ну просто такую мелочь как класс стека (мне хватает для этого массива и Top:Integer) или отсутствовавший в VCL до Delphi 10 пустяковый компонентик иконки в трее при желании можно махом написать самому или всегда найти.  Проблема блин. Очередь или сортировку сделать. Если сишники этого не могут без STL, то кто тогда Windows написал. Не делайте мне смешно.  
Не поймите меня превратно. Я ничего не имею против STL и даже за нее, меня всегда удивляло почему подобная мелочевка не идет в VCL (или по крайней мере я про нее не знаю). Но подобную мелочь всегда можно найти.