Причём разработку плееров под мобильники Adobe прекратил по собственной инициативе, в самый разгар бума мобил. Чем они руководствовались совершенное не ясно.
Adobe is allegedly set to sue Apple over changes in its iPhone software development kit, as the row over the lack of Flash support on the iPhone, iPod touch and iPad escalates.
Technology website IT World quotes sources close to Adobe as saying that they will be filing a lawsuit against Apple «within a few weeks». The software company is incensed at recent changes to the iPhone software development kit, which have banned the use of cross-compilers to build applications for the platform.
Adobe лицензировал исходники плеера производителям телефонов, телевизоров, приставок и прочих кофемолок с пылесосами. Удивительно, что исходники до сих пор не всплыли у пиратов.
Я не против markdown, для комментариев он прекрасен. Для статей нужно набивать руку и делать поправку на локальные баги площадок. Мне пока проще с HTML.
Я честно пытался сначала оформить эту свою статью через markdown, но потом сдался. Хотя, как можно заметить, никаких оформительских изысков там нет. Так как публикация была на Хабрахабре, баги его парсера игнорировать я не мог.
При всей любви к HTML, тексты размечать в Markdown сильно удобнее, а вся мощь HTML тут не нужна — скорее, избыточна.
Не соглашусь. При вёрстке в HTML результат предсказуем, а при вёрстке в markdown выстрелить может в любой момент. Причём на разных движках эти моменты разные.
Чтобы далеко не ходить, на Хабрахабре последовательность символов > 42. Foo будет отрендерена как, внимание:
Блок цитирования есть, «Foo» есть, а «42»… какое «42»?
Для сравнения GitHub:
Гораздо проще сразу писать в HTML, а не пытаться угадать как это отрендерится на этот раз. Markdown использую только для комментариев.
Лучшие качества: интересные задачи, современные технологии, адекватная зарплата, профессиональный рост, карьерный рост, отношения с коллегами, признание результатов труда, cвязь с топ-менеджментом, компания делает мир лучше.
Похоже на цитату из резюме вчерашнего студента. Там тоже «целеустремлённость», «стрессоустойчивость», «хорошая обучаемость». Опыта работы ещё нет, а хотя бы половину страницы чем-то забить надо.
В нашем рейтинге было около 40% — аутсорсинговых компаний и 60% — продуктовых.
Тут точно дефисы нужны?
доля продуктовых компаний растет с увеличением размера: среди небольших их 39%, а среди огромных уже 88%.
DNS, Лямода и Росатом это продуктовые компании? Серьёзно?
А ещё мы нарисовали крутые ачивки-медали
Что изображено на иконке соцпакета? Что-то из сантехники?
Аннотации в Java являются помечающей сущностью, и с точки зрения компилятора никак на выполняемый байткод не вляиют. То что куча фреймворков злоупотребляет этой особенностью и генерирует посредством аннотации байткод, ещё не означает, что так должен делать и javac тоже.
Я вам привёл ссылку на конкретную строку в исходниках javac, где аннотация очень значительно влияет на байткод с точки зрения компилятора.
Верно, эти причины философские.
Вновь отсылаю вас к исходникам, которые бесцеремонно попрают ваши философские воззрения.
А как это ещё назвать, если не поддержкой ключевых слов на уровне JVM?
Так и назвать, поддержкой final/volatile/etc. полей в классе.
Ключевые слова это свойство языка программирования. JVM не работает на уровне языков программирования, она работает на уровне класс-файлов. Вы смешиваете уровни абстракции.
В Котлине, к примеру, классы по умолчанию final и для того, чтобы сделать класс не final нужно использовать ключевое слово open:
By default, Kotlin classes are final: they can’t be inherited. To make a class inheritable, mark it with the open keyword.
По вашей логике в JVM с самой первой версии была поддержка ключевого слова open из тогда ещё не существовавшего языка программирования.
Напомню, что предполагаемая альтернатива новым ключевым словам — это использовать аннотации. И они как раз работать так же не будут, несмотря на то, что тоже могут включаться а класс-файл. Но нет механизма, согласно которому процессор аннотаций включал бы какие-нибудь биты.
Процессор аннотаций может перекорёжить весь класс как ему вздумается начиная с Java 6 как минимум (см. The Hacker’s Guide to Javac). В качестве живого примера см. Lombok.
Про использование аннотаций:
Нет никаких технических причин, по которым javac не мог бы обрабатывать определённые аннотации особым образом, устанавливать любые флаги и создавать любые аттрибуты какие разработчики сочтут нужными.
Естественно, что эти флаги и аттрибуты генерируются на основе ключевых слов в исходном тексте, но утверждать, что на уровне JVM есть «поддержка ключевых слов» — всё равно что называть системный блок компьютера «процессором».
Причём разработку плееров под мобильники Adobe прекратил по собственной инициативе, в самый разгар бума мобил. Чем они руководствовались совершенное не ясно.
Не всё так безоблачно было:
Тогда этот запрет вызвал большие бурления в интернетах и в конце концов он был отменён.
Adobe лицензировал исходники плеера производителям телефонов, телевизоров, приставок и прочих кофемолок с пылесосами. Удивительно, что исходники до сих пор не всплыли у пиратов.
Как я понял, главное при написании FizzBuzz — надёжно заблокировать выход из переговорки.
Потому, что ссылка на Хабрахабре это не аллея, а лабиринт.
Вот тот самый комментарий, адынадынадын1!: http://web.archive.org/web/20111112041138/http://habrahabr.ru/blogs/internet/118262/#comment_3854405
Я не против markdown, для комментариев он прекрасен. Для статей нужно набивать руку и делать поправку на локальные баги площадок. Мне пока проще с HTML.
Я честно пытался сначала оформить эту свою статью через markdown, но потом сдался. Хотя, как можно заметить, никаких оформительских изысков там нет. Так как публикация была на Хабрахабре, баги его парсера игнорировать я не мог.
То, что пока он работает я и сам заметил. Что со светлым будущим, будет там место HTML-разметке?
Дискуссию, наверное, стоит продолжить в посвящённой этому светлому будущему статье. Так будет больший охват заинтересованных лиц.
Не соглашусь. При вёрстке в HTML результат предсказуем, а при вёрстке в markdown выстрелить может в любой момент. Причём на разных движках эти моменты разные.
Чтобы далеко не ходить, на Хабрахабре последовательность символов
> 42. Fooбудет отрендерена как, внимание:Блок цитирования есть, «Foo» есть, а «42»… какое «42»?
Для сравнения GitHub:
Гораздо проще сразу писать в HTML, а не пытаться угадать как это отрендерится на этот раз. Markdown использую только для комментариев.
Я пару дней назад тегировал Boomburum в комментариях к анонсу этого чуда UX/UI-естроения. Пока ни ответа, ни привета. Надеюсь, что хотя бы эту статью удостоят ответа.
Похоже на цитату из резюме вчерашнего студента. Там тоже «целеустремлённость», «стрессоустойчивость», «хорошая обучаемость». Опыта работы ещё нет, а хотя бы половину страницы чем-то забить надо.
Тут точно дефисы нужны?
DNS, Лямода и Росатом это продуктовые компании? Серьёзно?
Что изображено на иконке соцпакета? Что-то из сантехники?
Так вы сюда в демагогии поупражняться пришли?
Так бы сразу и сказали. Демагогия у вас пока на троечку.
Я вам привёл ссылку на конкретную строку в исходниках
javac, где аннотация очень значительно влияет на байткод с точки зрения компилятора.Вновь отсылаю вас к исходникам, которые бесцеремонно попрают ваши философские воззрения.
Так и назвать, поддержкой final/volatile/etc. полей в классе.
Ключевые слова это свойство языка программирования. JVM не работает на уровне языков программирования, она работает на уровне класс-файлов. Вы смешиваете уровни абстракции.
В Котлине, к примеру, классы по умолчанию
finalи для того, чтобы сделать класс неfinalнужно использовать ключевое словоopen:По вашей логике в JVM с самой первой версии была поддержка ключевого слова
openиз тогда ещё не существовавшего языка программирования.Процессор аннотаций может перекорёжить весь класс как ему вздумается начиная с Java 6 как минимум (см. The Hacker’s Guide to Javac). В качестве живого примера см. Lombok.
Про использование аннотаций:
Нет никаких технических причин, по которым
javacне мог бы обрабатывать определённые аннотации особым образом, устанавливать любые флаги и создавать любые аттрибуты какие разработчики сочтут нужными.Пример: https://hg.openjdk.java.net/jdk8/jdk8/langtools/file/e9f118c2bd3c/src/share/classes/com/sun/tools/javac/comp/MemberEnter.java#l788
И комментарий оттуда:
ГК45-П-23БХ это же кварц?
Зачем их целых три штуки на одной плате?
Меня очень беспокоит фраза «Старый редактор доступен по ссылке, но скоро его поддержка прекратится.»
Очень не хотелось бы, чтобы в один прекрасный момент эта WYSIWYG-поделка осталась единственным способом редактирования статей.
Boomburum, вы же не будете удалять нормальный редактор?
На уровне class-файла final field это взведённый бит в соответствующем поле, а sealed type — аттрибут PermittedSubclasses.
Естественно, что эти флаги и аттрибуты генерируются на основе ключевых слов в исходном тексте, но утверждать, что на уровне JVM есть «поддержка ключевых слов» — всё равно что называть системный блок компьютера «процессором».
Вы о чём?
JVM не знает ни о каких ключевых словах. Ни о кастомных, ни о каких-либо других. Ключевые слова заканчиваются на уровне javac.
Любителей Lombok это не особо смущает.
Я бы предпочёл для этого аннотацию, по аналогии с
@Override. К ключевым словам-маркерам у меня идиосинкразия со времён Delphi.