Смысл как раз в том, что новый синтаксис исправляет ошибки дизайна языка. Делает его более логичным, более строгим, более удобным. А предложенный мной путь позволяет сохранить совместимость со старым кодом (точнее, отсутствие необходимости его переписывать) и при этом писать новый код уже на новом диалекте - и всё в рамках одного проекта. Буквально, часть файлов с расширением *.cpp, часть с расширением *.cpp2, и все компилируется и работает.
Думаю, если копнуть поглубже в эволюционную психологию, то все эти искажения окажутся следствиями того, что наши мозги - это практически на 100% мозги охотников и собирателей:)
Очевидно что не любые изменения можно версионировать, а только изменения в синтаксисе (то что называется синтаксический сахар). В одной версии функция объявляется как inf foo(int), в другой как func foo(int) int, и т.д. А как раз ABI у разных версий должен быть общим.
В результате в новой версии язык станет синтаксически чище и понятнее. Можно будет легче вводить новые языковые возможности. Это - единственная цель данного предложения. Но цель важная, так как именно этот "сахар" определяет в конечном итоге удобство использования языка программистами, количество ошибок, всяких UB и т.д.
Все проблемы с нарушением обратной совмесимости прекрасно решаются. Не знаю почему никому не приходит в голову очевидное решение версионирования языка на уровне исходников, и мыши продолжают жрать кактус святой обратной совместимости, вводя все новые и новые безумные заплатки в единственную версию языка.
да, а также типа Go, Rust, Swift, Scala, Kotlin и т.д. :)
Для любителей ломать обратную совместимость есть "современные языки".
Вот здесь я предложил рабочий способ одновременно сломать и сохранить обратную совмесимость. Просто вводим новую версию языка, несовместимую со старой на уровне исходников, но при этом требуем от компиляторов поддерживать обе версии одновременно в рамках проекта - за счет этого получается гарантированная совмесимость на уровне ABI без стандартизации самого ABI. Старую версию замораживаем, все улучшения вносим только в новую, и так постепенно лет за 20 все кому нужно перейдут на новую версию.
И то и другое что-то вроде нестандартных/экстремальных режимов работы человеческой нейросети:)
И читая статью, постоянно ловил себя на мысли - как же мы, люди, все-таки уязвимы - перед старостью, перед болезнями, перед несовершенством нашей биологической природы... Гениальный математик, и в конце жизни скатился в мистицизм и нумерологию:( И ведь каждого из нас в старости может ждать нечто подобное:(
Причем интуитивно более-менее понятно почему так происходит: мозг, на пике своих возможностей находивший скрытые закономерности в сложнейших математических абстракциях, в старости пытается делать то же самое - но в силу заметно меньших ресурсов делает это в очень упрощенном виде, на базовых, заложенных на инстинктивном уровне понятиях: добре и зле, религиозны/мистических чувствах и тому подобном - том, что заложено в нас наиболее глубоко.
Я в FIDO не был никогда, компьютер появился в 1998, интернет в 2000. И думаю, мои первые впечатления от интернета примерно такие же как ваши от FIDO.
Доступ был по модему, и поначалу это было примерно 5 часов в месяц. В таких условиях субъективная ценность информации казалась очень высокой, поэтому прежде чем заходить в интернет, тщательно думал что буду скачивать, а затем изучать оффлайн. По результатам изучения составлял файлы со ссылками на то что нужно скачать при следующем заходе. Пользовался и специальными программами, которые скачивали сайты оффлайн. В основном были интересны статьи по программированию и прочему айти, это казалось самым важным и интересным. Была даже специальная бумажка, где я вел учет времени, чтобы неожиданно не оказаться без интернета:)
В общем, статья - просто ностальгия по старым добрым временам - первые впечатления, да еще и в молодости, всегда наиболее яркие.
Что же касается "неайтишников"... вот сейчас есть всякие анонимные p2p-сети. И что, много ли там айтишников и много ли там ценной информации?
Ох уж эти шаблоны:) Но я не против унифицированной инициализации всего в круглых скобках (да и вообще я всегда за универсальность во всем). А зачем добавили фигурные? (на Хабре кстати множество статей с подробным разбором инициализации, например эта). Для решения проблемы "vexing parse" и для инициализации контейнеров. Первое - это проблема кривого синтаксиса функций (функция должна начинаться с ключевого слова, как во всех современных языках, а не с возвращаемого типа). Второе решается введением концепции "кортежей". Но вместо прямого решения проблемы )пусть и ломающего обратную совместимость) решили поставить заплатку на заплатке и породили еще один синтаксис инициализации.
Конечно в С++ с инициализацией наворотили лишнего. Зачем было вводить "универсальную инициализацию," если проблема была в другом - в том что нужно было ввести новый синтаксис функций (и его все равно ведь ввели - с auto и стрелочкой). И вообще добавление новых фич в С++ становится все более фрагментарным и бессистемным.
В целом я согласен - круглые скобки это конструктор (выполнение кода), фигурные с присваиванием - поэлементное присваивание публичных полей (т.е. даже и не инициализация как таковая, а просто присваивание нескольких полей одним оператором). Фигурные скобки без оператора присваивания вообще не стоило вводить. А вот что стоило, так это ввести универсальную концепцию кортежей - как раз тех самых составных литералов в фигурных скобках - как структурно типизированных объектов. Тогда бы можно было писать что-то вроде {i, j, k} = {1,2,3}, не потребовался бы отдельный синтаксис "структурных привязок" и т.д.
Отличный пример того, как инструмент применяется не совсем по назначению (ровно то же самое с математикой).
С одной стороны это гениально - GPT обучена на огромном количестве кода, и она может эвристически предположить смысл того или иного фрагмента кода, и соответственно восстановить осмысленные имена идентификаторов, комментарии и т.п.
С другой стороны, самим переименованием должна заниматься не нейросеть, а строгая символьная система (в данном случае парсер). Потому что GPT by design имеет право на ошибку, а парсер - не имеет. А малейшая ошибка способна исказить работу всего кода.
Знаете, что мне это напоминает: в средние века были алхимики, и они тоже думали что есть связи между некоторыми малоизученными на тот момент сущностями. Типа такого: Тихо Браге выражал уверенность в «связях между небесными телами, земными веществами и органами тела». Отголоски тех времен остались до сих пор во всякой астрологии и эзотерике:) С квантовой физикой и сознанием ИМХО творится та же фигня: две сложные для понимания сущности, и человеческая нейросеть сразу выдает - ну наверняка же они связаны! Видимо это какое-то общее когнитивное искажение.
Так смысл именно в том чтобы системное оформление было, без него то всё нормально работает. Мне категорически неудобен этот современный стиль окон без заголовка, когда на перетаскивание окна отведена пара пикселей, в которые еще нужно умудриться попасть, а остальное занято табами. Я еще понимаю если бы место экономили в конце 90-х, когда были маленькие разрешения... но сейчас, с огромными мониторами, зачем???
Сейчас поставил версию 6.9 на совершенно чистую виртуалку с Lubuntu 24.04 LTS, установил галку use Native Window, перезапустил браузер - та же проблема. Причем и само окно настроек также ей подвержено. Похоже, заголовок окна как-то пытается реагировать на первое нажатие, но дальше отваливается окончательно. Также пробовал ставить и снимать Show Title Bar - ни на что не влияет. Возможно это сочетание Vivaldi + LXQT дает такой эффект.
Добрый день! А вы вот с этой проблемой что нибудь сделали? Хотя-бы напишите смогли вы ее воспроизвести или нет, а то ведь совсем непонятно чего ожидать.
Потому что ключевое слово func стоит в начале всей конструкции. Значит, все что дальше - функция. Также как struct - структура, enum - перечисление, и т.д. Первое слово всегда определяет языковую конструкцию.
И кстати, еще одно преимущество синтаксиса Go - в том, что в нем лямбда-функции объявляются в точности также как и "обычные". Т.е. вообще никакой разницы, только имя не указывается. В остальных же языках - зоопарк кто во что горазд. Какие-то вертикальные палки и прочий ужас.
[](int x, int y) { return x+y; }; // C++
^int (int x, int y) { return a + b; }; // ObjC
(x, y) => x + y // C#
(int x, int y) -> x + y // Java
delegate int(int x, int y) {return x+y;} // D
let add = |a, b| a + b; // Rust
{ (a: Int, b: Int) -> Int in return a + b } // Swift
(a: Int, b: Int) => a + b // Scala
_ + _ // и это тоже Scala
{ x: Int, y: Int -> x + y } // Kotlin
lambda x, y: x + y // Python
lambda { |x, y| x + y } // Ruby
(x, y: int) => x + y // Nim
|x: i32, y: i32| i32 { return x + y; }; // Zig
И вообще в ASCII операторных символов мало (а в языках программирования используется именно ASCII потому что эти символы гарантированно есть на всех клавиатурах мира). Т.е. операторы лучше по возможности оставить для инфиксных выражений, унаследованных от математики.
Ключевое слово fn это рак мозга и паскальная живопись.
Нет, ключевое слово fn (а также fun, func, function) это необходимость для упрощения компилятора, чтобы не было всяких Most Vexing Parse (а короткие ключевые слова действиительно удобнее для написания). А вот что действительно рак мозга и паскальная живопись - так это мусорные стрелочки и двоеточия при объявлении функций и переменных, которые выполняют чисто декоративную роль и визуально засоряют код.
Смысл как раз в том, что новый синтаксис исправляет ошибки дизайна языка. Делает его более логичным, более строгим, более удобным. А предложенный мной путь позволяет сохранить совместимость со старым кодом (точнее, отсутствие необходимости его переписывать) и при этом писать новый код уже на новом диалекте - и всё в рамках одного проекта. Буквально, часть файлов с расширением *.cpp, часть с расширением *.cpp2, и все компилируется и работает.
Думаю, если копнуть поглубже в эволюционную психологию, то все эти искажения окажутся следствиями того, что наши мозги - это практически на 100% мозги охотников и собирателей:)
Очевидно что не любые изменения можно версионировать, а только изменения в синтаксисе (то что называется синтаксический сахар). В одной версии функция объявляется как inf foo(int), в другой как func foo(int) int, и т.д. А как раз ABI у разных версий должен быть общим.
В результате в новой версии язык станет синтаксически чище и понятнее. Можно будет легче вводить новые языковые возможности. Это - единственная цель данного предложения. Но цель важная, так как именно этот "сахар" определяет в конечном итоге удобство использования языка программистами, количество ошибок, всяких UB и т.д.
Все проблемы с нарушением обратной совмесимости прекрасно решаются. Не знаю почему никому не приходит в голову очевидное решение версионирования языка на уровне исходников, и мыши продолжают жрать кактус святой обратной совместимости, вводя все новые и новые безумные заплатки в единственную версию языка.
да, а также типа Go, Rust, Swift, Scala, Kotlin и т.д. :)
Вот здесь я предложил рабочий способ одновременно сломать и сохранить обратную совмесимость. Просто вводим новую версию языка, несовместимую со старой на уровне исходников, но при этом требуем от компиляторов поддерживать обе версии одновременно в рамках проекта - за счет этого получается гарантированная совмесимость на уровне ABI без стандартизации самого ABI. Старую версию замораживаем, все улучшения вносим только в новую, и так постепенно лет за 20 все кому нужно перейдут на новую версию.
Радуется наступлению православного национал-коммунистического самодержавия?
И то и другое что-то вроде нестандартных/экстремальных режимов работы человеческой нейросети:)
И читая статью, постоянно ловил себя на мысли - как же мы, люди, все-таки уязвимы - перед старостью, перед болезнями, перед несовершенством нашей биологической природы... Гениальный математик, и в конце жизни скатился в мистицизм и нумерологию:( И ведь каждого из нас в старости может ждать нечто подобное:(
Причем интуитивно более-менее понятно почему так происходит: мозг, на пике своих возможностей находивший скрытые закономерности в сложнейших математических абстракциях, в старости пытается делать то же самое - но в силу заметно меньших ресурсов делает это в очень упрощенном виде, на базовых, заложенных на инстинктивном уровне понятиях: добре и зле, религиозны/мистических чувствах и тому подобном - том, что заложено в нас наиболее глубоко.
Я в FIDO не был никогда, компьютер появился в 1998, интернет в 2000. И думаю, мои первые впечатления от интернета примерно такие же как ваши от FIDO.
Доступ был по модему, и поначалу это было примерно 5 часов в месяц. В таких условиях субъективная ценность информации казалась очень высокой, поэтому прежде чем заходить в интернет, тщательно думал что буду скачивать, а затем изучать оффлайн. По результатам изучения составлял файлы со ссылками на то что нужно скачать при следующем заходе. Пользовался и специальными программами, которые скачивали сайты оффлайн. В основном были интересны статьи по программированию и прочему айти, это казалось самым важным и интересным. Была даже специальная бумажка, где я вел учет времени, чтобы неожиданно не оказаться без интернета:)
В общем, статья - просто ностальгия по старым добрым временам - первые впечатления, да еще и в молодости, всегда наиболее яркие.
Что же касается "неайтишников"... вот сейчас есть всякие анонимные p2p-сети. И что, много ли там айтишников и много ли там ценной информации?
Ох уж эти шаблоны:) Но я не против унифицированной инициализации всего в круглых скобках (да и вообще я всегда за универсальность во всем). А зачем добавили фигурные? (на Хабре кстати множество статей с подробным разбором инициализации, например эта). Для решения проблемы "vexing parse" и для инициализации контейнеров. Первое - это проблема кривого синтаксиса функций (функция должна начинаться с ключевого слова, как во всех современных языках, а не с возвращаемого типа). Второе решается введением концепции "кортежей". Но вместо прямого решения проблемы )пусть и ломающего обратную совместимость) решили поставить заплатку на заплатке и породили еще один синтаксис инициализации.
Конечно в С++ с инициализацией наворотили лишнего. Зачем было вводить "универсальную инициализацию," если проблема была в другом - в том что нужно было ввести новый синтаксис функций (и его все равно ведь ввели - с auto и стрелочкой). И вообще добавление новых фич в С++ становится все более фрагментарным и бессистемным.
В целом я согласен - круглые скобки это конструктор (выполнение кода), фигурные с присваиванием - поэлементное присваивание публичных полей (т.е. даже и не инициализация как таковая, а просто присваивание нескольких полей одним оператором). Фигурные скобки без оператора присваивания вообще не стоило вводить. А вот что стоило, так это ввести универсальную концепцию кортежей - как раз тех самых составных литералов в фигурных скобках - как структурно типизированных объектов. Тогда бы можно было писать что-то вроде {i, j, k} = {1,2,3}, не потребовался бы отдельный синтаксис "структурных привязок" и т.д.
А что за язык программирования для которого нет парсера?
Отличный пример того, как инструмент применяется не совсем по назначению (ровно то же самое с математикой).
С одной стороны это гениально - GPT обучена на огромном количестве кода, и она может эвристически предположить смысл того или иного фрагмента кода, и соответственно восстановить осмысленные имена идентификаторов, комментарии и т.п.
С другой стороны, самим переименованием должна заниматься не нейросеть, а строгая символьная система (в данном случае парсер). Потому что GPT by design имеет право на ошибку, а парсер - не имеет. А малейшая ошибка способна исказить работу всего кода.
Знаете, что мне это напоминает: в средние века были алхимики, и они тоже думали что есть связи между некоторыми малоизученными на тот момент сущностями. Типа такого: Тихо Браге выражал уверенность в «связях между небесными телами, земными веществами и органами тела». Отголоски тех времен остались до сих пор во всякой астрологии и эзотерике:) С квантовой физикой и сознанием ИМХО творится та же фигня: две сложные для понимания сущности, и человеческая нейросеть сразу выдает - ну наверняка же они связаны! Видимо это какое-то общее когнитивное искажение.
Электроннотетрадь
Так смысл именно в том чтобы системное оформление было, без него то всё нормально работает. Мне категорически неудобен этот современный стиль окон без заголовка, когда на перетаскивание окна отведена пара пикселей, в которые еще нужно умудриться попасть, а остальное занято табами. Я еще понимаю если бы место экономили в конце 90-х, когда были маленькие разрешения... но сейчас, с огромными мониторами, зачем???
Сейчас поставил версию 6.9 на совершенно чистую виртуалку с Lubuntu 24.04 LTS, установил галку use Native Window, перезапустил браузер - та же проблема. Причем и само окно настроек также ей подвержено. Похоже, заголовок окна как-то пытается реагировать на первое нажатие, но дальше отваливается окончательно. Также пробовал ставить и снимать Show Title Bar - ни на что не влияет. Возможно это сочетание Vivaldi + LXQT дает такой эффект.
Добрый день! А вы вот с этой проблемой что нибудь сделали? Хотя-бы напишите смогли вы ее воспроизвести или нет, а то ведь совсем непонятно чего ожидать.
Потому что ключевое слово func стоит в начале всей конструкции. Значит, все что дальше - функция. Также как struct - структура, enum - перечисление, и т.д. Первое слово всегда определяет языковую конструкцию.
И кстати, еще одно преимущество синтаксиса Go - в том, что в нем лямбда-функции объявляются в точности также как и "обычные". Т.е. вообще никакой разницы, только имя не указывается. В остальных же языках - зоопарк кто во что горазд. Какие-то вертикальные палки и прочий ужас.
И вообще в ASCII операторных символов мало (а в языках программирования используется именно ASCII потому что эти символы гарантированно есть на всех клавиатурах мира). Т.е. операторы лучше по возможности оставить для инфиксных выражений, унаследованных от математики.
Нет, ключевое слово fn (а также fun, func, function) это необходимость для упрощения компилятора, чтобы не было всяких Most Vexing Parse (а короткие ключевые слова действиительно удобнее для написания). А вот что действительно рак мозга и паскальная живопись - так это мусорные стрелочки и двоеточия при объявлении функций и переменных, которые выполняют чисто декоративную роль и визуально засоряют код.
В языке Go нет никаких стрелочек и двоеточий, и никаких проблем их отсутствие не создает.
Сбоку на плате есть 4 контактных отверстия. Вполне может быть или UART или SWD, но без осциллографа не посмотреть:)
Скрытый текст