JavaScript 30 лет

А сами такие классы делаем, то считается?

Нет, это же то же самое, что «сделано в библиотеке». Вы один раз это сделали хорошо и забыли, а не постоянно пытаетесь вспомнить про delete.

Кросскомпиляция, какая прелесть. Я бы сказал, что это не совсем частый кейс, ну т.е. имеет место быть конечно, но не подходит под теримн «на каждом шагу».

А позволь полюбопытствовать, почему бы под винду не собирать под виндой? И что там за проект, компилятор и т.п.?

Ок, я не про язык в целом. Я про свои (возможно специфичные) задачи.

Винды у меня нет с 2006 и не будет. По разным, по большей части идеологическим причинам. Ну и материальным в том числе - мне некуда особо ее ставить. А до последнего времени и негде было особо ее брать.

К слову, эту проблему в последнее время великолепно на всех языках стал решать гитахб. Просто создаешь скрипт сборки, заливаешь проект на гитхаб - и вот тебе под все нужные системы бинарники. Плохо только что это не единственная проблема, а одна из.

Мне кажется нас жирно троллят какими-то фантазиями или это нейроночка.

Тебя удивляет, что у кого то может не быть винды? Серьезно? На linux.org.ru?

Не понимаю чем лоровцам нравится это бездарное поделие.

У этого бездарного поделия интерпретатор с полной реализацией языка требует намного меньше ресурсов чем JS, поэтому лезет даже в микроконтроллеры.

Ну и по мне, асинхронщина - треш,

А лично мне async-функции – единственное, что нравится в js. Пишешь обычный императивный код, а оно под капотом само в цепочки фьючерсов компиляеццо. Когда мне приспичит сделать асинхронный DSL, сначала сяду разберусь как эта компиляция работает.

сделал себе библиотеку scats и пишу на ts почти как на scala, чувствую себя ок без этих вот ваших undefined и null

Пишешь обычный императивный код, а оно

Эээ... Ну, может быть. Но всё равно у тебя там что-то, что «ещё не готово» и это требует другой архитектуры приложения.

сделал себе библиотеку scats и пишу на ts почти как на scala

https://dictionary.cambridge.org/us/dictionary/english/scat

scat noun (WASTE)

feces (= solid body waste) left by animals:

Bone may be found intact inside scats.

Хорошая библиотечка? Надеюсь, не сильно код пахнет потом? Руки часто моешь?

Не будь слабаком, лабай в машкоде чё!

Неа, rust может и станет ведущим системным, но сяшка всяко до 22века доживёт как живая латынь, вот чё может зазомбировать си так это zig который идёт со встроенной сяшкой что позловяет тащить окаменевшее а иноватироватб зигушками

До 22 не доживёт, только в архивах, как QBasic какой-нибудь. ИИ-шкой всё переделают.

ага, гугл не индексирует мою репу (да и пофиг если честно). вот мое: https://medium.com/@penkov.vladimir/scats-bridging-the-gap-between-scala-and-...

Ох не знаю на счёт «ии все переделает». Местами такое говно получается, при общем впечатлении, что все хорошо.

Напомню, до 22 века ещё 75 лет. 75 лет назад компьютеры были размером с машинный зал и работали на радиолампах, а 10 лет назад никто вообще не думал, что компьютер сможет генерировать осмысленную программу по заданию на человеческом языке.

Ты к тому, что допилят до идеального? Ну хз. Может и так. А может и упрутся в какую нибудь нерешаемую задачу.

Да сформируются они

у меньшей части популяции ибо

https://youtu.be/bh5ut_T6A4c

Про отступы это самый железный аргумент наоборот.

Нет. Проблемы это вызывает только при копипасте, но если ты не включаешь голову, пока копипастишь чужой код - ССЗБ.

Что до обязательности табов, то если бы я проектировал язык - я бы несоответствие кодинг-стайлу вообще сделал синтаксической ошибкой. Потому что отдельно взятый программист разумен, а в толпе обязательно найдутся яжхудожники, которые так видят.

Что до обязательности табов, то если бы я проектировал язык - я бы несоответствие кодинг-стайлу вообще сделал синтаксической ошибкой. Потому что отдельно взятый программист разумен, а в толпе обязательно найдутся яжхудожники, которые так видят.

Надеюсь, мне никогда больше не придётся с такими поехавшими ОКРщиками работать. А то уже приходилось специально обходить тулзу, проверявшую длину строки в CI, чтобы вставить ссылку на confluence в комменты (ссылка была длиннее 100 символов).

Такое ОКР очень дисциплинирует и помогает в дальнейшей поддержке кода.

Помню по началу игнорил частенько отступы - потом этот код проще выкинуть. Как и при использовании нечитаемых переменных и прочей хрени.

Правила и нормы разрабатываются не просто так - они полезны даже для единоличных проектов, а уж для совместной разработки соблюдение всех правил смертельно необходимо.

Проблемы это вызывает только при копипасте, но если ты не включаешь голову, пока копипастишь чужой код - ССЗБ.

Это проблема даже при копипасте своего кода и не только при копипасте. Зачем защищать это явно неудачное решение?

Это элементарно автоматизируется.

Ну это само собой, я в обязательном порядке прохожу fmt файл всегда. В саблимтексте это вообще автоматом при сохранении.

Но и вручную луше делать сразу правильно. Это же на уровне спинного мозга нарабатывается.

Нет не лучше. Не надо защищать явно неудачные решения.

Не соблюдать принятые в языке нормы - самое неудачное решение.

Это как насрать зимой в штаны. Поначалу даже тепло…

Опоздал. Только сегодня увидел. Предлагаю встать и спеть:

https://www.youtube.com/watch?v=yup8gIXxWDU

Такое ОКР очень дисциплинирует и помогает в дальнейшей поддержке кода.

Дело не в отступах. Дело в том, что для каждого из этих правил разметки встречаются примеры, когда они делают хуже. А нечитаемое говно можно написать с соблюдением любых правил.

Правила и нормы разрабатываются не просто так - они полезны даже для единоличных проектов, а уж для совместной разработки соблюдение всех правил смертельно необходимо.

Смертельно? Нет. Тут два варианта: либо ты работаешь с нормальными людьми, которые пишут читаемый код и следуют соглашениям по форматированию в 95% случаев где это имеет смысл, а в оставшихся 5% способны подумать своей головой и сделать читаемо. Либо ты работаешь с неуправляемыми мудаками, и тогда тебе уже ничего не поможет.

Если автомобиль будет взрываться, если не её помыл, то это плохое решение.

А ты всегда выбираешь с кем работать заранее? Всех их знаешь всю жизнь? Разработка крупных проектов - это всегда новые люди со своими привычками. И эти привычки лучше заранее загнать в рамки.

Для этого и нужны правила, законы, нормы.

Не соблюдать ПДД - вот плохое решение. Я понимаю, можно вставить заглушку вместо ремня безопасности, а в случае чего можно просто подлечиться. Но именно это и есть - плохое решение.

Или ты будешь рассказывать, что адекватные водятлы и так умеют ездить правильно и пдд для лузеров?

Ты бот? Только честно.

А ты? Что за идиотские примеры со взрывающимися машинами?

Есть два подхода: водятел должен сам соблюдать пдд и автоматика, следящая за этим. Например: не вставил ремень безопасности - машина не заведется.

Но даже использование автоматики не значит, что не нужно самому соблюдать правила.

Я согласен с тем, что с точки зрения работы это неудачное решение, но его значение слишком сильно переоценено. Я бы на месте Гвидо сделал обычные фигурные скобки.

Если не соблюдать кодинг-стайл, то проект быстро превращается в помойку.

Длину комментариев, кстати, не стоит ограничивать, с этим ваш ОКРщик явно переборщил.

Обычно ограничивается не длина комментатриев, а длина строки - чтобы все строки влезали в ширину терминала 79 символов обычно. Но переносить строки то никто не мешает.

И вот как раз это единственное правило, которое я не соблюдаю во всех языках.

Ты очень похож на бота, который потерял контекст и начал галлюцинировать. Причем здесь ПДД?

Про взрывающиеся машины начал ты, а не я. Я просто исправил твою кривейшую и тупейшую аналогию, сделав ее более подходящей к беседе.

Если не соблюдать кодинг-стайл, то проект быстро превращается в помойку.

Ты пропустил мой тезис про 95% случаев. Можешь увеличить до 99%.

Длину комментариев, кстати, не стоит ограничивать, с этим ваш ОКРщик явно переборщил.

Там всё было как ты хочешь: автоматическая проверка длины строк, отступов, наличия двух пустых строк между фукциями и прочего такого говна в CI. Код в результате был помойкой, потому что в итоге все стали херачить как угодно лишь бы проверка проходила. На собственно читаемость было насрать.

Ты пропустил мой тезис про 95% случаев. Можешь увеличить про 99%.

В реальности, увы, так не бывает.

потому что в итоге все стали херачить как угодно лишь бы проверка проходила

Линтерами эти проблемы, как правило, не решаются. Нужен язык с ограниченными средствами самовыражения. Хороший (и одновременно плохой) пример - голанг, где публичность функций в модуле приколочена гвоздями к их кейсу первого символа. Идея хорошая, но реализация - говно, лучше делать прочерки, как в питоне, для функций использовать названия в нижнем регистре, а для типов - только кемлкейс с большой.

Ты пропустил мой тезис про 95% случаев. Можешь увеличить про 99%.

В реальности, увы, так не бывает.

В реальности вот именно так и бывает.

Нужен язык с ограниченными средствами самовыражения. Хороший (и одновременно плохой) пример - голанг, где публичность функций в модуле приколочена гвоздями к их кейсу первого символа. Идея хорошая, но реализация - говно

Ты сам приводишь пример, почему твоя идея будет работать дерьмово. И так получается со всеми подобными затеями.

лучше делать прочерки, как в питоне, для функций использовать названия в нижнем регистре, а для типов - только кемлкейс с большой.

Но в питоне никто не мешает дёргать __функции__. Это просто соглашение.

В реальности вот именно так и бывает.

Неа. Потому что у людей собственные представления о прекрасном, а кодинг-стайл в современных языках недостаточно жесткий, поэтому даже в рамках существующего кодинг-стайла можно городить огород.

Ты сам приводишь пример, почему твоя идея будет работать дерьмово.

Я показываю пример, и говорю, как сделать лучше.

Но в питоне никто не мешает дёргать функции. Это просто соглашение.

Еще раз: речь о примере, в нашем выдуманном языке никто не мешает запретить дергать _функции.

Нет. Это не аналогия.

кодинг-стайл в современных языках недостаточно жесткий, поэтому даже в рамках существующего кодинг-стайла можно городить огород.

В языке вообще не должно быть кодинг-стайла. Это внешняя, по отношению к нему функция.

Неа. Потому что у людей собственные представления о прекрасном, а кодинг-стайл в современных языках недостаточно жесткий, поэтому даже в рамках существующего кодинг-стайла можно городить огород.

Повторю: если ты работаешь с нормальными людьми, они вполне могут писать читаемый код в рамках договорённостей о стиле, делая отступления там, где это и правда необходимо.

Если ты работаешь с поехавшими мудаками, тебе тупо ничего не поможет.

Так что это может быть оправданным только если ты работаешь с индусами, задача которых копипастить код отсюда и до обеда. Но это сложно назвать программированием, а язык для таких случаев уже есть – Java.

Ты не выбираешь людей, с которыми работаешь косвенно, только с теми, с кем напрямую. Ты можешь организовать свою компанию, или можешь выбрать команду грамотных людей, но ты в любом случае столкнешься с кодом, написанным людьми внешними. И вот тут описанные проблемы становятся в полный рост.

В твоем проекте всё прекрасно, но в библиотеках может твориться полный страх и ужас. И чем больше автор яжхудожник - тем больше времени уйдет на разбирание в этом безобразии. Времени на реализацию своей собственной библиотеки, при этом, уйдет кратно больше.

Такие вот дела.

Ты не выбираешь людей, с которыми работаешь косвенно, только с теми, с кем напрямую. Ты можешь организовать свою компанию, или можешь выбрать команду грамотных людей, но ты в любом случае столкнешься с кодом, написанным людьми внешними. И вот тут описанные проблемы становятся в полный рост.

Во внешнем коде на любом языке проблема форматирования стоит в последнюю очередь. В первую очередь там обычно стоит проблема документации, во вторую – предметная область.

В твоем проекте всё прекрасно, но в библиотеках может твориться полный страх и ужас. И чем больше автор яжхудожник - тем больше времени уйдет на разбирание в этом безобразии. Времени на реализацию своей собственной библиотеки, при этом, уйдет кратно больше.

Прогони автоформатирование, страдалец. Хватит распространять свой ОКР на окружающих.

Во внешнем коде на любом языке проблема форматирования стоит в последнюю очередь.

Нет. Плохо написанный код усложняет понимание.

Прогони автоформатирование, страдалец.

Как мы с тобой уже выяснили на твоем примере, это не особо работает ;)

Во внешнем коде на любом языке проблема форматирования стоит в последнюю очередь.

Нет. Плохо написанный код усложняет понимание.

Так плохо написанный или плохо отформатированный? Это разные вещи. Хорошо писать код ты ни одной автоматической штукой никогда никого не заставишь.

Прогони автоформатирование, страдалец.

Как мы с тобой уже выяснили на твоем примере, это не особо работает ;)

Как и твоя идея с вынесением форматирования в синтаксис работать не будет. Вообще, проблему криворуких мудаков ни один инструментарий не исправит.

Плохо написанный - это очень широкое понятие, начиная от форматирования, и заканчивая структурированием. Включи голову, будь любезен. Я предлагаю очень внимательно проработать кодинг-стайл вплоть до смешения его с синтаксисом, чтобы органически было невозможно (или крайне сложно) написать нечитаемый код.

А будет это работать или нет - мы не знаем, у нас нет примеров таких языков.