|
|
I have been using SketchUp[^] from the days when it was a high priced application (somewhere around 350 USD, 15+ years ago), through the years when Google provided it for free, and I am still using it. Today, you have two choices: Either buying a subscription (no one-time-fee option), or a web version. I detest web based software, so I stick to the last freely available one, "Sketchup Make 2017" - google that, and you will find lots of sites from which it can be downloaded.
It takes a little effort to learn to use it properly, but once you learn it, you can easily make some really impressing drawings. And there is a huge library of 3D components - lots of makers of furniture, machinery, tools or whathaveyou have made SketchUp models of their products as a way to market them. Plus zillions of components made by SketchUp users.
SketchUp is a sketching tool - not a CAD/CAM tool. It is for showing the carpenter (or whatever sort of craftsman) how you want it to be when completed, not to tell him how to build it. I am in the middle of a process to prepare 30-40 "slides" to show the entrepreneur how I want the remodeling of my house to be. For that use, SketchUp is great.
|
|
|
|
|
Perhaps something for a survey...
With so many options how do you choose what languages and frameworks you learn?
Do you just learn and use whatever is used where you work? Do you have a say in the matter? E.g. when starting a new project can you use whatever you want to get the job done or is there a specified language you have to use?
Do you learn something new because it's popular / in demand in the job market?
For personal projects... maybe just because it looks cool or useful?
|
|
|
|
|
Jacquers wrote: Do you just learn and use whatever is used where you work? Do you have a say in the matter? E.g. when starting a new project can you use whatever you want to get the job done or is there a specified language you have to use?
I get to choose, but it has to meet requirements so you end up with limited choice anyway. For example, if you need to make a web application, then you can't just choose a native Android app on the basis it is interesting... because it just wont meet requirements.
Jacquers wrote: Do you learn something new because it's popular / in demand in the job market?
Depends. If I was looking for a new job, or my current skillset appears to be dropping off the market at an alarming rate, then yes - learn what is in demand. Learning just the fun stuff is for people who have other (non-coding) ways to pay the bills.
Jacquers wrote: For personal projects... maybe just because it looks cool or useful?
If I want it done fast, use what I already know. If I have plenty of time, then maybe look at something new... or more realistically, just pretend to have ambitions to making all the awesome personal projects I come up with but really just do other non-coding things with my spare time instead.
|
|
|
|
|
I'm very biased, so first off, I don't learn new things just because the blog-sphere and rags start raving about some new language or framework.
Second, I love C# and I have absolutely no reason to use anything else, not even Python anymore as C# with .NET Core runs on my rPi's.
Third, I've ditched jQuery, Bootstrap, and am pretty much biased against any of those frameworks like Angular, React, Vue, etc., because frankly, it's not rocket science to "get stuff done." I don't need bloat to "get stuff done."
So for client-side development, I use TypeScript and that's about it. If I want a nice UI I'll use jqWidgets[^] but without all that framework support.
For work I have to use ExtJS  and am happy to use Angular, but for personal projects, I am highly opinionated and find no reason to "simplify" my coding with "complexity." The reason should be obvious.
|
|
|
|
|
Try Sveltejs. Might open you up to something new.
|
|
|
|
|
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.
|
|
|
|
|
What to learn?
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?
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.
|
|
|
|
|
I have been most fortunate in this respect.
As it turns out, I've always been able to just learn something because it seemed useful and the the fortunate part kicks in: it seems to be just what's needed where I work.
C, C++, ODBC for Excel, web development, and others. At least I prefer to think of it as luck, although clairvoyance wouldn't be found offensive.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
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.
Real programmers use butterflies
|
|
|
|
|
Mailing address please. You're in serious need of a rubber duck. 
|
|
|
|
|
I don't know what that means but you're probably right.
I inserted a switch/case instruction into my virtual machine that basically is the equivalent of 1 iteration of a DFA match.
Clever me. Now if I can get my code to emit these instructions i'll have partial DFAs in my machines.
Real programmers use butterflies
|
|
|
|
|
It means that your rubber duck[^] would be eager to consult on your original post (and many others).
|
|
|
|
|
I get it now. Thanks.
Real programmers use butterflies
|
|
|
|
|
I remember talking about my rubber duck before, and you must have been wondering "WTF?!"
|
|
|
|
|
I like some WTF moments, because it means I can learn stuff or at least have interesting convos about it.
Real programmers use butterflies
|
|
|
|
|
She's got a rubber duck, doesn't she? CP Lounge is a rubber duck as good as any!
|
|
|
|
|
Yes, but it'd be faster to speak to a rubber duck. More time to write code!
|
|
|
|
|
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.
|
|
|
|
|
|
haha that's actually kind of cool.
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.
That's awesome.
Real programmers use butterflies
|
|
|
|
|
Please consider using the "Best Windows of all times" 
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
