8 ms·
How do you guys think about the opportunity cost of learning dead/dying/new/unpopular languages? Even with newer languages that are gaining popularity and are
by st1x7 6y ago
How do you guys think about the opportunity cost of learning dead/dying/new/unpopular languages? Even with newer languages that are gaining popularity and are likely to be used in the future, I struggle to justify the time investment. I could be wrong but some of my concerns are:
- my time is better spent getting deeper into some more popular language that I already know to some extent
- unused skills deteriorate with time so by adding a new language that you don't need professionally right now, you also need to add the future time and effort of practicing and maintaining that skill
- I could be wrong but I feel that it's a red flag to have too many of the more esoteric languages on your resume.
I do enjoy tinkering with a new language but very often it just feels like a distraction.
Thoughts?
- kaba0 6y agoLearning another language with basically the exact same mental model behind them is not as worthy to spend time on. But learning a language with an entirely different paradigm is really eye opener and will make you a better programmer even if you’ll never write a line of code in it. For example, learning Haskell is a really good way to learn about FP and then you can easily apply it in a not strictly FP language. Prolog is interesting because it is really niche, and “learning it” as in solving a few easy problems will definitely not take much time but will add another way to think about a problem to your toolkit.
- tiew9Vii 6y agoI agree. For me it also came with a huge down side. I spent the last six to seven years using Scala, learning FP concepts, getting familiar with Haskell and it's concepts as well as other functional languages. This is after 7+ years prior doing lots of typical Java, Javascript, PHP which I was quite happy to use. Now I'm in the situation after learning languages which provide far more useful day to day principals, abstractions and safety I struggle or rather get frustrated very quickly when I go back to C style languages i.e Java, Javascript, PHP, Python. My huge problem now is I'm in Sydney, Australia. 4-5 years ago there was a reasonable strong enthusiasm for Scala and functional programmers in general. No, I've been looking to change jobs for the past year and absolutely nothing has popped up. It seems the only roles available are traditional Java with Spring Boot, Javscript, Python and C#. Even with DevOps stuff which I have a bunch of experience for everyone want Ansible when after discovering NixOS/Nix it completely removes the need for Ansible giving declarative deterministic infrastructure/deployments without fragile line upon line of YAML files. Of course all the functional programming work I've learnt is usable and can be applied everyday in other languages. Functional programming isn't new predating all the new shiny popular languages. The problem is having used better languages which treat these principals as first class it isn't the same as trying to hack together something in a language never designed to support it. It seems I've now learnt myself out of a job. If I want a job I need to take a step backwards and use tools that now frustrate me and seem clunky / broken. It's at the point where I'm starting to look at a career change outside of software to start enjoying work again.
- chii 6y ago> 4-5 years ago there was a reasonable strong enthusiasm for Scala and functional programmers in general. No, I've been looking to change jobs for the past year and absolutely nothing has popped up. I think businesses have weighted the power/capability of scala against the relative lack of easily hireable programmer for them. If a business makes themself dependent on one (or a few) key scala programmers, they are more prone to be held hostage (e.g., the power dynamic is more towards the scala programmer). They will have to pay more salary or face the risk of the programmer leaving (which affects business continuity). The scala stack doesn't automatically give a more competitive edge against the competition, however (tho i would say it does, but only if the entire org buys into it). Therefore, it makes more business sense, esp. for a middle manager responsible for hiring, to hire a java programmer (which is basically a dime a dozen at this point). The business will face no risk of the programmer holding the business hostage (because they are easily replaceable). So that's why you see businesses start to not adopt scala.
- ralphc 6y agoWhy did they adopt Scala in the first place? I remember around 2012-2014 it was the hawtness. My guess is that there are languages that give you much of the power of Scala without the complexity - Kotlin, and modern Java, having caught up.
- blandflakes 6y agoModern Java is a language I'd be happy to program in, but doesn't have the language constructs you need if what you're loving FP in Scala (easily chainable monad-things). Kotlin is a nice improvement on modern Java, but feels closer to Java than Scala. Arrow is interesting in this space: https://arrow-kt.io/ https://arrow-kt.io/
- stank345 6y ago> Why did they adopt Scala in the first place? I think in the case of Scala many companies became invested in Spark and Scala came along for the ride. Then as time went on, it turned out you could do advanced FP in Scala, despite its warts, with principled libraries like Cats and the Typelevel stack (see https://typelevel.org/cats/ https://typelevel.org/cats/). Companies could then use Scala as a "better Java" or squint-and-it's-almost-Haskell. Or like you said they could just ditch Scala and use something less powerful but easier to learn and work with.
- KMag 6y agoSee my post in this discussion "You can write <strike>FORTRAN</strike>Prolog in any language". One subset of Prolog is a nice concise declarative notation for rule matching engines. Back when I worked at Google, one of my colleagues (Jeremy) did some Bayesian inference on "1% experiment" results, where he needed to see which observations matched a complex hypothesis and complex rules for the context. So, Jeremy found it easiest to think about the problem in terms of Prolog, and wrote some Python objects whose constructors defined these rules. He also whipped up a memoizing backtracking engine that effectively lazily generated a DFA over experiment observations. He talked and thought in terms of Prolog, because that's the mental tool that he used, but the programming tool was Python. Interesting guy, that Jeremy. He used to do cacao price forecasting for Mars (Mars Bar/M&Ms). He also enjoyed craft beer and carving pumpkins with chainsaws. We also worked in the same (NYC) office with Fergus Henders, who in grad school wrote Mercury, a statically typed dialect of Prolog with an optimizing native code compiler.
- MaxBarraclough 6y agoHaskell is the gold standard for languages that get you to think differently. Forth is another highly unconventional language. Other less exotic languages can still be worth taking a look at to see what they do differently. Ada, for instance, is a plain old imperative/OOP language at heart, but it's different enough in the details that it could be worth looking at if you already know C/C++.
- Jtsummers 6y agoProlog isn't dead, it's just resting. Actually, people find practical uses for it still though it tends to be domain specific. Look at the alternatives. If there's a practical alternative to the language/material that has reasonably widespread use and can be counted on to be present in 5-20 years, go for the alternative. If you have a need for something that's been put through its paces for 40 years and is battle tested with well-supported compilers, consider the "dead language". And you can always leave languages off your resume.
- Blikkentrekker 6y agoThere are a great many languages that are often called “dead” that see rather active use in very specific domains that are called dead for not being general purpose. By the standards of “dead” frequently employed to point out that, say, Hasell is dead, R, Wolfram Language, and Fortran would be considered “dead” as well.
- g0ran 6y agoI have a feeling that Python has stepped over R's territory, right?
- astrange 6y agoThere are living languages based on Prolog syntax, like Mercury. I think they're very useful if you want to build something like an expert system or a game rule engine.
- ZephyrBlu 6y agoI'm curious about this as well, though in a more general sense than just PLs. There are already so many modern/useful things I want to learn that it's hard to justify learning something because it's 'beautiful' or purely intellectually stimulating.
- deleted 6y ago[deleted]
- the_only_law 6y agoPersonally, I probably would have quit entirely had I limited myself to only learning “practical” things.
- ZephyrBlu 6y agoI think I'm the opposite. If I can't see the practical application of something that I'm learning I generally lose motivation very quickly.
- baron_harkonnen 6y ago> hard to justify learning something because it's 'beautiful' or purely intellectually stimulating. You might be surprised to find out that "because it's 'beautiful' or purely intellectually stimulating" is the essence of the 'Hacker' ethos for which this site is named. The Y Combinator itself is something that fits this description quite perfectly. You will never use the y combinator in practice, and it likely won't help you to get a job ever, but it's a beautiful, wonderful thing to learn about and play with. I'll be the first person to criticize PG on a range of topics, but to his credit he has been a great proponent of this ethos and it is no coincidence that this site is named after what would be now considered esoteria by many of the commenters in this thread. It's predictable that the VC ethos of SV would undo that of the Hacker spirit that built it, but it's still sad to see.
- ZephyrBlu 6y ago> You might be surprised to find out that "because it's 'beautiful' or purely intellectually stimulating" is the essence of the 'Hacker' ethos for which this site is named Is it? I thought hacking was more (Or at least also) focused on exploration and making things work [0]. A Y-combinator doesn't really seem to fall into "'beautiful' or purely intellectually stimulating" either [1]. It seems like something that has practical value, as it enables recursion. I also don't think all these things are mutually exclusive. I find consensus algorithms to be quite fascinating and they also seem to have massive practical value, which is why I want understand them more deeply and perhaps implement one. [0] https://en.wikipedia.org/wiki/Hacker_culture https://en.wikipedia.org/wiki/Hacker_culture [1] https://stackoverflow.com/questions/93526/what-is-a-y-combinator https://stackoverflow.com/questions/93526/what-is-a-y-combin...
- triska 6y agoProlog syntax will always be with us, due to its close relation with first-order predicate logic. This syntax will still be there after many now popular languages will long have been forgotten and replaced with other languages. In this respect, learning it is a safe investment. Regarding opportunity cost of time investment, also take into account that, even though learning a lower-level language will first save you time in comparison to Prolog, most if not all tasks you solve with lower-level languages will take longer than solving them with Prolog would take. So, investment in Prolog is like an investment with compound interest: It first takes time, and then you save more and more time, freeing you for other activities.
- flubert 6y agoYou will not make more money because you learn Prolog. I'd approach it like a hobby. Some people like collecting stamps. Some like pondering esoteric programming languages. With things like Prolog, you are closer to Nature, so to speak. Or maybe more mathematical. Learning about a lot of "modern" technology is a lot like memorizing minutia about the semi-arbitrary choices that have been fossilized and accumulating cruft over time. YMMV.
- astrange 6y ago> You will not make more money because you learn Prolog. I think you might if you use it properly. I definitely don't think you'll earn less money - it doesn't take enough time for that.
- AnimalMuppet 6y agoGetting deeper into a language you already know has value. On the other hand, learning a new way of thinking about programming also has value. The ideal might be to be T-shaped: deep in one (or a few) languages, but broad at a shallow level. In this view, you don't have to spend much effort to keep up the skill over time, since you only knew it at a shallow level to begin with. If you're worried about too many esoteric languages on your resume, don't put them on your resume. You are under no obligation to state everything you know on there... Is it a distraction? Maybe. Should you make it a serious project? Perhaps not. But there's nothing wrong with stopping and smelling the roses (and the rare languages) every now and then.
- AnHonestComment 6y agoI learn a lot of languages, but I don’t try to use them at work — just the ideas from them. Example: Knowing Haskell makes it easier to understand Promises in JS/TS. I don’t think learning is a Boolean: I suggest learning a lot of things shallowly to keep practiced at learning, to expose yourself to new concepts, and to have fun playing around. I always think of it as you want a wide base to draw from, but focus on deep knowledge of only a few.
- gota 6y agoSome context on my personal path followed by my considerations: I've been trying to keep a professional career with parallel academic activities. I.e., I did my masters and Doctorate while working. For both my dissertation and thesis I worked in domains and problems that lend themselves to logical formulations - and most of the implementations I did were in Prolog. I also had minor professional experience with Prolog. Focusing here just on the learning-the-language parts and disregarding all other activities: * I _absolutely_ could have used that time to learn a more marketable language or framework. So that was a tradeoff, but - * I most likely would have put only a fraction of those hundreds of hours into "marketable training". I'd have played games for most of them. Or just browsed history channels on youtube, etc. * I did not feel like any practical skills deteriorated at all. In fact - * I feel like learning Prolog in-depth was a valuable "exercise in learning". It might have helped me learn hard stuff for my job by making me a better independent student - I hardly ever interview but I usually let Prolog be at most a footnote in my resume. I don't expect it to be useful in that way (but who knows?) My takeaway would be - for marketable purposes, learning Prolog is only substitute for meta-training. Like, instead of reading another (not your first!) book about design patterns or asynch control or (...) you could learn Prolog. But 85% of the benefit in learning it is the intelectual stimulation.
- bmitc 6y agoI am learning Prolog because I think I have an idea that I believe might actually be easily solved by Prolog instead of hacking it in some other language. I personally believe in learning paradigms of programming as far more important than languages. Prolog presents the very unique logic programming paradigm. Learning new paradigms always feels a bit mind-bending to me. Edit: Actually, my last statement may be only in hindsight given that any experienced programmer will know or know of languages like C and Python that aren't mindbending, so one's viewpoint gets slowly skewed. I think that's why sometimes beginners find things like Prolog or other "strange" languages interesting or even easy, and that's because they present a paradigm that is more like like how humans think about certain tasks. Whether it's Prolog and logic, Elixir/Erlang and messaging, F#/Ocaml/SML with pattern matching, etc., these paradigms are actually quite natural to humans who haven't been tainted with paradigms like that of C, which takes on the paradigm of "let's think like a machine".
- KMag 6y agoIf you're interested in learning many paradigms, the Oz[0] language, Mozart system, and accompanying textbook[1] were designed as a teaching tool to teach most of the major paradigms in a single language. I have not sat down with them, but they have been on a far back burner for years. [0] https://en.wikipedia.org/wiki/Oz_%28programming_language%29 https://en.wikipedia.org/wiki/Oz_%28programming_language%29 [1] https://en.wikipedia.org/wiki/Concepts,_Techniques,_and_Models_of_Computer_Programming https://en.wikipedia.org/wiki/Concepts,_Techniques,_and_Mode...
- bmitc 6y agoDefinitely! It's been on my backburner for years as well. I have the book and started to take the edX course a couple of years ago, but got sidetracked with work. I e-mailed Peter Van Roy back in May, asking if the edX course would be resumed. He stated that the local university course got removed from the engineering curriculum, so that's why the edX course isn't running anymore. Hopefully it comes back. He mentioned that he had recorded some lectures on his YouTube channel. https://www.edx.org/course/paradigms-of-computer-programming-fundamentals https://www.edx.org/course/paradigms-of-computer-programming... https://www.edx.org/course/paradigms-of-computer-programming-abstraction-and https://www.edx.org/course/paradigms-of-computer-programming... https://www.youtube.com/user/PeterVanRoy https://www.youtube.com/user/PeterVanRoy
- wrnr 6y agoMaybe learn something other than a programming language like algebraic geometry, dunno I feel learning only "computable" things is very restrictive because we live in a hyper computable word.
- Rochus 6y agoI spent much more time learning Latin than Lisp and Prolog together. But at least Lisp was somehow useful, if I look at it from today's perspective.
- lliamander 6y agoMy rough criteria: - does the language have some name recognition and positive reputation? - is it still in use (even if only in very niche areas)? - do you have a chance to use it to solve a problem (for work or for fun) to which the language is well suited? If the answer to all three is yes then I would have no hesitation.
- Gene_Parmesan 6y agoTo this, I personally would add as an "or" clause, "Does the language have something fundamental to teach me about programming that I don't already know, and which could be useful when brought to other domains?" This was the reason I learned FP, and also the reason I learned Prolog. I wanted to extend my understanding of programming beyond the C/procedural context. To that end, I found both exercises immensely beneficial even though I've never used a FP lang or Prolog to build an actual project.
- lliamander 6y agoThat's a fair point. I think that is worth highlighting. But I wouldn't make it an "or" clause. For context, I've been able to satisfy all the criteria when learning both Prolog and Erlang. They were both profoundly education experiences, but I think part of the impact of that experience came from using them to solve problems I had, and to which those languages were well suited. There are many languages that will teach me important concepts, but time to devote to learning them is limited. I need a filtering/prioritization process. The trick is to just be aware that these other languages exist, what domains they are good for, and be ready to learn them when I have the right problem.
- smadge 6y agoLearning Prolog is less about learning the particulars of the language than about learning the logic programming paradigm, which is timeless and universal.
- KMag 6y ago"You can write <strike>FORTRAN</strike>Prolog in any language." When I first started at Google, the 1440 Broadway office in Times Square was pretty crowded and they stuck me in where there was a desk, and I ended up sitting next to a guy (let's call him <strike>Mel</strike>Jeremy, because that's his name) who did "1% experiment" analysis. One day, I asked Jeremy what he was working on, and he said he was writing some Prolog to check some hypothesis, and he invited me over to have a look. Really, he was writing a complex rule matching engine (behind the scenes lazily constructing a DFA that operated over experiment observations instead of characters) in Python, to be able to sort sets of observations and contexts into those that fit a hypothesis and those that didn't, as part of some Bayesian inference. But, it was easiest to think of the experiments observations as a facts database and his complex hypotheses and complex contexts as Prolog rules. So, in this case, Prolog was a mental tool, not a programming tool, and he ended up implementing a tiny tiny subset of a Prolog engine that used Python object constructors instead of Prolog syntax.
- echelon 6y agoProlog is declarative instead of imperative. Playing with just a toy example will be eye-opening. You don't need to add the tool to your daily tool chest, but rather expand your horizon.
- curryst 6y agoI think there's value. I learned a tiny bit of prolog while looking at semantic technologies, and I found it really interesting. It's an interesting query language for arbitrary data; an alternative to GraphQL that creates "links" by establishing facts about bits of unstructured data. Is it worth becoming an expert? No. Is it worth spending a day or a week playing with? Most definitely. I have a few niche things I've picked up like that. Learning a little bit of Lisp was similar, although I'd like to learn more of that some day.
- ivanhoe 6y agoBack in the University I've had an assignment in Prolog that I've completely forgot about, so night before the deadline I've sit down around 9-10pm with a huge cup of coffee and by 4am I've learned enough Prolog to finish it (it was a simple path finder for the given graph), I even had some time left for a nap that night. And trust me, I was more than average programmer at that moment - had a lot of enthusiasm and energy back then, but not that much previous experience and I've literally never seen Prolog before. So if you're interested in playing with a quite unique syntax and a mental model of Prolog, just go for it, it will not be a huge investment of your time. You can easily cover the basics in a couple of weekends in your leisure time, instead of Netflix or something.
- avindroth 6y agoNote that when you ask a question like this, you will get a biased selection of answers. People who love niche languages for whatever reason will be more than ready to answer these sorts of questions. Passionate people are great, but you often are in need of some fresh opinions on the other side. Here are some that helped me out immensely (I used to love Haskell but now I love it adequately): https://prog21.dadgum.com/54.html https://prog21.dadgum.com/54.html http://comonad.com/reader/2014/letter-to-a-young-haskell-enthusiast/ http://comonad.com/reader/2014/letter-to-a-young-haskell-ent... New technologies can be a psychological trap.
- lr4444lr 6y agoPersonally speaking, if you're interviewing and you discuss your interest here, it tells me you think a lot about programming and your own thought patterns, with a curiosity about what's beyond what's "dreamt of in your philosophy". As long as you don't expect us to let you rewrite a whole service in it just to make you happy, these kinds of interests generally score you big points with me, conveying that you are a programmer who is eager to learn and try hard things.
- deleted 6y ago[deleted]
- StevePerkins 6y agoIn my experience, having a variety of programming languages on your resume is a double-edged sword. On one hand, it often impresses or makes you more desirable in the eyes of the programmers who do your initial phone screen or whiteboard interview. They like seeing that you're curious and passionate about the field. If you explore languages that they haven't explored yet, then they might be excited about the chance to learn something from you. If you've explored the same trendy language they're already exploring, then their ego might feel validated by seeing others on the same bandwagon. Either way, they're probably frustrated by various examples of not having buy-in from management or architects to do various things they'd like with the existing codebase. So they might see you as the right kind of mindset, someone hungry who will be an ally in pushing for improvements. On the OTHER hand, it will often worry managers and architects. Who have enough stress on their plates dealing with the business stakeholders, and don't want to hire another kid who will throw a temper tantrum when they're not allowed to re-write the entire platform in Rust. So if you DO decide to put various "personal interest" languages on your resume, then make it a point during phone or F2F interviews to highlight your professional maturity. How you understand the need to balance risk. In other words, that you explore languages on your personal time to make you a better developer, not because you really have an expectation of using Brainfuck on your employer's projects. Even with that said, by the time you're 5+ years in the industry, I'd be a little wary of putting too much on your resume that isn't genuine professional experience. I include Lisp and F# on my resume just for the occasional conversation-starter... but if I really had a list of 12 hobby languages, then I would probably try to mention that in the interview, rather than listing them all on my printed resume/CV.
- eyelidlessness 6y agoLearning an esoteric language is as valuable as learning anything else: it’s as challenging and as mind opening as you’re willing to stray. If you’re just exploring another language with the same paradigms you’re used to, you’re just playing in a sandbox. If you’re trying something that feels novel, that has different primitives and constructs and workflows, you might learn new ways to think about using your more comfortable tools. You might even come to have different standards and expectations of how your peers use those tools. I’ve become a much better developer from using somewhat esoteric languages and bringing insights back from that. I learned how to reason about and organize stateful code by doing FP, I learned how to write better interfaces in cross-paradigm languages by just reading a lot about Haskell, and I learned a ton about how to handle branching logic and databases by a foray into Prolog/logic programming. Which by the way isn’t dying, and has been breathing life into more common use languages. That’s the benefit of learning new languages. What they do differently can help guide the mainstream too. Here’s some ideas that have been percolating into ecosystems that didn’t have them: - immutability - static types - composable functions - patten matching - minimal contracts/dependency control inversion - provability/static validation - static runtime optimization of dynamic patterns These are all because people spend time with tech that’s uncommon. Maybe you don’t need it on your resume. But having it in your life experience is going to make you better at your dull day job.
- tannhaeuser 6y agoI get your point, but Prolog is by no means an esoteric language. It (or derivatives such as Datalog) has been the lingua franca for logic and constraint programming since about the mid-1970's, is an ISO-standardized language, and has more implementations than most programming language out there, including shells, JavaScript, BASIC (but probably not as many as historic LISP derivatives lol), has inspired the syntax of Haskell and Erlang, has been used to prototype languages (Erlang, again) due to extremely convenient built-in parser construction capabilities (operator precedence, recursive descend), etc. It's used behind the scenes in many, many apps, including financial optimization/allocation apps, logistic scheduling, or other discrete optimization, config management, combinatorial test case generation, graph/logic DBs including the so-called "semantic web", controlled language applications and other non-ML natural language apps, medical and system diagnostics, medical and legal taxonomies, formal specification/verification, simulation, DSLs, parsers and compilers, type inference and other decision problems in programming languages, layout algorithms and data representation in hypermedia formats, modelling in database theory including variant CAP and OT approaches, games, etc. etc. Sorry for ranting and unfairly picking your post for replying, but I'm a little bit disappointed to see the clueless and roundabout reaction of HNers here who, rather than sticking to the topic of Prolog, see stories like this as an invitation to advertise their fringe language, their not-quite-Prolog language, or their personal pet peeve.
- bird_monster 6y agoIt kinda depends on your goals I think. The T shaped developer skillset is extremely, extremely valuable and will only probably continue. Sure, you could get deeper in a language you already have experience with, but do you think that will better prepare you for future experiences in different languages? Do you want to stick with the tech you're currently using for the rest of your career? If you do, that's great! Don't even worry about the other stuff. But I can say, any time I've spent in my career learning something new has never been wasted time, even if I never used the tool again. Sometimes it's also fun to just see something different. There is value in "Play". You might find you actually really love the new thing, or you might find the new thing just totally reaffirmed your love for your current tools. Either is great! But finding out is probably more valuable. For what it's worth, to your question directly, I found using Prolog to be a pretty profound experience with respect to how I thought about programming. I haven't touched it in ~12 years, but while I was using it I thought it was incredible. One of the "funnest" learning experiences of my career was building sudoku solvers in Prolog.
- zshrdlu 6y agoIf you're optimizing for a career or something, then it's probably prudent to learn the latest and greatest fad. But sometimes you learn for fun, or out of sheer curiosity.
- toast0 6y agoDead/dying/new/unpopular doesn't matter too much. Does it work, and does it apply to problems want (or need) to solve matters much more. If it's dead, it may not get updates, so evaluate it based on what it is now and what you could conceivably add to it. Learning a new language gives you more ways to understand languages you already know, so it has some value even if you don't use it professionally. Unused skills deteriorate, but it's often easier to learn things the second time. I wouldn't put too many languages on a resume. It's always relevant experience, relevant education, relevant knowledge. That means you can omit things if you don't think they're using BrainFuck in production, or you don't think they'd apprechiate the classy name. Maybe make a point of putting your favorite esoteric language just in case, but leave the others out. Being able to pick up languages as needed is also a skill. At my last job, I was hired to do PHP work, but I learned Erlang on the job, as well as Applescript (ugh), got a lot less bad at C, wrote some perl and shell, and even had to write some python from time to time. And or course, I had to debug other people's Java, but didn't write any. I haven't seen a lot of positions where they explicitly hire for that, but it's sometimes what's needed.
- aflag 6y agoIf you care only about job prospects and your career, then I would skip it. However, if you like exploring different ideas and concepts in computer science, it is definitely worth a look.
- patrec 6y ago> How do you guys think about the opportunity cost of learning dead/dying/new/unpopular languages? Interesting question. My advice would be as follows: 1. Learn one practical language really well, well enough that you can both immediately write correct code, with no IDE or documentation, to both algo style problems (hacker rank etc.) and the things that typically come up in your day job or hobby projects (e.g. if you do datascience and use pandas a lot, be sure you can do all common operations from memory; if you do web development, you should be able to churn out a simple REST handler in your framework of choice without thought). You don't need to rote-memorize the language's entire API surface of course, but you should be able to churn out all the frequently needed stuff without thought. 2. Learn one or two other languages less well, but well enough to cover the spectrum of stuff you need to do, efficiently. Relying on the IDE and frequently looking up stuff is likely fine. For example, everyone should know at least one scripting language well enough to automate things by gluing stuff together and if you need to periodically do some simple web UI for a one-off tool, learn enough javascript to do so effectively if not necessarily elegantly. If you want to do systems stuff you'll at least need average C skills and so on and so forth. 3. Only now that you covered your bases to do "realistic" tasks effectively, look at learning some more exotic languages. Otherwise you risk flitting from one thing to the next wasting a lot of time setting up a third rate dev environment for a weird language and hunting for some semi functional library that helps you achieve X and never working on anything meaty enough to really learn much. But once you are productive and cover a range of tasks with mainstream languages, learning either maybe-up-and-coming or already-half-dead-but-interesting language can definitely pay off. Because if you make good choices about which languages to learn you can either broaden your horizons in ways that will pay off even if you don't ever use the language for "real work" or, if, you're lucky, you might have picked an up and coming language and be one of the small pool of people with any amount of experience with it, which will give you a strong competitive advantage. Don't allow your main language skills to grow dull (unless you are switching to a new bread-and-butter language), but there is no problem with learning X and then forgetting a lot of the day-to-day stuff about it, if you got some lasting enlightenment out of it. Also: don't put esoteric languages on your CV if you just have toyed with them, only list things you have used professionally or done some non-trivial hobby project with (unless, maybe, you are looking for a job in "obscure language X"). One of the annoying things with people telling you to learn X because it will help you to grow intellectually is that they often don't really provide concrete examples, so let me provide a few suggestions: 1. Lisp: templating trees by bashing together strings (or CPP style tokens) is braindamaged. Having a compiler at runtime is powerful and useful. A real REPL (not Python, ruby, scala, ...) is powerful and useful. Most DSLs suck and would have been better replaced with a simple sexp format. 2. Smalltalk: You can have a syntax that's as basically simple as lisp but more readable. Everything is live, inspectable and modifiable and you can persist the whole state of the world trivially. This has dangers, too. 3. Python: syntax can, and maybe should, look like pseudo-code. By getting the pragmatics mostly right (e.g. slices, convenient dicts, convenient and immutable strings, mutation returns None, good error messages and repr, basic pseudo-Repl), you can make a very productive language without particular hardcore engineering skills or understanding of CS theory (or history). On the other hand these will also become real limitations at some point. 2. APL/J/K: there are more reductions, inner products and outer products that are useful beyond those involving addition. Array rank and broadcasting. The joys of right associativity. Function power (including infinite) and under. The effects (good and bad) of extreme conciseness. 4. C/C++/Zig/Rust: understanding ownership, stack, heap, pointers. Low-level thinking. 5. Clojure: cons cells as in lisp or scheme suck. So do traditional FP linked lists. Reducers/transducers, schema-language leveraged for property-based tests. One way to think about concurrency with immutability. 6. Erlang: you can have some very nice properties without a horrendously complex implementation, if you make the right engineering trade-offs. E.g. Erlang is pretty much the only thing that gives you preemptive multi-tasking with very high granularity. Pseudo-ropes are an interesting way to do strings. Supervision trees are a powerful concept and way to think about failure and failure handling in concurrent code. The value of deep production introspectability and in particular low-overhead tracing. 7. SQL: Data is king. The power of a truly high level language (even if flawed). Where the abstraction breaks down, badly (e.g. locking, or the DB switching execution plans under you). "Null" done right (true ternary logic, even if confusing is a lot better than the NaN crap in ieee 754 or null in mainstream languages). Why you still want to avoid Nulls most of the time. ORMs are for losers. 8. Ocaml: a proper type system can make writing certain types of code much less error prone and is possible without Haskell-level ivory-tower-wankery. There is value in having a somewhat simple minded but predictable compiler. 9. Zig: you can do almost everything C++ can do at a tiny fraction of the conceptual overhead.
- indymike 6y agoIf all you see with languages is the dollars you can make with an hour of time then learn whatever the next COBOL, C#, Java or Python. If you are focusing on solving problems, then learning another language, especially one that allows you to approach problems differently makes a lot of sense. I haven't used Prolog in anger in about 20 years. But the experience with declarative, logic programming has carried over to nearly everything I've done (you'll see state machines differently and see other logic patterns you can generalize). The resume isn't the be-all end all. Programming is a portfolio profession. You can prove your skill by showing your work - even if it's just some toy you wrote for fun on the weekend.
- sriku 6y ago(speaking for myself) I focus on why a language looks interesting and worthwhile to learn - i.e. what new ideas are in it that are worth stealing. Over and over, I've found that grasping the new ideas in one language almost always permits you to use it in another more "mundane" language. I've for example used C++ functionally, brought Objective-C and Erlang ideas into C++ and so on when I was dominantly programming in C++. During that period, I also made a scheme-dialect interpreter in C because for some of the things we wanted to do C/C++ were too hard boiled. More recently, I've brought CSP into Javascript through sweet.js so I can write go-routines in JS, and along the way also brought Mozart/Oz's "data flow variables" a.k.a. promises as native to JS (again through sweet.js). I've also run a short fun "course" at my company called "no spoon" where the participants build a stack-based language in JS and implement many defining features of many other programming languages .. including all the above. So what I'm trying to say is that you don't need to lament that you can't use a language that you learnt in your day job. New ideas in languages are always worth learning no matter what language you work with on a day-to-day basis.