The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Of course, whatever matches best your high level view of things.
I prefer logic programming, which means safe, declarative programming in the broader terms.
So, now I'm going throu Rust apprenticeship, enjoying safety, functional programming at 0 cost, Wasm, multithreading, reactive GUIs, and more. IMHO, it's *the* language worth the effort.
I watch the local job market, keeping a mental list of the in-demand skills. I learned a long time ago that desired skill sets vary by area, and skills in-demand elsewhere don't help me. I don't bother with anything that will not provide a financial return on my investment in learning time.
Blogs are mostly opinion pieces that cherry pick "facts" to back up their points. I read some, but they never have the same importance as the local job boards.
Do I sound mercenary? I'm not, just financially responsible. I have learned to truly enjoy luxuries such as eating and living in a home, so ensuring I'm employed is top priority.
Technologies at work?
Mostly I've had an influence on what technologies were used. If I didn't think a given technology would be useful going forward, I found slots which used technologies that I thought would be. [Not that I haven't guessed wrong -- on those days my Magic Eight Ball was cloudy and told me to try again the next day.]
Side projects fill two needs for me: 1) keeping my mind engaged in something I like doing, and 2) learning new technologies. I have lost track of the number of languages I learned, and learning new languages lost its magic a long time ago. However, learning what I can do with a language (for fun or profit) continues to be important.
I have written an address book application a dozen times in various technologies. I know the requirements by heart and it includes the important concepts (UI, DB, business layer, etc.) for learning a new technology.
I personally go first and foremost with what makes the most sense for the task going for maturity, ease of use over popularity. And an overall stability of the ecosystem.
Were I, for example, to do web frontend stuff, I wouldn't pick the some JS framework du jour but would go with something more stable (and I guess less exciting) such as TypeScript or Blazor. Granted, the latter is kinda new and fast-moving, but it's foundation in C# is solid.
For dekstop development, my current choice during work hours is Delphi. It's got the advantage of not requring a separate runtime (which is an important topic when delivering software), but it's mature and modern as a language (with C++ catching up only slowly) and it got a, once again, mature and easy to use, UI framework integrated.
Although I'd start the next project with C# because it IS a better language, still got a good UI framework and the runtime requirement is getting less important as .NET gets included in latter Windows versions (with C# binaries running cross-platform should that need arise later).
The next topic I can think of is systems programming. There, I'd leave my old-and-tried-mantra because that whole "tried" part is, less important than safety which is IMHO actually way more important in systems programming than in high-level user-facing stuff. C is tried all right, but it's a nightmare to do anything productive with whereas Rust excludes heaps of bugs by language design and the compiled binaries are both compact and run fast making Rust my language-to-learn the moment I got to do anything low-level.
Since I was the firmware department at the last place I worked (retired now), I was able to use whatever language I wanted. In reality, C/C++ is really the only option I had. Every microprocessor I've written programs for (small memory processors) has had a C/C++ compiler available for it. Plus, after being a firmware engineer for my whole career, I had built up a very large library of C/C++ routines.
So I was trying to make my emitted bytecode in lexly a little tighter generally and my strategy was to introduce an AST->NFA intermediary step so i could analyze the execution as a graph, optimize the graph, and then emit code from that.
Well, I overthrought it.
it turns out I could move my optimizations to the parsing phase and get the ASTs to write out tight code. I don't need the NFA at all. But I guess now that i have it i can create execution graphs with it. I don't know what for. It's barely code.
If this were "real" code my strategy would have merit, but since it's such a simple language it can all be optimized during the parse. I wasn't getting any better code out of it turning it into a graph.
Now, it's possible that i might down the road, if I can get the fecking thing to do partial DFA transformations on that graph and then introduce some special instructions for running a DFA that would really be cooking with gas, - DFAs are very efficient, but so far I haven't had luck doing a partial powerset construction because i'm using rangesets as my basic input alphabet element. I've been boxed in here by Unicode. What I'd like to do is expand the rangesets into individual characters when they're not too big, and then transform that subset, while leaving the rest of hte graph alone but so far the problem stumps me.
Anyway, I'm either banging my head against it, which sometimes works, or i need something fresh to work on but i'm not coming up with anything just now, and my permanent insomnia that comes with my madness makes this kind of fretful for me. I need stuff to occupy me through the witching hour.
Personally, I use documentation for rubberducking. First writing it down as the elements come to mind; it usually comes out in a rather messy fashion. Then I start organizing all the elements in a proper structure for a user, making bullet lists of highlights, drawing sketches of how data structures relate, writing small code snippets to illustrate the use of what I am implementing.
I took a typing class in 8th grade; that was an essential preparation for a Comp.Sci education, although in 8th grade, I had never seen a computer. So it takes me far less time to write it down once I have created a statement in my head; most of my time "writing", my keyboard is idle (but usually with my fingers hovering over the keys). The typing doesn't take long - making my thoughts clear in my head is what takes time. That I will have to do even if talking to a rubber duck (or in my case: A 10 cm tall rubber Jenkins). One other benefit: Quite frequently, I believe that my first "final" explanation was clear and lucid. Picking it up a few days later, I see that it is still a mess, and I have not addressed, or misunderstood, several aspects. If talking to a rubber duck / Jenkins, there is no memory of the points that are still unclear.
Another benefit: I spend little time writing documentation. It is there already, ready to be delivered with the code.
Thanks for sharing your novel approach. I try to document code fairly thoroughly as I write it, but that's still quite a ways from what you're doing.
Our typing backgrounds are very similar. I also took it in 8th grade before seeing a computer. So when I took it in 9th grade with an 8th grade classmate, we became fairly proficient. He could do about 60 wpm and I could do about 55, on manual typewriters! Now that correcting errors is so easy, my accuracy has dropped significantly.
Michal learned that the object files that CoreTR's AOT (ahead of time) compiler in 2020 can be linked with the 1994 linker from Visual C++ 2.0. The result is native code that links up with Win32s that runs in 16-bit (ish) Windows 3.11. Magical. Kudos Michal.
Must be a team player that works with a sense of urgency.
Okay, there are two translations that come to mind:
1) "works with a sense of urgency" --
Translates to..."Drinks a lot of water but is allowed no restroom breaks"
2) Must be a team player that works with a sense of urgency -- Translates to, "Don't be griping when we tell you late Friday afternoon that the thing has got to be done by Monday morning!"
Also notice that they are looking for a "team player that" and not a "team player who" which indicates that they think of you as any other piece of office equipment (chair, desk, etc.) since you're a that and not a who.
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
Last Visit: 4-Jul-20 6:23 Last Update: 4-Jul-20 6:23