Я говорю о другом. Я говорю об увеличеннии производительности текущего способа написания программ. Я хочу то же самое окошко с курсором, но чтобы введенные символы преобразовывались в нужные конструкции. Я хочу чтобы классы можно было компоновать перетаскиванием методов. Чтобы можно было получить разнообразные графические схемы программы.
От написания функций способом похожим на текстовый не уйдешь, однако его можно значительно проапргрейдить отойдя от чисто-текстового подхода. Всё остальное, что не относится к содержимому функций, должно компоноваться а не описываться текстом.
Ну, распознаванием образов в реальном мире занимаются люди, здесь и надо копать :)
А насчет фреймворка, боясь попасть под минусы, скажу что плохо то понятие, которое не находит отражения в реальном мире. Веб-фреймворки зло :) Не существует их аналога в реальном мире потому, что корень зла лежит не в самих фреймворках, а вообще во всей софтвеерной архитектуре. Прежде чем хаять меня прочитайте еще один абзац :)
Когда зарождалась архитектура софта и веба, никто не думал о том, что компьютеры смогут стать отражением и дополнением реального мира. Компьютеры были вычислительными машинами. Все развивалось от необходимости решения вычислительных задач. Сейчас уже мало кто использует компьютер для рассчетов — в основном люди обмениваются материалами, узнают информацию и развлекаются. Вот и получается что задачи поменялись, а старое наследие осталось. Сейчас мы ваяем скульптуры гвоздём.
Я глубоко уверен что можно построить софтвеерную систему так, чтобы все её составляющие имели отражение в реальном мире. Мало того, я долго занимался этим вопросом и, если интересно, могу сказать как это возможно.
Мм, алгоритмы удобно, конечно, описывать последовательностью команд. Только команды должны быть красивые и удобные) Без ограничений, которые налагает текст. Например, вместо множества аргументов у функций, давать возможность вводить всё в окошко с параметрами, без привязки к порядку аргументов. А так же, например, позволять в этом же окошке описывать действия при ошибках выполнения функции. Можно добавлять скрытое комментирование — при нажатии на F1, к примеру, показывать рядом с сущностями иконку комментария, если таковые имеются. Математические функции должны описыватся в математической форме, примерно как в MatLab'е. Возможностей куча.
Но большее преимущество от такой среды разработки программист получил бы не в описании алгоритмов, а в установке связей. В моей практике описание каких-либо алгоритмов занимает меньше половины времени — всё остальное время уходит на создание объектов, методов, задание свойств и т.д. и прочую рутинную работу. Именно такую работу стало бы выполнять веселее :)
А мне, вот, товарищи, кажется, то будущее совсем не за языками программирования. Мне кажется что будущее за инструментами разработки. Текст хорош для описания последовательности действий, но современные программы это уже далеко не просто последовательности. В них присутствует компоновка и связи, которые гораздо удобнее было бы проводить не копируя текст туда-обратно, а перетаскивая блоки.
Еще один недостаток современного программирования — попытка свести к минимуму число понятий. У вас есть только объекты и функции — делайте с ними что хотите. Это, конечно, хорошо, когда ты только начинаешь обучение — меньше чего запоминать, но это сродни молотку со встроенной отверткой, кусачками, и зубилом. С помощью него, конечно, можно сделать многое, но лучше бы все эти функции были разделены на отдельные инструменты — было бы быстрее.
И из предыдущего параграфа следует следующий бич текстового программирования — с ростом числа понятий усложняется язык и компилятор. Становится сложнее изучать язык. Кроме того, не все логические конструкции можно лаконично описать текстом.
Вот и получается что гораздо умнее было бы не пытаться развивать то, что уже практически в тупике, а перескочить на следующий уровень — взглянуть на вещи по новому. Среда разработки, абстрагированная от языков программирования и позволяющая выполнять то же самое, но без привязки к синтаксису и работающая на более высоких понятиях стала бы, блин, спасением.
мм, насколько я понял по статье в wiki SOA — это архитектура взаимодействия программ, а не исполнителей внутри одной программы. По-моему модель акторов все таки подходит больше. Но смысл тот же.
… ну ладно по быстрому: notify() — ничего не сказано, для sleep() — это тоже самое что для минуса плюс. Кстати и про yield() забыли.
Насколько я знаю notify() работает в паре с wait(), а не с sleep().
Про yield() написал, спасибо.
Про сокеты убрал, пример, и правда, не удачный.
Объяснение про процессы много места не заняло. Оно дано для общей информации и без особого смысла. Без него параграф про процессы был бы суховатым.
Неточность в фразе про создание процесса исправил, еще раз спасибо.
Префикс «m» в имени переменной значит «member», а именно — член класса. Этот префикс служит для отличения переменных класса от переменных метода, в которых префикс не указывается. Вероятно вы подумали что он значит «my»…
Исправил текст про предугадание выполнения программы.
Насчет interrupted() я не очень понял. Именно этот метод вызавается потоком для проверки того, прерван он или нет. Метод interrupt() не убивает поток, а выставляет флаг прерывания, который потом проверяется методом interrupted().
Я вернул все назад, первый вариант был самым лояльным.
p.s. а линукс разве поддерживает интервалы прерываний меньше 1мс? Пока я искал информацию по методу sleep я натыкался на высказывания по поводу 10мс у windows и 1мс у линукса. Или я в чем-то заблуждаюсь?
Это было обращено к тому, кто хотел помочь, вместо того чтобы выделываться. Никаких претензий к комментарию aleks_pingvin'a не имею и в плане на статью добавил пометку на ReentrantLock и барьеры. В чем смысл вашего комментария я понять не могу… Унизить? Выпендриться? Или одно другого не исключает?
Сильно то, что не используется синхронизация или сильно то, что в фразе не правильный смысл?)
Volatile — добавил. Зачем он нужен — понял. Есть еще замечания?
Да, и я совсем забыл про то, как называл себя в статье великим знатоком многопоточного программирования, несущим знания в народ… хотя подождите, я же этого не писал. Хм, наверное потому что я так не думаю. Вот ведь интересно, с чего все остальные взяли обратнное? Наверное потому же почему люди верят в то, что по телеку вещают только величайшие умы современности, просто не способные ошибаться из-за своей безграничной крутости и приближенности к богу.
Я вам чем то не угодил? Вашу позицию я понял — кг/ам. Хотите и знаете чем сделать статью лучше и что в ней не правильно — с удовольствием почитаю и исправлю. Не хотите/не знаете — перестаньте, пожалуйста, писать бессмысленные комментарии.
Я говорю о другом. Я говорю об увеличеннии производительности текущего способа написания программ. Я хочу то же самое окошко с курсором, но чтобы введенные символы преобразовывались в нужные конструкции. Я хочу чтобы классы можно было компоновать перетаскиванием методов. Чтобы можно было получить разнообразные графические схемы программы.
От написания функций способом похожим на текстовый не уйдешь, однако его можно значительно проапргрейдить отойдя от чисто-текстового подхода. Всё остальное, что не относится к содержимому функций, должно компоноваться а не описываться текстом.
А насчет фреймворка, боясь попасть под минусы, скажу что плохо то понятие, которое не находит отражения в реальном мире. Веб-фреймворки зло :) Не существует их аналога в реальном мире потому, что корень зла лежит не в самих фреймворках, а вообще во всей софтвеерной архитектуре. Прежде чем хаять меня прочитайте еще один абзац :)
Когда зарождалась архитектура софта и веба, никто не думал о том, что компьютеры смогут стать отражением и дополнением реального мира. Компьютеры были вычислительными машинами. Все развивалось от необходимости решения вычислительных задач. Сейчас уже мало кто использует компьютер для рассчетов — в основном люди обмениваются материалами, узнают информацию и развлекаются. Вот и получается что задачи поменялись, а старое наследие осталось. Сейчас мы ваяем скульптуры гвоздём.
Я глубоко уверен что можно построить софтвеерную систему так, чтобы все её составляющие имели отражение в реальном мире. Мало того, я долго занимался этим вопросом и, если интересно, могу сказать как это возможно.
Но большее преимущество от такой среды разработки программист получил бы не в описании алгоритмов, а в установке связей. В моей практике описание каких-либо алгоритмов занимает меньше половины времени — всё остальное время уходит на создание объектов, методов, задание свойств и т.д. и прочую рутинную работу. Именно такую работу стало бы выполнять веселее :)
Еще один недостаток современного программирования — попытка свести к минимуму число понятий. У вас есть только объекты и функции — делайте с ними что хотите. Это, конечно, хорошо, когда ты только начинаешь обучение — меньше чего запоминать, но это сродни молотку со встроенной отверткой, кусачками, и зубилом. С помощью него, конечно, можно сделать многое, но лучше бы все эти функции были разделены на отдельные инструменты — было бы быстрее.
И из предыдущего параграфа следует следующий бич текстового программирования — с ростом числа понятий усложняется язык и компилятор. Становится сложнее изучать язык. Кроме того, не все логические конструкции можно лаконично описать текстом.
Вот и получается что гораздо умнее было бы не пытаться развивать то, что уже практически в тупике, а перескочить на следующий уровень — взглянуть на вещи по новому. Среда разработки, абстрагированная от языков программирования и позволяющая выполнять то же самое, но без привязки к синтаксису и работающая на более высоких понятиях стала бы, блин, спасением.
Насколько я знаю notify() работает в паре с wait(), а не с sleep().
Про yield() написал, спасибо.
Про сокеты убрал, пример, и правда, не удачный.
Объяснение про процессы много места не заняло. Оно дано для общей информации и без особого смысла. Без него параграф про процессы был бы суховатым.
Неточность в фразе про создание процесса исправил, еще раз спасибо.
Префикс «m» в имени переменной значит «member», а именно — член класса. Этот префикс служит для отличения переменных класса от переменных метода, в которых префикс не указывается. Вероятно вы подумали что он значит «my»…
Исправил текст про предугадание выполнения программы.
Насчет interrupted() я не очень понял. Именно этот метод вызавается потоком для проверки того, прерван он или нет. Метод interrupt() не убивает поток, а выставляет флаг прерывания, который потом проверяется методом interrupted().
Предложение в параграфе приоритета потоков убрал.
p.s. а линукс разве поддерживает интервалы прерываний меньше 1мс? Пока я искал информацию по методу sleep я натыкался на высказывания по поводу 10мс у windows и 1мс у линукса. Или я в чем-то заблуждаюсь?
Volatile — добавил. Зачем он нужен — понял. Есть еще замечания?
Да, и я совсем забыл про то, как называл себя в статье великим знатоком многопоточного программирования, несущим знания в народ… хотя подождите, я же этого не писал. Хм, наверное потому что я так не думаю. Вот ведь интересно, с чего все остальные взяли обратнное? Наверное потому же почему люди верят в то, что по телеку вещают только величайшие умы современности, просто не способные ошибаться из-за своей безграничной крутости и приближенности к богу.