Как стать автором
Обновить

Комментарии 100

Scala, только от Google…
Пока не прочел про синтаксис думал, что это CoffeeScript от Google.
не надо унижать scala
Это был укол в сторону Dart, a не Scala. Я сам пишу на Scala, это к тому, что они сделали велосипед, снова…
Зачем все пытаются переизобрести велосипед? Почему никто не пробует создать БелАЗ или автобус? Почему бы не заложить в язык паттерны? Например, объявляешь синглетон: singleton class MyClass и все. Или удобные механизмы задания архитектуры проекта: уровни/слои и зависимости между ними. Я вот хочу указать, что проект состоит из трех слоев ABC и из С использовать A напрямую нельзя. Как мне это сделать в любом современном языке?
Как на уровне языка отделить презентацию от модели? Я хочу объявить «слой модели» и запретить использовать в нем классы из UI. У меня вот проект состоит из трех сборок, в каждой из которых по 2-3 слоя, суммарно 8. Жду появления языка для больших проектов.
в скала можно описать объект те сингельтон.
Но вот дальше — ждемс очередного витка.
«Почему бы не заложить в язык паттерны?»
Ну вот вам только что заложили в язык паттерн Factory (от которого, как мы понимаем, до синглтона совсем недалеко).

«У меня вот проект состоит из трех сборок, в каждой из которых по 2-3 слоя, суммарно 8.»
Специально для вас в VS (Ultimate) есть архитектурная валидация. Строго для вашего случая.
это называется сферический конь в вакууме
singleton это решается на уровне annotation или traits (если 1-2 словами нужно), а то что вы предлагаете заложить в язык кучу keywords причем в динамический, это вообще бред
возьмите scala к примеру и на уровне типов запрещайте себе слои и т.п. в чем проблема? создайте свой dsl и радуйтесь
Если вам не нравится современные языки, напишите свой с блекджеком и паттернами.
Я вот хочу указать, что проект состоит из трех слоев ABC и из С использовать A напрямую нельзя. Как мне это сделать в любом современном языке?
Как на уровне языка отделить презентацию от модели? Я хочу объявить «слой модели» и запретить использовать в нем классы из UI.


Ну это вы можете сделать уже давно. Почитайте про то, что такое на самом деле инкапсуляция/сокрытие, почитайте про «компонентное проектирование», почитайте про правильное использование пространств имён и про то что в вашем любимом языке уже есть package private область видимости — и пользуйтесь на здоровье.

Попробуйте Haskell

Дико понравились фишки с методами и пропертями класса через лямбда выражения (через =>), и «интерполяция» строк типа '$salutation, $name'. Хотя количество языков от гугл настораживает (Go, Dart).
НЛО прилетело и опубликовало эту надпись здесь
Насколько я понял это уже реализовано в Standalone VM. См. пример чат сервера в исходниках.
неплохо, однако стоит уделить внимание некоторым «вычурным» на мой взгляд местам:
1)
var a = new Symbol('something');
var b = new Symbol('something');

>>Второй вызов на самом деле не создаст новый символ, а вернет уже имеющийся.
простите, но на мой взгляд, если я говорю new, то я имею ввиду создать новый, собственно, поэтому я и пишу new. Намного более гибким является использование статического метода.

>> Это удобно, так как если сначала нам не был нужен фабричный конструктор, а потом оказалось, что таки был, нам не придется где-то в коде менять new на вызов статического фабричного метода.
ну это вообще не оправдание для «ленивых», а собственно, возможный генератор ошибок.

2) >> Чтобы объединить несколько строк в одну, вы можете использовать конкатенацию:…
>> Но интерполяция будет чище и быстрее:…
Они не догадались сделать проверку типа скобок. Или это баг автора? К примеру, в php знак $ в строке с двойными кавычками является подстановкой значения переменной, а с одинарной — то что действительно записано в строке, что является более правильным подходом, на мой взгляд, так как дает разработчику выбор того, что он хочет вывести в строке без еще одного экранирования спец. символа. (кстати, здесь хоть экранирование '\$name' работает?)

3) Равенство ==/!= и ===/!==
Это вообще что-то страшное. В языке с динамической типизацией использовать == и != как проверку на эквивалентность (значение и тип)…
1) не правда, все работает так как и должно

2) экранирование работает

3) == и === не одно и то же.

try-dart-lang.appspot.com/s/MSsT
1) не понял, что в Вашем понимании «все работает так как и должно»?
2) хоть на этом спасибо )
3) я имел ввиду не равенство между == и ===, а раздел поста с названием «Равенство»
1) Не обращайте внимания, это я поспешил
3) после N-ого круга перечитывания фразы, я понял о чем вы =)
как раз то, что описано в разделе про «Равенство», == здесь является проверкой на эквивалентность, то есть проверка по значению и типу, и не выполняет каких либо преобразований типов
Так получается она == и === — одно и то же. Раз примитивы сравниваются по значению (но по факту, они как в джаве ссылаются на один и тот же адрес в пуле), а сложные переменные по адресу…

Не ясно зачем они так сделали… Вообще там сыро все… очень сыро… Может в светлом будущем…

Лучше бы Кофескрипт скопировали, добавили опциональную типизацию и убрали один момент, где кофескрипт умничает и не дает создать локальную переменную с таким же именем, что и глобальная (или в родительском замыкании).
Первый пункт, это же не особенность языка в целом, это особенность конкретного примера Factory конструктора. Если такое поведение не нравится, просто не пишите такие конструкторы
Как поступать со сторонними библиотеками? Пока в код не залезешь непонятно, используют они Factory конструктор или нет.
Вызывающий код должен знать только публичный интерфейс библоиотеки. Factory-конструктор или обычный — это детали реализации, которые вам, как пользователю библиотеки знать незачем.

И перечитайте пример кода еще раз. Factory Constructor != конструктор, всегда возвращающий один и тот же объект. Просто в гугле не очень удачный пример выбрали для демонстрации этой фичи
Допустим, есть класс Point(x, y, z), я как пользователь не знаю реализации, и мне нужны две точки в одном месте: p1 = Point(1, 2, 3); p2 = Point(1, 2, 3); Как мне узнать p1 и p2 — это один и тот же объект или 2 разных? каждый раз проверять? А если они в разных местах инициализируются?
Чукча не читатель, чукча — писатель? Дважды уже разъяснено в чем дело.
Пример на старом добром JS:

global oneEvilObject = {x:1, y:2, z:3};

function Point() {
return oneEvilObject;
}

p1 = new Point();
p2 = new Point();

Как вы определите что p1 и p2 это один объект не смотря в код и не делая явных проверок?
Говнокодить можно на чем угодно. Повторюсь, кеш — это просто не самое удачное приминение для Factory-конструктора
Такие фабрики для immutable объектов, а для них всё равно один это объект или два одинаковых
Пожалуй, солглашусь, для неизменяемых объектов это действительно весьма удобно и прозрачно будет
Да, но mutable объекты тоже можно запросто делать через такие фабрики. А с ними могут быть проблемы, очевидно же.
Ну если ты используешь что-то подобное для изменяемых объектов, то ты должен понимать, что ты делаешь. В некоторых случаях это даже полезно, Borg pattern, например, частный случай.

Если ты не знаешь, что ты делаешь, ну что ж, делать глупости не запретишь. На самом деле, запрещать делать глупости скорее вредно, чем полезно.
В языке с динамической типизацией использовать == и != как проверку на эквивалентность

Задолбали путать динамическую и слабую типизации, блин.
я не путаю эти понятия, просто в разделе «Равенство» написано, что будет произведена проверка без каких-либо неявных преобразований, такой акцент вызвал у меня обратную реакцию и я «прочитал между строк, что этот язык с динамической типизацией».
1) я думаю, что авторы языка исходили примерно из следующих соображений:

изначально был
class Symbol {
Symbol (String name)…
}

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

гугловцы в данном случае избавились от последнего. если же нам действительно нужен ещё какой-то конструктор, который всегда-всегда возвращает новые объекты, нам никто не мешает создать дополнительный конструктор Symbol.alwaysCreateNew(String name)
я за new как за такой «дополнительный конструктор» ;)
а вообще, это не трагедия, просто от этого страдает чистота языка что-ли
насколько я понимаю, можно как раз дополнительный конструктор сделать фабричным, а new сделать просто new.
но с практической точки зрения мне больше их вариант нравится, с new не-нью.
Ерунда какая-то, очередной полуимперативный-полуфункциональный язык, каких навалом вокруг. Все его штучки в том или ином виде давным давно есть в JS 1.6+, PHP 5.3+, а в питоне вообще в незапамятных времён. Зачем? Такой можно сочинить для развлечения, будучи студентом и изучая теорию компиляторов.

Я всё-таки поддержу general. Давно пора начать думать о ещё более высокоуровневых языках, нативно и красиво реализующих те же контракты, аспекты и какие-то устаканившиеся паттерны.
>> Все его штучки в том или ином виде давным давно есть
А что вы хотели написать do Chuck Norris и программа готова? Вот и напишите спецификацию, устройте презентацию крупным компаниям, сможете доказать эффективность вашего сферического коня, может получите грант. А просто говорить о какой супер абстрагированном языке все могут.
НЛО прилетело и опубликовало эту надпись здесь
Все те вещи, что императивщики подсмотрели у функциональщиков — first-class functions, лямбды, замыкания и т.п.
Вообще-то паттерны проектирования — это баги, а не фича. Попытка обойти ограничения ОО-языков.
Если бы они написали настоящий функциональный язык — вот это было бы круто. И да, насчёт «высокоуровневых абстракций» — что может быть абстрактнее категорий? ОО — это как ассемблер vs. с# по сравнению с достойным функциональным языком.
Хм, по моим ощущениям такой комплект забавных но не критичных особенностей как-то не оправдывает необходимость введения нового стандарта (языка), ну разве что типизация.
Хотя сейчас под него быстро портируют ключевые JS библиотеки и можно будет уже более предметно смотреть что к чему.
ИМХО, NodeJS нуждается в подобной вещи.
Сам Node.JS не нуждается, там все таки все завязано на java script. Можно будет сделать новый сервер сайд по типу node.js.
Ну это как бы прикольно. Я что-то не могу понять что Ryan сможет сделать связи с этим.
Отличное название для языка, специально, чтобы было ничего не найти в гугле :)
С предыдущим (Go) у них круче получилось.
Да ладно, как будто вы никогда не гуглили ничего по С.
Ох велосипедисты.
Я что-то не понял, почему нельзя просто
bool contains(num x, num y) {
return (x < width) && (y < height);
}

записать как
bool contains(num x, num y) { return (x < width) && (y < height); }
если очень хочется однострочник? Такая прям большая разница с
bool contains(num x, num y) => (x < width) && (y < height);
? Я уж молчу, что если понадобится добавить вторую строчку, придётся всё равно на скобки переписывать.
Dart integers are true integers, not
32 bit or 64 bit or any other ?xed range representation. Their size is limited only
by the memory available to the implementation.
Эффект «uncanny valley», он же «зловещая долúна». Перестарались. Язык Dart слишком походит на джаву и джаваскрипт, поэтому воспринимается не как «интересный новый язык», а как «зачем джаву и джаваскрипт извратили, изверги».
Не понял одного момента: в начале статьи было сказано, что «как большинство динамических языков, Dart не поддерживает перегрузку», а потом описано создание перегруженных операторов. Получается, для класса можно объявить только один оператор+?
НЛО прилетело и опубликовало эту надпись здесь
Значит в Dart нельзя сделать такое в одном классе?
operator +(num A) =>…
operator +(String a) =>…
НЛО прилетело и опубликовало эту надпись здесь
Посмотрим на правдивые реалии. Многие юзают такую замечательную вещь, как jQuery(MooTools,Prototype и т.д.). Да и в JS в браузерах, есть поиск по селекторам. Если я юзаю JS в браузере, то с большей вероятностью, я буду работать с DOM-моделью. И как будет юзаться это с Dart? Нет, я потом конечно думаю увижу такие статьи как «Запуск jQuery на Dart.». Т.е. рождение костыля. При должном проектировании — всё это не так требуется. 80% нынешних разработчиков, которые используют JS в своих проектах, забывают про его асинхронную природу и правило «в функциях и методах, как можно скорее отдавать управление».

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

Дальше, еще больше. Есть возможность трансляции в JS код. Кто может гарантировать то, что транслированный код, будет успешно работать в браузерах, и не конфликтовать с их базовыми методами(и их реализациями) класса window. И в случае проблем — мне что, придется копаться в то, что сгенерировал транслятор? Ну уж спасибо — нет. Да и насколько оптимизированным получится код? Нынешние браузеры и так жрут нещадно память.

Вообще — стоит поизучать подходы решения задач в при однопоточном, но асинхронном выполнении. И если для вашей задачи это не подходит, выберите другой язык.
Тем кто разрабатывает новые языки, поверх JS. Разрабатывается черновик JS 1.9 и JS 2.0.Может стоит разработчикам спецификации выслать свое мнение? Причем с учетом направленности JS.

Всё выше относится и к Ноде. Кстати, где-то я находил (если найду в хистори, ссылку скину) классный профессиональный перевод, где Райан Дал, описывал рекомендации, при написании JS приложения. Тем — кто хочет видеть данный подход в Ноде, юзайте лучше EventMaschine с Ruby.
1. Это не язык поверх JS. Это отдельный язык на данный момент использующий трансляцию в JS. Это не значит что это всегда так будет.
2. Не конфликтовать наверно может гарантировать область видимости, вы то сами как думаете? Вы же не ставите вопрос, «кто мне гарантирует в каждой браузере document.querySelector», логично что производитель браузера и гарантирует либо либа какая-то либо что вы сами себе гарантируете.
3. «Запуск jQuery на Dart… Т.е. рождение костыля» — может я открою для вас тайну но реализация DOM не имеет никакого отношения какой язык используется. Это API. Поэтому jquery вообще тут не причем.

Вас под дулом пистолета никто не заставляет использовать этот язык. Это язык даже без версии пока. Поэтому в продакшине адекватные люди врядли счас его будут использовать.
1) для ие значит
2а) судя по тексту примера с 17k строчками кода — все в глобале
2б) есть такое старое и банальное понятие: «определение возможностей юзер агента»
3) а в джиквери только дом? megaalli66 говорил о существующей архитектуре — что с ней делать? транслировать в dart, а для ие — обратно в скрипт? тут как раз такой топик пробегал: habrahabr.ru/blogs/humour/130150/
> в языке, который преследует асинхронное выполнение

погоня это хорошо. вы наверное прогуливали уроки литературы.

> Вообще — стоит поизучать подходы решения задач в при однопоточном, но асинхронном выполнении.

вы это гуглу, аудитории или самому себе? гугл в курсе, даже яваскриптовый движок написали, аудитория в основном тоже в курсе подходов решения задач при однопоточном выполнении. вопрос про литературу я уже задавал

> И если для вашей задачи это не подходит, выберите другой язык.

that's it! именно так они и поступили! другой язык! это НЕ javascript! да! именно другой язык! спасибо за совет! вы такой умный!
Жаль что не поддерживает Destructuring assignment. Код выдает ошибку:
main() {
  num x = 1, y = 2;
  [x, y] = [3, 4];
  print(x);
}
Возможно слегка не по теме…
Моей мечтой было бы увидеть реализацию двух пространств имен для объекта. Хотя это довольно экзотическая вещь. Например можно было бы всякие toString() toInt() toRainbow() писать в отдельный namespace и реализовать две ветки наследования. Это действительно может быть очень полезно при определенных архитектурах, ну и вспомните хотя бы про необходимость использовать сейчас hasOwnProperty (а если проверку нужно делать везде и для прямого родителя? с ума сойти). Еще можно вспомнить про заблокированное свойство name у функций.

Выглядеть это могло бы например так:
object.method() и object.$method()

И надеюсь будет хоть какая-то возможность прототипировать функции.
Меня, как дизайнера, в эту статью привлек отличный логотип =)
О боже
17200 строк! Рантайм не самый легкий
ну они там весь рантайм подключают при отключенных оптимизациях, как я понял
с оптимизациями значительно короче
gist.github.com/1277306
если бы обфускация использовала eval зипованной строки, то получилось бы еще вдвое короче, а так код всего на 22'290% длиннее вышел.
если собрать в visual studio 2008 вот этот привет мир, то получится 90 кб. да плюс ещё msvcrt71.dll на 350 кб.

#include int main() {
std::cout << «Hello, world» << std::endl;
}

а на ассемблере, говорят, всего 500 байт. означает ли это, что нужно писать на ассемблере? нет, не означает.

вернёмся к нашему дарту. если бы неоптимизированный вариант убирал неиспользуемый код из рантайм лайбрари, то кода было бы намного меньше. грубо говоря, компилятор в js работает следующим образом:
result = compile(input)
result += get_all_javascript_runtime_source
if (optimize) {
result = remove_unused_functions(result)
result = optimize_cycles(result)
result = remove_unused_sideeffects(result)
result = do_something_noone_understands_except_author(result)
result = obfuscate_and_compress_and_fuck_op(result)
}
скорость загрузки страницы
кэшируем рантайм и вуаля. jquery все уже тоже давно тянут с внешних серверов и он не загружается каждый раз при загрузке каждой страницы
> все
ctrl+u нажми, например
ок, но сути не меняет
all.js
/javascripts/1318261449
GET
304
Not Modified
все равно кэшируется
это тоже сути не меняет. мы только что выяснили, что-таки не «все» используют cdn (имхо, далеко не 50%), и что при первом открытии сайта, написанного на dart, рантайм надо будет еще один раз. а при последующих (на 99% сайтов) — будет лететь запрос для даты обновления.
*рантайм надо будет грузить еще один раз
ты что, дурак? что значит «скорость загрузки страницы»? скорость загрузки страницы что? какой страницы?
ну я точно не гугль, чтобы тебе понятия расшифровывать.
лестница монокль утконос
а я тебя как бы спрашиваю: ну и что это значит? при чём тут «скорость загрузки страницы цветок сельдерей помидор»? а ты меня посылаешь в гугль.
ты мне как бы сказал: «ты что, дурак?» скорость загрузки страницы — это параметр прямопропорциональный возгласу «чтож все еле грузится!». чем больше надо грузить — тем хуже, и чем больше запросов — тем хуже. там 30 кило, там еще 30, еще несколько раз — и сайтик уже не «летает».

а при отпимизированном для каждой страницы рантайме аргументы от fleshy (см. выше) надо делить на кол-во страниц в интернете (ну за вычетом глубины просмотра).

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

во-первых, я все-таки скажу то, чего ты сказал что говорить не надо.
использовать dart на маленьких страничках до тех пор, пока не будет нативной поддержки языка браузером — это глупость, даже глупее чем грузить jquery ради единственного вызова селектора по id — $('#id')

во-вторых, сейчас язык ещё даже не в альфа-версии. то есть оптимизацией никто как бы и не занимался особенно (ну, нафигачили за 10 минут вызов js-сжимателя, и как бы всё). думаю, что к бета-версии (если она вообще будет) проблема с большим рантаймом будет как-то решена. среди возможных вариантов:
1. оптимизировать руками (1 раз), потом сжать весь рантайм, выложить её на гугл-cdn
2. оптимизировать руками (1 раз), для каждого приложения делать свою сборку рантайма. будет уже не 30кб, а там 5 например. или меньше, смотря насколько они постараются.

да, это не идеальные решения, но любое из них жизнеспособно.
вопросов два.

1) кто будет заниматься отпимизацией? т.е. не «огласите весь список, пожалуйста», а сколько разработчиков на это не забьют? 1%, 3%, 5%?

поначалу вообще будут делать сайты на дарте только чтобы посмотреть что это за зверь такой — прямо на альфа-версии со всеми недостатками, даже не зная а нужно ли вообще этот дарт использовать.

2) пока что я каких-то революционных плюсов у dart'а не заметил. как ни отпимайзь файлы — профит от их загрузки должен быть.

ps 30кб это округленный вес gist.github.com/1277306 — как раз отпимизированного и минифаенного рантайма, откуда «5 например» получились?
1) оптимизацией будет заниматься Гугл. сейчас они на коленке нахерачили какой-то рантайм который хорош тем, что работает. других плюсов у него нет.
когда будет релиз — я почти уверен, что они перепишут тот код, который есть сейчас, по-нормальному, и вместо 17к строк будет гораздо меньше.
с другой стороны, оптимизатор (если использовать оптимизатор не для любых js-файлов, а с уклоном в js-файлы, получающиеся после компиляции дарта) сможет быть более агрессивным и выкидывать больше ненужных кусков кода. я уверен, что простыми машинными действиями можно свести размер хелловорлда до нескольких сот байт, но я также уверен, что это — не основное, куда стоит тратить ресурсы гуглу. поэтому, думаю, что какая-то оптимизация будет, но разумная. я выбрал разумную цифру в 5кб и сообщил её, чтобы наша дискуссия не висела в воздухе.
естественно, что в текущем виде дарт можно использовать только для экспериментов. ну, для домашних страничек может быть

2) а какие революционные плюсы должны быть? в своей области применения плюсы довольно очевидны: основной плюс это опциональная статическая типизация и отказ от этой js-ной прототипизации.
1) я про отпимизацию файлов, которую ты предложил:
> 1. оптимизировать руками (1 раз), потом сжать весь рантайм, выложить её на гугл-cdn
> 2. оптимизировать руками (1 раз), для каждого приложения делать свою сборку
имхо, этим будут заниматься 5% разработчиков. не имхо, даже если все 20%, в целом инет станет помедленнее. никакого профита.

2) этих двух плюсов достаточно для нового языка, требующего переписывания (пусть и автоматического) всех существующих библиотек? точнее даже одного плюса — опциональная статическая типизация. т.к. есть библиотеки/решения эмулирующие классические public/protected/private/extend. ну, это если прототипирование вообще относить к минусам.

в новой екме class'ы обсуждаются. а вероятность реализации в ie следующей спецификации js выше (нулевой) вероятности имплементации языка от прямого конкуретна.

я читал статью и вижу, что еще можно, например, оператор сложения переопределить — но действительно ли все это (для классов, повторюсь, есть библитечки.js) тянет на изучение нового синтаксиса и новых заморочек (тоже ==)?
я про отпимизацию файлов, которую ты предложил:
да. «оптимизировать руками (1 раз)» — это сделает гугл. именно об этом я и говорил

> в целом инет станет помедленнее

в браузерах, которые не будут поддерживать этот язык нативно

> выше (нулевой) вероятности имплементации языка от прямого конкуретна

я бы не сказал, что вероятность нулевая. в Win8 и Metro мелкософтовцы взяли курс на HTML5+JS как основное средство для разработки приложений. я бы даже сказал, как «платформу для native-приложений». а дарт как раз для таких задач и предназначен. microsoft конечно не империя добра, но своего не упускает.

> этих двух плюсов достаточно для нового языка, требующего переписывания (пусть и автоматического) всех существующих библиотек?

это довольно сложный вопрос, который нужно адресовать авторам языка. видимо, достаточно.
Язык хороший, но как быть с IE?
Если MS его поддерживать не будет, то смысла на клиенте в нем не много…
именно для этого и есть компилятор в javascript, который позволит использовать новый язык даже на старых говнобраузерах.

ну а в будущем наверное поддержат, если у гугла получится широко распространить язык
IE? Кто такой IE?
Google Chrome Frame?
Ну чо — круто :) В хромах работает? Как плагин можно зацепить к FF или IE?
А как с многопоточностью, как это запилили?
НЛО прилетело и опубликовало эту надпись здесь
А можно где-то примеры посмотреть или статьи почитать? Не сталкивался с такой многопоточностью.
НЛО прилетело и опубликовало эту надпись здесь
Я правильно понимаю, что язык не конкурент Node.js? Dart это альтернатива клиентскому JavaScript, а для бекенда google все также будут пилить Go?
Там же и серверная VM есть. Конкурент или не конкурент — пока не ясно.
прошу прощения, что на английском

You appear to be advocating a new:
[ ] functional  [ ] imperative  [ ] object-oriented  [ ] procedural [ ] stack-based
[ ] "multi-paradigm"  [ ] lazy  [ ] eager  [ ] statically-typed  [ ] dynamically-typed
[ ] pure  [ ] impure  [ ] non-hygienic  [ ] visual  [ ] beginner-friendly
[ ] non-programmer-friendly  [ ] completely incomprehensible
programming language.  Your language will not work.  Here is why it will not work.

You appear to believe that:
[ ] Syntax is what makes programming difficult
[ ] Garbage collection is free                [ ] Computers have infinite memory
[ ] Nobody really needs:
    [ ] concurrency  [ ] a REPL  [ ] debugger support  [ ] IDE support  [ ] I/O
    [ ] to interact with code not written in your language
[ ] The entire world speaks 7-bit ASCII
[ ] Scaling up to large software projects will be easy
[ ] Convincing programmers to adopt a new language will be easy
[ ] Convincing programmers to adopt a language-specific IDE will be easy
[ ] Programmers love writing lots of boilerplate
[ ] Specifying behaviors as "undefined" means that programmers won't rely on them
[ ] "Spooky action at a distance" makes programming more fun

Unfortunately, your language (has/lacks):
[ ] comprehensible syntax  [ ] semicolons  [ ] significant whitespace  [ ] macros
[ ] implicit type conversion  [ ] explicit casting  [ ] type inference
[ ] goto  [ ] exceptions  [ ] closures  [ ] tail recursion  [ ] coroutines
[ ] reflection  [ ] subtyping  [ ] multiple inheritance  [ ] operator overloading
[ ] algebraic datatypes  [ ] recursive types  [ ] polymorphic types
[ ] covariant array typing  [ ] monads  [ ] dependent types
[ ] infix operators  [ ] nested comments  [ ] multi-line strings  [ ] regexes
[ ] call-by-value  [ ] call-by-name  [ ] call-by-reference  [ ] call-cc

The following philosophical objections apply:
[ ] Programmers should not need to understand category theory to write "Hello, World!"
[ ] Programmers should not develop RSI from writing "Hello, World!"
[ ] The most significant program written in your language is its own compiler
[ ] The most significant program written in your language isn't even its own compiler
[ ] No language spec
[ ] "The implementation is the spec"
   [ ] The implementation is closed-source  [ ] covered by patents  [ ] not owned by you
[ ] Your type system is unsound  [ ] Your language cannot be unambiguously parsed
   [ ] a proof of same is attached
   [ ] invoking this proof crashes the compiler
[ ] The name of your language makes it impossible to find on Google
[ ] Interpreted languages will never be as fast as C
[ ] Compiled languages will never be "extensible"
[ ] Writing a compiler that understands English is AI-complete
[ ] Your language relies on an optimization which has never been shown possible
[ ] There are less than 100 programmers on Earth smart enough to use your language
[ ] ____________________________ takes exponential time
[ ] ____________________________ is known to be undecidable

Your implementation has the following flaws:
[ ] CPUs do not work that way
[ ] RAM does not work that way
[ ] VMs do not work that way
[ ] Compilers do not work that way
[ ] Compilers cannot work that way
[ ] Shift-reduce conflicts in parsing seem to be resolved using rand()
[ ] You require the compiler to be present at runtime
[ ] You require the language runtime to be present at compile-time
[ ] Your compiler errors are completely inscrutable
[ ] Dangerous behavior is only a warning
[ ] The compiler crashes if you look at it funny
[ ] The VM crashes if you look at it funny
[ ] You don't seem to understand basic optimization techniques
[ ] You don't seem to understand basic systems programming
[ ] You don't seem to understand pointers
[ ] You don't seem to understand functions

Additionally, your marketing has the following problems:
[ ] Unsupported claims of increased productivity
[ ] Unsupported claims of greater "ease of use"
[ ] Obviously rigged benchmarks
   [ ] Graphics, simulation, or crypto benchmarks where your code just calls
       handwritten assembly through your FFI
   [ ] String-processing benchmarks where you just call PCRE
   [ ] Matrix-math benchmarks where you just call BLAS
[ ] Noone really believes that your language is faster than:
    [ ] assembly  [ ] C  [ ] FORTRAN  [ ] Java  [ ] Ruby  [ ] Prolog
[ ] Rejection of orthodox programming-language theory without justification
[ ] Rejection of orthodox systems programming without justification
[ ] Rejection of orthodox algorithmic theory without justification
[ ] Rejection of basic computer science without justification

Taking the wider ecosystem into account, I would like to note that:
[ ] Your complex sample code would be one line in: _______________________
[ ] We already have an unsafe imperative language
[ ] We already have a safe imperative OO language
[ ] We already have a safe statically-typed eager functional language
[ ] You have reinvented Lisp but worse
[ ] You have reinvented Javascript but worse
[ ] You have reinvented Java but worse
[ ] You have reinvented C++ but worse
[ ] You have reinvented PHP but worse
[ ] You have reinvented PHP better, but that's still no justification
[ ] You have reinvented Brainfuck but non-ironically

In conclusion, this is what I think of you:
[ ] You have some interesting ideas, but this won't fly.
[ ] This is a bad language, and you should feel bad for inventing it.
[ ] Programming in this language is an adequate punishment for inventing it.


отсюда
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации