6 ms·

For a small hobby editor, this is fine. For anything serious, much of this advice will not scale at all.

wudangmonk 4y ago
Obviously when you want to scale things up, specially to webscale you want mongodb but I rather like the approach of bootstrapping the minimum viable product and then actually using it in order to design the rest. The world would be a much better place if that was the case.
- aliqot 4y ago
  > when you want to scale things up, specially to webscale you want mongodb What is about coffee in your actual nostrils that wakes you up more than the full cup itself?
  - chefandy 4y ago
    > What is about coffee in your actual nostrils that wakes you up more than the full cup itself? Not the person you're replying to, but as a food and beverage expert, I'm confident most beverages will yield more powerful emotional and physical responses and quicker absorbtion of many chemical components when taken nasally.
- chatmasta 4y ago
  Perhaps OP should try piping their code to /dev/null, which is fast in web scale. Does this editor support sharding? Shards are the secret ingredient in the web scale sauce. They just work.
  - dr_kretyn 4y ago
    Thank you for reminding this gem https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
reducesuffering 4y ago
“Do things that don’t scale” http://paulgraham.com/ds.html http://paulgraham.com/ds.html
helsontaveras18 4y ago
I don’t want to diminish the work the author has done. For a nice hobby project, sure hack away! But if you are looking to give this to the world, the lack of planning and emphasis on testing is less than ideal. It wouldn’t hurt to play with some editors and write a spec so data structures and algorithms can be planned appropriately. After all, there are tons of great examples to get inspiration from!
mindhash 4y ago
the question is 'what is serious?' generally one can go about every piece of code with a mindset that if it fails the sky will fall, or on the other extreme 'let it fail' philosophy. I like to take a mix of slow and fast approach. While some cases demand test-driven development, in other scenarios the test cases can follow the user demand. I like to build test coverage slowly depending on most used parts of the code. So they coverage catches up slowly but at the same time i am not spending time on test cases for things that don't get used at all. This means, I would prefer releasing features in small batches and as the features start being used, I start improving the coverage. While this may not work for all the teams or environments, it is one approach to build early stage products. which I mostly do.
- designed 4y ago
  Most if not all of the points are not applicable when medical software and firmware is involved. I could never play so fast and loose at work.
coldtea 4y ago
Most serious editors started as small hobby editors, including Vim and Emacs What historically doesn't scale is trying to get everything "scalable" and "extensible" from the get go - most ambitious projects like that get abandoned because they get the initial designs wrong and its too hard to change, or because there's just too much effort to get to usable state...
- lmm 4y ago
  Not convinced. I worked on a project with some friends that got to about 20kloc and then collapsed under its own weight because it became impossible to change anything without breaking something else. While there's a wrong way to design for scaling or extensibility, development practices that rely on holding the whole thing in your head will hit a brick wall sooner or later.
  - jackblemming 4y ago
    It's fascinating reading posts like this from people who have actually put in the work on 20k+ LOC projects with multiple people and those who just repeat a few articles or blog posts they read. The difference is stark.
    - coldtea 4y ago
      I find the comment a little rude, as if implying the grandparent poster (me) "just repeat a few articles or blog posts they read", whereas the anecdotal parent comment about a 20k+ project they've worked on shows the real experience. I've worked in multiple 20k+ LOC projects with other people and everything (teams of 10 or more people are good enough to you?). And 20k+ is not even that big, it's not like it offers any great insight regarding software development.
      - Arch-TK 4y ago
        I don't think the size of a project is that important if you're looking for insight into software development. There's certainly poor ways to go about developing small and large projects and most of the insight is to be gained from looking at the mistakes (and lack thereof), whether it's a 100 line piece of glue you wrote which became unreliable and caused major issues or if it's some 100k line project which became increasingly difficult to maintain.

Obviously when you want to scale things up, specially to webscale you want mongodb but I rather like the approach of bootstrapping the minimum viable product and then actually using it in order to design the rest. The world would be a much better place if that was the case.

aliqot 4y ago
> when you want to scale things up, specially to webscale you want mongodb What is about coffee in your actual nostrils that wakes you up more than the full cup itself?
- chefandy 4y ago
  > What is about coffee in your actual nostrils that wakes you up more than the full cup itself? Not the person you're replying to, but as a food and beverage expert, I'm confident most beverages will yield more powerful emotional and physical responses and quicker absorbtion of many chemical components when taken nasally.
chatmasta 4y ago
Perhaps OP should try piping their code to /dev/null, which is fast in web scale. Does this editor support sharding? Shards are the secret ingredient in the web scale sauce. They just work.
- dr_kretyn 4y ago
  Thank you for reminding this gem https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs

reducesuffering 4y ago

“Do things that don’t scale” http://paulgraham.com/ds.html http://paulgraham.com/ds.html

helsontaveras18 4y ago

I don’t want to diminish the work the author has done. For a nice hobby project, sure hack away! But if you are looking to give this to the world, the lack of planning and emphasis on testing is less than ideal. It wouldn’t hurt to play with some editors and write a spec so data structures and algorithms can be planned appropriately. After all, there are tons of great examples to get inspiration from!

mindhash 4y ago

the question is 'what is serious?' generally one can go about every piece of code with a mindset that if it fails the sky will fall, or on the other extreme 'let it fail' philosophy. I like to take a mix of slow and fast approach. While some cases demand test-driven development, in other scenarios the test cases can follow the user demand. I like to build test coverage slowly depending on most used parts of the code. So they coverage catches up slowly but at the same time i am not spending time on test cases for things that don't get used at all. This means, I would prefer releasing features in small batches and as the features start being used, I start improving the coverage. While this may not work for all the teams or environments, it is one approach to build early stage products. which I mostly do.

designed 4y ago
Most if not all of the points are not applicable when medical software and firmware is involved. I could never play so fast and loose at work.

coldtea 4y ago

Most serious editors started as small hobby editors, including Vim and Emacs What historically doesn't scale is trying to get everything "scalable" and "extensible" from the get go - most ambitious projects like that get abandoned because they get the initial designs wrong and its too hard to change, or because there's just too much effort to get to usable state...

lmm 4y ago
Not convinced. I worked on a project with some friends that got to about 20kloc and then collapsed under its own weight because it became impossible to change anything without breaking something else. While there's a wrong way to design for scaling or extensibility, development practices that rely on holding the whole thing in your head will hit a brick wall sooner or later.
- jackblemming 4y ago
  It's fascinating reading posts like this from people who have actually put in the work on 20k+ LOC projects with multiple people and those who just repeat a few articles or blog posts they read. The difference is stark.
  - coldtea 4y ago
    I find the comment a little rude, as if implying the grandparent poster (me) "just repeat a few articles or blog posts they read", whereas the anecdotal parent comment about a 20k+ project they've worked on shows the real experience. I've worked in multiple 20k+ LOC projects with other people and everything (teams of 10 or more people are good enough to you?). And 20k+ is not even that big, it's not like it offers any great insight regarding software development.
    - Arch-TK 4y ago
      I don't think the size of a project is that important if you're looking for insight into software development. There's certainly poor ways to go about developing small and large projects and most of the insight is to be gained from looking at the mistakes (and lack thereof), whether it's a 100 line piece of glue you wrote which became unreliable and caused major issues or if it's some 100k line project which became increasingly difficult to maintain.