Здравствуйте, neFormal, Вы писали:

C>>Нет. К моменту запуска/компиляции типы уже не нужны (кроме как для оптимизации). Они нужны во время разработки.
F>всё верно, я о том же.
F>не было бы типов, этот сорт погромистов делал бы падучее багло, потому что без костылей для разработки они уже не могут
F>так же и появились вообще типы, не?
Нет. Изначально типы появились для оптимизации. После чего было обнаружено, что типы так же сильно помогают с документированием кода.

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

F>>>фактически виртуальная машина и переменные окружения — немножко не одно и то же.
C>>Docker — это не виртуальная машина. Учим матчасть.
F>не пропускай слова.
F>докер даёт эмуляцию системы, что для пользователя выглядит, как виртуалка
Ровно как и venv.

C>Т.е. программист на статическом языке может посмотреть на код и за один взгляд понять с какими данными он работает.

в тред врывается вывод типов

и чтобы два раза не вставать, статические программисты тоже пишут тонны копротестов, чтобы покрыть инварианты легко выражаемые в чем-то типа dafny, но в c#/java/c++ не выражаемые никак
ну или не пишут — динамические тоже, бывает, не пишут.
c'est la vie

Здравствуйте, Cyberax, Вы писали:


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

Что значит без автоматической навигации, в куда? Go to работают же...

Здравствуйте, Sharov, Вы писали:

C>>Т.е. программист на статическом языке может посмотреть на код и за один взгляд понять с какими данными он работает. Динамические пргограммисты вынуждены судорожно копаться в тоннах копротестов, чтобы найти кусочек, который запускает нужный код. Без всякой автоматической навигации и гарантии того, что тест вообще написан правильно.
S>Что значит без автоматической навигации, в куда? Go to работают же...

class DoSomething(object):
   def foo(self, blah):
      blah.frobnicate()

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

Здравствуйте, koenig, Вы писали:

C>>Т.е. программист на статическом языке может посмотреть на код и за один взгляд понять с какими данными он работает.
K>в тред врывается вывод типов
IDE его решает.

K>и чтобы два раза не вставать, статические программисты тоже пишут тонны копротестов, чтобы покрыть инварианты легко выражаемые в чем-то типа dafny, но в c#/java/c++ не выражаемые никак
Ну я не против, если бы были промышленные языки, в которых были бы более богатые системы типов. Но пока таких нет.

C>>>Т.е. программист на статическом языке может посмотреть на код и за один взгляд понять с какими данными он работает.
K>>в тред врывается вывод типов
C>IDE его решает.

один взгляд превращается в элегантные шорты

C>Ну я не против, если бы были промышленные языки, в которых были бы более богатые системы типов. Но пока таких нет.

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

Здравствуйте, Calc, Вы писали:

D>>Ну как бы современный веб — это статический js-фронтенд (чаще всего на каком-нибудь React или Angular), который на бекэнд ходит за данными в формате json. PHP для этого ну вообще не нужен.

C>база напрямую отдает json?

"База"? Бэкенд отдаёт json, да. Откуда он его берёт — дело десятое.

Здравствуйте, Dair, Вы писали:

D>"База"? Бэкенд отдаёт json, да. Откуда он его берёт — дело десятое.
Этот комментарий эпичненько смотрится в сочетании с названием топика.

Здравствуйте, Sinclair, Вы писали:

D>>"База"? Бэкенд отдаёт json, да. Откуда он его берёт — дело десятое.
S>Этот комментарий эпичненько смотрится в сочетании с названием топика.

Эээ

Я, конечно, не настоящий сварщик, но скажи, где я ошибся.

Здравствуйте, koenig, Вы писали:

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

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

Здравствуйте, Dair, Вы писали:

D>"База"? Бэкенд отдаёт json, да. Откуда он его берёт — дело десятое.

Потому тема и растянулась на 10 страниц, что дело 10-е?

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

Здравствуйте, Cyberax, Вы писали:

C>И какой же? Я не знаю ни одного крупного проекта на Лиспе, кроме emacs. Собственно, даже и мелких проектов не знаю.

вот и выросло поколение, которое не вспоминает про автокад, когда разговор заходит за лисп

Здравствуйте, Cyberax, Вы писали:

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

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

Здравствуйте, Dair, Вы писали:
D>Я, конечно, не настоящий сварщик, но скажи, где я ошибся.
Вопрос: "на чём писать бэкенд".
Ваш ответ: на JSON. Откуда брать JSON — дело десятое.

А мы ещё в детстве смеялись над анекдотом про "рация — на ТАНКЕ!".

Здравствуйте, neFormal, Вы писали:

C>>И какой же? Я не знаю ни одного крупного проекта на Лиспе, кроме emacs. Собственно, даже и мелких проектов не знаю.
F>вот и выросло поколение, которое не вспоминает про автокад, когда разговор заходит за лисп
Я его помню, но там ЛИСП таки просто для встраиваемого языка. Не особо удачного, кстати. Сам АвтоДеск написан на сильнотипизированном С++.

Что именно есть написанного на ЛИСПе?

Здравствуйте, Cyberax, Вы писали:

C>Это самый уродливый язык в природе.

Ну неправда же. JS гораздо уродливее.

Здравствуйте, Cyberax, Вы писали:

C>

C>class DoSomething(object):
C>   def foo(self, blah):
C>      blah.frobnicate()
C>

C>Ну и куда будем навигироваться при попытке найти определение frobnicate?

М-да, питон я вообще не знаю. Кроме как простейших 5 строчек.
Удивило, что pycharm не предложил DoSomething3 в данном примере:

class DoSomething(object):
   def foo(self, blah):
      blah.frobnicate()



class DoSomething2(object):
    q = DoSomething()
    q2 = DoSomething3()
    q.foo(q2)



class DoSomething3(object):
   def frobnicate(self, blah):
       return 1

По идее можно же что-то предолжить, ведь и класс есть с похожим методом и как аргумент передается в соотв. ф-ию... Но все равно глухо.

Здравствуйте, koenig, Вы писали:

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

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

Здравствуйте, Ночной Смотрящий, Вы писали:

C>>Так SQL как раз — это динамический язык.
НС>Причем непонятно почему.
SQL проектировался как язык для не программистов. Из этого все его косяки и растут. Авторы просто боялись напугать бухгалтеров типами.

Здравствуйте, neFormal, Вы писали:

WH>>>>Так скрипт заполняет определённые структуры данных.
WH>>>>Дёргает определённое API.
F>>>или нет
WH>>Что за детский сад. Если нет аргументов так и скажи что был не прав.

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

F>не, ну если ты обобщаешь на вообще все данные, то я могу привести примеры, где это неприменимо
F>давай оставаться в рамках примера с конфигами
С конфигами у тебя ничего не получилось.
И тут не получится.

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

F>кроме того, многие готовые системы не позволяют сменить язык на тот, где есть АТД, или активно использовать рефлексию.
F>а программисты избегают сложных генераторов и, зачастую, не умеют их писать.
Добавить скалу (которая бесшовно интегрируется с жабой) для сложной логики не позволяют, а сменить жабу на питон значит позволяют?
Зашибись логика.

F>преимущество в скорости введения фичи.
F>гетерогенные коллекции интуитивно понятней и требуют меньше работы для поддержки.
Это просто не правда.

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

F>всё это решается на этапе автотестов. на выходе получается комплекс из кода и конфигов, которые в нём работают


WH>>То есть твоя цель это написать падучий багодром? Я тебя правильно понял?
F>да, потому что это вылезает на тестировании.
Зачем ловить тестами то, что гарантированно устраняется типами?
А если мы возьмем, например rust то быстро поймём что те ошибки, которые ловит его система типов тестами нельзя поймать вообще.
https://blog.faraday.io/saved-by-the-compiler-parallelizing-a-loop-with-rust-and-rayon/

F>такие системы имхо меньше приспособлены к отдаче в неподготовленные руки(хотя это может быть спорно), потому что требуют большего понимания предметной области
Ты сам-то понял что написал?

F>а ошибки будут попроще. типа, "в такой-то сущности нет такого-то поля"
И что пользователь программы с этой ошибкой будет делать?
В случае со статикой с ней будет разбираться программист. Причём из-за того что такие ошибки всплывают сразу после изменений у него будет весь контекст проблемы в голове.
На статически типизированных языках так рефакторинг делают. Что-то меняют и потом исправляют ошибки типизации.