Здравствуйте, so5team, Вы писали:
DM>>>>Одна из фундаментальных проблем — нет фокуса, нет ниши. Язык настолько широкого профиля, general purpose
Р>>>Альтернатива не лучше http://deadalusai.github.io/rust-for-csharp-developers/#1 Р>>>
A>>Как-то упячно излагать основы ЯП для нативного кода программистам на ЯП для виртуальной машины, ИМХО. Я к тому, что лучше бы было Rust for C/C++ developers.
S>Дык Rust Book же ж.
Сравнивать книгу и презентацию с примерами ещё упячнее.
Но ладно. Я посмотрел мельком, потом (может быть) почитаю не спеша. Пока впечатление не очень хорошее.
The function body is wrapped in {}. Rust requires curly brackets around all function bodies. It’s good style to place the opening curly bracket on the same line as the function declaration, adding one space in between.
Почему книга в статусе официальной (как-никак, rust-lang.org/book/) содержит авторские предпочтения по оформлению? Кто-нибудь может себе представить — приходишь ты в MSDN, в раздел по C++ (скажем, почитать про какой-нибудь printf), а там: "Используйте два пробела. Не три, не четыре — ровно два!". Жесть, конечно. Надо уметь найти у себя фонтан и заткнуть его, когда ты официальный голос языка.
Re[6]: Почему dlang не обрел большой популярности?
Здравствуйте, Alekzander, Вы писали:
Р>>>>Альтернатива не лучше http://deadalusai.github.io/rust-for-csharp-developers/#1 Р>>>>
A>>>Как-то упячно излагать основы ЯП для нативного кода программистам на ЯП для виртуальной машины, ИМХО. Я к тому, что лучше бы было Rust for C/C++ developers.
S>>Дык Rust Book же ж.
A>Сравнивать книгу и презентацию с примерами ещё упячнее.
ИМХО, C/C++ программистам не нужно делать презентации из категории "вы привыкли делать вот так, а здесь делают вот так", просто в силу того, что программируя на Си или C++ приходится понимать что происходит. А для понимания лучше штудировать нормальные материалы, вроде Rust Book.
A>Почему книга в статусе официальной (как-никак, rust-lang.org/book/) содержит авторские предпочтения по оформлению?
Насколько я могу судить, в современных языках нормальным считается фиксировать code convention на официальном уровне. Это в 1980-х считалось обычным делом, когда кто-то фигачит в snake_case с табами, а коллега по цеху в PascalCase с пробелами. Но уже в 1990-х стиль написания кода на конкретном языке прибивают гвоздями, а несоблюдающих побивают батогами и придают анафеме.
Ну или я не понял суть вашей претензии и вы нашли несоответствие стиля кода в Ruby Book официальному code convention для Rust?
Re[7]: Почему dlang не обрел большой популярности?
Здравствуйте, so5team, Вы писали:
Р>>>>>Альтернатива не лучше http://deadalusai.github.io/rust-for-csharp-developers/#1 Р>>>>>
A>>>>Как-то упячно излагать основы ЯП для нативного кода программистам на ЯП для виртуальной машины, ИМХО. Я к тому, что лучше бы было Rust for C/C++ developers.
S>>>Дык Rust Book же ж.
A>>Сравнивать книгу и презентацию с примерами ещё упячнее.
S>ИМХО, C/C++ программистам не нужно делать презентации из категории "вы привыкли делать вот так, а здесь делают вот так", просто в силу того, что программируя на Си или C++ приходится понимать что происходит. А для понимания лучше штудировать нормальные материалы, вроде Rust Book.
A variable or value can be borrowed for a period of time.
fn subroutine(data: &Foo) {
//...
}
fn main() {
let foo = Foo;
subroutine(&foo);
subroutine(&foo); // Ok! Ownership was not consumed
}
The ampersand (&) sigil indicates a "reference". We can loan out references to data we own as many times as we like.
Естественно, возникает вопрос, это мы берём адрес, или что? Или, вернее, как сочетаются все эти borrowing'и-ownership'ы с указателями и адресной арифметикой*. А раз чит-шит этот для программистов C#, то ответа, разумеется, не будет, т.к. в их системе понятий взятия адреса нет. Или, может, есть (я плохо разбираюсь в unsafe'ах и pinning'ах), но сильно неявно.
Вопрос под звёздочкой* меня интересует отдельно, вне связи с этим документом. Мне кажется, попытка переложить контроль с виртуальной машины на компилятор всегда попахивает каким-то мошенничеством. Но я ничего не утверждаю, т.к. the book пока ещё не прочёл.
A>>Почему книга в статусе официальной (как-никак, rust-lang.org/book/) содержит авторские предпочтения по оформлению?
S>Насколько я могу судить, в современных языках нормальным считается фиксировать code convention на официальном уровне. Это в 1980-х считалось обычным делом, когда кто-то фигачит в snake_case с табами, а коллега по цеху в PascalCase с пробелами. Но уже в 1990-х стиль написания кода на конкретном языке прибивают гвоздями, а несоблюдающих побивают батогами и придают анафеме.
Я могу обосновать, что это неправильно.
Во-первых, и это самое очевидное, "на официальном уровне" принято регулировать языки в виде стандартов. Или мы считает, что отступы это важно, вносим правило в стандарт, и тогда пусть дальнейшим занимается компилятор. Или НЕ считаем, и тогда какие могут рекомендации? Всё равно, что на водке писать, чем её правильно закусывать — только холивар на ровном месте разводить.
Во-вторых, code convention привязан не к языкам, а к прикладным вещам: библиотекам, API и т.д., вплоть до конкретного работодателя. Я на одном и том же C++ буду совершенно по-разному писать разные вещи.
Ну и, в-третьих, это неправда. Microsoft специально пишет официальный инструмент для работы со своим же собственным C#. И там у них бооооольшая простыня настроек, где делать перенос перед curly braces, а где — нет:
А ещё есть .editorconfig для оверрайда по месту. Так что, как минимум, один мощный контрпример (Microsoft, всё-таки) наблюдается даже в наши скорбные двадцатые.
S>Ну или я не понял суть вашей претензии и вы нашли несоответствие стиля кода в Ruby Book официальному code convention для Rust?
Re[4]: Почему dlang не обрел большой популярности?
Здравствуйте, Alekzander, Вы писали:
A>Здравствуйте, Разраб, Вы писали:
DM>>>Одна из фундаментальных проблем — нет фокуса, нет ниши. Язык настолько широкого профиля, general purpose
Р>>Альтернатива не лучше http://deadalusai.github.io/rust-for-csharp-developers/#1 Р>>
A>Как-то упячно излагать основы ЯП для нативного кода программистам на ЯП для виртуальной машины, ИМХО. Я к тому, что лучше бы было Rust for C/C++ developers.
Здравствуйте, Alekzander, Вы писали:
A>Естественно, возникает вопрос, это мы берём адрес, или что? Или, вернее, как сочетаются все эти borrowing'и-ownership'ы с указателями и адресной арифметикой*. А раз чит-шит этот для программистов C#, то ответа, разумеется, не будет, т.к. в их системе понятий взятия адреса нет. Или, может, есть (я плохо разбираюсь в unsafe'ах и pinning'ах), но сильно неявно.
A>Вопрос под звёздочкой* меня интересует отдельно, вне связи с этим документом. Мне кажется, попытка переложить контроль с виртуальной машины на компилятор всегда попахивает каким-то мошенничеством. Но я ничего не утверждаю, т.к. the book пока ещё не прочёл.
Не думаю, что в теме про причины непопулярности D имеет смысл углубляться в механизм ownership-а из Rust.
A>Я могу обосновать, что это неправильно.
Вы это обоснуйте тем, кто создает go fmt, rustfmt или навязывает применение clang-formatter-а. Думаю, они с удовольствием выскажут вам все, что думают по этому поводу. И, полагаю, будут правы.
A>Во-первых, и это самое очевидное, "на официальном уровне" принято регулировать языки в виде стандартов. Или мы считает, что отступы это важно, вносим правило в стандарт, и тогда пусть дальнейшим занимается компилятор.
В том же Go, AFAIK, на это уже пошли: экспортируемость имен из модуля зависит от того, с заглавной или со строчной буквы начинается это самое имя.
A>Во-вторых, code convention привязан не к языкам, а к прикладным вещам: библиотекам, API и т.д., вплоть до конкретного работодателя. Я на одном и том же C++ буду совершенно по-разному писать разные вещи.
Могу ошибаться, но только в Си и C++ такой маразм и существует. В "более нормальных" (с) языках люди пишут все в одном стиле и не парятся. А вот в C++, местами, маразм просто зашкаливает: выкладываешь что-то в OpenSource, прибегают люди с криками "как ужасно все у вас, просто невозможно пользоваться, глаза вытекли!" Начинаешь выяснять что к чему и почему, а оказывается, что они привыкли к PascalCase, а когда видят код в snake_case, с ними истерика приключается.
Re[9]: Почему dlang не обрел большой популярности?
Здравствуйте, so5team, Вы писали:
A>>Естественно, возникает вопрос, это мы берём адрес, или что? Или, вернее, как сочетаются все эти borrowing'и-ownership'ы с указателями и адресной арифметикой*. А раз чит-шит этот для программистов C#, то ответа, разумеется, не будет, т.к. в их системе понятий взятия адреса нет. Или, может, есть (я плохо разбираюсь в unsafe'ах и pinning'ах), но сильно неявно.
A>>Вопрос под звёздочкой* меня интересует отдельно, вне связи с этим документом. Мне кажется, попытка переложить контроль с виртуальной машины на компилятор всегда попахивает каким-то мошенничеством. Но я ничего не утверждаю, т.к. the book пока ещё не прочёл.
S>Не думаю, что в теме про причины непопулярности D имеет смысл углубляться в механизм ownership-а из Rust.
Ой, тут во что только не углубляются. Механизм ownership-а из Rust ещё не самое худшее, во что можно углубиться.
A>>Я могу обосновать, что это неправильно.
S>Вы это обоснуйте тем, кто создает go fmt, rustfmt или навязывает применение clang-formatter-а. Думаю, они с удовольствием выскажут вам все, что думают по этому поводу. И, полагаю, будут правы.
Может, мне ещё в армию поехать и обосновывать сержантам, что гражданские отнюдь не дураки, когда не в ногу ходят?
A>>Во-первых, и это самое очевидное, "на официальном уровне" принято регулировать языки в виде стандартов. Или мы считает, что отступы это важно, вносим правило в стандарт, и тогда пусть дальнейшим занимается компилятор.
S>В том же Go, AFAIK, на это уже пошли: экспортируемость имен из модуля зависит от того, с заглавной или со строчной буквы начинается это самое имя.
Зачем далеко ходить за примерами? https://en.wikipedia.org/wiki/Off-side_rule
A>>Во-вторых, code convention привязан не к языкам, а к прикладным вещам: библиотекам, API и т.д., вплоть до конкретного работодателя. Я на одном и том же C++ буду совершенно по-разному писать разные вещи.
S>Могу ошибаться, но только в Си и C++ такой маразм и существует. В "более нормальных" (с) языках люди пишут все в одном стиле и не парятся. А вот в C++, местами, маразм просто зашкаливает: выкладываешь что-то в OpenSource, прибегают люди с криками "как ужасно все у вас, просто невозможно пользоваться, глаза вытекли!" Начинаешь выяснять что к чему и почему, а оказывается, что они привыкли к PascalCase, а когда видят код в snake_case, с ними истерика приключается.
Мой пример с C# ты, конечно, проигнорировал. Хотя я даже не поленился картинку залить.
Ну да ладно. Уберём слово "только", а вот не хочешь подумать, ПОЧЕМУ в Си и C++ существует то, что ты называешь маразмом? А в силу популярности, вот почему. На них чего только не пишут. Некоторые (не будем показывать пальцем) даже бизнес-логику веб-приложений, прости их Господь. Понятно, что хедеры WinAPI, COM'а, буста и sqlite'а выглядят немного по-разному. Причём первые два — реально межъязыковые. Как ни крути, будет тебе разнобой. И на каком языке не пиши, будет разнобой, если только авторы байндингов не приведут в соответствие, ценой поломки документации и прочих интеграций. Если только ЯП достаточно популярен, чтобы пилить эти байндинги
Здравствуйте, Разраб, Вы писали:
DM>>>>Одна из фундаментальных проблем — нет фокуса, нет ниши. Язык настолько широкого профиля, general purpose
Р>>>Альтернатива не лучше http://deadalusai.github.io/rust-for-csharp-developers/#1 Р>>>
A>>Как-то упячно излагать основы ЯП для нативного кода программистам на ЯП для виртуальной машины, ИМХО. Я к тому, что лучше бы было Rust for C/C++ developers.
Р>Не вижу разницы. Разве нельзя скилы форсить? Р>А впрочем вот, только что чел все порешал https://0x8d.blogspot.com/2023/04/argentum-programming-language-argentum.html
Я ничего не понял.
Re[10]: Почему dlang не обрел большой популярности?
Здравствуйте, Alekzander, Вы писали:
A>Ой, тут во что только не углубляются. Механизм ownership-а из Rust ещё не самое худшее, во что можно углубиться.
Тем не менее, это офтопик в теме про D. Да, можно было бы занырнуть и туда, но кроличья нора там ну очень уж глубокая.
A>>>Я могу обосновать, что это неправильно.
S>>Вы это обоснуйте тем, кто создает go fmt, rustfmt или навязывает применение clang-formatter-а. Думаю, они с удовольствием выскажут вам все, что думают по этому поводу. И, полагаю, будут правы.
A>Может, мне ещё в армию поехать и обосновывать сержантам, что гражданские отнюдь не дураки, когда не в ногу ходят?
Дело ваше. Я говорю лишь то, что вижу. Начиная с Java акцент делается на то, чтобы код, написанный разными людьми, выглядел одинаково.
И вопрос не в том, что лично я думаю по этому поводу, а в то, что это уже мейнстрим больше 20 лет как.
И если раньше (те же Java, C#, Python, Ruby) в основном излагали общие рекомендации по стилю именования (типа PascalCase для имен классов, camelCase для имен методов, как в Java), а стиль скобочек и виды пробелов оставляли на откуп конкретных команд и проектов, то сейчас дело зашло еще дальше.
Программирование давно стало массовым, к массовому производству другие требования, что логично.
A>>>Во-вторых, code convention привязан не к языкам, а к прикладным вещам: библиотекам, API и т.д., вплоть до конкретного работодателя. Я на одном и том же C++ буду совершенно по-разному писать разные вещи.
S>>Могу ошибаться, но только в Си и C++ такой маразм и существует. В "более нормальных" (с) языках люди пишут все в одном стиле и не парятся. А вот в C++, местами, маразм просто зашкаливает: выкладываешь что-то в OpenSource, прибегают люди с криками "как ужасно все у вас, просто невозможно пользоваться, глаза вытекли!" Начинаешь выяснять что к чему и почему, а оказывается, что они привыкли к PascalCase, а когда видят код в snake_case, с ними истерика приключается.
A>Мой пример с C# ты, конечно, проигнорировал. Хотя я даже не поленился картинку залить.
Ваш пример демонстрирует массовое применение snake_case в C#? Есть ли вообще сколько нибудь заметные проекты на C# (начиная хотя бы с сотни звезд на GitHub), где наплевали бы на рекомендации по именованию сущностей и херачили бы все в snake_case?
То, что Microsoft еще не зажимает гайки по поводу пробелов и места расположения скобочек, это (возможно пока что) следствие того, что C# родом из 90-х, когда на эту тему еще не заморачивались.
A>Ну да ладно. Уберём слово "только", а вот не хочешь подумать, ПОЧЕМУ в Си и C++ существует то, что ты называешь маразмом? А в силу популярности, вот почему.
Нет. В силу того, что эти языки массово начали использовать еще до того, как до программистов ан-масс дошло, что стиль кода должен быть одинаковым вне зависимости от проекта. А это где-то начало-середина 1990-х.
Re[11]: Почему dlang не обрел большой популярности?
Здравствуйте, so5team, Вы писали:
S>Дело ваше. Я говорю лишь то, что вижу. Начиная с Java акцент делается на то, чтобы код, написанный разными людьми, выглядел одинаково. S>И вопрос не в том, что лично я думаю по этому поводу, а в то, что это уже мейнстрим больше 20 лет как.
Если бы это было так, то во всех конторах, где я работал больше 20 лет как, не было бы своих гайдлайнов (всюду разных). Даже тут, на RSDN, мне помнится, публиковали местные гайдлайны для дотнета. В майкрософтовских, вишь, нашли фатальный недостаток.
S>И если раньше (те же Java, C#, Python, Ruby) в основном излагали общие рекомендации по стилю именования (типа PascalCase для имен классов, camelCase для имен методов, как в Java), а стиль скобочек и виды пробелов оставляли на откуп конкретных команд и проектов, то сейчас дело зашло еще дальше.
S>Ваш пример демонстрирует массовое применение snake_case в C#?
Мой пример относится к моей цитате. Надеюсь, ты не забыл, с чего начался разговор?
The function body is wrapped in {}. Rust requires curly brackets around all function bodies. It’s good style to place the opening curly bracket on the same line as the function declaration, adding one space in between.
S>Нет. В силу того, что эти языки массово начали использовать еще до того, как до программистов ан-масс дошло, что стиль кода должен быть одинаковым вне зависимости от проекта.
И только один — мой, он же — правильный. И зелёной красочкой сверху всё покрасить.
Я понял твою точку зрения (причём, изначально). Но очень нескромно выдавать её за исторический факт.
Здравствуйте, Alekzander, Вы писали:
S>>Дело ваше. Я говорю лишь то, что вижу. Начиная с Java акцент делается на то, чтобы код, написанный разными людьми, выглядел одинаково. S>>И вопрос не в том, что лично я думаю по этому поводу, а в то, что это уже мейнстрим больше 20 лет как.
A>Если бы это было так, то во всех конторах, где я работал больше 20 лет как, не было бы своих гайдлайнов (всюду разных). Даже тут, на RSDN, мне помнится, публиковали местные гайдлайны для дотнета. В майкрософтовских, вишь, нашли фатальный недостаток.
Давайте так: покажите мне гайдлайны для дотнета, в которых наплевали бы на стиль именования сущностей, используемый самим Microsoft-ом. Т.е. не PascalCase, а хотя бы camelCase, не говоря уже про snake_case.
Если вся разница только в виде пробелов и в способах расставления скобочек, то, по большому счету, это всего лишь перестановка кроватей в борделе.
S>>И если раньше (те же Java, C#, Python, Ruby) в основном излагали общие рекомендации по стилю именования (типа PascalCase для имен классов, camelCase для имен методов, как в Java), а стиль скобочек и виды пробелов оставляли на откуп конкретных команд и проектов, то сейчас дело зашло еще дальше.
S>>Ваш пример демонстрирует массовое применение snake_case в C#?
A>Мой пример относится к моей цитате. Надеюсь, ты не забыл, с чего начался разговор?
A>
A>The function body is wrapped in {}. Rust requires curly brackets around all function bodies. It’s good style to place the opening curly bracket on the same line as the function declaration, adding one space in between.
Я не забыл, но вы, видимо, не в состоянии прочитать и осознать вот это:
И если раньше (те же Java, C#, Python, Ruby) в основном излагали общие рекомендации по стилю именования (типа PascalCase для имен классов, camelCase для имен методов, как в Java), а стиль скобочек и виды пробелов оставляли на откуп конкретных команд и проектов, то сейчас дело зашло еще дальше.
Из того, что я вижу, развитие происходит так:
— всем начхать на то, каким стилем пользуются (1970-е и 1980-е, до этого особой свободы и не было в силу особенностей тогдашних ЯП);
— а хорошо бы писать как-то более-менее одинаково, поэтому давайте определим правила именования сущностей (это начало-середина 1990-х);
— а хорошо бы писать еще более одинаково, поэтому давайте зафиксируем все еще жестче, да еще и инструменты для переформатирования кода сделаем штатными для языка (это где-то 2010-е годы).
Индустрия движется так и, имхо, это объективно. Хотите поссать против ветра пойти поперек объективной реальности? Да сколько угодно. Повторюсь: дело ваше.
Re[12]: Почему dlang не обрел большой популярности?
Здравствуйте, Alekzander, Вы писали:
A>It’s good style to place the opening curly bracket on the same line as the function declaration
BTW, Вбыв бы за такой стиль. Нечитаемо жеж совершенно!
Здравствуйте, CreatorCray, Вы писали:
A>>It’s good style to place the opening curly bracket on the same line as the function declaration CC>BTW, Вбыв бы за такой стиль. Нечитаемо жеж соверщенно!
Аминь, брат. Когда вижу — хочется монитор повернуть на 45°.
Здравствуйте, Разраб, Вы писали:
Р>Т.е. ди проектировался не а бы как а именно под современное железо. Р>Да и на взгляд дилетанта язык очень прост синтаксически, порой почти питон.
В этой области популярны C++, Java, C#.
Исключительно потому что появились вовремя, их знают все, на этих языках много легаси, нишу кое-как но закрывают.
C++ вообще даже за 12 лет комитету до конца не удалось убить.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, SkyDance, Вы писали:
SD>Потому что это "независимый язык". Нет ни одной мега-корпорации, которая была бы стояла за этим языком (была invested in it).
Использование мега-корпорациями это скорее следствие популярности, а не причина.
Например
1 Полно языков, которые сдохли будучи выпущены мега-корпорациями, их не перечесть
2 И так же полно языков, которые не были выпущены мега-корпорациями, но постепенно обросли ими, см Python, JavaScript, Bash
Здравствуйте, Разраб, Вы писали:
Р>Насколько я знаю, Уолт Брайт и Александреску высококлассные специалисты. Р>Т.е. ди проектировался не а бы как а именно под современное железо. Р>Да и на взгляд дилетанта язык очень прост синтаксически, порой почти питон.
Для меня вообще это тоже загадка. О D я услышал вначале первой половине нулевых, у людей было много энтузиазма, говорили, что за D будущее. Потом все как-то затихло, и о языке снова заговорили, в начале 10-х когда туда пришел Александреску. Он вроде даже книгу написал. Но потом все как-то снова затихло.
ИМХО просто неповезло, звезды не сошлись, этот язык появился не в то время, и главное слишком долго его до ума доводили. Сначала его затмили Java и С#, а потом, когда он снова вылез благодаря Александреску, его уже затмили Go и Rust. В итоге оба раза язык оказался неудел, и никто не стал серьезно в него вкладываться. Мне кажется, если язык за 20 лет так и не взлетел, то он уже не взлетит.
Re[13]: Почему dlang не обрел большой популярности?
CC>BTW, Вбыв бы за такой стиль. Нечитаемо жеж соверщенно!
Наоборот. Нечитаемо, когда у тебя из 40 помещающихся на экран строчек 20 заняты одинокими, но гордыми curly brackets.
Особливо в сочетании с упоротыми "не более 80 символов на строку" и "каждый аргумент вызова функции — в своей строке". Получается жесткач, когда вызов функции WinAPI занимает весь экран (11 параметров, а также if () для проверки кода возврата, плюс сплошные {} — по одной на строчечку).
Re[3]: Почему dlang не обрел большой популярности?
P>Использование мега-корпорациями это скорее следствие популярности, а не причина.
Я не про это писал. А про то, что для "успеха" язык должен получать огромные инвестиции от мега-корпов.
Нет, не для развития языкак как такового (здесь хватит и сравнительно небольшой команды). А для того, чтобы желающие получить работу люди эти языки изучали. Популярность идет от шума "а вот гугл использует ХХХ". И от "эффекта миллиона мух" — ну не может же гугл ошибаться, да?
Re[14]: Почему dlang не обрел большой популярности?
Здравствуйте, SkyDance, Вы писали:
CC>>BTW, Вбыв бы за такой стиль. Нечитаемо жеж соверщенно!
SD>Наоборот. Нечитаемо, когда у тебя из 40 помещающихся на экран строчек 20 заняты одинокими, но гордыми curly brackets. SD>Особливо в сочетании с упоротыми "не более 80 символов на строку" и "каждый аргумент вызова функции — в своей строке". Получается жесткач, когда вызов функции WinAPI занимает весь экран (11 параметров, а также if () для проверки кода возврата, плюс сплошные {} — по одной на строчечку).
Читаемо это как раз отлично. Плотность кода конечно низкая, зато каждая строчка прозрачна. Но надо учится колёсиком на мышке пользоваться.
У меня был одногрупник, он в математике шарил, все хотели посмотреть на его дабы по вычмату. Он охотно делился. Только там ничего не понять было. Переменные — исключительно i,j,k,l,m,n — зачем на них буквы тратить? Пробелы — это какая-то хрень, непонятно, зачем придуманная. Переносы строки тоже непонятно для кого придумано. Наверное, чтобы когда строчки в экран перестают влезать, то чтобы их перенести можно было. Но это не точно. Отступы — только место на экране занимают. И всё в таком роде. Я так понимаю, это твой идеал
Re[4]: Почему dlang не обрел большой популярности?
Здравствуйте, SkyDance, Вы писали:
SD>Я не про это писал. А про то, что для "успеха" язык должен получать огромные инвестиции от мега-корпов.
По моему, признак успеха это когда языком заинтересовались большие корпорации, и тогда инвестиции будут следствием этого интереса.
SD>Нет, не для развития языкак как такового (здесь хватит и сравнительно небольшой команды). А для того, чтобы желающие получить работу люди эти языки изучали. Популярность идет от шума "а вот гугл использует ХХХ". И от "эффекта миллиона мух" — ну не может же гугл ошибаться, да?
Не совсем понятно — каким чудом Питон, Перл, Жээс, bash набрали популярность. Никакой гугл за них не топил — вдруг выяснилось, что их используют практически везде
Re[14]: Почему dlang не обрел большой популярности?
Здравствуйте, SkyDance, Вы писали:
SD>Получается жесткач, когда вызов функции WinAPI занимает весь экран (11 параметров, а также if () для проверки кода возврата, плюс сплошные {} — по одной на строчечку).
Я понимаю, что это форум для лжи, срачей, подтасовывания аргументов, обмазывания собеседников и т.п., но трудно перешагнуть конструктивные позывы.
Чтобы решить обозначенную проблему, хорошо подходят маленькие обёртки. Хитрость в том, что не надо раздувать их до размеров и универсальности ATL/WTL/MFC. Тратить время, силы, глубоко проектировать и т.п. Просто вынеси вызов с перечислением 7-8 неизменных аргументов (не параметров!) из 11 в отдельный файлик, и пользуйся. Перечисляй при вызове только 3-4 актуальных аргумента.
Конечно, окружающие могут начать обзывать такой class File {} (или что там у тебя) "велосипедом", смеяться и тыкать пальцем, но, вообще-то, тут нет ничего смешного. Если не ставить цель написать свой фреймворк, а просто стремиться сделать код читабельнее.
Разумеется, в то, что "вызов функции WinAPI занимает весь экран" я никогда не поверю (у тебя 14" ЭЛТ 800x600 из 90-х, что ли?), но то, что большие вызовы трудно читать — это правда, и с WinAPI я знаком не понаслышке, там есть такая беда. Этот приём позволит её побороть, и оправдан, даже если вызов будет всего один.
