| Delphi 2007: Что год текущий нам готовит?.. |
Из неофициальных источников появилась некоторая интересная информация по поводу развития Delphi в 2007 году.
Компания-разработчик нашего любимого RAD-средства, проанализировав пожелания Delphi-сообщества, изменила свои первоначальные планы на текущий год.
Основные моменты:
1) В марте 2007 года выйдет Delphi 2007 (win32)
Плохая новость: в мартовской версии Delphi 2007 не будет юникода;
Хорошая новость: юникод будет в середине лета!
И это не единственная хорошая новость! В мартовской версии Delphi 2007 обещают много интересных "вкусностей", в том числе DBX4 и полную поддержку VISTA.
2) В марте 2007 года должен появиться новый и очень интересный продукт — Delphi for PHP — полноценное RAD-средство для разработки на PHP.
3) Выход новых версий продуктов линейки Turbo предполагается в конце 2007 года.
4) И еще небольшой сюрприз: стоимость Turbo Delphi Pro снизилась до 250$.
Вот так, коротенько...
 Елена Филиппова
Всего в теме 1215 сообщений
Добавить свое сообщение
Отслеживать это обсуждение 
| № 715 20-02-2008 06:14 |   |
Ответ на »сообщение 713« (Мухтар )
___________________________
Ответ на »сообщение 711« (ua.Skywalker)
___________________________
А какая проблема сваять оболочку?
Насколько понимаю, основная проблема в Кайликсе была связана с глючностью самой оболочки. Она работала как-то через Wine, очень криво.
Кроме того, не нужно подходить к вопросу типа "ваяния оболочек" таки образом. Они тратят колоссальные ресурсы на её поддержку. Где-то уже звучали призывы интегрировться в Visual Studio, чтобы об IDE думать было не надо и сфокусироваться полностью на компиляторе и библиотеках. Разумно это или нет - я не знаю. Но очевидно, что у CG не хватает ресурсов.
| № 714 20-02-2008 05:58 | |
Ответ на »сообщение 706« (Aleg Azarousky)
___________________________
КодГир более не рассматривается в Microsoft как соперник. И эта акция направлена в первую очередь против open-source средств разработки.
У микрософта уже несколько лет нет средств разработки приложений под Вин32 (не учитывая древний голимый МФЦ). То есть прямой конкуренции нет.
Тем не менее CodeGear имеет все шансы выстоять в этой ситуации, двигаясь в сторону кросс-платформных разработок. Microsoft никогда на это не пойдет, они будут поддерживать только Windows. Поэтому кроссплатформность даст Delphi явное конкурентное преимущество.
Именно так
| № 713 20-02-2008 05:35 | |
Ответ на »сообщение 711« (ua.Skywalker)
___________________________
А какая проблема сваять оболочку?
| № 712 20-02-2008 05:16 | |
Ответ на »сообщение 711« (ua.Skywalker)
___________________________
Им не надо делать собственно "оболочку", которая я бы запускалась в Линукс.
Почему это не надо? Вот у меня, например, основной домашний компьютер под Linux. И меня очень огорчает, что я не могу пользоваться Turbo Delphi (и при этом вполне могу пользоваться Eclipse или Lazarus).
| № 711 20-02-2008 03:52 | |
Им не надо делать собственно "оболочку", которая я бы запускалась в Линукс. Достаточно одного компилятора + кросплатформенную библиотеку + remote dbg, как уже указывалось. Подсмотрели бы во FreePascal'е что-ли...
Только сомнительно, что у CG хватит сил и средств сделать всё это в приемлемые сроки...
| № 710 20-02-2008 03:50 | |
Ответ на »сообщение 709« (panda)
___________________________
Если быть точнее - шанс CodeGear в отношении Delphi и VCL - это путь Trolltech с QT. Главное здесь, добавляя кроссплатформные возможности, не опустить планку качества в Windows-направлении. Тогда Delphi не будет равных среди средств разработки для нативных кросс-платформных приложений.
| № 709 20-02-2008 03:39 | |
Ответ на »сообщение 708« (Aleg Azarousky)
___________________________
Т.е., говоря по-простому, шанс CodeGear заключается в том, чтобы сделать "улучшенный" Lazarus (стабильный, удобный, мощный, ...)?
| № 708 20-02-2008 03:34 | |
Ответ на »сообщение 707« (panda)
___________________________
Я имею ввиду VCL for Linux, кросс-компилятор для Linux из Windows, и удаленный отладчик (remote debugger) для отладки программ под Linux из Windows IDE.
Kylix не нужен (по крайней мере пока). И CLX - это не VCL for Linux. Библиотека компонент должна быть общей для всех программ, как под Винду так и под Линукс. А Борланд сделал был кросс-платформную CLX (которую толком так и не доработали), в то время как большинство разработчиков продолжало работать с VCL.
Я полагаю, что такая кросс-платформная VCL может представлять из себя 2-уровневую библиотеку:
- на нижнем уровне - работа с API Windows и Linux, для каждой платформы - свой набор процедур и функций, хранящихся в отдельных каталогах на диске. Общее - только интерфейсные части модулей.
- на верхнем уровне - платформо-независимая библиотека классов и визуальных компонентов, общающаяся с внешним миром только посредством нижнего уровня.
Библиотека должна быть спроектирована так, чтобы в последствии можно было бы добавлять поддержку и других платформ в нижний уровень: OSX и т.п.
| № 707 20-02-2008 03:14 | |
Ответ на »сообщение 706« (Aleg Azarousky)
___________________________
Тем не менее CodeGear имеет все шансы выстоять в этой ситуации, двигаясь в сторону кросс-платформных разработок.
Вы имеете в виду поделие типа Kylix или решения на базе Eclipse (типа 3rd Rail)?
| № 706 20-02-2008 02:53 | |
Ответ на »сообщение 701« (Jack Of Shadows)
___________________________
Конечно, вы правы.
КодГир более не рассматривается в Microsoft как соперник. И эта акция направлена в первую очередь против open-source средств разработки.
Тем не менее CodeGear имеет все шансы выстоять в этой ситуации, двигаясь в сторону кросс-платформных разработок. Microsoft никогда на это не пойдет, они будут поддерживать только Windows. Поэтому кроссплатформность даст Delphi явное конкурентное преимущество.
Добавить свое сообщение
Отслеживать это обсуждение
| Дополнительная навигация: |
| 
