> Есть задачи на которых JIT обгоняет и PBO и ассемблер.
Ладно, не охота мне разводить спор, но по-любому — заточенные под одно и тоже железо асм будет быстрее си (при этом оба компилируемые) и уж тем более они оба будут быстрее интерпретируемой сущности (хоть и JIT-оптимизатором).
Другой вопрос, если говорить только лишь о динамических, интерпретируемых сущностях — так для этого, повторю, эти оптимизаторы (JIT и т.д.) создавались, чтобы быть быстрее.
а черт! )) случайно кнопка нажалась, не дописал и теги не закрыл )) ну в вроде все, что хотел — упомянул )) да, в Питоне — то же самое:
Хотя, я не читал спецификацию ES4 — возможно там сделано оптимизация, и это на самом деле, один метод (просто из-за того, что он связан с инстансами выдается false — но я не знаю точно, это только предположение)
Вот именно, что пугало. При этом одними, когда они видят заголовки «классы в JS», движет «несовершенство внешнего мира» :) и они хотят подкорректировать, уточнить, помочь, показать, — что в ECMAScript другая альтернативная модель и что стоит это учитывать. А другие могут насмотреться на это (на высказывания профи) и вообще бессознательно постоянно потом говорить «надругались».
При этом — копни чуть глубже (тот же Питон или Руби) — то, вроде, как и «тоже самое как в JS», но почему-то названо «класс». Поэтому, можно сразу уточнить — «Вы какие классы имеете в виду, когда говорите „надругались“? Статические или динамические, порождающие мьютэбл-объекты и сами являющиеся мьютэбл-объектами?». При этом сразу будет получен ответ — «эм… да, статические...». И дальше ответ — но это не возможно в текущей версии JS, поэтому обертка, которую люди называют «класс» (или еще как) внутри себя оперирует все теми же динамическими сущностями с делегирующим к прототипам наследованием.
При этом можно показать самое главное преимущество использования прототипов с делегирующей моделью — один метод расшаривается по всем инстансам (в то время как при описании той же порождающей сущности классом — будет использовать каскадная модель, которая создаст каждому инстансу свои одни и те же по семантике методы). Но при этом делегация имеет меньшую скорость в отличии от каскадирования. Мне вообще смутным представляется большая выгода (кроме скорости обращения) описания методов в классе, а не в прототипе. Например, из ES4:
dynamic class A {
function test() {}
}
var a = new A();
var b = new B();
a.test === b.test; // false!
a.hasOwnProperty('test'); // true
На кой ляд мне один и тот же одинаковый метод? А если инстансов будет 1000 (а если 100000?)? — при этом я не думаю, что будет цепь наследования в 10000 уровней. Конечно его выгодней вынести в прототип. Таким образом делегирующая прототипная модель получается выгодней в ресурсах.
> Начиная с некоторого уровня сложности системы код, написанный на низком уровне оказывается менее эффективен, чем код, переведённый с высокого уровня с учётом сложившихся реалий!
А то я тут рассуждаю про код под железо, сшитое при царе Гороже?! Когда проводятся аналогии — они и должны быть аналогиями.
Если железо перешло на новые стадии, то, естественно, код, который не в силах учитывать эти стадии будет менее эффективным. Это прописная истина.
> И даже JIT, написанный на ассемблере (и потому не включащий в себя многих оптимизаций) проиграет JIT'у, написанному на C/C++.
Это как? Мне реально интересно. Я правильно понимаю — Си-транслятор, написанный на асме (при этом Си-шные обертки внтри себя имеют по несколько десятков ассемблерных вставок, чтобы предусмотреть «все случаи жизни») быстрее того же самого асма (того же самого! а не того, который был был при Рамзесе-III написан и не учитывал новые возможности железа).
Какой смысл сравнивать то, что не может учитывать новых особенностей с тем, что это может делать? (и в случае с JIT'ом и PBO еще и делает это в рантайме, подстраиваясь под текущие аппаратные возможности) — обычная подмена понятий.
Кстати, JIT — такая же высокая абстракция, которая жертвует различного рода ресурсами (требует время на постоянную, больше памяти и т.д.), для создания прогресса. Как иначе создать кросс-платформенность, кроме как интерпретации (с промежуточным байт-кодом, и где-то — компиляции этого байт в нэйтив-код)? — Ответ — давайте потратим чуть больше времени на компиляцию некоторых критичных кусков прямо в рантайм, но зато будем учитывать специфику аппаратуры. Но, если если сравнивать сравнимое и аналогичное, то это и ежу понятно, что статичный скомпилированный код будет быстрее интерпретируемого (не важно какие оптимизации (JIT, PBO и т.д.) используются при этом).
При этом, несомненно, JIT добавляет в интерпретируемость приближение с компилируемым скоростям.
Все эти оптимизации — есть так же абстрагированные сущности прогресса и, конечно, очень важны в скорости разработки (для которой все это создается).
Относительно верхней абстракции? (мы имеем в виду скорость выполнения, а не скорость разработки). Еще какая гарантия, поскольку верхняя абстракция используется эту нижнюю внутри себя с многочисленных проверками, чтобы уменьшить монотонные операции.
> Большая и сложная программа на нём будет менее эффективна — просто внимания не хватит оптимально всё писать.
Ну так я именно об этом и говорю (внимательней прочитайте пост выше).
> и подумайте
:) я «оценил».
> сколько лет вы бы отлаживали подобную систему на ассеблере и какой реальный выигрыш вы бы получили.
туда же относится — я именно об этом и говорил постом выше (еще прочитайте внимательно).
В очередной раз повторяю — основная идея усиления абстракций — убыстрить разработку, жертвуя ресурсами (но с верой и знанием, что то, для чего разрабатывается абстракция — тоже развивается). Вы же, «цитируя» меня же из поста выше (поскольку я говорил об этом же) подменяете понятия — «скорость выполнения» и «скорость разработки».
> Если бы это всегда было не так, то никто бы не писал ассемблерные программы для маломощных устройств.
> накладные расходы при переходе на новый уровень абстракции приводят к уменьшению эффективности (несущественного для современных компьютеров, но критичного для маломощных устройств).
Друзья, и то, и то — верно.
Кстати, ассемблерные вставки могут использовать (помимо убыстрения) также и для более низкоуровневых операция, если таковые недоступны из «обёрточных» функций языка (например, модуль асма для программирования на Питоне — habrahabr.ru/blogs/python/45726/)
Можно так же задавать вопросы — почему, например, JavaScript / Python / Ruby и т.д. написаны не на ассемблере? А что? — было бы быстрее в разы. Это вот как раз то, когда абстракция усилилась (появился Си), когда появились автоматизации сканеров и парсеров (типа Flex'a и Bison'a) — стало удобней и быстрей создавать новые языки. При этом, вероятно, создателей языков все же волновал вопрос, что их новый язык будет медленней даже Си (раз в 200), не то, что ассемблера. Но и так же, они, вероятно, осознавали, что если начнут сейчас писать JavaScript на асме, то потеряют много своих человеческих ресурсов (и может, и когда закончат — этот новый язык уже устареет и мало кому будет нужным).
Так же можно провести аналогию — оружие разных времен (тема не очень гуманная, но все же) — ясно-понятно, что для создания боевой дубины из ресурсов нужна только палка. В то время как для ядерной бомбы будет затрачено ресурсов >>>> больше. Разница в масштабы — понятно какая.
Что же касается меня лично — рассуждая о теме абстракций в языках программирования, я при этом являюсь большим почитателем ассемблера (хоть моя работа и не связана напрямую с ним). Так же я фанат демо-сцен, когда на чистом асме (ну а сейчас уже на Си), общаясь с железом напрямую в реальном времени, пишут замечательные красивые демки размером всего 64Кб (а иногда и интро в 4Кб). Кто не в курсе — посмотрите, например, демо немецкой команды Farb-Rausch. Это, конечно, искусство!
Да конечно, не факт. Только вот с фразами «надругались над JS — используют классы» та же история. Конечно, печально, когда действительно не понимают, как это работает, и яро доказывают всякую отсебятину. Но вот те, кто создает просто удобные обертки для создания последовательной связи объектов через прототипы, мне кажется, и холиворить-то не будут никогда не эту тему. Ну назвали бы они эту обертку InheriteFrom(...) (или ObjectConstructorWithInheritance), а не Class(...) (при этом бы начинка не поменялась бы ни на байт) — все! — вряд ли бы вообще кто-то что-то критиковал.
Хотя, да — человек может и не осознавать, что он пишет обертку, а думать, что доводит до «ума» этот «бесклассовый язык». Здесь надо просто с самого начала сказать (и показать), что есть альтернативная модель наследования (что человек просто не в курсе, что речь о разных подходах ведется) и что она так же хороша и даже относительно лучше (это я опять не тебе говорю (ты и так хорошо преподаешь), а — вообще — всем, кто выбирает сам постоянно вестить на выкрики новичков aka «че за язык? тут даже классов нормальных нет!»)
> К слову, мне ближе позиция генерации кода и сейчас слежу вот за этим проектом: groups.google.com/group/ruby-red-js
сразу бросается в глаза надпись, выделенная жирным шрифтом:
You don't need to learn JavaScript.
Объективно, во всем этом лежит желание создать такую абстракцию, которая была бы единой для всех и не надо было бы изучать всякие другие непонятные/сложные/нудные (каждый свое выберет) абстракции. Но и это не получится, поскольку будут появляться еще более абстрагированные сущности, которые будут автоматом генерировать уже и код на Руби (и где-то будет блестать надпись «You don't need to learn Ruby») и т.д. — до тех пор, пока нужда писать код вручную отпадет полностью. И естественно, как и любая усиленная абстракция (когда Вы не будете писать ни строчки JS, а JS код полностью будет сформирован посредством Ruby), этот подход будет иметь большие потери в ресурсах на «нынешнем железе».
> Из-за этого, многие разработчики думают, что знают JavaScript, хотя, на самом деле они знают только Prototype.js.
повторяю (Вы, кстати, игнорировали мой коммент выше) — не стоит холиворить с теми, кто пока на начальном этапе изучения JS и может по дурости из-за нехватка информации нести всякую чушь aka «классы! классы! ибо Class.create()!». Вы-то знаете, что в ECMAScript на данный момент прототипное наследование. А вот то, что Вы постоянно пишите про «надругались!» — это тоже говорит о том, что Вы мыслите ограничено.
Вот здесь и здесь я проводил аналогию протипного наследования JS с классовой моделью Python'а. Почитайте; если Вам нравится JavaScript, Вам будет интересно. Поэтому, не волнуйтесь по поводу новичков, которые будут Вам доказывать, что они выучились JS по Prototype.js и уверены, что классы в JS есть — у них все еще впереди. А вот если Вы будете мыслить системно и абстрактно, то увидите, что роль классов в JS (пусть в больших кавычках) играет прототип конструктора (как подтверждение — схожая модель в Питоне, и там и там налицо — делегация).
> Я просто не согласен с той фразой, что переход на новый уровень происходит совсем без увеличения накладных расходов.
а кто это говорил? я не видел; в любом случае — это глупость, переход на новый уровень (на то он и прогресс, а не регресс) будет нести дополнительные расходы, но благодаря параллельному развитию того, для чего (или кого) эта абстракция писалась (в данном случае — язык для машины) получается прогресс (иначе был бы регресс — потребление ресурсов увеличивается и все тормозит, т.к. то, для чего была создана новая абстракция не развивается)
сами Вы язык «процессора»! :D есть только два положения — «есть напряжение / нет напряжения» и мнемокоды и hex- код (и даже bin- коды) — все это абстрагированные от физического проявления (есть напряжение / нет напряжения) сущности.
это необратимый процесс усиления абстракций, относительно старых ресурсов; сами ресурсы также развиваются параллельно с усилением абстракций.
Идеологи, которые создают новые абстракции прекрасно понимают, на что идут и осознают все ухудшения в потреблении ресурсов; однако, их идеи подпитываются улучшением возможностей железа.
Еще одно правило — всегда есть профессионалы в текущих абстракциях (часто именно они являются создателями последующих (усиленных) абстракций); и они всегда будут видеть недочеты в новых абстракциях — где-то сетовать, где устранять, где-то — помогать советами. Потом появятся профи в новых абстракциях и будут видеть недочеты в следующих.
> классовое ООП, что является страшным надругательством над JavaScript
насколько Вы профи в JS? а с Python'ом Вы знакомы, например? А классы в Питоне видели? А практически 93% сходство идеологий описания классов в Python и prototype based inheritance в JS видели? Тем не менее, в Python это назвали классы (да и Ruby тоже).
Не обращайте внимание на то, что кто-то делает для себя обертки в виде классов для JS. В любом случае — внутри этих оберток — все то же (единственное в текущей версии ECMAScript) — прототайп-бэйзд-инхеритэнс, а значит человек который писал эту обертку — понимал, в чем дело.
Другой вопрос, что новичкам это может туманить разум; вот в этих случаях им надо помогать.
Можно полностью почитать те мои комментарии; а здесь я скажу основную суть, как я вижу линейный ход усиления абстракций:
В этой мешанине наиболее ключевыми фигурами являются идеологи-созидатели и прикладные созидатели (возможно — потребители продуктов идеологов)
— выделяется физическая сущность (не абстрактная), например — программирование «проводками»;
— идеологи создают абстракцию (bin- и hex- коды) и уже управляют переключением проводов сигналами кодов — 0 и 1;
— на этом этапе подключаются прикладные потребители абстракций, созданных идеологами и начинают использовать эти абстракции (называя «уродливым» программирование проводками); некоторые потребители на этом этапе становятся идеологами-созидателями (но уже относительно этого нового уровня абстракции)
— идеологи продвигаются дальше (в виду различных причин), создавая все более абстрактные сущности — так появляются ассемблеры, которые являются очень мощной абстракцией, относительно программирования hex-кодами;
— и снова подключаются прикладные потребители, называя «уродливыми» hex- и bin- коды и холиворят на «форумах», отстаивая идеи продукта (при этом не являясь создателями); так же выделяются новые идеологи, которые уже на ассемблере пишут абстракции вроде Си, Паскаль, др.
— … и т.д. (от уровня ассемблера развитие абстракций можно найти в статье)
Главное здесь — этот процесс необратим. И главное, понимать, что любая новая абстракция несет потери в ресурсах, относительно предыдущей, на старом железе и сглаживает (и опережает) — на новом. В идеале, весь код должны будут генерировать машины, люди же будут созидать иными формами «языков» (возможно, мысленно).
> И вам остается только локти кусать что вы в это число не попали.
куда не попали? в «элиту» или пансионат? :D «элита» — понятие в данном случае относительное. На любого крутого найдется всегда круче ) Я ж отметил, что говорил лишь о методе подачи на сайте, не более (не сомневаюсь, что съезжаются туда хорошие специалисты). А вот информативная подача на сайте — психологически дешевая и паленная.
Хотя, каждый создает свои круги общения и выстраивает вертикальные лестницы как им вздумается (так появляются «лучизарные и солнцеподобные веб-гуру» :D) — и никто упрекать их (если это локальная группа со своими тараканами в голове) за это не может. И мне-то, собственно, по-барабану, я лишь заметил, но не упрекал. С другой стороны, если это выдается за «Орден, присваиваемый другими лучезарными гуру удостоенным новоиспеченным гуру» и распространяется за пределы локального круга общения, то, повторю, с подобной политикой главное не переборщить.
По поводу разрозненного именования функций (и как следствие — неопрятности php) полностью согласен.
.ps: я не PHP отстаиваю (мне самому Руби с Питоном больше нравятся; но не потому, что я могу написать 5.times вместо for-цикла, а из-за идеологии), я просто отметил очередное цепное появление подачи PHP в статьях о Руби, не более. Хотя, все, действительно, познается в сравнении.
а, черт, простите, я Вас спутал с неким Julik, о котором Вы упоминали; я сходил по ссылке — live.julik.nl/2005/11/php-is-so-90s и увидел третий пункт.
> то наверное он это не рандомная рефлексия.
конечно не рандомная, а цепная реакция;
При этом и Руби и Пайтон, повторю, действительно, изящны, меня просто умиляют фразы типа «я возненавидел PHP» — т.е. восхваляется продукт через сравнительное унижение другого продукта. Стало быть, к Вам это не относится, прошу извинить.
Ладно, не охота мне разводить спор, но по-любому — заточенные под одно и тоже железо асм будет быстрее си (при этом оба компилируемые) и уж тем более они оба будут быстрее интерпретируемой сущности (хоть и JIT-оптимизатором).
Другой вопрос, если говорить только лишь о динамических, интерпретируемых сущностях — так для этого, повторю, эти оптимизаторы (JIT и т.д.) создавались, чтобы быть быстрее.
Хотя, я не читал спецификацию ES4 — возможно там сделано оптимизация, и это на самом деле, один метод (просто из-за того, что он связан с инстансами выдается false — но я не знаю точно, это только предположение)
Вот именно, что пугало. При этом одними, когда они видят заголовки «классы в JS», движет «несовершенство внешнего мира» :) и они хотят подкорректировать, уточнить, помочь, показать, — что в ECMAScript другая альтернативная модель и что стоит это учитывать. А другие могут насмотреться на это (на высказывания профи) и вообще бессознательно постоянно потом говорить «надругались».
При этом — копни чуть глубже (тот же Питон или Руби) — то, вроде, как и «тоже самое как в JS», но почему-то названо «класс». Поэтому, можно сразу уточнить — «Вы какие классы имеете в виду, когда говорите „надругались“? Статические или динамические, порождающие мьютэбл-объекты и сами являющиеся мьютэбл-объектами?». При этом сразу будет получен ответ — «эм… да, статические...». И дальше ответ — но это не возможно в текущей версии JS, поэтому обертка, которую люди называют «класс» (или еще как) внутри себя оперирует все теми же динамическими сущностями с делегирующим к прототипам наследованием.
При этом можно показать самое главное преимущество использования прототипов с делегирующей моделью — один метод расшаривается по всем инстансам (в то время как при описании той же порождающей сущности классом — будет использовать каскадная модель, которая создаст каждому инстансу свои одни и те же по семантике методы). Но при этом делегация имеет меньшую скорость в отличии от каскадирования. Мне вообще смутным представляется большая выгода (кроме скорости обращения) описания методов в классе, а не в прототипе. Например, из ES4:
dynamic class A { function test() {} } var a = new A(); var b = new B(); a.test === b.test; // false!a.hasOwnProperty('test'); // true
На кой ляд мне один и тот же одинаковый метод? А если инстансов будет 1000 (а если 100000?)? — при этом я не думаю, что будет цепь наследования в 10000 уровней. Конечно его выгодней вынести в прототип. Таким образом делегирующая прототипная модель получается выгодней в ресурсах.
А то я тут рассуждаю про код под железо, сшитое при царе Гороже?! Когда проводятся аналогии — они и должны быть аналогиями.
Если железо перешло на новые стадии, то, естественно, код, который не в силах учитывать эти стадии будет менее эффективным. Это прописная истина.
> И даже JIT, написанный на ассемблере (и потому не включащий в себя многих оптимизаций) проиграет JIT'у, написанному на C/C++.
Это как? Мне реально интересно. Я правильно понимаю — Си-транслятор, написанный на асме (при этом Си-шные обертки внтри себя имеют по несколько десятков ассемблерных вставок, чтобы предусмотреть «все случаи жизни») быстрее того же самого асма (того же самого! а не того, который был был при Рамзесе-III написан и не учитывал новые возможности железа).
Какой смысл сравнивать то, что не может учитывать новых особенностей с тем, что это может делать? (и в случае с JIT'ом и PBO еще и делает это в рантайме, подстраиваясь под текущие аппаратные возможности) — обычная подмена понятий.
Кстати, JIT — такая же высокая абстракция, которая жертвует различного рода ресурсами (требует время на постоянную, больше памяти и т.д.), для создания прогресса. Как иначе создать кросс-платформенность, кроме как интерпретации (с промежуточным байт-кодом, и где-то — компиляции этого байт в нэйтив-код)? — Ответ — давайте потратим чуть больше времени на компиляцию некоторых критичных кусков прямо в рантайм, но зато будем учитывать специфику аппаратуры. Но, если если сравнивать сравнимое и аналогичное, то это и ежу понятно, что статичный скомпилированный код будет быстрее интерпретируемого (не важно какие оптимизации (JIT, PBO и т.д.) используются при этом).
При этом, несомненно, JIT добавляет в интерпретируемость приближение с компилируемым скоростям.
Все эти оптимизации — есть так же абстрагированные сущности прогресса и, конечно, очень важны в скорости разработки (для которой все это создается).
Были бы. Именно по скорости выполнения — были бы.
> Сам по себе ассемблер — не гарантия скорости.
Относительно верхней абстракции? (мы имеем в виду скорость выполнения, а не скорость разработки). Еще какая гарантия, поскольку верхняя абстракция используется эту нижнюю внутри себя с многочисленных проверками, чтобы уменьшить монотонные операции.
> Большая и сложная программа на нём будет менее эффективна — просто внимания не хватит оптимально всё писать.
Ну так я именно об этом и говорю (внимательней прочитайте пост выше).
> и подумайте
:) я «оценил».
> сколько лет вы бы отлаживали подобную систему на ассеблере и какой реальный выигрыш вы бы получили.
туда же относится — я именно об этом и говорил постом выше (еще прочитайте внимательно).
В очередной раз повторяю — основная идея усиления абстракций — убыстрить разработку, жертвуя ресурсами (но с верой и знанием, что то, для чего разрабатывается абстракция — тоже развивается). Вы же, «цитируя» меня же из поста выше (поскольку я говорил об этом же) подменяете понятия — «скорость выполнения» и «скорость разработки».
> накладные расходы при переходе на новый уровень абстракции приводят к уменьшению эффективности (несущественного для современных компьютеров, но критичного для маломощных устройств).
Друзья, и то, и то — верно.
Кстати, ассемблерные вставки могут использовать (помимо убыстрения) также и для более низкоуровневых операция, если таковые недоступны из «обёрточных» функций языка (например, модуль асма для программирования на Питоне — habrahabr.ru/blogs/python/45726/)
Можно так же задавать вопросы — почему, например, JavaScript / Python / Ruby и т.д. написаны не на ассемблере? А что? — было бы быстрее в разы. Это вот как раз то, когда абстракция усилилась (появился Си), когда появились автоматизации сканеров и парсеров (типа Flex'a и Bison'a) — стало удобней и быстрей создавать новые языки. При этом, вероятно, создателей языков все же волновал вопрос, что их новый язык будет медленней даже Си (раз в 200), не то, что ассемблера. Но и так же, они, вероятно, осознавали, что если начнут сейчас писать JavaScript на асме, то потеряют много своих человеческих ресурсов (и может, и когда закончат — этот новый язык уже устареет и мало кому будет нужным).
Так же можно провести аналогию — оружие разных времен (тема не очень гуманная, но все же) — ясно-понятно, что для создания боевой дубины из ресурсов нужна только палка. В то время как для ядерной бомбы будет затрачено ресурсов >>>> больше. Разница в масштабы — понятно какая.
Что же касается меня лично — рассуждая о теме абстракций в языках программирования, я при этом являюсь большим почитателем ассемблера (хоть моя работа и не связана напрямую с ним). Так же я фанат демо-сцен, когда на чистом асме (ну а сейчас уже на Си), общаясь с железом напрямую в реальном времени, пишут замечательные красивые демки размером всего 64Кб (а иногда и интро в 4Кб). Кто не в курсе — посмотрите, например, демо немецкой команды Farb-Rausch. Это, конечно, искусство!
Хотя, да — человек может и не осознавать, что он пишет обертку, а думать, что доводит до «ума» этот «бесклассовый язык». Здесь надо просто с самого начала сказать (и показать), что есть альтернативная модель наследования (что человек просто не в курсе, что речь о разных подходах ведется) и что она так же хороша и даже относительно лучше (это я опять не тебе говорю (ты и так хорошо преподаешь), а — вообще — всем, кто выбирает сам постоянно вестить на выкрики новичков aka «че за язык? тут даже классов нормальных нет!»)
> К слову, мне ближе позиция генерации кода и сейчас слежу вот за этим проектом: groups.google.com/group/ruby-red-js
сразу бросается в глаза надпись, выделенная жирным шрифтом:
Объективно, во всем этом лежит желание создать такую абстракцию, которая была бы единой для всех и не надо было бы изучать всякие другие непонятные/сложные/нудные (каждый свое выберет) абстракции. Но и это не получится, поскольку будут появляться еще более абстрагированные сущности, которые будут автоматом генерировать уже и код на Руби (и где-то будет блестать надпись «You don't need to learn Ruby») и т.д. — до тех пор, пока нужда писать код вручную отпадет полностью. И естественно, как и любая усиленная абстракция (когда Вы не будете писать ни строчки JS, а JS код полностью будет сформирован посредством Ruby), этот подход будет иметь большие потери в ресурсах на «нынешнем железе».
повторяю (Вы, кстати, игнорировали мой коммент выше) — не стоит холиворить с теми, кто пока на начальном этапе изучения JS и может
по дуростииз-за нехватка информации нести всякую чушь aka «классы! классы! ибо Class.create()!». Вы-то знаете, что в ECMAScript на данный момент прототипное наследование. А вот то, что Вы постоянно пишите про «надругались!» — это тоже говорит о том, что Вы мыслите ограничено.Вот здесь и здесь я проводил аналогию протипного наследования JS с классовой моделью Python'а. Почитайте; если Вам нравится JavaScript, Вам будет интересно. Поэтому, не волнуйтесь по поводу новичков, которые будут Вам доказывать, что они выучились JS по Prototype.js и уверены, что классы в JS есть — у них все еще впереди. А вот если Вы будете мыслить системно и абстрактно, то увидите, что роль классов в JS (пусть в больших кавычках) играет прототип конструктора (как подтверждение — схожая модель в Питоне, и там и там налицо — делегация).
ах, вот Вы о чем ) ну да ладно, зато посмеялись =))
> а то так и напряжение можно свести к электронным потокам.
я о чем и веду речь, только в обратную сторону — в сторону усиления абстракций
а кто это говорил? я не видел; в любом случае — это глупость, переход на новый уровень (на то он и прогресс, а не регресс) будет нести дополнительные расходы, но благодаря параллельному развитию того, для чего (или кого) эта абстракция писалась (в данном случае — язык для машины) получается прогресс (иначе был бы регресс — потребление ресурсов увеличивается и все тормозит, т.к. то, для чего была создана новая абстракция не развивается)
ток прошу — не обижайтесь )) я по-доброму сказал )
это я к тому, что процессор — камень, кристал, железка — она не знает никаких ассемблеров
сами Вы язык «процессора»! :D есть только два положения — «есть напряжение / нет напряжения» и мнемокоды и hex- код (и даже bin- коды) — все это абстрагированные от физического проявления (есть напряжение / нет напряжения) сущности.
это необратимый процесс усиления абстракций, относительно старых ресурсов; сами ресурсы также развиваются параллельно с усилением абстракций.
Идеологи, которые создают новые абстракции прекрасно понимают, на что идут и осознают все ухудшения в потреблении ресурсов; однако, их идеи подпитываются улучшением возможностей железа.
Еще одно правило — всегда есть профессионалы в текущих абстракциях (часто именно они являются создателями последующих (усиленных) абстракций); и они всегда будут видеть недочеты в новых абстракциях — где-то сетовать, где устранять, где-то — помогать советами. Потом появятся профи в новых абстракциях и будут видеть недочеты в следующих.
насколько Вы профи в JS? а с Python'ом Вы знакомы, например? А классы в Питоне видели? А практически 93% сходство идеологий описания классов в Python и prototype based inheritance в JS видели? Тем не менее, в Python это назвали классы (да и Ruby тоже).
Не обращайте внимание на то, что кто-то делает для себя обертки в виде классов для JS. В любом случае — внутри этих оберток — все то же (единственное в текущей версии ECMAScript) — прототайп-бэйзд-инхеритэнс, а значит человек который писал эту обертку — понимал, в чем дело.
Другой вопрос, что новичкам это может туманить разум; вот в этих случаях им надо помогать.
Можно полностью почитать те мои комментарии; а здесь я скажу основную суть, как я вижу линейный ход усиления абстракций:
В этой мешанине наиболее ключевыми фигурами являются идеологи-созидатели и прикладные созидатели (возможно — потребители продуктов идеологов)
— выделяется физическая сущность (не абстрактная), например — программирование «проводками»;
— идеологи создают абстракцию (bin- и hex- коды) и уже управляют переключением проводов сигналами кодов — 0 и 1;
— на этом этапе подключаются прикладные потребители абстракций, созданных идеологами и начинают использовать эти абстракции (называя «уродливым» программирование проводками); некоторые потребители на этом этапе становятся идеологами-созидателями (но уже относительно этого нового уровня абстракции)
— идеологи продвигаются дальше (в виду различных причин), создавая все более абстрактные сущности — так появляются ассемблеры, которые являются очень мощной абстракцией, относительно программирования hex-кодами;
— и снова подключаются прикладные потребители, называя «уродливыми» hex- и bin- коды и холиворят на «форумах», отстаивая идеи продукта (при этом не являясь создателями); так же выделяются новые идеологи, которые уже на ассемблере пишут абстракции вроде Си, Паскаль, др.
— … и т.д. (от уровня ассемблера развитие абстракций можно найти в статье)
Главное здесь — этот процесс необратим. И главное, понимать, что любая новая абстракция несет потери в ресурсах, относительно предыдущей, на старом железе и сглаживает (и опережает) — на новом. В идеале, весь код должны будут генерировать машины, люди же будут созидать иными формами «языков» (возможно, мысленно).
куда не попали? в «элиту» или пансионат? :D «элита» — понятие в данном случае относительное. На любого крутого найдется всегда круче ) Я ж отметил, что говорил лишь о методе подачи на сайте, не более (не сомневаюсь, что съезжаются туда хорошие специалисты). А вот информативная подача на сайте — психологически дешевая и паленная.
Хотя, каждый создает свои круги общения и выстраивает вертикальные лестницы как им вздумается (так появляются «лучизарные и солнцеподобные веб-гуру» :D) — и никто упрекать их (если это локальная группа со своими тараканами в голове) за это не может. И мне-то, собственно, по-барабану, я лишь заметил, но не упрекал. С другой стороны, если это выдается за «Орден, присваиваемый другими лучезарными гуру удостоенным новоиспеченным гуру» и распространяется за пределы локального круга общения, то, повторю, с подобной политикой главное не переборщить.
.ps: я не PHP отстаиваю (мне самому Руби с Питоном больше нравятся; но не потому, что я могу написать 5.times вместо for-цикла, а из-за идеологии), я просто отметил очередное цепное появление подачи PHP в статьях о Руби, не более. Хотя, все, действительно, познается в сравнении.
а, черт, простите, я Вас спутал с неким Julik, о котором Вы упоминали; я сходил по ссылке — live.julik.nl/2005/11/php-is-so-90s и увидел третий пункт.
> то наверное он это не рандомная рефлексия.
конечно не рандомная, а цепная реакция;
При этом и Руби и Пайтон, повторю, действительно, изящны, меня просто умиляют фразы типа «я возненавидел PHP» — т.е. восхваляется продукт через сравнительное унижение другого продукта. Стало быть, к Вам это не относится, прошу извинить.