Ньюфаг-программист

Благодарю.

Какая специальность в университете будет?

Прату не очень хвалят

https://accu.org/index.php?module=bookreviews&func=search&rid=1744

KrasnoGlazik: https://stackoverflow.com/questions/388242/the-definitive-c-book-guide-and-list (книжки по C++)

что ты хочешь написать или что тебе нужно? может это уже есть? или ты кино какое посмотрел где у программистов много денег и бабы дают. ещё не поздно посмотреть какое-нибудь другое.

потому что это совет из разряда ответа на вопрос: как построить дом? - ну, начни пилить брёвна

Программная инженерия

Мои мотивы в данном топике не обсуждаются. По факту есть что-нибудь?

Тогда SICP, как уже выше советовали (книжка в хорошем качестве: https://github.com/sarabander/sicp или https://github.com/sarabander/sicp-pdf), и алгоритмы (вместо Кнута можно взять CLRS). Но это всё непросто для первокурсника, возможно.

И ещё: https://habr.com/post/282986/ (хозяйке на заметку).

Есть ещё лекции с МФТИ от Тимофея Хирьянова

https://www.youtube.com/user/tkhirianov/playlists

все допиливают под себя, но ни с кем не делятся, потому что gpl, а они ценят свой труд

Что-то в тегах каша.

Дважды подумай, страсть к крестам свойственна неофитам и фанатикам. Остальные пишут на крестах только из-за зп\задач.

Не на голых сях же писать игори и кроссплатформенные ООП программы с GUI. А других технологий как-то не завезли, C# в Linux-е никакой и никому не нужен, JAVA везде монструозная для графики, C и ООП это трагикомедия, паскаль — на нем кто-то пишет? Rust, Go, Haskell и прочее это экзотика и не для этих задач немного. Питон хорош, пока скорость совсем не критична. Вот и живут кресты вместе с культями. Был бы хороший язык и инфраструктура, умерло бы всё это дело, но его нет и не будет, т.к. если ЯП ещё можно сделать относительно малой кровью, то нативные библиотеки для ЯП кто писать будет?

Не на голых сях же писать игори

почему бы и нет, если не из-за зп?

программы с GUI

а их и не надо писать не из-за зп, макаки корпораций сделают, им проще - их много и у них есть денежная мотивация

Пусть тогда пишет гуй на html, css, js, qml и прочем, как сейчас принято. Какие к чёрту кресты? Это убогое легаси. Кроме того гуй софту постольку поскольку, сам код вполне может быть и на си (и он будет даже эффективней зачастую, чем когда у тебя кути с высокоуровневыми фреймворками во все поля).

Зачем ему ООП? Гуй должен быть отдельно от приложения.

//эту капчу придумали содомиты.

эту капчу придумали содомиты

её придумали, чтобы лишить нас ботов голоса, но они просчитались

Далее мне бы понадобилось несколько учебников для начала.

что ты уже прочитал кроме букваря?

почему бы и нет, если не из-за зп?

Потому что писать игори без ООП очень грустно.

а их и не надо писать не из-за зп, макаки корпораций сделают, им проще - их много и у них есть денежная мотивация

Вообще ничего делать не надо. Прямо как про Двое из ларца.

Потому что писать игори без ООП очень грустно.

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

своим появлением

Из технического, относящегося к it - лишь устаревшее пособие по Линукс. Или вас художественная литература тоже интересует?

Вообще ничего делать не надо. Прямо как про Двое из ларца.

зачем на это тратить свою короткую жизнь? и зачем нам тогда вообще капитализм, если не использовать его преимущества?

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

структурное программирование

систематическое программирование

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

При чем тут это? Любые объекты труднее описывать функциональщиной.

ещё можешь до школы глянуть «знакомьтесь компьютер» и «язык компьютера» под редакцией Курочкина и не смотри что год издания 1989

до универа, в смысле

то есть ты признаешь что этап развития сменился этапом облегчения? ну и полигональным дрочиловом, само собой

Давно уже ничего принципиально нового не завозят. Разве что мощность видях растет и всякие вулканы появляются.

При чем тут это? Любые объекты труднее описывать функциональщиной.

А чего именно не хватает в функциональщине, кроме наследования реализации? Вроде бы все остальное есть в том же haskell: и инкапсуляция через модульную систему, и наследование классов типов (интерфейсы отдаленно похожи на классы типов), и элементы полиморфизма ad-hoc можно врубить через те же функции высшего порядка, помещенные в записи, что не отличишь потом от галимого ООП. Про rust примерно то же самое, потому что эту часть скопировали в rust из haskell.

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

Так чего именно не хватает функциональщине для создания игр?

Кстати, на rust уже стали писать игры, а там та же самая модель вместо ООП как и в haskell, о чем я упомянул выше.

Паскалю/Лазарусу

Можно глянуть там:
http://www.freepascal.ru/article/books/
http://www.cyberforum.ru/lazarus/thread454346.html

А чего именно не хватает в функциональщине, кроме наследования реализации?

Простоты. Если совсем утрировать в теории, то создал ты некоторый объект, скажем car, который где-то в своих недрах скрывает геометрию, текстуры (ты их даже не видишь, они тебе не нужны на верхнем уровне абстракции, чтобы, скажем, гонять разные машинки по дороге), методы для перемещения и т.д.. В результате если у тебя нет скриптового движка (по идее его и писать будет проще) который гоняет все машинки по дороге, то ты легко можешь поглядеть и на структуру твоей машинки (по методам) и более-менее просто ее создать, задав какие-то параметры, вроде скорости, ускорения, 3D модельки в конструкторе. Ты не сможешь забыть о чем-то если всё грамотно сделано.

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

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

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

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

Конечно, я не функциональный программист и смотрю на вашу тусу несколько издалека и могу ошибаться по поводу ряда пунктов. Единственный ЯП на котором я иногда пишу в этом виде — Python, но он не совсем функциональный, а скорее с элементами.

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

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

Black box, White box, Networking, GUI? Там очень много сортов всякого. Все знать необязательно, но понятие иметь нужно.

Malik D.S. C++ Programming_ Program Design Including Data Structures (2013)
Правда на английском, но зато с цветными картинками и схемами для новичков.
Много простых понятных примеров, а не протаскивание новичка через один мега пример, в котором пока до конца дойдешь, забудешь, что было в начале.

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

Про DES в играх можешь рассказать? Вообще, на серверах распределенное моделирование там «аналитическое» (то есть, точное) или как Бог на душу положит с полным игнорированием парадокса времени?

Надоело таксовать, браток?

Иногда бывает лень угадывать, и я не отвечаю ТСу. Не особо просчитались, думаю.

Не, я игры не пишу, компьютерная графика и AI пока мое хобби, но возможно всё изменится в ближайшие пару лет. DES хорош для моделирования разных более «реальных» вещей. Проще всего рассказать как первый раз еще по учебе писал модель банка с клиентами, приходящими по разным законам, распределяющимися в очереди и обслуживающимися в зависимости от проблемы разное случайное время в некоторых пределах. Сама программа должна была писать какие-то параметры, вроде нахождения клиента в очереди при выбранных начальных условиях, таких как количество клиентов, распределения, количество кассиров и т.д. + отображать в какое время суток банк перегружен, а когда простой у кассиров. Вот ООП там был ни к селу ни к городу.

Интересно, а ты на питочнике стал бы использовать DES, будь там что-то похожее на GPSS?

Мне кажется, что ИИ сейчас сильно тяготеет к нейронным сетям, или к гибридным сетям. В 90-е был такой проект у сотрудников Toshiba, который назывался Enfant. Был написан на Си++. Там можно было создавать гибридную сеть из элементов перцептрона и fuzzy. Эта сеть обучалась. Если добавить сверточные сети, то ваще было бы здорово, как мне кажется.

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

Интересно, а ты на питочнике стал бы использовать DES, будь там что-то похожее на GPSS?

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