Compression Oriented Programming

Всичко за програмирането на игри - архитектура, графика, звук, изкуствен интелект, мрежи.
gemicha
Site Admin
Site Admin
Мнения: 2930
Регистриран: 20 ное 2003 22:20
Местоположение: USA

Re: Compression Oriented Programming

Мнение от gemicha » 01 юни 2014 03:26

Ако си работиш сам в къщи можеш да правиш каквото решиш. Но, дори и тогава, ако след всяка промяна трябва да разглеждаш кода, който работи, и да го "компресираш" за да бъде "по-добър" това няма да доведе до нищо добро. Резултатът е ниска ефективност, трудна и бавна промяна на продукта и съвсем сигурно забавяне с месеци. Това също е многократно доказвано. Този, който си работи в къщи и иска всичко да му е идеално, според неговите не много популярни разбирания, стига до "липса на пари" и неминуемо търсене на работа. Работа предлагат тези, които са посещавали университет и са научили нещо за разработката на софтуер.

Методологиите са създадени за да ти помогнат да си ефективен. Един от проблемите, който решават е как да направим така, че след като определено парче код работи да може да се използва отново и отново без да се променя. По-лесното решение, което е по-трудно на практика, е функции без страничен ефект. По-трудно решение, но по-лесно на практика, е с ООП. Няма значение езика, който ползваш. Не случайно първите C++ компилатори транслират до C. Може да ползваш C, Pascal, ADA, C++ или Javascript.

Няма такова животно като Data Oriented Programing или "компресирано незнамсиквоси". Това са глупости. Ако някой от тези хора приложат подобни идеи в проект, който определя съдбата на компанията резултатът ще бъде затваряне на компанията. Ако не си на пазара както е с Linux ядрото може да си правиш всякакъв вид експерименти. Ако си в конкуренция с други по-добри от теб няма да стигнеш далеко. Пазарът е безмилостен и не се интересува дали си ходил в университет или какво мислиш за Лисков.

Последното ме навежда на мисълта да напише нещо за сравнението между Лисков и Кейси. Кейси е кодер. Според мен не особено добър. В района тук има поне стотина хиляди като него. Лисков е личност, която е променила софтуерната индустрия към по-добро. Такива са единици. Четете повече Лисков и по-малко Кейси и ще можете дълго да си работите от в къщи или в малки компании.

Потребителски аватар
stoiko
Power User
Power User
Мнения: 617
Регистриран: 04 дек 2003 15:44
Контакти:

Re: Compression Oriented Programming

Мнение от stoiko » 01 юни 2014 11:03

Но принципно премахването на състоянието е напълно възможно и ако имаме класове, които дори наследяват разни неща, четат се от XML и прочее.
съгласен съм че с много старание и труд може да пишеш "функционално" с класове, но това не е ли в противоречие със самата идея за "обект" т.е. съединяването на данните с кода който ги манипулира? кода на самите класовете колко добре се поддава на компресия (по кейси)? xml трябва да умре :)

Stilgar
Power User
Power User
Мнения: 824
Регистриран: 12 яну 2006 22:15
Контакти:

Re: Compression Oriented Programming

Мнение от Stilgar » 01 юни 2014 12:15

pdimov написа:
stoiko написа:обзалагам се че добре методически дизайнатия ви обектно ориентиран фреймуърк е пълен със стейт който се манипулира от хиляда места...
Това е важен момент, който не знам дали се разбира, така че ще се опитам да поясня.

Става въпрос за това дали UI обектите имат собствено състояние. Checkbox-ът, например, дали знае/помни дали е чекнат или не. Edit контролът - дали помни какъв текст има в него.

Нормалният отговор на този въпрос е "да", което означава дублиране на едно и също състояние на две места, които трябва да се синхронизират. Например, ако имаме checkbox "[x] Enable evil spirits", това съответства на bool g_enableEvilSpirits; в кода, и двете променливи трябва да се поддържат еднакви.

Или, като код,

Код: Избери всички

class ui_checkbox: public ui_mouse_handler, public ui_drag_handler
{
private:

  bool checked_;

public:

  // ...
};
Клика си потребителят по това чудо, и то си щрака checked_, а външният код трябва съответно да го извади и да го сложи в g_enableEvilSpirits, някак си и някога.

Аз лично съм се отървал от състоянието в UI елементите по следния, не-immediate mode, начин:

Код: Избери всички

class ui_checkbox: public ui_mouse_handler, public ui_drag_handler
{
public:

  bool (*getcheck_)();
  void (*setcheck_)(bool);

public:

  // ...
};
(Илюстративно, иначе трябва да има и void* context и прочее, но и така е ясно.)

Т.е. лицето ui_checkbox не пази състояние, а пита кода "бе аз сега чекнат ли съм?" или му казва "я ме чекни, че не се издържа". getcheck_ и setcheck_ съответно за нашия пример ще връщат и сетват g_enableEvilSpirits.

При ползване на immediate mode GUI се избягват тези callbacks, които са, да си призная, голяма досада. Там просто викаш функция ui_checkbox, на която и се подава старото състояние и тя връща новото. Човек като има нещо готово обаче не му се пренаписва. :-)

Но принципно премахването на състоянието е напълно възможно и ако имаме класове, които дори наследяват разни неща, четат се от XML и прочее.

Не че това има нещо общо със статията, но предположих, че може да е интересно за някого.
В маститите enterprise object orientated GUI frameworks with XML това е известно още като data binding.

А по темата аз изобщо не виждам как тоя подход на "компресирането" е несъвместим с ООП-то и въобще досега май само един път съм писал код от UML диаграми и то май беше нещо за пред клиента, накрая в кода не остана нищо от нарисуваното по тея диаграми.

BTW за мен една от най-големите ползи от ООП-то е една дето на теория няма нищо общо с него - discoverability. Като искам да направя нещо с някой обект натискам точката и магически ми се появяват неговите методи. В C# extension методите дават подобен experience за функции (статични методи), но със C++ функции не мога да си представя как го правите.

pdimov
gosu
gosu
Мнения: 871
Регистриран: 02 дек 2003 01:04

Re: Compression Oriented Programming

Мнение от pdimov » 01 юни 2014 13:20

stoiko написа:съгласен съм че с много старание и труд може да пишеш "функционално" с класове, но това не е ли в противоречие със самата идея за "обект" т.е. съединяването на данните с кода който ги манипулира?
Те пак си имат данни - позиция, размери, цвят, логическа групираност, и прочее. Неща, които не влияят на логиката на програмата и могат да се дадат на някой да ги рисува в tool, който вади XML.

pdimov
gosu
gosu
Мнения: 871
Регистриран: 02 дек 2003 01:04

Re: Compression Oriented Programming

Мнение от pdimov » 01 юни 2014 13:33

gemicha написа:Ако си работиш сам в къщи можеш да правиш каквото решиш. Но, дори и тогава, ако след всяка промяна трябва да разглеждаш кода, който работи, и да го "компресираш" за да бъде "по-добър" това няма да доведе до нищо добро. Резултатът е ниска ефективност, трудна и бавна промяна на продукта и съвсем сигурно забавяне с месеци.
Абсолютно погрешно. Явно говорим за тотално различни неща. Тук става дума за YAGNI. За наблюдението, че предварителното правене на "reusable" компоненти води до това, че 85% от тях не се reuse-ват изобщо, а останалите 15% в момента, в който дойде време за reuse, се оказва, че имат не тези методи, които са необходими, а някакви други.

Това е елементарно отражение на факта, че дори и най-добрите програмисти не могат да предвидят бъдещето с достатъчна точност.

Поради това вярната методология за разработка, тази, която води до по-малко изгубено време, е да се отложи проектирането на компоненти до момента, в който две или три места в кода показват нагледно необходимостта от компонент, който да елиминира повторението. Хубавото на тази методология (наблягам на думата методология, понеже ти е любима) е, че при наличието на конкретен код, който прави конкретни неща, е вече лесно да се прецени компонентът какви данни включва и какви методи за тяхната обработка трябва да предлага, вместо да гледаме тавана и да си ги смучем от пръстите.
gemicha написа:Последното ме навежда на мисълта да напише нещо за сравнението между Лисков и Кейси. Кейси е кодер. Според мен не особено добър. В района тук има поне стотина хиляди като него. Лисков е личност, която е променила софтуерната индустрия към по-добро. Такива са единици. Четете повече Лисков и по-малко Кейси и ще можете дълго да си работите от в къщи или в малки компании.
Какво общо има Лисков в случая? Къде виждаш изобщо връзката?

Потребителски аватар
stoiko
Power User
Power User
Мнения: 617
Регистриран: 04 дек 2003 15:44
Контакти:

Re: Compression Oriented Programming

Мнение от stoiko » 01 юни 2014 20:14

pdimov написа:За наблюдението, че предварителното правене на "reusable" компоненти води до това, че 85% от тях не се reuse-ват изобщо, а останалите 15% в момента, в който дойде време за reuse, се оказва, че имат не тези методи, които са необходими, а някакви други.

Това е елементарно отражение на факта, че дори и най-добрите програмисти не могат да предвидят бъдещето с достатъчна точност.

Поради това вярната методология за разработка, тази, която води до по-малко изгубено време, е да се отложи проектирането на компоненти до момента, в който две или три места в кода показват нагледно необходимостта от компонент, който да елиминира повторението. Хубавото на тази методология (наблягам на думата методология, понеже ти е любима) е, че при наличието на конкретен код, който прави конкретни неща, е вече лесно да се прецени компонентът какви данни включва и какви методи за тяхната обработка трябва да предлага, вместо да гледаме тавана и да си ги смучем от пръстите.
+1

gemicha
Site Admin
Site Admin
Мнения: 2930
Регистриран: 20 ное 2003 22:20
Местоположение: USA

Re: Compression Oriented Programming

Мнение от gemicha » 01 юни 2014 20:30

pdimov написа:Поради това вярната методология за разработка, тази, която води до по-малко изгубено време, е да се отложи проектирането на компоненти до момента, в който две или три места в кода показват нагледно необходимостта от компонент, който да елиминира повторението. Хубавото на тази методология (наблягам на думата методология, понеже ти е любима) е, че при наличието на конкретен код, който прави конкретни неща, е вече лесно да се прецени компонентът какви данни включва и какви методи за тяхната обработка трябва да предлага, вместо да гледаме тавана и да си ги смучем от пръстите.
Добре. Виждаш, че има две места, които има подобен код. Правиш от тях компонент. Идва трето място на което искаш да използваш компонента. Малко обаче не достига. Променяш компонента и разбира се трябва да се върнеш назад за да си сигурен, че не си счупил неща на първите две места. После идва четвърто място. И пак малко не достига. Променяш компонента и се връщаш да погледнеш дали нещо не си счупил на предните три места. Това ли е по-добрия начин? С какво точно е по-добър? Или грешно съм те разбрал? Ако наистина това си имал в предвид... успех с подобна стратегия за писане на голям продукт. Може да се пишат блогпостове за да се "учат" начинаещите, но до там.

По-правилния начин, според мен, е ... сядаш и мислиш.... смучеш от опита си в последните X години и пишеш компонент. Даваш възможност компонента да се разширява, но не и да се променя. ("Open Close Principle") Продължаваш напред и не пипаш това, което работи. Ако в 85% не се ползва значи си си загубил времето. Лошо няма. Ако се ползва, но методите, които ти трябват ги няма това не е хубаво, но не е причина да се връщаш назад защото има начин да ги добавиш *без да променяш кода, който работи*. Другия път ще напишеш по-добър компонент.

pdimov
gosu
gosu
Мнения: 871
Регистриран: 02 дек 2003 01:04

Re: Compression Oriented Programming

Мнение от pdimov » 01 юни 2014 21:59

gemicha написа:Добре. Виждаш, че има две места, които има подобен код. Правиш от тях компонент. Идва трето място на което искаш да използваш компонента. Малко обаче не достига. Променяш компонента и разбира се трябва да се върнеш назад за да си сигурен, че не си счупил неща на първите две места. После идва четвърто място. И пак малко не достига. Променяш компонента и се връщаш да погледнеш дали нещо не си счупил на предните три места. Това ли е по-добрия начин? С какво точно е по-добър? Или грешно съм те разбрал? Ако наистина това си имал в предвид... успех с подобна стратегия за писане на голям продукт. Може да се пишат блогпостове за да се "учат" начинаещите, но до там.

По-правилния начин, според мен, е ... сядаш и мислиш.... смучеш от опита си в последните X години и пишеш компонент. Даваш възможност компонента да се разширява, но не и да се променя. ("Open Close Principle") Продължаваш напред и не пипаш това, което работи. Ако в 85% не се ползва значи си си загубил времето. Лошо няма. Ако се ползва, но методите, които ти трябват ги няма това не е хубаво, но не е причина да се връщаш назад защото има начин да ги добавиш *без да променяш кода, който работи*. Другия път ще напишеш по-добър компонент.
Така. Отбелязваме прогрес. Признахме, че за методология номер две трябват първо X години опит, за да можеш да предвидиш бъдещето с достатъчно голяма точност. Бъдещето, в което ще имаш едно и също нещо на четири, пет, осем места. И не само можеш да предвидиш броя на местата, но и приблизително какво ще ти трябва на тези места.

Реално, разбира се, вярната стратегия винаги е смес от номер едно и номер две. Ако имаш достатъчно опит и си достатъчно добър пророк, повечко две. Ако не - по-добре повечко едно, тъй като иначе получаваш най-лошото от двете - хем губиш време за писане в началото на някакъв компонент, хем после го преправяш седем пъти така или иначе, понеже нищо от написаното не върши работа.

Но колкото и добър да си по номер две, няма как да не е печалба да отложиш компонента до първото дублиране, след което да го направиш перфектен за следващите повторения (понеже си that good).

Освен... ако работи една кола програмисти, които могат в паралел да разработят един framework reusable компоненти, при което загубеното време се дели на бройката им и вече не тежи толкова. Губенето на време се паралелизира перфектно.

gemicha
Site Admin
Site Admin
Мнения: 2930
Регистриран: 20 ное 2003 22:20
Местоположение: USA

Re: Compression Oriented Programming

Мнение от gemicha » 01 юни 2014 22:55

Никога не съм бил почитател на "първо пишем, после мислим". Не го препоръчвам най-вече на тези, които имат малко X в "X години опит". Колкото повече пишеш преди да мислиш, толкова по-трудно става. Това е вярно и за малки проекти, но там е по-евтино да се правят промените.

Проектите, по които работят много хора имат друга динамика. Там има още повече мислене защото веднъж като напишеш нещо поравянето е много скъпо.

Това, което съм виждал да работи добре е: Пиши на лист хартия и мисли, скицирай, чертай, мисли и планирай. Въпроса е как всеки един ред, който си написал да се променя само ако има дефект. Това е възможно и води до добри резултати. Колкото по-често го правиш толкова по-добър ставаш.

pdimov
gosu
gosu
Мнения: 871
Регистриран: 02 дек 2003 01:04

Re: Compression Oriented Programming

Мнение от pdimov » 02 юни 2014 00:08

Напълно съм съгласен с това, че трябва да се мисли, преди да се пише. Трябва обаче да се отчитат ограниченията на мисленето, и по-точно това, че никой не е достатъчно умен и съсредоточен за достатъчно дълъг период от време, за да измисли целия софтуер преди да напише и един ред. Затова се балансира между мисленето и писането. Чистото мислене, при което измисляш целия проект като обекти, е нещо като чисто теоретична наука, при която не се провеждат никакви експерименти. И в двата случая не знаеш дали вървиш във вярна посока, докато не дадеш контакт с реалността някъде.

Ти може да предпочиташ да проектираш на ниво обекти; няма проблем. Но не е правилно да отричаш другия подход. Той дава реални и практически резултати, особено при хора с малък брой години опит, към които ти бяха насочени препоръките всъщност. А ако си достатъчно опитен и добър, за да можеш и по двата начина, е вече въпрос на вкус.

А към бедния Кейси, който отнесе толкова незавидни сравнения с Барбара, е редно да си леко по-снизходителен най-малко поради факта, че той описва как влиза в чужд и непознат код и трябва да свърши еди-какво си. Няма как да върнеш времето и да почнеш да мислиш от преди летоброенето при готов вече донякъде софтуер. Бъди сигурен, че ако той види една кола обекти в съществуващия код, веднага ще мине на обектна вълна.

gemicha
Site Admin
Site Admin
Мнения: 2930
Регистриран: 20 ное 2003 22:20
Местоположение: USA

Re: Compression Oriented Programming

Мнение от gemicha » 02 юни 2014 05:18

Съгласен.

Отговори