Как можно вообще писать на этой динамике?

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

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

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

Если такой умный - спроектируй мне вот этот экран в виде набора мелких изолированных компонент.

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

А как ты думал пишется медицинский софт? За миллиарды денег коммандами по 100 человек на сишке? Я тебя расстрою. Js еще не самый плохой вариант. В больнице до сих пор куча софта на дельфях, VBA (да, да - скрипты в экселе), 1С (нет, не бухгалтерия, а именно софт использующийся в лечебных процессах) и прочем фокспро.

Зачем мне на халяву делать твою проприетарную работу :) ? Плачься дальше и мечтай как перепишешь все на тайпскрипт.

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

Вот веришь, нет - 0 минут и 0 секунд экономии. Если я заранее не знаю что за набор свойств у меня будет в объекте - написать Map<String, Object> properties - не так и сложно. У меня даже целых два таких свойства у объектов на весь проект есть.

Сколько времени теряешь на секс с рефакторингом и тесты и сколько времени экономишь на более компактном коде и отсутсвии сверхусложненных иерархий типов (man Scala collections) когда нужно сделать что-то нетривиальное (man Scala collections).

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

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

Почему моветон? Если язык говно by design, но по каким то причинам получил достаточную распространенность - еще не делает его хорошим. Как автовазовскую классику не делает хорошей машиной то, что 30 лет на ней вся страна ездила.

Обожаю лоровских комментаторов. Обосрать и спрятаться в кусты - это же так круто! =))

на дельфях
VBA
1С
фокспро

в этом списке только 1С говно и замена в виде JS была бы оправдана
а в остальных случайх софт понадёжнее будет

Если язык говно by design, но по каким то причинам получил достаточную распространенность - еще не делает его хорошим

тогда зачем проект на говне пишешь?

А на чем еще, если все хотят веб морду? Или у нас браузеры еще чему то научились? ;)

Есть конечно вариант писать на чем то, в этот js компилируемом, но там тоже своих подводных камней наверняка хватает.

Ассенизаторы тоже нужны.

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

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

сколько времени они сэкономили благодаря динамической типизации.

Так, интересно...

> сколько времени экономишь на более компактном коде и отсутсвии сверхусложненных иерархий типов

Чо, серьёзно? Откуда там взялся «более компактный» код?

С/C++ все делает лучше

1) C и C++ — разные языки.

2) C++ ни в какой области не является лучшим.

3) Fortran, ЕМНИМЭ, лидирует по качеству оптимизации.

Откуда там взялся «более компактный» код?

Засчет гибкости.

И нафига она так нужна эта гибкость в промышленном коде, когда чуть ли не половина его - злобная и тупая валидация входных параметрв. Сплошные if, if, if и хрен их куда денешь. Из последнего на что я смотрел, единственный язык, который экономит кучу кода, это, surprize! статически типизированный kotlin со своими http://kotlinlang.org/docs/reference/null-safety.html#safe-calls

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

Рефакторинг ради рефакторинга нахер не нужен. Если же речь идет об улучшении/расширении архитектуры, это как раз в Ъ-динамике делается тривиально, ибо не приходится каждый раз переписывать каждый кусок кода в отдельности. Имеется возможность отнаследовать класс от класса, и клепать объекты уже от него. Можно нагородить над любым существующим классом суперкласс. То есть, легко расширяем приложение как вверх так и вниз, практически не трогая кода. И все будет консистентно. Но это касается только Ъ-динамики, пистоноговно и прочая х*ня сюда не относится.

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

Синим воротничкам не нужна, для них есть Java, ++ и прочее. В целом же, иногда выгодно нанимать хороших специалистов, которые смогут быстро и качественно написать основу приложения, особенно, когда нужна сложная логика.

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

Ты прав.

Иногда - выгодно. Ровно до момента появления первого рабочего прототипа. Под который выбивается бабло из инвесторов (в росии - государства) на допиливание этого поделия. Потом поделие выкидывается и переписывается силами комманды не выебывающихся среднячков на яве/шарпе/плюсах.

Чё ты маешься, у тебя же жава не серваке, вот и отдавай клиентам готовые хтмлки. Нафига тебе со скриптом бороться?

Там кроме графиков - еще довольно много сложных форм. Если я на каждый чих буду дергать сервак для рендеринга html-я - выйдет лютый неюзабельный звиздец.

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

JS для сильных, опытных программистов

я слышал что даже бомжи на нем кодят

Я слышал, что ты бомж.

недалеко от истины ;) да и лично по моему мнению сейчас безопасней не иметь прописки, пусть это типа и незаконно.

Во первых это не обязательно делать на каждый чих.

Ну, если вообще не использовать client side скриптов - то придется на каждый.

А во вторых неужели у тебя внутренняя сеть такое гавно?

У меня сеть нормальная. Но это не внутреннее решение. А вот у заказчиков очень по разному бывает. Иногда приходится работать и через еле дышашщий вайфай.

Кстати, я вообще сейчас осваиваю Angular и ES, но УЖЕ обнаружил, что для безопасности своих ног имеет смысл:
- на серваке сформировать JSON
- на клиенте его забрать, и раскидать в объекты
- на клиенте использовать уже объекты

Да, лишняя сущность, но сильно упрощает.

Да, возможно. Только в данном случае не поможет :( Объекты на клиенте точно так же придется выправлять и менять, а статического анализатора в голом js нет и не предвидится.

И flow и typescript это superset JS, ты можешь их начать использовать не переписывая весь код.

Предлагаю еще посмотреть React+Flux, как более ногобезопасный. Angular, кмк, стоит ждать 2 версию перед тем как учить. Если план - лепить круды, то Ember еще не плохой вариант.

Я один пытаюсь сделать проект «для души», узкоспециализированная смесь магазина с вики и прочим, с перспективой, при этом фронт-энд должен быть и на мобилках - пока в моём случае лучше всего на мобилках кордова с ангуляром (не тормозит на 512к оперативы, удобно), минимум портирования с веба, ну и ангуляр с bootstrap-ui покрывают мои нужды. Естественно, стараюсь никаких уродских трюков не делать, чтобы ничего не текло и не тормозило.

1С (нет, не бухгалтерия, а именно софт использующийся в лечебных процессах)

А какого рода софт? Если учетные системы любой сложности с умеренно сложным взаимодействием с аппаратурой, я бы ни на чем другом для больницы и не писал. Собственно, и занимался этим в свое время 6 лет подряд.

подписался на тред, ожидаю 10 страниц

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

Фигушки, заглох срач почему-то.

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

JS пахнет деньгами) не хочешь писать на нём? Нет времени объяснять, просто начинай жевать мозоль))

Ты мне еще на 1с пописать посоветуй! =)

тогда получается проблема то не в js или еще чем то, где интеграционные тесты которые это отловят?

У тебя же там 1С софт? )) ситуация у тебя одна, а ты мечтаешь чтоб она была совершенно другая))

Есть задача, ты можешь её решить...хоть метод тебе и не нравится. Но ты ведь согласен работать на этой работе. Зачем страдать. Забей

Тред не читай, вопросы задавай ;)

Я там, насколько помню, выше писал что проблемы в куске, слабо поддающемся покрытию тестами.

Да и вообще, какого хрена я должен писать кучу тестов на то, что в нормальных языках отлавливается компилятором или статическим анализатором?

Есть задача, ты можешь её решить...хоть метод тебе и не нравится. Но ты ведь согласен работать на этой работе. Зачем страдать. Забей

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

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

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

Ну и выше вроде советовали — узкие места нужно сбивать в одно место. И лучше пусть там будут какие-то отдельные ф-ции/методы, которые будут принимать аргументы, а не манипулировать переменными из скопа выше (объекты один хрен там по ссылке). Тогда и исправлять будешь только в одном месте.

Да и вообще, какого хрена я должен писать кучу тестов на то, что в нормальных языках отлавливается компилятором или статическим анализатором?

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

Никого кидать не надо) просто решай задачу, не принимая всё близко к сердцу)

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

Хреновая, если честно, суть. В нормальном языке у меня есть выбор - оставить проверки на откуп компиляторам (что вполне работает в 98% случаев) или написать все через Map<String, Object> проверяя самому. А тут приходится либо кучу тестов на каждый чих городить, либо мучатся с поддержкой.

Ты концентрируешься на минусах динамических языков. У них есть и плюсы. Добавить метод всем объектам? Легко. Добавить метод конкретно этому объекту? Легко. Написать функцию, принимающую любой объект, в котором есть функция «кря»? Легко. И всё это без головной боли, связанной с типами.