Денис И. dplsoft

Кстати. Внимательные _американские_ зрители уже заметили на кадрах трансляции «первую мышь-астронавта которая улетела в космос без скафандра» на корпусе корабля Илона Маска. :)

Вот ссылка на ютуб с привязкой ко времени: youtu.be/e_5NCze1ZVg?t=11241
(смотреть на левую картинку — там где работает раскаленный до красна двигатель. нечто выпадает из-за золотинки на трубу, и «убегает» на верхнюю (относильно кадра) поверхность двигателя)

Выглядит и ведет себя действительно как мышь. но ведь её там быть не могло. ну не могло же…? или часть кадров «трансляции» — вовсе не трансляция и не то, за что нам это выдают"?

Ожидаем скандалЪ, по сравнению с которым наезды на Кубрика и лунную миссию были детской возней в песочнице?

Ну а если серьезно — вопрос к «знатокам» — что фигня творится на 6й с половиной минуте полета на между 30й и 35й секундами на камере показывающей работающий двигатель корабля ?!
Что это такое могло быть?

уже ни в чем) был не прав, а функции удаления нет.

но в любом случае настроения первого комментатора вида «конец российскому космосу» — это паникерсво и нагнетание — согласитесь?

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

И почему паникеры не орут про успехи Китая и не пророчат конец обоим космосам — и американскому и российскому? ))

-

Вот только давайте не будем начинать паникерство?

Маск сделал лоукост вариант. «Лоукост» — именно что во всех отношениях и ограничениях.
Молодец.
Только ведь жизнедеятельнсоть авиакомпании «победа» не привела к кончине «аэрофлота»? Так ведь?

И когда еще Маск сделает тяжелые ракетоносители — тоже еще вопрос.
И сделает ли. Но будем надеяться, что его намерение их сделать — «наши» будут рассматривать уже всерьез.

И предлагаю не ставить знак равно между «российским космосом» и текущим «роскосмосом». Менеджеров роскосмоса (в том числе и бывших) как бы можно и расстрелять… хотя нет, времена не те...… в отставку текущих отправить. ( но пиарщикам Рогозина (если они такие есть) — точно надо дать по голове за то, что позволили ему такие высказывания на публику — теперь Рогозину за это все косточки перемоют, но он как бы и сам виноват)

Отрасли был нужен пинок. «топы зажрались»)
Маск молодец что такой пинок сделал.
Посмотрим. интрига-ж, ведь )

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

В пользовательском соглашении, как «основной» адрес компании Atlassian, которая целиком и полностью владеет сервисом «bitbucket» (который, вопреки вашим предположениям, «компанией» не является. поправьте?) указан адрес именно в Сан-Франциско. www.atlassian.com/legal/privacy-policy

А в соглашении на использвоании облачных технологий ( www.atlassian.com/legal/cloud-terms-of-service ) так и вообще идет прямое указание на экспортные соглашения соединенных штатов и другие законы, тоже, штатов. не Европейсткие законы, ни Российские законы, ни законы других стран.

Вы точно уверены что компании, которые, как вы предполагаете, «не являются американскими фирмами» — будут подчиняться американским законам, руководствоваться в своей деятельности этими законами, и как головной офис указывать офис в Сан-Франциско? )

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

возьмем gitlab, sourceforge, bitbucket — они что — тоже прогнулись под «левую пятку заокеанских сенаторов» в этот раз? нет. они (поправьте?) в прошлом году никого не блокировали «из-за санкий».

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

айкрософт внезапно прикроет доступ к опен-сорс проектам на гитхабе или в том же nuget'e? Или попытается брать деньги за доступ?

ну вот, блин.
извините, но вот «прямо как вчера родились»)))

напомню события 31 июл 2019 г.: «GitHub ограничивает учётные записи разработчиков из Ирана, Крыма, Сирии и других регионов, находящихся под санкциями США».

или вам напомнить события послужившие причиной появления «Libre Office»?

или рассказать как оракл сейчас ужом извивается, всеми силами пытается «закрыть/монетизировать джаву», вот прямо спит и видит как ему будут платить за любой чих использования джавы? (и очень хорошо, что в свое время Sun сделал много, что бы сейчас не один оракл это решал)

___________________________________
Крайне наивно считать, что «ничего не случится» в головах людей, которые нацелены на максимизацию прибыли любыми средствами.

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

Оно по разному может аукнуться.
И деньги могут начать брать, и доступ могут закрыть.

И «лутбоксы» с «баннерами» могут вам к код подкладывать.

Ведь, если это делается без нарушения лицензии — с сохранением опенсорсности кода — то никто же не мешает это делать тому же майкрософту/ораклу/etc?
тем более когда они уже засветились в «крайне странных и сомнительных» телодвижениях.

Вам никто не обещал по «пользовательскому соглашению github », что ваш код будет хранится неизменным, а владелец репозитория не будет вмешивать в ваш код в github свои правки.

Покажете мне пункт в соглашении который запрещает это делать?
Покажете мне пункт, который запрещает владельцу github менять этот пункт в соглашении в одностороннем порядке?

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

действительно. можно же просто продекларировать что «философия использования Линукса <...>стремиться расширять свои возможности <...>чтобы любые цели <...> входили в рамки этих возможностей. »…

а доказывать…? зачем… не надо доказывать. ведь мы уже использовали несколько «да» в начале статьи — использовали. ведь туповатый читатель с наскоку и третьему утверждению поверит. его не надо доказывать. ведь так? )

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

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

— теперь имхо: философия линукс скорее заключается в том, что бы «иметь возможность открыть капот и подрегулировать кишочки», когда и если тебе это потребуется.

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

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

никто не требует от пользователя ковыряться в кишочках никсов.

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

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

она преподаватель музыки по классу фортепиано.
ни о каком, заявляемом в статье, «ковырянии в кишочках линухов ради расширения познания» — речи нет, и не будет — ей эта вся внутренне айтишная тема — глубоко побоку))

(*) это мой опыт наблюдения за линухами и dos-вендой на протяжении примерно 30 лет.) и позвольте мне его не доказывать)
а те кому нужны пруфы на ту же историю развития кeд и венды — найдут их сами.

_____
и да. не будет линуха на десктопах, весьма вероятно что его станет меньше и в интернете.

а тогда — каю — не будет вашего тырнета с мемасиками. вся инфраструктура держится на *nix системах. послушаем аффтара статьи и не будем учить студентов умению работать с линухами? тогда кто это все поддерживать будет?
на виндоус сервера переведем? не смешите мои тапочки)
я даже не про надежность. идите хотя бы цены на хостинг на венде посмотрите.

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

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

с вендой же — даже официально зарегистрированные баги в операционке с красными рейтингами не патчат лет по 10. потому что «пиплз схавает», да и как тогда зарабатывать на антивирусах?

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

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

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

вы пытаетесь поднять хайп, выдавая недоказанное или частное, как главное.

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

ваш же заголовок — некорректен. как например, и заголовок вида «у меня при игре в кости выпадают шестерки!» — некорректен, потому что он как бы намекает что у вас при подбрасывании кубика выпадают «только шестерки».

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

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

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

вы, что — полагаете что опенсорсность должна давать протекцию в вопросе «отключать или нет если утилита создает нагрузку»?

извините, но не надо выворачивать одно в другое.
или получается нечто аналогичное обратному фашизму
вида «тебя что, должны любить, только потому что ты негр?»(с)
т.е. «утилитой должны пользоваться и не запрещать, только потому, что она опенсорсная»? даже если она нарушает нормальную работу системы?

итог: подобными заголовками и выводами — вы вредите опенсорс движению.

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

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

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

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

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

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

Мне кажется, ситуация является прямым продолжением бездумного хайпа вокруг гибких/итерационных технологий разработки, который мы имели лет 5 назад.

Вспоминайте — все кому не лень вешали себе ярлыки «мы работаем по эджайлу», хотя у многиз даже итерационных процессов разработки и в помине не было.

Что в итоге? Молодые, насмотревшись на это, закрепили у себя в голове ассоциацию — «если говорят про agile — значит 90% пытаются обмануть».

И я даже из в этом не просто понимаю, я их поддерживаю.
К молодым, тоже, есть вопрос вида — а вы разобраться в сути вопроса не пробовали? (потому что, увы, не разбирались в большинстве своем).

Но повторюсь, что когда я вижу компанию, которая в вакансиях в первую очередь говорит про модные хайпанутые в этом сезоне технологии, процессы, или вещи — не важно будет это «эджайл», «девопс», «ангуляр на первом месте», «всем сотрудникам макбуки», «работаем только в идее», «git-flow» и тд и тп. — степень доверия к вакансии и к компании падает в разы, пропорционально числу использованных «слов для привлечения внимания». Не первостепенные это вещи. ;)

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

Наверное, надо, в первую очередь учить думать, не вестись на хайп, не раздувать хайп, не подменять понятия, вести разъяснительную работу.
В первую очередь — представлять из себя разумного рассуждающего человека.

И не пытаться выставлять очередную технологию как «мировую вакцину» — не пихать ее везде и всегда. Технология, процесс — это не серебрянная пуля. это просто тезнология, как и все технологии ограниченная.

Пять лет назад пихали эджайл во все дыры? — пихали. Даже туда, где эджайл не применим в силу условий среды; совершенно не разбираясь и не думая о границах применимости технологии…
Получили (ну наконец то!) негативный фидбек. Все закономерно, «шила в мешке не утаить», «нельзя обманывать всех людей все время» и тд.

Эджайл хорошая технология, но и как всякая технология она применимы далеко не во всех условиях, не на всех типах проектов. Об этом надо помнить, и, имхо, в таком направлении вести разъяснительную работу, а не пытаться обелить «имя эджайла» разбирая конкретные вопросы за и против.

Эджайл уже стал жертвой хайпа, извратившего суть термина. Ближайшее время это не изменится. Тут только разъяснять конкретным людям и объяснять про то, что «вы знаете о том, когда надо прекратить применять эджайл» и переходить на более тяжеловестный или другие по структуре процессы, и, в том числе, — доказывать, что вы знаете на какие процессы переходить и когда.

Простите, но мне одному кажется, что автор подменяет понятия?

Яндекс заблокировал конкретные действия — вне зависимости от того, открыты исходники инструмента или нет.

А автор пытается выдать это в плоскость борьбы с опенсорсом.
Или у автора есть примеры того, что яндекс разрешает автоматическую синхронизацию проприетарным утилитам? (свои клиенты яндекс-диска не в счет, по понятным причинам).

К яндексу, конечно, есть вопросы, но того характера что «вы в своем праве, но вы делаете не удобно вашим фанатам. Не даете автоматический бакап на яндекс диск — ок, но предложите путь как это делать по другому — тариф другой, или другой сервис?...»

Но и искажать ситуацию в статье, пытаться выдавать одно (ограничение нагрузки на свои сервисы) за другое (обвинять яндекс в нелюбви к опенсорс) — ради красного словца и хайпа — это же тоже не дело?

нет, не только.
основное его «достоинство» — это «поднимать в воздух клубами ту самую пыль, которую он должен был бы собирать» )

побить этот рекорд бесполезности сможет только, DIY-щик, сделавший пылесос, который будет вредить будет производить пыль ;)

ссылочку Доктору Дью уже отослал кто-нибудь? :)

Это опенсорс. Когда вы берете опенсорсное решение, вы должны понимать риски. Если нет, ну решение тут непричем.

ну, ну… не смешивайте опенсорс и бесплатность/отсутствиеподдержки.

скажем так, Java — тоже сейчас опенсорс.

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

Не знаю) Вы как человек от бизнеса, не проработали этот вопрос, когда решили его использовать?

я то вот как раз, (вроде) проработал в своё время, и выбираю как правило совсем не питон. и не советую питон в иных ролях кроме как скриптование мелких одноразовых задач. но некоторые заказчики находятся в таком диком убеждении что на питоне можно всё и вся, и для всего пригодно, так свято верят,… что я подумал — «может я что забыл ?»…

Внезапно, Питон тоже язык с динамической типизацией, только строгой.

всё лучше, чем те безобразия как у js или руби )))

и кажется же, что были разговоры про введение статической типизации?.. писал на питоне совсем давно, еще когда только третий был в самую новинку. подумал, может что изменилось. хотя бы методически — описание, стандарт внятный как у js например может появился… <_<
или может питоновцы что то «действительно новое придумали» в плане как быть с большими задачами и рефакторингом…

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

спасибо за диалог.

Иначе берите JS, на нем сейчас чего только не пишут. Там обратная совместимость практически 100%, со всеми вытекающими.

вообще, js плохо подходит для больших систем, в следствии динамической типизации.

опять же вспомню про создателей node.js, которые (честь и хвала им) осознали это достаточно быстро, и пересаживают всех на typescript. но, имхо, им этого тоже не надолго хватит, потому что «та же многопоточность», от которой никуда не деться, но которую нельзя впилить внятно в это «дитя js». потому js — нет, не подходит для сложных систем.

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

как эта «эволюция» помогает бизнесу эффективнее выполнять производственные функции?

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

а переход на юникод понизил расход ресурсов? опять же, утрируя — нет.

а «про юникод» бизнес вас вообще спросит: а почему вы сразу так не сделали? а когда вы разведете руками — запишет в графе «минусы»: "принимали необдуманные рещения, теперь просят с нас денег на перевод системы на вовую версию питона исправление своих ошибок в прошлом".

понимаете? во главе угла не эволюция ))) во главе угла сохранение работоспособности и минимизация расходов.

Если ваш бизнес не готов вложиться в переход на новую версию, можно сидеть на старой, никто ее не ломает, работать она будет, пока ваш проект на ней живёт

в этой фразе нет проработки рисков.

бизнес не может (вернее здравомыслящий бизнес не будет) сидеть на неподдерживаемой версии языка/системы, потому что в этом случае, все риски и ответственность связанные с ошибками в платформе/sdk/языке и убытками в следствии этих убытков — лягут на плечи подразделений этого самого бизнеса. а это никому из здравомыслящих менеджеров не надо — никто не хочет быть «виноватым без вины».

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

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

Если же вы хотите получать новый функционал в языке,…

вы продолжаете мыслить не теми категориями.
«бизнесу» — глубоко все равно какие там функции в языке.

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

никто не говорит про халяву. но затраты бывают разные

есть одна стоимость техподдержки, она линейна от времени.

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

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

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

и я снова спрашиваю: может ли питон 3 предложить что либо для минимизации таких рисков кроме LTS ( который, как было описано выше — не очень сильно помогает на большом сроке )?

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

с выделение байта в тип — мне прокомметировать сложнее ( не так хорошо знаю питон) но опять же в джаве вспоминается трюк с boxing-unboxing для простых и объектных типов.

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

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

и, увы, имхо, то что вы восхваляете как правильное и хорошее в 3м питоне — это, хотя и действитеьно (верю вам) правильное и хорошее, но это прямое следствие необдуманных решений при создании первоначального стандарта языка; а ситуацию из топика — мы имеем в виду «наплевателского» стиля при введении новых фич. имхо.

хотя, иногда такое наверное и надо делать. если вспомнить преход с Qt3 на Qt4 — это было действительно правильно. троллтечю пока еще были троллтечами, вообще с нуля переписали весь апи, получилось очень стройно, удобно и красиво. но, ВАЖНО, что у систем на базе C++/Qt и срок жизни куда менее чем 5-10 лет. ни о какой долгосрочности или громадности систем речи нет.

вы меня простите, но вы, имхо, по прежнему мыслите категориями «давайте сделаем наш инструмент красивым».

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

вы ставите во главу угла некий «проресс», кстати не детализаруя что это конкретно значит, а бизнес задается вопросом: «а сколько денег будет стоить этот прогресс» и «кто конкретно за это будет платить»?

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

— Обратную совместимость поддерживать, имхо, можно, достаточно долго, сильно больше чем любая LTS; хотя и при соблюдении ряда условий:

1. во перых требуется автомтический контроль за этой совместимостью (читай автоматические тесты валидности интерпритаторов/компиляторов под каждую версию). иначе как эту совместимость действительтно проверять?

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

не к ночи будет сказано, но у джавы и джаваскрипта такие спеки есть.
и есть альтернативные реализации, и процессы валидации/тестирования/проверки сторонних интерпритаторов тоже есть. и джава и а 13й версии продолжает поддерживать работоспособность версии 1.

у питона есть такое? а когда появится?
есть альтернативные реализации, совместимые с исходным стандартом?

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

— вот я и спрашиваю: питон 3 — это всё еще экспериментальный язык, для небольших систем со сроком жизни полгода-год, «с новыми фичами» и с «правильной по последнему слову архитектурой», которая целенаправленно и осознанно ломает обратную совместимость ради новых фич…

или это уже язык, претендуюший на звание «промышленный язык» — язык, в разработку кода на котором бизнес может вкладываться на горизонте более 5-10 лет, не боясь, что в какойто момент, все то, что было создано перестанет работать, потому что версия языка перестанет поддерживаться?

это не к рассуждениям плохо-хорошо.

это к позиционированию, и осознанию места и ниши языка, границ его применимости, внушения толпам молодых красноглазых неофитов/фанатиков правильного понимания о том, «где это можно применять».

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

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

питон 3 готов стать чем то иным?

В этом я с вами полностью согласен.

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

Более того, я считаю, что проблема EOL средств разработки для больших систем гарантированно наступает. (какой бы не был LTS длительным — он кончится).

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

Вот я и пытаюсь узнать — что делается создателями питона 3, что бы помочь избежать проблем связанных с EOL?

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

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

если вы пишете «промышленный», сложный код который будет работать ОЧЕНЬ долго — стоимость работ по переводу системы на версию языка, которая потеряла обратную совместимостиь — начинает составлять очень значительную часть бюджета.
и платить за это никто не готов.

и вопрос не в плановости или авральности. вопрос в том что это дорого. очень дорого.
потому, имхо, во многих случаях, говорить о переводе систем на питоне 2.7 на питон 3 — не приходится. никто за это платить не будет.
и в 20м году их будут попросту отключать, выводить из эксплуатации и заменять на другие. возможно и вероятно не на питоне написанные.

____________________________________________________
ладно. питон 2.7 -> 3 показал как не надо делать обновы, и ладно, дело прошлое опять вспомню про руби тоже пару раз давшему маху… тоже в прошлом.

но что же с питоном 3?

какие у него есть гарантии или стратегии, которые помогут ему претендовать на роль «промышленного языка для больших систем»? как создатели собираются предотвращать проблемы обратной совместимости и затрат на перевод на новые версии, проблем изменения поведения при смене версий?

когда я буду выбирать средства реализации для новой системы — что мне показать в аргументах? или сразу писать, что «ежегодно, на перевод на новые версии питона у вас будет уходить ~20% из бюджета поддержки системы??»

20% — цифра, конечно, с потолка, — но она есть, и вопрос в том что делается, что бы ее минимизировать?

offtop: можно для сравнения пообсуждать, что можно делать (и что делается) для этого на примере java, но тред же про питон?

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

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

и надо отдать должное — разработчики питона в данной ситуации повели себя хорошо — держались почти до последнего. столько лет тянуть поддержку 2.7 — честь и хвала.

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

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

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

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

что ответит питон 3 на такого рода запрос? есть ли полная подробная спека эталонного поведения языка? достаточно ли ее для того что бы сделать автоматические тесты, которые позволят проверить насколько «интерпретатор питона от васи пупкина» соответствует эталону? или насколько новая версия интерпретатора соответвует эталону старой?

и правильно, имхо, сомневаетесь.

пока котлин не обеспечит гарантий 100% обратной совместимости и полное покрытие спеками языка (и/или компилятора) — никакой конкуренции java он не составит. в лучшем случае будет болтаться в проруби платформенного языка так же как swift или шарпы, меняя спецификации от версии к версии.

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

Какая-нибудь Стрида, думаю, вполне себе близка по проходимости к крупным самокатам. При этом на ней вполне ездят 30+ по дороге.

давайте не будем брать крайние случаи и распространять их на всё множество?
Это лукавство.

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

Моноколёса так и вовсе довольно крупного диаметра и ввиду своего «моно» даже устойчивее при проезде мелких неровностей

Ну что вы такое говорите? «устойчивость» моноколеса?! ))

Я конечно могу ошибаться, но размышления говорят о том, что «устойчивость пилота» на средстве передвижения определяется не только диаметром колеса, но и «колесной базой» — основанием на которое пилот может опереться что бы не упасть.

Что имеем? По самокату или скейту — вон даже попереступать можно…
А у моноколеса «колесная база» — нулевая.

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

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

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

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

Кстати, велосипеду по ПДД — тоже запрещено «ехать в полосе» (ПДД, пункт 24.2: www.drom.ru/pdd/pdd/punkt_24_2 )

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

Ну раз так, то идите, пожалуйста, и попробуйте получить на ваш «50-и кубовый мотоцикл» номер. Мотоциклам же, как и автомобилям — запрещено ездить без номеров — это то вы тоже должны знать? ))

И попрообуйте объяснить инспектору, что вы лучше него знаете, что у вас «50-и кубовый мотоцикл», а не «мопед» — именно как раз по ПДД.

Главное запишите на видео — что бы мы тоже могли поугорать.

Самокаты до 250 ватт полностью соответствуют определению велосипедов из ПДД, а больше 250 ватт — мопедам. Не нужно ничего изобретать.

вы лукавите.

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

там где велосипед проедет на 40 км/ч, а пилот только синяк на заднице получит — самокат резко застрянет с 40 км/ч до нуля — со всеми последствиями для «ездока».

далее, если следовать вашему определению, то и инвалидные коляски, имеющие в современном исполнении мотор, тоже — являются «механическими транспортными средствами». и в следствии чего, им, (внимание!), нельзя ездить по тротуарам и в пешеходных зонах… да ?)

но ведь этого не происходит. все как раз наоборот:

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

почему? потому что она прописана в определении пешехода без уточнения — есть на ней мотор или нет.

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

и мы же не проект ПДД, обсуждаем, а действующие ПДД?..

По такой логике и на велосипеде по ПЧ нельзя ездить, вдруг ямка, щель и т.п. И на скутере поскользнуться можно.

вы вот это серьезно? понимаю, ерничаете или сарказмируете, наверное.

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

у велосипеда вы не встретите колес диаметра самоката: диаметр колеса велосипеда гораздо больше, и сопоставим с автомобильным или мотоциклетным, и мелкие щели на дороге, стыки плит, крышки люков (утопленный на 3 см под покрытие) — проезжаются велосипедами вполне незаметно. в отличии от самоката, который, проезжая крышку люка, рискует на этой же крышке люка и остаться.

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

Аргумент про скорость несостоятелен.

Быстроедущий самокат мотоциклом или велосипедом не становится.

Пешеход перемещающийся 30+ км/час на прыгучих ходулях не перестает быть пешеходом.

Не согласны? Вот пример из жизни: скутер «50кубиков», даже при конструктивной его возможности «гнать» 75 км/час — не перемещается из категории «мопед» в категорию «мотоцикл». И будет рассматриваться ГИБДД именно как «мопед».

Точно так же «быстроедущий самокат», с точки зрения ПДД не перестает быть приравненным к «очень быстро бегущему пешеходу».

При разборе ДТП судить будут по букве закона, а «буква», именно «буква ПДД» явно говорит про самокаты вне зависимости от их максимальной скорости.

Юридически вы приравниваетесь к велосипедистам

…
ээээ… что?!
Простите пожалуйста, но не надо вводить людей в заблуждение,

По ПДД, «самокатчики» — это именно пешеходы.

www.pdd24.com:

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

т.е именно пешеходы, со всеми вытекающими.

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

Вы, как пешеход, нагло и беспардонно нарушающий ПДД.

И когда вы «бежите» на самокате или моноколесе во втором ряду, даже на скорости 45 км/ч — водители не просто имеют право бибикать (для предотвращения дтп), но и наверное, им следует вызвать наряд гибдд, что бы вас оштрафовать зарвавшегося пешехода.

Настоятельно, очень сильно, сердечно от лица мото- и авто- водителей, прошу: не надо ездить на самокате по дорогам общего пользования! Помрете «низачто».
Ни на самокате, ни на моноколесе, ни на роликах, ни на самоходном скейтборде.

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

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

Ну что значит просто…
… где дзен SMD и паяльной пасты под 60W паяльником ?! ))

Я к чему:

1) тема SMD не раскрыта.
А это бывает срочно надо. Причем именно тогда, когда нет ни паяльной станции, ни фена, а только старый добрый «паяльник с жалом».

2) паять с пастой, имхо, куда приятнее чем с припоем и флюсом.

но вообще тема рабоче-технических комиксов — штука правильная. продолжайте)

размазывание лиц?.. хм… а ездить же в масках или бонданах еще не запрещено?

ну как же… тесла рано или поздно перейдет на активное сканирование местности (если уже не перешли?), или как минимум на восстановление 3D-ространства вокруг по стереопаре камер или даже (что имхо, разумнее) по трем камерам.

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

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

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

хотя это тоже вариант. работаем же с «wsdl-вебсервисами» в джаве аналогичным образом ?))) работаем.

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

так же, мне не нравится сама идея «форм собираемый в компайл тайм», хотя бы потому, что много с этим наелись в jsf. не самый элегантный, имхо подход, но для своего времени и многих областей — пригодно.

все же помнят что он НЕ бесплатный?)))
а то у нас тут один разработчик воткнул вебикс «просто потому что он работает», и очень сильно обижался что я его заставил выпилить это изделие из проекта. или заплатить за него из своего кармана. потому что мы не можем установить клиенту не лицензионное ПО, а 2500-4000 американских денег в бюджете проекта на вебикс у нас на тот момент не было.

хотя да, выглядит он не плохо.

с объектно ориентирвоанными БД тоже много засад. правильная объектная БД должна уметь валидировать объекты которые ей подсовывают.

т.е. в идеальном варианте — например поддерживать механизм типа XSD или хотя бы на крайний случай JSON Schema или им подобным.

Если она не делает этого, то эти вопросы потребуется решать вам, в вашей сситеме.

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

но если у вас объхектная СУБД не умеет валидировать данные (как например очень популярная легковесная MongoDB), а пишут в эту БД несколько систем, особенно если они от разных команд или производителей — то вы рано или поздно получите проблему когда вы с вашими коллегами ассинхронизируетесь в понимании как разбирать структуры в вашей бд.

т.е. объекты у вас будут, но понять что они означают вы не сможете. потому что давно потеряли информацию о том что записано и как трактовать эти json-структуры.

Если вам интересны примеры — сошлюсь на проект разработки первой версии ЕГРН для Росреестра давностью года 3 назад. Тамошние/тогдашние подрядчики создали именно такую ситуацию — в могно-дб лежали настолько разношерстные данные, что написать бота, который бы вытащил из этой БД хоть какие-то полезные данные было совершенно невозможно. и произошло это, по моей версии, как раз из за того что писали данные туда 2 системы, структуры данных развивались, а сама монго-дб не умела хоть как-то вализировать присылаеый ей мусор.

— ну так вот. я к тому, что метаданные для объектно ориентирвоанных БД или ОРМ которые скрывают работу с объектными БД — тоже нужны.
Только играют они иную роль и по другому выглядят, по другому называются.

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

Давайте ещё раз проговорим)

мы же, в контексте топика не о «классических подходах», а говорим в первую очередь о _генерации_ форм?

т.е.продолжая термины вашего примера — у вас не будет никакого UserForm.
У вас будет AutoGeneratedForm. один на всех.

AutoGeneratedForm — универсальный механизм. угловатый но предоставляющий приемлемый минимальный уровень работы со всеми сущностями.
механизм который умеет динамически себя перестраивать под тот объект который ей передали.

Хотите — передавайте ей User, хотите — AccountingYearReport, хотите — OperationLogElement — она сама перестроится и отобразит это на экране.

Т.е. идея такая: вы один раз написали такую универсальную форму, и после этого практически забыли о типовых CRUD-механизмах работы с сущностями в GUI (просмотр списка, просмjтр карточки, сортировка, выборка, редактирование).

Теперь к вам вопрос: каким образом реализовать такую систему?

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

И над сущностями User/AccountingYearReport/OperationLogElement и над AutoGeneratedForm висит «домокловым мечом» система метаданных, которая по мере необходимости дает и той и другой стороне (и фронту и беку) необхоимую информацию о том, как работать с передаваемой сущностью.

детали реализации — будет у вас хендлер или что то ещё, будут у вас метаданные храниться в объекте или централизованно — это уже не важно. Важно что и информационная сущность, и форма синхронизируются (или сопоставлены если хотите) через третью сущность — метаданные.

вы говорите что «на js можно поместить в объект информацию о том как его отображать» — я же правил но вас понимаю?

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

только система метаданных у вас организована так, что каждый объект «знает о себе всё».
и я так делал. так был построен мой орм для qt.

но когда мне потребовалось реализовать вариативный орм который имел бы одинаковый н ерфейс и для 3nf бд и для datavault — я использовал другую идеологию.

вот вы тоже противопоставляете фронт и бек))

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

сервер по прежнему отвечает за корректность обработки. а фронт за корректность отображения.

но откуда им обоим, если не из метаданных, взять информацию об объекте, что бы
1) фронт мог иметь систему генерации форм, способную автомтически сгенерировать форму для отображения любого ифн.объекта в системе?
2) а бек мог корректно это отработать?

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

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

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

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