Pull to refresh
43
0
Антон Жердев @Anthony

User

Send message
Она там называется утиная типизация — странный гидрид между статической и динамической.
Спасибо!
Да, динамическая типизация — это одна из главных проблем Objective-C. Сильно увеличивает количество ошибок.
В Objective-C она не совсем динамическая, правда, но это мало от чего спасает.
Я думаю, что плохой программист на любом языке напишет плохой код. Он и в Objective-C назовет параметры x, y, z. Мне кажется, что лучше все таки ориентироваться на хороших программистов, которые укажут что это, если это непонятно из контекста. А то в Java, например, приходится комментарий писать рядом или делать билдеры для сложных функций.
Тоже интересная штука. Немного смущает, Garbage Collector. Не будет ли в их реализации он подтормаживать интерфейс. Тоже самое и про Scala. Все таки, очень тонкая вещь, хотя и удобная безусловно.
Этого я не видел. Интересно, посмотрю. На самом деле, можно даже на Haskell писать под Objective-C. Есть и такой проект. Я искал подобные проекты, но все, которые я нашел, были недоделаны, да и многие мне вообще не понравились. Поэтому я решил разработать свой такой же недоделанный проект:)

На самом деле, в тот момент я просто решил написать небольшой генератор для своих нужд. Не думал, что этот генератор со временем вырастит в это.
Это не настолько просто, чтобы каждый бы делал свой язык) Хотя, и не очень сложно, на самом деле.
На самом деле, я не думал об этом. Как-то само получилось это разработать. Я причесал и выложил на github, потому что подумал, что кому-то это может быть интересно: попробовать использовать, присоединиться и развивать под свои нужды. Ни о каком рынке, финансировании или победе над Apple я не думал. Было бы здорово, чтобы Apple сама улучшила Objective-C и она делает это постепенно, но очень медленно.

3) Сейчас не так уж и много людей пишет на Haskell, не смотря на то, что язык крут. Слишком большой порог входа. Кто будет вашим разработчиком?

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

Что с документацией?

Ее нет.

Что с производительностью?

С производительность, он работает на той же скорости, что и Objective-C, так как генерирует код Objective-C, то есть не очень. Вызов функции — довольно медленная вещь в Objective-C. Но в Objective-D можно использовать структуры и работать с ними, как с обычными классами. Они генерируются в C структуры и функции. Это работает намного быстрее, чем Objective-C.

Что с переносимостью?

Через некоторое время собираюсь портировать Raildale на Android. Напишу генератор в Java. Также может быть и на Windows портирую.

Очень здорово, что вы пишете на Haskell — я бы посоветовал вам взять проект немного меньшего масштаба, ведь проблема не в том, чтобы разработать инструмент, а в том, чтобы его поддерживать и развивать. Удачи!

У меня есть довольно много интересных наработок. Возможно, постараюсь оформить что-то из них как законченный небольшой проект. Спасибо!
Честно говоря, bump-mapping не использовал пока что. Без надобности было. Но собираюсь улучшить вид вагончиков в игре, и думаю попробовать применить bump-mapping там. Но техника несложная, на самом деле.

Шаблон под XCode действительно был бы полезен, как мне кажется. Я довольно много времени на это убил при разработке Raildale. Так что постараюсь сделать.
Я не претендую на академичность. Если бы я с самого начала планировал разрабатывать язык, я бы действовал совсем по-другому. Провел бы исследования, выбрал бы более тщательно какие фичи включать, а какие нет. Более тщательно вел бы разработку. А так я и пишу, что на данный момент это еще совсем не доработано. Я просто подумал, что это интересный опыт, и кому-то может пригодиться.

Почему вообще Objective D? Вот, например, существует Objective J и фреймворк Cappuccino: чуваки взяли Objective C, Cocoa и сделали красивый порт на JS.


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

P.S. Оно того стоило? Самое отстойное ведь — вместо продукта (игры) большую часть времени писать велосипед с другим цветом сидения.


На самом деле, мне кажется, что изобретение новых велосипедов не такая уж плохая вещь, как о ней говорят. Да, конечно, это время, но это и прекрасный опыт. Я, например, тут получил опыт разработки на Haskell, а это дорого стоит, как мне кажется. Очень интересный язык, заставляет на многие вещи взглянуть под другим углом.

А разработка игры заняла у меня в 3 раза больше времени, чем разработка Objective-D. Но это, конечно, потому что я не знал OpenGL до этого и не имел опыта работы с 3D редакторами, а использовать готовый движок тоже как-то не хотелось. Там в основном конструкторы, а конструктор сцены это как-то не для меня. Поэтому я написал свой движок, свою модель освещения, карты теней и т.д. Это тоже велосипед, конечно. Но этот опыт также много стоит, как мне кажется. Как-нибудь напишу об этом отдельную статью.
Спасибо. Очень рад, что Вам это интересно. Надеюсь когда-нибудь доведу Objective-D до продакшен состояния.
Наверное, название и действительно, не очень удачное. Но тут ровно такая же логика, которая и у D. Просто следующая буква после C.

Но немного вводит в заблуждение, согласен. Если есть идеи о названии готов рассмотреть:)

Хотя, название на данном этапе большой роли не играет, как мне кажется.
Вообще, это классика объекно-ориентированного проектирования. Я вижу только одно исключение, когда стоит делать по-другому: критические к производительности или потреблению памяти куски. Примитивы намного быстрее и потребляют намного меньше памяти. Но такие куски лучше изолировать от остальной программы.
А я вечный двигатель изобрел только показать не могу пока — тайна:)
Вам не кажется, что это глуповато?
На каком основании вы делаете вывод относительно скорости рекурсивных запросов?
Вы сами сравнивали производительность или видели какое-то исследование?
Если его использовать как "=", то почему бы не написать "=", а не LIKE?
PHP тут не при чем. Так работает процессор с числами с плавающей точкой.
Я написал этот код специально для статьи.
На мой взгляд, та проблема, которую я здесь описал заслуживает внимания.
Не наши, если это не скажется на производительности.
Кроме спорности, наличие перегрузки ослажняет реализацию самого языка.
Я не проверял очень простые методы.
Метод CompareTo тоже простой. В нем вред ли возникнет ошибка, но я все же проверил один вариант.

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

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity