Автор статьи не хочет явно типы писать, как дженерики решают эту проблему?
Вероятно он хочет решать не эту проблему, потому что эта проблема уже решена в js
Самое начало статьи:
При написании алгоритмов зачастую возникает ситуация, когда какая-то функция нуждается в вызове с тем же количеством аргументов, но с не совпадающими типами. Решаем.
И приводится решение этой задачи 2-мя примерами на C++ и JS, после чего промежуточный вывод «Очевидно, что код на javascript является более удачным.»
Дальше идет, собственно, и сама суть:
Другими словами, когда нужна максимальная производительность и памяти хватает более предпочтительным является статический подход.Но при выборе, допустим, языка C++, теряется читаемость кода. Ведь на каждый чих приходится указывать тип, с которым вызывается функция.
Соответственно вместо написания своего языка, обозначенную проблему (писать максимально производительный код без потери читаемости и без необходимости писать тип на «каждый чих») можно решать другим путем, и я лишь дополнил наглядным примером, что получившийся код, например, на swift не сильно сложнее варианта на js
Но раз речь зашла про не указывать типы явно, то например, в swift тоже не обязательно описать типы явно, они выводятся из контекста, а для функций можно использовать дженерики, таким образом получится гибрит, когда ни один тип явно не задан и код не теряет в читаемости (тут http://www.runswiftlang.com/ можно поэкспериментировать онлайн)
func f<T>(fn: T -> Void, _ item: T) {
fn(item)
}
func a<T>(item: T) {
print("item type: \(item.dynamicType)") // аналог typeof item
}
let a1 = 1
let a2 = 1.0
let a3 = "Alexey"
f(a, a1) // item type: Int
f(a, a2) // item type: Double
f(a, a3) // item type: String
let z = "zzz"
let zz = ["key1": z]
f(a, zz) // item type: Dictionary
var b1 = 1
var b2 = "str"
b1 = b2 // error: cannot assign value of type 'String' to type 'Int'
Вот вы говорите, что трудно такой сделать и всё равно будет зернистость или артефакты.
Но вот вот пример, который я выше приводил: http://bellard.org/bpg/animation.html
Он уже эффективно жмет между кадрами, хранит не просто кадры подряд и т.д. и работает как обычный картиночный формат, это не видео, то есть он мог бы заменил гифки для ежедневного использования
Если речь о том, что трудно улучшить гиф, придумывая сложные кодеры и т.д., то да, но зачем это нужно, когда уже придумано и реализовано?
Я говорил не про «ещё один формат анимации», а про то, что сделать эффективный анигиф можно, но это будет дорого, (но, скорее всего, всё равно зернисто).
Не надо ничего делать, уже есть формат, который делает не зернисто и даже поддерживается браузерами
bpg, flif или webp не контейнер для видео и не «еще один формат для анимации», это варианты на замену jpeg+png+gif в одном лице
Например, bpg кодирует картинку с помощью x265 и результат получается лучше чем у webp, который использует кодек VP9, но webp поддерживается, bpg нет. В обоих случаях на выходе получается картинка, которая весит меньше jpg при том же качестве, но так как поддерживается анимация, то можно создавать анимацию намного лучшего качества и меньшим весом чем гиф или apng
И так как это не видео, не требуется html5 тэги чтобы его вставить, достаточно написать:
И сразу же увидим результат в браузере где поддерживает webp (по сути любой кроме edge, так как в safari будет с октября, в firefox тоже скоро):
Осталось дождаться не формата, а эффективного инструмента для конвертации mp4 в webp, который бы работал с этим форматом
2.7mb webp vs 11mb gif
Вот webp 2.8 метров из mp4 файла (delay между кадрами отличается, это потому что я не старался подобрать идеально, эта проблема решается автоматизацией софта)
И gif 11 метров из того же файла
Плохие исходники под рукой были, но идея думаю ясна
bpg, flif, webp используют специальный и очень продвинутый кодер при сжатии анимации
У bpg, например, используется x265 кодек http://bellard.org/bpg/animation.html
$ node prom.js
Бенчмарк промисов выполнен!
Время выполнения 14.426 сек.
$ node prom.js
Бенчмарк промисов выполнен!
Время выполнения 15.856 сек.
$ node -v
v6.5.0
Второй вариант:
$ node prom.js
Бенчмарк промисов выполнен!
Время выполнения 2.7 сек.
$ node prom.js
Бенчмарк промисов выполнен!
Время выполнения 10.404 сек.
Чтобы заменить чтото простое как гифка, нужно тоже что-то такое же простое в плане сохранения/добавления, соответственно видео форматы не подходят
Хоть и не лучший вариант, но подходит webp который умеет анимацию и кодирует (всмысле может перекодировать или создавать) «гифки» тем же VP9 что и в webm. Подошли бы и bpg с flif, но на данный момент только у webp есть более менее массовая поддержка браузерами (60-70%)
И начиная с ios 10 и macOS в safari будет поддерживаться webp (в бетах уже работает)
Скорее всего это отсылка к оригинальной презентации, что-то вроде «писать на свифте так же просто как на питоне, а результат в 3.9 раз лучше»
time go build -o test-go go/test.go
0.55 real 0.57 user 0.12 sys
time swiftc -O -o test-swift swift/test.swift
0.35 real 0.30 user 0.03 sys
time c++ -O3 -o test-c cplusplus/test.cc
0.56 real 0.51 user 0.04 sys
time ghc -O3 -o test-hask haskell/test.hs
Linking test-hask ...
0.46 real 0.34 user 0.10 sys
Да, теперь понятно. Есть такое, если это конец строки, просто никогда не сталкивался на практике, так как выделяю до конца строки привычным «shift + cmd + стрелка вправо», а когда по словам перемещаюсь, никогда не было ситуации, чтобы нужно было не к параметрам перейти, а к концу скобок (стираются ненужные переднии скобки через fn + ←)
Самое начало статьи:
И приводится решение этой задачи 2-мя примерами на C++ и JS, после чего промежуточный вывод «Очевидно, что код на javascript является более удачным.»
Дальше идет, собственно, и сама суть:
Соответственно вместо написания своего языка, обозначенную проблему (писать максимально производительный код без потери читаемости и без необходимости писать тип на «каждый чих») можно решать другим путем, и я лишь дополнил наглядным примером, что получившийся код, например, на swift не сильно сложнее варианта на js
Но раз речь зашла про не указывать типы явно, то например, в swift тоже не обязательно описать типы явно, они выводятся из контекста, а для функций можно использовать дженерики, таким образом получится гибрит, когда ни один тип явно не задан и код не теряет в читаемости (тут http://www.runswiftlang.com/ можно поэкспериментировать онлайн)
Но вот вот пример, который я выше приводил:
http://bellard.org/bpg/animation.html
Он уже эффективно жмет между кадрами, хранит не просто кадры подряд и т.д. и работает как обычный картиночный формат, это не видео, то есть он мог бы заменил гифки для ежедневного использования
Если речь о том, что трудно улучшить гиф, придумывая сложные кодеры и т.д., то да, но зачем это нужно, когда уже придумано и реализовано?
Не надо ничего делать, уже есть формат, который делает не зернисто и даже поддерживается браузерами
bpg, flif или webp не контейнер для видео и не «еще один формат для анимации», это варианты на замену jpeg+png+gif в одном лице
Например, bpg кодирует картинку с помощью x265 и результат получается лучше чем у webp, который использует кодек VP9, но webp поддерживается, bpg нет. В обоих случаях на выходе получается картинка, которая весит меньше jpg при том же качестве, но так как поддерживается анимация, то можно создавать анимацию намного лучшего качества и меньшим весом чем гиф или apng
И так как это не видео, не требуется html5 тэги чтобы его вставить, достаточно написать:
И сразу же увидим результат в браузере где поддерживает webp (по сути любой кроме edge, так как в safari будет с октября, в firefox тоже скоро):
Осталось дождаться не формата, а эффективного инструмента для конвертации mp4 в webp, который бы работал с этим форматом
И gif 11 метров из того же файла
Плохие исходники под рукой были, но идея думаю ясна
У bpg, например, используется x265 кодек
http://bellard.org/bpg/animation.html
Второй вариант:
Хоть и не лучший вариант, но подходит webp который умеет анимацию и кодирует (всмысле может перекодировать или создавать) «гифки» тем же VP9 что и в webm. Подошли бы и bpg с flif, но на данный момент только у webp есть более менее массовая поддержка браузерами (60-70%)
И начиная с ios 10 и macOS в safari будет поддерживаться webp (в бетах уже работает)
node v6.3.1: 26.3 сек
node v6.5.0: 16.5 сек
Вообще на node 6.5.0 тест из статьи выдает такие результаты:
В js, кстати, можно что-то аналогичное делать теперь:
Список проблем с ie10-11 (и других браузеров) и их решения:
https://github.com/philipwalton/flexbugs#flexbugs
Плагин для postcss который сам исправит известные проблемы:
https://github.com/luisrudge/postcss-flexbugs-fixes
https://github.com/archana-s/postcss-flexbox
На счет this и new тоже не понял почему так, так как с приходом es6 классов снова используется и this и new
shift + alt + стрелки — выделяет нормально, останавливается на скобках, запятых, двоеточиях и т.д.
shift + cmd + стрелка вправо — выделить до конца строки
В статье всё сумбурно и не содержится полезной информации, только запутывает
Чтобы упорядочить свои знания, стоит проглядеть хотя бы эти ссылки:
http://uppod.ru/help/html5/
http://uppod.ru/help#video
https://github.com/anselmh/object-fit