Не забывайте указывать ОС Windows в тегах. Это очень важно потому что этот API хотя и программируется на С++ но имеет разные реализации на Linux и Win.
Wataru, если визуализировать x в степени бесконечность численно (ну просто допустив что конечное число итераций нам достаточно, то у нас будет такой график.
От 0.0 до 1.0) не включительно == 0.0
Потом строго равно единичке при x = 1.0
И все что строго больше единички улетает в бесконечно большое вещественное число. Короче можно не считать.
paran0id, посмотрел. Много лишнего. Например мышкой можно двигать блоки туда-сюда. С точки зрения версионного контроля это будет считаться изменением? Чорт его знает. Я всегда очень придирчив к изменениям в коде. А если взять такой крупный визуальный проект - то в нем 20% changes будут структурны и 80% изменений просто свяазаны с тем что у кого-то "рука дрогнула".
Вобщем я берегу свои глаза и не хотел-бы просматривать тысячи измененных строк в git просто потому что какая-то дизайнерка шевелила долго мышкой.
Но вот я поворчал немного.
Вообще я люблю визуальную часть информации. Но применительно к данным больше чем к коду. Инфорграфика например. Прекрасная вещь.
Графическое программирование или проектирование в принципе не ново. Еще IBM создавал подобные штуки много лет назад. Это ничем не закончилось. Эти штуки не востребованы особо. Я работал в 3х банках и 6 корпорациях и нигде эти средства не играли какого-то особого значения в мейнстриме разработки. Архитекторы в кабинетах могли баловатся рисованием диаграмм со стрелками но это был просто рисунок для презентаций.
Поэтому если рассматривать программирование мышкой как какую-то панацею или цель - то я считаю что это пустая трата времени. Никто еще никогда мне не показал наглядного примера где-бы визуальное программирование имело хотя-б какое-то серьезное преимущество перед классическим. Перед написанием собственно текста программы.
Если речь идет о рисовании веб-дизайна по принципу WISIWIG - то я за. Это хорошая тема. Давно пора и в онлайн сразу. Но такое рисоване юаев не составляет конкуренцию программированию. Это просто другой сегмент задач.
сергей кузьмин, меня не покидает ощущение что задачу разработки делают админы. Разработчики бы сразу делали http/REST сервис. Консольное приложение - не проблема. Его можно тоже вызвать из любого процесса. API всегда есть. И в python. И в java.
Чорт его знает. Такие проблемы проще решать исключая переменные. Например. Автор пишет - лагает через провод. Что за провод? Сколько hops, сколько сегментов отделяют клиента от сервера? Можно ли просто переставить RDP сервер поближе? Возможно лагает сам RDP. Случаи разные. Антивирус заработал. Диск чем-то занят параллельно. Или кто-то рукастый запустил еще пару серверов на этом хосте. Это все надо ходить и проверять по пунктам. А вы говорите - как. Вот так.
chincharovpc, переложи приложение в другой фолдер. Еще придумал блин какие-то фолдеры с точками. Сделай чтоб оно просто заработало а потом уже разложи по феньшую.
res2001, я 15 лет назад был отпетым сторонником pure-OOP. Сейчас я стал философом. Я просто увидел другие разработки. Мир вообще более широк чем просто какая-то парадигма. Кстати есть такое религиозное наблюдение что все гениальные люди слегка безумны. Или скорее наоборот. Если ты претендуешь на гений - то ты должен отбросить в сторону паттернализм и стандартные подходы. Любой сложный и умный проект - он скорее нестандартный. Он разворачивает стандарты на 90 градусов.
Вобщем я с удовольсвием поговорю о парадигмах. Но просто это будет разговор о том что новичку сейчас не надо. Ему щас надо другое. Кнут. Вирт. Дейкстра. Дискретная математика. И инженерные сведения о железе.
res2001, я просто говорю к тому что вопрос парадигмы иногда вообще не стоит. Какая парадигма у микро-кода процессора? Чорт его знает. Главная парадигма - сверх-скорость и сверх-надежность.
Дружище ну это вообще не задача баз данных. В инфо-технологиях хранение данных и их отображение очень четко отделяется. А когда ты хочешь такую компоненту которая решает узкую задачу - запрограммируй ее сам.
Борис Животное, я-бы не экономил. Я-бы купил себе топовую конфигурацию по процессору и памяти. Благо доход позволяет. Я имею обширнейший опыт сидения на плохом железе. И у меня вобщем-то чутье на плохой и неоптимизированный код. И я его вижу на хорошей конфигурации и на плохой. Но сыну я-бы не стал покупать дорогую "игрушку". Тем более если он заявит что хочет учиться на разработчика. Ничего. Трудности закаляют характер.
Я думаю что зависит от задач. Если автор будет кодером embed-систем то ему в принципе подойдет комп старого поколения. Даже 32х разрядный можно купить. Или забрать у бабушки.
Вообще узкая конфигурация имеет смысл с точки зрения перформанс-тестирования. Например если вы гейм-девелопер - то ты должен понимать что рынок устройств несовершенен и игра должна ЛЕТАТЬ не на топовых железках а на широком потребительском сегменте. Или по крайней мере обеспечивать такие пре-сеты чтобы она терпимо работала в шир-потребе.
Вот с этой точки зрения я согласен что не стоит сидеть в тёплой ванне. В этом случае удары судьбы будут не так болезненны и более ... прогнозированы чтоли.
res2001, ты не поверишь что я лет 15 был ярым проповедником ООП. Я аки меч карающий ходил среди коллег и делал свое коде-ревью.
В любом случае та или иная парадигма будет использована (или какое-то их подмножество), т.к. без этого практически не возможно сейчас написать ни одно мало-мальски сложное приложение.
Как ты считаешь, ядро Linux - это сложное приложение?
