Или изменяет интерфейс так, что он становится крайне популярен у большинства обычных людей.
Под которых зачастую приходится подстраиваться программистам.
Если в обычной программе встречается непонятное что-то — обычно следует ошибка компилятора и warning.
Признаться не вижу причин, по которым данная система не сможет уточнить по телефону, что имел в виду программист.
А SQL жив уже лет 30 вроде и ничего для его замены я признаться пока не видел.
Хотя возможно просто не в курсе.
Я вижу что сейчас идет активное проталкивание всего, что угодно — в как можно более широкую аудиторию.
Начиная с коробок-автоматов на машинах, и кончая всевозможными АСУТП.
Потому-что это деньги для разработчика.
Чем больше людей сможет на этом программировать, включая бабушку Варю — тем больше денег и тем соответственно лучше.
Мой интерес в данном случае — направление развития.
А конкретная реализация может варьироваться.
Она ничего толком не решает — на С это будет или на чем то еще.
С использованием каких-то принципов или нет.
Будет использоваться данная иерархия — я не против.
Не будет — тоже собственно ничего страшного.
Ну во первых: Если человек программирует по человечески — ему сложно будет писать индусским кодом.
Это как хорошо зная русский язык писать на нем неправильно.
Во вторых: Откуда уверенность, что прототип изначально заработает и не потребует отладок? Предлагается писать следующий прототип или править хаос?
> В вашем случае, эти три варианта и есть прототипы.
Уже писал:
1. На подобные проблемы при изучении тратится больше половины времени, соответственно длительность реализации прототипа — крайне высока.
2. Именно в таком виде эта связь и будет использоваться в проекте, из чего следует, что мы занимаемся не прототипом, а продуктом.
Button и ProgressBar?
Тогда по каким собственно вопросам прототип позволяет получить «необходимый багаж знаний в предметной области»?
Например у нас сейчас необходимость соединения 2-х различных типов контроллеров по сети.
Тот самый новый непроверенный функционал в полный рост.
Не первая неделя тестов. Пробуем третий уже кажется вариант.
Честно говоря не представляю, чем тут помогут например проверка кнопки и индикатора процесса.
Я их за это время навтыкать мог миллионы. Мне ж не жалко — я добрый. Но они в данном случае бесполезны и ничего нового в себе не несут.
А вот новые, нуждающиеся в проверке — возможности связи с выбором подходящего интерфейса, занимают уйму времени.
Куда мне к ним надо приделать этот загадочный прототип?
В таком случае (с учетом ответа ниже) бытующее мнение верно — и я не совсем понимаю, что делать с коллективом, который выполняет двойную работу и заказчиком, у которого вдвое ползут сроки.
Это ж вроде не соответствует пунктам 6 и 3?
Мало с кем из заказчиков можно сохранить отношения, сорвав ему сроки в двойку.
И мало какой коллектив выполняя двойную работу сможет возвращаться домой после 8 часов на работе.
Либо сроки сразу ставятся двойные, и оплата соответственно берется двойная?
Но тогда я хочу посмотреть на заказчика, который платит в два раза больше реальной цены. И не нанимает коллектива, у которого это всё уже отработано, за стандартную сумму.
Что он должен употреблять? :)
Либо считаем, что продукт получается при помощи небольшой доработки прототипа.
Но тогда я не понимаю, чем работа над прототипом отличается от работы над продуктом.
Или это только мне так не везет и я упорно попадаю в моменты затишья.
Под которых зачастую приходится подстраиваться программистам.
Признаться не вижу причин, по которым данная система не сможет уточнить по телефону, что имел в виду программист.
А SQL жив уже лет 30 вроде и ничего для его замены я признаться пока не видел.
Хотя возможно просто не в курсе.
Начиная с коробок-автоматов на машинах, и кончая всевозможными АСУТП.
Потому-что это деньги для разработчика.
Чем больше людей сможет на этом программировать, включая бабушку Варю — тем больше денег и тем соответственно лучше.
Функциональностью набивают.
Сказать while do не сложнее, чем написать.
Цель? Научить программировать всех видимо.
Так-же как и упрощение интерфейсов.
А конкретная реализация может варьироваться.
Она ничего толком не решает — на С это будет или на чем то еще.
С использованием каких-то принципов или нет.
Будет использоваться данная иерархия — я не против.
Не будет — тоже собственно ничего страшного.
Бритва Хэнлона
Это как хорошо зная русский язык писать на нем неправильно.
Во вторых: Откуда уверенность, что прототип изначально заработает и не потребует отладок? Предлагается писать следующий прототип или править хаос?
Ни для чего.
Аналог для программирования можно привести?
Уже писал:
1. На подобные проблемы при изучении тратится больше половины времени, соответственно длительность реализации прототипа — крайне высока.
2. Именно в таком виде эта связь и будет использоваться в проекте, из чего следует, что мы занимаемся не прототипом, а продуктом.
Тогда по каким собственно вопросам прототип позволяет получить «необходимый багаж знаний в предметной области»?
Например у нас сейчас необходимость соединения 2-х различных типов контроллеров по сети.
Тот самый новый непроверенный функционал в полный рост.
Не первая неделя тестов. Пробуем третий уже кажется вариант.
Честно говоря не представляю, чем тут помогут например проверка кнопки и индикатора процесса.
Я их за это время навтыкать мог миллионы. Мне ж не жалко — я добрый. Но они в данном случае бесполезны и ничего нового в себе не несут.
А вот новые, нуждающиеся в проверке — возможности связи с выбором подходящего интерфейса, занимают уйму времени.
Куда мне к ним надо приделать этот загадочный прототип?
Это ж вроде не соответствует пунктам 6 и 3?
Мало с кем из заказчиков можно сохранить отношения, сорвав ему сроки в двойку.
И мало какой коллектив выполняя двойную работу сможет возвращаться домой после 8 часов на работе.
Либо сроки сразу ставятся двойные, и оплата соответственно берется двойная?
Но тогда я хочу посмотреть на заказчика, который платит в два раза больше реальной цены. И не нанимает коллектива, у которого это всё уже отработано, за стандартную сумму.
Что он должен употреблять? :)
Но тогда я не понимаю, чем работа над прототипом отличается от работы над продуктом.