обычно дело в отсутствии законченной идеи. А чтобы идея в конце концов оказалась законченной (полной и достаточной и непротиворечивой) ее надо не стесняться формулировать, многократно формулировать вновь и вновь до тех пор пока не будут разрешены все противоречия, как минимум.
То, что язык использовался и используется - это факт, который вы сами можете проверить.
Разве можно сомневаться что какой то язык использовался и продолжает использоваться? Что вы пытаетесь доказать?
Я же вам написал: мне кажется, пик успеха этого языка давно пройден, еще и судя по тому какой страшной формы в нем операторы применяются, %>% чем то Perl напоминает(который кстати тоже использовался и используется).
А так Visual Basic тоже использовался и используется, или вы будете спорить?
Я даже подозреваю что в Visual Basic-е тоже есть встроенный тип для табличных данных, возможно кому-то с ним тоже удобно работать для аналитики.
Я вообще XSLT предпочитаю для серьезных решений, для не серьезных я всегда могу что-то придумать на тех инструментах которые в данный момент под рукой. Не устанавливать же целую среду разработки для эпизодических задач.
по моему все гораздо хуже, это стиль какого-то праздника для младших школьников а-ля взрослый корпаратив - вроде бы серьезная тема но с котиками и, видимо, для котиков.
Как по мне это просто не уважение к аудитории, или аудитория уже достаточно пушистая?
Нет, логически такой вывод из приведённой цитаты не следует
я не претендую на то что моя логика единственно верная, возможно мне не хватает информации. Но вместо того чтобы привести аргументы, действительно что то доказывающие, вы как будто повторяете какую-то мантру:
R использовался ранее и продолжает использоваться по сей день.
Если для вас это все объясняет, я в принципе не против, но как то тоже выглядит загадочно.
на сколько я понимаю из этой цитаты пик успеха языка R был пройден в 2010 году. Заметьте на пике успеха язык был не победителем конкурса, а всего лишь вошел в список на непонятно каком месте. Через 15 лет доставать из чулана такого призера, на мой взгляд как-то странно и даже не солидно для ведущей компании в мире поисковиков.
И меня например поражает школьная наивность смешанная с восторгом вот таких заявлений:
благодаря которому конструкции вида f(g(h(x, 1), 'col'), 'mean') превращаются в изящное x %>% h(1) %>% g('col') %>% f('mean')
потому что ничего изящного я тут не вижу (попробуйте переставить параметры местами или использовать конструкцию для функций с другим количеством параметров).
Но я с интересом, думаю, почитал бы про RStudio
Всё это бесплатно, с удобным GUI и мощным движком визуализации данных.
Казалось бы, специализированный инструмент для аналитиков оказался практически незаменимым обычному разработчику в повседневной разработческой жизни.
RStudio как специализированный инструмент для аналитиков.
Кстати коммьюнити языка которое прячется в телеграмм и выставляет предварительные условия для входа совсем не внушает доверия, похоже на какую-то секту, на мой субъективный взгляд.
В 2010 году R вошёл в список победителей конкурса журнала Infoworld в номинации на лучшее открытое программное обеспечение для разработки приложений[9].
Удивительно, с какой огромной скоростью русскоязычный сегмент интернета осваивает зарубежные технологии.
Кстати написан достаточно аккуратно. И структурировано. Учитывая размер проекта и кросс платформенность вообще шедевр.
с тем что шедевр я согласен, потому что оно действительно работает и под win и под Линуксы, причем под несколько разных. Более того под win еще и проект в VS можно сгенерировать тем же make-file-ом и отлаживать любые потроха в современной визуальной среде - это просто чудо!
К сожалению
аккуратно. И структурировано
это далеко не всегда синонимы "профессионально", расставить правильно табуляции, выписать переменные в столбик много ума не надо, а вот чтобы они тысячами не плодились надо было бы подумать.
на новомодных YAML/json сделаете.
там все есть и XML тоже в мегабайтных текстовых файлах. И эти размеры и разнообразие опять же не признак профессионализма, это скорее признак не соглассованной работы, работы без формулировки общей концепции - что у кого получилось просто склеиваем чтобы в общем работало.
Положительный момент в том что это такая библиотека готовых РАБОТАЮЩИХ решений, правда перепутанных между собой, но которые при желании можно отковырять почистить и использовать.
да, на самом низком уровне м-файлы действительно скопированы, сотни(!) раз. Но кроме того что их надо скопировать имя подпроекта (каталога, библиотеки, каких то переменных) прописывается в 20-ти, в 70-ти, ... местах, то есть оно уже все равно дошло до уровня когда просто копирование уже не работает, все равно с навешанной лапшой приходится разбираться-фильтровать ее :( .
чем желание изучать командную строку и её утилиты (да, make из их числа).
когда вы изучите все утилиты командной строки вы можете внезапно выяснить что вам придется перейти работать в другой Шел с совсем другим набором утилит этой новой оболочки, и куда же вы денете все что вы вызубрили до этого, интересно, в таком случае?
А еще вы можете обнаружить что разные утилиты могут выполнять одни и те же функции. И наверно чтобы не забыть все утилиты вам придется применять по возможности как можно больше видов этих утилит в своем проекте, а хорошо ли это для проекта? Я боюсь что не хорошо. Кстати, вот мы и выяснили откуда берется зоопарк утилит в проектах, получается от желания изучить как можно больше утилит командной строки.
расскажете на пару абзацев что там заскриптовано, раз уж вам достаточно просто прочитать? Только учтите это только один makefile из системы makefile-лов в этом репозитории (внутри дерева каталогов) - надо рассказать про эту систему, а не про то какие переменные там определены. Если что я сам до конца еще не разобрался, вы мне можете очень сильно помочь.
Интересно сколько времени надо чтобы прочитать несколько тысяч строк скрипта?
вот еще можно почитать на досуге на 4000 строчек чтения:
мне одна доподлино известна: если у вас есть функция для которой обязательно надо вызвать двойника (антипод), например Lock-Unlock, в Си надо вручную отследить все выходы из области видимости, проблема решилась в С++, компилятор умеет.
я работал с англоязычным коллегой и у нас была супер навороченная embedded IDE для кастомных систем на кристале - АРМ интегрированный с цифровыми спутниковыми приемниками (4 штуки) с которых мегабайты трафика в секунду приходили. Так для отладки этот коллега нашел тулзу которая записывает движения мышью и нажатия, при этом тулза запоминает по картинке кнопки, галочки,... - куда нажимать (анализирует картинку!), в принципе тоже можно было скрипты написать и делать то же самое скриптами, но кто будет оплачивать такую работу по написанию тулзов. Вот там действительно страшная IDE была, там несколько уровней периферии визуально конфигурировались, дело в том что если бы это было НЕ визуально то разобраться с этими уровнями мне кажется было бы вообще не реально, визуально ты хоть можешь видеть какой-то граф пройденных-доступных зависимостей, в виде линейного текста ограниченного экраном это не реально представить и обозревать и соответственно ориентироваться в этом.
от меня вы же такого не слышали, а получается что это вы меня обзываете " таким "новатором" " :), а эта роль ругательная и меня расстраивает что вы ее ко мне применили :) !
Я, наоборот, всех уверяю что в любом программировании (не только в embedded) визуальная среда не помеха DevOps-у. Тут как раз это не зоопарк инструментов, а для каждого ТИПа задачи свой инструмент, вы же не будете дебагом заниматься на тулзах DevOps-а!
Вот и здесь вас спрашивали:
Вы правда думаете, что msbuild из скрипта не запустить?
Так и в любом IDE проект (компиляция, линковка, и что угодно) из скриптов запускается! Если ваши новаторы этого не знают- не умеют, чьи это проблемы? Может это потому что вы IDE сами не цените и новаторов соответствующих подбираете которые тоже сначала не ценят, а потом, когда оценят, разобраться до конца не могут?
Кстати в нормальных IDE без мышки одной клавиатурой вполне можно обходиться, при наличии навыков.
Лучше, быстрее и надежнее просто ликвидировать лишнюю стадию компиляции Си-кода и просто самим взять и написать лаконичный код на ассемблере.
вот это вы конечно загнули!
Я когда-то 20+ лет назад писал для 8-ми битных МК на ассемблере полную прошивку (-и), когда я наконец нашел С-компилятор для тех микроконтроллеров моему счастью и восторгу не было предела - я это поэтому очень хорошо помню, счастье нельзя забыть. Я думаю нет более широкого шага в повышении так называемого уровня языка програмирования чем от ассемблера к, даже самым первым, версиям плейн-Си при полном сохранении функциональности вплоть до того что в Си можно использовать встроенный ассемблер, можно проверять сгенерированный ассемблер, можно управлять памятью круче чем в ассемблере еще до этапа компиляции!
в этом отношении очень показательно, мне кажется, всеобщее восхищение инструментами Командной Строки и отказ от инструментов с визуальным интерфейсом. Прям вот стремление к всему новому и современному бьет ключом, скоро на самые современные перфокарты перейдут и будут восхищаться как это здорово.
или всё-таки под каждую задачу лучше подходящий инструмент?
эта опечатка по Фрейду :) ? Может не под каждую задачу, а под каждый тип задачи?
Про чувство такта обычно вспоминают на грустных мероприятиях. Но, в любом случае, извините что помешал вам устроить публичный междусобойчик.
обычно дело в отсутствии законченной идеи. А чтобы идея в конце концов оказалась законченной (полной и достаточной и непротиворечивой) ее надо не стесняться формулировать, многократно формулировать вновь и вновь до тех пор пока не будут разрешены все противоречия, как минимум.
а до этого вы меня упрекали в сарказме всезнающего...
как же вам угодить-то?
Разве можно сомневаться что какой то язык использовался и продолжает использоваться? Что вы пытаетесь доказать?
Я же вам написал: мне кажется, пик успеха этого языка давно пройден, еще и судя по тому какой страшной формы в нем операторы применяются, %>% чем то Perl напоминает(который кстати тоже использовался и используется).
А так Visual Basic тоже использовался и используется, или вы будете спорить?
Я даже подозреваю что в Visual Basic-е тоже есть встроенный тип для табличных данных, возможно кому-то с ним тоже удобно работать для аналитики.
Я вообще XSLT предпочитаю для серьезных решений, для не серьезных я всегда могу что-то придумать на тех инструментах которые в данный момент под рукой. Не устанавливать же целую среду разработки для эпизодических задач.
по моему все гораздо хуже, это стиль какого-то праздника для младших школьников а-ля взрослый корпаратив - вроде бы серьезная тема но с котиками и, видимо, для котиков.
Как по мне это просто не уважение к аудитории, или аудитория уже достаточно пушистая?
я не претендую на то что моя логика единственно верная, возможно мне не хватает информации. Но вместо того чтобы привести аргументы, действительно что то доказывающие, вы как будто повторяете какую-то мантру:
Если для вас это все объясняет, я в принципе не против, но как то тоже выглядит загадочно.
на сколько я понимаю из этой цитаты пик успеха языка R был пройден в 2010 году. Заметьте на пике успеха язык был не победителем конкурса, а всего лишь вошел в список на непонятно каком месте. Через 15 лет доставать из чулана такого призера, на мой взгляд как-то странно и даже не солидно для ведущей компании в мире поисковиков.
И меня например поражает школьная наивность смешанная с восторгом вот таких заявлений:
потому что ничего изящного я тут не вижу (попробуйте переставить параметры местами или использовать конструкцию для функций с другим количеством параметров).
Но я с интересом, думаю, почитал бы про RStudio
RStudio как специализированный инструмент для аналитиков.
Кстати коммьюнити языка которое прячется в телеграмм и выставляет предварительные условия для входа совсем не внушает доверия, похоже на какую-то секту, на мой субъективный взгляд.
Удивительно, с какой огромной скоростью русскоязычный сегмент интернета осваивает зарубежные технологии.
те кто используют СУБД MS SQL знают как что угодно сделать быстро, без лишних движений, там куча документации по делу. При чем здесь 1С?
с тем что шедевр я согласен, потому что оно действительно работает и под win и под Линуксы, причем под несколько разных. Более того под win еще и проект в VS можно сгенерировать тем же make-file-ом и отлаживать любые потроха в современной визуальной среде - это просто чудо!
К сожалению
это далеко не всегда синонимы "профессионально", расставить правильно табуляции, выписать переменные в столбик много ума не надо, а вот чтобы они тысячами не плодились надо было бы подумать.
там все есть и XML тоже в мегабайтных текстовых файлах. И эти размеры и разнообразие опять же не признак профессионализма, это скорее признак не соглассованной работы, работы без формулировки общей концепции - что у кого получилось просто склеиваем чтобы в общем работало.
Положительный момент в том что это такая библиотека готовых РАБОТАЮЩИХ решений, правда перепутанных между собой, но которые при желании можно отковырять почистить и использовать.
да, на самом низком уровне м-файлы действительно скопированы, сотни(!) раз. Но кроме того что их надо скопировать имя подпроекта (каталога, библиотеки, каких то переменных) прописывается в 20-ти, в 70-ти, ... местах, то есть оно уже все равно дошло до уровня когда просто копирование уже не работает, все равно с навешанной лапшой приходится разбираться-фильтровать ее :( .
когда вы изучите все утилиты командной строки вы можете внезапно выяснить что вам придется перейти работать в другой Шел с совсем другим набором утилит этой новой оболочки, и куда же вы денете все что вы вызубрили до этого, интересно, в таком случае?
А еще вы можете обнаружить что разные утилиты могут выполнять одни и те же функции. И наверно чтобы не забыть все утилиты вам придется применять по возможности как можно больше видов этих утилит в своем проекте, а хорошо ли это для проекта? Я боюсь что не хорошо. Кстати, вот мы и выяснили откуда берется зоопарк утилит в проектах, получается от желания изучить как можно больше утилит командной строки.
ну вот вам makefile, для примера:
https://github.com/LibreOffice/core/blob/master/Repository.mk
расскажете на пару абзацев что там заскриптовано, раз уж вам достаточно просто прочитать? Только учтите это только один makefile из системы makefile-лов в этом репозитории (внутри дерева каталогов) - надо рассказать про эту систему, а не про то какие переменные там определены. Если что я сам до конца еще не разобрался, вы мне можете очень сильно помочь.
Интересно сколько времени надо чтобы прочитать несколько тысяч строк скрипта?
вот еще можно почитать на досуге на 4000 строчек чтения:
https://github.com/LibreOffice/core/blob/master/RepositoryExternal.mk
Я кстати сомневаюсь что тут применим какой то термин типа makefile-эффект, потому что скопировать это чтобы переиспользовать вряд ли возможно.
нет пока.
мне одна доподлино известна: если у вас есть функция для которой обязательно надо вызвать двойника (антипод), например Lock-Unlock, в Си надо вручную отследить все выходы из области видимости, проблема решилась в С++, компилятор умеет.
я работал с англоязычным коллегой и у нас была супер навороченная embedded IDE для кастомных систем на кристале - АРМ интегрированный с цифровыми спутниковыми приемниками (4 штуки) с которых мегабайты трафика в секунду приходили. Так для отладки этот коллега нашел тулзу которая записывает движения мышью и нажатия, при этом тулза запоминает по картинке кнопки, галочки,... - куда нажимать (анализирует картинку!), в принципе тоже можно было скрипты написать и делать то же самое скриптами, но кто будет оплачивать такую работу по написанию тулзов. Вот там действительно страшная IDE была, там несколько уровней периферии визуально конфигурировались, дело в том что если бы это было НЕ визуально то разобраться с этими уровнями мне кажется было бы вообще не реально, визуально ты хоть можешь видеть какой-то граф пройденных-доступных зависимостей, в виде линейного текста ограниченного экраном это не реально представить и обозревать и соответственно ориентироваться в этом.
от меня вы же такого не слышали, а получается что это вы меня обзываете " таким "новатором" " :), а эта роль ругательная и меня расстраивает что вы ее ко мне применили :) !
Я, наоборот, всех уверяю что в любом программировании (не только в embedded) визуальная среда не помеха DevOps-у. Тут как раз это не зоопарк инструментов, а для каждого ТИПа задачи свой инструмент, вы же не будете дебагом заниматься на тулзах DevOps-а!
Вот и здесь вас спрашивали:
Так и в любом IDE проект (компиляция, линковка, и что угодно) из скриптов запускается! Если ваши новаторы этого не знают- не умеют, чьи это проблемы? Может это потому что вы IDE сами не цените и новаторов соответствующих подбираете которые тоже сначала не ценят, а потом, когда оценят, разобраться до конца не могут?
Кстати в нормальных IDE без мышки одной клавиатурой вполне можно обходиться, при наличии навыков.
похоже на перевод даташита. Жалко что у меня 25 лет назад не было такого перевода.
вот это вы конечно загнули!
Я когда-то 20+ лет назад писал для 8-ми битных МК на ассемблере полную прошивку (-и), когда я наконец нашел С-компилятор для тех микроконтроллеров моему счастью и восторгу не было предела - я это поэтому очень хорошо помню, счастье нельзя забыть. Я думаю нет более широкого шага в повышении так называемого уровня языка програмирования чем от ассемблера к, даже самым первым, версиям плейн-Си при полном сохранении функциональности вплоть до того что в Си можно использовать встроенный ассемблер, можно проверять сгенерированный ассемблер, можно управлять памятью круче чем в ассемблере еще до этапа компиляции!
в этом отношении очень показательно, мне кажется, всеобщее восхищение инструментами Командной Строки и отказ от инструментов с визуальным интерфейсом. Прям вот стремление к всему новому и современному бьет ключом, скоро на самые современные перфокарты перейдут и будут восхищаться как это здорово.
эта опечатка по Фрейду :) ? Может не под каждую задачу, а под каждый тип задачи?