Мне кажется, что вы неверно поняли посыл моего комментария.
Я не просил вас писать сухой текст. Я просил вас выбирать формулировки, не противоречащие логике вашего повествования.
Смотрите, у вас есть некий опыт работы с Kotlin и Java. Вы, основываясь на нем, поняли, что есть много случаев, когда Kotlin предпочтительнее Java и хотите поделиться этой мыслью с другими людьми, чтобы обратить их внимание на этот язык и, возможно, мотивировать на его изучение.
Это то, что я увидел в Вашем тексте, исходя из вывода, тезисов, вступления.
Если коротко:
Вы обращаете внимание читателя на возросшую популярность языка.
Делитесь личным опытом, таким, чтобы читатели, которые являются основной вашей аудиторией(т.е. те, кто не писал на Kotlin) почувствовали, что они находятся в положении близком к Вашему.
Перечисляете характеристики языка, которые наиболее вам понравились и приводите примеры.
Делаете заключение.
И, все бы было хорошо, если бы не маленькая ошибка:
В какой-то момент вы увлекаетесь и переходите на категоричные заявления, вместо того, чтобы продолжить делиться своим личным опытом.
И более того, допускаете логическую ошибку в своих суждениях, о чем я написал выше.
А так же вводите в заблуждение тех, кто не пишет ни на Kotlin ни на Java, т.к. подразумеваете, что знание Kotlin более полезно (возможно мне показалось, что эта мысль есть в тексте, если что — поправьте), а вот к этому возникают серьезные вопросы, ибо огромная часть нашего кода все еще написана на Java и ее знание для разработки под Android (даже если она не профессиональная, вдруг у вас баг в библиотеке, которую вы используете) — очень важно.
Я дико извиняюсь, что сейчас достанется именно вашему посту, но он стал последней каплей в чашу моего терпения, касательно некоторого множества статей с определенной структурой.
Все написанное ниже является сугубо моим мнением.
В последнее время я наблюдаю в нашей области просто катастрофическое число статей и заметок, которые, на мой взгляд, обладают серьезными ошибками в самой их структуре и логике. В частности:
Нельзя доказывать общие утверждения частными примерами.
Если вы берете некоторую систему или совокупность систем и их зависимостей и утверждаете, что для них выполняется правило X, то без рассмотрения всех вариантов, которые вы затрагиваете формулировкой вашего правила, вы не можете это доказать.
Вы можете доказать примерами неверность тезиса, пример:
Тезис: Java лучше Kotlin.
*Ваш пример с моделью, и тем, что она короче и читается лучше.*
Таким образом мы доказали, что тезис Java лучше Kotlin неверен, поскольку Kotlin лучше Java в конкретном случае, представленном выше.
Если же мы говорим:
Почему же Котлин оказался лучше Джавы?
То, чтобы доказать верность этого утверждения, нужно перебрать все варианты возможного использования Котлина и Джавы, ибо если хоть в одном случае окажется, что Java лучше Kotlin, то утверждение неверно.
Эту формулировку можно спокойно заменить на:
«Мне понравился Kotlin, потому что:»
«Использование Kotlin дает преимущество в ряде случаев, в том числе следующих:»
В общем, сузить область применимости вашего тезиса, до тех случаев где он действительно верен.
P.S.
Я вот думаю, статью на эту тему написать, что ли.
Мне, например, в период когда я занимался своими проектами хватало убедительности, чтобы продавать даже не конечный продукт, а всего лишь его идею и готовность его реализовывать.
И я бы не сказал, что это не нужный инженеру навык. В конце концов мы продаем компаниям свое время и умения, и способность правильно «впарить» их на этапах резюме, собеседования и правильно индексировать их стоимость в зависимости от своего личностного роста — очень пригождается.
Единственное что — обучение тут действительно не короткое. 10 тысяч часов, все дела.
Видимо у всех разный опыт.
За пару лет в вузе, на большинстве дисциплин я только и делал, что собирал треугольные колеса.
Более того, попытки возразить, что колеса бывают и круглыми, или, о боже, собрать велосипед с ними — приводят к санкциям со стороны преподавательского состава.
Не собираюсь делать излишних обобщений, поэтому уточню, что примерно 10% преподавателей демонстрировали другой подход и что речь идет только о СПБГЭТУ (ЛЭТИ).
PS
На правах ИМХО: для расширения личного кругозора, как ни странно, лучше всего делать что-то самому. Читать статьи на незнакомые темы, проходить курсы, которых навалом вокруг, общаться с людьми на профильных ресурсах или IRL, etc.
Потому что без этого(что с вузом, что без вузa) кругозор расширяется весьма неохотно.
А, да, tryToOpen — является частью интерфейса OpenableByKey, который является расширением общего Openable.
Ну, т.е. мы получаем, что есть объекты, которые могут быть открыты ключом, каждый класс таких объектов как-то по-своему реализует взаимодействие с ключами в зависимости от атрибутов, а потом передает коллбэк, в котором мы можем узнать состояние объекта и что-то с ним сделать…
Ведь когда я вставляю ключ в дверь, мне пофигу на механизм внутри, но я пытаюсь ее открыть этим ключом, а затем получаю результат, и анализирую что с ним сделать дальше. И мне нужны только ключ и дверь, количество оборотов обычно определено не мной, а состоянием двери в текущий момент (насколько ее в прошлый раз закрыли я могу знать, а могу и не знать)
Для начала — научите людей использовать поисковики. In my honest opinion, это один из наиболее критичных скиллов на данном этапе развития общества, но, при этом, что в вузе, что в школе, что на работе, я постоянно встречаю людей, которые просто не умеют работать с тем объемом информации, который находится у них под рукой и не могут быстро ее найти и применить.
Полугодичный курс в университете в первом семестре, с названием «Гуглим правильно» и аналогичный предмет для школьников был бы очень полезен.
Да, в дополнение комментарию выше — я собирался выложить ее в open source, вдруг будет интерес. К сожалению, я пока этого не делал ранее и изучаю, что для этого собственно нужно и как вообще все это происходит. Посмотреть что из себя представляет последняя версия можно здесь (bitbucket). Как видите, там пока не очень хорошо все оформлено=)
Я собираюсь выпустить библиотеку, как только разберусь со всеми тонкостями собственно ее выкладывания, лицензий и прочего, и, возможно, к этому моменту успею разобраться с версией под Marshmallow.
Я не просил вас писать сухой текст. Я просил вас выбирать формулировки, не противоречащие логике вашего повествования.
Смотрите, у вас есть некий опыт работы с Kotlin и Java. Вы, основываясь на нем, поняли, что есть много случаев, когда Kotlin предпочтительнее Java и хотите поделиться этой мыслью с другими людьми, чтобы обратить их внимание на этот язык и, возможно, мотивировать на его изучение.
Это то, что я увидел в Вашем тексте, исходя из вывода, тезисов, вступления.
Если коротко:
Вы обращаете внимание читателя на возросшую популярность языка.
Делитесь личным опытом, таким, чтобы читатели, которые являются основной вашей аудиторией(т.е. те, кто не писал на Kotlin) почувствовали, что они находятся в положении близком к Вашему.
Перечисляете характеристики языка, которые наиболее вам понравились и приводите примеры.
Делаете заключение.
И, все бы было хорошо, если бы не маленькая ошибка:
В какой-то момент вы увлекаетесь и переходите на категоричные заявления, вместо того, чтобы продолжить делиться своим личным опытом.
И более того, допускаете логическую ошибку в своих суждениях, о чем я написал выше.
А так же вводите в заблуждение тех, кто не пишет ни на Kotlin ни на Java, т.к. подразумеваете, что знание Kotlin более полезно (возможно мне показалось, что эта мысль есть в тексте, если что — поправьте), а вот к этому возникают серьезные вопросы, ибо огромная часть нашего кода все еще написана на Java и ее знание для разработки под Android (даже если она не профессиональная, вдруг у вас баг в библиотеке, которую вы используете) — очень важно.
Все написанное ниже является сугубо моим мнением.
В последнее время я наблюдаю в нашей области просто катастрофическое число статей и заметок, которые, на мой взгляд, обладают серьезными ошибками в самой их структуре и логике. В частности:
Нельзя доказывать общие утверждения частными примерами.
Если вы берете некоторую систему или совокупность систем и их зависимостей и утверждаете, что для них выполняется правило X, то без рассмотрения всех вариантов, которые вы затрагиваете формулировкой вашего правила, вы не можете это доказать.
Вы можете доказать примерами неверность тезиса, пример:
Тезис: Java лучше Kotlin.
*Ваш пример с моделью, и тем, что она короче и читается лучше.*
Таким образом мы доказали, что тезис Java лучше Kotlin неверен, поскольку Kotlin лучше Java в конкретном случае, представленном выше.
Если же мы говорим:
Почему же Котлин оказался лучше Джавы?
То, чтобы доказать верность этого утверждения, нужно перебрать все варианты возможного использования Котлина и Джавы, ибо если хоть в одном случае окажется, что Java лучше Kotlin, то утверждение неверно.
Эту формулировку можно спокойно заменить на:
«Мне понравился Kotlin, потому что:»
«Использование Kotlin дает преимущество в ряде случаев, в том числе следующих:»
В общем, сузить область применимости вашего тезиса, до тех случаев где он действительно верен.
P.S.
Я вот думаю, статью на эту тему написать, что ли.
Мне, например, в период когда я занимался своими проектами хватало убедительности, чтобы продавать даже не конечный продукт, а всего лишь его идею и готовность его реализовывать.
И я бы не сказал, что это не нужный инженеру навык. В конце концов мы продаем компаниям свое время и умения, и способность правильно «впарить» их на этапах резюме, собеседования и правильно индексировать их стоимость в зависимости от своего личностного роста — очень пригождается.
Единственное что — обучение тут действительно не короткое. 10 тысяч часов, все дела.
За пару лет в вузе, на большинстве дисциплин я только и делал, что собирал треугольные колеса.
Более того, попытки возразить, что колеса бывают и круглыми, или, о боже, собрать велосипед с ними — приводят к санкциям со стороны преподавательского состава.
Не собираюсь делать излишних обобщений, поэтому уточню, что примерно 10% преподавателей демонстрировали другой подход и что речь идет только о СПБГЭТУ (ЛЭТИ).
PS
На правах ИМХО: для расширения личного кругозора, как ни странно, лучше всего делать что-то самому. Читать статьи на незнакомые темы, проходить курсы, которых навалом вокруг, общаться с людьми на профильных ресурсах или IRL, etc.
Потому что без этого(что с вузом, что без вузa) кругозор расширяется весьма неохотно.
Ну, т.е. мы получаем, что есть объекты, которые могут быть открыты ключом, каждый класс таких объектов как-то по-своему реализует взаимодействие с ключами в зависимости от атрибутов, а потом передает коллбэк, в котором мы можем узнать состояние объекта и что-то с ним сделать…
Ведь когда я вставляю ключ в дверь, мне пофигу на механизм внутри, но я пытаюсь ее открыть этим ключом, а затем получаю результат, и анализирую что с ним сделать дальше. И мне нужны только ключ и дверь, количество оборотов обычно определено не мной, а состоянием двери в текущий момент (насколько ее в прошлый раз закрыли я могу знать, а могу и не знать)
Для начала — научите людей использовать поисковики. In my honest opinion, это один из наиболее критичных скиллов на данном этапе развития общества, но, при этом, что в вузе, что в школе, что на работе, я постоянно встречаю людей, которые просто не умеют работать с тем объемом информации, который находится у них под рукой и не могут быстро ее найти и применить.
Полугодичный курс в университете в первом семестре, с названием «Гуглим правильно» и аналогичный предмет для школьников был бы очень полезен.