Если система не имеет устоявшихся правил и постоянно модифицируется это свидетельствует об ошибках проектирования в самом начале пути. Можно безконечно заниматся модификациями и улучшениями, стараясь достигнуть совершенства и баланса всех ее составляющих. Но такой путь возможен при соблюдении нескольких условий.
Во-первых: при каждой существенной итерации система должна качественно улучшатся, избегая ошибок которые были допущены в плилотных версиях продукта.
Во-вторых: частое испралвение ошибок, слабый рост, в догоняющей позиции должен компенсироваться революционными идеями способными вместить в себя все предыдущие технологии в наиболее выгодном свете.
И, наконец, третье: такой рост возможен лишь с согласия всех лиц у чавствующих в разработке и использовании этой системы.
Получается, что как только аудитория становится более грамотной, переростает систему и ее авторов система умерает. Это происходит постепенно и нужно лишь ждать когда автор, ее идейный вдохновитель поймет свое бессилие и откажется догонять впереди его идующую толпу.
Очень наглядный тому пример можно увидеть в этом интервью.
Беседуют два уже не молодых человека. Каждый придерживается своей системы и своих взглядов. У каждого свое представлние об одних и тех же технолгиях (функциональном программировании, например), но они продолжают улыбаться друг другу и вести дружелюбную беседу. Вот она: полит корректность.
Для того чтобы двум людям, совершенно разных взглядов быть так приветливым необходимо: либо быть настоящим лицимером, политиком, либо иметь хорошую выдержку и понимать, что слабую технологию легче всего поглотить, чем воевать против нее.
...
SPJ: Whenever you've got concurrency and multiple processes working, you need to be very careful about side effects. Otherwise it just does your head in. Something that Haskell and Erlang both share is being careful about effects. Haskell is sort of super-careful and Erlang is merely careful, but in both cases, we don't have this, unrestricted side effects all the time, the computational fabric being effectful. It seems to me it makes it jolly hard to write programs that exploit multithreads.
...
JA: And the garbage collector doesn't need to know about what types are generated.
SPJ: Oh the garbage collector, that's not a problem. Our garbage collectors are complicated, not because of types, it knows nothing of types.
...
SPJ: Do you have any profiling tools?
JA: Yes, sure.
SPJ: So, you can see "Oh, this process is stalled."
JA: What's interesting is when you are finding the sequentiality.
...
JA: With each new generation of chips, it's... We don't know what's going to happen.
...
JA: When you're developing Erlang, you don't have to write the entire program to get it to work, and you're not quite sure what the types are. In Erlang you just write some program here, and you evaluate something and it throws out this great big thing and you say: "Oh, that's what the type was". Then you can say: "Well that wasn't quite right, let's change it to that". But you're not restricted in having to get all the bits working before you can just do those experiments. Wouldn't you miss something like that?
SPJ: You still don't have to get all the bits working, you have to think of what type you might have, but you might evolve that type.
JA: Or you can just run it and see. We have things called parse transforms which allow you to change them. In a module you can say there's a parse transform, and the parse transform is given the parse tree of the program and it can turn it into another parse tree before it's given to the compiler. That's a way of doing deeply sinful things that you normally can't do. And the nice thing about that is, somebody has asked me "How do I get started with this?"
Ссылки по теме:
понедельник, 28 сентября 2009 г.
Подписаться на:
Комментарии к сообщению (Atom)
2 коммент.: