Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Grienders Земля  
Дата: 25.04.15 07:51
Оценка: :)
http://www.reddit.com/r/haskell/comments/2useoq/haskell_opportunities_at_facebook/

Hi, friends –

I have a number of very interesting openings at Facebook HQ in Menlo Park, California. There are two different teams hiring.

The first set of positions are for an entirely new team. This project involves distributed systems, data mining, and machine learning. There may be roles on this team for less experienced candidates in a few months, but right now we are looking for people who have written a reasonable amount of Haskell, have built real production systems in some language or other (and have the scars to prove it), and can contribute in major ways to the design and construction of a demanding new system that we're building from scratch.

The second set of positions are for a cousin team, which is building on the success of our Haxl project to extend our capability to fight spam and malware. For these roles, we're open to a broader range of experience levels.

If you're interested, please drop me an email with a current CV.

Re: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: -n1l-  
Дата: 25.04.15 08:04
Оценка: -2 :))) :))) :))
Где-то у меня мелькала статья про лисп.
Парни создали софт, веб приложение используя лисп, а все остальные не могли за ними угнаться.
Так как они внедряли новые фичи со скоростью света.
Так вот, они говорили, про особый способ оценки опасности небольших конкурирующих компаний. Они смотрели джоб офферы на биржах работы
и их никогда не волновала компания нанимающая си, джава разработчиков, но они всерьез беспокоились если видели что-то хоть чуть-чуть пахнущее в сторону фп.
Кстати говоря лиспа они так и не встретили, в итоге выкинув конкурентов с рынка, а их самих купил yahoo. И в yahoo lisp до сих пор используется.
Подведу итог, на хаскель я сейчас смотрю как на супер оружие 21 века, со всеми этими паттерн матчингами и так далее.
Уже лежит книга по многопоточности на этом языке и уже читается другая по синтаксису.
Хаскель нужен, я так считаю.
Немерль, с которого я начал знакомтсво с фп, тоже.
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Jack128  
Дата: 25.04.15 08:35
Оценка: +1
Здравствуйте, -n1l-, Вы писали:

N>Где-то у меня мелькала статья про лисп.

N>Парни создали софт, веб приложение используя лисп, а все остальные не могли за ними угнаться.
N>Так как они внедряли новые фичи со скоростью света.
N>Так вот, они говорили, про особый способ оценки опасности небольших конкурирующих компаний. Они смотрели джоб офферы на биржах работы
N>и их никогда не волновала компания нанимающая си, джава разработчиков, но они всерьез беспокоились если видели что-то хоть чуть-чуть пахнущее в сторону фп.
N>Кстати говоря лиспа они так и не встретили, в итоге выкинув конкурентов с рынка, а их самих купил yahoo. И в yahoo lisp до сих пор используется.

ты читал про Paul Graham, но его детище уже давно переписано с лиспа.
Re[3]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: -n1l-  
Дата: 25.04.15 08:48
Оценка:
Да, точно. Переписано? Ну может быть, однако на тот момент его выбор повлиял очень сильно.
Re: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 25.04.15 10:41
Оценка: +6 -2
Здравствуйте, Grienders, Вы писали:

G>http://www.reddit.com/r/haskell/comments/2useoq/haskell_opportunities_at_facebook/


А теперь давай посмотрим на эту ситуацию с другой стороны. На эту/эти вакансии в ФБ так же придется сдавать зачет по алгоритмам, сортировать гномиков и заниматься другой аналогичной гомосятиной. Но, до кучи, тебе еще устроят зачет по Haskell! Это реально возможность, факт
Ты, похоже что, не понимаешь самого главного. Важен не инструмент, супер языка не было и пока не предвидится. А вот предметные области были, есть и будут.
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Grienders Земля  
Дата: 25.04.15 12:07
Оценка: +1
Здравствуйте, kaa.python, Вы писали:

KP>А теперь давай посмотрим на эту ситуацию с другой стороны. На эту/эти вакансии в ФБ так же придется сдавать зачет по алгоритмам, сортировать гномиков и заниматься другой аналогичной гомосятиной. Но, до кучи, тебе еще устроят зачет по Haskell! Это реально возможность, факт

KP>Ты, похоже что, не понимаешь самого главного. Важен не инструмент, супер языка не было и пока не предвидится. А вот предметные области были, есть и будут.

А на какую вакансию тебе не прийдется сдавать зачет по языку? Кодить-то после найма на чем прийдется?
Что же до сих пор перебираешь инструменты: Scala, Python, Swift, Rust и продолжаешь в них разочаровываться и снова искать, если давно это понял?

А, вообще, давно уже всем понятно, что ты любитель поспорить и оставить на собой последнее слово.
Re: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Joie de vivre  
Дата: 25.04.15 12:53
Оценка: +4 -1
Здравствуйте, Grienders, Вы писали:

G>http://www.reddit.com/r/haskell/comments/2useoq/haskell_opportunities_at_facebook/


Было интересно узнать доводы, а почему же именно Хаскель.
Про machine learning с data mining ничего не знаю, а если же смотреть на distributed systems, то

1. Сетевое программирование? Здесь только значение предметной области. Ничего принципиального нового хаскель тут не даст.
2. Многопоточность и т.п. может конечно на хаскеле и безопаснее чем на C/C++ и меньше букавок писать чем на java. Но дедлоки, гонки и их последствия и умение устранять приходят только с опытом. Сам хаскель конечно может как-то и уменьшит область возникновения таких ошибок и не даст появиться самым тривиальным из них, но баги, на поиск которых могут уйти недели, устранены автоматически языком/компилятором и чем-то там еще скорее всего не будут.
3. Основые проблемы, потенциальные бажные места в таких проектах? Здесь только опыт.
Re: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: neFormal Россия  
Дата: 25.04.15 16:32
Оценка:
Здравствуйте, Grienders, Вы писали:

G>http://www.reddit.com/r/haskell/comments/2useoq/haskell_opportunities_at_facebook/

G>

G>The first set of positions are for an entirely new team. This project involves distributed systems, data mining, and machine learning


у него довольно узкая область применения.
да, местами он нужен. но всех он заменить не сможет.
...coding for chaos...
Re: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Kolesiki  
Дата: 25.04.15 21:40
Оценка: 1 (1) +3 -5 :))) :)
Здравствуйте, Grienders, Вы писали:

G>haskell_opportunities_at_facebook/


Ребят, вы же взрослые люди, а поклоняетесь идолам как дикари! Что тут грандиозного, что протухающий фэйсбук (состоящий из дикой смеси школоло-эксгибиционистов и рекламных тролей) с какого-то перепугу решил поиграть в Хаскель?! Да хоть на Брэйнфаке пусть нанимают, с чего вы решили, что из этого можно делать какие-то выводы? Есть деньги, есть неопытный менеджер, обчитавшийся Интернета до "Хаскеля Головного Мозга" и вот результат — набирают отдельную команду для какого-то пилотного проекта с громкими баззвордами. Ни применимость Хаскеля в данной задаче, ни его преимущества перед другими языками не объяснены. Зато хорошо видно, что руководство вообще не шарит в программистских штуках — я бы им простил даже С++, но Хацкель... это проект на выброс, а его глава может прямо сейчас увольняться — ортогональные выходки в мэйнстриме дорого обходятся.
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Grienders Земля  
Дата: 26.04.15 01:31
Оценка:
Здравствуйте, Kolesiki, Вы писали:

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


G>>haskell_opportunities_at_facebook/


K>Ребят, вы же взрослые люди, а поклоняетесь идолам как дикари! Что тут грандиозного, что протухающий фэйсбук (состоящий из дикой смеси школоло-эксгибиционистов и рекламных тролей) с какого-то перепугу решил поиграть в Хаскель?! Да хоть на Брэйнфаке пусть нанимают, с чего вы решили, что из этого можно делать какие-то выводы? Есть деньги, есть неопытный менеджер, обчитавшийся Интернета до "Хаскеля Головного Мозга" и вот результат — набирают отдельную команду для какого-то пилотного проекта с громкими баззвордами. Ни применимость Хаскеля в данной задаче, ни его преимущества перед другими языками не объяснены. Зато хорошо видно, что руководство вообще не шарит в программистских штуках — я бы им простил даже С++, но Хацкель... это проект на выброс, а его глава может прямо сейчас увольняться — ортогональные выходки в мэйнстриме дорого обходятся.


может, это не тот проект, на который набирали
https://code.facebook.com/posts/302060973291128/open-sourcing-haxl-a-library-for-haskell/
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 26.04.15 04:55
Оценка: +3 -1
Здравствуйте, -n1l-, Вы писали:

N>Парни создали софт, веб приложение используя лисп, а все остальные не могли за ними угнаться.

N>Так как они внедряли новые фичи со скоростью света.

И где же эти парни? Почему про их проект не гремит всемирная слава?
Re[3]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Слава  
Дата: 26.04.15 07:10
Оценка: +1 :))
Здравствуйте, CreatorCray, Вы писали:

CC>И где же эти парни? Почему про их проект не гремит всемирная слава?


Есть множество парней, достигших успеха, но вы о них не знаете и не узнаете никогда.
Re[3]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: -n1l-  
Дата: 26.04.15 08:31
Оценка:
На вики красуются, а их проект стал всеминоизвестным yahoo store
Re[3]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: trop Россия  
Дата: 26.04.15 08:33
Оценка:
Здравствуйте, Grienders, Вы писали:
G>может, это не тот проект, на который набирали
G>

hxt с комбинаторами гораздо прикольнее,
приходилось преобразовывать схемы yed — стрелки, комбинаторы,
а как всё это писать на императивных языках даже думать не хочется
-
Re[4]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 26.04.15 09:31
Оценка:
Здравствуйте, -n1l-, Вы писали:

N>На вики красуются, а их проект стал всеминоизвестным yahoo store

А, слава уже отгремела.
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.04.15 19:34
Оценка: +1
Здравствуйте, -n1l-, Вы писали:

N>Кстати говоря лиспа они так и не встретили, в итоге выкинув конкурентов с рынка, а их самих купил yahoo. И в yahoo lisp до сих пор используется.


Точнее Яха взял и переписал лисповый код на плюсах потому что не смог найти команду лисперов, кто бы мог майнтейнить.
Re[5]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 27.04.15 19:39
Оценка: 1 (1)
Здравствуйте, CreatorCray, Вы писали:

N>>На вики красуются, а их проект стал всеминоизвестным yahoo store

CC>А, слава уже отгремела.

Очень известная история была, небольшая команда в один момент превратилась в кучку миллионеров. Это было почти 20 лет назад, навроде как

Яха, правда, переписал весь лисп на с++ и умело похоронил маркетингом.
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Sharov Россия  
Дата: 27.04.15 20:48
Оценка:
Здравствуйте, Joie de vivre, Вы писали:

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


G>>http://www.reddit.com/r/haskell/comments/2useoq/haskell_opportunities_at_facebook/


JDV>Было интересно узнать доводы, а почему же именно Хаскель.


Туда перешел некто Симон Марлоу (Simon Marlow), ну и видимо будут что-то
пилить под нужды мордокнижия.
Кодом людям нужно помогать!
Re[6]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 27.04.15 21:08
Оценка: +4
Здравствуйте, Ikemefula, Вы писали:

I>Очень известная история была, небольшая команда в один момент превратилась в кучку миллионеров. Это было почти 20 лет назад, навроде как

А при чём тут лисп? Удачная идея была удачно продана.
Re[7]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.04.15 06:43
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

I>>Очень известная история была, небольшая команда в один момент превратилась в кучку миллионеров. Это было почти 20 лет назад, навроде как

CC>А при чём тут лисп? Удачная идея была удачно продана.

Товарищи написали всё на лиспе.
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Yoriсk  
Дата: 28.04.15 06:56
Оценка: +5 :)
Здравствуйте, Ikemefula, Вы писали:

CC>>А при чём тут лисп? Удачная идея была удачно продана.

I>Товарищи написали всё на лиспе.

А еще они все пили воду и носили штаны. За штанами будущее!
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.04.15 07:51
Оценка: +1 -1
Здравствуйте, Yoriсk, Вы писали:

CC>>>А при чём тут лисп? Удачная идея была удачно продана.

I>>Товарищи написали всё на лиспе.

Y>А еще они все пили воду и носили штаны. За штанами будущее!


Ты что сказать хотел ?
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 28.04.15 08:00
Оценка: +4
Здравствуйте, Ikemefula, Вы писали:

I>>>Очень известная история была, небольшая команда в один момент превратилась в кучку миллионеров. Это было почти 20 лет назад, навроде как

CC>>А при чём тут лисп? Удачная идея была удачно продана.
I>Товарищи написали всё на лиспе.

Продают не код, продают идею и/или клиентскую базу. Пофигу на чём был написан прототип, купившему надо чтобы купленная идея продолжила работать уже внутри имеющейся инфраструктуры купившего.
Поэтому на чём оно там было написано вообще ничего не решает.
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.04.15 08:15
Оценка: +1
Здравствуйте, CreatorCray, Вы писали:

CC>>>А при чём тут лисп? Удачная идея была удачно продана.

I>>Товарищи написали всё на лиспе.

CC>Продают не код, продают идею и/или клиентскую базу.


Ты получил ответ на вопрос "А при чём тут лисп" ?

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

CC>Поэтому на чём оно там было написано вообще ничего не решает.

Вот как откроешь своё дело, попробуй продавать идеи без единой строчки кода.
Эти товарищи обеспечили себе успех благодаря лиспу. Собственно, это факт.

Если ты хочешь порассуждать на тему "главное в яблоке это цвет и кожура", то это не ко мне.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Sinclair Россия https://github.com/evilguest/
Дата: 28.04.15 11:56
Оценка: 2 (1) +13 -1
Здравствуйте, Ikemefula, Вы писали:

I>Если ты хочешь порассуждать на тему "главное в яблоке это цвет и кожура", то это не ко мне.

Успех им обеспечило то, что они взяли знакомый им инструмент. Пока конкуренты осваивали Яву и писали фидбек её авторам, старички пилили Лисп со скоростью опытной машинистки. И не потому, что Лисп круче, а потому, что кроме Лиспа они ничем не владели. Владели бы они Фортраном — вы бы сейчас писали "о, надо писать веб-магазины на Фортране".
Если вы хотите скопировать их успех, не надо копировать Лисп. Надо копировать подход "если у вас есть бизнес-идея, пилите её на знакомом вам инструменте, в котором вы уверены".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 28.04.15 14:59
Оценка: :)
Здравствуйте, Sinclair, Вы писали:

I>>Если ты хочешь порассуждать на тему "главное в яблоке это цвет и кожура", то это не ко мне.


S>Успех им обеспечило то, что они взяли знакомый им инструмент. Пока конкуренты осваивали Яву и писали фидбек её авторам, старички пилили Лисп со скоростью опытной машинистки. И не потому, что Лисп круче, а потому, что кроме Лиспа они ничем не владели. Владели бы они Фортраном — вы бы сейчас писали "о, надо писать веб-магазины на Фортране".


Это уже дело десятое. Понятно, что продукт, контору, бренд и тд создаёт предприниматель, а не технарь, но ведь разговор был не про это.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 28.04.15 20:48
Оценка: +3
Здравствуйте, Ikemefula, Вы писали:

I>Ты получил ответ на вопрос "А при чём тут лисп" ?

Да. Лисп тут вообще ни при делах.

I>Вот как откроешь своё дело, попробуй продавать идеи без единой строчки кода.

Хехе. "Сперва добейся", ага.
Ну вот продали как то наш стартап. С кодом, от которого уже почти ничего не осталось, почти весь уже переписан.
Какая разница на чём он был написан изначально? Главное там была идея а не конкретная реализация.

I>Эти товарищи обеспечили себе успех благодаря лиспу. Собственно, это факт.

Дада, а мы обеспечили себе успех исключительно благодаря С, С++ и С#.
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.04.15 06:41
Оценка: +1 -1
Здравствуйте, CreatorCray, Вы писали:

I>>Ты получил ответ на вопрос "А при чём тут лисп" ?

CC>Да. Лисп тут вообще ни при делах.

Я понял твою идею, они написали всё на С++ а потом наврали про Лисп.

CC>Какая разница на чём он был написан изначально? Главное там была идея а не конкретная реализация.


Идея без конкретной реализации ничего не стоит, вообще.

I>>Эти товарищи обеспечили себе успех благодаря лиспу. Собственно, это факт.

CC>Дада, а мы обеспечили себе успех исключительно благодаря С, С++ и С#.

И что тебя смущает ?
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 29.04.15 09:06
Оценка: +1
Здравствуйте, Ikemefula, Вы писали:

I>>>Ты получил ответ на вопрос "А при чём тут лисп" ?

CC>>Да. Лисп тут вообще ни при делах.
I>Я понял твою идею, они написали всё на С++ а потом наврали про Лисп.

Нет, ты ничего похоже так и не понял.

CC>>Какая разница на чём он был написан изначально? Главное там была идея а не конкретная реализация.

I>Идея без конкретной реализации ничего не стоит, вообще.

Язык, на котором реализована идея — тоже ничего не стоит.

I>>>Эти товарищи обеспечили себе успех благодаря лиспу. Собственно, это факт.

CC>>Дада, а мы обеспечили себе успех исключительно благодаря С, С++ и С#.
I>И что тебя смущает?

Меня ничего не смущает. Я прекрасно знаю что язык был ни при чём. Я знаю что нас купили из-за работающей идеи а не того кода, что был написан.
Re[13]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Sharov Россия  
Дата: 29.04.15 09:33
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Я знаю что нас купили из-за работающей идеи а не того кода, что был написан.


Если не секрет, "нас" этого кого?
Кодом людям нужно помогать!
Re[14]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 29.04.15 09:35
Оценка:
Здравствуйте, Sharov, Вы писали:

CC>>Я знаю что нас купили из-за работающей идеи а не того кода, что был написан.

S>Если не секрет, "нас" этого кого?

нас == стартап со всем прилагающимся.
Re[15]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Sharov Россия  
Дата: 29.04.15 10:03
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>нас == стартап со всем прилагающимся.


Это понятно, предметная область какая?
Кодом людям нужно помогать!
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: BulatZiganshin  
Дата: 29.04.15 11:08
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Продают не код, продают идею и/или клиентскую базу. Пофигу на чём был написан прототип, купившему надо чтобы купленная идея продолжила работать уже внутри имеющейся инфраструктуры купившего.

CC>Поэтому на чём оно там было написано вообще ничего не решает.

как ты думаешь, если бы они писали на браинфаке, они бы тоже добились успеха?
Люди, я люблю вас! Будьте бдительны!!!
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: -n1l-  
Дата: 29.04.15 17:32
Оценка: :))) :))
Не аргумент, на шарпе, хоть он не и знаком, я бы делал это дольше в разы.
Попрограммировав чуть-чуть на лисп, я понял, что он потрясающий.
У меня даже стиль изложения изменился.
Re[13]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.04.15 18:39
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>>>Какая разница на чём он был написан изначально? Главное там была идея а не конкретная реализация.

I>>Идея без конкретной реализации ничего не стоит, вообще.

CC>Язык, на котором реализована идея — тоже ничего не стоит.


Наоборот. Язык уже давно доказал свою пригодность. Скажем, в то время многие пилили аналогичные проекты.
Там тоже использовали ту же идею и тоже использовали привычные инструменты.

I>>И что тебя смущает?


CC>Меня ничего не смущает. Я прекрасно знаю что язык был ни при чём. Я знаю что нас купили из-за работающей идеи а не того кода, что был написан.


И что, идея работала сама по себе, без вашего кода ? Ну и фантазёр же ты.
Re[15]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 29.04.15 18:41
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>>>Я знаю что нас купили из-за работающей идеи а не того кода, что был написан.

S>>Если не секрет, "нас" этого кого?

CC>нас == стартап со всем прилагающимся.


Что именно за софт ?
Re[16]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 02.05.15 16:47
Оценка:
Здравствуйте, Sharov, Вы писали:

CC>>нас == стартап со всем прилагающимся.

S>Это понятно, предметная область какая?

Storage.
Re[16]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 02.05.15 16:47
Оценка: 2 (1)
Здравствуйте, Ikemefula, Вы писали:

CC>>нас == стартап со всем прилагающимся.

I>Что именно за софт ?

Storage virtualization.
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 02.05.15 17:55
Оценка: +2
Здравствуйте, CreatorCray, Вы писали:

CC>>>нас == стартап со всем прилагающимся.

I>>Что именно за софт ?

CC>Storage virtualization.


Я знаю несколько контор в которых пилилась всякая разная виртуализация. Что интересно, ни одна не выстрелила. Хотя везде её пилили люди на привычных им инструментах, в т.ч., скажем, дотнет и джава. Идея ясна ?

Если идея это всё что надо, очень странно, что проект выстрелил только у вас.
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Sharov Россия  
Дата: 02.05.15 20:03
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Storage.


Это многое объясняет.
Кодом людям нужно помогать!
Re[18]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 03.05.15 06:27
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Я знаю несколько контор в которых пилилась всякая разная виртуализация. Что интересно, ни одна не выстрелила. Хотя везде её пилили люди на привычных им инструментах, в т.ч., скажем, дотнет и джава. Идея ясна ?

Пилить системщину только на шарпе или Java как то уж очень необычно.

I>Если идея это всё что надо, очень странно, что проект выстрелил только у вас.

Может потому, что идея ещё должна быть хорошей?
Re[18]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 03.05.15 06:27
Оценка:
Здравствуйте, Sharov, Вы писали:

CC>>Storage.

S>Это многое объясняет.

Любопытно, что именно?
Re[19]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Sharov Россия  
Дата: 03.05.15 13:30
Оценка:
Здравствуйте, CreatorCray, Вы писали:

CC>Любопытно, что именно?


Прощу прощения, я не видел раннего комментария про storage virtualization.
Все ясно, благодарю.
Кодом людям нужно помогать!
Re[19]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 04.05.15 07:53
Оценка: +1 -1
Здравствуйте, CreatorCray, Вы писали:

I>>Я знаю несколько контор в которых пилилась всякая разная виртуализация. Что интересно, ни одна не выстрелила. Хотя везде её пилили люди на привычных им инструментах, в т.ч., скажем, дотнет и джава. Идея ясна ?

CC>Пилить системщину только на шарпе или Java как то уж очень необычно.

Ну как же, зато инструмент привычный и всё такое.

I>>Если идея это всё что надо, очень странно, что проект выстрелил только у вас.

CC>Может потому, что идея ещё должна быть хорошей?

Ога.

Хорошая идея с кривой реализацией -> говно, которое никому не нужно.
Идея без реализации -> говно
Хорошая реализация с кривой идеей -> говно

Вроде понятно, что нужен правильный баланс, так сказать, гармония. А тебя послушать, так оказывается, что идея это всё, а на реализацию можно забить. Смотри свои же слова про шарп и джаву — ты споришь, что характерно, сам с собой
Re[20]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: CreatorCray  
Дата: 04.05.15 21:40
Оценка:
Здравствуйте, Ikemefula, Вы писали:

I>Ну как же, зато инструмент привычный и всё такое.

Кроме привычности инструмент должен ещё быть подходящим к предметной области.
Неэффективно пытаться писать код в системное ядро на js и веб скрипты на ассемблере.

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

Мой поинт в том, что язык реализации — третьестепенен.
Re[21]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ikemefula Беларусь http://blogs.rsdn.org/ikemefula
Дата: 05.05.15 04:38
Оценка: 2 (1) +2
Здравствуйте, CreatorCray, Вы писали:

I>>Ну как же, зато инструмент привычный и всё такое.

CC>Кроме привычности инструмент должен ещё быть подходящим к предметной области.
CC>Неэффективно пытаться писать код в системное ядро на js и веб скрипты на ассемблере.

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

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

CC>Мой поинт в том, что язык реализации — третьестепенен.

Ты сам себя опроверг чуть выше
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 16.06.22 16:43
Оценка: :)
Здравствуйте, -n1l-, Вы писали:

N>Кстати говоря лиспа они так и не встретили, в итоге выкинув конкурентов с рынка, а их самих купил yahoo. И в yahoo lisp до сих пор используется.


Похоже, так написали, что до сих пор тот код не смогли выбросить.

N>Подведу итог, на хаскель я сейчас смотрю как на супер оружие 21 века, со всеми этими паттерн матчингами и так далее.

N>Уже лежит книга по многопоточности на этом языке и уже читается другая по синтаксису.

Выбрось.

Смотри сюда: https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/haskell.html
Все что тебе надо, это понять примеры по ссылкам. Вот, например,
https://benchmarksgame-team.pages.debian.net/benchmarksgame/program/regexredux-ghc-3.html
import Foreign.C.Types
import qualified Data.Vector.Storable as V
import qualified Data.Vector.Storable.Mutable as M
import Foreign.Ptr
import Foreign.Marshal.Alloc
import Data.Word
import Control.Monad
import Foreign.Storable
import System.IO
import Control.Concurrent
import Data.Foldable
import Data.Char

-- first some foreign imports (Haskell does not have a proper pcre2 binding!)

foreign import capi "pcre2.h value PCRE2_JIT_COMPLETE"
  c_PCRE2_JIT_COMPLETE :: CUInt

foreign import ccall "pcre2.h pcre2_get_ovector_pointer_8"
  c_pcre2_get_ovector_pointer :: Ptr MatchData -> IO (Ptr CSize)

foreign import ccall "pcre2.h pcre2_compile_8"
  c_pcre2_compile :: Ptr CChar -> CSize -> CInt -> Ptr CInt -> Ptr CSize
    -> Ptr () -> IO (Ptr Code)

foreign import ccall "pcre2.h pcre2_jit_compile_8"
  c_pcre2_jit_compile :: Ptr Code -> CUInt -> IO ()

-- This one is marked unsafe for extra performance.
-- See https://wiki.haskell.org/Performance/FFI
foreign import ccall unsafe "pcre2.h pcre2_jit_match_8"
  c_pcre2_jit_match :: Ptr Code -> Ptr CChar -> CSize -> CSize -> CUInt
    -> Ptr MatchData -> Ptr MatchContext -> IO CInt

foreign import ccall "pcre2.h pcre2_code_free_8"
  c_pcre2_code_free :: Ptr Code -> IO ()

foreign import ccall "pcre2.h pcre2_match_context_create_8"
  c_pcre2_match_context_create :: Ptr GeneralContext -> IO (Ptr MatchContext)

foreign import ccall "pcre2.h pcre2_jit_stack_create_8"
  c_pcre2_jit_stack_create :: CSize -> CSize -> Ptr () -> IO (Ptr JitStack)

foreign import ccall "pcre2.h pcre2_jit_stack_assign_8"
  c_pcre2_jit_stack_assign :: Ptr MatchContext -> Ptr () -> Ptr JitStack
    -> IO ()

foreign import ccall "pcre2.h pcre2_match_data_create_8"
  c_pcre2_match_data_create :: CUInt -> Ptr GeneralContext
    -> IO (Ptr MatchData)

foreign import ccall "pcre2.h pcre2_match_context_free_8"
  c_pcre2_match_context_free :: Ptr MatchContext -> IO ()

foreign import ccall "pcre2.h pcre2_jit_stack_free_8"
  c_pcre2_jit_stack_free :: Ptr JitStack -> IO ()

foreign import ccall "pcre2.h pcre2_match_data_free_8"
  c_pcre2_match_data_free :: Ptr MatchData -> IO ()

data MatchData
data MatchContext
data Code
data GeneralContext
data JitStack

data GrowString = GrowString
  {-# UNPACK #-} !(M.IOVector Word8)
  {-# UNPACK #-} !Int

-- Freeze and trim
freezeGrowString :: GrowString -> IO (V.Vector Word8)
freezeGrowString (GrowString dat siz) = V.unsafeFreeze (M.slice 0 siz dat)

-- Function for searching a srcString for a pattern, replacing it with some
-- specified replacement, and storing the result in dstString.
--
-- dstString might be reallocated so this function returns a new GrowString.
-- For optimal performance you should not use the old GrowString anymore.
replace :: V.Vector Word8 -> V.Vector Word8 -> V.Vector Word8
  -> GrowString -> Ptr MatchContext -> Ptr MatchData -> IO GrowString
replace !pattern !replacement !srcString !dstString !mcontext !mdata =
  alloca $ \errorCode -> alloca $ \errorOffset -> do
    match <- c_pcre2_get_ovector_pointer mdata

    -- Compile and study pattern.
    regex <- V.unsafeWith pattern $ \patternPtr -> c_pcre2_compile
      (castPtr patternPtr) (fromIntegral (V.length pattern)) 0 errorCode
      errorOffset nullPtr
    c_pcre2_jit_compile regex c_PCRE2_JIT_COMPLETE

    -- Find each match of the pattern in srcString and append the characters
    -- preceding each match and the replacement text to dstString.
    let
      go !pos !dstString = do
        !x <- V.unsafeWith srcString $ \srcStringPtr ->
          c_pcre2_jit_match regex (castPtr srcStringPtr)
            (fromIntegral srcStringLen) (fromIntegral pos) 0 mdata mcontext
        if (x >= 0) then do
          !match0 <- fromIntegral <$> peekElemOff match 0

          -- Allocate more memory for dstString if there is not enough space
          -- for the characters preceding the match and the replacement text.
          let
            growLoop str@(GrowString !dat !siz)
              | siz + match0 - pos + replacementSize > M.length dat = do
                !dat' <- M.grow dat (M.length dat) :: IO (M.IOVector Word8)
                growLoop (GrowString dat' siz)
              | otherwise = return str
          (GrowString dat siz) <- growLoop dstString

          -- Append the characters preceding the match and the replacement text
          -- to dstString and update the size of dstString.
          let
            !siz' = siz + match0 - pos
            !siz'' = siz' + replacementSize
          V.copy (M.slice siz  (match0 - pos)  dat)
            (V.slice pos (match0 - pos) srcString)
          V.copy (M.slice siz' replacementSize dat) replacement

          -- Find the new pos to continue after the current match.
          !pos' <- fromIntegral <$> peekElemOff match 1

          go pos' (GrowString dat siz'')
        else return (pos, dstString)
    (!pos, !dstString') <- go 0 dstString

    c_pcre2_code_free regex

    -- Allocate more memory for dstString if there is not enough space for the
    -- characters following the last match (or the entire srcString if there
    -- was no match).
    let
      growLoop str@(GrowString !dat !siz)
        | siz + srcStringLen - pos > M.length dat = do
          dat' <- M.grow dat (M.length dat) :: IO (M.IOVector Word8)
          growLoop (GrowString dat' siz)
        | otherwise = return str
    (GrowString dat siz) <- growLoop dstString'

    -- Append the characters following the last match (or the entire srcString
    -- if there was no match) to dstString and update the size of dstString.
    V.copy (M.slice siz (srcStringLen - pos) dat)
      (V.slice pos (srcStringLen - pos) srcString)

    return (GrowString dat (siz + srcStringLen - pos))
  where
    srcStringLen = V.length srcString
    replacementSize = V.length replacement

main :: IO ()
main = do
  let
    f = V.fromList . map (fromIntegral . ord)
    countInfo = map f
      [ "agggtaaa|tttaccct"
      , "[cgt]gggtaaa|tttaccc[acg]"
      , "a[act]ggtaaa|tttacc[agt]t"
      , "ag[act]gtaaa|tttac[agt]ct"
      , "agg[act]taaa|ttta[agt]cct"
      , "aggg[acg]aaa|ttt[cgt]ccct"
      , "agggt[cgt]aa|tt[acg]accct"
      , "agggta[cgt]a|t[acg]taccct"
      , "agggtaa[cgt]|[acg]ttaccct"
      ]
    replaceInfo = map (\(a,b) -> (f a, f b))
      [ ("tHa[Nt]", "<4>")
      , ("aND|caN|Ha[DS]|WaS", "<3>")
      , ("a[NSt]|BY", "<2>")
      , ("<[^>]*>", "|")
      , ("\\|[^|][^|]*\\|", "-")
      ]

  input <- (\x -> GrowString x 0) <$> M.new 16384
  sequences <- (\x -> GrowString x 0) <$> M.new 16384

  -- Read in input from stdin until we reach the end or encounter an error.
  let
    readLoop (GrowString !dat !siz) = do
      bytesRead <- M.unsafeWith (M.slice siz (M.length dat - siz) dat)
        $ \inputPtr -> hGetBuf stdin inputPtr (M.length dat - siz)
      if bytesRead > 0 then do
        -- update the size of input to reflect the newly read input and if
        -- we've reached the full capacity of the input string then also double
        -- its size.
        dat' <- if (siz + bytesRead == M.length dat)
          then M.grow dat (M.length dat) :: IO (M.IOVector Word8)
          else return dat
        readLoop (GrowString dat' (siz + bytesRead))
      else return (GrowString dat siz)
  input' <- freezeGrowString =<< readLoop input
  let !inputSiz = V.length input'

  let
    threadInit = do
      mcontext <- c_pcre2_match_context_create nullPtr
      stack <- c_pcre2_jit_stack_create 16384 16384 nullPtr
      c_pcre2_jit_stack_assign mcontext nullPtr stack
      mdata <- c_pcre2_match_data_create 16 nullPtr
      return (mcontext, stack, mdata)
  (mcontext, stack, mdata) <- threadInit

  -- Find all sequence descriptions and new lines in input, replace them with
  -- empty strings, and store the result in the sequences string.
  sequences'@(GrowString seqDat seqSiz) <-
    replace (f ">.*\\n|\\n") (f "") input' sequences mcontext mdata

  -- Work on performing all the replacements serially.
  replaceVar <- newEmptyMVar
  -- Fork this thread explicitely to capability 0 to discourage the scheduler
  -- from interrupting this thread.
  forkOn 0 $ do
    -- We'll use two strings when doing all the replacements, searching for
    -- patterns in prereplaceString and using postreplaceString to store the
    -- string after the replacements have been made. After each iteration these
    -- two then get swapped. Start out with both strings having the same
    -- capacity as the sequences string and also copy the sequences string into
    -- prereplaceString for the initial iteration.
    prereplaceString <- (\x -> GrowString x seqSiz) <$> M.clone seqDat
    postreplaceString <- (\x -> GrowString x 0) <$> M.new (M.length seqDat)

    -- Iterate through all the replacement patterns and their replacements in
    -- replaceInfo
    let
      cons (pre@(GrowString dat _),post) (a,b) = do
        dat' <- freezeGrowString pre
        post' <- replace a b dat' post mcontext mdata
        let pre' = (GrowString dat 0)
        -- Swap pre and post in the next iteration.
        return (post', pre')
    -- If any replacements were made, they'll be in the fst element of the
    -- tuple instead of the second because of the swap done at the end of each
    -- iteration.
    (GrowString _ !siz, _) <- foldlM cons
      (prereplaceString, postreplaceString) replaceInfo

    c_pcre2_match_context_free mcontext
    c_pcre2_jit_stack_free stack
    c_pcre2_match_data_free mdata

    putMVar replaceVar siz

  -- Iterate through all the count patterns in countInfo and perform the
  -- counting for each one on a different thread if available.
  first <- newMVar ()
  rest <- replicateM (length countInfo) newEmptyMVar

  for_ (zip3 countInfo (first : rest) rest) $ \(pattern, prev, next) ->
    forkIO $ do
      (mcontext, stack, mdata) <- threadInit
      match <- c_pcre2_get_ovector_pointer mdata

      -- Compile and study pattern.
      regex <- alloca $ \errorCode -> alloca $ \errorOffset ->
        V.unsafeWith pattern $ \patternPtr -> c_pcre2_compile
          (castPtr patternPtr) (fromIntegral (V.length pattern)) 0 errorCode
          errorOffset nullPtr
      c_pcre2_jit_compile regex c_PCRE2_JIT_COMPLETE

      -- Find each match of the pattern in the sequences string and increment
      -- count for each match.
      let
        go !count !pos = do
          x <- M.unsafeWith dat $ \datPtr -> c_pcre2_jit_match regex
            (castPtr datPtr) (fromIntegral siz) pos 0 mdata mcontext
          if x >= 0 then do
            -- Find the new pos to continue searching after the current match.
            pos' <- peekElemOff match 1
            go (count + 1) pos'
          else return count
          where
            (GrowString dat siz) = sequences'
      count <- go 0 0

      c_pcre2_code_free regex

      -- Print the count for each pattern in the correct order.
      takeMVar prev
      V.unsafeWith pattern $ \patternPtr ->
        hPutBuf stdout patternPtr (V.length pattern)
      putStr " "
      print count
      putMVar next ()

      c_pcre2_match_context_free mcontext
      c_pcre2_jit_stack_free stack
      c_pcre2_match_data_free mdata

  siz <- takeMVar (replaceVar)

  takeMVar (last rest)

  -- Print the size of the original input, the size of the input without the
  -- sequence descriptions & new lines, and the size after having made all the
  -- replacements.
  putStrLn ""
  print inputSiz
  print seqSiz
  print siz
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.06.22 19:28
Оценка: +1
Здравствуйте, -n1l-, Вы писали:

N>Где-то у меня мелькала статья про лисп.

N>Парни создали софт, веб приложение используя лисп, а все остальные не могли за ними угнаться.
N>Так как они внедряли новые фичи со скоростью света.

Эти ребята назывались Paul Graham, Robert Morris и Trevor Blackwell а их приложение называлось Viaweb.

Yahoo купило их поделие за 49 миллионов баксов и переименовало в Yahoo! Store. A Paul Graham стал властителем человеческих дум, написал кучу эссе, которые принято считать непреложной истиной, и даже основал компанию YCombinator, которая вкладывает небольшие денежки в IT стартапы и форматирует мозги их основателям. Получить деньги от YCombinator'а считается столь почетным, что никто, на самом деле, не решается их тратить, а засовывают чек в рамочку, вешают на стену и с гордостью всем показывают. Миллионеры, увидев на стене чек от YCombinator'а в рамочке, сразу падают в обморок, а придя в себя, не задумываясь выдают такому стартапу настоящих уже денег на развитие и карманные расходы.

N>Кстати говоря лиспа они так и не встретили, в итоге выкинув конкурентов с рынка, а их самих купил yahoo. И в yahoo lisp до сих пор используется.


Я слышал, краем уха, что Yahoo вроде в конечном итоге переписало это поделие на нормальном языке. Но могу и ошибаться.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.06.22 19:30
Оценка: 2 (1) +3
Здравствуйте, Ikemefula, Вы писали:

Y>>А еще они все пили воду и носили штаны. За штанами будущее!


I>Ты что сказать хотел ?


Он хотел сказать, что может они и не из-за лиспа преуспели, а просто повезло сделать удачную штучку, не важно на чем.
Re[3]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: vsb Казахстан  
Дата: 16.06.22 19:47
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Я слышал, краем уха, что Yahoo вроде в конечном итоге переписало это поделие на нормальном языке. Но могу и ошибаться.


Не ошибаешься.

А вообще я так и не понял фишки лиспа, хотя я даже его компилятор писал (не дописал, но тему изучил достаточно, чтобы представлять себе всё, что надо). Обычный язык. Ничем от джавы не отличается принципиально. Любой код можно плюс-минус одинаково перенести. Есть некоторые головодробительные концепции вроде continuations (даже не уверен, что они есть в общем лиспе), но на практике они особо не нужны и заменяются другими концепциями. Ну единственное, чем отличается лисп от других языков — нормальные его реализации стоят абсолютно диких денег. Может потому его и пиарят — типа раз заплатили такие деньги, стыдно себе признаться, что бесплатная жмв с идеей за 100 баксов гораздо круче.

А жаваскрипт вообще один в один лисп. Только вместо s-выражений — c-подобный синтаксис.
Отредактировано 16.06.2022 19:48 vsb . Предыдущая версия .
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Michael7 Россия  
Дата: 16.06.22 20:10
Оценка: +1
Здравствуйте, Sinclair, Вы писали:

S>Успех им обеспечило то, что они взяли знакомый им инструмент. Пока конкуренты осваивали Яву и писали фидбек её авторам, старички пилили Лисп со скоростью опытной машинистки. И не потому, что Лисп круче, а потому, что кроме Лиспа они ничем не владели. Владели бы они Фортраном — вы бы сейчас писали "о, надо писать веб-магазины на Фортране".


Ну нет, лисп таки крут был своим метапрограммированием, да и сейчас неплох. Собственно многие фичи лиспа и фп с тех пор проникли в мейнстрим от C++ до Javascript и C# и совсем не случайно. В 90-е же мейнстрим куда убоже был.

S>Если вы хотите скопировать их успех, не надо копировать Лисп. Надо копировать подход "если у вас есть бизнес-идея, пилите её на знакомом вам инструменте, в котором вы уверены".


Ну это тоже верно конечно. Но и выбор инструмента имеет все же очень важное значение.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.06.22 22:16
Оценка:
Здравствуйте, -n1l-, Вы писали:

N>Не аргумент, на шарпе, хоть он не и знаком, я бы делал это дольше в разы.

N>Попрограммировав чуть-чуть на лисп, я понял, что он потрясающий.
N>У меня даже стиль изложения изменился.

Да, ты теперь всегда в уме подсчитываешь скобки.
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 17.06.22 00:56
Оценка: +2 -1
Здравствуйте, Sinclair, Вы писали:

S>Успех им обеспечило то, что они взяли знакомый им инструмент. Пока конкуренты осваивали Яву и писали фидбек её авторам, старички пилили Лисп со скоростью опытной машинистки. И не потому, что Лисп круче, а потому, что кроме Лиспа они ничем не владели. Владели бы они Фортраном — вы бы сейчас писали "о, надо писать веб-магазины на Фортране".


Эта команда владела еще много чем и подобрала наиболее подходящий им инструмент под конкретную техническую задачу. Задача была блестяще решена и продукт взлетел. Умело подобранная тобой метафора "скорость машинистки", предполагает высокую скорость набора текста, но их секрет в том, что лисп им дал в разы меньший объем кода, чем любая альтернатива того времени.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 17.06.22 13:41
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Эта команда владела еще много чем и подобрала наиболее подходящий им инструмент под конкретную техническую задачу. Задача была блестяще решена и продукт взлетел. Умело подобранная тобой метафора "скорость машинистки", предполагает высокую скорость набора текста, но их секрет в том, что лисп им дал в разы меньший объем кода, чем любая альтернатива того времени.


"команда владела еще много чем" означает что опыта у них было дохренища, чего у типичных команд нашего времени вобщем не бывает.

На тот момент их подход к бизнесу был довольно востребованым, без чего бы мы про их успехи и не узнали.

Я шота более чем уверен, выбери вместо лиспа другой высокоуровневый языки, типа питона или что навроде, результат был бы не хуже.
Re[2]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: IT Россия linq2db.com
Дата: 17.06.22 13:56
Оценка: -1
Здравствуйте, -n1l-, Вы писали:

N>Кстати говоря лиспа они так и не встретили, в итоге выкинув конкурентов с рынка, а их самих купил yahoo. И в yahoo lisp до сих пор используется.


Известная история. Типичные лямбда-самцы, в коде которых никто не может разобраться по причине того, что это write-only код.
Кстати, их говно-код потом был полностью выброшен на помоечку и приложение полностью переписано.
Если нам не помогут, то мы тоже никого не пощадим.
Re[13]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 17.06.22 15:18
Оценка: 1 (1) +1
Здравствуйте, Pauel, Вы писали:

P>Я шота более чем уверен, выбери вместо лиспа другой высокоуровневый языки, типа питона или что навроде, результат был бы не хуже.


Откуда такая уверенность? Лично я экономил на стэке и архитектуре, которую можно было дешево реализовать только в нем, в разы. Силами очень небольшой команды за счет профессионализма и инструмента.

А профи (те, кто доводит до пользователя непростые проекты с хорошим соотношением цена/качество), которые выбрали бы неудобный для решения задачи стек "типа питона" и терпеливо жрали бы долгое время этот кактус, мне не встречались. Обычно они понимают, что и зачем выбрали, а не действуют по принципу — мы крутые машинистки и на пэхапе наклепаем.
Re[3]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 17.06.22 15:23
Оценка:
Здравствуйте, IT, Вы писали:

IT>Известная история. Типичные лямбда-самцы, в коде которых никто не может разобраться по причине того, что это write-only код.

IT>Кстати, их говно-код потом был полностью выброшен на помоечку и приложение полностью переписано.

Вот кто бы говорил? ) Много команд потянут мейнтейн linq2db без особой подготовки?

Мало ли архитекторов найдется с мнением, что надо все выкинуть и переписать на Go?
Re[4]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: IT Россия linq2db.com
Дата: 17.06.22 18:01
Оценка: 4 (2) +4
Здравствуйте, Ziaw, Вы писали:

Z>Вот кто бы говорил? ) Много команд потянут мейнтейн linq2db без особой подготовки?


Если не ошибаюсь там был простенький толи магазинчик, толи mail клиент. И его потом не смогла поднять профессиональная команда разработчиков, чтобы его развивать и поддерживать. Не помогла ни подготовка, ни переподготовка. Дело не в ней. Лямбда-самцы действительно способны писать на FP шедевральные вещи, которые нам, простым селянам не доступны в силу нашего скудоумия. Но FP здесь лишь катализатор, очень мощный, но не критичный. Можно и без FP наворотить одноразового кода, который невозможно будет развивать.

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

Z>Мало ли архитекторов найдется с мнением, что надо все выкинуть и переписать на Go?


Не стоит обобщать. Конкретно данный пример с лиспом — это пример того как изначально провальный проект выдают за шедевр инженерного творчества и неспособность плебеев понять глубину мысли истинных ламбда-джедаев. Хотя, думаю, история выглядела немного по-другому:

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

Далее их заметили, купили, повосторгались и предложили из поделки сделать настоящий продукт. И вот здесь размер той самой "ментальной" модели превзошёл возможности несомненно талантливых парней. Адаптировать модель под требуемые фичи стало всё сложнее. Тем более, что список новых фич формируется уже не самим тобой, а другими людьми, часто обладающими несовместимой с твоей фантазией. Если раньше любую невпихуемую фичу можно было отбросить (с собой договориться элементарно), то теперь надо делать. Требование заказчика. Но ведь архитектуры как не было так и нет. Возможно была даже предпринята попытка что-то соорудить на коленке. Но боюсь это только усугубило проблему.

В результате получилось — слепок "ментальной" модели с прилепленными сбоку плохо совместимыми фичами и возможно попытками всё это заархитектурить. Помножим всё это на своеобразность выбранного инструмента и получаем абслютно бесполезный в плане развития продукт. Идеальный шар поломался, в кучу не собирается, не монолит и не артефакт, а артехрень. Единственно правильное решение — это взять веничек и замести это всё в мусорное ведёрко. Что, как я понимаю, и было сделано.
Если нам не помогут, то мы тоже никого не пощадим.
Re[4]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: SkyDance Земля  
Дата: 17.06.22 20:31
Оценка: +1
vsb>А вообще я так и не понял фишки лиспа

Так можно почти про любую технологию сказать.

Можно писать веб-приложения на С++.
Можно писать распределенные системы на Фортране.

Но некоторые технологии позволяют людям с определенной подготовкой работать намного эффективнее, и добиваться поставленных целей с бОльшей вероятностью. Кроме того, поддержка продукта на некоторых технологиях может быть существенно дороже (потому что мало кто помнит COBOL), но может статься, что и на порядок дешевле (потому что достаточно одному грамотному инженеру изучить COBOL, и обойтись без найма 20 писателей на С++).

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

Маленькие компании не могут рассчитывать на армию в 100500 тружеников на С++, потому вынуждены искать более эффективные средства решения их проблем. Почему бы и не лисп. Или Хаскель.
Re[13]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 17.06.22 20:36
Оценка: +1
P>Я шота более чем уверен, выбери вместо лиспа другой высокоуровневый языки, типа питона или что навроде, результат был бы не хуже.

Уверен, что результат был бы хуже.
Потому что им пришлось бы вместо решания задачи воевать с инструментом (языком), а также со своим нежеланием преодолевать кривизну оного инструмента.

Второе зачастую важнее, чем первое — если инструмент нравится, то и дело с ним спорится. А если нет, то вместо работы постоянно отвлекаешься на раздражающие проблемы. У меня так с С++ было, слишком часто нужно заглядывать в те или иные мануалы, слишком часто консультироваться с гуглом, слишком долго ждать сборки или запуска тестов. Та же Java многие из этих проблем решила, хотя сам по себе язык не то чтоб отличается (по крайней мере не так сильно, как LISP).
Re[5]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 17.06.22 20:47
Оценка:
IT>Если не ошибаюсь там был простенький толи магазинчик, толи mail клиент. И его потом не смогла поднять профессиональная команда разработчиков, чтобы его развивать и поддерживать. Не помогла ни подготовка, ни переподготовка. Дело не в ней.

Как раз в ней и дело. Профессионализм разработчиков состоит в том, чтобы уметь прочитать код, а потом изменить (или вовсе выкинуть за ненужностью — это уже высший пилотаж). Но этому, увы, не учат — даже на собеседованиях вопрос ставится как "напишите мне код, который будет ..."

IT>Лямбда-самцы действительно способны писать на FP шедевральные вещи, которые нам, простым селянам не доступны в силу нашего скудоумия. Но FP здесь лишь катализатор, очень мощный, но не критичный.


Само по себе функциональное программирование может и не быть критичным. Но все то, что дает подход, и делает критичной разницу.
E = mc^2, Errors = More (Code ^ 2).
Чем больше букв, тем больше ошибок. Тем сложнее тестировать и развивать. Особенно в те времена, когда инструментарий для других языков тоже отсутствовал. Это сейчас можно решить кучу проблем дизайна того же питона с помощью мириад утилит — все эти линтеры, форматтеры, CI и CD. В 90х (да и в 2000х) этот инструментарий был малодоступен (и неразвит). Поэтому были особенно ценны свойства самого языка — лаконичность, выразительность.

IT>В результате получилось — слепок "ментальной" модели с прилепленными сбоку плохо совместимыми фичами и возможно попытками всё это заархитектурить. Помножим всё это на своеобразность выбранного инструмента и получаем абслютно бесполезный в плане развития продукт.


Хочешь сказать, это была классика покупки хорошего продукта "большой компанией" со всеми традиционно вытекающими следствиями?

Так и есть. Команде профессионалов скомандовали — "вот вам 100500 индусов, напилите побольше фич". Традиционный подход "эффективного менеджмента", когда для решения любой проблемы нужно просто добавить людей. Который попросту не работает (вне зависимости от инструмента, просто потому, что хорошие продукты могут сделать только маленькие команды сильных инженеров).

Внезапно, это не сработало нигде и ни у кого. Собственно говоря, и не должно было работать. Основной задачей покупки было устранить возможную конкуренцию, а вовсе не продукт развивать.
Re[6]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: IT Россия linq2db.com
Дата: 18.06.22 03:55
Оценка: +3
Здравствуйте, SkyDance, Вы писали:

SD>Так и есть. Команде профессионалов скомандовали — "вот вам 100500 индусов, напилите побольше фич". Традиционный подход "эффективного менеджмента", когда для решения любой проблемы нужно просто добавить людей. Который попросту не работает (вне зависимости от инструмента, просто потому, что хорошие продукты могут сделать только маленькие команды сильных инженеров).


Почему только? В любом продукте есть масса работы для инженеров любого уровня. А маленькая команда сильных инженеров — это, во-первых, дорого, во-вторых, рискованно. Так считают современные манагеры.
Если нам не помогут, то мы тоже никого не пощадим.
Re[14]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.06.22 16:05
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Откуда такая уверенность? Лично я экономил на стэке и архитектуре, которую можно было дешево реализовать только в нем, в разы. Силами очень небольшой команды за счет профессионализма и инструмента.


Потому, что бОльшая часть времени в разработке уходит не на код, а на изучение домена, уточнение требований, проектирование, планирование, согласование, тестирование, настройку окружения, инфраструктуры, траблшутинг, багфикс, отладку, документирование итд итд.

Отсюда ясно, что другая команда имея такое же количество людей/опыта в той же области, но специализируясь на другом языке, даст результат за сравнимое время. Может чуть быстрее, может чуть медленнее.
На сам код у нормальных людей уходит 5-10 процентов времени. Потому сэкономить больше этих 5-10% ну никак не выйдет.

Другие, например, например, потратят на проектирование вдвое больше, в итоге на код уйдет больше времени, но багфикса, траблушинга, итд может оказаться много меньше.

Z>А профи (те, кто доводит до пользователя непростые проекты с хорошим соотношением цена/качество), которые выбрали бы неудобный для решения задачи стек


Сравнивать нужно яблоки с яблоками — например, две команды с примерно одинаковым опытом но специализируются на разныз технологических стеках, абы эти стеки под задачу подходили.
Re[14]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.06.22 16:07
Оценка:
Здравствуйте, SkyDance, Вы писали:

P>>Я шота более чем уверен, выбери вместо лиспа другой высокоуровневый языки, типа питона или что навроде, результат был бы не хуже.


SD>Уверен, что результат был бы хуже.

SD>Потому что им пришлось бы вместо решания задачи воевать с инструментом (языком), а также со своим нежеланием преодолевать кривизну оного инструмента.
SD>Второе зачастую важнее, чем первое — если инструмент нравится, то и дело с ним спорится.

Вот вот, сам себе противоречишь. Что мешает сравнить две команды с одинаковым опытом, но предпочитающих разные стеки?
Re[14]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: · Великобритания  
Дата: 18.06.22 16:59
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Откуда такая уверенность? Лично я экономил на стэке и архитектуре, которую можно было дешево реализовать только в нем, в разы. Силами очень небольшой команды за счет профессионализма и инструмента.

Z>А профи (те, кто доводит до пользователя непростые проекты с хорошим соотношением цена/качество), которые выбрали бы неудобный для решения задачи стек "типа питона" и терпеливо жрали бы долгое время этот кактус, мне не встречались. Обычно они понимают, что и зачем выбрали, а не действуют по принципу — мы крутые машинистки и на пэхапе наклепаем.
Ага, вот типичная машинистка на пэхапе. И до сих пор используют, переписывать не пришлось, в отличие от этих ваших лиспов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 20.06.22 20:26
Оценка: 1 (1) +1
IT>Почему только? В любом продукте есть масса работы для инженеров любого уровня. А маленькая команда сильных инженеров — это, во-первых, дорого, во-вторых, рискованно. Так считают современные манагеры.

Все правильно написал.

Команду нужно сделать большой и слабой (это будет еще дороже, но уже без риска случайно сделать хороший продукт — у большой и слабой команды это невозможно).
Тогда современные манагеры будут "важными управленцами". Ведь манагер 1000 человек — это шибко круче, чем манагер у 40.
Re[15]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 20.06.22 20:29
Оценка:
P>Вот вот, сам себе противоречишь. Что мешает сравнить две команды с одинаковым опытом, но предпочитающих разные стеки?

В чем именно противоречие?

Мне сложно представить две команды с одинаковым опытом. Если бы опыт был в самом деле одинаков, предпочтения, вероятно, тоже сходились бы.
Re[15]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 20.06.22 20:33
Оценка:
·>Ага, вот типичная машинистка на пэхапе. И до сих пор используют, переписывать не пришлось, в отличие от этих ваших лиспов.

Э-э-э.
Скажу так, он того пэхапе что был пэхапе там, пожалуй, не осталось ровным счетом ничего. Более того, PHP как язык не поддерживается вообще.

В то же время другие языки — как тот же Haskell или Erlang — используются очень широко, и без переписывания всей кодовой базы.
Re[5]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 21.06.22 02:31
Оценка:
Здравствуйте, IT, Вы писали:

IT>Если не ошибаюсь там был простенький толи магазинчик, толи mail клиент. И его потом не смогла поднять профессиональная команда разработчиков, чтобы его развивать и поддерживать. Не помогла ни подготовка, ни переподготовка. Дело не в ней. Лямбда-самцы действительно способны писать на FP шедевральные вещи, которые нам, простым селянам не доступны в силу нашего скудоумия. Но FP здесь лишь катализатор, очень мощный, но не критичный. Можно и без FP наворотить одноразового кода, который невозможно будет развивать.


Вот-вот. Лисп тут всего лишь инструмент, которым решили какие-то архитектурные задачи.

IT>linq2db пережил уже мильён сто тыщь пицот и ещё семь доработок, рефакторингов и глобальных фичедобавлений. При этом базовая архитектура хоть и расширяется, но тотально не меняется. И, кстати, большинство последних фич сделано людьми, которые присоеденились к проекту далеко не сразу.


А представь, что это интернет магазин который купила крупная корпорация и решила инвестировать в его разработку $5-10 миллионов в месяц. Легко будет увеличить в разы команду и поставить на поток новые фичи? Подозреваю, что ты справишься, но если вдруг придется делать без тебя и придет инженер с другим бэкграундом, не факт, что ему хватит скила сохранить твое видение архитектуры в которую можно уложить нужные фичи без запредельного увеличения сложности.

IT>Не стоит обобщать. Конкретно данный пример с лиспом — это пример того как изначально провальный проект выдают за шедевр инженерного творчества и неспособность плебеев понять глубину мысли истинных ламбда-джедаев. Хотя, думаю, история выглядела немного по-другому:


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

IT>Несомненно талантливые парни вооружились нетривиальным, но и не самым очевидным инструментом и начали клепать разные несложные поделки. Пока "ментальная" модель этих поделок целиком умещалась в голове, то при добавлении новых фич можно было переписывать код хоть каждый раз с нуля (не раз наблюдал такую картину). В таких продуктах, прости господи, архитектура обычно отсутствует напрочь, даже намёки на неё. Это всегда просто слепок "ментальной" модели, воплощённый в коде. Этакий монолит, идеальный круглый шар, артефакт, великолепно и эффективно выполняющий возложенные на него задачи. Хотя и вещь в себе, ни добавить, ни убавить.


Очень сомневаюсь, что идеальности шара проект достиг ровно к моменту продажи. Обычно у стартапа проект растет рывками и в разные стороны, о какой-то идеальности можно говорить лишь на самой первой итерации.

IT>Далее их заметили, купили, повосторгались и предложили из поделки сделать настоящий продукт. И вот здесь размер той самой "ментальной" модели превзошёл возможности несомненно талантливых парней. Адаптировать модель под требуемые фичи стало всё сложнее. Тем более, что список новых фич формируется уже не самим тобой, а другими людьми, часто обладающими несовместимой с твоей фантазией. Если раньше любую невпихуемую фичу можно было отбросить (с собой договориться элементарно), то теперь надо делать. Требование заказчика. Но ведь архитектуры как не было так и нет. Возможно была даже предпринята попытка что-то соорудить на коленке. Но боюсь это только усугубило проблему.


Скорее всего да, решили резко поменять курс. Причем тот кто решал, умел (или делал вид, что умел) делать продукты совсем по другому и на Грэма с его лиспом смотрел в лучшем случае недоверчиво.

IT>В результате получилось — слепок "ментальной" модели с прилепленными сбоку плохо совместимыми фичами и возможно попытками всё это заархитектурить. Помножим всё это на своеобразность выбранного инструмента и получаем абслютно бесполезный в плане развития продукт. Идеальный шар поломался, в кучу не собирается, не монолит и не артефакт, а артехрень. Единственно правильное решение — это взять веничек и замести это всё в мусорное ведёрко. Что, как я понимаю, и было сделано.


Резкие смены курса и команды именно к такому и приводят почти всегда. Независимо от стэка. Новому хозяину кода все кажется говнокодом и слепком ментальной модели автора (что в принципе применимо к любому продукту в той или иной степени), который только переписать.
Re[16]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 21.06.22 08:33
Оценка:
Здравствуйте, SkyDance, Вы писали:

SD>Мне сложно представить две команды с одинаковым опытом.

Мне кажется еще более странно будет сравнивать команды, когда одна выбирает знакомыый удобный инструмент, а вторая — незнакомый неудобный.

> Если бы опыт был в самом деле одинаков, предпочтения, вероятно, тоже сходились бы.


Если опыт идентичный, то конечно же да. Я имею ввиду опыт решения задач в конкретной области, а не использование конкретных технологических стеков или языков программирования.

Т.е. сравнивниваем устоявшиеся команды, которые имеют успешный опыт реализации схожих по профилю и сложности проектов, с разницей только в технологиях.
Re[15]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 21.06.22 09:53
Оценка: 1 (1)
Здравствуйте, Pauel, Вы писали:

P>Потому, что бОльшая часть времени в разработке уходит не на код, а на изучение домена, уточнение требований, проектирование, планирование, согласование, тестирование, настройку окружения, инфраструктуры, траблшутинг, багфикс, отладку, документирование итд итд.

P>Отсюда ясно, что другая команда имея такое же количество людей/опыта в той же области, но специализируясь на другом языке, даст результат за сравнимое время. Может чуть быстрее, может чуть медленнее.
P>На сам код у нормальных людей уходит 5-10 процентов времени. Потому сэкономить больше этих 5-10% ну никак не выйдет.

Настройку инфраструктуры, окружения, документирование и тестирование (кроме автотестов) можно сразу вынести за скобки. Они разовые и от стека зависят почти никак.

Изучение домена, уточнение требований, согласование, планирование — можно делать силами относительно небольшой команды.

А вот проектирование, программирование, отладка, траблшутинг, то есть то, чем занимаются дорогостоящие программисты, может быть очень и очень разным по стоимости.

P>Другие, например, например, потратят на проектирование вдвое больше, в итоге на код уйдет больше времени, но багфикса, траблушинга, итд может оказаться много меньше.


Вот именно. И здесь разные стеки для разных продуктов могут проявить как свои сильные, так и слабые строны во всей красе.

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


Вряд-ли это возможно и реально. Конечно можно сравнивать FB и Twitter, Github/Bitbucket, Skyscanner/Aviasales, но смысл непонятен. Продукт делается много кем и его коммерческий успех не определяется только технологией. Технология позволяет делать что-то дешевле/дороже, быстрее/дольше и только. Тем не менее я убежден, что FB/Twitter/Github/Amazon именно такие сильно благодаря используемому стеку, был бы другой стек продукты были бы совсем другими.
Re[16]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Sharov Россия  
Дата: 21.06.22 10:45
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Изучение домена, уточнение требований, согласование, планирование — можно делать силами относительно небольшой команды.

Z>А вот проектирование, программирование, отладка, траблшутинг, то есть то, чем занимаются дорогостоящие программисты, может быть очень и очень разным по стоимости.

А это скорее всего будут одни и те же люди. Либо речь пойдет о скорости коммуникации -- кто быстрее и четче сформулирует задачу для программиста, тот
скорее всего и будет успешнее. Т.е. речь о процессах скорее, а не о стеках.
Кодом людям нужно помогать!
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 21.06.22 10:49
Оценка:
Здравствуйте, Sharov, Вы писали:

S>А это скорее всего будут одни и те же люди. Либо речь пойдет о скорости коммуникации -- кто быстрее и четче сформулирует задачу для программиста, тот

S>скорее всего и будет успешнее. Т.е. речь о процессах скорее, а не о стеках.

Да, в требованиях — о процессах.
Re[16]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 21.06.22 11:11
Оценка:
Здравствуйте, Ziaw, Вы писали:

P>>Потому, что бОльшая часть времени в разработке уходит не на код, а на изучение домена, уточнение требований, проектирование, планирование, согласование, тестирование, настройку окружения, инфраструктуры, траблшутинг, багфикс, отладку, документирование итд итд.

P>>Отсюда ясно, что другая команда имея такое же количество людей/опыта в той же области, но специализируясь на другом языке, даст результат за сравнимое время. Может чуть быстрее, может чуть медленнее.
P>>На сам код у нормальных людей уходит 5-10 процентов времени. Потому сэкономить больше этих 5-10% ну никак не выйдет.

Z>Настройку инфраструктуры, окружения, документирование и тестирование (кроме автотестов) можно сразу вынести за скобки. Они разовые и от стека зависят почти никак.


Какая интересная подтасовка. Как я вижу — все эти активности булькают постоянно, особенно тестирование. Например, документирование, это написание некоторых design docs, что делается на каждую большую вещь. Тестирование, ручное и автоматическое, это вообще непрерывный процесс.
От стека они не зависят, но зависят от конкретной команды, и время тем не менее требуют постоянно, о чем я тебе и говорю. Считать нужно не чистое время кодинга, а именно время на всё, включая деливери.

Z>Изучение домена, уточнение требований, согласование, планирование — можно делать силами относительно небольшой команды.


Это тем не менее требуется любой команде. Дорогостоящие программисты всё равно должны погрузиться в проблему, иначе не бывает.

Z>А вот проектирование, программирование, отладка, траблшутинг, то есть то, чем занимаются дорогостоящие программисты, может быть очень и очень разным по стоимости.


Могут. И все зависит не от стека, от опыта этих специалистов. И в любом случае издержки на проектирование-программирование-отладку это всего лишь малая часть всех вместе взятых активностей. С учетом того, что доля кодинга скажем, 5-10%, то увеличив её искусственно в 5 раз, мы получим всего 150%. То есть, в полтора раза больше, а не в разы. Зато мы можем сэкономить на других активностях, и снова вернемся туда, где были.

P>>Другие, например, например, потратят на проектирование вдвое больше, в итоге на код уйдет больше времени, но багфикса, траблушинга, итд может оказаться много меньше.

Z>Вот именно. И здесь разные стеки для разных продуктов могут проявить как свои сильные, так и слабые строны во всей красе.

Это как раз те самые 5-10%. Для долгоиграющего проекта гораздо важнее будет ,скажем, выстроить правильную команду. Потому как команда из дорогостоящих специалистов это огромный риск, что после первого релиза никого не останется.
А раз так, то все становится еще интереснее.

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


Z>Вряд-ли это возможно и реально. Конечно можно сравнивать FB и Twitter, Github/Bitbucket, Skyscanner/Aviasales, но смысл непонятен. Продукт делается много кем и его коммерческий успех не определяется только технологией. Технология позволяет делать что-то дешевле/дороже, быстрее/дольше и только. Тем не менее я убежден, что FB/Twitter/Github/Amazon именно такие сильно благодаря используемому стеку, был бы другой стек продукты были бы совсем другими.е


Именно что, коммерческй успех в основном определяется не технологией программирования. Есть исключения — скажем Виндовс был бы другим, если бы его писали не на Си/С++. C другими проектами все далеко не так однозначно. На чем строится твое убеждение про FB, Twitter итд, мне совсем не ясно.
Re[4]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 21.06.22 11:22
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Не ошибаешься.


vsb>А вообще я так и не понял фишки лиспа, хотя я даже его компилятор писал (не дописал, но тему изучил достаточно, чтобы представлять себе всё, что надо). Обычный язык. Ничем от джавы не отличается принципиально. Любой код можно плюс-минус одинаково перенести.


Я как то задался целью перевести SICP со схемы на JS. И шота в середине процесса мне стало скучно — я понял, что занимаюсь совсем не тем. Обычный язык.
Re[5]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: vsb Казахстан  
Дата: 21.06.22 11:34
Оценка:
Здравствуйте, Pauel, Вы писали:

vsb>>А вообще я так и не понял фишки лиспа, хотя я даже его компилятор писал (не дописал, но тему изучил достаточно, чтобы представлять себе всё, что надо). Обычный язык. Ничем от джавы не отличается принципиально. Любой код можно плюс-минус одинаково перенести.


P>Я как то задался целью перевести SICP со схемы на JS. И шота в середине процесса мне стало скучно — я понял, что занимаюсь совсем не тем. Обычный язык.


В схеме есть необычные концепции. Это continuations и гигиенические макросы. Аналога этому в других языках обычно нет (вроде в Rust есть макросы). В остальном — да, обычный язык. Не знаю, используются ли эти концепции в SICP.
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 21.06.22 13:58
Оценка:
Здравствуйте, Pauel, Вы писали:

P>От стека они не зависят, но зависят от конкретной команды, и время тем не менее требуют постоянно, о чем я тебе и говорю. Считать нужно не чистое время кодинга, а именно время на всё, включая деливери.


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

P>Это тем не менее требуется любой команде. Дорогостоящие программисты всё равно должны погрузиться в проблему, иначе не бывает.


Это необходимое требование.

P>Могут. И все зависит не от стека, от опыта этих специалистов. И в любом случае издержки на проектирование-программирование-отладку это всего лишь малая часть всех вместе взятых активностей. С учетом того, что доля кодинга скажем, 5-10%, то увеличив её искусственно в 5 раз, мы получим всего 150%. То есть, в полтора раза больше, а не в разы. Зато мы можем сэкономить на других активностях, и снова вернемся туда, где были.


Да нифига, правильный выбор стека ведет к уменьшению сложности. А сложность это самая проблемная метрика проекта, как только все становится сложно, все становится очень дорого.

P>Это как раз те самые 5-10%. Для долгоиграющего проекта гораздо важнее будет ,скажем, выстроить правильную команду. Потому как команда из дорогостоящих специалистов это огромный риск, что после первого релиза никого не останется.

P>А раз так, то все становится еще интереснее.

Если у продукта есть будущее — после первого релиза все только начинается. Нормальные специалисты только входят во вкус.

P>Именно что, коммерческй успех в основном определяется не технологией программирования.


Рад, что ты тоже это понимаешь. Это не означает, что он ей не определяется вообще и можно этим не заморачиваться. Каждый стратап проходит очень много тонких моментов на грани и в некоторые моменты разработка становится либо грузом, топящим бизнес либо спасательным кругом, который его затаскивает. Точно так же, как и отдел продаж/маркетинга.
Re[18]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 21.06.22 16:24
Оценка:
Здравствуйте, Ziaw, Вы писали:

P>>От стека они не зависят, но зависят от конкретной команды, и время тем не менее требуют постоянно, о чем я тебе и говорю. Считать нужно не чистое время кодинга, а именно время на всё, включая деливери.


Z>Считать надо то, на что мы можем повлиять управляющим воздействием (выбором стека). На кой черт считать расходы на тестирование, покупку компов сотрудникам и


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

Z>Да нифига, правильный выбор стека ведет к уменьшению сложности. А сложность это самая проблемная метрика проекта, как только все становится сложно, все становится очень дорого.


Теоретически. Когда речь про формошлепство, то в данный момент у нас несколько кандидатов — React и чтото там еще. А если речь про солюшн, а не компонент, то влияние стека сильно размывается.

P>>А раз так, то все становится еще интереснее.


Z>Если у продукта есть будущее — после первого релиза все только начинается. Нормальные специалисты только входят во вкус.


Вот-вот. И нужно теперь гарантировать, что этих людей ты сможешь вовремя заменить. Как то так выходит, что команда крутых спецов на старте означает переписывание всего подряд с версии 2.0. Вот пример с Лиспом он как раз это и продемонстрировал.
Re[16]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: · Великобритания  
Дата: 21.06.22 17:52
Оценка: :)
Здравствуйте, SkyDance, Вы писали:

SD>·>Ага, вот типичная машинистка на пэхапе. И до сих пор используют, переписывать не пришлось, в отличие от этих ваших лиспов.

SD>Э-э-э.
SD>Скажу так, он того пэхапе что был пэхапе там, пожалуй, не осталось ровным счетом ничего.
Эээ.. пхп же остался. А вот лисп переписали и лиспа не осталось вообще.

SD>Более того, PHP как язык не поддерживается вообще.

Stable release 8.1.7 / 9 June 2022; 10 days ago

SD>В то же время другие языки — как тот же Haskell или Erlang — используются очень широко, и без переписывания всей кодовой базы.

Stable release Haskell 2010[2] / July 2010; 11 years ago

Так что пишите, дети, на пэхапэ, и вы сможете себе позволить сводить подружку в макдональдс!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: cppguard  
Дата: 21.06.22 21:51
Оценка:
удалено
Отредактировано 21.06.2022 21:53 cppguard . Предыдущая версия .
Re[7]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 01:45
Оценка:
Здравствуйте, IT, Вы писали:

IT>Почему только? В любом продукте есть масса работы для инженеров любого уровня. А маленькая команда сильных инженеров — это, во-первых, дорого, во-вторых, рискованно. Так считают современные манагеры.


Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно. А то, что при этом в коде творится и насколько все могло бы быть дешевле и проще — не их зона ответственности. Если все дорого, валится и надо переписать — виновата команда, архитектор, тимлиды (менеджер же не мог это проконтролировать). Если продукт таки задышал и начал приносить прибыль — менеджер молодец, для бизнеса он управлял его созданием.
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 22.06.22 02:51
Оценка: +1
P>Т.е. сравнивниваем устоявшиеся команды, которые имеют успешный опыт реализации схожих по профилю и сложности проектов, с разницей только в технологиях.

Еще раз повторю, ни разу подобного не видел. Более того, сравнивать зачастую стоит не столько команды, сколько конкретных людей, которые команду образуют. Достаточно одного сильного инженера с талантом преподавателя, чтобы команда оценила и полюбила незнакомый стек. Достаточно одного брюзги с нежеланием учиться ничему новому, поставленного в позицию сеньора, чтобы та же команда стала сборищем тормозов.
Re[17]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: SkyDance Земля  
Дата: 22.06.22 03:43
Оценка:
·>Эээ.. пхп же остался. А вот лисп переписали и лиспа не осталось вообще.

Где остался-то? Уж точно не в Facebook'е. Гуглить по словам "Hack" (форк PHP).

SD>>Более того, PHP как язык не поддерживается вообще.


...но это не в Фейсбуке. Лисп вне Yahoo тоже жив.

SD>>В то же время другие языки — как тот же Haskell или Erlang — используются очень широко, и без переписывания всей кодовой базы.

·>Stable release Haskell 2010[2] / July 2010; 11 years ago

Внимательнее смотри.

27 May 2022
GHC 9.2.3 Released! [download]
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: so5team https://stiffstream.com
Дата: 22.06.22 05:09
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно.


Дико извиняюсь, но позвольте уточнить, правильно ли вас понял: вы утверждаете, что для управления коллективом из 100 человек управленческих навыков нужно меньше, чем для управления коллективом из 10 человек?
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 05:46
Оценка: -2
Здравствуйте, so5team, Вы писали:

S>Дико извиняюсь, но позвольте уточнить, правильно ли вас понял: вы утверждаете, что для управления коллективом из 100 человек управленческих навыков нужно меньше, чем для управления коллективом из 10 человек?


Эффективно управлять командой профи из 5 человек (то есть согласовывать цели продукта, команды, компании) в разы сложнее, чем набрать 50 человек и размазать ответственность по всем. То, что это будет в 5 раз дороже тоже гораздо проще обосновать — есть конкретные метрики. Вобщем жопа менеджера прикрыта со всех сторон, в отличии от первого варианта. Опять же тупняки менеджмента, типа продавленного неверного решения, в команде из 50 человек вообще не видны.

Ниже цена, выше риски. Чудес не бывает. У менеджера конфликт интересов с компанией, его задача снизить личные риски, у компании — быть эффективной.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: so5team https://stiffstream.com
Дата: 22.06.22 05:50
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

Спасибо за то, что развернуто ответили. Еще вопрос, если можно: это вы на основании собственного опыта или из книг/разговоров с коллегами к такому выводу пришли?
Re[18]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.06.22 07:26
Оценка:
Здравствуйте, SkyDance, Вы писали:

P>>Т.е. сравнивниваем устоявшиеся команды, которые имеют успешный опыт реализации схожих по профилю и сложности проектов, с разницей только в технологиях.


SD>Еще раз повторю, ни разу подобного не видел.


Значит, мало видел.

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


Вот-вот. Снова противоречие. Нужно сравнивать не коней в вакууме, а эффективность с т.з. решения проблемы целиком, от начала работ до финала деливери.
Все остальное, типа "я закодил фичу в 100500 раз быстрее" на общем фоне неразличимы.

Все достаточно просто — перформанс команды == перформанс ботлнека. И вот такая штука, что код бывает ботлнеком не так уж и часто. Гораздо чаще таким ботлнеком будет обеспечение качества, менеджмент и тд. Например, мега-менеджер решил, что им тестировщики не нужны. Ну ок. Значит вся команда начинает потиху отрываться от реальности, независимо от квалификации. Рано или поздно все это приводит к тому, что продукт заполняется вечноживыми багами.
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.06.22 07:30
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно. А то, что при этом в коде творится и насколько все могло бы быть дешевле и проще — не их зона ответственности. Если все дорого, валится и надо переписать — виновата команда, архитектор, тимлиды (менеджер же не мог это проконтролировать). Если продукт таки задышал и начал приносить прибыль — менеджер молодец, для бизнеса он управлял его созданием.


У тебя неадекватное обобщение, разновидность шериданства, т.н. "технологического расизма". Разница в том, что у шеридана виноваты девелоперы, у тебя — менеджеры.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.06.22 07:32
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Эффективно управлять командой профи из 5 человек (то есть согласовывать цели продукта, команды, компании) в разы сложнее, чем набрать 50 человек и размазать ответственность по всем. То, что это будет в 5 раз дороже тоже гораздо проще обосновать — есть конкретные метрики. Вобщем жопа менеджера прикрыта со всех сторон, в отличии от первого варианта. Опять же тупняки менеджмента, типа продавленного неверного решения, в команде из 50 человек вообще не видны.

Z>Ниже цена, выше риски. Чудес не бывает. У менеджера конфликт интересов с компанией, его задача снизить личные риски, у компании — быть эффективной.

Вот-вот. Шериданство в чистом виде.
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:04
Оценка:
Здравствуйте, Pauel, Вы писали:

P>У тебя неадекватное обобщение, разновидность шериданства, т.н. "технологического расизма". Разница в том, что у шеридана виноваты девелоперы, у тебя — менеджеры.


Это какие-то твои проекции. Здесь нет ничего про вину. Здесь про то, что умеют и чем руководствуются менеджеры. Я сам менеджер, если что и мне нафиг не нужны трудовые подвиги ни мои ни командные. Работа по выжиманию всего из требований, стека и архитектуры результативная, но очень слабо предсказуемая, а это мало кому интересно. Более того, это может удлинить какие-то промежуточные этапы, плохо попадает в оценку и сложно ложится в проектную деятельность.

Я по опыту знаю, что собрать крутую команду и создать ей крутой продукт за цену в разы меньшую чем по корпоративным расценкам можно. И знаю, насколько проще создавать продукты в корпорации, пусть и в разы дольше и дороже, но это никого особо не парит, едем по рельсам и все. Просто потому, что по другому никто не готов и страшно узнать, что это вообще возможно.

Это мой опыт и если все что тебе остается — переходить на личности, то избавь меня от такого чтения. Себя же дураком выставляешь, у которого бомбит от того, что кто-то может по другому и срочно надо опровергнуть.
Re[6]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: Ночной Смотрящий Россия  
Дата: 22.06.22 08:06
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>В схеме есть необычные концепции. Это continuations и гигиенические макросы. Аналога этому в других языках обычно нет


Это continuations то в других языках нет? Или другие языки у тебя строго равны java?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ночной Смотрящий Россия  
Дата: 22.06.22 08:06
Оценка: +3
Здравствуйте, Ziaw, Вы писали:

Z>Эффективно управлять командой профи из 5 человек (то есть согласовывать цели продукта, команды, компании) в разы сложнее, чем набрать 50 человек и размазать ответственность по всем.


Звучит как слова теоретика. На практике с точностью до наоборот — управлять 5 профи практически не нужно, они сами прекрасно справятся, а вот заставить 50 раззвиздяев что то выдать полезное — крайне нетривиальная задача.
Плюс больших команд со средней квалификацией не в том что ими проще/комфортнее/престижнее управлять, а в том что они обеспечивают business continuity. Т.е. такую команду намного проще создать и прогнозируемо поддерживать примерно в одинаковом состоянии длительный промежуток времени. Т.е., к примеру, уволилось у тебя из такой команды пара-тройка человек — да и фик бы с ними, новых наймем. А вот если такое произойдет с командой из 5 профи — продукт окажется на коленях.
Поэтому большие конторы стараются профи-команды применять там, где риск подобного минимален либо бенефиты перевешивают риски — стартап-проекты, аварийные команды, определяющие главные свойства продукта его части.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:07
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Вот-вот. И нужно теперь гарантировать, что этих людей ты сможешь вовремя заменить.


Гарантировать можно только свою смерть. Если бы можно было гарантировать успех проекта, то все бы давно уже это делали.

P>Как то так выходит, что команда крутых спецов на старте означает переписывание всего подряд с версии 2.0. Вот пример с Лиспом он как раз это и продемонстрировал.


Не выходит. Но заменять людей и расставаться с ними в любом случае надо уметь.
Re[20]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ночной Смотрящий Россия  
Дата: 22.06.22 08:10
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

Z>Гарантировать можно только свою смерть. Если бы можно было гарантировать успех проекта, то все бы давно уже это делали.


Так и делают. Если у тебя есть хороший vision, проработанный рынок и ресурсы на разработку — вероятность успеха очень высока. Я крайне редко вижу сейчас проваленные только из-за проблем в реализации проекты. Проваливаются почти всегда из-за кривого vision или неправильной оценки рынка.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:20
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Звучит как слова теоретика. На практике с точностью до наоборот — управлять 5 профи практически не нужно, они сами прекрасно справятся, а вот заставить 50 раззвиздяев что то выдать полезное — крайне нетривиальная задача.


Управлять 5 профи все равно нужно и все управленческие проблемы с ними уникальны. А 50 развиздяев так или иначе по проторенным практикам будут выдавать что-то полезное и управлять надо не всеми ими, а несколькими лидами и требованиями к продукту и коду. В этих требованиях лучше запретить всякие непонятные штуки, так как при неумелой доработке они стреляют в ноги всей команде и никакое ревью не спасает.

НС>Плюс больших команд со средней квалификацией не в том что ими проще/комфортнее/престижнее управлять, а в том что они обеспечивают business continuity. Т.е. такую команду намного проще создать и прогнозируемо поддерживать примерно в одинаковом состоянии длительный промежуток времени. Т.е., к примеру, уволилось у тебя из такой команды пара-тройка человек — да и фик бы с ними, новых наймем. А вот если такое произойдет с командой из 5 профи — продукт окажется на коленях.

НС>Поэтому большие конторы стараются профи-команды применять там, где риск подобного минимален либо бенефиты перевешивают риски — стартап-проекты, аварийные команды, определяющие главные свойства продукта его части.

Именно это я и говорю. Большим конторам редко нужны такие кейсы по вполне понятным и обоснованным причинам. Но там где они применяются, хорошую экономию дает и стек и умелое использование его особенностей. А именно это пытаются здесь оспорить некоторые как "не бывает, а если бывает, то все равно говно получается".
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:23
Оценка:
Здравствуйте, so5team, Вы писали:

S>Спасибо за то, что развернуто ответили. Еще вопрос, если можно: это вы на основании собственного опыта или из книг/разговоров с коллегами к такому выводу пришли?


Из собственного.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ночной Смотрящий Россия  
Дата: 22.06.22 08:27
Оценка: +1
Здравствуйте, Ziaw, Вы писали:

Z>Управлять 5 профи все равно нужно


Только стратегически, чтобы они выдерживали курс. Иначе это не профи.

НС>>Поэтому большие конторы стараются профи-команды применять там, где риск подобного минимален либо бенефиты перевешивают риски — стартап-проекты, аварийные команды, определяющие главные свойства продукта его части.

Z>Именно это я и говорю.

Но причины этого ты приводишь какие то фантастические.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: so5team https://stiffstream.com
Дата: 22.06.22 08:41
Оценка:
Здравствуйте, Ziaw, Вы писали:

S>>Спасибо за то, что развернуто ответили. Еще вопрос, если можно: это вы на основании собственного опыта или из книг/разговоров с коллегами к такому выводу пришли?


Z>Из собственного.


Очень и очень странно. Возможно, вам повезло. Возможно, вы просто не отрефлексировали свое собственное развитие в менеджменте и судите о сложности управления коллективом из 100 человек не учитывая опыта, которого у вас не было когда вы управляли коллективом из 10 человек.
Re[21]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 08:44
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Так и делают. Если у тебя есть хороший vision, проработанный рынок и ресурсы на разработку — вероятность успеха очень высока. Я крайне редко вижу сейчас проваленные только из-за проблем в реализации проекты. Проваливаются почти всегда из-за кривого vision или неправильной оценки рынка.


Если ресурсов на разработку с запасом, да, высока. Сейчас достаточно практик наработано. Можем конечно пободаться за термины гарантии/вероятности, но не вижу смысла.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 22.06.22 08:51
Оценка:
Здравствуйте, Ziaw, Вы писали:

НС>>Звучит как слова теоретика. На практике с точностью до наоборот — управлять 5 профи практически не нужно, они сами прекрасно справятся, а вот заставить 50 раззвиздяев что то выдать полезное — крайне нетривиальная задача.


Z>Управлять 5 профи все равно нужно и все управленческие проблемы с ними уникальны.


Обычно такие команды максимально автономны. Им сообщают приоритеты, новые фичи и всё. Т.е. участие менеджера сводится к минимуму.

Проблемой может быть говно- и микроменеджмент — тогда команда профи может как разбежаться, так и "сожрать" менеджера. Мне, скажем, известен случай, когда когда проектная команда из таких профи сожрала не одного, а целый страйк менеджеров.

Например,
1 прибегает менеджер и вопит "..я, чего ты тут занимаешься этим, это уже не надо..." ? А откуда разработчику знать, что не надо, если тикет ему только вчера выдан?
2 Или так "..я, почему бакенды коммитают раз в день, а фронтенды по 10-15 раз в день" и начинает "ускорять", потому что по его мнению бакенды тупые и ленивые, а фронтенды — хорошие и годные.
3 Или вот кейс "на текущий спринт приоритет — десктоп!!!!1111" и всем тикеты по андроиду. Следующий спринт — "приоритет андроид!!!!1" и тут же менеджер требует "мне срочно нужен релиз десктопа"
4 А вот еще "напиши вот такой код, должно работать", "если сеть ненадежна, то пусть админы сделают её надежной" — это менеджер объясняет разработчику с 15ю лет опыта, что можно писать код так, как будто сеть 100% надежна.

Итого 1 — сожран, 2 — сожран, 3 — сожран, 4 — сожран. А продукт взлетел, несмотря на "менеджеров"
Re[22]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ночной Смотрящий Россия  
Дата: 22.06.22 09:02
Оценка:
Здравствуйте, Ziaw, Вы писали:

Z>Если ресурсов на разработку с запасом, да, высока.


Так в том и суть — платим ресурсами за предсказуемость и гарантии. В большинстве случаев это окупается.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[7]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: vsb Казахстан  
Дата: 22.06.22 09:38
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

vsb>>В схеме есть необычные концепции. Это continuations и гигиенические макросы. Аналога этому в других языках обычно нет


НС>Это continuations то в других языках нет? Или другие языки у тебя строго равны java?


А в каких есть?
Re[13]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 10:07
Оценка:
Здравствуйте, so5team, Вы писали:

S>Очень и очень странно. Возможно, вам повезло. Возможно, вы просто не отрефлексировали свое собственное развитие в менеджменте и судите о сложности управления коллективом из 100 человек не учитывая опыта, которого у вас не было когда вы управляли коллективом из 10 человек.


Ты неверно меня понял (а я не однозначно выразился). В 100 человек у меня опыта нет и я его не заявлял, говорил про разницу команд на порядок и опыт в этом.

Опять же, если только управлять — конечно ты прав, 100 человек намного сложнее. В команде на 5 человек управление осложняется тем, что кроме управления ты еще и инженер и часто в равной позиции, а в некоторых случаях тобой может управлять другой. Сложность здесь именно в совмещении, уникальности и плотности решаемых задач, постоянном поиске нестандартных решений.

Если сравнивать только управление, ответ однозначный, с количеством сложность растет (совсем не линейно, но растет).
Re[13]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 22.06.22 10:22
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Только стратегически, чтобы они выдерживали курс. Иначе это не профи.


Люди сложнее чем профи/непрофи. Хотя может я не встречал тех, кого ты называешь профи.

НС>Но причины этого ты приводишь какие то фантастические.


При этом некоторые перекликаются с твоими, только другими словами.

Я говорю:
Менеджеры боятся плохо предсказуемых проектов и цена из корпоративного бюджета их интересует не так уж и сильно, а собственный комфорт и безопасность сильно. Управлять разработкой большой командой может быть проще, чем малой.

Ты говоришь:
Плюс больших команд со средней квалификацией в том что они обеспечивают business continuity. Т.е. такую команду намного проще создать и прогнозируемо поддерживать примерно в одинаковом состоянии длительный промежуток времени.

Может быть формулировки мои резковаты, вон у Икемефулы вообще бомбануло, что менеджеры в чем-то виноваты. Как будто в избегании рисков есть что-то плохое.
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: Ночной Смотрящий Россия  
Дата: 22.06.22 10:31
Оценка:
Здравствуйте, vsb, Вы писали:

НС>>Это continuations то в других языках нет? Или другие языки у тебя строго равны java?

vsb>А в каких есть?

https://en.wikipedia.org/wiki/Continuation#Programming_language_support
Даже java заявлена, хотя и через зад сделано. Для шарпа/VB, кстати, помимо await есть еще и старый добрый yield, доступный аж со 2 версии.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: vsb Казахстан  
Дата: 22.06.22 10:39
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>>>Это continuations то в других языках нет? Или другие языки у тебя строго равны java?

vsb>>А в каких есть?

НС>https://en.wikipedia.org/wiki/Continuation#Programming_language_support

НС>Даже java заявлена, хотя и через зад сделано. Для шарпа/VB, кстати, помимо await есть еще и старый добрый yield, доступный аж со 2 версии.

Я про нормальную поддержку, first-class, как говорится. Кому-то и setjmp/longjmp за continuation пойдёт. async/await это вообще из другой оперы, хз, при чём тут они. В котлине Continuation тоже не то. Я так подозреваю, они там Continuation-ами называют одноразовый возврат к ранее сохранённому стеку. А правильный continuation позволяет многоразовый возврат.
Re[8]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: Ziaw Россия  
Дата: 22.06.22 10:40
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>А в каких есть?


А что ты подразумеваешь под continuations? Поддержку ключевыми словами языка? Оптимизацию стека при этом?

Понятие-то широкое, всего лишь паттерн дизайна флоу выполнения. Для такого паттерна 30 лет назад применяли setjmp/longjmp в C.
Re[14]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ночной Смотрящий Россия  
Дата: 22.06.22 10:40
Оценка:
Здравствуйте, Ziaw, Вы писали:

НС>>Только стратегически, чтобы они выдерживали курс. Иначе это не профи.

Z>Люди сложнее чем профи/непрофи.

В данном случае это прямо следует из определения. Профи знает как и умеет получать результат без сторонних пинков. Если не умеет — это не профи. Усложнять тут можно только чтобы запутать.

Z> Хотя может я не встречал тех, кого ты называешь профи.


Может. Я встречал. Даже если в команде есть джуны/мидлы без фатальных проблем с софтскиллами и их количество не превышает критического — такая команда прекрасно самоорганизуется.
И да, чем больше джунов/миддлов, тем больше нагрузка на лида, проверено на собственном опыте неоднократно.

НС>>Но причины этого ты приводишь какие то фантастические.

Z>При этом некоторые перекликаются с твоими, только другими словами.

А некоторые прямо противоречат.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: Ночной Смотрящий Россия  
Дата: 22.06.22 10:45
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>Я про нормальную поддержку, first-class, как говорится.


А там почти все языки в списке, кроме жабы — first class.

vsb> Кому-то и setjmp/longjmp за continuation пойдёт. async/await это вообще из другой оперы


Нет, это не из другой оперы, это continuations в чистом виде, просто несколько подвязанные на TPL. Поэтому куда лучший пример для шарпа — yield, тут уже никакой подвязки нет, на выходе совершенно абcтрактный IEnumerable/IEnumerator.

vsb>В котлине Continuation тоже не то.


Что именно не то?

vsb> Я так подозреваю, они там Continuation-ами называют одноразовый возврат к ранее сохранённому стеку.


Подозреваешь или знаешь?
Нет там вообще никакого стека, там стандартный подход с генерацией FSM — https://kotlinlang.org/spec/asynchronous-programming-with-coroutines.html
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: vsb Казахстан  
Дата: 22.06.22 10:58
Оценка:
Здравствуйте, Ziaw, Вы писали:

vsb>>А в каких есть?


Z>А что ты подразумеваешь под continuations? Поддержку ключевыми словами языка? Оптимизацию стека при этом?


То, что подразумевается в scheme. Сохранение точки выполнения (стек, состояние переменных) и многократный возврат к этой точке выполнения в будущем. В произвольном коде, без каких-либо ограничений.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2
От: Ziaw Россия  
Дата: 22.06.22 11:07
Оценка: 2 (1)
Здравствуйте, vsb, Вы писали:

vsb>То, что подразумевается в scheme. Сохранение точки выполнения (стек, состояние переменных) и многократный возврат к этой точке выполнения в будущем. В произвольном коде, без каких-либо ограничений.


В таком виде руби умеет https://ruby-doc.org/core-2.5.0/Continuation.html. Но по применимости обычно заменяемо FSM, на чем-то вроде енумератора.
Re[23]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 23.06.22 06:58
Оценка:
Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Так в том и суть — платим ресурсами за предсказуемость и гарантии. В большинстве случаев это окупается.


Если ресурсов хватает, особенно не своих, разумный выбор.
Re[10]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.06.22 07:38
Оценка:
Здравствуйте, Ziaw, Вы писали:

P>>У тебя неадекватное обобщение, разновидность шериданства, т.н. "технологического расизма". Разница в том, что у шеридана виноваты девелоперы, у тебя — менеджеры.


Извини, тут я трохи не так выразился — не менеджеры, а команда, т.к. ты возложил вину на команду. Далее твоя цитата про это.

Z>Это какие-то твои проекции. Здесь нет ничего про вину. Здесь про то, что умеют и чем руководствуются менеджеры.


Похоже, ты скоро начнешь отрицать отрицание Смотри, как ты переобуваешься: "виновата команда" -> "здесь нет ничего про вину"
Читаем вместе:

Современные манагеры, которые так считают, преследуют в первую очередь свои интересы — большая команда это престижнее, ей проще управлять как людьми, меньше скилов управленца нужно. А то, что при этом в коде творится и насколько все могло бы быть дешевле и проще — не их зона ответственности. Если все дорого, валится и надо переписать — виновата команда, архитектор, тимлиды (менеджер же не мог это проконтролировать).


На счет проекций — ты собственно транслируешь своё видение, только приписывавешь это абстрактным менеджерам, " Здесь про то, что умеют и чем руководствуются менеджеры." . Во первых, это и есть проекции, твои собственные, т.е. именно ты так видишь.
Во вторых, ясно, что у тебя дихотомия простая: или виновата команда, или менеджер молодец.

Ну и дальше, "жопа менеджера прикрыта со всех сторон" — вот такое эмоциональное подтверждение всего выше. У меня, из личного опыта, когда менеджер "думает жопой", т.е. постоянно заботится о её прикрытии, почти всегда действует ровно так же — или команда виновата, или менеджер молодец.
Re[11]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 23.06.22 07:52
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Извини, тут я трохи не так выразился — не менеджеры, а команда, т.к. ты возложил вину на команду. Далее твоя цитата про это.


Начались проблемы с пониманием прочитанного?

P>Похоже, ты скоро начнешь отрицать отрицание Смотри, как ты переобуваешься: "виновата команда" -> "здесь нет ничего про вину"


Здесь тоже проблемы с пониманием или сову на глобус натягиваешь?

P>Ну и дальше, "жопа менеджера прикрыта со всех сторон" — вот такое эмоциональное подтверждение всего выше. У меня, из личного опыта, когда менеджер "думает жопой", т.е. постоянно заботится о её прикрытии, почти всегда действует ровно так же — или команда виновата, или менеджер молодец.


И это довольно частое явление.
Re[12]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Pauel Беларусь http://blogs.rsdn.org/ikemefula
Дата: 23.06.22 09:43
Оценка:
Здравствуйте, Ziaw, Вы писали:

P>>Извини, тут я трохи не так выразился — не менеджеры, а команда, т.к. ты возложил вину на команду. Далее твоя цитата про это.


Z>Начались проблемы с пониманием прочитанного?


P>>Похоже, ты скоро начнешь отрицать отрицание Смотри, как ты переобуваешься: "виновата команда" -> "здесь нет ничего про вину"


Z>Здесь тоже проблемы с пониманием или сову на глобус натягиваешь?


Вот и подъехало отрицание отрицания
Re[13]: Так, господа, а вот это уже серьезно (Haskell нужен 2)
От: Ziaw Россия  
Дата: 23.06.22 10:09
Оценка:
Здравствуйте, Pauel, Вы писали:

P>Вот и подъехало отрицание отрицания


Пожалей сову.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.