the startup company i work in uses 6 different programming languages, which makes me feel what you argue here. to add, markup languages are fun and contrubiting also, particularly devops developing with yaml and composing Docker components makes you think in a different organizational mindset than other programming domains
Trying new programming languages helped me grow as a software engineer
111–120 of 192 posts
Re: Trying new programming languages helped me grow as a software engineer
#112For my personal case, I found out that writing "real programs" in anything else than assembly with a conservative usage of a macro processor is kind of toxic: it is a complex matter based on my experience and what I could understand from "software history".
A high level script language would be such "real program". Idem for a command shell.
risc-v, if successfull, will help a lot to this then remove a lot of what I consider toxic.
Re: Trying new programming languages helped me grow as a software engineer
#113Earlier quoted context omitted.
"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.
Defining the problem is a core part of engineering to me.
That's more on the project management side. (Initiating a project / gathering requirements)
Re: Trying new programming languages helped me grow as a software engineer
#114A lot of people seem to overdo it, but I'd recommend - Some sort of assembly - C - Java/Kotlin/C#/similar - Python - Javascript - Some Lisp flavor - Possibly Erlang - Possibly Rust This covers a lot of layers of the stack, along with some unique paradigms. I'd use it somewhat seriously for a while (months to year), not just as a toy to learn a language in a week. For a toy, JS and Java are close enough that you might…
Some logic programming sibling too
Re: Trying new programming languages helped me grow as a software engineer
#115Earlier quoted context omitted.
Defining the problem is a core part of engineering to me.
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…
Well, first of all, in your example bridge building is not the only civil engineering discipline involved—traffic engineers absolutely would be involved in those other questions.
More to the point though, software is not like a bridge. With a bridge, the high-level requirements are easily defined in a way that any layman can understand (weight limits, lane count, etc). Failure of a bridge is also viscerally obvious. Obviously there may be extreme engineering challenges in actually building a given bridge, but at the end of the day no one involved ever runs a serious risk of losing their handle on the big picture.
Software, by contrast, is arbitrary logic full of leaky abstractions and unknown touchpoints. Even if we narrow down to the most vanilla business CRUD app, precise requirements can be frustratingly elusive. No matter how well thought out a project, there are always discoveries at build time of any non-trivial project which significantly impact the requirements.
For this reason, I consider it a core responsibility for senior engineers to help define requirements and not just be a passive recipient of them. Martin Fowler captures my viewpoint more eloquently: https://www.youtube.com/watch?v=4E3xfR6IBII
Re: Trying new programming languages helped me grow as a software engineer
#116I 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…
Other than the fact that C can be run on basically any device on earth, and the super rich history behind it, does C as a language have any benefits? I personally don’t find C more ergonomic, expressive or beautiful compared to any other language.
C used to have a close to bare metal semantics, and on some environments¹ still have it. So if you need low level semantics, it normally beats assembly on those environments.
The Rust people are working hard to support everything that C does, so in the future C and asm will probably not have a monopoly there. But this is still not our reality.
1 - Of course, not a PC software stack, and not on any ARM available today.
Re: Trying new programming languages helped me grow as a software engineer
#117For my personal case, I found out that writing "real programs" in anything else than assembly with a conservative usage of a macro processor is kind of toxic: it is a complex matter based on my experience and what I could understand from "software history". A high level script language would be such "real program". Idem for a command shell. risc-v, if successfull, will help a lot to this then remove a lot of what I c…
Why do you think so? I assume that writing the same piece of code in assembly would take more than twice as long (conservative estimate) if you do the same in high level languages without much benefit. Can you elaborate your opinion a bit more as I am curious. I have been wanting to get into learning assembly but just cant seem to do it as high level languages are so easy to code in and want to know if anyone really uses assembly nowadays.
Re: Trying new programming languages helped me grow as a software engineer
#118Probably the best is learning null-safe types and why it is important for basic hygiene.
When you don't learn elementary type-safety, you create languages like Java and Go which are plagued with NullPointerException's and nil panics.
So please, learn an ML (and a Lisp).
Re: Trying new programming languages helped me grow as a software engineer
#119Earlier quoted context omitted.
C has a virtual machine? Do tell more.
It appears to also be called the "abstract machine"[1]. C semantics do not work "directly on the hardware" but instead on an abstract machine that is then converted to the actual hardware. It most often comes up when talking about undefined behavior and pointer behavior. Some assorted reading, mostly in the context of Rust and C: https://blog.regehr.org/archives/213 https://raphlinus.github.io/programming/rust/2018/0…
To be fair,
Assembly once worked directly on the hardware. On modern machines it doesn't.
Re: Trying new programming languages helped me grow as a software engineer
#120For my personal case, I found out that writing "real programs" in anything else than assembly with a conservative usage of a macro processor is kind of toxic: it is a complex matter based on my experience and what I could understand from "software history". A high level script language would be such "real program". Idem for a command shell. risc-v, if successfull, will help a lot to this then remove a lot of what I c…
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 platform, rewrite! Any application writer wanting to port their program from one hardware system to another, rewrite!
That would be an awful world to live in, though more people would be employed. Less would actually get done, though.