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

151–160 of 192 posts

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

#151

Post by nuancebydefault »

chrsig wrote: post #147
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…

> I think it is impossible to make a list of programming languages that are worth learning "Worth learning" is a subjective phrase, so it'll naturally be different for everyone. My list above was to give a list of languages that would cover as much of the spectrum as possible. > would you also make such a list for normal languages? English, Arabic and Chinese? No, for starters because I'm terrible with spoken languag…

> romance language

That's a language any person can learn :p

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

#152

Post by Jtsummers »

sylware wrote: post #128
Jtsummers wrote: post #120

Earlier quoted context omitted.

Are you actually saying all programs should be written in a macro assembly language? Tied to only one hardware platform, with high level concepts completely obfuscated by the need to express them in assembly? So when MS wants to make an ARM version of Windows, rewrite! When Apple switched from 68k to Power to x86/x64 to ARM, rewrite! Port the Linux kernel to a new platform, rewrite! Port the unix utilities to a new p…

That's why I cited risc-v. Standard of interoperabitily at the assembly level. Yes, and porting from 1 assembly to another is easy.

> Yes, and porting from 1 assembly to another is easy.

So I disagree with this because it discounts the actual differences between hardware systems (including RISC-V variations, 32-bit memory addresses versus 64-bit, different sets of instructions depending on the underlying variant). Then again, I've worked with systems that gave you complex number registers which are not terribly common on any other system. Could be translated away (and sometimes was, but usually to a high level language first) but if you stuck to assembly you exploded the instruction count to do so since now you needed complex math routines (among other things) that were baked into the older system.

But let's say it is easy, then you are either wasting a massive amount of time doing something by hand a computer can do for you (only a fool does this for long), or you have a computer do it for you. At which point your ISA I Assembly->ISA II Assembly translator becomes, wait for it, a compiler. And then you have a really shitty language (some old system's ISA) instead of an actually useful high level language.

EDIT: And suppose, somehow, you kill all non-RISC-V ISAs (good luck). How do you handle other hardware like GPUs? Do you really expect a common ISA to form there any time soon?

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

#153

Post by Jtsummers »

ok123456 wrote: post #149
hardware2win wrote: post #80

Earlier quoted context omitted.

It works on Linux just fine

Problem is the mono C# compiler is several years behind Roslyn in terms of features. It's pretty much a non-starter if you don't have nullable types in 2022.

https://dotnet.microsoft.com/en-us/download

Works fine on non-Windows systems (well, Linux and macOS at least) IME and isn't several years behind.

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

#154

Post by summerlight »

I think it's also very important to see (and easy to miss) that a language is just a part of bigger programming systems. Every problem domains with enough complexity will eventually grow into some sort of a domain specific programming system to provide flexibility and simplicity. Composition, abstraction and generalization are all important tools to tackle this problem and programming languages exist exactly for this reason.

Because general purpose language only solves a tip of iceberg, you will find out that your system begins to resemble more and more of a language as your system evolves. (Although it's usually best to avoid this situation IMHO, but if more than thousands of users depend on it then it's inevitable!) At this moment, some knowledge on language design and implementation could be helpful to avoid pitfalls and make the system more consistent and easy to the users even if it doesn't take a form of a textual language with its own unique syntax.

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

#155

Post by mikepurvis »

nuancebydefault wrote: post #150
mikepurvis wrote: post #140

Earlier quoted context omitted.

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…

I understand what you mean and I agree for the most part. Still, there are multiple degrees of freedom for choosing languages, any list is just a proposal.

Right, but the presence of all those degrees means it’s valuable to at least dabble in many different languages, vs asserting that a list of just a few basically has it covered.

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

#156

Post by sylware »

Jtsummers wrote: post #152
sylware wrote: post #128

Earlier quoted context omitted.

That's why I cited risc-v. Standard of interoperabitily at the assembly level. Yes, and porting from 1 assembly to another is easy.

> Yes, and porting from 1 assembly to another is easy. So I disagree with this because it discounts the actual differences between hardware systems (including RISC-V variations, 32-bit memory addresses versus 64-bit, different sets of instructions depending on the underlying variant). Then again, I've worked with systems that gave you complex number registers which are not terribly common on any other system. Could b…

As I said, I do agree to "pay this price", because I am literally fed up to pay the other price of dependency on very few grotesquely and absurdely massive compilers and the never ending planned obsolescence of computer language syntax.

And high level script interpreters (python-like/swift-like/lua-like/javascript-like/etc-like) written themselve in assembly would be around.

In the interim, I would still code plain and simple C (probably "stuck" at c89 with benign bits of c99/c11), but using the most idiotic small and simple compilers out there, and never ever use gcc or clang to compile it.

And with risc-v, even ultra-small risc-v SOCs offer at least a 64bits core, so I would stick to 64bits.

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

#158

Post by synthc »

tomtheelder wrote: post #135
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…

What would you say the value is in learning some sort of lisp? I see the value in all the others, but lisp dialects tend to be pretty vanilla aside from their syntax. I can't think of anything you'd learn from lisp that you wouldn't from Haskell.

Macros

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

#159

Post by saltcured »

synthc wrote: post #133
mrighele wrote: post #125

Earlier quoted context omitted.

In a functional language technically you don’t have multiple returns, because the function is a single expression so in a way you’re right. On the other hand the actual result of the expression is determined on a leaf of the expression so you could consider it a return point To make an example the following expression can be considered to have two returns: max x y = if x > y then x else y The Java equivalent is int m…

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 conditionals can easily have incomplete coverage of possible program states, and it can be easy to overlook problems if you have a mixture of side-effect branches and early returns. I think some people struggle with this more than others, and it can flummox them almost like goto-laden spaghetti code.

Of course, there are other areas where similar errors can occur in different languages, i.e. in exception-handling or pattern-matching constructs. There are many different coding styles which can make these control-flow structures easier or harder to debug. But, I think there can also be a lot of "cargo culting" where zombie rules of thumb continue beyond when they were really particularly helpful.

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

#160

Post by ttfkam »

deltasevennine wrote: post #101
tester756 wrote: post #66

Earlier quoted context omitted.

>Your own examples in your edit literally contradict what you say as you chose langs with extremely divergent concepts. C# and Erlang, Rust and C. You missed haskell and lisp. How so? You can learn and understand concepts implemented in Rust without learning Rust

Concepts aren't just "learned" by reading about it. True learning requires internalization. Internalization requires practice. Practice requires the concepts to be applied. Application requires real world tools. Usage of tools requires one to learn about the tools. If the only tool available is rust, then one must learn rust to truly learn the concepts related to it.

100% agree. And the Rust compiler is a great way to internalize those lessons since it shows what you got wrong, where you missed an ownership assignment, and often telling you how to fix the problem in plain English. It's as close as I've found to an actual teacher while writing code.

When the compiler stops yelling at you all the time, you'll get your feedback that you've actually learned those lessons.

Post reply on HN