Не помню, чтобы мне приходилось лазить. Я не питонист, но периодически пишу простые скрипты. Полагаю, что школьникам с их задачами тоже лазить не придётся. Как по мне тому же школьнику сложнее разобраться, а где мне взять компилятор оберона и какой именно?
Чисто ради интереса спрошу, чем оберон лучше того же паскаля, питона или бейсика? Питон как по мне очень простой и вполне подходит для обучения ещё и промышленным является, паскаль я особо не трогал, но он, вроде как, предшественник оберона. Бейсик очень простой, у меня в своё время сложностей, связанных конкретно с использованием бейсика в качестве обучающего языка не было.
Оберон я как-то хотел потрогать, но так и не понял, какой компилятор использовать и забил
Сразу оговорюсь, что я не призываю на этих языках разрабатывать (хотя это было бы неплохо), нужны очень веские причины, чтобы принять такое решение. Но знакомство с ними — важная часть профессионального роста.
Однако, после прочтения не понятно, почему стоит попробовать форт. Тут даже примеров кода на нём не было. Было интересно прочитать историческую справку, но всё равно хотелось бы примеров и подтверждения данного в начале тезиса. Сразу скажу, что немного на форте я писал, так разные простые задачки чисто для гимнастики, но не сказал бы что его прямо стоит попробовать. Гораздо больше мне в своё время сломали шаблон язык ассемблера и хаскель.
Да, только написать интерпретатор bf - это на уровне решенения линейного уравнения, т.е. настолько просто, что писать об 100500 раз не стоит. Плюс, как вы могли заметить, в программе автора нашли несколько значительных недочётов. Ещё сам автор, как бы, написал, что статью он писал не для того, чтобы чем-то интересным поделиться, а чтобы получить инвайт.
Настроить самому требует больше времени и сил, чем настроить чужой конфиг под свои хотелки
Ну не знаю, в этих ваших astra/nvchad надо дополнительно разбираться, при том профита это не даст. У меня же простой конфиг на 200+ строк, в котором легко разобраться. Не помню, чтобы сильно сложно было его писать. Ему уже лет 8 (если не учитывать переписывание с vim script на lua, но это заняло буквально два часа), его легко дополнять, если вдруг надо, а главное нет ничего лишнего.
В любом учебнике, отдельно что потокам, что управлению памятью больше информации даётся. Тут всё очень поверхностно, чисто для рекламы курсов. Ещё и RAII зачем-то натягивается на си. Стоит объяснять людям, что не любой ресурс надо освобождать. Если программа запускается, выполняет одну задачу и завершается, ничего освобождать не нужно, ОС всё сделает за вас. Если программа аллоцирует ресурсы, а потом работает с ними в цикле (и в цикле никакие ресурсы не выделяются), то тоже ничего освобождать не нужно. Для управления памятью можно использовать не стандартный malloc, а arena allocator, да не всегда, но когда можно, жизнь он упрощает, ещё и работает быстрее, чем malloc. Потому что не нужно следить за жизнью 1000 ресурсов, потому что можно одним вызовом free освободить сразу всю 1000. Иногда можно использовать scratch arena (не знаю, как на русский перевести), там вообще можно ничего не освобождать. Передал в функцию копию аллокатора (не ссылку), функция что-то там повыделяла, но менялась при этом только копия аллокатора, а значит после завершения функции, вся память, ею выделенная считается доступной. Надо про это рассказывать, а не про то, как натягивать сову RAII на глобус Си.
UPD: ну и как выше заметили, про статическое выделение памяти тоже надо рассказывать. Многие вещи можно вообще без аллокаций сделать: например сетевые клиенты или игровые движки
Насколько я помню, в SFML есть не только создание окна и 2d рендеринг. Там ещё есть поддержка различных графических форматов и вывода аудио. Так что смысл всё же имеется (некоторые предпочитают SDL, но он имеет сишный интерфейс).
Можно инициализировать OpenGL контекст и весь рендеринг с его помощью делать, а SFML использовать для создания окна, обработки ввода и проигрывания аудио.
Всегда интересно читать историю разработки какого-нибудь проекта. Первая статья, конечно, мало чем отличается от типичного гайда по SFML, ну так ведь это первая статья из цикла. Надеюсь, дальше будет интереснее
У меня просто не возникало причин его использовать. Развернуть проект локально очень просто (ставим rbenv, mysql, redis, rabbitmq, а потом bundle install). Хотфикс вимом у нас никто не делает, только merge request в master, а потом деплой через ci/cd. Стенды мы ансиблом поднимаем, проблем не возникает.
Сложилось такое впечатление из-за этого предложения
Я пришел в компанию, уже 2 года назад, можно сказать для построение IT направление. По началу - это GitHub + Vercel(да-да, и фронт и бек в рамках 1 проекта), позже новый бек, новый фронт - уже два проекта
Около 20 сервисов на данный момент, в процессе распила основного бека
У нас их штук 10, и докер мы не используем, деплой пишется тоже очень просто. Поэтому мне и стало интересно, а зачем вообще докер нужен
А зачем вам в данной ситуации kubernetes? Я так понял, он нужен, когда у вас куча микросервисов, у каждого из которых может быть несколько инстансов, и всё это дело на разных хостах запускается. У вас же есть только бекенд. Есть ещё вопрос к знающим людям, а зачем вообще использовать в таких простых случаях докер, можно же взять какой-нибудь capistrano и точно так же деплоить из CI?
Менуэт - это же танец, а автор - Фин. Самое очевидное, что мне приходит в голову, вряд ли пришло бы в голову автору, так как русский он не знает. Может тут что-то менее очевидное?
Уже сложнее, чем пайтон. Совершать столько усилий ради языка, который почти нигде не используется, мне лень.
Я имел дело только с Visual Basic, там таких проблем не было. Насчёт простоты оберона могу только поверить на слово, так как дел с ним не имел
Не помню, чтобы мне приходилось лазить. Я не питонист, но периодически пишу простые скрипты. Полагаю, что школьникам с их задачами тоже лазить не придётся. Как по мне тому же школьнику сложнее разобраться, а где мне взять компилятор оберона и какой именно?
Чисто ради интереса спрошу, чем оберон лучше того же паскаля, питона или бейсика? Питон как по мне очень простой и вполне подходит для обучения ещё и промышленным является, паскаль я особо не трогал, но он, вроде как, предшественник оберона. Бейсик очень простой, у меня в своё время сложностей, связанных конкретно с использованием бейсика в качестве обучающего языка не было.
Оберон я как-то хотел потрогать, но так и не понял, какой компилятор использовать и забил
Однако, после прочтения не понятно, почему стоит попробовать форт. Тут даже примеров кода на нём не было. Было интересно прочитать историческую справку, но всё равно хотелось бы примеров и подтверждения данного в начале тезиса. Сразу скажу, что немного на форте я писал, так разные простые задачки чисто для гимнастики, но не сказал бы что его прямо стоит попробовать. Гораздо больше мне в своё время сломали шаблон язык ассемблера и хаскель.
Да, только написать интерпретатор bf - это на уровне решенения линейного уравнения, т.е. настолько просто, что писать об 100500 раз не стоит. Плюс, как вы могли заметить, в программе автора нашли несколько значительных недочётов. Ещё сам автор, как бы, написал, что статью он писал не для того, чтобы чем-то интересным поделиться, а чтобы получить инвайт.
Just for fun
Решил перед полным прочтением написать аналогичную программу самостоятельно. Вот, что получилось:
Вот ссылка на интрепретатор с кодом: https://tio.run/##pVVJDsIwDDyPX@EPcGD5EEJIcEMCieeXZpzFCS4rFarr2BMvE@d@Ot@O18v@cJwmVRU@mv@iEKRfkueXrSnsS5E@BNRkmf5iJpLX@CIQ3Ys0a0E/FFTuBDQbc0eOJ29polY4atG0Taxai1kt4ALgsBpADWfQRvt6A8zZckWyraQ4MOxJnxpTxhlicuHraEpsFykCLQLblqsPpk8KY36dabBXW3c6lsAw@vzTurSeKLJKyJaK8xQaut5EXcCb5roydDUNS/YS1vl7nrTiOW1IJAqFKJY5xsx/wl2oDEKG/MmbOK7uMLiG6pDv4tmIz2PcyK9Y/iF1fWscTz8@vPpM/IHjL4um8Yjp9tRotAW48SFfGpPxQOhqXWvhxpyxt3RTyyVQJzs4/2G3Aa@O5DRNG9nKTlbrBw
Получилось 1635 байт whitespace. А теперь пойду читать
https://github.com/cyberfined/wspasm
Я тоже недавно сделал примерно такой же язык, транслирующийся в whitespace, для написания программ в рамках adventofcode. Выглядит так:
Ну не знаю, в этих ваших astra/nvchad надо дополнительно разбираться, при том профита это не даст. У меня же простой конфиг на 200+ строк, в котором легко разобраться. Не помню, чтобы сильно сложно было его писать. Ему уже лет 8 (если не учитывать переписывание с vim script на lua, но это заняло буквально два часа), его легко дополнять, если вдруг надо, а главное нет ничего лишнего.
В любом учебнике, отдельно что потокам, что управлению памятью больше информации даётся. Тут всё очень поверхностно, чисто для рекламы курсов. Ещё и RAII зачем-то натягивается на си. Стоит объяснять людям, что не любой ресурс надо освобождать. Если программа запускается, выполняет одну задачу и завершается, ничего освобождать не нужно, ОС всё сделает за вас. Если программа аллоцирует ресурсы, а потом работает с ними в цикле (и в цикле никакие ресурсы не выделяются), то тоже ничего освобождать не нужно. Для управления памятью можно использовать не стандартный malloc, а arena allocator, да не всегда, но когда можно, жизнь он упрощает, ещё и работает быстрее, чем malloc. Потому что не нужно следить за жизнью 1000 ресурсов, потому что можно одним вызовом free освободить сразу всю 1000. Иногда можно использовать scratch arena (не знаю, как на русский перевести), там вообще можно ничего не освобождать. Передал в функцию копию аллокатора (не ссылку), функция что-то там повыделяла, но менялась при этом только копия аллокатора, а значит после завершения функции, вся память, ею выделенная считается доступной. Надо про это рассказывать, а не про то, как натягивать сову RAII на глобус Си.
UPD: ну и как выше заметили, про статическое выделение памяти тоже надо рассказывать. Многие вещи можно вообще без аллокаций сделать: например сетевые клиенты или игровые движки
Насколько я помню, в SFML есть не только создание окна и 2d рендеринг. Там ещё есть поддержка различных графических форматов и вывода аудио. Так что смысл всё же имеется (некоторые предпочитают SDL, но он имеет сишный интерфейс).
Можно инициализировать OpenGL контекст и весь рендеринг с его помощью делать, а SFML использовать для создания окна, обработки ввода и проигрывания аудио.
Всегда интересно читать историю разработки какого-нибудь проекта. Первая статья, конечно, мало чем отличается от типичного гайда по SFML, ну так ведь это первая статья из цикла. Надеюсь, дальше будет интереснее
windows-only же
У меня просто не возникало причин его использовать. Развернуть проект локально очень просто (ставим rbenv, mysql, redis, rabbitmq, а потом bundle install). Хотфикс вимом у нас никто не делает, только merge request в master, а потом деплой через ci/cd. Стенды мы ансиблом поднимаем, проблем не возникает.
Сложилось такое впечатление из-за этого предложения
У нас их штук 10, и докер мы не используем, деплой пишется тоже очень просто. Поэтому мне и стало интересно, а зачем вообще докер нужен
А зачем вам в данной ситуации kubernetes? Я так понял, он нужен, когда у вас куча микросервисов, у каждого из которых может быть несколько инстансов, и всё это дело на разных хостах запускается. У вас же есть только бекенд. Есть ещё вопрос к знающим людям, а зачем вообще использовать в таких простых случаях докер, можно же взять какой-нибудь capistrano и точно так же деплоить из CI?
Менуэт - это же танец, а автор - Фин. Самое очевидное, что мне приходит в голову, вряд ли пришло бы в голову автору, так как русский он не знает. Может тут что-то менее очевидное?