Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 144
Потенциал большой, довести до ума надо просто.
Тоньше некуда.
До появления Ajax я тоже так думал.
Ведь верно! Первым примером хорошего кода на js, который я увидел, был prototype.
+1. То же самое. До этого писанина на JavaScript представлялась не очень приятной рутиной, когда "надо что-то сбацать на коленке, а некоторые монстры, мол, делают даже, что там что-то плавает/двигается. Уау!" :)
Не соглашусь, что prototype это пример хорошего кода, но соглашусь, что это была первая мощная реализация js-библиотеки, которая дала мощный толчок (пинок) вперед в развитие этого языка и Ajax подхода.
Егоне заставили работать за 10 лет одинаково совсем изза других вещей, не надо пожалста путать %опу с пальцем. Это весьма приятный язык - программировать на нем действительно просто и приятно.
Брат, ты не прав, как, собственно, и автор статьи. 1. JavaScript - динамический язык, приобретающий все большую популярность, и который вскоре перейдет с вебовского клиент-сайда в десктоп и сервер-сайд, по крайней мере такая стратегия четко прослеживается в действиях SUN-а и Adobe-а. 2. Автор, учи матчасть!
Википедия говорит нам, что "Синтаксис языка брал начало от языка Си, но, поскольку технология Java была в то время очень модной, LiveScript переименовали в JavaScript, получив соответствующую лицензию у Sun."
Что и говорить... маркетинг :).
Что и говорить... маркетинг :).
"Я её сложно читать и ещё сложнее там что-нибудь понять"
Поправьте пожалуйста ("Двойные стандарты").
Поправьте пожалуйста ("Двойные стандарты").
перевод есть нехорош и сложно читать
возможно, скорее всего это из-за такого стиля изложения у автора оригинала. он скачет от мысли к мысли, стараясь очень не углубляться в подробности
вероятно :) мне сложно было "въехать" в некоторые предложения при прочтении
На самом деле, нет. Не хочу оскорбить ваш труд, но перевод действительно не очень качественный — явно видно, что это перевод с английского, т. к. очень много фраз переведены «буквально», то есть с сохранением типичной для английского языка (но не для русского) структурой. По переводу не должно быть видно, что это перевод.
На самом деле, может быть, даже не в переводе дело. Он в порядке, но по нему нужно жёстко пройтись редактурой.
На самом деле, может быть, даже не в переводе дело. Он в порядке, но по нему нужно жёстко пройтись редактурой.
Идиотские статьи и комменты не на 100% порождены незнанием языка.
Представьте, есть люди, которые умеют делать свойства в JavaScript приватными, но вздрагивают от того количества геморроя, через который приходится проходить, чтобы реализовать простейшую вещь.
Т.е. "понять" JavaScript не так уж и сложно (сайтик отлично помогает, согласен). А вот понять "зачем так жить" гораздо тяжелее. По крайней мере для меня.
Представьте, есть люди, которые умеют делать свойства в JavaScript приватными, но вздрагивают от того количества геморроя, через который приходится проходить, чтобы реализовать простейшую вещь.
Т.е. "понять" JavaScript не так уж и сложно (сайтик отлично помогает, согласен). А вот понять "зачем так жить" гораздо тяжелее. По крайней мере для меня.
Попробуйте перечитать свой перевод. Если ничего не заметите, подучите русский язык, это важнее, чем JavaScript.
Я дал вам пищу для размышлений о javascript, вы дайте мне пищу для размышления о русском языке - опишите ошибки.
Хорошо, их очень много. Вот, например, в первом абзаце:
"один из самый популярных", а нужно "— один из самых популярных" - это обычная неаккуратность.
Перевод названия явно неадекватный: "misunderstood" означает "непонятый", а не "непонятный".
"Несмотря" пишется слитно.
"Неплохо" - то же самое.
"Так же" в сочетании "так же как" - наоборот, раздельно.
"Эти ошибки ..., и поставил весь дизайн языка под вопрос" - опять неаккуратность в слове "поставил".
"написана" - пишется с одной "н".
Короче говоря, ошибок множество. Я уж не говорю про пунктуацию. Хуже всего речевые ошибки, из-за них иногда совсем непонятно, что имел в виду автор. Судя по тому, что мне понизили "карму", я сделал что-то ужасное., но я всего лишь хочу читать грамотно составленные тексты. Простите.
"один из самый популярных", а нужно "— один из самых популярных" - это обычная неаккуратность.
Перевод названия явно неадекватный: "misunderstood" означает "непонятый", а не "непонятный".
"Несмотря" пишется слитно.
"Неплохо" - то же самое.
"Так же" в сочетании "так же как" - наоборот, раздельно.
"Эти ошибки ..., и поставил весь дизайн языка под вопрос" - опять неаккуратность в слове "поставил".
"написана" - пишется с одной "н".
Короче говоря, ошибок множество. Я уж не говорю про пунктуацию. Хуже всего речевые ошибки, из-за них иногда совсем непонятно, что имел в виду автор. Судя по тому, что мне понизили "карму", я сделал что-то ужасное., но я всего лишь хочу читать грамотно составленные тексты. Простите.
> Перевод названия явно неадекватный: "misunderstood" означает "непонятый", а не "непонятный".
Прочитайте внимательно название - там так и есть.
Остальные ошибки исправил, спасибо.
Прочитайте внимательно название - там так и есть.
Остальные ошибки исправил, спасибо.
Хм... надо же меня приглючило...
Думаю, что не приглючило. В титуле до сих пор «непонятный».
в титуле непонятый без буквы н между т и ы.
причем здесь т?
причем здесь т?
Может быть имеет смысл заменить это слово на "недооцененный", во избежание ложных трактовок?
Ой, опять поменялось. Как может двоих одновременно глючить... :}
не опять, а первый раз, в связи с комментарием выше.
supersasha
supersashaВы абсолютно правы. Думаю, читателям просто не понравилась агрессивность вашего комментария. ;)
Спасибо за статью. Практически согласен.
И исправьте "очепятки" если не тяжело:)
"...ибкой, также как и прямая запись в коде регулярны выражений..."
"...Они содержат ошибки, плохие примеры и дают плохие практик..."
И исправьте "очепятки" если не тяжело:)
"...ибкой, также как и прямая запись в коде регулярны выражений..."
"...Они содержат ошибки, плохие примеры и дают плохие практик..."
AFAIK JScript это не JavaScript
JScript — это имплементация JS в браузере Internet Explorer. Чтобы не лицензироваться, они просто дали ему другое название :))
JScript пошел несколько дальше IE, ушел в Windows-скрипты и даже в .NET.
Абсолютно верно — но в контексте данной тематики это не имеет значения :) Я сам в свое время, ковыряясь в каких-то файлах win98, напарывался на декларативное обозначение и анимацию интерфейса на html и jscript. Было время! А сейчас — да, все именно так :)
ну ввели они предопределённые объекты, доступные только в своей среде, но язык-то остался прежним
Не в браузере, это теперь стандартный скриптовый язык для Windows, наряду с VB. То есть на нем можно писать выполнимые ОСью сценарии.
Давали бы тогда нормальную лицензию - может и лицензировался бы. :)
А вы часто конкурентам лицензию продаете? :))
JavaScript был заявлен в качестве открытого стандарта, в оригинале в декабре 1995-ого это звучало так:
"Netscape and Sun plan to propose JavaScript to the W3 Consortium (W3C) and the Internet Engineering Task Force (IETF) as an open Internet scripting language standard. JavaScript will be an open, freely licensed proposed standard available to the entire Internet community. Existing Sun Java licensees will receive a license to JavaScript. In addition, Sun and Netscape intend to make a source code reference implementation of
JavaScript available for royalty-free licensing, further encouraging its
adoption as a standard in a wide variety of products."
В итоге к моменту появления JScript ничего открыто не было, ни доков, ни лицензий. Кроме того JavaScript по ходу дела был тихо переписан (из Mocha в 95-ом в SpiderMonkey в 96-ом), обратная совместимость была ужасна, а возможная в будущем лизензия ограничивала внесение изменений. В этих весёлых условиях только идиот стал бы ждать у моря погоды. MS поступила совершенно верно, создав через несколько месяцев собственную реализацию под собственным же именем... ;)
"Netscape and Sun plan to propose JavaScript to the W3 Consortium (W3C) and the Internet Engineering Task Force (IETF) as an open Internet scripting language standard. JavaScript will be an open, freely licensed proposed standard available to the entire Internet community. Existing Sun Java licensees will receive a license to JavaScript. In addition, Sun and Netscape intend to make a source code reference implementation of
JavaScript available for royalty-free licensing, further encouraging its
adoption as a standard in a wide variety of products."
В итоге к моменту появления JScript ничего открыто не было, ни доков, ни лицензий. Кроме того JavaScript по ходу дела был тихо переписан (из Mocha в 95-ом в SpiderMonkey в 96-ом), обратная совместимость была ужасна, а возможная в будущем лизензия ограничивала внесение изменений. В этих весёлых условиях только идиот стал бы ждать у моря погоды. MS поступила совершенно верно, создав через несколько месяцев собственную реализацию под собственным же именем... ;)
Насчет книг: я ьы еще почитал вот эти:
"Pro JavaScript Design Patterns"
"Pro JavaScript Techniques"
"Pro JavaScript Design Patterns"
"Pro JavaScript Techniques"
После сегодняшней статьи про JS2 сам хотел написать нечто подобное, только немного в другом стиле. JS не непонятный, в JS просто никто не хочет разбираться - "как это нет классов? что это за язык такой в эпоху ООП? фигня какая-то!". JS как язык вполне может соревноваться с Ruby и Python'ом "в общем" (в частных случаях последние всё же имеют преимущество) - это полноценный динамически типизированный язык.
PS. Насчет книжек - еще есть замечательная Pro JavaScript Techniques.
PS. Насчет книжек - еще есть замечательная Pro JavaScript Techniques.
Раз уж тут два раза в положительном ключе упомянули эту книжку, то в противовес копипаст себя же с винграда: "Pro JаvаSсript Techniques. Общее впечатление такое - набор статей весьма среднего уровня, подобранных по приниципу обо всём по чуть-чуть (но в русле моды). Куча ошибок, самодельная терминология. С практической точки зрения польза от книжки есть - достаточно много скриптов (особенно в DOM-разделе), но всё обыкновенное, нагугливаемое на раз. Резюме - читать по диагонали."
>перевод: sylvio
Это новый электронный переводчик?
Это новый электронный переводчик?
Jscript != JavaScript
Jscript - больная фантазия разработчиков от MS, которые, впрочем, как обычно, посчитали, что всё должно быть только их и придумали практически идентичный JavaScript язык, только для продуктов от MS
Jscript - больная фантазия разработчиков от MS, которые, впрочем, как обычно, посчитали, что всё должно быть только их и придумали практически идентичный JavaScript язык, только для продуктов от MS
После долгих размышлений я так и не смог придумать задачи где бы prototype-подход оказался бы более удобным, чем классическое ООП. Таким образом... зачем ломать голову или эмулировать на нем классические классы с классичим наследованием?
Оба подхода имеют как свои преимущества, так и недостатки. В браузерах, судя по всему, прототипное ООП было более подходящим.
Расскажите мне про реальные преимущества? Я их не вижу.
А недостатки прототипного подхода можно? :) Только не в стиле "он необычный, не использующийся и вообще мне он не нравиться". Реальные факты.
Я же могу сказать одно - так как нединамических языком программирования с прототипами я не видел, то буду рассматривать тольео динамические. А в данном случае вопрос можно поставить как "что лучше - стол или стул". Подходы взаимозаменяемы, в JS вполне можно реализовать систему классов, посмотрите на фреймворки на JS. Чем подход JS удобнее - у тебя "наследование" не статическое, а динамическое, т.е. ты можешь динамически менять базовые классы у наследника.
Я же могу сказать одно - так как нединамических языком программирования с прототипами я не видел, то буду рассматривать тольео динамические. А в данном случае вопрос можно поставить как "что лучше - стол или стул". Подходы взаимозаменяемы, в JS вполне можно реализовать систему классов, посмотрите на фреймворки на JS. Чем подход JS удобнее - у тебя "наследование" не статическое, а динамическое, т.е. ты можешь динамически менять базовые классы у наследника.
Это не аргумент. Если у prototype нет примуществ, то для нормальной удобной работы приходится испольщовать библотеки или пользоваться не стандартным, что всегда менее удобно, подходом.
Так почему не сдалеть сразу удобно? :)
Так почему не сдалеть сразу удобно? :)
Гм. Какие библиотеки? Для прототипного JS есть куча всяких разных библиотек. Работа с DOM реализована, использование компонентов типа ActiveX есть. Где вы тут проблему видите?
Я говорю про библиотеки позволяющие пользоваться (framework-ами Вы их назвали, не суть) стандартным и привычным ООП, а не prototype.
Если у prototype нет плюсов, то почему бы не сделать сразу нормально? :)
Если у prototype нет плюсов, то почему бы не сделать сразу нормально? :)
А почему Вы решили, что прототипное программирование - это ненормально?
А как вы к функциональному программированию относитесь? Тоже, отстой, потому что нет зацикливания на классах?
А как вы к функциональному программированию относитесь? Тоже, отстой, потому что нет зацикливания на классах?
То ли я плохо объясняю, то ли Вы не хотите меня понять. Я могу Вам назвать реальные технические преимущества функционального программирования.
Я решил, что прототипное программирование — это не нормально потому, что распространенный подход сейчас другой, а какие-либо плюсы этого подхода я не вижу, более того, Вы мне их так и не смогли назвать. Когда прототипное программирование удобнее и лучше, чем классическое ООП.
Я решил, что прототипное программирование — это не нормально потому, что распространенный подход сейчас другой, а какие-либо плюсы этого подхода я не вижу, более того, Вы мне их так и не смогли назвать. Когда прототипное программирование удобнее и лучше, чем классическое ООП.
Чем подход JS удобнее - у тебя "наследование" не статическое, а динамическое, т.е. ты можешь динамически менять базовые классы у наследника.
Я это назвал.
Я это назвал.
Я могу это сделать и при обычных классах в динамическом языке, например в Python.
Это вне конктекста обсуждения красоты такого решения.
Это вне конктекста обсуждения красоты такого решения.
Ага, ну раз вне контекста - тогда я уже сказал - подходы взаимозаменяемы, на JS можно использовать ООП с классами. Почему нужно было в javascript включать прототипы (или включить в браузеры другой язык) мне лично неведомо. :)
По красоте, как архитектурного решения, в большинстве случаев можно использовать не такое вот динамическое наследование, а делигаты. :)
Почему нужно было включать в javascript прототипы мне тоже неведомо.
Более того, мне так и остались неведомы его преимущества , я так и не смог придумать под него какой-то класс задач, чтобы было убобнее с ним работать, чем с классическими классами, которые получили значительно большее распространение.
Таким образом к теме недооцененности — javascript ООП (прототипирование) неудобен, плюс в некоторых местах реализация крива.
Почему нужно было включать в javascript прототипы мне тоже неведомо.
Более того, мне так и остались неведомы его преимущества , я так и не смог придумать под него какой-то класс задач, чтобы было убобнее с ним работать, чем с классическими классами, которые получили значительно большее распространение.
Таким образом к теме недооцененности — javascript ООП (прототипирование) неудобен, плюс в некоторых местах реализация крива.
Неудобен для тебя. Неудобен еще для кого-то. Мне лично всё равно - мне что на классах, что на прототипах писать одинаково удобно.
Неудобен для большинста с тех пор, как JavaScript перестал быть маленьким скриптовым языком для маленьких поделок, где не нужно реальное ООП, ибо удобнее писать в той парадигме, в которой работаешь большее время или которая оптимально подходит под решаемую задачу.
Коммент Zeroglif расставил все точки над i
Коммент Zeroglif расставил все точки над i
>Почему нужно было включать в javascript прототипы мне тоже неведомо.
Ради простоты. В те времена Java позионировалась для больших околобраузерных задач, JavaScript - для маленьких и ничего больше.
"...in minimizing JS-the-language, I added explicit prototype-based delegation, allowing users to supplement built-in methods with their own in the same given single-prototype namespace." (Brendan Eich)
Ради простоты. В те времена Java позионировалась для больших околобраузерных задач, JavaScript - для маленьких и ничего больше.
"...in minimizing JS-the-language, I added explicit prototype-based delegation, allowing users to supplement built-in methods with their own in the same given single-prototype namespace." (Brendan Eich)
http://waltersmith.us/wp-content/uploads… - довольно интересный документ :)
Посмотрите на сырцы mootools. Вы сможете реализовать нечто подобное, скажем, на C++?
А как насчет динамических языков? Например, Python.
Я не моуг представить себе класс задач, где было бы выгоднее именно прототипирование, если Вы можете привести пример или как-то этот класс описать, то это будет очень интересно.
Я не моуг представить себе класс задач, где было бы выгоднее именно прототипирование, если Вы можете привести пример или как-то этот класс описать, то это будет очень интересно.
на Python, Ruby, Smalltalk - всё это можно реализовать... не в этом вопрос.
Вот не понимаю я таких людей.... А скажите пожалуйста все, что распространненное - всегда более удобно и лучше?
Насколько я знаю, приставка Java-... в названии этого языка появилась исключительно из желания получить дивиденды с уже неплохо раскрученного к тому моменту бренда от Sun.
пока статью не читал, занёс в favourites, позже прочитаю.
Но разве Javascript = JScript? JScript это же микрософтская версия, если я не ошибаюсь.
И насколько я знаю ECMAscript JavaScript, а яваскрипт относится к семейству ECMA
Но разве Javascript = JScript? JScript это же микрософтская версия, если я не ошибаюсь.
Компания Microsoft, увидев успех JavaScript, создала свою версию этого языка под названием JScript.(c)Wikipedia
И насколько я знаю ECMAscript JavaScript, а яваскрипт относится к семейству ECMA
По возможностям ECMAScript примерно соответствует JavaScript 1.1 (c)WikiPedia
Да, именно. JavaScript это реализация и расширения стандарта ECMA-262, который описывает язык ECMAScript. ECMAScript в чистом виде вряд ли где-то встретить можно
http://ru.wikipedia.org/wiki/ECMAScript
http://ru.wikipedia.org/wiki/ECMAScript
Потенциал хороший, но как раз из-за недостатка инфы и глючности пользуюсь самым минимальным набором средств (математика, массивы, циклы).
Осталось написать быструю реализацию JavaScript. Нынешние не выдерживают никакой критики. Примитивнейшие интерфейсы, доступные нам в браузерах, на i386/DOS были на порядок функциональнее и уж не знаю на сколько порядков быстрее. Мне, честно говоря, страшно смотреть на индикатор загрузки моего CPU Core2Duo, когда я захожу на какой-нибудь сайт. Flash-а у меня нет уже полтора года, JavaScript выключить сложнее :(
Реализации есть, вот только никто не спешит их использовать.
Упс. ссылка тут :-)
В своем раннем детстве, чуть больше 10 лет назад, когда я впервые всерьёз задумался о будущей профессии — я долго выбирал себе первую книжку по программингу :)
выбирал как раз между Java и JavaScript почему-то :)))
выбирал как раз между Java и JavaScript почему-то :)))
ошибка: "по тому что"
Самые недооцененные языки это Oberon и Forth.
Перевод невозможно читать, учите язык. Вопрос не в грамматических ошибках а в том что почти все фразы построены коряво и не сразу понятно что имелось ввиду
и самый недооцененный из ECMA - actionscript. Синтаксис понятен, классы - описаны, есть правда особенности с которыми приходится сталкиваться разработчикам. Отчего бы не писать вдоволь? но большого количества качественных приложений нет.
А по поводу Javascript - посмотрите на AJAX фреймворки (в первую очередь на их количество и качество монстров). Нет никаких сомнений что если руки растут из головы, то Javascript отлично подходит даже для сложных задач типа клиентских интерфейсов.
А по поводу Javascript - посмотрите на AJAX фреймворки (в первую очередь на их количество и качество монстров). Нет никаких сомнений что если руки растут из головы, то Javascript отлично подходит даже для сложных задач типа клиентских интерфейсов.
Я не буду повторяться, и указывать на ошибки, допущенные при переводе статьи. По-моему, подобных замечаний уже достаточно. Я бы хотел пожелать автору перевода вот что.
Прежде чем браться за следующий перевод, было бы полезно ознакомиться с основами переводческой деятельности. Сделать это достаточно просто – сейчас очень много литературы, посвященной теории и практике переводческой работы (начать можно с любой небольшой брошюры). Это действительно важно. Ведь для перевода недостаточно просто хорошо знать языки, уметь сопоставлять речевые обороты, находить эквивалентные конструкции. Это все - лишь малая часть работы. Поэтому, как минимум, нужно иметь представление о методике перевода (а это – целая наука).
Кстати, (это возможно самое главное для переводчика) нельзя забывать об авторском праве. Я уверен, что Дуглас Крокфорд заинтересован в переводах своих статей. Но я так же уверен, что он не доверит эту работу кому попало. И тогда уже может возникнуть проблема.
С уважением, и желаю удачи в дальнейшем!
Прежде чем браться за следующий перевод, было бы полезно ознакомиться с основами переводческой деятельности. Сделать это достаточно просто – сейчас очень много литературы, посвященной теории и практике переводческой работы (начать можно с любой небольшой брошюры). Это действительно важно. Ведь для перевода недостаточно просто хорошо знать языки, уметь сопоставлять речевые обороты, находить эквивалентные конструкции. Это все - лишь малая часть работы. Поэтому, как минимум, нужно иметь представление о методике перевода (а это – целая наука).
Кстати, (это возможно самое главное для переводчика) нельзя забывать об авторском праве. Я уверен, что Дуглас Крокфорд заинтересован в переводах своих статей. Но я так же уверен, что он не доверит эту работу кому попало. И тогда уже может возникнуть проблема.
С уважением, и желаю удачи в дальнейшем!
а на русский эта книжка переведена? я не боюсь английского, но на русском о новом приятнее читать)
Про ошибки дизайна.
Интересно, а чем плох + для конкатенации строк? Надо было как в пхп сделать точку, а потом, когда точка оказалась занятой, использовать минус-больше для свойств объектов? Гы! Не, плюсик - лучше.
Что там не так с точкой с запятой? Её же можно не писать. И что вместо неё, если бы понадобилось таки писать в одну строчку? Непонятно.
Непосредственное написание регэкспов - рулит. Хорошо, что разработчики не пошли по пути того же пхп (и явы, кстати) с их безумным размножением слешей...
Ну, и о функциональности... Замыкания... Они есть почти в любом динамическом языке. А конкретно в джаваскрипте они делаются через дж..опу :). Ну, в смысле, через хак с двойной обёрткой. Похоже на побочный эффект, который потом "узаконили" :).
Интересно, а чем плох + для конкатенации строк? Надо было как в пхп сделать точку, а потом, когда точка оказалась занятой, использовать минус-больше для свойств объектов? Гы! Не, плюсик - лучше.
Что там не так с точкой с запятой? Её же можно не писать. И что вместо неё, если бы понадобилось таки писать в одну строчку? Непонятно.
Непосредственное написание регэкспов - рулит. Хорошо, что разработчики не пошли по пути того же пхп (и явы, кстати) с их безумным размножением слешей...
Ну, и о функциональности... Замыкания... Они есть почти в любом динамическом языке. А конкретно в джаваскрипте они делаются через дж..опу :). Ну, в смысле, через хак с двойной обёрткой. Похоже на побочный эффект, который потом "узаконили" :).
>Что там не так с точкой с запятой?
В оригинальной статье (перевод подкачал) говорится о процедуре ASI (Automatic Semicolon Insertion), которая была введена для простоты, но на деле является сложным да ещё и плохо прописанным алгоритмом, по своему реализованным в каждом браузере. Намного проще писать, отбивая руками точку с запятой, не запуская ASI для корректировки. В этом смысле D.C. прав, решение о внедрении ASI было ошибочным. Brendan Eich при создании языка пытался отказаться от лишней пунктуации вообще, но это пошло вразрез с политикой менеджмента о Java-like стиле, в результате появилось компромиссное решение - точка с запятой в JavaScript ОБЯЗАТЕЛЬНА, но ставится она как программистом, так и интерпретатором...
> в джаваскрипте они делаются через дж..опу :). Ну, в смысле, через хак с двойной обёрткой.
Замыкания по сути и не надо делать, всё уже заложено в языке, они под ногами на каждом шагу.
В оригинальной статье (перевод подкачал) говорится о процедуре ASI (Automatic Semicolon Insertion), которая была введена для простоты, но на деле является сложным да ещё и плохо прописанным алгоритмом, по своему реализованным в каждом браузере. Намного проще писать, отбивая руками точку с запятой, не запуская ASI для корректировки. В этом смысле D.C. прав, решение о внедрении ASI было ошибочным. Brendan Eich при создании языка пытался отказаться от лишней пунктуации вообще, но это пошло вразрез с политикой менеджмента о Java-like стиле, в результате появилось компромиссное решение - точка с запятой в JavaScript ОБЯЗАТЕЛЬНА, но ставится она как программистом, так и интерпретатором...
> в джаваскрипте они делаются через дж..опу :). Ну, в смысле, через хак с двойной обёрткой.
Замыкания по сути и не надо делать, всё уже заложено в языке, они под ногами на каждом шагу.
Может замыкания там и под ногами, но при попытке воспользоваться ими в явном виде, это приходится делать через.. неё самую. :(
Примером поясните. Простеньким.
Ну...
Вот на руби. Очевидно просто:
#!/bin/env ruby
funcs = []
(0..5).each { |i| funcs << Proc.new { i * i } }
funcs.each { |func| puts func.call }
На яваскрипте приходится оборачивать в дополнительную анонимную функцию с неочевидным синтаксисом:
var funcs = []
for (var i=0; i<5; ++i)
funcs[i] = function(x) { return function() { return x*x } } (i)
for (var i=0; i<funcs.length; ++i)
document.write('result: '+funcs[i]())
Вот на руби. Очевидно просто:
#!/bin/env ruby
funcs = []
(0..5).each { |i| funcs << Proc.new { i * i } }
funcs.each { |func| puts func.call }
На яваскрипте приходится оборачивать в дополнительную анонимную функцию с неочевидным синтаксисом:
var funcs = []
for (var i=0; i<5; ++i)
funcs[i] = function(x) { return function() { return x*x } } (i)
for (var i=0; i<funcs.length; ++i)
document.write('result: '+funcs[i]())
Синтаксис дополнительной функции и её вызова вполне очевиден. Если нужно создать много функций в одном контексте и при этом "привязать" к каждой функции определённое своё значение, то чего же грешить на замыкания, если в javascript вложенная функция по определению "помнит" не значения, а scope chain. Нужно отдельное значение - сохраняйте отдельное значение, вашим способом или любым другим, например, так:
for (var i = 0; i < 5; ++i) with ({i:i}) funcs[i] = function () { return i*i; };
или (если 'with()' не по душе) сохраняя значение непосредственно в свойстве каждой функции, или конструируя тело функции, или ещё как, не вижу тут хаков...
for (var i = 0; i < 5; ++i) with ({i:i}) funcs[i] = function () { return i*i; };
или (если 'with()' не по душе) сохраняя значение непосредственно в свойстве каждой функции, или конструируя тело функции, или ещё как, не вижу тут хаков...
:) Я-то на сами замыкания не грешу. К замыканиям у меня претензий нет. Я указал на очевидную ошибку в статье - язык не поддерживает замыканий. Ваше "если нужно" - это и есть определение замыкания. Именно автоматическое сохранение контекста в момент создания функции. На уровне языка. Ясен пень, что значения можно сохранять вручную тем или иным способом. Помните такой язык - фортран4? Там при вызове функций параметры сохранялись не на стеке, а в специальную область памяти и были в ней фиксированы. Можно ли было вызывать там функции рекурсивно? Можно. Путём хитрых манипуляций с common блоками или массивами. Но языком рекурсия не поддерживалась. И её поддержка не декларировалась.
Так и с нашими баранами. Языком замыкания не поддерживаются. Но нужного поведения таки можно добиться, применив смекалку :). Это и называется хаком. :) :)
Так и с нашими баранами. Языком замыкания не поддерживаются. Но нужного поведения таки можно добиться, применив смекалку :). Это и называется хаком. :) :)
>язык не поддерживает замыканий
На мой взгляд поддерживает, хотя я не очень люблю этот термин. Спорить тут сложно, нет базиса. Попробуйте найти общепризнанное определение замыкания (не найдёте, если только у авторитетного Филд-а). Под определение существующую в javascript ситуацию можно подвести запросто, потому как контекст (scope chain в javascript) на момент создания функции сохраняется и существует вместе с функцией, формируя т.н. "function-value". По факту JS-сообщество (включая шишек-разработчиков) приняло термин "замыкание", его использует, он краток, в общих чертах понятен, плюс-минус точно отражает суть. Протестовать против замыкания как термина, а тем более, как явления, так же бесполезно, как бороться с хешами, ассоциативными массивами, классами в ECMAScript... ;)
На мой взгляд поддерживает, хотя я не очень люблю этот термин. Спорить тут сложно, нет базиса. Попробуйте найти общепризнанное определение замыкания (не найдёте, если только у авторитетного Филд-а). Под определение существующую в javascript ситуацию можно подвести запросто, потому как контекст (scope chain в javascript) на момент создания функции сохраняется и существует вместе с функцией, формируя т.н. "function-value". По факту JS-сообщество (включая шишек-разработчиков) приняло термин "замыкание", его использует, он краток, в общих чертах понятен, плюс-минус точно отражает суть. Протестовать против замыкания как термина, а тем более, как явления, так же бесполезно, как бороться с хешами, ассоциативными массивами, классами в ECMAScript... ;)
Подвести-то под определение можно всё. См.пример с рекурсивными вызовами в фортране-4. Формально, да, попадает. Просто ситуация странная - все идут не в ногу, а один явийскрипт - в ногу, не находите? :)
А против явления я не протестую, просто во всех остальных виденых мною языках с задекларированой поддержкой замыканий, под этим явлением подразумевалось нечто чуточку другое.
А против явления я не протестую, просто во всех остальных виденых мною языках с задекларированой поддержкой замыканий, под этим явлением подразумевалось нечто чуточку другое.
Ага, "полностью ооп язык" - но реализация через (|)опу. Одни приватные переменные чего стоят - чтобы создать приватную переменную надо на лету генерить ей аксессор.
А "классическое наследование" - все через костыли, inherits, uber\super. AFAIK одна из основополагающих "фич" наследования как раз в том, чтобы не писать вызовы "родителя", а пользоваться родительским вызовом прозрачно для кода, чтобы тот же ToString() вызывался бы родительский если нету дочернего, а с такими свистоплясками с прототипами и обертками.
Это знаете ли - "язык Эз(|)" - т.е. "сказать" можно все, но подход - как у нетрадиционно ориентированных. Это как в .NET дали бы только Reflection и сказали - ну теперь вы можете написать все что угодно. Да, наверное могу, но не хочу, потому что есть другие, нормальные средства, в которых с выразительностью получше и нету таких косяков.
PS: Сам сначала был в восторге от некоторых возможностей, особенно прототипа, конструирования классов на лету и прочее, а в итоге понял что для нормального, читабельного и поддерваемого кода лучше такое не трогать, а еще лучше - вообще отказаться от JS и использовать только там где без него - никак.
Я бы назвал этот язык не "СНЯП" а "самая распространенная уродливая реализация хорошей идеи".
А "классическое наследование" - все через костыли, inherits, uber\super. AFAIK одна из основополагающих "фич" наследования как раз в том, чтобы не писать вызовы "родителя", а пользоваться родительским вызовом прозрачно для кода, чтобы тот же ToString() вызывался бы родительский если нету дочернего, а с такими свистоплясками с прототипами и обертками.
Это знаете ли - "язык Эз(|)" - т.е. "сказать" можно все, но подход - как у нетрадиционно ориентированных. Это как в .NET дали бы только Reflection и сказали - ну теперь вы можете написать все что угодно. Да, наверное могу, но не хочу, потому что есть другие, нормальные средства, в которых с выразительностью получше и нету таких косяков.
PS: Сам сначала был в восторге от некоторых возможностей, особенно прототипа, конструирования классов на лету и прочее, а в итоге понял что для нормального, читабельного и поддерваемого кода лучше такое не трогать, а еще лучше - вообще отказаться от JS и использовать только там где без него - никак.
Я бы назвал этот язык не "СНЯП" а "самая распространенная уродливая реализация хорошей идеи".
Фактически каждый персональный компьютер имеет его интерпретатор и активно им пользуется.
JavaScript имеет C-подобный синтаксис
Он имеет массивы вместо списков
Он имеет замыкания.
JavaScript имеет свои ошибки в дизайне
JavaScript имеет настолько сильную выразительную мощь
Он имеет объекты
Он не имеет классо-ориентированного наследования — ну хоть кого-то он не имеет, маньячинка этакий!
Статья очень секси ;-)
JavaScript имеет C-подобный синтаксис
Он имеет массивы вместо списков
Он имеет замыкания.
JavaScript имеет свои ошибки в дизайне
JavaScript имеет настолько сильную выразительную мощь
Он имеет объекты
Он не имеет классо-ориентированного наследования — ну хоть кого-то он не имеет, маньячинка этакий!
Статья очень секси ;-)
insertion 1) введение, включение insertion of a new item in the programme — включение нового номера в программу 2) а) вставка (слова, текста, страницы в рукописи, в корректуре) б) вставка (в одежде) в) объявление (в газете)
использование авторами языка точки с запятой eq включение ее в синтаксис, разве нет?
Статья безграмотна.
1)"JavaScript всецело обязан своей популярностью тому, что он стал основным скриптовым языком для веба."
От такой популярный потому что популярный... Если что-то используется везде - оно и так популярно.
2)"Судя по всему это название выбрали специально, чтобы создать неразбериху"
Название выбрали как маркетиговый шаг.
3)"Префикс "Java-" намекает на то, что он является подмножеством или упрощенной версией Java."
JS не является ни подмножеством, ни упрощенной версией Java.
4)"Он лучше чем Java в приложениях, для которых Java (тогда называвшаяся Oak) изначально разрабатывалась."
Сравнение вообще некорретно. Иными словами автор говорит что на JS лучше писать веб-службы и высоконагруженные системы чем на Java. Это минимум спорное утверждение.
И так далее...
1)"JavaScript всецело обязан своей популярностью тому, что он стал основным скриптовым языком для веба."
От такой популярный потому что популярный... Если что-то используется везде - оно и так популярно.
2)"Судя по всему это название выбрали специально, чтобы создать неразбериху"
Название выбрали как маркетиговый шаг.
3)"Префикс "Java-" намекает на то, что он является подмножеством или упрощенной версией Java."
JS не является ни подмножеством, ни упрощенной версией Java.
4)"Он лучше чем Java в приложениях, для которых Java (тогда называвшаяся Oak) изначально разрабатывалась."
Сравнение вообще некорретно. Иными словами автор говорит что на JS лучше писать веб-службы и высоконагруженные системы чем на Java. Это минимум спорное утверждение.
И так далее...
дочитайте статью до конца
2, 3) Это такой литературный прием - показать весь идиотизм выбранного названия из-за котрого в том числе пошла неразбериха.
4) Почитайте для чего разрабатывался Oak, да, это было очень давно.
2, 3) Это такой литературный прием - показать весь идиотизм выбранного названия из-за котрого в том числе пошла неразбериха.
4) Почитайте для чего разрабатывался Oak, да, это было очень давно.
2)Думаю литературные приемы стоит оставить для художетсвенной литературы. В технических статьях лучше говорить конкретно, а не образно. "Java - это интерпретируемая Java." - видимо тоже литературный прием... Как там было в индуском коде: i=i; - буддиское созерцание постоянности.
3) А собственно какое мне дело в 2008 году для чего разрабатывалась Java в 1995? Или, быть может, статья написана как раз в 1995 и она представляет исторический интерес? Java давно не Oak, а JS до выхода JS2 почти не изменился. А тут такие выводы...
3) А собственно какое мне дело в 2008 году для чего разрабатывалась Java в 1995? Или, быть может, статья написана как раз в 1995 и она представляет исторический интерес? Java давно не Oak, а JS до выхода JS2 почти не изменился. А тут такие выводы...
1) JS язык пригодный и разрабатываемый не только для внутребраузерного использования, популярность он обрел именно из-за того, что его стали использовать повсеместно в веб
Тоску навеевает то, что это единственный язык, который понимают браузеры. Альтернативы нет. Сколько M$ ни старалась продвинуть свой VBScript - ничего не получилось (впрочем, это и к лучшему). А между тем, JS в силу вышеперечисленных причин, далеко не самый удачный скриптовый язык, который мог бы использоваться для клиентского программирования. Взять хотя бы Ruby или Python... Вообще идея была иметь встраиваемые в браузер интерпретаторы (для данных языков уже существуют), но данная технология не имеет поддержки со стороны производителей браузеров.
Между прочим, JavaScript и Java имеют несколько больше общего, нежели только название. Например, из JavaScript можно вызывать методы Java аплета и наоборот - Java Applet имеет доступ к DOM и JS. Кому интересно, дам линки:
http://java.sun.com/j2se/1.5.0/docs/guid…
http://java.sun.com/j2se/1.5.0/docs/guid…
Между прочим, JavaScript и Java имеют несколько больше общего, нежели только название. Например, из JavaScript можно вызывать методы Java аплета и наоборот - Java Applet имеет доступ к DOM и JS. Кому интересно, дам линки:
http://java.sun.com/j2se/1.5.0/docs/guid…
http://java.sun.com/j2se/1.5.0/docs/guid…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Самый недооцененный язык в мире