Learn more ? I'm actively trying to unlearn a bunch of languages at this point!
ofcourse, when I was a wageslave in the bay area, its nice to know python, java, javascript, scala etc. - got me jobs every 2-3 years & put food on table.
now that i'm in academia, its completely upside down.
literally everybody is way more productive than me in just about any task. The other day I as supposed to program a poisson clock, it took forever. Meanwhile my advisors & classmates with zero industry experience chug thru these tasks effortlessly. Lately I've confirmed its because they know exactly 1 language , but they know it so well & in so much depth, they know exactly where to look, the right mcmc library, the right slice sampler, the right optimizer, that's what matters.
There's no point programming the same bloody front-end & back-end in a dozen different languages just because of industry constraints. That's like eating a spaghetti with a fork, a spoon, with chopsticks, with your fingers...its the same fucking spaghetti. cook something else, not just rotate dish-ware.
It's perfectly possible to know several languages in-depth. It just takes a lot of time and effort. Moreover, it gets easier with time and practice. Knowing N languages makes learning N+1 language just a bit easier. For me the turning point was around N == 10, since when learning a new language - and yes, in-depth, including idioms, stdlib, some external libraries, maybe some framework (if needed), and also some facts about the implementation and its inner workings[1] - takes a week at most, and for simpler cases a weekend is enough.
OTOH, it took around 15 years to get there. I understand that this kind of dedication may not be possible or worth it for everyone.
[1] Because there is very, very little unique features to each language. Unless you go to the fringes, you're bound to see the same concepts applied again and again and again, which gets really disheartening after a while. If you don't believe me, try naming any "new" feature which was added to your favorite (EDIT: I meant mainstream - TIOBE top 10 or 20 - lang here!) language recently - and I'll show you that same feature implemented 10 or 20 years ago in another language(s).
What I do doubt, is that it's possible to know several languages in-depth and at the same time be at least very good in a specific domain (webdev & mobile apps are not domains), have good algo and problem-solving skills, have decent to good soft skills, know at least a little bit of PM and also be a good conversation partner and well informed citizen of the world, while also being a good husband/wife/dad and being reasonably competent at some hobby that is hopefully not related to computers.
Learning and keeping up to date with the N+1th language takes space from learning the many other interesting things this world has to offer.
Define know though. A C++/Java programmer can quickly write some Python code but isn't Pythonic. To me being able to write a program in a language doesn't mean you can write some code in it, you also have to know the paradigm its supposed to be used, as well as the layout styles, build tools, commonly used libraries etc etc. Even learning a new library often takes months alone.
I think this is true for just learning the language alone. But for the type of productivity the grandparent post is talking about the language ecosystem can be a bigger challenge, at least for me.
It wasn't in academia, but I spent a while working on one of the major native front end platforms almost exclusively and had the opportunity to get very familiar with it. And by 'familiar' I don't mean just knowing where to look things up, I mean knowing many of the exact APIs by heart, and having a wide variety of things I could just type in (without much looking things up) even if it involved working with images, network requests, JSON, file IO, string processing, dates/scheduling, collections, serialization, menus, windows, controls, input, drawing, sound, etc.
Another big thing was when there are multiple ways do the same thing, having done it both ways and having direct experience of why one choice will likely be more effective in general or for a particular project. This can apply to choosing libraries/frameworks or app architectural decisions.
I noticed I missed this level of familiarity quite a lot when I switched to a different ecosystem later. Maybe this is worse for native UI development because of the large API surfaces. But I found needing to consult the documentation again to be a lot slower.
Having had that experience has kind of made me wonder about full-stack vs specialization, and optimal-language-for-the job vs standardizing (although of course some languages are totally inappropriate for some jobs). At least in my own experience I found sticking with the same language for a while to have continuing productivity benefits well beyond the 1 week/month period.
> Lately I've confirmed its because they know exactly 1 language , but they know it so well & in so much depth, they know exactly where to look, the right mcmc library, the right slice sampler, the right optimizer, that's what matters.
That sounds like your "issue" isn't knowing too many languages but that you don't know any one language as in depth as they do though?
I don't see why you'd want to unlearn anything.. doesn't that knowledge only help?
I think there are benefits to learning more languages but also support the idea you should have at least one you're super comfortable with.. thats not mutually exclusive!
Not sure know how far you may be into your career but as one who’s had a couple decades, it’s definitely possible to have both. I have been able to learn two very different languages (C and Haskell) to that level of comfort and am feeling nearly there in Rust. At the same time, I feel reasonably comfortable picking up a project in any of about 20 others with frequent reference to standard lib docs.
With only my own experience and that of people I’ve worked with to go by I can’t provide any broader scope, but I feel like it really is the case that a critical mass of familiarity with different languages and ecosystems makes it far easier to pick up and run with others and be more or less unaffected by the differences. It is probably important that the languages in your set be actually different though, rather than superficially different as most historically-popular languages have tended to be.
I agree. If most of your experience is with a popular OO language, consider learning a lisp. Learn an ML. Try elixir/erlang to get a feel for how different programming for the BEAM can be.
I suppose you don't _have_ to use different languages to learn new concepts, but it certainly helps in some cases. For example, learning about currying is going to be much more natural in F# than it would be in C#.
Yea this is 100% nonsense, and is borderline gatekeeping. Well roundedness allows me to identify a particular language/tech stack that is most suitable for a task and then I can just drill down on it and get productive very quickly.
As a developer you are the chef. If all you can make is spaghetti, is it the kitchen's fault? OP makes the point explicit: the language shapes the way you approach problem solving.
When declarative, functional and procedural programming all yield the "same fucking spaghetti", you might just have missed the point.
It just sounds like they know the domain space better then you. You seem to know less about the domain of a poisson clock then them.
Maybe because I'm also unfamiliar with it, I can't judge. But knowing the right set of algorithms to solve domain specific problem sounds language agnostic to me.
That said, I agree that you should also continue to learn about CS, learn more data-structures, more algorithms, explore newer techniques and paradigms. That includes learning new languages, but not only that.
> Lately I've confirmed its because they know exactly 1 language , but they know it so well & in so much depth, they know exactly where to look, the right mcmc library, the right slice sampler, the right optimizer, that's what matters.
It sounds to me like you're working in a highly specialized area that requires deep domain knowledge and rich set of tools to apply that knowledge. Your colleagues have a lot of familiarity with that domain and those tools. Knowing multiple languages isn't your problem, it's just that you haven't spent your entire career working in this particular domain and you're playing catch-up.
I work for an airline. I known about constraints. If I knew only one language, I never would be at the level I am. Here is the tech stack I deal with daily.
VB6
Kix scripts
Powershell
.net 3.5
Winforms
WPF
.net 4+
.net core
.net asp
Java
JavaScript
React
Angular
C++
Golang.
If programming is a job and not your craft, it will be harder for you. You just have to practice more.
That just sounds like some mess that one is forced to deal with, not reasonable software engineering. I mean yes, some jobs will drown one in useless stuff. Doesn't mean that learning the useless stuff is a virtue now.
I'm not familiar with the author, but I didn't take the article strictly from the perspective of the labor market. There are people who program as a hobby, for example. For those who are interested, it can be enlightening to see how different language designs lend themselves to different tasks.
It’s funny you say spaghetti and list two tools that were invented to eat noodles (chopsticks and forks). Even after it’s invention, it took centuries to improve the fork with a third and fourth tine. It seems hasty in an industry so young to say pick one tool and get great at it. We wouldn’t be in the same place as an industry if we didn’t accelerate web development with oo, dynamic languages, various innovative frameworks etc. a poison transform doesn’t change but the http spec and its requirements do (try writing the asynchronous code that http2 requires on the languages and frameworks of a decade.
That's probably because those languages are completely middle-of-the-road, with a load of inconsistent APIs that one has to learn along with the syntax itself, and that don't really expand one's programming ability.
why don't you share the code that they wrote? I'm interested in seeing the code produced by people in academia. Anyway, once you reach enough mastery in your craft using one language or another is just a difference in deciding what level of abstraction you can work at and this is determined by performance requirements.
"The code produced by people in academia" is about as specific a target as asking about the diet of people in Portland. It ranges from a strict regimen of Taco Bell to pesca-pescatarian.
I mean sure, if you have limitless time then feel free to learn a bunch of programming languages as well as everything else you could want to learn. But real humans have opportunity cost. If you are a software engineer, the time you spend on skill development can already cut across many, many dimensions. Additional programming languages is just one, and I'd argue a fairly narrow one after you've touched on a few key language paradigms.
What about:
- Architecture
- Software Delivery
- Networking
- Project management
- Interaction design
- Visual design
- Human factors/Social systems
- Graphics/Art (2D/3D)
- Market validation
- Sales & Marketing
- Business planning and finance
- Application domain knowledge
- Operations and Monitoring
- Data infrastructure
- Analytics
- Machine Learning
- Machine Vision
- Computer Graphics
- Simulation
- Game Engineering + Design
- Information Retrieval + Recommender Systems
- Embedded systems/Control theory
- Optimization
- Scientific Computing
I mean there is basically an endless list of areas you can reach into in the limited time you have time focused on skill development as a software engineer beyond "on the job" training. Building a strong, broad "stack" of skills seems like a good investment. Learning new programming languages is a niche within a niche depending on how expansive a scope you set for yourself as a person creating software for the world to use.
I would argue that for software engineers, the fields you mentioned would be adjacent fields, while other languages would give deeper insight into the tools of the very trade you're in.
In a time of people going for T-shaped careers, another language is deepening the vertical bar, while another field enriches the horizontal bar.
In that sense, learning a new language and learning a new field are complementary, but different in essence.
Learning a new language doesn't necessarily deepen the vertical bar if the language cannot really be used to improve productivity/innovation on top of an engineer's current toolset. Learning TypeScript on top of Javascript can be thought of as vertical, but learning say Lua or C# on top of JS is probably better described as horizontal unless you're already intending to do some really specific desktop application.
I don't think there's a binary state on if an area of study is adjacent or not, but a spectrum that is unique to the individual. Depending on your career goals, learning areas that don't directly contribute to the production or quality of the lines of code you write could be more "core" to your skills and non-adjacent compared to learning an esoteric programming language you may never even use to build something with.
Given the leverage developing software can have, and the ease to which it can be deployed globally, I err on the side of assuming that the breadth of skills that are "core" to a career which includes a focus on writing code to create software to be potentially quite broad.
I think I certainly take a generally unorthodox viewpoint in that I have a hard time swallowing the idea that a single person shouldn't be able to consider the skills to design, build, deploy, operate, and iterate on a single piece of domain-specific software as "core" to the job of being a software developer. 20 years ago, it was generally normal thing to do that, with a huge number of software tools (often shareware) developed by a single individual or 2-3 person teams. Today, its much rarer, perhaps except in a few domains like indie game development or open source infrastructure products/frameworks. Projects may start that way but it's generally assumed that when it becomes time to get serious, you need to staff up and delegate to specialized workers.
Even within the generally accepted scope of the domain of software development I find it hard to understand the justification for the separation between "front end" and "back end" engineering -- beyond the fact that the tools today have grown full of incidental complexity, making it hard to get the breadth of knowledge needed to be effective, it seems clear that a person building a single integrated system is going to build something different than a number of people building a system where Conways law informs the architecture due to specialization and communication boundaries.
learning rust might teach a javascript programmer a lot about performance that they can apply to their javascript. learning f# or rust might get a c programmer comfortable with ADTs which one can leverage in C with a little work. i do agree though that taking this too far can just be a waste of time. maybe pick up ONE new language outside of whatever domain you are currently in, see if you learn anything useful.
At this point I have almost 20 languages that I've used for at least two years, which is what I consider an decent bar for "knowing" a language.
The problem I now have is that I don't know if I'll ever be able to master any language anymore. Mmmmaybe C, since I've used that fairly consistently, albeit on-and-off for 25 years.
But whenever I get to an "if" or "for" or function declaration, I often have to look at an example real quick because I have too many fighting memories: is it "if () then {}" or "if then:" and is it "else if" or "elif"? Do I need parens around the clauses? Is it "&&" or "and"?
Mostly I've found that the difference between two languages isn't the difference between two cheeseburgers, but rather the difference between a cheeseburger and lasagna. There's absolutely personal preferences (I still despise Python's whitespace-as-scope, even though I love the language), but they all get your belly full.
> I don't know if I'll ever be able to master any language anymore
Even with just a handful of languages in my toolbox, I feel this way too. A mixture of unease and anxiety.
In addition to syntactic variations, I find that the notion of writing idiomatic code in a given language amounts to more thinking overhead which eats into productivity. I'd need to be programming in the same language over a long period of time for idiomatic code to come more naturally. Can't seem to just instantly switch like some talented folk out there.
I run into the idiomatic, or even "regional dialect", issue all the time. I've had many coworkers look at me like I'm stupid when I ask them how they like to implement a certain, basic algorithm. It's not that I don't know how to get it done, I'm just wondering how they like to structure their code, as I find it more important to match style than impose my own, generally speaking.
If I don't have to match styles, and can just write the code as I feel like it, I can work so much faster.
I don't care so much about writing idiomatic code anymore. For example I tend to write python like javascript. Mostly only use lists and dicts (JSON basically), while ditching the whole OOP/class concepts for the most part. What I prefer is more or less a language-independent style, which makes it easy to port code at least between languages with similar paradigms.
Try clustering similar languages into groups centered around shared features, then try to come up with high-level statements which hold true for all the languages in a group. Then try to derive the individual differences within the group from these statements. Use mnemonic techniques as required and prepare cheatsheets if needed.
One thing to realize, though, is that syntax - outside of a few special cases - is the most trivial part of any language. It's 100% acceptable to forget the syntax of a `for` loop in one language, as long as you still know that, in that language, the `for` loop is actually a for-each construct working on sequences of some types and additionally it's an expression which returns a sequence of results, making it equivalent to `map` higher-order function. Now, I described the `for` loop of (for example) Elixir, CoffeeScript, Racket, Common Lisp (`loop` with `collect`) and F# and Scala (with `yield`). As long as I know that a language I'm using right now belongs to this group, I can plan my implementation around the semantics outlined above. Then, when it comes to writing the code, I can just look up the syntax, or more commonly - just make my editor autocomplete and snippet-insert the relevant bits for me.
So, my advice would be to first learn and understand as many programming language features as possible, focus on their semantics, and then group the languages you know around the features. The syntax is really a trivial matter, and "mastering it" (ie. having the whole grammar constantly in your head) is not actually necessary in my experience.
I agree, I don't really sweat it, and the seasoned engineers I respect totally get it. But mastery can be fun, and while I'm developing a kind of "meta-mastery" (I touched my first Go production codebase two weeks ago, and was able to fix a bug in it without really cracking the books except for Interface{}), I miss plain-old mastery that other fields can achieve.
I'm this way with foreign languages: Spanish and french. I know french very well, and learning/speaking Spanish is significantly harder because I'm always using french words by mistake. sure it'll get better with practice, but interlingual dyslexia is real.
Interesting, I feel like I have the opposite issue. Coming from Portuguese, learning Spanish was a breeze and I can usually surprise French speaking people with “hard” words in my basic French sentences — just because I reached out to a Portuguese word and “frenchyfied” it.
I’m not too familiar with the Southern European languages, but I am quite familiar with the Northern European languages. That is where I find the opposite of your difficulty happen, where all those languages look like a different flavour of German to me, so they were very easy to pick up, because I could just read Swedish slowly without ever looking at a textbook or dictionary, and over time I found myself quickly able to write it.
Differences between people, or differences between cultures perhaps. Having grown up in the Netherlands I did already come across Frisian and Limburgs, which are also slightly different but if you keep reading or listening you just pick it up. So I don’t know, keep practicing I’m sure you’ll get Spanish!
One really striking thing is going between {Go, C++, C#, Java} and getting the sources of documentation confused between each one. Not even the languages themselves, but the ecosystems, can be really confusing.
Know all those except Prolog, plus a couple of Lisps - it just makes it worse ;) I agree that the more disparate the languages, the easier it is. And if I use one language consistently for a year or so, I get pretty keyed into it and only rarely try to figure out why it isn't working because I randomly typed "if not X {}" in Go ;)
This is one reason I love PowerShell's design that everything is case insensitive.
For casual scripting, it's so nice to not have to care if it's length or Length. At least memory can help me if it's len/length but length/Length is no distinction at all.
(Case sensitivity is one of my pet hates, for anti-human UX).
IDEs are useful for this. Let them keep track of minutia like syntax rules and names of common but differently-named methods. I find also find that it only takes me about a day of picking a language back up to remember which way they've gone on most of these things.
This kind of gets at what I think is the big advantage of learning a bunch of languages: it gives you instincts for which things are minutia and which aren't. The things you listed that every language has but does differently, which are annoying to figure out and remember, that's the minutia.
At the end of the day it's more about applying the right patterns. A language is just a hammer. But you won't make good furniture without design skills. So it does not matter that you need to Google up things and forget things.
Lol - I remember years ago bouncing through javascript, python, lisp, prolog and others, all using ";" differently; then coming back around to C, and despite once knowing the spec by heart and having written C parsers, writing some one-line test programs... because I just could not believe that semicolon was a statement terminator - it looked so "this just isn't right". :)
> [syntax]
But when swapping languages, I had more trouble with cognitive interference on higher-level constructs. Syntax can go in cheat sheets[1], and idioms gathered in example files. Badly organized and incomplete documentation (once common before the programming community exploded in size) can be overlaid with tables of contents and notes. Because remembering how to find things in each languages' documentation was for me a major pain. But for designing say large apis, you have to remember things like some type-system path does look pretty... but only until you hit some language-misfeature monster that lives on it. And also not shy from some approach because of a misremembered or misattributed gotcha from another language. Though maybe that's easier now with so much discussion of best practices, and so much code available to read.
> cheeseburger and lasagna [...] they all get your belly full.
Or alternately, that they're all shambling toxic wretchedness, but you choose the one which seems likely to poison the customer the least, cooking it as well as circumstances permit. Cockroach popcorn and fried millipedes can be tasty. And even with swill milk... gypsum plaster is non-toxic... it's the other adulterants, little nutrition, and absence of sanitation that burn you. I do love programming, but I so look forward to less crippling languages.
The best technique I've found for staying sane when working in a large number of languages is to configure your editor to highlight errors based on language. If you use perens where you're not supposed to, your editor should tell you right away. No need to go find an example.
This becomes less useful when it's "which library do I use" or "what is the idiomatic way to do this in X language".
I know a bunch of languages too, or at least I claim that I know, because I've used it for some time in the past. And I do not remember the most of them, in the sense that I cannot right now start writing in those languages. But I can start to write C or rust without need to take a look into a tutorial or something like, because I use them routinely.
After lisp I've lost the idea of syntax as of an inherent part of language. You know, all that stuff, that lisp's s-expressions and their memory representation are mapped into each other seamlessly lead to a conclusion that any of them is not important, there is an abstract idea of a lisp object while conrete representations of lisp objects are just some practical ways to deal with them in different situations.
So the official language syntax is a one of the practical ways to represent ideas using that language. The most of languages do not bother to have a second representation, but it doesn't matter. Syntax doesn't matter. You can learn it on a whim in a half an hour of leizure reading.
I wrote a working compiler (learning type exercise level) effectively in pseudo-code resembling Java once because I didn't know the syntax very well, then commented it all out and translated it to Java line by line. Surprisingly, it had no bugs that I ever knew of. It definitely freed me up to think purely about the logic.
You might just throw down whatever and let the next compile/interpretation cycle let you know if you didn't get the syntax right.
Yes, esp some languages are deceptively similar: if you know C, then PERL, Javascript, and PHP looks very similar, but it is hard to remember the differences.
In case anyone isn't familiar with them, these two books[1][2] from the Pragmatic Programmer are great for doing just this. They offer a guided intro to 7 different languages each, and they're a whole lot of fun.
I loved the first one. It's one of my all-time favorite technical books. I was really disappointed by the second, though. I'd recommend skipping it. The second lacked the cohesion of the first probably owing to the fact that it wasn't written by the same author as the first. And each chapter was written by a different author.
I learned programming from books like The Waite Group's Turbo-C Bible around 1989. In trying to teach my oldest son programming through using modern books, it seemed much more difficult. IDEs and languages change so rapidly that books (and even online tutorials) are dated quickly. Menu options change, links stop working, etc.
It made my son more frustrated when he was first starting.
Could you please elaborate on how it changed your life? I am interested in learning Elixir and wondering if you can give some words of encouragement, assuming it changed your life positively :)
I spent a lot of time learning Haskell early in my career. I doubt I'll ever write an actual program in Haskell. I probably won't write so much as a single line of it that will ever see production. (Thank goodness. Haskell is far from perfect, despite its many zealots.) But learning Haskell has changed the way I write code in any language. It's helped me to write better, more testable, more readable, more maintainable, more bug-free Javascript. I wrote a lot of Clojure for a while a few years ago and being familiar with Haskell dropped the learning curve of Clojure down to almost nothing. I personally adore Lisps more than Haskell, but Haskell unlocked the world of functional programming for me. It also showed me the true power strong typing has at a time when the only strong typing I was aware of was the dismal type system of Java. (Like late 90s Java at that!)
I also really like Haskell but except for one consulting customer I only use Haskell for side projects.
Recently I started a side project with the deep learning part in Python and the rest in Haskell. I ended up just week ago converting the Haskell part to Common Lisp. Much faster dev, but I have been using Common Lisp since 1982.
I couldn't agree more, but if I could make a recommendation. If you already know a mainstream OO language, you won't get much benefit out of learning another in the same arena. Going from Java to C# you will learn less than going from javascript to ocaml or Java to Haskell.
The best thing (for my own learning) I ever decided to do was learn Haskell. I have never been paid to write code in Haskell but it gave me such a confidence with languages that I don't think I've seen any language features in any other language that has ever surprised me or that I felt like I couldn't learn. Haskell and it's language extensions will expose you to many many different ideas. It helped me learn Rust, I feel like I can read ocaml, any other functional language doesn't feel like a stretch to read, etc
So, don't just learn many languages. My advice would be to pick languages across paradigms and learn them. Don't waste your time learning 5 object oriented languages.
Failing to learn how to program in Haskell made me realize that I had absolutely no understanding of what I was really doing when I was coding and sent me down a deep rabbit hole learning all the computer science concepts I hadn’t ever learned as a self taught programmer.
I had the same experience with lisp, and it's one of the reasons I chose to keep programming (and eventually major in CS) during college.
It's crazy how easy it is to learn how to pattern match well enough that you can build really useful stuff while still not really understanding what you're doing. Human brains are amazing.
What would you recommended first? I'm also self-taught, just JavaScript, typescript and react and a tiny bit of shell scripting. Job never asks for anything more, but I want to get better at designing, engineering, and building scaleable webapps. So more towards "full stack" I guess.
Haskell sounds super cool, but it seems like nobody really uses it to build things on the web. They mostly just talk about how it "helped them think".
> Going from Java to C# you will learn less than going from javascript to ocaml or Java to Haskell.
Depends on how you'll use C#. If you'll write Java-style OOP, you'll indeed learn very little. But C# offers much more than Java: generics, FP, LINQ, async-await, dynamic, native interop, unsafe and pointer arithmetic..
So I fully agree here because techniques from one language often lead to much better technique in a language of a different paradigm.
For instance, I now use many of the functional techniques I’ve learned in JavaScript to write less, easier to read code instead of more loc of imperative code. I’ve also worked at a company that had many functional patterns implemented in php, and frankly made the language quite decent.
In terms of the time issue, I spend about 15 minutes a day just before bedtime learning new languages. I probably manage to do this 4 days out of every 7.
> In terms of the time issue, I spend about 15 minutes a day just before bedtime learning new languages. I probably manage to do this 4 days out of every 7.
Do you find this actually works? Personally I've read entire books for a language and then gone to write some code in it and realized I knew almost nothing. The only way I've found to learn a language is by writing it.
The company I worked at was Facebook when it still ran on pure php. Much of the functional
toolkit was written by Evan Priestley, who also built and still works on Phabricator.
My suggestion is Objective-C. It's just so weird to anyone who's never coded in it, that it will force you out of your comfort zone into new ways of thinking. The NS framework is probably the most well designed stdlib of any language ever, and the whole thing is inspired directly from Smalltalk. Protocol Oriented Programming [0] was also a real revelation for me, and I still apply those concepts anywhere I can. It's also a great introduction to lower level concepts like pointers and memory management that is a lot more forgiving than C/C++.
Obj-C will always be a dear example to me, because after people praised it so much on HN in contrast with C++, Java I expected it to be something at least a little bit special. When I actually had the chance to use it, I found a mediocre and pretty error-prone language. And then the cherry on top, Apple unceremoniously flushed it down the drain...
This taught me to take any programming language recommendations from HN with a huge quantity of salt and also mostly ignore Kay-style OO purists.
I'm sad to see that you feel that way about the language; since I had exactly the opposite experience. Objective-C is a beautiful (if syntactically verbose) language, and I prefer it to C++ as an "object-oriented C". I'm actually curious what you tried doing with the language, because
> I found a mediocre and pretty error-prone language.
makes it seem like you didn't get a chance to dive down into the runtime and how the message-passing model works. FYI,
> Apple unceremoniously flushed it down the drain...
this is not true at all. Most of the code that Apple themselves writes is Objective-C.
This is mostly because Swift exists and this is where app development, Objective-C's main niche, is moving towards. Note the verbiage describing "dreaded":
> Most dreaded means that a high percentage of developers who are currently using these technologies express no interest in continuing to do so.
Readit News
ofcourse, when I was a wageslave in the bay area, its nice to know python, java, javascript, scala etc. - got me jobs every 2-3 years & put food on table.
now that i'm in academia, its completely upside down. literally everybody is way more productive than me in just about any task. The other day I as supposed to program a poisson clock, it took forever. Meanwhile my advisors & classmates with zero industry experience chug thru these tasks effortlessly. Lately I've confirmed its because they know exactly 1 language , but they know it so well & in so much depth, they know exactly where to look, the right mcmc library, the right slice sampler, the right optimizer, that's what matters.
There's no point programming the same bloody front-end & back-end in a dozen different languages just because of industry constraints. That's like eating a spaghetti with a fork, a spoon, with chopsticks, with your fingers...its the same fucking spaghetti. cook something else, not just rotate dish-ware.
OTOH, it took around 15 years to get there. I understand that this kind of dedication may not be possible or worth it for everyone.
[1] Because there is very, very little unique features to each language. Unless you go to the fringes, you're bound to see the same concepts applied again and again and again, which gets really disheartening after a while. If you don't believe me, try naming any "new" feature which was added to your favorite (EDIT: I meant mainstream - TIOBE top 10 or 20 - lang here!) language recently - and I'll show you that same feature implemented 10 or 20 years ago in another language(s).
EDIT: more neutral wording.
What I do doubt, is that it's possible to know several languages in-depth and at the same time be at least very good in a specific domain (webdev & mobile apps are not domains), have good algo and problem-solving skills, have decent to good soft skills, know at least a little bit of PM and also be a good conversation partner and well informed citizen of the world, while also being a good husband/wife/dad and being reasonably competent at some hobby that is hopefully not related to computers.
Learning and keeping up to date with the N+1th language takes space from learning the many other interesting things this world has to offer.
It wasn't in academia, but I spent a while working on one of the major native front end platforms almost exclusively and had the opportunity to get very familiar with it. And by 'familiar' I don't mean just knowing where to look things up, I mean knowing many of the exact APIs by heart, and having a wide variety of things I could just type in (without much looking things up) even if it involved working with images, network requests, JSON, file IO, string processing, dates/scheduling, collections, serialization, menus, windows, controls, input, drawing, sound, etc.
Another big thing was when there are multiple ways do the same thing, having done it both ways and having direct experience of why one choice will likely be more effective in general or for a particular project. This can apply to choosing libraries/frameworks or app architectural decisions.
I noticed I missed this level of familiarity quite a lot when I switched to a different ecosystem later. Maybe this is worse for native UI development because of the large API surfaces. But I found needing to consult the documentation again to be a lot slower.
Having had that experience has kind of made me wonder about full-stack vs specialization, and optimal-language-for-the job vs standardizing (although of course some languages are totally inappropriate for some jobs). At least in my own experience I found sticking with the same language for a while to have continuing productivity benefits well beyond the 1 week/month period.
What about Rust's borrow checker? I considered it novel, but I'd love to find out it was stolen from somewhere.
Deleted Comment
That sounds like your "issue" isn't knowing too many languages but that you don't know any one language as in depth as they do though?
I don't see why you'd want to unlearn anything.. doesn't that knowledge only help?
I think there are benefits to learning more languages but also support the idea you should have at least one you're super comfortable with.. thats not mutually exclusive!
With only my own experience and that of people I’ve worked with to go by I can’t provide any broader scope, but I feel like it really is the case that a critical mass of familiarity with different languages and ecosystems makes it far easier to pick up and run with others and be more or less unaffected by the differences. It is probably important that the languages in your set be actually different though, rather than superficially different as most historically-popular languages have tended to be.
I suppose you don't _have_ to use different languages to learn new concepts, but it certainly helps in some cases. For example, learning about currying is going to be much more natural in F# than it would be in C#.
https://gist.github.com/prakhar1989/1b0a2c9849b2e1e912fb
“A wide variety of experiences might lead to well-roundedness, but not to greatness, nor even goodness.”
As a developer you are the chef. If all you can make is spaghetti, is it the kitchen's fault? OP makes the point explicit: the language shapes the way you approach problem solving.
When declarative, functional and procedural programming all yield the "same fucking spaghetti", you might just have missed the point.
Maybe because I'm also unfamiliar with it, I can't judge. But knowing the right set of algorithms to solve domain specific problem sounds language agnostic to me.
That said, I agree that you should also continue to learn about CS, learn more data-structures, more algorithms, explore newer techniques and paradigms. That includes learning new languages, but not only that.
It sounds to me like you're working in a highly specialized area that requires deep domain knowledge and rich set of tools to apply that knowledge. Your colleagues have a lot of familiarity with that domain and those tools. Knowing multiple languages isn't your problem, it's just that you haven't spent your entire career working in this particular domain and you're playing catch-up.
VB6 Kix scripts Powershell .net 3.5 Winforms WPF .net 4+ .net core .net asp Java JavaScript React Angular C++ Golang.
If programming is a job and not your craft, it will be harder for you. You just have to practice more.
That just sounds like some mess that one is forced to deal with, not reasonable software engineering. I mean yes, some jobs will drown one in useless stuff. Doesn't mean that learning the useless stuff is a virtue now.
which language is this? I'm guessing Python.
What about:
- Architecture
- Software Delivery
- Networking
- Project management
- Interaction design
- Visual design
- Human factors/Social systems
- Graphics/Art (2D/3D)
- Market validation
- Sales & Marketing
- Business planning and finance
- Application domain knowledge
- Operations and Monitoring
- Data infrastructure
- Analytics
- Machine Learning
- Machine Vision
- Computer Graphics
- Simulation
- Game Engineering + Design
- Information Retrieval + Recommender Systems
- Embedded systems/Control theory
- Optimization
- Scientific Computing
I mean there is basically an endless list of areas you can reach into in the limited time you have time focused on skill development as a software engineer beyond "on the job" training. Building a strong, broad "stack" of skills seems like a good investment. Learning new programming languages is a niche within a niche depending on how expansive a scope you set for yourself as a person creating software for the world to use.
In a time of people going for T-shaped careers, another language is deepening the vertical bar, while another field enriches the horizontal bar.
In that sense, learning a new language and learning a new field are complementary, but different in essence.
Given the leverage developing software can have, and the ease to which it can be deployed globally, I err on the side of assuming that the breadth of skills that are "core" to a career which includes a focus on writing code to create software to be potentially quite broad.
I think I certainly take a generally unorthodox viewpoint in that I have a hard time swallowing the idea that a single person shouldn't be able to consider the skills to design, build, deploy, operate, and iterate on a single piece of domain-specific software as "core" to the job of being a software developer. 20 years ago, it was generally normal thing to do that, with a huge number of software tools (often shareware) developed by a single individual or 2-3 person teams. Today, its much rarer, perhaps except in a few domains like indie game development or open source infrastructure products/frameworks. Projects may start that way but it's generally assumed that when it becomes time to get serious, you need to staff up and delegate to specialized workers.
Even within the generally accepted scope of the domain of software development I find it hard to understand the justification for the separation between "front end" and "back end" engineering -- beyond the fact that the tools today have grown full of incidental complexity, making it hard to get the breadth of knowledge needed to be effective, it seems clear that a person building a single integrated system is going to build something different than a number of people building a system where Conways law informs the architecture due to specialization and communication boundaries.
The problem I now have is that I don't know if I'll ever be able to master any language anymore. Mmmmaybe C, since I've used that fairly consistently, albeit on-and-off for 25 years.
But whenever I get to an "if" or "for" or function declaration, I often have to look at an example real quick because I have too many fighting memories: is it "if () then {}" or "if then:" and is it "else if" or "elif"? Do I need parens around the clauses? Is it "&&" or "and"?
Mostly I've found that the difference between two languages isn't the difference between two cheeseburgers, but rather the difference between a cheeseburger and lasagna. There's absolutely personal preferences (I still despise Python's whitespace-as-scope, even though I love the language), but they all get your belly full.
Even with just a handful of languages in my toolbox, I feel this way too. A mixture of unease and anxiety.
In addition to syntactic variations, I find that the notion of writing idiomatic code in a given language amounts to more thinking overhead which eats into productivity. I'd need to be programming in the same language over a long period of time for idiomatic code to come more naturally. Can't seem to just instantly switch like some talented folk out there.
If I don't have to match styles, and can just write the code as I feel like it, I can work so much faster.
One thing to realize, though, is that syntax - outside of a few special cases - is the most trivial part of any language. It's 100% acceptable to forget the syntax of a `for` loop in one language, as long as you still know that, in that language, the `for` loop is actually a for-each construct working on sequences of some types and additionally it's an expression which returns a sequence of results, making it equivalent to `map` higher-order function. Now, I described the `for` loop of (for example) Elixir, CoffeeScript, Racket, Common Lisp (`loop` with `collect`) and F# and Scala (with `yield`). As long as I know that a language I'm using right now belongs to this group, I can plan my implementation around the semantics outlined above. Then, when it comes to writing the code, I can just look up the syntax, or more commonly - just make my editor autocomplete and snippet-insert the relevant bits for me.
So, my advice would be to first learn and understand as many programming language features as possible, focus on their semantics, and then group the languages you know around the features. The syntax is really a trivial matter, and "mastering it" (ie. having the whole grammar constantly in your head) is not actually necessary in my experience.
Differences between people, or differences between cultures perhaps. Having grown up in the Netherlands I did already come across Frisian and Limburgs, which are also slightly different but if you keep reading or listening you just pick it up. So I don’t know, keep practicing I’m sure you’ll get Spanish!
I'm white so I'm sure this was even more confusing for him
C, {all kinds of assembly}, {C++, Java, C#}, {Python, Ruby}, {Haskell, OCaml}, Prolog, {VHDL, Verilog}
For casual scripting, it's so nice to not have to care if it's length or Length. At least memory can help me if it's len/length but length/Length is no distinction at all.
(Case sensitivity is one of my pet hates, for anti-human UX).
This kind of gets at what I think is the big advantage of learning a bunch of languages: it gives you instincts for which things are minutia and which aren't. The things you listed that every language has but does differently, which are annoying to figure out and remember, that's the minutia.
Lol - I remember years ago bouncing through javascript, python, lisp, prolog and others, all using ";" differently; then coming back around to C, and despite once knowing the spec by heart and having written C parsers, writing some one-line test programs... because I just could not believe that semicolon was a statement terminator - it looked so "this just isn't right". :)
> [syntax]
But when swapping languages, I had more trouble with cognitive interference on higher-level constructs. Syntax can go in cheat sheets[1], and idioms gathered in example files. Badly organized and incomplete documentation (once common before the programming community exploded in size) can be overlaid with tables of contents and notes. Because remembering how to find things in each languages' documentation was for me a major pain. But for designing say large apis, you have to remember things like some type-system path does look pretty... but only until you hit some language-misfeature monster that lives on it. And also not shy from some approach because of a misremembered or misattributed gotcha from another language. Though maybe that's easier now with so much discussion of best practices, and so much code available to read.
> cheeseburger and lasagna [...] they all get your belly full.
Or alternately, that they're all shambling toxic wretchedness, but you choose the one which seems likely to poison the customer the least, cooking it as well as circumstances permit. Cockroach popcorn and fried millipedes can be tasty. And even with swill milk... gypsum plaster is non-toxic... it's the other adulterants, little nutrition, and absence of sanitation that burn you. I do love programming, but I so look forward to less crippling languages.
[1] http://rigaux.org/language-study/syntax-across-languages.htm...
This becomes less useful when it's "which library do I use" or "what is the idiomatic way to do this in X language".
After lisp I've lost the idea of syntax as of an inherent part of language. You know, all that stuff, that lisp's s-expressions and their memory representation are mapped into each other seamlessly lead to a conclusion that any of them is not important, there is an abstract idea of a lisp object while conrete representations of lisp objects are just some practical ways to deal with them in different situations.
So the official language syntax is a one of the practical ways to represent ideas using that language. The most of languages do not bother to have a second representation, but it doesn't matter. Syntax doesn't matter. You can learn it on a whim in a half an hour of leizure reading.
You might just throw down whatever and let the next compile/interpretation cycle let you know if you didn't get the syntax right.
Dead Comment
[1] https://pragprog.com/book/btlang/seven-languages-in-seven-we...
[2] https://pragprog.com/book/7lang/seven-more-languages-in-seve...
It made my son more frustrated when he was first starting.
Recently I started a side project with the deep learning part in Python and the rest in Haskell. I ended up just week ago converting the Haskell part to Common Lisp. Much faster dev, but I have been using Common Lisp since 1982.
I think that's the bottom line. The creator of Haskell confirmed and explained: https://youtu.be/iSmkqocn0oQ?t=22
The best thing (for my own learning) I ever decided to do was learn Haskell. I have never been paid to write code in Haskell but it gave me such a confidence with languages that I don't think I've seen any language features in any other language that has ever surprised me or that I felt like I couldn't learn. Haskell and it's language extensions will expose you to many many different ideas. It helped me learn Rust, I feel like I can read ocaml, any other functional language doesn't feel like a stretch to read, etc
So, don't just learn many languages. My advice would be to pick languages across paradigms and learn them. Don't waste your time learning 5 object oriented languages.
It's crazy how easy it is to learn how to pattern match well enough that you can build really useful stuff while still not really understanding what you're doing. Human brains are amazing.
Haskell sounds super cool, but it seems like nobody really uses it to build things on the web. They mostly just talk about how it "helped them think".
Depends on how you'll use C#. If you'll write Java-style OOP, you'll indeed learn very little. But C# offers much more than Java: generics, FP, LINQ, async-await, dynamic, native interop, unsafe and pointer arithmetic..
Metaprogramming / what OOP could have been / interesting error handling: Common Lisp
Static Types/FP: Haskell (or Ocaml)
Logic Programming: Prolog
Untyped FP: Clojure (or Scheme)
Actor Model: Erlang (or Elixir)
CSP: Clojure w/ core.async (or Go)
GUI Development: Lazarus (or Delphi)
For instance, I now use many of the functional techniques I’ve learned in JavaScript to write less, easier to read code instead of more loc of imperative code. I’ve also worked at a company that had many functional patterns implemented in php, and frankly made the language quite decent.
In terms of the time issue, I spend about 15 minutes a day just before bedtime learning new languages. I probably manage to do this 4 days out of every 7.
Do you find this actually works? Personally I've read entire books for a language and then gone to write some code in it and realized I knew almost nothing. The only way I've found to learn a language is by writing it.
Oooh, got any examples?
https://phptherightway.com/pages/Functional-Programming.html
https://github.com/mtdowling/transducers.php
Don't forget putting a function into a function, gives you behaviour polymorphism at runtime, without inheritance or class based dependency injection
[0] https://www.sicpers.info/2015/06/protocol-oriented-programmi...
This taught me to take any programming language recommendations from HN with a huge quantity of salt and also mostly ignore Kay-style OO purists.
> I found a mediocre and pretty error-prone language.
makes it seem like you didn't get a chance to dive down into the runtime and how the message-passing model works. FYI,
> Apple unceremoniously flushed it down the drain...
this is not true at all. Most of the code that Apple themselves writes is Objective-C.
> Most dreaded means that a high percentage of developers who are currently using these technologies express no interest in continuing to do so.