501–510 of 527 posts
Earlier quoted context omitted.
For anyone not familiar: You can bundle arbitrary software as Python wheels. Can be convenient in cases like this!
What "cases" are those? Tell me one useful and neat case. Why is it useful and neat, you think?
Earlier quoted context omitted.
It could easily be the case that the zig compiler is useful in some mixed-language project and this is not actually "abuse".
Regular Python bindings / c extensions don’t depend on a pypi-packaged instance of gcc or llvm though. It’s understood that these things are provided externally from the “system” environment. I know some of it has already happened with rust, but perhaps there’s a broader reckoning that needs to occur here wrt standards around how language specific build and packaging systems handle cross language projects… which coul…
Usually arbitrary binaries stuffed in Python wheels are mostly self contained single binaries and such, with as little dynamic linking nonsense as possible, so they don't break all the time, or have dependency conflicts.
It seems to consistently work really well for binaries, although it would be nice to have first class support for integrating npm packages.
Earlier quoted context omitted.
Because std::vector isn't much of an abstraction, in the sense of removing a set of concerns from consideration. v[i] is just pointer math. What happens if you index outside the bounds of v is anybody's guess, and it can fail silently. You could use v.at(i), but then somebody will yell at you for using exceptions. Regardless of where you stand on C++ exceptions, the fact that it's up for debate means that it will get…
I assume that whatever pron had in mind would apply equally to Rust, and this does not.
Earlier quoted context omitted.
Unfortunately capy uses Gtk+ on Linux, so it's a no-go for me. :(
What do you consider to be native GUI on Linux if not something like GTK or Qt ?
Earlier quoted context omitted.
You could have achieved the same with Modula-2, which is the mapping to 1978 from those dates.
That's fair. I was born twenty years after Modula-2 was released, so I definitely have gaps in my language knowledge :D
As for the other ones I listed,
https://en.wikipedia.org/wiki/Mesa_(programming_language) (some PDFs linked from there)
https://bitsavers.org/pdf/borland/turbo_pascal
https://docwiki.embarcadero.com/RADStudio/Sydney/en/Delphi_D...
and
The article's claim of Zig being a "totally new way to write programs" is quite mad but I'd like to make a different claim: Zig's own development is a totally new way of writing programming languages (or is at least very rare). While I don't wholly agree with all choices made by Andrew and the Zig team, I greatly appreciate the care with which they develop features. The slow pace of deliberating over features, refini…
In terms of programming language development, take a look at Clojure. The clarity of reasoning behind every decision is unmatched.
A great degree of occasional criticism of Clojure typically comes from brief exposure - either from not using structural editing idioms, misunderstanding REPL-driven workflows, or confusion around "the type system". Of course, Clojure being dynamically/strongly typed, doesn't really have a type system in the traditional sense, yet it has mechanisms that provide type-like guarantees, and from pragmatic point-of-view those instruments are incredibly robust.
Earlier quoted context omitted.
> So it would fail to compile when configuring static analysis to build on error when using C with C++ compiler. What do you mean? I don't think I can follow you. > yet the compiler language switches to use C extensions in C++ mode keep being used across many projects. When you use compiler extensions, that just happen to be both available in C and C++, I wouldn't say you are writing C in C++, I mean the extension is…
Only when removing everything that C++ adopts from C, other than low level implementation details that cannot be done in any other way. That is what writing proper modern C++ is all about, anything else is writing C in C++. Null terminated strings with pointer arithmetic instead of std::string and string_view, pointer arithmetic instead of std::span, bare pointer arrays instead of std::array and std::vector, C style…
That is a claim that is yours and I do not agree with that. C++ that does not fit your taste of modern C++ does not suddenly become C, it is likely a syntax error in C and when it compiles it has a different meaning. Code that may look to you like C in C++ has C++ semantics, that differs from C semantics.
Earlier quoted context omitted.
"C-like" code in C++ still has C++ semantics. "modern C++" is a disputed paradigm, but not necessarily how things should be done. When you write C++, but not "modern C++", that doesn't mean you are writing C. There are also modern features in C. https://floooh.github.io/2019/09/27/modern-c-for-cpp-peeps.h...
Null terminated strings with pointer arithmetic instead of std::string and string_view, pointer arithmetic instead of std::span, bare pointer arrays instead of std::array and std::vector, C style casts,...
Earlier quoted context omitted.
Same can be said about other programming languages. Therefore the comment of yours has zero value…
Nah, there are many languages ignored or even despised by those dev celebs. > yours has zero value Yours didn't bring much as well, so I suppose value isn't strictly required.
BTW: Your reply made me laugh so hard… I loved it.
Thanks.