[HN Gopher] How to Rapidly Improve at Any Programming Language (...
___________________________________________________________________
How to Rapidly Improve at Any Programming Language (2016)
Author : jcubic
Score : 246 points
Date : 2021-09-18 16:25 UTC (6 hours ago)
(HTM) web link (www.cbui.dev)
(TXT) w3m dump (www.cbui.dev)
| _skhan_ wrote:
| I feel like the approach the author laid out near the end is
| passive and would lead to one assuming they have retained some
| knowledge. At the most, it would help someone avoid a similar
| bug/mistake.
|
| A better approach would be to checkout the repo at a commit
| before the fix and try to replicate the solution in a short
| amount of time. You would then build context around what the
| contributor had to figure out and in the worst case you'll have a
| "gold standard" solution to fallback on (assuming the PR was
| successful).
| jcubic wrote:
| I don't think it's good idea, because it will be wasted time.
| You can use your time to contribute to the project after
| reading some closed PR, try to use your knowledge to
| contribute.
|
| For me it's best advice how to start with Open Source, and be
| sure that your PR will be accepted. And as side effect you will
| learn a lot, but this is with any practice like with your idea,
| but you will make project better. Your idea is as worthless as
| doing LettCode or similar.
| christophergs wrote:
| This guy deliberate practices
| rStar wrote:
| i play guitar every morning in my free time. work is for work.
| you're a good enough programmer already. enjoy yourself.
| redeux wrote:
| For some coding is a craft and a job. Just as I would expect a
| professional musician to enjoy growing in their craft and
| learning from their peers, so do people in other areas of life,
| including programming.
| _hilro wrote:
| Do it on company time.
| WJW wrote:
| If you enjoy programming for its own sake, why not improve
| your skills in it both on and off company time?
| schwartzworld wrote:
| Eh, I was a hobbyist before being a pro. I love coding at home,
| I just won't do the same thing I do at work.
| parafactual wrote:
| Not all of us are professional programmers, and especially not
| all of us are _only_ professional programmers.
| autoliteInline wrote:
| For me, programming for free would be painful at a cellular
| level.
|
| Better to learn the piano or how to do portrait art.
| teddyh wrote:
| Programming constantly changes and evolves. Does your employer
| allow you to use your work time to read journals and educate
| yourself on modern developments? If not, you'd better do it in
| your own time if you want to avoid being stuck in the past.
| tayo42 wrote:
| You read journals about programming? Like research papers?
| nkrisc wrote:
| And my work is not programming so coding in the morning for me
| is the same as you playing guitar.
| lordnacho wrote:
| Here's what I do when learning a new language. I've written
| projects in C#, VB6, C++, Python, Rust, Kotlin, Java, Swift,
| Objective-C and a tiny bit of typescript.
|
| - First of all, find out what the typical toolchain is. What IDE
| do people tend to use? What compiler? How is package management
| done? These can be really complicated or super simple to answer.
|
| - Compile a Hello World and see that it runs. If it's reasonably
| specific and supported by a bigcorp, there's often extensive
| downloadable examples. Android and iOS for instance will tell you
| a lot in their tutorials. If there's a book, get the book and see
| how the author presents it, just skim it for key concepts, don't
| get bogged down in the cpp templates SFINAE explanation, it will
| only make sense once you have done some coding.
|
| - Find out how modules work in your language. Every language has
| this, and you need to know it before you can get anywhere, both
| reading and writing.
|
| - Note down keywords from the tutorial code. Recurring things you
| see, look them up. If you're doing Rust maybe you see `match,
| await, clone, some, and unwrap` quite often. If it's iOS maybe
| `controller`, or if it's Android maybe `fragment`. Google all
| these things.
|
| - Look for the libs that you need. If you need a websocket, look
| for that. Major frameworks will tend to have good examples in
| idiomatic style. You can't know all the libs you'll need, so just
| get the ones that are obvious. This will give you a better
| histogram of keywords and soon key concepts.
|
| - Start to code your actual thing you want to make. As you run
| into issues the errors will give you keywords. This will improve
| your knowledge as you google those as well. After a short time
| you will run into larger issues than syntax, and those issues
| will turn out to have been mentioned in the appropriate books.
| dudul wrote:
| "start reading them from the beginning. Just a few a morning for
| warmup while you drink your morning coffee and catch up on
| email."
|
| How do you read PRs while you catch up on emails?
|
| Not to discount the overall advice, but this statement is kind of
| weird.
| darkbatman wrote:
| If someone need my suggestion, here is what you do - try doing
| different sort of questions (multiple topics too) on leetcode
| from different topics may be just 20-30 in language you want to
| learn.
|
| Its different way but you will learn a lot of new libraries, ways
| to mutate objects, lists, all sort of data structures and new
| things really really fast.
| raman162 wrote:
| I've only done a few leet code questions but only in languages
| that I'm comfortable with. Even then, I've had similar
| experiences to the author mentions where I've gotten different
| perspective on how to approach certain problems.
| nostrademons wrote:
| Leetcode is leetcode. It's its own skillset within software
| engineering, one you often need to get a job, but it bears
| pretty little resemblance to any of the skills you need to
| deliver working, functional software that solves a user's
| problem. Practicing it will help you get better at it, which
| may help you land a job where you can practice all the other
| skills, but don't confuse leetcode with proficiency in software
| development.
|
| Among other differences, leetcode teaches you little about
| reading large unfamiliar codebases; debugging; organizing large
| software-engineering projects; working in teams; teasing out
| actual requirements; making incremental progress; real-world
| performance (and the tools you need to identify bottlenecks);
| and most of the libraries and frameworks that are common
| industry knowledge.
| btheshoe wrote:
| I have a feeling that most of these skills don't change all
| that much between languages
| xondono wrote:
| I've tried a lot of those, even contributed to exercism. I
| think it has it's uses, but you can only extract value from
| those exercises once you know _enough_ about a language.
|
| For me those exercises are more about developing muscle memory
| than really learning a language.
|
| OPs idea is good, but I think fails in the same way. I don't
| think you'll get much value out of reading PRs until you have
| certain familiarity. No amount of PRs will teach you what a
| monad is, you need to dive deep and conceptually understand the
| model(at least IMO).
| raman162 wrote:
| I never thought about reviewing existing open source project PRs
| to get better at a language. It seems so obvious considering it's
| similar to how I get ramped up with new projects.
|
| > 2. When you want to level up, start reading the diff, and
| review the code and changes yourself before reading the comments.
|
| > 3. Finally, when you start feeling more confident, start
| leaving those comments on new PRs so that the maintainer doesn't
| have to. You're starting to contribute to open source!
|
| The steps from two to three are pretty dramatic, I personally
| would replace step 3 with tackling an open issue related to code
| you reviewed before. I feel like to give feedback on a PR you
| need to be intimately familiar with the code, something you get
| from writing and/or making changes to it.
| ChrisMarshallNY wrote:
| I just feel that taking on projects I can't [yet] do, is the best
| way for me to improve.
|
| It bucks up my language skills, design skills, debugging skills,
| research skills, framework skills, etc.
|
| https://littlegreenviper.com/miscellany/thats-not-what-ships...
| [deleted]
| enduku wrote:
| In addition to wonderful responses already posted, I'd like to
| add one more: Learn Forth. Learn Lisp. Learn APL. No need to be
| good at these; just enough to learn their programming models.
| Imperative, functional, OOP, or any other, it doesn't matter.
| Learning the programming model in such languages changes the way
| you think. Then start with a language you wish to master. Start
| with a problem in mind. Always have a problem in mind. Try coding
| the thought on paper. Do the same with the target programming
| language. Though it appears as an idealistic procedure, it does
| serve its purpose and instills confidence in the learner like no
| other approach out there.
| rafaelvasco wrote:
| Two things I did and always do: Code things that solve real
| problems you want to solve. The harder the problem, the better
| you'll get in the language and as a programmer in general.
|
| Second, look at existing open source, well written code that,
| again, solves a problem you're interested in. I always emphasize
| this: Things you're passionate about. That way you can master any
| language/framework. By master here, I mean you can code anything
| you want in the technology efficiently. Your final app will be:
| Easy to modify/enhance, easy to understand in terms of code.
| Memory and CPU efficient in terms of runtime.
| voidnullnil wrote:
| This only works for so long until the devs get tired of
| spoonfeeding. More importantly: There shouldn't be subtle nuances
| in something like a web routing library which is _supposed_ to be
| trivial. Just the other day I had the experience of watching a
| grown man give a presentation on his beloved HTTP library,
| explaining fundamentals of asynchronous (TM) programming and
| syntax as if the audience does not understand their own
| programming language in 2021, after seeing the previous 500
| LangX.FrameworkY.HTTPlibs. This shouldn't be a thing. We
| shouldn't be relearning basic shit every day. The problem aside
| from UNIX being a giant pile of garbage, and HTTP being utterly
| pointless (can you even name what problem is being solved when
| you create a new p2p application and make them talk HTTP to each
| other?), is that everyone keeps making their new languages and
| libs to "fix" one tiny issue, and they _always_ lack basic
| knowledge of the past 50 years of PL history, such as Standard ML
| which is better than whatever they just came up with.
| ineedasername wrote:
| _I learned that using the collection functions on strings in
| Clojure is much less performant... But it doesn't have to be my
| PR. It can be anybody's. "_
|
| This reveals a fundamental problem in coding. Best practices for
| performant code shouldn't require ad hoc digging into PR's, and
| as long as it does then we'll have code that is buggy & slow(er
| than necessary).
|
| Learning from others, in any field, will always be a valuable
| source of improvement, but it just doesn't seem that, in software
| dev, it results in laying down solid incremental increases in
| general knowledge that makes its way back into the education of
| future devs or current devs in a language new to them:
|
| If this was structural engineering, you'd have to have taken a
| "materials" course and learn all about different types of
| materials, their properties, load capacities, degradation
| profiles and how to evaluate new ones that come your way under
| the same criteria.
|
| Maybe that's what we need for software development. A structural
| engineer wouldn't use a composite material without knowing its
| performance characteristics. Why should a programmer use
| something like string collection from a language without knowing
| its performance characteristics?
|
| This is on _us_ to demand this, to standardize-- not languages
| themselves-- but the performance profiles & characteristics that
| we must know about in order to make a choice on which tool to
| use. And it shouldn't be that each user has to figure it out on
| their own, dig into PR's or whatever. Again, there will always be
| experiential learning. But _too much_ is experiential right now.
| jcubic wrote:
| I think you read this wrong, the performance doesn't matter. It
| matter that the person learned something new even that he was
| experienced Clojure developer. And he did this by reading
| closed PR.
|
| Success Open Source project are usually created by very smart
| and experienced developers. And big projects have a lot of
| them. Their Code Reviews are much better then anyone your
| closed source team will have, unless you're junior developer in
| team of Senior developers.
|
| Right now I'm thinking that at work we also have git (for
| intranet application) and we have PR, this may be very good
| idea for newcomers to read the PR that was done to understand
| how some features were implemented instead of just diving into
| recent code. This may be best advice I've seen in a while. But
| maybe it's just my own idea that came from this article, that
| you've understand differently.
|
| For me this article is about advice read closed PR you will
| learn a lot, here for Open Source projects, because OSS
| projects on GitHub are biggest projects you can find.
| ineedasername wrote:
| I fully agree that there is significant value in what the
| author writes even if there was more of the sort of
| crystallization of experience into learning. I just thing
| that this method of learning-- which seems not just useful
| but _essential_ in learning how to write performant and less
| buggy code.
|
| As I said, experiential learning and learning from others
| will always be important & valuable, as it is in any field. I
| just think the balance between that and more established best
| practices is weighted too heavily toward the "figure it out
| for yourself finding ad hoc sources" side of things.
| SmellTheGlove wrote:
| > Maybe that's what we need for software development. A
| structural engineer wouldn't use a composite material without
| knowing its performance characteristics. Why should a
| programmer use something like string collection from a language
| without knowing its performance characteristics?
|
| Up front, I don't disagree with you, but let me throw out a
| parallel benefit of your scenario here:
|
| For the most part, in software engineering, a building won't
| collapse if I'm fucking around with a language and doing sub-
| optimal things. If I need optimization, I probably know that
| going in, and would probably take the time to know exactly what
| language/features I should use.
|
| Since most software built today is pretty low
| risk/inconsequential if it fails, we might be moving the state
| of the art forward faster than they might in structural
| engineering simply because we have the freedom to fuck around
| and learn. We can test our materials in production, whereas I
| hope the dude that built my office can't. Like, yeah,
| definitely don't do this with medical devices and airplanes,
| but with CRUD app of the day, I might learn something when
| people decide to use it all of a sudden and it grinds to a
| halt.
|
| I dunno, I should say I'm not a real software engineer in the
| first place and am open to being totally wrong here.
| ineedasername wrote:
| _we might be moving the state of the art forward faster than
| they might in structural engineering simply because we have
| the freedom to fuck around and learn_
|
| Thanks-- I think that's a very concise response & reflection
| on my comment.
|
| I still think we can & should do better, but you're right
| that the lower stakes probably lower the bar on acceptable
| crystallization of experience into best practices. Which is
| problematic because of things like writing a library for your
| own low-stakes project, but the library gets published on
| github and used by someone in a something that isn't low
| stakes.
|
| Maybe part of what we need are defined "stakes" levels and
| corresponding criteria for acceptable practices at each
| stage.
| jamisteven wrote:
| This is precisely why I hate coding, even the articles about
| coding dont make sense to me.
| dennisy wrote:
| I hate giraffes, even the articles about giraffes don't make
| sense to me
| dwmbt wrote:
| It's funny cause I feel the opposite way... I read endless
| amounts of articles that I don't understand, books that go way
| over my head, and even tutorials about things I'm completely
| unfamiliar with and somehow it's entertaining? I've started
| reading The Linux Programming Interface [1], thinking I was
| well versed, and realized how little I knew about my
| environment. It's sort of motivating knowing that I'll always
| be able to dive deeper into the rabbit hole?
|
| One pet peeve I do have is on forums dedicated to help people
| (i.e. Stackoverflow, Arch forum, etc), albeit a small
| percentage of users, seem to think that most basic things are
| "common" knowledge. I understand that we shouldn't handhold and
| leave people to do little to no work but the attitude certain
| responses have rub me the wrong way. People ask questions
| precisely because they are uninformed, why not point them to
| the documentation or at least in the right direction?
|
| [1] https://man7.org/tlpi/
| tienthanh8490 wrote:
| Nice advice. I always hear people suggest building some projects
| to learn the language, but I doubt if it's realistic given other
| constraints in life (I also tried it but the initial excitement
| wears off pretty quickly). In the end, knowledge can come from
| anywhere, we just have to find the right source.
| rob74 wrote:
| In the spirit of this, the Go project has a "common code review
| comments" document
| (https://github.com/golang/go/wiki/CodeReviewComments) - topics
| that come up frequently when reviewing pull requests. Reading
| these can certainly help you get better at writing (idiomatic)
| Go...
| 147 wrote:
| Hey, author here. Surprised to see this on the front page of HN
| since I wrote it 5 years ago.
|
| I've always been fascinated with talent acquisition and skill
| development and would probably different recommendations today
| after having more experience and reading Ultralearning by Scott
| Young.
| basedbertram wrote:
| I remember hearing about his MIT Challenge. This answer on
| Quora from an MIT student highlights some of the issues with
| that challenge https://www.quora.com/How-do-MIT-students-and-
| professors-fee...
|
| In the book does he reflect on any of this, or is it based on
| the MIT challenge at all?
| PartiallyTyped wrote:
| Can be done given that a person has free time, energy, and
| good planning. It doesn't seem feasible for someone who has
| adhd or add.
|
| Anecdotal, but I burned through 1/3 of a two semester
| abstract algebra course in 3ish days of full-time studying,
| and solving all exercises. But in all honesty, the retention
| would have been very low had I not began a linear algebra
| course aimed at graduate pure math students (I am not a math
| student, nor do I have a math degree).
|
| For such a challenge to work with topics like mathematics,
| the content needs to be planned such that every course
| studied builds on top of the previous one, so that the
| student essentially revises and uses the content studied the
| previous week.
| 5faulker wrote:
| Can vouch Scott Young's work. It applies to other subjects non-
| related to programming as well.
| mbrevoort wrote:
| Would love to hear more about that. What was your biggest
| takeaway from Ultralearning?
| jcubic wrote:
| I've published this because I was reading your more recent post
| (GitHub Actions Limitations and Gotchas), found in newsletter
| Programmer Weekly, and found this post that was 10x more
| interesting.
| ryohkyo wrote:
| What would you do differently today than the article?
| 147 wrote:
| I'll probably go back and update the article at some point.
|
| Background on the book Ultralearning. It was written by Scott
| Young who went viral for doing his MIT challenge, to teach
| himself the MIT CS coursework within a small amount of time.
|
| I would expand on the post and focus on the concept of direct
| learning. That is, if you're not really practicing a skill in
| the way you're going to use it in an actual real life
| situation then it's less optimal.
|
| The example he gave in the book and I totally agree with is
| learning a language. People look to apps like Duolingo where
| you're working to recall vocabulary and language in a way
| that's much different than when speaking.
|
| This isn't to take anything away from doing drills wherein
| you focus on a specific subset of a skill, like say, free
| throws in basketball.
|
| The approach I discovered myself and outlined in this post is
| really a drill for doing code reviews in a language you're
| learning and learning idioms and patterns from the community.
| People don't usually look at these aspects because usually
| the advice is to build a project you're passionate about.
|
| I'm bad at finding side projects to build from the ground up
| that I'm "passionate" about. I have a couple of drills to
| work on coding more actively than reviewing code. I take an
| open source library that I'm interested in, take the tests
| and write the code to make the tests pass. Or vice-versa
| where you write the tests for a library. You can make this as
| big or small as you'd like. I'd start with either a function
| or a module that's interesting.
|
| This way you zero in on the coding aspect and you don't worry
| too much about designing the interface since it already has
| tests. It's also much more real world than doing leetcode
| algorithm problems. I was taking this approach when I was
| working on learning how the raft consensus protocol worked.
| jcubic wrote:
| I would not edit the post in any way, leave it as it is.
| But I would love to read a follow up. You can link to that
| new post from that old one.
|
| For me your article is a revelation, didn't realized that I
| can just read old PR to check how to contribute to Open
| Source project. I've never read this advice in any guide
| that show how to contribute to FLOSS and I'm working on
| Open Source for more than 10 years (I'm sometimes read
| about how to get started, when I was starting with OSS,
| there were no guides like this).
|
| I would give this advice to anyone that that want to
| contribute, it's even more important than looking for good-
| first-issue or help-wanted. This should be first thing the
| person do when trying to contribute. Look at old PR.
|
| For me learning new language is side effect. You always
| learn when you're practicing with real project and work
| with more experienced developers. It doesn't matter if you
| work on closed source program in your own team at work or
| on Open Source. But with Open Source there may be more
| people, and big project are usually created by very smart
| people.
| [deleted]
| zarzavat wrote:
| My hack to improve at a new programming language is to read its
| grammar. We instinctively try to learn programming languages the
| same way as we would a natural language, bottom up. But unlike
| natural languages, programming languages have complete grammars
| that can be read in a session. This will prime you with the right
| questions to ask ("WTF is an XYZ?").
|
| Doesn't work for Clojure though :)
| dgb23 wrote:
| For Clojure what helped me was starting to read the source.
| Typically core lib first and then the Java implementation of
| certain constructs.
|
| For me it helps tremendously to see how the sausage is made.
| wrycoder wrote:
| Not really for Python, either.
| d0mine wrote:
| You can definitely read it
| https://docs.python.org/3/reference/grammar.html Though I
| found it useful only to answer narrow specific questions.
| DoreenMichele wrote:
| This is potentially approachable advice for a total noob who
| can't really code: Just read the pull requests and comments in
| open source if you want to start learning.
|
| It's thought provoking and not what I expected. I'm used to
| hearing "If you want to learn, build something." That assumes
| some basic knowledge I simply don't have, so I haven't yet
| managed to pull it off.
| habibur wrote:
| First try it yourself. Then read how others did it.
|
| You will improve rapidly.
| aloisdg wrote:
| My own take, to improve at any programming language, use them to
| build actual small project. The smaller the better. Something
| familiar. Something easy. A library to convert celsius to
| fahrenheit. A webapp to count the day until Halloween. This kind
| of useless-ish stuff.
|
| My last example is to add a state machine with xstate to a
| project fetching some data and formatting a nice output. Do I
| need a state machine? Not really, but it is a good way to learn
| it. btw, the goal of the project is to smooth attribution to
| stack overflow's answer. I just started it, sorry for any bug.
|
| the app: https://stacktribution.vercel.app/
|
| the code: https://github.com/aloisdg/Stacktribution
| 2OEH8eoCRo0 wrote:
| This is basically what they say in SICP. Write programs. That's
| it.
|
| It could be small projects or it could be well-known puzzles
| you already know. Fibonacci- iterative and recursive, fizz
| buzz, sudoku puzzle solver, 8 queens, etc.
|
| Storytime: I would work at site when I worked in defense and do
| 15 hour days. I could sit there and monitor, as the job
| required, but I was also learning Perl for the job. I had no
| Internet so I spent all my time writing tools and
| reimplementing every programming puzzle that I could think of
| in Perl. In very short time I became the go-to "Perl" guy even
| though all the "toys" I made in spare time were "stupid and
| useless" according to coworkers.
| giovannibonetti wrote:
| Instead of using a library for state machines, have you thought
| about trying a language [1] that does that in a type safe way,
| with a compiler that has your back if you forget to deal with a
| state?
|
| [1] https://elm-lang.org
| aloisdg wrote:
| I read a lot of good think about elm. I would personally rely
| on F# and use Fable (with elmish syntax), but most front-end
| team are not ready for this kind of jump. xstate is quite
| easier to insert into a classic React code base. js devs dont
| really like to move outside js. Beside it is hard to onboard
| js devs, let's say that the F# or elm pool are even smaller.
| Zababa wrote:
| > A library to convert celsius to fahrenheit.
|
| I don't think you learn anything with that, unless you mean
| getting confortable with the toolchain.
| aloisdg wrote:
| You can learn a lot from new technology. Do it with state
| machine (xstate in my case). Build a restful API. Do it in
| Nim. Write a gui with Fable.Elmish. Whatever you are learning
| at the moment. If you want to create a raytracer instead of a
| degree converter, go for it :)
| ducharmdev wrote:
| I did something similar to learn Go & gRPC. I had a python
| client for displaying a simple COVID-19 report with the option
| to export as CSV, and had a Go server that sent a request to a
| public API to collect the data for the report. Did I need gRPC
| or the Go server? Not really, but when you're learning
| something new, there's a certain psychological benefit to being
| able to finish something using the technology you're learning.
| That, and you can focus more on the learning part instead of
| getting sidetracked by the other details of a larger project.
| bbertelsen wrote:
| I love this approach. I think looking at the FAQ for a
| programming language's tag is also an amazing way to dive into a
| programming language. Lots of detail, different approaches and
| people discussing best practices on even the simplest of
| programming tasks.
| [deleted]
| wefarrell wrote:
| As a first step I like solving basic problems on Exercism (but
| any other leetcode platform will probably work) and then working
| my way up to the more advanced ones. Then I like to read a thick,
| in-depth guide to the features of that language while continuing
| to work on increasingly harder problems. When I start actually
| using the language for work or other real-world problems I'll
| read through the code of the libraries I'm using.
|
| I've used this approach to come in as a lead developer to
| unfamiliar languages and give meaningful feedback to developers
| who have worked in that language for 10+ years.
| bradneuberg wrote:
| Does anyone know good open source projects that are using modern
| c++ (c++ 11 to 17 techniques) that I can study and possibly
| contribute to to get better at c++?
| ensiferum wrote:
| Well since you asked...a 2D game engine
| https://github.com/ensisoft/gamestudio
| einpoklum wrote:
| But don't only a few languages/frameworks/library collections
| have such a repository of "PR"s, with diffs and review comments
| and everything?
| eyelidlessness wrote:
| The is a great suggestion. I've also learned a lot just from
| reading the already-merged code of projects I'm interested in,
| and stepping through git history to see how it evolved. I even
| frequently do this on my phone when I want time away from the
| desk.
|
| For instance I've been super interested in SolidJS[1] for months.
| I learned from reading the source that a lot of the work is done
| by its underlying dom-expressions[2] compiler. And in reading
| _its_ source, I learned enough about JS AST transformation that,
| when I had a need to do some AST transforms of my own for work, I
| knew enough to confidently timebox a proof of concept to two
| hours (and actually finished the work in that time!). All from
| reading code casually on my phone.
|
| Sure, I front-loaded a lot of that work in my free time. But I
| did it because I was genuinely interested in the project I was
| learning from.
|
| 1: https://www.solidjs.com/ 2: https://github.com/ryansolid/dom-
| expressions
| betwixthewires wrote:
| This is actually a great idea that I hadn't thought of. I've been
| trying to learn a new language for something important and it's
| been a bit much. I'm going to try this.
| e9 wrote:
| When I need to learn new language I try to solve basic coding
| questions with minimum number of characters. You learn a ton
| about language this way pretty quickly.
| greggman3 wrote:
| A lot of people seem to be saying "build a small project" and I'm
| not saying that doesn't work but...., but, something I've
| experienced a lot is that people stick to their old ways, myself
| included.
|
| As a C/C++ programmer I used to hate JavaScript (pre ES5). I
| didn't like it's function based scoping system. I didn't like
| it's prototype based class system. I loathed using it and wrote
| as little as possible, only enough to make a small WebGL demo or
| add a tiny feature to my blog. I was basically trying to use
| JavaScript as C/C++ and hating it.
|
| At some point though I flipped. I actually started using
| JavaScript and playing to its features. I embraced prototypical
| inheritance and all the ways it's more flexible than class based.
| I embraced JavaScript's dynamic typing using, where appropriate,
| the ability to easy wrap APIs, to write more generic and flexible
| code. I also really loved closures and building functions that
| closed over data, something that, at the time, C/C++ didn't have.
|
| I also really enjoyed that, at least in the browser, JavaScript
| is bundled with a lot of CROSS PLATFORM functionality (graphics,
| GPU access, audio, video, networking, UI) that pretty much no
| other language has and of course that I could share anything I
| made with just a link.
|
| Then ES5 to current shipped with better scoping, import,
| map/reduce, promises, async/await
|
| But, I bring this up because I still work with 30-40 people that,
| even in 2021, they work on the browser teams (Chromium, WebKit,
| Firefox) and yet none of them really know JavaScript. They all
| still have the same attitude that I had 15yrs ago. They avoid it
| as much as possible and they treat it like C/C++. Some of them
| have been doing this for 15+ years. They've written 1000s of even
| 10s of 1000s of lines of JavaScript to create tests for the
| features they're implementing but they still having really
| "learned the language".
| wpietri wrote:
| What would you or others recommend to fellow dinosaurs wanting
| to come to grips with modern JS?
|
| The first time I learned it was back in the days when it was
| mainly for mouse rollovers. I want to tackle it as if it were a
| different language these days (which in many ways it is). But
| in years past I've been put off by what seemed like high
| volatility in the current best practices, to the point of
| flavor-of-the-month syndrome. I'm sure there must be a stable
| core that's worth learning and using, but as an outsider I have
| trouble spotting it.
| heavenlyblue wrote:
| Have many front ends are actually written in vanilla JS? I
| thought that in many cases TypeScript is actually used instead.
| chillpenguin wrote:
| Perhaps it's a vocal minority or something that is giving
| this perception. The reality is far more projects are written
| in javascript than TypeSrcipt. Even greenfield projects.
| nicoburns wrote:
| A lot. TypeScript is becoming popular these days, but there
| are still a lot more projects being written in JavaScript
| than TypeScript.
| irrational wrote:
| I have a similar problem, only it is with JavaScript. I started
| using JavaScript in 1997 and have been using it professionally
| since 1999. I am far more comfortable with JS pre-ES5 and tend
| to stick with what I know. Very very slowly I have been coming
| around to more modern JS, but it is very hard. It feels like
| complexity for the sake of complexity versus the (perhaps
| perceived) simplicity I have been accustomed to.
| chillpenguin wrote:
| I agree with you for the most part. They keep adding more and
| more to the language and it is getting more and more bloated.
| It's becoming a chore to keep up with, and the added power
| isn't that necessary. Much of what they add is just making
| the language more terse. I do prefer the terseness once I get
| used to a new feature, but having to relearn javascript all
| the time is pretty annoying.
|
| I really admire small and simple languages that don't change
| much over time. Lisps, SML, etc.
|
| But once again, many of the improvements are quite nice once
| you learn them and get used to them. I wouldn't want to give
| up arrow functions, for example, now that I'm used to them.
| nkozyra wrote:
| I find modern JS much simpler, much more terse. You don't
| have to carry `this` around like a chain, you have tight
| arrow/rocket functions, you avoid leaky scope with var and
| you have mutability control.
|
| It's taken me from "this is a mess" to "ok I can work with
| this."
|
| It sounds to me like you have a familiarity issue. When
| something changes drastically in something you're comfortable
| with it evokes a very strong natural rejection, because it's
| like someone's taking something away from you.
| wizzwizz4 wrote:
| Parts of it are overly verbose, but as a 1997 developer
| you're likely to understand that better. Have a play with a
| Lisp, or Python's functional aspects, or Haskell, then think
| about how you'd put those in JavaScript: chances are, you'll
| end up with a similar solution to what we have today.
| hnrj95 wrote:
| i agree. working on your own when learning a language seems
| like a great way to pick up bad habits, especially if you're
| moving paradigms. eg going from c to go probably isn't that
| dangerous, but moving from java to ocaml is likely quite
| dangerous
| [deleted]
| [deleted]
| rhizome wrote:
| The 30-40 people wouldn't seem to be in the market for building
| a small project, could they be simply happy in their jobs?
| Working with 30-40 C/C++ developers just for browser-oriented
| code you obviously work at a company of a size where people
| have families and stuff, settling into a career mode.
| ecshafer wrote:
| I come from a C++/C/Java background and also always disliked
| Javascript. It still has its warts sure, but the book
| "Javascript the Good Parts" really opened my eyes. I liked
| programming lisp in school quite a bit, and the idea of just
| treat Javascript like a lisp and program it in this specific
| way was really enlightening. Prior to that I was either shoe
| horning it in to a java model, or building on some legacy JS
| that didn't really have a methodology to it.
| travisgriggs wrote:
| This seems great for language/library knowledge. As an
| experienced polyglot, the languages are not where I'm hitting the
| wall these days though. It's the tooling. I can learn new
| language basics faster than I can figure out the
| ecosystem/tooling.
|
| For example, my current conundrum is how to deploy an Elixir
| Phoenix/MQTT app. Writing the app was a fun curve to climb. And I
| could use techniques like described here to learn from others in
| the actual programming. But how to build an executable I can wrap
| in a systemd process running on a different machine? Those are
| actions people do, not expressed so much in code I can look at.
| The few blogs I can find on the subject are mired in deep CI
| toolchains.
|
| I want the blog that discusses the secret sauce to learn to
| acquire the knowledge to work the raft of ever evolving tools we
| have to work with now days. The "materials" (the languages) are
| the easy part now days. It's the massively automated complicated
| machinery we've built around the language of ideas that are my
| personal pain point of entry.
| rubyn00bie wrote:
| I totally agree with you about tooling being the major hurdle,
| and I would like to also note your particular case: deploying
| Elixir/Erlang the first-time is a real motherfucker.
|
| I've deployed (server-side) code in Ruby, Python, PHP, Java,
| .NET, JavaScript, and probably a couple others I forgot
| about... but among all of those Erlang/Elixir was by far the
| most difficult first-time deploy (as an OTP application). It
| has gotten infinitely better, but probably only for those of us
| who have been doing it for a while (6+ years doing Elixir
| professionally for me). For your particular case, let me see if
| I can help you out ('cuz I've definitely been there).
|
| It _now_ mostly boils down to, use mix release:
|
| https://hexdocs.pm/mix/1.12/Mix.Tasks.Release.html#module-te...
|
| with the "secret sauce" being to setup a build server where you
| will build the production release. You'll want the same
| flavor/version of Linux you plan on deploying to, and then copy
| the build artifact (tarball) from your build server to your
| application server (or somewhere else in-between).
|
| One other thing to note, there's a good chance (because
| _everyone_ does this) that you 'll have some broken environment
| variables, or module attributes, because you thought they were
| set at runtime but they are in-fact set at compile time.
|
| Maybe I should write that blog you're looking for...
| jcubic wrote:
| If you find some project that do this right and use tools you
| need, just ask the author to publish his knowledge. It will be
| beneficial to everyone not only you. Most people like to share
| their knowledge, and if you find that other person, just try to
| find another one.
|
| A year ago I've read article about the person that self-
| published a book (printed and ebook), here wrote an article how
| he do that and how he created it in markdown (very well written
| book about TypeScript in Polish), I've asked an year ago (when
| read that article) if can publish the code, he said that he was
| thinking about this. Recently he published how own blog system
| online on GitHub and wrote another article this time with link
| to GitHub. I still waiting for the book code.
| derefr wrote:
| The trick for tooling is usually to find the blog post where
| the newest major version of the tooling was announced. Such a
| blog post will almost always contain a demonstration of what
| idiomatic use of the tooling looks like now. (Because, if it
| didn't, how would anyone get started using it?)
|
| This is also the domain of the more extensive language
| tutorials and/or "Learn X" books. Elixir's website's getting-
| started docs have a very good section on using Mix, for
| example, including `mix release`.
|
| (People tend to forget to re-check an ecosystem's official
| getting-started docs as new tools are introduced into the
| ecosystem. I'd encourage everyone to give your favourite
| language's docs a quick skim every year or two; something new
| might jump out at you!)
| samhwr wrote:
| > But how to build an executable I can wrap in a systemd
| process running on a different machine? Those are actions
| people do, not expressed so much in code I can look at.
|
| The former sounds like a makefile, and the latter sounds like a
| Terraform plan (perhaps combined with something like Kubernetes
| manifests, but that's getting more architecture-specific).
| These days I don't think there's any excuse to use the point-
| and-click approach for setting up infrastructure: it's
| effortful, bug-prone, a security hazard, means everyone has to
| be trained in yet another area, and risks accidentally spending
| far more money than you intend (either by using surprisingly
| expensive services like Spanner, or by inadvertently leaving
| unused infrastructure running).
|
| That said, I do agree that platforms like AWS are unnecessarily
| complex for the vast majority of CRUD web developers. The
| complexity makes sense for the small percentage of people who
| are genuinely setting up a very idiosyncratic and unique
| architecture, but the 98% of CRUD developers really need an
| opinionated platform, perhaps built on top of AWS/GCP/Azure and
| modelled on v1 platforms like Heroku, which would set up the
| infrastructure you need for the average web backend.
| black_13 wrote:
| Being good at anything or anything in demand doesn't translate
| into an income.
| adamnemecek wrote:
| Also reading the source code for the standard library can be
| illuminating.
|
| Note that some languages have pretty subpar standard libraries.
| This might have changed but ~10 years ago the Ruby standard
| library really left some things to be desired. I don't recall the
| details but I wasn't a fan of parts of it.
|
| On the other hand, the Rust standard library is top notch.
| einpoklum wrote:
| > Also reading the source code for the standard library can be
| illuminating.
|
| That's a lot more hit-and-miss. On one end of the spectrum, you
| have Java, where all of the lower-level, nitty-gritty work
| happens within the JVM anyway; and on the other end of the
| spectrum you have C++, where it's "turtles all the way down"
| almost, with lots of repetitiveness, ugly hacks to within the
| library to help the user avoid ugly hacks in their code, a big
| bunch of preprocessor macro definition checks for meeting
| innumerable compatibility requirements for different versions
| of the language standard on different platforms, and so on.
| Yes, you will learn from it, but it will be painful.
___________________________________________________________________
(page generated 2021-09-18 23:00 UTC)