And apps like Notion and Obsidian have to use web technologies because there are simply no alternatives.
Even those React rich text editors don't support React Native.
It's just way too hard to solve this problem for medium-sized teams.
2,155 karma · joined April 8, 2018
Even those React rich text editors don't support React Native.
It's just way too hard to solve this problem for medium-sized teams.
With that being said, managing personal projects is simpler than "management" which involves human interations.
In short, start with a basic pen, paper or notepad-like software. Update it as shortcomings appear. Managing is like designing data structures or databases: it involves "reads" and "writes" (I actually mean "search and read" and "search and write", to be percise), starts simply, and is designed around use cases.
I've applied this to cooking. I used to struggle finding spices in a deep drawer. I realized they were organized like a stack, making it difficult to reach the ones at the back. I moved them to a wider drawer. The frequent used ones shuffles to the front, whereas the less used are left in the back. And with time, I memorized their rough locations.
This process mirrored data structure design: starting with a minimal structure (linked list), moving to a more complex one when it becomes slow (search trees), and further improving it when it gets imbalanced (AVL tree). You'll not going to invent red–black tree in the first place - even copy it from the text book is a pain.
This perspective can be applied to anything - digital data, paper systems, or physical spaces. 'Reads' and 'writes' costs are determined by the system you use. System efficiency depends on its use case and time as costs are "amortized".
A few examples:
Diary: Easy to write, harder to read. Low overhead makes it enjoyable to write.
Dictionary: Takes longer to write, quicker to read. The large audience justifies the high writing cost for well-organized indexes.
Research notes: Balanced read-write (citations and knowledge graph). Constantly evolving knowledge even makes folders inadequate, hence the popularity of software like Obsidian and systems like Zettelkastens. But such systems take efforts to build so most people adopt instead of developing their own.
RDBMS: Balanced read-write but difficult to develop.
Kafka-ish DB: Designed for high-speed writing. RDBMS is too slow for its use case due to constant indexing.
Your system will depend on your use case, which will emerge over time.
This is like DeepFloyd but probably combined with OpenAI's strength in NLP field.
I remember Ilya Sutskever often mentioned how multimodal is important in multiple interviews. ControlNet can produce more impressive results for sure, but the model being able to have strong understanding of multimodals like language and light and space as a unified modal will push the industry forward towards the goal of AGI.
If you do some "real world pizza making" instead of toying, that function would be like at least 1k lines, including how you carefully shape the dough, how to handle exceptions when you tear some holes, and how you should observe and rotate in the oven by how much, how you should redo it if the roller blade just didn't cut through properly, so on and so forth. Of course it's better to have top-down overview like prepare -> bake -> box otherwise the readers will surely lose themselves in details without figuring out what is happening.
People in the game industry told me their horror story of helping designers with a Lua script that they were writing over the years. And it turned out the "Lua script" was a single file, with 100k+ lines, that bearly had several functions in it. That would be SO linear.
Yeah. I was trying to explain why the chaotic parts are there and there are quite some notable exceptions.
> I think to be honest there you need to say cities not towns
TBH I was very hesitant to pick the word town or city or any others because in my mind it was the generic "城/Cheng" in Chinese. I find the nouns are often culturally specific as cities, castles, churches, and towns are European-oriented and more specific than "Cheng".
> Also, but I wouldn't really consider Shanghai a southern city, would you?
It's a southern city. Geographically speaking, China was divided by the Yangtze and the Yellow River into three 1/3 parts. Shanghai is located on the Yangtze so it's in the South. The south/north divider is the Qin Mountain range and Huai River line [0]. That's the line where the culture, climate, and pretty much everything differs drastically.
> pick one--Tianjin
Well, that's a sophisticated example that I happen to know about (I just realized there's even a wiki but in Chinese [1]):
- Almost every taxi driver in Beijing who has been to Tianjin told me how they got so frustrated with the road system. It's not hard to guess, since the roads are around the river and not as perpendicular as Beijing.
- But the old Tianjin was a squared town before the Western countries moved in. The town resides to the west of the river, exactly within today's north, east, south, and west roads (Dong, Xi, Nan, and Bei Malu). In the center it's the drum tower. Outside there were walls and moans and all that.
- So it didn't appear to be particularly chaotic to me at that time, at least there were quite some designs as you can see. And it wasn't nearly as important historically until the West started to settle in China. At least compared to Xi'an, Luoyang, Kaifeng, Zhengzhou, etc.,
- Later, the Western countries set up settlements along the river both on the east and west banks. The city started to grow. That's where the messy road system comes from.
> but what about the suburban places
But yeah, many suburban areas are a mess. While I kind of agree there is some chaotic nature, most culture does that without professional modern urban planning departments. Slums are very, very common outside the first world. Back in the old days in Europe, slums were also easy to be seen outside cities and castles.
Another factor is Tianjin was way messier decades ago. In 1976, there was a great earthquake and Mao died. A lot of the buildings were destroyed or damaged, and a lot of people would then rebuild their houses without proper knowledge and skills. Most of those were lost in the cultural revolution. People would randomly put together bunker-like stuff in random places and call it home. The same situation happened in Beijing - you can find Hutongs in Beijing are very chaotic, which should have been less so before the cultural revolution. Here's a video about the Beijing side of the story [2].
> It permeates the very fabric of Chinese culture
Honestly, I'm not very sure of it. On one hand, it's indeed chaotic as we can often see. There are also Chabuduo (good enough) and Meibanfa (there's nothing can be done) cultures. On the other hand, the Chinese also like to pursue regularity such as a lot of things have to be made in the shape of squares and circles. Numbers in designs and shapes have to be "stable" as 4 and 8. Those are not just for nobles, normal people do care and sometimes OCD about that, too.
I don't know man, if anything, Chinese culture is full of contradictions and confusion as always :)
[0] https://en.wikipedia.org/wiki/Qinling%E2%80%93Huaihe_Line [1] Wiki on old Tianjin (Chinese version only, unfortunately) https://zh.wikipedia.org/zh-hk/%E5%A4%A9%E6%B4%A5%E8%80%81%E... [2] https://youtu.be/3uo47m-1gQ4
> You can see the same "ad hoc"-ratic development "philosophy" at work in Chinese cities today.
First, it was 4000 years ago when the Chinese culture was completely different.
Other than that, it's still not entirely accurate. If anything, the planning is very diverse or bumps between extremes in China. You can check out Beijing or any historically important town with walls on the map. Most of those cities are carefully designed in square shape, and every important building is facing towards the south. Things are intentionally majestic. Form over practically sometimes.
Most of the examples you have mentioned are southern cities, which are probably heavily influenced by the Suzhou garden design. The most famous Suzhou garden is the Humble Administrator's Garden [0]. The idea of the garden is to use a lot of obstacles and irregular shapes to segment zones. In terms of practicality, it creates more "rooms" instead of wasting space with empty squares. In terms of aesthetics, it creates discoverability where every turn provides a different scene. But most importantly, it's carefully non-majestical to not offend the emperor - the holy ruler of the absolute monarchy (who can easily execute any a whole clan at will without justification). You can also feel the uneasiness even in the garden's name itself.
But indeed, a lot of Chinese cultured towns are chaotic by nature. My personal take is regions like Europe and Japan with feudal backgrounds are sufficiently decentralized with proper hierarchy, making every piece of land plan things for themselves, the lords, the church, and the guilds can design and interact back and forth. However, China is purely top-down and lacks organizations between the imperial court and individual levels (the feudal system was brutally wiped out 2000 years ago and made very few unsuccessfully comebacks). Any non-imperial organizations like mansions guides are highly discouraged as those are seen as potential threats. Chinese society in modern terms is a "flat organizational structure", and its people are just individuals (clans and families are often forced apart, and shuffled between lands). As a result, we can see towns as official projects are built in orthodox ways, which are the rest are littered with ad-hocness.
Actually, in the South, there were also quite some fortresses that were well-designed and typically resided in difficult terrains such as Tulou [1] (man, they look like Apple Park). Because they were large clans living in remote provinces, the imperial court had a hard time dealing with them so often the court didn't bother.
> In my experience, the one exception is Hong Kong
As a guy who spends most of my time living in Beijing, my first impression of Hong Kong is its chaotic (in a good way, I love it). You probably know Hong Kong is the most important reference for those cyberpunk concept artworks. Singapore, IMO, is more well thought out beforehand in terms of urban planning.
[0] https://en.wikipedia.org/wiki/Humble_Administrator%27s_Garde... [1] https://en.wikipedia.org/wiki/Fujian_tulou
I agree because I have seen this a lot.
> JavaScript has many missing features. This is not one of them.
While I do agree that abusing Observable might leads to messy code, it's very valuable in highly interactive apps. It provides proper abstraction/algebra which letting you tackle problems like tripple click, which might be extremely tedious to solve otherwise.
And interactivity is one of the natrual thing modern browser should empower developer to achieve (at least for non-die-hard no-JS person).
> But we already have them via the ReadableStream and TransformStream APIs.
I do appreciate that you appreciate simplicity and this sentiment in general. But I feel similar sentiments that led JavaScript to stagnent for a long time (ES6 is just ES4 but more than a decade later).
People like Douglas Crockford found the parity in JavaScript and Lisp, and summarized the beauty in his works. While his book is one of my favorite programming book, the sentiment (JavaScript don't need features because of closure, Lisp-like and all that) was so popular at time, which probably contributes to the stagnant.
(Microsoft and friends was probably happy about this that the web wasn't taking over so fast and they can shit everybody with IE6 for years, and then the mobile and their walled gardens were taking over. In other word, the web had even greater potential in between IE6 and mobile era)
People could really try re-implement their React apps without modern tooling to feel the pain: No ES6 module and abuse closure then cat the all files into one giant ball, only to mess up the order and dependencies. Or without reactivity, updating states everywhere which leads to confusing bugs that making apps out of sync., etc
Maybe we should give it a good name and hopefully seeing OSS adopt this.
As for why it might not make Google worse, just think about YouTube algorithms:
1. One good video is substantially better than hundreds of bad videos, or thousands even.
2. Clickbait works in terms of getting people to click on your video, but if you don't deliver what the clickbait promised people would leave and it would hurt your stats.
3. Generating large amounts of videos may be profitable because it's like collecting peanuts with automation, but that would never reach the mainstream audience like Mr. Beast.
This is because the algorithm promotes videos that are frequently clicked and fully watched. Generated or not, the content must be good enough to be watched through, in order to please the algorithm.
You see, there are a lot of bootleg versions of Stackoverflow, but many of them are terrible. Some of them get ranked because they're still helpful (to the 80% majority of programmers, probably not for the HN elites). We can imagine there would certainly LLM generated versions of those, but very likely with better quality. Generated or not, it's still an arms race to generate more helpful and higher quality content to get traffic.
Also, HN people have been complaining about how the quality of Google degrade over time. It might be Google's fault, but I believe there's another important factor that hurts search engines as a whole - There are too many walled gardens nowadays: Instagram, Discord, and now Twitter, etc. Value information is hiding behind those, which would certainly make search engines less helpful over time.
For example, when I play not very popular video games I wish there are wikis or guides for that. In the old days, I know I can find most of the information in several forums and check the top posts. Now I need to go through Discord and scroll through casual chats and wonder if I missed something.
With LLMs, people would likely be draining that information from walled gardens and compiling them into helpful insights.
Again, there are a lot of dynamics, and it's hard to tell how things would turn out. Maybe it would kill Google and possibly the old Web, maybe it would make the Web great again.
I remember reading in a magazine when I was a kid that Pentium 4 Extreme failed to reach 4.0 GHz in 2003 or 2004.
Since then, it took Intel quite some years to hit 4.0 GHz. Instead, the industry shifted to multi-core CPU, starting with the Core 2 series.
Does multi-core CPU count? I would say it's a bit of a stretch. It's more about horizontal scaling, where multi-CPU or even cluster also work in similar ways - there's no hard limit on how many CPUs you can add as long as you can cool them down. You can also make it much larger and sparse then put it in a large box to deal with the heating problem.
P.S. From the perspective of programming paradigm, people would then find "share nothing" and "message passing" is the way to harness concurrent and multi-core programming, after getting burned again and again with shared memory. These disciplines of not sharing RAM would further make multi-core more like programming on multi-CPU or clusters.
The past decades were dull for me in terms of programming languages, compared to the era of Scheme and Prolog. But the computing industry advanced steadily: multi-core programming, map-reduce clusters, CUDA, etc. And these led to these crazy generative neural networks we see today.
I recall GJS gave several talks on this "We Don't Know How to Compute". I can't find the source and I skimmed this video and couldn't find it, but I remember he talked about how Gecko (or Lizard I'm not sure) could be transplanted with extra arms and still function. It strikes me as how much we don't know about computing, if we view biology and other things as computation.
Now, with the AI hype, these frontiers seem open again to exploration. For example, you can give AI agents goals and tools and let them act on their own, it's still clunky but it works and it's improving fast every single day. It's just that we haven't figure out the patterns, implications and best practices yet. Exciting times!
E.g. reversing, weak encryption, Cyrillic alphabet, or translating them into other languages
For those residing in urban China, it is nearly impossible to avoid owning a smartphone equipped with Chinese apps. This is particularly true during the COVID era, when a green QR pass from these apps is necessary for going anywhere. Mobile technology has become deeply ingrained in Chinese society.
As the project progresses, the AI model would likely gain a better understanding of the client's values and principles, leading to improved results and potentially valuable insights and feature suggestions.
Until someone creates a well-thought decentralized CF alternative from the ground up, which solves bad actor, slow and unstable node problems, with clever incentives, et cetera et cetera, we'll be stuck with centralized solutions.
However, it's sad to see it's growth is likely to be capped - because JVM languages is not that fashionable like 2003 or 2007. What's in nowadays is Go and Rust: bear metal, small binary, fast startup speed, solid module packaging system (without all historical stuff or touching Maven), etc.
Even though Scala Native is there, the language was tailored for JVM and it will never get rid of that.
Maybe a ground-up Scala-like language like Go or Rust could fill in the market and gain popularity? A language with GC/runtime like Go but not as awkward on abstrations. But it's unlikely to happen - the compiler would be much harder and complex to implement compared to Go.
Take a look at the Stable Diffusion community: images generated from plain prompts like "a guy walking on the street at night" returns extremely blend images, while throw in a bunch of modifiers like "futuristic", "cyberpunk", "4K", "perfect face", "trending on Artstation", "realistically shaded", etc actually adds in real vibe of art.
Also, sometimes the ways are not obvious. In the first place the model having difficulty on drawing hands. But later people find negative prompts which essentially saying "I don't want ill-drawned hands" works surprisingly.
I'm convinced the single biggest factor is the wrong incentive leads to poor quality, well beyond other factors like the paywalls, publications, etc. Not only it disinterests reader but more importantly, it push away good writers. Content is the beating heart of your platform.
It started out like a beautiful small town. The residents are nice and talented, the streets are clean and elegant - it attracts tourists.
It went wrong when the incentive encouraged bad actors to resides in town - litters and tea scammers are everywhere. Not only they're hurting tourists, they discourage good actors from residing in - nobody wants to live in dirty neighborhood and live with bad neighbors.
Thus the negative feed back loop, which causing the infinite downward spiral on quality.
JavaScript, C/C++, Python are very old and the package systems were pretty much bolt-on. And of course a lot of historical factors were playing a bit role.
In the old days, people usually start minimal. When they get burned they also find they were locked-in - thus the bolt-ons.
> we apparently have no "package management theory"
People are definitely standing on top of each others' shoulders. Node.js npm actually felt like Ruby package tools but also being first-party (they also cut some corners, and made some design choices - some worked well and some didn't).
i.e. Hex for Elixir feels like nothing new, but avoided most common pitfalls others have experienced. I believe most language designers nowadays can do the same, given they want to play it safe and want nothing too novel.
- No extra app. People scan the QR in WeChat (everybody has it) on the table, it will call a mini-app dynamically (somewhat similar to React Native but interpreted in WeChat).
- You are putting orders directly.
- You are paying within WeChat as well so it's seamless.
- The app is smooth because almost every restaurant is using the takeout giant Meituan's mini-app.
- Almost every single restaurants in China is tech savvy enough to use those systems because it's already a take-out centered society. Restaurants not leveraging these systems have virtually zero chance to survive the competition.
- You don't have to wait for anything or talk to anybody in the whole process.
The problems people mentioned in this thread:
- Minorities, people without smart phone or those are less tech savvy, are left behind.
- The walled garden and monopolies and such.
These problems are real, but it's probably not the QR menu to blame, because it's a far greater problem - in China, you are not allow to go anywhere without WeChat and scanning QR code due to those draconian regulations.
In this post-mortem talk [0] on Diablo 1. The creator mentioned his worst business decision - the Hotmail guy offering 10% of the company in return for an office in the back they weren't even using, and he rejected it.
According to him, the pitch was: "I'm going to make email over the Internet".
His response: "Dude, that's the dumbest idea I've ever heard! What are you talking about, I already have my email over the Internet - this isn't even an invention!".
14 months later, that 10% was worth $40 million. Meanwhile they agreed to do Diablo only for $300k for Blizzard, and that was a bad deal - they even had to find more contracts to compensate it.
But recently it is booming. The reason is not related to DALL·E, but Stable Diffusion.
Stable Diffusion is 1) open sourced 2) the model is small and easy enough to run on people's computer. As a result, it can embed in a lot of tools and services, so people are getting excited and start building ecosystem and business around it. When people can create art without effort, how to streamline the creative process and dealing with giant amount of arts are going to be the problems that worth solving.
As for use cases, I can see it either replacing a lot of artists or being one of the most important tool for artists, or both. Also, it might flood the Internet with its creations in the following years so be prepared.
2. The trade-off is more about computation in general. In typical "service" scenarios you almost always want to prioritize latency over throughput, while in most "batch processing" scenarios which you want to optimize overall processing time you want to prioritize throughput.
Examples:
1. Erlang server: Great preemptive scheduling thus the theoretical overall computation throughput is relatively lower. But in practice, Erlang servers are extremely fast and responsive. (Prioritize latency over throughput, great for "services")
2. Traditional C/Java blocking (non-async) server spawns threads: Theoretical computation throughput is greater but in reality, it's very easy to DDoS it. (Great for batch processing but suck at "services")
Phoenix comes with its own database tool called Ecto[0] which is excellent, and it uses Postgres by default. If you're not intended to leverage CouchDB for offline support you should go Postgres without a second thought.
That said, I'm also curious about how to implement offline support with Phoenix in a nice and trivial way.
[0] "A language that doesn't affect the way you think about programming is not worth knowing." -- Alan Perlis
One thing they can do is they can come up with a design system. Let them do the case studies together and came up with the solution together.
A design system, in essence:
- is a common language they can communicate with.
- is their consensus that they could agree upon.
- if they do the case study right, it will be a set of sane designs that works great on the target platform (Web, mobile, etc.)
Go through the first half of Crafting Interpreters [0]. And then try to complete mal - Make a Lisp [1]. That's it. You'll only need these two.
P.S. People also say good things about Build Your Own Lisp [2], but I didn't finish it because I find spending quite some time writing C doesn't make me feel I'm enjoying something elegant.
[0]: https://craftinginterpreters.com/ [1]: https://github.com/kanaka/mal [2]: https://buildyourownlisp.com/
But I prefer touch typing with two-piece split keyboards on the bed, instead of raising hands.
But GraphQL as a solution is not great. It looks nice in the first place, but there is too much hassle to deal with.
P.S. I've seen quite a fraction of GraphQL projects actually using Node.js as the backend. If that's the case I would recommend TRPC[0] over GraphQL - it's more seamless and straightforward.
[0] https://trpc.io/