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

vsb>>На мой взгляд почти идеальный баланс это Java 1.4 (до введения генериков). Я бы туда добавил только properties и некоторые мелкие фичи из поздних версий Java.

П>Восьмая Java — это 1.8?

Вроде 1.5 ребренднули в 5 и дальше уже начали называть без "1.". Так что — да.

> Писал как-то на ней, после даже 0x03 плюсиков — полный отстой. Про 1.4 даже думать не хочется, что там

Ну если вкратце — то 5 это генерики, 6 и 7 какие-то проходные, по языку там изменений почти не было, 8 это уже куча изменений, самое главное это лямбда и функциональная библиотека потоков для коллекций (streams).

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

vsb>Просто для понимания — люди пишут на JS и на Python, где типов вообще никаких нет.

Там типы есть.

Только типизация динамическая, а не статическая.

vsb>И нормально пишут. Тебя это тоже так удивляет?

Нет. Динамическая типизация дает позволяет применять duck typing, что и есть обобщенное программирование для динамически типизированных языков.

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

vsb>>Просто для понимания — люди пишут на JS и на Python, где типов вообще никаких нет.

S>Там типы есть.

S>Только типизация динамическая, а не статическая.

Я про типы в коде.

vsb>>И нормально пишут. Тебя это тоже так удивляет?

S>Нет. Динамическая типизация дает позволяет применять duck typing, что и есть обобщенное программирование для динамически типизированных языков.

Это всё теория. На практике без типов у тебя каждая опечатка вылезает только в рантайме. А значит тебе надо тестировать каждую строку кода, чтобы быть хоть сколько-то в нём уверенным. Если есть статическая типизация, то компилятор даёт частичную уверенность. Если нет генериков, значит все структуры данных используют базовый тип вроде Object. То бишь нужно кастовать и неправильно указанный тип вылезет только в рантайме. Но тут всё же ошибиться куда сложней, тут нужно ошибиться не просто в одной букве, а в названии целого типа (или неправильно понять, что передаётся).

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

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

S>Давайте возьмем два языка — базовый ЯП — C и какой-нибудь достаточно высокоуровневый, как то C#.

S>Что можно отнести к синтаксическому сахару, приятному для глаз, но особо ни на что не влияющему. А что относится к вещам реально сокращающим время разработки.

auto в C++ облегчает написание, но, порой, снижает читаемость кода.

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

N>А Исаак Ломоносов сказал, что большинство цитат из Интернета приписано тем, кто их никогда не говорил.
"Никогда не доверяйте цитатам из интернета" (с) Ленин

SD>>Чем больше строк кода, тем больше ошибок (в квадрате).
N>Ссылку на исследования — в студию.
N>Причём так, чтобы универсально подходило ко всем языкам, и чтобы там был именно квадрат.

Квадрат это конечно перебор, но плотность (количество на строку кода) ошибок растет при увеличении объема после определенного порога.
Исследование раз (язык ADA) https://www.cs.colostate.edu/~cs530/modsize.pdf — плотность ошибок модуля после объема в 250 строк начинает расти.
Исследование два (опенсорс Java) — https://www.researchgate.net/publication/221635599_A_Study_on_Defect_Density_of_Open_Source_Software — растет незначительно при росте размера ПО.

Поэтому при прочих равных писать меньше — всегда лучше.

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

vsb>Я про типы в коде.

Я тоже.

Типы есть и никуда не деваются.

В отличии от программирования на ассемблере или на C/C++ когда все прячется за void*.

S>>Нет. Динамическая типизация дает позволяет применять duck typing, что и есть обобщенное программирование для динамически типизированных языков.

vsb>Это всё теория.

Ну ничёсе, пардон май френч. Это самая что ни есть практика.

vsb>На практике без типов у тебя каждая опечатка вылезает только в рантайме.

В динамически типизированном ЯП -- да, вылезет. К счастью.
В чистой сишечке ничего не вылезет, разве что программа быстро упадет, если повезет.

vsb>А значит тебе надо тестировать каждую строку кода, чтобы быть хоть сколько-то в нём уверенным.

Ну вот в динамически-типизированных языках такую цену приходится платить за обобщенный код.

Когда же обобщенное программирование не поддерживается от слова совсем, то и объем исходного кода раздувается, и тестировать все это все равно приходится.

vsb>Вероятно у го в этом плане подход идеальный. Он даёт обобщённый интерфейс для базовых структур вроде массива, отображения и всё. В итоге 99% клиентского кода работают как будто в языке есть генерики. При этом это никак не повышает сложность системы типов и интуитивно понятно для программиста. В общем если говорить про идеальный язык, наверное конкретно эту бы фичу я тоже из го взял. Не давать генерики программисту в руки, но дать их стандартной библиотеке.

У вас какая-то шизофреничность в желаниях. То Java до генериков идеал, то Go с генериками.

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

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

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

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

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

CC>case 100500: FooBar (foo, bar); break;

Это по сути один statement. Метка ("case") это атрибут, а break — вообще пережиток обратной совместимости с "языком для goto".

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

Само собой. Речь не о том, что нужно все "однострочные методы" убрать, или потребовать форматировать всю программу в одну строку.

А о простой статистике — чем больше буковок кода (при прочих равных), тем больше багов в этом коде. Собственно, языки высокого уровня для того и нужны, чтобы уменьшить количество этих самых буковок, а значит, ускорить чтение и написание кода, заодно снизив и количество багов. Посему называть "синтаксический сахар" бесполезным — ошибка. Это очень важный компонент языка программирования. Порой, пожалуй, даже более важный, чем остальное. А то ведь С — это "синтаксический сахар" поверх ассемблера.

G>Квадрат это конечно перебор, но плотность (количество на строку кода) ошибок растет при увеличении объема после определенного порога.

Квадрат, это, конечно, шутка (для соответствия формуле).
Спасибо за ссылки. Есть и другие исследования. Не смог сходу найти, но то, где в Ericsson переписали код AXD301, и получили в 4 раза меньше строчек при очень высоком uptime и низких ошибках.

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

Ну вот замыкания,Linq, yield, async await, ПМ, Span это тоже сахар. Но удобный. Экономит кучу времени.
Те же деревья выражений

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


vsb>Ну я вот на Go недавно несколько тысяч строк написал. Генерик я использовал там ровно в одном месте:
ну, мне самому писать свои генерики и правда не каждый день приходится, но использовать то практически всегда. Те же коллекции без генериков — это ж караул.

vsb>Не, генерики это штука хорошая, я же с этим не спорю. Но систему типов они усложняют очень изрядно. Настолько изрядно, что работающий рефлекшн с простой системой типов я бы предпочёл этим генерикам.
Гм, вместо системы типов, которая при компиляции всё проверит, писать решение на строках, которое упадёт только в рантайме. Странный выбор.

vsb>Просто для понимания — люди пишут на JS и на Python, где типов вообще никаких нет. И нормально пишут. Тебя это тоже так удивляет? Я считаю, что писать вообще без типов это уже чересчур. Но для меня золотая середина пролегает вот примерно где-то в районе Java 1.4.
Люди конечно пишут, но как-то не всем нравится без типов. Неспроста появились TS и аннотации типов в Питоне, в которых(surprise) есть генерики.

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

S>Давайте возьмем два языка — базовый ЯП — C и какой-нибудь достаточно высокоуровневый, как то C#.

S>Ваше мнение?

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



Рич Хикки довольно глубокий анализ дал на эту тему. В общем случае да чем проще тем лучше, но вопрос что есть просто не простой.
Св-ва шарпа это необходимость работы с binding winforms, потом уже его дальше потащили.

Объективно одна вещь (ЯП) может быть проще другой. Но субъективно чем лучше ты знаешь конкретный ЯП тем лучше код. Пожалуй это очевидно.

В фарпе например не стали сыпать сахар, а придумали движок CE,
теперь у них даже код разметки выглядит почти как родной

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

SD>а break — вообще пережиток обратной совместимости с "языком для goto".
Убери break и получится совсем другое, но тем не менее легальное и часто используемое поведение.

SD>А о простой статистике — чем больше буковок кода (при прочих равных), тем больше багов в этом коде.
Тем не менее refactor rename всех имён на более длинные багов не добавит.

SD> Собственно, языки высокого уровня для того и нужны, чтобы уменьшить количество этих самых буковок, а значит, ускорить чтение и написание кода, заодно снизив и количество багов
Ну вон perl преуспел в уменьшении колва буковок, но это только добавило ему зубодробительной нечитабельности.

SD> Посему называть "синтаксический сахар" бесполезным — ошибка.
А вот это как раз верно.

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

LVV>Все, чего нет в Go — оно и не нужно.
LVV>Только усложняет язык.

Все, чего нет в Обероне — оно и не нужно.
Только усложняет язык.

Все, чего нет в С++ — оно все нужно.
Очередность включения определяют члены комитета и другие уважаемые люди.

LVV>>Все, чего нет в Go — оно и не нужно.
LVV>>Только усложняет язык.
_>Все, чего нет в Обероне — оно и не нужно.
_>Только усложняет язык.
Совершенно верно. В книжке Донована и Кернигана прям так и нарисовано: Go — прямой наследник Оберона.
А синтаксис взят из С.
И там еще есть ветка совсем экспериментальных языков (3 штуки), в основе которых CSP Хоара.
_>Все, чего нет в С++ — оно все нужно.
_>Очередность включения определяют члены комитета и другие уважаемые люди.
И с этим соглашусь.
Математические константы, которые Борланд в библиотеку занесла 25 лет назад, только-только появились...
И модули.
От этого я вообще фигею — конструкция ж хорошо проработана со времен Модулы-2.
Или он там книжек не читают?

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

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

LVV>>Все, чего нет в Go — оно и не нужно.
LVV>>Только усложняет язык.

_>Все, чего нет в Обероне — оно и не нужно.
_>Только усложняет язык.

А в обероне есть как в модуле-2 многопоточка (стр 127)?

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

SD>>а break — вообще пережиток обратной совместимости с "языком для goto".
CC>Убери break и получится совсем другое, но тем не менее легальное и часто используемое поведение.

А это неважно. Главное что семантически это один элемент и писать несколько стейтментов заставляет уродство языка. И то что ты написал одной строкой тому доказательство.

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

D>Тогда ускользает ощущение сложности алгоритма. С таким сахаром джун лекго напишет O^6 код и даже этого не заметит.

Джун так может сделать с любым подходом, потому что обычные функции даже в самом синтаксически бедном ЯВУ тоже никто не отменял.

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

LVV> Все, чего нет в Go — оно и не нужно.
LVV> Только усложняет язык.

Язык без исключений не нужен. Fixed.

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

LVV>Совершенно верно. В книжке Донована и Кернигана прям так и нарисовано: Go — прямой наследник Оберона.
Вот только почему-то Обероном иначе как учебным языком никто не пользуется, а Go несмотря на то, что с некоторых сторон выглядит уродинкой, язык вполне практичный

LVV>А синтаксис взят из С.
Это в java и C# синтаксис взят из С, а в Go какая-то страшненькая мешанина.
Тем не менее Go можно с пользой юзать. почему? Если не углубляться, а чисто идейно, потому как его создатели не изображали из себя мессий несущих в мир единственно правильное, в отличие от Вирта и последователей.

LVV>И модули.
Модули идейно противоречат всей истории Си начиная с Кернигана и Ритчи, решение добавить модули это по сути создание нового языка, но сохранив совместимость, что самое важное.

LVV>От этого я вообще фигею — конструкция ж хорошо проработана со времен Модулы-2.
Потому как в Паскале, честно не претендующем ни на что кроме чисто учебного языка компиляция из нескольких файлов исходников предусмотрена не была предусмотрена.
Ну и Вирт и последователи не заботились о совместимости. Потому как ничего полезного на их языках у чего есть будущее и для чего может быть нужна совместимость, написано все равно не было. Нужно что-то добавить или переделать, по необходимости или из собственного каприза — легко и быстро запилим новый язык. С Си/С++ такое не прокатит.