Войти
ФлеймФорумПрограммирование

Почему вы НЕ будете использовать свой движок? (26 стр)

Страницы: 122 23 24 25 26 27 Следующая »
#375
8:03, 23 янв 2017

gammaker
> STL многие не любят, а значит, буду заинтересовавшиеся.
  Как раз наоборот, те, кто не любит STL, тем будет глубоко наплевать какие там шаги предпринимаются для его воскрешения. Разве что поугарать с неудачников, которые до сих пор пытаются что-то сделать с этим трупом.

> Потому что Go продвигает Google, а D не продвигает никто.
  Нет, просто Go даёт программистам кое что из того, чего до сих пор нет в С++ и чего там уже никогда не появится: лёгкие потоки, менеджер пакетов из коробки. А D это просто немного улучшенная замена всё тем же умирающим крестам, без каких-то особых улучшений. Ну да, нормальные шаблоны и годогенерация. Ну да, модули приведены в порядок (что для языка, придуманного в XXI веке уже скорее обязательный пункт) и чуть получше стандартная библиотека. Но эффективному решению задач это всё равно не способствует.
  Ну и конечно же гугл не стал бы продвигать D.

#376
11:34, 23 янв 2017

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 были все нужные библиотеки. То каких бы фич языка не хватало, чтобы всё это было максимально удобным?

#377
11:52, 23 янв 2017

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

#378
12:04, 23 янв 2017

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

#379
12:05, 23 янв 2017

По поводу количества "библиотек" новость недавно была.

На конференции 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 миллиардов пакетов.

#380
12:15, 23 янв 2017

9К720
> следствие удобства языка, а не причина.
только удобства для бизнеса, а не для программистов. А так да, то что в Java-мире надо на любой чих XML для настройки фабрики поправить это удобно.
vater
> что аж на любой вкус — Scala, Groovy, новоиспеченный Kotlin.
Ну и Groovy я так понимаю собирается умирать, а котлин это вендорлок, вдруг jetbrains завтра поссорятся с ораклом и разорятся.

#381
12:20, 23 янв 2017

gammaker
> Это и причина и следствие.
Изначальной причиной количество и качество библиотек быть не может, они же не из воздуха появились, лол.

>А ещё есть куча других причин, по которым у языка
> может быть много библиотек, например популярность, которая ещё зависит от того,
> как этот язык продвигают.
Это ты к чему? Какая-то теория заговора? Язык продвигают потому что он позволяет решать задачи быстро, дешево и удобно.

#382
12:24, 23 янв 2017

kipar
>только удобства для бизнеса, а не для программистов
Естественно. А как иначе? Все решения делаются для бизнеса. Как и везде.

Ты небось когда покупаешь машину,тоже хочешь, чтобы она была сделана удобно для тебя, а не для слесаря на конвеере или проектировщика в конструкторском отделе.

Ну и одно другому не мешает. Чай библиотеки не бизнесмены пишут.

> А так да, то что в Java-мире надо на любой чих XML для настройки фабрики
> поправить это удобно.
Херню не пиши. Понятно почему для тебя 200к в соседнем треде это огромная недостижимая сумма.

kipar
> Ну и Groovy я так понимаю собирается умирать,
С чего это? Это один из самых популярных скриптовых языков на данный момент.

#383
12:39, 23 янв 2017

9К720
> Ты небось когда покупаешь машину,тоже хочешь, чтобы она была сделана удобно для
> тебя, а не для слесаря на конвеере или проектировщика в конструкторском отделе.
Java как раз можно сравнить с машиной удобной не для водителя, а для его работодателя. Например в которой нельзя на красный свет свернуть и которая всегда его вовремя на работу довезет, даже если он индус и правил не знает.

9К720
> Херню не пиши. Понятно почему для тебя 200к в соседнем треде это огромная
> недостижимая сумма.
Это сарказм был. Конечно ничего в этом нет удобного.

#384
12:48, 23 янв 2017

9К720
> Изначальной причиной количество и качество библиотек быть не может, они же не
> из воздуха появились, лол.
Я не говорю, что это изначальная причина. Тогда это был бы замкнутый круг. Но были другие факторы, которые позволили этот замкнутый круг разорвать.

9К720
> Это ты к чему? Какая-то теория заговора?
К тому, что каждая компания хочет продвинуть своё детище, зачем им чужие языки продвигать? А у крупных компаний есть деньги на разработку и продвижение языка.

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

#385
12:53, 23 янв 2017

Повелительница
Всего пять минут же, почти незаметно. Даже серьезные бизнесмены могут себе такой перерыв позволить! Да вы больше на учебу ПДД потратите!

#386
14:38, 23 янв 2017

Повелительница
> всякие unity тормозят безбожно
ну например libGDX, чем не альтернатива юньке, написан на жабе с подключением нативных dll-ок. Запаса производительности хватит с головой

kipar
> котлин это вендорлок, вдруг jetbrains завтра поссорятся с ораклом и разорятся
как это может повлиять на разработку опенсорсного проекта, завязанного на другом опенсорсном проекте (OpenJDK, например)?
или может быть ситуация, когда у языка вообще нет своего компилятора, а только лишь талмуд на 1200 страниц мелким шрифтом, и все держится на сторонних разработках, лучше?

#387
15:31, 23 янв 2017

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

#388
15:33, 23 янв 2017

vater
Котлин это боковой проект компании, которая делает деньги на IDE. Если они завтра обанкротятся или решат что им выгоднее будет его закрыть и раскручивать YAJVMLang то о языке никто и не вспомнит, пофиг опенсорсный он или нет. В этом смысле языки которые начали независимые энтузиасты или совсем гиганты типа гугла все-таки надежнее.
Ну да, это не слишком серьезный аргумент, а сам котлин мне в принципе понравился, синтаксис лаконичный, идеи интересные, ide неплохая.

Мне в нём только JVM не нравится - как только доходит до того чтоб что-то делать надо подключать библиотеки которые писались отнюдь не на котлине. Смотришь на это безумие из волшебных аннотаций к каждому методу, xml и бойлерплейта и то ли для индусов писали то ли для инопланетян.
Вот даже GUI взять - на вопрос "какая самая современная адекватная и всё такое библиотека" уверенно отвечают "JavaFX", на вопрос "а как там делать GUI" - да кодом делайте, ну да, там есть SceneBuilder, но он глючит, лучше запускайте отдельным окном и вручную все теги копируйте, а что тормозит так это ничего, вы же не серьезно GUI собрались на Java делать, на ней только интерпрайз пишут.

#389
18:26, 23 янв 2017

kipar
> В этом смысле языки которые начали независимые энтузиасты или совсем гиганты
> типа гугла все-таки надежнее.
  Совсем гигантам вообще кинуть свой проект ничего не стоит. Про MS лишний раз напоминать надеюсь не надо, гугл тоже держит марку в этом деле. Они делают что-то лишь до тех пор, пока заниматься этим выгоднее, чем отказаться. А проекты энтузиастов держатся исключительно на хайпе.  Энтузиазм самих энтузиастов, как правило, иссякает даже раньше, чем хайп переходит из стадии роста в стагнацию и проект к тому времени держится исключительно усилиями периодически появляющихся случайных контрибуторов из числа студентов, которые повелись на вау-эффект, но почему-то решили не писать своего убийцу этого проекта. Естественно эти случайные контрибуторы ничего слышать не хотят про какие-то там планы развития и реализовывают то, что кажется прежде всего именно им наиболее интересным. Фиксаль какие-то некритичные баги? На фиг надо, и так сойдёт.

Страницы: 122 23 24 25 26 27 Следующая »
ФлеймФорумПрограммирование

Тема в архиве.