Switches from Java to JavaScript

6yrop

типа JS захавает всё?

One of the benefits of using JavaScript from browser to server is, according to Harrell, the elimination of a divide between front and back-end development by having one team “which allows us to understand and react to our users’ needs at any level in the technology stack.”
http://www.infoq.com/news/2013/11/paypal-java-javascript

IT отрасль неуклонно погружается во тьму средневековья?

yroslavasako

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

Dasar

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

Dasar

Убрать из законодательства понятия "вредносная программа" и "взлом сайта" и предоставить программистам самим отвечать за качество своих продуктов перед пользователями, а не перекладывать вину на третьих лиц.
Чем это отличается от убрать понятие "грабитель" и "насильник" и предоставить гражданам самим отвечать за качество своей защиты?
ps
можно предложить много кол-во атак от которых никакими программными методами не защитишься.
В частности, ты разрешаешь всем провайдерам между пользователем и сайтом официально использовать атаку человек по середине для всех соединений.

karkar

elimination of a divide between front and back-end development by having one team
Целых два языка в одной голове (или хотя бы команде) никак поместиться не могут, это просто невозможно!

karkar

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

Это вполне может оказаться правдой.
Но мне вот интересно: что это за статически проверяемая гибкость такая, которую нельзя иметь в статически типизированном языке? Т.е. нафига вообще нужна динамика при хорошей системе типов и их выводе?
Структурная типизация и row polymorphism вроде неплохо так справляются, даже если оставаться без зависимых типов.

Dasar

Т.е. нафига вообще нужна динамика при хорошей системе типов и их выводе?
и как системы типов помогают при решении задач вида:
у элемента взять все поля и вывести их на экран?
того же рода задачи:
взять все элементы и их поля и смаппить на бд
взять все элементы и их поля и сериализовать их в виде xml-я
взять все элементы и их поля из библиотеки Y и смаппить их на похожие из библиотеки Z
на такого рода задачах статически типизированные языки часто лишь мешают. Соответственно, динамика нужна чтобы обойти ограничения статически типизированных языков.

yroslavasako

Либо через сериализацию, тот же haskell умеет через data type сериализировать, либо через рефлексию, статически типизированная java вполне умеет в это.

Dasar

тот же haskell умеет через data type сериализировать, либо через рефлексию, статически типизированная java вполне умеет в это.
это более-менее удобно для направления: внутренние типы данных преобразовать в данные для внешнего мира.
а вот с обратным направлением: на основе внешнего мира (например, по готовому xml-нику) сконструировать внутренние типы данных - всё обычно печально. Как минимум из-за того, что требуется время для того, чтобы все эти типы аккуратно описать.

karkar

и как системы типов помогают при решении задач вида:
 у элемента взять все поля и вывести их на экран?

Внезапно, они позволяют узнать, какие у элемента есть поля, чтобы вывести их на экран.
D:
 

struct S {

  int a;

  string b;

}



void show(TT x)

{

  foreach(m; __traits(allMembers, T

    static if (!isSomeFunction!(__traits(getMember, T, m

      writeln(m, " = ", __traits(getMember, x, m;

}



void main(string[] argv)

{

  auto s = S(3, "lines");

  show(s);

} 

a = 3

b = lines

Dasar

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

Dasar

foreach(m; __traits(allMembers, T
static if (!isSomeFunction!(__traits(getMember, T, m
writeln(m, " = ", __traits(getMember, x, m;
в итоге кода больше, чем на динамике, и никакой пользы от статической проверяемости типов

karkar

на основе внешнего мира (например, по готовому xml-нику) сконструировать внутренние типы данных
Вот это похоже на ответ, спасибо. Хоть сам такой подход мне очень не нравится, представить, что кто-то захочет его применить, можно.

karkar

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

Правда больше? А как выглядит более короткий аналог на динамике, не пытающийся выводить не-данные?
Польза от статической проверяемости даже в таком простом куске есть:
1) гарантия того, что не попытаемся вывести поле, которое не умеем превращать в строку,
2) скорость: такой цикл будет развернут в серию вызовов для конкретных типов и полей, максимально специализирован, и имена полей тут просто константы, а не хранящиеся не пойми где в куче переменные.

Dasar

Хоть сам такой подход мне очень не нравится, представить, что кто-то захочет его применить, можно.
таких задач очень много.
БОльшая часть данных персистентная и лежит во внешнем мире: БД, xml, веб и т.д. В коде же требуется маленькую частичку этих данных взять, преобразовать и кинуть обратно.
И при этом, конечно, не хочется городить полноценную систему структурных типов параллельную таким же типам из БД, xml-я и т.д.

Dasar

javascript:


var s = {x:1, y:"zz"};



for (var key in s)

  print(key + ": " + s[key])

karkar

for (var key in s)
print(key + ": " + s[key])
Синтаксис чуть покороче, но в целом то же самое. Особенно если добавить проверку, чтобы функции не выводились.

6yrop

Целых два языка в одной голове (или хотя бы команде) никак поместиться не могут, это просто невозможно!
во-первых, поместиться могут, но ресурсы головы сильно ограничены (см. Дейкстру) и крайне ценные, тратим их попусту, получаем значительно худший результат, чем могли бы получить. Собственно, это в отчете и говориться Java+JS работало, но херово.
во-вторых, нельзя шарить код между клиентом и сервером

Dasar

также на текущих статик-типизированных языках тяжело реализуются обобщенные функции над структурными типами.
например, следующая функция:
взять на вход произвольную структуру и вернуть новый экземпляр с преобразованием всех полей в ненулевое состояние. С соответствующим изменением типов полей: тип поля T?/Option<T>/Nullable<T> преобразуется в T.
или "обратная" функция:
во входной структуре на основе определенного условия выборочно забраковать значения полей и заменить их null-ем. Тип поля при этом меняется с T на Option<T>

6yrop

F# Type Providers не решают проблему?

Dasar

F# Type Providers не решают проблему?
они скорее решают первую проблему: получить объекты на основе внешних источников, но не решают напрямую вторую проблему: преобразовать структурный тип в почти такой же.

karkar

также на текущих статик-типизированных языках тяжело реализуются обобщенные функции над структурными типами.

Когда есть развитая компайл-тайм рефлексия (как в том же D или макросах Скалы это совершенно не проблема.
Другой вопрос, что многие из текущих языков не имеют таких возможностей, ну так я их и не имел в виду, а говорил о потенциальном будущем

Dasar

Когда есть развитая компайл-тайм рефлексия (как в том же D или макросах Скалы это совершенно не проблема.
пример можно?
ps
можно даже пример проще: смешать два структурных типа. Поля одной структуры подмешать к другой.

6yrop

компайл-тайм рефлексия
а навигация и рефакторинг будет работать?

karkar

 
смешать два структурных типа

Например, так:
 

string getFields(T

{

    string txt = "";

    T x;

    foreach(m; __traits(allMembers, T

        txt ~= typeof(__traits(getMember, x, m.stringof ~ " " ~ m ~ ";\n";

    return txt;

}



struct Combine(A,B) {

    mixin(getFields!A);

    mixin(getFields!B);

}



struct S {

    int a;

    string b;

}



struct U {

    bool c;

    char d;

}



void main(string[] argv)

{

    alias X = Combine!(S, U);

    auto x = X(1, "hi", false, 'x');

    x.a = 10; 

    x.c = true;

    show(x); // определен в посте выше

}

выводит
 
a = 10

b = hi

c = true

d = x

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

karkar

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

Ivan826

А чо? для "динамических языков", под коими вы тут имеете ввиду JS, есть IDE?
И навигация? И интеллисенс? И, не побоюсь этого слова, рефакторинг?
Да, и эта, а при чём тут джава вообще?

6yrop

И навигация? И интеллисенс? И, не побоюсь этого слова, рефакторинг?
Это всё есть. Но в этом форуме упорно не понимают какого качества это всё для js.

yroslavasako

Это всё есть.
Каким образом оно может быть? Это же алгоритмически неразрешимая задача для динамических языков

6yrop

Каким образом оно может быть?
Оно есть вот в таком виде http://www.jetbrains.com/webstorm/features/
Это же алгоритмически неразрешимая задача для динамических языков

А ты, по видимому, имеешь ввиду нечто иное.

karkar

Каким образом оно может быть?
Методом "beta than nothing". Никто ж там не обещает 100% точного решения. Сделал чуть умнее чем grep - уже хорошо.

Ivan826

ну то есть ничего лучше нечёткого поиска всё равно не придумано
а я уж испугалсо
продолжу и дальше писать код в саблайме

6yrop

ну то есть ничего лучше нечёткого поиска всё равно не придумано
на самом деле придумали, TypeScript это JS с возможностью добавлять навигацию и рефакторинг там, где тебе нужно.

Ivan826

TypeScript
вот я в принципе не понимаю этих костылей
зачем лепить статическую типизацию? Нахрена классическое ооп карячить?
JS хорош именно своей слабой типизацией и прототипно-ориентированностью.

6yrop

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

Ты про классы? Это всего лишь одна из фич TS. Хочешь используешь, хочешь нет. Это не является какой-то принципиальной фичей.
 
JS хорош именно своей слабой типизацией и прототипно-ориентированностью.

JS является подмножеством TS, весь код на JS является кодом на TS. Всё, что есть в JS, доступно в TS. Просто сделали возможность добавлять по требованию навигацию и рефакторинг. Именно так и надо воспринимать TS. А не как новый язык со своими правилами: классический ооп и т.д. Просто добавили синтаксических фич в JS и всё. Иначе запили ли бы компилятор C# в JS, но этим путём уже многие ходили, и Хельсберг понимает, что это тупиковый путь.

Ivan826

тебе же хотел навигации и рефакторинга, вот пожалуйста.
за такую цену оно мне нахрен не нужно
лучше погрепаю

6yrop

за такую цену
за какую? что ты платишь?

luna89

JS хорош именно своей слабой типизацией и прототипно-ориентированностью.
Не видел нигде чтобы прототипы как-то использовались. Везде они используются для эмуляции классов. Пример - coffeescript.

6yrop

Корян манагер, сам не прогает. Прочитал новости и думает, что разбирается. Его сообщения это просто цитаты из новостной ленты. Более глубокий вопрос, и он уже молчит.

yroslavasako

Чем это отличается от убрать понятие "грабитель" и "насильник" и предоставить гражданам самим отвечать за качество своей защиты?
Тем что гражданин сам взялся участвовать в этом процессе, сам разместил сервер, либо же заплатил другому гражданину за представительство в интернете, и тот уже разместил сервер по поручению первого.
Можно рассмотреть другую ситуацию, где нет ассиметрии в возможностях осуществлять право, т.е. армия юристов и пиарщиков доступна одинаково пострадавшим и бенефицарам от компьютерных багов. Известно несколько разорений компаний, торгующих на бирже, вызванных сбоями в алгоритмах автоматической торговле на этой самой бирже. При этом пользу из найденного бага мгновенно и в автоматическом режиме извлекали умные алгоритмы других компаний, торгующих на бирже. И что-то я не слышал ни разу, чтобы результаты торгов отменяли.
Можно говорить, конечно, что компании эти гораздо профессиональнее пользователей, и потому в отличие от пользователей могут нести полную ответственность самостоятельно. Но это отвратительный аргумент, потому что без ответственности нет и свободы, и я не желал бы ограничивать свободу физических лиц в сравнении с юридическими.

evgen5555

Пора уже вырастать из детсада, не вечно же воспитателю будут приглядывать за детьми. Это будет хорошим стимулом к повышению качества как конечной продукции, так и методологий, используемых при её создании.
Если в детсаду всем раздать по автомату Калашникова и оставить наедине друг с другом без воспитателя, то получишь некое подобие Сомали. Там каждый должен уделять значительное время думам о собственной безопасности, плюс стремиться использовать слабости остальных, чтобы нажиться, ведь власть не накладывает ни на кого никаких ограничений. Насколько сомалийцы развились с уходом оттуда зашоренных европейцев, можешь увидеть собственными глазами, съездив туда туристом :grin:

Dasar

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

yroslavasako

Полное разорение за 40 минут - это ограничение рисков? Какой бы вирус не словил простой пользователь, вряд ли он смог бы нанести больший относительный урон.

yroslavasako

Если в детсаду всем раздать по автомату Калашникова
Глупо думать о софте в терминах "щит - меч". Мол на каждое усиление защиты найдётся ещё более мощное оружие. Софт - это скорее "дождь против крыши". Когда в крыше нет дырок, то нигде не течёт, какой бы сильный дождь не шёл.

Dasar

Полное разорение за 40 минут - это ограничение рисков?
да, есть ограничение. Нельзя потерять больше, чем есть на счете.
ps
Через дыру же в ПО можно потерять сколько угодно много, вплоть до имущества; денег, которых еще нет (влезание в долги) и т.д.

Dasar

Полное разорение за 40 минут - это ограничение рисков?
во-вторых, можно предусмотреть многоуровневые защиты, которые фиксируют убытки, для произвольных дыр в ПО такое невозможно сделать теоретически.

Dasar

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

yroslavasako

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

evgen5555

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

yroslavasako

А вообще я был не прав. Я тут вспомнил, что производители сердечных стимуляторов предпочитают security from obscurity, поэтому их больные, обычные пользователи, вполне могут потерять жизнь. Ну а что касается богатств - есть личное банкротство, аналогичное корпоративному.

yroslavasako

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

Dasar

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

evgen5555

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

yroslavasako

Для торговли на бирже есть некий протокол. Всё, что подключается по этому протоколу, полностью отвечает за свои действия. Что мешает вести себя по отношению к протоколу TCP/IP?

yroslavasako

ну и как следствие - откат к бумаге, карандашику, распишитесь тут, там, требуется личное присутствие, и не ебет, что нужно ехать в Магадан :grin:
Ха-ха. Уже сейчас есть безглючные решения для обычных пользователей. Просто больше будет зарабатывать аппл на iOS и гугл на chromebook, потому что они готовы брать риски клиентов на себя и квалифицировано решать вопросы компьютерной безопасности.

Kira

не корми эльфа

evgen5555

Ты же даже разницы между глюками и дырами не понимаешь, каким образом тебе удалось дойти до глубоких суждений о применимости закона, остается только гадать :grin:

Dasar

Для торговли на бирже есть некий протокол. Всё, что подключается по этому протоколу, полностью отвечает за свои действия. Что мешает вести себя по отношению к протоколу TCP/IP?
первый протокол очень узкий (небольшое кол-во команд описывает очень малую часть жизни и нулевая стратегия (ничего не делать) обычно позволяет остаться при своих.
для tcp всё наоборот.

yroslavasako

Для tcp опасна нулевая стратегия?

yroslavasako

Ну просвети меня насчёт дыр в экосистеме iOS. Я вообще-то верю, что сейчас возможно и есть парочка (помимо встроенных для пользования правительственными агентами но большая компания с очень высоким коэфициентом масштабирования вполне способна от них избавиться за разумную плату. Тебя же никто не заставляет писать идеальный код. Ты просто можешь построить многоуровневую систему защиты и дублирования функциональности, чтобы сделать систему в целом надёжнее отдельных её компонент.

Dasar

Для tcp опасна нулевая стратегия?
при наличии дыры - да

yroslavasako

а что ты называешь нулевой стратегией в tcp? Я вот как-то думал, это ничего не посылать, ничего не принимать. И допустить дыру в реализации такой стратегии ещё сложнее чем в стратегии "ничего не торговать".

Dasar

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

yroslavasako

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

soroka000

Походу вы окончательно упоролись ...
Вы в курсе, что "баги" есть и у человека в мозге?
Решение одного человека, у которого есть большой "управленческий рычаг" может разорить или даже убить много людей. Но на сколько часто это происходит?
Есть такие понятия как форс-мажор и управление рисками. Другий вопрос, что упомянутая компания (которая разорилась на бирже) либо не правильно управляла рисками, либо просто умудрилась выкинуть Zero на рулетке из миллиона делений.
Что же до спора "статическая типизация vs динамическая":
Основная задача программирования (как и вообще рационализации) — это увеличить экономическое плечо. А если по-простому — зарабатывать бабло.
Если грубо говоря одинаковый (в плане квалификации) человеко-час на языке X приносит больше прибыли, чем человеко-час на языке Y, то какой смысл использовать язык Y? (в прибыли я тут подразумеваю заложенные риски в плане багов)
Оставить комментарий
Имя или ник:
Комментарий: