|
Mircea Neacsu wrote: In C++ '+' can be redefined to do whatever you want.
I never programmed Forth myself, but a former coworker who was a Forth worshipper (quoting the Scriptures: "Go Forth, and Multiply") showed med how to really obfuscate code: Forth lets you redefine any token. So he redefined '17' to have the value of '5'. That brings the concept of 'off by one' to new levels 
|
|
|
|
|
I had a love affair with Forth. When I read Leo Brodie's "Starting Forth" book I fell so much in love with it that I wrote my own interpreter (in MACRO11 - the PDP11 assembler no less). Talk about being young and foolish 
Mircea
|
|
|
|
|
LOL! sorry for cliche but so true.
|
|
|
|
|
Greg Utas wrote: I'm amused that Linux wants to start using it. Talk about a culture clash. C++ would make far more sense, but maybe the Linux crowd also feel that C has abused them.
Linus hates the way some C++ features generate huge amounts of magic code behind the scenes that makes it difficult to reason about low level performance impacts.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Anything that's critical to performance has to be measured and can typically be rectified. I think the main problem is that almost all the Unix types are hackers at heart, comfortable with spaghetti code.
|
|
|
|
|
That article (rant) that you mentioned is really interesting & makes a great point about C being not just a language but a protocol (since you have to learn C if you want to make any system calls). That's really a great article. Thanks for sharing.
|
|
|
|
|
In fairness, it was Kent who originally posted that link. It was a fun read that made some good points.
|
|
|
|
|
I started reading the rust documentation -- in the first section it says that by default variables are immutable.
Hokay ... it appears the inventors of the language didn't know what "variable" means and didn't know how to type "dictionary.com" in their browser.
I didn't feel the need to read further ...
|
|
|
|
|
All they did was make C/C++ const the default so that you have use the equivalent of mutable if it's not constant.
|
|
|
|
|
Greg Utas wrote: All they did was make C/C++ const the default so that you have use the equivalent of mutable if it's not constant.
Let's think about this. In a typical program I declare dozens of variables and a handful of constants, and of those variables, probably 0.01% need to be immutable once declared.
So the Rust designers flip that, requiring me to explicitly specify that a standard entity in all programming actually behaves as expected, and the default behavior is an edge case? It's a solution in search of a problem and failing to find one.
OTOH, each new release of C# contains new syntax that is more cryptic, and those designers crow, "with this new syntax you save typing TTWWWWOOOOOOO characters!" like it's the greatest thing in the world.
Clowns to the left of me, jokers to the right ....
|
|
|
|
|
The variables may be immutable, but that just means you can't modify the state of the variable. Strings in dotNet and Java are immutable but you can assign a new value to the variable.
Immutability has huge advantages in multi-processing, whether it be on a single core or multiple cores. These advantages all resolve around proving the code is correct. Note - performance is not an advantage in this case. Since Rust is designed to be a system level language that supports multi-core systems, making all variables immutable greatly simplifies development.
|
|
|
|
|
BryanFazekas wrote: in the first section it says that by default variables are immutable.
Hokay ... it appears the inventors of the language didn't know what "variable" means
One rule I remember from my student days: "Constants ain't, variables won't".
I have experienced the truth of this rule quite a few times.
|
|
|
|
|
Coming from a history of C/C++ & even C#, I too felt the way you do about Rust when I first started looking at it. And, I also felt like the syntax is ugly & odd.
However, if you look at it from the viewpoint of what the Rust developers were actually trying to fix, it is quite amazing.
I think that reading this book is what really opened my eyes to it: Rust for Rustaceans: Idiomatic Programming for Experienced Developers[^]
That books delves into what the problems were that have occurred to C/C++ and how the language and compilers have been manipulated to make them end-all be-all even at the risk of code becoming breakable & unsecure.
But, it's a lot to go into and if you're happy with C then there is no reason you would really look into it. I'm always just curious about what they are really trying to do at the foundations.
|
|
|
|
|
Thank you for that. Maybe it will open my eyes, and even change my mind. I've been looking for good material on Rust.
To err is human. Fortune favors the monsters.
|
|
|
|
|
Hey!
fn main() is fn awesum!
:p
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I was in total agreement until you wrote:
honey the codewitch wrote: a perfectly good language (C)
Neither perfect nor good, IMO.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
Well I was being generous. I prefer C++ myself.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I can respect that. In my current and previous roles in the financial and music industries (respectively), both immersed in the Microsoft world with no need for hardware-level programming, I prefer C#. But if I had the opportunity to do hardware-level stuff again my preference would probably shift to Assembly. I love speaking CPU.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
I like the challenge of developing highly usable type safe interfaces that resolve to really efficient assembly like you'd have typed by hand.
A recent endeavor had me bitbanging the SPI hardware registers on an ESP32 MCU to get faster performance. It was all microsecond sensitive, requiring me to have total control over what got inlined and not. I had to use constexpr everywhere to forward as much of the configuration, like pin assignments off to compile time evaluations.
It replaced a nasty set of C preprocessor macros that accomplished the same. Byte for byte it generates the same assembly instructions.
The guts of this file are not clean, but what it presents to the user of this header *is*
htcw_tft_io/tft_spi.hpp at master · codewitch-honey-crisis/htcw_tft_io · GitHub[^]
To err is human. Fortune favors the monsters.
|
|
|
|
|
That's some sweet code there, and a great use-case for C. But gawd how I hate pointers. 
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
I'm a weirdo, but I feel like i have a knack for pointers. they don't intimidate me at all and i almost never cause AVs with them in C++. I'm much more likely to make bad things happen like that when I'm P/Invoking from C# just because i have less of an immediate idea of what marshalling is happening.
To err is human. Fortune favors the monsters.
|
|
|
|
|
It might be that Rust is designed to solve different problems than the ones you need to solve? Though it's okay to just flat out dislike it as well.
If you add up the billions of dollars of damage caused by good C programmers with decades of experience making mistakes that Rust would have disallowed - things like Heartbleed - you can see the motivation to use a language like Rust. Like it or not, year in and year old, a huge percentage of bugs and vulnerabilities in software are caused by memory safety issues.
It's certainly not the best choice for every problem. I can't say I *love* writing Rust. But I think it's a good choice for you need C-like performance but can't afford vulnerabilities. Say you're implementing something like OpenSSL - I'd argue that if you're starting a project like that in 2022, you'd be crazy to pick C (or even C++) over Rust. I suppose you could pick something like MISRA C or even Ada as well, but I don't think either of those would be more joyful to write than Rust.
For certain classes of problems, the only safe assumption you should make is that you do need training wheels because no matter how much experience you have or how good you are, eventually you will make a costly mistake. For most other applications, Rust probably isn't the best choice.
My personal position on it is that I never quite enjoy writing Rust as much as other language; I never seem to get into that state of seamless flow I get into in other languages. But I also think it fills a niche that isn't particularly well-served by other languages. I think that Rust might not be the #1 tool for you or me, but I also think our industry as a whole needs it (or something similar) pretty desperately.
|
|
|
|
|
This all makes a lot of sense to me, and I think it even goes to explain what I don't like about it in the end - it's not "flowy" enough.
I'd agree that our industry needs something like Rust, and maybe Rust is it. But I don't have to like it!
To err is human. Fortune favors the monsters.
|
|
|
|
|
Design in a studio tries for a role (9)
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
modified 22-Mar-22 6:32am.
|
|
|
|
|
Design (anag)
in a studio INASTUDIO
tries for a role
AUDITIONS
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
