Не знаю, треды такие не видел. А может видел, но уже не помню. Пишу я на связке php/python/go уже достаточно давно и в упор не вижу каких-либо явных преимуществ у python перед php (у php перед python тоже не вижу). По крайней мере, если речь о веб-разработке. На питоне писать приятнее (лично мне), но больше каких-то явных преимуществ я не вижу. Опять-таки если рассматривать вебню. Я это начал не холивара ради, а реально интересно.
Я в курсе, зачем нужны тесты - я не об этом. Я о том, что якобы есть какие-то там инструменты, которые помогут оценить покрытие кода тестами.
Под покрытием тестами я имею ввиду не что-то абстрактное, а именно «покрытие» — каждая часть кода выполнилась. Не во всех возможных комбинациях, а просто выполнилась, хотя бы раз.
Такое покрытие не слишком тяжело делать. Оно не усложняет код, не портит его читаемость. И оно ловит большинство простых ошибок сразу, на этапе тестирования, а не когда-то потом на сервере в рантайме. Нужен только инструмент, который скажет, что тесты прошли успешно, и покрыли весь код.
И такой инструмент есть. Для JS. Увы, для питона мне его найти не удалось.
Поэтому на JS я могу защититься от простых мелких ошибок. А на питоне — нет.
Пример у меня прямо сейчас перед глазами: после слияния веток проект начал гадить ошибками, и, самое страшное, нет никаких средств отладки проблемы
А вот был бы код покрыт тестами — сразу бы все ошибки нашлись! 🙂
Ещё есть всякие `node debug` / `node inspect`, смотря что отлаживать.
У JS есть неустранимая нерасширяемость, которая, например, не дает vue.js полноценно отслеживать изменения переменных, как то установка атрибута объекта или значения в массиве по индексу.
Там же есть спецметоды set и get. Делай атрибуты через них и следи. Массив тоже можно свой поверх встроенного сделать.
Руби? PHP? CL? Racket? Они постарее JS будут, а до питона почему-то не дотянули.
Они все моложе питона, потому и не дотянули. Кроме CL. Но тут сыграл роль второй пункт: «более удачный стартовый синтаксис» в питоне.
А до JS они не дотянули потому, что тянуть некому. PHP был первым подобным языком для веба, на нём куча наработок, потому он ещё держится, пусть и только в вебе. А руби кто будет развивать? Корпораций за ним нет, а сообщество слишком маленькое, и не вытягивает.
Тьюринг-полнота еще не делает язык языком общего назначения.
Верно. Языком общего назначения JS делают области его применения.
Язык выбирается под задачу. На любом «тьюринг-полном» языке теоретически возможно решить любую задачу. Но на некоторых языках её решать легко. Чем больше есть разных областей, где язык легко решает задачи, тем более общий это язык.
И для питона и для JS таких областей много, их можно считать языками общего назначения. Питон был таким изначально. JS стал им благодаря ноде, до ноды это был просто язык скриптования в браузере.
То, что кто-то решил натягивать сову на глобус, еще не значит, что сова стала общего назначения.
Хех. Да, сову JS пришлось немного растянуть, пришить ей пакетный менеджер, но натянулось же!
Я не говорю, что питон плох. Наоборот, он хорош! Потому он и популярен. Сейчас популярны всего три вида языков:
1. legacy, языки которые первыми заняли какую-то нишу, и держатся за счёт наработок в ней
2. языки, активно продвигаемые корпорациями
3. питон.
Я просто говорю, что не стоит расслабляться, питон уже не один в своих областях. JS — его главный конкурент. И отбирать программистов JS будет не у PHP и не у жавы, а именно у питона.
И оно ловит большинство простых ошибок сразу, на этапе тестирования, а не когда-то потом на сервере в рантайме. Нужен только инструмент, который скажет, что тесты прошли успешно, и покрыли весь код.
Нет никакой разницы в этом плане между построчно покрытым тестами кодом и не построчно покрытым. Одинаковые классы алгоритмических ошибок не попадут туда, при этом банальные синтаксические ошибки компилятор питона проверит в обоих вариантах, и тогда можно было бы говорить про необходимость покрытия кажлого модуля тестами. Питон погибче будет, и из-за этого намного сложнее для статического анализа и оптимизаций, и тем более для него однократное успешное исполнение строки ничего не значит.
А вот был бы код покрыт тестами — сразу бы все ошибки нашлись!
Он покрыт тестами и основной функционал прекрасно работает. Проблема возникает в системе сборки, которая почему-то решила картинки смешать в кучу, и эту систему сборки не представляется возможным отладить за короткое время.
Ещё есть всякие `node debug` / `node inspect`, смотря что отлаживать
Там же есть спецметоды set и get. Делай атрибуты через них и следи. Массив тоже можно свой поверх встроенного сделать.
Можно сделать defineProperty для конкретного атрибута, но нельзя сделать его для некоего произвольного свойства/элемента массива, который пользователь в будущем добавит.
Корпораций за ним нет, а сообщество слишком маленькое, и не вытягивает.
И за PHP корпораций нет. Дальше что?
JS стал им благодаря ноде, до ноды это был просто язык скриптования в браузере.
Node.js по праву можно считать отдельным диалектом JS, примерно как второй и третий питон. Я не понимаю людей, которые говорят «я пишу на жавоскрипте», но пишут они на ноде. Там даже банальный импорт модулей совершенно другой.
И отбирать программистов JS будет не у PHP и не у жавы, а именно у питона.
Никого он не будет отбирать. Индусы необучаемы, потому будут сидеть на своей нише до гроба. Нода возникла как раз из-за того, что на рынке возник избыток JS-макак, которых некуда девать.
Они даже в стандарте 2002 года уже есть. Так же как и Юникод и возможность использовать значения с плавающей точкой. А актуальный стандарт для Кобола от 2014 года.
Актуальный стандарт кобола - это J2SE 5.0, а всё остальное - это попытка к нему приблизиться, не потеряв совместимости со старым кодом.
Э, вроде, всё понятно. Питон популярнее «за счёт возраста, и более удачного стартового синтаксиса». А раз питон старше, то остальные моложе, не?
И за PHP корпораций нет. Дальше что?
Дальше он будет умирать, сдавая свои позиции сначала руби, потом питону, теперь JS-у, очень-очень медленно, потому что под него много наработок. См.п.1 из списка.
Нет никакой разницы в этом плане между построчно покрытым тестами кодом и не построчно покрытым.
Не покрытый тест не поймает случайные ошибки, вроде:
if no_data or flags["DOSOMEHTING"]: # <- тут опечатка
do_something()
Если в тесте этот код выполнится с no_data=True, то flags не считается, зато в рантайме с no_data=False он сгенерит ошибку. Покрытие тестами эту ошибку бы поймало.
Нода возникла как раз из-за того, что на рынке возник избыток JS-макак, которых некуда девать.
Нода это любопытный феномен. Ты пробовал на ней писать? Не какую-то илитную хурму типа транспиляторов, а простую макакичную «бизнес-логику» типа крудов? Это же такой адок, что просто капец. По-моему намного проще макаку обучить другому языку, чем пытаться из нее выжать что-то вменяемое на этом песдеце.
Если в тесте этот код выполнится с no_data=True, то flags не считается, зато в рантайме с no_data=False он сгенерит ошибку. Покрытие тестами эту ошибку бы поймало.
Это именно то, про что я писал: невозможно создать инструмент, который смог бы оценить покрытие всех вариантов работы произвольного алгоритма. А это именно то, что ты хочешь. Ты приводишь один из вариантов разветвления выполнения в условии, но их в реальной программе может быть огромное множество, в том числе неявных.
Нода возникла как раз из-за того, что на рынке возник избыток JS-макак, которых некуда девать.
Нода это любопытный феномен. Ты пробовал на ней писать? Не какую-то илитную хурму типа транспиляторов, а простую макакичную «бизнес-логику» типа крудов? Это же такой адок, что просто капец. По-моему намного проще макаку обучить другому языку, чем пытаться из нее выжать что-то вменяемое на этом песдеце.
Нет, бизнес-логику на ноде не писал, я ж не дебил какой-то. Да, это ад. Даже транскомпиляторы через анус выходят, регулярно ругаю тех придурков, которые написали его на чем попало вместо хорошего языка. Но комерсам побезразлично и довсё-равно, потому что кодеры нужны, их мало квалифицированных, а тут JS-макаку более-менее адекватную можно за миску риса нанять.
JavaScript уже победил. Это самый популярный язык. Стоит взглянуть на npm и его количество пакетов. Кто этого не понял - остался в 90-ых, скажем так. Следующая итерация js - это сделать «компилируемый js». Чтобы компилировался аля в сишечку с рантаймом как у go. Вот скринь моё сообщение и проверишь лет через 15 - «изобретут» 😀
JavaScript уже победил. Это самый популярный язык. Стоит взглянуть на npm и его количество пакетов. Кто этого не понял - остался в 90-ых, скажем так.
Так и запишем, языки, которые реализуют форматирование строк внутри стандартной библиотеки – это остатки девяностых. Всё прогрессивное человечество качает однострочные лефтпады со встроенными майнерами и рекламой из npm.
И отбирать программистов JS будет не у PHP и не у жавы, а именно у питона.
JS до сих пор выезжает на веб-обезьянках, которые не хотят учить второй язык.
Программисты пишут на питоне, потому что питон удобен. JS удобным может назвать только человек с адским синдромом утёнка. Чтобы отбирать программистов именно у питона, ему по крайней мере надо устаканить свои стандарты, за которыми не одна реализация не поспевает, и обзавестись вменяемой стандартной библиотекой.
У Python сильнейшие привязки к всяким machine learning инструментам. У php их нет, так что из альтернатив только Java и Scala, но на них быстро лепить медленнее. Так что Python самое то в этой нише.
Там часть пакетов нужна для того, чтобы привнести в язык то, что во многих других языках есть и так из коробки. Например, чего стоит отдельный пакет для функции inArray. Так что не сказал бы, что количество пакетов - показатель чего-то там.
JavaScript уже победил. Это самый популярный язык.
Это только из-за бурно растущего фронтенда, который впрочем уже устаканивается. Ситуация примерно как с пхп в нулевых, но где теперь ваш пхп? Когда переходят на стадию допиливания и длительной поддержки, такое говнище как жоэс и похапэ уже не прельщает никого. Популярность костыля typescript уже намекает на острую востребованность нормальных инструментов в нише жоэс.
Следующая итерация js - это сделать «компилируемый js». Чтобы компилировался аля в сишечку с рантаймом как у go.
Но это будет уже никакой не жоэс. Даже typescript уже другой язык. А так можно договориться, что го это следующая итерация пхп.
js ужасен и жив только из-за огромного количества веб-макак.
Так это в основном верстальщики с жквери. Толку с них? А с нормальными кодерами ситуация точно как везде: их мало, и они стоят дорого. За ваяние на ноде чего-то сложного тебя вообще обдерут как липку.
Следующая итерация js - это сделать «компилируемый js»
Это называется reasonml. Хочешь — компилируй в нативный бинарник, хочешь — в жабоскрипт через bucklescript.
Чтобы компилировался аля в сишечку с рантаймом как у go
Проще компилировать из других языков (того же rust) в wasm. Или в жс.
У других языков, как правило, более интересные системы типов (а не как в typescript) и более умный оптимизирующий компилятор, чем у всего, что есть в js-экосистеме. Ну и работает всё это на пару порядков быстрее, чем babel.
У других языков, как правило, более интересные системы типов (а не как в typescript) и более умный оптимизирующий компилятор, чем у всего, что есть в js-экосистеме. Ну и работает всё это на пару порядков быстрее, чем babel.
Ты заблуждаешься по поводу оптимизации. Хорошо написанный код на JS имеет производительность, сравнимую с хорошо написанным кодом на жаве, потому что по сути выполняемые команыд мало чем отличаются: те же самые объекты, те же самые классы, те же оптимизации локальных вычислений в стэк. Да, медленнее, чем какой-нибудь Go, и тем более языки без сборщика мусора. Но все равно очень быстро. Это и стало одним из ключевых факторов широкого распространения JS за сферу своей специализации, которого не случилось, например, у питона, потому что его нельзя настолько заоптимизировать - иначе бы питон уже давно победил всех и вся.
У жавы статическая типизация и распакованные данные (unboxing). У JS приходится перед любой операцией проверять тип.
Я жду ответа от адептов ноды. Я-то его знаю, но здесь, наверняка, есть люди, которые пишут на ноде и знают преимущества этого замечательного инструмента.
не адепт, но скажу. Преимущество ноды в том, что она есть. А это электрон и все что на нем. ЯП можно хаять в хвост и в гриву, но альтернатив-то все равно нет.
Переход на что-то другое будет, через WebAssembly, но постепенно.
А это электрон и все что на нем. ЯП можно хаять в хвост и в гриву, но альтернатив-то все равно нет.
Для меня это звучит как «А это фастфуд и все его производные. Сою и пальмовое масло можно хаять в хвост и в гриву, но альтернатив-то все равно нет.» 8-Е.
Переход на что-то другое будет, через WebAssembly, но постепенно.
Для меня это звучит как «А это фастфуд и все его производные. Сою и пальмовое масло можно хаять в хвост и в гриву, но альтернатив-то все равно нет.» 8-Е.
Звучит неважно, но альтернатив все равно нет )
Фастфуд в своей нише и никаких перспектив того, что его оттуда выбьет повар дядя Вася. И даже коллектив поваров с этим вряд ли справится.
Ну и потом - не состоит же фастфуд целиком из сои и пальмового масла, не все так плохо )
Преимущество ноды в том, что она есть. А это электрон и все что на нем
«Преимущество говна в том, что оно есть» - и чо дальше? На мой взгляд электрон - это полнейший провал, волна хайпа которого начинает спадать и электрон отправляется на заслуженный покой. Из приложений на электроне я пользовался дискордом и атомом - два прожорливых тормоза, интерфейс которых неродной для абсолютно любой ОС-и. Я до сих пор не могу привыкнуть к работе внешних панелей атома (изменение размера, сокрытие) - и это за несколько месяцев работы в нем.
ЯП можно хаять в хвост и в гриву, но альтернатив-то все равно нет.
Я бы согласился, если бы ты писал про веб. Но ты пишешь про ноду, а в своих областях применения она сама является сомнительной альтернативой другим решениям.
Переход на что-то другое будет, через WebAssembly, но постепенно.
JVM в браузере уже была. Похоронили.
Несоответствие инструментов Javascript современным требованиям уже очевидно, и появление новой технологии неизбежно произойдет. Вопрос заключается лишь в том, какая именно это технология будет.
Флэш, например, очень хорошо взлетел и доминировал над вебом долгое время. По сути WAsm - это что-то похожее на подход флэша, только более радикальный. Например, в отличие от JVM в WAsm нет сборщика мусора и безумной прожорливости в плане памяти - это были весьма важные изъяны, отбивавшие охоту пользоваться жава аплетами.
Несоответствие инструментов Javascript современным требованиям уже очевидно
А можно пример, в чём несоответствие и как оно должно быть
Нынче наметилась мода на богатые веб-приложения. Проблема в том, что JS имеет свои убогие типы и динамичность, и банально ограничивает разраба одним этим языком. Ограничения языка исправляются транспайлерами, убогость динамических типов довольно эффективно затыкается через JIT, но все равно раза в полтора-два проигрывает тому же asm.js, скомпилированному AOT, а сам asm.js с AOT где-то в 1.3 раза медленнее WebAssembly. К слову, советую заценить вот такой бенчмарк, в котором один из движков (SpiderMonkey) показывает намного ниже производительность тупо из-за особенностей реализации: https://github.com/sniklaus/experimental-raytracer
То есть, тяжело гарантировать, что оптимизация отработает правильно и ты не получишь внезапно многократную проскадку производительности.
Еще можно сделать виртуальную машину на жаваскрипте, но тормозить это будет адово, и тогда овчинка не стоит выделки. Таким образом, нужно фундаментально иное решение в обход JS, которое позволяло бы развязать руки разрабу фронтенда и при этом было бы кроссплатформенно. Гугл уже пытался делать свой https://ru.wikipedia.org/wiki/Native_Client
Мозилла разрабатывала asm.js, в итоге asm.js перерос в WebAssembly, и гугл отказался от Native Client в пользу WebAssembly.
А пока все эти пертурбации происходили, Цукерберг уже разрабатывал свой React Native, поскольку у React на игрофонах есть большие проблемы, например, в виде жора аккомы, которая ограничена, в отличие от лепестричества в розетке.
Ну а что у нас еще есть десктопного, кроссплатформенного и чтоб без сей с плюсами, от которых у молодого поколения икота и несварение?
Кутя, wx, жава не только под плюсы есть. К слову, я не понимаю, почему люди недолюбливают жаву за тормознутость и неродной вид, если у электрона точно такая же тормознутость и неродной интерфейс.
К слову, я не понимаю, почему люди недолюбливают жаву за тормознутость и неродной вид, если у электрона точно такая же тормознутость и неродной интерфейс.
Что ты не понимаешь? Те же люди и электрон недолюбливают.
Что ты не понимаешь? Те же люди и электрон недолюбливают.
Ну а как же
Преимущество ноды в том, что она есть. А это электрон и все что на нем. ЯП можно хаять в хвост и в гриву, но альтернатив-то все равно нет
Есть же люди, которым нравятся приложения на электроне. И эти люди будут писать, что кутя выглядит как неродная на маке, что жава жрет память, но не писать о том, что электрон отвратительно встраивается в абсолютно любую систему, причем, как и в плане внешнего вида, и в плане логики, как то любимое мной форматирование дат, которое даже в атоме не смогли осилить за столько лет.