Группа исследователей в области искусственного интеллекта анонсировала проект pix2code (https://uizard.io/research#pix2code), в рамках которого развивается идея по созданию генератора кода, воссоздающего макет интерфейса пользователя, изображённого на скриншоте. По мнению разработчиков проект упростит работу дизайнеров интерфейса, который смогут реализовать свои задумки в форме графических макетов, а pix2code даст возможность сформировать на основе предложенных картинок готовый каркас кода, требующий минимальный правок для создания рабочего прототипа приложения.В процессе генерации кода используется абстрактный предметно-ориентированный язык, который затем преобразуется в представление на языке целевой системы. Данный подход позволяет генерировать код для построения интерфейса для различных платформ и языков. В данный момент обеспечена поддержка воссоздания кода для web-приложений и мобильных приложений для платформ iOS и Android.
В основе pix2code лежит система машинного обучения, натренированная на реальных образцах приложений. Модель для обучения построена на основе примерно 90 тысяч примеров мобильных приложений и 140 тысяч примеров web-интерфейсов. На текущей стадии разработки уже удалось добиться воссоздания интерфейса на основе скриншота с 77% точностью. В ближайшее время связанные с проектом наборы данных и готовую модель для генерации кода планируется опубликовать (https://github.com/tonybeltramelli/pix2code) на GitHub под лицензией Apache 2.0.
URL: https://news.ycombinator.com/item?id=14416530
Новость: http://www.opennet.me/opennews/art.shtml?num=46603
Можно и микроскопом гвозди забивать.
> идея по созданию генератора кода, воссоздающего макет интерфейса пользователя, предложенного на скриншотеПо-моему хрень. Макет интерфейса надо представлять в виде макета, а не в виде проекции на холст который статичен. Если развить идею дальше то макет интерфейса + динамика даст...видеофайл?
>> идея по созданию генератора кода, воссоздающего макет интерфейса пользователя, предложенного на скриншоте
> По-моему хрень. Макет интерфейса надо представлять в виде макета, а не в
> виде проекции на холст который статичен. Если развить идею дальше то
> макет интерфейса + динамика даст...видеофайл?который будет показываться пользователю вместо сайта....
Бизнес фишинговых сайтов оценит инициативу, возможно они и оплачивают ;)
А смысл? Я не понимаю, почему фишинговые сайты просто не берут html-код и стили и скрипты исходного. Будет 1 в 1 и никаких визуальных отличий. Они же вроде и так преступники, с чего бы им копирайт соблюдать?
У них проблема не в копирайте, а в самом копировании. В исходных сайтах часто попадается защита от копирования и программные ошибки, которые мешают копировать сайт, например, есть сайты со сторонними скриптами, Flash даже у серьёзных организаций, есть сайты которые даже после сохранения в локальный файл не открываются из него. Всё это нужно исправлять руками и специальными инструментами, но автоматически всё не исправить. А тут предлагается автоматизация.
Qt и QML теперь будут на помойке истории. Эта штука интереснее.
Для кого? Для программеров или для мартышек за клавиатурой?
Скорее второе. Генераторы вам нагенерят простыней из кода. Такими темпами скоро и 32гига оперативы будет мало, что бы запустить какую ни будь простенькую программулинку.
Будущее принадлежит мартышкам.
Если взять триллион мартышек, и посадить из за клаву, то они напишут DOS!
> Если взять триллион мартышек, и посадить из за клаву, то они напишут
> DOS!Они напишут DDOS!!!
Ваш Кэп :)))
Да они никогда не станут популярными. Это как в ворде делать сайты.
> Да они никогда не станут популярными. Это как в ворде делать сайты.Да и в Adobe Muse сайты тоже получаются шлаком...
Автоматические генераторы вебсайтов- все поголовно - хня....
Скажите это пользователям Жумлы и Вордпрессов
Я - пользователь вордпресса. Своё постит, нагрузку как-то держит, мозг не сношает. Так почему нет?
А почему не как в Delphi или Qt Creator?
Потому как скриншот/скан, в общем случае, не содержит достаточной информации о макете.
* Лучше бы они написали графический конструктор интерфейса на абстрактном языке. Сама по себе развязка инструмента для дизайна и IDE — вовсе не плохая идея.
С точностью до наоборот. Данная штука избавит от еще одной рутины, которой иногда надо заниматься и освободит время для написания кода, реализующего логику, а не создающего интерфейс. И никакого повышенного потребления тоже не будет. В конце концов ничего не мешает написать свой генератор кода для целевого UI тулкита/фреймворка из их абстрактного представления. А вот работа части "мартышек за клавиатурой" действительно станет неактуальной.
> С точностью до наоборот. Данная штука избавит от еще одной рутины, которой
> иногда надо заниматься и освободит время для написания кода, реализующего логику,
> а не создающего интерфейс. И никакого повышенного потребления тоже не будет.
> В конце концов ничего не мешает написать свой генератор кода для
> целевого UI тулкита/фреймворка из их абстрактного представления. А вот работа части
> "мартышек за клавиатурой" действительно станет неактуальной.Обычно логику приложения и интерфейс пишут вообще говоря разные люди :)
Как мимимум для android/ios это, как правило, одни и те же люди.
Угу, особенно если приложение пишет один человек или небольшая команда. Или тех, кто не работает в корпорации на 1000+ человек, вы за программистов не считаете?
Ага, конечно... То-то часто в Qt приходится игнорировать QML в пользу полного контроля за процессом генерации интерфейса... Особенно вредны такие штуки в тех случаях, когда интерфейс сам генерится "на лету" на основании входных данных. А ещё... сейчас я скажу такую крамолу, которую нельзя всуе перед новаторами произносить — разъярённо затопчут на месте, как врага народа)))... ещё оно абсолютно бесполезно для построения эффективных связей "модель — абстракция", когда интерфейс черпает данные из некоей модели данных, общей для разных его частей) Я прямо-таки слышу истошные гневные вопли и топот разъярённой толпы "модных программистов")))
Там он и так автоматом генерируется, без подобных штуковин. А за нестандартные интерфейсы (прибитые гвоздями "гением-автором", а не те, что хозяин под себя настроил) надо сжигать на костре.
Аналогично: абсолютно безответственных пальце-мышко-тыкателей надо гнать из программеров поганой метлой. Я же говорю: QML обхожу стороной и не потому, что охота весь этот код писать самому, а потому, что работа с указателями позволяет вообще выгрузить из памяти ненужную часть интерфейса и вгрузить свою на основании полученных данных. А код, написанный любителями копи-пасты и черезмерной автоматизации вызывает рвотный рефлекс. Это же насколько ТУПЫМИ надо стать, чтобы вот ЭТОМУ радоваться? Абстракция — это хорошо, но не до такой же степени...
Просто представь, что у тебя 15 вариантов интерфейса и ещё с десяток вариантов всяких мелочей в каждом и ты хочешь оттестировать их прежде чем полноценно реализовывать хоть один из оных. Будешь ли ты прорабатывать их все до мелочей, выверяя код до идеала, если 14 вариантов ты потом просто выкинешь?
> Просто представь, что у тебя 15 вариантов интерфейса и ещё с десяток
> вариантов всяких мелочей в каждом и ты хочешь оттестировать их прежде
> чем полноценно реализовывать хоть один из оных. Будешь ли ты прорабатывать
> их все до мелочей, выверяя код до идеала, если 14 вариантов
> ты потом просто выкинешь?А теперь давай выпрямим нормально причинно-следственные связи и трезво посмотрим на всю проблему. Я описал ситуацию, в которой такое, вот, автоматическое построение просто-напросто не работает.
Три пункта:
1) Регенерация интерфейса;
2) Формирование оного в соответствии с набором данных;
3) Связь интерфейса с моделью данных;Что надо делать:
1) Организовать возможность проектирования подгружаемых частей интерфейса и API для их загрузки/выгрузки;
2) Обеспечить поддержку шаблонов интерфейса и API для их использования и передачи им указателей на источники данных;
3) Реализовать возможность мнемонического/графического сопоставления GUI с моделью;Всё. Вся проблема решится на корню, не оставив причин отказываться от автопроектирования. Но нет, мы будем спорить, чья мода креативнее/прогрессивнее, ведь это проще, чем решать возникающие задачи... Мода... Чтоб она сдохла...
Ещё раз. Если у тебя есть метаданные, на основе которых ты можешь сгенерировать гуй - оно тебе и так не надо. Если же гуй задан дизайнером - чего ради морочить голову и ручками его рисовать, если можно те же метаданные получить? А чтобы оно память лишнюю не жрало - об этом фреймворк/тулкит должен заботиться, а не разработчик приложения костылить.
> Если же гуй задан дизайнером - чего ради морочить голову и ручками его
> рисовать, если можно те же метаданные получить?Так не получишь - обязательно будет глючить, т.к. это же изначально разрабатывается как нечёткая штука. Т.е. ты нарисуешь, оно переведёт в код нормально, потом перерисуешь - переведёт в код несколько не так, как ты хочешь. Пойдёшь разбираться почему, и умрёшь не доходя до кассы.
Ну значит недопилено, делов-то. А после допила - будет "ну не так, как хотел, но в целом приелемо, и соответствует гайдлайнам", в отличие от попыток товарища выше сделать всё по-своему.
> Ну значит недопилено, делов-то. А после допила - будет "ну не так,
> как хотел, но в целом приелемо, и соответствует гайдлайнам", в отличие
> от попыток товарища выше сделать всё по-своему.А потом приходит ТЗ от будущих пользователей, которым с большой колокольни начихать на взгляды программистов. У них свои мотивы, положенные на опыт каждодневного использования ПО, своя специфика данных и работы с ними. Им вообще до ядрёной кочерыжки какие-либо гайдлайны, им работать надо, а не подстраиваться под какое-то там сообщество!
> Ну значит недопилено, делов-то. А после допила - будет "ну не так,
> как хотел, но в целом приелемо, и соответствует гайдлайнам", в отличие
> от попыток товарища выше сделать всё по-своему.Если ты ставишь нейросети и нечёткую логику на допиливание, то количество таких "насяльника, я не поняла, что это должна быть кнопка, а не две" будет зашкаливающим. Многие из них будут скрытыми - работает в 99% случаев, а в 1% получается какой-то ну совершенный ахтунг.
И, в результате, твой процесс допила займёт больше, чем процесс написания на нормальном языке с 0-я.
> Ещё раз. Если у тебя есть метаданные, на основе которых ты можешь
> сгенерировать гуй - оно тебе и так не надо. Если же
> гуй задан дизайнером - чего ради морочить голову и ручками его
> рисовать, если можно те же метаданные получить? А чтобы оно память
> лишнюю не жрало - об этом фреймворк/тулкит должен заботиться, а не
> разработчик приложения костылить.Решения разработчика фреймворка воспринимаются вштыки, т.к. ломают на корню логику более высокого уровня, коей и является данный проект. Стоит разработчику фреймворка позаботиться об удобстве программистов, как "модные перцы" начнут его заливать потоками экскрементов, ведь оказывается, что их чаянья, на самом деле, бесполезны)
Не, не так. Вся гуёвая логика должна быть жёстко прибита к тулкиту и гайдлайнам, которым и следует генератор. Всё остальное - от лукавого, так как нарушает предсказуемость и унификацию интерфейса с точки зрения пользователя.As for me - гуй не просто надо генерировать, в него вообще нельзя программмистам давать ручками лезть.
> Не, не так. Вся гуёвая логика должна быть жёстко прибита к тулкиту
> и гайдлайнам, которым и следует генератор. Всё остальное - от лукавого,
> так как нарушает предсказуемость и унификацию интерфейса с точки зрения пользователя.
> As for me - гуй не просто надо генерировать, в него вообще
> нельзя программмистам давать ручками лезть.Такой подход работает ровно до тех пор, пока в интерфейс не начинают подмешиваться специализированные "виджеты", требующие своей логики реакции. В этих ситуациях стандартное поведение GUI как минимум неудобно, как максимум доводит пользователя до бешенства.
Собственно, кто сказал, что это поведение самое адекватное и универсальное? Именно потому остаётся право на переделку. А если следовать "As for me", тогда просто появятся фреймворки для фреймворков, ломающие данные ограничения нафиг.
Один из примеров, который всплывает в уме - прокрутка QScrollArea с виджетами внутри. По стандартной логике скроллбар появляется поверх канваса внутри границ виджета, перегораживая нахрен содержимое. Установка отступов — это дурно пахнущий кодинг, ибо вся задумка дизайна летит к собачьему роду под хвост. Особенно, если содержимое виджета переменно.
Работа с кодом напрямую позволяет делегировать скроллбар из виджета в соседнюю ячейку лэйота, вынеся его отдельно. Ровным счётом НИКАКИХ ПРОБЛЕМ у пользователя такой фокус не вызывает, но картина становится приятной и красивой, сохраняя все привычные очертания.
И что теперь? Вот это запрещать? Да, я переделываю по-своему, но кто сказал, что дефолтный вариант истинно верный?
поэтому у таких подходов интерфейс быстрый но не красивый, а народу ещё важна эстетика;)
> поэтому у таких подходов интерфейс быстрый но не красивый, а народу ещё
> важна эстетика;)Потому эстетика дизайна должна цениться на равных с эстетикой кода. Вместо перетягивания каната эти группы разрабов должны договариваться. Т.е. дизайнер придумал такую, вот, штуку, как выше, пошёл к разработчикам средств автогенерации интерфейса и тем, кто пользует фреймворк, да спросил, как оно им? Нужно ли что-то учесть?
Но ему НАПЛЕВАТЬ... У него творческий порыв летит вперёд быстрее логики. Ему, во что бы то ни стало, надо срочно реализовать затеянное, чтобы "сразить" других, повысив самооценку. Ему некогда вылизывать свою идею...
Нет такого понятия как "эстетика кода", а кто ее придумал - это уже другой вопрос. Вся ваша эстетика - как ваш код выглядит в блокноте. Другое дело - интерфейсы. Именно их все видят и эстетически оценивают.
Мало того, что некрасивый - оно почти всегда ломает ожидания пользователя, потому что подобные штуки в куче нюансов ведут себя совсем не так, как стандартные контролы/группы контролов.
Ты можешь в QML работать с указателями и выгружать куски UI, в которых в данный момент не нуждаешься.
> Ты можешь в QML работать с указателями и выгружать куски UI, в
> которых в данный момент не нуждаешься.Можно, но я не могу туда вгрузить "кусок GUI", сгенерённый по данным, как это делается в случае ВЕБ-а. Это приходится делать "руками".
Можешь. Есть куча способов и все зависит от задачи. Помимо всего абсолютно того же, что ты можешь сделать в вебе, ты так же можешь пронаследоваться от итема в плюсах и нарисовать все что тебе вздумается.
Странное заявление. У тебя есть полный контроль и при использовании QML.
Для тех и для тех это начало конца. 32 гб оперативы стоят копейки, учитывая, что мартыху-верстальщика можно не кормить. А потом и программиста.
Где эти программисты обитают и какие программы они разрабатывают? Все графические программы (и не только) тяжелеют с каждой версией. Видать программеры деградируют в сторону макак.
> Где эти программисты обитают и какие программы они разрабатывают? Все графические программы
> (и не только) тяжелеют с каждой версией. Видать программеры деградируют в
> сторону макак.Рынок труда говорит им, что запах кода не играет столь важной роли, как скорость его написания. Заказчик часто выбирает не тот вариант, где сделают нормально, а тот, где он будет прав. Это ему важнее. А в будущих проблемах всегда можно обвинить исполнителей.
А откуда следует, что оно в дальнейшем не научится генерить код на QML?
Сразу видно, что вы не сильно в курсе про возможности QML.
> Qt и QML теперь будут на помойке истории. Эта штука интереснее.Скорее наоборот, для сабжа сделают транслятор в QML, после чего тот победно зашагает по планете.
что-то подобное я слышал, когда мартышкам показали, что можно сайты в Word'е делать :D
У тех мартышек уже дети выросли - вэб-макаками служат.
Очень интересная идея! Да и программист скоро перестанет существовать как класс, так как каждый будет обладать этим навыком. Будущее без этого просто невозможно!
Люди умеют шить уже тысячелетия, однако я не замечаю этого навыка в совершенстве у каждого встречного. То же касается строительства, металлургии, любой инженерной области. Программировать должно уметь меньшинство, чтобы упрощать жизнь большинству. Если в будущем для работы элементарного терапевта или бухгалтера им будет необходимо уметь запрограммировать своё рабочее пространство, это лишь значит, что кто-то не доделал свою работу по разработке простого интерфейса для специалистов.
Вы путаете теплое с мягким или просто не понимаете о чем идет речь.
Совершенно верно.
> Если в будущем для работы элементарного терапевта или бухгалтера им будет необходимо уметь запрограммировать своё рабочее пространство, это лишь значит, что кто-то не доделал свою работу по разработке простого интерфейса для специалистов.Да, если в будущем для работы элементарного терапевта или бухгалтера им будет необходимо настроить яркость монитора, это лишь значит, что кто-то не доделал свою работу по настройке яркости монитора.
Вообще-то да. Если мониторы не устареют как класс, то рано или поздно кто-нибудь да разработает монитор, который будет подстраивать яркость самостоятельно в зависимости от того кажется ли вам текущее значение корректным или нет. Идеальный интерфейс должен работать максимально незаметно для пользователя. Если какой-то элемент без веских на то оснований требует внимания от пользователя, то кто-то действительно не доделал свою работу.
Естественно это не значит, что у такого монитора не должно быть возможности настроить яркость вручную, но объективных причин туда лезть у пользователя быть не должно.
>рано или поздно кто-нибудь да разработает монитор, который будет подстраивать яркость самостоятельно в зависимости от того кажется ли вам текущее значение корректным или нет.А потом в него посмотрят одновременно 2 или 3 человека и монитор разорвет от натуги сделать всем збсъ.
>Идеальный интерфейс должен
Идеальный интерфейс существует только в мире розовых пони и безмозглых детишек.
Зачем? Реагировать на хозяина, остальные - что видят то видят. Второй (и лучший) вариант - очки или контактные линзы-проекторы, хочешь кому-то показать - транслируй ему экран. Вероятно, к тому и придёт.Я к тому, что это "вообще идеальным" интерфейс быть не может. А "идеальным для хозяина" может и должен.
> А потом в него посмотрят одновременно 2 или 3 человека и монитор
> разорвет от натуги сделать всем збсъ.Почему он должен реагировать на кого-то иного? Система знает, кто залогинился — под него и подстраивается.
> Идеальный интерфейс существует только в мире розовых пони и безмозглых детишек.
«Идеал - это путеводная звезда. Без нее нет твердого направления, а нет направления - нет жизни.» Лев Николаевич Толстой
Обычно идеал невозможно достичь, но это не значит, что к нему не нужно стремиться.
не надо забывать что в отличии от терапевта или бухгалтера, конечная цель программиста оставить без работы всех остальных в том числе даже терапевта
В идеале в том числе и самого себя.
Уж не учителя ли информатики сделают каждого программистом?
А программирование - это не только интерфейсы для мартышек, это и то, что под капотом. И такую систему (которая сама будет мысли мартышек угадывать) должны будут написать программисты (которые программисты, а не мартышки). Как Вы думаете, без саботажа обойдётся? :)
> Очень интересная идея! Да и программист скоро перестанет существовать как класс, так
> как каждый будет обладать этим навыком. Будущее без этого просто невозможно!Если вы не выполняете какую-то работу - это значит что кто-то делает ее за вас. Это правило работает в обе стороны - Если вы не хотите делать какую-то работу- кто-то ДОЛЖЕН сделать ее за вас...
Проблема в том, что вы сейчас, не задумываетесь над тем, что пользуетесь трудом и профессиональным навыком огромного количества людей, знания которых вы постичь даже не в состоянии. Нажимая пальцем на кнопку клавиатуры - вы приводите в действие труд огромного количества узких специалистов.Но если будущее будет выглядеть как его рисуете вы- то вам, чтобы сделать нажатие на кнопку клавиатуры- нужно будет обладать всеми знаниями этих тысяч специалистов. Что просто тупо и нереально. Таким образом Вы просто несете дилетантский невежественный вздор.
Комбайнер не обладает навыками и знаниями жнецов и молотильщиков, также как ими не обладет никто из тех, кто делает и даже проектирует комбайн. Тем не менее один комбайнер и комбайн делают работу сотен жнецов и молотильщиков. Как это укладывается в твою теорию?
> Комбайнер не обладает навыками и знаниями жнецов и молотильщиков, также как ими
> не обладет никто из тех, кто делает и даже проектирует комбайн.
> Тем не менее один комбайнер и комбайн делают работу сотен жнецов
> и молотильщиков. Как это укладывается в твою теорию?Он приводит в действие труд инженеров, создавших машину, управление которой сводится к простым действиям. Он не обладет знаниями этих инженеров. Он знает как устроена машина только поверхностно. Он узкий специалист по управлению этой машиной но по молотьбе и не по труду жнецов и инженеров...
Естественным образом укладывается :)
Я тебе привел простой пример, опровергающий вот этот вывод:> чтобы сделать нажатие на кнопку клавиатуры- нужно будет обладать всеми знаниями этих тысяч специалистов.
Либо ты не понял пример, либо я не понял, что ты вообще хотел сказать.
> Комбайнер не обладает навыками и знаниями жнецов и молотильщиков, также как ими
> не обладет никто из тех, кто делает и даже проектирует комбайн.
> Тем не менее один комбайнер и комбайн делают работу сотен жнецов
> и молотильщиков. Как это укладывается в твою теорию?Вы же понимаете, что комбайн жнет и молотит не потому что его "запрограммировал" комбайнер.
Запрограммировали комбайн (если так можно выразится) инженеры его создавшие. Комбайнер просто жмет кнопку ПОВЕР и задает направление. в этом смысле его труд ничем не отличается от труда домохозяйки, использующей кухонный процессор...
При некой доли фантазии и веселости можно и такие действия конечно назвать "программированием".. но что-то подсказывает что веселости надо для этого много...
Что за чушь? Конечно, те, кто проектирует комбайн, обладают знаниями жнецов и молотильщиков, иначе они спроектируют какую-то херню.
Нет, не обладают. Скажу страшное, они серп и цеп в руки никогда не брали, оно им не надо.
Сознательно путаем знания и навыки?
Соответсвующих знаний(типа левой рукой обхватить такое-то количество колосьев на такой-то высоте, собрать их в пучок, приставить серп такой-то частью к пучку в таком-то месте, провести режущее движение таким-то образом итд) у них тоже нет. По той же причине - ненужно. Комбайн не иммитирует жнеца, он работает слегка по-другому. Вот если бы инженер проектировал человекообразного робота, который бы взял в руки серп и пошел жать, то тогда знания, а еще лучше практические навыки жнецов были бы нужны.
Вы слишком глубоко копаете, а ответ лежит на поверхности. Я всего лишь имел в виду, что программирование станет неотъемлемой частью жизни любого человека. В будущем!
Было бы очень хорошо, но пока большинство не может объяснить, на что способна их микроволновка и какие режимы и почему они выбирают у стиральной машины - я бы особо не надеялся. Даже в линуксе "power user" с ad-hoc программированием на скриптах - вымирающий вид.
Похоже вы с собеседниками вкладываете разный смысл в слово "программировать"
Программировать - задать режим (алгоритм) работы стиральной машины.
Программировать - перевести алгоритм на язык понятный машине.
Эээ куда вас понесло! Перенести макет интерфейса, над которым вы работали, допустим, на природе под или с "музой", имея лишь набор фломастеров или обычного карандаша с ручкой. Ну признайтесь... Ну круто же! ^_^
> Да и программист скоро перестанет существовать как класс, так как каждый будет обладать этим навыком. Будущее без этого просто невозможно!Пока что не нашли даже способа эффективно обучать ремеслу программиста любого человека. Имеющиеся методы обучения просто не работают для большинства людей, обучаются только те, кто и так мог это сделать самостоятельно. Это примерно как попытки научить всех поголовно рисовать или сочинять музыку.
Ну и для светлого будущего нужна ликвидация свовсем других классов.
Вы преувеличивайте. Вопрос всегда стоял лишь в мотивации. Именно благодаря мотивации животные поддаются дрессировке! ^_^
Есть разница между дрессировкой выполнять фиксированный набор действий и обучением творческой деятельности. Я здесь это хорошо вижу - куча народу кинулась учиться IT ради денег, мотивации полно, толку - чуть. Потому что если мысли человека направлены на "о, вот скоро заработаю", а не на то, как хорошо сделать то, что он делает - увы, хорошего обучения не выходит. Ни в инженерии, ни в медицине, ни в чём сложном.Впрочем, насчёт "не научились учить" я тоже не согласен. Проблемы есть там, где пытаются учить навыкам вместо стиля мышления, либо пытаются учить тех, кому оно на фиг не надо на самом деле, либо не объясняют, как та чертовщина, которой учат, связана с практикой (тем более, что половина таки не связана, и брыкаются жертвы "обучения" совершенно оправданно).
> Впрочем, насчёт "не научились учить" я тоже не согласен. Проблемы есть там,
> где пытаются учить навыкам вместо стиля мышления, либо пытаются учить тех,
> кому оно на фиг не надо на самом деле, либо не
> объясняют, как та чертовщина, которой учат, связана с практикой (тем более,
> что половина таки не связана, и брыкаются жертвы "обучения" совершенно оправданно).Ну вот есть масса хороших книг по программированию. Те, кто по ним выучились, подтверждают, что книги хорошие и что им легко было по ним изучить программирование с нуля. Тем не менее по ровно тем же книгам другие люди не могут освоить практически ничего. Классическое "смотрю в книгу вижу фигу". Так как это книга и самостоятельное изучение, то все твои факторы мимо кассы, но результат по прежнему печальный - способа обучения программированию пока не найдено. В качестве альтернативы можно взять хорошие книги по кулинарии и увидеть, что там результативность обучения близка к 100%.
Потому что части повезло - у них есть базовые ментальные навыки, которые для программирования подходят. А другой части эти навыки надо сначала поставить. Всей разницы. Там обычно что-то простое, вроде неумения отделить имя от объекта или ходить между уровнями абстракции. Лечится это довольно просто.Книга в этом плане - самый убогий подход, так как нет обратной связи и некому посмотреть, что именно человек делает не так.
> - способа обучения программированию пока не найдено.И не надо. "Дурака учить - только портить".
Я всего лишь обосновал тот факт, что обучение невозможно без соответствующий мотивации. Нельзя научить того, кто не хочет этого делать. Умение мотивировать - это почти что магия! В случае дрессировки - это лакомство. В наше же время, учителя просто подают материал и не пытаются как-то вдохновить учеников. В этом на мой взгляд и вся проблема. Но с другой стороны, человек не способный себя мотивировать - еще тот овощ! ^_^
>Пока что не нашли даже способа эффективно обучать ремеслу программиста любого человека.
>Имеющиеся методы обучения просто не работают для большинства людей, обучаются только
>те, кто и так мог это сделать самостоятельно. Это примерно как попытки научить всех >поголовно рисовать или сочинять музыку.
>
>Ну и для светлого будущего нужна ликвидация свовсем других классов.Это просто потому, что в нынешнем понимании программист это математик-дилетант. Когда создадут язык программирования полностью абстрагированный от железа и позволяющий описывать алгоритмы и связи с данными более естественным языком. В этот момент большая часть программирования умрёт, как Web-программирование после изобретения CMS. Естественно там, где нужна быстрая скорость работы потребуется или математик или инженер . А так же некоторое количество переводчиков из языка гуманитариев в более строгую форму.
В нынешнем понимании для абсолютного большинмства специализаций программист - вообще не математик. А то, о чём вы говорите - это постановка задач, а нихрена не программирование. Чтобы только её хватало - полноценный AI нужен, пожалуй. Перевод же "в более строгую форму" - это и есть программирование, сюрприз.И да, "полностью абстрагированных от железа" сотнями. Суть не в железе, а в том, что выразить достаточно сложную проблему можно только адекватно сложными средствами. А с ними уже работать уметь надо. Можно от байтов с битами избавиться, а от архитектурных паттернов - чёрта с два. Если без ИИ, конечно.
Для светлого будущего нужна ликвидация ровно одного класса - невежественных дураков.И, кстати, насчёт рисования - если не знали, обучить "ремеслу рисования/сочинения" можно любого, это для "шедевров" вроде бы талант нужен (а скорее - энтузиазм и масса усилий). Ну так и насчёт прогарммирования здесь явно не о шедеврах речь.
>>И, кстати, насчёт рисования - если не знали, обучить "ремеслу рисования/сочинения" можно любого,"Рисовать" абстракции (изибразительное искусство) - не научишь, рисовать портреты научишь потому-что там более точные (строгие) правила (антропометрия), тоже самое с черчением. Область, у которой есть строгая методология, можно изучить и научиться и владеть в совершенстве. (Мы это уже обсуждали в предыдущих темах)
>>это для "шедевров" вроде бы талант нужен (а скорее - энтузиазм и масса усилий).
что есть "талант" - не ясно. (может то, что умеет один, но не умеют другие? если даже умеет один - по его знаниям строим методологию и обучаем других, свойство обучаемости есть у каждого человека)
>>Ну так и насчёт прогарммирования здесь явно не о шедеврах речь.
Повторюсь, программирование - не "искусство", здесь нет "шедевров", тут не нужен "талант". Вся проблема в том, что Д. Кнут неудачно назвал свою книгу (Искусство программирования), вот и все те кто прочитал её "зарубили" себе, что программирование есть какое то искусство. (Личное мнение)
Я о рисовании абстракций речь и не вёл - это уже "искусство", как вы правильно заметили, это не то, что нас интересует. Чтобы научиться рисовать надо, грубо говоря, две группы навыков - одна ментальная - увидеть мимо дорисованной мозгом картинки (светотени, перспектива - вот это всё), вторая моторная - как это изобразить данным набором инструментов и наработать глазомер. Вот с программированием часто забывают о "ментальной" части, отсюда и проблемы. Ну и убогие попытки обучить программированию без хоть примерного понимания, как работает компьютер - пресловутая неспособность понять указатели и рекурсию. Хотя для понимания - там пару раз ручками карточки по ячейкам поперекладывать.
>>Ну и убогие попытки обучить программированию без хоть примерного понимания, как работает компьютер - пресловутая неспособность понять указатели и рекурсию. Хотя для понимания - там пару раз ручками карточки по ячейкам поперекладыватьТаки да, совершенно согласен.
> Для светлого будущего нужна ликвидация ровно одного класса - невежественных дураков.Нет. Это не является ни необходимым, ни достаточным условием. Более того, оно еще и невыполнимо в принципе, так как человеческий мозг давно уже неспособен вместить в себя все знания человечества, а значит всегда будут области в которых данный индивид невежественен.
> И, кстати, насчёт рисования - если не знали, обучить "ремеслу рисования/сочинения" можно любого, это для "шедевров" вроде бы талант нужен
Нельзя. Даже черчению можно обучить далеко не каждого, а уж рисованию и подавно. Максимум можно натаскать на рисование однотипных рисунков каких-то определенных объектов. Дай ему незнакомый объект и такой "художник" вернется на уровень рисунков ребенка.
>>Даже черчению можно обучить далеко не каждого, а уж рисованию и подавно.Подмечу, что даже зная все правила черчения, человеку с нарушенной мелкой моторикой всё равно будет "трудно".
Речь о больных людях не шла, у здоровых - нарабатывается.
Ну так не надо пытаться всё в голову запихнуть, а вот рациональное мышление и общее понимание того, как работают системы - здорово помогут.Насчёт рисования - см. мой ответ чуть выше. Вот если забудете "ментальный" блок навыков - так и будет, как вы говорите. Но ему можно именно что любого научить, именно для этого в худшколах всякие кубы с к шарами рисуют и прочее подобное.
Смотрю по отмазкам ты просто спец. Не работает методика? Нет, что вы, конечно она работает, просто у вас нет ментального блока навыков!
Ну, у тебя и обучение рисованию "не работает". Хотя худшколы до состояния "нарисовать то, что вижу, чтобы было на фотографию похоже" учат любую обезьяну.Ну сюрприз - если человек обычное планирование "что за чем" не освоил и не может ответить на вопрос "из слов холодильник, утюг, микроволновка и автомобиль что лишнее и почему" - то его сначала этому надо доучить.
> Ну, у тебя и обучение рисованию "не работает". Хотя худшколы до состояния "нарисовать то, что вижу, чтобы было на фотографию похоже" учат любую обезьяну.Не любую. Они учат лишь тех, кто уже имеет выраженную склонность к рисованию, других туда просто не отправляют, так как это бесполезно.
> Очень интересная идея! Да и программист скоро перестанет существовать как класс, так
> как каждый будет обладать этим навыком. Будущее без этого просто невозможно!Базовое программирование - это набор весьма нехитрых навыков. По-сути, это чуть-чуть расширенное умение читать и писать. Развивается у детей всякими Пиктомирами, learn.code.org и т.д. Ничего сложного и ужасного.
Тем не менее, вокруг толп программистов что-то не видно.
Так и будущее еще не наступило! ^_^
Смотря чье будущее. Будущее конных извозчиков наступило.
> Базовое программирование - это набор весьма нехитрых навыков.Всего-то анализ и синтез. Сначала научиться декомпозиции процесса на операции, а целого на части, а затем агрегации примитивов в сложные сущности - в структуры и функции.
А интерфейс Blender'а прожуёт?
> А интерфейс Blender'а прожуёт?
> https://github.com/rasteron/oui-blendishТам только про мобильные приложения написано (которые для мартышек) :)
> А интерфейс Blender'а прожуёт?Я бы лучше тулкит блендера взял за основу по аналогии GIMP -> GTK -> Gnome. Реактивная получилась бы система.
К сожалению, это не так просто, он сильно повязан на внутренностях Блендера. Давно бы вынесли в отдельную либу, если бы могли.
И появится тысяча поддельных сайтов.
А кто до этого мешал их делать? Css стили доступны, а с ними намного легче скопировать внешний вид, чем с этой программой.
бесполезная хрень - это также как попытаться построить дом по рисунку его экстерьера. может собачья будка и получится, а вот коттеджик со всеми необходимыми несущими конструкциями, комнатами и переходами - хер. Типичное одностраничное приложение может иметь дофига перекрывающихся div'ов со сложной взаимосвязью и layout'ом. вот почему для fast UI dev'а и существуют framework depended вещи типа sencha architect или qt creator
Такая оптимизация внутреннего состояния кода тоже возможна средствами искусственного интеллекта. Это может стать следующим шагом развития. Разве нет?
test
Мозг верстальщика, версия 0.1.
Я считал, что верстальщика можно заменить баш-скриптом, особенно это касается всех сайтов, построенных на бутстрапе, но все оказалось немного сложнее - какая никакая нейронная сеть все таки понадобилась.
отличная идея! Фаин ридер отлично помогает с рефератами, а этот проект отлично поможет с работами по информатике!
Это может быть полезно для задач удаленного доступа к GUI
Ну да, для подмены форм аутентификации юзеров ;)
следующий этап это собрать один кубит машинного обучения из пятерки индусов
В любом случае, хуже, чем вэб-макаки оно не сделает, просто не сумеет.
Чувак, нейросеть обучается на коде, написанном вебмакаками, так что я бы так не радовался.
в отличие от вебмакаки, у которой мозг какой-никакой а есть, эта штука, будет громоздить в одну кучу тот самый код написанный вебмакаками не понимая что она громоздит...
результат будет вероятно забавен :)
Полностью согласен. Я то думал, что нышнее потребление ресурсов приложениями - это предел, но похоже что у нас еще все впереди
Круто! Ждём в гуглоплее троянов, сделанных с помощью этой штуки.
> Круто! Ждём в гуглоплее троянов, сделанных с помощью этой штуки.Мелко плаваешь, через эту штуку можно будет сделать пульт для управления Вселенной.
Вот и появился повод научиться рисовать! ^_^
Даже из первой картинки видно, что оно "нинужно", ибо генерит непонятно что непонятно для кого. Вариантов того, как разработчик/дизайнер реализовал верхнюю половину view как минимум два: 1) TableView с "ячейками" (это, собственно, и распознала"распозновалка"); 2) Каждый "элемент списка" - отдельный ViewController с constraints'ами по бокам. И реализовано оно так или иначе может быть по разным причинам: например, требование поворота только "половины списка" при повороте экрана, или использование каких-нидь VIPERов при проектировании (на каждый такой "серый прямоугольник" будет по 3 класса + модель с тестами) и т.д.
Ну вот и останется один общепринятый вариант, давно пора. Бардак с богатой фантазией гуе-дизайнеров здорово утомил.
вспомнился анекдот - компания ADOBE купила DELPHI. теперь чтобы создать программу ее достаточно нарисовать.
swift по моему не особо отличается ))
подходит для написания всяких автокликалок в игрушках
Точно так же, подходит, как и звонок на твоей двери.
Норм такое загонять в нейронку, которая бы еще задавала сопутствующие вопросы и предлагала разные улучшения!
А потом и макет будет не нужен!
а когда то шутили про кнопку "сделать зашибись"...
IBM Watson подменяет уже врачей, так что и программистов будет подменять.
Будет называться "Великий Интеграл". Вернее "Его Величие Магистр Великий Интеграл".
> IBM Watson подменяет уже врачейВ диагностике или в лечении? Или для вэб-макаки это одно и то же?
В получении зарплаты наверное
Что нажать чтобы он заменил моего участкового или хотя бы консультацию у гугла?
Ололо, верстальщики больше не нужны? :)
верстальщики AI систем нужны.
В комментариях тестируют "Проект по автоматической генерации комментариев"
Верстальщики окажутся без работы.
Эта идея - жалкий отпрыск ИИ. Попытка сделать "наскоком" то, чему люди учатся годами.
Что может этот убогий копирователь?? Даже кнопку он найти не в состоянии, потому что это не может сделать даже сам человек с этими погаными "плоскими интерфейсами"! Соотв, выход этой перделки - бессмысленный набор прямоугольников, повторяющий оригинал, но даже близко не стоящий с реальной функциональностью. Какие секции могут раздвигаться? Куда выравнивание? Какие контролы стоят на позициях? В каких группах? Всё это пропускается и выдаётся бессмысленный результат.