Сабж

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

B>Короче, дискасс.

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

1. Статическая типизация. Но тут нужен баланс, хаскель лесом.

2. Простота. Язык должен познаваться на 99% за пару часов. Чем меньше WTF-ов, тем лучше.

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

4. Понятность. В языке должно быть как можно меньше магии. Посмотрев на код должно быть понятно, что он делает на 100%.

5. Скорость. К языку непосредственно, конечно, не относится, но обычно каждый язык ассоциируется с конкретным компилятором, в общем результат должен выполняться не медленнее, чем код на C. В крайнем случае не на порядок медленней. То же про занимаемую память.

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

У>>Python
B>Я не об этом. Что плохого в навязывании стиля? Уж лучше пусть все в одном стиле пишут, чем как попало.

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

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

B>А что для вас определяет "вкус" языка? Наличие синтаксического сахарка в виде лямбд и прочей функциональщины? Огромная стандартная библиотека? Коммьюнити?

В первую очередь, простота языка (синтаксическая и концептуальная), регулярность (когда похожие вещи выглядят похоже, а разные — различно) и возможность максимально въедливого статического анализа

У>Python
Я не об этом. Что плохого в навязывании стиля? Уж лучше пусть все в одном стиле пишут, чем как попало.

У>Мне не нравится, что это вызывает ошибку компиляции, как минимум
Это же наоборот круто! Единый стиль для всех программ, написанных на этом языке!

У>Или в рантайме что-нибудь вылетит, из-за того, что где-то не так пробел стоит.
Прогонять каким-нибудь PEP verifier'ом или lint'ом перед запуском.

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

B>Короче, дискасс.


Мне в языках нравится культура. Если она практичная и более прикладная (python, Go) то язык нравится. Если вещь в себе с некоторыми странностями (С++, Java) — то не очень, хотя на обоих языках можно писать практично, ядовитого комьюнити, которое будет тебе объяснять важность DI или template metaprogramming не избежать. Мне не нравятся языки, которые пытаются защищать от ошибок ценой verbosity и меньшей выразительности (С++, Scala, Rust). Нравятся языки которые позволяют выстрелить себе в ногу, но на которых очень легко создавать/комбинировать/описывать и тд, т.е. выразительные языки вроде питона или С. В общем, языки в которых есть набор простых строительных блоков из комбинации которых все строится, как в сишечке например, или в Go, или в питоне.

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

CK> Мне не нравятся языки, которые пытаются защищать от ошибок ценой verbosity и меньшей выразительности (С++, Scala, Rust)
CK> выразительные языки вроде питона или С.

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

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

DE>Хм... как по мне, то в С этого самого verbosity будет куда больше чем в С++ или Scala из-за того, что в последних доступны дополнительные инструменты абстракции. Опять же, где в плюсах такая уж особая защита? Смартпоинтеры вместо ручной работы с памятью, например? Так в итоге код наоборот короче получается.

Резьба по цитатам. Я там раскрыл что именно имею ввиду под выразительностью.

CK>Нравятся языки которые позволяют выстрелить себе в ногу, но на которых очень легко создавать/комбинировать/описывать и тд, т.е. выразительные языки вроде питона или С.

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

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

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

У>>Навязывание одного определенного стиля форматирования — минусище
B>???

Python

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

B>А что для вас определяет "вкус" языка?

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

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

У>Наличие кучи ключевых слов, и необходимость в различных приседаниях, как в паскале — это минус.

По ключевым словам и приседаниям Паскаль не отличается от сишки, по-моему. Разве что напортачить сложнее. Вот Ада уже поинтереснее. Даже указатель на переменную так просто не взять. Но это плюс скорее.

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

У>Begin/End?

А какие с ними проблемы?

>Еще и какие-то мутные правила, когда блоки вложенвы.

???

> Раздел описания констант/переменных/типов в каждой процедуре?

Нефиг большие процедуры делать.

> Как это мешает портачить —

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

T a[N]

вместо

std::array<T,N> a

принято вешать люлей, но нормальных людей мало.

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

vsb>1. Статическая типизация. Но тут нужен баланс, хаскель лесом.
Э.... А что не так с типизацией в Хаскеле? По сравнению, скажем, с С++?

You will always get what you always got
  If you always do  what you always did

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

У>Писать дольше и захламляют код



У>Ну там где-то точку надо ставить, где-то не надо. Не помню, давно не откушивал

Про точку с запятой после } я до сих пор запомнить не могу. А в Паскале точка нужна лишь после мейна.

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

Одно слово var. Фишка с объявлением в начале действительно бесит, но лишь когда говнокод жёсткий лепишь.

У>Хм, кто-то еще использует сейчас массивы, а не вектора?

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

У>:= vs =/== — спасибо, что напомнил. Отдельный луч поноса за эту фишку.

А, ещё свич, в котором по умолчанию выполнение "протекает" в следующий блок, и надо ставить бряк, чтоб этого не было. Это просто пипец какой-то. Возможность делать перечисления и диапазоны в метках свича убивает 95% применения протекания, а на остальные 5% случаев (которые все говнокод) добавили б слово "континуе" для принудительного протекания.

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

TB>Нефиг большие процедуры делать.

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

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

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

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

Нередко слышу вокруг себя субъективные (и не очень) мнения о том, что такой-то язык г#вно и писать на нём в современном мире -- моветон.

Разумеется, в таком тоне говорится абсолютно обо всём -- PHP, JS, 1С etc. Как известно, языки делятся на два типа -- те, которые ненавидят, и те, на которых никто не пишет.

А что для вас определяет "вкус" языка? Наличие синтаксического сахарка в виде лямбд и прочей функциональщины? Огромная стандартная библиотека? Коммьюнити?

Короче, дискасс.

M>Сабж
TypeScript же.

У>Навязывание одного определенного стиля форматирования — минусище
???

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

M>>Сабж
B>TypeScript же.
Еще не вникал. Но придется, похоже. Больно часто стал упоминаться.

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

У>>Мне не нравится, что это вызывает ошибку компиляции, как минимум
B>Это же наоборот круто! Единый стиль для всех программ, написанных на этом языке!

И мне этот стиль не удобен


У>>Или в рантайме что-нибудь вылетит, из-за того, что где-то не так пробел стоит.
B>Прогонять каким-нибудь PEP verifier'ом или lint'ом перед запуском.

Ну, pep'ом, да. А смысл тогда в динамике, если всё равно нужно какие-то прогоны типа компиляции делать? Тогда бы уж и типизацию бы статическую прикрутили бы, всяко больше пользы, как сейчас.

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

У>>Наличие кучи ключевых слов, и необходимость в различных приседаниях, как в паскале — это минус.

TB>По ключевым словам и приседаниям Паскаль не отличается от сишки, по-моему. Разве что напортачить сложнее. Вот Ада уже поинтереснее. Даже указатель на переменную так просто не взять. Но это плюс скорее.

Begin/End? Еще и какие-то мутные правила, когда блоки вложенвы. Раздел описания констант/переменных/типов в каждой процедуре? Мелочь конечно, но напрягает при регулярном использовании. Как это мешает портачить —

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

У>>Begin/End?

TB>А какие с ними проблемы?

Писать дольше и захламляют код


>>Еще и какие-то мутные правила, когда блоки вложенвы.

Ну там где-то точку надо ставить, где-то не надо. Не помню, давно не откушивал


>> Раздел описания констант/переменных/типов в каждой процедуре?

TB>Нефиг большие процедуры делать.

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

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

TB>T a[N] 
TB>

TB>вместо
TB>

TB>std::array<T,N> a 
TB>

TB>принято вешать люлей, но нормальных людей мало.

Хм, кто-то еще использует сейчас массивы, а не вектора?
:= vs =/== — спасибо, что напомнил. Отдельный луч поноса за эту фишку. На знак = вместо == — натыкаюсь регулярно, да. Раз в пару лет. И компилятор не дает так сделать (не помню, ошибка или варнинг, скорее всеже второе), если уж приспичило что-то именно приравнять, приходится доп скобки ставить

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

TB>А, ещё свич, в котором по умолчанию выполнение "протекает" в следующий блок, и надо ставить бряк, чтоб этого не было. Это просто пипец какой-то. Возможность делать перечисления и диапазоны в метках свича убивает 95% применения протекания, а на остальные 5% случаев (которые все говнокод) добавили б слово "континуе" для принудительного протекания.

Надо просто помнить, что свич — это просто goto label на стероидах

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

У>Надо просто помнить, что свич — это просто goto label на стероидах

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

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

У>>Надо просто помнить, что свич — это просто goto label на стероидах

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

Ну, если не легче, то ничем не могу помочь.

Меня сишный свич вполне устраивает, не вижу с ним никаких проблем

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

У> не вижу с ним никаких проблем

Необходимость запасаться активированным углём — не проблема?!

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

У>> не вижу с ним никаких проблем

TB>Необходимость запасаться активированным углём — не проблема?!

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

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

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

Значит, желудок привык...

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

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

TB>Значит, желудок привык...

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

vsb>>1. Статическая типизация. Но тут нужен баланс, хаскель лесом.
J>Э.... А что не так с типизацией в Хаскеле? По сравнению, скажем, с С++?

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

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

B>Я не об этом. Что плохого в навязывании стиля? Уж лучше пусть все в одном стиле пишут, чем как попало.

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

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

TB>По ключевым словам и приседаниям Паскаль не отличается от сишки, по-моему. Разве что напортачить сложнее.
По своему опыту работы с DirectX (то ли восьмым, то ли девятым — не помню уже) из Delphi — код очень капитально замусоривается бесконечными приведениями типов, в итоге за деревьями из кастов становится не видно леса (то есть непонятно, что, собственно, код делает — ну кроме приведений типов само собой).
Отдельная история с COM-интерфейсами в дельфях.
Короче, паскаль считает себя умнее того, кто пишет на нём код. Мне это не нравится.

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

У>Хм, кто-то еще использует сейчас массивы, а не вектора?
Я использую в коде для МК. Ибо там нету менеджера памяти, так как в нём нет никакого смысла (всего памяти считанные килобайты максимум). Потому массивы являются единственным способом как-то упорядочить расход памяти.

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

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

TB>>По ключевым словам и приседаниям Паскаль не отличается от сишки, по-моему. Разве что напортачить сложнее.
K>По своему опыту работы с DirectX (то ли восьмым, то ли девятым — не помню уже) из Delphi — код очень капитально замусоривается бесконечными приведениями типов, в итоге за деревьями из кастов становится не видно леса (то есть непонятно, что, собственно, код делает — ну кроме приведений типов само собой).

А что там с кастами? В крестах со всеми предупреждениями всякие static_cast приходится писать не меньше.

K>Отдельная история с COM-интерфейсами в дельфях.

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

K>Короче, паскаль считает себя умнее того, кто пишет на нём код. Мне это не нравится.

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

У>>Хм, кто-то еще использует сейчас массивы, а не вектора?
K>Я использую в коде для МК. Ибо там нету менеджера памяти, так как в нём нет никакого смысла (всего памяти считанные килобайты максимум). Потому массивы являются единственным способом как-то упорядочить расход памяти.

Ну для МК и паскаля нет со встроенной проверкой индексов

ЗЫ Для ардуино есть какая-то либа, имитирующая несколько классов stl, там вектор есть, и я его использовал

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

TB>А что там с кастами? В крестах со всеми предупреждениями всякие static_cast приходится писать не меньше.
В плюсах они нужны намного реже. Конкретно в случае DirectX точно.

TB>Они в язык вроде интегрированы, но я уже не помню подробностей.
Зато я вот до сих пор помню — а уже полтора десятка лет прошло

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

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

TB>>А что там с кастами? В крестах со всеми предупреждениями всякие static_cast приходится писать не меньше.
K>В плюсах они нужны намного реже. Конкретно в случае DirectX точно.

Я вспомнил только две вещи, которые можно в плюсах, но нельзя в Дельфи.
1. Арифметика указателей. В ДХ оно разве надо?
2. Приведение массива к указателю неявно, в Дельфи приходится писать foo(@a[0]). Но вроде бы нормальные люди и так не пользуются сырыми массивами, и в любом случае уже вместо foo(a) пишут foo(a.data()) либо foo(&a[0]).

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