Главное - не быть "программистом"

автор **Gudleifr** Вс Май 07, 2017 11:13 am

Как пишутся компьютерные игры? Нет, когда-то, игру сначала придумывали, а потом программировали, но те времена счастливо канули в лету. Вот пара перлов с Форума "современных игроделов":

* Т.е. "современный программист" якобы должен представить все тупо в уме, написать код, рассчитав (допустим он кодит платформер) всю геометрию уровней, размеры/скорости, противников, и весь интерактив встречающийся по ходу, ну и так же мысленно представляя расположение интерфейсов, их удобство и юзабилити полагаясь лишь на свой третий глаз? Конечно же разукрасив в коде все красивыми комментариями, чтоб представлять было удобней.
* А давайте (сарказм.- G.) в игры так же играть - поставим ведьмака на паузу, откинемся на кресле, закроем глаза и мысленно пройдем игру самым интересным для нас способом - а то современные игроки тоже обленились - все им во всех красках покажи да расскажи, за ручку проведи, в конце в попу поцелуй - совершенно не осталось места для фантазии и свободы действий.
* Большая часть проблем решается визуальными компонентами. Мне обычно хватает пару часов на создание всего этого. (Если без доп функций, типо выводов графиков, рассчетов, обработки данных и тп).

Как же происходит "программирование" сейчас?

Сначала выбирают два опорных "столпа": существующую компьютерную игру, которая "почти годится", и некоторый ее идеальный вариант ("такой же, но с перламутровыми пуговицами"). Затем начинается процесс "совместной разборки" обоих программ - углубления в их внутреннее устройство. Разборка длится до тех пор, пока не становится возможным, на основе понятых частей старой игры, с добавлением осмысленных модулей новых, собрать нечто работающее.
Иногда это просто, например, выясняется, что старая игра имеет встроенный редактор, возможности которого вполне обеспечат внедрение "инноваций". Или файлы ресурсов (контента) вполне могут быть быть хакнуты без правки программного кода. Но, иногда, при разборке от старой игры остается только "пшик". Или идея новой игры признается несостоятельной.

Метод "поиска наибольшего общего делителя" двух игр сам по себе ни хорош и не плох. Но есть подводные камни.

1. Необходим "третий столп" - какой-то набор знаний, позволяющий провести разборку. К сожалению, обычного для "современных игроделов" знания одного-двух языков программирования и лженауки - геймдизайна, совершенно недостаточно. Единственное, что они обычно могут, создать плохую копию старой игры "на своей элементной базе", часто, без понимания принципов игры. "Берем картину мироздания и тупо смотрим, что к чему..." - вот девиз настоящего программиста в процессе "совместной разборки". Тут важнее не приготовленный заранее багаж, но готовность учиться... Как говорил Гельвеций: "Знание некоторых принципов легко возмещает незнание некоторых фактов".

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

автор **Gudleifr** Пн Май 08, 2017 11:35 am

Замкнутый круг геймдева.
1. Конечно, если есть идея собственно компьютерной игры, то ее можно быстренько реализовать на каком-нибудь BASIC, строк этак в двадцать. Подобавлять туда фич, пока размер не вырастет до нескольких сотен строк - и забыть/выкинуть. Но такие игры уже никого не интересуют, нужен гигабайтный контент.
2. Управление гигабайтным контентом само по себе целая наука, и процесс коллективного творчества.
3. Это коллективное творчество быстро становится работой, не оставляющей возможности поиграть. Требуются конструкторы, позволяющие написать что-то веселое строк в двадцать... Далее см. 1.
***

Более того, с каждым витком этого круга мы все дальше уходим от реальной жизни:

Вот, например, на КВН в 2007 году радостно ржут над тем, как был бы поражен Билл Гейтс, увидев убогую советскую игру "Ну, погоди!" 1984 года.

А, вот герой фильма "К-9" 1989 года играет в подобную игру (Manhole) и почему-то не кажется ни убогим, ни отсталым:

Главное - не быть "программистом" K-9

Как будто было бы стильнее, если бы Белуши водил раскоряченными пальцами по разноперомы планшету современного планшета...

1. Допустим, есть работяга, целый день проводящий "в поле", который вечером хочет расслабиться.
2. Есть программист, умеющий заставить компьютер играть и расслаблять, который хочет помочь работяге.
3. Есть игрок, которому эти расслабление за компьютером интереснее работы.
4. Есть бизнесмен, который видит потенциальные возможности рынка игроков.
5. Есть игродел, который хочет втюхать бизнесмену свой продукт.

И кто-то хочет воспринимать копошение #5 всерьез? А кушать что будем?

автор **Gudleifr** Чт Июн 08, 2017 11:19 am

К чему это приводит?

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

1. Мне плевать, кто и что написал до меня. Я пишу потому, что не могу не писать.
2. Я свободно ориентируюсь в том, что написали другие. И заведомо смогу не хуже. Почему бы не урвать свой кусочек славы, денег...
3. Я перерыл многое из написанного другими, но так и нашел того, что заставило "душу развернуться, а потом опять свернуться". И мне не важно, я напишу подобное или кто другой, главное, я хочу в это играть.
4. Другими написано много дельного и много ерунды. Я даже не хочу в это вникать. Но обсуждение этой вот конкретной темы (или рождение нового проекта) слишком похоже на игру само по себе и я хочу в нее поиграть.

И остался только п.2b - "Только бабки! Утром деньги - вечером стулья!"?

автор **Gudleifr** Чт Июл 13, 2017 9:00 pm

Есть игры - иллюстрации каких-то идей (сначала они одни и были). Брали какую-либо игру и добавляли к ней компьютер для оживляжа. Или, наоборот, находили игровое решение какой-то реальной боевой задачи. Это игры для программистов.

Но, одни решения оказались более удобными для переноса на машину, чем другие. Более того, эти удобные решения часто оказывались настолько частными, что в них изначальная мат.модель и угадывается-то с трудом. Так появились игры для нормальных людей.

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

Быдло - массовый потребитель. Креатитвный класс.
Форумный планктон - посетители, считающие, что с Форумом они "весят" больше, чем без Форума.
Мультимедиа продукт - то, что называет игрой быдло. Спам-атака на примитивные чувства игрока. Настоящая игра - там "на донышке".
Компьютерная игра - обычная игра, к которой прицепили компьютер.
Хорошая КИ - КИ, в которой компьютер делает то, чего нельзя достичь без него.
Плохая КИ - КИ, в которой компьютер делает то, что возможно и без него (картинки, музыка, виртуальная реальность, симулятор жизни...).
Старая игра, настоящая игра - игра, написанная для себя.
Составные части игры - идея, реализация и общественное мнение.
Быдлоигра - игра, в которой главное - общественное мнение. Создавались путем компиляции "опробованных" методов: WS3D, DuneII, PG, SP, H M&M, X-Com...
Геймплей - бессмысленная характеристика мультимедийного продукта.
Свобода - то, от чего отказывается игрок, садясь за КИ.
Реализм КИ - адекватность игровых переживаний реальным.
Искусство КИ - профанация.
Полное 3D - замена красивых картинок безвкусными моделями.
Смайлик - признак неуверенности в своей позиции.
Сделано нейросетью - подделка.
IT-специалист - инфоцыган.

автор **Gudleifr** Чт Июл 13, 2017 9:02 pm

Я знаю два способа играть интересно и бесплатно:

1. По-минимуму
Играете в своем дворе, классе, студ.группе, лаборатории, офисе. Сами придумываете, сами изготовляете необходимые настольные, спортивные, компьютерные принадлежности. Развиваете игру в игре. Надоедает - выбрасываете и придумываете новую игру. Со двора не выносите. По старости - описываете в мемуарах. См. "Кондуит и Швамбрания".

2. По максимуму.
Устраиваетесь на хорошую работу. Любите ее. Находите в ней игровые моменты и развиваете. Дорастаете до должности, когда вам платят за вашу игру, точнее за ее полезный побочный эффект. Ср. "Наука - есть удовлетворение своего любопытства за государственный счет".

автор **Gudleifr** Вс Сен 03, 2017 11:08 am

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

Итак, суперхардкор. Нужно осилить, писаясь и плача, всего две книжки:

1. В.М.Брябрин, Программное обеспечение персональных ЭВМ, 1988 - Главное - не быть "программистом" Leaf10

DJVU, 2.75Мб Главное - не быть "программистом" Leaf10

.
Конечно, в те годы книжка писалась, как введение для пользователей (и даже тогда проигрывала в этом качестве печально известной книге Фигурнова), но где те пользователи? Где те компьютеры? За исключением некоторых вещей, которые можно кое-как сэмулировать на современном компьютере, все придется принимать на веру и практически абстрактно. Однако... Со смысловой точки зрения все осталось по-прежнему. Если тогда операционная система кое-как была способна на какую-то фичу, то, в большинстве случаев, "дальнейшее развитие" свелось к тому, чтобы доказать "сообществу", что красивое графическое оформление этой фичи целиком компенсирует неспособность сделать ее более удобной/разумной.
Так что, просто просмотреть эту книжку: мол, это так устарело, что и читать не буду, а то - очевидно тоже самое, что я уже понял,- ни в коем случае нельзя. Нужно тщательно пересчитывать функции и представлять насколько они покрывают область запросов пользователя. Что пользователь должен был делать сам, а что тогда мог компьютер.
Чтобы было легче, попробуйте посмотреть какие либо фильмы тех времен, те же "Военные игры" по Бишофу или технотриллеры по книгам Крайтона. Сойдут даже "Коломбо" и "Она написала убийство".

2. Л.Бек, Введение в системное программирование, 1988 - Главное - не быть "программистом" Leaf10

PDF, 27.6Мб Главное - не быть "программистом" Leaf10

.
Тут будет полегче. Хотя, описываемые тут компьютеры тоже вымерли, но, по крайней мере, многие термины употребляются до сих пор.

Итак, осилили. Теперь Вы знаете то, что все уже забыли. Сначала, для психологической разгрузки надо хорошенько поржать (конечно, Вас уже немножко посмешило описание Windows 1.0 у Брябрина). Берем любую книгу/журнал тех времен с красочным описанием возможностей компьютеров будущего...
***

Спойлер:

***

Или, ту самую "зарубежную печать" - "В мире науки" - 11 1984 Главное - не быть "программистом" Leaf10

PDF, 37.1Мб Главное - не быть "программистом" Leaf10

или 12 1987 Главное - не быть "программистом" Leaf10

PDF, 25.7Мб Главное - не быть "программистом" Leaf10

. Приложите это к тому, что прочли в допотопных книгах - не правда ли, современная реализация этих чудес выглядит сделанной через задницу?

Что дальше? По уму, получив какую-то задачу, Вы, имея в голове примерную схему "что из чего следует", можете найти "что-то из современного", что бы заткнуть эту дыру. Например, написать и запустить что-то из книги Ч.Уэзерелл, Этюды для программистов, 1982 - Главное - не быть "программистом" Leaf10

DJVU, 9.74 Главное - не быть "программистом" Leaf10

... Но тут современные производители подложили свинью: мол, хочешь программировать - купи обезьянник, без него ты даже не найдешь в какое место свои программы запихивать... Тут проще кому-нибудь на хвост сесть... и убедиться, что ваши тайные знания основ программирования никому не нужны... Или..?

P.S. Но, зато, в хорошей компании - Главное - не быть "программистом" Leaf10

DJVU, 9.41Мб Главное - не быть "программистом" Leaf10

(Лекции лауреатов премии Тьюрига).

Я попытался кое-как упорядочить - Главное - не быть "программистом" Leaf10

ФОРУМ #18

. Но это только для тех, кто действительно хочет узнать, как работает ЭВМ...

автор **Gudleifr** Вс Сен 03, 2017 11:41 am

А ЧТО, ВООБЩЕ, ДОЛЖЕН ЗНАТЬ ПРОГРАММИСТ?

ГЛАВА ПЕРВАЯ. ОСНОВНЫЕ ПОНЯТИЯ
Аксиома 1: Программистов не бывает. Есть только системщики и пользователи. Системщики бывают математиками или электронщиками, а пользователи - физиками или лириками.
Следствие 11: Программирование - есть создание кибернетических машин, максимум энтропии которых соответствует останову при получении правильного результата.
Следствие 12: Машина понимает только действия и значения. Любые абстракции - функции, объекты, компоненты, системы, языки - это лишь многоуровневые системы имен (обозначающих некоторые наборы действий, значений и других имен), удобных для решения некоторых конкретных задач.
Следствие 13: Если запись решения на языке программирования оказывается более путаной и длинной, чем на человеческом языке, значит, программист не владеет нужным языком программирования.
Следствие 14: Тестирование программы не может доказать отсутствия в ней ошибок.
Следствие 15: Сложность программы определяется только ее размером.

ГЛАВА ВТОРАЯ. КУРСЫ
Аксиома 2: Нельзя научить решать задачи, но можно научиться решать задачи.
Следствие 21: В обучении программированию наглядность курсов обратно пропорциональна полезности. Ибо программирование - умение абстрагироваться от наглядности.
Следствие 22: Знания/умения программиста никак не могут иметь ценности за пределами конкретной задачи.
Следствие 23: Сначала научись что-то делать и только потом учись это программировать.

ГЛАВА ТРЕТЬЯ. ЗАДАЧИ
Аксиома 3: Человек решает задачу. Человек программирует решение для машины. Человек знает необходимые детали устройства машины. Эти три умения программиста между собой никак не связаны.
Следствие 31: Любое решение программистской задачи можно записать языком математики. Т.к. машина является материальным представлением языка математики, то существует способ перевода решения задачи на язык машины. Этот способ называется языком программирования.
Следствие 32: Языки программирования в равной степени могут созданы теоретиками, практикам или самим программистом.
Следствие 33: Если результат можно рассчитать, это хорошо, если нет - нужно использовать таблицы. Только, если и это невозможно, можно применять сложные структуры управления языка программирования.
Следствие 34: Язык программирования выбирается/изобретается таким, чтобы как можно больше результатов рассчитать.

ГЛАВА ЧЕТВЕРТАЯ. САМОДЕЛКИ
Аксиома 4: Мы живем в Матрице, которую называем культурой.
Следствие 41: Машина должна исполнять не ту работу, которую легко запрограммировать, но ту, которую человеку исполнять сложно или неинтересно.
Следствие 42: Легкость программирования определяется не интеллектуальностью машины, но ее простотой.
Следствие 43: Машины/языки развиваются в двух направлениях: "понимают, что вам надо" - интерпретаторы, и "знают лучше вас, что вам надо" - компиляторы. И это развитие далеко опережает реальные потребности программиста.
Следствие 44: Простейший способ написать что-то сложное - переложить работу на пользователя.
Следствие 45: Объединять простые модули в сложную программу удобнее всего средствами операционной системы. Не стоит это делать вручную (изобретать для этого сложные языки).

ГЛАВА ПЯТАЯ. ПРОЕКТЫ
Аксиома 5: Очень небольшой процент рабочего времени программист тратит на написание программ. Гораздо больше уходит на то, чтобы заставить их работать. Первое приятно и престижно, второе - нет.
Следствие 51: Ни один программист не любит сложных программ. Пропадает даже та маленькая толика удовольствия, которая ему положена.
Следствие 52: Еще эфемернее предстает возможность научиться программировать на большом проекте. Неразрешимые проблемы встретятся раньше, чем появятся первые результаты.
Следствие 53: Единственный способ написания хорошей программы - полное выбрасывание исходников, как только они перестают нравиться.

автор **Gudleifr** Вс Сен 03, 2017 11:49 am

БЫДЛОКОДЕРСТВО КАК НЕПОНИМАНИЕ ДУАЛИЗМА

Есть, например, юниты, у каждого - набор свойств и навыков (а-ля Герои - Минотавр имеет "Храбрость", лазутчик - "Отравленный выстрел")
Возникает, скажем, такая ситуация: лучник стреляет в пехотинца, применяя скилл "Стрельба". Пехотинец имеет навык "Щит", поэтому урон снижен. Однако лучник не простой, он имеет также способность "огненная стрела", поэтому пехотинец загорается. Но будь у пехотинца свойство "Несгораемость", не подгорел бы.
Все юниты, эффекты, навыки - отдельные объекты, с набором методов и, тем более, их реализацией, я не могу определиться.
Как бы вы стали организовывать подобное взаимодействие? Т.е. срабатывание (применение) одного скилла может активировать другой и так далее. Где какой код писать (идейно)?

Интересно, много ли осталось людей, понимающих, что если бы на этот вопрос существовал ответ в форме, ожидаемой спрашивающим, т.е. "тупо создайте темплейт объекта типа <дурацкий факт> и тупо используйте его метод <логическое осмысление>", то программирование не было бы искусством?

В чем же в данном случае это искусство заключается?
Налицо наличие некоторого набора фактов/правил на основании которых нужно произвести некоторые выводы/действия. Программированием чего программист и занимается всю свою сознательную жизнь.

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

Это знают все. Особенно изобретатели всяких там языков "логического", "автоматного" и прочего "хитрого программирования". Но подавляющее большинство почему-то забыло, что ВСЕ языки программирования, даже какой-нибудь ALGOL-60, УЖЕ являются машинами для подобных рассуждений. Наличествующие в той или иной мере в каждом языке механизм данных и процедур уже готовы к решению "рассуждательной проблемы". Механизм данных обеспечивает накопление фактов (прямая цепочка), механизм процедур - их запрашивает и использует (обратная цепочка). Все остальное, что есть в языке - способ как-то ограничить "область перебора", т.е. разбить и факты, и действия на изолированные группы, в которых и осуществлять логические вычисления. Т.е. не проверять все условия боя на мечах при расчете космических перелетов, и не проверять, как влияет бузина в огороде на поведение дядьки в Киеве.

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

Существуют ли системы, при изобретении которых программист вынужден все-таки, однозначно определить, каким способом он будет рассуждать? Этот вопрос целиком относится к вопросу ограничений машины, для которой пишется программа. Противопоставление машины с хранимой программой (изменяющей свой код при получении новых фактов) машине с произвольным доступом к памяти (способной гибко запрашивать данные). Или, даже, противопоставление ОС, основанных на процессах (ожидающих готовности данных), ОС, основанным на сообщениях (где данные вызывают действия). Применение одного из методов в этих случаях диктуется железом. Но! Для программиста отличие одной машины/ОС от другой совершенно ничего не определяют! Эквивалентность этих машин/ОС многократно проверена и местами строго доказана! Так, что привязывая свою логику к WIN-объектам и/или пытаясь описать в XML-файлах все сущее, быдлокодер, по сути, отказывается от решения программистской задачи, пытаясь тупо приспособить вчерашнее решение к сегодняшней задаче.

автор **Gudleifr** Пт Дек 27, 2019 7:28 pm

Опаньки! Даже для "современных программистов" начало доходить, что они никому не нужны.

ТЕХНИКА - МОЛОДЕЖИ 14/2019
ПРОГРАММИСТЫ СТАНУТ НЕ НУЖНЫ?
(Автор не указан. Видимо, с какой-то социалки).

Хорошо быть программистом - индустрия цветет и развивается, спрос на кодеров увеличивается, зарплаты растут. Но как долго это будет продолжаться?

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

В середине XIXв. телеграфным операторам хорошо платили, их уважали и считали достаточно подкованными технически. По мере прокладки все большего количества проводов спрос на операторов быстро рос. Разрабатывались стандарты для ускорения передачи сообщений, и операторам приходилось подстраиваться, запоминать все более сложные и эффективные системы сокращений и протоколов.

Но к ХХв. был изобретен телефон, не требовавший участия человека для преобразования кода в естественный язык. И к 1920-м годам от большого числа операторов осталась лишь малая часть.

Перенесемся на сотню лет вперед - и мы окажемся в схожей ситуации, только уже с программистами. Конечно, эта профессия требует больше навыков и интеллектуальных возможностей, чем у телеграфного оператора. Но программисты сегодня занимают функционально схожую с операторами нишу. Взрывное распространение софта похоже на распространение ранних видов коммуникаций XIXв. Тогда спрос на операторов рос пропорционально росту сетей, и ныне спрос на программистов растет пропорционально росту ПО. Раньше все телеграммы необходимо было транслировать с азбуки Морзе в человеческий язык, и сегодня весь программный код должен быть написан человеком.

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

Но все это изменится.

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

Ясно, что в будущем сохранится нужда в программистах - специалистах узкого профиля и других людях, разбирающихся в компьютерах, но кажется неизбежным, что программирование на подходе к XXII столетию постепенно исчезнет как массовая профессия.

автор **Gudleifr** Пт Ноя 01, 2024 12:34 am

"Товарищи ученые, доценты с кандидатами..."
/Владимир Высоцкий/

В последние годы (2024г.) слишком много говорят об импортозамещении. Даже в программировании. Мол, давайте произведем русский процессор, перепишем Linux на русском, Си-компилятор - на русском, все остальное - на русском. Причем, с нуля и с самораскруткой. Пользуясь русскими программами, русский программист развернется во всю ширь и вытеснит пиндосовские программы из виртуального русского мира.
***

Расскажу вам сказку о картошке.

Как сажает картошку, условно, белорус? Берет и сажает. Нужен ли для этого компьютер? Конечно. В какой день лучше это сделать, каким квадратно-гнездовым методом, сколько удобрений? Наверняка существуют оптимальные цифры для этого места и этого сезона. Очевидно их расчет имеет два крайних варианта: позвонить в сель.хоз.академию или поискать в своих-дедовских старых записях. Промежуточное решение - что-то спросить, что-то посмотреть, что-то посчитать... Т.е. белорус-программист: во-первых, должен оценить, какое решение удобнее (а кроме самого крестьянина это никто не скажет), во-вторых, произвести конкретные действия, припомнив кучу способов решения аналогичных проблем. Может ли это сделать сам крестьянин? Сможет, если способы решения хорошо отсортированы и документированы, а он имеет среднее советское образование. В конце концов, когда картошку будут сажать уже его внуки, он вполне сможет написать книжку по своему картофельно-программистскому опыту.

Как сажает картошку пиндос? За него это делают мексиканец, канадец и белорус. Заинтересован ли программист США в решении их проблем? Нет. Он заинтересован в том, чтобы они ни в коем случае не купили программы ни у кого, кроме него. Пусть его программы ничего не решают, но они настолько распиарены и сложно устроены, что ни у кого и в мыслях нет написать что-то свое.

Наконец, как сажает картошку русский? Никак. Он идет в магазин и покупает ее у перекупщиков-иностранцев. Его кормят сказками о диких мексиканцах и белорусах, и ставят в пример умных пиндосов, у которых на грядках вместо картошки сразу доллары растут. И наш инфоцыган кричит: я могу писать не хуже американцев! Я могу по-русски! Я вытесню пиндосов из их бизнеса! Я обыграю их по их же правилам!.. А ничего-то он и не может... Картошка сама не родится...
***

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

Главное - не быть "программистом"

Главное - не быть "программистом"

Re: Главное - не быть "программистом"

Re: Главное - не быть "программистом"

Re: Главное - не быть "программистом"

Re: Главное - не быть "программистом"

Re: Главное - не быть "программистом"

Re: Главное - не быть "программистом"

Re: Главное - не быть "программистом"

Re: Главное - не быть "программистом"

Re: Главное - не быть "программистом"