» Вопросы по Embarcadero RAD Studio XE5-XE8,10.x(Seattle, Berl

kaz_av


Цитата:

Если такая архитектура приведет к удобной работе с плагинами, почему бы нет.

Ты сейчас говоришь о нативных плагинах для браузера? Если так, мне не понятно нафига этот винегрет (JS+нативные плагины) нужен, если можно делать просто отдельный продукт. Какие плюсы будут получены от браузер-основанной IDE?

Про пакеты в атоме тут: https://atom.io/docs/v0.67.0/creating-a-package

Вкратце: атом построен на веб-технологиях (html5+css render, less/sass, coffe-script код, node.js, менеджеры пакетов наподобие npm). В результате довольно просто и ясно как делать плагины к редактору, которые сильни изменяют его поведение. Но при этом - само приложение является десктопным. Не думаю, что будет слишком сложно добавить туда нативные куски кода для работы с отладчиком и тп, что неудобно делать из JS. Ну и архитектура атома - вполне себе свежее явление! Мне импонирует такой подход: в JS завернуто в основном прикладная логика оболочки, и вопросы рендера view, удобная css стилизация и прочие плюшки. Насчет скорости - ну не все так плохо, думаю современные dev-машины вполне себе потянут.


Добавлено:

Цитата:

Какие плюсы будут получены от браузер-основанной IDE?  

Из плюсов - легкость и простота интеграции довольно мощных пакетов, при этом безопасность вполне ок. Многопоточность, как я понял, обеспечивается через node.js Не нужно генерировать бинарные плагины для каждой платформы. Ну и бинарный плагин - это всегда определенный риск, JS попроще.

sergionn

Цитата:

если отбросить всю маркетинговую шелуху то в 2014 почти ничего нужного и актуального НЕ СВЕТИТ

QPS более чем актуально. И если оба релиза будут направлены на это, есть вероятность, что чего-нибудь да улучшат.

Alexey_Gawrilow

Цитата:

Это чейта? Список языков JVM

Это список языков для которых JVM является бэкендом, но ты то сказал о фронтенде т.е. непосредственно самой Java. МС однажды пыталась сделать собственную Java, и солнцевским, помнится, это не очень понравилось


Цитата:

kaz_av? если да

Да, блог мой.

deks

Цитата:

Из плюсов

Ну вот кроме кроссплатформы я никаких внятных плюсов не вижу, да и тот упирается в нативные плагины. Зато могу предположить о минусах - скорость и потребление памяти. Как я понимаю, на Atom вживую посмотреть пока нельзя, поэтому конкретно о нем ничего не сказать, но можно посмотреть по подобию (HTML+JS приложения). Например простенькая демка в хроме потребляет примерно 50Mb, ничего особенного не делая. Очень простой браузерный гуй (yaaw) для aria2c кушает примерно 16Mb. Сколько будет потреблять полноценная IDE с открытым проектом я что-то даже представить боюсь. Думаю, даже для девелоперской машины это будет слишком. Ну и по скорости. Я перепробовал кучу десктопных редакторов для программистов, позиционирующихся очень быстрыми и умеющими понимать паскалевский код (т.е. не просто подсветка, но и стурктура кода + навигация по структуре) и ни один не смог с нормальной скоростью работать с файлом на 15 тыс. строк. Кроме Delphi и Lazarus - ни один (впрочем, с навигацией у Delphi беда). Хотя нагнуть можно и Delphi Однажды, для интереса, я попробовал открыть в Delphi машинно-сгенерированный фай содержащий примерно 20 тыс. перегруженных процедур (это был эксперимент!) - Delphi пришлось снимать через диспетчер задачь Так вот я не думаю, что внутрибраузерный редактор сможет сделать то, чего не могут настольные.

kaz_av

Атом в закрытой бэте по инвайтам. Если нужен инвайт - почту в ПМ.

Про memory footprint: Eclipse тоже не нативный, а вовсе даже на java - и ничего, работают. Аналогично всем поделкам от JetBrains. Демка в хроме есть память потому, что сам хром жирный. Даже оч крутая демка будет жрать столько же - так как из 50Mb 49,9 жрет сам хром (на жизнь, shadow dom и все браузерные плюшки).

Про память и dev машины. Не знаю у кого как, но меньше 16Gb на настольной машине по нынешним временам - это смешно. У меня на самом дохлом ноуте 4Gb (и то думаю заменить на ноут с 8Gb), поэтому 50Mb ram memory footprint вообще ни разу не пугают.

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

Про "может сделать" - в браузерных штуках с открытой архитектурой плагинов плюс один - плагины смогут делать куча народа. Бинарные же плагины - это для откровенных эстетов, нужен определенный API и SDK для их разработки, что делает все сложнее на порядок. Поэтому речь не идет о некоторых возможностях, которые недостижимы в настольном приложении. Просто в браузере все легче получится, проще (ну например, стили css и общий layout) - а некоторые вещи тупо быстрее (из-за оптимизированности движков браузеров).

deks

Цитата:

Даже оч крутая демка будет жрать столько же - так как из 50Mb 49,9 жрет сам хром (на жизнь, shadow dom и все браузерные плюшки).

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


Цитата:

поэтому 50Mb ram memory footprint вообще ни разу не пугают.

Да там не 50Mb будет, а много больше (у меня сейчас Опера 12 (однопроцессная еще) с полутора десятками страничек уже перевалила за 800Mb. Все страницы статичны, flash вообще заблокирован). К сожалению нет ничего похожего, чтоб сделать хоть какой-то сравнительный анализ. Но я думаю, что шевелиться оно перестанет раньше, чем сожрет все ОЗУ


Цитата:

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

Язык, увы, не позволяет. Я писал о причине на форуме фрипаскаля:

Цитата:

У меня есть модуль XmlRpc.Types количство строк в котором приближается к 15 тыс. Там описаны только базовые типы и работа с ними. Ничего лишнего. По идее, я мог бы выделить каждый тип в отдельный модуль, но это будет означать, что мои пользователи вместо Uses XmlRpc.Types; вынуждены будут писать Uses XmlRpc.Value, XmlRpc.Array, XmlRpc.Struct и так далее. Мне эта идея не нравится. Однако, если бы в ObjectPascal была нормальная реализация пространств имен я не задумываяь разделил бы такой большой файл, но не потому что он такой большой, а потому, что в этом случае такое деление выглядело бы логичным.

Ну и потом, дельфийские Forms.pas, Classes.pas тоже в районе 15-16 тыс. Windows.pas так вообще 37 тыс. (XE2).


Цитата:

Просто в браузере все легче получится, проще

Простота означает только одно - низкий порог вхождения. Чем плох низкий порог объяснять, думаю, не нужно. Ну и потом, не всем нравится тот плагинный угар существующий в лисе. Перефразируя известную фразу о линуксе - настроить можно все и вы, @#$дь, будете это настраивать

kaz_av

Цитата:

МС однажды пыталась сделать собственную Java, и солнцевским, помнится, это не очень понравилось

Не понравилось почему?
Потому что MS сделала расширения, привязывающую реализацию к Windows и напрочь убивавщую единственное оправдание существования Java на Земле - написано однажды - работает везде.
Ну это по крайней мере, SUN тогда так думала.

MS не сильно расстроилась, и подумав, выкатила NET.

А RO...назовут "Углеродом"... и поедут дальше.

kaz_av

Цитата:

Язык, увы, не позволяет

Oxygene / C# имеют вполне годные namespace. Поэтому смысла в портянках нету! Для Дельфи то никто и не предлагает browser-based IDE, для EMRO новая IDE щас вообще не приоритет, хотя, имхо, могли бы и показать какой-то прогресс со времен RAD Studio.

Alexey_Gawrilow

Ну - в целом мысль то про Java здравая! Про тот же C# написали, что 90% инвестиций в развитие продукта идет на пользу обоим языкам! А получив еще и Java (один из ведущих по распространенности среди девелоперов языков) можно нехило расширить базу клиентов. Благо опыт с Java у них есть: Paste Java as Oxygene существует (конвертер кода). Ну и третий фронтэнд для готового backend - это уже легче чем второй))

Цитата:

Ну и третий фронтэнд для готового backend - это уже легче чем второй

Грусть - тоска.
Вспоминается TopSpeed, XDS.
Нагло обворованный Juice.

Хотя для XDS компиляторы всегда были лишь средством производства, а не титульным продуктом.

Alexey_Gawrilow

Цитата:

Потому что MS сделала расширения, привязывающую реализацию к Windows и напрочь убивавщую единственное оправдание существования Java на Земле - написано однажды - работает везде.

Ну а теперь могут наехать за то, что реализация поддерживает .NET - прямого конкурента Oracle ведь уже пыталась наехать на ведроид за использование Java API.


Цитата:

А RO...назовут "Углеродом"... и поедут дальше.

И для пиара плохо, да и не известо, можно ли вот так просто взять и сделать 100% совместимый язык, а потом просто вывеску сменить. В общем, даже если наезд оракула будет не бесспорным, у RO, думаю, деньги закончатся раньше


deks

Цитата:

Oxygene / C# имеют вполне годные namespace. Поэтому смысла в портянках нету!

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


Цитата:

хотя, имхо, могли бы и показать какой-то прогресс со времен RAD Studio

Да вот по роадмапу собираются новые визуальные редакторы делать для мобильной разработки. Не стало бы хуже...

kaz_av

Вместо новых визуальных редакторов нужен новый backend для среды: текущий - это же позор. нет нормальных refactoring, error insight работает как бог на душу положит, временами code formatting портит код, и тп. Правильную же затею начали - перевести кодогенерацию на модульную архитектуру - фронтэнд, бэкэнд, заюзать LLVM и тп. Видимо, кончается компетенция в развитии подобных штук.

deks
И не говори

Цитата:

  Вместо новых визуальных редакторов нужен новый backend для среды

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

HeMet
А Рощин на скуле говорил, что решения принимаются в Америках. Впрочем, это, разумеется, не может помешать местным горячо спорить


Цитата:

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

Блин, им бы, для начала, самой FMX заняться...

Цитата:

Впрочем, это, разумеется, не может помешать местным горячо спорит

Разговор был о EMB в целом, а не о нашем подразделении.

HeMet

А о чем горячо спорить про IDE? Очевидно же что нету никаких особенных инноваций начиная с 2006 версии (или когда там Studio появилась).

Видимо - споры о том, не пора ли пристрелить старушку..

Лично мое мнение простое: "до основанья, а затем" - не метод. Только плавная полировка сабжа, только частые релизы, только быстрый фикс багов. Допиливать нужно именно "потроха" IDE, там архитектура страдает. Слишком много технического долга накоплено, пора отдать: выкинуть нафиг J#, сделать единый парсер для языка (языков? C++ и Pascal), который компилятор будет обслуживать и всех прочих нуждающихся (рефакторинг, подсветки кода, ошибок, CC, а может еще и в API отдать AST), старый DCC отставить в сторону, и перевести все платформы на новый модульный компилятор (для совместимости оставить на несколько релизов старый компилятор - как Apple делала с GCC/LLVM)..

Также страшно нужен единый нормальный менеджер пакетов с репозиториями (публичными для open source и частными для коммерческих компонентов с autorized доступом). Неплохо было бы прикрутить к менеджеру пакетов какую нибудь галлерею!..

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

Цитата:

Также страшно нужен единый нормальный менеджер пакетов с репозиториями

Есть же OwlyCI, но со стороны сообщества к нему очень мало внимания. Есть люди, которые считают, что «а нафига оно надо? мы и так все скачаем и поставим».

HeMet

Для дельфистов - может и пофиг, все привыкли к установке пакетов руками, есть куча автоматизации такой установки (LazyDelphiBuilder, DelphiPI, InnoSetup, Train, etc), но ни одного приличного средства от вендора.

У конкурентов - у всех есть пакеты (в C#, JS, Cocoa, etc). То есть, если переманивать народ на свою платформу - нужно дать вменяемые альтернативы привычным инструментам. Странно, что в ЭМРО этого не понимают.

Fire Свежий скрин про Fire - какую то среду (Mac или CrossPaltform? но нативную для Oxygene/C#) от RemObjects: https://twitter.com/dwarfland/status/441373075201064960/photo/1 Выглядит как XCode, видимо расчитано на переманивание народа с Cocoa для кросс-платформы. Забавно будет делать iPhone/Android приложение с такой IDE))

Что придумали маркетологи....
http://www.appmethod.com/
http://delphibistro.com/?p=305
http://techcrunch.com/2014/03/06/embarcadero-launches-appmethod-a-new-multi-device-development-platform-for-native-apps/?ncid=rss

sergionn
Ценник интересный. Не зря все-же RO пилят элементы

Цитата:

Что придумали маркетологи....

Это что новая жизнь старой RAD Studio?

Цитата:

Ценник интересный

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


Цитата:

Это что новая жизнь старой RAD Studio?

ага без vcl.......
"старым" дельфистам кроссплатформ не нужен, решили зайти на молодой рынок с новой вывеской........

Предположу, что тут баги с emb могут сыграть злую шутку, молодежь долго цацкаться не будет,
не будет работать как заявлено, раструбят/загубят на весь инет, мало не покажется,
это ведь только закоренелые дельфи-адепты могут верить в "светлое будущее" 5 и более версий подряд.........


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

sergionn

Цитата:

это покруче чем SA, не заплатил - обломись...

Ну, $300 баксов в год не страшно, если конечно будет за что платить

Цитата:

Ну, $300 баксов в год не страшно, если конечно будет за что платить

не вопрос, сумма адекватная, "дъявол" в последней фразе
мы штуку$ за xe2 выложили, на волне схожего анонса..........,
тоже казалось все будет шоколадно

sergionn

Цитата:

не вопрос, сумма адекватная, "дъявол" в последней фразе

Так там же еще и бесплатная версия по которой можно будет оценить качество. Правда, не понятно, что будет с исходниками в бесплатной. В TurboDelphi Explorer исходники были. Ну, ждать осталоcь не долго

Добавлено:
На скриншоте инспектор объектов глючит, прям, как и в XE5 (свойство Opacity)

Цитата:

не дав поддержку не-НЕОНОВЫХ проциков и Atom для Андроида

Какая у них доля на рынке? Неоном не оснащены только относительно старые модели, у Intel пока тоже не густо.
Откуда информация о том, что ничего не будет работать когда истечет оплаченный срок обновлений?

Цитата:

На скриншоте инспектор объектов глючит, прям, как и в XE5

Судя по FAQ http://www.embarcadero.com/products/rad-studio/appmethod-faq это оно и есть, но исключительно кросс-платформенное и по другой цене.

Как я понял, AppMethod - это только FM Platform. Интересно, что там с IDE! Видимо, RAD Studio с новой шкуркой.

deks

Цитата:

Видимо, RAD Studio с новой шкуркой.

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

Весьма интересна дата - 18 Марта. Скорее всего и полная студия зарелизится в тот же день.

Цитата:

Ну, $300 баксов в год не страшно, если конечно будет за что платить

прекрасный стимул для Эмбы пилить FMX с максимальной отдачей. Иначе не купят сл. версию. А за $300 без продлений бонусов никому не дадут. Когда умеренно плохо все у Эмбы -- это хорошо. Наступает отрезвление. "Пиджаки" понимают, что нужно реально работать, или их уволят.

Я верю: если долго мучиться, что-нибудь получится. Только бы тупые "архитекторы" не саботировали.

Что же до планов 2014 года. Дельфи и впрямь нужны QPS(все критические инновации уже есть), а среде в целом -- новый 32-разрядный компилятор С++. Наполеоновских планов нет. Ну и не надо.

--
про объекты.
A_V

Цитата:

создаются, как и рекорды, на стеке, это по-сути и есть рекорд с методами и наследованием ,но без полиморфизма.

A_V, не греши!
1. Созаются где угодно, включая стек.
2. Полиморфизм есть, опционально (позорник)!


deks

Цитата:

Скажите - а для этих "старых" объектов существует такое понятие, как конструктор? Как они создаются? Ну - для общего развития))

Да существует. Как и деструктор. Для объектов без виртуальных методов, это просто метод. В отличие от НОВЫХ классов, конструктор вызывается как обычный метод ( а не как метод класса!)
Для объектов с виртуальными методами, происходит инициализация VMT указателя(который бинарно расположен в хвосте объекта, а не в начале)
У невиртуальных объектов нет этого указателя.

Для объектов в ДИНАМИЧЕСКОЙ памяти можно вызвать конструтор в рамках New.


Код:
var myObj:^TMyObj;
begin
New(myObj,Init);//Init это имя конструктора)
///do the stuff
Dispose(myObj, Done) //Done это имя деструктора!! Как-то так.

Цитата:

Предположу, что тут баги с emb могут сыграть злую шутку, молодежь долго цацкаться не будет,
не будет работать как заявлено, раструбят/загубят на весь инет, мало не покажется

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