gammaker
> STL многие не любят, а значит, буду заинтересовавшиеся.
Как раз наоборот, те, кто не любит STL, тем будет глубоко наплевать какие там шаги предпринимаются для его воскрешения. Разве что поугарать с неудачников, которые до сих пор пытаются что-то сделать с этим трупом.
> Потому что Go продвигает Google, а D не продвигает никто.
Нет, просто Go даёт программистам кое что из того, чего до сих пор нет в С++ и чего там уже никогда не появится: лёгкие потоки, менеджер пакетов из коробки. А D это просто немного улучшенная замена всё тем же умирающим крестам, без каких-то особых улучшений. Ну да, нормальные шаблоны и годогенерация. Ну да, модули приведены в порядок (что для языка, придуманного в XXI веке уже скорее обязательный пункт) и чуть получше стандартная библиотека. Но эффективному решению задач это всё равно не способствует.
Ну и конечно же гугл не стал бы продвигать D.
gamedevfor
> Потому что твой STL не выполняет требования стандарта по С++
Если что, то я не придерживаюсь стандарта, по крайней мере, во всём, иначе это действительно получится ещё одна STL. Я пишу свою библиотеку, которая не является STL, но которая может её заменить. Но если это что-то важное и конкретное, пиши - именно этой дискуссии я и жду.
gamedevfor
> и даже поверхностный обзор показывает что ты многих моментов вовсе не
> учитываешь
С этого места давай поподробнее. Каких моментов я не учитываю? Ну кроме тех про которые я сам знаю и собираюсь проработать - например безопасность с точки зрения исключений.
gamedevfor
> а если за твою хрень возьмется комитет С++ то вообще боюсь ты получишь дурную славу.
Не возьмётся, потому что они от своей STL уже никогда не откажутся ради обратной совместимости. Да и стиль кода у меня другой, не тот, который принят в STL. Для меня это плюс, а для них - серьёзный минус.
Zefick
> Как раз наоборот, те, кто не любит STL, тем будет глубоко наплевать какие там
> шаги предпринимаются для его воскрешения. Разве что поугарать с неудачников,
> которые до сих пор пытаются что-то сделать с этим трупом.
Я не пытаюсь воскресить STL, я наоборот хочу его похоронить и заменить чем-то более современным и удобным.
Zefick
> Нет, просто Go даёт программистам кое что из того, чего до сих пор нет в С++ и
> чего там уже никогда не появится: лёгкие потоки, менеджер пакетов из коробки.
Не очень понимаю, что это за лёгкие потоки и насколько они нужны. Но что-то типа менеджера пакетов есть в D - DUB. Может это и не совсем из коробки, но вроде многие проекты его используют.
Zefick
> А D это просто немного улучшенная замена всё тем же умирающим крестам, без
> каких-то особых улучшений.
В каких языках есть шаблоны и кодогенерация кроме C++, D и некоторых совсем экзотических языков? В Java нет, в C# нет, в Go нет. И это накладывает большие ограничения на языки. С шаблонами и кодогенерацией и другими фичами C++\D потенциал больше - можно вывернуться и многое запилить самому. А без них приходится довольствоваться тем, что есть.
Zefick
> Но эффективному решению задач это всё равно не способствует.
А что способствует этому в твоей любимой Java кроме наличия нужных библиотек? Предположим, если бы в C++ или D были все нужные библиотеки. То каких бы фич языка не хватало, чтобы всё это было максимально удобным?
gammaker
> А что способствует этому в твоей любимой Java кроме наличия нужных библиотек?
Наличие большого количества библиотек это следствие удобства языка, а не причина.
9К720
> Наличие большого количества библиотек это следствие удобства языка, а не
> причина.
Это и причина и следствие. А ещё есть куча других причин, по которым у языка может быть много библиотек, например популярность, которая ещё зависит от того, как этот язык продвигают.
По поводу количества "библиотек" новость недавно была.
На конференции Node.js Interactive озвучены заслуживающие внимания достижения проекта NPM.
В настоящее время в NPM размещено более 380 тысяч пакетов. Для сравнения в репозитории Apache Maven присутствует 173 тысячи пакетов, в Rubygems.org - 127 тысяч, в Packagist (PHP) - 123 тысячи, в PyPI - 96 тысяч, в nuget (.NET) - 70 тысяч, в CPAN - 34 тысячи.
За последние 28 дней через NPM было установлено 18 миллиардов пакетов.
9К720
> следствие удобства языка, а не причина.
только удобства для бизнеса, а не для программистов. А так да, то что в Java-мире надо на любой чих XML для настройки фабрики поправить это удобно.
vater
> что аж на любой вкус — Scala, Groovy, новоиспеченный Kotlin.
Ну и Groovy я так понимаю собирается умирать, а котлин это вендорлок, вдруг jetbrains завтра поссорятся с ораклом и разорятся.
gammaker
> Это и причина и следствие.
Изначальной причиной количество и качество библиотек быть не может, они же не из воздуха появились, лол.
>А ещё есть куча других причин, по которым у языка
> может быть много библиотек, например популярность, которая ещё зависит от того,
> как этот язык продвигают.
Это ты к чему? Какая-то теория заговора? Язык продвигают потому что он позволяет решать задачи быстро, дешево и удобно.
kipar
>только удобства для бизнеса, а не для программистов
Естественно. А как иначе? Все решения делаются для бизнеса. Как и везде.
Ты небось когда покупаешь машину,тоже хочешь, чтобы она была сделана удобно для тебя, а не для слесаря на конвеере или проектировщика в конструкторском отделе.
Ну и одно другому не мешает. Чай библиотеки не бизнесмены пишут.
> А так да, то что в Java-мире надо на любой чих XML для настройки фабрики
> поправить это удобно.
Херню не пиши. Понятно почему для тебя 200к в соседнем треде это огромная недостижимая сумма.
kipar
> Ну и Groovy я так понимаю собирается умирать,
С чего это? Это один из самых популярных скриптовых языков на данный момент.
9К720
> Ты небось когда покупаешь машину,тоже хочешь, чтобы она была сделана удобно для
> тебя, а не для слесаря на конвеере или проектировщика в конструкторском отделе.
Java как раз можно сравнить с машиной удобной не для водителя, а для его работодателя. Например в которой нельзя на красный свет свернуть и которая всегда его вовремя на работу довезет, даже если он индус и правил не знает.
9К720
> Херню не пиши. Понятно почему для тебя 200к в соседнем треде это огромная
> недостижимая сумма.
Это сарказм был. Конечно ничего в этом нет удобного.
9К720
> Изначальной причиной количество и качество библиотек быть не может, они же не
> из воздуха появились, лол.
Я не говорю, что это изначальная причина. Тогда это был бы замкнутый круг. Но были другие факторы, которые позволили этот замкнутый круг разорвать.
9К720
> Это ты к чему? Какая-то теория заговора?
К тому, что каждая компания хочет продвинуть своё детище, зачем им чужие языки продвигать? А у крупных компаний есть деньги на разработку и продвижение языка.
>Язык продвигают потому что он
> позволяет решать задачи быстро, дешево и удобно.
Без библиотек язык не позволяет этого. Сам по себе язык нужными библиотеками не обрастёт, а значит, не будет удобным. Нужны люди, которые будут трудиться над этим, а бесплатно немногие захотят это делать. Поэтому без поддержки со стороны крупной компании язык будет развиваться десятки лет, как это и происходит сейчас с D.
Повелительница
Всего пять минут же, почти незаметно. Даже серьезные бизнесмены могут себе такой перерыв позволить! Да вы больше на учебу ПДД потратите!
Повелительница
> всякие unity тормозят безбожно
ну например libGDX, чем не альтернатива юньке, написан на жабе с подключением нативных dll-ок. Запаса производительности хватит с головой
kipar
> котлин это вендорлок, вдруг jetbrains завтра поссорятся с ораклом и разорятся
как это может повлиять на разработку опенсорсного проекта, завязанного на другом опенсорсном проекте (OpenJDK, например)?
или может быть ситуация, когда у языка вообще нет своего компилятора, а только лишь талмуд на 1200 страниц мелким шрифтом, и все держится на сторонних разработках, лучше?
Я хочу некстген графоний, удобный интерфейс, поддерживаемые передовые технологии - симуляцию не трердых тел, гпу-ускоренную и легко конфигурируемую систему частиц, эти ваши мегатекстуры, стриминг локаций.
Я не хочу думать как быстро происходит конкатенация строк и копирование массивов.
vater
Котлин это боковой проект компании, которая делает деньги на IDE. Если они завтра обанкротятся или решат что им выгоднее будет его закрыть и раскручивать YAJVMLang то о языке никто и не вспомнит, пофиг опенсорсный он или нет. В этом смысле языки которые начали независимые энтузиасты или совсем гиганты типа гугла все-таки надежнее.
Ну да, это не слишком серьезный аргумент, а сам котлин мне в принципе понравился, синтаксис лаконичный, идеи интересные, ide неплохая.
Мне в нём только JVM не нравится - как только доходит до того чтоб что-то делать надо подключать библиотеки которые писались отнюдь не на котлине. Смотришь на это безумие из волшебных аннотаций к каждому методу, xml и бойлерплейта и то ли для индусов писали то ли для инопланетян.
Вот даже GUI взять - на вопрос "какая самая современная адекватная и всё такое библиотека" уверенно отвечают "JavaFX", на вопрос "а как там делать GUI" - да кодом делайте, ну да, там есть SceneBuilder, но он глючит, лучше запускайте отдельным окном и вручную все теги копируйте, а что тормозит так это ничего, вы же не серьезно GUI собрались на Java делать, на ней только интерпрайз пишут.
kipar
> В этом смысле языки которые начали независимые энтузиасты или совсем гиганты
> типа гугла все-таки надежнее.
Совсем гигантам вообще кинуть свой проект ничего не стоит. Про MS лишний раз напоминать надеюсь не надо, гугл тоже держит марку в этом деле. Они делают что-то лишь до тех пор, пока заниматься этим выгоднее, чем отказаться. А проекты энтузиастов держатся исключительно на хайпе. Энтузиазм самих энтузиастов, как правило, иссякает даже раньше, чем хайп переходит из стадии роста в стагнацию и проект к тому времени держится исключительно усилиями периодически появляющихся случайных контрибуторов из числа студентов, которые повелись на вау-эффект, но почему-то решили не писать своего убийцу этого проекта. Естественно эти случайные контрибуторы ничего слышать не хотят про какие-то там планы развития и реализовывают то, что кажется прежде всего именно им наиболее интересным. Фиксаль какие-то некритичные баги? На фиг надо, и так сойдёт.
Тема в архиве.