Да, стратегия в пределе оптимальна, но результат не столь тривиален, как сама стратегия. Доказательство можно найти в Eugene Curtin and Max Warshauer, The locker puzzle, The Mathematical Intelligencer, 28.1.
Мне кажется, есть несколько причин делать технические переводы. Скажем, вы говорите/читаете по-немецки, и вам попалось что-то очень интересное. Понятное дело, вы многим окажете замечательную услугу. Или же текст написан очень живим языком, который хочется передать людям, владеющим исключительно техническим английским (до сих пор не видел близкого к совершенству перевода why's (poignant) Guide to Ruby). Возможно, имеет смысл переводить сложные по смыслу статьи, где слабое знание языка отвлекает от сути (большинство статей о настоящем таком функциональном программировании).
С другой стороны, большинство разработчиков владеют техническим английским достаточно хорошо, чтобы перевод «средней» англоязычной статьи имел под собой серьезные основания.
Как только миру только представили Swift, разработчики всех мастей стали дружно учиться на нем разговаривать. В этом плане статьи Тони, несомненно, читать приятно, полезно и нужно (особенно разработчикам, имеющим малое представление о функциональном программировании).
При всем уважении, перевод читается тяжело. Попробую аргументировать:
Встречаются странные, местами комичные варианты перевода: response превратился в ответная реакция сети. Или же вот: многократных if-let предложений.
Иногда искажается смысл: … случаев (case) перечисления (enum) … У перечислений бывают значения (или хотя бы варианты), а случаи бывают у операторов ветвления.
Пропущены некоторые вещи. В оригинале есть фраза: «First, let’s look at the Maybe Monad which is similar to Swift optionals.» Собственно, без нее упоминать монады совершенно не имеет смысла (информация важна для людей с опытом функционального программирования, которые впервые знакомятся с языком Swift).
Если беретесь переводить статью с большим количеством кода, комментарии тоже нужно переводить.
С некоторым словами (чаще всего терминами) совсем беда. Встречаются все из перечисленных вариантов.
Используем английский термин, русский пишем в скобках: … в своих values (значениях).
Не переводим вообще: options парсинге, используя Applicative.
Используем русский термин, английский пишем в скобках: функторов (Functors).
Местами просто дословный перевод, «завернутый» в кавычки (а не обернутый).
Есть еще «модель, подтверждающая протокол» (реализующая, видимо), «входные переменные» вместо параметров и многое другое.
Может показаться, что технический перевод — это просто. На самом деле, хороший технический перевод — это когда ты дочитал статью до конца и с удивлением обнаружил ссылку на первоисточник.
Кто-то скажет, что я придираюсь… Главное, чтобы вы не подумали, что я наезжаю. На самом деле, очень мало людей имеют желание и силы что-то переводить. Так что я всячески поддерживаю ваше начинание. Просто если уж беретесь, относитесь к делу серьезно и не забывайте о читателе.
P. S. Если моя критика не лишила вас энтузиазма, можете перевести вторую и третью части.
Да, спасибо, такой источник нам известен. Собственно, он полностью противоречит вашему заявлению о том, что во всех тестах Swift код разительно уступает Objective-C по производительности.
На самом деле, из перечисленных вами пунктов, имеют место только проблема с Xcode + сомнительные ошибки компиляции (противоречивых не встречал, но сообщения бывают, что называется, misleading). Гораздо большая неприятность — это то, что нет разумного способа собрать Swift библиотеку и использовать ее в приложении под iOS >= 7.0/7.1.
Интеграция с Objective-C кодом работает в свою очередь очень хорошо даже в больших проектах.
Приложение у вас очень симпатичное и «чистенько» смотрится. Ценник нормальный, не надо ориентироваться на российский рынок, который боится заплатить 66 рублей (ситуация все-таки улучшается). Я пару месяцев назад купил его, но в конечном итоге все равно использую Clear. Не могу точно описать, почему, но обычный список оказывается удобнее. С 9 локализациями убили — посмеялся от души.
Есть одна вещь, которая очень раздражает в iPhone версии: код в тексте статьи обрезается, для просмотра нужно на него кликнуть. Даже если там одна строчка. Что еще хуже, естественная реакция iOS-пользователя — потянуть код влево (ожидается горизонтальный скролл блока с кодом), что приводит к переключению на следующую статью. Ощущения неприятные.
Платить больше имеет смысл, когда имеется нечто, работающее лучше. Нормального 4G у мтс я не встречал, а 3G часто напоминает скоростью на пресловутый edge.
Я понял, что меня смутило. Дело в том, что WWDC и iOS 7 Tech Talks — это разные вещи. Если я правильно помню, Tech Talks решили провести впервые в этом году после феноменально быстрой продажи всех билетов на WWDC.
Текущий вид donation'a не исчезает даже после переустановки приложения. При повторной попытке пожертвования с тем же Apple Id мы денег не возьмем, а доступ к контенту откроем.
По поводу подобных подсказок — спасибо, подумаем. Про обычные пожертвования мне что-либо сказать тяжело. Формально это противоречит правилам Apple, насколько я понимаю.
С другой стороны, большинство разработчиков владеют техническим английским достаточно хорошо, чтобы перевод «средней» англоязычной статьи имел под собой серьезные основания.
Как только миру только представили Swift, разработчики всех мастей стали дружно учиться на нем разговаривать. В этом плане статьи Тони, несомненно, читать приятно, полезно и нужно (особенно разработчикам, имеющим малое представление о функциональном программировании).
При всем уважении, перевод читается тяжело. Попробую аргументировать:
Есть еще «модель, подтверждающая протокол» (реализующая, видимо), «входные переменные» вместо параметров и многое другое.
Может показаться, что технический перевод — это просто. На самом деле, хороший технический перевод — это когда ты дочитал статью до конца и с удивлением обнаружил ссылку на первоисточник.
Кто-то скажет, что я придираюсь… Главное, чтобы вы не подумали, что я наезжаю. На самом деле, очень мало людей имеют желание и силы что-то переводить. Так что я всячески поддерживаю ваше начинание. Просто если уж беретесь, относитесь к делу серьезно и не забывайте о читателе.
P. S. Если моя критика не лишила вас энтузиазма, можете перевести вторую и третью части.
На самом деле, из перечисленных вами пунктов, имеют место только проблема с Xcode + сомнительные ошибки компиляции (противоречивых не встречал, но сообщения бывают, что называется, misleading). Гораздо большая неприятность — это то, что нет разумного способа собрать Swift библиотеку и использовать ее в приложении под iOS >= 7.0/7.1.
Интеграция с Objective-C кодом работает в свою очередь очень хорошо даже в больших проектах.
UIButton— это какой-то новый стиль…По поводу подобных подсказок — спасибо, подумаем. Про обычные пожертвования мне что-либо сказать тяжело. Формально это противоречит правилам Apple, насколько я понимаю.