Да потому что просто невозможно читать миллиарды килотонн текста на каждом шагу. Ваш комментарий, к примеру, занимает целый экран и при этом сложен для чтения, так как в нем сложно найти начало следующего параграфа — нет индентации и/или пустых линий.
Это не «ненавистью к чтению», это нелюбовь к избыточности.
При выборе приложения из нескольких вариантов я не хочу увидеть на их сайтах по стене текста, повествущих о создании программы с момента зарождения компании до прошлого четверга. Я хочу увидеть пару скриншотов, краткое описание и список основных возможностей и отличительных черт.
То же самое со статьями. Монументальный труд в 10.000 слов в один присест не осилит никто. Разделение на части и разбавление статьи картинками упрощает ее визуальне восприятие, становится проще ориентироваться в статье и читать ее бегло, концентрируясь на основных высказываниях.
Проблема заключается в невероятном потоке информации, с которым мы сталкиваемся каждый день, большая часть из которой не является принципиально новой.
public class Person {
private String name;
private int age;
public Person(String name, int age) {
this.name = name;
this.age = age;
}
public String getName() {
return this.name;
}
public int getAge() {
return this.age;
}
public equals(Person other) {
return other.name.equals(this.name) &&
other.age == this.age;
}
@Override
public String toString() {
return "Person(" + name + ", " + Integer.toString(age) + ")";
}
@Override
public int hashCode() {
int hash = 1;
hash = hash * 31 + name.hashCode();
hash = hash * 42 + age;
return hash;
}
public Person copy() {
return this;
}
public Person copy(String name) {
return new Person(name, this.age);
}
public Person copy(int age) {
return new Person(this.name, age);
}
public Person copy(String name, int age) {
if (name.equals(this.name) &&
age == this.age) {
// prevent new non-uniq object of immutable
// data structure from being created
return this;
} else {
return new Person(name, age);
}
}
}
// не знаю как вы, а я вспотел и почувствовал "глубокое внутреннее удовлетворение от продуктивно проведенного рабочего дня"
// ...чтобый прийти на следующий день, проверить что нигде не накосячил и обложить это все тонной тестов.
Так вот, синтаксический сахар, это когда:
// можно так
x = x + 1
// а можно так
x += 1
А case class'ы и другие фичи Scala — это уже «конструкции языка».
В последних версиях Scala такой финт ушами по умолчанию запрещен, так как может создавать неодназначность синтаксиса. Создатели и разработчики языка тоже понимают, что сложностью языка надо как-то управлять.
Использование точки предпочтительнее, но если прямо совсем не в моготу можно добавить импорт:
1. Конечно он сложный по сравнению с make. Ведь описание сборки происходит с помощью DSL на полноценной Scala.
2. Как он может быть неполноценным по сравнению с make? Ведь описание сборки происходит с помощью DSL на полноценной Scala.
Таски на Scala гораздо более удобные чем make, потому что каждый таск возвращает какое-то значение (функциональщина же), что позволяет гибко комбинировать их.
При этом sbt сам построит древо зависимостей, определит независимые таски и запустит их параллельно, увеличив скорость сборки проекта в разы (а то и на порядок).
Да, return действительно можно опустить, пропустил этот момент, а вот с типами все несколько хитрее — тип можно опустить только если он очевиден из контекста, присвоить такую анонимную функцию переменной без явного определения типа не получится.
Да, согласен. То же самое с if и другими управляющими конструкциями. Очень странное решение, учитывая функциональные возможности языка, так как это означает, что невозможно обходится только неизменяемыми переменными. Да и необходимость в явном return раздражает (:
Затем что язык только-только вышел и толпа разработчиков, которые последние 5-6 лет программировали на Objective-C и привыкли делать вещи определенным образом, полезла изучать его и выдавать статьи на-гора, используя Swift не столько как новый язык со своими подходами, сколько как большую кучу синтаксического сахара для Objective-C.
Поэтому в ближайшие несколько месяцев (если не лет) нас ждет огромная куча статей с «плохими практиками программирования на Swift».
На самом деле у Swift'а несколько странный синтаксис, поначалу он показался мне очень похожим на Scala, но если Scala это смесь объектно-ориентированной и фунациональной парадигм с уклоном в функциональную, то Swift выглядит как смесь функциональной и процедурной (ну и капельку объектно-ориентированной тоже) с уклоном в процедурную.
Те же примеры на Scala:
// возвращаемый тип функции выводится автоматически
// последнее выражения функции является возвращаемым значением
def increment(value: Int) = value + 1
// нижнее подчеркивание обозначает, что надо сохранить в переменную функцию, а не возвращаемое ей значение
// (это связано с тем, что функция в Scala может быть вызвана без скобок)
val functionAlias = increment _
val incrementer = (x: Int) => x + 1
def generateIncrementer(step: Int)(value: Int) = value + step
val addTen = generateIncrementer(10) _
addTen(15) // 25
Так как Swift поддерживает функции высшего порядка, использования постфиксного синтаксиса для определения возвращаемого типа позволяет сделать синтаксис более однородным.
Объявление функции:
func increment(value: Int) -> Int {
return value + 1
}
Объявление переменной, которая хранит функцию отображающую целочисленные значения в целочисленные значения:
let functionAlias: (Int) -> Int = increment
Обявление анонимной функции:
let incrementer: (Int) -> Int = { (x: Int) -> Int in return x + 1 }
Объявление функции, которая возвращает другую функцию:
func generateIncrementer(step: Int) -> (Int) -> Int {
return { (value: Int) -> Int in return value + step }
}
let addTen = generateIncrementer(10)
addTen(15) // 25
Зачем объявлять managedModel через вспомогательную переменную?
//Managed Model
var _managedModel: NSManagedObjectModel?
var managedModel: NSManagedObjectModel{
if !_managedModel{
_managedModel = NSManagedObjectModel.mergedModelFromBundles(nil)
}
return _managedModel!
}
Разве нельзя сделать как-то так:
@lazy var managedModel = NSManagedObjectModel.mergedModelFromBundles(nil)
Это не «ненавистью к чтению», это нелюбовь к избыточности.
При выборе приложения из нескольких вариантов я не хочу увидеть на их сайтах по стене текста, повествущих о создании программы с момента зарождения компании до прошлого четверга. Я хочу увидеть пару скриншотов, краткое описание и список основных возможностей и отличительных черт.
То же самое со статьями. Монументальный труд в 10.000 слов в один присест не осилит никто. Разделение на части и разбавление статьи картинками упрощает ее визуальне восприятие, становится проще ориентироваться в статье и читать ее бегло, концентрируясь на основных высказываниях.
Проблема заключается в невероятном потоке информации, с которым мы сталкиваемся каждый день, большая часть из которой не является принципиально новой.
И будут созданы все возможные комбинации путей:
«Эквивалентный» код в Java:
Так вот, синтаксический сахар, это когда:
А case class'ы и другие фичи Scala — это уже «конструкции языка».
Использование точки предпочтительнее, но если прямо совсем не в моготу можно добавить импорт:
2. Как он может быть неполноценным по сравнению с make? Ведь описание сборки происходит с помощью DSL на полноценной Scala.
Таски на Scala гораздо более удобные чем make, потому что каждый таск возвращает какое-то значение (функциональщина же), что позволяет гибко комбинировать их.
При этом sbt сам построит древо зависимостей, определит независимые таски и запустит их параллельно, увеличив скорость сборки проекта в разы (а то и на порядок).
returnдействительно можно опустить, пропустил этот момент, а вот с типами все несколько хитрее — тип можно опустить только если он очевиден из контекста, присвоить такую анонимную функцию переменной без явного определения типа не получится.ifи другими управляющими конструкциями. Очень странное решение, учитывая функциональные возможности языка, так как это означает, что невозможно обходится только неизменяемыми переменными. Да и необходимость в явномreturnраздражает (:Особенно в анонимных функциях, это ужас какой-то:
Поэтому в ближайшие несколько месяцев (если не лет) нас ждет огромная куча статей с «плохими практиками программирования на Swift».
Те же примеры на Scala:
Объявление функции:
Объявление переменной, которая хранит функцию отображающую целочисленные значения в целочисленные значения:
Обявление анонимной функции:
Объявление функции, которая возвращает другую функцию:
managedModelчерез вспомогательную переменную?Разве нельзя сделать как-то так:
То же самое касается всех схожих участков кода.