Использование языка для практических задач

Добрый день.

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

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

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

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

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

У меня есть желание например сделать текстовилку, это очень простая тема и в виде консоли я ей уже занимался, но вот какую библиотеку выбрать и тд я вообще не разбираюсь. (Если есть умные, просто направьте)

Но всё же, что делать новичку, который вроде что то знает, но ему чего то не хватает для попадания пусть даже в мизерный проект и он даже не знает чего именно.

Спасибо за внимание.

0

Если надо, могу скинуть простой пример обмена через SDL2-NET по UDP. SDL - Вот да! Кидайте пример, с удовольствием изучу материал.

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

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

Вроде даже всё конкретно, но вот почему то не могу я двинуться дальше никуда. Литературу пытался читать разного рода, но так получается, что читаю я её до тех пор пока я уже знаю тему, а потом тут же встреваю колом. Не идут книги, не знаю что с этим делать.

0

Сообщение от Peccatum Если надо, могу скинуть простой пример обмена через SDL2-NET по UDP. SDL - Вот да! Кидайте пример, с удовольствием изучу материал.

Держите. Правда, глубоко в сеть я не копал, но то что есть вроде работает.

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

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

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

Далеко не везде графика нужна. Я сейчас занимаюсь контроллерами, там и дисплея-то обычно нет, не то что полей воода. В лучшем случае семисегментный индикатор, россыпь кнопок да RS232 текстовый интерфейс. Немного преувеличил: с дисплеем от Raspberry Pi 320х240 я работал, но сути дела это не меняет.
В системном ("ядерном") программировании тоже графика больше мешает. Там рулят текстовые или вообще бинарные интерфейсы.
В расчетных задачах (численное моделирование, криптография) тоже толку от графики нет.
В сетевом взаимодействии графика нужна только клиенту, и то ее пишут на всяких php.
Даже в тех областях, где графика действительно полезна - офисные программы и игры, она делается разными способами, опять придется выбирать какое направление ближе.

Вложения

sdl-net.7z (3.35 Мб, 2 просмотров)

1

Спасибо большое. Буду копать и расширять свои знания.

0

Сообщение от Peccatum Литературу пытался читать разного рода, но так получается, что читаю я её до тех пор пока я уже знаю тему, а потом тут же встреваю колом. Не идут книги, не знаю что с этим делать.

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

1

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

0

Сообщение от COKPOWEHEU В расчетных задачах (численное моделирование, криптография) тоже толку от графики нет.

А визуализация того что насчитали тоже типа нафиг не нужна?

Добавлено через 53 секунды

Сообщение от COKPOWEHEU Даже в тех областях, где графика действительно полезна - офисные программы и игры, она делается разными способами, опять придется выбирать какое направление ближе.

CAD и обсчет моделей по наукам тоже типа ни разу графоний не юзает? Или гуй систем управления промышленным оборудованием? или гуй тех же автопилотов? Или в том же деогнастическом оборудовании? Графика нужна почти везде. Потому что восприятие графических данных для человека гораздо удобнее. Они для моска нативные в отличии от текста.

0

Сообщение от Fulcrum_013 А визуализация того что насчитали тоже типа нафиг не нужна?

Иногда нужна.
Иногда можно визаулизировать в сторонней программе вроде feedgnuplot или calc.
Иногда вовсе не нужна.

Сообщение от Fulcrum_013 CAD и обсчет моделей по наукам тоже типа ни разу графоний не юзает? Или гуй систем управления промышленным оборудованием? или гуй тех же автопилотов? Или в том же деогнастическом оборудовании? Графика нужна почти везде.

Графика нужна почти в любой программе, ориентированной на графическое взаимодействие с пользователем? Ну, с такой формулировкой глупо спорить.
Вы привели кучу одинаковых примеров использования графики для "офисного" GUI, то есть ориентированного на стандартные компоненты управления - кнопки, вкладки, поля ввода, выпадающие списки - без особых требований к скорости. Да, такой класс задач есть и для его решения написаны соответствующие библиотеки вроде QT или gtk.
Второй класс графических задач вы затронули вскользь - вывод, ориентированный на скорость. 3D-моделирование, игры, визуализация соответствующих данных. Типичные библиотеки для этих задач - OpenGL, Vulkan, DirectX. Иногда графика этого класса встраивается как "под-окно" в компонент библиотеки предыдущего случая, иногда - наоборот.
Примеры библиотек скорее не вам, Fulcrum_013, а ТСу, Peccatum, вдруг действительно захочет изучить сторону языка, связанную с GUI.
Но надо помнить, что это далеко не все задачи, решаемые программистом. И уж точно не стоит с этого начинать изучения языка.

Сообщение от Fulcrum_013 восприятие графических данных для человека гораздо удобнее. Они для моска нативные в отличии от текста.

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

0

Сообщение от COKPOWEHEU Не стоит также забывать, что CLI позволяет решать задачи куда быстрее, гибче и проще (как для программиста, так и для юзера), чем GUI.

Глюпости.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Не даром документация ведется именно в текстовом виде с добавлением графики по необходимости.

НУ еще бы. Букофки писать быстрее чем иероглифы малевать. Хотя и сами букофки тоже графика как ни крути. Только вот то что таки графика в доке используется как раз и говорит о том что речь/письменность не в состоянии передать всю полноту данных на которые способна графика.

0

Сообщение от Fulcrum_013 Хотя и сами букофки тоже графика как ни крути

Это колесико нас может далеко закатить...

0

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

Сообщение от Fulcrum_013 Глюпости.

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

Сообщение от Fulcrum_013 Хотя и сами букофки тоже графика как ни крути.

Да неужели? А если буковка - 8 бит, то она тоже графика? А если буковка - колебание воздуха? Буковка - всего лишь абстракция, ее можно представить десятком разных способов.

Сообщение от Fulcrum_013 Только вот то что таки графика в доке используется как раз и говорит о том что речь/письменность не в состоянии передать всю полноту данных на которые способна графика

Вот только ситуации, когда графика предпочтительнее достаточно редки. Обычно передача информации идет именно в текстовом виде, и причин этому несколько:
- Плотность информации: у текста на порядки выше. И это весьма существенное преимущество. Сюда же и документация, и передача по сети, и скорость восприятия
- Независимость от средства отображения: можно вывести на экран, можно зачитать, а можно передать азбукой глухо-немых, причем без малейшего искажения. Сюда же универсальность. Средства отображения текста есть везде, тогда как графики - нет. Сюда же возможность продиктовать что-то по телефону.
- Помехозащищенность. Сравните информативность сканов старых книг. Много там можно понять из картинок? А из текста?
- Простота для программиста. Ввод-вывод текста встроены в любой язык, причем сделаны предельно просто. А вот с графикой придется повозиться. Подключать различные сторонние библиотеки, вызывать сотню инициализаций с мутными параметрами, а потом призывать специалистов по эргономике чтобы подсказали как же правильно расположить одну кнопку чтобы юзеры не промахнулись. И ведь все равно не получается.
- Простота автоматизации. И это не менее существенный плюс, чем плотность. Обрабатывать текст программы умеют отлично, а значит вывод одной можно отправить на ввод другой, тем самым собрав конвейер. Сюда же сбор массивов данных и работа с ним.
.
Хватит пока.
Еще раз: речь не о том, что графика не нужна вообще нигде и никогда. Но умение писать GUI ни разу не является обязательным для программиста. Это всего лишь одна из областей, которую неплохо бы изучить.

1

Сообщение от COKPOWEHEU Обрабатывать текст программы умеют отлично, а значит вывод одной можно отправить на ввод другой,

Вот это уже крайняя глюпость. Ненужные затраты на преобразование бинарка-текст а потом текст-бинарка. Хуман ридабле машине нафиг не нужен. ей нужен машино-ориентированный бинарный интерфейс. А человеку гуй.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Простота для программиста.

Тоже сказки. С графонием все гораздо гораздо проще.

Сообщение от COKPOWEHEU Подключать различные сторонние библиотеки, вызывать сотню инициализаций с мутными параметрами,

То уже от знаний программиста зависит в плане предметов изучаемых на втором курсе.

Добавлено через 1 минуту

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

Мышкование на несколько порядкоф эффективнее. Потому что есть проверка вводимых данных на лету в отличии от хуман-ридаблов.

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Сюда же и документация, и передача по сети, и скорость восприятия

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

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Помехозащищенность. Сравните информативность сканов старых книг. Много там можно понять из картинок? А из текста?

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

Добавлено через 1 минуту

Сообщение от COKPOWEHEU Средства отображения текста есть везде, тогда как графики - нет.

Это в какой пещере вы нашли комп без графического адаптера то?

Добавлено через 3 минуты

Сообщение от COKPOWEHEU Много там можно понять из картинок?

Ну вот сравните к примеру текстовое отображение координат слябов в виде текстовой таблички и их хотя бы псевдографическую отрисовку в виде схемы стана и расположения не ней слябов. В каком виде оператор увидет сразу где что находится так чтобы понять где именно это на реальных рольгангах едет? А время его реакции в секундах (не в 10ках секунд а именно в единицах секунд) до того как будете снимать 20 тонн раскаленного металла с другого такого же 20 тонного раскаленного куска а то и ловить 100-тонный валок летящий по кускам по линии прокатки.
Схематичные и т.д. изображения гораздо информативнее и гораздо быстрее для восприятия чем текст.

Добавлено через 43 минуты

Сообщение от COKPOWEHEU Вот только ситуации, когда графика предпочтительнее достаточно редки.

https://habr.com/ru/company/microsoft/blog/457192/
Ага вы вот этим ребяткам это скажите. Вот где реальный экономический выхлоп от графония просто зашкаливает. А соответсвенно это и есть основные задачи индустрии и спецы все туда перекуплены.
А вы все социалочки пакемончики ютубы с cli. Да откуда вооще у этих нищебродов типа гугла деньги то возьмутся на то чтобы спецам платить которые графоний клепать умеют? Они все раскуплены хайтечем еще с универа и перекупить их у этим веб- и линукс - нищебродам без шансов.
Вот и задвигают сказки про типа текст это круто. На самом деле бред такой же как и росказни про эффективность GC, устаревшего к тому же концу 60-х что и cli

0

Сообщение от Fulcrum_013 Вот это уже крайняя глюпость. Ненужные затраты на преобразование бинарка-текст а потом текст-бинарка. Хуман ридабле машине нафиг не нужен. ей нужен машино-ориентированный бинарный интерфейс. А человеку гуй.

Долго же вы спали. Таким бредом и раньше мало кто занимался, а теперь и подавно.

Сообщение от Fulcrum_013 Тоже сказки. С графонием все гораздо гораздо проще.

Проще чем printf("some text");? Пример в студию!

Сообщение от Fulcrum_013 То уже от знаний программиста зависит в плане предметов изучаемых на втором курсе.

Количество параметров от знаний программиста не зависит. Оно зависит от упоротости разработчика графической библиотеки (это сейчас не рассматриваем) и сложности предметной области. А вывод графики значительно сложнее вывода текста.

Сообщение от Fulcrum_013 Мышкование на несколько порядкоф эффективнее. Потому что есть проверка вводимых данных на лету в отличии от хуман-ридаблов.

Понятно. Вы просто не пробовали. Рекомендую таки попробовать. Да хотя бы в офисном пакете нарисовать формулу: в tex, writer и word. Первые два текстовые, третий - мышевозный. Конкретный пример:

tex: 35 сек y=\lim_{x\rightarrow 0} {\frac{sin x}{x}} + \sum_{i=0}^{N} {a_i^{2 \cdot i+1}}
writer: 30 сек y=lim from {x->0} {{sin x}over x} + sum from {i=0} to {N} {a_i^{2 cdot i +1}}
word: 60 сек
Это учитывая то, что я не занимаюсь набором формул ни ни в одной из этих сред. Разница в 2 раза.

Сообщение от Fulcrum_013 Ну передайте попробуйте деталю самолеты в виде текстового описания.

Ну давайте теперь притягивать за уши примеры и объявлять их типичными.
Передайте в виде картинки, без текста, параметры транзистора КТ315.
Для вас будет откровением существование слепых людей, у которых вообще нет возможности воспринимать графическую информацию?

Сообщение от Fulcrum_013 Текст от помех защищен ничуть не лучше графония в векторном представлении.

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

Сообщение от Fulcrum_013 Это в какой пещере вы нашли комп без графического адаптера то?

А кто говорил про комп? Встраиваемые системы с настройкой по RS232 или знакосинтезирующими экранами, телефоны с черно-белым экраном (да, такие существуют!). Да даже доисторические компы под DOS'ом. Не стоит забывать и про средства удаленного доступа к современным компам - там тоже с графикой негусто (за что некоторые админы искренне благодарны: меньше телефонного трафика тратят в экстренной ситуации).

Сообщение от Fulcrum_013 А время его реакции в секундах

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

Сообщение от Fulcrum_013 Вот и задвигают сказки про типа текст это круто. На самом деле бред такой же как и росказни про эффективность GC, устаревшего к тому же концу 60-х что и cli

Текст это самый универсальный способ передачи информации, и это просто факт. Будет ли он оптимальным или бесполезным в данном конкретном случае - другой вопрос. Мы же сейчас обсуждаем не конкретные случаи (я вижу, экзотики у вас в карманах полно, так пусть там и остается) а именно необходимость бросать все и учить графические библиотеки. И вот этой необходимости для ТСа нет.
Про GC особо сказать ничего не могу, поскольку никогда им не пользовался. Но что-то мне подсказывает, что и у него, как и у графических средств автоматизации, есть область применений, где замены ему нет.

0

пришёл Fulcrum_013 и отнял тему у топикстартера, превратив в личную флудильню о вкусе фломастеров...

1

Сообщение от COKPOWEHEU Оно зависит от упоротости разработчика графической библиотеки (это сейчас не рассматриваем) и сложности предметной области. А вывод графики значительно сложнее вывода текста.

А он типа не программист? Или разработка графической либы на основе абсолютно понятного при наличии знаний API доступа к железу стало сложной задачей?

0

Сообщение от COKPOWEHEU Конкретный пример:

А теперя возьмите и попробуйте этот конкретный пример отобразить ни разу не юзая графоний.

0

Сообщение от Peccatum совершенно не могу научиться кодить программу так, что бы она могла взаимодействовать по сети.

Напишите сначала чат, а потом крестики-нолики по локальной сети. Я сам несколько лет что-то почитывал про сеть, книги, читал/смотрел туторы, делал простые примеры типа чата. Если нравятся текстовые туторы, то гуглите их, если нравится смотреть видео, то ищите в Youtube. Нравится изучать английский - ищите на нём. Если хочется в коде разбираться ищите на GitHub. Казалось бы, крестики-нолики - это одно из самых простых, что можно придумать по сети. Я нахожусь в процессе написания, всё откладываю продолжение на завтра. Из тех кто изучал или изучает сеть мало кто написал даже такую простую игру, в том числе и я.

Я бы мог вам свои наработки скинуть, но во-первых, они на C#/OpenGL/TcpSockets и на TypeScript/WebGL/WebSockets, а во вторых они очень сырые. Просто я хотел сказать по своему опыту, что нужно меньше времени тратить на ерунду, а больше на реальные проекты, например, на написание сетевых крестиков-ноликов. Я настаиваю на этой игре, потому что она проще, чем сетевые: морской бой, шашки, карточный дурак и т.д. Реальные - в том смысле, что более или менее рабочие. Наприме, чат, который можно запустить хотя бы локально. Если я вас попрошу скинуть мне исполняемый файл чата или крестиков-ноликов, у вас должна быть папка с такими exe'ешниками. Это я называю реальными проектами. Смысл в том, что в программировании изучение без практики мало что даёт, как и практика без теории.

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

0

Сообщение от Fulcrum_013 А он типа не программист? Или разработка графической либы на основе абсолютно понятного при наличии знаний API доступа к железу стало сложной задачей?

Ключевую фразу выделил. API любой библиотеки надо учить. На это тратится время и энтузиазм, которые можно потратить и на другие цели. Собственно, выбор на что и как тратить энергию - личное дело каждого.
Мне, например, не настолько интересно учить тот же QT, хотя я прекрасно осознаю что было бы полезно. Но вот насущной необходимости в этом нет. Подавляющее большинство информации можно отобразить в текстовом виде, а для того мизера, что нельзя, хватает сторонних программ вроде feedgnuplot.

Сообщение от Fulcrum_013 Конкретный пример: формула в офисном пакете А теперя возьмите и попробуйте этот конкретный пример отобразить ни разу не юзая графоний.

Напоминаю: речь шла не об отображении, а о скорости работы юзера. Был приведен конкретный пример, формула. На набор в текстовом режиме потребовалось вдвое меньше времени, чем в графическом.
А отображение математических формул из своего кода - вообще отдельная и довольно сложная задача, слабо связанная с GUI, так что вообще непонятно зачем вы ее сюда притянуть пытаетесь.
Впрочем, фанатизм он такой. Не позволяет усомниться в единственности мнения и даже попробовать альтернативу. С доказательной базой у вас тоже все печально. Одно только высказывание "GUI всегда быстрее и удобнее CLI", столь же безапелляционное, сколь нелепое, достаточно говорит.

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

Полностью поддерживаю!
Если кажется, что написать "змейку" элементарно и бесполезно - вы просто не пробовали. Мало того, что там достаточно своих особенностей, так и самостоятельно можно прикручивать новые темы и технологии.
Не говоря уж о том, что любая задача - это опыт и знания, которые пригодятся везде, причем даже не обязательно в программировании.

0

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

Ещё добавлю, что только тогда вам будет нравиться что-то изучать, если вы будете двигаться в том направлении к чему, как вы написали "тяготеет душа". То что важно для вас - решать только вам. Есть области программирование, где одно очень важно, а другое не используется вовсе. Я тоже буду писать мини игры по сети. Есть одна книга переведённая на русский. Я только немного введение прочитал, я читаю её в оригинале. Вот перевод: Многопользовательские игры. Разработка сетевых приложений. В этой книге используется для сети WinSock. Это часть WinAPI для сети. Для графики используется SDL2. Я собираюсь переводить примеры на TcpSockets (C#, .NET) и WebSockets (TypeScript). Но эта книга в основном ориентирована на плавное перемещения объектов, а не на дискретные передачи сообщений, как в крестиках-ноликах, шашках, морском бое и т.д. То есть в книге большая часть уделяется компенсациям сетевых задержек, предсказаниям на клиенте, интерполяции координат объектов на клиентах и т.д. Это всё делается, чтобы было плавное перемещение объектов, чтобы была синхронизация плавных перемещений на удалённых клиентах. Сетевые задержки могут быть от 50 мс до 200 мс и более. Задача в книге - научить основам, как сделать сетевые задержки максимально незаметными для пользователей. На протяжении книги постепенно пишется одна мини-игра. Но, например, в Youtube можно найти много видео уроков на английском, которых достаточно, чтобы научиться писать дискретные мини-игры, где не требуются техники компенсации сетевых задержек.

0

Сообщение от Fulcrum_013 А теперя возьмите и попробуйте этот конкретный пример отобразить ни разу не юзая графоний

Так это просто. Когда в школе выходили к доске по математике, делали пример и проговаривали вслух... ну или преподаватель когда обьяснял, то проговаривал, вспомните. Все математические форулы читаются. А значит легко и однозначно выражаются словами.
y равняется пределу от синус х делить на х, при х стремщемся к нулю, плюс сумма по i от 0 до N, от a i-тое в степени два i плюс один.
Все. Никакой графики.
Просто сущестуют люди с разными типами восприятия информации (визуалы, аудиалы, ... слышали?) Кому-то проще увидеть, а кому-то услышать или проговорить

0

Сообщение от Крашеная Все. Никакой графики.

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

0