JS-разработчики подешевле будут
раскрыть ветку (156)
Я так питон начал учить. Кто знает? С начала суток прошло 320 мин. Программа должны выдать число часов и минут.
раскрыть ветку (43)
раскрыть ветку (16)
Вот такие пользователи библиотек, потом из 2 чисел не могут найти бОльшее, без метода max.
раскрыть ветку (15)
раскрыть ветку (12)
раскрыть ветку (11)
Тут главное - определиться. Он учится кодить на питоне, чтобы потом фигачить в продакшн (тогда нужно учиться юзать либы) или просто "для развития мышления"?
раскрыть ветку (10)
Путь в тупик, рано или поздно попадешь в ситуацию, когда нужно понимать как это работает уровнем ниже. Лучше понять это рано, чем поздно. В приличных конторах без понимания алгоритмов и умения выбора оптимальных решений к продакшну не пустят.
раскрыть ветку (1)
Так ему никто не посоветовал заюзать либу DateTime и заглянуть в её код. Ему предложили велосипед, оправдываясь "развитием мышления". Он запомнит, что это и есть решение подобной задачи. А потом мы с тобой будем выгребать из продакшена такие пизанские башни.. Которые а) не покрывают несколько важных случаев, б) написаны неподдерживаемо.
В приличных конторах без понимания алгоритмов и умения выбора оптимальных решений к продакшну не пустят.
Я вас умоляю. Сколько этих контор в % от рынка труда? Крохи. Да и зачем учить решать задачу неправильно, чтобы потом в приличной конторе его переучивали?
Впрочем, я лично такой подход production разработчиков полностью поддерживаю. Хоть и невозможно без слез смотреть как очередной мастер сохранил выборку всей таблицы из бд в массив и вытаскивает оттуда данные, пробегая по ним в цикле. Зато я понимаю, что конкуренции на рынке не предвидится.
раскрыть ветку (1)
Это же пример человека, делающего велосипед, вместо использования функций СУБД. В этом смысле - да, соглашусь. А то в нашей отрасли старым программистом быть сложнее, чем молодым :)
раскрыть ветку (5)
Оно в школе/универе развивается.
С начала суток прошло 320 мин. Программа должны выдать число часов и минут.
Да эта задача и есть уровня 4 класса обычной школы. Если у человека настолько не развито мышление, в программисты ему рано/противопоказано.
раскрыть ветку (4)
раскрыть ветку (3)
раскрыть ветку (2)
Да ладно, не принимай в серьёз) А если не можешь 320 разделить на 60 с остатком - сразу иди в программисты! Тем ценнее будем мы на рынке труда (как правильно заметил @vandersex).
раскрыть ветку (1)
Я то могу разделить. Но если человек хочет переучиться - почему бы и нет? Знаю нескольких таких, которые оказались действительно способными.
А как пользование библиотек к сравнению относится?🤔
Да, можно два дня писать код, вместо того, чтобы просто использовать библиотеку... Если ты с ней работать будешь регулярно, то тебе придётся узнать, как оно под капотом работает
Да, можно два дня писать код, вместо того, чтобы просто использовать библиотеку... Если ты с ней работать будешь регулярно, то тебе придётся узнать, как оно под капотом работает
раскрыть ветку (1)
Тут не тот случай. Парень (или дама) скидывает свое задание с курсов, где нужно посчитать сколько часов и минут в 320 минутах.
Самое время юзать библиотеку! Да?
В итоге вырастет очередная кодящая макака, которая впадает в ступор от любой сколь нибудь нетривиальной задачи.
Да как так то?!!!
Какой нахрен питон тебе если минуты в часы перевести не можешь.
Какую великую хрень ты можешь сваять с такими знаниями?
Какой нахрен питон тебе если минуты в часы перевести не можешь.
Какую великую хрень ты можешь сваять с такими знаниями?
раскрыть ветку (22)
ещё комментарии
Ебать , ты балбес.
Повторяю вопрос:
какую программу может сделать человек который не может перевести мин в часы? Это вам не jmp на jne править, тут хоть что-то надо понимать с чем работаешь.
Повторяю вопрос:
какую программу может сделать человек который не может перевести мин в часы? Это вам не jmp на jne править, тут хоть что-то надо понимать с чем работаешь.
раскрыть ветку (6)
Чувак, поддержу. Речь не про ЯП и алгоритмы, речь про понимание элементарной математики 6го класса.
раскрыть ветку (4)
При чем здесь ЯП и алгоритмы, если речь о математике 6го класса - деление с остатком? И связь часы/минуты?
раскрыть ветку (2)
Да хоть о 5м классе. Тоже самое можно сказать, "как он может говорить на английском, если он a/the путает". ЯП и математика это инструменты. Владение ими можно подтянуть, хоть с нуля, хоть с минус 100%
раскрыть ветку (1)
ещё комментарии
Да всё может быть. У всех бывают тупняки и все с этого начинали, не зная всего функционала. Я когда Python начинал учить был очень удивлен, когда узнал, что есть вшитая стандартная функция остатка по делению и это норма во всех ЯП, так как до этого редко пользовался этим в какой-нибудь области, кроме школьной теории чисел.
раскрыть ветку (4)
Даже если бы её не было, то можно было бы реализовать через костыли и обычное деление
Однако, этот оператор, это как правило, первая глава любого учебника, а математика чуть ли не начальная школа
И что на мой взгляд куда важнее, нужно прежде чем задавать вопросы - гуглить.
Чтобы быстрее учиться есть stackoverflow. Там порой объясняют какую реализацию эффективнее использовать
раскрыть ветку (1)
Да понятно когда в новом языке не знаешь операторов и функций. Бывает и на точку тупишь и вспоминаешь точка это, запятая или оператор сложения.
Но все же интересно знать какую программу хочет собрать индивид.
Может немного погорячился, понятно что это ребенок.
Ребенок , извини. Программирование это весело, все что надо для творчества это голова и комп (можно и на телефоне))
Но все же интересно знать какую программу хочет собрать индивид.
Может немного погорячился, понятно что это ребенок.
Ребенок , извини. Программирование это весело, все что надо для творчества это голова и комп (можно и на телефоне))
А ты сам-то без книжек и универа быстро бы решение понял? Может он самообразовывается, наоборот мог бы порадоваться за человека, токсик.
раскрыть ветку (5)
Это задача 3 класса, радуюсь за человека, что он не усвоил базовую математику, не умеет делить с остатком, ноза "пайтон" взялся.
раскрыть ветку (4)
Вы в 3 классе такие задачи решали? Не все были вундеркиндами, странно, что вы не в курсе существования обычных людей.
раскрыть ветку (3)
раскрыть ветку (2)
Ок, допустим школьник такую задачку решит. Возможно, спрашивал не школьник, а взрослый человек, который эти вещи давно позабыл. Ему теперь нельзя программированием заняться, не освоив школьную математику?
раскрыть ветку (1)
Я когда начал PHP изучать тоже часто ломал голову над простейшими вещами, дали человеку минуты, он радостный разделил и выдал время, а тут прибегает такой как ты и вопит:"ну лошара не знает функцию date();" после этого всего я понял, что правильными будут оба варианта, ибо результат будет правильным.
раскрыть ветку (1)
А я рад, что сейчас много таких разрабов. На их фоне, я с профильной вышкой, опытом и профилем на хаккерранке, могу прокатить за профессионала:D
ещё комментарии
раскрыть ветку (79)
раскрыть ветку (28)
Если вдруг кто не видел классику - https://www.destroyallsoftware.com/talks/wat
Enough about languages that suck. Let's talk about JavaScript!
раскрыть ветку (1)
Уж как я не люблю Js но тут же все логично и понятно, если хоть чуть чуть знаком с языком.
раскрыть ветку (15)
Объясните логику сложения пустого массива с пустым объектом и почему такое выражение вопреки математике некоммутативно?
раскрыть ветку (10)
я не знаком с js вообще, но видимо потому что массив ([]) имеет свой оператор + (который видимо имеет смысл добавить элемент в массив). и пустой объект({})) имеет дефолтную реализацию оператора +.
т.е. это 2 разных оператора, а не один и тот же.
раскрыть ветку (2)
Не, вообще не так, просто специфика преобразования типов. Просто в данном случае ( [] + {} ) массив, т.к. не подразумевает сложение будет преобразован в строку, а т.к. теперь мы прибавляем к строке объект будет тоже преобразован в строку.
Итого мы получим пустую строку + строку [object Object]
Там все немного тупее про приведение типов. Но все равно это это не объяснение такой "логичности".
первый уже разъяснили #comment_190887894
Ну со вторым все ясно унарный + приводит пустой массив к числовому значению 0.
раскрыть ветку (3)
Как и всегда - трудноуловимые баги, от которых рантайм не особо-то пытается спасти программиста.
раскрыть ветку (2)
раскрыть ветку (1)
Ну вообще да, в JS этого вполне достаточно) А как оно будет создано - втупую руками или багом проберется через много слоев абстракии - это уже не особо важно.
на самом деле всё вполне нормально и имеет свои обоснования как и почему что-то работает, например проблема с картинки это проблема с динамической типизацией и эта проблема присуща не только JS, но и почти всем языкам с ДТ.
раскрыть ветку (45)
php более адекватно приводит переменные к одному типу при сложении, python при попытке сложить строку и число выдаст TypeError, но это всё языки с ДТ
раскрыть ветку (11)
В PHP разделили операторы сложения и конкатенации, что избавило от большей части указанных проблем
раскрыть ветку (6)
В питоне не разделяли и тоже норм. Самый ад из-за неявного преобразования типов там, где его не следовало бы позволять.
А всё почему? Потому что кто-то когда-то придумал, что исключение - это хуже чем некорректно работающая программа. Ага. Гениально.
раскрыть ветку (5)
Просто нужно понимать что касты в жабаскрипте почти всегда в строки кастуют, потому нужно быть морально к этому готовым
А еще не писать на жабаскрипте, а писать хотяб на TS
раскрыть ветку (4)
раскрыть ветку (3)
Ну там может каст в число быть, если оно возможно, но все же лучше тогда уже явно делать касты, ну или не пользоваться этим без необходимости. На ноде той же только тайпуха.
раскрыть ветку (2)
Да всё правильно, если этим еще и пользоваться. то вообще "привет"! Но вопрос-то не в том. Это как раскидать по столовой ложки дырявые и стулья с пиками точеными, ну и в ыпоняли, и говорить потом. что, мол,вы ими не пользуйтесь, ерите еду и идите на крыльце поешьте, там и воздух свежий и скамейки и в целом как-то поуютнее. Претензия не к языку в целом. а к его рудиментам, от которых одна боль что тогда, что сейчас.
раскрыть ветку (1)
Ну выйти на крыльцо - хоть какой-то вариант, который спасает, особенно когда проект через пол года надо допиливать
раскрыть ветку (1)
А какой результат тут ожидался? Чисто логически тут хрень получается. 15% он привел к числу, потому что первым знаком цифра, $25 не привёл и посчитал за 0, итого: 3 + 15 + 0. Ещё и варнинг выдал, что вы чего-то странного хотите.
имеет свои обоснования"Ну так помнлучилось исторически, читайте спеку, вы просто ленивые и не хотите глубоко изучить свой инструмент!!1"
это проблема с динамической типизацией и эта проблема присуща не только JS, но и почти всем языкам с ДТ.
Картинка про слабую типизацию, что ортогонально динамичности. Подобным страдают статически типизированные С/С++, в то же время Python - строг, даже будучи динамическим языком.
раскрыть ветку (13)
А в чем строгость?
Поведение с картинки реализуемо где угодно?
Определи в питоне __neg__ от строки как int и доопредели в __add__(x) приведение x к типу this и получишь ту же чехарду с картинки.
На мой взгляд вся чехарда никак не связана с реальными проблемами.
Это как сломать мозг студенту ко/контр-инвариантностью когда в реале шансы на то что ему это понадобится примерно такие же как то что он придумает своя яп.
раскрыть ветку (12)
Определи в питоне __neg__ от строки как int и доопредели в __add__(x) приведение x к типу this
Чувствуете, сколько придется сделать, чтобы поиметь проблем? В JS это из коробки. Это разница между гибкостью и плохим дизайном.
раскрыть ветку (6)
Нет. Чтобы поиметь проблем нужно написать такое использование без понимания результата. На питоне ты везде получишь typeerror.
То есть нельзя просто бездумно написать что-то и ждать правильного ответ.
И там и там проблему придется отлавливать и появится она только в рантайме.
Суть в том что правила чтобы понимать результат довольно примитивны и описать их можно в трех строчках, но главное в том что они не нужны - у тебя все равно потребуют складывать числа с числами а строки со строками не важно приведет ли код к typeerr, к логической ошибке или вообще выполняется идеально.
раскрыть ветку (5)
Нет.
Чтобы поиметь проблем нужно написать такое
Чему же вы противоречите?)
И там и там проблему придется отлавливать и появится она только в рантайме.
В одном случае ошибка будет, в другой - нет (она может отправиться в увлекательное путешествие, поломать немало данных по пути и не факт, что вообще что-нибудь явно упадёт). Рантаймовые ошибки - всегда зло, но падение как можно раньше - это меньшее из них.
Суть в том что правила чтобы понимать результат довольно примитивны и описать их можно в трех строчках, но главное в том что они не нужны - у тебя все равно потребуют складывать числа с числами а строки со строками не важно приведет ли код к typeerr, к логической ошибке или вообще выполняется идеально
Если я правильно понял, речь о том что никто в здравом уме не будет складывать числа со строками в явном виде. ОК. Но как насчет 100500 слоёв абстракции и какого-нибудь JSON, где вместо числа пришла строка? Это может легко произойти на практике, а отлаживать "дрейфующие" ошибки в больших кодовых базах очень трудозатратно.
В Python другие дефолты, поэтому круг возможных проблем сужается до узкого круга мест, где программист в явном виде разрешил (и должным образом обработал) это безобразие.
раскрыть ветку (4)
Так же блин как и в питоне или любом другом языке - Если какой-то модуль тебе может выдать и строку и число описывай оба случая или явно сведи один к другому.
Просто проблема сама ничтожная.
А то что в питоне ошибка явная, так она все равно может раз в год вылезать плюс ошибки питнона это модно и ваша ошибка тоже может уйти гулять куда-то по try-except
раскрыть ветку (3)
А то что в питоне ошибка явная, так она все равно может раз в год вылезать
Не может. Если интерпретатор на нее наткнется, то сразу и вылетит.
Если какой-то модуль тебе может выдать и строку и число описывай оба случая или явно сведи один к другому.
Вы отталкиваетесь от того, что уже знаете причину, не замечая слона в комнате - время и силы на ее поиск.
и ваша ошибка тоже может уйти гулять куда-то по try-except
1. Она уйдет только туда, куда программист захотел
2. Там будет стек-трейс, который укажет на точку возникновения с точностью до оператора, где бы она ни всплыла.
раскрыть ветку (2)
Смотри.
Ошибка возникла не потому что js плохой. А потому что код
x = a + b; - неправильный если ты не уверен что a и b того типа который ты думаешь.
Он неправильный и в js и в питоне. Просто в питоне он вылетает с ошибкой а в js он делает не то что ты хотел.
Если ты думал что a и b целые, но и a и b оказались строками то и питон не увидит проблемы.
То есть ты должен сразу так не делать. Либо ты уверен в том откуда у тебя взялось значение либо тебе нужно его обработать. Оно так везде. Это существенная часть программирования.
раскрыть ветку (1)
Это вам здесь показывают проблему в "минимально воспроизводимом виде": a + b, а "в полях" это будет через 100500 абстракций и косвенно. Там полчаса еще придется раскидывать о том, что откуда пришло и отладчиком ходить.
Если ты думал что a и b целые, но и a и b оказались строками то и питон не увидит проблемы.
С какой вероятностью все должно сломаться в двух местах так, чтобы паззл идеально сложился?)
Если a - строка, а b - целое, то питон проблему увидит, а JS - нет. К примеру, один параметр вам пользователь нагенерил, другой - из запроса пришел.
ты должен сразу так не делать.
Баги есть везде и всегда. Потому ценен тот инструмент, который позволяет создавать качественные штуки быстро, не утопая в дебаге. А если твой инструмент содержит много граблей и ничем за это не вознаграждает, то это печально.
Определи в питоне __neg__ от строки как int и доопредели в __add__(x)Ну раз пошла такая пьянка, то давайте уж вспомним про перегрузку операторов в C++. Чоб нет то?
раскрыть ветку (4)
У плюсов и без этого есть о чем поговорить:
- указатели неявно приводятся к булам и наоборот,
- std::initilizer_list с перегрузками конструкторов дает впечатляющие спец.эффекты,
- препроцессор уже хоть и маргинализирован у модных-молодежных, но все равно добавляет магичности.
раскрыть ветку (3)
указатели неявно приводятся к булам и наоборота в чем проблема?
std::initilizer_list с перегрузками конструкторов дает впечатляющие спец.эффектыа можно поподробнее. а то я пишу на С или старых плюсах, а на новинки только облизываюсь.
препроцессор уже хоть и маргинализирован у модных-молодежных, но все равно добавляет магичности.испортить себе жизнь можно абсолютно любым инструментом если он в кривых руках. но в плюсах вроде констэкспрешенны, темплейты и перегрузка покрывают подавляющую часть того где юзался препроцессор.
раскрыть ветку (2)
а в чем проблема?
Семантически несовместимые типы свободно конвертируются друг в друга. Учитывая вывод типов, это может приводить трудноуловимым последствиям. Например, в плюсах примерно затем придумали nullptr_t, чтобы хоть как-то при перегрузках отличать интегральные типы от нулевого указателя.
а можно поподробнее
В плюсах можно конструировать объекты с помощью синтаксиса круглых скобок и фигурных. У обоих способов есть свои плюсы и минусы, но если есть хоть одна прегрузка с initializer_list, то компилятор будет всеми правдами и неправдами трактовать вызов фигурных скобок в его пользу. Это особенно неприятно для шаблонного кода.
Подробнее можно почитать у Мейерса в "Эффективном и современном С++".
испортить себе жизнь можно абсолютно любым инструментом если он в кривых руках.
Безусловно. Но стоит исходить из того, что код пишут не всегда гики, которым в кайф ползать по спеке, а зачастую - индусы (всех национальностей). И чем меньше wtf/sec у технологии, тем лучше.
раскрыть ветку (1)
Например, в плюсах примерно затем придумали nullptr_t, чтобы хоть как-то при перегрузках отличать интегральные типы от нулевого указателя.насколько я понимаю, чтобы отличать нулевой указатель от указателя на другой объект. целый тип не кастится неявно к типу указателя:
6.3.1.8 Usual arithmetic conversions
1 Many operators that expect operands of arithmetic type cause conversions and yield result
types in a similar way. The purpose is to determine a common real type for the operands
and result. For the specified operands, each operand is converted, without change of type
domain, to a type whose corresponding real type is the common real type. Unless
explicitly stated otherwise, the common real type is also the corresponding real type of
the result, whose type domain is the type domain of the operands if they are the same,
and complex otherwise. This pattern is called the usual arithmetic conversions:
т.е. неявно _Bool к указателю скастить не получится. а вот указатель к _Bool - без проблем и логика в этом преобразовании одинаковая для всех целочисленных типов:
6.3.1.2 Boolean type
1 When any scalar value is converted to _Bool, the result is 0 if the value compares equal
to 0; otherwise, the result is 1.
6.3.2.3 Pointersпри том это интуитивно понятно (имхо). не вижу никаких проблем.
3 An integer constant expression with the value 0, or such an expression cast to type
void *, is called a null pointer constant.
55) If a null pointer constant is converted to a
pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function
если есть хоть одна прегрузка с initializer_list, то компилятор будет всеми правдами и неправдами трактовать вызов фигурных скобок в его пользут.е. код типа A a{1, 2, 3}. если у класса A есть конструктор с std::initializer_list, то это будет его вызов даже не смотря на наличие конструктора принимающего 3 инта, верно? Ладно, пожалуй стоит почитать майерса, а то я слишком слабо знаком с этим чтобы увидеть тут какую-то беду.
все же беда не только в динамической типизации, а в том, что у JS она одновременно динамическая, слабая и неявная. Отсюда и возникает слишком много магических преобразований.
динамическая типизация , а так же что "+" - это как оператор сложения так и оператор для конкатенации строк
раскрыть ветку (16)
раскрыть ветку (15)
Потому что помимо классификации статической/динамической есть понятие сильной/слабой типизацией. Питон относится к сильно типизированным языкам, где нет неявного приведения типов. И это круто как по мне.
Потому что для джс, на момент его появления, главное было выполнится не смотря ни на что (тк юзался он для "оживления фронта", и был чем тр вроде доп. фишкой для css), сейчас, когда логика на фронте довольно сложна такое поведение является проблемой, поэтому и используются всякие Typescript и ему подобные
раскрыть ветку (13)
поэтому и используются всякие Typescript
Которые все равно слабую типизацию не делают сильной. Равно как и тайпхинты в PHP.
Единственный способ победить этот класс проблем - отказаться от JS-рантайма в бизнес логике (в пользу WASM, например).
раскрыть ветку (12)
Вы видимо не очень юзали тс, понятное дело все внешние источники данных должны прогонятся через анализаторы и орать если что то не подходит по типу или по интерфейсу
Вебасебляй уже несколько лет грозится выстрелить, но чет ни как, по мне это больше нежелание писать на джс и как то втиснуться в мир фронтендеров получющих 300к-400к за рюшечки, от чего у бэкенда бомбит
раскрыть ветку (10)
понятное дело все внешние источники данных должны прогонятся через анализаторы и орать если что то не подходит по типу или по интерфейсу
Понятно ли при этом, что такой дополнительной работой мы обходим ограничения TS, типы которого в рантайме исчезают?
раскрыть ветку (4)
тайпскрит - конвертится в джс при деплое - джс кладется на сервер и юзается
О каких ограничениях речь?
Если (допустим, хотя таких СПАшек дофига, неговоря уже о либах) у нас приложение не имеет общения с сервером, и не получает данные от чистых джс файлов (которые не проходили компиляцию тс в джс) и мы не юзали any и object, а описывали все взаимодействие через типы и интерфейсы, то откуда там взяться ошибки по типам? Если я инициализировал все свои переменные с определенным типом, тс проверил что я случайно не передал в функцию где ожидался number строку, ток как там может произойти косяк с типами?
Если же мы имеем общение с бэком и/или получаем данные от чистых джс файлов, но при этом я все эти данные прогоняю через анализатор (а без этого уже ни как, тс тут работает только как вспомогательная тулза со своими джененриками и перегрузками, но ни как валидатор типов) то опять же откуда взяться ошибкам?
раскрыть ветку (3)
Приложение, которое не получает данные извне - околобесполезно. Кроме того есть популярное в JS рантаймовое метапрограммирование (плагинчики, там, обобщенное программирование, на которое у дженериков не хватает сил), при котором TS вообще ничего не умеет сверх возможностей JS.
при этом я все эти данные прогоняю через анализатор
Вы вынуждены это делать, только потому, что это такая особенность платформы - за вас она этого не сделает.
раскрыть ветку (2)
Сеошники - раскручивающие свои проекты на лэндингах с ненавистью на вас смотрят)
Зацените последнюю версию, прокачка тс весьма и весьма
"при котором TS вообще ничего не умеет сверх возможностей JS." - эм..ну как бы тс конвертится в джс, а при написании кода дженерики, кастомные типы и перегрузки маст хэв для упрощенной разработки и читаймости, основные парадигмы, как эвент луп тс ясное дело не изменит, не пойму о чем спор
Ну да, я нигде обратное не утверждал. Плохо ли это? если делаете сайтец с простым джс функционалом, то нет, возможно даже будете юзать как фичи, если мы говорим о серьезной разработке то да, это проеб, но он хотя бы решаем
Зацените последнюю версию, прокачка тс весьма и весьма
"при котором TS вообще ничего не умеет сверх возможностей JS." - эм..ну как бы тс конвертится в джс, а при написании кода дженерики, кастомные типы и перегрузки маст хэв для упрощенной разработки и читаймости, основные парадигмы, как эвент луп тс ясное дело не изменит, не пойму о чем спор
Ну да, я нигде обратное не утверждал. Плохо ли это? если делаете сайтец с простым джс функционалом, то нет, возможно даже будете юзать как фичи, если мы говорим о серьезной разработке то да, это проеб, но он хотя бы решаем
раскрыть ветку (1)
Сеошники - раскручивающие свои проекты на лэндингах с ненавистью на вас смотрят)
Штош, это единственные люди, которые используют JS в том виде, в котором он задуман)
ну как бы тс конвертится в джс
"Конвертация" заключается в отрезании ценных метаданных типов. Это грустно и требует костылить всякие верификаторы-синхронизаторы типов.
а при написании кода дженерики, кастомные типы и перегрузки маст хэв
Это статика, я про динамику, то бишь рефлекшн. Типы TS там нельзя использовать.
раскрыть ветку (4)
и? по вашему коду чтоб такое было надо написать что-то типа
const a: string = 'hello';
const b: number = 3;
console.log(a + b);
Что сразу на ревью видно и можно за это отругатьа если делать по феншую то можно заюзать что-то типа такого https://ramdajs.com/docs/#add и тайпскритп при компиляции будет орать как не в себя
ИМХО
В джс много косяков, и весь синтаксический сахар который в нем есть аля классы, асинк авейт это тот еще адок вунтири, но как сам иструмент для реализации различных задач на фронте он вне конкуренции, а развитие всяких Typescript и ECMAScript делают разработку этих задач весьма комфортной
раскрыть ветку (3)
на ревью видно и можно за это отругать
Наглядно это сделано умышленно.
а если делать по феншую то можно заюзать что-то типа такого
Можно и еще больше костылей, почему бы и нет?)
развитие всяких Typescript и EMSA делают разработку этих задач весьма комфортной
Я бы сказал не такой болезненной. TS - действительно неплохое болеутоляющее (фиксация статических контрактов), но новые стандарты ES - это чаще всего только сахар, который концептуальные проблемы не исправляет.
раскрыть ветку (2)
Ну не наглядно я могу куда угодно фаталы напихать или данные колечить, фишка в том что я буду знать что переменная а имеет тип стринг или не буду при ревью))
Ну рамда не костыль, не надо с ней так) это же заточка под фп
Стандарты ES часто хватают пример именно от тс
Повторюсь, у джс, как и у любого языка есть проебы (от себя могу сказать про пых и го, если кто-то говорит что его яп идеален, то он его не достаточно юзал)), весьма очень ощутимые, НО для фронта он незаменим на сегодняшний день и не замены ему не предвидится, так что мы можем сколько угодно обсуждать что джс говно, но всякие модалки, поповеры и тп будем пилить на нем)
раскрыть ветку (1)
Ну рамда не костыль, не надо с ней так
Так это вы предложили)
для фронта он незаменим на сегодняшний день
Для общего случая с этим никто не спорил.
замены ему не предвидится
Вот это уже не факт. Понятно, что такая могучая штука, как Blazor, несмотря на свою зрелость для продакшна уже сейчас, не будет слишком популярна из-за порога вхождения, но если в WASM добавят сборщик мусора, то туда приедет компактный рантайм Python/Dart/etc. Тогда там целая толпа замен будет. И припрется во фронт очередная толпа неудачников-датасаентистов и мобильщиков.
IT-юмор
7.5K постов53.3K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору