О бедном Crystal замолвите слово

они не предлагают радикального улучшения родителя,

Это примерно как «радикальное улучшение английского». Или русского. Получится красивый но мертвый «эсперанто» - выверенный, правильный и очень простой. Но не работает.

Поэтому все и вертится в рамках скобочек, логических операторов и знака «равно».

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

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

пошлют даже с деньгами

Значит мало предлагаете!

Думаю даже у отказа от отступов есть своя цена и явная передача селфа на сдачу будет ещё.

Думаю даже у отказа от отступов есть своя цена и явная передача селфа на сдачу будет ещё.

Отвечу вот такой замечательной ссылкой

Правда сколько там предлагали не знаю :)

как «радикальное улучшение английского».

Я не только про синтаксис, желательно ведь в первую очередь и бэкенд улучшить (особенно в случае тормозного питона, хотя бы на регистры и llvm jit портануть), не нарушая интероп. Пример - Котлин, который куда более френдли, чем Java, совместим и можно хоть в браузере через wasm запустить без костылей.

Такое не всегда возможно

Понятно, что не всегда, но софт форки тоже делают и успешно (пусть иногда и не совсем в нужное русло), например, PyPy.

Пример - Котлин, который куда более френдли, чем Java, совместим и можно хоть в браузере через wasm запустить без костылей.

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

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

По-сути что Котлин что Скала догоняют свежие реализации JDK, которые выходят сейчас очень часто.

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

показал пример того, что язык может быть и совместим (до крайне разумного предела), и портабельней. А в случае с Python, который до NNN раз медленней C++ на наипростейшем коде, когда Javascript (пусть и значительно более простой язык) с JIT на V8 умудряется практически нативную скорость выдавать, еще и производительность можно подтянуть (что особенно важно). Регистры в виртуалку Python пока не ввели, объекты даже под примитивные типы жирнючие, только-только оптимизнули однострочные генераторы и так далее. Всё это не синтаксис, не шугар, а внутрянка. И что мы имеем в качестве альтернатив: PyPy, Numba, Mojo, все даже и близко не совместимы, это не тот уровень качества Kotlin или Scala.

догоняют свежие реализации JDK

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

А в случае с Python, который до NNN раз медленней C++ на наипростейшем коде

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

Я вот не могу сказать что петон тормозной, как-то так получается что у меня он не тормозит.

Oracle вообще бы так и не зачесались, пока Kotlin не отнял добрую часть пользователей.

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

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

Наяриваем на синтетические бенчмарки конечно же. Кстати, crystal помнится показывал очень посредственные результаты на web framework benchmarks. Сборка мусора там что ли портит малину. Возможно эти результаты одна из причин угасания интереса к языку. Время шло, а хипстеры не могли похвастаться даже не призами спецолимпиады, а хотя бы какими-то средними результатами. Даже убрали с офсайта слоган «Fast as C, slick as Ruby», что было совсем уж неприлично.

одна из причин угасания интереса к языку

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

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

Кстати, crystal помнится показывал очень посредственные результаты на web framework benchmarks.

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

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

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

Как тебе такое Элон Маск?

что же вы такое делаете с языком

банально: линейно обрабатывали 100 транзакций, а теперь надо обрабатывать и выдавать 1000 в реалтайме на каждый запрос после обработки в базе. Писать на другом языке не выйдет - в компании другие люди тоже есть, поддерживать нетипизированную лапшу на pandas со строками не вариант, проходили: пару апдейтов либы, и всё надо переписывать. Все метания бы сразу закончились, если бы язык был банально шустрее.

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

мой личный опыт тут менее релеватен, если надо: датаклассы однострочные сразу в языке без багажа всяких Lombok (с тех времен уже подвезли, но не совсем такие же), удобная асинхронщина на корутинах тоже без внешних либ (такого в Java до сих пор нет, даже виртуальные треды не сравнятся), null проверки на уровне языка (тоже без мук c Optional), и т.д. Небольшие изменения сильно упрощают разработку сразу для всего языка.

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

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

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

Как тебе такое Элон Маск?

Для этого у рубистов есть mruby, спонсируемый министерством экономики, торговли и промышленности Японии. Можешь этот веб-интерфейс хоть в один бинарник запихнуть, прям как в Go, и собрать хоть для MIPS, хоть для RISC-V. Я для роутеров, как то и писал на нём софт, для одного VPN-провайдера. Стрипованый бинарник со всем необходимым, включая поддержку TLS/SSL имел размер в 500 килобайт и работал на домашних роутерах с 64-256Мб ОЗУ (стандартные Linux + musl или uClibc). Hello world мог весить и 200Кб.

линейно обрабатывали 100 транзакций, а теперь надо обрабатывать и выдавать 1000 в реалтайме на каждый запрос после обработки в базе

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

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

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

Стрипованый бинарник со всем необходимым, включая поддержку TLS/SSL имел размер в 500 килобайт и работал на домашних роутерах с 64-264Мб ОЗУ (стандартные Linux + musl или uClibc).

Вах! Надо взять на вооружение.

Транзакции криптовалютные, данные короче, а не транзакции с rw локами базы.

Не люблю эту тему, но там же суть транзакции в наборе неких математических операций - не логичнее вынести логику такой «транзакции» отдельно в нативную библиотеку на каком-нибудь c++ и оттуда дергать?

Вооот, об этом я тоже написал, другие люди в компании не знают ни Rust, ни C++, и не смогут поддерживать.

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

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

Ну дык, люди забыли как интернет на CGI скриптах работал. Сейчас всем подавай вундервафли, иначе лох.

crystal помнится показывал очень посредственные результаты

Crystal сопоставим или обходит Go в искуственных бенчмарках. Меня, собственно, на рассматрение Crystal сподвиг пост Heng Li, который искал ЯП подходящий для Biomedical Informatics: https://lh3.github.io/2020/05/17/fast-high-level-programming-languages И пришёл к выводу, что с наименьшими движениями в плане дополнительной оптимизации результаты наиболее близкие к C выдавал Crystal.

Что там показывает TechEmpower - вообще иррелевантно, можно данные той же точности получить на random.org/lists. Последний раз когда смотрел, они жопоруко использовали технологии в которых не разбирались, сравнивали ужа с ежом, а поправить что-то было нетривиально в виду дебильной организации всех этих замеров: монорепа, которую отказывался клонировать git из-за слишком большого размера, необходимость разворачивать локально кучу всего не относящегося конкретно к технологии, которую ты планируешь тестировать. Как результат, производительность у них прямо коррелируют с наличием свободного времени у разработчика тестируемой технологии.

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

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

Например, попробуйте сделать ОС, совместимую с Windows в плане запуска приложений — хотя бы для одной единственной железки, никто даже не говорит повторять всю поддержку виндового железа. По состоянию на 2023 один из наиболее ярких примерно — Chromium. Вы думаете, гугл не понимает, что наращивание функциональности браузера ­— это тупиковый путь? Понимает, а также понимает, что ни один игрок на рынке не готов потратить столько ресурсов, чтобы сравниться с Chromium. Уже пора бы переименовать HTML в CML (Chromium Markup Language).

И тут приходит коммерс, которому нужно просто продавать слонов в интернете, и говорит «бюджет на разработку у нас большой, с избытком выделили, тысячу долларов аванс, еще тысяча после запуска в прод», и удивляется «как это за эти деньги ничего нельзя сделать? Мария Петровна мне за эти деньги полгода будет двор мести!». А вот потому что есть стандарт, за ним еще стандарт, за ним еще десять стандартов, и вот три несовместимых готовых решения, и со всеми ними нужна совместимость, под каждое отдельный контейнер, контейнеры на двадцати серваках, админить их должна отдельная команда или аутсорсеры. И это нормально, потому что иначе рынок IT был бы раз в 10 меньше.

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

плохие решения

искусственные барьеры

тупиковый путь

Похоже, ты заработался. Может, в отпуск?

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

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

Похоже, ты заработался. Может, в отпуск?

Никто меня не выпустит.

Вот если бы программы и библиотеки проектировались, писались, тестировались и документировались сами по себе, а стандарты сами по себе соблюдались

Когда я перешел с делфей на JS, то я резко почувствовал что-то вроде «да здесь же ничего нету!». Хотя, казалось бы, технологии здесь развивались дольше и активнее, бюджеты вложены жирнее. Тем не менее поддержка десятков слоев совместимостей с совместимостями, фич, которые никто не использует, но которые по стандарту положены, требует огромных ресурсов для разработки платформы/аналога.

Я тут недавно упоминал BPEL:
Архитектура системы обработки заказов (комментарий)
Типичный вариант переусложненного ненужного стандарта. XML — почему XML? Язык не подходит для передачи сообщений между программами из-за чрезмерной сложности, но его продолжают пихать куда ни попадя. Есть уже даже стандарт MicroXML
https://dvcs.w3.org/hg/microxml/raw-file/tip/spec/microxml.html
под который парсер пишется в 2 тысячи строк, но нет, мы будем использовать полную спеку, а еще XPath и XSLT, чтобы кодеры даже не думали о том, что можно просто сделать парсер для этого говна. То есть, вместо того, чтобы решить проблему по кратчайшему пути, одну кучу говна наращивают второй кучей говна.

Или вот я года два назад занимался интероперабельностью с MS Office — вот уже где пацаны постарались на славу: ISO/IEC 26300 на OpenDocument в десять раз меньше ECMA-376 на Office Open XML — и там еще не все причуды офиса задокументированы. Если требовать поддержки всяких xslx и docx, то сложность резко взлетает в космос, если ограничиться ODF/ODS — уже чуть лучше (хотя XML все равно говнище).

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

А какая в этом экономическая целесообразность? Windows уже есть. Объясни виндоводам зачем им твоё поделие на одной железке, если у них всё и так работает.

Или вот я года два назад занимался интероперабельностью с MS Office

Я даже знаю как это называется, даже видео есть.

Когда я перешел с делфей на JS, то я резко почувствовал что-то вроде «да здесь же ничего нету!»

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

А какая в этом экономическая целесообразность? Windows уже есть. Объясни виндоводам зачем им твоё поделие на одной железке, если у них всё и так работает

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

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

Основной аргумент — это работает на всех платформах (которых нынче стало неприятно дофига). То есть, можно написать код, который заработает и на андроиде, и на маке, и на винде. В какое-то время это даже было хайпом, мол «употребляйте Electron и ваши волосы будут мягкими и шелковистыми». Особо поехавшие писали на Electron+React. После того, как кучу стартапов на электроне загнулось, публике стало ясно, что Electron не является серебрянной пулей, прыти поубавилось, снова возникли поиски альтернативных, более надежных платформ. А также пришло понимание, что таки для винды и андроида нельзя использовать одинаковый GUI — ну вот разные они, хоть убей.

после дельфей современные технологии GUI кажутся каким-то издевательством

Delphi как RAD-система был хорош, пока графических разрешений было немного. Прибить контролы к пикселям и усё. Я в своё время немало разрабатывал на Delphi и хорошо помню тот момент, когда стало трудно адаптировать GUI к разным разрешениям. Даже начал сочинять что-то вроде системы лэйаутов, потом плюнул и перешёл на C++/Qt.

Я в своё время немало разрабатывал на Delphi и хорошо помню тот момент, когда стало трудно адаптировать GUI к разным разрешениям

У них багованная система выравниваний-якорей. Она пересчитывала туда-обратно размеры при пересоздании окон, а пересоздание окон было краеугольным камнем всей VCL, поскольку по другому нельзя изменить целый ряд свойств стандартных контролов винды. Она изначально костылилось поверх того, что было не адаптировано к грамотным выравниваниям. И вот на втором слое костылей этой системе стало совсем плохо.

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

Так зачем ты выбираешь тот стул, где эту поддержку надо кровь из носу запиливать самостоятельно, а не тот, где предоставлен удобный интероп с платформой, через который ценители садо-мазо могут ловить свой собственный кайф, а не ценители — даже и не знать, что такое вообще существует? %)

И при этом и те, и другие могут пользоваться всеми плюшками, которые даёт твой язык.

Основной аргумент — это работает на всех платформах

Что мешает сделать в браузере стандартную библиотеку виджетов хотя бы уровня Tk?

Так зачем ты выбираешь тот стул, где эту поддержку надо кровь из носу запиливать самостоятельно, а не тот, где предоставлен удобный интероп с платформой, через который ценители садо-мазо могут ловить свой собственный кайф, а не ценители — даже и не знать, что такое вообще существует? %)

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

Что мешает сделать в браузере стандартную библиотеку виджетов хотя бы уровня Tk?

Если ты пользовался Google Docs, то ты понимаешь, насколько геморно сделать банальный многострочный редактор текста на голом JS. Кнопки есть в браузере из коробки, надписи есть, галочки, выпадающие списки, но только с ограниченным набором фич. Сделать с нуля на JS выпадающий список с широкой возможностью кастомизации — весьма нетривиальная задача.

Всё сводится к тому, что писать на C/C++ GUI с нуля можно, а вот с JS такого уже не провернуть. Вон, на Java делали GUI, так от них тоже плевались.

на Java делали GUI, так от них тоже плевались

кто плевались? от swing или fx плевались?

кто плевались? от swing или fx плевались?

FX не взлетело, все остальные печальные какие-то. Сколько я пользовался жавовыми софтинами — впечатление примерно как от Tk.

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

JavaFX не то чтобы не взлетело - ниша кончилась, новые проекты ушли в веб, старые и большие остались на RDP монстрах вроде Eclipse.

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

Инертность рынка.

JavaFX не то чтобы не взлетело - ниша кончилась, новые проекты ушли в веб, старые и большие остались на RDP монстрах вроде Eclipse

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

Собственно можно сказать что Java после 1.8 точно также не взлетела - куча решений и вендоров так и остались на 1.8, несмотря на выход уже аж 21й версии JDK

Посмотри на VS Code. Это JS/нода, и она работает не хуже жавы. Да, поздние версии жавы лучше восьмерки, но по сравнению с JS не нужны ни поздние, ни ранние версии жавы. Потом еще на серверах пришел Go и оставил жаве только нишу legacy.

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

Угу, от вида фотошопа сожравшего 50Гб памяти при работе тебе наверное вообще поплохеет. Молчу про видеомонтаж.

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

Еще конечно просто и красиво наезжать на RAD вроде Eclipse, если не знать что до них никаких сложных сред разработки не было.

А Visual Studio так вообще едва едва вылез из уровня простого редактора с подсветкой синтаксиса, в районе 2015го года.

Посмотри на VS Code. Это JS/нода, и она работает не хуже жавы.

Это ты на нее смотришь, а я на нем работаю. И оно хуже, сильно хуже.

Потом еще на серверах пришел Go и оставил жаве только нишу legacy.

Все таки надо в отпуск. Без отпуска можно перейти черту и начать писать на Haskell для прода - это именно так и начинается: с выгорания и экстремальных тезисов.

Угу, от вида фотошопа сожравшего 50Гб памяти при работе тебе наверное вообще поплохеет. Молчу про видеомонтаж

Adobe стабильно выдает куски дерьма, и это не значит, что так оно и должно быть.

Еще конечно просто и красиво наезжать на RAD вроде Eclipse, если не знать что до них никаких сложных сред разработки не было.

Потому что они были НЕ НУЖНЫ. Java — это настолько всратый язык, что на нем непрактично писать сложный код, нужна обязательная прокладка, которая будет транслировать жаву в человекочитаемое представление.

Но это не имеет никакого отношения к тому, что VS Code представляет собой лучшую альтернативу Eclipse/IntelliJ Idea, и в целом в сфере GUI JS укатал Java в асфальт.

Посмотри на VS Code. Это JS/нода, и она работает не хуже жавы.

Это ты на нее смотришь, а я на нем работаю. И оно хуже, сильно хуже.

Хуже для чего? Для жавы? VS Code для жавы использует, внезапно, Eclipse, потому что выбор анализаторов для жавы невелик. Я юзаю его для JS, Python, C/C++.

Без отпуска можно перейти черту и начать писать на Haskell для прода - это именно так и начинается: с выгорания и экстремальных тезисов

Я еще не настолько упорот.

Adobe стабильно выдает куски дерьма, и это не значит, что так оно и должно быть.

И какие из продуктов Адоба мьсе использует для работы? Иллюстратор? Премьер? Или может быть Фотошоп?

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

Барнаул, Алтайский край.

VS Code представляет собой лучшую альтернативу Eclipse/IntelliJ Idea, и в целом в сфере GUI JS укатал Java в асфальт.

В отпуск, срочно. Или детокс в клинике для богатых.

Я серьезно, тут остался шаг до Хаскелла и это необратимо.

А Visual Studio так вообще едва едва вылез из уровня простого редактора с подсветкой синтаксиса, в районе 2015го года.

ты не путаешь ничего?

Нет, сравни возможности студии хотя-бы с тем что дает Eclipse/Netbeans, уж молчу про Intellij Idea.

Сколько я пользовался жавовыми софтинами — впечатление примерно как от Tk.

VS Code. Это JS/нода, и она работает не хуже жавы

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

в сфере GUI JS укатал Java в асфальт

не понял тебя: в сфере разработки десктопного гуи решения основанные на java были замещены html/js потому что что? потому что первые были архитектурно неудачны? имели низкое качество? были неполны? или потому вторые просто технологически лучше, изначально удачнее спроектированы, полнее? или потому что с первыми результат был менее удобен конечному пользователю? или что? почему так произошло-то в твоем понимании?

ты уверен, что ничего не путаешь?

Уверен, но можешь уже конкретику называть. Благо мьсе работает со студией начиная с 6й версии, честно купленной на Горбушке ( еще той )

А Visual Studio так вообще едва едва вылез из уровня простого редактора с подсветкой синтаксиса, в районе 2015го года.

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

так же по моим воспоминаниям в середине-конце 2000-ыx, в VS была навигация по коду кликом, встроенная справка, отладчик, автокомплит, интеллисенс, графический построитель для WinForms, хреновина для uml проектировая, инструмент для работы БД (MSSQL разумеется), встроенный контроль версий (их сурссейф), в конце 2000-ых там уже было два дизайнера (второй для WPF). да чего там наверное только не было - я за этим только со стороны наблюдал, но даже этого достаточно чтобы понять, что ты несешь дичь.

какой еще 2015 год? какой еще «простого редактора с подсветкой синтаксиса, в районе 2015го года»? что ты гонишь вообще?

Держи себя в руках, понимаю что это трудно )

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

1. Рефакторинг

Изменить пакет, класс, сигнатуру метода, сгенерировать стандартные методы (get/set property для C# как пример)

2. Обновление проекта

До сих пор это исправляется ручной правкой проектных файлов, студия в некоторых случаях просто такой проект не открывает.

3. Анализатор кода

Неиспользуемые классы и методы, неверная реализация и подсветка проблемных мест, CVE в конце концов.

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

Заранее извиняюсь за возможный оффтопик и суровую правду жизни.

Рефакторинг

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

Анализатор кода

про это не знаю.

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

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

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

Но по делу тебе конечно сказать нечего. Правда ведь?

я по делу уже все сказал: VS более чем соответствовала понятию IDE в середине двухтысячных (а не в 2015), была как минимум on-par с другими IDE, и точно не была простым текстовым редактором как ты выразился. а вот тебе сказать действительно больше нечего - не будешь же ты признавать что несешь чушь.

Я выше по пунктам перечислил что именно было в нормальных средах и чего не было в студии. Есть что добавить?

то есть тебе не очевидно что ты в лужу сел? ок.

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

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

Со всем уважением, но вот так.

вы точно про VS а не VScode?

ибо VS всегда была у микрософт флагманским продуктом и в версии энтерпайз всегда(т.е с момента появления такого варианта поставки в середине 90ых) имела много(через чур по мнению многих) гитик

ваще под VS чуть ли не весь софт микрософт был одновремя сделан

ибо VS всегда была у микрософт флагманским продуктом и в версии энтерпайз всегда(т.е с момента появления такого варианта поставки в середине 90ых) имела много(через чур по мнению многих) гитик

Блин, вот специально по пунктам описал что не так, с конкретикой. И все равно «автор дурак».

Я прекрасно понимаю и что такое Visual Studio и чем она отличается от VSCode, я использовал и использую и то и другое, видел Visual Studio Enterprise Edition еще версии 6.0 (это где-то 2004-2005й годы).

По делу есть что ответить? Не абстрактно как тут любят?

видел Visual Studio Enterprise Edition еще версии 6.0 (это где-то 2004-2005й годы).

VS 6.0 – это 1998-й. Там даже полноценной поддержки С++98 не было еще.

2004 – это должно было уже быть, минимум, VS2003. А в 2005-ом вышла VS2005.

Ну а так-то VS 6.0 – это почти то, что вы и рассказывали: редактор, интегрированный отладчик, браузер проекта (с возможности перейти на декларацию или реализацию функции/метода), поддержка MFC на уровне разнообразных Wizard-ов.

Рефакторинга тогда в VS 6.0 не было (емнип). Рефакторинги – это уже 2000-е годы, когда написанные на Java и для Java IDE достигли должной зрелости и приемлемой производительности.

итак:

https://en.wikipedia.org/wiki/Code_refactoring

там видимо вредители указали VS

.

https://en.wikipedia.org/wiki/Visual_Studio#Architecture

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

студия предполагает плугинами

https://marketplace.visualstudio.com/

очень похоже на то как они своим экселем и vba на корню подмяли под себя всю малую офисную автоматизацию

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

Понятно, ну продолжай изучать википедию, дело полезное.

вы не правы.

И какие из продуктов Адоба мьсе использует для работы? Иллюстратор? Премьер? Или может быть Фотошоп?

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

Барнаул, Алтайский край

Что ты сказать-то хочешь этой фразой?

Что ты сказать-то хочешь этой фразой?

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

Не неся херню про корпорации и идиотов вокруг.

А Барнаул? Барнаул это мантра такая.

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

не понял тебя: в сфере разработки десктопного гуи решения основанные на java были замещены html/js потому что что? потому что первые были архитектурно неудачны?

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

Можно долго спорить системах выравнивания контролах, наличия/отсутствия возможности низкоуровневого кодописания, но для средней арифметической конторы нанять людей и написать убогую софтину на HTML намного проще, чем сделать то же самое, скажем, на JavaFX. Да, можно спорить о том, что придется заставлять пользователя запускать огромный браузер, но не то чтобы JVM сильно отставала от хрома по ресурсожоркости (еще одно следствие плохой архитектуры жавы).

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

По итогу я пользуюсь приложениями на электроне, пользуюсь поделками на гтк и куте, даже НА ПИТОНЕ пишут гуй, но у меня нет ни одного приложения на жаве. У меня даже рантайма жавы не стоит. Поймите меня правильно: я не пытаюсь избегать всего жавового софта, я ставил себе ту же Android Studio, когда мне нужно было адаптировать софт под андроид, но софта под жаву реально МАЛО.

$ apt-cache rdepends default-jre | grep -v lib | grep -v python | wc -l
177
$ apt-cache rdepends python3 | grep -v lib | grep -v python | wc -l
937
apt-cache rdepends libqt5core5a | grep -v lib | grep -v python | wc -l
1316
apt-cache rdepends libgtk-3-0 | grep -v lib | grep -v python | wc -l
944

Справедливости ради, кросплатформенного софта на GTK тоже мало (поскольку GTK на самом деле не кроссплатформенный).

Теперь объясняю отличие между IDE и текстовым редактором с дополнениями которые ты любезно описал

А я объясню, что в свое время я участвовал в разработке гномового Anjuta, и с тех пор заработал такую аллергию на IDE, что даже в Delphi разрабатывал GUI в текстовом редакторе вместо WYSIWYG. И я могу обосновать свою позицию с позиции человека, который был по обе стороны баррикад, а не просто пришел с вопросом «где у вас тут шморгалка, как на моей Идее?».

Основная проблема IDE в том, что они НЕГИБКИЕ, то есть, она умеет работать только в строгом соответствии с какой-то моделью разработки, код должен написан в ожидаемом стиле, потому что если этого не будет, IDE начнет творить какую-то херню. Средний кода на Java, особенно старых версий, выглядит как машиногенерированный текст, и именно поэтому легко поддается парсингу/модификации через IDE. Однако, основная задача ЯП — это быть легко читаемым и легко писаемым человеком, и эту задачу Java с треском провалила.

Когда же код становится ближе к человеку, то выясняется, что человек любит писать ПО РАЗНОМУ, однотипные выражения он старается записывать концентрировано, вплоть до создания DSL доступными в ЯП средствами (например, это штатно можно сделать в C/C++ и Python). И тогда внезапно получается что инструменты анализа и рефакторинга кода превращаются в тыкву, а остаются лишь полуавтоматические анализаторы (которые требуют помощи человека) и инструменты редактирования голого текста (тоже полуавтоматика). То есть

Неиспользуемые классы и методы, неверная реализация и подсветка проблемных мест, CVE в конце концов.

В достаточно сложном проекте на НЕ-Java это не работает ни на одной IDE.

Я выше по пунктам перечислил что именно было в нормальных средах и чего не было в студии. Есть что добавить?

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

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

От этого премьера не перестанет жрать память и глючить.

код должен написан в ожидаемом стиле

Именно так и должно быть в любом нормальном проекте, не поверишь. Полагаю когда ты участвовал в разработке Anjuta то точно также соблюдал местные «stying guidelines» и «code conventions».

Когда же код становится ближе к человеку, то выясняется, что человек любит писать ПО РАЗНОМУ, однотипные выражения он старается записывать концентрировано, вплоть до создания DSL доступными в ЯП средствами

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

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

Неиспользуемые классы и методы, неверная реализация и подсветка проблемных мест, CVE в конце концов. В достаточно сложном проекте на НЕ-Java это не работает ни на одной IDE.

Работает работает, Node.js/.NET как минимум, скорее всего уже и в Golang завезли. Это мейнстрим и направление движения сейчас.

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

написать убогую софтину на HTML намного проще, чем сделать то же самое, скажем, на JavaFX.

понятно.

мой небольшой опыт написания убогих софтин говорит о том, что написать гуи на любом инструменте, называющим себя тулкитом (winforms, fx, pyside) примерно в один миллиард раз проще чем на html+css+js. качество софтины при этом в один миллиард раз выше чем у html+css+js.

в сфере разработки десктопного гуи решения основанные на java были замещены html/js потому что что?

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

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

но ты ведь и этого не говоришь.

Именно так и должно быть в любом нормальном проекте, не поверишь. Полагаю когда ты участвовал в разработке Anjuta то точно также соблюдал местные «stying guidelines» и «code conventions»

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

То что код мало написать, его еще потом надо будет многократно читать, причем другим людям - следующая стадия понимания на пути к просвящению

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

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

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

Неиспользуемые классы и методы, неверная реализация и подсветка проблемных мест, CVE в конце концов. В достаточно сложном проекте на НЕ-Java это не работает ни на одной IDE.

Работает работает, Node.js/.NET как минимум, скорее всего уже и в Golang завезли. Это мейнстрим и направление движения сейчас.

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

Конечно, если ты имел в виду TypeScript (а тогда стоило это явно указывать), то да, там получче ситуация, но не сильно, поскольку там уже сама система типов морочит голову.

проще отключить и никогда не включать вообще, потому что иначе будешь читать предупреждения больше, чем код

Подозреваю, что проблема тут совсем не в линтере %)

мой небольшой опыт написания убогих софтин говорит о том, что написать гуи на любом инструменте, называющим себя тулкитом (winforms, fx, pyside) примерно в один миллиард раз проще чем на html+css+js. качество софтины при этом в один миллиард раз выше чем у html+css+js

Мне кажется, что ты делал что-то не то, поскольку действительно просто писать на электроне только с готовыми виджетами, то есть, никакого html+css+js там нет, ты настраиваешь только свойства готовых элементов и прописываешь обработчики, прямо как в гуишных тулкитах. Проще только WYSIWYG среды, где прямо мышкой лепишь окошки.

И да, я имел опыт писания на html+css+js, это очень тяжело с учетом огромного числа слоев совместимости, накопившегося за годы, но делать это для быстрописания проектов смысла нет, примерно как нет смысла в писании GUI на одном только win32 API, через прямое создание окошечек, указание оконных процедур руками, и прочего, прочего, прочего — это сложно и не нужно.

я бы понял, если бы ты, например, сказал, что в отличие о Java, JavaScript - это язык который спроектирован хорошо

JS — такой же кусок дерьма, он там не играет большой роли. Electron используют ради Chromium, в частности, движка V8, а не ради JS самого по себе. Проблема возникла от того, что Java — такой же кусок дерьма, как JS, потому выраженного преимущества у него нет, особенно в свете продвижения статической типизации через TypeScript.

Подозреваю, что проблема тут совсем не в линтере

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

VS более чем соответствовала понятию IDE в середине двухтысячных (а не в 2015), была как минимум on-par с другими IDE

Я не знаком с VS и .NET как платформой, но много работал Java кодером в Eclipse. Краем уха наслышал что в VS многих фишек просто не было.

1. Навигация по .net classpath в VS появилась наверное после 2015 года? Может это бред?
   Короче как давно в VS стало возможным просто ходить дебаггером не только по своему коду, но и по тем же стандартным коллекциям .net или по коду third-party библиотеки?

2. Еще наслышан что в VS не было hotswap code replacment, когда можно менять код/логику без перезапуска приложения. После изменений класс фоном перекомпилировался и подкладывался в рантайм.

Это все было в Java даже 12 лет назад, когда именно стало доступным не знаю.

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

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

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

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

в середине конце 2000-х я наблюдал за этим только со стороны,

Я говорю про 2015 год.

не имеет большого значения при рассмотрении VS как IDE

В Java я кучу времени провел по хождению по classpath сторонних подключенных бибилиотек, я работал кодером с 2007 года, тогда же я начал использовать Eclipse и я даже не задумывался как бывает иначе.
И вот десятилетие спустя я от кого-то услышал что в VS вроде ходить можно было только по коду своего проекта, но не в сторонние библиотеки. Типа это фишка последних лет. И я думаю может это бред был сказан а я повелся?

Java — такой же кусок дерьма, как JS

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

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

Еще одну фишку нашел, оказывается code coverage появился в VS2015 и только в Enterprise.

А вот в бесплатной Eclipse code coverage уже давно использовался. Этак в 2012 году в фирме где я работал PM заморочился поднять code coverage тестами до 80% и приходилось следить, все ли основные ветвления покрыты.

Я нагуглил, дебажить ASP.NET в рамках своего проекта стало можно только с Visual Studio 2017. В 2015 тоже можно, но там целая эпопея. Надо ли говорить что это все уже давно было в Eclipse, я думаю он тут опередил VS лет на 5.

В 2015м просто видимо произошло озарение и начался процесс, но даже на 2023й год студия выглядит убого по сравнению с Java средами.

Я после текущего исследования тоже пришел к выводу что в 2015 году они решили наконец сделать из своего редактора IDE. Оказывается там кучи фишек не было.
Правда нужно взглянуть что там было с ReSharper, может он делал из VS современную IDE.

VSCode это большая победа Microsoft, поскольку он стал платформой для наверное всех современных «Web-based» редакторов кода, вроде ShaderToy

Но блин это не полноценная современная IDE. Хотя это не совсем тот форум где такое интересно изучать.

сделать из своего редактора IDE

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

VIM это редактор из которого делают IDE, VS до 2015 года был просто редактором с поддержкой AST некоторых языков и дебаггером.
Я привел факты которые указывают насколько VS до 2015 года уступал Eclipse 2010-2012 года, а именно три пункта:

1. Нет навигации по исходникам подключенных библиотек.
2. Нет code coverage.
3. Нет code hotswap reload.

P.S. VSCode мне нравится, пользуюсь для ts на frontend, и для заметок в markdown+katex. Для backend я сейчас пользуюсь Idea, к сожалению Eclipse мне очень разочаровал и в 2017 я с него ушел.

VS до 2015 года был просто редактором

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

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

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

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

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

Наслаждайся: https://yosefk.com/c fqa/fqa.html
Просто зацени масштаб. Это мой кумир, я на его твиттер подписан.

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

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

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

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

Ну чел тебе правильно ответил: .NET активно использует нативные библиотеки, по которым ходить можно только бинарным отладчиком (который, на самом деле, в VS есть). Для меня, наоборот, факт закрытости системных либ является чем-то самоочевидным.

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

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

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

NullPointerException и Type Erasure — это «другого уровня»? Как по мне — примерно такого же. Никакущая производительность у жавы без JIT присутствует аналогично JS. Жор памяти и там, и там, просто у электрона он происходит на запуске браузера. На самом деле, если начать писать на TS, то разница вообще станет исчезающая — та же Type Erasure, та же проверка по статическим класса до стирания, те же грабли с пустым значениям при неаккуратной обработке ошибок.

Разница только в том, что в Electron ты получаешь готовый вебсайт, который пользователь может открыть с любого девайса, поскольку браузер есть везде. Что ты будешь делать с жавоприложением? Предлагать пользователю запустить жавоаплет?

А вот в бесплатной Eclipse code coverage уже давно использовался. Этак в 2012 году в фирме где я работал PM заморочился поднять code coverage тестами до 80% и приходилось следить, все ли основные ветвления покрыты.

В C++ пытаться достичь code coverage — это особо изысканная специальная олимпиада, из-за неявных путей выполнения. Потому я даже не сильно в него верю, хотя мы на проекте покрытием пользуемся. Оно помогает отловить самые-самые очевидные прорехи, которые скорее всего и так бы отловились достаточно простым тестированием, а вот со сложными сценариями у него очень большие проблемы.

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

Я после текущего исследования тоже пришел к выводу что в 2015 году они решили наконец сделать из своего редактора IDE. Оказывается там кучи фишек не было.

Я посоветовал бы вспомнить, что монополистом в своих нишах MS был именно в те годы, когда VS был, по вашим словам, недо-IDE. После 2015 это уже было IDE для хипстеров с рюшечками и установкой по интернету... Ну то есть да, современная IDE.

VSCode это большая победа Microsoft, поскольку он стал платформой для наверное всех современных «Web-based» редакторов кода

VS Code изначально был пиар проектом с индусами в качестве ЦА — то есть, успех не совсем случайный. Заметьте, что вышел он спустя год после назначения индуса CEO Microsoft.

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

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

Назови одну вещь в IDE, без которой мое кодописание на C++/Python потеряет очень много? Я начинал карьеру в сплошных IDE, и я очень скептически отношусь к идее жавоподобных IDE вне мира жавы.

Для backend я сейчас пользуюсь Idea, к сожалению Eclipse мне очень разочаровал и в 2017 я с него ушел.

На чом у тебя бэк?

Тогда был Java, а после 17 стало Kotlin/Java.

«Неполноценная IDE» он настолько же, насколько неполноценны Vim или Emacs

Все эти редакторы «не полноценные IDE» только по сравнению с современными IDE. В VIM вообще нету AST! Т.е. у него даже хайлатинг лажает по определению, потому что он реализован через regexp’ы.

Но если мы мысленно перенесемся в 90-е или в самое начало 2000-х, то тогда было вообще не очень с инструментами разработки. Я немного знаком с VS6 из 2000-го, это был просто редактор с подсветкой синтаксиса + дебаггер в графическом режиме. Я не интересовался миром *nix в те годы но думаю из VIM и тем более из Emacs можно было сделать более полноценные IDE прицепив скриптами всю возможную автоматизацию по сборке, тестированию и модификации кода.

Тогда был Java, а после 17 стало Kotlin/Java.

Так и думал, но решил переспросить. Я давно говорю, что никто не пишет на жаве, все пишут либо на Eclipse, либо на IntelliJ Idea. Сам по себе Java как ЯП несостоятелен. Я просто никогда не писал ни на Java, ни на C#, потому мне ваши скорби по IDE непонятны.

А hot reload... Ну был у меня этот hot reload на JS с вебпаком, безо всяких IDE, и все равно окончательную проверку нужно делать перезапуском, потому что горячая перезагрузка не перестроит заново состояние. Чем ограниченнее инструментарий разработчика ­— тем проще сделать горячее обновление кода, и тем стабильнее оно работает. И наоборот, практически нереально сделать горячее обновление после изменения шаблоного кода C++ или сишного макроса.

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

Смотрю ты вообще крайне мало знаешь о людях.

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

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

И таких поциентов у реальных врачей сотни и тысячи. А ты про какой-то там рефакторинг.

Я немного знаком с VS6 из 2000-го, это был просто редактор с подсветкой синтаксиса + дебаггер в графическом режиме.

Я еще раз повторю вопрос: допустим, я программист на C++ с VS в начале нулевых — отсутствие каких фич заметно замедляет мою разработку? Hot reload? Code coverage? Перейти на символ в заголовке можно, но не особо полезно (я не в курсе, когда появилась фича «go to definition»).

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

Я просто никогда не писал ни на Java, ни на C#, потому мне ваши скорби по IDE непонятны.

Наверное из-за доступности кода в IDE и появилась такая максима как «лучшая документация это код».
Я вот заметил что многие программисты не из мира Java жалуются на плохую документацию в коде фремворков и либ. А я не понимаю как можно верить комментам (исключая стандартные библиотеки которые не будут менять поведение и контракты для их пользователей, если разработчики не хотят потерять их). Если бы не современные IDE было бы другое отношение, в том числе к документации, но я не сказал бы что отсутствие документации это плохо, я помню сколько фрустрации у меня вызывала дока в том же msdn. Ты не мог просто прочитать доку и все понять, нужно было «играться» с «черным ящиком» чтоб понять как с ним взаимодействовать и дока в этом помогала.

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

хорошо ок, отдельные доводы:

жава документирована. если, допустим, я захочу выяснить какой-то вопрос, ну например, как equality-wise сравниваются ордеред мапы, то в жаве я найду четкий и точный ответ (наверняка окажется, что об этом подумали лет так 20 назад и подумали нормально). в js? окажется что? наверняка какая-нибудь дичь: типа что equality-тестов там нет, только identity (допустим). или что нет equal/hashcode контракта. или… что нет мап, а объект для этих целей использовать будет не удобно. или вообще что нет ответа (среньк-пук вместо ответа, ой, мы об этом не подумали, ты неправильно делаешь, зачем тебе это надо, читай вот тут книжку гуры-мудака)

жава документирована. да даже если я захочу вообще понять что либо в жаба - я найду ответ в официальной документации. и окажется что это все продумано, есть какая-то «система» (понятий, инструментов). или в tutorial или в стандартной библиотеке или в JLS или в tech notes. не надо никакие сраные ю-донт-ноу-говно-js-книжки на 1000 страниц, где вынуждены обсуждать каждую молекулу высера именумого js. да для жава есть одна-три книжки полезные, но там не рассмотрение отдельных элементов бессмысленного хаоса, там другое.

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

другое - посрали, called it a day. через полтора десятиления (вроде) стали вливать огромные деньги в.. ускорение кала.

как это можно сравнивать вообще?

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

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

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

А потому что там тоже тупость и инертность, заблуждения десятилетиями передает из поколения в поколение и никто с этим ничего не делает. Реальный личный пример, который случился совсем недавно: в довольно дорогой стоматологии удалили на зубе нерв, хотя современная стоматология уже лет 7 как такие зубы спасает с гарантией 80-90%; на мое предложение ознакомиться с современными протоколами главврач ухмыльнулься и посмотрел как на идиота.

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

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

Интерфейс Win32 API намеренно сделан переусложненным и не до конца документированным, это свойство тщательно культивировалось, чтобы конкурент не мог повторить реализацию API. Большого прогресса Wine достиг именно в то время, как в сеть утекли полные сорцы NT4 и частично 2000.

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

То есть, мне от IDE нужен только отладчик, которые показывал бы строки кода и стэк вызова — зачем мне еще какая-то IDE?

Я еще раз повторю вопрос: допустим, я программист на C++ с VS в начале нулевых — отсутствие каких фич заметно замедляет мою разработку?

В начале 00-х я пытался «научиться программировать на C++ за 21 день». По книжке осваивал написание MFC приложения в VS. И вот там рассказано как создать логику на нажатие какой-нибудь кнопки. Создаешь нужный метод в контроллере и обязательно нужно прописать вызов какого-то макроса вначале и в конце метода. В книжке не сказано что делают эти макросы. Магия? И как же посмотреть что скрывается за макросами в «IDE»? Никак. Помню что не мог найти что именно инлайнится и какой код исполняется. Наверное у меня даже была дока в виде MSDN на трех дисках но мне и это не помогло.

Мои студенческие похождения конечно не впечатляют и мало ли что я не осилил из-за своей тупости. Хотелось бы услышать мнение настоящих программистов того времени, что там было у microsoft с докой, доступностью кода фреймворков и навигацией по нему в VS?

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

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

которые показывал бы строки кода и стэк вызова — зачем мне еще какая-то IDE?

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

еще отдельные доводы «с потолка», раз уж ты начал.

ну вот например: у жавы есть стандартная библиотека и считается что она (за каким-то исключениями) имеет очень высокое качество. сравнение не в пользу js (хотя может быть сейчас ситуация изменилась). ну например там есть collection framework. сравнение не пользу JS.

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

Для меня, наоборот, факт закрытости системных либ является чем-то самоочевидным.

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

Мир поменялся старик! Код будет свободным! :)

Я так понял тебе не нравится современная ООП парадигма, и я согласен что очень трудно дебажить «правильный код», где есть куча абстракций и десяток реализаций для каждой.
Мне не нужно продвинутое IDE в более простом и линейном коде, например для небольшого frontend (других не писал) мне хватает VSCode.
А есть сишные проекты написанные почти целиком в одном файле на 10к-100к строк, им наверное тоже не нужны никакие сложные IDE, хватит одного VIM с 2-3 плагинами, нужен поиск функции по имени, быстрый переход на функцию, автозамена, автодополннеие и пожалуй все.

в js? окажется что? наверняка какая-нибудь дичь: типа что equality-тестов там нет, только identity (допустим). или что нет equal/hashcode контракта. или… что нет мап, а объект для этих целей использовать будет не удобно. или вообще что нет ответа (среньк-пук вместо ответа, ой, мы об этом не подумали, ты неправильно делаешь, зачем тебе это надо, читай вот тут книжку гуры-мудака)

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

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

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

Я тебе умоляю, вот в этом
https://docs.oracle.com/javase/8/docs/api/java/util/LinkedList.html
ты видишь какую-то ценность? Что для сраного списка создано семь интерфейсов и пять уровней иерархии — я должен быть благодарен? Фактически настолько сложная система не поддается модификации в базовые сущностях (если в них специально не добавлен десяток интерфейсов расширения) — что есть типовой реазультат чрезмерного употребления класс-ориентированного программирования.

не надо никакие сраные ю-донт-ноу-говно-js-книжки на 1000 страниц, где вынуждены обсуждать каждую молекулу высера именумого js

Добрая половина фич JS в проде просто не используется, потому на собеседовании на фронт тебя даже не спросят про оператор нечеткого сравнения «==».

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

А получилось говно. Sun ответил за свои грехи. Я еще раз напомню свой тезис из соседнего треда:
Как вкатиться в проект? (комментарий)

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

Крупные корпорации очень часто скатываются в говно, используя имеющиеся ресурсы всё менее и менее эффективно. Вот ты пишешь, что доки стройные, модель стройная — именно это увидели люди, ответственные за принятие решений, именно для них это всё рисовалось. Что в реальном кодинге это не работает — никогда не волновало, потому что это люди изначально не умели реализовывать сложные системы, хотя считали, что умеют. Опять же, самоцитируясь:
Как вкатиться в проект? (комментарий)

разгребая говно тысячу раз, две тысячи раз, три тысячи раз, ты ни на шаг не приближаешься к получению навыка постройки дома. Ну то есть может и получил, но совсем не от того, что разгребал говно. Это болезнь, которой больна большая часть профессионального общества. Думают эти люди так: я выполнил работу, я получил деньги — значит я выполнил работу хорошо, значит я что-то умею, значит я могу создавать собственные программы...
Люди в упор не могут увидеть, что они не научились писать софт, они научились лишь выполнять работу/зарабатывать ­— это разные вещи, как тёплое и мягкое, как канал и канализация, как белый цвет и розовый шум, они могут быть вместе, но могут и не быть.

другое - посрали, called it a day. через полтора десятиления (вроде) стали вливать огромные деньги в.. ускорение кала

В JS ввели новые инструменты взамен старым, но для совместимости оставили старые. В современном проекте старые инструменты уже не используются, вместо них применяют только строгое равенство, стандартизированные модули, «let» вместо «var», лямбды вместо «function», форматирование строк вместо знака «+», контейнеры Map и Set для данных, спред "..." массивов и деструктурирование сложных объектов, и прочее — это уже совсем другой язык, нежели 20 лет назад. Уже не говоря про TypeScript, который в прямом смысле другой язык.

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

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

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

Ну то есть мне нужен отладчик, который умеет показывать исходный код при пошаговом выполнении. Это умеет даже gdb. Зачем мне эта ваша «IDE»?

Что для сраного списка создано семь интерфейсов

Это и прекрасно, LinkedList несет реализацию семи контрактов: реализует контракт списка, контракт очереди (в том числе двухсторонней), можно получить его копию (интерфейс Clonable), можно сохранить на диск (Serializable), элементы можно обходить разными способами (Interator, Collection).

Чего тут действительно не хватает так это интерфейса Stack, потому как на основе LinkedList реализуется и стек (методы push, pop). Но только вот когда-то в 90-х была опрометчива создана коллекция Stack и теперь ничего не поделать, этот анахронизм теперь до конца жизни платформы.

у жавы есть стандартная библиотека и считается что она (за каким-то исключениями) имеет очень высокое качество

Медленно работает и жрет кучу памяти — это входит в понятие «очень высокое качество»?

например там есть collection framework. сравнение не пользу JS

Стандартные типы данных в JS закрывают эдак 80% задач, для которых применяются collection framework. Можно спорить по поводу того, насколько эффективно они это делают, но, тем не менее, делают.

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

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

Многопоточность в JS еще хуже, да, она там на уровне C/C++, так что не стоит о грустном.

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

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

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

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

В JS ввели новые инструменты взамен старым, но для совместимости оставили старые

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

применяют только строгое равенство

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

я уверен, ты знаешь, но чтобы уточнить мою мысль: над экземплярам reference types можно провести identity test (бесполезный в нормальных задачах) и equality test. семантика последнего должна быть sane по-дефолту для встроенных в язык и библиотеку типов и определима программистом для его типов. иначе не сможет работать set, dict. но если она определима, то чтобы работало сносно нужно еще hash-code, но тогда он должен быть тоже определим. и тут возникает контракт который нужно документировать, и возникает или интерфейс или «протокол» (питон). и возникает, не только, как ты мне помог выразиться - стройность. что еще важнее, оно работает в практических задачах, особенно если сравнивать с тем, где этого нет. поэтому нечто, над чем думали - оно лучше, по крайней мере для макаки типа меня.

у value types identity нет, а equality тест очевиден.

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

---

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

Ну то есть мне нужен отладчик, который умеет показывать исходный код при пошаговом выполнении. Это умеет даже gdb. Зачем мне эта ваша «IDE»?

В CLI ты потратишь на дебаг не 30 минут а 2-3 часа :)

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

я признаться смутно помню и не эксперт, но там полно инструментов, они надежны, считается, что выверены/вычитаны. там ассортимент. можешь интринсик монитор брать синтаксисом, можешь мютексы из библиотеки, есть condition variables, есть executor сервисы, пулы, есть коллекции в которых там как-то само всё сделано. это даже я как пхпшник знаю, пробовал и могу сказать всё там нормально. и документировано всё. и оно работает и никаких дедлоков. и изучать для этого главу про JMM из JLS вовсе необязательно, есть другая точная официальная документация / публикации авторов.

с инструментами многопоточности в Go, которое хоть и не дает безупречных гарантий

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

безупречных гарантий

прямо «безупречные гарантии» я не знаю такой язык, это не язык нужен наверное, а ОС без многозадачности ну и с одним процессором понятно.

у жавы есть стандартная библиотека и считается что она (за каким-то исключениями) имеет очень высокое качество

Медленно работает и жрет кучу памяти — это входит в понятие «очень высокое качество»?

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

не бесплатно — нужно прописывать типы и снижается читаемость от лишних типов

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

А есть сишные проекты написанные почти целиком в одном файле на 10к-100к строк, им наверное тоже не нужны никакие сложные IDE, хватит одного VIM с 2-3 плагинами, нужен поиск функции по имени, быстрый переход на функцию, автозамена, автодополннеие и пожалуй все.

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

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

Это и прекрасно, LinkedList несет реализацию семи контрактов: реализует контракт списка, контракт очереди (в том числе двухсторонней), можно получить его копию (интерфейс Clonable), можно сохранить на диск (Serializable), элементы можно обходить разными способами (Interator, Collection)

А теперь представь, что список в JS реализует всё это без парада интерфейсов. Можно тихо-спокойно выполнить задачу, а можно выполнить ее пафосно, с торжественным парадом и оркестром. Как и сделали в Sun. Та же история была в Facebook:
https://habr.com/articles/593167/
Что они сделали в Facebook? Да вообщем-то ничего, они заменили Zookeeper на Zookeeper с их прокладкой. Но проект сдан, премии выплачены, задачи в жире закрыты, по графику и даже с опережением.

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

Чего тут действительно не хватает так это интерфейса Stack, потому как на основе LinkedList реализуется и стек (методы push, pop). Но только вот когда-то в 90-х была опрометчива создана коллекция Stack и теперь ничего не поделать, этот анахронизм теперь до конца жизни платформы.

Это типовой результат применения класс-ориентированной парадигмы. Реальные алгоритмы и интерфейсы имеют схожесть, но они никогда идеально не наследуются друг от друга, и всегда найдется какой-то очередной объект, который не впишется ни в одну модель. Именно потому МОДЕЛЬ ДОЛЖНА БЫТЬ КАК МОЖНО ПРОЩЕ.

А теперь представь, что список в JS реализует всё это без парада интерфейсов.

Ты что-то имеешь против статической типизации? Ранее ты утверждал что тесты могут заменить статическую проверку типов, только они не заменяют. Проверка типов удостоверяется в совместимости типов, тесты проверяют поведение.
Есть только одна альтернатива – Haskel, там вроде все гарантии на стадии компиляции, но желание осиливать FP у меня нет. Даже мальком увиденной дискуссии между FP кодерами как правильнее обернуть сайд эффект в манаду отбивает всякое желание. У меня такое ощущение что они не пишут программы а решают головоломки.

winforms, fx, pyside примерно в один миллиард раз проще чем на html+css+js

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

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

А теперь представь, что список в JS реализует всё это без парада интерфейсов

Списки в JS из коробки? Любопытно.

А теперь представь, что есть некоторый набор стандартных функций, который работает со списками (ну там filter, map, reduce и всё такое прочее), и тебе надо сделать, чтобы они работали и с твоим пользовательским типом тоже. Ну чтобы не городить этот чёртов map каждый чёртов раз для каждого чёртова нового типа.

Если стандартные функции реализованы в терминах абстракций (например, абстрактных типов данных, спрятанных за некоторым интерфейсом), ты просто реализуешь интерфейсы этих абстракций (условные cons, first и rest для абстрактного списка) в своём типе и откидываешься на спинку кресла, у тебя всё просто работает (тм).

Если же стандартные функции реализованы в терминах одного конкретного типа данных… ты вздыхаешь, запускаешь вим и начинаешь писать my-twisted-set-map. Ну или наследуешься от конкретного типа, который умеет map, со всеми вытекающими. Если тебе это высочайше позволено, конечно.

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

Люто плюсую к информации о типе ­­— в крестах я страдаю от отсутствия информации о типе.

Правда, по типам у меня есть замечание. Венгерская нотация была чудовищно извращена массовым программистом. Изначально префиксом переменной было НАЗНАЧЕНИЕ переменной. То есть, «индекс в строке имени» или «имя файла конфигурации» — это не просто «строка», не просто «число», а конкретная информация с конкретными применением. В пределе это «аргумент, который нужен этой функции» и «результат, возвращаемый этой функцией» — это и есть «тип».

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

Изначально префиксом переменной было НАЗНАЧЕНИЕ переменной

А в докстринге это описать не проще?

разверни мыль пожалуйста, разве запроектированное в языке соглашение equals/hash не об этом?

Для хэшмапа есть как минимум три распространенных формы сравнения: identity, равенство ключей, и равенство всех пар ключ-значение. Если хэшмап упорядоченный, то может добавиться равенство порядка... а может и не добавляться. Из-за сложности объекта возникает более одного сравнения для одого и того же объекта.

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

Зато этот тупиковый подход является хорошим оправданием для того, чтобы оставаться при работе, строгать метод за методом и интерфейс за интерфесом, получать гигантскую кучу взаимодублирующего кода, писать к ней такую же по объему документацию. Грубо говоря, для класса «собака» реализуем функции «почесать за ухом», «понюхать другую собаку», «пописать под кустом», «записаться в стрим» — короче говоря, формы взаимодействия С ДРУГИМИ ОБЪЕКТАМИ, что есть заранее невыполнимая до конца задача, потому что других объектов бесконечное число.

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

Кстати, за это же ненавижу Rust, только там кроме бесконечных специализированных функций есть еще нашествие ёлочек Option<Box<Vec<char>>>.

над экземплярам reference types можно провести identity test (бесполезный в нормальных задачах) и equality test. семантика последнего должна быть sane по-дефолту для встроенных в язык и библиотеку типов и определима программистом для его типов

Ты опять мыслишь в парадигме «класс должен уметь решать все на свете задачи». Как правило, сложный объект создают не для того, чтобы просто иметь ассоциативный массив строка-строка, там хранятся непростые ключи и непростые значения, которые могут по разному применяться в зависимости от того, какая функция с ними работает — именно потому нет никакого смысла раз и навсегда привязывать все функции к этому ассоциативному массиву. И когда ты это поймешь, то поймешь, что все эти сравнения сложных объектов должны реализовываться в ИСПОЛЬЗУЮЩЕМ хэшмап коде, а не в самом хэшмапе, реализацией либо явными функциями с говорящими названиями, либо прямо по месту инлайновым алгоритмом.

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

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

Есть классная статья по этой теме, но для питона, там в том числе пример того, как код писателя строчек получилось ужать в 120 раз:
https://habr.com/articles/140581/

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

Решает задачи пользователя. Больше меня ничего не колышет.

В CLI ты потратишь на дебаг не 30 минут а 2-3 часа

Да, я чувствую отсутствие адекватных отладчиков под линь, но торможение получается максимум в два раза. В частности, примерно потому никто не спешит делать удобный отладчик (не сильно горит). А еще в отладке собственных сложных проектов пошаговый проход отходит на второй план, важнее становятся логи и кордампы. Но да, порой хочется пройтись по незнакомому коду и просмотреть изменение переменных — этого реально не хватает, даже в GUI к GDB это реализовано всрато.

А в докстринге это описать не проще?

Можно и в докстринге. Я имел в виду, что ни названия переменных, ни названия типов не было достаточно для настоящего описания типа переменной ­— отсюда родилась венгерская нотация, когда присвоение целого числа от одной переменной inpVal к другой idxStart как бы кастует тип, хотя, казалось бы, у обоих переменных формальный тип int.

можешь интринсик монитор брать синтаксисом, можешь мютексы из библиотеки, есть condition variables, есть executor сервисы, пулы, есть коллекции в которых там как-то само всё сделано

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

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

Go исповедует идеологию shared nothing, как и Erlang.

присвоение целого числа от одной переменной inpVal к другой idxStart как бы кастует тип, хотя, казалось бы, у обоих переменных формальный тип int

Понел. Наверное, лучше так, чем писать два дополнительных класса InputValue<Integer> и StartIndex — хотя и на такое любители найдутся.

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

Ну что значит «насколько это разумно». Вот по-твоему, манагеры из Sun сидели и думали «как бы нам сделать стандартные контейнера, которые бы жрали память как не в себя и без тщательного прогрева на JIT-оптимизаторе имели бы производительность уровня Perl»? Но по результатам имеем именно это — ресурсожоркоое решение, лучше которого бывает даже питон на отдельных задачах (и именно потому питон до сих пор жив).

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

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

Наверное, лучше так, чем писать два дополнительных класса InputValue<Integer> и StartIndex — хотя и на такое любители найдутся.

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

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

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

Проверка типов удостоверяется в совместимости типов, тесты проверяют поведение.

В ЯП со статической типизацией проверка типов обычно лишь удостоверяется, что символ «A» будет интерпретирован как байты 65 и 0, а не как вещественное число с черт пойми каким значением. Больше они нихрена не проверяют, а в C/C++ есть еще и безумные приведения типов с подводными камнями, которые делают пользу от статических проверок еще более сомнительной.

Даже мальком увиденной дискуссии между FP кодерами как правильнее обернуть сайд эффект в манаду отбивает всякое желание. У меня такое ощущение что они не пишут программы а решают головоломки.

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

На самом деле нынче и C++, и C#, и Java бодро идут в сторону функционального программирования, другое дело, что инструментов для удобства писания ФП в них всего-ничего.

Из этого списка тебе всё приложение не повесят только многопотоковые коллекции

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

то поймешь, что все эти сравнения сложных объектов должны реализовываться в ИСПОЛЬЗУЮЩЕМ хэшмап коде

У меня когда-то была задача, где нужно было в качестве ключей использовать картинки. Причем нужно было «неточное сравнение» (т.е. допустимая разница в нексольких пикселях в несколько градаций серого). Причем нужно было лимит на размер мапы, то есть старое вытеснять. Деталей я не помню, по документации я обнаружил более подходящую мапу (чтобы выкидывала элементы и соответственно теряла ссылки на ключи). Дальше там то ли компаратор как-то подсунуть можно было, то ли я обернул просто эти картинки, но короче нужный equals добавил. Вполне работало, непроизводительно разумеется т.к. hashcode очевидно для неточного сравнения сделать невозможно. Но всё же. То есть вот это, то что ты говоришь, оно решается если нужно. При том что я не экперт вообще в жаве и вообще программист средний скажем так. То есть вот эта херота джавоская, которая ты говоришь ненужна (всмысле «стройность», наличие готового) - оно в целом помогало, мне так думается.

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

Это понятно. Кстати, и у питона и жавы (насколко помню) семантика сравнения словарей одинаковая. И если спросить меня, то я считаю, что она sane и практична. Что косвенно может говорить о том, что useful «дефолтное» equals для многих объектов придумать можно.

то поймешь, что все эти сравнения сложных объектов должны реализовываться в ИСПОЛЬЗУЮЩЕМ хэшмап коде

Для огромного числа объектов встроенная в него самого логика сравнения вполне себе возможна и нужна. То есть с этим лучше чем без. А «кастомное» - так оно всегда «кастомное».

Если стандартные функции реализованы в терминах абстракций (например, абстрактных типов данных, спрятанных за некоторым интерфейсом), ты просто реализуешь интерфейсы этих абстракций (условные cons, first и rest для абстрактного списка) в своём типе и откидываешься на спинку кресла, у тебя всё просто работает (тм).

Чтобы мы чуть конкретнее понимали задачу, можем взять, например, сериализацию в поток. Есть стандартный интерфейс сериализуемого объекта, есть стандартный интерфейс потока — что может пойти не так? Дело в том, что в любом случае на одной, второй, или обоих сторонах нужно будет адаптировать имеющиеся структуро-алгоримты к конкретной задаче сериализации, которая имеет свои причудливости в разных случаях. Нужна дополнительная передача по боковому каналу TCP/UDP? Сасаем со стандартными потоками. Нужна неблокирующая асинхронность? Снова сасаем. И так далее, Input/OutputStream в стандартной либе сделан по вполне конкретный спектр задач, и бесполезен за его пределами.

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

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

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

условные cons, first и rest для абстрактного списка

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

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

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

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

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

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

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

и у питона и жавы (насколко помню) семантика сравнения словарей одинаковая. И если спросить меня, то я считаю, что она sane и практична. Что косвенно может говорить о том, что useful «дефолтное» equals для многих объектов придумать можно.

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

Для огромного числа объектов встроенная в него самого логика сравнения вполне себе возможна и нужна. То есть с этим лучше чем без.

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

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

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

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

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

Есть стандартный интерфейс сериализуемого объекта, есть стандартный интерфейс потока — что может пойти не так?

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

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

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

Нужна дополнительная передача по боковому каналу TCP/UDP? Сасаем со стандартными потоками. Нужна неблокирующая асинхронность? Снова сасаем. И так далее

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

Input/OutputStream в стандартной либе сделан по вполне конкретный спектр задач, и бесполезен за его пределами.

Молоток сделан под конкретный спектр задач и бесполезен за его пределами. Удивительно %)

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

ты не понял, к чему эта иллюстрация была

Хэшмап полностью бесполезен, если у тебя нет точного сравнения

я в курсе и в цитате на которую ты отвечаешь это понятно

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

вероятно, но я в такое не умею

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

вот и я так же.

что ты упростил, создав десятки интерфейсов? Типовые задачи, реализация которых не представляет сложности

Взаимозаменяемость реализаций же. Молоток может быть на деревянной ручке, пластиковой или металлической, и забивать любые гвозди примерно одинаково. map, filter и reduce могут одинаково работать со списками, векторами и строками. Не нужно изобретать гвозди для молотков с металлической ручкой и отдельные vector-map, vector-filter и vector-reduce.

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

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

не понял кто кого косплеит. или я не знаю, что значит косплеить

насколько я помню, в джаве есть только небольшое число традиционных операторов над встроенными в язык value types. для объектов в java вообще нет операторов. исключения только == (чтобы сравнить ссылки можно было) и особняком стоит «+» существующий для строк. но плюс это особый случай, самой такой практики операторов для объектов в жаве нет. так же в java нет и пользовательского operator overloading.

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

условные cons, first и rest для абстрактного списка

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

На самом деле можно, просто это будет неэффективно. Вектор тут подходит лучше. Почему он подходит лучше? Потому что позволяет определение количества элементов и доступ по индексу элемента за постоянное время.

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

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

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

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

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

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

Нужна дополнительная передача по боковому каналу TCP/UDP? Сасаем со стандартными потоками. Нужна неблокирующая асинхронность? Снова сасаем. И так далее

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

В том числе потому я не верю в C++ STL. Этот инструмент устарел примерно в тот момент, как вышел, поскольку модель однопоточного программирования с синхронным вводом-выводом и выделением данных в стэковой форме или «бесплатной» куче перестала удовлетворять потребности где-то в конце 90-х, а вышла STL в начале 90-х. А потом какие-то придурки сделали Boost, чтобы hello world комплиировался несколько минут.

C++ STL

Boost

Спасибо тебе, г-споди, что я не сишнек.

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

ты не понял, к чему эта иллюстрация была

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

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

вот и я так же.

И это плохо, потому что это значит, что код фундаментально ненадежен.

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

есть альтернативные технологии для многопоточности где возникает каким-то образом доказательство корректности?

есть альтернативные технологии для многопоточности где возникает каким-то образом доказательство корректности?

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

Молоток может быть на деревянной ручке, пластиковой или металлической, и забивать любые гвозди примерно одинаково. map, filter и reduce могут одинаково работать со списками, векторами и строками. Не нужно изобретать гвозди для молотков с металлической ручкой и отдельные vector-map, vector-filter и vector-reduce.

Слабо замапить вектор в односвязанный список? Трансдьюсеры хороши, когда у тебя в ЯП всего 3-4 базовых контейнера и всё остальное строится на них. В том числе это актуально длы JS, как для типичного функционального языка.

не понял кто кого косплеит. или я не знаю, что значит косплеить

Костюмированные игры, когда детишки одевают костюм губки боба или человека-паука.

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

есть альтернативные технологии для многопоточности где возникает каким-то образом доказательство корректности?

Да, Clojure. Конечно, там корректность опирается на корректность реализации самой Clojure, но это уже ограниченная решаемая задача.

Слабо замапить вектор в односвязанный список?

Чё там по эффективности? Если без ленивости. Линейная сложность, я полагаю?

Трансдьюсеры хороши, когда у тебя в ЯП всего 3-4 базовых контейнера и всё остальное строится на них

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

Ты как я понял, говорил о бесполезности заложенной в жаву системы идей, в том числе касаемо упомянутого мной контракта equals/hash. атаковав его тем, что семантика сравнения носимая самим сравниваемым объектом - это так себе идея, т.к. часто этой семантика известна только клиенту мапы. и это в том числе подтверждает отсутствие ценности в том что авторы жавы напроектировали, то есть нет разницы между языком над которыми долго думали и, например, JS. и понятийной стройности в жаве нет, а только понятийная бесполезность.

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

при этом при всём, для обычных случаев коих 99% у обычных программистов, этот заложенный в жава контракт equals/hash вполне пригоден, и я уже повторяюсь, полезен. что доказывает, что java, как язык, который проектировали, лучше, чем какой-нибудь язык который не проектировали.

А если тебе нужно сделать точное сравнение картинки или сравнение по адерсу указателя — ты чем собрался пользоваться?

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

Я повторюсь, для очень многих типов это (идея о дефолтном equals()) работает. Это работает в конце концов для строк в стандартной бибилиотке. Строки сравниваются вызовом equals().

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

Костюмированные игры, когда детишки одевают костюм губки боба или человека-паука.

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

Можно узнать ответ на загадку про Apple?

Слабо замапить вектор в односвязанный список?

Чё там по эффективности? Если без ленивости. Линейная сложность, я полагаю?

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

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

Ничего, модель замечательна, JS примерно так и построен. Другое дело, что речь шла про Java, в которой такой простоты подавно нет.

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

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

при этом при всём, для обычных случаев коих 99% у обычных программистов, этот заложенный в жава контракт equals/hash вполне пригоден, и я уже повторяюсь, полезен. что доказывает, что java, как язык, который проектировали, лучше, чем какой-нибудь язык который не проектировали.

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

JS примерно так и построен

С абстрактностью вот только беда.

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

Неочевидный факт: в исходном питоне не было классов:

https://github.com/python/cpython/tree/85a5fbbdfea617f6cc8fae82c9e8c2b5c42443...

Идея добавить классы и несколько специализированных функций с подчеркиваниями появилась где-то к версии 1.0, вышедшей в 1994 году:

https://legacy.python.org/download/releases/src/python1.0.1.tar.gz

Там был очень ограниченный набор из __init__, __del__, __repr__, __cmp__, __len__, __getitem__, __setitem__, __delitem__, __getslice__, __setslice__, __delslice__. Потом уже их количетсво увеличилось в разы. Я подозреваю, что такая упоротость перегрузками возникла не из Java, а из C++.

Можно узнать ответ на загадку про Apple?

Ruby.

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

Не применительно конкретно к жаве, или даже именно к языкам - а вообще - вот с этим я согласен.

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

То же, я догадываюсь, справедливо и для JS до какой-то степени.

Питон аналогично: чрезвычайно сложный язык (for no good reason), наверняка на уровне C++ или сравнимо.

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

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

Потому твой пример лишь доказывает, что Java проектировали идиоты.

Ты не прав.

Я подозреваю, что такая упоротость перегрузками возникла не из Java, а из C++.

Ну наверное, ведь в Javа нет перегрузок операторов, да и вообще в Java нет операторов для reference types кроме, identity test (но это про ссылки, а не про объекты) и одного исключения для строк. Не знаю откуда это взял про «в питоне перегруженные операторы - косплей java»

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

Существует ли пример языка, который в твоем понимании был грамотно спроектирован, но не получил популярности?

Какой ЯП без классов порекомендуете?

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

Причем тут оператором-то?

Я говорил о контракте equals/hash в Java. Я не говорил про операторы. Ты почему-то начал про операторы сравнения объектов в Java (которых нет).

Уясни наконец: в джаве нет операторов reference types. Кроме identity test и одного синтактического исключения для строк. Java и python - это разные языки.

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

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

Сравнить два множества у тебя тоже никогда не возникало мысли?

вот про питон явно не так

питон со врем>н Бизли(1995) очень пророс на суперкомпах как скриптота для юзанья массовопаралельного фортрана на нихже

numpy (по началу Numeric(Paul Fred Dubois) на котором отрос scipy ) с тех времён

гугл как разтаки пытается подменить питон гофером

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

и снова нет

и С++ и Python отнаследовались прямо от Algol68

в догонку

numpy (по началу Numeric(Paul Fred Dubois)(P. F. Dubois, K. Hinsen, and J. Hugunin, “Numerical Python”, Computers in Physics, v. 10, #3, May/June 1996.)(интересный источник https://pfdubois.com/biography#0d36d19b-6831-405e-8407-d1cde83579e4 в низу pdf на 103 страницы (https://img1.wsimg.com/blobby/go/040f68a0-de26-4bdf-9c3a-4a1d9f4a2b29/downloads/Computational%20Science.pdf?ver=1656175737088)с автобиографией сего чела и очень примечательным экскурсом как из Basis выросло то что теперь Python) на котором отрос scipy ) с тех времён

JS примерно так и построен

С абстрактностью вот только беда.

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

Когда пишешь на JS очередной my-twisted-set-map — представляй себе розовых бегемотиков, бегущих по лужайке.

Починил.

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

Та же история, CPython со своей библиотекой по сложности примерно как C++. Не то, чтобы это давало какую-то индульгенцию C++ — он по прежнему остается №1 по переусложненности (из достаточно популярных).

То же, я догадываюсь, справедливо и для JS до какой-то степени.

JS минус неиспользуемые фичи дает ЯП, который сильно проще всех перечисленных. С неиспользуемыми фичами — да, что-то около PHP.

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

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

Существует ли пример языка, который в твоем понимании был грамотно спроектирован, но не получил популярности?

Да, паскаль вообще без каких-либо сомнений могу называть. Самое смешное то, что он был в одном шаге от того, чтобы стать стандартом за 6 лет до фактической реализации первого компилятора паскаля. Но «почти» не считается. Проблема лишь в том, что нынче не 1985 год, паскаль устарел и адекватного развития не получил. Вместо развития получили забытый Component Pascal и уродливыйObjective Pascal — последний по итогу просто с большим опозданием копировал уродливые фичи С++.

Rust имел очень хорошую идею в фундаменте, и я даже серьезно думал в него вкатываться, но крестовики эту идею испоганили, получив жутко переусложненный язык, который компилируется дольше С++ (у нас вообще есть другие ЯП, которые компилируются дольше С++?).

Какой ЯП без классов порекомендуете?

Go.

питон со врем>н Бизли(1995) очень пророс на суперкомпах как скриптота для юзанья массовопаралельного фортрана на нихже

Про какое время после 1995 года идет речь? В этой статье:
https://web.archive.org/web/20190219031439/https://www.computer.org/csdl/mags...
говорится про маленькую, но преданную группу ученых, и ничего не говорится про суперкомпьютеры.

numpy (по началу Numeric(Paul Fred Dubois) на котором отрос scipy ) с тех времён

Numpy — это уже 2006 год.

гугл как разтаки пытается подменить питон гофером

В начале нулевых гугл организовал проект по реализации JIT-оптимизации для питона, но очень быстро выяснилось, что у гугла нет столько триллионов денег, чтобы реализовать JIT-оптимизацию для питона. Позже на результатах этого проекта был сделан PyPy, по которому видны все ограничения JIT-оптимизации, в частности — он не может оптимизировать ни одно расширение, включая NumPy и Pandas, а значит зачем он нужен?

Когда гуглу стала ясна бесперспективность проекта, то он перешел к поиску альтернатив, и по итогу создал свою альтернативу Java и Python одновременно. Заметь, что базовые типы у Go примерно такие же, как у Python (строка, массив, ассоциативный массив, объект struct и duck-typed интерфейсы к нему).

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

Я настаиваю на том, что до гугла питон был языком, на котором писала очень узкая группа маргиналов. Да, гугл взял питон не в зародыше, а после нескольких лет развития маргиналами — тем хуже результат, уже к 2000 году питон был неисправим без полной перестройки языка и переписывания всех расширений. Как ни странно, именно Numeric/Numarray/Numpy (в хронологическом порядке) и построенные на них иные расширения гарантируют, что питон никогда не будет развиваться, потому что это сплошные implementation-defined API, то есть, один проект зависит ото всей реализации другого проекта.

и С++ и Python отнаследовались прямо от Algol68

Есть интервью Гвиды, где он рассказывает, кто от кого отнаследовался:
https://web.archive.org/web/20070501105422/http://www.amk.ca/python/writing/g...

ABC was a major influence, of course, since I had been working on it at CWI. It inspired the use of indentation to delimit blocks, the high-level types, and parts of the object implementation. I'd spent a summer at DEC's Systems Research Center, which introduced me to Modula-2+; the Modula-3 final report was being written there at about the same time. What I learned there later showed up in Python's exception handling, modules, and the fact that methods explicitly contain 'self' in their parameter list. String slicing came from Algol-68 and Icon.

C is another influence, second only to ABC in importance. Most of Python's keywords, such as break, continue and others, are identical to C's, as are operator priorities. C also affected early extension modules; many of them, such as the socket and POSIX modules, are simply the corresponding Unix C functions translated into Python, with some modifications to make programming more comfortable. For example, errors raise exceptions rather than return a negative value, and sockets are objects.

The Bourne shell was also a model for Python's behaviour. Like the shell, Python can execute scripts by specifying their filename, but when run without arguments, it presents you with an interactive prompt. This is well suited for experimenting with the language, or with a new module you're trying to learn.

Неочевидный факт, который видно из сорцов самого первого питона — там не было классов. Вообще. Были объекты, как в JS. Код строился на функциях, как это опять-таки делается в JS. Модули тоже выполняли роль объектов. То есть, можно сказать, что «класс», как новый тип объекта, можно было написать только в форме сишного расширения, в самом языке средств создания новых типов не было.

Причем, наследие этой модели ярко проявлялось в двойке и было устранено только в третьем питоне, а именно: два сильно разных семейства объектов (old-style classes vs new-style classes); отсутствие прямых эквивалентов сишным хукам (постепенно было введено большое число магических методов с подчеркиваниями для этой функции); неограниченный доступ к глобальному пространству имен, которую закрыли уже в двойке, но только к тройке добавили nonlocal, чтобы различать переменные родительских функций и глобальные переменные модуля (до того опять же был только один global).

Потому, да, питон не относледовался от C++, хотя позже приобрел его классы. Примерно как C расширялся с B, сам B был подобием SMALGOL, урезанного старого Алгола, но в Си были добавлены типы, подобные типам из Алгол-68.

Потому можно считать, что ABC и C в значительной степени были производными Алгол-68, Модула — это вообще производная паскаля, являющегося производным перво-Алгола — питон стал производным этих трех, так что связь довольно непрямая, нельзя сказать «Python отнаследовался прямо от Algol68».

P. F. Dubois, K. Hinsen, and J. Hugunin, “Numerical Python”, Computers in Physics, v. 10, #3, May/June 1996

Сама статья:
https://pubs.aip.org/aip/cip/article-abstract/10/4/359/136360/Extending-Pytho...

Потому можно считать, что ABC и C в значительной степени были производными Алгол-68, Модула — это вообще производная паскаля, являющегося производным перво-Алгола — питон стал производным этих трех, так что связь довольно непрямая, нельзя сказать «Python отнаследовался прямо от Algol68».

«Influenced by» это дословно «повлиял», это не про унаследовал или вообще какие-либо родственные узы.

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

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

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

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

сделаю такой обзор сам

Таблицу, по столбцам семейства языков, по строкам идеи.

Ниже были ссылки-одна из них:

https://scipy.github.io/old-wiki/pages/History_of_SciPy

в которой поясняется за чехарду с Numeric|Numpy начиная с 1995 - Олифант постепенно потеснил(в 1999 один из соавторов) и переписал (в 2006 его мануал)

во второй половине 90ых питон очень разош>лся по академии 1.5 на той же uve(сервер олимпиадного программирования)Скиены предлагался для скачивания

пример с Бизли который начал swig для всей скриптоты но очень быстро(в 1996) добавил и питон хотя он же уже в 1994 использовал питон для скриптоты на числодробилке

крч - гугль свой поисковик писали уже на питоне - а не на оборот

один из редакторов пересмотренного сообщения алгол-68 был директором в 80ых той шайки-лейки где Гвидо выносил python - подход с дандер методами - которые в изначальном питоне сразу были это несколько похоже на подход 68го где есть представление публикации vs представление на машине

ваще видно как в середине 90ых что луа что js что python позиционировались как встраиваимые + язык_клей - и как по разному их «судьба разбросала»

крч - гугль свой поисковик писали уже на питоне - а не на оборот

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

По факту ажно до 2003 питон был потешным язычком для скриптинга, полностью зависевшим от сишных биндингов, но при этом в версии 1.5 имевшем примерно 15% от того, что есть в стандартной питонолибе сейчас (вы можете убедиться в этом сами https://legacy.python.org/download/releases/src/ ). И нет, Swig — это совсем не то же, что родные биндинги, потому что вываливает всю небезопасность сишного кода в питоний. Из готовых либ наиболее видными были предки NumPy, но там была такая лапша, что в стандартную либу их бы никто в своем уме не включил.

Именно в таком виде питон въехал в 21-й век: системная клей-скриптота с батарейками для ученых. Неочевидный факт — Грин и Пейдж по слухам от первых работавших в гугле людей были ужасными кодерами, и при этом происходили из институтской среды — идеальная ЦА для питона. Это я плавно подвожу к тому, что качество питона как языка очень спорно, но факт в том, что он нашел поддержку в институтских кругах, там очень долго и медленно развивался и получал поддержку с 2003 где-то до 2008 года, после чего был принят тем же MIT в качестве ЯП для обучения студней — с этого момента пошел резкий рост популярности. Можно спорить по поводу того, был ли MIT причиной или следствием — для нас важен лишь факт медленного роста популярности питона, никакого бума по факту использования гуглом и ютьюбом питона не наблюдалось, графики PyPl, TIOBE, Sourceforge это подтверждают.

Даже после 2008 питон был в основной системной скриптотой плюс датасаенс батарейки. Можно спорить, что вообще-то даже сейчас он собой именно это и представляет, несмотря на то, что некоторые люди на всяких там Django и Pyramid делает вебсаеты.

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

подход с дандер методами - которые в изначальном питоне сразу были

Дандер-методов не было в «изначальном» питоне, в котором даже классов не было, классы с дандерами появились где-то в районе 1.0. Да, slicing и дандеры взяты напрямую из алгол-68, но там реально единицы фич были подсмотрены из этого ЯП, большая часть все-таки заимствована из других.

По факту ажно до 2003 питон был потешным язычком для скриптинга, полностью зависевшим от сишных биндингов, но при этом в версии 1.5 имевшем примерно 15% от того, что есть в стандартной питонолибе сейчас

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

При желании можно найти ранние фото Шварцнеггера или Сталлоне и узнать что они не всегда были суперзвездами и в 17 лет были похожи на обычных людей.

Простой факт что из простого и убогого со временем и усилиями вырастает сложное и красивое вызывает вопросы?

закругляя диспут

частично питон повторил траекторию паскаля (из европы через академию)

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

частично си - язык всёж отделяет себя от операционной среды ( чего до си не было - все языки считали что их программа на голой машине а ось - это так набор библиотек)

и важно в успехе Python - сыграло то что им начали скриптит на суперкомпах работу с вычесанными fortran-либами - это просто ща не заметно за событиями которые случились с языком потом - а в первой половине 90-ых это реально оказалось килерфичей - студенты(аспиранты) лепят код на питоне а числодробление в фортране - mit по ходу не смог защитить схему а на жабу ушёл в отказ - а так как в америце к тому времени на питоне могли во всех лабах (и ливерморе тоже ) - то вот

гугл с go реально опоздал на несколько лет - выкати они его на пару лет раньше - …

А какой все же смысл изучать и подчеркивать именно убогость чего-то, еще и в историческом плане?'
Простой факт что из простого и убогого со временем и усилиями вырастает сложное и красивое вызывает вопросы?

Да, вызывает вопросы. Хочется понимать, предсказывать, управлять. А поскольку люди на планете всё те же, то и подходы к ним можно применять те же. У меня другой вопрос — почему на подобные темы никто не пишет книжек? Или хотя бы статей. Реально трезвая объективная оценка успешности-неуспешности того или иного проекта — огромная редкость.

частично лиспа - есть repl и можно сидеть в питоне как в шелле

Ты оговорился по фрейду — вообще-то он повторил шелл.

частично си - язык всёж отделяет себя от операционной среды ( чего до си не было - все языки считали что их программа на голой машине а ось - это так набор библиотек)

Всё было наоборот: до Си большинство языков, кроме асма, создавали высокоуровневую абстракцию, которая абстрагировала кодера от заморочек процессора. А ОС или без — это уже не так важно.

Далее, влияние Си в том, что Гвидо на самом деле скаргокультировал целый ряд концептов Си, как то непрерывные массивы, передаваемые по ссылке изменяемые по месту сложные объекты (список, словарь, класс) и копируемые неизменяемые простые (числа, строковые константы) — всему этому, по-хорошему, нечего делать в высокоуровневом ЯП, где пользователь захочет добавлять элементы только в начало списка и при этом обязательно запутается в правах владения, случайно поменяв переданный по ссылке список (а его трудно передать не по ссылке).

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

и важно в успехе Python - сыграло то что им начали скриптит на суперкомпах работу с вычесанными fortran-либами - это просто ща не заметно за событиями которые случились с языком потом - а в первой половине 90-ых это реально оказалось килерфичей

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

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

в языках типа python и java это не «переданный по ссылке список». python и java - они строго pass by value. просто некоторые, путают parameter-passing scheme и value vs. reference types. а некоторые другие, к примеру, автор релевантной страницы в документации питона - используют термины отличные от устоявшихся в индустрии.

pass by reference - это другое, ни в питоне, ни жаве этого нет.

в языках типа python и java это не «переданный по ссылке список». python и java - они строго pass by value. просто некоторые, путают parameter-passing scheme и value vs. reference types. а некоторые другие, к примеру, автор релевантной страницы в документации питона - используют термины отличные от устоявшихся в индустрии.

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

Прочитай сообщение на которое ты отвечаешь внимательнее. Питон строго pass by value, так же как и джава.

Прочитай сообщение на которое ты отвечаешь внимательнее. Питон строго pass by value, так же как и джава.

Ты такой зануда... По значению передается ссылка, а в C/C++ вообще передача по ссылке и передача ссылки по значению равнозначны. Еще можно сказать, что в питоне и жаве ссылка передается по значению, а значение — по ссылке.

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

По значению передается ссылка

Именно.

а в C/C++ вообще передача по ссылке и передача ссылки по значению равнозначны.

Во-первых, ты говорил о питоне. Во-вторых, ссылки - не указатели.

В третьих. Я не особенно знаю С, но эквивалентом того, что в языках (которые не C) называют «pass by reference» для C будет &локальной переменной и передача полученного указателя, где его разыменуют и поредактируют тебе переменную, что ты обнаружишь по возврату. Так понятно?

в C/C++ вообще передача по ссылке и передача ссылки по значению равнозначны

Ну нет же. Даже моих околонулевых знаний C достаточно чтобы понимать, что не эквивалентно.

питоне и жаве ссылка передается по значению, а значение — по ссылке.

Нет. Если ты говоришь «передается по ссылке» имя в виду англ. «pass by reference», то нет. Ни жвае, ни в питоне это невозможно. Java и Python только pass by value. Из языков о которых я знаю, pass by reference возможно в PHP и C#.

Parameter passing scheme - это одно. Деление на value types и reference types это другое.

Ты такой зануда…

Нет, просто ты ошибаешься и при этом еще споришь. Pass by reference - это другое. Это устоявшаяся терминология, нужна ровно для того, чтобы не допускать вот этой путаницы которую ты допустил.

Primitive arguments, such as an int or a double, are passed into methods by value. This means that any changes to the values of the parameters exist only within the scope of the method. When the method returns, the parameters are gone and any changes to them are lost.

Reference data type parameters, such as objects, are also passed into methods by value. This means that when the method returns, the passed-in reference still references the same object as before.

https://docs.oracle.com/javase/tutorial/java/javaOO/arguments.html

For example, suppose the caller passes a local variable expression or an array element access expression. The called method can then replace the object to which the ref parameter refers. In that case, the caller’s local variable_ or the array element refers to the new object when the method returns.

Don’t confuse the concept of passing by reference with the concept of reference types. The two concepts are not the same.

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref

Нет, просто ты ошибаешься и при этом еще споришь. Pass by reference - это другое. Это устоявшаяся терминология, нужна ровно для того, чтобы не допускать вот этой путаницы которую ты допустил.

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