LINUX.ORG.RU

JavaScript 30 лет

 ,

JavaScript 30 лет

0

5

Ровно 30 лет назад, 4 декабря 1995 года компании Netscape и Sun совместно анонсировали новый язык программирования – JavaScript, впервые доступный в браузере Netscape 2.0, вышедшем на следующий день после анонса. С тех пор JavaScript сумел распространиться повсюду, его реализация содержится в каждом популярном браузере, на нём пишут серверный и десктопный софт, и спустя 30 лет он считается самым популярным языком программирования на планете.

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

>>> Анонс в интернет-архиве

★★★★★

Проверено: anonymous_incognito ()
Последнее исправление: hobbit (всего исправлений: 2)
Ответ на: комментарий от vap77

знания конкретных вывертов конкретных фреймворков

Это не знание, а сноровка

buddhist ★★★★★
()
Ответ на: комментарий от sabacs

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

Ведь разумные существа всегда сами знают как им себя вести, верно? А по земле должны ходить свободные люди и кони!

Вот только ты живешь не в идеальном сферическом обществе в вакууме. Неспособность смириться с несовершенством мира - это и есть как раз первый шаг к ОКР.

У тебя не получится все сделать идеально, Мир вокруг не идеален. Многое приходится присобачить сбоку на сопли. А к языку присобачить некоторые левые соглашения.

Так работает несовершенная реальность. Мы подпиливаем ее то тут то там, подгоняя под наши хотелки.

LightDiver ★★★★★
()
Ответ на: комментарий от liksys

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

Да-да. Это не будет работать, о чём я и пишу.

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

У нас есть примеры подобного с внешним тулингом, и там как раз работает правило 95%/5%. В 5% его отключают комментом. Но почти все примеры такого защищают разве что от случайных косяков, от твоего «ЯЖХУДОЖНИК» это не помогает вообще никак. Собственно, я одного такого ОКРщика доводил, форматируя код абсолютно мудацким способом, который тем не менее проходил все проверки.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Да-да. Это не будет работать, о чём я и пишу.

И это неправильный ответ.

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

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

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от liksys

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

Звучит очень похоже на… лисп лол.

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

К слову, немного не в тему, но в 80х были эксперименты с хранением сырцов (в основном на Ada) не в виде текста, а в виде бинарного AST, с настраиваемым форматированием при выводе. Ссылки под рукой нет, но можешь сам нагуглить. Тебе такое должно зайти.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Я не представляю себе примеров подобного.

Потому что это надо сидеть и проектировать, долго-долго и вдумчиво.

Ссылки под рукой нет, но можешь сам нагуглить. Тебе такое должно зайти.

Я знаю про это, и это чушь какая-то. Это не решает проблему вообще никак, потому что я говорю не только о форматировании.

liksys ★★★★
()
Ответ на: комментарий от liksys

Это не решает проблему вообще никак, потому что я говорю не только о форматировании.

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

Потому что это надо сидеть и проектировать, долго-долго и вдумчиво.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от liksys

Мы с тобой обсуждаем идею, а ты зачем-то требуешь с ходу реализацию.

Реализацию не требую. Хочу увидеть пример такого синтаксиса всего лишь.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Реализацию не требую. Хочу увидеть пример такого синтаксиса всего лишь.

/0

liksys ★★★★
()
Ответ на: комментарий от hateyoufeel

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

А потом я вспоминаю: начинается же эра ИИ. Еще чуток и все эти проблемы в целом могут стать неактуальны. Пищущие код вручную вымрут за своей неэффективностью. Там где они будут писать 10 строк, юзер с ИИ автоматом создаст 10000 строк. Ну или нет…

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

LightDiver ★★★★★
()
Последнее исправление: LightDiver (всего исправлений: 1)
Ответ на: комментарий от LightDiver

А потом я вспоминаю: начинается же эра ИИ.

Нет никакой эры ИИ. Есть эра чат-ботов, которые могут генерировать шаблоны. Всё, что за пределами шаблонов - тушите свет.

Там где они будут писать 10 строк, юзер с ИИ автоматом создаст 10000 строк…

Нейрослопа. Я у грока спрашивал про питоновые биндинги к ublk и пример, и он мне радостно написал стену кода на pyublk, сделал к нему подробное ридми и инструкцию по запуску.

Вот только есть нюанс: pyblk не существует.

И так во всём. Шаг вправо-влево от типичных решений с SO - и оно поплыло.

Потому что это ЧАТ, МАТЬ ЕГО, БОТ. К нему можно прикрутить калькулятор, можно прикрутить анализатор синтаксиса языков и прочие вещи. Но он не думает. Он не может написать нормальный работающий код. Только типовой бойлерплейт.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 2)
Ответ на: комментарий от LightDiver

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

Четвёртый назвал козу именем бывшей жены, водит соседского козла её трахать, а потом рисует это в подробностях в MS Paint абсолютно вырвиглазными цветами.

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

Просто у тебя нет воображения и чувства прекрасного. Может этот четвертый давно уже эту козу с именем бывшей жены собственноручно зарезал и съел.

LightDiver ★★★★★
()
Ответ на: комментарий от liksys

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

Проблемы это вызывает в рандомном месте. Никогда не знаешь, в какой момент поедут табы и от чего. Пробле лишний не зацепил при копировании и жопа отвалилась. Наложим это на возможные стрессовые ситации и попытки починить что-то в проде супер срочно, когда написан корректный код, но на сервере по SSH оказался странно настроенный vim, который частично оставил почему-то табы, а частично пробелы - да хрен его знает ещё почему. В общем, навязывание кодстайла таким способом - это как «если вы голодны, просто жрите больше пирожных» (с) - в общем какие-то аристократические игры, не понятные простому рабочему. Смысл в том, что я хочу забить микроскопом гвозди прямо сейчас, решив проблему работоспособности системы в моменте, в отдельной ветке. А потом уже давайте мёржить в мастер и прогонять через автоматические чекеры кодстайла и т.п.

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

lesopilorama
()
Последнее исправление: lesopilorama (всего исправлений: 4)
Ответ на: комментарий от sabacs

Signal and noise in programming language

https://dl.acm.org/doi/10.1145/800181.810322

по странному от соавтора Стиля Кернигана ну и автора трёхтомника Программистких эссе

ой чё было то полвека то - не то что развитАя современность - сплошь бред в прошлом

SIGNAL AND NOISE IN PROGRAMMING LANGUAGE
P.J. PLAUGER
Yourdon, Inc.
It has been my observation that the syntax of a
programming language affects how it is used all out
of proportion to its importance in the overall
scheme of things. Specifically, programmers tend
to avoid long-winded constructs even after they
have been assured that such forms make for nicer
code. And they seem to delight in the terse, no
matter what the cost in intelligibility or running
time. Witness APL.
That language at least has the virtue of being consistent; and one can argue at the other extreme
that COBOL is uniformly wordy. Most languages are
rather inconsistent, and few achieve that delicate
balance between the concise and the cryptic that
makes for a truly useful notation. It is important,
then, to evaluate what parts of a language syntax
provide useful signal to the reader, and what are
simply noise.
The first principle is well known in both linguistics and coding theory: things which get said
lo~t should be concise. Thus begin...end is a poor
way to group, and do...end is worse, because it is
easily misread as a potential loop. Groups occur
frequently in well-written code--they should not be
represented as degenerate loops. Many studies have
shown in fact that loops frequently consist of but
on___~e statement. A group is not a loop is not a
group. So why not just allow bracketing {...} to
represent all groups?
Perhaps we should go even further. Well-written
programs are always indented to show who controls
what. A very hard bug to find, in fact, is one
where the indenting shows the intent but not the
actuality:
if (a)
if (b)
else ...
The else binds with the innermost if, even though
that is not wanted here. Why not have the compiler
read the same signal as we human beings, and let
the indenting control grouping? It warrants consideration.
Which raises a second issue: similar thln~s should
be said in similar ways. It's nice to have the
redundancy of an if...then...else...fi, or a d__oo...
od, or even a ease...esac, but do you gain anything
from all those different words (and pseudo-words)?
I think not--they are mainly noise. Grammars which
do not need such complexity are well understood,
and so is the code accepted by them. All we have
to remember are rules such as
statement := simple statement
lif (test) statement
lwhlie (test) statement
liprogram}
and we have a readable language at our fingertips.
The corollary is: different things should be said
differently. Evaluating a function with arguments
is not the same as indexing into an array; if the
former is ~(x_) the latter should be something different, such as K[x]. Similarly assignment and
equality testing should not both be represented by
the same sign '='. Either the former should be "-'.-
or the latter '--'--. It is not enough that a compiler can tell from context which is which--the
human reader should never be in doubt. 
And finally: syntax errors should fail soft. A
missing comment delimiter should not eat up code
through the end of the next comment. Or worse, a
missing delimiter should not turn comments into
code and vice versa for the rest of the source, as
when both start- and end-of-comment delimiters are
the same. We need a clear (but concise) signal
that a comment is beginning, and a powerful ~ondition such as end-of-line to signal the end. Similar considerations apply to string constants, and
even identifiers. Keywords and names should never
be permitted to continue on another line.
This may seem a hodgepodge of observations, but
the theme is constant. The purpose of computer
programming language is first to be readable by
people, second to be easily written by people, and
only third to be readable by a compiler. We have
learned many things about how people communicate
best. We should apply what we have learned to this
important mode of communication. 

qulinxao3 ★☆
()
Последнее исправление: qulinxao3 (всего исправлений: 2)
Ответ на: комментарий от hateyoufeel

это были структурные редакторы (под многие языки творилось в каждом случае)-ибо(одна из причин) сжатие в токенцы(тот же бейсик в спектрупеZX)

в частности syntax-directed editor

в некотором смысле тот жи colorForth - где(в одном из вариантов) не было отдельного сырца а был код который средой показывался в виде имён соответсвующих слов

qulinxao3 ★☆
()
Ответ на: комментарий от liksys

вот смотри colorForth = появись(получи туже степень известности как все поделия того времени начиная с A0 и прочих экс(пе|к)рeментов оно во времена ipl-57 на тех вычислительных неможиях история была бы более чистой

ваще реально история индустрии вычислений это очень неленейная кривая - одно уж разделение (до сих пор следы заметны) на научные и концелярские «вычисления» - и да (72)36битность первых машин далеко не случайно а на века обдуманное решение - как и байтовость копромис по правильному бит-нибл-16бит-сегмент(65кбит)

как и идея общей памяти Multics (с опцией горячего подключения памяти прозрачным для конечного пользователя и не отличения для пользователя места хранения долговременных данных и грязной копии в раме и вообще идея персистентности без разделения )

однако очередной «кембрийский» взрыв микропроцев позволил повторно пробежатся по трассе(с граблями и лулзами) большим массам

qulinxao3 ★☆
()
Ответ на: комментарий от vap77

А про форт - ага, представляю я, как бы я пытался на нем сетевые сервисы писать

Что, слабо́? ;)

А вот Андрей Черезов (разработчик SP-FORTH) писал... ;))

Видимо, это (как и всё прочее) уметь надо... а не только в форумах языком... ;P ;))

Somebody ★★★★
()
Ответ на: комментарий от buddhist

и знания мгновенно устаревают

Зато незнание не устаревает. :))

Хоть в чём-то стабильность есть... ;P ;))

Somebody ★★★★
()
Ответ на: комментарий от KOHb-TPOJIJIbJIEP

Вот тогда да, тогда заживём

Зажуёте, ага... ;D ;))

Somebody ★★★★
()
Ответ на: комментарий от liksys

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

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

bread
()
Ответ на: комментарий от LightDiver

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

Законы определены синтаксисом языка, всё что вы там придумали сверху это заморочки типа хороших манер при дворе Людовика Хренадцатого. Как положено кланяться, как жопу оттопыривать и делать прочие ку. Это можно ещё терпеть как соглашения, но как всеобщие правила нет, идите нафиг.

bread
()
Ответ на: комментарий от LightDiver

Но я искренне надеюсь, что раст вытеснит сишку.

Напрасно. Как финансирование раста иссякнет, так раст и сдохнет бесследно. Форумы, социалочки и масс-медию перестанут засирать маркетоидным бредом проплаченные ублюдки из Rust Evangelism Strike Force, а crates.io начнёт показывать «This domain is for sale» и всё, про раст все забудут к едрене фене буквально на следующий день.

Stanson ★★★★★
()

лучше сразу начать с TS, чем портить жизнь себе и другим херача на JS.

splinter ★★★★★
()
Ответ на: комментарий от bread

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

LightDiver ★★★★★
()
Ответ на: комментарий от LightDiver

Право никто и не отменял, как и последствия; токмо инокультурные обнаруживают опытным путём, что вероятность негативных последствий такова , что рецидив не фиксируется

qulinxao3 ★☆
()
Ответ на: комментарий от gmv4ever

Короче на одну букву. Это очень большое преимущество в программировании.

seiken ★★★★★
()
Ответ на: комментарий от bread

заморочки типа хороших манер при дворе Людовика Хренадцатого. Как положено кланяться, как жопу оттопыривать и делать прочие ку. Это можно ещё терпеть как соглашения, но как всеобщие правила нет, идите нафиг.

Вы как будто кино про Д’Артаньяна не смотрели (откуда такой взялись вообще?).

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

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

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

ugoday ★★★★★
()
Ответ на: комментарий от bread

Кста как указал выше содискурсант см: Норберт Элиас двухтомник про генезис этикета в Европе нового времени - так что стиль важен

Есть другая проблема - вынужденность обвинять код что-бы малограмотные в структурах данных и алгоритмах не тригирились :(

qulinxao3 ★☆
()

Кормилица наша. Ми-ми-ми-ми.

lenin386 ★★★★
()
Ответ на: комментарий от qulinxao3

так что стиль важен

Только в узкой группе каких-то «дворян». И то, они должны договориться и согласиться. А не просто по приказу главмакаки.

bread
()
Ответ на: комментарий от gmv4ever

PHP - это джаваскрипт для сервера.
JS - это пыхапе для клиента.

Разные инструменты из разных миров

uin ★★★
()
Ответ на: комментарий от DarkAmateur

PHP - это джаваскрипт для сервера.

Только вот PHP так и остался на сервере, в отличии от…

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

hateyoufeel ★★★★★
() автор топика
Ответ на: комментарий от hateyoufeel

То же самое тебе скажут про джаваскрипт, мол «на чистом JS никто уже не пишет, абсолютно бесполезный язычок»
На деле же речь как правило идет о разной фреймворк-говне и переходных скриптах работающих через ноду.

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

uin ★★★
()
Ответ на: комментарий от uin

но это сложный компилируемый язык выдающий платформо-зависимые бинарии.

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

Алсо, назвать Golang сложным может только полный кретин. Это один из самых простых языков на рынке сейчас, специально спроектированный для написания кода обезьянами.

hateyoufeel ★★★★★
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.