раскрыть ветку (49)
раскрыть ветку (46)
В смысле? Я в этой теме не шарю, но было бы любопытно посмотреть как такое вообще может происходить. Типа, блин, в pyton придумали блоки выделять не чем-то нормальным символьным и понятным вроде фигурных скобок, а решили положиться просто на отступы в текстовом редакторе и научили компилятор нормально понимать что до чего? Если так, то такой фокус можно с любым ЯП провернуть, хотя бы на уровне расстановки блоков согласно отступам перед компиляцией.
Правда, это из таких решений вроде как шасси от самолёта на него не ставить, а делать платформой на полосе, чтоб он на неё точно садился и катился потом - очень экономно и упрощает конструкцию самолёта, но надёжность страдает...
раскрыть ветку (11)
раскрыть ветку (8)
Спасибо, теперь точно ясно, что дело именно в отказе от выделения блоков фигурными скобками. Ну, во всяком случае в pyton хотя бы нет споров о том, оставлять открывающую фигурную скобочку в конце строки или переносить на следующую. И это уже неплохо.
раскрыть ветку (7)
раскрыть ветку (4)
Ахаха... Так в pyton та же петрушка есть, только не для фигурных скобочек? :)
Даёшь бой всяким скобочкам! Только отступы и пробелы! (и запятые) :)
раскрыть ветку (3)
Ну на самом деле в PEP прописано все. Сколько символов макс в строке, какой тип названия переменных используется и тп, сколько пробклов где, как переносить. В общем, есть куча всего, что не влияет на выполнение кода, но при этом будет не соответствовать правилам PEP. Например ты можешь спокойно использовать camelCase для переменных, но в PEP это не так прописано
раскрыть ветку (2)
Запомню на случай, если меня основательно понесёт в нейросети и стану учить pyton, конечно. Но вообще snake_case, например, мне действительно нравится больше, хотя он мало где принят за правило для написания хоть чего-нибудь.
раскрыть ветку (1)
А где есть такие споры? Есть же соглашения о кодстайле и типа о чем там можно спорить? Опять же таки код стайл в разных компаниях может отличаться, но там есть своё внутреннее соглашение следуя которому ты и будешь писать код. Там тоже спорить не о чем_)
раскрыть ветку (1)
Тут согласен - в компаниях такого нет и это вполне разумно и правильно. К тому же даже не обязательно писать код согласно кодстайлу компании изначально, ведь зачастую есть такая штука, как автоматический рестайл кода, так что вся заморочка в одном нажатии кнопки, чтобы сделать как себе удобно.
Но. Вот сидим я и Вася Пупкин, и что бы как-то поддержать беседу я говорю, что в блоках кода всенепременно надо ставить фигурную скобку на новой строке, ибо хоть это и занимает отдельную строку, однако ж визуально выделение блока становится более различимым, и что пока я даже ещё не начал называть все другие преимущества, миру пора бы уже это осознать, прийти наконец к единому кодстайлу и закончить уже этот цирк... Ну, как бы понятно, что на уровне аргументированно попытаться доказать куда действительно объективно лучше ставить эту всратую скобочку, можно провести не один час разговоров.
Нормальная поддержка отступов - вынужденная мера в любом функциональном языке программирования (haskell и т.д.). Питон очень хорошо поддерживает функциональную парадигму, поэтому добавлять фигурные скобки и точки запятой - наоборот было бы лишней работой в данном случае, не очень для языка обоснованной.
Fortran!
ох, сколько я намучился с ним раньше... Если программа берет тело subroutine из файла, то весь текст в файле должен иметь отступ. Понять и простить..
раскрыть ветку (17)
А ещё нумерация, описание каждой переменной в каждом призыве и прочий ад
данила, 21 год, писал диплом на Фортране (перекожживал что было написано в 80х под нынешнюю задачу)
данила, 21 год, писал диплом на Фортране (перекожживал что было написано в 80х под нынешнюю задачу)
раскрыть ветку (16)
данила, 21 год, писал диплом на Фортране
Запятая лишняя, я исправил:
данила, 21 год писал диплом на Фортране
раскрыть ветку (14)
Математическое решение уравнения с 6 неизвестными (матрицы 6х6) с мнимой частью.
сама задача: рассчет спиновых волн с учётом магнитного момента (до этого не предполагалось что магнитное взаимодействие волн имеет место быть)
спойлер:
Теория приблизилась к практике с погрешностью 0.01%
сама задача: рассчет спиновых волн с учётом магнитного момента (до этого не предполагалось что магнитное взаимодействие волн имеет место быть)
спойлер:
Теория приблизилась к практике с погрешностью 0.01%
раскрыть ветку (8)
Подтверждаю. Фортран стал мощным средством для решения математических задач. У нас тяжелые матрицы при расчете теплогидравлических схем тоже на нем построены.
раскрыть ветку (7)
Я тебе больше скажу
друг занимается нейросетями
и часть работы с матрицами у него выполнены на питоне а часть на Фортране
друг занимается нейросетями
и часть работы с матрицами у него выполнены на питоне а часть на Фортране
раскрыть ветку (4)
раскрыть ветку (3)
И компилирует хорошо, и библиотек охулиард. Причём таких, в которых страшный говнокод с точки зрения проектирования и прочих код ревью, но охуенно быстрый.
раскрыть ветку (1)
Т.е. дело не только в историческом наследии мегатонн написанных и отлаженных библиотек - но и в компиляторе .. любопытно, спасибо.
Видимо, да
ну а в моем случае просто не было выбора. Или так или все с 0
уж проще ввод матрицы и условия вывода перебрать чем весь код заново
ну а в моем случае просто не было выбора. Или так или все с 0
уж проще ввод матрицы и условия вывода перебрать чем весь код заново
раскрыть ветку (1)
Ну, наши корифеи начинали в 90ых писать на фортран 66, вплоть до 2011 года ходила папка с компилятором CVF67. Сейчас медленно переползаем на купленный Intel Fortran 2015. Так понимаю, это стандарт 15.
Математика. Там такую огромную кодовую базу собрали, что переводить её на очередную новомодную заебумбу нет н сио, ни средств.
ЦЕРНовские библиотеки, вродею энтузиасты на плюсы переводили, но насколько оно там продвинулось и чем закончилось - не знаю, ушёл из отрасли.
ЦЕРНовские библиотеки, вродею энтузиасты на плюсы переводили, но насколько оно там продвинулось и чем закончилось - не знаю, ушёл из отрасли.
Последняя версия языка Fortran 2018 (ранее известная как Fortran 2015) была выпущена 28 ноября 2018 года.
Можно еще тут https://habr.com/ru/post/400523/ почитать.
раскрыть ветку (3)
Я кроме Python ничего не знаю. Это был вопрос ради вопроса, а не вопрос ради возражения (не подумал, что и так можно понять)
раскрыть ветку (1)
> Это был вопрос ради вопроса
Вопрос ради вопроса это "А можно спросить?" (:
А вы задали вопрос ради информации)
SASS. Не язык, препроцессор, но тем не менее.
+ ряд синтаксических сахаров.
раскрыть ветку (3)
раскрыть ветку (2)
Плюшки и конструкций языка, которые упрощают какие-то аспекты написания кода. Обычно введением новой фичи конструкции языка/ключевого слова, которые заменяют много старого кода, упрощая написание.
раскрыть ветку (1)
Блять, я в курсе, что такое сахар
Я спрашивал, что имел в виду предыдущий комментатор, отвечая на вопрос:
В каких языках ещё отступ может сломать программу? Любопытно.Что в "ряде сахаров" отступ может что-то сломать?
Или что SASS - это препроцессор с "рядом сахаров".
В целом звучит странно коммент
В других ЯП отступы нужны для человека, компилятору же на них плевать, хоть в одну строку пиши весь код.
раскрыть ветку (1)
IT-юмор
7.4K пост53.2K подписчика
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору