[-] FizzyOrange@programming.dev 3 points 1 month ago

I would probably recommend not trying to understand the whole field of programming initially. It's huge, you won't understand what the terms mean (e.g. OOP, functional programming, etc.) and it's not very motivational.

Instead I would pick one or two popular languages to learn and actually make something in. The no-brainers are Python and Typescript. They're hugely popular, not difficult, and let you get a lot done.

I think I would consider learning both at the same time. If not, at least don't stick with Python too long. It is immensely popular but also has a lot of brain dead design decisions. Especially a) it's reaaaally slow, you easily get a 50x speed up just by switching language, and b) the "infrastructure" around it - installing Python, adding libraries etc. is completely awful. There are attempts to fix that but they're nascent.

Above all I think a good thing to have is a realistic goal of something to make. For Typescript the obvious thing is a web site. I really like this way of making web sites - you can get started with literally 2 command - but it may be a little too much for a beginner.

For Python I would look into some kind of automation or maybe web scraping thing. It's decent at that.

Or if you have more specific project ideas you could use the most appropriate language for those, e.g. a microcontroller project you probably want to start with Arduino (C++). C++ was my first language (apart from QBasic which doesn't count). Probably not for everyone though. I was very young and had free time.

[-] FizzyOrange@programming.dev 3 points 1 month ago

The only Git GUIs that I've ever liked:

  • GitX, and its many forks. Mac only though.
  • Git Extensions. Terrible name, but this is actually a standalone Git GUI and is surprisingly decent. I think it started Windows only but maybe there's a Linux port now.
  • VSCode's "Git Graph" extension. It's not quite as fully featured but it integrates well into VSCode and is pretty nicely designed.

I've tried almost all the others (SmartGit, Sublime Merge, GitKraken, etc.), and didn't really like how they worked.

[-] FizzyOrange@programming.dev 3 points 1 month ago

Ooo I've not seen this before. Looks interesting.

[-] FizzyOrange@programming.dev 3 points 1 month ago
  1. If your alternative is C++ then it removes the enormous burden of manually tracking lifetimes and doing manual memory management. C++ does have RAII which helps with that enormously but even then there are a gazillion footguns that Rust just doesn't have - especially with the newer stuff like rvalue references, std::move, coroutines etc. It also saves you from C++'s dreaded undefined behaviour which is everywhere.

  2. It has a very strong (and nicely designed) type system which gives an "if it compiles it works" kind of feel, similar to FP languages like Haskell (so they say anyway; I've not used it enough to know). The borrow checker strongly pushes you to write code in a style that somehow leads to less buggy code. More compiler errors, but much less debugging and fixing bugs.

  3. The libraries and APIs are generally very well designed and nice to use. If you've ever used Dart or Go think how nice the standard library is compared to JavaScript or PHP. It took C++ like 2 decades to get string::starts_with but Rust started with it (and much more!).

  4. Fast by default.

  5. Modern tooling. No project setup hassle.

  6. It's a value based language, not reference based. References are explicit unlike JavaScript, Java, C#, etc. This is much nicer and makes things like e.g. copying values a lot easier. JavaScript's answer for ages was "serialise to JSON and back" which is crazy.

Downsides:

  1. Slow compilation sometimes. I'd say it's on par with C++ these days.

  2. Async Rust is kind of a mess. They shipped an MVP and it's still kind of hard to use and has unexpected footguns, which is a shame because sync Rust avoids footguns so well. Avoid async Rust if you can. Unfortunately sometimes you can't.

  3. Interop with C++ is somewhat painful because Rust doesn't have move constructors.

Great language overall. Probably the best at the moment.

[-] FizzyOrange@programming.dev 3 points 1 month ago

I think you need to give more details about why you have this crazy set-up. What are you trying to achieve?

You can git add the file but also add it to .gitignore. But I don't know if that really solves your problem because it isn't clear what your problem is.

[-] FizzyOrange@programming.dev 3 points 1 month ago

I'm not sure I'm convinced by their reasons for not creating a new language (i.e. PRQL). I used it a bit and it was fantastic. It has support for using raw SQL if you need to access really niche features.

Really the only problem is that it doesn't support mutation, or database-specific features (but you can use the raw SQL escape hatch in that case).

Still, this does look like a great improvement.

[-] FizzyOrange@programming.dev 3 points 2 months ago

Oo hello. Didn't know that's what you were doing these days! Hope it goes well, though I'd be nervous about a realistic business plan.

Anyway, yeah bit too late for Python.

[-] FizzyOrange@programming.dev 3 points 2 months ago

you generally use a SAT solver for dependency resolution (unless you don’t care for correctness)

Actually Go's dependency system is specifically designed to avoid the need for global constraint solvers. Go has the most modern and elegant dependency versioning system that I'm aware of. Python was designed before people realised that it's dependency style was a mistake.

https://research.swtch.com/vgo-principles

[-] FizzyOrange@programming.dev 3 points 3 months ago

no need for flatpack/appimage/snap ect

No matter how large their repo is you're always going to find some software they haven't packaged. Trying to convince the entire world to use your repo isn't scalable.

[-] FizzyOrange@programming.dev 3 points 3 months ago

Anything that helps scientists and engineers move away from MATLAB is welcome.

The MATLAB language may be pretty bad but IMO that's not what makes MATLAB good. Rather it's:

  1. Every signal processing / maths function is available and well documented. I don't know how well Julia does on this but I know I wouldn't want to use Python for the kinds of things I used MATLAB for (medical imaging). You don't have to faff with pip to get a hilbert transform or whatever...

  2. The plotting functionality is top notch. You can easily plot millions of points and it's fast and responsive. Loads of plotting options. I just haven't found anything that comes close. Every other option I've tried (a lot) only works for small datasets.

[-] FizzyOrange@programming.dev 3 points 3 months ago

Sure but that's not relevant to the current discussion. The point is that removing the GIL doesn't affect Numpy because Numpy is written in C.

[-] FizzyOrange@programming.dev 3 points 3 months ago

Python is written in C too, what’s your point?

The point is that eliminating the GIL mainly benefits pure Python code. Numpy is already multithreaded.

I think you may have forgotten what we're talking about.

the new python version was less than 50 lines and was developed in an afternoon, the c++ version was closing in on 1000 lines over 6 files.

That's a bit suss too tbh. Did the C++ version use an existing library like Eigen too or did they implement everything from scratch?

view more: ‹ prev next ›

FizzyOrange

joined 1 year ago