(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-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 я отлично в курсе, я на нем довольно много программировал (хотя и не то, что обычно на нем программируют).