m**u
发帖数: 541 | 1 今天正式决定， 开历史倒车，啥Framework都废掉，以后不允许使用任何framework。
需要的话，自己建库，而且，只能是最简单、没有任何关联的库。 |
a*****g
发帖数: 19398 | 2 不容易
【在 m**u 的大作中提到】
: 今天正式决定， 开历史倒车，啥Framework都废掉，以后不允许使用任何framework。
: 需要的话，自己建库，而且，只能是最简单、没有任何关联的库。
|
p*******e
发帖数: 286 | 3 说说具体的灾难
【在 m**u 的大作中提到】
: 今天正式决定， 开历史倒车，啥Framework都废掉，以后不允许使用任何framework。
: 需要的话，自己建库，而且，只能是最简单、没有任何关联的库。
|
ET
发帖数: 10701 | 4 case by case..
【在 m**u 的大作中提到】
: 今天正式决定， 开历史倒车，啥Framework都废掉，以后不允许使用任何framework。
: 需要的话，自己建库，而且，只能是最简单、没有任何关联的库。
|
W***o
发帖数: 6519 | 5 让人一点都不明白的话有啥说头这是。。。
啥灾难啊
【在 m**u 的大作中提到】
: 今天正式决定， 开历史倒车，啥Framework都废掉，以后不允许使用任何framework。
: 需要的话，自己建库，而且，只能是最简单、没有任何关联的库。
|
e*******o
发帖数: 4654 | 6 模仿前几天一个大牛的发言
目睹了一场车祸以后 开始走了上班 不允许使用任何交通工具 而且自己走路也要走一
步 看三下
【在 m**u 的大作中提到】
: 今天正式决定， 开历史倒车，啥Framework都废掉，以后不允许使用任何framework。
: 需要的话，自己建库，而且，只能是最简单、没有任何关联的库。
|
l******t
发帖数: 55733 | 7 一猴子吃花生前都要先塞进屁股再拿出来吃。对此管理员解释道：曾有人喂它桃子，结
果桃核拉不出来，猴子吓怕了，现在一定要量好再吃。 |
q*c
发帖数: 9453 | 8 尼玛， 屌就一个字。
【在 l******t 的大作中提到】
: 一猴子吃花生前都要先塞进屁股再拿出来吃。对此管理员解释道：曾有人喂它桃子，结
: 果桃核拉不出来，猴子吓怕了，现在一定要量好再吃。
|
r***y
发帖数: 4379 | 9 神一般的回复...
老夫, 笑翻羊年...
【在 l******t 的大作中提到】
: 一猴子吃花生前都要先塞进屁股再拿出来吃。对此管理员解释道：曾有人喂它桃子，结
: 果桃核拉不出来，猴子吓怕了，现在一定要量好再吃。
|
a******n
发帖数: 5925 | 10 lol
【在 l******t 的大作中提到】
: 一猴子吃花生前都要先塞进屁股再拿出来吃。对此管理员解释道：曾有人喂它桃子，结
: 果桃核拉不出来，猴子吓怕了，现在一定要量好再吃。
|
|
|
c******o
发帖数: 1277 | 11 frankly, tried this before, you will end up with a same, less matured
framework yourself.
on the other hand, if you can do it better than other framework, why not
sell the framework yourself? Why do app?
【在 m**u 的大作中提到】
: 今天正式决定， 开历史倒车，啥Framework都废掉，以后不允许使用任何framework。
: 需要的话，自己建库，而且，只能是最简单、没有任何关联的库。
|
m**u
发帖数: 541 | 12 您总结的真好，程序员的写照。
【在 l******t 的大作中提到】
: 一猴子吃花生前都要先塞进屁股再拿出来吃。对此管理员解释道：曾有人喂它桃子，结
: 果桃核拉不出来，猴子吓怕了，现在一定要量好再吃。
|
m**u
发帖数: 541 | 13 很多时候，使用这类的框架给人的感觉就像贪小便宜，一看开始看着是赚了，省了不少
事，但随后会发现，后面的开发都需要为了框架来折衷，倒是把问题本身放到第2位了。
当然不是说开倒车就没有问题。不过感觉上，应该避免形成所谓的框架，这种东西最后
会变得越来越密耦合，结果变成为了框架而框架。
【在 c******o 的大作中提到】
: frankly, tried this before, you will end up with a same, less matured
: framework yourself.
: on the other hand, if you can do it better than other framework, why not
: sell the framework yourself? Why do app?
|
z****e
发帖数: 54598 | 14 我跟你感觉不一样
我觉得本来很多东西就有共通的需求
比如都有网络对于协议的封装的需求
然后基于这些需求，作出了一个框架来解决问题
这样什么telnet，php什么就都不是问题了
但是问题在于，框架的作者往往在一开始解决了绝大多数人共通的需求
然后就没事做了，但是资金开始往他们手中聚集，因为他们的框架成功了嘛
然后就尝试解决剩下需求，结果就越做越大，总是尝试什么问题都搞定
最后整个框架变得臃肿不堪，变得很复杂，到最后就会逐步走下坡路
因为大多数人用不到全部的需求，就像windows一样
一开始很成功，结果什么都有，人们就开始厌恶这个东西
现在模式都是先做一个基础的平台，然后建设plugins
就像eclipse这些东西一样，表什么都做，做minimum就好了
剩下的，你要你再down再install，这种模式成功的不少
vert.x最好的就是，它不是什么都塞给我，就塞给我最少的最基本的
剩下的我自己组合就好了
但是不能因为框架变得复杂而否定框架的作用
否则你进一步就会开始否定os的意义
os和语言本身都是一些基础的框架，越底层其实越没啥意思
了。
【在 m**u 的大作中提到】
: 很多时候，使用这类的框架给人的感觉就像贪小便宜，一看开始看着是赚了，省了不少
: 事，但随后会发现，后面的开发都需要为了框架来折衷，倒是把问题本身放到第2位了。
: 当然不是说开倒车就没有问题。不过感觉上，应该避免形成所谓的框架，这种东西最后
: 会变得越来越密耦合，结果变成为了框架而框架。
|
m**u
发帖数: 541 | 15 确实是这个问题，很多（可能是所有的）框架开始的时候思想是正的，确实有用，但问
题是走着走着就朝着高大全去了，结果使用的人就傻了，只好围着这个框架转，本质上
等于是被绑架了，非常尴尬，抛掉得从头重来，要命，继续也很要命。
所以问题的本质是框架的走向问题。 而且现在 似乎很多开发人员都觉得 简单哲学 过
时了，非要眉毛胡子一把抓， 解决就形成了这种尴尬。
再加上马农的小农意思根深蒂固， 互不服气，结果经常吵叫， 最后经常散架，这在开
源体系里尤其明显，最后经常自己折腾自己。。。。
现在回过头来看看，当年windows基于API的做法还是最有效和合理的。 什么事做过了
都要命。 |
g*****g
发帖数: 34805 | 16 You can't quite change the frameworks. But you can choose the frameworks
that are most suitable. And unless you are doing some really cutting-edge
works, chance is that there's always a proven one that works for you. It
does take experience and/or evaluation to find the one.
Frameworks these days tend to be light. Spring 2.5.x was one library that
contains everything. Now it's 20 smaller libs.
【在 m**u 的大作中提到】
: 确实是这个问题，很多（可能是所有的）框架开始的时候思想是正的，确实有用，但问
: 题是走着走着就朝着高大全去了，结果使用的人就傻了，只好围着这个框架转，本质上
: 等于是被绑架了，非常尴尬，抛掉得从头重来，要命，继续也很要命。
: 所以问题的本质是框架的走向问题。 而且现在 似乎很多开发人员都觉得 简单哲学 过
: 时了，非要眉毛胡子一把抓， 解决就形成了这种尴尬。
: 再加上马农的小农意思根深蒂固， 互不服气，结果经常吵叫， 最后经常散架，这在开
: 源体系里尤其明显，最后经常自己折腾自己。。。。
: 现在回过头来看看，当年windows基于API的做法还是最有效和合理的。 什么事做过了
: 都要命。
|
o**2
发帖数: 168 | 17 Framework翻译成框架，还是挺准确的，突出了其是一个有frame/框的刚性结构。
一般来说，框架基本上都是基于Strategy和Template method之类的设计模式，这和现
有编程语言以及人思维的特性有直接的关系。
现有编程语言的特性是它们的组织结构和引用机制，比如object和reference，决定了
它们要先组成小集团、小context，然后逐步组成大集团、大context，这样一个
context外面的caller基本上就只能按该context指定的方式去访问。
这个是导致框架缺少柔性、灵活性的根本原因，从而框架间不容易合作、框架本身不容
易重组，也就是楼主提到的问题：人被框架拽下水了。
这种情况，我觉得Joe Armstrong描述得最生动： I think the lack of reusability
comes in object-oriented languages, not functional languages. Because the
problem with object-oriented languages is they’ve got all this implicit
environment that they carry around with them. You wanted a banana but what
you got was a gorilla holding the banana and the entire jungle.
我对functional programming不感冒，所以我自己另搞了Lemina Computer来克服现有
编程语言的这个问题。
我回这个帖，也是因为刚好我在写一篇这个主题的文章，还没有完成，不过有个示意图
可以在这里分享一下。
Lemina Computer里面只有一种programming unit，不是object，是一种有自我执行能
力的Lemina Function，静态形式就象C语言里的function。
一个Lemina function的reference是一个string，可以直接寻址，这保证了任何一个
Lemina function可以参与多个框架，还可以同时是freelance。
一个caller可以异步或同步地调用一个Lemina function。
这里不多介绍了，其它已完成的文章在Leminasoft.com/docs/，有介绍模型的，有介绍
proof of concept，还有代码，一个最简单的Lemina Computer就500行Java/C#代码，
使用者完全不用担心被绑架了。 |
m**u
发帖数: 541 | 18 这类框架有很多的无解问题，遵循着无解的概念， 所有就会有各种 xxxJS框架 ，只不
过是再添加一个instance而已。。。
希望楼上的能跳出这个圈子。所有的类项目都是开始看着不错， 中程就大吵，然后大
改，然后高大上，然后用的码农就傻眼了。。。。真心的希望，能不再重复这个 循环。
实际上， 俺已经对开源的代码有了完全不同的认识， 既然是 开源， 那本质上＝＝＝
没有责任，所以改动也好，放弃也好，都是由着开发人员随心而定，因此很不靠谱。 |
h**********c
发帖数: 4120 | 19 其实搞工程的人就是古代的雕刻匠
精雕细刻不挣几个钱，出事还要掉脑袋
喜欢disrupt，冒险不如去跟cartel混
【在 m**u 的大作中提到】
: 今天正式决定， 开历史倒车，啥Framework都废掉，以后不允许使用任何framework。
: 需要的话，自己建库，而且，只能是最简单、没有任何关联的库。
|
b******y
发帖数: 9224 | 20
Test driven development
【在 l******t 的大作中提到】
: 一猴子吃花生前都要先塞进屁股再拿出来吃。对此管理员解释道：曾有人喂它桃子，结
: 果桃核拉不出来，猴子吓怕了，现在一定要量好再吃。
|
w**z
发帖数: 8232 | 21 你具体用了啥框架？框架选错了，或不active 是比较惨。所以选择是要谨慎。但不能
因为选错一次就把所有的open source 全打到。
环。
【在 m**u 的大作中提到】
: 这类框架有很多的无解问题，遵循着无解的概念， 所有就会有各种 xxxJS框架 ，只不
: 过是再添加一个instance而已。。。
: 希望楼上的能跳出这个圈子。所有的类项目都是开始看着不错， 中程就大吵，然后大
: 改，然后高大上，然后用的码农就傻眼了。。。。真心的希望，能不再重复这个 循环。
: 实际上， 俺已经对开源的代码有了完全不同的认识， 既然是 开源， 那本质上＝＝＝
: 没有责任，所以改动也好，放弃也好，都是由着开发人员随心而定，因此很不靠谱。
|
