I just heard the bad news that I am probably going to need a new job starting in July.
So, before beginning the regular search, I wanted to ask my Fedi friends if anyone could use a capable C++ programmer with lots of graphics and networking experience. I wouldn't mind a change, so I'm open to anything. Even other programming languages! It would be awesome if I could use Linux to do the work. 🐧
Locations I would consider are: Central Europe, Melbourne, Sydney or Remote
Another bit of gold from #ICFP2023 by Pjotr Prins of the University of Tennessee. The actual title of the talk is "Why code in Python+C if you can code in Lisp+Zig?" but the "Lisp" in this case is actually Guile Scheme. I didn't know this, but Zig uses the C ABI so it binds to any language that can do FFI bindings to C, including most Scheme and Common Lisp implementations. But why don't I just post the abstract here:
> "Most bioinformatics software today is written in Python and for performance C is used. Lisp has been around for over half a century and here I don’t have to tell how or why programming Lisp is great. I will talk about Zig as a minimalistic new language that is unapologetically focused on performance, tellingly with a blazingly fast compiler. It is advertised as a replacement for Thompson, Ritchie, and Kernighan’s C, but it may even replace C++ in places. Zig uses the C-ABI and does not do garbage collection, so it is ideal for binding against other languages. In this talk I will present combining GNU Guile Lisp with Zig. I’ll argue that everyone needs two languages: one for quick coding and one for performance. With Guile and Zig you get both at the same time and you won’t have to fight the Rust borrow checker either."
What are the benefits of using C over C++ for greenfield projects, setting aside build times and such.
In other words, is there anything that can be done in C that cannot be done at least equally well in C++? Is there something that can be done in C that just can't be done in C++? What are the dealbreakers?
(No language wars please.)
Boosts appreciated: my sphere of influence is quite small. 🙏
The software industry, especially in the realm of free software, has mostly settled on a pattern of using C++ for creating performance critical libraries, and creating Python binding to the C++ libraries for scripting. I was hoping Rust might come along and change all this, but it will take decades.
In the mean time, if you want to use C++ but not actually write C++, you can make use of the ECL Common Lisp compiler, which can compile Lisp to C++ code. This gives you all the best features of Common Lisp for programming with the universe of C++ code libraries available to you. You can use a C++ library and still have Common Lisp macros, garbage collection, high-level scripting, S-expressions as serialization, domain specific languages, a proper meta-object protocol that wraps C++ classes nicely, and wealth of choices for functional programming systems from the untyped lambda calculus all the way up the lambda cube to System-F and the Calculus of Constructs. This not only makes ECL a viable alternative to Python for scripting and app development, but objectively better than Python since you can actually turn your Common Lisp scripts into code that gets compiled into a larger C++ application.
With ECL I would have all sorts of C++ libraries available to me:
game engines like Unreal and Godot
3D modeling: FreeCAD, OpenSCAD, Blender
Machine learning, big data, and HPC with PyTorch, TensorFlow, OpenCV, OpenCL
I will continue to contribute to the Scheme and Haskell communities as much as I can. I will continue to pursue my dream of an Xfce-like desktop environment written in Scheme. But no matter how I look at it, I am going to more productive in the long run using ECL and C++.
I was hoping that the software industry would gradually shift over to better, more functional languages like Rust and Haskell. And I would love it if Scheme languages could ever begin to seriously replace Python as a scripting language. But realistically, I think I am going to change tack and meet the industry half way. I think I should probably start using ECL as my language of choice, as much as I would prefer Scheme or an ML-family language like Haskell.
I was experimenting with colour distances at work today. I need to find out how similar two colours are, so I wrote a little test program and it was surprisingly pretty.
The algorithm is simple:
Fill the canvas with random colours.
Set the first pixel (top left) to red.
For all pixels, find the most similar pixel and move it next to the current pixel.
To determine the similarity, I calculated the 3D distance in the RGB, HSV and YUV color spaces, which brought very different results. Now, it's quite possible that my HSV and YUV conversion functions were just broken, but that's okay.
It is interesting that both C++ coroutines and async Rust are stackless coroutines, but unlike Rust, C++ coroutine states must be dynamically allocated.
In addition, C++ coroutines is a more general-purpose feature that can model things such as generators, which I definitely wish it could reside on stack.
I am not knowledgable enough about what kind of tradeoff lead to those design decisions though.
Told myself I'd do an #introduction / #intros pinned post after I got 500 followers and here we are.
I'm Marie, a bisexual woman from the US midwest, California, or Rhode Island depending.
You can find me as jamuraa on most of the platforms I exist on. I make Bluetooth, bake a lot, and play with 3D printing. I have a Ph.D in Computer Science and run for exercise most days unless I'm hiking around a forest.
I like Bluetooth - luckily getting money to work on it and make it better for billions of people for almost a decade. I've been in tech much longer.
I code a lot in #rustlang and #cplusplus but also have approximate knowledge of many languages and use them variously.
I've been avidly baking things for about five years now, and really enjoy learning new recipes and techniques. It's definitely magic to have some bread out of the oven. I post my baking on the #MarieBakes tag behind a CW as they can get long, with the exception of the #BreakfastBakes which always have that tag.
Reminder that the #programming languages useful for #applications may not be the same as those used for #libraries that the applications use, and this is just fine, e.g. performance often requires that one does not rediscover the wheel by recoding libraries in #clang#cplusplus and #fortran because they are, for whatever reason , resistant to use a proper #ffi (or an #IPC) #api.
After 11 years and 15 days from 2012-07-12, I am proud to present the first real release of MoeNavigator - a web browser written from scratch in C++. Its engine (called MoeNavigatorEngine) is also written from scratch:
If you're doing a lot of work in C/C++/Rust consider using sccache to cache compilations. It's easy to set up and will save you a lot of time and a huge amount of power.
I think there would be still space for systems programming language with a constraint from day zero that it would 1:1 compatible with plain C”s binary layout and memory model:
Roughly just .text, .bss, .rodata and ,data.
No symbol mangling at all.
All the memory safety etc. fancy features would be then designed within exactly those constraints.
#Rust is essentially a derivative of C++ when compiled to binary, which does not really make it a strong competitor for plain #C. It can substitute C in many cases for sure, just like C++ did, but there’s always need for minimal systems programming language, which also looks elegant in binary, not just in source code.
A compiled C program can be quite easily understood with a binary with no debug symbols at all if you understand the CPU architecture well enough. That is, and will be a strong asset for C.
This is a 48 minute long article that's critical of the Rust hype train vs C/C++. The TLDR is that while security is a problem, the Rust vs C choice as the only choice for low-level systems programming is a “non choice”. The author states that Go is a perfectly fine choice. https://medium.com/