6 ms·
I just wanted to share that everything jvns is saying here is true. In 2014, for the Google Summer of Code program, I applied to build a JIT compiler for the M
by brrt 8y ago
I just wanted to share that everything jvns is saying here is true.
In 2014, for the Google Summer of Code program, I applied to build a JIT compiler for the MoarVM virtual machine. (It is actually more correct to speak of my work as a JIT backend than a full-fledged compiler - the 'frontend' of the compiler was already under development when I started). At the time, I knew just short of nothing about compilers, let alone JIT compilation. So what I did instead was learn, and make lots and lots of mistakes.
And it worked. The JIT backend I created has been in production since 2014, with a new backend since 2017, and a small (but thriving) community of contributors. It is far from the worlds most advanced JIT compiler, but it does provide a nice speedup on real-world perl 6 programs. All the while I've continued learning.
So... definitely try ambitious things :-)
- Serow225 8y agoThat's awesome, congrats!
- brrt 8y agoThank you. I should add I have had support of more people than I can name :-)
- criddell 8y agoMy problem sometimes is just getting started. I have a simple little project I'd like to make to manage movie night with my friends. Right now we do it all over email and it's a confusing mess. Since I'm new to the world of web apps (and looking for an excuse to dive in), I needed to learn some background and now I'm firmly gripped by analysis paralysis. I've learned a bit of Go, of Ruby and Rails, Dart, Angular, and some others. I've read through most of the HTTP spec and I have Roy Fielding's paper where he defines REST in my Pocket account. This morning I'm thinking I should check out Azure or maybe Google Cloud. But also I've done work in Java + Tomcat... maybe I should dust of my JDK? I need somebody to say "here are the four things you need to make a one-page app that lets users express some preferences and constraints and a little engine in the background can tally the results".
- sdenton4 8y agoIt's worthwhile to think about what the minimum viable product might be... I had a similar problem with a book club, which we solved with a google drive spreadsheet (collecting ranked votes) and an ipython/ jupyter notebook (performing the run off).
- criddell 8y agoYou know, I never thought about scripting and Google Docs...
- arcbyte 8y agoNot sure exactly all the requirements, but it sounds fairly simple. Use AWS S3 or Azure Blob to store and retrieve a static webpage and json "database" and wrote the whole thing in JavaScript and html
- criddell 8y agoI like working with Python. Do you think Google's Cloud Platform should be considered? I really just need to stop considering...
- IceSentry 8y agoIf you already know java for the backend then just use that. Or if you want to learn something new pick one language. You don't need to learn all of them. For the client side I would recommend vue, but react is also very popular. Once you have chosen the backend/frontend technologies then you can start building. If you don't know anything about rest learn how your apecific framework does it. You don't need to learn rhe whole spec. At least not in the beginning.
- elorant 8y agoRuby on Rails is more than enough for your needs. Pair it with some simple HTML, plain JavaScript (no frameworks whatsover), and a database of your choice and you're good to go. Or you could use plain JSON with no database at all. No cloud either, just host it to a simple shared hosting provider. Don't be lured by the latest and greatest HN koolaid. Stick to the bare minimum. The more complexity you add to a project the harder would be to maintain.
- konamicode 8y agoThis can work well if you are in an environment like the Google Summer of Code program. It's much harder to do this if you don't have a mentor or two who would be able to spot your mistakes and guide you in the right direction. For many engineers out there they would not have the same set up. Someday I would love to help out somebody with something ambitious but I feel like I need to learn a ton before I am in that position.
- deleted 8y ago[deleted]
- brrt 8y agoIndeed, I owe a debt of gratitude to a lot of people.
- afarrell 8y agoI would like to know, when you run into the situation that you don’t know was is going on with what you are building and feel a sense of confusion, do you: 1) Stop and spend time trying to get a clear mental model of what you are confused about 2) Push forward and try to build despite not understanding In the past, when I tried doing super-ambitious things, I used the second strategy. Many sleep-deprived (tip: “sleep is for the weak” is BS) nights in which I accomplished nothing left me with a strong feeling that I should not try to do impossible things. However, since I learned the first strategy and have been applying it successfully to projects at work, I am rethinking this. I have increasingly been feeling like I would be able to be surmount large challenges if I first set myself up for success in terms of resources and people to ask for help. Questions: A) Do you apply a “step back and study” strategy to tackle confusion? Have you found it successful? B) Do you have any more detail you could add on how it works? C) How do you set yourself up for success outside of a work setting? For instance, I would like to write a server-side debugger for nodejs that is independent of google chrome and works toward a pry.rb-like developer experience. However, I haven’t written C since by OS class in uni and I don’t know the internals of node.js. How would I go about building trustfull relationships with people who know the internals of node.js so that I can ask them questions in the style of https://jvns.ca/blog/good-questions/ https://jvns.ca/blog/good-questions/
- reggieband 8y agoIt is interesting because I went through this exact question recently with an intern. My condensed advice is: 1. Are you still making progress? Keep going. Don't give up. 2. Are you spinning your wheels? Take a step back, re-evaluate what you know, investigate things you are not clear on. 3. Still stuck? Ask for help. Don't panic or be ashamed. Show the progress you've made in step 1 and share the things you studied in step 2.
- brrt 8y agoThese are all good questions, and not so easy to answer :-) Any answers I can give are personal, of course, and may well have no relevance to your situation. a): 'Studying' is definitely very important to get an idea of the context of the thing you are trying to solve. (I did a lot of reading both before and during the project). But, it doesn't always relate easily to the problem you have right now. (E.g. I'm using linear scan allocation, and the papers on that method all glossed over the nature of a 'live range', which took me 3 iterations to figure out). And without a practical problem to guide you, it is easy to get lost in literature. b): What I find is that before I try to do something, I typically put together a high-level overview of how I think I can achieve it (what stuff to change where, and what I will need for that, roughly). But I'd classify that more under planning than under studying per se. What I also do is take lots of notes. I have several large org-mode files (big fan) and before that paper notebooks in which I write down thoughts as they come up. I think org-mode is superior because it lets me organize things after the fact. Notes are a crucial bit of making progress for me, because I don't need to revisit the same things over and over. The other thing that I find helps very much (and which I wasn't very good in at first) is to do incremental, small-step improvements. Move a function here, change an struct there, change an interface, move some process earlier or later, split it up. Simple things that you can do and that you know will not go wrong. Many problems can be broken down in that way, and the few that can't can at least be 'isolated' so that you can fix them 'atomically'. I wrote a blog post about this some time ago, if you'll excuse the link: http://brrt-to-the-future.blogspot.com/2016/06/in-praise-of-incremental-change.html http://brrt-to-the-future.blogspot.com/2016/06/in-praise-of-... c): I was lucky to be able to join the perl community as part of a GSoC project, and fortunate that the perl community is altogether friendly and welcoming. And I really can't speak for the node.js people at all. But what I will say that anyone with a genuine interest in contributing (as you seem to have) and a willingness to do the work to learn (and to listen) will find a warm welcome from nearly all open source projects, because all of them are relatively understaffed compared to their ambitions :-) So in your situation, I'd start with checking out the node.js source, start with trying to figure out how a debugger could work (there is lots of prior art here, of course, so you can check out the chromium source as well), and ask your questions basically as the jvns comic demonstrates. I hope that answers some of your questions.
- swsieber 8y agoIndeed. Mostly, it just takes time and getting familiar with whatever idea you're tackling. I love to throw out crazy ideas. Most of them get filtered away, but I've gotten to prototype some initially unapproachable stuff: * Generate a dsl for interacting with web pages in ui tests from the frontend framework templates * Write a test recorder that lets you step through the browser state * Write a Jenkins plugin to track who's probably broken what test * Write a VSCode plugin to add run buttons to CodeceptJS tests * Write a git hook that maintains two way synchronization of a folder between two separate git repositories (by rewriting & copying commits). My co-workers see me do crazy stuff, but in actuality, it's not that hard. I would say that VMs are definitely harder than what I've done, but I think the concept is the same: the unfamiliar seems unapproachable.
- criddell 8y agoI find DSLs and FSMs are the most satisfying things to develop. Getting a DSL right is like a magic turbo button and a FSM with the right states and transitions can help clarify really ugly problems.