«Mac/Linux дает заработок» — ну вот Mac поддерживают уже сейчас, Linux обещают в дальнейшем.
«О каком провале Borland'a идет речь? Вы относительно .Net'a в 8ке? Ну там никто не бросал native»
Это как это не бросал? Выкинута старая IDE, все силы на .NET, ЕМНИП восьмера под Win32 вообще не собирала.
«Ну там никто не бросал native, просто был наркоманский эксперимент уровня iOS'a в XE2 ) „
Поддержка iOS — лишь малая часть нововведений XE2. А Delphi 8 — это чистый метадон.
“Prism — это не borland'овский потуги, а отдельная коммерческая разработка, которая не пыталась хватать звезд с неба»
Я в курсе, чья это разработка :)
«Т.е. по вашему поддержка (почти готовая) линукс-зоопарка это мелочь жизни,»
Вопрос в степени этого «почти». И субъективно — для меня мелочь. Ибо десктоп на линуксе как-то заработка не обещает, а не десктоп занят плотно и не Дельфи.
«Я лишь спорю о приоритетах, о выборе партнеров и о характере «движения» в целом. „
Ну спорить об этом можно и иногда нужно, но пока принятые решения не дают повода говорить о сливе, тем более эпическом. А выбор партнера — операция, требующая взаимности. Хорошо иметь, скажем, яблоко в союзниках, но надо чтобы и яблочные этого союза хотели.
Для сравнения — эталонный эпический слив борланда: как можно было бросать рынок разработки нативных приложений, вставая в полную зависимость от микрософт, пытаясь портировать непортируемое с гарантированным отставанием от оригинала. Приницпиальная разница с XE2 очевидна, не так ли?
Решается и стартует — я как раз в такой работаю. Проблемы масштабирования на другие платформы не стоят, а со всем остальным Дельфи справляется вполне успешно. Главное что беспокоит — размеры комьюнити в целом и оправданность цены. XE2 ИМХО позитивно работает на оба показателя.
«Вот, смотрите, Delphi в его одном из последних стабильных состояний (возьмем, допустим x86 D2007) — всем хорош, он устраивает от и до. »
Я как раз на нем пишу — не устраивает. Нормальный юникод, генерики, анонимные методы, атрибуты, автодокументация — иногда аж скулы сводит, когда приходится раз за разом вместо нормального решения «кодоблудить».
«Давайте посмотрим, чего ждало большинство. Может быть iOS? Да ни за что не поверю, это безумие. „
Я не ждал, но рад. Ибо дополнительное поле для заработка без необходимости копаться в Objective C
“Кто мешал договориться с foundation, которое держит FPC на лицензирование последнего?»
Обычно такие вопросы не имеют достоверного ответа по построению — возможно, договариваются прямо сейчас, возможно — владельцы упертые. Девок вон тоже было бы хорошо включить в поставку — но видно не все сразу.
«С RTL все более менее ясно, но почему выбор по GUI пал таким макаром?» Полагаю, потому что к Qt/Gtk интерфейс всегда будет оберточным, а две обертки до натива — это не Дельфи стиль ни разу. Плюс, предпочли опираться на свое, не надеясь ни на комьюнити, ни на владельца.
«Ведь до последнего, пока не поняли, что их кидают — многие компонент-вендоры держали порты под CLX.»
А как у CLX с макосью? И запах кидалова, пусть и еще борландовского вендоров точно не привлечет. А тут сразу видно — за свою библиотеку эмбаркадеро будет держаться всеми частями тела.
Какая бездна-то? Эмбаркадеро на Дельфи убытков явно не несет, а понадеяться на нокию — можно эпически слить, даже сделав все остальное правильно. Вытащить Дельфи из застоя можно только решительными мерами по развитию, что и делается. Да, есть риск облажаться, но выигрывать без риска нельзя.
Нормально пытаются — яблочный рынок вполне себе капиталоемкий. 64-битность нужна для нормальной интеграции в проводник, FastReport дает возможность фрилансить без обязательного приобретения себя любимого, поддержка документации на лету давно уже нужна. Кроссплатформенность — добавляется прямо сейчас. Что еще надо-то от далеко не самой крупной конторы-производителя?
Создание-уничтожение на стеке — штука одинаково стремительная. Создание-уничтожение в куче — в ФП быстрее, причем не в одной операции, а в целом. Сущности в ФП далеко не столь краткоживущи как кажется, благодаря неограниченному повторному использованию по ссылкам.
И если приложение по своей природе обладает зверским аппетитом, то кормить придется либо возвратом к процедурами, либо задействуя функциоанльный подход, либо используя и то и другое. ООП же экономии ресурсов железа не обещает ни в каком варианте. От него нет плюсов в плане производительности приложения — только в плане производительности разработки по сравнению с процедурным подходом.
«Когда требуется масштабирования на другие платформы» — для 90% приложений не требуется никогда. Можно юзать яву — но тогда про ваш десктоп надо будет говорить или хорошо или ничего.
Кроссплатформа+несколько архитектур+мобильные — причем тут Дельфи? Дельфи — это нативные приложения с удобным пользовательским интерфейсом, удобным разработчику языком и визуальным дизайнером. Делать такое еще и для макоси — замечательно, для афони — великолепно (разуммется, когда до ума доведут). Последняя версия — движение как раз в предложенном вами направлении. Что не так? То что линуксовому зоопарку предпочли яблочную упорядоченность?
Альтернативы какие? Нативные приложения под винду за дельфи остаются, под дотнет предлагается призма, под линукс самим ломиться смысла нет, Ынтрыпрайз поеден явой. Что остается? Нативные приложения под яблочников ИМХО самое то.
«Естественно требует, но не на каждый чих.»
Именно, что на каждый — создание-уничтожение объекта требует выделение-освобождение памяти.
«Да, она может выделяться и собираться быстрее, нежели в ООП, однако это отнюдь не означает, что данной проблемы нет.»
Есть, но стоит менее остро из-за отсутсвия потребности в копировании сущностей. Сборка мусора для функциональных сред появилась раньше и сейчас более эффективно, чем для ООП. Разница есть только на задачах, которые длительное время используют фиксированные ресурсы — но это уже не ООП, а процедурный подход.
На больших объемах ООП сливает быстрее, чем функциональщина — вторая может требовать нетривиальной оптимизации, а первая рушится под грузом миллионов объектов и синхронизации между потоками. Груз массы объектов лечится только шагом назад — возвратом на критичном уровне к массивами, процедурам и прелестям чистого C.
А груз синхронизации — устранением где только возможно изменяемого состояния, т.е. использованием функциональщины.
Думать, что ООП кушает меньше ресурсов, чем ФП — принципиальная ошибка.
«функциональная парадигма требует постоянного выделения\собирания памяти» — а ООП не требует?
«что, все-таки имеет некоторый эффект как на быстродействие системы, так и на требование к количеству используемой памяти» — выделение памяти и сборка мусора в функциональной среде куда быстрее и экономнее, чем в императивной, так как не неизменяемые данные не нуждаются в копировании и контроле за изменениями. Проблема в другом — на нижнем уровне архитектура таки императивная и нет универсального эффективного интерпретатора.
Я бы сказал грубее — если я делал правки, то с какого перепугу программа думает, что они мне потом не нужны? Да еще и блочит! Не хотелось бы мне сохранять — я бы выбрал в меню команду «выход без сохранения». Ах, нет такой команды? Можно только трансректально?
«О каком провале Borland'a идет речь? Вы относительно .Net'a в 8ке? Ну там никто не бросал native»
Это как это не бросал? Выкинута старая IDE, все силы на .NET, ЕМНИП восьмера под Win32 вообще не собирала.
«Ну там никто не бросал native, просто был наркоманский эксперимент уровня iOS'a в XE2 ) „
Поддержка iOS — лишь малая часть нововведений XE2. А Delphi 8 — это чистый метадон.
“Prism — это не borland'овский потуги, а отдельная коммерческая разработка, которая не пыталась хватать звезд с неба»
Я в курсе, чья это разработка :)
Вопрос в степени этого «почти». И субъективно — для меня мелочь. Ибо десктоп на линуксе как-то заработка не обещает, а не десктоп занят плотно и не Дельфи.
«Я лишь спорю о приоритетах, о выборе партнеров и о характере «движения» в целом. „
Ну спорить об этом можно и иногда нужно, но пока принятые решения не дают повода говорить о сливе, тем более эпическом. А выбор партнера — операция, требующая взаимности. Хорошо иметь, скажем, яблоко в союзниках, но надо чтобы и яблочные этого союза хотели.
Для сравнения — эталонный эпический слив борланда: как можно было бросать рынок разработки нативных приложений, вставая в полную зависимость от микрософт, пытаясь портировать непортируемое с гарантированным отставанием от оригинала. Приницпиальная разница с XE2 очевидна, не так ли?
Я как раз на нем пишу — не устраивает. Нормальный юникод, генерики, анонимные методы, атрибуты, автодокументация — иногда аж скулы сводит, когда приходится раз за разом вместо нормального решения «кодоблудить».
«Давайте посмотрим, чего ждало большинство. Может быть iOS? Да ни за что не поверю, это безумие. „
Я не ждал, но рад. Ибо дополнительное поле для заработка без необходимости копаться в Objective C
“Кто мешал договориться с foundation, которое держит FPC на лицензирование последнего?»
Обычно такие вопросы не имеют достоверного ответа по построению — возможно, договариваются прямо сейчас, возможно — владельцы упертые. Девок вон тоже было бы хорошо включить в поставку — но видно не все сразу.
«С RTL все более менее ясно, но почему выбор по GUI пал таким макаром?» Полагаю, потому что к Qt/Gtk интерфейс всегда будет оберточным, а две обертки до натива — это не Дельфи стиль ни разу. Плюс, предпочли опираться на свое, не надеясь ни на комьюнити, ни на владельца.
«Ведь до последнего, пока не поняли, что их кидают — многие компонент-вендоры держали порты под CLX.»
А как у CLX с макосью? И запах кидалова, пусть и еще борландовского вендоров точно не привлечет. А тут сразу видно — за свою библиотеку эмбаркадеро будет держаться всеми частями тела.
И если приложение по своей природе обладает зверским аппетитом, то кормить придется либо возвратом к процедурами, либо задействуя функциоанльный подход, либо используя и то и другое. ООП же экономии ресурсов железа не обещает ни в каком варианте. От него нет плюсов в плане производительности приложения — только в плане производительности разработки по сравнению с процедурным подходом.
Именно, что на каждый — создание-уничтожение объекта требует выделение-освобождение памяти.
«Да, она может выделяться и собираться быстрее, нежели в ООП, однако это отнюдь не означает, что данной проблемы нет.»
Есть, но стоит менее остро из-за отсутсвия потребности в копировании сущностей. Сборка мусора для функциональных сред появилась раньше и сейчас более эффективно, чем для ООП. Разница есть только на задачах, которые длительное время используют фиксированные ресурсы — но это уже не ООП, а процедурный подход.
На больших объемах ООП сливает быстрее, чем функциональщина — вторая может требовать нетривиальной оптимизации, а первая рушится под грузом миллионов объектов и синхронизации между потоками. Груз массы объектов лечится только шагом назад — возвратом на критичном уровне к массивами, процедурам и прелестям чистого C.
А груз синхронизации — устранением где только возможно изменяемого состояния, т.е. использованием функциональщины.
Думать, что ООП кушает меньше ресурсов, чем ФП — принципиальная ошибка.
«что, все-таки имеет некоторый эффект как на быстродействие системы, так и на требование к количеству используемой памяти» — выделение памяти и сборка мусора в функциональной среде куда быстрее и экономнее, чем в императивной, так как не неизменяемые данные не нуждаются в копировании и контроле за изменениями. Проблема в другом — на нижнем уровне архитектура таки императивная и нет универсального эффективного интерпретатора.