It feel silly to say that AI is curing cancer. Normally a phrase like that would sinal the apex of the hype cycle but I guess it actually has some meat in this situation. Using AI more like statistical inference to screen for medical conditions or predict treatment could be helpful. I remember Jeremy Howard from fast.ai did that with deep learning to detect things in medical images. Seems like a good thing for CERN to do as long as it works.
Readit Newsgreenyouse commented on CERN trains AI models to revolutionize cancer treatment english.elpais.com/health... · Posted by u/geox
greenyouse commented on Ask HN: What AI Software Product/Software Do You Need? · Posted by u/iiJDSii
Here's a fun project that you could try. Use TTS to transcribe books but make the transcriptions feel more realistic. Give each character in the book a unique voice. Leading characters should have voices based on their personalities. Use quote extraction and character attributtion to tie characters to lines. Try to do convey the human qualities with EmotionML, SSML, or some kind of semantic analysis.
The best would be a TTS system at the level of OpenAI's but with voice selection like GCP TTS so you can get quality and a range of voices.
Copyright would probably spike any monetization effort but you could try. It would be nice to have an open source tool for this though! :)
In a remote world, can that person exist?
That would depend on the culture of your team and larger workplace. Healthy teams should be checking in frequently to talk about ideas, reviewing big things, scoping upcoming work, etc. If there's time reserved for deeply technical but loosely structured discussion like that, then everybody takes turns being that person. In that env someone could "specialize" in it and help inspire others to do great work.
It's the team that creates that kind of opportunity for feedback though. If the team has dysfunctions like rejecting deeper discussion or not working beyond jira tickets or checking out at meetings, etc. then it's not going to work. Someone that's good at that kind of supporting discussion will feel push back when fostering those discussions so it will fall off over time.
The teams that do the best work and are the most fun to be on can host those types of discussions though, even remotely. It's worth experiencing if you haven't!
Check out the Upwind section of this PG essay (and the rest of the essay).
http://www.paulgraham.com/hs.html
What do you want to do with coding? What's going to give you the most leverage in the long term?
That course is going to dump you into the deep end for modern web dev. You'll probably struggle with it because it's taking on a bunch of things all at once. Some of the technology is also temporary. Will MongoDB or GraphQL still exist in 30 years? Will HTML, CSS, and JS exist in 30 years? Focus first on fundamentals that will give you a leg up.
I know professional frontend devs that still struggle with HTML because they went straight into React without learning semantic HTML first. If you can master the basics early on, then learning React and other frontend frameworks later becomes way easier.
Start with building web pages rather than web apps. You can do apps later but there's a lot more stuff going on. It's like trying to ride a unicycle while juggling flaming torches and balancing a spoon on your nose. Maybe you could sort of figure it out but it's better to split up the tasks and handle each in turn. That course is for people that already know the basics and want to try balancing on a new unicycle.
If you want ways to practice frontend, try building copycats of websites. Read the DOM, look stuff up, make lists of HTML elements or JS built-ins and memorize them. Play games to learn CSS flexbox or grid. Do whatever as long as you like it and it's teaching you the way.
There's lots of other stuff like frontend challenge sites that are good too. You'll always be "challenged" going forward for professional projects. Some might be really easy tasks, others will be hard. Get used to being resourceful and learning how to figure things out. It's an infinite game.
This style of learning isn't unique to frontend. If you wanted to be a backend dev, learning Spring Boot before design patterns, networking, etc. would probably be a bad idea. It's better to start as a beginner and embrace learning the basics. Go slow and master things step by step. Eventually it pays off.
You could also zoom out and abstract things to help with programming languages. Popular languages are pretty similar. Familiarize yourself with basic control flow syntax in one language and chances are it carries over into others. The same goes for "paradigms" like imperative, OO, and functional programming (others exist but they're more niche). Learning a paradigm is like rebuilding the thought process for your brain. If you learn different paradigms, then your thinking gets more flexible and you can approach problems differently. You might like the "aha" moments you get when things finally connect too!
greenyouse commented on Htmx is part of the GitHub Accelerator htmx.org/posts/2023-06-06... · Posted by u/jjdeveloper
Don't forget Polymer, whose main marketing was that it's the tech behind... McD's menu screens. It turned into lit html, I have no idea what the state of that is now, haven't heard from it for a while now.
Polymer powered a few other things at Google too. Look at the DOM for YouTube, that dev team started with Polymer for Web Components and talked about how they built an internal library of custom HTML for the site. Doing that shared library approach seemed like a good way to scale out development across teams. It seems like it's still alive and well over there. (also used at ING, Comcast, Vercel, and others)
I still have hope that frontend will eventually turn back to web components now that HTML templates, Custom Elements, Shadow DOM, and ES Modules are fully adopted. One of the problems is that this stack is foreign even to professional web devs that hail from React land. It's weird because it's native browser tech adopted by the W3C and painstakingly built into the browsers. Maybe it picks up after someone rewrites the react-dom internals to support web components and adds a new tooling layer over it?
It's not bad tech and web components are built into the platform of the web now so they're not really going anywhere...
greenyouse commented on A Tradecraft Primer (2009) cia.gov/resources/csi/boo... · Posted by u/greenyouse
Shows some helpful ways to reason about open problems with incomplete information.
Ah, this missed the mark since the domain is all political/state related. I saw the mental liquidity story from today and it reminded me of an old book they published about how to think. That one has better theory based talk. This article has too many references to conflicts so it's kind of distracting from the interesting stuff.
psychology of intelligence analysis book link: https://www.cia.gov/static/9a5f1162fd0932c29bfed1c030edf4ae/...
previous discussion: https://news.ycombinator.com/item?id=14852250
Wallaby.js is so nice for instant as you type evaluation of unit tests. Its magical and improves my productivity immensely.
Vitamin R is a great hack for the ADHD brain.
Wallaby.js is a no-brainer tool for writing frontend unit tests. I see a lot of people at work struggle with unit testing. For the productivity boost it gives, it's easily worth the cost.
greenyouse commented on A Tradecraft Primer (2009) cia.gov/resources/csi/boo... · Posted by u/greenyouse
Shows some helpful ways to reason about open problems with incomplete information.
His post reminds me of an old idea I had of a language where all you wrote was function signatures and high-level control flow, and maybe some conformance tests around them. The language was designed around filling in the implementations for you. 20 years ago that would have been from a live online database, with implementations vying for popularity on the basis of speed or correctness. Nowadays LLMs would generate most of it on the fly, presumably.
Most ideas are unoriginal, so I wouldn't be surprised if this has been tried already.
I feel like this is a great approach for LLM assisted programming because things like types, function signatures, pre/post conditions, etc. give more clarity and guidance to the LLM. The more constraints that the LLM has to operate under, the less likely it is to get off track and be inconsistent.
I've taken a shot at doing some little projects for fun with this style of programming in TypeScript and it works pretty well. The programs are written in layers with the domain design, types, schema, and function contracts being figured out first (optionally with some LLM help). Then the function implementations can be figured out towards the end.
It might be fun to try Effect-TS for ADTs + contracts + compile time type validation. It seems like that locks down a lot of the details so it might be good for LLMs. It's fun to play around with different techniques and see what works!