Здравствуйте, iHateLogins, Вы писали:
HL>Я вот что скажу по поводу .NET-а. Сейчас, в 2010, уже стало понятно, что это тупик. WPF не взлетел, Silverlight не взлетел, Entity Framework не взлетел. ASP.NET давят со всех сторон динамические языки. Ну а что остается от дотнета?
Здравствуйте, Antikrot, Вы писали:
MM>>АСУ Станции примерно половины железных дорог России. A>так вот почему они мне летом не могли найти станцию на собственной железной дороге! (повбывав бы)
Я думаю мы говорим о разном ПО. АСУ станции — это не то, что крутится на сайте РЖД. Это то, с помощью чего люди на местах контролируют движение.
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, enji, Вы писали:
E>>Вы не поверите Но это так — есть чел, который сидит на объекте в 300 км от города с ноутом, на котором стоит win98 и gsm модемом. Как обычно сроки горят, все надо запустить еще вчера. И чего ему сказать — чтобы поменять параметры оборудования вам нужно скачать 30 метров с сайта микрософт или sun?
E>>И такие случаи не редкость... MM>Так если не редкость, может пора уже научить этих людей, как скачать несчастные 30 метров до командировки? Или Винду обновить. Это тоже не редкость
Далеки вы от народа
Как вы предлагаете их обучать? Это же не наш человек там сидит, а "сервисный инженер" клиента... А они встречаются очень разные — как прошаренные, так и нет. Ноуты у многих рабочие и старые, фреймворка там нет. Ставить фреймворк до выезда на объект? Надо знать, что он нужен — т.е. прочитать руководство. А их никто не читает Да и не всегда вообще наперед известно, что такая программа понадобится.
В общем, необходимость что-то ставить дополнительно в данном случае — ОЧЕНЬ большой минус.
Здравствуйте, iHateLogins, Вы писали:
HL>Здравствуйте, пыщьх, Вы писали:
TSP>>>>Да хз. Есть в нем что то такое. Мне в свое время на нем нравилось писать. И к тому же это действительно ощущается как RAD. Шлеп кнопку, менюшку и какой нибудь TSuperComponent. Мгновенная сборка за пару секунд и готово. MM>>>Про "шлеп кнопку" я не очень согласен, т.к. именно на Delphi учил многое из WinAPI по части GUI, но вот очень поддерживаю касательно нравилось писать и мгновенная сборка. Очень жаль, что Borland не смогла тащить это проект. Эх. До сих пор вспоминаю Delphi только добрым словом П>>Во времена Win3.11 — NT4 — 98 вещь была незаменимая. Но сейчас, ИМХО, все плюсы Delphi есть в C#. А в дополнение к ним — edit'n'continue, мощный отладчег и прочие плюшки. Что не мудрено, т.к. проектировал это главный борландовскйи архитект, перекупленный M$.
HL>Так да не так. Микрософт сама запуталась в дотнете. Они в начале 2000-х думали одно, а вышло совсем другое. Пример: многие абстракции и библиотеки не успевают дожить даже до N+2-й версии. Например, Windows.Forms стала почти deprecated уже в .NET 3.0, с появлением WPF. То же самое и про первую реализацию веб-сервисов. И система компонент (System.ComponentModel) тоже как-то не взлетела. Проблема микрософта в том, что у них не получается сделать long-running API в .NET. В WinAPI — без вопросов, а в .NET-е, при всей его объектно-ориентированности, как-то не получается. В итоге они просто бросают код и начинают заново. Так появился ASP.NET MVC, EF, ну много еще примеров.
Я вижу ровно обратную ситуацию. SL, EF, ASP.NET MVC набирают популярность вытесняя конкурентов на других платформах. WPF и WinForms существуют параллельно, для разных задач предназначаются.
Здравствуйте, MxMsk, Вы писали:
MM> H>Честно говоря, никогда не ощущал потребности в мульти-делегатах
MM> Допустим хочу подписаться на событие Application.OnException. Могу ли я гарантировать, что мое присваивание не затрет чужой, ранее подписанный обработчик? По хорошему, придется запоминать значение в приватном поле и звать его из своего обработчика. Жить можно, но не шибко удобно.
Я же не отрицаю, что мульти-делегаты могут быть удобны. Просто, настолько ли часто они требуются, чтоб их отсутствие считать проблемой
Здравствуйте, winston, Вы писали:
w> S>Много уже написанного крупного софта?
w> Всегда считал, что Дельфи это для студентов и школьников, и ничего серьезного на нем не пишется, а оказывается "Много уже написанного крупного софта", можно примеры этого крупного софта?
Здравствуйте, enji, Вы писали:
E>Вы не поверите Но это так — есть чел, который сидит на объекте в 300 км от города с ноутом, на котором стоит win98 и gsm модемом. Как обычно сроки горят, все надо запустить еще вчера. И чего ему сказать — чтобы поменять параметры оборудования вам нужно скачать 30 метров с сайта микрософт или sun?
E>И такие случаи не редкость...
Бедный чувак. Но я, если честно, не понмаю, почему его нежелание брать с собой 30 метров фреймворка на флешке (и дистр нормальной операционки) должно усложнять вашу работу как программиста. Я бы сказал: хотите качественный софт — используйте качественные тулзы. Не знаете? Спросите меня как
Delphi — это старый добрый Pascal со всеми вытекающими последствиями:
— низкая производительность (хуже .Net 4.0 минимум в 3 раза);
— неудобная среда разработки (нет элементарного resharper);
— отсутствие средств для написания и использования snippet'ов (на момент 2004 года, сейчас может что и поменялось).
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, winston, Вы писали:
w>> S>Много уже написанного крупного софта?
w>> Всегда считал, что Дельфи это для студентов и школьников, и ничего серьезного на нем не пишется, а оказывается "Много уже написанного крупного софта", можно примеры этого крупного софта?
H>Проследуй
ого скока програмулек, практически ни одной не знаю, но вот Altium Designer и FL Studio действительно крупный софт, пользовался, добро
Здравствуйте, MxMsk, Вы писали:
MM>Здравствуйте, hattab, Вы писали:
MM>>> Не было там такого. Совсем не было. Делегаты круче того, что было (или есть). H>>Как это нет? Процедурные типы Или ты считаешь, что делегатами может называться только шарповая реализация? MM>Под делегатами я подразумеваю типы, умеющие "суммировать обработчики". В Delphi насколько я помню, был не больше чем указатель на метод. Если двое подписываются на одно и то же событие — вызовется только один. Или нет?
Извини, но суммирование — далеко не то, что главное в делегате. На любом языке класс, суммирующий обработчики(при их наличии в нем) пишется за пару минут. А вот возможность иметь ссылку на метод — это фича языка.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, hattab, Вы писали:
H>Здравствуйте, MxMsk, Вы писали:
MM>> В этом и заключается их главная проблема. События в Delphi — классная идея, но с какой-то недоделанной реализацией. Не буду утверждать, что делегаты в C# самые правильные — они тоже не идеальны, но именно как встроенный в компилятор механизм множественной подписки (в том числе с учетом многопоточности), они лучше Делфийских.
H>Честно говоря, никогда не ощущал потребности в мульти-делегатах
Иногда нужно. Но реализация мультиделегата довольно проста, если подумать.
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, iHateLogins, Вы писали:
HL>Так да не так. Микрософт сама запуталась в дотнете. Они в начале 2000-х думали одно, а вышло совсем другое. Пример: многие абстракции и библиотеки не успевают дожить даже до N+2-й версии. Например, Windows.Forms стала почти deprecated уже в .NET 3.0, с появлением WPF.
Не-а, у MS такая политика — каждую пару лет выкатывать новую технологию и создавать вокруг нее рынок. Не было бы этой политики, был бы MS там, где сейчас Borland. HL>То же самое и про первую реализацию веб-сервисов. И система компонент (System.ComponentModel) тоже как-то не взлетела. Проблема микрософта в том, что у них не получается сделать long-running API в .NET. В WinAPI — без вопросов, а в .NET-е, при всей его объектно-ориентированности, как-то не получается. В итоге они просто бросают код и начинают заново. Так появился ASP.NET MVC, EF, ну много еще примеров.
Про веб сервисы не в теме.
HL>А вот в Дельфи таких проблем почти не было. Код, написанный давно, можно заставить работать и сейчас и не нужно ничего переписывать.
Да, но удобство разработки новых приложений сильно уступало C#.
HL>Я вот что скажу по поводу .NET-а. Сейчас, в 2010, уже стало понятно, что это тупик.
Альтернативы для пердосвистелоксвистоперделок а-ля "база пациентов с диагнозами, управление каким-нибудь меддевайсом и рисование красивых графиков пульса, чтобы у ПОЦиента возникало ощущение мегакрутости клиники и оборудования и больше желания 'платить исчо'"? QT? Оно не managed, там на ручную работу с памятью и прочие мелочи будет 20% времени уходить. WTL? Еще хуже для таких задач. Java? Чем оно лучше C# для десктопа? C? Только если заказчик впал в кому лет на 20. HL>WPF не взлетел, Silverlight не взлетел, Entity Framework не взлетел. ASP.NET давят со всех сторон динамические языки. Ну а что остается от дотнета? Автоматическое управление памятью и реализация парсинга дат? Слабовато как-то.
WinForms designer чего только стоит. Автоматическое управление памятью как физическая невозможность вещей а-ля "AccessViolation in FuckYou.VCL at address 0xDEADBEEF. Please restart everything you can while you can". HL>Даже вот бизнес-приложения Микрософт так и не перевела на .NET. Был такой Project Green, типа объединение, фактически переписывание всей линейки Dynamics. Был да сплыл. Не осилили. А вот Оракл — осилила, выпустив месяц назад Oracle Fusion Applications.
Узкая ниша.
Здравствуйте, wety, Вы писали:
W>Здравствуйте, gandjustas, Вы писали:
W>Delphi — это старый добрый Pascal со всеми вытекающими последствиями: W>- низкая производительность (хуже .Net 4.0 минимум в 3 раза); W>- неудобная среда разработки (нет элементарного resharper); W>- отсутствие средств для написания и использования snippet'ов (на момент 2004 года, сейчас может что и поменялось).
W>Так? Так!
А если учесть что более 50% delphi даже сейчас это Delphi 7, то становится очень даже смешно.
Здравствуйте, Antikrot, Вы писали:
A>Здравствуйте, MxMsk, Вы писали:
Y>>>Я вот такой софт для ЖД знаю http://kaprem.com/ Y>>>А Вы какой? MM>>АСУ Станции примерно половины железных дорог России. A>так вот почему они мне летом не могли найти станцию на собственной железной дороге! (повбывав бы)
АСУ станции и система продажи билетов(я так понимаю, через нее станцию искали?) — это очень разные вещи. Последняя(Экспресс 3) крутится на юниховых IBM мэйнфреймах(приходилось с ней работать), так что Делфей там точно нет. А проблема с поиском — это скорее или некомпетентность кассира(интерфейс системы ни разу не интуитивный, и неопытный кассир мог тупить легко), или того, кто вводил описание станции, так что спокойнее, без паники .
Новости очень смешные. Зря вы не смотрите. Как будто за наркоманами подсматриваешь. Только тетка с погодой в завязке.
There is no such thing as a winnable war.
Здравствуйте, wety, Вы писали:
W>Здравствуйте, gandjustas, Вы писали:
W>Delphi — это старый добрый Pascal со всеми вытекающими последствиями: W>- низкая производительность (хуже .Net 4.0 минимум в 3 раза);
Тесты в студию
W>- неудобная среда разработки (нет элементарного resharper);
Вы 2010/XE(2011) видели? Ничем не уступает MS VS 2008
W>- отсутствие средств для написания и использования snippet'ов (на момент 2004 года, сейчас может что и поменялось).
Автокомплита вполне достаточно.
Все остальное долно быть вынесено в функции. Если очень критично по производительности, то функция должна быть inline
W>Так? Так!
Не так!
Здравствуйте, пыщьх, Вы писали:
П>Здравствуйте, iHateLogins, Вы писали:
HL>>Так да не так. Микрософт сама запуталась в дотнете. Они в начале 2000-х думали одно, а вышло совсем другое. Пример: многие абстракции и библиотеки не успевают дожить даже до N+2-й версии. Например, Windows.Forms стала почти deprecated уже в .NET 3.0, с появлением WPF. П>Не-а, у MS такая политика — каждую пару лет выкатывать новую технологию и создавать вокруг нее рынок. Не было бы этой политики, был бы MS там, где сейчас Borland. HL>>То же самое и про первую реализацию веб-сервисов. И система компонент (System.ComponentModel) тоже как-то не взлетела. Проблема микрософта в том, что у них не получается сделать long-running API в .NET. В WinAPI — без вопросов, а в .NET-е, при всей его объектно-ориентированности, как-то не получается. В итоге они просто бросают код и начинают заново. Так появился ASP.NET MVC, EF, ну много еще примеров. П>Про веб сервисы не в теме.
HL>>А вот в Дельфи таких проблем почти не было. Код, написанный давно, можно заставить работать и сейчас и не нужно ничего переписывать. П>Да, но удобство разработки новых приложений сильно уступало C#.
HL>>Я вот что скажу по поводу .NET-а. Сейчас, в 2010, уже стало понятно, что это тупик. П>Альтернативы для пердосвистелоксвистоперделок а-ля "база пациентов с диагнозами, управление каким-нибудь меддевайсом и рисование красивых графиков пульса, чтобы у ПОЦиента возникало ощущение мегакрутости клиники и оборудования и больше желания 'платить исчо'"? QT? Оно не managed, там на ручную работу с памятью и прочие мелочи будет 20% времени уходить. WTL? Еще хуже для таких задач. Java? Чем оно лучше C# для десктопа? C? Только если заказчик впал в кому лет на 20.
В Delpi можно писать не используя ручного управления памятью! Чем он и хорош: где нет работы с железом и не критична производительность можно и не знать что такое pointer.
А при желании можно писать в C++ стиле с указателами, PChar вместо string и т.д.
HL>>WPF не взлетел, Silverlight не взлетел, Entity Framework не взлетел. ASP.NET давят со всех сторон динамические языки. Ну а что остается от дотнета? Автоматическое управление памятью и реализация парсинга дат? Слабовато как-то. П>WinForms designer чего только стоит. Автоматическое управление памятью как физическая невозможность вещей а-ля "AccessViolation in FuckYou.VCL at address 0xDEADBEEF. Please restart everything you can while you can".
NullPointer exception ничем не хуже HL>>Даже вот бизнес-приложения Микрософт так и не перевела на .NET. Был такой Project Green, типа объединение, фактически переписывание всей линейки Dynamics. Был да сплыл. Не осилили. А вот Оракл — осилила, выпустив месяц назад Oracle Fusion Applications. П>Узкая ниша.
Здравствуйте, BlackEric, Вы писали:
W>>Delphi — это старый добрый Pascal со всеми вытекающими последствиями: W>>- низкая производительность (хуже .Net 4.0 минимум в 3 раза); BE>Тесты в студию
Хм. Для начала надо придумать как и что тестировать. Есть идеи?
Хотя бы примерный тест на C# подскажите, а я его тогда и реализую окончательно и на C# и на Delphi.
А ещё надо будет скачать эту 2010/XE(2011) (если только такая есть на торрентах).
W>>- неудобная среда разработки (нет элементарного resharper); BE>Вы 2010/XE(2011) видели? Ничем не уступает MS VS 2008
Нет, не видел. Как-то уже не слежу за этим Delphi.
W>>- отсутствие средств для написания и использования snippet'ов (на момент 2004 года, сейчас может что и поменялось). BE>Автокомплита вполне достаточно. BE>Все остальное долно быть вынесено в функции. Если очень критично по производительности, то функция должна быть inline
W>>Так? Так! BE>Не так!
Как же так???
Поможешь написать тест для прогонки на C# и Delphi? Просто нужна идея, а не код.
Здравствуйте, Eugeny__, Вы писали:
E__>Извини, но суммирование — далеко не то, что главное в делегате.
Извиню без проблем. Оказалось, что делегат — это именно указатель на метод, не обязательно со список подписчиков. Так что в такой терминологии делегаты в Delphi есть.
E__>На любом языке класс, суммирующий обработчики(при их наличии в нем) пишется за пару минут. А вот возможность иметь ссылку на метод — это фича языка.
А вот здесь поспорю. "Пишется за пару минут" и встроена в язык, в том числе с почти lock free подпиской — это все-таки разные вещи.
Здравствуйте, Eugeny__, Вы писали:
H>>Честно говоря, никогда не ощущал потребности в мульти-делегатах E__>Иногда нужно. Но реализация мультиделегата довольно проста, если подумать.
Хех.
Но это так — есть чел, который сидит на объекте в 300 км от города с ноутом, на котором стоит win98 и gsm модемом. Как обычно сроки горят, все надо запустить еще вчера. И чего ему сказать — чтобы поменять параметры оборудования вам нужно скачать 30 метров с сайта микрософт или sun? 
