Здравствуйте, Basil2, Вы писали:
B> Поэтому имхо знание языка является определяющим, а не предметная область. Но, насколько это соответствует истине, покажет практика.
Так не работает и с положением вещейна рынке это слабо коррелирует. Язык может быть совершенно любым, просто подходящим, в рамках предметной области на которой ты специализируешься.
B>ML да. Но не целиком, ибо часто прототипируют на питоне, а потом кодят финальное решение на плюсах. Все ж таки скорость решает, хотя сами библиотеки все равно одинаковые бинарные.
ML это далеко не только видео и картинки. Скорее DL — это очень небольшая его часть (по объёму рынка работы), просто более хайповая в данный момент времени. При этом само построение модели — это очень небольшая часть работы data scientist'а. И здесь решает не скорость работы кода, а удобство, возможность быстро проверить гипотезы, сделать визуализации, покрутить данные. Интегрировать с другими частями бизнес-системы можно через какой-нибудь RabbitMQ. А с точки зрения производительности подход в проектах примерно такой: 1) высокоуровнево оптимизируй существующий код на Python, 2) закэшируй, что можно закэшировать, 3) распараллель, что можно распараллелить, 4) перепиши на другом языке программирования. И до пункта 4 очень редко доходит дело.
Здравствуйте, Basil2, Вы писали:
B>Это понятно. Мой пойнт в том, что прикладную область (то, что приносит прибыль) можно изучить в процессе.
Да — наверное есть здесь новые тенденции — появление метатехнологий именно в области разработки ПО — т.е. прикладной областью становится уже не условная "медтехника", а область разработки ПО (машинное обучение, блокчейн, серверы и т.п.) с уже наработанным базисом инструментов, модулей и подходов. Если вспомнить 0-е, таких метатехнологий было мало, ограничивалось в основном фреймворками общего профиля под язык. А поскольку эти метатехнологии используются широко, происходит появление считай что новых подпрофессий — и компаниям выгодно брать специалиста в этой уже "разработческой" прикладной области. А порой это и вообще единственный шанс на успех проекта — вот нужен тебе спец по нейронкам, набивший где-то шишки и знающий как все это сделать — и всё, его не заменит никакой "хорошо знающий язык Х" человек — нет никаких гарантий ни по времени ни по результату, ты не можешь с таким человеком запускать коммерческий проект. Т.е. основная доля успеха проекта — это не хорошо написанный код на языке Х — а успешно обученная и интегрированная в продукт нейронка.
Здравствуйте, Basil2, Вы писали:
B>Это понятно. Мой пойнт в том, что прикладную область (то, что приносит прибыль) можно изучить в процессе. Если пишется софт для медоборудования, вряд ли много найдется кандидатов, что уже писали софт для этого оборудования. Все равно медоборудованию придется учить, и это не так долго (условно, полгода-год). А вот С++, со всеми подводностями, учить долго, и не факт что человек вообще сможет научится. Поэтому имхо знание языка является определяющим, а не предметная область. Но, насколько это соответствует истине, покажет практика.
Вы всерьез полагаете, что в сложной предметной области стоит использовать язык, который еще сложнее? С тз. временных затрат на обучение. По-моему это неправильно.
Здравствуйте, удусекшл, Вы писали:
DI>>Булшит конечно, использовать плюсы в ядре ОС можно, но только ограниченным подмножеством которое, чуть больше, чем си.
У>Виртуальные методы, абстрактные классы, шаблоны, алгоритмы — это "чуть больше, чем си"? Если так, то и весь язык просто чуть больше, чем си
А ты вот, например, понимаешь как работают виртуальные вызовы? Я расскажу:
1. В каждом объекте появляется указатель на таблицу виртуальных функций, выросший размер объекта приводит, например, к тому, что твой объект перестает помещаться в кеш линию, а это значит, что в память надо ходить чаще
2. С девиртуализацией компилятор может не справится, поэтому:
3. Чтение таблицы ВФ по этому указателю тоже может означать поход по памяти и плюс к этому вытеснение из кеша данных, которые могут скоро понадобится
4. И еще один поход по памяти собственно в функцию
Неудачное стечение обстоятельств и вызов ВФ оказывается медленней в сотни раз. При этом в С виртуальные функции при необходимости делаются легко.
Вот теперь, когда ты знаешь про стоимость этой абстракции, скажи будут в ядре ОС использовать ВФ?
Здравствуйте, Sharov, Вы писали:
S>Вы всерьез полагаете, что в сложной предметной области стоит использовать язык, который еще сложнее?
Как бы сложность решаемой задачи и сложность применяемых инструментов должны быть сопоставимы. В противном случае образуется слишком большой семантический разрыв.
Собственно, суть в том, что с конца 1980-х и начала 1990-х, когда у C++ было немного конкурентов и C++ приходилось применять где нужно, и где ненужно, очень сильно изменилась ситуация. И огромное количество задач стало сильно проще, посему для их решения и не нужен C++. Как и становятся ненужными толпы C++ разработчиков.
V>Да — наверное есть здесь новые тенденции — появление метатехнологий именно в области разработки ПО — т.е. прикладной областью становится уже не условная "медтехника", а область разработки ПО (машинное обучение, блокчейн, серверы и т.п.) с уже наработанным базисом инструментов, модулей и подходов. Если вспомнить 0-е, таких метатехнологий было мало, ограничивалось в основном фреймворками общего профиля под язык.
Не уверен, что распарсил правильно, но для машинного обучения это не так. В те годы был SAS и был R, никаких нормальных библиотек и фреймворков под языки программирования общего назначения не было. А сейчас как раз таки очень многое решается языками общего назначения и всякие "метатехнологии" типа SAS потихоньку уходят в закат, несмотря на то, что для многих вещей и SAS и R до сих пор лучше.
DI>Неудачное стечение обстоятельств и вызов ВФ оказывается медленней в сотни раз. При этом в С виртуальные функции при необходимости делаются легко.
DI>Вот теперь, когда ты знаешь про стоимость этой абстракции, скажи будут в ядре ОС использовать ВФ?
1) С чего ты решил, что я буду сувать виртуальные функции везде?
2) Буду, если надо. Собственно, на сях то же самое всё делают, но только всё ручками. Зачем?
Здравствуйте, so5team, Вы писали:
S>>Вы всерьез полагаете, что в сложной предметной области стоит использовать язык, который еще сложнее? S>Как бы сложность решаемой задачи и сложность применяемых инструментов должны быть сопоставимы. В противном случае образуется слишком большой семантический разрыв.
Сложность применяемых инструментов должна быть сильно проще(меньше) задачи, иначе зачем это все? Т.е. понятное дело, что есть какая-то изначальная сложность от которой не избавиться,
сложность, присущая задаче. И решение не должно сильно увеличивать имеющуюся сложность. Иначе у нас сложная предметаня область, сложная технология и пойди найди специалиста, если надо
здесь и сейчас.
Здравствуйте, Basil2, Вы писали:
B>Это понятно. Мой пойнт в том, что прикладную область (то, что приносит прибыль) можно изучить в процессе. Если пишется софт для медоборудования, вряд ли много найдется кандидатов, что уже писали софт для этого оборудования. Все равно медоборудованию придется учить, и это не так долго (условно, полгода-год).
Софт для медоборудования пишет всё-таки не врач, а программист.
Познавать тонкости той или иной медицинской специфики этот программист IMHO должен параллельно с написанием софта.
В этом контексте мне непонятно, о каком сроке полгода-год ты сообщил выше?
Это сроки разработки первой версии ПО?
Когда можно будет на практике проверить, что программист усвоил (а что — нет), проверив его софт?
Попутно замечу, что лечить пациента при помощи этого самого медоборудования будут сотрудники больницы, а не разработчики софта.
Также непонятно, зачем инженеру-программисту знать всю медицинскую специфику, если от него требуется разработка ПО для конкретной модели аппарата?
B>А вот С++, со всеми подводностями, учить долго, и не факт что человек вообще сможет научится. Поэтому имхо знание языка является определяющим, а не предметная область. Но, насколько это соответствует истине, покажет практика.
+100500
Это и есть разделение труда и специализация.
Что же касается предметной области, то разработчик софта, ИМХО, должен владеть ею в той самой мере, в которой она ему актуальна.
Так, например, разработчик софта для авиации не должен быть ни пилотом, ни авиадиспетчером.
Тем не менее, должен иметь представление о работе и того, и другого.
Здравствуйте, so5team, Вы писали:
S>И при этом они окажутся магическим образом лишены вышеперечисленных недостатков?
Конечно нет, просто разработчик будет понимать, сколько это стоит и не использовать без серьезной необходимости, а не топить за ВФ в ядре ОС, как один неофит рядом.
Здравствуйте, so5team, Вы писали:
S>>Вы всерьез полагаете, что в сложной предметной области стоит использовать язык, который еще сложнее?
S>Как бы сложность решаемой задачи и сложность применяемых инструментов должны быть сопоставимы.
У человека есть предел сложности с которой он может справится, у кого-то он выше, у кого-то ниже. Очевидно, что если применяемый инструмент сложен, то интеллектуальных ресурсов на решаемую задачу может и не хватить, все усилия уйдут на борьбу с инструментом.
S>В противном случае образуется слишком большой семантический разрыв.
Здравствуйте, Sharov, Вы писали:
S>Сложность применяемых инструментов должна быть сильно проще(меньше) задачи, иначе зачем это все?
Кому должна? И что все?
Если вам нужно построить будку для собаки, то вам не нужно не так уж много знать и уметь, да и требований к качеству использованных материалов особых не будет. И инструмента потребуется совсем немного. И к качеству инструментов особых требований так же не будет.
Если же вы захотите сделать авторскую мебель, которую будете продавать не за 100 рублей, то вам придется чему-то научиться. И совсем по другому подойти к выбору и материалов, и инструментов.
А если вы захотите делать деревянные музыкальные инструменты (скрипки, например, или виолончели, или рояли), то вам придется еще чему-то научиться. И требования к материалам и инструментам опять же станут еще жестче.
В разработке софта, собственно, тоже самое. Распознавание речи в реальном времени -- одно, CRUD приложения для сервиса с 1000 уников в день -- другое.
Здравствуйте, gardener, Вы писали:
... G>Но с другой стороны, пишущие код отлично, но не разбирающиеся в предметной области вообще не нужны. Никак их не используешь.
Почему же?
Тот факт, что человек пишет код отлично уже говорит о наличии и мозгов, и навыков.
Что же мешает подтянуть элементарные (ИМХО — глубоких то и не надо) знания предметной области?
Или здесь просто речь идёт о жадности работодателя, который хочет сразу всё в одном флаконе человеке, да ещё и за миску риса
P.S. Всё-равно разработчик софта должен работать бок о бок со специалистом предметной области.
Именно это и является залогом успеха разработки.
Здравствуйте, Denis Ivlev, Вы писали:
S>>И при этом они окажутся магическим образом лишены вышеперечисленных недостатков?
DI>Конечно нет,
Тогда к чему было щеки надувать?
Ключевой вопрос в том, нужна ли функциональность виртуальных функций или нет. Если нет, то вы не будете нести на это расходов и в C++. А если не нужна, то в C++ вы получите ее из коробки, да еще и с поддержкой девиртуализации со стороны компилятора. Да еще и плюшки в виде ключевых слов override и final в самом языке.
Что сильно лучше, чем колупаться с указателями на функции вручную.
AG>Тот факт, что человек пишет код отлично уже говорит о наличии и мозгов, и навыков. AG>Что же мешает подтянуть элементарные (ИМХО — глубоких то и не надо) знания предметной области?
Ничего не мешает. Но для некоторых предметных областей может потребоваться довольно много времени, чтобы человеку можно было поручить что-то серьёзное и ответственное. В некоторых случаях такого запаса времени нет.
Здравствуйте, so5team, Вы писали:
S>В разработке софта, собственно, тоже самое. Распознавание речи в реальном времени -- одно, CRUD приложения для сервиса с 1000 уников в день -- другое.
В распозновании речи важен алгоритм, а не тулзы. Потому что оптимизировать будут именно его(при необходимости), а не лепить мув-семантику везде где попало.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
