на один ооп язык не предоставляет вам информации о том, как надо отображать объект.
потому вам надо что то дополняющее те метаданные которые вы можете вытащить например через рефлекшен в java, через систему метаданных в Qt или другие механизмы в вашем языке.
например вам надо отображать поле с типом Integer. какой контролс следует использовать системе генерации «формы редактирования по умолчанию» — поле ввода с калькулятор-дроп-дауном, поле со стрелочками вверх-вниз как в хроме, или может быть скроллер для повышения визуальности? где указать допустимые для ввода границы что бы еще на этапе ввода отсечь нежелательные значения?
метаданные синхронизируют в этих вопросах поведение универсальных механизмов MVC. метаданные, если можно так сказать, выступают 4м элементом, которые позволяют в одном месте указать информацию которой будут пользоваться и «модель», и «контроллер», и «вид». они по прежнему отвечают каждый за свое как и надо в модели MVC, но универсальные механизмы имеющиеся в каждой из этих частей, используют информацию из метаданных для того, что бы работа была синхронизированна.
можедь знала что надо обработать поле с числом типа int, контроллер что надо позволять только отрицательные числа от 0 до -20, а вид — что надо использовать дропдаун с выбором значения.
имхо — в пределах погрешности 1 фут/с т.е. примерно 0.25 м/с — конечно, лучше еще меньше, но просто точнее измерять «штатные китайские хронографы» не умеют и в итоге результатов точнее пока не зафиксированно.
( вы же заметили что все значения у них это строго х.2 м/с, х.4 м/с, х7м/с или тому подобный ряд цифр с разрывами в .2-0.3 м/с? у нас родилось объяснение что внутри они считают все в футах, а потом переводят в метры, отсюда и такой странный ряд значений через .2 или через .3).
что бы достичь таких показателей с аег — вам надо будет «шимить» и тюнить «очень долго и
и очень проблемно», плюс держать аег будет эти показатели не долго. просто потому что это механика и она сложная.
а с хорошей ввд системой управляемой электронно — вам это будет сделать гораздо проще, и держаться в таком состоянии она будет не в пример дольше. просто потому что механики там кроме клапанов — нет. остнется проблема хопапа, хороших шаров, чистки ствола и «натекания» если регулятор плохой, но это решается устновкой хорошего регулятора, подбором комплектующих для первых трех элементов и нехитрым обслуживанием типа почистить ствол и закупкой хороших шаров. имхо, вы и сами это прекрасно знаете.
ну еще стволик тоже лучше бы подлиннее. имхо ))
без полновесной системы метаданных, увязывающей как бд так и шаблонизатор — не выйдет, имхо.
а это задача куда больше чем «фреймворк для генерации формочек».
что бы генерировать типовую форму ввода/просмотра вам надо держать в синхронизации и структуры данных с типами, и описания того как вам это отображать (тупо какой контролс использовать для какого типа и когда), и еще иметь механизм не только построения форм, но и наполнения этих форм данными и получения данных обратно. не говоря про валидацию.
при этом этот «механизм построения формочек» должен еще уметь расширять бизнес логику работы этой самой формы — под различные варианты алгоритмов валидации.
и это еще не обсуждены вопросы реструктуризации бд и гуи, когда у вас изменятся структуры данных.
силами js -фреймворка это все не решить. это должна быть единая связка между серверной системой с метаданными, орм, механизмом генерации и управления гуи, механизмами действующими на клиенте для отображения этой формы.
создать такое «в популярном подходе», когда у тебя есть некий бек с рест-ушками и есть толстый js — принципиально невозможно или крайне затруднительно как по затратам так и идеологически — просто потому бек и фронт в современных «модно-молодежных подходах» к разработке разделяются или даже, по сути, противопоставляются — у вас практически нет производителя который бы все связал в единое целое.
есть плагины гуи-фреймворков для ноды, но это, имхо, больно уж походит на франкенштейна, взаимодействие все равно остается ращорванным рест-сервисами, а генерации гуи по метаданным нет.
из того что связывает «воедино фронт и бек» вспоминается только 1с и qt (которые могут собрать приложение и в виде сервера с веб формой управляемой через вебсокет. но у qt нет метаданных связанных с орм и генерацией гуи. собственно, и орм то в свое время для qt я писал сам)
не стоит этого ждать решений такого рода от массовых фреймворков заточеных под массовый веб-js-девелопмент «бложеков и вконтактиков» и потому, что эта область просто не содержит задач такой сложности — требующей генерации интерфейса работы с данными. потому не ищите js-фреймворков.
не под автоматизацию бизнес-процессов они все заточены.
т.е. все они «муссируют» идею массового веба, простых процессов и максимальной разгрузки сервера с выносом бизнес процессов на клиента. именно в этой области работают большая часть тех, кто голосует «фреймворк не нужен, учитесь пользоваться тем что дают»)) и не стоит удивляться что таковых в пересчете на число душ — большинство.
но помимо массового веб, есть корпоративный веб. который по сути вебом не является. это бизнес системы, а веб-интерфейс у них только как дань моде и доступен он в интранете и только.
и вам, имхо, надо искать решение в этой области, когда у вас нет массового доступа к системе, сложные бизнес процессы со сложной валидацией данных.
именно тут вам часто нужно генерить многие формы автоматически, потому что они типовые: когда у тебя 20 справочников различающихся только атрибутами — рисовать под них формы просмотра, редактирования и т.п. руками — часто тупо геморройно.
теперь что есть: из схожего — есть изделия «кровавого интерпрайза» от hp / ibm / etc, но с этими монстрами встречаться не хочется. костылей там много, и это что ни на есть тот самый кровавый интерпрайз который тянется из ранних эпох становления веб-интерфейсов и даже самих идей работы с метаданными.
из менее крового и достаточно функционального — идейно смотрите на систему метаданных 1С, аналогов которой имхо, все таки ни у кого нет. даже той системы метаданных какая была в 7.7.
к достоинствам 1С скажу что часто вознкают учетные задачи и вот чего точно не хватает в java-фреймворках — это не только их системы метаданных, но и их учетных механизмов — тех-же регистров.
я бы очень хотел видеть такое например в java но увы, ничего кроме собственных наработок нет, а публиковать наши фрейворки мы не будем как минимум еще полгода, тем более бесплатно.
и до 1С мы во многом не дотягиваем, хотя нам пока вроде хватает — мы освоили метаданные, орм, основы автогенерации форм, шаблонизацию, работу с клиентом и с генеренными формами и тп.
но т.к. это не будет публично еще какое то время — потому, увы — «пилите сами», тем более если на go. смотрите как работает механизм метаданных в 1С и думайте как это увязать в классическую клиент серверную архитектуру. у меня на то что бы получить более-менее стройный вариант для веб — ушло несколько попыток. и несколько лет )
не могу с вами согласиться. как минимум не полностью.
хорошую кучность обеспечивает повторяемость параметров выстрела.
естественно, что хопап играет роль, просто потому что это «часть комплекса», но имхо, не меньший объем проблем создает именно сам «aeg-подход» с моторчиком и оттягиванием «лязгающей пружины».
хотите укладывать 8 из 10 в ростовую на 100 метрах? — переходите на ввд, причем именно на ввд с клапанами контролируемыми электроникой, и, желательно, с раздельным управлением клапаном и движением ноззла.
поддержу автора. редизайн «сам по себе» нафиг не нужен.
особенно, если в угоду улучшения графического дизайна жертвуют функциональным дизайном, осознанно или нет.
не раз был свидетелем, когда приложение после «редизайна» теряло часть функциональности,
или делало доступ к функциям дико НЕ удобным.
иногда о полезных моментах просто забывают, потому что «это не особо документированно», или новый дизайнер просто не в курсе, что «вот эти 2 элемента рядом» — это «ну вот ппц как удобно» для целевой адитории.
иногда сама новая концепция или стиль дизайна не предполагает той сложности иртерфейса, которая нужна что бы эффективно пользоваться приложением. посмотрите на ленточный интерфейс офисов после 2007 г. красиво, но функциональное уродство. при сравнении со старыми многокнопочными интерфейсами скорость работы упала раза в 2. при малейшем сдвиге размеров элементы начинают менять свой размер и положение — в итоге я ищу большую кнопку с одной картинкой, а нахожу другую кнопку, маленькую и с непохожей иконкой. это разве удобство ?)))
а часть функцийю просто убрали, потому что не помещаются — кнопки то большие.
вывод? его заредизайнили не ради удобства, а ради непохожести на опен-офис.
а потом многочисленные последователи моде начали переводить свои приложения на можную ленту, и убивать функциональность.
или взять модный паттерн в дизайне сайтов — все в один столбик, или как он там называется. попытка пересвести на него сайт, у которого больше 2х старниц текста на всем сайте — преврашает попытку что либо найти на нем — в бесконечное пролистывание экранов.
«все в один столбик» — хороший паттерн, красивый, но только если у тебя 3 раздела на сайте. а если их 5 и с полразделами — не надо делать в таком стиле даже лендинг.
то сразу говорит о том, что мода съела ваш мозг и рассулительности в нем не осталось.
хотя, все, конечно, зависит от вашей целевой аудитории.
как сказано в одной книжке по дизайну интерфейсов — именно по функциональному дизайну, а не графическому — если вы сделаете интерфейс «только как для идиотов», то и пользоваться вашим приложением будут только идиоты.
А вот скажите — он похож на Телеграмм только скринами, или юзабилити и механика тоже?
Можно сколько угодно рассуждать про безопасность и прочее… но пока не будет нормального юзабилити — не взлетит. И у телеги именно юзабилити продумано. Потому что к телеговскому клиенту у меня только одна претензия про ограничение прикрепления чатов в 5 штук. Мне надо закрепить штук 20 ))
И так. Перечислю некоторые фичи, без которых новообразованный чатик, имхо, не имеет шансов… т.е. не взлетит:
Цитирование, ссылка на сообщение, в ответ на которое ты пишешь.
— вот знаете… в скайпе цитирование тоже «формально» есть. но вот ответить на сообщение так же удобно и легко как в телеге — я не могу. Тупо не могу найти в контекстном меню «ответтиь на»… потому нафиг скайп, имхо))
Или картинки с подписями — ну нету их в скайпе. А в телеге есть, и это очень удобно.
Боты . — есть программное АПИ мейло-вконтактовского поделия?
Кроссплатформенные чаты и клиенты. Десктоп линукс? мобильный клиент для андроида? есть?
Кто пользовал новое изделие — скажите как там с этим?
Я наблюдал высшую степень «велосеподофобии», когда фобия начинает поглощаться «стокгольмским синдромом» вместе с «синдромом мокрой обезьяны и непритрагиваемого банана».
Т.е.: те, кого били по рукам, начинают не просто бить по рукам, но ведут бездумную, яростную, фанатичную «охоту на ведьм». Они, не понимая почему их били по рукам, начинают бить по рукам всех без разбору, даже в том случае, когда «по их мнению, велосипед» является обоснованным и едва ли не единственным для данной ситуации решением.
Они не могут объяснить почему это плохо или хорошо; они знают что «есть типовое», а раз есть — его надо использовать любой ценой,
т.е. использование типового решения становится самоцелью, а не средством решения проблем
Они не понимают, что стандартные типовые решения, как и любые решения, имеют пусть и большую, но ограниченную область применения, и попытка воткнуть их «вот в этом конкретном случае» — будет не просто попыткой забивать экскаватором гвозди, она приведет к серьезным переработкам.
Как бы вы знали, как меня достала эта охота на ведьм! оох. (и даже без смайлика, да, действительно достало.)
Товарищи! ) Давайте уже объяснять новичкам почему их бьют по рукам, и что иногда надо, надо, надо писать «велосипеды».
Поддерживаю автора — чем больше у вас опыта и понимания, тем больше шансов что ваш «велосипед», станет именно тем, что нужно тут и сейчас.
Велосипеды писать надо.
Даже не потому что это поможет им понять почему типовые решения сделаны так, как они сделаны.
Просто потому, что как минимум иногда проекту крайне необходимо решение, у которого
седло по форме твоего седалища, руль кривизной под твои руки, а на колесах выемки строго по форме выбоин на дороге, по который вы сейчас едете!
ps: тут, главное, не забыть сказать, что нельзя впадать в другую крайность: далеко не всегда такое 'частное велосипедное решение' стоит потом повторно использовать, или пускать в массы. Согласитесь — тонны новоявленных языков да фреймворков, которые рождаются буквально каждый день и дохнут так же быстро как стада леммингов при миграции — это как бы намекает, что нельзя все подряд велосипеды пытаться пускать в массовость )
А «обычные» — это какие именно значения? Более конкретно, меня интересует content type: должно указать «multipart/form-data», «application/json», «application/javascript», «text/plain» или что-то иное или это не важно?
К статье нужен или пример http-запроса со всеми заголовками и содержимым ( что бы его можно было повторить в soap ui, или с помошью curl, wget ) или js-код который умеет отсылать запрос на сервер в подходящем формате. На базе того-же jQuery скажем — просто рабочий пример, банальная демонстрация того, что то, что вы только что собрали по данному мануалу — оно вообще-то работает )
A пример запроса и того как его отправить будут?
Меня, например, устроили бы примеры для Soap UI.
Я к чему? — для меня в данной среде и данном примере совсем не очевиден процесс сериализации/десериализации объектов в/из json/xml? Какой вариант сериализации используется тут? С какими httpзаголовками посылать запрос и тд. и тп. Нужны примеры.
Согласитесь, именно как раз «борьба активистов против токсичности» зачастую приобретает самый токсичный оттенок из всех возможных.
Очень похоже на детскую жестокость — люди которые ещё не понимают, что «они делают очень больно» — больше всех вопят о том что «больно им».
Люди которые не понимают, что их поступки разрушают рабочий процесс — зачастую больше других кричат, что им нужна «не токсичная атмосфера», подменяя понятие «токсичность» на личные обиды на критику и форму обращения.
Я буду не политкорректен. Извините.
Буду добалять, наверное, свои 5 копеек к посту.
Для начала давайте определим термин «токсичное поведение».
Я под «токсичным поведнием» понимаю поведние. Которое разрушает среду, разрушает процесс работы, мешает продуктивно и конструктивно работать, мешает выдавать качественый результат.
и вот тут не важно, грубо подается критика или нет, посылает подчиненный начальство или подопострастно пополижествует, грубо говорит старщий или коллега или нет — важно по делу это говорится или нет, решается вопрос эффективно или нет, создается хорошая it — система или нет, улучшается качество результата или нет.
к сожалению, у многих внешне грубый процесс ассоциируется с токсичным поведением. хотя, согласитесь, к токсичности грубость может не иметь никакого отношения.
действительно токсичным может быть и вежливое подлижество, мягкое «идина*****йство», «итальянская забастовка» с доброжелательной физиономией и пр… — когда все вокруг улыбаются, а дело не идет.
ну так вот. инженерам это противно. и автор статьи, как мне кажется, совершенно точно это отметил.
но к сожалению в it-среду из за «перегретого спроса» в разы превышающего предложение, начали набиваться люди имеющие к it «практически никакое» отношение.
и тот ажиотаж вокруг политкорректности и толерастии, который мы имеем в исконно грубоватой но продуктивной технической среде — это, имхо, именно следствие попыток не-технарей выжить в технарской, чуждой им, среде. они бы рады, к нам не соваться, но тут типа вакуум, а в их областях вообще тухляк… и они приходят сюда.
нескончаемый шквал смены моды, подходов, фреймворков — это из той-же оперы: когда человек плохо мыслит технически и логически — поиск серебрянной пули приобретает особенный смысл.
… хотя и авантюристов с прохвоставми в «новоделанных it -шниках» тоже хватает. вспомните истории индусов которые устраиваются на работу «вместо собрата, прохлдившего собеседование».
Хотя таких, по крайней мере у нас, вроде как, не так много, как искренне верующих в собственную профессиональность безумцев с синдромом начинающего программиста.
Ну так вот. Очень много «новых специалистов», выучивших инструменты, но у которых нет ни инженерного чуться, ни «технической жилки», ни природной предрасположенности к техническим наукам.
ну представьте, если психиатором будет работать слесарь? ну вот и тут точно так же.
Я понимаю почему они тут появились, но легче от этого не становится — они приносят сюда нечно типа бардака «бабской бухгалтерии». Не хочу ни кого обидеть, простите, но вы поняли о чем я — подковерщина, толерастия, лицемерие, эмоциональное поведение там, где надо делать, думать и работать.Увы.
И именно такое поведение разрушает рабочую среду.
Что делать? Я не знаю. Но это данность. Они сюда пришли, и пока потребность даже в таких «пожизненных неофитах», думающих эмоциями, а не головой не исчезнет, — они никуда не денутся.
А потребрость ни куда не денется. особенно в условиях техногенной цивилизации и неспособности системы образования не убить природную предрасположенность к инженерным наукам в большинстве людей, исходно имеющих от природы техническую жилку.
Что делать? не уверен что знаю.
Пока же для лиц, не способных отличить объективную критику от личностных наездов (как при прослушивании так и высказывающих ), имеющих сложности с техническим мышлением и преобладающим эмоциональным восприятием, но пытающихся работать в it в технических ролях, вопящих сверх разумного про токсичномть — предлагаю ввести термин «it-меньшинства»..
именно так.
И обращаться с людьми, которые ведет себя действительно токсично(*) именно так же, как с «агрессивным подмножеством лгбт »: вежливо и аккуратно, но пусть идут общаться с разделяющими их интересы.
(*) повторюсь: под действительно токсичным поведением я понимаю поведение, приводящее к развалу конструктивного рабочего процесса
Второй вариант — ботоводить. именно в схеме «тимлид-проф и толпа младших». к сожалению это тоже сложно, потому что живущие эмоциями часто плохо воспринимают прямые технические указания. самость не позволяет. им же на курсах скзали, что они тепеоь профессиональные программисты. потому — отбирать адекватных, растить из нтх инжееров, а с остальными, увы, как с «агрессивными it-меньшинствами». вежливо и корректно, но выводить их из среды здорового грубоватого, но объективного и аргументированного общения технарей. Пусть портят рабочий процесс у конкурентов. имхо.
Еще варианты? Не знаю.
Но что точно — нам, инженерам, необходимо взращивать в себе некую житейскую мудорость и умение работать с человеческим окружением. Эти скиллы сейчас жизненно необходимы не столько и не только для лмчного выживания, но и для сохранения отрасли. иихо.
Какими бы мы не были асоциальными от природы, как бы мерзка ипротивна эта политкорректность не была местами — эти скиллы нужны.
Хотя бы просто ради того, что бы иметь навыки создать «островки чистой воды», не допустить туда действительно токсичных «толерантных», защитить области чистой воды от окружающего безумия.
Согласитесь, нам необходима среда, в которых можно просто работать. Дружески посылать друг друга нафиг, материться про код, грубо и иногда эмоционально, но конструктивно и объективно обсуждать архитектуру — вот это нужно, а не забивать себе голову фобией о том, что очередной представитель «it-меньшинств» подумает о форме твоих слов, потому что не способен понять содержимое.
Инженеры имеют право на такого рода области работы никак не меньше тех, кто громче всех кричит о своих правах и токсичном к себе поведении.
нам нужно не апи. а весь сервер. для установки на территоию заказчика.
в закрытую изолированую сеть. наружу у заказчика только sip-каналы в сотовую сеть.
гм… может я и заоффтополю, простите, но ваши менеджеры так мне и не ответили на вопрос:
нам нужна веб-версия для оффлайн сети для интеграции с нашей системой с веб-интерфейсом.
нужен веб 2GIS, с данными 2гис, постащиком тайлов(или вашим js-клиентом), поиском по улицам и объектам.
вопрос простой: когда, сколько стоит?
мы могли бы внедрить 2gis заказчику в таком варианте, но видимо надо будет довольствоваться OSM.
или вы все-таки предложите варианты? :)
Прочитал еще одну статью про «психологические типажи разработчиков». И с меня хватит. Как всегда, в этой статье предлагают узнать себя в одном из антипаттернов «плохих парней», понять, что я врежу бизнесу и начать наконец «исправляться». Я вот узнал себя в каждом типе. Я и рок-звезда, и солдат, и некомпетентный, и мечу в менеджеры…
… а бессмертную классику с родильной горячкой уже цитировали? нет? ну так я первый буду.
Как-то раз я зашел в библиотеку Британского музея, чтобы навести справку о средстве против пустячной болезни, которую я где-то подцепил,-- кажется, сенной лихорадки. Я взял справочник<...> а потом, от нечего делать, начал перелистывать книгу, просматривать то, что там сказано о разных других болезнях. <...> Несколько минут я сидел, как громом пораженный;
<...> я добросовестно перебрал все буквы алфавита, и единственная болезнь, которой я у себя не
обнаружил, была родильная горячка.<...>
Я конечно дико извиняюсь )) но вот разве в коментарии к статье о котлине нельзя написать, что "автор на примере конкретного перечня проблем в своей стаье, на самом деле иллюстрирует серьезную (мега)проблему _вообще_, которая имеет место быть не только с котлином"?
Именно это я в первом посте и написал. разве нет?
а вы начали воспринимать это как оскорбление колтина, попытку регламентирвоать назначение языков, порывались засыпать меня перечнем «фич из коробки»… ну и зачем так? ))
ладно. проехали. Нравится обсуждать конкретику, без попыток сопоставить с ситуацией вообще за пределами отдельно взятой узкой темы — ок, я не против, но я не с вами в данном направлении. Мой комментарий совсем не про конкретные микрофичи языка. не поняли друг друга, бывает.
Задачи языков программирования — очень разные, и уж точно не регламентируются третьими лицами в кулуарах обсуждений на тематических форумах.
гм… при чем тут «регламентирование»?
мы обсуждаем вектор классификации языков программирования, которые претендуют на «хоть сколько то» практическое применение. надо же как то оценивать и сранивать направленность языков и возможность их применния?)
и где и как вырабатывать такую классификацию, если не в обсуждениях между специалистаи в паблик форумах (хабр же не кулуарное обсуждение, согласитесь?)
С другой стороны, Kotlin позволяет писать гораздо быстрее. А еще у него из коробки...
стоп стоп стоп ))) пАгадите… при чем тут котлин? я нигде не наезжал на котлин, и не упоминал его, ведь правда? заметьте.
я поднимал проблему обоснованности появления новых языков, и то, что причины появления подавляющего числа языков не имеют прямых технических оснований — фичи большей части (имхо, если не подвляющего числа) «новоделов» не решают каких либо технических проблем, а скорее отражают взгляд авторов на мир и их собственную вкусовщину. с попеременным успехом это находит отклик в сердцах неофитов или склонных к чувственному восприятию мира людей. имхо.
я рад за тех кому это нравится. серьезно. но мне, признаться, несколько «все равно», из коробки там пара фич или нет… ну честно, извините. я настолько наслышан от предыдущих проповедников о прелестях их новых языков, и настолько видел, «куда эти языки ушли» вопреки рекламным проповедям, что простите, я вам, конечно, верю, но в вашу веру обращаться не буду, как минимум пока не будет на это технической необходимости. а технических оснований я не вижу — НАМ переводить джава проекты на котлин дорого и рискованно. не те ставки. не курсачи пишем.
я рад что вам это зашло, и что вам нравится (судя по вашему посту), но я вот, стараюсь выбирать средства разработки не по удобству или вкусовщине, а по степени пригодности для решения возникающих задач.
для андроида, возможно когда нибудь и переключусь с джавы, но пока вот более заходит Qt, просто потому, что более кросплатформенно.
и если говорить про котлин и моё «имхо»(если вы пытаетесь меня в чем-то убедить) то вот вам мое имхо: извините, не обижайтесь, но я не вижу чем котлин принципиально отличается от другиз jvm-языков.
ну вот сами посмотрите:
* был груви? был. где он? мода прошла, груви уходит на обочину истории оставясь узким нишевым языком для гиков.
* была скала? была. где она? мода прошла, скала уходит на обочину историию оставаясь нишевым языком для гиков.
* был клюжЮр? был… где он?..
и так далее — там еще в ряду, если верить википедии jPython, jRuby и далее…
и котлин ничем принципиально о них не отличается. извините, имхо.
если в чем и есть отличие ситуации с котлином, так это только то, что гуглю нужен «запасной аэродром» из-за постоянных нападок оракла. ни больше ни меньше, и это ни разу не связано с прелестями языка. это ситуация, «так карты сложились». они плотно дружат c jetBrains и «почему бы нет», я полностью понимаю выбор гугля…
но прошу вас, не надо рассказывать про прелести языка… если завтра гугль и оракл достигнут мирного соглашения — котлин с 90% вероятностью пойдет на обочину истории, как и его предшественники. в нишевость, в гиковость. и там ему пусть будут рады, я рад за тех кому это зашло.
все равно будем топить любое новшество просто потому что «у меня есть инструмент, я им решаю свои задачи, изучать новые инструменты мне не надо».
«не надо навешивать на меня ваших крокодильчиков» ) я такое не говорил.
я за разумные новшества, обоснованные, не приводяшие к технической неоднозначности или непонятности для разработчиков. я ЗА новшества. но за взвешенное к ним отношение.
давайте поясню на примере джавы: диамонд синтаксис — классная вещь, потому что понятно
«что пропускается» и где смотреть что пропущено, код по прежнему однощначен. это было хорошее нововведение.
А вот лямбда функции — «полнейшая фигня»)) очень сомнительно. потому что без IDE, читая текст примера кода на сайте — вы можете только догадываться о типах передаваемых параметров. это было плохое нововведение. из исходного кода делись определения тип аргументов и какие они долджны быть — из текста исходного кода не понятно.
Или вот взять проблемы перехода с 6й джавы на 7ю. Болезненно для многих, особенно банковских и др интерпрайз систем, да. Но извините, доступ к приватным методам класса через рефлекшен — это не просто не правильно, это не описано в стандарте, и по сути, сродни багу платформы. Это и убрали в 7й джаве, но сохранили обратную совместимость в рамках описанного в стандарте поведения.
понятно мое отношение к новшествам? )
(а вот теперь я буду наезжать на котлин )
Кстати, где у очередного убивцы джавы котлина — стандарт языка, описание поведения, процесс сертификации сторонних компиляторов на предмет совместимости со стандартом? котлин, вопреки заявлениям авторов языка, не сможет заменить джаву, как минимум в интерпрайз секторе, пока не сможет предоставить аналогичных стандартов и воплотить гарантии сохранения обратной совместимости в виде явного стандарта и процесса сертификации сторонних компиляторов.
извините — я это у всех проповедников новых языков программирования спрашиваю, вы не первый.
не обижайтесь, но давайте с котлином подождем года 2 или 3. вдруг там оракл и гуглем помирятся?)
или вы согласитесь со мной, в моем понимании, "почему джава успешно пережила не один сезон «убивцев джавы», и почему котлин, сам по себе, ни разу не исключение". или котлин займет нишевое положение эксклюзивно-платформенного языка, так же как свифт с иосом) — посмотрим, время покажет, не торопитесь, в общем.
вам заходит, — классно. пилите свои проекты, глядишь толк из этого выйдет. но не надо агитировать моих стажеров или меня. и хайп вокруг языка — ну прошу, не надо вот этого.., столько раз уже было, ну надоело, честное слово… глупое это дело… да и показывает вас с не лучшей стороны.
мы сами к вам придем коли потребуется.
спасибо что дочитали. удачи вам.
Апплодирую стоя! на 100% согласен с автором если не в деталях, то в сути поднимаемой им проблемы.
Поиск очередной серебрянной технологии пули, помноженный на современные технологии пиара и очковтирательства в купе с увеличением «поголовья хомячков в IT» приводят к действительно безумной ситуации.
И это проблема, т.к. ситуация приносит выгоду только желающим «погреть лапу» на семинарах/пиаре/продажеКнижОнок.
Появление новых фреймворков и языков практически не имеет никакого отношения к решению технических проблем, которые стоят перед разработчиками.
... а проблемы как валялись так и валяются.
Стада хомячков гоняются от одного «синтакс-сахорочка» к другому; новые языки придумываются потому, что кому-то не нравится _синтаксис_, а за основу берутся «примитивы» для обучения дошкольников программированию; потом эти «go-go»-новорожденыши пихается в продуктив и «буквальновсе» пиарятся что вот уже «целый гугл» использует «go-go» (ну и конечно же как самый основной язык для самого центрального сервера, а не на задворках для автоматизации скриптов подготовки данных для юнит-тестов); толпы неофитов бьтся в экстазе от того, что на эксклюзивных курсах «от новичка до профессионального программизда за 3дня» освоили очередную сакральную концепцию применимую в одном единственном языке/фреймворке; IDE выбираются не за поддержку тех или иных возможностей, а за темную или светлую тему оформления; дизайн и работу элементов интерфейса определяют «груше-дизайн-ХУДОжники», которые никогда не будут пользоваться своим «творением» за пределами презентации;… (продолжать?).
О том, что это всё — ни разу НЕ НОРМАЛЬНО — надо периодически напоминать.
Потому, что, согласитесь, задача языков программирования и it-технологий — это всё таки не радость неофита от прикосновения к сакальному и его вкусовые очущения от синтакс-сахара, а решение технических задач, однозначность кода, обеспечение прогнозируемости поведения и прозрачности структуры системы.
PS
PS: Кстати, пока вы читали этот пост, и задавались проблемами а «что же с этим всем делать», ещё 2 школьника «изобрели» «2 уникальных инновационных js-фреймворка», технологию, парадигму разработки и под это дело — целый язык программирования — с турбореактивным связыванием, интеллектуальным дополненеим кода в рантайме с угадыванеим «что имел в виду заказчик», с удобным безскобочным принудительным форматированием кода отступами, компиляцией в node.js-байткод и нивуя-себе-шаблонизацией. «Как сейчас но ещё лучше». Надежно, масштабируемо, проверено. Обкатано на 3-х лабораторных работах. 10ю коллегами автора. Уже затерроризирован учитель информатики, который будет на нем делать школьный сайт и воодушевлено 3 журналиста. Скоро будет репортаж про дизактиватор Бубкина с веб-интерфейсом на первом канале.
И это все станет популярным через 2 года. На пару месяцев. И десятке-другом продуктовых серверов. Хорошо, если только этим все и ограничится, и не нам с вами это поделие разгребать и поддерживать, после того как их авторы срулят, заметая следы, в туман рубить бабла на впаривании очередное откровения. Или просто отмахиваясь куда-подальше от монстра который они создали.
потому вам надо что то дополняющее те метаданные которые вы можете вытащить например через рефлекшен в java, через систему метаданных в Qt или другие механизмы в вашем языке.
например вам надо отображать поле с типом Integer. какой контролс следует использовать системе генерации «формы редактирования по умолчанию» — поле ввода с калькулятор-дроп-дауном, поле со стрелочками вверх-вниз как в хроме, или может быть скроллер для повышения визуальности? где указать допустимые для ввода границы что бы еще на этапе ввода отсечь нежелательные значения?
метаданные синхронизируют в этих вопросах поведение универсальных механизмов MVC. метаданные, если можно так сказать, выступают 4м элементом, которые позволяют в одном месте указать информацию которой будут пользоваться и «модель», и «контроллер», и «вид». они по прежнему отвечают каждый за свое как и надо в модели MVC, но универсальные механизмы имеющиеся в каждой из этих частей, используют информацию из метаданных для того, что бы работа была синхронизированна.
можедь знала что надо обработать поле с числом типа int, контроллер что надо позволять только отрицательные числа от 0 до -20, а вид — что надо использовать дропдаун с выбором значения.
( вы же заметили что все значения у них это строго х.2 м/с, х.4 м/с, х7м/с или тому подобный ряд цифр с разрывами в .2-0.3 м/с? у нас родилось объяснение что внутри они считают все в футах, а потом переводят в метры, отсюда и такой странный ряд значений через .2 или через .3).
что бы достичь таких показателей с аег — вам надо будет «шимить» и тюнить «очень долго и
и очень проблемно», плюс держать аег будет эти показатели не долго. просто потому что это механика и она сложная.
а с хорошей ввд системой управляемой электронно — вам это будет сделать гораздо проще, и держаться в таком состоянии она будет не в пример дольше. просто потому что механики там кроме клапанов — нет. остнется проблема хопапа, хороших шаров, чистки ствола и «натекания» если регулятор плохой, но это решается устновкой хорошего регулятора, подбором комплектующих для первых трех элементов и нехитрым обслуживанием типа почистить ствол и закупкой хороших шаров. имхо, вы и сами это прекрасно знаете.
ну еще стволик тоже лучше бы подлиннее. имхо ))
а правильные результаты хрона, это примерно вот так:
m.vk.com/photo22361296_456242289
m.vk.com/photo-36860851_456264111?list=wall-112854702_8917&from=profile
m.vk.com/photo-112854702_456239549?list=wall-112854702_6042&from=profile
m.vk.com/photo22361296_456242271?list=wall-112854702_7397&from=profile
без полновесной системы метаданных, увязывающей как бд так и шаблонизатор — не выйдет, имхо.
а это задача куда больше чем «фреймворк для генерации формочек».
что бы генерировать типовую форму ввода/просмотра вам надо держать в синхронизации и структуры данных с типами, и описания того как вам это отображать (тупо какой контролс использовать для какого типа и когда), и еще иметь механизм не только построения форм, но и наполнения этих форм данными и получения данных обратно. не говоря про валидацию.
при этом этот «механизм построения формочек» должен еще уметь расширять бизнес логику работы этой самой формы — под различные варианты алгоритмов валидации.
и это еще не обсуждены вопросы реструктуризации бд и гуи, когда у вас изменятся структуры данных.
силами js -фреймворка это все не решить. это должна быть единая связка между серверной системой с метаданными, орм, механизмом генерации и управления гуи, механизмами действующими на клиенте для отображения этой формы.
создать такое «в популярном подходе», когда у тебя есть некий бек с рест-ушками и есть толстый js — принципиально невозможно или крайне затруднительно как по затратам так и идеологически — просто потому бек и фронт в современных «модно-молодежных подходах» к разработке разделяются или даже, по сути, противопоставляются — у вас практически нет производителя который бы все связал в единое целое.
есть плагины гуи-фреймворков для ноды, но это, имхо, больно уж походит на франкенштейна, взаимодействие все равно остается ращорванным рест-сервисами, а генерации гуи по метаданным нет.
из того что связывает «воедино фронт и бек» вспоминается только 1с и qt (которые могут собрать приложение и в виде сервера с веб формой управляемой через вебсокет. но у qt нет метаданных связанных с орм и генерацией гуи. собственно, и орм то в свое время для qt я писал сам)
не стоит этого ждать решений такого рода от массовых фреймворков заточеных под массовый веб-js-девелопмент «бложеков и вконтактиков» и потому, что эта область просто не содержит задач такой сложности — требующей генерации интерфейса работы с данными. потому не ищите js-фреймворков.
не под автоматизацию бизнес-процессов они все заточены.
т.е. все они «муссируют» идею массового веба, простых процессов и максимальной разгрузки сервера с выносом бизнес процессов на клиента. именно в этой области работают большая часть тех, кто голосует «фреймворк не нужен, учитесь пользоваться тем что дают»)) и не стоит удивляться что таковых в пересчете на число душ — большинство.
но помимо массового веб, есть корпоративный веб. который по сути вебом не является. это бизнес системы, а веб-интерфейс у них только как дань моде и доступен он в интранете и только.
и вам, имхо, надо искать решение в этой области, когда у вас нет массового доступа к системе, сложные бизнес процессы со сложной валидацией данных.
именно тут вам часто нужно генерить многие формы автоматически, потому что они типовые: когда у тебя 20 справочников различающихся только атрибутами — рисовать под них формы просмотра, редактирования и т.п. руками — часто тупо геморройно.
теперь что есть: из схожего — есть изделия «кровавого интерпрайза» от hp / ibm / etc, но с этими монстрами встречаться не хочется. костылей там много, и это что ни на есть тот самый кровавый интерпрайз который тянется из ранних эпох становления веб-интерфейсов и даже самих идей работы с метаданными.
из менее крового и достаточно функционального — идейно смотрите на систему метаданных 1С, аналогов которой имхо, все таки ни у кого нет. даже той системы метаданных какая была в 7.7.
к достоинствам 1С скажу что часто вознкают учетные задачи и вот чего точно не хватает в java-фреймворках — это не только их системы метаданных, но и их учетных механизмов — тех-же регистров.
я бы очень хотел видеть такое например в java но увы, ничего кроме собственных наработок нет, а публиковать наши фрейворки мы не будем как минимум еще полгода, тем более бесплатно.
и до 1С мы во многом не дотягиваем, хотя нам пока вроде хватает — мы освоили метаданные, орм, основы автогенерации форм, шаблонизацию, работу с клиентом и с генеренными формами и тп.
но т.к. это не будет публично еще какое то время — потому, увы — «пилите сами», тем более если на go. смотрите как работает механизм метаданных в 1С и думайте как это увязать в классическую клиент серверную архитектуру. у меня на то что бы получить более-менее стройный вариант для веб — ушло несколько попыток. и несколько лет )
ну вот как-то так.)
хорошую кучность обеспечивает повторяемость параметров выстрела.
естественно, что хопап играет роль, просто потому что это «часть комплекса», но имхо, не меньший объем проблем создает именно сам «aeg-подход» с моторчиком и оттягиванием «лязгающей пружины».
хотите укладывать 8 из 10 в ростовую на 100 метрах? — переходите на ввд, причем именно на ввд с клапанами контролируемыми электроникой, и, желательно, с раздельным управлением клапаном и движением ноззла.
особенно, если в угоду улучшения графического дизайна жертвуют функциональным дизайном, осознанно или нет.
не раз был свидетелем, когда приложение после «редизайна» теряло часть функциональности,
или делало доступ к функциям дико НЕ удобным.
иногда о полезных моментах просто забывают, потому что «это не особо документированно», или новый дизайнер просто не в курсе, что «вот эти 2 элемента рядом» — это «ну вот ппц как удобно» для целевой адитории.
иногда сама новая концепция или стиль дизайна не предполагает той сложности иртерфейса, которая нужна что бы эффективно пользоваться приложением. посмотрите на ленточный интерфейс офисов после 2007 г. красиво, но функциональное уродство. при сравнении со старыми многокнопочными интерфейсами скорость работы упала раза в 2. при малейшем сдвиге размеров элементы начинают менять свой размер и положение — в итоге я ищу большую кнопку с одной картинкой, а нахожу другую кнопку, маленькую и с непохожей иконкой. это разве удобство ?)))
а часть функцийю просто убрали, потому что не помещаются — кнопки то большие.
вывод? его заредизайнили не ради удобства, а ради непохожести на опен-офис.
а потом многочисленные последователи моде начали переводить свои приложения на можную ленту, и убивать функциональность.
или взять модный паттерн в дизайне сайтов — все в один столбик, или как он там называется. попытка пересвести на него сайт, у которого больше 2х старниц текста на всем сайте — преврашает попытку что либо найти на нем — в бесконечное пролистывание экранов.
«все в один столбик» — хороший паттерн, красивый, но только если у тебя 3 раздела на сайте. а если их 5 и с полразделами — не надо делать в таком стиле даже лендинг.
то сразу говорит о том, что мода съела ваш мозг и рассулительности в нем не осталось.
хотя, все, конечно, зависит от вашей целевой аудитории.
как сказано в одной книжке по дизайну интерфейсов — именно по функциональному дизайну, а не графическому — если вы сделаете интерфейс «только как для идиотов», то и пользоваться вашим приложением будут только идиоты.
Можно сколько угодно рассуждать про безопасность и прочее… но пока не будет нормального юзабилити — не взлетит. И у телеги именно юзабилити продумано. Потому что к телеговскому клиенту у меня только одна претензия про ограничение прикрепления чатов в 5 штук. Мне надо закрепить штук 20 ))
И так. Перечислю некоторые фичи, без которых новообразованный чатик, имхо, не имеет шансов… т.е. не взлетит:
— вот знаете… в скайпе цитирование тоже «формально» есть. но вот ответить на сообщение так же удобно и легко как в телеге — я не могу. Тупо не могу найти в контекстном меню «ответтиь на»… потому нафиг скайп, имхо))
Кто пользовал новое изделие — скажите как там с этим?
Они тестят. Просто тестят.
Они верят в 100%е покрытие тестами.
Они верят что код большой код можно контролировать тестами ))
Т.е.: те, кого били по рукам, начинают не просто бить по рукам, но ведут бездумную, яростную, фанатичную «охоту на ведьм». Они, не понимая почему их били по рукам, начинают бить по рукам всех без разбору, даже в том случае, когда «по их мнению, велосипед» является обоснованным и едва ли не единственным для данной ситуации решением.
Они не могут объяснить почему это плохо или хорошо; они знают что «есть типовое», а раз есть — его надо использовать любой ценой,
Они не понимают, что стандартные типовые решения, как и любые решения, имеют пусть и большую, но ограниченную область применения, и попытка воткнуть их «вот в этом конкретном случае» — будет не просто попыткой забивать экскаватором гвозди, она приведет к серьезным переработкам.
Как бы вы знали, как меня достала эта охота на ведьм! оох.
(и даже без смайлика, да, действительно достало.)Товарищи! ) Давайте уже объяснять новичкам почему их бьют по рукам, и что иногда надо, надо, надо писать «велосипеды».
Поддерживаю автора — чем больше у вас опыта и понимания, тем больше шансов что ваш «велосипед», станет именно тем, что нужно тут и сейчас.
Велосипеды писать надо.
Даже не потому что это поможет им понять почему типовые решения сделаны так, как они сделаны.
Просто потому, что как минимум иногда проекту крайне необходимо решение, у которого
;)
ps: тут, главное, не забыть сказать, что нельзя впадать в другую крайность: далеко не всегда такое 'частное велосипедное решение' стоит потом повторно использовать, или пускать в массы. Согласитесь — тонны новоявленных языков да фреймворков, которые рождаются буквально каждый день и дохнут так же быстро как стада леммингов при миграции — это как бы намекает, что нельзя все подряд велосипеды пытаться пускать в массовость )
ясно.
А «обычные» — это какие именно значения? Более конкретно, меня интересует content type: должно указать «multipart/form-data», «application/json», «application/javascript», «text/plain» или что-то иное или это не важно?
К статье нужен или пример http-запроса со всеми заголовками и содержимым ( что бы его можно было повторить в soap ui, или с помошью curl, wget ) или js-код который умеет отсылать запрос на сервер в подходящем формате. На базе того-же jQuery скажем — просто рабочий пример, банальная демонстрация того, что то, что вы только что собрали по данному мануалу — оно вообще-то работает )
Меня, например, устроили бы примеры для Soap UI.
Я к чему? — для меня в данной среде и данном примере совсем не очевиден процесс сериализации/десериализации объектов в/из json/xml? Какой вариант сериализации используется тут? С какими httpзаголовками посылать запрос и тд. и тп. Нужны примеры.
Очень похоже на детскую жестокость — люди которые ещё не понимают, что «они делают очень больно» — больше всех вопят о том что «больно им».
Люди которые не понимают, что их поступки разрушают рабочий процесс — зачастую больше других кричат, что им нужна «не токсичная атмосфера», подменяя понятие «токсичность» на личные обиды на критику и форму обращения.
Буду добалять, наверное, свои 5 копеек к посту.
Для начала давайте определим термин «токсичное поведение».
Я под «токсичным поведнием» понимаю поведние. Которое разрушает среду, разрушает процесс работы, мешает продуктивно и конструктивно работать, мешает выдавать качественый результат.
и вот тут не важно, грубо подается критика или нет, посылает подчиненный начальство или подопострастно пополижествует, грубо говорит старщий или коллега или нет — важно по делу это говорится или нет, решается вопрос эффективно или нет, создается хорошая it — система или нет, улучшается качество результата или нет.
к сожалению, у многих внешне грубый процесс ассоциируется с токсичным поведением. хотя, согласитесь, к токсичности грубость может не иметь никакого отношения.
действительно токсичным может быть и вежливое подлижество, мягкое «идина*****йство», «итальянская забастовка» с доброжелательной физиономией и пр… — когда все вокруг улыбаются, а дело не идет.
ну так вот. инженерам это противно. и автор статьи, как мне кажется, совершенно точно это отметил.
но к сожалению в it-среду из за «перегретого спроса» в разы превышающего предложение, начали набиваться люди имеющие к it «практически никакое» отношение.
и тот ажиотаж вокруг политкорректности и толерастии, который мы имеем в исконно грубоватой но продуктивной технической среде — это, имхо, именно следствие попыток не-технарей выжить в технарской, чуждой им, среде. они бы рады, к нам не соваться, но тут типа вакуум, а в их областях вообще тухляк… и они приходят сюда.
нескончаемый шквал смены моды, подходов, фреймворков — это из той-же оперы: когда человек плохо мыслит технически и логически — поиск серебрянной пули приобретает особенный смысл.
… хотя и авантюристов с прохвоставми в «новоделанных it -шниках» тоже хватает. вспомните истории индусов которые устраиваются на работу «вместо собрата, прохлдившего собеседование».
Хотя таких, по крайней мере у нас, вроде как, не так много, как искренне верующих в собственную профессиональность безумцев с синдромом начинающего программиста.
Ну так вот. Очень много «новых специалистов», выучивших инструменты, но у которых нет ни инженерного чуться, ни «технической жилки», ни природной предрасположенности к техническим наукам.
ну представьте, если психиатором будет работать слесарь? ну вот и тут точно так же.
Я понимаю почему они тут появились, но легче от этого не становится — они приносят сюда нечно типа бардака «бабской бухгалтерии». Не хочу ни кого обидеть, простите, но вы поняли о чем я — подковерщина, толерастия, лицемерие, эмоциональное поведение там, где надо делать, думать и работать.Увы.
И именно такое поведение разрушает рабочую среду.
Что делать? Я не знаю. Но это данность. Они сюда пришли, и пока потребность даже в таких «пожизненных неофитах», думающих эмоциями, а не головой не исчезнет, — они никуда не денутся.
А потребрость ни куда не денется. особенно в условиях техногенной цивилизации и неспособности системы образования не убить природную предрасположенность к инженерным наукам в большинстве людей, исходно имеющих от природы техническую жилку.
Что делать? не уверен что знаю.
Пока же для лиц, не способных отличить объективную критику от личностных наездов (как при прослушивании так и высказывающих ), имеющих сложности с техническим мышлением и преобладающим эмоциональным восприятием, но пытающихся работать в it в технических ролях, вопящих сверх разумного про токсичномть — предлагаю ввести термин «it-меньшинства»..
именно так.
И обращаться с людьми, которые ведет себя действительно токсично(*) именно так же, как с «агрессивным подмножеством лгбт »: вежливо и аккуратно, но пусть идут общаться с разделяющими их интересы.
(*) повторюсь: под действительно токсичным поведением я понимаю поведение, приводящее к развалу конструктивного рабочего процесса
Второй вариант — ботоводить. именно в схеме «тимлид-проф и толпа младших». к сожалению это тоже сложно, потому что живущие эмоциями часто плохо воспринимают прямые технические указания. самость не позволяет. им же на курсах скзали, что они тепеоь профессиональные программисты. потому — отбирать адекватных, растить из нтх инжееров, а с остальными, увы, как с «агрессивными it-меньшинствами». вежливо и корректно, но выводить их из среды здорового грубоватого, но объективного и аргументированного общения технарей. Пусть портят рабочий процесс у конкурентов. имхо.
Еще варианты? Не знаю.
Но что точно — нам, инженерам, необходимо взращивать в себе некую житейскую мудорость и умение работать с человеческим окружением. Эти скиллы сейчас жизненно необходимы не столько и не только для лмчного выживания, но и для сохранения отрасли. иихо.
Какими бы мы не были асоциальными от природы, как бы мерзка ипротивна эта политкорректность не была местами — эти скиллы нужны.
Хотя бы просто ради того, что бы иметь навыки создать «островки чистой воды», не допустить туда действительно токсичных «толерантных», защитить области чистой воды от окружающего безумия.
Согласитесь, нам необходима среда, в которых можно просто работать. Дружески посылать друг друга нафиг, материться про код, грубо и иногда эмоционально, но конструктивно и объективно обсуждать архитектуру — вот это нужно, а не забивать себе голову фобией о том, что очередной представитель «it-меньшинств» подумает о форме твоих слов, потому что не способен понять содержимое.
Инженеры имеют право на такого рода области работы никак не меньше тех, кто громче всех кричит о своих правах и токсичном к себе поведении.
в закрытую изолированую сеть. наружу у заказчика только sip-каналы в сотовую сеть.
нам нужна веб-версия для оффлайн сети для интеграции с нашей системой с веб-интерфейсом.
нужен веб 2GIS, с данными 2гис, постащиком тайлов(или вашим js-клиентом), поиском по улицам и объектам.
вопрос простой: когда, сколько стоит?
мы могли бы внедрить 2gis заказчику в таком варианте, но видимо надо будет довольствоваться OSM.
или вы все-таки предложите варианты? :)
… а бессмертную классику с родильной горячкой уже цитировали? нет? ну так я первый буду.
намек понят? или нало разъяснять ?)))
Именно это я в первом посте и написал. разве нет?
а вы начали воспринимать это как оскорбление колтина, попытку регламентирвоать назначение языков, порывались засыпать меня перечнем «фич из коробки»… ну и зачем так? ))
ладно. проехали. Нравится обсуждать конкретику, без попыток сопоставить с ситуацией вообще за пределами отдельно взятой узкой темы — ок, я не против, но я не с вами в данном направлении. Мой комментарий совсем не про конкретные микрофичи языка. не поняли друг друга, бывает.
«форканул? убери за собой!».
«опять нафоркал и не убрал?!»
:)
гм… при чем тут «регламентирование»?
мы обсуждаем вектор классификации языков программирования, которые претендуют на «хоть сколько то» практическое применение. надо же как то оценивать и сранивать направленность языков и возможность их применния?)
и где и как вырабатывать такую классификацию, если не в обсуждениях между специалистаи в паблик форумах (хабр же не кулуарное обсуждение, согласитесь?)
стоп стоп стоп ))) пАгадите… при чем тут котлин? я нигде не наезжал на котлин, и не упоминал его, ведь правда? заметьте.
я поднимал проблему обоснованности появления новых языков, и то, что причины появления подавляющего числа языков не имеют прямых технических оснований — фичи большей части (имхо, если не подвляющего числа) «новоделов» не решают каких либо технических проблем, а скорее отражают взгляд авторов на мир и их собственную вкусовщину. с попеременным успехом это находит отклик в сердцах неофитов или склонных к чувственному восприятию мира людей. имхо.
я рад за тех кому это нравится. серьезно. но мне, признаться, несколько «все равно», из коробки там пара фич или нет… ну честно, извините. я настолько наслышан от предыдущих проповедников о прелестях их новых языков, и настолько видел, «куда эти языки ушли» вопреки рекламным проповедям, что простите, я вам, конечно, верю, но в вашу веру обращаться не буду, как минимум пока не будет на это технической необходимости. а технических оснований я не вижу — НАМ переводить джава проекты на котлин дорого и рискованно. не те ставки. не курсачи пишем.
я рад что вам это зашло, и что вам нравится (судя по вашему посту), но я вот, стараюсь выбирать средства разработки не по удобству или вкусовщине, а по степени пригодности для решения возникающих задач.
для андроида, возможно когда нибудь и переключусь с джавы, но пока вот более заходит Qt, просто потому, что более кросплатформенно.
и если говорить про котлин и моё «имхо»(если вы пытаетесь меня в чем-то убедить) то вот вам мое имхо: извините, не обижайтесь, но я не вижу чем котлин принципиально отличается от другиз jvm-языков.
ну вот сами посмотрите:
* был груви? был. где он? мода прошла, груви уходит на обочину истории оставясь узким нишевым языком для гиков.
* была скала? была. где она? мода прошла, скала уходит на обочину историию оставаясь нишевым языком для гиков.
* был клюжЮр? был… где он?..
и так далее — там еще в ряду, если верить википедии jPython, jRuby и далее…
и котлин ничем принципиально о них не отличается. извините, имхо.
если в чем и есть отличие ситуации с котлином, так это только то, что гуглю нужен «запасной аэродром» из-за постоянных нападок оракла. ни больше ни меньше, и это ни разу не связано с прелестями языка. это ситуация, «так карты сложились». они плотно дружат c jetBrains и «почему бы нет», я полностью понимаю выбор гугля…
но прошу вас, не надо рассказывать про прелести языка… если завтра гугль и оракл достигнут мирного соглашения — котлин с 90% вероятностью пойдет на обочину истории, как и его предшественники. в нишевость, в гиковость. и там ему пусть будут рады, я рад за тех кому это зашло.
«не надо навешивать на меня ваших крокодильчиков» ) я такое не говорил.
я за разумные новшества, обоснованные, не приводяшие к технической неоднозначности или непонятности для разработчиков. я ЗА новшества. но за взвешенное к ним отношение.
давайте поясню на примере джавы: диамонд синтаксис — классная вещь, потому что понятно
«что пропускается» и где смотреть что пропущено, код по прежнему однощначен. это было хорошее нововведение.
А вот лямбда функции — «полнейшая фигня»)) очень сомнительно. потому что без IDE, читая текст примера кода на сайте — вы можете только догадываться о типах передаваемых параметров. это было плохое нововведение. из исходного кода делись определения тип аргументов и какие они долджны быть — из текста исходного кода не понятно.
Или вот взять проблемы перехода с 6й джавы на 7ю. Болезненно для многих, особенно банковских и др интерпрайз систем, да. Но извините, доступ к приватным методам класса через рефлекшен — это не просто не правильно, это не описано в стандарте, и по сути, сродни багу платформы. Это и убрали в 7й джаве, но сохранили обратную совместимость в рамках описанного в стандарте поведения.
понятно мое отношение к новшествам? )
(а вот теперь я буду наезжать на котлин )
Кстати, где у
очередного убивцы джавыкотлина — стандарт языка, описание поведения, процесс сертификации сторонних компиляторов на предмет совместимости со стандартом? котлин, вопреки заявлениям авторов языка, не сможет заменить джаву, как минимум в интерпрайз секторе, пока не сможет предоставить аналогичных стандартов и воплотить гарантии сохранения обратной совместимости в виде явного стандарта и процесса сертификации сторонних компиляторов.извините — я это у всех проповедников новых языков программирования спрашиваю, вы не первый.
не обижайтесь, но давайте с котлином подождем года 2 или 3. вдруг там оракл и гуглем помирятся?)
или вы согласитесь со мной, в моем понимании, "почему джава успешно пережила не один сезон «убивцев джавы», и почему котлин, сам по себе, ни разу не исключение". или котлин займет нишевое положение эксклюзивно-платформенного языка, так же как свифт с иосом) — посмотрим, время покажет, не торопитесь, в общем.
вам заходит, — классно. пилите свои проекты, глядишь толк из этого выйдет. но не надо агитировать моих стажеров или меня. и хайп вокруг языка — ну прошу, не надо вот этого.., столько раз уже было, ну надоело, честное слово… глупое это дело… да и показывает вас с не лучшей стороны.
мы сами к вам придем коли потребуется.
спасибо что дочитали. удачи вам.
Поиск очередной серебрянной
технологиипули, помноженный на современные технологии пиара и очковтирательства в купе с увеличением «поголовья хомячков в IT» приводят к действительно безумной ситуации.И это проблема, т.к. ситуация приносит выгоду только желающим «погреть лапу» на семинарах/пиаре/продажеКнижОнок.
Появление новых фреймворков и языков практически не имеет никакого отношения к решению технических проблем, которые стоят перед разработчиками.
О том, что это всё — ни разу НЕ НОРМАЛЬНО — надо периодически напоминать.
Потому, что, согласитесь, задача языков программирования и it-технологий — это всё таки не радость неофита от прикосновения к сакальному и его вкусовые очущения от синтакс-сахара, а решение технических задач, однозначность кода, обеспечение прогнозируемости поведения и прозрачности структуры системы.
PS: Кстати, пока вы читали этот пост, и задавались проблемами а «что же с этим всем делать», ещё 2 школьника «изобрели» «2 уникальных инновационных js-фреймворка», технологию, парадигму разработки и под это дело — целый язык программирования — с турбореактивным связыванием, интеллектуальным дополненеим кода в рантайме с угадыванеим «что имел в виду заказчик», с удобным безскобочным принудительным форматированием кода отступами, компиляцией в node.js-байткод и нивуя-себе-шаблонизацией. «Как сейчас но ещё лучше». Надежно, масштабируемо, проверено. Обкатано на 3-х лабораторных работах. 10ю коллегами автора. Уже затерроризирован учитель информатики, который будет на нем делать школьный сайт и воодушевлено 3 журналиста. Скоро будет репортаж про дизактиватор Бубкина с веб-интерфейсом на первом канале.
И это все станет популярным через 2 года. На пару месяцев. И десятке-другом продуктовых серверов. Хорошо, если только этим все и ограничится, и не нам с вами это поделие разгребать и поддерживать, после того как их авторы срулят, заметая следы, в туман рубить бабла на впаривании очередное откровения. Или просто отмахиваясь куда-подальше от монстра который они создали.