JS для сильных, опытных программистов, которые не ошибаются

Гы


ГыГы

Как вообще люди в здравом уме соглашаются на этом дерьме писать?

вот уже третий час сижу вылавливаю баги.

Ну вот и поведай нам как ты на это согласился.

Тем, что компилятор во всех местах при попытке обращения к старой структуре выдал бы ошибку.

Т.е. у нас есть класс А:

public class А {

  public List<Parameter> parameters;

}

Меняем его на

public class А {

  public List<Group> groups;

  public static class Group {
    public String groupName;
    public List<Parameter> parameters;
  }
}

А теперь у меня компилятор сам отловит

public void doSmth(A a) {
  log.info(a.parameters); //Ошибка компиляции
}

Я там оратору выше ответил. С примерами.

Некому больше пока. Как позволит бюджет - наймем отдельного разработчика под морду.

У тебя в языке дублируется та же структура, что с сервера приходит?

Ехал JSON через JSON… :}

js, ненависть

что-то слишком часто я вижу эту комбинацию

Дай угадаю. Жаба-быдло?

На клиенте? Да. Используется серверная структура.

Предлагаешь гонять на веб морду XML?

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

А JS не только динамически-типизированный, в нем еще есть позднее динамическое связывание, прям как в смоллтоке, поэтому он такой выразительный. Для быдла это полный абзац, конечно:)

Ну возьми и в скриптопараше тоже везде поправь поиском обращение к parameters.

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

JS не только динамически-типизированный, в нем еще есть позднее динамическое связывание, прям как в смоллтоке, поэтому его так любят безработные акробаты вроде анонiмуса

/fixed

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

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

Был бы JS нормальным языком - у меня были бы на клиенте дублирующие (ну или, как вариант - сгенеренные по серверным) структуры данных. Поменял в одном месте - будь добр поменяй в другом. Иначе получишь либо А) ошибку сериализации, если забыл поменять либо Б) ошибку компилятора/статического анализатора если поменял структуры, а код нет. Но js в такое не умеет.

Я о коде же, ну.

Вот после нескольких часов секса с поиском и выправлением скриптов этот пост и родился.

См. второй абзац

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

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

В статических языках система типов вынудила бы тебя написать подобную функцию (или другим способом описать структуру данных). В js у тебя был выбор как поступать, и ты выбрал неправильно.

Всё как обычно.

Еще раз - добавилось энное количество новых требований, в том числе и к визуальной части. Т.е. даже если бы визуалка работала со своими, отдельными структурами данных, их бы точно так же пришлось переделывать. И без статической типизации это вылилось бы в точно такой же, а то еще и больший pain in the ass (поскольку пришлось бы править еще и конвертер данных сервер <-> клиент).

Размазанная архитектура, видать.

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

Еще раз объясняю, для не читающих тред. Поменялись требования в.т.ч. к визуалке. И структуры с которыми она работает - точно так же пришлось бы менять. С ровно таким же anal pain.

Но ведь за него только может последние три года взялись. До этого JavaScript был просто высером. Все пилили флеши, сервелаты, Adobe Air, JavaFX, только потом разрабы браузеров выскочили с HTML5+CSS3 и активной разработкой JavaScript и уложили всех лицом на пол. Так что с ES6 я бы сказал что они даже не «медлили», а наоборот, «неожидано подсуетились»

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

Ругать языки программирования кроме совсем неактуальных - моветон. Неактуальный язык - язык программирования в нише которого есть популярный язык который все делает лучше. Пример неактуального - Perl, когда есть Python и Ruby. Ruby и Python по отношению к друг другу пока не являются неактуальными, так как один хрен только в профиль. Пример неактуального - Fortran. С/C++ все делает лучше, включая все ниши Fortran кроме поддержки существующего Fortran кода, что не считается. JavaScript никак не попадает под неактуальный, так как в его нише много языков работающих лучше (Dart, TypeScript), но они не популярны. Потому ругать его - ругать стену, все равно пойдешь писать на нем код. Не хочешь писать - иди меняй, но потом окажешься в катастрофически малом community. Безумству храбрых поем мне песнь. Конечно pet-projects и простенькие стартапы - другое дело

А в чем проблема-то?

Неужто ты не в силах изменения в CGI сразу же отразить изменениями в жабоскрипте?

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

Ругать языки программирования кроме совсем неактуальных - моветон.

Говно нужно называть говном. То, что говно популярно, и то, что ты вынужден его использовать, не играет роли.

Анонимус имеет мнение

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

Но таки да, языки без статического анализа - дерьмо.

Вот что интересно, одно из наиговнейших (после пхытона) говен — це++ — чуть ли не соперничает с сишечкой! Вот как такой маразм мог получиться?

Анонимус недоумевает

Поменялись требования в.т.ч. к визуалке. И структуры с которыми она работает - точно так же пришлось бы менять. С ровно таким же anal pain.

Каким образом статика спасла бы тебя от этого геморроя? Структуры один фиг пришлось бы менять.

це++ — чуть ли не соперничает с сишечкой!

эскобар.жпг

дело не столько в динамике, сколько в том, что js и web

и не лениться писать юнит-тесты

Бюджет проекта крайне ограничен пока.
Как только будет бабло - наймем отдельного человека на написание морды

он таким и останется, бабла не будет
ты студент штоле?
по-моему заниматься подобными проектами себе дороже

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

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

на эту структуру куча логики клиентской завязана.

Вообще говоря если у тебя это структура RPC то есть API то надо какбы юзаеть ее через единую точку на клиенте, и добавлять туда версию апи - тогда при таком рефакторинге ты сможешь в эту единую точку вкорячить костыль преобразующий новую струкртуру в старую для legacy кода (а там где тебе нужна новая структура укажешь RPC коду что понимаешь новую версию API )

Типизированные языки (нет не C++) можно отрефакторить из IDE.

Код не размазан ... Но модули большие и хитровыебаные.

/0

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

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

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

Планирование никак не гарантирует отсутствие изменений в условиях и необходимость рефакторинга. А юнит-тесты как замена проверки компилятором - говно (хотя для динамики выхода нет).

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

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

Примерно вот такой http://pastebin.com/f5WvGsER

медицинский софт на JS ?
ещё и до кучи почти нет финансирования?
это что за трэш вообще?!?!?

Ты не понял. Тебе как бы намекнули, что программист на JS обязан быть программистом по-определению, иначе он сможет родить только обезьяний код, вроде того, что родил ТС. Для жаба-мартышек это не обязательно. Улавливаешь разницу?

Все критичные параметры жизнедеятельности мониторятся напрямую на прикроватнике/аппарте ивл.

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

Это не трэш, это Россия.

чтобы компилятор проверял

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

Вот такая вот веселая жЫсть у обезьян. Ну вот почему эти ыдыоты все пытаются себе на жопу приключений найти? А ведь просто надо вместо сраного сыплусплус нормальлный ЯП использовать!

Нет ЯП кроме сишечки, и керничи — пророк его!

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

Представь себе мартышку

okay.jpg