41–50 of 192 posts
You're never going to build your next major project in one of them (unless you happen to be a COBOL developer or happen to maintain OpenFirmware boot code written in Forth) but seeing different ways of doing things is both interesting and instructive.
I value learning new languages, especially as I have yet to find a very good one. Some are pure and beautiful like Scheme, but if you asked me what single language I would take to a lonely island with me where I was stranded, it would still have to be C. To those here who would like to have some guidance diving into other languages I can recommend these two books: Bruce Tate: Seven Languages in Seven Weeks https://ww…
- Pony’s lifetimes and destructive reading [1]
- Mercury’s overloading of dataflow direction and determinism [2]
were mentioned in [3].
[1]https://tutorial.ponylang.io/reference-capabilities/consume-...
[2]https://www.mercurylang.org/information/doc-latest/mercury_r...
To this date I feel that using Python and SQL are amongst the best decisions in my developer life. Domain specific, without any helper libraries nor macros. Eye opener for using abstractions instead of doing everything the hard way using any low level languages.
Wouldn’t it be more useful to your audience (juniors I assume) to say that “learning patterns in software design helped you grow as an engineer?” I mean you call out things like discovering DDD and I’m sure you also came across Data-oriented design as well, Patterns of enterprise architecture, etc. In my experience knowing those patterns provides far more value in one’s toolkit than “knowing” Kotlin, Ruby, Scala, Gol…
It’s two different things. For instance using more functional language convinced me of the vertus of immutability. Pattern 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'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 languages is that at work, we're pretty firmly in Go. 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.
I’ve worked deeply with about 9 programming languages. Not hobby level, but client work level. They did not really help me to become a better software engineer. What did? Being able to understand the business of the customer and create software that helped them do that easier. That’s why today I tell junior programmers that almost everything we do these days could be accomplished with Bash, text files to hold the dat…
That's because you've been learning languages that are similar. The algol family of languages with OOP. You need to learn languages outside of this family to see the benefit. But the benefit won't be in your ability to do "business". It will be exclusively improvements in programming unrelated to "business programming" >That’s why today I tell junior programmers that almost everything we do these days could be accomp…
Maybe a brief bit of research before throwing stones next time?
I’ve worked deeply with about 9 programming languages. Not hobby level, but client work level. They did not really help me to become a better software engineer. What did? Being able to understand the business of the customer and create software that helped them do that easier. That’s why today I tell junior programmers that almost everything we do these days could be accomplished with Bash, text files to hold the dat…
"Being able to understand the business of the customer and create software that helped them do that easier." I don't consider that software 'engineering' necessarily. Yes to be a more useful employee or more successful freelancer etc understanding the business case is absolutely an essential skill. But the 'engineering' begins once the problem has been defined; how do you actually implement the vision.
Earlier quoted context omitted.
How are you supposed to learn concepts like higher-order functions if you only know C, for example?
If mathematicans did it, then why we, computer people wouldnt?
Earlier quoted context omitted.
>Well yeah learning a wide variety of languages is a good way to do that. Well, depends what concepts are you talking about. Computer science is huge as hell, concepts that you may learn from programming languages are just subset. There's a lot of interesting and hard stuff that does not touch those (I'm not focusing on some domain-specific-languages that nobody know about)
But learning languages is a great way to learn many concepts. Obviously it doesn’t teach you everything - nobody claimed that. Want to learn concurrency? Try a concurrent language. Parallelism? Learn a parallel language. Data flow? Learn a data flow language. Pattern matching? Learn a language with pattern matching. Etc for a thousand useful subjects to learn. These are great ways to learn so many software engineerin…
eg async await
You are just learning tool like Excel