Я лично считаю что первый язык программирования должен быть C
А я так не считаю, хоть первый язык и был монстр под названием C/C++, который в школе и вузе давали.
И теперь я расскажу почему.
Потому что для новичков - нифига не понятно. Никакой "магии общения с машиной". У тебя то компилируется, то не компилируется, если скомпилировалось - упадет, но почему - да хрен знает, сиди printf-дебагингом занимайся
Туллчейн, в котором у тебя во время сборки сообщения вида %TEMP__sdx__0x10000FUCK_YOU_x42 NOT IMPL LYNC NOT FOUND% а ты сиди-кури
100500 способов прострелить себе ногу, и даже не заметить этого
Тривиальные вещи - делаются с такой болью, что тебе уже пофиг на результат, тебе просто хочется выкинуть это все дело к чертям, купить билет до Страуструпа и авторам gcc и серьезно поговорить с ними на филосовские темы
Наимерзотнейший стандарт
UВ на UB и UB погоняет, живи с этим как хочешь
STL(да это плюсы, но все равно), которую писали так, будто ненавидят всех кто будет ей пользоваться
И, вот при всех таких вводных - Java, питон, шарп, да любой язык более-менее современный, который взял, и просто именно что учишься. Делаешь свой 100500 туду лист, 100500 компилятор, 100500 веб сервер, базу данных, да что угодно, и занимаешься РАЗРАБОТКОЙ, а не танцами с бубном вокруг вот этой всей фигни.
Ну, если уж не Java-питон-шарп, то хотя бы паскаль. Паскаль, если отбросить то что не применяется сейчас особо в проде - не обладает вот этими вот интересностями си-плюсов, имеет нормальный туллчейн, и при желании - хоть низкоуровневые вещи, хоть высокоуровневые. Отличный язык.
Для веба он дает вторую часть что в "дополнительно". Потоки - дорогие. При большой нагрузке - большое времени будет тратится на переключение контекста, чем на обработку самого запроса. C10k/C10M или как-то так обзывается в вебе. Асинхронщина - позволяет уменьшить это самое число потоков, ведь когда запустилась асинхронная операция - этот поток может не ждать пока она завершиться, а переключиться на обработку других запросов. Когда обработка завершится - планировщик, в зависимости от настроек, либо найдет незанятый поток и тот продолжит выполнение, либо будет ждать пока вызвавший поток будет готов к обработке результата.
Соответственно, продолжать дальше мы по-любому не можем
Вот ваш код на UI-потоке. Пользователь клацнул кнопку - открыть файл. Файл - 100500 гигабайт. Этот UI-поток начал чтение с диска и ждет пока все прочитается. Для пользователя выглядит как будто все зависло. В диспетчере задач - не отвечает. Пользователь не дожидается, убивает ее через диспечер.
Вот чтобы не блокировать основной поток - и нужны асинхронные операции.
Дополнительно, при большом количестве IO, мы более рационально используем потоки, если используем тот же самый async-await, зачем нам целый тред, который ничего не делает, и чего-то ждет, если он может что-то полезное делать пока IO-операция ожидает завершения?
Раз такая пьянка, то может быть лучше английский кириллицей? Решает ровно те же проблемы.
Вот хабр тсинк эбаут ит?
Для разных языков - разные письменности не просто так придуманы. В японском - сколько не пытались ради сближения с западом латинизацию провести - очень плохо это дело идет. Текст становится очень сильно оторванным от речи. Даже в английском, после того как повыкидывали кучу символов "за ненадобностью" - сейчас рассказывают, что нет никаких правил - ты просто должен запомнить, что вот тут - читай так, там - так.
то то я вижу сантехники на убитых жыгулях ездят и используют технику далеко не топовых брендов...видимо они потом дома пересаживаются на камри и ведут семью обедать в ресторан... ;))
Я - айтишник, но тоже не то чтобы какие-то там шмотки, или дорогую технику покупаю. Все в семью. До этого - в хобби Типа я не знаю. А разве все кто хорошо зарабатывают - должны обязательно купить себе машину подороже, какой-нибудь телефон из алмазов с золотыми вставками и золотой унитаз?
Не то чтобы прям плохо. Но вот проблемы, которые из-за null часто возникают:
null - может быть валидным значением в контексте поиска. И тогда непонятно - этот null есть в коллекции, или его таки нет.
Принимающей стороне - может быть неочевидно из сигнатуры, что null может быть возвращен, в результате, клиент - не проверил, радостно залил в прод, и через 5 лет все упало, почему - хз. Поиск этого NRE может оказаться не таким тривиальным.
Если даже никто ничего не забыл. Исходя из того что любой ссылочный тип - может быть null - ты должен как параноик - на каждом шагу проверять. И код превращается в бесконечные проверки на этот самый null
Варианты что делать: как договорились в команде.
Если в команде - ок с null - возвращайте-проверяйте. Если в команде принято кидать исключения - кидайте. Если у вас команда дофига любители ФП - Either<T, Error> какой-нибудь. Если любители ООП - какой-нибудь Result
Очевидные алгоритмы очевидны. Их как-бы не просто так в гуглах и прочих гоняют. Это же просто такое "секретное рукопожатие", человек шарит в алгоритмах - пускаем дальше на собес, не шарит - заворачиваем. Времени при этом тратится меньше и у кандидата и у человека, который будет проверять его, в отличии от тестового задания в духе: напиши админку) Да, можно заучить. Так ведь не заучивают алгоритмы почти никто, вон сколько нытья, про то: ЗАЧЕМ МНЕ ВАШИ АЛГАРИТМЫ, ЕСЛИ Я JSON'ы ГОНЯЮ???
СИ.
int main() {auto str = "Hello world";
printf("%s\n", str);
str = str + 5;
printf("%s\n", str);
return 0;
}
Да, варнинги посыпятся, но соберется и запустится. Весело. Да?
Ну, давайте разбирать.
А я так не считаю, хоть первый язык и был монстр под названием C/C++, который в школе и вузе давали.
И теперь я расскажу почему.
Потому что для новичков - нифига не понятно. Никакой "магии общения с машиной". У тебя то компилируется, то не компилируется, если скомпилировалось - упадет, но почему - да хрен знает, сиди printf-дебагингом занимайся
Туллчейн, в котором у тебя во время сборки сообщения вида %TEMP__sdx__0x10000FUCK_YOU_x42 NOT IMPL LYNC NOT FOUND% а ты сиди-кури
100500 способов прострелить себе ногу, и даже не заметить этого
Тривиальные вещи - делаются с такой болью, что тебе уже пофиг на результат, тебе просто хочется выкинуть это все дело к чертям, купить билет до Страуструпа и авторам gcc и серьезно поговорить с ними на филосовские темы
Наимерзотнейший стандарт
UВ на UB и UB погоняет, живи с этим как хочешь
STL(да это плюсы, но все равно), которую писали так, будто ненавидят всех кто будет ей пользоваться
И, вот при всех таких вводных - Java, питон, шарп, да любой язык более-менее современный, который взял, и просто именно что учишься. Делаешь свой 100500 туду лист, 100500 компилятор, 100500 веб сервер, базу данных, да что угодно, и занимаешься РАЗРАБОТКОЙ, а не танцами с бубном вокруг вот этой всей фигни.
Ну, если уж не Java-питон-шарп, то хотя бы паскаль. Паскаль, если отбросить то что не применяется сейчас особо в проде - не обладает вот этими вот интересностями си-плюсов, имеет нормальный туллчейн, и при желании - хоть низкоуровневые вещи, хоть высокоуровневые. Отличный язык.
Для веба он дает вторую часть что в "дополнительно".
Потоки - дорогие. При большой нагрузке - большое времени будет тратится на переключение контекста, чем на обработку самого запроса. C10k/C10M или как-то так обзывается в вебе.
Асинхронщина - позволяет уменьшить это самое число потоков, ведь когда запустилась асинхронная операция - этот поток может не ждать пока она завершиться, а переключиться на обработку других запросов. Когда обработка завершится - планировщик, в зависимости от настроек, либо найдет незанятый поток и тот продолжит выполнение, либо будет ждать пока вызвавший поток будет готов к обработке результата.
Вот ваш код на UI-потоке. Пользователь клацнул кнопку - открыть файл. Файл - 100500 гигабайт. Этот UI-поток начал чтение с диска и ждет пока все прочитается. Для пользователя выглядит как будто все зависло. В диспетчере задач - не отвечает. Пользователь не дожидается, убивает ее через диспечер.
Вот чтобы не блокировать основной поток - и нужны асинхронные операции.
Дополнительно, при большом количестве IO, мы более рационально используем потоки, если используем тот же самый async-await, зачем нам целый тред, который ничего не делает, и чего-то ждет, если он может что-то полезное делать пока IO-операция ожидает завершения?
Раз такая пьянка, то может быть лучше английский кириллицей? Решает ровно те же проблемы.
Вот хабр тсинк эбаут ит?
Для разных языков - разные письменности не просто так придуманы. В японском - сколько не пытались ради сближения с западом латинизацию провести - очень плохо это дело идет. Текст становится очень сильно оторванным от речи. Даже в английском, после того как повыкидывали кучу символов "за ненадобностью" - сейчас рассказывают, что нет никаких правил - ты просто должен запомнить, что вот тут - читай так, там - так.
Я - айтишник, но тоже не то чтобы какие-то там шмотки, или дорогую технику покупаю.
Все в семью. До этого - в хобби
Типа я не знаю. А разве все кто хорошо зарабатывают - должны обязательно купить себе машину подороже, какой-нибудь телефон из алмазов с золотыми вставками и золотой унитаз?
Не то чтобы прям плохо. Но вот проблемы, которые из-за
nullчасто возникают:null- может быть валидным значением в контексте поиска. И тогда непонятно - этотnullесть в коллекции, или его таки нет.Принимающей стороне - может быть неочевидно из сигнатуры, что
nullможет быть возвращен, в результате, клиент - не проверил, радостно залил в прод, и через 5 лет все упало, почему - хз. Поиск этогоNREможет оказаться не таким тривиальным.Если даже никто ничего не забыл. Исходя из того что любой ссылочный тип - может быть
null- ты должен как параноик - на каждом шагу проверять. И код превращается в бесконечные проверки на этот самыйnullВарианты что делать: как договорились в команде.
Если в команде - ок с
null- возвращайте-проверяйте. Если в команде принято кидать исключения - кидайте. Если у вас команда дофига любители ФП - Either<T, Error> какой-нибудь. Если любители ООП - какой-нибудь ResultОчевидное
Either<T, Error>Очевидные алгоритмы очевидны.
Их как-бы не просто так в гуглах и прочих гоняют. Это же просто такое "секретное рукопожатие", человек шарит в алгоритмах - пускаем дальше на собес, не шарит - заворачиваем. Времени при этом тратится меньше и у кандидата и у человека, который будет проверять его, в отличии от тестового задания в духе: напиши админку)
Да, можно заучить. Так ведь не заучивают алгоритмы почти никто, вон сколько нытья, про то: ЗАЧЕМ МНЕ ВАШИ АЛГАРИТМЫ, ЕСЛИ Я JSON'ы ГОНЯЮ???
Использовать другой поставщик контейнеров(докерхаб это не единственное место откуда тянуть контейнеры можно)
Воспользоваться зеркалами
Поднять VPN
Сделать свой контейнер ручками и где-нибудь разместить его (любой дешевый хостинг-провайдер, на нем какой-нибудь Nexus или любая альтернатива)