Дело в том, что бэкенд не является частью клиента. Суть архитектуры клиент-сервер в separation of concerns. Соответственно, да, бэкенд может быть ДЛЯ клиента, но он никоим образом не является частью клиента и здесь нет никаких значимых различий с вебом.
А теперь смотрим на исходное сообщения, к которому я привязался с целью выяснить что же все таки понимает под фронтендом и бэкендом автор статьи:
Ну фронт и бэк есть и у десктопных клиентов
У меня возникло ощущение, что автор под словом «бэкенд» понимает совсем не то что я или вы, я пытаюсь выяснить что именно.
UPD Ну и да, исходная мысль была в том, что программирование не ограничивается клиент-серверными архитектурами, где есть выделенные фронтенд и бэкенд.
И, возвращаясь к контексту, программисты для бэк- и фронт-частей в тех проектах были сильно разные как по скиллам, так и по используемому инструментарию (например, Delphi vs C++).
Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?
Нет, это пример разных ролей на проекте. Я не критикую термины «бэк» и «фронт», я критикую людей, которые всерьез рассуждают о терминах «бэкендер», «фронтендер» и «фуллстек» как о профессиях распространяя вебовую специфику (где это чисто исторически имеет некоторый смысл) на всех.
Причем тут вообще энтерпрайз и машинное обучение если вы же говорите о стеках?
… и вы начинаете противоречить собственной же статье.
UPD Я повторю вопрос — все эти роли настолько разные и требуют настолько разного набора знаний, что вырождаются в отдельные профессии, как это происходит в вебе, и требуют написания таких статей?
Вы не ответили на мой вопрос.
К слову, что такое «бэк десктопного клиента»?
Мне кажется, вы опять пытаетесь свести вопрос к очень ограниченному подмножеству проектов и отвечаете в рамках этого подмножества. Я же как раз говорю, что не надо так делать.
Например, я работаю в десктопном проект на ~20кк строк (достаточно большой?) и у нас нет базы данных (реляционной во всяком случае).
… и перестать делить разработчиков на фронтендеров, бэкендеров и фуллстеков. Точнее осознать, что мир состоит не только из веба и принятых в нем ролей.
Вы под «быстрее/медленнее» подразумеваете производительность в миллисекундах (измеряемую).
Да, конечно, ту которую можно измерить, и которая реально влияет на пользовательский опыт.
Вы видимо зацепились за «Уже придумали алгоритм, ищущий быстрее двоичного поиска?»
Именно так.
Вообще, я хотел высказать идею, что принимать решение о выборе алгоритма только на основании его асимптотик (как часто просят на «неправильных» собеседованиях поклонники карго-культа и зубрежки) — неправильно.
1. Это просто полезно, даже не для программирования.
2. Умение решать такие задачи открывает двери в места, где такие задачи решать нужно, можно и интересно. Не говоря уже о чисто материальных и репутационных плюшках.
Но если вам интересно в кровавом энтерпрайзе (в хорошем энтерпрайзе таких задач тоже много) или вебе (без иронии, я понимаю почему это может быть интереснее), то как бы да, выбор понятен.
Это очень сильно зависит от проекта и специфики. Есть проекты где это неважно (типичный веб), есть проекты где про это все нужно думать постоянно даже на очень простом коде (я сейчас на таком).
Другой не задумался на решением или не знал другого варианта и использовал List.
… и через несколько лет, когда при масштабировании этот код внезапно отожрал всю память или начал тормозить на казалось бы обычных операциях, придется потратить еще больше времени дорогих специалистов на профилирование, поиск проблемы, отладку и переписывание с учетом регрессии.
Хорошо, извините за резкий тон и спасибо за адекватную реакцию.
Давайте подробно, по порядку.
Что по вашему такое «асимптотика функции»?
Я осознаю, что в случае хэш-таблицы это сложность в среднем, а в бин. поиске — в худшем случае. Но, как вы сказали, мы обсуждаем «какой алгоритм быстрее».
Не совсем «в среднем», это предел от «среднего» при n -> бесконечность.
В вашем примере с хэшфункцией по строке со сложностью O(L) получается:
Это не говорит о том быстрее или медленнее работает хэш-таблица, это говорит о том, что при росте n хэш-таблица в общем случае не становится медленнее.
А здесь я вас поддержу. Выбор и проектирование правильных алгоритмов и структур — это фактически архитектурный вопрос, а не предварительная оптимизация.
Речь в комментарии на который я отвечал шла о том "какой алгоритм быстрее", а не о том сложность какого алгоритма быстрее растет при росте n.
А дальше попрошу сходить в любую книжку по алгоритмам и разобраться с понятием амортизированной сложности алгоритма (по пути можно заглянуть в матанализ и посмотреть, что такое предел по одной переменной) и а также алгоритмами хэширования строк.
А теперь смотрим на исходное сообщения, к которому я привязался с целью выяснить что же все таки понимает под фронтендом и бэкендом автор статьи:
У меня возникло ощущение, что автор под словом «бэкенд» понимает совсем не то что я или вы, я пытаюсь выяснить что именно.
UPD Ну и да, исходная мысль была в том, что программирование не ограничивается клиент-серверными архитектурами, где есть выделенные фронтенд и бэкенд.
Эта разница обусловлена фундаментальными различиями в программировании фронтенда и бэкенда или просто выбором технологии для их реализации?
2) Бэкенд в multitier — это просто бэкенд.
Причем тут вообще энтерпрайз и машинное обучение если вы же говорите о стеках?
UPD Я повторю вопрос — все эти роли настолько разные и требуют настолько разного набора знаний, что вырождаются в отдельные профессии, как это происходит в вебе, и требуют написания таких статей?
К слову, что такое «бэк десктопного клиента»?
Мне кажется, вы опять пытаетесь свести вопрос к очень ограниченному подмножеству проектов и отвечаете в рамках этого подмножества. Я же как раз говорю, что не надо так делать.
Например, я работаю в десктопном проект на ~20кк строк (достаточно большой?) и у нас нет базы данных (реляционной во всяком случае).
Настолько разные, что «десктопный фронт» и «десктопный бэк» стали «типа разными» профессиями?
Да, конечно, ту которую можно измерить, и которая реально влияет на пользовательский опыт.
Именно так.
Вообще, я хотел высказать идею, что принимать решение о выборе алгоритма только на основании его асимптотик (как часто просят на «неправильных» собеседованиях поклонники карго-культа и зубрежки) — неправильно.
2. Умение решать такие задачи открывает двери в места, где такие задачи решать нужно, можно и интересно. Не говоря уже о чисто материальных и репутационных плюшках.
Но если вам интересно в кровавом энтерпрайзе (в хорошем энтерпрайзе таких задач тоже много) или вебе (без иронии, я понимаю почему это может быть интереснее), то как бы да, выбор понятен.
… и через несколько лет, когда при масштабировании этот код внезапно отожрал всю память или начал тормозить на казалось бы обычных операциях, придется потратить еще больше времени дорогих специалистов на профилирование, поиск проблемы, отладку и переписывание с учетом регрессии.
Давайте подробно, по порядку.
Что по вашему такое «асимптотика функции»?
Не совсем «в среднем», это предел от «среднего» при n -> бесконечность.
В вашем примере с хэшфункцией по строке со сложностью O(L) получается:
Это не говорит о том быстрее или медленнее работает хэш-таблица, это говорит о том, что при росте n хэш-таблица в общем случае не становится медленнее.
Нет, конечно не на месте в массиве. Для него немного подумаю с бумажкой и рисунками.
А здесь я вас поддержу. Выбор и проектирование правильных алгоритмов и структур — это фактически архитектурный вопрос, а не предварительная оптимизация.
Я повторю ещё раз.
Речь в комментарии на который я отвечал шла о том "какой алгоритм быстрее", а не о том сложность какого алгоритма быстрее растет при росте n.
А дальше попрошу сходить в любую книжку по алгоритмам и разобраться с понятием амортизированной сложности алгоритма (по пути можно заглянуть в матанализ и посмотреть, что такое предел по одной переменной) и а также алгоритмами хэширования строк.