VS против Delphi

← →
Cherrex © (2005-10-06 14:59) [0]

Здравствуйте господа. Перед не небольшим коллективом прораммистов ставят большую задачу (2 года). Кадача сводится к написанию клиентского приложения под СУБД SYBASE. И тут в коллективе разгорелись споры: Переходить на .NET или нет.
После того как большинство проголосовало за .NET разгорелся спор на чем писати VS (C#) или Delphi .Net. .NET толком не кто не знает из нас. На предприятии есть и то и то, дополнительно закупать не чо не надо.
ВОПРОС: Что использовать VS (C#) или Delphi .Net. Какие приемущества и не достатки у обеех систем?

← →
Андрей Жук © (2005-10-06 16:58) [1]

← →
Sergey_Masloff (2005-10-06 22:20) [2]

Распускать на хрен коллектив в котором такие вопросы голосованием решаются. Просто правление колхоза какое-то. Не шутка...

← →
Джо © (2005-10-07 03:15) [3]

> большинство проголосовало за .NET разгорелся спор

> .NET толком не кто не знает из нас

Забавно-с...

← →
Cherrex © (2005-10-07 08:32) [4]

> Забавно-с...

Но всем Хочится опробывать

← →
Lamer@fools.ua © (2005-10-07 08:34) [5]

>После того как большинство проголосовало за .NET разгорелся спор на чем писати VS (C#) или Delphi .Net. .NET толком не кто не знает из нас.

Русского, похоже, тоже никто не знает?

← →
Lamer@fools.ua © (2005-10-07 08:36) [6]

По сабджу:
Либо C# дотнет, либо Delphi не-дотнет.

← →
DiamondShark © (2005-10-07 12:51) [7]

Главное преимущество VS.NET в том, что у него нет недостатков.
Главный недостаток Delphi.NET в том, что у него нет преимуществ.

← →
Cherrex © (2005-10-07 13:53) [8]

Чем Delphi.NET так плох в реальности. По моему (хотя я скорее всего ошибаюсь) разница в синтаксисе и в производителе. А еще в книги DELPHI FOR .NET написано что Delphi очени сильно повлияло на создание .NET. И много .NET от Делфи ( что именно не знаю).

← →
DiamondShark © (2005-10-07 16:14) [9]

> Чем Delphi.NET так плох в реальности

Он не плох. Мне нечего сказать против него.

Но мне так же нечего сказать и ЗА него.
А это гораздо хуже.

← →
Антон773 (2005-10-08 09:24) [10]

В восьмой делфи глючит ActiveX(winform)

← →
Priest © (2005-10-10 15:39) [11]

>>Cherrex
Delphi очени сильно повлияло на создание .NET. И много .NET от Делфи ( что именно не знаю).

Тем что C# разрабатывал тот, кто и Дельфи.

А я сейчас пишу под Дельфи 2005 на С#. Нравится мне больше чем VS 2003. По крайней мере нет постояного сообщения о том, что библиотека с компонентом заблокирована.....

← →
ilya39 © (2005-10-10 16:44) [12]

> Тем что C# разрабатывал тот, кто и Дельфи.

Напомните имя-фамилию этого товарища пожалуйста

← →
Джо © (2005-10-10 16:51) [13]

> [12] ilya39 © (10.10.05 16:44)

Андерс Хейльсберг известен как создатель компилятора Borland Turbo Pascal и ведущий конструктор технологии Borland Delphi
За время его работы в Microsoft с 1996 года главной его заслугой считается создание языка Cool, позже переименованного в C#

← →
ilya39 © (2005-10-10 16:57) [14]

> [13] Джо © (10.10.05 16:51)

Спасибо.

← →
Seg (2005-10-12 17:35) [15]

А что, собственно требуется от .NET?
Какие ставятся задачи, которые нельзя решить, не используя .NET?

← →
DrPass © (2005-10-12 22:51) [16]

Самое смешное вот что:
> .NET толком не кто не знает из нас.

Как тогда можно браться за серьезный проект на .NET?

← →
Lamer@fools.ua © (2005-10-13 00:30) [17]

>>Seg (12.10.05 17:35) [15]

Вопрос, обычно во времени, а не возможности как таковой.

← →
Курдль © (2005-10-13 11:04) [18]

> DiamondShark © (07.10.05 12:51) [7]
>
> Главное преимущество VS.NET в том, что у него нет недостатков.
>

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

Забавно, что наш небольшой коллективчик именно так и пишет - большие проекты на VS (С#) в том числе под Sybase ASA.
Сейчас одно из решений содержит более 20 проектов.

← →
Lamer@fools.ua © (2005-10-13 11:06) [19]

>>Курдль © (13.10.05 11:04) [18]

>Сейчас одно из решений содержит более 20 проектов.

Wow!

← →
Курдль © (2005-10-13 11:14) [20]

> Seg (12.10.05 17:35) [15]
> А что, собственно требуется от .NET?
> Какие ставятся задачи, которые нельзя решить, не используя
> .NET?

Все можно сделать хоть на ассемблере, хоть на "машкодах". Но наверняка изменится время исполнения проекта.

Не знаю, на чем еще, кроме как на VS можно быстро написать, например, трехзвенку. Работа с .NET ДэйтаСэтами не идет ни в какое сравнение ни с чем (разве что Power Builder немного похож).
.NET Remoting мне вовсе показался волшебным чудом. Когда любые данные любой структуры можно запросто гонять между любыми узлами, не заботясь особо даже о том, в локалке они, или в инете. Например, заполняешь Дэйтасэт с несколькими таблицами данными и передаешь его, как параметр, методу "находящемуся" на другом конце сетки.

← →
Курдль © (2005-10-13 11:18) [21]

> Lamer@fools.ua © (13.10.05 11:06) [19]
> >Сейчас одно из решений содержит более 20 проектов.
> Wow!

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

← →
Lamer@fools.ua © (2005-10-13 21:47) [22]

>>Курдль © (13.10.05 11:18) [21]

Я смайл забыл поставить. Типа поддеть пытался :o)

>Как ни стремились минимизировать его - не получилось.

Значит одно из двух: либо количество проектов - меньше некуда, либо плохо оптимизировали. Склоняюсь к первому варианту.

>>Курдль © (13.10.05 11:14) [20]

> Когда любые данные любой структуры можно запросто гонять между любыми узлами, не заботясь особо даже о том, в локалке они, или в инете. Например, заполняешь Дэйтасэт с несколькими таблицами данными и передаешь его, как параметр, методу "находящемуся" на другом конце сетки.

Запросто-то запросто. Это мне и самому нравится. Но следует, всё-таки, заботиться о производительности и стараться минимизировать объём передаваемых данных.

← →
Курдль © (2005-10-14 10:18) [23]

> Lamer@fools.ua © (13.10.05 21:47) [22]
> >Как ни стремились минимизировать его - не получилось.
> Значит одно из двух: либо количество проектов - меньше некуда,
> либо плохо оптимизировали. Склоняюсь к первому варианту.

Могу запросто объяснить, откуда ноги растут :)
Автоматизация определенного предприятия. Десяток типов рабочих мест (клиентов) - это уже десяток проектов.
Сервер приложений - еще один. Их взаимодействие - на ремоутинге (wellknown-объекты). Значит общий проект для интерфейсов, общий - для дэйтасетов. Общий - для стандартных типов и констант. Кроме того - базовые классы, разработанные на уровне корпоративных стандартов. Еще проект - Setup. Вот и получается - больше 20. Ради интереса посмотрел - файлов в решении больше 3 000!

← →
Lamer@fools.ua © (2005-10-14 10:40) [24]

>>Курдль © (14.10.05 10:18) [23]

Если Вы решили меня просветить, то зря. Я это, в общем, и так знаю :-)

← →
Курдль © (2005-10-14 10:44) [25]

Да я тут лихорадочно оправдываюсь за невинно убиенное файловое пространство :)

← →
Seg (2005-10-14 17:47) [26]

Десяток типов рабочих мест (клиентов) - это уже десяток проектов.

Раньше это модулями называлось.

← →
Seg (2005-10-14 17:49) [27]

Дэйтасэт с несколькими таблицами данными

Я тут начал изучать C#, но так и не понял, как получить из Датасета строку, на которой стоит курсор в Гриде?

← →
DrPass © (2005-10-17 00:05) [28]

Как-нибудь через BindingContext (не слишком интуитивно, но другого не вижу)
CurrencyManager cm = (CurrencyManager)BindingContext[dataGrid1.DataSource, dataGrid1.DataMember];
DataRowView rw = (DataRowView)cm.Current;
DataRow row = rw.Row;

← →
Курдль © (2005-10-17 12:21) [29]

> Seg (14.10.05 17:49) [27]
> Дэйтасэт с несколькими таблицами данными
> Я тут начал изучать C#, но так и не понял, как получить
> из Датасета строку, на которой стоит курсор в Гриде?

Это самая забавная неразбериха в мозгах при работе с ADO.NET - отсутствие "текущей записи" :)

Кроме способа [28] есть еще и методы самого грида.
Получаешь индекс выбранной строки, а по нему - запись.
(Но надо помнить про грабли для мастер-детальных гридов и деревьев - там все по рекурсии). Если пользоваться только навороченными гридами, как я, то будет нечто типа:

private DataRow GetFocusedRow() { DataRow row = null; DevExpress.XtraGrid.Views.Grid.GridView gv; gv = gcRescActs.KeyboardFocusView as DevExpress.XtraGrid.Views.Grid.GridView; if (gv != null) { row = gv.GetDataRow(gv.FocusedRowHandle); } return row; }

← →
Seg (2005-10-19 11:28) [30]

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

Это и есть .NET технология?

← →
Seg (2005-10-19 11:32) [31]

По коду в [29] я понял, что данные беруться все-таки из грида, а не из ДатаСета?

← →
Курдль © (2005-10-19 14:36) [32]

> Seg (19.10.05 11:28) [30]
> любые данные любой структуры можно запросто гонять между
> любыми узлами, не заботясь особо даже о том, в локалке они,
> или в инете. Например, заполняешь Дэйтасэт с несколькими
> таблицами данными и передаешь его, как параметр, методу
> "находящемуся" на другом конце сетки.
>
> Это и есть .NET технология?
>

Это часть концепции .NET Remoting. Она гласит, что любые классы могут быть сериализованы для пересылки между доменами. При этом многие классы сериализуемы по умолчанию (напр. датасэт). Большинству других для этого достаточно префикса [Serializable]. Кроме того, внутренние классы технологии .NET Remoting доступны для разработчика (можно писать свои сериализаторы, реальные прокси удаленных объектов, канальные приемники и т.п. ). Самое распространенное вмешательство - включение собственных кодировщиков, либо стандартных типа PGP).

> Seg (19.10.05 11:32) [31]
>
> По коду в [29] я понял, что данные беруться все-таки из
> грида, а не из ДатаСета?

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

← →
Seg (2005-10-19 16:20) [33]

I>любые классы могут быть сериализованы для пересылки между доменами.

А это, извините зачем?
Нельзя эти классы просто почтой отправить и включить в проект?

Данные берутся исключительно из датасэта<

Можно пример кода?

← →
Курдль © (2005-10-19 16:34) [34]

> Seg (19.10.05 16:20) [33]
> I>любые классы могут быть сериализованы для пересылки между
> доменами.
> А это, извините зачем?
> Нельзя эти классы просто почтой отправить и включить в проект?

Прикалываемся? :)

Не для компилляции, а для работы распределенной системы!

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

> Можно пример кода?

Ага!
Он в [29]! :)

row = gv.GetDataRow(gv.FocusedRowHandle);

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

Эту row можно юзать по всем законам класса System.Data.DataRow и все изменения в ней реально отразятся на соотв. записи в наборе данных.

← →
Seg (2005-10-19 16:48) [35]

сервер приложения собирает определенный набор данных от SQL-сервера

А откуда сервер приложений знает, какие данные надо выбрать?

← →
Курдль © (2005-10-19 16:56) [36]

> Seg (19.10.05 16:48) [35]
> А откуда сервер приложений знает, какие данные надо выбрать?

Пока программист его не запрограммирует - он и не знает! :)

Приведу пример.
Клиент запросил карточку юридического лица по ID = 0001
Сервер приложений составил запросы к SQL-серверу на заполнение
таблицы основных реквизитов ЮЛ, таблицы банковских счетов, таблицы заказов и таблицы платежей. Потом все это упаковал в ранее разработанный программистами класс - датасэт по имени, напр. dsSubjectCard и отправил его на клиентсое рабочее место.
А последнее, в свою очередь, открыло ранее разработанный программистами класс - форму отображения карточки Юр.лица, где все контролы отображения так или иначе связаны с таблицами такого же точно датасэта dsSubjectCard

← →
Seg (2005-10-19 17:01) [37]

Так это же обычное выполнение запроса.

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

← →
Курдль © (2005-10-19 17:15) [38]

:(

"Клиент" - это клиентская часть трехзвенки (я ж писал это в "параметрах примера" :)

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

Фишка в том, что он "одним потоком" получает упакованные в соотв. с замыслом программиста данные, связанные в соотв. с релэйшнами и проверенные констрэйнтами. Т.е. для программиста достаточно вызвать метод удаланного объекта напр. "scSubjectsServerLogic":
scSubjectsServerLogic.FillSubjectCard(dsSubjectCard1);
В результате этого сервер приложений пробежится по коду этого scSubjectsServerLogic, соберет из БД нужные данные и заполнит ими датасэт.
Данные тут же появятся перед светлыми очами благодарного юзера.

← →
Seg (2005-10-20 11:03) [39]

Оно так и было. Пользователь заходит на сайт, выбирает, что ему нужно, нажимает на кнопку и VB или Java скрипт его обрабатывает и возвращает результат.

Ничего нового здесь нет.

← →
Курдль © (2005-10-20 11:37) [40]

> Seg (20.10.05 11:03) [39]
> Ничего нового здесь нет.

Однозначно! :(
Программист - программирует, а юзер - жмет на кнопки и получает результат. Никто ничего нового и не обещал... кроме изменения сроков выполнения проекта.

← →
Seg (2005-10-20 12:04) [41]

кроме изменения сроков выполнения проекта.

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

← →
Курдль © (2005-10-20 12:09) [42]

> Seg (20.10.05 12:04) [41]
> Я думал, что это качественно новая ступень, к сожалению
> ошибся...

Это и есть качественно новая ступень. Но программировать сама - без программиста она пока не научилась :(

← →
Курдль © (2005-10-24 11:04) [43]

А правду говорят, что в Delphi 2005 нет графического представления датасета?
Т.е. не схема с таблицами, их связями, а просто компонент со списочными свойствами? Я бы повесился :( Ведь в VS датасэт выглядит, как часть ER-модели. И, кстати, может импортироваться прямо из CASE-инструментов.

← →
ИА (2005-10-25 05:52) [44]

Если нужен процесс - с точки зрения программиста переходить надо и писать на VS - перспективнее.
Если нужен результат - с точки зрения начальника давить поганой метлой и писать на Delphi & Win32. Ибо нефиг учиться всем отделом в рабочее время.

← →
Курдль © (2005-10-25 10:36) [45]

> ИА (25.10.05 05:52) [44]
>
> Если нужен процесс - с точки зрения программиста переходить
> надо и писать на VS - перспективнее.
> Если нужен результат - с точки зрения начальника давить
> поганой метлой и писать на Delphi & Win32. Ибо нефиг учиться
> всем отделом в рабочее время.

Нормально с любой точки зрения. Отдел через полгода программирует абсолютно профессионально. Не без ебуков, конечно, но с уважением :)
Ностальгия по делфийской скорости компилляции и безглючности есть, но как представишь работу без .NET датасэтов, объединения проектов в "решение", регионов и мн.др. - тоскливо становится.
Кроме того, все больше и больше средств разработки интегрируются с VS.
Нпример, "PD 10" позволяет создавать иерархию классов и экспортировать ее прямо в код. Некоторые объектно-ориентированные СУБД позволяют "вписать" свои объекты тоже в код напрямую. Достаточно заявить, что этот объект [persistent] и он сразу же будет сопоставлен с БД (т.е. храниться в БД, автоматически заносить все свои изменения, включая структурные).

← →
ИА (2005-10-25 18:27) [46]

"отдел через полгода программирует абсолютно профессионально"

Вот как раз с точки зрения начальника это и есть безобразие.
Пол года платить зарплату как стипендию, потом наблюдая как народ уйдет на другое место с новой строчкой в резюме :)
Я не против взять кого учиться, но не весь отдел. И не на те деньги, которые профессионалу платят. Работать надо.
А настрой "да мы тут быстро разберемся" мне знаком, сам таким был.

Что касается практической стороны, но Delphi это тупик. Никакого смысла,
кроме как использовать старые наработки (или Win 95) в ее использовании нет.
Поскольку проекты старые еще живут, особенно в Европе, то профессионалам-дельфийцам на хлеб с маслом хватать пока будет. Новичкам я бы посоветовал бежать от нее как от чумы. Желающие могут пойти на monster.com и запустить там поиск.
Конкретно по набору фич сравнивать бессмысленно, всегда можно найти на стороне /написать самому - где-то одно удобнее, где-то другое. Главное помнить, что технические характеристики IDE вторичны при выборе средства разработки, а для успешности продажи продукта этой самой разработки
они вообще принципиальной роли не играют.

Иа

← →
Курдль © (2005-10-26 10:13) [47]

> Пол года платить зарплату как стипендию, потом наблюдая
> как народ уйдет на другое место с новой строчкой в резюме
> :)
> Я не против взять кого учиться, но не весь отдел. И не на
> те деньги, которые профессионалу платят. Работать надо.
> А настрой "да мы тут быстро разберемся" мне знаком, сам
> таким был.

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

← →
ИА (2005-10-26 16:50) [48]

Немного не так (про набраны с нуля никто не говорил, но давайте действительно добавим в картинку)

1) Имеем коллектив, опытный в Delphi и пишущий новый проект на ней
2) Имеем коллектив, опытный в Delphi и пишущий новый проект на .NET
3) Набираем коллектив, опытный в .NET и пишущий новый проект на .NET

В первом случае работа начинается сразу, во втором на уровень первого они выйдут через год, при том что все написаное за этот год потом выкинут.
Итого - год обучения за счет фирмы. В третьем нужно два-три месяца на притирку, я в таком процессе (набор с нуля под проект) участвовал трижды.
С точки зрения менеджера которому не пофигу вариант 2 неприемлем.

← →
Игорь Шевченко © (2005-10-26 17:14) [49]

ИА (25.10.05 18:27) [46]

> Что касается практической стороны, но Delphi это тупик.
> Никакого смысла,
> кроме как использовать старые наработки (или Win 95) в ее
> использовании нет.

А Borland об этом знает ? Или по незнанию ерундой продолжает страдать, вкладывая деньги в разработку новых версий ?

ИА (26.10.05 16:50) [48]

> 1) Имеем коллектив, опытный в Delphi и пишущий новый проект
> на ней
> 2) Имеем коллектив, опытный в Delphi и пишущий новый проект
> на .NET
> 3) Набираем коллектив, опытный в .NET и пишущий новый проект
> на .NET

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

Не все так однозначно.

← →
Курдль © (2005-10-26 17:22) [50]

> 2) Имеем коллектив, опытный в Delphi и пишущий новый проект
> на .NET

Для меня это звучит странно, типа "...имеем пианистов, играющих раньше на "Вейнбахе", а теперь репетирующих на "Стэйнвее".

Год для перехода от делфи к VS - это немыслимо! И немыслимо, если вся работа за этот год - на выброс. Не более месяца на переход к полноценному проекту! Чего такого в VS, что не знает специалист по ООП? Чего такого в
ADO.NET, чего не знает специалист по РБД?

Delphi, C++, Java - это проблемы даже не программиста, а всего лишь кодировщика.
Немного сложнее для перехода к ADO.NET или "Power Builder" (LISP и Prolog не берем, как малоиспользуемые).
А в главном - моделировании и оптимизации бизнес-процессов, создании концепции сбора и хранения данных, структурного проектирования и тому подобных наиболее сложных вопросах, специалисты остаются специалистами.
Ну и что, если сотрудник раньше не работал на VS? Зато он, помимо того, что талантливый программист, еще и высококвалифицированный дипломированный специалист по ораклу. Или в совершенстве знает оба вида бухгалтерского учета, или мастер в подготовке к тендерам?
Как и за какое время можно оцнить такие качества специалиста? Мало ли, что у него написано в резюме или в трудовой книжке...

← →
ИА (2005-10-27 04:30) [51]

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

Борланд продолжает вкладывать деньги, так как это им приносит деньги, хотя и копейки.
К перспективам разработчиков, особенно долгосрочным, перспективы Борланда отношения прямого не имеют. Ну вот к примеру Sybase выпустила Power Builder 10, мы же не собираемся обсуждать перспективы человека, начинающего сегодня ему учиться?
Я ведь советовал пойти на монстер, давайте я за вас схожу, ладно.
Итак, имеем, ну, к примеру, Калифорния. Сан-Диего. Говорят, там хорошо :)
Keyword: Delphi. Позиций - 1 (одна), три недели назад. Открываем - на самом деле им нужен сишник. То есть 0.
Keyword: C#, VB.NET. Позиций - 56.
В Европе исторически Delphi более популярно, поэтому не так заметно, разница примерно вдвое насколько я могу прикинуть незная немецкого (monster.de). Вывод - перспектив у человека, начинающего учить Delphi никаких.
Для крепкого профессионала пока работа есть, но новичкам тяжело и будет еще тяжелее. Имеем эффект, когда народ готов душу продать за крутого дельфиста, так как мало их. Но это так же означает, что все меньше новых проектов будут начинать, так как сложнее найти работников.

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

← →
ИА (2005-10-27 04:50) [52]

> Для меня это звучит странно, типа "...имеем пианистов, играющих
> раньше на "Вейнбахе", а теперь репетирующих на "Стэйнвее".
>

Аналогия ошибочна, хотя и эмоциональна.
Про год вы сами писали, кстати. Зачем сами себе возражаете?
В любом случае, между Delphi Win32 и VS.NET разница больше, чем кажется.
Да, сам язык похож, Framework во многом копия VCL, что неудивительно.
Однако, идеология разработки сильно отличается. Да вы же сами упомянули их датасеты и remoting. Многие вещи, которые дельфист со стажем напишет влоб, использую свой опыт, можно и нужно писать по другому, и когда народ набьет руку в новой среде, выяснится что многое из того (все :)) что написано ранее можно и нужно сделать проще, лучше и изящнее. Имеет место эффект кажущейся легкости, за который в свое время доставалось Delphi - бросил кнопку, нажал F9, вот тебе и формочка.
После MS Visual C++ 3.0 Delphi 1 казалась чудом :) Потом приходило понимание. У многих - нет, и чайники заполонили просторы RU.DELPHI с бессмертным вопросов про "иконку где часики".

Подведя итоги - на оригинальный вопрос ответ простой, давайте я его еще раз приведу.

Если нужен процесс - с точки зрения программиста переходить надо и писать на VS - перспективнее.
Если нужен результат - с точки зрения начальника давить поганой метлой и писать на Delphi & Win32.

← →
ИА (2005-10-27 05:11) [53]

> С точки зрения менеджера, которому не пофиг, вполне может
> быть предпочтителен второй вариант, так как кроме умения
> программировать на той или иной платформе, это, безусловно,
> важно, но далеко не достаточно. Если коллектив, упомянутый
> в варианте 2 за время программирования на Delphi, набрался
> опыта в прикладной области, то разумнее будет платить ему
> стипендию в течение времени обучения, нежели растолковывать
> за то же время прикладную область набранному коллективу.
>
>
> Не все так однозначно.

В мире вообще мало что однозначно. Но в данном случае это не важно,
так как мы рассматриваем позицию менеджера. А она проста - есть опытные программисты на Delphi, знающие предметную область.
Значит, будем писать на Delphi. Точка. Если кто-то захочет уйти,
пусть идет, если есть куда. Оставшимся повысить зарплату,
набрать новичков за немного денег, и вперед, выдавать результат на-гора.

← →
Seg (2005-10-27 13:05) [54]

Delphi, C++, Java - это проблемы даже не программиста, а всего лишь кодировщика.

Чем отличается программист от кодировщика?
И вообще - что это за должность "кодировщик"

← →
Seg (2005-10-27 13:13) [55]

вперед, выдавать результат на-гора.

Как ни странно, но результат будет...

← →
Курдль © (2005-10-27 13:31) [56]

> Seg (27.10.05 13:05) [54]
> И вообще - что это за должность "кодировщик"

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

← →
Seg (2005-10-27 13:43) [57]

рук.док.

Что это такое?
Полное название тоже лениво написать?

← →
isasa © (2005-10-27 14:11) [58]

Если нужен процесс ...
Если нужен результат ...

Программирование, ради самого программирования.

Кроме этого(ИМХО), MS так и не смогла, на сегодняшний день, сотворить толковой среды визуальной разработки. Это я в плане конструирования интерфейса и избавления от рутинного высчитывания позиций элементов ...
MS VS C# - лучше, но с VCL Delphi, не сравнить.

Кроме этого, если вспомнить о существовании COM/COM+ то "проблема языка" решается простым распределением ролей учасников проекта.

← →
Курдль © (2005-10-27 14:23) [59]

> MS VS C# - лучше, но с VCL Delphi, не сравнить.

Это почему же? Согласен, что Делфя в этом значительно шустрее, но VS безусловно удобнее! Напр. на Делфе попробуй перенести массив контролов с одной панели на другую! А "нарисовать" ADO.NET датасэт в Делфе вообше нельзя :(

← →
Курдль © (2005-10-27 14:24) [60]

← →
Seg (2005-10-27 14:24) [61]

с VCL Delphi, не сравнить.

Золотые слова.

← →
isasa © (2005-10-27 15:01) [62]

А "нарисовать" ADO.NET датасэт в Делфе вообше нельзя

А зачем его рисовать? :)
Его юзать надо, и желательно не глобально.

← →
Курдль © (2005-10-27 15:15) [63]

А как его юзать, если сначала не нарисовать? Если у тебя в датасэте десяток связанных таблиц, юзать его умозрительно как-то не очень просто...

← →
Игорь Шевченко © (2005-10-28 19:47) [64]

ИА (27.10.05 04:30) [51]

Очень интересный метод - учиться тому, на что есть спрос на рынке. Можно некоторым образом попасть впросак. Например, в блаженной памяти 1999 году очень сильно требовались программисты на Коболе. В 2001, как известно, уже не так сильно требовались.
Обычно неплохо еще поинтересоваться, на какой предмет требуются программисты - разгребать баги в унаследованном коде или заниматься новыми перспективными разработками.

А с момента появления .Net, кстати, так и вовсе без обоой разницы, на каком языке писать - все в код для CLR преобразуется.

← →
Джо © (2005-10-28 20:09) [65]

> [64] Игорь Шевченко © (28.10.05 19:47)
> А с момента появления .Net, кстати, так и вовсе без обоой
> разницы, на каком языке писать - все в код для CLR преобразуется.

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

← →
Игорь Шевченко © (2005-10-29 00:09) [66]

Джо © (28.10.05 20:09) [65]

> В таком смысле и для Win32 (да и для чего угодно) все равно
> на чем писать, все равно все в машинный код преобразуется
>

Это точно. Только связываться не всегда удобно с уже написанным, а иногда хочется :)

← →
Джо © (2005-10-29 00:41) [67]

> [66] Игорь Шевченко © (29.10.05 00:09)
> Это точно. Только связываться не всегда удобно с уже написанным,
> а иногда хочется :)

Да, в этом смысле, конечно, можно пожелать .Net долгих лет и повсеместного распространения. Лишь бы только опять не вышло по схеме "хотели, как лучше, а вышло, как всегда"... Тьху, шоб не накаркать:)

← →
ИА (2005-10-29 04:22) [68]

> Очень интересный метод - учиться тому, на что есть спрос
> на рынке. Можно некоторым образом попасть впросак. Например,
> в блаженной памяти 1999 году очень сильно требовались программисты
> на Коболе. В 2001, как известно, уже не так сильно требовались.
>

Вы путаете. Учиться не тому, на что есть спрос на рынке, а тому,
на что скорее всего _будет_ спрос на рынке. И если на Delphi спроса уже нет, то он вероятно не появится.
Через несколько дней будут результаты Борланда за 3 квартал, за второй убыток был порядка 17 миллионов, Инпрайз :) уже много лет находится в состоянии не жив не мертв, о каких _перспективах_ использования его продуктом может вообще идти речь?

← →
ИА (2005-10-29 04:35) [69]

> А с момента появления .Net, кстати, так и вовсе без обоой
> разницы, на каком языке писать - все в код для CLR преобразуется.
>

Именно! С одной стороны имеем многомиллиардно прибыльную контору, с гиганскими запасами денег, практически неограниченными ресурсами и Андресом Хейлсбергом. Создающую саму операционку и CLR.
С другой стороны, медленно теряющая деньги и людей небольшая фирма,
которая _всегда_ по определению в свете вышесказанного будет в отстающих. Сегодня я могу зайти на msdn и скачать только что выпущенный VS.2005 с .NET 2.0.
Когда будет Delphi его поддерживающая? Какой, скажите, мне интерес
использовать Delphi для .NET? В чем преимущества? В том, что я Delphi знаю?
Что мне привычнее среда и язык? А человеку начинающему учиться, зачем ему Delphi? Чем она лучше для новичка?

Ладно, я повторяюсь уже. Хотите думать, что с Delphi все будет в порядке, ваше дело. Только вот советовать начинающим ее учить не стоит, не надо вам плохой кармы.

Сегодня я могу зайти на msdn и скачать только что выпущенный VS.2005 с .NET 2.0.

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

ИА (29.10.05 04:22) [68]
ИА (29.10.05 04:35) [69]

> Учиться не тому, на что есть спрос на рынке, а тому,
> на что скорее всего _будет_ спрос на рынке.

Ну кто же мог предугадать, что будет ажиотажный спрос на КОБОЛ и программистов на нем ? :)

А учиться, уважаемый, лучше программированию. На чем угодно, хоть на том же КОБОЛе. Заниматься противопоставлением MS и Borland дело безнадежное, "это я тебе, голуба, говорю, как краевед", поскольку обе этих фирмы живут и здравствуют, у обоих есть сильные и слабые стороны, и живут со здравствованием они довольно давно. Говорить, что "учите одно, иначе пропадете" - тон, харатеризующий поверхностный взгляд на индустрию разработки программ.

← →
alex_*** (2005-11-10 11:37) [72]

[70] На крючок все мы сели уже давно :)

> ИА (29.10.05 04:35) [69]

> Сегодня я могу зайти на msdn и скачать только что выпущенный
> VS.2005 с .NET 2.0.

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

>>Карелин Артем © (12.11.05 08:46) [73]

>А если нет у них средств связи, да и виндосы новые сложно найти?
Думаете, это проблема Microsoft"а?

← →
ИА (2006-02-09 18:23) [75]

> > Очень интересный метод - учиться тому, на что есть спрос
>
> > на рынке. Можно некоторым образом попасть впросак. Например,
>
> > в блаженной памяти 1999 году очень сильно требовались
> программисты
> > на Коболе. В 2001, как известно, уже не так сильно требовались.
>
> >
>
>
> Вы путаете. Учиться не тому, на что есть спрос на рынке,
> а тому,
> на что скорее всего _будет_ спрос на рынке. И если на Delphi
> спроса уже нет, то он вероятно не появится.
> Через несколько дней будут результаты Борланда за 3 квартал,
> за второй убыток был порядка 17 миллионов, Инпрайз :) уже
> много лет находится в состоянии не жив не мертв, о каких
> _перспективах_ использования его продуктом может вообще
> идти речь?

Ну вот, не прошло и пол-года.

http://www.borland.com/us/company/news/press_releases/2006/02_08_06_borland_acquires_segue_software.html

“Both markets are important, but Borland can no longer give both the resources and attention they require. Therefore, Borland has chosen to focus wholly on its ALM business, while acting in the best interests of the development community. Our intention is to create a standalone business focused on advancing individual developer productivity.”

Borland has retained Bear, Stearns & Co. Inc. to manage the process of seeking a buyer for Borland’s IDE assets. To learn more about this announcement, please visit www.borland.com.

ИА (09.02.06 18:23) [75]

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

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

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

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

найдите работу со знанием BC++ 5.0 OWL ....

alex_*** © (15.02.06 14:28) [77]

Я не знаю BC 5.0, как не знаю BC4.0, BC3.0 и прочие Zortech C++ или Watcom C.

Я не знаю OWL, PWL, QWL, RWL и тому подобных WL.

Я не знаю расположение кнопок на пульте телевизора конкретной фирмы.

Но на поиски работы это не повлияет.

а что влияет? Наверно знание каких-то конкретных технологий/сред разработки? (если цель найти серьезную работу)

> alex_*** © (15.02.06 18:45) [79]
> а что влияет? Наверно знание каких-то конкретных технологий/сред
> разработки? (если цель найти серьезную работу)

главное уметь как, и только потом - чем... ИМХО

alex_*** © (15.02.06 18:45) [79]

> Наверно знание каких-то конкретных технологий/сред разработки?
>

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

так кто бы спорил что все меняется и что само по себе знание среды ни кому не нужно. А было бы неплохо заточиться под один язык, выучить все тонкости и пахать на нем. На мой взгляд рекрутеры ищут потенциальных работников, набирая в поисковике конкретные фразы типа VC++, Delphi, C#, Oracle... а уж потом разбираются кто насколько чем владеет. Не всеж набирают супермегаубер программистов которые владеют в совершенстве концепциями разработки/проектирования и им все равно на чем писать, хотя у таких людей в списке конкретных навыков, как правило, все равно целые простыни из языков, сред разработки и типов БД.
Да и умение работать в современной среде разработки уже говорит о том что человек в какой-то мере владеет современными концепциями разработки, если голова на плечах есть.

P.s. странно что эта ветка до сих пор не в потрепаловке

alex_*** © (16.02.06 11:20) [82]

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

Не говорит. Медведь, обученный ездить на велосипеде, не более того.

> . странно что эта ветка до сих пор не в потрепаловке

Без проблем

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

← →
pation (2006-02-22 02:30) [86]

Офигеть
Главная фишка .Net в том что писать можно на всём сразу.
Так что не геморойтесь и пишите кто на чём хочет.
Код генериться один и тотже в VB,C# и J# (об этом чётко сказано в MSDN, компилятор оди и тотже , разный только синтасический анализатор) , про Delphi не знаю

← →
pation (2006-02-22 02:30) [87]

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

> Слепить на чем хочешь (быстрее на делфи) универсального
> клиента,

А почему-бы сразу не на java?

← →
noname_ (2006-02-22 11:24) [90]

2 pation [86]

> Главная фишка .Net в том что писать можно на всём сразу.
>
> Код генериться один и тотже в VB,C# и J#

VC++ и Delphi тоже создают один и тот же код, в чем преимущество .net ?

> А почему-бы сразу не на java?

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

> Тормозит ява сильно

По сравнению с чем? С .NET? Это уж вряд ли.

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

Друзья и не такое подскажут... Какая разница, в чем исходник написан - в блокноте или в Eclipse?

> VC++ и Delphi тоже создают один и тот же код, в чем преимущество
> .net ?

В том, что созданные в Delphi.Net классы можно использовать в VB.NET, C# и во всем, что поддерживает CLI (если я не путаю).

← →
noname_ (2006-02-22 13:44) [94]

2 Харько [93]

Использовать классы одного языка в другом возможно если эти языки используют одинаковые парадигмы, чем отличается С# от Delphi.NET кроме синтаксиса?
Как можно применять шаблонные классы с перегруженными методами в языке где нет шаблонов и перегрузки, как вызывать функцию с побочными эффектами в функциональном языке?

Два года назад один мой товарищ на вопрос "Ты на чем нить програмируешь" ответил: "Да, на php". Да какой он програмист, думал тогда я. А сейчас сам предпочитаю его. Даже дипломный проект делаю на нем. Хотя многих вещей на нем, как таковом, сделать невозможно, но это мне не мешает. Вобщем мысль, которую хочу донести такова: не важно на чем ты пишешь, главное, чтобы была возможность выполнить поставленную задачу.

> Использовать классы одного языка в другом возможно если
> эти языки используют одинаковые парадигмы, чем отличается
> С# от Delphi.NET кроме синтаксиса?
> Как можно применять шаблонные классы с перегруженными методами
> в языке где нет шаблонов и перегрузки, как вызывать функцию
> с побочными эффектами в функциональном языке?

C# и Delphi.NET, C++ могут использовать свои нестандартные решения внутри себя, такие решения будут совместимы с .NET. Для того, чтобы другие языки могли использовать классы C# и Delphi.NET, C++ нужно, чтобы созданные классы соответствовали спецификации CLI.

VS против Delphi Найти похожие ветки