Здравствуйте, elmal, Вы писали:

E>Тупо под заходом на любой сайт скрывается огромнейшая машинерия. На порядок круче всех хешмапов. Однако зайти на сайт и что то там скачать или стукануться к сервису по url — это сверхбазовая операция.

Ну вот я не согласен с этим. Прежде, чем стукаться к сервису по URL, нужно разобраться с юниксом, научиться работать с TCP сокетами, а потом уже можно и свой веб-сервер написать, и клиента. И будешь понимать, что скрывается за fetch(...).

Хотя с этими HTTP/2 и прочими это уже, кажется, не так просто. Но HTTP/1.1 за реверс-проксями ещё долго будет жить.

Вот недавно видел на одном форуме вопрос. Человек пишет, что у него POST-запросы отваливаются с connection refused иногда, а GET не отваливаются. И он пытается разобраться, что у него там с запросами. А если бы он понимал, что connection refused это уровень TCP, а не HTTP, он бы не тратил время на бессмысленные вопросы. Но — привык, что fetch это сверхбазовая операция и если оно не работает, значит надо проверять параметры запроса. А вот — не сверхбазовая.

E>А можно наоборот пойти. Сделать одну структуру данных — тупо хешмапа, и из нее выводить списки, массивы и т.д. Пифиг на скорость, пофиг на эффективность, пусть там вместо константного времени поиска будет кубическая — главное чтоб работало. И научить выполнять простейшие полезные в быту задачи. Спускаться на уровень массивов в современном программировании мало кому требуется. Все современные абстракции сильно выше массивов сразу, и можно проработать 20 лет и ни разу не столкнуться с необъодимостью работы именно с чистым массивом.

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

Здравствуйте, elmal, Вы писали:

E>Тупо под заходом на любой сайт скрывается огромнейшая машинерия. На порядок круче всех хешмапов. Однако зайти на сайт и что то там скачать или стукануться к сервису по url — это сверхбазовая операция.

Ну вот я не согласен с этим. Прежде, чем стукаться к сервису по URL, нужно разобраться с юниксом, научиться работать с TCP сокетами, а потом уже можно и свой веб-сервер написать, и клиента. И будешь понимать, что скрывается за fetch(...).

Хотя с этими HTTP/2 и прочими это уже, кажется, не так просто. Но HTTP/1.1 за реверс-проксями ещё долго будет жить.

Вот недавно видел на одном форуме вопрос. Человек пишет, что у него POST-запросы отваливаются с connection refused иногда, а GET не отваливаются. И он пытается разобраться, что у него там с запросами. А если бы он понимал, что connection refused это уровень TCP, а не HTTP, он бы не тратил время на бессмысленные вопросы. Но — привык, что fetch это сверхбазовая операция и если оно не работает, значит надо проверять параметры запроса. А вот — не сверхбазовая.

E>А можно наоборот пойти. Сделать одну структуру данных — тупо хешмапа, и из нее выводить списки, массивы и т.д. Пифиг на скорость, пофиг на эффективность, пусть там вместо константного времени поиска будет кубическая — главное чтоб работало. И научить выполнять простейшие полезные в быту задачи. Спускаться на уровень массивов в современном программировании мало кому требуется. Все современные абстракции сильно выше массивов сразу, и можно проработать 20 лет и ни разу не столкнуться с необъодимостью работы именно с чистым массивом.

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

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