Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trying new programming languages helped me grow as a software engineer

cichocinski.dev

Post reply on HN
Print view View original

161–170 of 192 posts

Re: Trying new programming languages helped me grow as a software engineer

#161

Post by Syzygies »

tester756 wrote: post #15

I do believe that learning many programming languages is overrated Learn concepts, obtain foundational computer science knowledge, write complex projects not just get familiar with somebody's interpretations that they implemented as a language. Languages that I used besides my job language barely gave me anything, in most cases they made me appreciate more for sane environment (package managers, IDEs, debuggers, stro…

My name is Dave, and I'm an addict.

Charlie Watts wasn't just into jazz, he was into all music. George Harrison understood that jazz could deepen him as a musician, but found Indian music.

If one wants to write a language that is truly original, that might actually influence the future, not just smearing around familiar weightings for features found useful "in the trades", then one wants to have some grasp of languages representative of every language in use. Then, only proceed with a compelling vision of what's missing.

For the rest of us, being a language junkie can be a problem. Without being judgmental, it is possible for a person to be too promiscuous. Same with languages. I wish I could just stick to Haskell and get work done.

Re: Trying new programming languages helped me grow as a software engineer

#163

Post by BlargMcLarg »

saltcured wrote: post #159
synthc wrote: post #133

Earlier quoted context omitted.

Yes this is exactly what I meant. After years of coding in Haskell and Clojure, and then going back to Java I have absolutely no problems with int max(int x,int y) { if (x>y) return x; else return y; } I just looks completely fine to me, but colleagues would complain about it in reviews and I just don't understant the problem at all. The variant with the extra result variable looks just wierd to me, and I have seen m…

What do these languages do when you accidentally miss a branch in you decision tree? Is there any lexical or static analysis error, or does it cause a runtime error or implicit null return when you hit the actual missed condition? I think these differences in potential outcomes are what guide many of these cultural rules of thumb in different programming styles. In imperative programming, a bunch of nested conditiona…

And this is likely one of those zombie rules. It's a trivial case and anyone with a semblance of programming knowledge understands what happens. You don't even need the else statement in GP's case. Meanwhile, any non-trivial case is so context-dependent you can't blindly apply rules and claim to have the best result or even just a better result from what people would come up with naturally.

The fact everything is context-dependent is the basis of all these discussions to begin with. We severely lack evidence and most rules are hearsay taken as gospel.

Re: Trying new programming languages helped me grow as a software engineer

#164

Post by fifilura »

chrsig wrote: post #126

Learning different programming languages definitely helped expose me to new ideas, but I think it's a relatively shallow way to grow. There's only a few that I think are really worth learning for the sake of personal growth: - both C and C++ - Some form of lisp. I could see julia taking this spot. - Haskell - SQL There are obviously more that are worth learning for industrial use. Learning the above will give a solid…

I think SQL is both the simplest to learn and most worthwhile in this aspect.

Why? Short answer - Because it doesn't have for loops.

It forces you to think about data in another way. It is like origami for programming. You can't brute force it, you have to fold your way to the result.

Re: Trying new programming languages helped me grow as a software engineer

#165

Post by jstimpfle »

dunefox wrote: post #56
habibur wrote: post #53

Earlier quoted context omitted.

Pointers. Nearer to the core. In assembly it's all pointers, pointers and pointers. C having better support for pointers makes it nearer to how the processor works, compared to other languages.

C is very far removed from the CPUs of the last few decades.

It's not that far from assembly languages, the nearest you can get to CPUs in terms of software.

Re: Trying new programming languages helped me grow as a software engineer

#166

Post by barrkel »

adra wrote: post #102
barrkel wrote: post #31

Earlier quoted context omitted.

Concepts can often be simulated in many languages, but only clumsily, and the lack of ergonomic affordances in syntax, control flow and type systems can lead one to believe that a different paradigm doesn't work very well - it can be hard to see the wood for the trees. It's hard to write a declarative querying library in C. SQL is not an ideal language, but as a way of expressing intent rather than a physical query p…

It's interesting you bring up REPLs. I never in 20 years working have ever worked with one. I switched jobs and a few people are coco in love with them. This probably more than anything else comes down the programmer style. I had to use Jupiter notebook to help my wife learn programming Python and it was horrific. I could never imagine that real work was done in this way, but I know many good programmers that swear b…

Well, there you go. Jupyter isn't very much like binding.pry, because it lacks the debugger-ness.

REPLs without the debugger bit aren't nearly as good. That's why I mentioned debugger for JS and binding.pry (implicitly, for Ruby).

binding.pry pops you into a terminal REPL with the local binding in scope, just like the eval function of your debugger; except you can start writing loops, define new variables, and more rarely, new functions, right there.

When writing code with a test-first model, you set up the data fixture then pop a binding.pry in the implementation, right where you expect to start implementing it, and run the test. You can then implement the logic in the middle of the test execution - in the middle of your debugger session - and because the REPL is so expressive, you can do a lot. You then copy & paste out those lines and save them in the implementation logic, and shuffle the binding.pry on to the next spot.

Or in a hobby project, you can fly by the seat of your pants, and write code live on the server. There's a remote version of Pry if multiple workers sharing a terminal start fighting each other to own keystrokes.

Re: Trying new programming languages helped me grow as a software engineer

#167

Post by lanecwagner »

I love moving domains every so often because changing up tooling and languages is such a great learning experience. Here's a related piece I wrote talking about why I think learners should also be learning multiple programming languages: https://blog.boot.dev/education/learn-multiple-programming-l...

Re: Trying new programming languages helped me grow as a software engineer

#168

Post by raydiatian »

mrkeen wrote: post #75
raydiatian wrote: post #45

Earlier quoted context omitted.

> Patterns won’t do that I’m pretty sure Clean Code by Uncle Bob has a section on why you should use const to achieve immutable variables. In any case, good style guides inevitably are preaching this as well, as are good senior engineers. All in one’s first language (human), without needing to understand lambda calculus, or monads to run a hello world.

> I’m pretty sure Clean Code by Uncle Bob has a section on why you should use const to achieve immutable variables. Doesn't go far enough. Firstly, it's just advice. I might like it, but it doesn't mean I can get my teammates to do it. Secondly, if I want to do it, I have to get it right, any mistakes I make are on me. Thirdly, const is not enough. You'll probably end up with immutable pointers to mutable data, rathe…

> A language which helps you get immutability right is a world of difference. It's like the difference between a memory-safe language vs just using C (and a C textbook which recommends that you write memory-safe code)

I mean I understood how to get immutability right before I ever picked up an FP language, but I can see how this is a flexible point though. The virtues of immutability really don’t take a long time to extol, and they’re a concept you’re introduced to immediately in MyFirstFPLang™.

Re: Trying new programming languages helped me grow as a software engineer

#169

Post by nottorp »

mettamage wrote: post #131
lordnacho wrote: post #78

I think the period where I grew the most as a dev was an interlude when I knew I was changing jobs, including moving countries. From having built trading systems in c++, I ended up building, over about a year or so: - A django (python / js) website. It integrated with both Android (java) and iOS (objective-C) apps that could read QR codes and ask the server stuff. It also made me interact with the app stores for the…

How do you get all these different jobs? I’d just hear: you don’t have enough experience in framework/language X.

Networking networking.

I know people I'd bring in to help no matter what the framework is because i trust them. And some people would do the same with me if they needed help.

Re: Trying new programming languages helped me grow as a software engineer

#170

Post by mattkrause »

mikepurvis wrote: post #140
nuancebydefault wrote: post #138

Earlier quoted context omitted.

I think it is impossible to make a list of programming languages that are worth learning. Just as a comparison, would you also make such a list for normal languages? English, Arabic and Chinese? Choosing a language to learn depends on, among many more aspects: * What style do you prefer. Return codes vs exceptions, small lambdas vs elaborate functions... * What paradigms you find useful (procedural, functional) * how…

But I think the point should be to get at least a taste of either end of every one of those continuums, so that you get a broad overview of what kinds of problems are well suited to different sets of tradeoffs. For another silly example, see the difference between rust’s collect and using generators in Python. Same end result with very different semantics. Without this, there’s a risk that the “learning” is just tunn…

This holds for natural languages too!

I did a linguistics degree as an undergrad, and one of the requirements was coursework/proficiency in two different foreign languages. Unless you planned on actually using both of them, you were strongly encouraged to choose very different languages, rather than (say) Spanish and Italian.

Having learnt a Romance language, I took a year of intensive Japanese (the tones in Chinese were a bridge too far). It was a nightmarish amount of memorization and I juste eked out a passing grade, but the exposure to totally different writing, grammatical, and honorific systems was also really fascinating.

Post reply on HN