Сообщение Re[11]: StackOverflow от 08.01.2017 13:49
Изменено 08.01.2017 13:53 Слава
Re[11]: StackOverflow
Здравствуйте, lpd, Вы писали:
С>>У меня есть замечательный пример зарепорченного бага в Freeswitch, из-за которого бага можно легко потерять уйму денег. Исправляли полгода, еще полгода прошло — до сих пор патч не принят в апстрим. При том, что будь логика той части вынесена в управляемый код — а там нет ничего сложного, обычное диспетчирование, то поправили бы за неделю.
lpd>Ты всерьез по одному конкретному случаю с Freeswitch делаешь вывод о всей технологии? Даже если там дело в buffer overflow на C++, такой баг поправляется очень легко. И я представляю, сколько нужно админить серверов и какие писать load-balancerы, чтобы обрабатывать VoIP на C#. Напомню, C# в 2-4 раза медленнее, чем C++, причем на ровном месте.
Там не С++, а вообще Си. Столь любимая многими сишечка. Без модулей. Без дженериков.
Выводы я делаю по примерам вроде того же bind, в котором до сих пор баги находят. По mysql с его дырками. Дело не только в языке, а и в культуре разработки. Вот тут весь тред копья ломают — ах, на чём же писать весь проект целиком, только на С++, или только на С#? При том, что в несчастном мобильном стартапе используется три языка и три разных специалиста — C# для Xamarin (и тем не менее для iPhone нужен отдельный специалист), JS и Angular — а это тоже отдельный мир, требующий своих специалистов, и наконец HTML5 c CSS3, который должен единообразно выглядеть везде, на всех устройствах, и для этого требуется специалист-верстальщик, а не просто С#-разработчик "со знанием HTML".
Можно использовать несколько языков в проекте. Только вот выбранный ранее язык определяет идиосинкразию предыдущих разработчиков к чему-то новому и отличному от милого их сердцам make c #DEFINE TRUE FALSE.
Вот хороший пример совсем из другой области:
Because within the HPC community, the reaction to these new entrants is mostly not excitement at novel technologies and interesting new problems to solve, but scoffing at solutions which were Not Invented Here, and suggestions that those who use other platforms simply aren't doing "real" high performance computing – and maybe don't know what they're doing at all. You can see this attitude even in otherwise well-researched and thought-out pieces, where the suggestion is that it is genomics researchers' responsibility to alter what they are doing to better fit existing HPC toolsets. This thinking misses the rather important fact that it is HPC's job to support researchers' computing needs, rather than vice versa.
Уж казалось бы — HPC. Куда там ffmpeg'у какому-то, или обработка voip, которая вся сводится к манипуляции текстовыми заголовками. И то — людям стало УДОБНЕЕ пользоваться не байтогрызным MPI с его высокомерным сообществом, а написать свой Java Spark. Фреймворк для ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ вычислений для Яве. На Яве, Карл!
Или вот еще оттуда, оцени уровень удобства байтогрызного фреймворка из 80х родом:
Today, MPI's error handling model is what it has always been; you can assign an errorhandler to be called when an error occurs in an MPI program, and when that happens you can... well, you can print a nice message before you crash, instead of crashing without the nice message.
С>>У меня есть замечательный пример зарепорченного бага в Freeswitch, из-за которого бага можно легко потерять уйму денег. Исправляли полгода, еще полгода прошло — до сих пор патч не принят в апстрим. При том, что будь логика той части вынесена в управляемый код — а там нет ничего сложного, обычное диспетчирование, то поправили бы за неделю.
lpd>Ты всерьез по одному конкретному случаю с Freeswitch делаешь вывод о всей технологии? Даже если там дело в buffer overflow на C++, такой баг поправляется очень легко. И я представляю, сколько нужно админить серверов и какие писать load-balancerы, чтобы обрабатывать VoIP на C#. Напомню, C# в 2-4 раза медленнее, чем C++, причем на ровном месте.
Там не С++, а вообще Си. Столь любимая многими сишечка. Без модулей. Без дженериков.
Выводы я делаю по примерам вроде того же bind, в котором до сих пор баги находят. По mysql с его дырками. Дело не только в языке, а и в культуре разработки. Вот тут весь тред копья ломают — ах, на чём же писать весь проект целиком, только на С++, или только на С#? При том, что в несчастном мобильном стартапе используется три языка и три разных специалиста — C# для Xamarin (и тем не менее для iPhone нужен отдельный специалист), JS и Angular — а это тоже отдельный мир, требующий своих специалистов, и наконец HTML5 c CSS3, который должен единообразно выглядеть везде, на всех устройствах, и для этого требуется специалист-верстальщик, а не просто С#-разработчик "со знанием HTML".
Можно использовать несколько языков в проекте. Только вот выбранный ранее язык определяет идиосинкразию предыдущих разработчиков к чему-то новому и отличному от милого их сердцам make c #DEFINE TRUE FALSE.
Вот хороший пример совсем из другой области:
Because within the HPC community, the reaction to these new entrants is mostly not excitement at novel technologies and interesting new problems to solve, but scoffing at solutions which were Not Invented Here, and suggestions that those who use other platforms simply aren't doing "real" high performance computing – and maybe don't know what they're doing at all. You can see this attitude even in otherwise well-researched and thought-out pieces, where the suggestion is that it is genomics researchers' responsibility to alter what they are doing to better fit existing HPC toolsets. This thinking misses the rather important fact that it is HPC's job to support researchers' computing needs, rather than vice versa.
Уж казалось бы — HPC. Куда там ffmpeg'у какому-то, или обработка voip, которая вся сводится к манипуляции текстовыми заголовками. И то — людям стало УДОБНЕЕ пользоваться не байтогрызным MPI с его высокомерным сообществом, а написать свой Java Spark. Фреймворк для ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ вычислений для Яве. На Яве, Карл!
Или вот еще оттуда, оцени уровень удобства байтогрызного фреймворка из 80х родом:
Today, MPI's error handling model is what it has always been; you can assign an errorhandler to be called when an error occurs in an MPI program, and when that happens you can... well, you can print a nice message before you crash, instead of crashing without the nice message.
Re[11]: StackOverflow
Здравствуйте, lpd, Вы писали:
С>>У меня есть замечательный пример зарепорченного бага в Freeswitch, из-за которого бага можно легко потерять уйму денег. Исправляли полгода, еще полгода прошло — до сих пор патч не принят в апстрим. При том, что будь логика той части вынесена в управляемый код — а там нет ничего сложного, обычное диспетчирование, то поправили бы за неделю.
lpd>Ты всерьез по одному конкретному случаю с Freeswitch делаешь вывод о всей технологии? Даже если там дело в buffer overflow на C++, такой баг поправляется очень легко. И я представляю, сколько нужно админить серверов и какие писать load-balancerы, чтобы обрабатывать VoIP на C#. Напомню, C# в 2-4 раза медленнее, чем C++, причем на ровном месте.
Там не С++, а вообще Си. Столь любимая многими сишечка. Без модулей. Без дженериков.
Выводы я делаю по примерам вроде того же bind, в котором до сих пор баги находят. По mysql с его дырками. Дело не только в языке, а и в культуре разработки. Вот тут весь тред копья ломают — ах, на чём же писать весь проект целиком, только на С++, или только на С#? При том, что в несчастном мобильном стартапе используется три языка и три разных специалиста — C# для Xamarin (и тем не менее для iPhone нужен отдельный специалист), JS и Angular — а это тоже отдельный мир, требующий своих специалистов, и наконец HTML5 c CSS3, который должен единообразно выглядеть везде, на всех устройствах, и для этого требуется специалист-верстальщик, а не просто С#-разработчик "со знанием HTML".
Можно использовать несколько языков в проекте. Только вот выбранный ранее язык определяет идиосинкразию предыдущих разработчиков к чему-то новому и отличному от милого их сердцам make c #DEFINE TRUE FALSE.
Вот хороший пример совсем из другой области:
Because within the HPC community, the reaction to these new entrants is mostly not excitement at novel technologies and interesting new problems to solve, but scoffing at solutions which were Not Invented Here, and suggestions that those who use other platforms simply aren't doing "real" high performance computing – and maybe don't know what they're doing at all. You can see this attitude even in otherwise well-researched and thought-out pieces, where the suggestion is that it is genomics researchers' responsibility to alter what they are doing to better fit existing HPC toolsets. This thinking misses the rather important fact that it is HPC's job to support researchers' computing needs, rather than vice versa.
Уж казалось бы — HPC. Куда там ffmpeg'у какому-то, или обработке voip, которая вся сводится к манипуляции текстовыми заголовками. И то — людям стало УДОБНЕЕ пользоваться не байтогрызным MPI с его высокомерным сообществом, а написать свой Apache Spark. Фреймворк для ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ вычислений для Яве. На Яве, Карл!
Или вот еще оттуда, оцени уровень удобства байтогрызного фреймворка из 80х родом:
Today, MPI's error handling model is what it has always been; you can assign an errorhandler to be called when an error occurs in an MPI program, and when that happens you can... well, you can print a nice message before you crash, instead of crashing without the nice message.
С>>У меня есть замечательный пример зарепорченного бага в Freeswitch, из-за которого бага можно легко потерять уйму денег. Исправляли полгода, еще полгода прошло — до сих пор патч не принят в апстрим. При том, что будь логика той части вынесена в управляемый код — а там нет ничего сложного, обычное диспетчирование, то поправили бы за неделю.
lpd>Ты всерьез по одному конкретному случаю с Freeswitch делаешь вывод о всей технологии? Даже если там дело в buffer overflow на C++, такой баг поправляется очень легко. И я представляю, сколько нужно админить серверов и какие писать load-balancerы, чтобы обрабатывать VoIP на C#. Напомню, C# в 2-4 раза медленнее, чем C++, причем на ровном месте.
Там не С++, а вообще Си. Столь любимая многими сишечка. Без модулей. Без дженериков.
Выводы я делаю по примерам вроде того же bind, в котором до сих пор баги находят. По mysql с его дырками. Дело не только в языке, а и в культуре разработки. Вот тут весь тред копья ломают — ах, на чём же писать весь проект целиком, только на С++, или только на С#? При том, что в несчастном мобильном стартапе используется три языка и три разных специалиста — C# для Xamarin (и тем не менее для iPhone нужен отдельный специалист), JS и Angular — а это тоже отдельный мир, требующий своих специалистов, и наконец HTML5 c CSS3, который должен единообразно выглядеть везде, на всех устройствах, и для этого требуется специалист-верстальщик, а не просто С#-разработчик "со знанием HTML".
Можно использовать несколько языков в проекте. Только вот выбранный ранее язык определяет идиосинкразию предыдущих разработчиков к чему-то новому и отличному от милого их сердцам make c #DEFINE TRUE FALSE.
Вот хороший пример совсем из другой области:
Because within the HPC community, the reaction to these new entrants is mostly not excitement at novel technologies and interesting new problems to solve, but scoffing at solutions which were Not Invented Here, and suggestions that those who use other platforms simply aren't doing "real" high performance computing – and maybe don't know what they're doing at all. You can see this attitude even in otherwise well-researched and thought-out pieces, where the suggestion is that it is genomics researchers' responsibility to alter what they are doing to better fit existing HPC toolsets. This thinking misses the rather important fact that it is HPC's job to support researchers' computing needs, rather than vice versa.
Уж казалось бы — HPC. Куда там ffmpeg'у какому-то, или обработке voip, которая вся сводится к манипуляции текстовыми заголовками. И то — людям стало УДОБНЕЕ пользоваться не байтогрызным MPI с его высокомерным сообществом, а написать свой Apache Spark. Фреймворк для ВЫСОКОПРОИЗВОДИТЕЛЬНЫХ вычислений для Яве. На Яве, Карл!
Или вот еще оттуда, оцени уровень удобства байтогрызного фреймворка из 80х родом:
Today, MPI's error handling model is what it has always been; you can assign an errorhandler to be called when an error occurs in an MPI program, and when that happens you can... well, you can print a nice message before you crash, instead of crashing without the nice message.