4 ms·

I think you and I both know - once you've run with something long enough, you hit a wall. Everything - every language, framework or tool hits a wall. You hit yo

by jnoller 16y ago

I think you and I both know - once you've run with something long enough, you hit a wall. Everything - every language, framework or tool hits a wall. You hit yours with Django because you fundamentally disagreed with some of the design decisions. I personally have not hit my wall (with django) but I see plenty of room for improvement. It's awesome you built something so quickly with Rails - I have a similar experience with Django (a tiny amount of time to build a really deep application). I personally found it amusing/bothersome that you were lauding a fairly magical and opinionated framework when you had old posts deriding Django (and it's ORM) in the past.

snprbob86 16y ago
I like opinionated software. Especially when it matches my opinions. And if it doesn't match my opinions, it is easy to dismiss it. It isn't the magic about Django (and it's ORM) that I didn't like. It was the design decisions that didn't match how I think (and approach of declaring the DB schema in code).
- jnoller 16y ago
  We (mostly) agree then. The non-opinionated stuff makes me 1000x more angry then something silly like lack of class-based views, or the inclusion of GIS in contrib (for Django). I was probably overly sarcastic in my original comment, so for that I'm sorry.
berntb 16y ago
>>once you've run with something long enough, you hit a wall. Hmm... resonates. Sounds like an insight. That would implicate flexibility in languages, editors and frameworks -- so you can tunnel through the wall. More Ruby/Perl than Python and more Emacs/Vim than most IDEs. Etc.
- jnoller 16y ago
  Nice try; but having more flexibility can be just as damning as not enough. Me, and plenty of others, have found that we know where, say, Python's wall is and accept it or we go around it. The wall I'm talking about is the mental barrier where you either no longer want the tradeoffs involved, or find you disagree with a fundamental axiom of the thing under inspection. Drilling through it is impossible without discarding it entirely. Having flexibility to drill through that wall just puts a bigger, harder wall someplace else. And other people find Emacs/VIM ideas perfectly workable IDEs, and find the flexibility of Emacs and VIM horribly confusing. You have to know, and accept the wall and limitations - it's a series of tradeoffs, and you just need to know what you're getting in the trade. In the case of frameworks, it's just a bigger set of tradeoffs as they tend to be a lot more opinionated, which means you're trading more for comfort.
  - berntb 16y ago
    Hmm... I don't yield the point yet. :-) Emacs is use optimized, not learning optimized. It takes lots of time -- if you don't use it for hours a day, it is probably not worth it. Org mode in Emacs is a good example. It took embarrassing long to learn for me -- while the GUI variants (e.g. gjots2) are trivial. But now, I can take notes and doodle with Org mode that I could only do on paper before. It is built into my fingers in a way which IDEs/GUIs failed for lots of years. I'd argue that Emacs is without a wall for programmers. (-: As long as you don't want to do word processing with WYSIWYG. :-) The problems will be new areas, like how will text understanding libraries (theoretical concept, not in that area) integrate with Emacs compared to others. You could probably do the same arguments for Perl and Lisp. But I don't know any framework I'd say the same about. Edit: Thinking back on my life, I'll yield the point re frameworks. Not libraries, for a not too large problem (a pack of collected libraries would have a wall in a bad Big-O for complexity/time). Edit 2: You could put my argument to be that the last decades of history shows Emacs to be, for all practical [programmer] purposes, infinitely flexible -- as long as new functionality can be integrated to the normal Emacs usage. Which is a big caveat, yes. Org isn't the first generation of that kind of note taking modes in Emacs, the evolution was afaik in much how Org was used.
    - jnoller 16y ago
      Emacs might be insanely flexible, sure, but at what cost? Bloat? Infinite complexity? Heck, I get frustrated with my VIM configuration sometimes because I forget the less used keybindings when I really need them, and need to go spelunking. So sure; if you're willing to trade the up-front investment of time (not insubstantial) Emacs will go far - and the wall is way off on the horizon and someone scribbled "complexity" on it. Up-front investment can't be underestimated; there's a reason why things like Textmate (which starts simple, and grows out well) are so popular. Low initial investment, and plenty of ramp, and it works out well until it simply doesn't. That low initial barrier is easier to climb, and while emacs (or even VIM) might have a wall that, when compared to Textmate's, is infinitely far away, textmate will still have fantastic adoption. The wall textmate has is further off then most people are willing to worry about. For most people, a framework, like, say, Django or even Rails offers a wall far enough out that most people don't need to worry about it, but when they hit that wall, they're going to hit it hard, and kinda be mad.

by jnoller 16y ago

snprbob86 16y ago

I like opinionated software. Especially when it matches my opinions. And if it doesn't match my opinions, it is easy to dismiss it. It isn't the magic about Django (and it's ORM) that I didn't like. It was the design decisions that didn't match how I think (and approach of declaring the DB schema in code).

jnoller 16y ago
We (mostly) agree then. The non-opinionated stuff makes me 1000x more angry then something silly like lack of class-based views, or the inclusion of GIS in contrib (for Django). I was probably overly sarcastic in my original comment, so for that I'm sorry.

berntb 16y ago

>>once you've run with something long enough, you hit a wall. Hmm... resonates. Sounds like an insight. That would implicate flexibility in languages, editors and frameworks -- so you can tunnel through the wall. More Ruby/Perl than Python and more Emacs/Vim than most IDEs. Etc.

jnoller 16y ago
Nice try; but having more flexibility can be just as damning as not enough. Me, and plenty of others, have found that we know where, say, Python's wall is and accept it or we go around it. The wall I'm talking about is the mental barrier where you either no longer want the tradeoffs involved, or find you disagree with a fundamental axiom of the thing under inspection. Drilling through it is impossible without discarding it entirely. Having flexibility to drill through that wall just puts a bigger, harder wall someplace else. And other people find Emacs/VIM ideas perfectly workable IDEs, and find the flexibility of Emacs and VIM horribly confusing. You have to know, and accept the wall and limitations - it's a series of tradeoffs, and you just need to know what you're getting in the trade. In the case of frameworks, it's just a bigger set of tradeoffs as they tend to be a lot more opinionated, which means you're trading more for comfort.
- berntb 16y ago
  Hmm... I don't yield the point yet. :-) Emacs is use optimized, not learning optimized. It takes lots of time -- if you don't use it for hours a day, it is probably not worth it. Org mode in Emacs is a good example. It took embarrassing long to learn for me -- while the GUI variants (e.g. gjots2) are trivial. But now, I can take notes and doodle with Org mode that I could only do on paper before. It is built into my fingers in a way which IDEs/GUIs failed for lots of years. I'd argue that Emacs is without a wall for programmers. (-: As long as you don't want to do word processing with WYSIWYG. :-) The problems will be new areas, like how will text understanding libraries (theoretical concept, not in that area) integrate with Emacs compared to others. You could probably do the same arguments for Perl and Lisp. But I don't know any framework I'd say the same about. Edit: Thinking back on my life, I'll yield the point re frameworks. Not libraries, for a not too large problem (a pack of collected libraries would have a wall in a bad Big-O for complexity/time). Edit 2: You could put my argument to be that the last decades of history shows Emacs to be, for all practical [programmer] purposes, infinitely flexible -- as long as new functionality can be integrated to the normal Emacs usage. Which is a big caveat, yes. Org isn't the first generation of that kind of note taking modes in Emacs, the evolution was afaik in much how Org was used.
  - jnoller 16y ago
    Emacs might be insanely flexible, sure, but at what cost? Bloat? Infinite complexity? Heck, I get frustrated with my VIM configuration sometimes because I forget the less used keybindings when I really need them, and need to go spelunking. So sure; if you're willing to trade the up-front investment of time (not insubstantial) Emacs will go far - and the wall is way off on the horizon and someone scribbled "complexity" on it. Up-front investment can't be underestimated; there's a reason why things like Textmate (which starts simple, and grows out well) are so popular. Low initial investment, and plenty of ramp, and it works out well until it simply doesn't. That low initial barrier is easier to climb, and while emacs (or even VIM) might have a wall that, when compared to Textmate's, is infinitely far away, textmate will still have fantastic adoption. The wall textmate has is further off then most people are willing to worry about. For most people, a framework, like, say, Django or even Rails offers a wall far enough out that most people don't need to worry about it, but when they hit that wall, they're going to hit it hard, and kinda be mad.