Borland продал подразделение CodeGear компании Embarcadero T

[m_guest]

осле седьмой версии, Делфи становился только хуже.

Весьма спорное суждение..
Неудачными были 8 и 2005.
2006 после серии обновлений и , тем более, 2007 вполне себе ничего..
Впрочем, тема не об этом

[Сергей Смирнов]

Давайте не будем пессимистами и подождем реальных шагов.
В Codegear тоже не враги себе.

Мда, остаётся только ждать. Я всё же надеюсь, что реальные шаги будут сделаны не в ущерб дельфи и фрипаскалю/лазарю, но кто знает...

Что Embarcadero себе не враг я не сомневаюсь, но представьте, что свежекупленная Codegear -- это целая команда самых разных специалистов, которым надо платить зарплату. При этом совершенно не понятно, какая выручка будет ТЕПЕРЬ от продаж дельфи и других продуктов. Соответственно, Embarcadero может распорядиться этими сотрудниками исключительно в своих и только своих интересах. И это только часть проблемы. Совершенно не понятно, как новый владелец распорядится доставшимися ему технологиями, какие из них посчитает полезными ДЛЯ СЕБЯ и будет развивать и нести соответствующие затраты, а какие не будет.

Фактически, мы врядли узнаем об этом очень уж скоро. Должен пройти некий период оценки, ревизии и осмысления, во время которого все нынешние продукты Codegear будут продаваться как ни в чём не бывало под дружный аккомпанимент радостных песен маркетологов Embarcadero.

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

[m_guest]

зык паскаль, который несколько устарел морально

Но Вы же наверняка продолжаете использовать этот язык?
Класть плиту на могилу Pascal'я (во всех его реинкарнациях) рановато.
ИМХО, разумеется.

[Сергей Смирнов]

Но Вы же наверняка продолжаете использовать этот язык?
Класть плиту на могилу Pascal'я (во всех его реинкарнациях) рановато.
ИМХО, разумеется.

Я (и другие, возможно, также) использую паскаль в силу целого букета исторических причин и из-за самого удачного, НМВ, подхода к работе с БД в дельфи и лазаре. Это не совсем тот локомотив, который должен мчать паскаль к повсеместному успеху.

[m_guest]

в силу целого букета исторических причин

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

к повсеместному успеху

Вряд ли его стоит ждать. Повсеместного.
---
Сделка по покупке оформится официально вроде как 30 июня. Только после этого срока можно начинать о чем-то говорить.
Лучше пословицы о том, что "поживем-увидим" ничего не придумаешь.

[debi12345]

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

ИМХО - спорный вопрос. Отчасти и то только со стороны C++ - с его "templates" ( хотя FPC уже это умеет ? ) и множественным наследованием ( трюк с "interface" не совсем то, и передачи параметров унаследованным конструкторам вроде нет ). Ну может еще VisualBasic - еще более-менее конкурент.
Для программ типа BLENDER лучше C++ ничего не придумаешь - душа поет, видя это код. Но разве на C++ ( без WITH, без пропертей, без людской обработки исключений, без прозрачной работы со строками и юникодом ) напишешь, например - сложную и надежную БД-программу ?
От .NET народ шарахается как от чумы ( хрень какая-то высосанная из пальца ), на Java писать GUI нереально из-за невероятной тормознутости.
Думаю, как раз из-за отстуствия адекватных конкурентов по части написания business GUI программ на CodeGear и обратили внимание.

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

[bw]

> Кстати, кто знает - почему в FPC не хотят добавить множественное наследование ?
Потому что это зло.
Паскаль отлично сбалансирован. В нем нет ничего лишнего и вот приделывать к нему множественно наследование точно не нужно. Вместо того что бы брать первое что попадется в руки (я про наследование) для реализации некой мысли, лучши подумай еще раз. Паскаль заставляет думать и делать читабельнее, а значит лучше.
Вообще я в такие споры не ввязываюсь, но все же останусь при своем мнении. Я отдаю себе отчет, для каких задач подойдет один из следующих языков: asm, c, pascal или python (зачем нужен c++ пока не понял). В паскале сейчас есть все для полноценной качественной и быстрой работы, все остальное, то что сейчас многие пытаются улизнуть из си++, лишнее.

p.s. Вообще сколько людей столько и мнений. Не тратье время, не ищите доводы в пользу стиля c++ (или отдельных его абстракций), скорее всего я с ними уже знаком :-).

p.p.s. Вообще парадигмы программирования следует выбирать в зависимости от задачи. Я, например, не всегда использую ООП. Стараюсь минимизировать наследования. Использую множественное наследование крайне редко (в Python) и следую определенному стилю, например создаю имена классов с суффиксом Mixin (MyRendererMixin), и эти классы используются только в множественном наследовании.

..bw

[ev]

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

[Сергей Смирнов]

ИМХО - спорный вопрос. Отчасти и то только со стороны C++ - с его "templates" ( хотя FPC уже это умеет ? ) и множественным наследованием ( трюк с "interface" не совсем то, и передачи параметров унаследованным конструкторам вроде нет ). Ну может еще VisualBasic - еще более-менее конкурент.

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

От .NET народ шарахается как от чумы ( хрень какая-то высосанная из пальца ), на Java писать GUI нереально из-за невероятной тормознутости.

Никто особо не шарахается. Довольно много корпоратива пишется на дотнете, особенно веб-приложений -- тут паскаль в полном пролёте, увы и ах. Вообще, у меня складывается впечатление, что системы быстрой и дешевой разработки узко специализированных бизнес-приложений как-то сходят на нет. Кругом SAP-ы да 1С-ы сплошные, которые бьют себя пяткой в грудь с воплями, что могут автоматизировать всё на свете. Какая из этого фигня получается все как-то потом замалчивают. В общем, миром правит маркетинг на грани обмана, а к здравому смыслу давно уже никто не прислушивается. Все говорят лозунгами и выдают расхожие стереотипы за свои мысли. Ладно, что-то я размитинговался

Добавлено спустя 7 минут 23 секунды:

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

Да, примерно так и есть. Учитывая, что современные манагеры от IT могут запудрить мозги кому угодно и впарить любой отстой. Опять же, программирование на таких языках как паскаль или с++ является в какой-то степени искусством и требует от программиста некоторого интеллектуального уровня. Современный же индустриальный подход к созданию крупных систем предполагает в основном просто тупой кодинг "на время". Мне даже иногда кажется, что люди, планирующие и координирующие такие проекты вообще с удовольствием избавились бы от программистов в пользу каких нибудь роботов-кодогенераторов.

[FedeX]

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

поддерживаю!

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

В точку!

Кстати сейчас листаю свежий номер журнала ЧИП, обнаружил на диске к нему дистрибутив "Линукс Юниор". Вот что про него написано:

...Из пяти дистрибутивов, представленных победителями федерального конкурса на разработку и апробацию пакета свободного программного обеспечения для использования в общеобразовательных школах РФ, «Линукс Юниор» - второй по «легкости» требований к компьютеру....
...В список пакетов для «школьного» дистрибутива входят офисные и антивирусные программы, утилиты для работы в Интернете, редактирования графики и мультимедиа, средства программирования Lazarus и KDevelop и т. п., то есть стандартный набор. Из специализированных продуктов – программа для проведения тестов с опцией загрузки образовательных тестов из Интернета...

Хех) Может не так всё и худо

[ev]

Хех) Может не так всё и худо

было бы все худо, уже бы многие сбежли с этого сайта на форум с обсуждением с#
но, как можно видеть по статистике (в разделе о проекте), она только растет

[*vmr]

Долго гуглил по сабжу. Пришел к выводу что все будет в шоколаде

John Kaster, CodeGear Internet Services Architect:

By now, many of you have probably seen the announcement about Embarcadero and CodeGear. I’ve received some messages from people outside CodeGear asking me what I think, so I’ll answer here.
There were many potential outcomes from this "spin-off" effort. I think CodeGear and Embarcadero Technologies fit very well together. Honestly, this outcome is just about the best scenario I could expect. Basically, I didn’t dare to be this optimistic!
The complementary combination of our products and our companies is extensive, exciting, and promising. The two companies have a very large area of interest and expertise overlap, without having conflicting product offerings. The combination of the two product lines will lead to extremely productive development solutions for both sets of customers.
Others have written long posts about this already, so I’m not going to belabor the same points.
I just wanted to provide a public answer to the questions I was getting from people, and reiterate that I think this is a great move and a great day for CodeGear’s customers and its employees.
P.S. As you can imagine, I’m going to be really busy working out the details of integrating our various Internet Services with Embarcadero’s, so I hope you’ll understand if I don’t respond to blog comments immediately.

Nick Hodges: Totally Juiced Up!

.... Done? Great. And now, I have to tell you, I am thrilled with this. Totally thrilled. Seriously. It is hard for me to conceive of a non-fantasy based outcome for us, the products, and our customers that could have been better. Merging into Embarcadero Technologies is going to be awesome. I’m already thinking up new products, combinations and SKUing that is really, really exciting. If you haven’t taken a look at the Embarcadero product line up, please do. There is some seriously cool stuff there. All of the products are database-neutral, just like us. All of them are developer tools.

The cool part is that the Embarcadero product line is completely complementary to Delphi. Delphi’s bread an butter has always been client/server development with rich, powerful Windows interfaces. Database access has always been a key and valuable part of the product, but we never really ventured over the world of database design and management. Where Delphi lets off, tools like Rapid SQL and ER Studio start.

And a word for you guys who don’t care about databases and don’t know a SELECT statement from a hole in the wall. Delphi still is and will continue to be the tool of choice for you. How could it not be? We’ve got some really cool stuff on our roadmap for this year including VCL enhancements, language enhancements like Generics and Anonymous Methods, as well as Unicode development that will continue to make Delphi the best development tool in the world. If database isn’t your thing, we still have you covered like we always have. Not to worry. It’s me, remember?

Okay, enough for now. No doubt this will be a topic for a while, eh?

[debi12345]

Учитывая, что современные манагеры от IT могут запудрить мозги кому угодно и впарить любой отстой.
=========
Ну не знаю. На прошлой неделе нам пытались впарить такой проект.И попали впросак - хотя мы помогали чем-могли на месте, ибо нужно было очень срочно. Однако, наше терпение лопнуло - после 1) установки MSSQL-сервера на саму клиентскую машину ( типа, ради хранимых процедур - в простейшием по бизнес-логике проекте ! понты какие-то ) затем 2) установки .NET-фраймворка ( заняло минут 15 ! ) затем 3) поиска новейшего сервиспака для win2000 (где его сейчас возьмешь ?) затем 4) требования предоставить winxp а значит и апгрэйда до 256М оперативки (где взять такие DIMM сейчас ?), чтобы ее установить.
Обязательный современный P4 ради простейшей программы - издевательство какое-то. Послали их нафиг и за пару дней наваяли сырую версию аналогичного проекта, работающую даже под "свежей" win98.
Думаю, чтот такие попадания впросак с требования аппаратных монстров ради простейших задач ( для котороых обычно планируется некий несвежий "ящик со склада" )- не редкость.
Причину поветрия не просто неэффективных, а даже смешных решений в Ташкенте вижу в "репертуаре" учебных центров ( готовящих "ремеслеников" ), а также веру ( кстати, ничем не подкрепленную ) в магию M$-сертификатов.

Опять же, программирование на таких языках как паскаль или с++ является в какой-то степени искусством и требует от программиста некоторого интеллектуального уровня.
=========
Думаю, что интеллект-уровень с языком мало корреллируется. Даже так - на Дельфях/MSE БД-программы на порядок легче пишутся, чем на том же VB ( я с него начинал GUI-программирование - потому знаю на свой шкуре ). То есть - думать реально меньше, отладка легкая, дизайн компонентов и событий продуман и не требует ухищрений и прочих оригинальностей.
( вспоминаю свое кодирование на VB с использованием класов и наследования - вот это бы маразматический "пилотаж" !)

Насчет вреда множественного наследования - несогласен. Интерфейсы (замена этого наследования) не могут содержать переменные - а это очень неприятное ограничение ( из-за этого иногда приходится "знакомить" предка с наследником - тупейшая возня ! ).

Еще вопрос - мотивация в отказе от реализации FRIEND- классов ? Ведь это заставляет выносить в public-спкцию по-существу приватные методы !

[*vmr]

Насчет вреда множественного наследования - несогласен. Интерфейсы (замена этого наследования) не могут содержать переменные - а это очень неприятное ограничение ( из-за этого иногда приходится "знакомить" предка с наследником - тупейшая возня ! ).

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

Еще вопрос - мотивация в отказе от реализации FRIEND- классов ? Ведь это заставляет выносить в public-спкцию по-существу приватные методы !

И как вы себе это представляете?
1. Если классы находятся в одном юните, то проблемы вообще нет.
2. Скрытые поля(не методы!) можно повыносить через протектед проперти. Рядом с фриендом обьявляется класс наследуемый от требуемого, в котором в паблике вкратце прописываются все нужные проперти (перенос из протектед в паблик)

Че-то мы разоффтопились...

[ev]

предлагаю обсудить нужность и реализацию подобных фич в специальном подфоруме - Компилятор / язык программирования