Компания Google отпраздновала год с момента открытия (http://www.opennet.me/opennews/art.shtml?num=31991) языка программирования Dart публикацией (http://news.dartlang.org/2012/10/dart-m1-release.html) первого релиза проекта. Dart (http://www.dartlang.org/) позиционируется как язык структурированного программирования для Web, который в долгосрочной перспективе может стать прогрессивной заменой JavaScript, решающей имеющиеся в настоящее время проблемы с расширяемостью, производительностью и поддержкой разработки сложных приложений. Язык обладает похожим на Java синтаксисом, не требует явного определения типов и может использоваться для создания серверных и клиентских приложений.
Отмечается, что за год существования открытого проекта было исправлено большое количество ошибок и недоработок, что позволило сформировать первый стабильный и функциональный выпуск, готовый для повсеместного использования. По сравнению с первоначальным вариантом языка в представленном выпуске Dart отмечается (http://www.dartlang.org/articles/m1-language-changes/) большое число улучшений и изменений, подготовленных на основе отзывов и анализа эффективности. В будущем улучшение языка будет продолжено, но на уровне оттачивания и оптимизаций, не нарушающих обратную совместимость. Из главных планов также отмечается продолжение развития SDK, проведение работы по увеличению надёжности и производительности.
Для упрощения разработки с использованием Dart новый выпуск оформлен в виде SDK (http://www.dartlang.org/docs/sdk/), включающего в себя компилятор dart2js (http://www.dartlang.org/docs/dart2js/), виртуальную машину Dart VM (http://www.dartlang.org/docs/standalone-dart-vm/), пакетный менеджер pub (http://pub.dartlang.org/) и набор библиотек. Для выполнения и отладки приложений на языке Dart, без компиляции в JavaScript, распространяется Dartium - сборка браузера Chromium с интегрированной виртуальной машиной Dart VM. Дополнительно доступен (http://www.dartlang.org/downloads.html) расширенный пакет Dart Editor (http://www.dartlang.org/docs/editor/), в который помимо SDK и Dartium включена специализированная среда разработки на языке Dart.
<center><a href="http://1-ps.googleusercontent.com/x/s.dart-lang.appspot.com/... src="http://www.opennet.me/opennews/pics_base/0_1350459412.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>Среди новшеств, представленных в первом выпуске Dart SDK:
- Высокопроизводительная виртуальная машина Dart VM, в некоторых тестах Octane (https://developers.google.com/octane/) опережающая JavaScript-движок V8. При запуске Dart-приложений внутри виртуальной машины планируется обеспечить производительность выполнения близкую к компилируемым в машинный код языкам;
- Новый компилятор для трансляции кода с языка Dart в представление на языке JavaScript, способное работать во всех современных браузерах; Новый компилятор отличается генерацией быстрого и компактного JavaScript-кода;
- Универсальная библиотека (http://api.dartlang.org/docs/continuous/dart_html.html) для обработки и генерации HTML-контента, работающая во всех браузерах;
- Библиотека (https://github.com/dart-lang/js-interop) для обеспечения взаимодействия с кодом на языке JavaScript;
- Редактор кода (http://www.dartlang.org/docs/editor/getting-started/), обладающий возможностями современных IDE;
- Новый пакетный менеджер Pub (http://pub.dartlang.org/), позволяющий работать с репозиториями модулей и библиотек на языке Dart;
- Dartium (http://www.dartlang.org/dartium/) - сборка Chromium со встроенной поддержкой Dart;
- Серверная библиотека (http://api.dartlang.org/docs/continuous/dart_io.html) для организации воода/вывода;
- Документация и спецификации (http://www.dartlang.org/docs/spec/) с описанием семантики и возможностей языка.Особенности языка Dart:
- Привычный и простой для изучения синтаксис, естественный для программистов на JavaScript, Си и Java.
- Обеспечение быстрого запуска и высокой производительности для всех современных web-браузеров и различных типов окружений, от портативных устройств до мощных серверов;
- Возможность определения классов и интерфейсов, позволяющих использовать инкапсуляцию и повторно использовать существующие методы и данные;- Необязательное указание типов, использовать или нет статические типы решает разработчик. Указание типов позволяет упростить отладку и выявление ошибок, делает код более ясным и читаемым, упрощает его доработку и анализ сторонними разработчиками.
- Среди поддерживаемых типов: различные виды хэшей, массивов и списков, очереди, числовые и строковые типы, типы для определения даты и времени, регулярные выражения (RegExp). Возможно создание своих (http://www.dartlang.org/articles/optional-types/) типов;- Для организации параллельного выполнения предлагается использовать классы с атрибутом isolate, код которых выполняется полностью в изолированном пространстве в отдельной области памяти, взаимодействуя с основным процессом через отправку сообщений;
- Поддержка использования библиотек, упрощающих поддержку и отладку больших web-проектов. Сторонние реализации функций могут подключаться в виде разделяемых библиотек. Приложения можно разбить на части и поручить разработку каждой из частей отдельной команде программистов;- Набор готовых инструментов для поддержки разработки на языке Dart, включая реализацию средств динамической разработки и отладки с исправлением кода на лету ("edit-and-continue");
- Возможность создавать однородные системы, охватывающие как клиентскую, так и серверную часть. Использование одного языка и инструментария для клиентских и серверных компонентов упрощает процесс кодирования и избавляет от постоянной смены контекста.
URL: http://news.dartlang.org/2012/10/dart-m1-release.html
Новость: http://www.opennet.me/opennews/art.shtml?num=35102
Потыкал его. Довольно вкусная штука. Хотя как по мне был сыроват малясь. Например регулярки работали только в построчном режиме и игнорировали параметр multiLine: true. Посмотрим что будет в релизе.
Ну дык, все впереди.
Как же Гугл обожает Яву)
> Как же Гугл обожает Яву)И это хорошо
И именно гуугл мы должны благодарить за то что в java до сих пор нет ни замыканий ни инференции типов.
> И именно гуугл мы должны благодарить за то что в java до
> сих пор нет ни замыканийВы наверно да, если вас там забанили и вы не можете узнать, что замыкания в жаве таки есть.
> ни инференции типов.Однажды сетовал на это пока не понял, что пытаюсь почесать левое ухо правой ногой. Возможно есть случаи когда это критично, но я таких не придумал.
>что замыкания в жаве таки есть.Нет. или вы про кривенький рерайт который делает javac под названием "анонимный класс"?
Я вас прошу.
Реализуйте ка это
//scala
var sum:Int = 0
val array:Array[int] = Array(1,2,3,42)
array.foreach((x)=>sum+=x)
assert(sum == 48)//javascript
var array = [1,2,3,42]
var sum = 0
array.map(function(x){sum+=x})
console.log(sum) //48
>>что замыкания в жаве таки есть.
> Нет. или вы про кривенький рерайт который делает javac под названием "анонимный
> класс"?Есть, остальное вопрос реализации.
> Я вас прошу.
> Реализуйте ка это...
> //javascript
> var array = [1,2,3,42]
> var sum = 0
> array.map(function(x){sum+=x})
> console.log(sum) //48
>
int[] array = new int[]{1,2,3,42};
int sum = 0;
for (int x : array){sum+=x;}
assert sum == 48;
И?
> int[] array = new int[]{1,2,3,42};
> int sum = 0;
> for (int x : array){sum+=x;}
> assert sum == 48;И где вы тут, конкретно, видите замыкание?
Замыкания
http://en.wikipedia.org/wiki/Closure_(computer_science)
Где вы видите необходимость в замыканиях в этом куске кода?
Совершенно нигде.
Но и нет никакой необходимости в который раз приветствовать мир так?
int sum = 0
val sumattor = (x:Int)=>sum+=xval list1 = List(1,2,3)
val list2 = List(4,5,6)
val Set1 = Set(2,3,9)
//... добрая сотня разных листов сетов последовательностей которые надо просумироватьlist1.foreach(sumattor)
...
list999.foreach(summator)
Set1.foreach(summator)
// а вы будете писать сотню циклов? Удачи не ошибится, и не написать sum=x вместо sum+=x в 75 раз.
И больше мы можем вернуть этот сумматор из функции и продолжать накапливать значения из разных модулей библиотек и процедур.
> И больше мы можем вернуть этот сумматор из функции и продолжать накапливать
> значения из разных модулей библиотек и процедур.Собственно сумматор в лоб заменяется на Интерфейс + анонимная реализация. И работает и " больше мы можем вернуть этот сумматор из функции и продолжать накапливать значения из разных модулей библиотек и процедур"
Причем на таком коде разница в синтаксисе будет минимальна.
Вот только не надо код пересказывать своим словами, я вас умоляю.
Продемонстрируйте.
class Summator{
int sum;
void add(Iterable<Integer> list){
for (int i : list){
sum += i;
}
}
}хотя куда проще
static int function(Iterable<Integer> list){
int sum = 0;
for (int i : list){
sum += i;
}
return sum;
}
Все еще не вижу замыканий.
И да, ваш код не эквивалентен моему. У меня аккумулятор внешний и не доступен вызывающей стороне.У вас вообще нет инкапсуляции sum.
То есть надо минимально
public class Summator{
private int sum;
public int getSum(){
return sum;
}public void add(Iterable<Integer> list){
for (int i : list){
sum += i;
}
}
}
Вы все еще не видите преимущества замыканий? Напомню
val f = (x:Int)=>sum+=x
Всё ещё считаете что тут _необходимы_ замыкания?Я давно прошу привести пример, где:
1. Без замыкания не обойтись, либо код с замыканием на порядок проще и понятнее чем альтернативный путь
2. Анонимный класс проблему либо не решает либо код слишком сложен и непонятен.
Вместо этого мне предлагают просуммировать массив. Вас что, на замыканиях замкнуло? Кофе по утрам тоже через замыкания пьёте?
А я вас который раз прошу привести доказательства что в java замыкания вообще есть. Хотя бы на суммировании массива.
1. Без замыкания не обойтись
Так как брейнфак тоже полон по Тьюрингу следует что можно обойтись без любый "фишек" языка. Достаточно сложения вычитания и получения и установки значения.
Вы сверху видели что задача решающаяся одной строкой через замыкания решается у вас 12 строками. Причем ваше решение неверно.
>А я вас который раз прошу привести доказательства что в java замыкания вообще естьналичие анонимных классов в жаве вы сами упомянули, какие ещё доказательства вам нужны?
>1. Без замыкания не обойтись
У меня было
>1. Без замыкания не обойтись, либо код с замыканием на порядок проще и понятнее чем альтернативный путьИспользование класса для сложения элементов массива - это вообще подход за гранью добра и зла. Тем более что задача надуманна.
Если все ваши аргументы сводятся к тому что на жаве нельзя написать val f = (x:Int)=>sum+=x, то я не могу возражать, синтакис этого действительно не позволяет. И что вы мне пытаетесть доказать в этом случае?
Анонимные классы не замыкания. Замыкания не анонимные классы.
Я выше привел задачу которую можно решить замыканиями но нельзя решить с помощью анонимных классов.
>Использование класса для сложения элементов массива - это вообще подход за гранью добра и зла. Тем более что задача надуманна.Вы либо можете решить задачу заданными средствами или нет. Вы ратовали за существование полноценных замыканий в java вот и докажите это решив вышеприведенную задачу. А то подход на уровне пятого класса -"Я теорему Пифагора доказывать не буду - задача надуманная!"
>Анонимные классы не замыкания. Замыкания не анонимные классы.Согласен, замыкание это функция внутри анонимного класса
>Я выше привел задачу которую можно решить замыканиями но нельзя решить с помощью анонимных классов.Выше вы привели задачу которую нет смысла решать на жаве с помощью замыканий. Чтобы понять почему, можете почитать про использование жавовских коллекций в скале. Что бы сдублировать ваш код необходимо как минимум писать свою реализацию листа.
>Вы ратовали за существование полноценных замыканий в java вот и докажите это решив вышеприведенную задачу
Можете считать замыкания в жаве неполноценными, ибо нельзя написать val f = (x:Int)=>sum+=x.
> Однажды сетовал на это пока не понял, что пытаюсь почесать левое ухо
> правой ногой. Возможно есть случаи когда это критично, но я таких
> не придумал.Это совершенно не критично. Это намного хуже, это неудобно.
Был когда то такой язык КОБОЛ. Он был весьма недружелюбен к программистам. Отчего и умер.
> Это совершенно не критично. Это намного хуже, это неудобно.Что именно неудобно?
Много писанины, которая что характерно совершенно бессмысленна
import java.util.ArrayList;
public class App{
public static void main(String[] args){
ArrayList<Integer> list =new ArrayList<Integer>();
wtf(list);
Integer wtf = list.get(0); // ошибка времени исполнения
}
private static void wtf(ArrayList a){ //популярнейшая ошибка, от которой должна защищать система типов... но
a.add("Wtf"); // компилируется на ура
}
}
И на хрена я ТРИ раза писал Integer ? У javac память как у мартышки?
> И на хрена я ТРИ раза писал Integer ?private static void wtf(ArrayList a) { // здесь
a.add("Wtf"); // и сдесь компилятор выдает ворнинги
System.out.println("нахрена ты их не читаешь?");
}
То есть все что смог выдавить из себя компилятор после того как я ТРИ раза написал тип - это не фатальный "ворнинг"? Я кстати открою страшный секрет - эти "ворнинги" никто не читает, в доказательство погуглите "eclipse" "class cast exception" или замените эклипс на ваш любимый продут на java.
ракалицо.Но я понял, что вам даёт жаваскрипт и особенно отсутствие типизации - возможность написать любую хрень, которая будет делать вид что работает.
Я вам рекомендую Scala - статически(в отличие от java) типизированный язык. В статически типизированном языке писать типы совершенно не обязательно. Они никуда не денутся, никто не сотрет.
import scala.collection.mutable._
val list = MutableList(1,2,3)
list += 4 // ок
list += "f" // никогда, ни под каким видом не компилируется.
> Я вам рекомендую Scala - статически(в отличие от java) типизированный язык. В
> статически типизированном языке писать типы совершенно не обязательно. Они никуда не
> денутся, никто не сотрет.
> import scala.collection.mutable._
>
> val list = MutableList(1,2,3)
> list += 4 // ок
> list += "f" // никогда, ни под каким видом не компилируется.
>Приведённый кусок никаким боком не пересекается с тем что на пару постов выше ибо
ArrayList<Integer> foo = new ArrayList<Integer>();
foo.add("bar");
тоже ни разу не компилируется
А приведенный кусок изобразить на скале не получится, ввиду статической типизации.
> Приведённый кусок никаким боком не пересекается с тем что на пару постов
> выше ибо
> ArrayList<Integer> foo = new
> ArrayList<Integer>();
> foo.add("bar");
> тоже ни разу не компилируетсяДа ладно вы просто не умеете готовить кофе.
ArrayList<Integer> foo = new ArrayList<Integer>();
ArrayList bar = foo;
bar.add("wtf")
и потом
$maven compile && maven deploy
и пусть весь мир подождет.
двойной рукалицоещё можно написать throw new RuntimrException();
только ответа на вопрос я так и не получил
>Что именно неудобно?
> ещё можно написать throw new RuntimrException();можно. но когда так пишут то они явно хотят выкинуть RuntimeException. А когда пишут тип хотят что?
>Что именно неудобно?Заходит джавист в столовую и говорит “Паблик статик файнал Борщ борщ нью Борщ, пожалуйста”.
> когда пишут тип хотят что?А когда пишут явно нерабочий код чего хотят?
>Заходит джавист в столовую и говорит “Паблик статик файнал Борщ борщ нью Борщ, пожалуйста”.
Петросян в треде?
> А когда пишут явно нерабочий код чего хотят?А код
ArrayList bar = foo()
не рабочий? Он работает прекрасно. Пока...
>Петросян в треде?А вы не из его аудитории? Тогда к чему вы употребляете "мемы"?
> А код
>
> ArrayList bar = foo()
>
> не рабочий? Он работает прекрасно. Пока...Так же как и c = a / b;
> И именно гуугл мы должны благодарить за то что в java до
> сих пор нет ни замыканий ни инференции типов.Как если бы их грокали в MS.
require("traslator")
А у МС в этом плане все хорошо. Можно не любить платформу, но с точки зрения языка c# намного приятней java. Java малость устарела.
> require("traslator")
From Jargon File (4.3.1, 29 Jun 2001) [jargon]:grok /grok/, var. /grok/ vt. [common; from the novel "Stranger in a
Strange Land", by Robert A. Heinlein, where it is a Martian word meaning
literally `to drink' and metaphorically `to be one with'] The emphatic
form is `grok in fullness'. 1. To understand. Connotes intimate and
exhaustive knowledge. When you claim to `grok' some knowledge or
technique, you are asserting that you have not merely learned it in a
detached instrumental way but that it has become part of you, part of
your identity. For example, to say that you "know" {LISP} is simply to
assert that you can code in it if necessary - but to say you "grok" LISP
is to claim that you have deeply entered the world-view and spirit of
the language, with the implication that it has transformed your view of
programming. Contrast {zen}, which is similar supernal understanding
experienced as a single brief flash. See also {glark}. 2. Used of
programs, may connote merely sufficient understanding. "Almost all C
compilers grok the `void' type these days."[/grok]> А у МС в этом плане все хорошо.
В том-то и дело, что нет. Очередное временно успешное наведение иллюзии при неглубоком относительно предшественников понимании предмета. Это разве что для мигрантов с вижуал-басика новые глубины...
Возможно с точки зрения идеи, не знаю что было в головах авторов при создании. Но вот реализация - кошмар.
конечно, первые версии их паука были написаны как раз на Java
К сожалению сейчас они перешли в отношении к java в режим "Хватать и не отпускать". И медленно, но верно, превращают java в новый COBOL.
Java с самого начала была "новым коболом". И там, и там ориентировка на загадочный "энтерпрайз"; и там, и там отсутствие любого намёка на краткость. Разница только в том, что Java — C-like, а COBOL — нет.
И тем не менее на скриншоте мы видим что-то похожее на православную сишечку.
> на скриншоте мы видимбогопротивный эклипс, который ухитряется тормозить на всем, что только смог изобрести человеческий разум.
Тормозят не ЯП и не IT-системы. А лишь мозги программёров и сисадминов.
К эклипсу это не относится.
>богопротивный эклипсОтличная среда в которой можно разрабатывать под android к примеру на любой платформе - под линем и маком отлично работает. А что вантуз кросплатформенного может предложить?
> который ухитряется тормозить на всем, что только смог изобрести человеческий разум.Отлично, буду знать что core-i7 3770k изобрели пришельцы. Как и core2-duo
>Отлично, буду знать что core-i7 3770k изобрели пришельцыНу слава богу, процессор всего за 500$ долларов равный по мощности всем вычислительным системам в США в 1980 году может тянуть без торможений, этот, по сути, текстовый редактор.
Срочно пошел копить.
>>Отлично, буду знать что core-i7 3770k изобрели пришельцы
> Ну слава богу, процессор всего за 500$ долларов равный по мощности всем
> вычислительным системам в США в 1980 году может тянуть без торможений,
> этот, по сути, текстовый редактор.
> Срочно пошел копить.Удивительно но факт http://www.opennet.me/opennews/art.shtml?num=34779. И я уже наблюдал горемыку который не читал новостей
> Удивительно но факт http://www.opennet.me/opennews/art.shtml?num=34779. И я уже наблюдал
> горемыку который не читал новостейТо есть для 4.2 этого уже мало? Кстати, версией 4 2 они видимо намекают на ту машину которая на лучшем доступном человечетву оборудовании считала ответ на вопрос несколько миллионов лет?
Не вижу в чем dart _существенно_ лучше, чем javascript.
Быдлокодеры просто прототипное ООП осилить не могут.
CoffeeScript, Dart, TypeScript...
> Быдлокодеры просто прототипное ООП осилить не могут.Откуда вас, адептов, столько развелось? Вы не думали что люди не против прототипной модели — она замечальная. Но вот её реализация в JS, к сожаленью, убога, как и многое другое в этом языке.
Впрочем, если нравится — пользуйтесь, чем бы дите не тешилось. Но согласитесь, что от наличия альтернативы хуже точно не станет.
Мне многое не нравится в реализация JavaScript.
Но изобретать dart/*script проблему не решит.
С таким же успехом можно пробовать HTML заменить. XHTML 2.0 тому доказательство.
С JS все в порядке. Node.js это явно доказал. А если "use strict" то вообще все отлично.
DOM другое дело.
node.js доказал только то что желание передавать функции в качестве аргументов других функций ни к чему хорошему не приводит.
Каким же образом он это доказал?
> Каким же образом он это доказал?Ну если посмотреть на проекты, которые на нём сделаны то станет понятно что 20% можно было сделать на чём либо более подходящем, но ведь только жаваскрипт позволяет написать foo(new function(){...}, new function(){...})
А остальные 80% просто потому что жаваскрипт позволяет написать foo(new function(){...}, new function(){...})
Да многие проекты на нем пишут из за того? что на js можно писать foo(new function()...).
Это, кстати, называется continuation passing и являлось предметов зависти программистов на других языках к Common Lisp на протяжении многих лет. Реализация на js не самая идеальная, но лучше чем например рубиновый callcc.
> Да многие проекты на нем пишут из за того? что на js
> можно писать foo(new function()...).
> Это, кстати, называется continuation passing и являлось предметов зависти программистов
> на других языках к Common Lisp на протяжении многих лет. Реализация
> на js не самая идеальная, но лучше чем например рубиновый callcc.Проблема в том, что почитатели ноджс чситают это единственно возможным способом писать код.
И превращают свои творения в нечитабельный кошмар. А завязка на ноджс делает большинство проектов практически бесполезными.
Когда кто то говорит что это дизайн языка заставил его писать плохой код он малость лукавит. Да и не намного вложенные функции хуже вложенных if или switch
Полюбуйтесь
Foo_state do_foo(Bar bar,Foo_state foo)
{
switch(foo)
{
case foo_none: //start
switch(bar)
{
case bar_stuff:
//do stuff
return foo_none;
case bar_other:
//do other stuff
return foo_again;
case foo_again: //!! this doesn't work
/* edit: this is supposed to be a case of
* switch(foo), not switch(bar)
*/
//do more other stuff
return foo_none;
default:
//stuff
return foo_none;
}
default:
//fail
return foo_error;
}
}
http://stackoverflow.com/questions/1978202/c-nested-switches...
> Полюбуйтесь…как человек активно не хочет упрощать себе жизнь, ваяя на чистых сях то, что следует делать при помощи простого кодогенератора (это же машина состояний у него, которую разумней всего генерировать каким-нибудь скриптом из внятного описания).
полюбовался. некоторых людей лучше не подпускать к сложной технике.
Ваше заявление позволяет с уверенностью предположить, что на вашей рабочей системе (Windows XP) установлен официальный ICQ-клиент.
Он проще, понятнее и позволяет решать чуть большее количество задач. А когда для решения задачи есть более простой способ, то использовать будут его. Зачем осиливать прототипное ООП, функциональное программирование и другие сложности, если задачу можно решить проще (а значит дешевле и надежнее)? Поэтому сложные технологии - удел маргиналов, которые гордятся своей непохожестью на других, дискредитируют плебеев, неосиливших ТЕХНОЛОГИЮ и для решения простых задач используют мегасложные вещи, потому что это круто.
>Он проще, понятнееКто? Это "классы" то проще?
>Зачем осиливать прототипное ООПЗачем осиливать компьютер когда лопата проще. Ну действительно, не мучайте себя.
>функциональное программирование и другие сложностиФункциональное программирование - сложно? А азбука для вас не сложна?
Оно значительно проще ООП, которое в jave выродилось в КПП(Классо Ориентированное).
>Зачем осиливать компьютер когда лопата проще.Ну кстати, если проблему можно решить как лопатой, так и компьютером — я выберу лопату однозначно.
Оно и для здоровья полезнее...
Проблему зарабатывания денег можно решить и лопатой.
> Проблему зарабатывания денег можно решить и лопатой.Нда? Это как - заработать миллионы, копая траншеи? Или лопатой баблище грести? :)))))
Да. Классы проще. На больших проектах - особенно. Потому что они при очень небольших усилиях держат архитектуру проекта обозримой. Они дают некую самодокументируемость - если я передаю функции объект класса Circle это отнюдь не то же самое, что сунуть ей нечто, в чем есть члены x, y и r. Функциональщина в этом смысле ещё хуже - там сущности какие-то совсем нечеловеческие получаются.
> Да. Классы проще.Только потому как большинство и не знает альтернатив.
DSL-s кстати еще проще.> На больших проектах - особенно.
Хреново они себя показывают на больших проектах. Когда у тебя 400 классов до глубины в 9 уровней наследования понять как работает хоть что то - не реально.
Противоположность еще хуже. Класс User на 3500 loc который:
- формирует html личной страницы пользователя
- создает sql и записывает себя в базу
- включает все возможные и невозможные свойства пользователя, включая лог всех его посещений
- реализует 19 интерфейсов
- и много всего другого ...
И это реальность. Знаете как забавно играть в игру - "Угадай, что сломается если изменить формат .toString()"
>Потому что они при очень небольших усилиях держат архитектуру проекта обозримой. Они дают некую самодокументируемость если я передаю функции объект класса Circle это отнюдь не
> то же самое, что сунуть ей нечто, в чем есть членыВы путаете ООП c типизацией. Они никак не связаны.
> Функциональщина в этом смысле ещё хуже - там сущности какие-то совсем нечеловеческие получаются.Признайтесь, "Функциональщина" вы упомянули ради красного словца.
А классы - это, осбственно, и есть такой DSL - определяем объекты и клеим их средствами языка. Тьюринг-полного, навороченного, с кучей возможностей, в отличие от большинстваИ если кто-то ваяет гору уровней наследования - то это либо с гловой плохо либо бедный язык вроде Джавы, на котором иначе не сделать. Собственно, наследование - штука вообще довольно редко нужная, а уж 9 уровней - это дикость. Впрочем, класс-помойка еще хуже. Как раз потому что эти 9 уровней - оно жуть, конечно, но оно логично, можно понять, что мы за сущность в данный момент обрабатываем, и сделать над собой что-то недопустимое эта сущность не даст.
А ООП и типизацию я не путаю. Ну да, можно ввести в JS просто структуры - но тогда получим только половину плюшек - поля у нас будут, а что с полями делается - не документировано ни разу. Продолжая мой пример - есть разница между arg.x = 1; arg.y = 2 и circle.moveTo(1,2)
Что касается ФП - оно хорошо внутри императивного языка, какая-нибудь односточная обработка с map или чем-то подобным. И то foreach часто читается получше. А если на хаскеле каком большую софтину писать - то я это читабельным никак не назову. Онять же - последовательность операций для человеческих мозгов привычна и понятна, можно каждый кусок по отдельности читать, и пишутся они по отдельности. А вот формулу приходится самостоятельно мысленно рвать на какие-то части, разбираться, какой конкретный смысл имеет в данном случае общая конструкция и т.п.
У вас класический батхерт программиста на Блаб -е. Просто в рамочку и на стену вешай.
"Представим себе Блаб - средненький язычок, расположенный посрединке линейки языков. Не самый мощный, но уж помощнее чем машинный код и 1с.
Наш, гипотетический, программист на Блабе уж конечно не будет писать на машкоде, для этого ведь придумали компиляторы, так? Что до 1с, то он не знает как на 1с можно написать хоть что то, ведь там нет X(объектов, классов, полиморфизма - вставьте "фичу" Блаба на свой выбор)
И вот болтаясь в середине вселенной языков, наш программист смотря вниз прекрасно понимает что он смотрит вниз. Языки ниже явно слабее чем Блаб, ведь они не имеют возможностей к которым он привык. Но когда гипотетический Блаббер смотрит в обратном направлении он не понимает что он смотрит вверх. То что он видит это весьма странные языки. Он считает их по мощности равным Блабу, но но с добавлением неведомой фигни. Блаб -а ему достаточно, так как он мыслит категориями Блаба.
Но когда(если) он переключается на язык более мощный, он с удивлением обнаруживает что
смотрит на Блаб сверху вниз. И как на Блабе можно сделать хоть что нибудь, ведь там нет (Pattern matching, pure function, Монад... )?
Вот поэтому и нельзя доверять мнению программистов о языках. Ведь для них все языки кроме своего делятся на 1)Слабые 2)Странные.
http://en.wikipedia.org/wiki/Paul_Graham_(computer_programmer)#Blub
Цитатка забавная, но не обо мне. Я и на ассемблере пишу, и на D, который весьма странен и богат, и на перле, на котором можно накрутить почище JS. Но надо понимать, для какой области что имеет смысл использовать.Если у нас прошивка контроллера - то даже если пишем на сях в ассемблерный листинг глянуть придётся.
Если большая система - то нужен язык с мощной системой типов и модульностью. Причём всё это должно быть в языке или в карйнем случае в стандартной бибилиотеке, чтобы все используемые библиотеки использовали один подход, а не эмулировали нужные средства десятком способов. Потому что здесь важны разнообразные автоматические проверки, то есть семантика должна быть явно дана машине. Отсюда типизация, классы, приватные члены и т.д.
А "более мощные языки" - это обычно полигон для обкатки новых возможностей, которые потом приходят в мейнстрим, как было с делегатами, лямбдами, итераторами, классами и многим другим. Но писать продакшн на этом - увольте. Второе применение таких языков - развитие программиста. Но тут, кстати, выгодно брать, грубо говоря, не Haskell, а Scala или D - больше разных концепций, можно посмотреть, как они взаимодействуют и как стыкуются с уже существующими мейнстримными возможностями.
> Но писать продакшн на этом - увольте.Надо будет adept@ рассказать -- он к нам подумывал, но решил, что ninja team хаскелятников интересней, чем скучный продакшен на эрланге ;-) А другой коллега участвовал в лисповой части orbitz.com.
Порой такая боязнь функциональщины у тех, кому не повезло с учителями математики и в частности алгебры. Вот только нет смысла пытаться к императивному языку приматывать изолентой трофейные заплатки, если всё равно оторвутся или в лучшем разе будут странновато смотреться... а если и приматывать, так для сколь-нибудь разумного применения помогает понимать, как оно в естественных условиях работает.
Отчасти на том основана и шпилька в адрес некрософта была.
Не знаю, может где-то что-то живое на функциональщине пишут, но я не видел. Максимум - эрланг, который хорош, в общем-то, как клей для нативных модулей в распределённой среде либо на софт вида "решил откуда взять и куда положить, а дальше работаешь трубой". Какие-либо обработки на нём делать себе дороже - тормозной. Ну и синтаксис у него с чудесами - одни records чего стоят. Я на нём пишу чуток, если что;-)И нелюбовь не из-за математики, а из-за того, что ФП не даёт разбить логику на удобные блоки, отражающие сущности, с которыми работают - ну по другим принципам там раздиение получается.
А лисп - это отдельная песня. Может, он только для меня совершенно нечитабелен, но, IMHO, лучше иметь специализированные конструкции из коробки, чем лисповскую общность - их и опознаёшь в коде быстрее, и понимают их одинаково все, кто знает данный язык, и инструменты лучше работают с ними, и готовын шаблоны применения и подводные камни известны и описаны.
И насчет "заплаток" вы зря, объединяется оно хорошо,самое очевидное - closures, делегаты, лямбды, map/reduce (по факту - то же паттерн Visitor) - всё это отлично улеглось в императив и стало абсолютной нормой для любого современного языка. Собственно, именно в императиве, когда у нас есть состояние, те же делегаты куда интереснее, чем в ФП функции как параметры. Кое-где также спокойно живут nullable типы, immutable variables...
> [erlang] Какие-либо обработки на нём делать себе дороже - тормозной. [...]
> Я на нём пишу чуток, если что;-)Если циклами, то неудивительно. :)
> И нелюбовь не из-за математики, а из-за того, что ФП не даёт
> разбить логику на удобные блоки, отражающие сущности, с которыми работают -
> ну по другим принципам там раздиение получается.Странно, а мне как раз даёт. BTW порой даже на шелле писать удобнее именно из-за конвейера, который тоже своего рода гирлянда скобок...
> А лисп - это отдельная песня. Может, он только для меня совершенно
> нечитабелен, но, IMHO, лучше иметь специализированные конструкции из коробки,
> чем лисповскую общностьДело вкуса -- есть люди, которым проще идти от частного, иным же от общего. Когда код является данными в полной мере -- непосредственно пригодными для разбора -- порой это выручает куда больше, чем вычурные конструкции.
> - их и опознаёшь в коде быстрее, и понимают их одинаково все, кто знает данный язык,
> и инструменты лучше работают с ними, и готовын шаблоны применения и подводные камни
> известны и описаны.Да, это типичная индустриальная точка зрения. :) Вот только обиндусиваться не хочется.
> И насчет "заплаток" вы зря, объединяется оно хорошо, самое очевидное -
> closures, делегаты, лямбды, map/reduce (по факту - то же паттерн Visitor) -
> всё это отлично улеглось в императив и стало абсолютной нормой для
> любого современного языка.Есть люди, которые задачки в школе решали в символьном виде, а потом подставляли значения; а есть те, которые всё сразу решали в числах и функциями пользовались примерно как калькулятором. Так вот последние функций не понимают (зато конкретную задачку, если не ошибутся по дороге, могут решить порой и быстрей -- но вот на следующей аналогичной обычно начинают отставать).
Это не наезд ни в коей мере, а скорее напоминалка о том, что мы, по счастью, бываем разные :)
А в ответ приводишь классический баттхёрт функциональщика - "Я один пишу на самом лучшем языке, любой кто пишет на другом ущербен по определению". Понимаю что цитата, но хоть бы немного оригинальности.
Первое место в десятке js багов.
function Constructor(name, val){
this.hello = name;
this.bugs = val
}
var obj = Constructor()
Это не к тому, что прототипное наследование это плохо.
Плохо то как оно сделано в js.
Проблемы со зрением?
Так можно сказать "быдлокодеры brainfuck освоить не могут". Профита с этих прототипов как основного механизма? Код замусоривать там где можно написать class Foo{} ? То же что и крики "на лиспе можно любую объектную систему сделать и вообще что хотите". Ну можно, и что? На кой мне любая? Мне нужна конкретная, да так чтобы нужные конструкции легко писались, легко читались (то есть из коды выхватывались одним взглядом) и чтобы инструментя их понимали. И с JS то же самое - если чтобы сделать приватный член класса мне надо как-то извращаться - на кой оно надо, если в нормальном языке я просто пишу private и потом с одногов згляда вижу, что это?
Анекдотические претензии вида "Испанский язык отстой, потому что я его не знаю!"
Да жизнь рассудила уже. Когда ООП показало свои преимущества над чисто процедурным программированием - оно за считанные годы захватило свои позиции. А потом их слегка потеряло, что правильно. А функциональщики флагами уже лет сорок машут.Понимаете, "чистое" FP, как и любой другой "чистый" подход - это сектантство. А что нужно в реальной жизни показывает продакшн. И это смесь парадигм почти всегда - вон классы, вон шаблоны (которые могут быть функциональными, а могут и не быть), вон лямбда, вон класс-функтор, сохраняющий своё состояние, вон shared data, вон actor... вот тогда жить удобно. А когда правоверные начинают писать - то всегда выходит чудовище, будь это иерархия в 9 уровней, попытки избавиться от состояния и императивного кода любой ценой или писанина на C, где в результате получается эмуляция ООП.
> А что нужно в реальной жизни показывает продакшн.в реальной жизни нужно, чтобы слабообученая обезьяна могла делать лапшу. и могла бы быть без труда заменена другой аналогичной обезьяной.
впрочем, с усложнением проектов в них начинают проникать вещи, о которых раньше рассуждали «высоколобые». и в итоге всё как обычно: сначала «в продакшене это не надо», потом «в продакшене это иногда полезно», а потом — «как же можно вообще делать продакшэн без этого?!»
А что стало с языком "Go"?
А что с ним? Цветет и пахнет себе. Он какбэ немного из другой области.
Пахнет, да. Правда не цветет.
"Давайте все перепишем еще раз. На этот раз на GO!" - нет спасибо.
Кто-то кого-то заставляет переписывать что-то на Go?
Сам Google переписал уже почти полностью (а может уже таки полностью) YouTube с Python. Теперь им требуется в несколько раз меньше вычислительных серверов для выполнения тех же задач.
Go очень даже хорошо развивается. Людям очень нравится. Стоит только посмотреть на количество и качество (последнее - субъективно) библиотек для него, которые делает народ.
>Go очень даже хорошо развивается.Если под развитием понимается написание не совместимых версия, то да.
>Стоит только посмотреть на количество и качество (последнее - субъективно) библиотек для него, которые делает народ.Новый язык + бедная библиотека + NIH = "нужна библиотека - напиши сам"
"А для записи в Oracle мы будем использовать написанную Василием xXx4axoRxXx Пупкиным библиотеку с гитхабика. В твиторе сказали что она - отвал башки!"
Вы так говорите, как будто это плохо :)
А потом выяснится что Василий, начитавшись книги Hacker's delight, все действия с числами в своей библиотеке производит с помощью побитовых операций и сдвигов, но к сожалении еще не дочитал до главы "Числа со знаком". И поэтому все ваши должники магическим образом стали миллионерами.
Васи с гитхаба они такие.
>>Go очень даже хорошо развивается.
> Если под развитием понимается написание не совместимых версия, то да.
>>Стоит только посмотреть на количество и качество (последнее - субъективно) библиотек для него, которые делает народ.
> Новый язык + бедная библиотека + NIH = "нужна библиотека - напиши
> сам"
> "А для записи в Oracle мы будем использовать написанную Василием xXx4axoRxXx Пупкиным
> библиотеку с гитхабика. В твиторе сказали что она - отвал башки!"Вы явно не в теме, раз такое пишете. Хотя бы раз взгляните на стандартную библиотеку прежде чем такое писать.
На эту?
http://golang.org/pkg/
Очень куцая.
Анекдот - для языка который позиционируется и как язык для серверного web-а нет поддержки xpath.
Гораздо больше, чем стандартные для С/С++ даже последних стандартов. А с учётом того, что ему несколько лет, то это очень много. Из это СТАНДАРТНАЯ библиотека.
Моё мнение такого. Ваше я также понял, но советую подумать всё ли так плохо, как Вы считаете.
Сказать что ваша стандартная библиотека больше чем у С, это все равно что сказать что у вас мозгов больше чем у таракана.
Что по поводу с++, так размер стандартной библиотеки называется одним из главных недостатков языка, см выступление секретаря коммитета iSO по стандартизации с++ Саттера http://channel9.msdn.com/Events/GoingNative/GoingNative-2012... момента 1:16:00 +
То есть ваш подопечный уже обогнал безногого и одноногого спортсменов. Но если сравнивать с java EE и .NET то он сам тянет только на хромого.
*err
Day 2 Keynote - Herb Sutter: C++11 and Beyond
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
> Сказать что ваша стандартная библиотека больше чем у С, это все равно
> что сказать что у вас мозгов больше чем у таракана.
> Что по поводу с++, так размер стандартной библиотеки называется одним из главных
> недостатков языка, см выступление секретаря коммитета iSO по стандартизации с++ Саттера
> http://channel9.msdn.com/Events/GoingNative/GoingNative-2012...
> c момента 1:16:00 +
> То есть ваш подопечный уже обогнал безногого и одноногого спортсменов. Но если
> сравнивать с java EE и .NET то он сам тянет только
> на хромого.Java - 1995
C# - 2000
Посмотрим на библиотеку Go через 10 лет. Хотя бы.Off top: У Java/C# и С/С++ совсем разные точки зрения. Пример тому то, что в стандарт когда не хотел включать то, что сейчас называется стандартной библиотекой шаблонов.
Используйте ГО потому что через десять лет у него будет шикарная библиотека!
А у Java С# и Python, у которого, кстати, тоже библиотека больше, за 10 лет ничего не прибавится?Что до STL я знаю компании в которых использование STL программистами запрещено.
И их можно понять - ведь STL это не только мозговзрывной дизайн, но и +50% времени компиляции и +100% WTF?! в сообщениях об ошибках.
Не использовать STL в работе с С++ можно в двух случаях.
1. Используется библиотека более высокого уровня, использующая STL в реализации, но в "завернутом" виде - для тех, кто не умеет пользоваться STL сам. Некоторое время все может казаться идеальным, потом зависимость от этой библиотеки начинает выходить боком.
2. Пишутся свои низкоуровневые велосипеды на замену STL - а заодно и компиляторы, которые их оптимизируют лучше, чем нынешние популярные компиляторы оптимизируют STL. Вряд ли это ваш случай - людям, которые работают на таком уровне, практически невозможно указывать, как именно работать.Если вы действительно знаете альтернативу - расскажите подробнее.
И третий случай когда не стоит использовать STL - при наличии головного мозга.
> И третий случай когда не стоит использовать STL - при наличии головного
> мозга.Скорее, при его отсутствии. Ну или по религиозным соображениям, что, видимо, ваш случай.
Ничего мозголомного в STL нет. Лезть в его реализацию вас никто не заставляет, а пользоваться - куда уж проще?
> Используйте ГО потому что через десять лет у него будет шикарная библиотека!Поясните всё же, чем не устроили CL и перл? Или доводы малость односторонние?..
Больше интересуют языки практического программирования. Извините.
> Используйте ГО потому что через десять лет у него будет шикарная библиотека!
> А у Java С# и Python, у которого, кстати, тоже библиотека больше,
> за 10 лет ничего не прибавится?Я Вас правильно понял - Вы против появления новых языков программирования?
> Что до STL я знаю компании в которых использование STL программистами запрещено.
> И их можно понять - ведь STL это не только мозговзрывной дизайн,
> но и +50% времени компиляции и +100% WTF?! в сообщениях об
> ошибках.Странные компиляторы используются, если +100% времени - это сообщения об ошибках.
>Я Вас правильно понял - Вы против появления новых языков программирования?Если они несут хоть одну новую идею - нет. А если это 100% NIH как с Golang?
>>Я Вас правильно понял - Вы против появления новых языков программирования?
> Если они несут хоть одну новую идею - нет. А если это
> 100% NIH как с Golang?Доброе утро.
Я не знаком с тем, что означает "NIH".В случае Go идея была в улучшении и облегчении создания многопоточных программ, возможность использовать один язык как для web, так и для компьютера, и чтобы это был компилируемый, полностью кроссплатформенный язык, но при этом с возможностью как ручного, так и автоматического управления памятью.
Как по мне - собрать воедино то, что требует реалии - очень хорошо. И это я говорю несмотря на то, что некоторые моменты (в основном, связанные с синтаксисом Go) мне очень неприятны.
> но и +50% времени компиляцииЛол, вьюноша, осиль уже make -j9
И как я не догадался. Спасибо!
> В твиторе сказали что она - отвал башки!"Дай угодаю, ты завсегдатай тупичка?
Конечно, только вот почему мне на MSDN в C# (.NET, Mono) советуют пользоваться каким-то Jayrock [http://jayrock.berlios.de] для роботы с JSON? А в Java для JSON приходиться искать что-то в роде Jackson [http://jackson.codehaus.org]? Где логика?>А для записи в Oracle мы будем использовать ...
Одину из оберток (которую написать то и особого труда не составит самому, хотя да, можно и из GitHub стащить) к Oracle Call Interface [http://www.oracle.com/technetwork/database/features/oci/inde... через доступ библиотекам на голом С.
Когда же уже кто-нибудь написшет язык для написания языков !
Уже написан. Английский называется)
> Когда же уже кто-нибудь написшет язык для написания языков !Я принёс вам добрую весть: https://ru.wikipedia.org/wiki/ANTLR
>ANTLR (от англ. ANother Tool for Language Recognition — «ещё одно средство распознавания языков») — генератор парсеров, позволяющий автоматически создавать программу-парсер (как и лексический анализатор) на одном из целевых языков программирования (C++, Java, C#, Python, Ruby)[1] по описанию LL(*)-грамматики на языке, близком к РБНФ. Позволяет конструировать компиляторы, интерпретаторы, трансляторы с различных формальных языков. Предоставляет удобные средства для восстановления после ошибок и сообщения о них. ANTLR — продолжение PCCTS (Purdue Compiler Construction Tool Set), который был разработан в 1989 г.Более 20 лет как всё есть уже.
Вот и выросло поколение, не знающее про Lex и Yacc.
> Вот и выросло поколение, не знающее про Lex и Yacc.Языком программирования некоторая грамматика становится не после того, как вы ее смогли "распарсить", а после того как сможете выполнять корректную программу написанную с ее помощью.
http://ru.wikipedia.org/wiki/%D0%9F%D1%8...
http://haxe.org/
После появления TypeScript лично для меня перспективы дарта стали совсем сомнительными. Тайпскрипт в отличие от дарта изучается за 20 минут и идеально транслируется в JS, причем очень прозрачная трансляция получается. То есть порог освоения почти нулевой. А в сравнении с тайпскриптом дарт уже совсем не так выигрышно смотрится - основные проблемы джаваскрипта тайпскрипт решает.Опять же - MS явно быстрее научит IE тайпскрипту, чем гугл впихнет дарт в хромиум...
Ну как сказать... И TypeScript, и Dart транслируются в JS. Работая на одном из них нет смысла смотреть на код на JS вообще, а как раз наоборот - вам важно чтобы оно работало именно так, как Вы задумывали и при этом во всех браузерах. Т.о. и TypeScript'овцы (какое окончание некрасивое), и Dart'овцы в одинаковых позициях.
А вот на счёт порога вхождения - это покажет время и наличие библиотек для обоих языков.
Видите ли, отладка-то идёт уже транслированного кода. И то, что генерирует TypeScript, весьма приигодно для отладки и точка в генерированном JS отлично сопоставляется с исходником на TypeScript. А вот у Dart с этим так же плохо, как у CoffeeScript.А вот с бибилиотеками интереснее. Typescript поддерживает JS-код из коробки, являясь его надмножеством, а чтобы получить проверку типов для сторонних библиотек нужны относительно несложные декларации. А вот в Dart работа с JS-кодом сделана, скажем вежливо, не ахти (прокси какие-то), и проверка типов там уже, судя по всему,не получается. Вот, можете полюбоваться: http://www.dartlang.org/articles/js-dart-interop/?ModPagespe...
> Видите ли, отладка-то идёт уже транслированного кода. И то, что генерирует TypeScript,
> весьма приигодно для отладки и точка в генерированном JS отлично сопоставляется
> с исходником на TypeScript. А вот у Dart с этим так
> же плохо, как у CoffeeScript.
> А вот с бибилиотеками интереснее. Typescript поддерживает JS-код из коробки, являясь его
> надмножеством, а чтобы получить проверку типов для сторонних библиотек нужны относительно
> несложные декларации. А вот в Dart работа с JS-кодом сделана, скажем
> вежливо, не ахти (прокси какие-то), и проверка типов там уже, судя
> по всему,не получается. Вот, можете полюбоваться: http://www.dartlang.org/articles/js-dart-interop/?ModPagespe...Настолько я не разбирался ни с одним из языков, но чувствуется, что Вы тут лучше разбираетесь. Ну и выше я написал, что в итоге всё должно вылиться в то, что про JS вообще никто думать не будет, как, к примеру, пишут на Java, хотя всё переводится в код на С (ну или нативный для устройства).
Только если отладку в исходных языках поддержат в основных браузерах. Что, в принципе, ничего экстраординарного не требует - хватит какого-нибудь формата аннотаций в генерированном JS вроде как в генерированном C есть #line
Для Гугля это пройденный несколько лет назад этап (см. ECMAScript Harmony). Всё же решили, что в долговременной перспективе горбатого полностью не исправить, лучше сделать сразу правильно. Но Harmony тоже поддерживают. Так что здесь MS выступает в роли велосипедоизобретателя (им это не впервой).
Не припомню чтобы между революционным решением и эволюцией индустрия выбирала революцию. А здесь MS очень плавный переход предлагает - полная обратная совместимость плюс при желании - новые плюшки. IMHO - у такого подхода много больше шансов победить. Да и язык довольно аккуратно продуман, тут не отнять. Сами спецификацию почитайте - оцените.Собственно, полностью горбатого исправлять и не обязательно - хотелось бы, конечно, выкинуть автоматическое преобразование типов, чушь с необязательными точками с запятой и прочее, но для реальной работы предложения MS вполне достаточно - есть проверка типов, есть закрытые именованные структуры, которые можно пихать вместо невнятных {...}, есть удобные классы без синтаксического мусора, есть модули. Для того чтобы делать веб-приложения этих добавок вполне хватит.
знаете, почему-то столько раз, когда индустрии требовались новые решения, MS всегда умудрялась подсунуть дерьмо в красивом фантике. Не то что бы у них хороших разработчиков не было - вполне даже встречаются, да и свежих на стороне регулярно прикупают. Но вот что из этого обычно выходит, лучше бы уж совсем не брались.
Да как сказать... В области языков программирования у них всегда дела неплохи были. Тот же VB в своё время был вполне себе революцией (и при правильном применении был весьма неплох), c# - как язык просто хорош. Есть некие конфликты рантаймов, но сам язык очень достойный и выразительный. Другое дело, что регулярно получалось, что "упрощенные" инструменты пытались использовать для чего-то большого и закономерно натыкались на грабли - с VB и особенно VBA это очень заметно было. А здесь у MS и автор языка с репутацией (как и C#), и к браузеру своему они всё это не прибили, на удивление, и транслятор под приемлемой лицензией... В общем, ждать подвоха вроде и неоткуда.
> ... MS ... ждать подвоха вроде и неоткуда.Как правило, это означает просто, что мы чего-то не знаем.
Ну вон с Mono уже ждут подвоха сколько лет - а его всё не видно.
> Ну вон с Mono уже ждут подвоха сколько лет - а его всё не видно.Он просто с другой стороны пришёл -- "всем спасибо, все свободны".
java не купили вовремя, теперь жрут кактус
> java не купили вовремя, теперь жрут кактус(равнодушно) В отличие от тебя, неспособного ни купить JRE, ни написать что-то подобное в одно лицо, они хотя бы оказались способны ко второму.
Не называйте транслятор компилятором.
> Не называйте транслятор компилятором.Границы уже давно размыты. Вылазь из криокамеры.
> Не называйте транслятор компилятором.а какая разница? по какому критерию можно точно определить, что является чем?
То что действительно сейчас нужно, так это компилятор который будет делать следующееint function a() implements b {
bool x;
string y;
return 1;
}var z = function () {};
....
var function a() {
var x;
var y;}
var z = function () {};
