(no subject)
Sep. 13th, 2015 02:21 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
kikaЧитая обсуждение http://ivan-gandhi.livejournal.com/3329246.html и ответы на мой коммент, я вдруг понял почему так тяжело идет. У меня нет никаких проблем барабанить на Erlang'е например, а Purescript, Elm или их идейный отэц Haskell (ну или ML) идет с гораздо большим трудом.
Потому что я пришел в программирование из программирования микропроцессоров. Для меня долгое время компьютер был просто гибкой логической микросхемой, которую можно было запрограммировать на последовательность действий вместо долгого и унылого паяния и протягивания проводов, а потом отладки пробником и паяльником же.
Потом как-то программирование на ассемблере превратилось в программирование на С, но компиляторы для этих микропроцессоров были таковы, что регулярно генерировали последовательности типа
Потому что так у него оптимизатор работает, видите ли. Ну или еще почему. И надо было компилировать в ассемблерный листинг, читать его и руками чистить от этого мусора, потому что иначе в ПЗУ не лезло.
А в универе учили как на Фортране ряды Тейлора вычислять, что тоже не прибавляло.
В результате я всегда когда программирую или читаю программу, симулирую в голове стековую-регистровую машину и "исполняю" на ней программу. И какие-нибудь list comprehensions, лямбды или хвостовые рекурсии отлично на такой голове исполняются. А вот стрелки и монады - почему-то нет.
Нужна книжка или статья "Функциональное программирование для недохардверных недоинженеров". Реквестирую у мироздания.
Потому что я пришел в программирование из программирования микропроцессоров. Для меня долгое время компьютер был просто гибкой логической микросхемой, которую можно было запрограммировать на последовательность действий вместо долгого и унылого паяния и протягивания проводов, а потом отладки пробником и паяльником же.
Потом как-то программирование на ассемблере превратилось в программирование на С, но компиляторы для этих микропроцессоров были таковы, что регулярно генерировали последовательности типа
mov bx, ax
mov dx, ax
mov bx, dx
mov ax, bx
Потому что так у него оптимизатор работает, видите ли. Ну или еще почему. И надо было компилировать в ассемблерный листинг, читать его и руками чистить от этого мусора, потому что иначе в ПЗУ не лезло.
А в универе учили как на Фортране ряды Тейлора вычислять, что тоже не прибавляло.
В результате я всегда когда программирую или читаю программу, симулирую в голове стековую-регистровую машину и "исполняю" на ней программу. И какие-нибудь list comprehensions, лямбды или хвостовые рекурсии отлично на такой голове исполняются. А вот стрелки и монады - почему-то нет.
Нужна книжка или статья "Функциональное программирование для недохардверных недоинженеров". Реквестирую у мироздания.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2015-09-14 09:36 pm (UTC)А мне норм.
На венде не нужен этот стандарт. Уже многие десятилетия есть прекрасный ABI, который называется COM.
В отличие от того, что теоретически возможно со стандартным C++ ABI, COM позволяет использовать DLL из любого языка, из дот нета, из петона, и если приспичит, то можно даже из PHP. Там и многопоточность, и исключения, и ещё куча всего, и производительности хватает даже для очень performance critical штук (если оно in-process, конечно).
Если бы в красноглазом мире было нечто подобное, я уверен, что им бы тоже не упёрся этот C++ ABI.
А так у них выбора в общем-то не было, кроме как стандартизировать C++ ABI, и программировать на 30-летней давности C++.
no subject
Date: 2015-09-14 09:53 pm (UTC)Это, гм, п-ц а не abi.
>Если бы в красноглазом мире было нечто подобное,
CORBA. Особой популярностью не пользуется.
no subject
Date: 2015-09-14 10:26 pm (UTC)Не умеете его готовить.
>CORBA
Это никакой не ABI.
CORBA это стандарт взаимодействия распределённых систем.
В случае in-process COM, используемого из C++, накладные расходы — единственный виртуальный вызов. Так работают Direct3D, Media Foundation, и другие очень требовательные к производительности штуки.
В случае CORBA вы anyway попадаете на сериализацию\десериализацию, что очевидно ставит крест на производительности.
no subject
Date: 2015-09-16 06:45 am (UTC)Что характерно, никогда не стремился. С п-цом дел стараюсь не иметь.
>Это никакой не ABI.
>CORBA это стандарт взаимодействия распределённых систем.
И то, и другое - стандарт доступа к (возможно, удаленному) менеджеру/хранилищу объектов. Разумеется, ни то, ни другое стандартов ABI не являются.
>В случае in-process COM, используемого из C++, накладные расходы — единственный виртуальный вызов. Так работают Direct3D,
Чё-чё-чё?
С каких это пор DirectX стал работать через виртуальные вызовы?
no subject
Date: 2015-09-16 07:23 am (UTC)Прекрасная проверенная временем технология.
Очень удачная.
Например весь новый WinAPI (который Windows Runtime) целиком построен на COM-интерфейсах.
>И то, и другое - стандарт доступа к (возможно, удаленному) менеджеру/хранилищу объектов.
На самом высоком уровне абстракции да.
Однако COM включает в себя и ABI тоже, который с определёнными оговорками можно использовать отдельно от его более высокоуровневых фич.
>С каких это пор DirectX стал работать через виртуальные вызовы?
DirectX работает через виртуальные вызовы всю свою историю.
Он весь построен на COM интерфейсах, наследующих от IUnknown (ID3D11Device, IXAudio2, etc).
С точки зрения языка C++, COM интерфейс это pure abstract class c таблицей виртуальных методов, которые можно вызывать.
no subject
Date: 2015-09-16 08:54 am (UTC)Ничего хорошего в этом нет, в общем-то. ООП головного мозга теперь совсем зохавает мир.
>DirectX работает через виртуальные вызовы всю свою историю.
Мда. Я-то помню времена, когда это был чисто сишный АПИ, без всякого COM на поверхности. А тут вы рассказываете про ком.
Все-таки не зря винду считают гнилой платформой того же уровня, что и кофемолки.
no subject
Date: 2015-09-16 11:01 am (UTC)Ничего лучше человечество не придумало.
Интерфейс всех современных ОС задизайнен в ООП стиле, даже если он на чистом C с хэндлами, как в Win32 или линупсе.
>Я-то помню времена, когда это был чисто сишный АПИ, без всякого COM на поверхности
У вас значит с памятью что-то. Вот например статья эпохи DirectX 5, из текста которой видно, что COM на поверхности был ещё в DirectX 3:
https://www.microsoft.com/msj/0298/primitive.aspx
no subject
Date: 2015-09-16 11:49 am (UTC)Эээ, ненене. ООП там нет. Объекты - есть, ООП точно нет. И слава богу.
>У вас значит с памятью что-то.
*внимательно поглядел матчасть* Действительно. Ну, от майкрософта ничего хорошего ждать и не следовало...
no subject
Date: 2015-09-16 12:30 pm (UTC)Взаимоисключающие параграфы детектед.
>от майкрософта ничего хорошего ждать и не следовало
Тем не менее «ничего хороший» Direct3D почему-то выиграл в конкурентной борьбе у OpenGL:
http://programmers.stackexchange.com/a/88055/25371
no subject
Date: 2015-09-16 02:32 pm (UTC)Безграмотность детектед.
>Тем не менее «ничего хороший» Direct3D почему-то выиграл в конкурентной борьбе у OpenGL:
Ничего там не выиграно, даже в играх. Афаик ключевые движки (id tech, unreal engine) opengl как минимум поддерживают если на нем не живут.
На мобильном рынке (андроид, ios) directX малозаметен.
no subject
Date: 2015-09-17 03:40 am (UTC)Первая строчка из википедии:
Object-oriented programming (OOP) is a programming paradigm based on the concept of "objects"
Если вы на чём-то программируете и у вас там есть какие угодно объекты, поздравляю, у вас есть ООП. Все остальные фичи ООП вроде композиции, полиморфизма и ключевого слова class в языке — опциональны.
Поэтому ваше утверждение «Объекты - есть, ООП точно нет» таки взаимоисключающие параграфы.
>ключевые движки (id tech, unreal engine) opengl как минимум поддерживают
Поддерживают на OSX и playstation.
На венде почти 100% современных игр (кроме казуальных вроде майнкрафта и angry birds, которым не нужна производительность) рендерят при помощи Direct3D.
no subject
Date: 2015-09-17 03:58 am (UTC)Есть объектное, объектно-ориентированное и прототипное программирование (и языки, их поддерживающие). Во всех трех есть объекты, но парадигмы принципиально разные. Объектное базируется на объектах и сообщениях, объектно-ориентированное - на объектах, интерфейсах и наследовании, прототипное - на объектах и расширении существующих объектов. Примеры языков - smalltalk, java, ecmascript соотвтвенно.
И нет, не надо мне пытаться объяснить, что объектная и прототипные парадикгмы - подвариант объектно-ориентированной. Это не так.
>На венде почти 100% современных игр (кроме казуальных вроде майнкрафта и angry birds, которым не нужна производительность) рендерят при помощи Direct3D.
id Tech 6 is an upcoming OpenGL based game engine under preliminary development by id Software, which will tentatively follow id Tech 5.[1]
id Tech 5 [...] the demo used only a single core with single-threaded OpenGL implementation [...].
Кармак как сидел на opengl, так и сидит (правда, юзает directX для неграфических нужд)
no subject
Date: 2015-09-17 04:53 am (UTC)У вас детектед, да.
>Есть объектное
Smalltalk is an object-oriented, dynamically typed, reflective programming language.
>прототипное
Prototype-based programming is a style of object-oriented programming
>Это не так.
Википедия думает, что так. А у вас есть пруфлинки какие-нибудь, или это вы сами так решили?
>id Tech 5
Занимает исчезающе малую долю. 4 года на рынке, 4 выпущенные игры.
Для сравнения, на GameBryo за это время вышли 15 игр, на CryEngine примерно 30, на Unreal Engine порядка 200.
no subject
Date: 2015-09-17 10:38 am (UTC)>is a style of object-oriented programming
Больше читайте идиотов.
>Википедия думает, что так.
Википедия много глупостей думает, и зачастую неконсистентна внутри себя.
Принципы того, что называют ООП сейчас (т.е. интерфейсы, объекты, методы, полиморфизм, декомпозиция, UML-моделирование и т.п.) появились после работ Буча в конце 80-х. smalltalk заметно старше, prototype-based стиль появился в Self примерно одного с этими работами возраста, при этом оба подразумевают совершенно иной подход к проектированию. Т.е. несмотря на желание адептов ООП примазаться, это совершенно самостоятельно возникшие концепции, и с ООП у них общего только объекты и наследование
А если вы попытаетесь эти языки засунуть в ООП, то туда же придется засунуть еще и Haskell например, поскольку что-то типа subtyping, inheritance & classes/objects в нем есть =)))). И Си, поскольку на нем все это можно эмулировать. Т.е. термин потеряет классификационную силу, поскольку под него можно будет подвести любой язык.
Разумеется, интерфейс ОС ни разу не ОО, а просто О. В смысле, объекты там есть, методы есть, а вот с наследованием и субтайпингом некоторые сложности, т.е. даже в расширенном смысле их под определение ООП подвести не удастся.
>UT4
UT4 не может быть примером, поскольку он поддерживает И opengl И directX бэкэнды. Да, подвиндой у него два бэкэнда, причем я бы не сказал, что directX-вый лучше, судя по бегло нагугленному бенчмарку. Еще есть Source - у него тоже сейчас два бэкэнда, при том Valve нахваливает именно opengl бэкэнд - который вдобавок еще и сильно более молодой.
no subject
Date: 2015-09-19 04:52 pm (UTC)Термин object-oriented programming впервые использовали в применении в языку Smalltalk, про который вы мне тут рассказываете, что он не object-oriented.
Концепция развивалась конечно, но не менялась принципиально.
>А если вы попытаетесь эти языки засунуть в ООП
Программировать в ООП стиле можно даже на ассемблере, вообще без языков.
>термин потеряет классификационную силу
У него никогда не было этой силы, потому что многие современные языки мультипарадигменные.
>с наследованием и субтайпингом некоторые сложности
Например от COM-объекта тоже нельзя унаследоваться. От этого технология стала менее ОО?
>поскольку он поддерживает И opengl И directX бэкэнды
Поддерживает OpenGL потому что playstation, OSX и прочий ондроед.
>я бы не сказал, что directX-вый лучше
Под виндой как правило единственный.
>Valve нахваливает именно opengl бэкэнд
Странно, почему же тогда их собственный Source Engine под виндой рендерит только через Direct3D?
no subject
Date: 2015-09-19 05:13 pm (UTC)Языковой дрейф.
>У него никогда не было этой силы
Гм. Тогда зачем его вообще приплетать?
>Например от COM-объекта тоже нельзя унаследоваться
например, отлично можно унаследоваться от интерфейса и в ОО есть субтайпинг.
>Странно, почему же тогда их собственный Source Engine под виндой рендерит только через Direct3D?
По историческим причинам. Сначала они сделали Direct3d. И в крайнем Dota2 они сделали поддержку OpenGL подвинду. Сильно подозреваю, с перспективой сделать её основной.
no subject
Date: 2015-09-19 06:22 pm (UTC)Это никакой не дрейф, это у вас очень кривые трактовки общепринятых терминов.
>Тогда зачем его вообще приплетать?
Первое упоминание ООП в тредике было у вас, в каменте, который гласил «ООП головного мозга теперь совсем зохавает мир». Зачем?
>отлично можно унаследоваться от интерфейса
А от класса — нельзя. От этого технология стала менее ОО?
>По историческим причинам. Сначала они сделали Direct3d.
Сначала они лицензировали OpenGL-движок первого квейка. Direct3D они туда добавили, но OpenGL выкидывать не стали, пользователь первого half-life мог выбирать между двумя.
>Dota2 они сделали поддержку OpenGL подвинду
Для OpenGL там нужно шо-то дополнительное качать и запускать игру с какими-то ключами командной строки — 99.9% пользователей не будут этого делать, а будут играть на Direct3D.
no subject
Date: 2015-09-19 06:51 pm (UTC)Ок. Методики Буча головного мозга теперь совсем зохавуют мир.
Так лучше?
>А от класса — нельзя. От этого технология стала менее ОО?
Нет. Равно как и более. И?
>99.9% пользователей не будут этого делать, а будут играть на Direct3D.
Ну так это первый этап. Анонс ухода с Direct3d и превью технологии.
no subject
Date: 2015-09-20 06:54 am (UTC)WinRT API и современный С++ с лямбдами имеют немного общего с методиками Буча.
А если вспомнить, что WinRT API ещё видно из JavaScript, так и совсем почти ничего общего.
>Нет. Равно как и более.
OK.
Почему тогда интерфейсам ОС вы отказываете в том, чтобы быть ОО, на том же самом основании "не все методики Буча поддерживаются"?
>Ну так это первый этап
Первый этап был GoldSrc, когда OpenGL и Direct3D были равноправны, и переключались пользователем в настройках.
Второй этап был Source Engine, когда OpenGL выкинули.
Сейчас Valve вставили экспериментальную поддержку OpenGL, но отзывы виндовых пользователей, у которых глючит и тормозит, кагбэ говорят нам, что на венде OpenGl не нужен.
no subject
Date: 2015-09-19 07:01 pm (UTC)Кроме того, у D3D, опять же в отличие от IE, было хотя бы одно конкурентное преимущество (на самом деле два) - доступ к новым фичам (второе - immediate mode). В OpenGL они пробирались долго и зачастую через несовместимые расширения от вендоров.
А потом пришли сосноли и мобилы. Ну и в общем всё. D3D больше ничего не выиграл, он по прежнему держит рынок виндовых настольных игр, держит не монопольно, а на остальных платформах (кроме хкоробки) ему не светит ничего от слова совсем.
Сейчас все движки поддерживают обе технологии, поддерживают почти одинаково хорошо, и это в обозримом будущем не изменится, пока не сменится стандарт на игровой десктоп.
no subject
Date: 2015-09-20 07:04 am (UTC)Там намного интереснее история. Вот детально:
http://programmers.stackexchange.com/a/88055/25371
В двух словах — OpenGl слишком большой комитет, решения очень консервативны, например шейдеры проспали.
>не был таким уж жутким говном в районе 3.0
По-моему он был жутким говном до 6.0, просто говном до 9.0, а начиная с 10 стал хорошим.
>доступ к новым фичам
Это верно, только если вы имели в виду «одинаковый у красных и у зелёных доступ». Сами по себе новые фичи обычно первыми появлялись в vendor-specific OGL extensions.
>все движки поддерживают обе технологии, поддерживают почти одинаково хорошо
Почему-то на практике почти 100% виндовых игр рендерят Direct3D, несмотря на «одинаково хорошо» :-)
no subject
Date: 2015-09-20 09:28 pm (UTC)Про проблемы OpenGL я отлично в курсе, я на нем довольно много программировал (хотя и не то, что обычно на нем программируют).