Какие вы можете выделить сегодня тенденции развития программирования?

[pu4koff]

Сообщение от Пепел Феникса

в принципе насчет ругания ОС согласен, не ОС виновата.

ОС должна давать удобный АПИ, чтобы не было необходимости создавать костыли. Так же, где возможно, должна вынуждать писать правильно (в соответствии с выбранным подходом в конкретной ОС)

Сообщение от Пепел Феникса

в винде есть механизмы DLL, ActiveX/COM.
разработчики их не используют на всю мощь, вот и вся проблема по сути говоря.

DLL умеет только функции. Есть объектные DLL в MFC, но тамтеряется весь смысл DLL, т.к. их только с MFC кодом и можно использовать.
ActiveX - это в принципе объектная надстройка над DLL, т.е. костыль и он достаточно сложен в использовании. Если бы это был удобный инструмент, тогда его использовали, а так нафиг он никому не сдался.
Итого имеем достаточно удобные DLL, которые не умеют классы и потому они не используются в ОО коде или же пишутся кучи обёрток. И совершенно неудобные ActiveX. Нормального инструмента нет.

Сообщение от Пепел Феникса

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

Давайте посмотрим.
Есть С++ без стандартного GUI. Имеем целый зоопарк библиотек, которые оборачивают WinAPI.
Есть Delphi со стандартной библиотекой на классах. В итоге нет никакого зоопарка, а чистый WinAPI используется отдельными ценителями прекрасного.
Есть C# с WinForms и позже появившимся WPF (веб в данном случае не берем в расчет). Не слышал, чтобы кто-то делал свою альтернативу над чистым WinAPI.
Плюс WinAPI в том, что он выглядит одинаково во всех языках. Когда же имеется целый зоопарк надстроек и прокладок, то фигня получается. К багам API добавляются баги и особенности конкретных обёрток. Так зачем нужны эти лишние звенья?

Сообщение от Пепел Феникса

надо менять тенденцию разработчиков, а не ОС.

Это да. Выпустили вот новую WP7. Понаписали кучу рекомендаций по созданию программ и их интерфейсов. В итоге куча программ написаны в стиле других ОС и к МЕТРО-дизайну не имеют никакого отношения.

Сообщение от Пепел Феникса

знаете, пусть даже в ОС будет все то вы просите, но если разработчики так и будут плодить это все для себя(каждый себе библиотечку) то и это обернеться тем же.

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

Сообщение от Пепел Феникса

низкоуровневый это АПИ или асм?
если АПИ то от него не уйти в принципе.

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

[Пепел Феникса]

ОС должна давать удобный АПИ, чтобы не было необходимости создавать костыли. Так же, где возможно, должна вынуждать писать правильно (в соответствии с выбранным подходом в конкретной ОС)

ну насчет вынуждать писать правильно, к сожалению почти невозможно(кривые руки ОС не выпрямит...)

DLL умеет только функции. Есть объектные DLL в MFC, но тамтеряется весь смысл DLL, т.к. их только с MFC кодом и можно использовать.

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

Давайте посмотрим.

а почему берем именно ООП языки?
вот именно поэтому я против ООП-АПИ.

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

по мне так компромисным решением была бы оффициальная обертка над АПИ(чтоб не было разницы в функциональности с ООП и без)
то есть:

FILE* f=CreateFile("1.txt");
WriteFile(...);
CloseFile(f);

и

File* f=File::Create("1.txt");
f.Write(...);
delete File;

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

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

по сути это единственное чем я недоволен в экспорте сейчашнем.
а то экспорт/импорт/работа с функциями phLibrary_Stream_Create как то не айс.
разве что делать обертку с переименованием.

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

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

[rpy3uH]

Сообщение от pu4koff

ОС должна предоставлять адекватный API. Сейчас у них в большинстве своём он базируется на функциях, а код объектно-ориентированный. Из-за этого существует куча обёрток, которые создают то же самое, но через классы. При этом для каждого языка эти обёртки разные и особенности у них разные. Тот же WinAPI мало кто в чистом виде использует.

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

если мы вызываем функцию ReadFile, то она в свою очередь просто оболочка вокруг функции ядра системы NtReadFile. ядро системы и программы отгорождены друг от друга высоким бетонными забором. поэтому превратить взаимодействие ОС в объекто-ориентированную вещь очень сложно, и в итоге всё равно всё сведётся к вызову функций.

и к тому для ООП нет стандарта, в том время как дял COM и ActiveX стандарт есть.

Сообщение от pu4koff

DLL умеет только функции. Есть объектные DLL в MFC, но тамтеряется весь смысл DLL, т.к. их только с MFC кодом и можно использовать.
ActiveX - это в принципе объектная надстройка над DLL, т.е. костыль и он достаточно сложен в использовании. Если бы это был удобный инструмент, тогда его использовали, а так нафиг он никому не сдался.
Итого имеем достаточно удобные DLL, которые не умеют классы и потому они не используются в ОО коде или же пишутся кучи обёрток. И совершенно неудобные ActiveX. Нормального инструмента нет.

DLL - это единственное, до чего дошёл прогресс разработчиков. лучше ещё не придумали.
как только мы вводим ООП, то библиотеку можно использовать только на одном языке программирования.

Сообщение от pu4koff

Есть C# с WinForms и позже появившимся WPF (веб в данном случае не берем в расчет). Не слышал, чтобы кто-то делал свою альтернативу над чистым WinAPI.

в .NET напрямую вызывать win API нельзя

Сообщение от pu4koff

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

вся проблема в том что разработчики почему-то постоянно стремятся к кроссплатформенности поэтому и используются всякие обёртки типа fstream и прочие.

[Utkin]

pu4koff - насчет браузеров . Есть LunaScape - японцы догадались засунуть в него три движка. Оперный и ослиный там есть .

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

Потому что они навязаны. Пользуйте Posix.

[pu4koff]

Сообщение от Пепел Феникса

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

Вот и я о том же. Только ActiveX капец как неудобен. В то время как работа с DLL близка к идеальной в случае с функциями.

Сообщение от Пепел Феникса

а почему берем именно ООП языки?
вот именно поэтому я против ООП-АПИ.

На данный момент бОльшая часть прикладного кода пишется на ОО-языках.

Сообщение от Пепел Феникса

по мне так компромисным решением была бы оффициальная обертка над АПИ(чтоб не было разницы в функциональности с ООП и без)

Как вариант, но это тоже костыль.

Сообщение от Пепел Феникса

по сути это единственное чем я недоволен в экспорте сейчашнем.
а то экспорт/импорт/работа с функциями phLibrary_Stream_Create как то не айс.

А еще получается каша из разных подходов программирования. Или же в коде появляются обёртки над обёртками обёрток.

Сообщение от Пепел Феникса

разве что делать обертку с переименованием.

Это лишняя никому ненужная работа, которая только влечёт возникновение ошибок.

Сообщение от Пепел Феникса

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

я считаю, что вместо асма должен быть JIT / MSIL и аналоги.

Сообщение от rpy3uH

от ассемблера никуда не уйти, API как было так и будет всегда.

Не айти только от команд процессора, а ОС должна выдавать наружу что-то более высокоуровневое, подобно жабе и дот нету.

Сообщение от rpy3uH

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

Прям так и невозможно?

Сообщение от rpy3uH

если мы вызываем функцию ReadFile, то она в свою очередь просто оболочка вокруг функции ядра системы NtReadFile. ядро системы и программы отгорождены друг от друга высоким бетонными забором. поэтому превратить взаимодействие ОС в объекто-ориентированную вещь очень сложно, и в итоге всё равно всё сведётся к вызову функций.

Да. По сути будут те же яйца, только в профиль. Основная разница: я не буду видеть всех этих прослоек. Инкапсуляция, будь она не ладна

Сообщение от rpy3uH

и к тому для ООП нет стандарта, в том время как дял COM и ActiveX стандарт есть.

На самом деле у меня и к ООП вопросов есть, но... в этих самых комах разве не один из вариантов ООП реализован по сути?
Да они есть, но они неудобны в использовании. Я лучше напишу ОО-код, засуну его в DLL, наружу выдам обычные функции, а потом еще дополнительную обёртку в ОО-стиле напишу, чтобы нормально этой DLL пользоваться в программах, чем начну приделывать ActiveX.

Сообщение от rpy3uH

в .NET напрямую вызывать win API нельзя

С чего вдруг? Обычные неуправляемые DLL можно подгружать, а винапишные - нет?

Сообщение от rpy3uH

вся проблема в том что разработчики почему-то постоянно стремятся к кроссплатформенности поэтому и используются всякие обёртки типа fstream и прочие.

Что в этом плохого? Зачем переписывать одно и то же под разные платформы, когда можно спроектировать единые интерфейсы и общаться через них? У Microsoft сейчас есть Xna и игры под xbox, pc и wp7 могут иметь одну базу с допиливанием графики, управления и прочих нюансов под конкретную платформу. Это лучше, чем писать под каждую из платформ всё с нуля. Разве нет?
Вместо рационального планомерного развития технологий, сейчас топчемся на месте (что-то куда-то постоянно портируют, клонируют, создают форки,...). Производители процессоров бьются за потребителя за звонкую монету и придумывают свои технологии. Производители видеочипов туда же. В итоге происходит постоянная гонка технологий, которыми люди не успевают толком начать пользоваться, как они уже объявляются устаревшими.
По сути же для меня, как пользователя, ничего кардинально нового не принесли эти технологии. Игрушки красивше стали и реалистичнее, окошки полупрозрачные появились. В работе же мне что-то удобнее не стало. В программировании за тем же .NET не успеешь, потому что тоже за кем-то гонятся постоянно.
Я хочу, чтобы наконец подумали о человеках и их целях. Я лично за большую абстракцию от железа и подобных нюансов. Мне пофиг какая там файловая система на компе стоит и не хочу думать, что на флешку с FAT32 не влезет 10 гиговый фильмак. А еще я хочу вводить фамилию длиннее 100 символов. Мне плевать что и как там в базе данных хранится, хочу и всё тут. 2011 год или где? Мультики рисуют, что от фильмов уже не отличить по качеству картинки, а такую фигню не умеют. Позорище.

[pu4koff]

Сообщение от Utkin

pu4koff - насчет браузеров . Есть LunaScape - японцы догадались засунуть в него три движка. Оперный и ослиный там есть .

Оперного нет там как раз
Вообще мне бы то же самое, только чтобы интерфейс был от оперы, а движок пусть будет IE.

Сообщение от Utkin

Потому что они навязаны. Пользуйте Posix.

Posix не достаточно глобален, удобен, красив и это не ООП, т.е. опять обёртки

[rpy3uH]

Сообщение от pu4koff

Что в этом плохого? Зачем переписывать одно и то же под разные платформы, когда можно спроектировать единые интерфейсы и общаться через них? У Microsoft сейчас есть Xna и игры под xbox, pc и wp7 могут иметь одну базу с допиливанием графики, управления и прочих нюансов под конкретную платформу. Это лучше, чем писать под каждую из платформ всё с нуля. Разве нет?

всё правильно, я не отрицаю. просто именно в этом и кроется причина написания сотен всяких обёрток и прокладок вокруг АПИ

[pu4koff]

Сообщение от rpy3uH

всё правильно, я не отрицаю. просто именно в этом и кроется причина написания сотен всяких обёрток и прокладок вокруг АПИ

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

[Utkin]

Posix не достаточно глобален

Щито? Это теперь так называется?

[pu4koff]

Сообщение от Utkin

Щито? Это теперь так называется?

Таки да