Подскажите, пжлст, куда пойти поучится на английском . Изначально думал поступать на программу Internet Programming and Development AEC от John Abbott , но она покрыта EMPLOI-QUÉBEC , получить подтверждение от агента возможно, но с определёнными усилиями. Сейчас начал думать о программе в Конкордии (Computer Science (GrDip)) https://www.concordia.ca/academics/grad … ploma.html. Если буду учится на Computer Science , то буду больше делать уклон в сторону Веб разработки (мне это интересно). Сегодня узнал, что есть программа в Vanier
Software Applications Specialist. В общем, меня интересует фул-тайм обучение и только на английском, в дальнейшем хочу работать в веб разработке. Посоветуйте, пжлст, каким путём лучше пойти. Возможно у кого-то есть подобный опыт.
Web Developer. Какое учебное заведение выбрать?
.
[quote="Lascal":1bvhinw0][quote="loco":1bvhinw0][quote="Lascal":1bvhinw0]
Забудьте за win phone.
[/quote:1bvhinw0]
не хочу:)
где я еще найду 5 дюймовый смартфон с книгочиталкой-интернетом, отличными картами и навигатором за 100 баксов[/quote:1bvhinw0]
в Китае, на alibaba, даже дешевле 100
кстати поддержка HERE maps под win phone прекращена
))
не стоит цепляться за старые скелеты …[/quote:1bvhinw0]
не, кетайские за сто — это даже близко не нокия. Будем откровенны, железо в лумиях — отменное, это даже не самсунг
.
.
[quote="Lascal":2qhj6ndi]собсна вопрос
есть ли смысл сейчас, с выходом Angular 2.0, сконцентрироваться на нем?
ну т.е. не распыляться на прошлую версию[/quote:2qhj6ndi]
попрёт второй — ну и в путь тогда …
вот, почитайте https://habrahabr.ru/post/309300/
[url=https://habrahabr.ru/post/312022/:1taoeg4k]Каково оно учить JavaScript в 2016[/url:1taoeg4k]
[quote="Algo":1lib8y32][url=https://habrahabr.ru/post/312022/:1lib8y32]Каково оно учить JavaScript в 2016[/url:1lib8y32][/quote:1lib8y32]
Как выучившая JavaScript в 2016, подтверждаю — все так.
На самом деле, большинство программистов почему-то недооценивает JavaScript, хотя это очень мощный язык. Просто многие думают, наверное, что JavaScript — это jQuery.
На JavaScript можно писать и бэк энд, и делать очень крутые вещи, как функциональное программирование (да, это действительно очень круто и все больше компаний начинают использовать ту же Scala, если проект на Java), при этом язык поддерживает и ООП. В Java, для сравнения, функциональное программирование добавили только два года назад. Я знала программиста, который на JavaScript написал программу для 3D нейровизуализации. А вы — фу, JavaScript, фронт энд…
.
[quote="Ольга_":26jn10f7]
Как выучившая JavaScript в 2016, подтверждаю — все так.
На самом деле, большинство программистов почему-то недооценивает JavaScript, хотя это очень мощный язык. Просто многие думают, наверное, что JavaScript — это jQuery.
[/quote:26jn10f7]
Он не мощный, он гибкий
Т.е., многие концепции можно представить красивой оберткой. Вот даже на js oop посмотреть — ну это ж какие-то извращения вокруг функций и прототипов. Гибкость языка позволяет извращаться, но зачем, в чем смысл!?
[quote="Ольга_":26jn10f7]
[/quote:26jn10f7]
Я знала программиста, который на JavaScript написал программу для 3D нейровизуализации. А вы — фу, JavaScript, фронт энд…
И как у нее с производительностью было?
А вообще, вся эта активность вокруг js выглядит ппц как смешно. Т.е., народ берет скриптовый язык, созданный со специфическими целями, и пытается его превратить в нечто большее. Зачем, почему — нифига не понятно. Тока браузер теперь жрет еще больше памяти и тормозит
Еще смешное — раньше был flash, который по сути был скачиваемым приложением, запускаемым в браузере. И все сперва тащились, ms даже вон силверлайт сделала, а потом все сказали — фууу, только тонкие клиенты, только серверная обработка.
А нынче бац, все тащатся от angular
все возвращается на круги своя
[quote="Ольга_":sc51af1p][quote="Algo":sc51af1p][url=https://habrahabr.ru/post/312022/:sc51af1p]Каково оно учить JavaScript в 2016[/url:sc51af1p][/quote:sc51af1p]
Как выучившая JavaScript в 2016, подтверждаю — все так.
На самом деле, большинство программистов почему-то недооценивает JavaScript, хотя это очень мощный язык. Просто многие думают, наверное, что JavaScript — это jQuery.
На JavaScript можно писать и бэк энд, и делать очень крутые вещи, как функциональное программирование (да, это действительно очень круто и все больше компаний начинают использовать ту же Scala, если проект на Java), при этом язык поддерживает и ООП. В Java, для сравнения, функциональное программирование добавили только два года назад. Я знала программиста, который на JavaScript написал программу для 3D нейровизуализации. А вы — фу, JavaScript, фронт энд…
[/quote:sc51af1p]
наплодилось javascript программиров вот и пишут back end на чем умеют
ООП на жаваскрипт "из коробки" это просто праздник. особенно мощный там полиморфизм и перегрузка функций
вот и творят люди всякие костыли и фреймворки, где жаваскрипта все меньше
[quote="Lascal":1aewfilf]
Поделитесь как учили, какиe материалы использовали?
Материала завались, но хочется услышать Ваше мнение.
И еще … что Вы думаете про TypeScript?[/quote:1aewfilf]
Брала курсы на Udemy Learn and Understand AngularJS, JavaScript: Understanding the Weird Parts. И на работе параллельно изучаю фреймворк, написанный коллегой и код на AngularJS. Меня взяли на позицию Full Stack c условием, что я выучу JavaScript, я его знала как раз на уровне jQuery до этого.
TypeScript не знаю.
[quote="loco":1g6rtba9][quote="Ольга_":1g6rtba9]
Как выучившая JavaScript в 2016, подтверждаю — все так.
На самом деле, большинство программистов почему-то недооценивает JavaScript, хотя это очень мощный язык. Просто многие думают, наверное, что JavaScript — это jQuery.
[/quote:1g6rtba9]
Он не мощный, он гибкий
Т.е., многие концепции можно представить красивой оберткой. Вот даже на js oop посмотреть — ну это ж какие-то извращения вокруг функций и прототипов. Гибкость языка позволяет извращаться, но зачем, в чем смысл!?
[quote="Ольга_":1g6rtba9]
[/quote:1g6rtba9]
Я знала программиста, который на JavaScript написал программу для 3D нейровизуализации. А вы — фу, JavaScript, фронт энд…
И как у нее с производительностью было?
А вообще, вся эта активность вокруг js выглядит ппц как смешно. Т.е., народ берет скриптовый язык, созданный со специфическими целями, и пытается его превратить в нечто большее. Зачем, почему — нифига не понятно. Тока браузер теперь жрет еще больше памяти и тормозит
Еще смешное — раньше был flash, который по сути был скачиваемым приложением, запускаемым в браузере. И все сперва тащились, ms даже вон силверлайт сделала, а потом все сказали — фууу, только тонкие клиенты, только серверная обработка.
А нынче бац, все тащатся от angular
все возвращается на круги своя[/quote:1g6rtba9]
Я не понимаю, что значит производительность программы. Можете протестировать: https://brainbrowser.cbrain.mcgill.ca/
.
.
[quote="Ольга_":182rckeq]
Брала курсы на Udemy [/quote:182rckeq]
это был сознательный выбор? (ну в смысле рассматривались ли альтернативы типа pluralsight)? брали только видеокурсы или с инструктором тоже общались?
[quote="Ольга_":27lrz69v]
Я не понимаю, что значит производительность программы. Можете протестировать: https://brainbrowser.cbrain.mcgill.ca/[/quote:27lrz69v]
фпс, frames per second в случае 3д
ну и 3д ж не на жаваскрипте:) На opengl, так и я умею!:)
Хотя, проект отличный, конечно.
Но, имхо, если туда начать прикручивать разное, типа текстур, зума и проч — то возможно, проще это будет сделать на десктопе
При этом, вот чего я в упор не понимаю вообще — зачем подобное делать в браузере. Ведь все признаки десктопного приложения в наличии — и сама программа полностью скачивается на клиента, и данные. Зачем тут еще доп. прослойка в виде браузера? Она ж жрет память и процессор
Дело в простоте написания? Дак давно уже веб-инерфейсы не менее трудоемки, чем десктопные. В удобстве распространения? Опять же, давно уже программы сами себя апдейтят. Ну и т.д.
[quote="елкапалка":3kfn6vi4][quote="Ольга_":3kfn6vi4]
Брала курсы на Udemy [/quote:3kfn6vi4]
это был сознательный выбор? (ну в смысле рассматривались ли альтернативы типа pluralsight)? брали только видеокурсы или с инструктором тоже общались?[/quote:3kfn6vi4]
Я сейчас в основном беру курсы на Udemy. Там очень большой выбор, конкретно по JavaScript Anthony Alicea — отличный инструктор, я не зря два его курса взяла. Про Pluralsight не в курсе была. Там в 10 раз меньше курсов, чем на Udemy, по ценам не поняла — сколько там стоят курсы? На Udemy постоянно скидки, 100-200 долларовые курсы можно возять за 20.
[quote="loco":2uyo7ltn][quote="Ольга_":2uyo7ltn]
Я не понимаю, что значит производительность программы. Можете протестировать: https://brainbrowser.cbrain.mcgill.ca/[/quote:2uyo7ltn]
фпс, frames per second в случае 3д
ну и 3д ж не на жаваскрипте:) На opengl, так и я умею!:)
Хотя, проект отличный, конечно.
Но, имхо, если туда начать прикручивать разное, типа текстур, зума и проч — то возможно, проще это будет сделать на десктопе
При этом, вот чего я в упор не понимаю вообще — зачем подобное делать в браузере. Ведь все признаки десктопного приложения в наличии — и сама программа полностью скачивается на клиента, и данные. Зачем тут еще доп. прослойка в виде браузера? Она ж жрет память и процессор
Дело в простоте написания? Дак давно уже веб-инерфейсы не менее трудоемки, чем десктопные. В удобстве распространения? Опять же, давно уже программы сами себя апдейтят. Ну и т.д.[/quote:2uyo7ltn]
Никто и не говорил, что графика тоже на JavaScript. Но попробуйте напишите программу для манипуляции подобной графикой на JavaScript, потом скажете, что тоже так умеете. Я сейчас там уже не работаю, не могу спросить, зачем он это сделал на JavaScript. Он очень крутой специалист по JavaScript, ему виднее, наверное. Вот выдержка из документации:
BrainBrowser is a lightweight, high-performance JavaScript visualization library built to provide easy-to-use, powerful, on-demand visualization of remote datasets in this new research environment. BrainBrowser leverages modern web technologies, such as WebGL, HTML5 and Web Workers, to visualize 3D surface and volumetric neuroimaging data in any modern web browser without requiring any browser plugins. It is thus trivial to integrate BrainBrowser into any web-based platform. BrainBrowser is simple enough to produce a basic web-based visualization in a few lines of code, while at the same time being robust enough to create full-featured visualization applications. BrainBrowser can dynamically load the data required for a given visualization, so no network bandwidth needs to be waisted on data that will not be used. BrainBrowser’s integration into the standardized web platform also allows users to consider using 3D data visualization in novel ways, such as for data distribution, data sharing and dynamic online publications.
[quote="Lascal":1g3m9tnk][quote="loco":1g3m9tnk]…А вообще, вся эта активность вокруг js выглядит ппц как смешно. Т.е., народ берет скриптовый язык, созданный со специфическими целями, и пытается его превратить в нечто большее. Зачем, почему — нифига не понятно. Тока браузер теперь жрет еще больше памяти и тормозит …[/quote:1g3m9tnk]
Память нынче стоит копейки … в лептопах за 500 кад уже ставят по 8гб озу
браузеры постоянно оптимизируют + конкуренция …
вот кстати Edge … вроде неплохой браузер, хорошая задумка
но если открыть в нем 20 вкладок, то начинаются фризы
так что до хрома ему еще очень далеко[/quote:1g3m9tnk]
дело не в размере памяти, как таковой, а в ее дефрагментированности, это раз, два — все совсем не просто с памятью
попробуйте открыть картинку 10000х10000 пикселей 32bpp — это всего-то 3 с копейками гига(несжатая, в памяти все несжатые)
Как его не оптимизируй — выполнение в ОС будет быстрее и менее затратно по ресурсам, при прочих равных.
едж — вообще какое-то г, прямо скажем
[quote="Ольга_":35633wir]
Никто и не говорил, что графика тоже на JavaScript. Но попробуйте напишите программу для манипуляции подобной графикой на JavaScript, потом скажете, что тоже так умеете. Я сейчас там уже не работаю, не могу спросить, зачем он это сделал на JavaScript. Он очень крутой специалист по JavaScript, ему виднее, наверное. Вот выдержка из документации:
BrainBrowser is a lightweight, high-performance JavaScript visualization library built to provide easy-to-use, powerful, on-demand visualization of remote datasets in this new research environment. BrainBrowser leverages modern web technologies, such as WebGL, HTML5 and Web Workers, to visualize 3D surface and volumetric neuroimaging data in any modern web browser without requiring any browser plugins. It is thus trivial to integrate BrainBrowser into any web-based platform. BrainBrowser is simple enough to produce a basic web-based visualization in a few lines of code, while at the same time being robust enough to create full-featured visualization applications. BrainBrowser can dynamically load the data required for a given visualization, so no network bandwidth needs to be waisted on data that will not be used. BrainBrowser’s integration into the standardized web platform also allows users to consider using 3D data visualization in novel ways, such as for data distribution, data sharing and dynamic online publications.[/quote:35633wir]
я прочел документацию:)
Писать 3д — оно везде одинаковое, что на с++, что на с#, что на js — это последовательные вызовы методов api плюс трансформация матриц. В сложных случаях — еще и сплайны, но их мой слабый мосг уже не очень понимает
Я подозреваю, сделал на js потому что другого ничего не знает
.
[quote="loco":2oy2rua5]
я прочел документацию:)
Писать 3д — оно везде одинаковое, что на с++, что на с#, что на js — это последовательные вызовы методов api плюс трансформация матриц. В сложных случаях — еще и сплайны, но их мой слабый мосг уже не очень понимает
Я подозреваю, сделал на js потому что другого ничего не знает[/quote:2oy2rua5]
По себе-то не судите. Сейчас все очень легко гуглится — да, он спец по JavaScript, но помимо этого знает Ruby, Java, C, C++. Кстати, в Нью-Йорке сейчас работает 3D Software Engineer.
Он написал, почему такой выбор — проще работать с распределенными системами и интегрировать в проекты. У меня, кстати, недавно было интервью на позицию Cloud Integration Developer. Язык, на котором пишут эту интеграцию, — догадаетесь сами? Правильно, JavaScript. Не надо недооценивать язык. Если вы не знаете, что он широко используется и помимо манипуляций с окошками в браузере, то это не значит, что это язык для неудачников, неспособных выучить другие языки.
.
[quote="Ольга_":hkmdz7pl][quote="loco":hkmdz7pl]
я прочел документацию:)
Писать 3д — оно везде одинаковое, что на с++, что на с#, что на js — это последовательные вызовы методов api плюс трансформация матриц. В сложных случаях — еще и сплайны, но их мой слабый мосг уже не очень понимает
Я подозреваю, сделал на js потому что другого ничего не знает[/quote:hkmdz7pl]
По себе-то не судите. Сейчас все очень легко гуглится — да, он спец по JavaScript, но помимо этого знает Ruby, Java, C, C++. Кстати, в Нью-Йорке сейчас работает 3D Software Engineer.
Он написал, почему такой выбор — проще работать с распределенными системами и интегрировать в проекты. У меня, кстати, недавно было интервью на позицию Cloud Integration Developer. Язык, на котором пишут эту интеграцию, — догадаетесь сами? Правильно, JavaScript. Не надо недооценивать язык. Если вы не знаете, что он широко используется и помимо манипуляций с окошками в браузере, то это не значит, что это язык для неудачников, неспособных выучить другие языки.
[/quote:hkmdz7pl]
js просто не для этого
с б-м приличным 3д будет зверски тормозить
Это как на мон-тремблан на самокате ездить — вполне можно, но зачем?
[quote="Lascal":3pydkpq8]Посоветуйте хорошую mooс.
еще запомнился один автор с излюбленным словом-паразитом "alright?" чуть ли не после каждой фразы вставлял. 
Их щас великое множество развелось (udemy, pluralsight и т.д.). Трудности выбора.
Пусть платно, главное чтобы качественно.[/quote:3pydkpq8]
по качеству, на мой взгляд udemy — любители, pluralsight — профи.
из плюсов udemy — количество курсов, гибкая ценовая политика (как я понимаю, платить можно отдельно за курс) и то, что с "профессором" можно общаться.
Вывод насчет качества сделан из личного опыта — нам HR оформили подписку на 1500 курсов от udemy, а моя лицензия MSDN дает доступ на несколько десятков курсов у pluralsight. — Я походил и там и там. Не все, конечно, открывал, но как-то так попало, что курсы с интересными мне названиями на udemy читали с сильным индусским или арабским акцентом
ps: на рутрекере есть большая коллекция pluralsight. если религия позволяет
.
[quote="Eugene_4ik":381wpabq][quote="Бриолин":381wpabq][quote="Eugene_4ik":381wpabq]http://www.johnabbott.qc.ca/continuing-education/programs/aec/web-technology/
А чем такой AEC не подходит? Я вот на него подаваться буду[/quote:381wpabq]
слабая программа, если сравнивать с Internet Programming and Development AEC LEA.BN http://www.johnabbott.qc.ca/continuing- … velopment/
я бы тогда конкордию выбрал[/quote:381wpabq]
Безусловно Internet Programming and Development сильнее. Но на нее меня уже Emploi-Quebec отшил. Та вторая без Emploi_quebec можно. А насколько она слабая? После нее работу вообще не найти на entry level? Не понимаю зачем они тогда создают такие программы для быстрого трудоустройства после которых не устроиться. Может тогда лучше вообще голову не морочить а на DEC подаваться?[/quote:381wpabq]
[quote="loco":aawcmuu3][quote="Ольга_":aawcmuu3]
Я не понимаю, что значит производительность программы. Можете протестировать: https://brainbrowser.cbrain.mcgill.ca/[/quote:aawcmuu3]
фпс, frames per second в случае 3д
ну и 3д ж не на жаваскрипте:) На opengl, так и я умею!:)
Хотя, проект отличный, конечно.
Но, имхо, если туда начать прикручивать разное, типа текстур, зума и проч — то возможно, проще это будет сделать на десктопе
При этом, вот чего я в упор не понимаю вообще — зачем подобное делать в браузере. Ведь все признаки десктопного приложения в наличии — и сама программа полностью скачивается на клиента, и данные. Зачем тут еще доп. прослойка в виде браузера? Она ж жрет память и процессор
Дело в простоте написания? Дак давно уже веб-инерфейсы не менее трудоемки, чем десктопные. В удобстве распространения? Опять же, давно уже программы сами себя апдейтят. Ну и т.д.[/quote:aawcmuu3]
ну как сделать десктоп приложение под виндоус, мак ос и линух?
[quote="Ilya":2c64x032][quote="loco":2c64x032][quote="Ольга_":2c64x032]
Я не понимаю, что значит производительность программы. Можете протестировать: https://brainbrowser.cbrain.mcgill.ca/[/quote:2c64x032]
фпс, frames per second в случае 3д
ну и 3д ж не на жаваскрипте:) На opengl, так и я умею!:)
Хотя, проект отличный, конечно.
Но, имхо, если туда начать прикручивать разное, типа текстур, зума и проч — то возможно, проще это будет сделать на десктопе
При этом, вот чего я в упор не понимаю вообще — зачем подобное делать в браузере. Ведь все признаки десктопного приложения в наличии — и сама программа полностью скачивается на клиента, и данные. Зачем тут еще доп. прослойка в виде браузера? Она ж жрет память и процессор
Дело в простоте написания? Дак давно уже веб-инерфейсы не менее трудоемки, чем десктопные. В удобстве распространения? Опять же, давно уже программы сами себя апдейтят. Ну и т.д.[/quote:2c64x032]
ну как сделать десктоп приложение под виндоус, мак ос и линух?[/quote:2c64x032]
так-то обычно платформу под приложение подгоняют, а не наоборот. потребитель, в смысле.
то есть если приложение — чума, то пиши на чем хочешь, — купят. а если приложение — туфта, то обилие покрытых платформ не поможет.
Это если отойти от вопроса к сути проблемы.
ну а как ответ на вопрос — можно на дельфях писать. там в последних версиях говорят чудо-кнопка есть, которая один и тот же исходник подо все платформы компилирует.
[quote="елкапалка":3lje0ij1][quote="Ilya":3lje0ij1][quote="loco":3lje0ij1]
фпс, frames per second в случае 3д
ну и 3д ж не на жаваскрипте:) На opengl, так и я умею!:)
Хотя, проект отличный, конечно.
Но, имхо, если туда начать прикручивать разное, типа текстур, зума и проч — то возможно, проще это будет сделать на десктопе
При этом, вот чего я в упор не понимаю вообще — зачем подобное делать в браузере. Ведь все признаки десктопного приложения в наличии — и сама программа полностью скачивается на клиента, и данные. Зачем тут еще доп. прослойка в виде браузера? Она ж жрет память и процессор
Дело в простоте написания? Дак давно уже веб-инерфейсы не менее трудоемки, чем десктопные. В удобстве распространения? Опять же, давно уже программы сами себя апдейтят. Ну и т.д.[/quote:3lje0ij1]
ну как сделать десктоп приложение под виндоус, мак ос и линух?[/quote:3lje0ij1]
так-то обычно платформу под приложение подгоняют, а не наоборот. потребитель, в смысле.
то есть если приложение — чума, то пиши на чем хочешь, — купят. а если приложение — туфта, то обилие покрытых платформ не поможет.
Это если отойти от вопроса к сути проблемы.
ну а как ответ на вопрос — можно на дельфях писать. там в последних версиях говорят чудо-кнопка есть, которая один и тот же исходник подо все платформы компилирует.[/quote:3lje0ij1]
Сколько ж можно спорить, автор же объяснил выбор языка и технологий.
[quote:3lje0ij1]In recent years, neuroimaging research has seen itself inundated by large, distributed datasets that have necessitated a shift in how scientists approach their research: guiding hypotheses are often articulated after analyzing the mass of available data (Margulies et al., 2013), and data sharing has become a necessity for scientific discovery (Jomier et al., 2011). Several large-scale, distributed, collaborative platforms have been developed to facilitate this new approach, and they tend to integrate poorly with traditional visualization tools requiring a local installation and local data. These tools and their dependencies would have to be installed locally, and data would generally have to be exported from the platform in order to be visualized in the local environment. Web-based visualization tools, on the other hand, present significant benefits in the context of distributed research platforms:
• They can be easily integrated into existing web-based platforms.
• Other than the web browser, no software or libraries need to be installed.
• If a visualization doesn’t require the entirety of a remote dataset at once, it can load required data on-demand, potentially saving bandwidth.
Ideally, a web-based visualization tool might have the following properties:
• Performant and responsive: If network latency or lagging performance interfere with usability, researchers will not use it.
• Doesn’t require any browser plugins (e.g., Java, Flash): Plugins add extra friction to the deployment of tools that depend on them. They require users to install software on their machines and keep it up to date. Furthermore, not all users have the administrative access to their machines that is required to install most plugins.
• Dynamic and interactive: If the tool is to be used to explore data, it should allow that data to be loaded, removed, manipulated and modified with minimal effort.
• Extensible: Many labs use different data formats, standards and requirements can change rapidly, so the tool should be able to adapt.
• Open source: It’s easier for researchers to trust the results they’re seeing if they can verify how the tool is functioning. If need be, they can also extend, customize and tweak the tool to fit their needs.
While this shift in research requirements has been taking place, modern web standards have introduced a host of new technologies that are built directly into modern web browsers and allow for the creation of high-performance, web-based applications that rival much of what is available offline. Improvements to the JavaScript language itself and the optimizations made by browser vendors such as Google and Mozilla to their JavaScript engines have created a base on which robust applications can be built. At the same time, Graphical Processing Unit (GPU) access through WebGL, and multi-threaded processing through Web Workers, blur the lines between what is possible on native versus web applications.
The fact that these technologies are now a part of the hyper-connected web platform has also made it possible to consider using visualization technologies in novel ways:
• Publication: With scientific articles now being published online, publishers are looking for ways to disseminate datasets and present them in more meaningful ways (Jomier et al., 2011). It is now possible to replace the static visual media of traditional print publications, such as static figures or charts, with more dynamic, interactive 2D or 3D visualizations1.
• Distribution: Online visualization tools can also be used as a means to distribute data, as researchers can use the tools to explore a remote dataset directly. BrainBrowser, for example, was used to share the MACACC dataset, as will be discussed further in Section 4.1. TissueStack, which will be discussed in Section 2, was used for remote visualization of the BigBrain dataset (Amunts et al., 2013) upon its release.
As will be discussed in Section 2, approaches to using the aforementioned web technologies for visualization can be broadly split into two categories. The first requires some back-end infrastructure to support a front-end client. This infrastructure will usually involve some processing of the data to be served, and might also include some proxying or database support. The second runs completely in the browser, requiring the back end to do nothing more than serve static files. BrainBrowser takes the latter approach for the following reasons:
1. Scalability: Both approaches require that the resources available on the server be capable of handling the user load at all times, but a fully front-end application puts a much lighter load on those resources. For back-end infrastructure, growth of the user base necessitates an expansion of infrastructure resources to prevent the application from blocking. In a commercial setting, where new users bring increased revenues, this type of expansion might not be considered problematic. In a research setting, however, where the relationship between users and revenue is not so direct, the cost of scaling becomes a major concern.
2. Network latency: If simple manipulations of a visualization require continuous network traffic, the responsiveness of the application will be bound by network latency. After the initial load of the data to be visualized, most fully front-end applications will no longer be dependent on the network.
3. Flexibility: Being independent of any particular server allows a fully front-end application to pull its data from essentially anywhere. An application could allow users visualize data they have stored locally on their machines without being required to upload them to a server. There is also nothing preventing fully front-end application from requesting data from a server with more elaborate infrastructure, thus allowing it to benefit from both approaches.
BrainBrowser has been developed to facilitate the exploitation of modern web technologies for a wide range of purposes. It exposes an application programming interface (API) that is simple enough to create a basic, interactive visualization in a few lines of code, while being deep enough to build more complex visualizations involving dynamic, on-demand fetching and loading of remote data. It uses WebGL, the HTML5 Canvas and Web Workers to push as much of the processing client-side as possible, thus minimizing the effect of network lag on its usage and eliminating the need for browser plugins. BrainBrowser is an open-source project, meaning that its users can verify the code directly and even modify it to fit their needs.[/quote:3lje0ij1]
попалась статья занятная, — чем не повод поднять топик
[url=https://medium.freecodecamp.com/a-roadmap-to-becoming-a-web-developer-in-2017-b6ac3dddd0cf:1wf5tjhv]A roadmap to becoming a web developer in 2017[/url:1wf5tjhv]
сперва общий чарт, типа камень на распутье
[img:1wf5tjhv]https://cdn-images-1.medium.com/max/1000/1*GD5sdzPlE3h4ljSWNaPx0Q.png[/img:1wf5tjhv]
и потом подробно по каждому пути…
[img:1wf5tjhv]https://cdn-images-1.medium.com/max/1000/1*s6DocnGRV5y0QdZ_JHN6Xg.png[/img:1wf5tjhv]
[img:1wf5tjhv]https://cdn-images-1.medium.com/max/1000/1*wS8k6IlIgSb-7-lPhaNyrQ.png[/img:1wf5tjhv]
[img:1wf5tjhv]https://cdn-images-1.medium.com/max/1000/1*Qc0PqmXenUZmRvnkMh9AoQ.png[/img:1wf5tjhv]
[quote="Ольга_":5mw6inwl]
1. Scalability: Both approaches require that the resources available on the server be capable of handling the user load at all times, but a fully front-end application puts a much lighter load on those resources. For back-end infrastructure, growth of the user base necessitates an expansion of infrastructure resources to prevent the application from blocking. In a commercial setting, where new users bring increased revenues, this type of expansion might not be considered problematic. In a research setting, however, where the relationship between users and revenue is not so direct, the cost of scaling becomes a major concern.
2. Network latency: If simple manipulations of a visualization require continuous network traffic, the responsiveness of the application will be bound by network latency. After the initial load of the data to be visualized, most fully front-end applications will no longer be dependent on the network.
3. Flexibility: Being independent of any particular server allows a fully front-end application to pull its data from essentially anywhere. An application could allow users visualize data they have stored locally on their machines without being required to upload them to a server. There is also nothing preventing fully front-end application from requesting data from a server with more elaborate infrastructure, thus allowing it to benefit from both approaches.[/quote:5mw6inwl]
O, только увидел
Все, что здесь расписано, не обьясняет почему js
Более того, оно прямо указывает на десктопное приложение по характеристикам
Как только у парня пойдут б-м нагруженные модели, переползет на десктоп, на жаву/дотнет/с++
js — это узко прикладной язык. Попытки сделать его универсальным не приведут ни к чему. Безусловно, денег заработать можно и на нем, и даже много. Но стать профессионалом — эт вряд ли
Вот хорошая статья по поводу
http://eao197.blogspot.ca/2017/04/progthoughts.html
[prog.thoughts] Вероятно, наступило время языков, на которых можно "просто педалить код"…
У меня в блоге давно не было псевдофилосовских рассуждений на тему языков программирования и тенденций их развития. Тому есть свои причины. Мне самому уже, в силу возраста, не так интересно тратить время на пустое сотрясение воздуха. Блог живет уже достаточно давно и в нем подобные темы уже поднимались неоднократно. Плюс к тому, текущие дела и заботы заставляют больше смотреть в сторону проблем маркетинга и позиционирования на рынке, а проблемы технологий и языков программирования при этом отходят на второй, третий или даже четвертый план.
Тем не менее, есть ощущение, что такие языки, как JavaScript и Go (в особенности Go), становятся все более и более востребованными в нашей индустрии… Ну, если и не восстребованными, то одними из самых обсуждаемых. Хочется разобраться, почему так происходит и, если получится, понять, чем это грозит и, может быть, придумать, как этим можно воспользоваться.
Итак, вот есть язык Go. Который, на первый взгляд, выглядит очень простым и практичным. Я бы, правда, сказал, что он примитивный и убогий, ну да я старый маразматик, мои слова все равно ничего не изменят
Вот только на второй взгляд, выясняется, что в Go так же есть приличное количество своих косяков и неоднозначностей. Так что мифы о простоте Go, наверное, несколько преувеличены. Тем не менее, большое количество людей Go пользуется, пользуется с удовольствием и, что удивительно, не особо хочет чего-то другого.
Недавно у меня возникло ощущение, что я таки окончательно понял, почему именно так.
В какой-то момент все само собой разложилось по полочкам и стало понятно, почему с Go происходит именно так. Ключевым моментом стала увиденная где-то (возможно, в Facebook-е) заметка, в которой разработчик на Go троллил разработчиков на других языках программирования многократно повторяя, что на Go можно "просто педалить код". Мол, пока Java-программисты спорят о том, какие паттерны они будут задействовать и сколько абстрактных фабрик им придется построить, Go-программисты просто педалят код.
Не смотря на то, что заметка носила троллинговый характер, ее автор явно узрел в корень и написал чистую правду: язык Go нужен для того, чтобы просто педалить код.
Это заставило меня вспомнить свое впечатление от знакомства со средствами работы с базами данных времен начала 90-х. Были такие вещи, как dBase (FoxBase, FoxPro) и язык Clipper. Очень активно использовались для разработки прикладного софта, вроде бухучета, складов, картотек и т.д. По сравнению даже с Pascal, не говоря уже про C и C++, это были ну очень ограниченные по своим выразительным возможностям языки. Но вот что важно: для своих предметных областей они позволяли педалить код гораздо быстрее, чем на том же самом Pascal-е (про C вообще можно было не говорить).
Сдается мне, что языкостроение давным-давно разделилось на несколько направлений. Из которых в контексте данного разговора интересно только два. Первое направление это разработка заточенных под специфическую предметную область специализированных языков программирования. Вот тех же самых ForBase или Clipper. Языки эти могут быть весьма убогими, не сильно продуманными, напоминающими лоскутное одеяло, сшитое из совершенно разных кусочков… Но зато они отлично закрывают свою узкую прикладную нишу. Беря такой язык ты просто педалишь конкретный прикладной код и понимаешь, что вряд ли какой-то другой язык мог бы дать тебе такую же скорость разработки и качество результата (за те же деньги, по крайней мере).
Другое направление это разработка универсальных языков программирования. Их специфика в том, что сам по себе универсальный язык программирования вряд ли может хорошо решать какую-то прикладную задачу. Но зато он позволяет разработчику самостоятельно создать инструментарий, с помощью которого решение прикладной задачи упрощается в разы.
Ну вот, например, нужен вам графический редактор уровня Photoshop или Corel DRAW. В голом C или даже в голом C++ нет никаких готовых средств для создания графического редактора. Однако, и C, и C++ позволяют разработчику сформировать набор специализированных библиотек, на базе которых задача становится уже вполне себе решаемой. При этом, правда, такие библиотеки могут оказаться совершенно бесполезными для написания, скажем, СУБД уровня MSSQL или Oracle. Но это уже проблемы разработчиков СУБД
Так вот, целью универсальных языков программирования является предоставление разработку такого набора низкоуровневых примитивов, из которых разработчик сможет создать нужные ему строительные блоки. Возможно, даже несколько слоев этих самых строительных блоков (например, на базе C++ строится STL, на базе STL строится Boost, на базе Boost-а еще какой-то более приближенный к прикладной задаче слой и т.д.). Поэтому с 1970-х годов и до недавнего времени универсальные языки программирования развивались так, чтобы становиться все более и более выразительными. На моей памяти примерами этого стали такие языки, как Ada, которая оказалась мощнее и выразительнее Pascal и Modula-2, под влиянием которых она и создавалась. Или C++. Или Eiffel.
Особенно показателен в этом плане пример Java. Там изначально под флагом "мы выбросили из C++ все самые опасные фичи" создали такой куцый язык, что сейчас даже страшно вспомнить. Но затем в Java пришлось добавлять вещи, которые реально упрощают жизнь программисту. И современная Java, к счастью, сильно ушла от Java времен 1995-го года. А авторы C#, имея перед глазами пример Java, прошли этот путь гораздо быстрее.
Однако, вернемся ближе к телу. Развитие универсальных языков шло по пути их усложнения. Ada была гораздо сложнее в изучении, чем Pascal и Modula-2. Про сложность C++ и говорить не приходиться. Даже Eiffel, весьма продуманный и, я бы сказал, довольно минималистичный язык, не так уж и прост и требует изрядного перестроения мозгов и взглядов на то, как нужно проектировать и реализовывать программы. Как сказано выше, современная Java уже совсем не так проста, как Java 1.0. Собственно, тоже самое можно сказать и про современный C#. Ну а Scala всегда была сложной
Эта сложность универсальных языков программирования, имхо, полностью оправдывается, когда универсальные ЯП используются для создания инфраструктуры. Т.е. сложность C++ вам нужна, когда вы пишете свой аналог STL для специфических условий или же пишете собственную NoSQL СУБД. Но эта сложность совершенно не нужна, когда вам нужно просто раз в 10 секунд прочитать значение какого-то датчика и записать полученное значение в определенный MQ-шный топик.
И вот тут оказывается (да, я тормоз, для меня это "внезапно"), что за минувшие 25-30 лет огромное количество инфраструктурных задач уже было успешно решено тем или иным способом. И еще более огромное количество задач сейчас лежит в области именно прикладного программирования. Когда задачей обычного разработчика является написание прикладного "клеевого кода". Т.е. реализация взаимодействия с другими компонентами по типу: нас дернули отсюда, взяли параметры запроса, проверили, если вот это, то спросили вот у этой подсистемы, а если вот это, то вот у той.
Т.е. за последние годы сформировался набор прикладных ниш, для которых нужны не универсальные языки общего назначения, пусть даже и снабженные большим количеством прикладных библиотек, а современные аналоги dBase и Clipper-а. В хорошем смысле этого слова
Почему же нужны специализированные языки, а универсальные не подходят? Главная причина в человеческой тупости, ибо количество разума на планете есть величина постоянная, а население-то растет. Ну причин много, полагаю. Наиболее важные это более высокий порог входа. Изучить Go все-таки проще, чем какой-нибудь Eiffel, Rust или C++. А изучать придется, т.к. абстракции все-таки текут и когда прикладному разработчику приходится заглядывать в потроха используемых библиотек, то ему минимального знания языка программирования явно не хватит. Плюс к тому, чем меньше способов решить проблему, тем лучше. Когда у разработчик выбирает бросить ли ему исключение или вернуть Option, это это проблема выбора. Таких проблем быть не должно. Плюс к тому, заточенный под предметную область язык не должен давать возможность писать мудреный код, требующий знаний каких-то специфических особенностей языка программирования (вроде ADL в C++ или специализаций шаблонов).
Получается, что специализированный язык в принципе должен быть избавлен от средств повышения выразительности, которые специально закладываются в универсальные языки программирования. Ведь сложность это проблема для специализированного языка. Поэтому специализированные языки должны двигаться в противоположном направлении и должны избавляться от всего, что может усложнить жизнь среднестатическому прикладному программисту. Что мы, собственно говоря, и видим на примере языка Go.
Какой же сухой остаток можно выделить из всего вышесказанного?
А вот фиг его знает
Для меня становится очевидно, что прослойка "инфраструктурного программирования" с годами становится все уже и уже. Однако, отрадно, что эта узость вряд ли выражается в абсолютных цифрах. Скорее всего, речь про сужение в процентном отношении. Прикладного программирования все больше и больше, на этом фоне "инфраструктура" не так заметна.
В этом сужении "инфраструктурного программирования" плохо то, что зарабатывать на такого рода задачах будет все сложнее и сложнее. Поскольку сюда же нужно добавить и тенденцию разрабатывать OpenSource продукты, за которые большинство пользователей просто не платят. Но хорошо то, что у людей, не боящихся сложных универсальных языков программирования, конкурентных преимуществ должно быть побольше. В этой нише.
Есть ощущение, что Go это всерьез и надолго. В ИТ с каждым годом вливается все больше и больше народу. Объективно, для изрядной части даже современная Java это уже over complicated. А Go в самый раз. Будем посмотреть, как все это повлияет на ИТ в перспективе 5-10 лет. Хотя есть ощущение, что ИТ сейчас настолько сегментировано, что тенденции в одном сегменте вряд ли оказывают влияние на другой сегмент. Только вот про сегментацию постоянно забываешь, ибо на слуху самые горячие темы вроде front-end-а на JavaScript и back-end-а на Go. И складывается ощущение, что кроме этих горячих тем ничего больше нет. Что совершенно не так. Но это уже совсем другая история.
PS. Думается, что Erlang это еще один пример специфического прикладного языка, который взлетел именно тогда, когда появилась насущная необходимость в решении определенного рода прикладных задач в Web-е и коммуникациях через Интернет.
[quote="loco":3lc4ccl7][quote="Ольга_":3lc4ccl7]
1. Scalability: Both approaches require that the resources available on the server be capable of handling the user load at all times, but a fully front-end application puts a much lighter load on those resources. For back-end infrastructure, growth of the user base necessitates an expansion of infrastructure resources to prevent the application from blocking. In a commercial setting, where new users bring increased revenues, this type of expansion might not be considered problematic. In a research setting, however, where the relationship between users and revenue is not so direct, the cost of scaling becomes a major concern.
2. Network latency: If simple manipulations of a visualization require continuous network traffic, the responsiveness of the application will be bound by network latency. After the initial load of the data to be visualized, most fully front-end applications will no longer be dependent on the network.
3. Flexibility: Being independent of any particular server allows a fully front-end application to pull its data from essentially anywhere. An application could allow users visualize data they have stored locally on their machines without being required to upload them to a server. There is also nothing preventing fully front-end application from requesting data from a server with more elaborate infrastructure, thus allowing it to benefit from both approaches.[/quote:3lc4ccl7]ис
O, только увидел
Все, что здесь расписано, не обьясняет почему js
Более того, оно прямо указывает на десктопное приложение по характеристикам
Как только у парня пойдут б-м нагруженные модели, переползет на десктоп, на жаву/дотнет/с++
js — это узко прикладной язык. Попытки сделать его универсальным не приведут ни к чему. Безусловно, денег заработать можно и на нем, и даже много. Но стать профессионалом — эт вряд ли
Вот хорошая статья по поводу[/quote:3lc4ccl7]
Если и это прямое и доступное объяснение самого инженера не объясняет, то что я могу сделать.
Никто не пытается сделать JS универсальным. Человек, который разрабатывал проект, объяснил, почему решил использовать фронт-энд по максимуму для этого некоммерческого проекта. О зарабатывании денег тут речи нет, проект держится исключительно на грантах и создавался не для продажи.
Человек сейчас руководит группой инженеров, которые разрабатывают JS движок для визуализации человеческого тела в нью-йоркской компании, а вы все равно будете утверждать, какой он дурак, что не написал на "жаву/дотнет/с++". Конечно, вам, распределяющему радиосигналы в монреальской компании, виднее.
В качестве дисклеймера — мне лично JS не нравится, по крайней мере как язык фронт-энда, и весь фронт-энд в целом — это скучно и неинтересно, несмотря на все его крутые фреймворки. С большой радостью покинула позицию фулл стак девелопера.
[quote="Ольга_":3ciieham][quote="loco":3ciieham][quote="Ольга_":3ciieham]
1. Scalability: Both approaches require that the resources available on the server be capable of handling the user load at all times, but a fully front-end application puts a much lighter load on those resources. For back-end infrastructure, growth of the user base necessitates an expansion of infrastructure resources to prevent the application from blocking. In a commercial setting, where new users bring increased revenues, this type of expansion might not be considered problematic. In a research setting, however, where the relationship between users and revenue is not so direct, the cost of scaling becomes a major concern.
2. Network latency: If simple manipulations of a visualization require continuous network traffic, the responsiveness of the application will be bound by network latency. After the initial load of the data to be visualized, most fully front-end applications will no longer be dependent on the network.
3. Flexibility: Being independent of any particular server allows a fully front-end application to pull its data from essentially anywhere. An application could allow users visualize data they have stored locally on their machines without being required to upload them to a server. There is also nothing preventing fully front-end application from requesting data from a server with more elaborate infrastructure, thus allowing it to benefit from both approaches.[/quote:3ciieham]ис
O, только увидел
Все, что здесь расписано, не обьясняет почему js
Более того, оно прямо указывает на десктопное приложение по характеристикам
Как только у парня пойдут б-м нагруженные модели, переползет на десктоп, на жаву/дотнет/с++
js — это узко прикладной язык. Попытки сделать его универсальным не приведут ни к чему. Безусловно, денег заработать можно и на нем, и даже много. Но стать профессионалом — эт вряд ли
Вот хорошая статья по поводу[/quote:3ciieham]
Если и это прямое и доступное объяснение самого инженера не объясняет, то что я могу сделать.
[/quote:3ciieham]
Он обьясняет, почему толстый клиент:) А не почему js
[quote:3ciieham]Человек сейчас руководит группой инженеров, которые разрабатывают JS движок для визуализации человеческого тела в нью-йоркской компании, а вы все равно будете утверждать, какой он дурак, что не написал на "жаву/дотнет/с++". Конечно, вам, распределяющему радиосигналы в монреальской компании, виднее.
[/quote:3ciieham]
Да я-то тут при чем:)
В разработке софта есть масса примеров, когда первые прототипы, и даже версии софта были по-быстрому наваяны хоть на чем, тот же фейсбук и php, например
А потом, с ростом сложности задач, все б-м неуклонно переползали на более универсальные платформы
[quote:3ciieham]В качестве дисклеймера — мне лично JS не нравится, по крайней мере как язык фронт-энда, и весь фронт-энд в целом — это скучно и неинтересно, несмотря на все его крутые фреймворки. С большой радостью покинула позицию фулл стак девелопера.
[/quote:3ciieham]
Даже самый разлюбезный язык/платформа надоедают:( Но с узкоприкладными языками это случается быстрее
[quote="loco":3aqlgo7z]
Он обьясняет, почему толстый клиент:) А не почему js
[/quote:3aqlgo7z]
А на каком языке надо было писать фронт-энд ?
[quote:3aqlgo7z]Да я-то тут при чем:)
В разработке софта есть масса примеров, когда первые прототипы, и даже версии софта были по-быстрому наваяны хоть на чем, тот же фейсбук и php, например
А потом, с ростом сложности задач, все б-м неуклонно переползали на более универсальные платформы[/quote:3aqlgo7z]
Ну да, человека наняла на работу нью-йоркская компания, так и не поняв, какой ерундой он занимается, перенося визуализацию на фронт-энд.
[quote:3aqlgo7z]Даже самый разлюбезный язык/платформа надоедают:( Но с узкоприкладными языками это случается быстрее
[/quote:3aqlgo7z]
Мне пока Джава не надоела, наоборот, с выпуском 8 версии, которая поддерживает функциональное программирование, стало гораздо интереснее. Функциональное программирование — это, пожалуй, единственное, что мне нравится в JS.
Я надеюсь, узкоприкладные языки — это вы не про JS.
[quote="Ольга_":3gy970ge][quote="loco":3gy970ge]
Он обьясняет, почему толстый клиент:) А не почему js
[/quote:3gy970ge]
А на каком языке надо было писать фронт-энд ?
[/quote:3gy970ge]
эээ
на любом. Но при чем тут фронтэнд?
бизнес логика, типа отрисовка 3д и работa с б-м приличными массивами данных это не фронтэнед. Какое это имеет отношение к UI?
Как-то мы друг друга совсем не понимаем. Представление моделей, сиречь UI — это одно. Обработка и хранение данных — это бизнес логика, back end. Последняя может быть очень ресурсоемкой, и поэтому выполнять ее лучше на клиенте, т.к. там мощностей больше. А раз мы на клиенте, то след. логичный шаг — переписать БЛ на более универсальном и производительном языке/платформе. JS к ним не относится, и вашему знакомому рано или поздно придется это сделать
Вот, собссно, что я хотел сказать.
[quote:3gy970ge]
Мне пока Джава не надоела, наоборот, с выпуском 8 версии, которая поддерживает функциональное программирование, стало гораздо интереснее. Функциональное программирование — это, пожалуй, единственное, что мне нравится в JS.
Я надеюсь, узкоприкладные языки — это вы не про JS.
[/quote:3gy970ge]
js и есть узкоприкладной:) То, что на нем пишут всякое типа node.js — ну так я и веб приложения на с++ видел, всякое бывает. Попробуйте на js какой-нить api написать, чтоб дергать его извне, не из js
K тому же сам node.js написан на с++:)
Жава, конечно, стала всякое поддерживать, но блин, вот действительно нужные вещи как-то через одно место. Ихние лямбды — обнять и плакать. Плюс куча откровенно дурацких решений типа inner classes&enums, странных генериков, еще более странных monads и проч. При этом до сих пор пропертей не удосужились сделать, и кортежей, и динамических типов, inferring types и прочего — всех вот этих мелочей, которые облегчают жизнь
Очень многословный язык, после сишарпа выглядит несколько устаревшим — им приходится волочь за собой просто гигантское legacy. Вот бы оракл стукнул кулаком по столу и сказал — все, со след версии нифига не поддерживаем, делаем все как надо..
Единственное, зачем на ней пишу — это разработка под андроид, т.к. там есть масса новых(для меня) концепций, тот же material design, но сам язык, это даа.. Но выбора нет!:)
[quote="loco":388r2lzo]
эээ
на любом. Но при чем тут фронтэнд?
бизнес логика, типа отрисовка 3д и работa с б-м приличными массивами данных это не фронтэнед. Какое это имеет отношение к UI?
Как-то мы друг друга совсем не понимаем. Представление моделей, сиречь UI — это одно. Обработка и хранение данных — это бизнес логика, back end. Последняя может быть очень ресурсоемкой, и поэтому выполнять ее лучше на клиенте, т.к. там мощностей больше. А раз мы на клиенте, то след. логичный шаг — переписать БЛ на более универсальном и производительном языке/платформе. JS к ним не относится, и вашему знакомому рано или поздно придется это сделать
Вот, собссно, что я хотел сказать.
[/quote:388r2lzo]
То есть вопрос сводится к тому, почему это веб приложение, а не десктоп? Автор объсняет это в самом начале статьи.
[quote:388r2lzo]
js и есть узкоприкладной:) То, что на нем пишут всякое типа node.js — ну так я и веб приложения на с++ видел, всякое бывает. Попробуйте на js какой-нить api написать, чтоб дергать его извне, не из js
K тому же сам node.js написан на с++:)
[/quote:388r2lzo]
Бэк-энд на С++ — это исключение, мы в универе и на С писали, а вот node.js — это Mozilla, Uber, LinkedIn, Netflix и т.д. Если на языке можно писать и клиент, и сервер, и десктопные приложения (JS используют не только в веб приложениях), то как его можно назвать узкоприкладным?
[quote:388r2lzo]
Жава, конечно, стала всякое поддерживать, но блин, вот действительно нужные вещи как-то через одно место. Ихние лямбды — обнять и плакать. Плюс куча откровенно дурацких решений типа inner classes&enums, странных генериков, еще более странных monads и проч. При этом до сих пор пропертей не удосужились сделать, и кортежей, и динамических типов, inferring types и прочего — всех вот этих мелочей, которые облегчают жизнь
Очень многословный язык, после сишарпа выглядит несколько устаревшим — им приходится волочь за собой просто гигантское legacy. Вот бы оракл стукнул кулаком по столу и сказал — все, со след версии нифига не поддерживаем, делаем все как надо..
Единственное, зачем на ней пишу — это разработка под андроид, т.к. там есть масса новых(для меня) концепций, тот же material design, но сам язык, это даа.. Но выбора нет!:)[/quote:388r2lzo]
А вот это уже интересно. Чем вам лямбда не угодила? Чем плохи иннер классы и enums и чем странны генерики? Про monads услышала сейчас впервые, погуглив, нашла, что monads называют Optional. Вам и Optional не угодил? Или есть еще какие-то монады в Джаве? Я не считаю, что Джава — идеальный язык, там куча своих недостатков, в основном как раз legacy. Но в целом вполне достойный. И то, что вы приписали в недостатки, я как раз считаю скорее наоборот.
[quote="Ольга_":332bm0co]
То есть вопрос сводится к тому, почему это веб приложение, а не десктоп? Автор объсняет это в самом начале статьи.[/quote:332bm0co]
В чем смысл именно веб приложения, если он все выгружает на клиента? У меня только одно обьяснение — человек не очень хорошо знает жаву/.нет/с++
То, что написано для клиентов — это маркетинг:)
[quote:332bm0co]
Бэк-энд на С++ — это исключение, мы в универе и на С писали, а вот node.js — это Mozilla, Uber, LinkedIn, Netflix и т.д. Если на языке можно писать и клиент, и сервер, и десктопные приложения (JS используют не только в веб приложениях), то как его можно назвать узкоприкладным?[quote:332bm0co]
Потому что он под это все вышеперечисленное не заточен. Как и c++ под веб
Какие десктопные приложения есть на js? node.js написан на c++, есличо:)
[quote:332bm0co]
А вот это уже интересно. Чем вам лямбда не угодила? Чем плохи иннер классы и enums и чем странны генерики? Про monads услышала сейчас впервые, погуглив, нашла, что monads называют Optional. Вам и Optional не угодил? Или есть еще какие-то монады в Джаве? Я не считаю, что Джава — идеальный язык, там куча своих недостатков, в основном как раз legacy. Но в целом вполне достойный. И то, что вы приписали в недостатки, я как раз считаю скорее наоборот.[/quote:332bm0co][/quote:332bm0co][/quote:332bm0co]
Ламбды очень коряво сделаны, многословно. Это ж функциональщина, она по сути своей лаконична
Иннер класс в жаве имеет доступ к private members класса, куда он вложен — так быть не должно, нарушение принципа приватных мемберов
enum в жаве это не перечисление, а по сути статический класс, и народ с ним извращается по всякому, что делает его совсем не енумом
Монады сделаны, опять-таки, криво. Самая известная, maybe monad в шарпе выглядит как obj?.method(), a в жаве — несколько строчек писать надо, заворачивая обьект в Optional. Это ни разу не функциональное программирование.
Очень многословный язык, и многие вещи сделаны, как бы это сказать.. Громоздко. Т.е., люди добавляют новые фичи на изначально кривую архитектуру, ну и получается тоже не очень.
[quote="loco":u0xg3p4y]
В чем смысл именно веб приложения, если он все выгружает на клиента? У меня только одно обьяснение — человек не очень хорошо знает жаву/.нет/с++
То, что написано для клиентов — это маркетинг:)
[/quote:u0xg3p4y]
Каких клиентов, это статья из научной публикации, это не коммерция, это научные исследования.
Он же написал:
[quote:u0xg3p4y]Web-based visualization tools, on the other hand, present significant benefits in the context of distributed research platforms:
• They can be easily integrated into existing web-based platforms.
• Other than the web browser, no software or libraries need to be installed.
• If a visualization doesn’t require the entirety of a remote dataset at once, it can load required data on-demand, potentially saving bandwidth.[/quote:u0xg3p4y]
[quote="loco":u0xg3p4y]
Потому что он под это все вышеперечисленное не заточен. Как и c++ под веб
Какие десктопные приложения есть на js? node.js написан на c++, есличо:)
[/quote:u0xg3p4y]
Как раз node.js, в отличие от с++, именно под это и заточен.
Все интерпретируемые языки написаны на с или с++, и что с того?
[quote:u0xg3p4y]
Ламбды очень коряво сделаны, многословно. Это ж функциональщина, она по сути своей лаконична
Иннер класс в жаве имеет доступ к private members класса, куда он вложен — так быть не должно, нарушение принципа приватных мемберов
enum в жаве это не перечисление, а по сути статический класс, и народ с ним извращается по всякому, что делает его совсем не енумом
Монады сделаны, опять-таки, криво. Самая известная, maybe monad в шарпе выглядит как obj?.method(), a в жаве — несколько строчек писать надо, заворачивая обьект в Optional. Это ни разу не функциональное программирование.
Очень многословный язык, и многие вещи сделаны, как бы это сказать.. Громоздко. Т.е., люди добавляют новые фичи на изначально кривую архитектуру, ну и получается тоже не очень.[/quote:u0xg3p4y]
Что значит коряво? Нормальные лямбды, это же не Lisp, в конце концов. Очень лаконично все. Optional в Джаве — всего лишь опция избегать возвращения null, никто не считает это частью функционального программирования, не надо ему приписывать ничего сверхъестественного.
[quote="loco":n5317aq6]
Какие десктопные приложения есть на js? node.js написан на c++, есличо:)
[/quote:n5317aq6]
Почитайте про Electron framework от GitHub. В числе прочего, на нем написан Slack
[quote="вилли баранкин":2b1yv09z][quote="loco":2b1yv09z]
Какие десктопные приложения есть на js? node.js написан на c++, есличо:)
[/quote:2b1yv09z]
Почитайте про Electron framework от GitHub. В числе прочего, на нем написан Slack[/quote:2b1yv09z]
почитал
как-то он выглядит практически уже как универсальные языки. А тогда какой в нем смысл
слаковское десктопное приложение, кстати, ужасно — жрет память как не в себя, и все время падает
О чем я и говорю — либо язык мутирует в еще один универсальный, и уже не будет таким простым, либо будет неприспособлен для подобных задач
пс Рассуждения о кроссплатформенности отдельно рассмешили
[quote="Ольга_":17l95dug]
[quote:17l95dug]Web-based visualization tools, on the other hand, present significant benefits in the context of distributed research platforms:
• They can be easily integrated into existing web-based platforms.
• Other than the web browser, no software or libraries need to be installed.
• If a visualization doesn’t require the entirety of a remote dataset at once, it can load required data on-demand, potentially saving bandwidth.[/quote:17l95dug][/quote:17l95dug]
Это все понятно, это стандартные преимущества веб-приложения
Я ж уже говорил про это — как только начнутся тяжелые вычисления и работа с памятью, придется переползать на клиент. А там получается, что еще выгоднее использовать какой-нить универсальный язык.
Давайте годик-два подождем, и посмотрим?
[quote:17l95dug]Что значит коряво? Нормальные лямбды, это же не Lisp, в конце концов. Очень лаконично все.[/quote:17l95dug]
Коряво — значит в сравнении с
Посмотрите, как это сделано в других языках
[quote:17l95dug]Optional в Джаве — всего лишь опция избегать возвращения null, никто не считает это частью функционального программирования, не надо ему приписывать ничего сверхъестественного.
[/quote:17l95dug]
Это не опция. Это не очень удавшаяся попытка реализовать насквозь функциональные монады средствами ооп
Как это не часть функционального программирования? Монады это и есть функциональное программирование, по сути своей.
У нас довольно бессмысленный спор получается, т.к., насколько я понимаю, вы знакомы только с js и java, и мои примеры из других языков просто не работают.
При этом, я допускаю, что может я чего не вижу, т.к. жаву знаю не очень хорошо. Пишу только о том что вижу
пс Больше всего меня бесило отсутствие чего-то вроде linq — каждый раз писать foreach, или имплементировать comparable чтоб найти значение это ж ужас какой-то. В конце концов написал класс —
public final class ListExtension
{
@Nullable
public static <T> T find(List<T> array, com.android.internal.util.Predicate<T> equalityPredicate)//тоже, кстати, корявоватое обьявление дженерика
{
if(array == null || equalityPredicate == null)
return null;
for (T e : array)
{
if(equalityPredicate.apply(e))
return e;
}
return null;
}
}
Использование
final MyClass found = ListExtension.find(myList, new Predicate<MyClass>() {
@Override
public boolean apply(MyClass obj)
{
return obj.getId() == someConst;
}
});
Но это все равно ужас
в дотнете это выглядит как
var found = myList.FirstOrDefault(l => l.getId() == some const);
[quote="loco":1a997gp7]
Это все понятно, это стандартные преимущества веб-приложения
Я ж уже говорил про это — как только начнутся тяжелые вычисления и работа с памятью, придется переползать на клиент. А там получается, что еще выгоднее использовать какой-нить универсальный язык.
Давайте годик-два подождем, и посмотрим?
[/quote:1a997gp7]
Да на какой клиент переползет, вы знаете, сколько памяти надо только для одного MRI снимка? Эта визуализация работает с distributive systems. Уже 3 года прошло, давайте подождем еще хоть 10.
[quote:1a997gp7]
Коряво — значит в сравнении с
Посмотрите, как это сделано в других языках
[/quote:1a997gp7]
В других функциональных языках? Джава изначально не чисто функциональный язык, у нее есть свои ограничения, которые приходится учитывать. Я считаю, что с лямбда удобно работать и ничего там корявого нет (в самой лямбде).
[quote:1a997gp7]
Это не опция. Это не очень удавшаяся попытка реализовать насквозь функциональные монады средствами ооп
Как это не часть функционального программирования? Монады это и есть функциональное программирование, по сути своей. [/quote:1a997gp7]
Ну конечно, вы знаток, я смотрю. Optional — это опция избегать NullPointerException. То, что он обладает свойствами монады — так это потому, что используется в фунцкиях, то есть это уже второстепенное свойство для использования в функциональном программировании. Я использую Optional в основном в обычном ООП, там его монадные свойства вообще не нужны.
[quote:1a997gp7]У нас довольно бессмысленный спор получается, т.к., насколько я понимаю, вы знакомы только с js и java, и мои примеры из других языков просто не работают.
При этом, я допускаю, что может я чего не вижу, т.к. жаву знаю не очень хорошо. Пишу только о том что вижу[/quote:1a997gp7]
Я знакома помимо Java и JS (то есть когда-то что-то писала на них) с SML, OCaml, Haskell, Scala, Python, C, C++, Perl, PHP, MATLAB, R, Visual Basic.
[quote:1a997gp7]пс Больше всего меня бесило отсутствие чего-то вроде linq — каждый раз писать foreach, или имплементировать comparable чтоб найти значение это ж ужас какой-то. В конце концов написал класс —
public final class ListExtension
{
@Nullable
public static <T> T find(List<T> array, com.android.internal.util.Predicate<T> equalityPredicate)//тоже, кстати, корявоватое обьявление дженерика
{
if(array == null || equalityPredicate == null)
return null;
for (T e : array)
{
if(equalityPredicate.apply(e))
return e;
}
return null;
}
}
Использование
final MyClass found = ListExtension.find(myList, new Predicate<MyClass>() {
@Override
public boolean apply(MyClass obj)
{
return obj.getId() == someConst;
}
});
Но это все равно ужас
в дотнете это выглядит как
var found = myList.FirstOrDefault(l => l.getId() == some const);
[/quote:1a997gp7]
В Java 8 для этого есть stream:
boolean found = myList.stream().anyMatch(el -> el.getId() == someConst);
Выучите хотя бы основной функционал Java, а потом жалуйтесь, какая она плохая.
[quote="Ольга_":p26xi2ld]
Да на какой клиент переползет, вы знаете, сколько памяти надо только для одного MRI снимка? Эта визуализация работает с distributive systems. Уже 3 года прошло, давайте подождем еще хоть 10.
[/quote:p26xi2ld]
T.e., приложение используется все также — js из браузера?
Значить, не те там обьемы
Чудес не бывает
[quote:p26xi2ld]
В других функциональных языках? Джава изначально не чисто функциональный язык, у нее есть свои ограничения, которые приходится учитывать. Я считаю, что с лямбда удобно работать и ничего там корявого нет (в самой лямбде). [/quote:p26xi2ld]
В других _универсальных_ языках
[quote:p26xi2ld]
Ну конечно, вы знаток, я смотрю. Optional — это опция избегать NullPointerException. То, что он обладает свойствами монады — так это потому, что используется в фунцкиях, то есть это уже второстепенное свойство для использования в функциональном программировании.[/quote:p26xi2ld]
Да, в сравнении с вами — знаток.
Суть maybe monad — возвращаем либо результат функции, либо null. Помогает избежать кучи if-ov(functional is stateless), а не нулл ексепшен. Вы почитайте по функциональщине, прежде чем рассказывать, что это такое
Н-да. "Обладает свойствами монады". A в документации пишут, что это монада и есть
[quote:p26xi2ld]Я знакома помимо Java и JS (то есть когда-то что-то писала на них) с SML, OCaml, Haskell, Scala, Python, C, C++, Perl, PHP, MATLAB, R, Visual Basic. [/quote:p26xi2ld]
Таки знакомы, или плотно работали — по 2 года мин на каждом? Если нет, то это именно что "знакома". А я с Трюдо знаком — видел его по телевизору
[quote:p26xi2ld]
В Java 8 для этого есть stream:
boolean found = myList.stream().anyMatch(el -> el.getId() == someConst);
Выучите хотя бы основной функционал Java, а потом жалуйтесь, какая она плохая.[/quote:p26xi2ld]
dalvik это пока не поддерживает, потому и не знаю/не пользовался — о чем сразу написал.
Это раз
Два — я не жалуюсь, я прямо говорю — многие программные концепции в жаве громоздки и неоптимальны, просто потому что базируются на древней архитектуре языка. Взять те же массивы, коллекции-дженерики — внутри-то они все те же массивы, с дурацким боксингом/анбоксингом. Или взять те же виртуальные функции
Ну и что в оракле к 8-й жаве сподобились таки сделать некое подобие линка, который в доднете появился еще в 2007 году, о чем-то говорит
[quote="loco":fleh8ca6]
T.e., приложение используется все также — js из браузера?
Значить, не те там обьемы
Чудес не бывает
[/quote:fleh8ca6]
Клиент получает информацию порционно, только то, что ему надо в данный момент.
[quote:fleh8ca6]
Да, в сравнении с вами — знаток.
Суть maybe monad — возвращаем либо результат функции, либо null. Помогает избежать кучи if-ov(functional is stateless), а не нулл ексепшен. Вы почитайте по функциональщине, прежде чем рассказывать, что это такое
Н-да. "Обладает свойствами монады". A в документации пишут, что это монада и есть
[/quote:fleh8ca6]
Я знаю, что такое монада. Я вам еще раз повторяю — цель создания класса Optional — это способ избегать null. Вот вы в своем примере постоянно возвращаете null — а это плохо, лучше возвращать Optional.empty(). То, что она монада — потому что ее используют в функциях, то есть в библиотеках Java, поддерживающих функциональное программирование. Ее не создавали изначально как "попытка реализовать насквозь функциональные монады средствами ооп", ее создавали для того, чтобы избегать NullPointerExcetion. И класс используется не только в функциональном, но и в ООП.
[quote:fleh8ca6]
Таки знакомы, или плотно работали — по 2 года мин на каждом? Если нет, то это именно что "знакома". А я с Трюдо знаком — видел его по телевизору
[/quote:fleh8ca6]
Вы сами изначально сказали: "насколько я понимаю, вы знакомы только с js и java". Я и объяснила, с чем я еще знакома.
[quote:fleh8ca6]
dalvik это пока не поддерживает, потому и не знаю/не пользовался — о чем сразу написал.
Это раз
Два — я не жалуюсь, я прямо говорю — многие программные концепции в жаве громоздки и неоптимальны, просто потому что базируются на древней архитектуре языка. Взять те же массивы, коллекции-дженерики — внутри-то они все те же массивы, с дурацким боксингом/анбоксингом. Или взять те же виртуальные функции
Ну и что в оракле к 8-й жаве сподобились таки сделать некое подобие линка, который в доднете появился еще в 2007 году, о чем-то говорит[/quote:fleh8ca6]
Ну так если какая-то VM не поддерживает весь функционал языка, это не значит, что язык плохой. На C# вообще нельзя писать приложения для мобильных, но я же не говорю, какой корявый язык этот ваш C#.
[quote="loco":xukc7lxu]
Да, в сравнении с вами — знаток.
[/quote:xukc7lxu]
Вы сами ничего конкретного не сказали.
— Лямбда у Джавы — корявые.
— Почему?
— Ну вы сравните с другими языками.
Я сравниваю, и не обнаруживаю никакой корявости. Вы даете пример на C# — я показываю тот же пример на Java. Минимальные отличия в синтаксисе. И тем не менее Java все равно корявая.
Хотя бы раз согласились, что не правы и пошли бы почитали Java API и какие библиотеки есть для VM, не поддерживающих stream, а не продолжать здесь упорно демонстрировать свой дилетантизм. Когда будете знакомы с Java не как с Трюдо, а как с собственной женой, тогда и продолжим, а пока конструктивного диалога не получится, все скатывается к банальному троллингу.
[quote:f21m2fj8]Клиент получает информацию порционно, только то, что ему надо в данный момент.[/quote:f21m2fj8]
я про 3д говорил
там не бывает "порционно"
[quote:f21m2fj8]Я знаю, что такое монада. Я вам еще раз повторяю — цель создания класса Optional — это способ избегать null[/quote:f21m2fj8]
Если знаете, зачем такое говорите? Цель не избегать нул, цель — быть stateless, т.е., грубо говоря, избегать проверки состояния обьекта(нул или нет), по крайней мере снаружи
[quote:f21m2fj8]Вот вы в своем примере постоянно возвращаете null — а это плохо, лучше возвращать Optional.empty().[/quote:f21m2fj8]
Это философский вопрос
[quote:f21m2fj8]ее создавали для того, чтобы избегать NullPointerExcetion.[/quote:f21m2fj8]
Что же мешает делать то же самое посредством if(obj != null), раз так?
[quote:f21m2fj8]Вы сами изначально сказали: "насколько я понимаю, вы знакомы только с js и java". Я и объяснила, с чем я еще знакома. [/quote:f21m2fj8]
я имел в виду "профессионально знакома", т.е. опыт работы по 2 года в среднем на язык, это минимум.
Иначе это ни о чем, как у меня с жавой — я на ней б-м плотно сижу где-то с полгода(хотя до этого сталкивался), и полагаю, что про язык знаю совсем мало, кроме указанных отличий, которые бросаются в глаза в сравнении. Т.е., понятно, что многие концепции похожи, и есть интересные моменты, но тем не менее
[quote:f21m2fj8]Ну так если какая-то VM не поддерживает весь функционал языка, это не значит, что язык плохой. На C# вообще нельзя писать приложения для мобильных, но я же не говорю, какой корявый язык этот ваш C#.[/quote:f21m2fj8]
сишарп не корявый:) Как раз таки они сперва брали пример с жавы, в том числе внимательно смотрели, что там сделано нехорошо. И в результате получилась очень толковая концепция языка.
Второй момент — сишарп проектировался изначально одной командой(а не коммьюнити), причем с очень светлой головой во главе, создателем bpl, и получился очень продуманным, что позволило делать самые разнообразные вещи без оглядки на legacy. С теми же массивами — в первой версии все было как в жаве, boxing/unboxing hell; во второй они сделали дженерики и принципиально новые коллекции, в новых неймспейсах. Хочешь — пользуйся старыми, хочешь — новыми.
а то, что МС про ээ любила мобильный рынок — стыд им и позор, я даже не представляю, КАК это можно было сделать, имея лидирующую по сути позицию. Огромное разочарование, вопщем
[quote="Ольга_":rk6tjyk3]
Я сравниваю, и не обнаруживаю никакой корявости. Вы даете пример на C# — я показываю тот же пример на Java. Минимальные отличия в синтаксисе. И тем не менее Java все равно корявая. [/quote:rk6tjyk3]
Хорошо, с т.з. синтаксиса все неплохо
Плохо с closures
[quote:rk6tjyk3]Хотя бы раз согласились, что не правы и пошли бы почитали Java API и какие библиотеки есть для VM, не поддерживающих stream, а не продолжать здесь упорно демонстрировать свой дилетантизм. [/quote:rk6tjyk3]
Где-то я, понятно, могу быть неправ
Но весь мой опыт показывает, что таких случаев не так уж много.
Вы вот, к примеру, упорно утверждаете, что js не менее мощный язык, чем универсальные — c#/c++/java. С моей т.з. это очевидное дилетантство, проистекающее из факта владения только одним языком. Но я вас дилетантом не называю, правда?
А! А еще меня бесит фигурная скобка(открытие блока) на той же линии!!! Граждане, у нас уже большие мониторы, можно переносить!!!
[quote="loco":1p6a71zy]
Если знаете, зачем такое говорите? Цель не избегать нул, цель — быть stateless, т.е., грубо говоря, избегать проверки состояния обьекта(нул или нет), по крайней мере снаружи[/quote:1p6a71zy]
Вот вы упрямый, это же надо.
There’s a new feature in Java 8 called the Optional class which is supposed to cure NullPointerExceptions.
https://dzone.com/articles/java-8-optional-whats-point
В последний раз — цель Optional — избегание null values. Он создавался именно для этого. Optional.empty — это тоже состояние объекта и вы его проверяете, if Optional.isPresent(). Просто если вы используете Optional, у вас никогда не будет NullPointerException, потому что объект всегда есть, хоть и пустой.
[quote:1p6a71zy][quote:1p6a71zy]Вот вы в своем примере постоянно возвращаете null — а это плохо, лучше возвращать Optional.empty().[/quote:1p6a71zy]
Это философский вопрос
[quote:1p6a71zy]ее создавали для того, чтобы избегать NullPointerExcetion.[/quote:1p6a71zy]
Что же мешает делать то же самое посредством if(obj != null), раз так?[/quote:1p6a71zy]
Это не философский вопрос, это прямое назначение Optional — возвращать Optional в тех случаях, когда объекта может не быть. Не все постоянно проверяют if obj == null, NullPointerException — одно из самых распространенных исключений из-за ошибок программистов. Optional заставляет программстов всегда возвращать объект, хоть и пустой.
[quote:1p6a71zy]
я имел в виду "профессионально знакома", т.е. опыт работы по 2 года в среднем на язык, это минимум.
Иначе это ни о чем, как у меня с жавой — я на ней б-м плотно сижу где-то с полгода(хотя до этого сталкивался), и полагаю, что про язык знаю совсем мало, кроме указанных отличий, которые бросаются в глаза в сравнении. Т.е., понятно, что многие концепции похожи, и есть интересные моменты, но тем не менее
[/quote:1p6a71zy]
У меня нет, конечно, такого опыта, но функциональные языки я изучала год в универе, очень подробно, чисто функциональные SML и OCaml. Потом год писала на Scala, функциональные языки — это вообще моя слабость, Javа я знаю достаточно хорошо, поэтому я могу судить, насколько коряво или нет написаны библиотеки, поддерживающие функциональное программорование на Java. С С# не сравниваю, потому что С# не знаю.