фулстэк подразумевает более широкий но менее глубокий скоуп знаний. Банально в силу того что за всем уследить вы не сможете. Да и "фулстэк фулстэку" рознь. Ну и даже если вы носите гордое звание фулстэка это не отменяет специализацию.
Например мне не составляет труда напилить какой-нибудь фронтэндик, поднять класстер серверов и т.д. но я прекрасно понимаю что моя специализация все же бэкэнд. И тот факт сколько времени я могу уделять развитию сильно сказывается на уровне "сопутствующих знаний".
Ну то есть я вижу проблему с тем что понятие "фулстэка" у всех разное. Знать все невозможно. Но оно и не нужно обычно. Достаточно знать много, а копать вглубь только при необходимости.
то есть мы избегаем лока от одного вендора за счет лока на другого вендора (Надеюсь вы не пишите свои ORM).
Задача ORM не абстракцию от базы вам предоставить, а мэппинг данных организовать, из реляционной модели в ваши in-memory структуры. При этом у вас может быть тотальная завязка на нюансы конкретной СУБД. Дальше все больше про разделение ответственности (изменения персистенса не должны влиять на бизнес логику, но думать что при смене СУБД вам код не придется писать — глупо).
как версионирование и развертывание.
на самом деле нет. Все это тоже можно мигрировать и версионировать, и обратную совместимость схемы между деплоями никто не отменял (потому что вы не можете абсолютно одновременно, без даунтайма выкатить одинаковые версии схемы и кода)
Плюс требуют от разработчика дополнительных компетенций
Если подумать то объем знаний необходимых для работы с каким-нибудь nhibernate сопоставим с объемом знаний для работы с процедурами. Да, это сильно разный опыт, и стоит ориентироваться на рынок труда (а он такой что я ни тот ни другой вариант бы не доверил большинству)
в каких-то весьма высоконагруженных приложениях.
Обычно оправдание — тотальное разделение ответственности и контроль за данными, секьюрити политики и т.д. Производительность — сомнительный довод. Да и процедуры будут ограничивать вас по горизонтали (хотя кто его знает).
p.s. Если что — принципиально не использую процедуры/тригеры для бизнес логики и пока не встречался с юзкейсами где это все дает очевидные преимущества. Но полагаю такие кейсы есть. Не подумайте что я там фанат таких вещей.
хорошо или плохо — не очень то инженерные понятия.
то надо пересобрать все клиенты, чтобы проверить, что типы сходятся. Не так ли?
все так, на уровне одного модуля все с типами хорошо, на уровне другого — не сходятся. Но на практике все не столь уж плохо что бы отказываться от преимуществ подобной "утиной типизации в компайл тайме".
Опять же, тут думаю стоит еще учитывать особенности системы модулей, которые сильно уменьшают риски от вот таких вот изменений (явно прослеживаются зависимости модулей, что позволяет отследить по иерархии зависимости все что надо на всякий случай протайпчекать)
Не все проблемы в мире выгодно решать структурным тайпингом. Абстрактные классы бывают полезны (особенно если интерфейсы не могут содержать дефолтной реализации как в Java).
А в случае TS можно поразбираться в вопросах номинальный тайпинг vs структурный тайпинг, плюсы и минусы одного и второго.
В TS в основном все юзают структурный тайпинг (опять же можно порассуждать на тему оверюза фич).
Вот есть у вас 2 модуля, A и B, один зависит от другого. Как сделать инверсию зависимостей в какой-нибудь Java? Добавим интерфейс в модуль A и B его будет имплементить, направление зависимостей уже меняется. Как это делать в TS? Примерно так же, только имплементить интерфейс не нужно. Типы либо сходятся либо нет.
И в целом как и в случае с Java необходимости в абстрактных классах практически нет (опять же после появления возможности объявлять дефолтное поведение в интерфейсах). И в целом в java как по мне абстрактные классы представляют ценность только для обратной совместимости.
Возьмите не среднюю температуру за месяц, а статистику по перепадам температур, статистику по ураганам, по осадкам (опять же важна динамика, скажем дней с осадками было меньше но осадков выпало больше). Суть всей этой фигни с «изменением климата» в том что происходит это не равномерно и в целом выражается в менее мягком климате по сравнению с предыдущими годами. Ну и все это сильно к региону привязано, где-то эффекты проявляются больше, где-то меньше.
По поводу социальных потрясений — ну подождите лет так 50, и будут вам потрясения. От того так сложно общаться с кем-либо на эту тему — уж больно отдаленные перспективы и «мы не застанем».
Потому что опять же изменения происходят относительно медленно. Но кое какие последствия уже можно наблюдать. Например в следствии увеличения температуры уже наблюдается более сильные ураганы (их мощность зависит от температуры воды)
Ну и в долгосрочной перспективе в следствии изменения температуры океана, и как следствие, изменение градиентов солености воды ближе к полюсам, могут перестроиться океанические течения которые и работают за счет разности плотности воды в следствии разности солености.
Суть в том что увеличение средней температуры не означает что в целом будет теплее. Наоборот, будет больше разница температур. И в той же Европе, климат которой сильно зависит от гольфстрима, будет холоднее чем сегодня.
Я конечно не шарю во всех этих делах, но при желании исследования всего это гуглятся.
> Нормальному человеку не может быть нужной крипта вообще.
мне она не нужна, и биткойны никому не нужны. Но сама идея в целом крутая, и применение найти ей нет особо проблемы.
Проблема крипты — хайп вокруг, который как раз и разделяет все на два лагеря. И да, регулярно вижу какие-то тупые биткойн митапы где вся соль как раз таки и сводится к спекуляциях на курсе валют.
Меня такое не интересует.
> А вот ресурсов эта ерунда съест огромное количество.
ну вопрос оптимизаций. По идее не должна она уж столько ресурсов есть.
> Хоть бы уж тогда воду горячую делали бы, какая-никакая польза.
Да, все так. Но не везде. Как пример "интересностей" посмотрите на Кению и их мобильные платежи. Не криптовалюты конечно, но прецедент как по мне неплохой.
Ну и, из той статистики которую мне удалось нагуглить (за 15-ый год) — 2.5 миллиарда людей не имеют доступа к банкам.
Глобально, выигрывает тот, кто тратит меньше джоулей и/или времени на ту же задачу.
Никак не могу нагуглить статистику по потерям на межбанковских переводах… Если вкурсе поделитесь.
(грубо говоря, ACID СУБД)
а вот отсюда наверное эти потери и берутся… не умеет ACID в распределенность.
Что бы устранить посредника в экономических сделках, разумеется. Разумеется для стран с развитой банковской системой "подвинуть" никого не выйдет, вот только это далеко не все страны.
Аналогия тут может быть очень простая — в развитых странах у вас сначала были телеграфные линии, затем поверх начали строить телефонные, затем инфраструктура для мобильной связи и интернета. И есть страны где, начали сразу с мобильной связи, так как другой инфраструктуры до этого у них не было.
Жить некогда, везде дэдлайны.
Хочется пошутить что у вашей жизни тоже есть дэдлайн но думаю вы сами все прекрасно поняли.
p.s. почему-то ваш комментарий мне напомил отрывок из монти пайтона про анархо-синдикалистов.
Как же хорошо когда студенты технологи по какой-то картинке могут делать подобные выводы. И зачем нужны все эти сложнейшие климатические модели, анализ ледяных кернов для отслеживания динамики состава атмосферы, модели изменения океанических течений в следствии изменения солености воды… Можно ж было просто посмотреть карту.
p.s. А вот интересно, так сколько джоуелей? А ват сколько? И сколько там петават от солнышка прилетает (лучше наверное с учетом отражения)?
вы фразу видимо не дочитали. PHP отличная платформа со своими изюминками (вроде умирающей модели выполнения, алицетворяющей феникса). Вот эта самая платформа и привлекает людей. Платформа, а не язык.
В возможно вы вовсе и не про язык а про интерпритатор говорили. В таком случае смысл вашего комментария для меня остается загадкой.
я к тому что я понятия не имею что вы под ООП имеете ввиду.
Есть Elixir, у него синтаксис поприятнее. Что до "других задач" — ну вот то куда люди свулле впихивают как раз таки "те самые другие задачи".
Swift можно использовать хоть для бэкэнд разработки хоть для фронтэнда (webassembly). Это ваши стереотипы. Так же как и Kotlin native можно юзать для написания экстеншенов для php. C# так же вполне себе юзабелен для кросплатформенной разработки нынче. Для вэба — опять же выбор сильно больше, ну и опять же — подождем годика три пока webassembly наберет популярность. А так уже сегодня многие используют различные трансляторы в js.
Как там говорится, прогресс движется в сторону интеропа языков и это хорошо.
Относительно высосаных из пальца аргументов
еще раз, я против php как платформы ничего не имею, использую его на протяжении 10-ти лет. Но повторюсь, язык убогий.
уже всем привычное ООП (java-like)
посмотрите как в той же джаве можно красиво билдеры описать и грустите что подобного в php не будет. Нет, ну может быть вот это протащат и я тогда буду меньше ругаться, но…
А пока все эти "самый лучший интерпритатор" и прочие восхваления языка лишь вред ему несут.
Phalcon призван уменьшить оверхэд на бутстраппинг фреймворка, однако этот оверхэд все же есть. Свулле же это полноценный application server, а потому такие штуки как «отдать json» для него фигня. Из вариантов не требующих «переписи» лично мне нравится roadrunner. Будет не так круто как со свулле но я предпочел бы писать подобное не на php.
А вот почему такая огромная разница с тем же amp (разве что парсинг http запросов силами php) — это для меня загадка.
фулстэк подразумевает более широкий но менее глубокий скоуп знаний. Банально в силу того что за всем уследить вы не сможете. Да и "фулстэк фулстэку" рознь. Ну и даже если вы носите гордое звание фулстэка это не отменяет специализацию.
Например мне не составляет труда напилить какой-нибудь фронтэндик, поднять класстер серверов и т.д. но я прекрасно понимаю что моя специализация все же бэкэнд. И тот факт сколько времени я могу уделять развитию сильно сказывается на уровне "сопутствующих знаний".
Ну то есть я вижу проблему с тем что понятие "фулстэка" у всех разное. Знать все невозможно. Но оно и не нужно обычно. Достаточно знать много, а копать вглубь только при необходимости.
Когда я придумал термин ООП я не имел ввиду C++ (с) Алан Кей.
Ну и если мы говорим про провославное ООП и Rust: https://github.com/actix/actix
ммм… не поделитесь определением? Что есть что?
то есть мы избегаем лока от одного вендора за счет лока на другого вендора (Надеюсь вы не пишите свои ORM).
Задача ORM не абстракцию от базы вам предоставить, а мэппинг данных организовать, из реляционной модели в ваши in-memory структуры. При этом у вас может быть тотальная завязка на нюансы конкретной СУБД. Дальше все больше про разделение ответственности (изменения персистенса не должны влиять на бизнес логику, но думать что при смене СУБД вам код не придется писать — глупо).
на самом деле нет. Все это тоже можно мигрировать и версионировать, и обратную совместимость схемы между деплоями никто не отменял (потому что вы не можете абсолютно одновременно, без даунтайма выкатить одинаковые версии схемы и кода)
Если подумать то объем знаний необходимых для работы с каким-нибудь nhibernate сопоставим с объемом знаний для работы с процедурами. Да, это сильно разный опыт, и стоит ориентироваться на рынок труда (а он такой что я ни тот ни другой вариант бы не доверил большинству)
Обычно оправдание — тотальное разделение ответственности и контроль за данными, секьюрити политики и т.д. Производительность — сомнительный довод. Да и процедуры будут ограничивать вас по горизонтали (хотя кто его знает).
p.s. Если что — принципиально не использую процедуры/тригеры для бизнес логики и пока не встречался с юзкейсами где это все дает очевидные преимущества. Но полагаю такие кейсы есть. Не подумайте что я там фанат таких вещей.
А каким критериям должен удовлетворять уровень человека что бы можно было именовать его сеньором?
Чего только в наше время не выдумают: Blazor — Full-stack web development with C# and WebAssembly
хорошо или плохо — не очень то инженерные понятия.
все так, на уровне одного модуля все с типами хорошо, на уровне другого — не сходятся. Но на практике все не столь уж плохо что бы отказываться от преимуществ подобной "утиной типизации в компайл тайме".
Опять же, тут думаю стоит еще учитывать особенности системы модулей, которые сильно уменьшают риски от вот таких вот изменений (явно прослеживаются зависимости модулей, что позволяет отследить по иерархии зависимости все что надо на всякий случай протайпчекать)
А в случае TS можно поразбираться в вопросах номинальный тайпинг vs структурный тайпинг, плюсы и минусы одного и второго.
Вот есть у вас 2 модуля, A и B, один зависит от другого. Как сделать инверсию зависимостей в какой-нибудь Java? Добавим интерфейс в модуль A и B его будет имплементить, направление зависимостей уже меняется. Как это делать в TS? Примерно так же, только имплементить интерфейс не нужно. Типы либо сходятся либо нет.
И в целом как и в случае с Java необходимости в абстрактных классах практически нет (опять же после появления возможности объявлять дефолтное поведение в интерфейсах). И в целом в java как по мне абстрактные классы представляют ценность только для обратной совместимости.
Как вы сделали такой вывод?
как и половина других языков программирования.
А еще он создавался как шаблонизатор для Си. Это тоже будем вспоминать?
Не спорю, и он прекрасно с ними справляется. Как платформа. Но язык довольно неконсистентный, и в нем масса крайне сомнительных решений.
По поводу социальных потрясений — ну подождите лет так 50, и будут вам потрясения. От того так сложно общаться с кем-либо на эту тему — уж больно отдаленные перспективы и «мы не застанем».
Потому что опять же изменения происходят относительно медленно. Но кое какие последствия уже можно наблюдать. Например в следствии увеличения температуры уже наблюдается более сильные ураганы (их мощность зависит от температуры воды)
Ну и в долгосрочной перспективе в следствии изменения температуры океана, и как следствие, изменение градиентов солености воды ближе к полюсам, могут перестроиться океанические течения которые и работают за счет разности плотности воды в следствии разности солености.
Суть в том что увеличение средней температуры не означает что в целом будет теплее. Наоборот, будет больше разница температур. И в той же Европе, климат которой сильно зависит от гольфстрима, будет холоднее чем сегодня.
Я конечно не шарю во всех этих делах, но при желании исследования всего это гуглятся.
мне она не нужна, и биткойны никому не нужны. Но сама идея в целом крутая, и применение найти ей нет особо проблемы.
Проблема крипты — хайп вокруг, который как раз и разделяет все на два лагеря. И да, регулярно вижу какие-то тупые биткойн митапы где вся соль как раз таки и сводится к спекуляциях на курсе валют.
Меня такое не интересует.
> А вот ресурсов эта ерунда съест огромное количество.
ну вопрос оптимизаций. По идее не должна она уж столько ресурсов есть.
> Хоть бы уж тогда воду горячую делали бы, какая-никакая польза.
Да вроде как есть такие проекты уже)
Да, все так. Но не везде. Как пример "интересностей" посмотрите на Кению и их мобильные платежи. Не криптовалюты конечно, но прецедент как по мне неплохой.
Ну и, из той статистики которую мне удалось нагуглить (за 15-ый год) — 2.5 миллиарда людей не имеют доступа к банкам.
Никак не могу нагуглить статистику по потерям на межбанковских переводах… Если вкурсе поделитесь.
а вот отсюда наверное эти потери и берутся… не умеет ACID в распределенность.
Что бы устранить посредника в экономических сделках, разумеется. Разумеется для стран с развитой банковской системой "подвинуть" никого не выйдет, вот только это далеко не все страны.
Аналогия тут может быть очень простая — в развитых странах у вас сначала были телеграфные линии, затем поверх начали строить телефонные, затем инфраструктура для мобильной связи и интернета. И есть страны где, начали сразу с мобильной связи, так как другой инфраструктуры до этого у них не было.
Хочется пошутить что у вашей жизни тоже есть дэдлайн но думаю вы сами все прекрасно поняли.
p.s. почему-то ваш комментарий мне напомил отрывок из монти пайтона про анархо-синдикалистов.
Как же хорошо когда студенты технологи по какой-то картинке могут делать подобные выводы. И зачем нужны все эти сложнейшие климатические модели, анализ ледяных кернов для отслеживания динамики состава атмосферы, модели изменения океанических течений в следствии изменения солености воды… Можно ж было просто посмотреть карту.
p.s. А вот интересно, так сколько джоуелей? А ват сколько? И сколько там петават от солнышка прилетает (лучше наверное с учетом отражения)?
p.p.s. из того что сходу помню, но то что может подойти — Space Exploration is the Worst
вы фразу видимо не дочитали. PHP отличная платформа со своими изюминками (вроде умирающей модели выполнения, алицетворяющей феникса). Вот эта самая платформа и привлекает людей. Платформа, а не язык.
В возможно вы вовсе и не про язык а про интерпритатор говорили. В таком случае смысл вашего комментария для меня остается загадкой.
Как там говорится, прогресс движется в сторону интеропа языков и это хорошо.
еще раз, я против php как платформы ничего не имею, использую его на протяжении 10-ти лет. Но повторюсь, язык убогий.
посмотрите как в той же джаве можно красиво билдеры описать и грустите что подобного в php не будет. Нет, ну может быть вот это протащат и я тогда буду меньше ругаться, но…
А пока все эти "самый лучший интерпритатор" и прочие восхваления языка лишь вред ему несут.
А вот почему такая огромная разница с тем же amp (разве что парсинг http запросов силами php) — это для меня загадка.