Новшества добавляемые в ECMAScript6 - это заимствования из других языков, вроде Python и Ruby. Перенимать ещё многое можно.

1) Невозможно уследить за типами объектов, т.к. прототип объекта может быть изменён, а instanceof проверяет наличие прототипа в объекта указанного как Function.prototype, который также можно изменить, т.е:

function Foo() {}
var foo = new Foo;

foo instanceof Foo; // true
Foo.prototype = {};

foo instanceof Foo; // false

Лечится соглашением: не делайте так, описывайте прототипы, как если бы вы описывали класс, т.е. статически и спокойно сравнивайте типы по instanceof.

В ECMA6 лечится сахаром в виде class

2) Отсутствие модулей приводит к захламлению глобального пространства.

Лечится соглашением: используйте анонимные самовызываемые функции, свойства объектов как пространства имён и паттерн "модуль".

В ECMA6 лечится сахаром module

3) Плохая поддержка автокомплита и статического анализа в ИДЕ, т.к. нет явной декларации типов.
Лечится соглашением об обязательном использовании JSDoc.

4) JavaScript жутко медленный, ужас!
Не складывайте строки с числами, не меняйте динамически прототипы во время исполнения, не вызывайте eval внутри eval и вы удивитесь, как быстро может работать ваш код.

5) Громоздкий старомодный синтаксис функций, функциональная область видимости.
ArrowFunction, let ...

Могу долго перечислять.

Зачем разбираться в 3-х?


Попиши на Яве или С# в блокноте. Явная декларация типов для того и создана, чтобы IDE могла вам помогать. В Dart тоже явная декларация типов, и тоже с целью поддержки в ИДЕ. Если ты не будешь пользоваться ИДЕ под Дарт, то тебя он будет только бесить.

Не уследил, когда последний раз игрался с ним - то не было:)

Как это вообще связано? ;)

Ну пиши на любом языке, потом компилируй в asm.js, подключай и используй. Или тебе прям elf формат нужен ?

Я знаю, только где бенчмарки о сравнении скажем корректного JS (можно даже asm) и VM Dart?

Многих раздражает писать явные декларации типов (ведь скриптовые языки часто юзаются в повседневных задачах, где эта многословность только мешается). Самым правильно решением имхо является как например в ActionScript 3: хочешь пиши, хочешь не пиши. Я не вижу преград, почему в JS не смогут добавить опциональную поддержку типов данных, т.е. новый язык для этого лепить не надо.

nerv_, я ответил на твои вопросы, а теперь ты назови 3 фичи Дарта, которые не могут быть эволюционно добавлены ЖС и являются фатальным недостатком, из-за которого необходимо пилить новый язык, новую VM, новую IDE, новые фреймворки ?) Просто гугл любит повелосипедить :)

Угу клево мне тоже нравится. В typescript так, можно опускать тип.

Осмелюсь предположить что дело не в том чего нельзя добавить в JS а в том чего из него нельзя убрать. Действительно добавить можно что угодно, а вот выпилить мешает обратная совместимость.

Там это немного криво сделано. Например я не могу сделать так:

Node.prototype.foo = function () {
};

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

Они говорят, что любой ЖС валиден ТС. Берём Mootools, подключаем без специального плагина и всё ломается :)

Ваще у ТС ещё много проблем. Когда он вышел я с радостью бросился его юзать, но через недели 2 положил на полку. Я не говорю, что он плохой, а просто он ещё слишком молодой, а когда я узнал про фичи ECMA6 то понял, что и не хочу с JS уходить.

'use strict'; 'use asm'; и т.д.

Так например уже выпилена возможность объявлять переменные без var, arguments.callee, with и т.д. и никто же не умер.

Ну да, asm.js выпилил из языка почти всё, оставив очень ограниченное подмножество. Хотя ничего не мешает написать внутри модуля var a = 'b', всего-то валидация будет забракована и плюшек AOT-компиляции мы не получаем, но код все равно будет работать.
То есть, как бы расширение языка поперек, а не вдоль. Не столько эволюция базы, сколько агрегация субстандартов.

Советую всем наконец познакомиться с Lua :)

Ага:

new List<int>.generate(10, (final int index) => index + index); // [0, 2, 4, 6, 8, 10, 12, 14, 16, 18]

Зачем транслировать код из Lua в JS, а потом еще в ASM.js, который в свою очередь будет транслироваться в байт-код, если можно сразу получить байт-код? ;)

Ну смари, сидишь на работе, к тебе босс подходит и спрашивает: "почему ничего не делаешь?", а ты ему честно в ответ "я компилирую":D

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

А так сейчас, жизнь и без этого не сладка, учитывая всякеские html/css/js препроцессоры, линтеры, минификаторы, сборщики, и пр. штуки.

Как и везде:) Мне Братишка рассказывал, как у них в Яве проекты собираются (разумеется я имею ввиду большие проекты с километровыми слоями интеграций xslt и прочего) и я понял, что у нас не всё так уж и плохо:)

Если ты сначало откомпилишь LUA в JS то в дальнейшем нет смысла делать из него asm.js :) Ибо все что написано на JS работает быстрее без компиляции в asm.js :)

Байт код для intel 32, или байткод для intel 64 ? И что делать с ARM архитектурой ?

Это вариант.

В NaCl вроде с этим справились.

Java это отдальный разговор :)

Байт-код, как правило, аппаратно независим. Это как язык, только для другой программы, а не для человека. Считай, готовый набор инструкций для компилятора или VM.

В NaCL юзается LLVM. Я так понимаю, что он поддерживает множество платформ.

Насколько я знаю ELF под конкретную архитектуру компилируется.
А в NaCL юзается LLVM.

А вот кстати, можете объяснить:
Про GCC (GNU Compiler Collection) я читал, что он работает по принципу: сначала транслирует в ассемблер, а затем в машинный код под конкретную архитектуру.

А как работает Clang? Т.е. он генерит байт код для LLVM? А что есть LLVM, т.е. некая VM которая по дефолту встроена в ОСь или что?

:blink:
Интересно, почему не в хаскель? (иронизирую)

From Source to Binary: The Inner Workings of GCC

Прям ща держку книжку по С, издательство O`Realy (Дэвид Гриффитс, Дон Гриффитс), купил в этом году, в книжке описывается стандарт С11, C99 и Ansi C, как компилятор выбран именно GCC.

1) Прекомпиляция исходника: добавление заголовочных файлов указанных с помощью #include
2) Трансляция в ассемблер
3) Ассемблирование: генерирование объектного кода
4) Линковка: сбор всех файлов вместе

Я не думаю, что в O`Realy допустили бы столь грубую неточность.

kobezzza,
А, ну как промежуточное звено перед объектным кодом, возможно.

Ну я бы не стал писать такие вещи, если бы сам о них не узнал из достоверных источников или не убедился на практике:)

kobezzza,
Не, я немного не понимаю насчет, сложилось ли так исторически, или этот шаг строго необходим по другим причинам. Ибо сам с ассемблером не пересекался.
Может, я просто туплю сегодня. :)

Где ты это нашел?

В бы рекомендовал начать в такой последовательности:

The C++ Programming Language — Bjarne Stroustrup
C++ for Real Programmer — Jeff Alger
The Art of C++ — Herbert Schildt
Algorithms in C++ — Robert Sedgewick
Design Patterns: Elements of Reusable Object-Oriented Software — Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides
C++ Gotchas. Aoiding Common Problems in Coding and Design — Stephen C. Dewhurst
C++ Templates: The Complete Guide — David Vandevoorde, Nicolai M. Josuttis
The CERT C Secure Coding Standard — Robert C. Seacord
More Effective C++: 35 New Ways to Improve Your Programs and Designs — Scott Meyers
Effective C++: 55 Specific Ways to Improve Your Programs and Designs — Scott Meyers
C++ Coding Standards — Herb Sutter, Andrei Alexandrescu
C++ Concurrency in Action: Practical Multithreading — Anthony Williams
Ну и со временем начать мониторить станадрат )

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

monolithed, мне был нужен С, а не С++:)

Или тебе доставляет удовольствие искать в гуле как сконтанировать строку? :D

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

GLSL - язык шейдеров, по сути С
Cuda C - возможность юзать GPU видюх NVidia
и т.д.

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

А чем С++ не угодил, он же включает в себя С?
Или тебе нравится определять все переменные в начале функции? :D

Ну по первых не всякий С - это С++, я уже сам лично в этом убедился, но это ладно, главное, что мне просто не нужен сейчас С++ (вернее нет времени) + как я уже говорил знание фишек С++ мне не поможет в GLSL, т.к. их там нет:)

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

В С переменные можно объявлять где угодно:)

Как выстрелить себе в ногу, ты точно быстро выучишь.
Но monolithed прав, на С++ это можно сделать куда более кроваво и изощренно. :D

C89/90 требуют этого.

А вот этот пример в C99, не скомпилится (без особых флагов):

for (int i = 0; i < 10; i++) { ...

Нужно так:

int i; 
for (i = 0; i < 10; i++) { ...

Как говорит Страуструп, на С++ острелишь :D

На дворе С14:)
Твой пример у меня без всяких флагов работает, юзаю Clang для компиляции.

Ты наверно имел виду С11 ?

Вероятно потому что:

➜ clang -v
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin13.0.0
Thread model: posix

Вышел же 14 стандарт, или это только для С++ ?
http://habrahabr.ru/post/184606/

C++14 пока даже финального драфта нет, но Сlang и GCC49 уже поддерживают его большую часть.
Про С14 я не слышал.

Моя первая нога. Ща уже точно не помню, но примерно так...

CFile * OpenFile()
{
    CFile file("123.txt", CFile::modeRead);
    return &file;
}

void main(int argc, char *argv[]) 
{
    unsigned char * pData = new unsigned char[100];
    CFile * textFile = OpenFile();
    // тут еще какой-то код, вызовы)))))
    textFile->Read(pData, 100);
    // а тут по идее вывод в консольку... но только по идее
}

:lol: