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

181–190 of 192 posts

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

#181

Post by jacknews »

MAGZine wrote: post #97
jacknews wrote: post #61

Earlier quoted context omitted.

Of course understanding the requirements is essential, but the post effectively said the most important aspect of SE is to help the client business. Imagine it's civil engineering, and we're talking about building a bridge. To what extend does a bridge engineer need to understand regional trading patterns, and what bridge location and size would give maximum economic benefit? To me that's a separate discipline to bui…

I don't think you're making the point you think you're making. You should absolutely understand what the purpose of the bridge is, what sort of things will be transported across it (trains? pipelines? weights? hazardous materials?), what sort of volume it will handle, what are the goals you're looking to solve with the bridge, what are acceptable and unacceptable tradeoffs? where are OK connection points, and where w…

I don't think you read what I wrote.

Of course engineers need to understand all the requirements for the bridge.

But coming up with those requirements, ie designing the economic/business case, is a separate discipline. As someone said, some of that may also be engineering; economic engineering, traffic engineering, social, political etc, but it is not bridge engineering.

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

#182

Post by mikedelago »

wefarrell wrote: post #55
mikedelago wrote: post #46

It's also really, really fun to use a language that's completely different than what you're used to. I've learned Elixir, Scala, F#, and Common Lisp on the side in the past year or so. I like Elixir and CL to the point where they're typically my go-to for personal projects. I liked Scala and F# a lot but I don't reach for them so often; it'd be nice to work with them. The worst part about learning (and liking!) new l…

Elixir was the most pleasant experience I’ve had learning a new language. I really enjoy the ergonomics of pattern matching and the pipe operator. Really wish I had an opportunity to use it professionally.

I agree, so many of the idioms (tuple returns into pattern matching, comfortable lambdas, DI through behaviours) all just felt like a breath of fresh air.

It feels like the language was designed to be as good as any other language you've learned.

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

#183

Post by mikedelago »

bern4444 wrote: post #174
phillipcarter wrote: post #96

Earlier quoted context omitted.

> IMO, while Go is nice from a minimalism and resource utilization standpoint, it's simply not fun to write after using much more expressive languages. It's definitely a blessing and a curse. What I think I'd say about Go is that it's a simple "day 1" language and a complicated "day 2" language. Speaking strictly from an expressivity and language semantics standpoint, as its runtime and standard toolset are simply gr…

> What I think I'd say about Go is that it's a simple "day 1" language and a complicated "day 2" language. This resonates. I very much dislike Go's error handling model. Its overly simple and leads to exorbitant if err != nil checks all over the place. It clutters the actual business code and remains a clunky, leaky abstraction. I think Go is a language designed for engineers who don't care to learn about more elegan…

The big thing too, with the `if err != nil` pattern is that it's _good_ Go practice to do that, but it doesn't feel good to constantly be spamming a 3 line error check on every single statement.

I really don't like hopping into a codebase and seeing a 27-line function (uncommented, of course) with 21 of the lines being `if err != nil` checks

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

#184

Post by ok123456 »

hardware2win wrote: post #178
ok123456 wrote: post #149

Earlier quoted context omitted.

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.

Dont use Mono Also I think you are giving nullable ref types too much credit

I don't think you're giving them enough credit.

Having the type system be able to tell you that you may have a null reference exception in a complicated code base is magic. I've inherited bad code bases and refactored them to use nullable references and watched lots of bugs fall out.

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

#185

Post by chaorace »

iudqnolq wrote: post #129
synthc wrote: post #52

Different languages also have their own culture and ecosystem, which are also valuable to learn in order to get a different perspective. Some things that are taken as best practices are bad practices in other langauges and vice versa. For example, lots of Java devs are against early and multiple returns to the point of absurdity, while in functional languages this is idiomatic and no problem at all. Using different l…

Rust convinced me that having a section at the top of a function that early returns in error/exceptional situations works very well. I find myself missing this in the one functional language I've tried, Elixir, although I find Elixir worth it for other reasons. I initially fell in love with the Rust convention of simply bubbling up errors throughout a function but I've gradually realized that leads to a poor API. [1]…

Regarding citation #1: I'm a Rust learner myself, so this is something that's rather salient for me. What do you think about the "boxing errors[1]" approach? This strikes me as one possible way you could bubble up dependency errors without being forced to deal with type conversions.

[1]: https://doc.rust-lang.org/rust-by-example/error/multiple_err...

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

#186

Post by hardware2win »

ok123456 wrote: post #184
hardware2win wrote: post #178

Earlier quoted context omitted.

Dont use Mono Also I think you are giving nullable ref types too much credit

I don't think you're giving them enough credit. Having the type system be able to tell you that you may have a null reference exception in a complicated code base is magic. I've inherited bad code bases and refactored them to use nullable references and watched lots of bugs fall out.

I'd rather use Result everywhere

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

#187

Post by iudqnolq »

chaorace wrote: post #185
iudqnolq wrote: post #129

Earlier quoted context omitted.

Rust convinced me that having a section at the top of a function that early returns in error/exceptional situations works very well. I find myself missing this in the one functional language I've tried, Elixir, although I find Elixir worth it for other reasons. I initially fell in love with the Rust convention of simply bubbling up errors throughout a function but I've gradually realized that leads to a poor API. [1]…

Regarding citation #1: I'm a Rust learner myself, so this is something that's rather salient for me. What do you think about the "boxing errors[1]" approach? This strikes me as one possible way you could bubble up dependency errors without being forced to deal with type conversions. [1]: https://doc.rust-lang.org/rust-by-example/error/multiple_err...

When I said

> I now think you should either expose only a string message your user can just show their end user or an error that's much more specific so they can write code that intelligently responds to it.

a boxed trait object is the main way to implement an error that merely conveys a string message.

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

#188

Post by synthc »

Izkata wrote: post #177
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…

Cargo-culting from C where you have explicit malloc() and free(). Best practice was to have only 1 return to ensure free() was always called on everything just before the return, so you wouldn't have a memory leak if one was missing from an early return.

I was wondering where this 1 return practice originated from, but yeah, it makes sense in that context.

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

#189

Post by bern4444 »

mikedelago wrote: post #183
bern4444 wrote: post #174

Earlier quoted context omitted.

> What I think I'd say about Go is that it's a simple "day 1" language and a complicated "day 2" language. This resonates. I very much dislike Go's error handling model. Its overly simple and leads to exorbitant if err != nil checks all over the place. It clutters the actual business code and remains a clunky, leaky abstraction. I think Go is a language designed for engineers who don't care to learn about more elegan…

The big thing too, with the `if err != nil` pattern is that it's _good_ Go practice to do that, but it doesn't feel good to constantly be spamming a 3 line error check on every single statement. I really don't like hopping into a codebase and seeing a 27-line function (uncommented, of course) with 21 of the lines being `if err != nil` checks

Plus go code seems to embrace as short of a name for variables as possible.

Have a parameter for an array of users? Call it ‘u’. Want to have a variable for a config object? Obviously call it ‘c’.

‘Idiomatic’ go code is bad code.

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

#190

Post by chaorace »

iudqnolq wrote: post #187
chaorace wrote: post #185

Earlier quoted context omitted.

Regarding citation #1: I'm a Rust learner myself, so this is something that's rather salient for me. What do you think about the "boxing errors[1]" approach? This strikes me as one possible way you could bubble up dependency errors without being forced to deal with type conversions. [1]: https://doc.rust-lang.org/rust-by-example/error/multiple_err...

When I said > I now think you should either expose only a string message your user can just show their end user or an error that's much more specific so they can write code that intelligently responds to it. a boxed trait object is the main way to implement an error that merely conveys a string message.

I see, thanks for the response! I guess you're looking for something more deterministic so you can more effectively pattern match against the error's type?
Post reply on HN