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

I>>>>Кейс "на чом угодно" нужно исключить уже ради того, что бы у тебя был предсказуемый набор людей, иначе в команду придется добавить рекрутёра.
S>>>И тут мимо. Этот кейс как раз помогает найти людей, способных написать качественный код.
I>>Нам нужны разработчики не только на старте, а на всём времени жизни проекта.
I>>Вот стартовал ты прокт на баше.
S>И тебе тоже непонятна фраза "...на чом угодно... Да хоть на..."
S>Яснопонятно...

Наоборо — я говорю о том, что "на чом угодно" надо исключить, что бы на налететь на риски с поиском замены экзотического специалиста.

И вместо "на чом угодно" нужно брать "мейнстрим".

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

S>>>Дальше не читал. Вообще насрать. Потому что если программистам думать про деньги — получается говнокод.
НС>>Кто должен думать про деньги?
S>Не программисты.

Именно. Потому программисты крайне редко принимают такие решений, как выбор стека, т.к. такое решение это куча рисков связаных с именно с деньгами
1. команда, состав, уровень, количество
2. инфраструктура — состав, количество
3. риски найма == задержки деливери

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

I>Реальные альтернативы:
I>- руби
I>- питон
I>- C# — дико дорого
I>- Java — дико дорого
I>- Go — дико дорого


В чем дороговизна и отличие от первых двух в этом плане?

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

S>>Кто такой СТО? Старший/главный программист?
scf>CTO по-русски — это замдиректора по IT. Он планирует траты на IT в компании, защищает их перед генеральным и акционерами, осваивает эти деньги и отвечает за результат.

CTO -- это и есть директор IT.

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

I>>Реальные альтернативы:
I>>- руби
I>>- питон
S>I>- C# — дико дорого
I>>- Java — дико дорого
I>>- Go — дико дорого
S>

S>В чем дороговизна и отличие от первых двух в этом плане?

C#, Java, Go требуют гораздо бОльшего времени на освоение платформы. Соответсвенно, для простых задач это будет работать против тебя.

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

S>>>Кто такой СТО? Старший/главный программист?
scf>>CTO по-русски — это замдиректора по IT. Он планирует траты на IT в компании, защищает их перед генеральным и акционерами, осваивает эти деньги и отвечает за результат.

S>CTO -- это и есть директор IT.

В конторах, где любят слово "директор", СТО будет директором.
В конторах, где СЕО не любит конкурентов, или вышел из советской эпохи, СТО будет замом.
В конторах, где СЕО вышел из разработчиков и считает, что это круто, СТО будет разработчиком

Реальная роль такого человека это выстраивание пайплайна, по которому будут разрабатываться проекты/продукты с технической точки зрения.
Соответсвенно СТО может отдавать распоряжения вида "продукты в таком то домене пишем на баше, потому что так сказал шеридан на рсдн"
Тогда солюшн-архитектор учитывает все это.

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

I>C#, Java, Go требуют гораздо бОльшего времени на освоение платформы.

А разве платформу надо осваивать каждый раз, когда стартует написание очередного микросервиса?

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

S>>Он в одну голову, сам решения принимает или просит подчинённых провести аналитику, по результатам которой работает?

scf>Он руководитель, он несет ответственность за весь IT отдел. В том числе ответственность за то, что ему насоветуют подчиненные. Решение о делегировании полномочий тоже принимает он)
Говённый руководитель, относящийся к подчинённым как к рабам, а не как к профессионалам.

scf>Возвращаясь к исходной теме — выбор технологий, языков программирования, фреймворков жестко увязан с кадровой политикой и финансами. Поэтому в нормально управляемых компаниях никто не даст разработчикам/лидам самостоятельно выбирать язык и платформу.
Даст, если хочет результат, а не галеру сделать.

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

S>>Люди примут решения, стек, язык из того что предложишь ты, как профессионал. Так как тебя наняли для этого.
I>Ну да, спросили шеридана — он предложил баш/с++/перл. Как думаею, сколько времени ты будешь искать замену, когда уволится кто нибудь из этой команды?
Сразу же мимо.
Нет. Я профессионал. Я никогда не выбираю из личных предпочтений для проектов работодателя. Это своё я могу на чом угодно, а там я выберу наиболее подходящий для задачи стек, причом так, чтобы хотя бы несколько человек в нём понимало и умело.

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

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

S>>>>Дальше не читал. Вообще насрать. Потому что если программистам думать про деньги — получается говнокод.
НС>>>Кто должен думать про деньги?
S>>Не программисты.

I>Именно. Потому программисты крайне редко принимают такие решений, как выбор стека, ...
Дальше чтото про бабло и небесные кренделя.
Именно программисты должны принимать решение о выборе стека. Посоветовавшись с девопсами и админами. Коллегиально. А не некий манагер без понимания как вообще устроен компустер.
Руководитель должен написать ТЗ, хотя бы коаткое под новый проект и выдать на обсуждение, скажем на неделю. Соответственно не всем подряд, а опытным людям. Например, тимлидам.

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

Z>C# не имеет аналогов своего linq. Просто на голову выше всего остального, ничего подобного другие языки предложить не могут.
Искал что-то подобное для Java. Нашел JINQ. Похоже, что там лямбды в рантайме рефлекшеном анализируются
Единственная проблема: проект скорее мертв, чем жив

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

A>Единственная проблема: проект скорее мертв, чем жив

Есть еще одна, language integration позволяет писать сильно проще чем функциональный стиль. Если на одной таблице это не так заметно, то на джойнах все очень наглядно.

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

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

A>>Единственная проблема: проект скорее мертв, чем жив
Z>Есть еще одна, language integration позволяет писать сильно проще чем функциональный стиль. Если на одной таблице это не так заметно, то на джойнах все очень наглядно.

Для N:1 jinq знает сам как джойнить

cityStream
   .select( c -> c.getCountry().getName() ); // select t2.name from cities t1 join countries t2 on t1.countryId = t2.Id

Для N:N тоже знает, но там Pair появляется (хотя можно как-то на свои custom tuples мапить)

JinqStream<Pair<Country,City> pairs = countryStream
   .where( c -> c.getContinent().equals("Europe") )
   .joinList( c -> c.getCities() );

С большим количеством джойнов и т.п. будут ужасы Pair<Pair<Pair<..>>,...>, но, опять же, custom tuples могут помочь побороть вложенность.

Здравствуйте, Ночной Смотрящий, Вы писали:

I>>C#, Java, Go требуют гораздо бОльшего времени на освоение платформы.

НС>А разве платформу надо осваивать каждый раз, когда стартует написание очередного микросервиса?

Непонятно с чего ты мне этот вопрос задаёшь.

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

S>>>Люди примут решения, стек, язык из того что предложишь ты, как профессионал. Так как тебя наняли для этого.
I>>Ну да, спросили шеридана — он предложил баш/с++/перл. Как думаею, сколько времени ты будешь искать замену, когда уволится кто нибудь из этой команды?
S>Сразу же мимо.
S>Нет. Я профессионал. Я никогда не выбираю из личных предпочтений для проектов работодателя. Это своё я могу на чом угодно, а там я выберу наиболее подходящий для задачи стек, причом так, чтобы хотя бы несколько человек в нём понимало и умело.

Вот ты и объяснил разницу — своё можешь на чем хошь писать. А как только добавляем сюда бизнес, то появляются ограничения. И ты даже пример привел этого ограничения "что бы несколько человек понимало и умело"

На самом деле все сложнее — продукт придется мейнтейнить, развивать, скажем, лет пять, десять или даже больше. И тут всякие кейсы "стартовали на баше/С++/перле" дают геморрой до тех пор, пока не перепишешь на что вменяемое.

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

S>>>>>Дальше не читал. Вообще насрать. Потому что если программистам думать про деньги — получается говнокод.
НС>>>>Кто должен думать про деньги?
S>>>Не программисты.

I>>Именно. Потому программисты крайне редко принимают такие решений, как выбор стека, ...
S>Дальше чтото про бабло и небесные кренделя.
S>Именно программисты должны принимать решение о выборе стека.

С программистами есть проблема — по специфике работы они сидят в одном проекте/стеке/домене/команде, ну двух, от силы. Вот, скажем, ты сам даже почту свою не можешь настроить, что бы она чем-то внятным отвечала, а не ошибкой "всё пропало".

А вот скажем солюшн-архитект
1. не привязан к стеку
2. работает с разными проектами/стеками/доменами/командами

Фактически, солюшн архитект это менеджерская профессия, хотя и техническая при этом. Но это уже точно не разработчик.

СТО дополнительно получает сведения еще и о рынке труда, бюджетах, планах, работает над реализацией бизнес модели и тд.

Забавно посмотреть на твою эволюцию
1. стек должны выбирать админы
2. стек должны выбирать программисты

Вобщем, пройдет еще лет десять, и ты узнаешь, что решения о том, как тратить бабло, принимает именно тот, кто платит это бабло. А стек технологий это куча рисков связаных с этим самым баблом. Например — риски найма, о которых программисты вообще не в курсе.

Отсюда ясно, что у программистов есть квалификация писать, проектировать код, а вот выбор стека малюсенкая часть выбора "писать, не писать, заказать, купить лицензию, продукт, команду, бизнес, контору"

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

НС>>А разве платформу надо осваивать каждый раз, когда стартует написание очередного микросервиса?
I>Непонятно с чего ты мне этот вопрос задаёшь.

Ты заявил что C#/Java/Go это дорого, потому что их сложно осваивать. В реальности, однако, это никак не связанные процессы — у тебя уже есть команда, умеющая в C#/Java/Go, и ей не надо осваивать.
Или недорого это когда ты нанимаешь людей с абсолютно нулевым бекграундом?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Ты заявил что C#/Java/Go это дорого, потому что их сложно осваивать. В реальности, однако, это никак не связанные процессы — у тебя уже есть команда, умеющая в C#/Java/Go, и ей не надо осваивать.

Как так вышло, что у тебя есть именно эта команда? Кто ее набирал, под какие цели и почему набрали именно этих, а не тех, что имеют опыт вдвое меньше?


НС>Или недорого это когда ты нанимаешь людей с абсолютно нулевым бекграундом?

Это про кривую вхождения. Скажем, у нас кучка студенческих проектов пилится каждый год в целях обучения. И вот хронически выходит так, что дотнет/джава успевают только половину, когда на ноде успевают все.

Типичный кейс — ментор команды дотнета пытается объяснить фронтам как ихний бакенд собрать, развернуть, настроить. Вот почему то такой херни на ноде как то не выходит, все само работает. В итоге у одних фронт и бек друг о друге не знают даже на финише, а у других это есть прямо со старта.

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

НС>>Ты заявил что C#/Java/Go это дорого, потому что их сложно осваивать. В реальности, однако, это никак не связанные процессы — у тебя уже есть команда, умеющая в C#/Java/Go, и ей не надо осваивать.
I>Как так вышло, что у тебя есть именно эта команда?

У тебя есть именно та команда, которая есть. Куда интереснее почему ты решил, что ее нету, и почему ее нельзя нанять, если уж нету.

НС>>Или недорого это когда ты нанимаешь людей с абсолютно нулевым бекграундом?
I>Это про кривую вхождения.

Кривая вхождения — это для разработчика. А для компании нет никакой кривой, есть только стоимость специалиста в зависимости от платформы. Стоимость Java или C# разработчика существенно выше чем рубиста или питониста?

I>Скажем, у нас кучка студенческих проектов

Т.е. альтернатива "дорогим" жабе и шарпу — студенты? Ок, так понятно.

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

I>C#, Java, Go требуют гораздо бОльшего времени на освоение платформы. Соответсвенно, для простых задач это будет работать против тебя.
JS тоже требует время. И тоже немалого.
Специалисты получают примерно одинаково на любом языке. А вот джуниоры наговнят на любом языке.
Я бы выбрал C# c Native AOT http://rsdn.org/forum/flame.comp/8286600.1

Автор: Serginio1
Дата: 29.05.22

Легковесный, но со сборщиком мусора