In tech startup jargon you hear this convention a lot:
It's basically the idea that a product isn't inherently going to succeed but if it's found the right market fit, things will go well. Or that no founder is inherently great, but with the right project, they can really succeed.
So what is your coder/language fit? The language that works for you because of how you are as a person—not necessarily because of its inherent greatness. No language is without flaw, nor is any language totally terrible. It's about the fit with the project, or in the case of this question—the person.
Top comments (49)
Python and Ruby are my two favorites. Honorable mention to Bash because it's fun. :)
I've tried to learn more strict static, compiled languages (and I will keep trying, because I think it's an important skill to have), but I can't be nearly as productive or creative as I can in Python and Ruby. I love that you can just throw some code into a file and run it right away. I love that they're forgiving of little things.
They don't have huge, giant, opaque, intimidating build toolchains, and they've got a robust standard library that cuts down on how frequently you have to install a dependency, which means that when you do install a dependency, it doesn't install the entire whole world of other people's dependencies.
It's funny that they're so different in their philosophies:
And both of those things resonate with me, but in different ways and situations.
If Python had blocks and the focus on method chaining that Ruby does:
I would be very happy.
The only thing that I really feel myself missing is an easy way to deploy my code repeatably to someone else without having them go through a bunch of steps that make no sense because they don't do Python.
But no matter how often I go off to learn another language, I always find myself coming back to Python and Ruby. They're really the only languages that I've ever written something and then sat back and smiled because the code was so slick and pretty.
So anyways... I ❤️ Python and Ruby.
Some compiled languages can do that, for example Go and Nim.
This is a great example of where I think we deviate in terms of personality - the fact that the language forgives something that could be an error (or might become a problem at a later time) is what drives me crazy.
I enjoy languages such as TypeScript, C#, Go and Nim because they knock you over the head when you're doing something that might not be safe.
What's annoying and restrictive to you, to me is a helpful, guiding language that teaches and drives me towards correctness.
I also love the fact that strict languages, in addition to the syntax and idioms, don't have a bunch of rules and what-ifs I have to memorize - when types can be automatically cast, all the rules about casting, and so on. I like the fact that a string is a string, a number is a number, and you can't write code that implicitly converts things without any visible artifacts of my decision-making.
Do you have a great memory?
I have no capacity for rote memorization, and I've always suspected that's one of the main characteristics that separate your kind from my kind.
I simply can't trust myself to remember on monday what I wrote on friday, and so, for me, it's crucial that everything is formally defined and decisions written down; not as a matter of discipline, but simply by letting the language guide me to it.
For me, it's almost the reverse - I can't be nearly as productive in languages like Python and Ruby.
I couldn't agree more with you. If you check my reply to the same article, I program in Ada and in Ada you suppose that the programmer is just a fallible human being, so the compiler must protect the programmer from self.
I often say that programming in Ada is like doing pair programming, with the compiler playing the role of your partner.
I think you would love F# (or Haskell or any other functional programming language) for the strong type system the languages are built around. If you design your types correctly, a lot of errors will be caught at compile time. fsharpforfunandprofit.com has some really cool articles and uses of F#, but he does NOT know how to write for beginners. I had to learn functional programming by other means before his stuff clicked with me, but once it did I learned some mind-blowing things.
I'm actually not fond of purely functional programming languages. While they're great in theory, I find that the barrier of entry is too high for most people, and code in functional languages tends to be more nested and harder to understand.
It's not a skill that most people acquire easily - and while you could say that it's worth the investment (and you'd probably be right) there is a shortage of talented programmers to begin with, most of them do not know functional programming.
Besides, I don't think there's really a functional programming language that is popular enough that you could describe it as "mainstream"?
I do think that programmers should know some functional programming language concepts and have an understanding of the qualities, but, from my perspective, it's better to choose mainstream languages that also allow functional programming - so we can apply the concepts when it makes sense and adds value, but, the rest of the time, we can leverage the talents of the majority of the talent pool.
You bring up a lot of really good points. The learning curve is pretty insane, from me hearing about functional programming and trying to learn it for the first time until I felt moderately comfortable using it, 2 years had passed. Some of that is the lack of good resources or poor community support, but it is difficult.
It has changed the way I write C# and JS in a positive way. I am about to start contributing to the F# foundation I think. Making it viable...one ticket at a time!
For me that language has always been Python but I'm not sure anymore. I found a good fit in it because of its simplicity, the creators efforts to avoid complexity while creating a language that can be used to solve complicated problems. It's my "go to" language.
The thing is though, I have changed as a human and as a programmer over the years and Python has mostly been the same language (I know, it looks like I'm talking about a romantic relationship gone sour).
I might be an orphan after all.
I feel like there is sometimes a thirst on people's part for change for its own sake, and that's really not great when it comes to computer languages. I think the relative stability of the core syntax of python is not a bad thing. And I'm with you that it's the language I would pick for this discussion as well.
There are aspects of the language that I would definitely change if I could, but those tend to be things that don't really apply to the basic syntax. For example, I think the import/module/package system in python has continued to be confusing from day one, and it's not really much better today than it was in python 2. I think npm is far superior for example compared to the mess we have in python.
Another thing is the infamous global interpreter lock. It's not something that is always going to be a major problem, and there are of course workarounds. And some people will even argue that it has some benefits. However I do consider it to be fundamentally inelegant and kind of weird for a modern programming language.
Finally, some of the standard libraries are better than others. I've definitely encountered some modules where I was wondering if I'd somehow stumbled into Java. It surprised me that more effort had not been put into keeping to the philosophy of python in that regard.
The basic syntax is pretty darn great though. It's simple without being too simple. When it comes to understanding open source code, it's definitely the language where I've found it the least difficult to figure out what people are trying to do.
Yeah, mine is not a criticism to Python per se, I definitely value this thing. I'm just saying that I'm not sure it fits in my brain as easily as it did when I picked it up first.
I partly agree. The package system has been messy but the import and module system is quite alright. BTW I believe Pipenv covers almost every need now
Maybe, but in reality npm suffers by the enourmous amount of small packages with large dependencies trees that transform
node_modulesin a mess. The tool is solid though. "Far superior" to me means that the other tool is barely ok, but I wouldn't call Pipenv barely ok. It works.
It took too long to get there and there are still kinks but I believe we're on the right path. Finally 😅
I disagree. The GIL was a very smart move (Python was developed at the end of the 80s, not exactly a new language), it made the Python ecosystem of libraries and packages develop faster with the added bonus of creating (mostly) thread safe extensions. Many industries ate it up because they could use its simple syntax and extend with C wrappers. I think the GIL is one of the reasons why Python popularity grew over the years and it still relevant after 30 years.
Someone thought about removing it in Python 3 (they were already breaking compatibility) but they didn't because they still didn't think it was worth it: extensions would become harder to write and single threaded Python programs without the GIL would be slower.
Keep in mind that the GIL is a real limit only with CPU bound multithread programs that do calculations in Python. If you are I/O bound you're fine. If you're CPU bound but inside the C API you're fine.
This is one of the reasons the GIL is still, with its drawbacks, a smart move for Python.
ps. there are implementations of Python that do not have the GIL like Jython...
Maybe throw it all out of the window and go weird. Give Haskell or Clojure a shot, wear that hat for a while 🙃
I was at meeting yesterday and a Ruby dev I've known for years suggested I try Clojure as well :D
The universe has spoken!
I find Go to mesh pretty well with my brain. I can't put my finger on it exactly and I haven't gotten around to use it in a large project, but something about Go just clicks with me. Maybe because it's inherently a simple language, there's not much syntax or keywords to learn before you get into all the concepts. Or maybe it's just the fact that I can finally have one variable named properly for each of its use cases.
But what really makes Nim a language that fits me as a coder is its fit as a "hacking" language. My other language love is Clojure, which is a fantastic "software engineering" language. Its great for a large, shared, enterprise grade project. The JVM is rock solid, it has the libraries, and Clojure is fantastic on top of all of that. But if I want to sit down and hack, its just not my first choice. I don't want to be concerned with JVM classpaths, jars, Closure compiler (for JS target), AOT compilation, and all of that. I can open a
.nimfile, throw down some lines, and compile a static binary with no fuss. I've currently got a couple side projects in Nim, and I've only run into issues with the language a couple times.
Honestly modern object oriented PHP. Along long time ago, in a land far away I tried to learn C and had no idea about programming or anything. Nothing clicked and I got very frustrated with it and I decided programming was not for me.
Eventually I found PHP and figured out how to build things and to make web applications. Eventually I learned lower level concepts that C teaches you but learning PHP well first helped usher in a new Era in my life.
After 20 years I have grown to like and sometimes love php, despite really not wanting to!
This is actually something I've thought about a lot recently when I talk to people about different languages, and for me it's Ruby. And as you said not because Ruby isn't without its flaws, or that Ruby is the right fit for every project. But I have found that Ruby fits really well into my personal mental model of programming. Most things in Ruby work how I expect them to work.
It's syntax is simple enough that it can almost look like pseudo code in simple cases and is easy to visualize, for me personally.
Another thing that makes Ruby fit well into my mental model is it's complete lack of typing, and emphasis on 'duck' typing, or having objects of different types that respond to the same methods, and acting on all of them using this shared interface. This fits well with how I imagine objects working in my head.
Ruby is the language I will probably pick if I just want to knock something out quickly and the language doesn't matter. But for new learning focused projects there are a few other languages like Elixir and Rust that I want to get more into!
I really love working in Kotlin, but it seems like the stars never quite align to where I can use it as my primary language at work. It's usually my default for new backend stuff for personal projects now. I think my favorite thing is how modern it feels but you also get the power of the very mature Java ecosystem.
For more ad-hoc stuff I love python, I can cobble together something workable extremely quickly. Also, comprehensions are a wonderful quality of life feature.
I'm in the same boat. I use Kotlin almost exclusively for my side projects, both JVM and JS stuff, but my work projects are mainly still Java. Some projects are slowly adding a bit of Kotlin, but its just hard to start integrating new Kotlin while most of the app is plain Java. It's just so natural, when fixing a bug in Java code, to just keep writing new Java for it.
I think it's just a matter of time. Kotlin has really only been a "very mainstream" language for a year or so now. As more greenfield projects get started with it, it will get more acceptable to migrate existing projects to it as well.
I am agree with you, kotlin is my primary language right now, use in different platform especially i do in android development. Kotlin popular because contribute in Android development and most of android developer migrate java into kotlin language, because the stdlib api make android developer feel comfortable.
When i do in backend there same as java language but with flavor. kotlin have good community not only develop in mobile side but in backend side to. i try ktor.io, spring, micronaut, etc. All is great, especially kotlin make every field as properties, when java doesnt have it automatically.
You can do great things with a Node.js sever and a Python client!
I'm rather new, but may I know how would you go about building a Python client?
It's running as a service on Linux machines.
I actually really enjoy TypeScript
I would say TypeScript as well. I'm fairly new to it, but I've been finding it to be incredibly useful. Self-documenting in a sense, great at helping me catching silly mistakes, and fairly flexible. I've had some friction with the syntax, but I'll chalk it up to unfamiliarity.
Ruby and Ada
Yes, they couldn't be more different: duck typing the former, very strong typing the latter.
Duck typing is not as robust as strong typing, but its flexibility makes it very easy to write some fast-and-dirty code. Typical use case: if I have some text file that I need to process to extract information or if I need to write some networking code for an extemporaneous need.
However, for larger and longer-lived software I prefer the order that Ada can enforce to your code.
Sure, you could do the same with C or Ruby by choosing some coding convention, but having the compiler enforcing it and checking it before you can run the code it is much better. How many times I had to run some code again and again in order to find a bug that would have been spotted at compile time by Ada.
Typescript and Kotlin.
I also have a weird fascination with languages that compile to binaries (like Rust, which I'm learning now. Though it's more like a cosmic battle with the borrow checker)
That, and also, the fact that TypeScript mostly looks at "shapes" of objects, rather than specific classes and interfaces, allowing us to write expressive code. Who cares where an object came from? As long as the object has the right shape, then we're good to go, something that C# lacks (although somewhat available with LINQ). C++ somewhat implements such an idea, but TypeScript is much easier to get started.
This thread was inspired by this interaction
One thing I would like to emphasize in my to-be-created language is that there should, generally speaking, only be one correct way to do something. I think it would make the syntax more uniform and make things less difficult to document, etc.*
So I suppose at some point I'll have to decide between
~and so on. Leaning toward the English-like options.
*One interesting effect this would have is that there would only be one kind of loop. No
while, just some kind of
Yeah, Ruby pretty much goes the other way completely with that. I try not to indulge it too much, but this mentality jives with my personality, probably helps create the right coder language fit.