Typescript vs Dart
 

http://channel9.msdn.com/Shows/Going...cript-and-Dart (en)
Прям "Отцы и дети" какие-то, помимо прочего... А вообще мне начинает нравится идея со статической типизацией, опциональной. А вам? Это должно дать возможность отслеживать использования переменных, методов, ... (из того, что меня интересует).

ну и вот еще на всякий случай: http://channel9.msdn.com/posts/Ander...ing-TypeScript (en)

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

аааааа.. пипец, чтоб видос на сайте у них посмотреть я должен загрузить silverligth. WTF???????

Ты про вот это?

Поставь современный браузер нуп!

Gozar,
добряшка.

При чем тут браузер нуп?

Речь о плагине silverligth

Ч.Т.Д.:

а по теме что-нибудь? Проблема поиска с учетом синтаксиса перед вами не стоит?

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

Видео еще не смотрел, но скажу... :)
Дарт — выдумывание велосипеда, создание собственного синтаксиса, методов и пр. А мелкософту респект, они сделали "надъязык", в котором даже чистый яваскрипт является полностью валидным. Не знаю, буду ли я когда-либо использовать Тайпскрипт, но они явно больше молодцы, чем Гугловцы и я очень рад, что никто не хочет поддерживать этот небогоугодный Дарт.

FINoM,
Я в принципе согласен, хотя сейчас в es-disscus часто обсуждают dart, не считаю его чем то плохим.

Понравилось как они интерфейсы с обьектами связали.
Добавили только то что нехватало.

классы + (классика всегда в цене :D )
интерфейсы + (контроль над согласование множества обьектов, очень не плохо )
статическая типизация+ (как добавка к динамической то что надо)
отсутствие именованных параметров в функциях - (очень удобно, но нету :( )
необходимости предварительной компиляции --- (была бы удобнее компиляция в браузере, хотябы как опция)

Они заботятся о производительности, ну и может быть о помощи программисту (которую по идее должна дать статическая типизация), хотя насчет второго не знаю насколько они серьезно. У Typescript основная цель - вторая.

Я наверное плохо сформулировал вопрос. Как вы относитесь к статической типизации и почему? Хотя если вы сначала видео хотите посмотреть, я конечно подожду...

какие-то ответы неаргументированные и/или субъективные (мне нравится, что...)

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

всегда удобно иметь набор инструментов на выбор.
если статическая типизация, доступна вместе с динамической то это идеальное сочетание на мой взгляд. Очень полюбил C# за эту возможность в своё время, именно там впервые начал пользоваться динамическими переменными. Автор typeScript и автор С#, pascal, delphi это один и тот же человек.

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

function hello(d){
   console.log(d);
}
hello(1);
hello("привет");

уже работать небудет

Пришлось бы вводить в язык перегрузку функций и получилось бы что то вроде.

function hello(d:int){
   console.log(d);
}
function hello(d:string){
   console.log(d);
}

hello(1);
hello("привет");

нифига некамельфо.

вот поэтому я и говорю что статическая + динамическая - это гуд.
А только у статической и только динамической немало недостатков.

DjDiablo,
Приведение типов перед передачей в функцию не решит проблему?

NaCl, я думаю, порвет здесь любой язык.Лично я совершенно не вижу преимуществ статической типизации. В крайнем, если она мне, вдруг, понадобится, я буду использовать дескрипторы, отлавливая получаемый тип. Что-то типа:

Object.defineProperty( Object.prototype, 'defineInteger', {
	value: function( key, value ) {
		Object.defineProperty( this, '_' + key, {
			value: parseInt( value ) || 0,
			enumerable: false,
			writable: true
		});
		Object.defineProperty( this, key, {
			get: function() {
				return this[ '_' + key ];
			},
			set: function( value ) {
				var parsed = parseInt( value );
				if( value !== parsed ) {
					throw Error( 'Key "'+key+'" must be an integer, fuck off, motherfucker' );
				} else {
					this[ '_' + key ] = value;
				}
			}
		});
	},
	enumerable: false
});

o = {};
o.defineInteger( 'myInt', 333 );
console.log( o.myInt );
o.myInt = 444;
console.log( o.myInt );
o.myInt = 'valera';

Нужно только немного подождать сметри ИЕ8.
Производительность здесь, конечно, херовая, но, мне кажется, задачи, где реально требуется статическая типизация с высокой производительностью, настолько редки, что ими можно пренебречь. Если уж хотите быстроты, параллельте приложение с помощью воркеров. Еще раз попеарю небольшую поделку: https://github.com/finom/Functions/t...r/InlineWorker

решит, но ведь для этого придётся приводить :D, пусть лучше компилятор этим вместо меня занимается

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

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

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

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

function getTitle( $dom ){
    so_dom::ensure( $dom );
    return (string) $dom->select(' / html / title ');
}

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

Входная переменная $dom - у тебя нетипизированная, естественно ты можешь передать в функцию что угодно

вот только вызвать метод select я могу не у чего угодно. so_dom::ensure собственно и гарантирует, что $dom будет поддерживать интерфейс so_dom со всеми его соглашениями.

понял, забавно.

как насчёт

interface idom {
    function select(string $bla);
}

function a(idom $dom) {
    
}

неа ?

строку или массив так не передашь..

конечно нет :)

В обсуждаемой теме имеются в виду типизированные переменные (то бишь единичные, атомарные данные), а для канвасов и пр. можешь использовать типизированные массивы и воркеры. В чем проблема-то? Или ты думаешь, что заменив
for( var i = 0; ... )
на
for( int i = 0; ... )
производительность сильно улучшится?

это какая-то статическая типизация времени выполнения

Если будешь везде указывать типы, я думаю улучшится. В видео должно было упоминаться, не помню точно. Зачем по-твоему Google решили пересоздать javascript?

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

Итого, статическая типизация вам нужна, чтобы: 1) быстро обнаруживать часть ошибок за счет проверки типов во время компиляции или выполнения (tenshi, DjDiablo), 2) повысить производительность (DjDiablo). И то, складывается впечатление, что как-то слабо нужна.

Попробую своими словами объяснить, зачем нужна статическая типизация. Вы предоставляете больше информации компилятору (и всяким инструментам) и в результате получаем: 1) удобство разработки (удобная навигация по коду, поиск, место объявления, использования, подсказки, автодополнение, рефакторинг), 2) производительность. Для несложных проектов (нечеткая граница) это конечно же не важно. Лично меня в первую очередь интересует поиск по коду с учетом синтаксиса ЯП.

... или давайте переформулирую вопрос так: зачем вам нужна статическая типизация, м? :)

Мне проще производить отладку. Да и количество ошибок должно быть меньше. Остальное мне до лампочки.

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

Ну вот и я о том же. Типизация нужна, как правило, на большиз объемах данных, а для этого есть специальны массивы.Захотелось, не? Каждый язык имеет свои недостатки, яваскрипт в том числе. Но полностью переделывать язык (отсутствие поддержки литералов объектов без кавычек, совершенно другие имена методов...) — глупо. Взяли бы, да новые версии ES реализовали (если я не ошибаюсь, там где-то были статические типы).

Не знаю почем они выбрали слово Guard для Contacts, но идея не плохая.

Кстати контракты уже реализованы в одном из диалектов CoffeeScipt - contracts.coffee

А гварды, для меня это, вот (пример из LiveScript):

state = | 1 => 'true'
        | _ => 'false'

Я писал в общем, больше про организацию кода, нежели про быстродействие.

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

Самый быстрый способ выполнить javascript это преобразовать его в машинный код и скормить процессору. В хроме насколько я знаю так и происходит.

возьмём пример на js
a=a+b;

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

mov eax,a ;//Перемещаем в eax, значение из a
mov edx,b ;//Перемещаем в edx значение из b
add eax,edx ;//складываем значения

А если нетипизированы то что делать ?
процессор то только с регистрами умеет операции выполнять, а про нетепизированные переменные он слыхом неслыхивал :D

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

//в al- значение символизирующее тип обоих переменных (пусть для простоты примера он общий для обоих переменных)
// если тип =1 тогда перейдём к метке sumvar
cmp al, 1
jz sum_var

// если тип =2 тогда перейдём к метке sumstring
cmp al, 2
jz sum_var

//подпрограмма сложения целых чисел
sumvar:

jmp next_step

//подпрограмма сложения строк
sumstring:

jmp next_step

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

если уж переделывать, то почему не привести все в порядок?

monolithed,
Увы, незна ни CoffeeScript, ни LiveScript. JSа хватаем по самые уши :) Но TypeScript интересно. Когда буду писать для win8, тогда наверно и попробую.

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

А что не так-то? Разве так удобнее

x = {
  'a':1,
  'b':2
}

чем

x = {
  a:1,
  b:2
}

?
Да и методы зачем переписали? Имена классов? Что с ними не так?

Несколько примеров отсюда:
http://synonym.dartlang.org/

console.log('Level completed.'); → print('Level completed.');

Зачем? Ну то ладно.

Якобы ничего → final name = 'Bob';

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

new Array(); → new List();
a.push('donut'); → a.add('donut');

Зачем?

a.pop() → a.removeLast()

Да, это выглядит несколько логичнее, но, опять же, зачем?

numbers.sort(function(a, b) {
  return a - b;
});

→

numbers.sort((a, b) => a - b);

Молодцы, конечно, но это есть в ES (не помню, какой версии). Запилите, вместо того, чтоб херней страдать.

new Object(); → new Map();

Тот же вопрос.

var periodic = {
  gold: 'AU',
  silver: 'AG'
};
var periodic = {
  'gold': 'AU',
  'silver': 'AG'
};

→

var periodic = {
  'gold' : 'AU',
  'silver' : 'AG'
};

Идиотизм.

periodic.gold // == 'AU'
periodic['gold'] // == 'AU'

→

periodic['gold']

Не меньший идиотизм. Вообще нифига не удобно.

Якобы ничего → var fruits = new Set();

Set есть в ES, его поддерживает FF, он же легко реализуется ручками.

var queue = []; → var queue = new Queue();

И че это? Оптимизированные списки типа как в Прологе?

...
Тут еще масса негодования.

Дарт масдай. ES должен развиваться и реализовываться в Хроме, там и остальные потянутся (мелкософт, если мне не изменяет память, обосрала Дарт и не будет его поддерживать).

В TC39 состоит не только Mozilla, но и Microsoft, Apple, Opera и Google. Они развивают его. V8, один из первых кто поддерживает большинство эксперементальных фишек, не считая конечно SpiderMonkey.

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

Он настолько медленно реализовывается, что я прям хочу спать.

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

FINoM, ответ на часть твоих вопросов я уже приводил:
Например, касательно add/removeLast для массивов. На остальные - производительность.

Нет, ты здесь не угадал, речь не о приведении в порядок.

P.S. Мысли теряются на фоне эмоций. Чего ты так разнервничался?

а зачем им вообще заниматься?