Комментарии 55
Когда впервые за много лет сел за мак на новой работе, посмотрел на objective-C снова (лет десять назад писал на нем какой то инсталлятор) и понял, что он мне очень не нравится эстетически, я как раз стал писать на Скале и очаровался ее лаконичностью и таким новым подходом к разработке программ, вообще было не в кассу. А сейчас посмотрел на ваш проект (scala-like!)и снова загорелся, надеюсь, будет шанс попробовать. Очень вы крутой.
Зашёл увидеть что-то связанное с D…
Наверное, название и действительно, не очень удачное. Но тут ровно такая же логика, которая и у D. Просто следующая буква после C.
Но немного вводит в заблуждение, согласен. Если есть идеи о названии готов рассмотреть:)
Хотя, название на данном этапе большой роли не играет, как мне кажется.
Но немного вводит в заблуждение, согласен. Если есть идеи о названии готов рассмотреть:)
Хотя, название на данном этапе большой роли не играет, как мне кажется.
Objective-Scala? :)
Людям будет понятнее о чем речь:) Для гугления опять же больше подходит. Мне тоже пришла в голову мысль о скрещивании Objective C и D (что тоже кстати было бы интересно).
То что вы сделали — уже очень круто. А если вы сделаете полноценную реализацию такого языка для LLVM, это будет уже не просто круто, а войдет в историю.
То что вы сделали — уже очень круто. А если вы сделаете полноценную реализацию такого языка для LLVM, это будет уже не просто круто, а войдет в историю.
Названо видимо в продолжение традиции Objective-C, который к С тоже мало отношения имеет.
Как это мало имеет? Objective-C это C + "[,],+,-". Это С++ к С мало отношения имеет.
Это С++ к С мало отношения имеет.C++ по крайней мере обратно с С совместим. А Objective-C?
в Objective C-файлах можно писать вообще любой C-код, без всяких extern «C» и прочего. В отличие от C++.
Objective-C это самый обыкновенный C и, собственно, ООП и рантайм. Некоторые из Cocoa-фреймворков вообще имеют исключительно сишный API, например Core Graphics.
Мне язык и нравится в том числе тем, что при необходимости очень легко писать низкоуровневый оптимизированный код на C, а где нужно — высокоуровневый, используя все преимущества динамической типизации. И всё это в рамках одного языка и платформы, без костылей и биндингов между языками.
Мне язык и нравится в том числе тем, что при необходимости очень легко писать низкоуровневый оптимизированный код на C, а где нужно — высокоуровневый, используя все преимущества динамической типизации. И всё это в рамках одного языка и платформы, без костылей и биндингов между языками.
Всё это больше напоминает стандартный подход по написанию фреймворка, вместо использования существующих. “Мне тут усё не нравится, сейчас усё сделаем”. На выходе имеем фреймворк (язык), который пригоден только для нас. Мы на нём что-то ещё где-то сможем сваять (если что, мы подправим фреймворк/язык), а другие — увольте.
В подтверждение к сказанному пара тезисов:
Как бы то ни было, я ни коим образом не принижаю работу автора, факт OpenSource выкладывания его работы и всё такое прочее. Игрушка получилась, судя по всему, классной и это главное.
P.S. Оно того стоило? Самое отстойное ведь — вместо продукта (игры) большую часть времени писать велосипед с другим цветом сидения.
В подтверждение к сказанному пара тезисов:
- В отличие от разработчиков CoffeeScript, SASS/LESS, Dart и RubyMotion (ой, да оно же как раз и позволяет писать на другом языке под iOS), автор не является экспертом Objective C разработки
- Автор так же не имел опыта iOS разработки и программирования на Objective C до разработки ”Objective D“
- Почему вообще Objective D? Вот, например, существует Objective J и фреймворк Cappuccino: чуваки взяли Objective C, Cocoa и сделали красивый порт на JS.
- Большая часть “фишек” не имеют строгой аргументации и скорее сделаны, потому что автору так больше нравится: “Ужасно, что Objective-C не поддерживает дженерики и использует утиную типизацию”, “Мне нравятся именованные параметры в Objective-C”, “Мне нравятся перечисления в Java”
Как бы то ни было, я ни коим образом не принижаю работу автора, факт OpenSource выкладывания его работы и всё такое прочее. Игрушка получилась, судя по всему, классной и это главное.
P.S. Оно того стоило? Самое отстойное ведь — вместо продукта (игры) большую часть времени писать велосипед с другим цветом сидения.
Я не претендую на академичность. Если бы я с самого начала планировал разрабатывать язык, я бы действовал совсем по-другому. Провел бы исследования, выбрал бы более тщательно какие фичи включать, а какие нет. Более тщательно вел бы разработку. А так я и пишу, что на данный момент это еще совсем не доработано. Я просто подумал, что это интересный опыт, и кому-то может пригодиться.
Честно говоря, я вообще не думал над названием. Оно появилось в самом начале, когда я подумал как назвать папку под проект и репозоторий на github.
На самом деле, мне кажется, что изобретение новых велосипедов не такая уж плохая вещь, как о ней говорят. Да, конечно, это время, но это и прекрасный опыт. Я, например, тут получил опыт разработки на Haskell, а это дорого стоит, как мне кажется. Очень интересный язык, заставляет на многие вещи взглянуть под другим углом.
А разработка игры заняла у меня в 3 раза больше времени, чем разработка Objective-D. Но это, конечно, потому что я не знал OpenGL до этого и не имел опыта работы с 3D редакторами, а использовать готовый движок тоже как-то не хотелось. Там в основном конструкторы, а конструктор сцены это как-то не для меня. Поэтому я написал свой движок, свою модель освещения, карты теней и т.д. Это тоже велосипед, конечно. Но этот опыт также много стоит, как мне кажется. Как-нибудь напишу об этом отдельную статью.
Почему вообще Objective D? Вот, например, существует Objective J и фреймворк Cappuccino: чуваки взяли Objective C, Cocoa и сделали красивый порт на JS.
Честно говоря, я вообще не думал над названием. Оно появилось в самом начале, когда я подумал как назвать папку под проект и репозоторий на github.
P.S. Оно того стоило? Самое отстойное ведь — вместо продукта (игры) большую часть времени писать велосипед с другим цветом сидения.
На самом деле, мне кажется, что изобретение новых велосипедов не такая уж плохая вещь, как о ней говорят. Да, конечно, это время, но это и прекрасный опыт. Я, например, тут получил опыт разработки на Haskell, а это дорого стоит, как мне кажется. Очень интересный язык, заставляет на многие вещи взглянуть под другим углом.
А разработка игры заняла у меня в 3 раза больше времени, чем разработка Objective-D. Но это, конечно, потому что я не знал OpenGL до этого и не имел опыта работы с 3D редакторами, а использовать готовый движок тоже как-то не хотелось. Там в основном конструкторы, а конструктор сцены это как-то не для меня. Поэтому я написал свой движок, свою модель освещения, карты теней и т.д. Это тоже велосипед, конечно. Но этот опыт также много стоит, как мне кажется. Как-нибудь напишу об этом отдельную статью.
Вот. Если опубликуете template для Xcode с рисованием пары треугольников с bump-mapping, то еще десяток плюсов получите и вечную славу.
Честно говоря, bump-mapping не использовал пока что. Без надобности было. Но собираюсь улучшить вид вагончиков в игре, и думаю попробовать применить bump-mapping там. Но техника несложная, на самом деле.
Шаблон под XCode действительно был бы полезен, как мне кажется. Я довольно много времени на это убил при разработке Raildale. Так что постараюсь сделать.
Шаблон под XCode действительно был бы полезен, как мне кажется. Я довольно много времени на это убил при разработке Raildale. Так что постараюсь сделать.
Насчет велосипедов в данном случае — очень тонкий момент. Так же можно и Scala назвать велосипедом.
Строго говоря, как Objective-J не имеет ничего общего к J, так и Objective-D имеет право не иметь ничего общего с D.
Да ладно, вот дженерики-то как раз нужны.
И перечисления в Java тоже более типобезопасны, чем старые-добрые enum в C.
И перечисления в Java тоже более типобезопасны, чем старые-добрые enum в C.
Безусловно круто. Но опять набор стандартных вопросов:
1) Вы хотите сделать из языка замену Objective-C. Вы готовы посвятить ближайшие 10-20 лет работе в основном над этим проектом, как это делали родоначальники таких языков как Java, Scala или Python?
2) Предположим вы готовы. На какие средства вы собираетесь финансировать сообщество разработчиков вашего языка? Как вы соберете сообщество? Например Scala получила реальное финансирование пару лет назад.
3) Сейчас не так уж и много людей пишет на Haskell, не смотря на то, что язык крут. Слишком большой порог входа. Кто будет вашим разработчиком?
4) Как вы собираетесь убеждать крупные компании, что им следует пользоваться вашим языком, а не Objective C? Без сообщества и крутых фишек языка у вас не так много шансов выиграть у Apple на их же территории.
5) Что с документацией? Что с производительностью? Что с переносимостью?
Очень здорово, что вы пишете на Haskell — я бы посоветовал вам взять проект немного меньшего масштаба, ведь проблема не в том, чтобы разработать инструмент, а в том, чтобы его поддерживать и развивать. Удачи!
1) Вы хотите сделать из языка замену Objective-C. Вы готовы посвятить ближайшие 10-20 лет работе в основном над этим проектом, как это делали родоначальники таких языков как Java, Scala или Python?
2) Предположим вы готовы. На какие средства вы собираетесь финансировать сообщество разработчиков вашего языка? Как вы соберете сообщество? Например Scala получила реальное финансирование пару лет назад.
3) Сейчас не так уж и много людей пишет на Haskell, не смотря на то, что язык крут. Слишком большой порог входа. Кто будет вашим разработчиком?
4) Как вы собираетесь убеждать крупные компании, что им следует пользоваться вашим языком, а не Objective C? Без сообщества и крутых фишек языка у вас не так много шансов выиграть у Apple на их же территории.
5) Что с документацией? Что с производительностью? Что с переносимостью?
Очень здорово, что вы пишете на Haskell — я бы посоветовал вам взять проект немного меньшего масштаба, ведь проблема не в том, чтобы разработать инструмент, а в том, чтобы его поддерживать и развивать. Удачи!
Лучше бы сразу предложили заполнить сами-знаете-какую анкетку, ей богу.
На самом деле, я не думал об этом. Как-то само получилось это разработать. Я причесал и выложил на github, потому что подумал, что кому-то это может быть интересно: попробовать использовать, присоединиться и развивать под свои нужды. Ни о каком рынке, финансировании или победе над Apple я не думал. Было бы здорово, чтобы Apple сама улучшила Objective-C и она делает это постепенно, но очень медленно.
Поэтому только свой проект может быть шансом попробовать этот язык в деле. Могу сказать, что это очень полезно для любого разработчика.
Ее нет.
С производительность, он работает на той же скорости, что и Objective-C, так как генерирует код Objective-C, то есть не очень. Вызов функции — довольно медленная вещь в Objective-C. Но в Objective-D можно использовать структуры и работать с ними, как с обычными классами. Они генерируются в C структуры и функции. Это работает намного быстрее, чем Objective-C.
Через некоторое время собираюсь портировать Raildale на Android. Напишу генератор в Java. Также может быть и на Windows портирую.
У меня есть довольно много интересных наработок. Возможно, постараюсь оформить что-то из них как законченный небольшой проект. Спасибо!
3) Сейчас не так уж и много людей пишет на Haskell, не смотря на то, что язык крут. Слишком большой порог входа. Кто будет вашим разработчиком?
Поэтому только свой проект может быть шансом попробовать этот язык в деле. Могу сказать, что это очень полезно для любого разработчика.
Что с документацией?
Ее нет.
Что с производительностью?
С производительность, он работает на той же скорости, что и Objective-C, так как генерирует код Objective-C, то есть не очень. Вызов функции — довольно медленная вещь в Objective-C. Но в Objective-D можно использовать структуры и работать с ними, как с обычными классами. Они генерируются в C структуры и функции. Это работает намного быстрее, чем Objective-C.
Что с переносимостью?
Через некоторое время собираюсь портировать Raildale на Android. Напишу генератор в Java. Также может быть и на Windows портирую.
Очень здорово, что вы пишете на Haskell — я бы посоветовал вам взять проект немного меньшего масштаба, ведь проблема не в том, чтобы разработать инструмент, а в том, чтобы его поддерживать и развивать. Удачи!
У меня есть довольно много интересных наработок. Возможно, постараюсь оформить что-то из них как законченный небольшой проект. Спасибо!
Под маленьким проектом я имел в виду что-нибудь вроде (по крайней мере раньше он был маленький): github.com/jaspervdj/hakyll
НЛО прилетело и опубликовало эту надпись здесь
… то всех это начнёт раздражать и полноценные макросы наконец-то появятся в мейнстримных языках.
А как же С++? Он не мэйнстрим уже или там недостаточно крутые макросы? Один знакомый джентльмен батники макросами генерил, которые потом при сборке запускались. К счастью для него, успел уволиться, пока это обнаружили :)
В плюсах очень убогие макросы. Верхней планкой для макросов был и остается Common Lisp, разумеется (в котором reader macros позволяют менять поведение вплоть до уровня лексера, т.е. работать с исходником напрямую как с потоком символов). Но в качестве разумной планки можно посмотреть на Scheme, Nemerle, D.
В плюсах очень убогие макросыИ слава
Так как они реализованы в C да, но можно же совсем по-другому. Макросы, которые оперируют синтаксическим деревом, как, например, в той же Scala: docs.scala-lang.org/overviews/macros/overview.html
С++ и «начинающие» в одном предложении — это практически всегда введение в хоррор стори.
особенно для начинающихЕсли посмотреть на boost::preprocessor, то эту часть предложения можно смело опустить.
Это не настолько просто, чтобы каждый бы делал свой язык) Хотя, и не очень сложно, на самом деле.
А не тыкали ли вы случаем Scala LLVM бекенд? Если его допилить будет же честная(да да да с таким нравом это девочка несмотря что язык) scala и под iOS и вообще.
Scala не может быть честной под iOS/OS X. На это есть несколько причин:
1. Слишком много заточено под Java.
2. Как мне кажется, сделать взаимодействие Objective-C и Scala кода сложно. Слишком разные базовые концепции.
В итоге получите «голую» Scala с забавно выглядящим кодом взаимодействующим с системой.
Если очень уж хочется попробовать «Как оно?», попробуйте RoboVM.
1. Слишком много заточено под Java.
2. Как мне кажется, сделать взаимодействие Objective-C и Scala кода сложно. Слишком разные базовые концепции.
В итоге получите «голую» Scala с забавно выглядящим кодом взаимодействующим с системой.
Если очень уж хочется попробовать «Как оно?», попробуйте RoboVM.
Этого я не видел. Интересно, посмотрю. На самом деле, можно даже на Haskell писать под Objective-C. Есть и такой проект. Я искал подобные проекты, но все, которые я нашел, были недоделаны, да и многие мне вообще не понравились. Поэтому я решил разработать свой такой же недоделанный проект:)
На самом деле, в тот момент я просто решил написать небольшой генератор для своих нужд. Не думал, что этот генератор со временем вырастит в это.
На самом деле, в тот момент я просто решил написать небольшой генератор для своих нужд. Не думал, что этот генератор со временем вырастит в это.
Вы молодец!
Хоть тут справедливо сетуют на ненужность и обречённость подобного проекта, мне нравится, что человек просто взял и написал для себя что-то такое.
Сами мы пытаемся слезть в ObjC на Xamarin/C#/F#, сил больше нет с динамической типизацией.
Хоть тут справедливо сетуют на ненужность и обречённость подобного проекта, мне нравится, что человек просто взял и написал для себя что-то такое.
Сами мы пытаемся слезть в ObjC на Xamarin/C#/F#, сил больше нет с динамической типизацией.
Спасибо!
Да, динамическая типизация — это одна из главных проблем Objective-C. Сильно увеличивает количество ошибок.
В Objective-C она не совсем динамическая, правда, но это мало от чего спасает.
Да, динамическая типизация — это одна из главных проблем Objective-C. Сильно увеличивает количество ошибок.
В Objective-C она не совсем динамическая, правда, но это мало от чего спасает.
Ну, формально она там даже статическая, но да, толку мало.
Она там называется утиная типизация — странный гидрид между статической и динамической.
это одна из главных проблем Objective-C
Это одна из главных особенностей языка и его рантайма. Это просто прекрасная особенность. Вот именно про это слышать очень странно. Громоздкий и избыточный синтаксис — да, на каждом шагу новички плачут. У меня такое ощущение, что вам просто не хватает опыта.
Подобные вещи еще принято слышать в сторону былого NSAutoreleasePool — я и сам плевался от этой штуки. Но достаточно понять, как оно работает, и понимаешь, что это прекрасная штука.
Дженерики — да, типизированные структуры данных очень бы не помешали языку, но тут, наверное, ничего не поделаешь. Хотя по прошествии годов разработки конкретно на obj-C меня это перестало беспокоить.
Более того, я постоянно переключаюсь на C# и меня не покидает чувство, что хорошо бы, чтобы С# в некоторых моментах работал так же. Хотя сейчас уже больше в плане архитектуры самих SDK — всякие GCD и NSRunLoop чертовски крутые штуки рядом с непредсказуемыми ThreadPool и всякими асинхронными операциями, которые на него кидают колбэки. Асинхронное программирование на Cocoa это просто сказка. Хотя async/await конечно все равно высший пилотаж.
Однако, иногда имена параметров излишни, поэтому в Objective-D их можно опустить.
Это не работает. Именованные параметры есть и в питоне, и в шарпе, и вообще много где. Но если их можно опускать, их будут опускать.
В Objective-C это в общем-то не именованные параметры (функции там сишные, в Си такой фичи нет), а часть синтаксиса сообщений. Обязательная, естественно. Имена невозможно опустить, поэтому приходится их продумывать. В итоге средний код на Objective-C читается прекрасно с минимальной подготовкой читающего. Огромное влияние на популярность языка оказывает то, что я могу за секунды нагуглить пример, понять его и переделать под свои нужды. Двадцать первый век же, никто не читает документацию. А так код сам себя документирует достаточно успешно.
Для С++, кстати, есть Cocos-2dx. Но он откровенно отстает от оригинала.
Я думаю, что плохой программист на любом языке напишет плохой код. Он и в Objective-C назовет параметры x, y, z. Мне кажется, что лучше все таки ориентироваться на хороших программистов, которые укажут что это, если это непонятно из контекста. А то в Java, например, приходится комментарий писать рядом или делать билдеры для сложных функций.
Открою вам один маленький секрет: в Objective-C можно опускать часть имен сообщений.
Вот это будет работать. Только зачем?
-(void)makeMeHappy:(NSString*)name :(NSNumber*)number :(NSData*)data;
Вот это будет работать. Только зачем?
Это вы их опускаете в декларации метода. Так делать не нужно, разумеется. Потому что потом вы уже не сможете указать имена при вызове. Просто иногда имена параметров при вызове очень полезны, а иногда и так все очевидно, и можно обойтись без них.
Вы не опустили часть имени сообщения.
Вы просто определили makeMeHappy:::
Через некоторое время глядя на makeMeHappy::: вы сами не поймете, что делает вас счастливым.
Вы просто определили makeMeHappy:::
Через некоторое время глядя на makeMeHappy::: вы сами не поймете, что делает вас счастливым.
Огромное влияние на популярность языка оказывает
Огромное влияние на популярность языка оказывает существование кое-какой мобильной платформы. Остальное — ничтожно по сравнению с этим)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Objective-D — альтернатива или дополнение к Objective-C