99,9% фронтэнда написано JS, всё работает и не отваливается:)
Я в курсе :)
Может быть секрет в автоматизации тестирования кода, если вы про него слышали.
А есть ещё и статический анализ — до какой-то степени тоже тесты, но которые ещё и писать не нужно. Не знаю, как с ними в JS — наверное, тоже приемлемо, всё-таки язык мягко говоря распространённый, но вот сами анализаторы писать, наверное, жуть.
Указание типов это только 20% тормозов. То что в JS пишется в одну строчку на других языках может занять 10+.
Про Hascel ничего не знаю, кроме того, что вакансий по нему почти нет. Может там и правда удобно.
Когда-то, когда я только становился Scala-программистом, мне её рекламировали, как язык, на котором разработка почти столь же быстрая, как на ну грубо говоря Python (там был другой язык с динамической типизацией), но при этом с шикарной системой типов. Так вот прикол конкретно Scala в том, что она изначально задумывалась как, в том числе, язык для создания DSL, ну и традиционные вещи в ФП типа filter, map, flatMap и т. д. там во весь рост. При этом "под капотом" там местами какая-то лютая система типов, но ровно для того, чтобы для пользователя это был очень простой DSL, притом статически проверяемый. В общем, извините за излишнюю рекламу Scala — она здесь как пример, что статическая типизация — это не всегда синоним "неудобно писать код" — иногда да, но в целом нет. Так что, если вдруг ради интереса решите посмотреть в сторону Haskell — лучше гляньте на Scala. Она, скорее всего, покажется намного более понятной, да и используется "в дикой природе" намного чаще.
В данной ситуации ясно о чём речь. JS на браузере — он же фронтэнд. Если вам уровень мышления позволяет без проблем проанализировать консоль и понять откуда что прилетело, то JS, если нет то TS, WebAsembly и т.п. вам больше подойдут.
Так ведь некоторые и десктопные приложения в Electron пихают. И да, Scala тоже не полностью устраняет необходимость аккуратного кодинга.
По удобству и скорости разработки с JS может соревноваться только Python
Как "хейтер JS" не могу не прокомментировать :) Кроме времени на разработку есть ещё и время на отладку + поддержку. Чтобы что-то спрототипировать, конечно, скриптовые языки с динамической типизацией удобны. А вот с гарантиями, что через неделю что-нибудь где-нибудь не отвалится в самый неожиданный момент — тут уже сложнее.
Может, это прозвучит странно, но я бы не рискнул написать что-то большое на Python, да и на счёт C бы задумался — я банально не настолько в себе уверен. :) Мне намного комфортнее на Scala. Просто квалификация — понятие векторное: у кого-то чёткая дисциплина, позволяющая с бешеной скоростью писать на языках со статически-слабой проверкой типов, а кого-то не напрягает формулировать типы (не пишу "указывать", поскольку в Scala это далеко не везде обязательно, в отличие от старых версий Java), но при этом спокойнее, когда компилятор страхует, где только можно. Про Haskell вон вообще шутки ходят, мол, если скомпилировалось, то почти наверняка работает, как надо.
Будете смеяться, но насколько я помню, когда-то в Селектеле, грубо говоря, переписывали скрипты с Python на Haskell — ну, такой мелкий рефакторинг устроили, ага… Итог был, что даже с учётом отладки всё-таки медленнее, но тем не менее провалом, вроде, это не посчитали.
К тому же ладно, если я один пишу. А если команда в течение пяти лет? А если это открытый проект с априори неизвестной квалификацией контрибьютеров. Вон, в Mozilla, говорят, стали спать спокойнее, когда перешли на Rust для некоторых многопоточных библиотек (или их вообще не решались сделать многопоточными до этого — точно не помню...).
В общем, всё-таки выбор языка зависит от задачи, и кроме времени разработки есть ещё и время отладки/поддержки и вероятность, что что-то может сломаться внезапно. JS — это ещё один вариант в trade-off (для меня вряд ли приемлемый), но едва ли серебряная пуля, как его некоторые пытаются выставить в последнее время (а другие с OpenNet их называют нехорошими словами. Впрочем, фанатам Раста и всего, что не C, там тоже часто достаётся).
Спасибо! :) В некоторых случаях можно попробовать сделать разные обёртки для разных систем: например, на Windows, говорят, есть некий Structured Exception Handling (а вот как быть на старых Линуксах и прочих *nix...).
Но вещают, возможно, с DRM, а различных HTML5 DRM-модулей, насколько я понимаю, в природе не так уж много.
В любом случае, у меня цель ни в коем случае не отговаривать, а просто предупредить и посоветовать, в какую сторону смотреть при аналогичной проблеме. Я-то забил не потому, что посчитал, что проблемы принципиально не решаемые. Просто конкретно в этой задаче не было достаточной мотивации поставить 64-битный дистрибутив (у меня RPi 3, которая уже 64 бита, а Raspbian, как я понял, универсальный), чтобы проверить предположение. А когда поставил, было уже лень разбираться с телевизором :)
С какими проблемами я столкнулся перед тем, как забить:
с ходу не сумел запустить платную подписку ivi — были проблемы с DRM-модулем на Raspbian (возможно, дело в том, что ОС была для 32-х битного ARM), но как ютубосмотрелка заработало
сильно не уверен, что удастся получить разрешение больше порядка 320 строк через композитный выход, но если вы так же, как и я, хотите "оживить" большой кинескопный телевизор, то едва ли это принципиально.
Возможно, проблемы с DRM ушли бы на Ubuntu под AArch64, но когда я её установил, меня уже больше интересовал JTAG :)
Кстати, если кому интересно, у RPi есть не только видеовыход на HDMI, но и, внезапно, RCA — обычный композитный видеовыход на старый телевизор. Работает через общий джек. Только покупая 4-контактный кабель, нужно уточнять разводку — я с первой попытки купил единственный полностью неподходящий вариант из четырёх.
На малинку нужно просто поставить Ubuntu и на неё же OpenOCD. :) Заходить можно по SSH. Используется конфиг interface/sysfsgpio-raspberrypi.cfg. На правах рекламы: сам я уже подробности подзабыл, но эксперимент описан тут. Впрочем, сразу предупреждаю, для меня железная часть была неким чёрным ящиком, сам я работал со Scala+Asm+C. По поводу таймингов — действительно удивительно, но, может, просто итоговая скорость была не ахти, судя по тому, что прямая заливка данных в память была в час по чайной ложке (впрочем, тут нужно уже и на само ядро смотреть).
За счёт GPIO малинку можно использовать в качестве serial-порта (тут, конечно, и без того вариантов много) + JTAG-отладчик через OpenOCD. Использовал для отладки RISC-V софт-ядра. Это уже не совсем про "без программирования" :) Впрочем, это вполне себе без программирования конкретно RPi, так что для электронщика, знакомого с каким-нибудь диковинным ассемблером и не желающего отвлекаться, это, наверное, можно считать "без дополнительного программирования".
Видимо, это защита просто, чтобы неповадно было подгружать с SD-карты so-шку (десять раз переписанную злоумышленником), а потом обрабатывать пароли. Что-то вроде "разрешим грузить shared objects только оттуда, где действуют права доступа, а не с FAT". Я писал не с точки зрения взломщика, а с точки "хитрого на выдумки" бывшего пользователя телефона с 512Mb флеша и 32Gb SD-картой (так и не допилил тогда эту задумку).
Эмуляторы на FPGA — это, что ли вроде FireSim? Кстати, а чем это отличается просто от синтеза под FPGA? Или это синтез под одну FPGA, будто это другая FPGA с другими скоростными характеристиками?
Интересный факт: насколько я помню, если весь раздел подмонтирован с опцией noexec (как раньше было в Android для SD-карты — может, и сейчас), то для запуска ELF-файла не поможет даже явное указание линкера — он просто будет пытаться отобразить куски файла в память с PROT_EXEC, но получит ошибку. Тут уже нужно патчить линкер или что-то в этом роде (и сразу идёт лесом возможность иметь одну копию для всех сегментов кода — ну или нужно костылить ещё больше).
Ой, главное, написал же какой-то пример с неинициализированной переменной, потом думаю: "Вдруг там не воспроизведётся, лучше скопипасчу" :) Вот и докопипастился не посмотрев, извините. :) Только то ли я туплю, то ли это корректный сишный код тоже?
Я бы не рекомендовал пытаться разделить UB на логичный и "да к этому же никто не придерётся" :)
Например, как может повести себя приблизительно такой код? (пример скопирован со StackOverflow)
// Zero-filled global buffer of 16 characters
char destBuffer[16];
void Serialize(bool boolValue) {
// Determine which string to print based on boolValue
const char* whichString = boolValue ? "true" : "false";
// Compute the length of the string we selected
const size_t len = strlen(whichString);
// Copy string into destination buffer, which is zero-filled (thus already null-terminated)
memcpy(destBuffer, whichString, len);
}
Я в курсе :)
А есть ещё и статический анализ — до какой-то степени тоже тесты, но которые ещё и писать не нужно. Не знаю, как с ними в JS — наверное, тоже приемлемо, всё-таки язык мягко говоря распространённый, но вот сами анализаторы писать, наверное, жуть.
Когда-то, когда я только становился Scala-программистом, мне её рекламировали, как язык, на котором разработка почти столь же быстрая, как на ну грубо говоря Python (там был другой язык с динамической типизацией), но при этом с шикарной системой типов. Так вот прикол конкретно Scala в том, что она изначально задумывалась как, в том числе, язык для создания DSL, ну и традиционные вещи в ФП типа
filter,map,flatMapи т. д. там во весь рост. При этом "под капотом" там местами какая-то лютая система типов, но ровно для того, чтобы для пользователя это был очень простой DSL, притом статически проверяемый. В общем, извините за излишнюю рекламу Scala — она здесь как пример, что статическая типизация — это не всегда синоним "неудобно писать код" — иногда да, но в целом нет. Так что, если вдруг ради интереса решите посмотреть в сторону Haskell — лучше гляньте на Scala. Она, скорее всего, покажется намного более понятной, да и используется "в дикой природе" намного чаще.Так ведь некоторые и десктопные приложения в Electron пихают. И да, Scala тоже не полностью устраняет необходимость аккуратного кодинга.
Как "хейтер JS" не могу не прокомментировать :) Кроме времени на разработку есть ещё и время на отладку + поддержку. Чтобы что-то спрототипировать, конечно, скриптовые языки с динамической типизацией удобны. А вот с гарантиями, что через неделю что-нибудь где-нибудь не отвалится в самый неожиданный момент — тут уже сложнее.
Может, это прозвучит странно, но я бы не рискнул написать что-то большое на Python, да и на счёт C бы задумался — я банально не настолько в себе уверен. :) Мне намного комфортнее на Scala. Просто квалификация — понятие векторное: у кого-то чёткая дисциплина, позволяющая с бешеной скоростью писать на языках со статически-слабой проверкой типов, а кого-то не напрягает формулировать типы (не пишу "указывать", поскольку в Scala это далеко не везде обязательно, в отличие от старых версий Java), но при этом спокойнее, когда компилятор страхует, где только можно. Про Haskell вон вообще шутки ходят, мол, если скомпилировалось, то почти наверняка работает, как надо.
Будете смеяться, но насколько я помню, когда-то в Селектеле, грубо говоря, переписывали скрипты с Python на Haskell — ну, такой мелкий рефакторинг устроили, ага… Итог был, что даже с учётом отладки всё-таки медленнее, но тем не менее провалом, вроде, это не посчитали.
К тому же ладно, если я один пишу. А если команда в течение пяти лет? А если это открытый проект с априори неизвестной квалификацией контрибьютеров. Вон, в Mozilla, говорят, стали спать спокойнее, когда перешли на Rust для некоторых многопоточных библиотек (или их вообще не решались сделать многопоточными до этого — точно не помню...).
В общем, всё-таки выбор языка зависит от задачи, и кроме времени разработки есть ещё и время отладки/поддержки и вероятность, что что-то может сломаться внезапно. JS — это ещё один вариант в trade-off (для меня вряд ли приемлемый), но едва ли серебряная пуля, как его некоторые пытаются выставить в последнее время (а другие с OpenNet их называют нехорошими словами. Впрочем, фанатам Раста и всего, что не C, там тоже часто достаётся).
PS: получилось довольно по-капитански, знаю...
Спасибо!
Спасибо! :) В некоторых случаях можно попробовать сделать разные обёртки для разных систем: например, на Windows, говорят, есть некий Structured Exception Handling (а вот как быть на старых Линуксах и прочих *nix...).
Сделал статью по добавлению поддержки нового языка в CPD и PMD.
Хы-хы, слона-то я и не задокументировал, спасибо за баг-репорт :) Добавил абзац в статью с описанием, откуда оно взялось.
Но вещают, возможно, с DRM, а различных HTML5 DRM-модулей, насколько я понимаю, в природе не так уж много.
В любом случае, у меня цель ни в коем случае не отговаривать, а просто предупредить и посоветовать, в какую сторону смотреть при аналогичной проблеме. Я-то забил не потому, что посчитал, что проблемы принципиально не решаемые. Просто конкретно в этой задаче не было достаточной мотивации поставить 64-битный дистрибутив (у меня RPi 3, которая уже 64 бита, а Raspbian, как я понял, универсальный), чтобы проверить предположение. А когда поставил, было уже лень разбираться с телевизором :)
С какими проблемами я столкнулся перед тем, как забить:
Возможно, проблемы с DRM ушли бы на Ubuntu под AArch64, но когда я её установил, меня уже больше интересовал JTAG :)
Кстати, если кому интересно, у RPi есть не только видеовыход на HDMI, но и, внезапно, RCA — обычный композитный видеовыход на старый телевизор. Работает через общий джек. Только покупая 4-контактный кабель, нужно уточнять разводку — я с первой попытки купил единственный полностью неподходящий вариант из четырёх.
На малинку нужно просто поставить Ubuntu и на неё же OpenOCD. :) Заходить можно по SSH. Используется конфиг
interface/sysfsgpio-raspberrypi.cfg. На правах рекламы: сам я уже подробности подзабыл, но эксперимент описан тут. Впрочем, сразу предупреждаю, для меня железная часть была неким чёрным ящиком, сам я работал со Scala+Asm+C. По поводу таймингов — действительно удивительно, но, может, просто итоговая скорость была не ахти, судя по тому, что прямая заливка данных в память была в час по чайной ложке (впрочем, тут нужно уже и на само ядро смотреть).За счёт GPIO малинку можно использовать в качестве serial-порта (тут, конечно, и без того вариантов много) + JTAG-отладчик через OpenOCD. Использовал для отладки RISC-V софт-ядра. Это уже не совсем про "без программирования" :) Впрочем, это вполне себе без программирования конкретно RPi, так что для электронщика, знакомого с каким-нибудь диковинным ассемблером и не желающего отвлекаться, это, наверное, можно считать "без дополнительного программирования".
Видимо, это защита просто, чтобы неповадно было подгружать с SD-карты so-шку (десять раз переписанную злоумышленником), а потом обрабатывать пароли. Что-то вроде "разрешим грузить shared objects только оттуда, где действуют права доступа, а не с FAT". Я писал не с точки зрения взломщика, а с точки "хитрого на выдумки" бывшего пользователя телефона с 512Mb флеша и 32Gb SD-картой (так и не допилил тогда эту задумку).
Эмуляторы на FPGA — это, что ли вроде FireSim? Кстати, а чем это отличается просто от синтеза под FPGA? Или это синтез под одну FPGA, будто это другая FPGA с другими скоростными характеристиками?
Интересный факт: насколько я помню, если весь раздел подмонтирован с опцией
noexec(как раньше было в Android для SD-карты — может, и сейчас), то для запуска ELF-файла не поможет даже явное указание линкера — он просто будет пытаться отобразить куски файла в память сPROT_EXEC, но получит ошибку. Тут уже нужно патчить линкер или что-то в этом роде (и сразу идёт лесом возможность иметь одну копию для всех сегментов кода — ну или нужно костылить ещё больше).Ещё некий Verilog to Routing (VTR) на Гитхабе периодически проскакивает — это не аналогичный проект?
Не совсем в тему, просто забавный факт: GIMP умеет экспортировать картинки в сишный исходник:
-
Буду знать! Спасибо!
Ой, главное, написал же какой-то пример с неинициализированной переменной, потом думаю: "Вдруг там не воспроизведётся, лучше скопипасчу" :) Вот и докопипастился не посмотрев, извините. :) Только то ли я туплю, то ли это корректный сишный код тоже?
Я бы не рекомендовал пытаться разделить UB на логичный и "да к этому же никто не придерётся" :)
Например, как может повести себя приблизительно такой код? (пример скопирован со StackOverflow)
Отгадка