All streams
Search
Write a publication
Pull to refresh
71
0
Dzmitry Malyshau @kvark

User

Send message

Кто конкретно пишет на ассемблере? Я таких людей не знаю. Напротив, шейдеростроение потихоньку поднимает уровень используемых языков. Так, за сегодняшними HLSL и GLSL с их С-ишным синтаксивом мы видим новый Metal с шейдерами на упрощённом С++. Иронично (к вашему последнему вопросу), общая тенденция идёт к тому, чтобы писать шейдеры на том же языке, то и игру.

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


Они отличаются, но они не лучше, по крайней мере не настолько лучше, чтобы оправдать возвращение набора инструментов обратно в каменный век.

Каждый стоящий новый язык тянет за собой новую парадигму. Если язык не заставляет вас мыслить иначе, значет его незачем изучать.


А все эти росказни про то, что утилиты обратно в каменный век, и что всё переписывать надо — это всё от лукавого. Инструменты должны изначально писаться не под конкретный язык, выделять свои функционально независимые блоки в отдельные взаимозаменяемые модули. Это вопрос развития экосистемы утилит и сред программирования, там ещё поле не пахано (посмотрите на тот же Light Table).

Шикарно! Хочу больше статей о том, как вы делаете ноутбуки.
Можно ли ожидать подобной технологии в X1 Yoga?

Интересно написано. Слишком много математики на мой вкус, плюс вначале некорректная постановка цели:


Сколько существует разных способов представить обыкновенный поворот в трехмерном пространстве?

Какая разница? С интерполяцией вращения и кватернионы отлично справляются. Описываемый вами подход нужен для грамотного совмещения движения и вращения — вот тут-то и надо было альтернативы приводить.


Насколько я понимаю, бикватернионы решают ту же задачу, но более эффективно, а также успешно применяются в реальных проектах. Сам применял, результатом остался доволен ;)

Феноминально, что язык ещё жив. Я в своё время писал на нём всякие мандельбротики, визуализаторы игры жизнь, архиваторы, и прочую мелочь. Тогда это казалось востребованным, ибо компилятор С не был так умён. Сегодня же, не вижу смысла уползать ниже Rust/C без лишней необходимости.

ух, действительно пахнет странно

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

Алфред Ван Вогт, "Чудовище"

Неа, полным ядром там пока и не пахнет. Игры «на нём» делают точно также, как и без движков — пишут свою логику. Автор и сам его движком с натяжкой называет. Всё-таки есть большая разница между большим движком, разбитым на слои/библиотеки, и разбросанным набором библиотек, которые хотят быть движком.
Поясните? В самом начале Rust был сам на себя не похож.
Ну это вы перегнули. На Rust есть графические движки, да, и Piston стремится покрыть многие задачи именно игрового движка. Однако он суть просто набор библиотек, которым ещё долгий путь до настоящих движков. Давайте не торопить события.
Молодцы! Глядишь и вправду игры делать начнут ;)
Странный график скорости у вас, к слову. Go 1.5 обозначен желтым цветом и все маркеры на отмекте 0 секунд. Куда стремиться уже?
стандартные обобщённые структуры данных
Понимаете, в чём ирония… Ладно бы там вообще не было обобщений, как в С. А то ж есть, вот они (map, array), но даны богом свыше и недостижимы простым смертным.
Постойте, постойте-ка, какой ещё статический? Компилятор, по вашему, знает о типе каждого элемента списка на этапе сборки? Ересь.
Go достаточно многословный и строгий язык программирования с очень предсказуемой и стремительной кривой обучения, что делает его крайне удачной технологией для обучения программированию новоприбывших!

Я так понял контекст, что речь идёт о программировании в целом. Исключения есть практически во всех широко используемых языках, проще перечислить, где их нет (Go, Rust, что ещё?). Алгебраические типы также есть во многих языках: Scala, Erlang, Haskell, Rust, etc. Сказать, что это специфические ЯП фишки — явное лукавство.
Давайте тогда уже и механизм исключений не изучать, раз его в Go не завезли. И наследование, и алгебраические типы, и функциональное программирование. Вы понимаете, какова вообще суть обучения?
Грубо говоря, гошная статическая система типов в такой задаче сдаётся без боя.
Ок, встроенными оказались только массивы (array) и отображения (map), насколько я вижу. Аскетичненько так.
Постойте, а разве в Go нету встроенного обобщённого списка?
Я по большей частью согласен, НО «дополнительный слой абстракции» — это скорее про «бутсрапинг или кодогенерация», чем про нормальные родные обобщения. К тому же, никто не заставляет их сразу использовать.

Information

Rating
Does not participate
Location
Toronto, Ontario, Канада
Date of birth
Registered
Activity