|
Richard Andrew x64 wrote: the engine makes 12 horsepower.
I just googled the Model T speed record. It apparently was 42 mph (68 kph), so I was out by a bit. It doesn't change my basic argument, that the advances in computer technology are orders of magnitude greater than the advances in mechanics and similar technologies.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
There is no such thing as kph! it is km/h.
|
|
|
|
|
About twenty-five years ago I wrote some code that did something similar. It was my import definition file for my script engine that define all the libraries and functions that were going to be imported along with their arguments and calling type. This was all loaded into shared memory once by the initialization process. This was for an automation system framework that was designed as a whole bunch of small, independent processes that were all implemented with the script engine. Everything was parsed and compiled to native machine code and it was lightning fast in both execution and load time. I was and still am pretty proud of that code. The last I heard there were over one thousand installed systems using the framework that are used to build all kinds of things.
The thing is, it too is a bit rusty now. That was all done in the 32-bit world and one thing in particular was done a bit on the sloppy side. Enough so that if it is ever ported to the 64-bit world it is going to a HUGE amount of work. One amusing thing is we heard from a few customers who thought interpreted code would be too slow. It really wasn't but I figured out how to generate machine code on the fly so speed become a non-issue. Now, with 5GHz, multi-core processors being normal that script engine could be reverted to compilation for interpreted execution and still be more than fast enough.
FWIW - the sloppy thing was handling time values which is REALLY important for those systems since a big part of their job is scheduling processing equipment. I should have used a specially defined type and the porting would be really easy. The way they were handled is going to be difficult to sort out but the clock is ticking on that. This is actually a potentially bigger issue than the year 2000 stuff was. That is because in 2037 the 32-bit time_t value is going to overflow so any systems that still use them are going to have interesting problems. I suspect that is a pretty large number of systems. Did you know the German railroad system still runs most of their trains with Windows 3.1? The US Navy still runs a large number of ships with Windows 98. There are tons of ancient, legacy systems in all kinds of places that need to be updated and if we don't get started soon big problems will arise. At the speed of government, thirteen years is really not that long.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
As far as time values I've learned to love the unix timestamp in 64-bits for cross platform transferability.
If you need higher resolutions than seconds you can fractionalize that or add a trailer or whatever.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
The New York subway system still runs on OS2. And Amtrak is probably still running on Visual Studio 6.0. The point being, it is really really hard to re-engineer an existing system. Sort of like re-building a skyscraper without tearing it down first. In other words, real code maintenance (aka, evolution) does not really exist yet. Monthly OS updates is not really a solution now is it.
|
|
|
|
|
Yes, it is hard to re-engineer an existing system BUT it is not that hard to update a system to run on a current operating system and compiler because that usually does not require re-engineering. That is, as long as the OSs are of the same family. I know because that is something I have done many, many times. The most frequent problems I encountered were issues with interfaces. I learned to make interfaces as generic as possible and that considerably minimizes porting issues.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
I wrote code over 40 years ago that I'm fairly sure is still running in telecom switches. It was a framework, so it might even still be used for a little development. And I know this to be the case for a framework I wrote over 25 years ago. If you're an AT&T mobile subscriber, that code runs whenever you call or text.
|
|
|
|
|
I am younger, so I can't speak about creations of mine older than 15-20 years. But I am pretty sure a couple of hundred-thousands (if not a couple of millions) have been using products done by machines I programmed in my industry automation days 
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
That's the whole point... Being on the edge... Granted, what once was a complex beauty now can be done with a single line, but the beauty stays... And we are moving on...
"If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization." ― Gerald Weinberg
|
|
|
|
|
Now, in my opinion, it's really an exaggeration:
Develop it today, migrate it tomorrow  
|
|
|
|
|
My name's enshrined here [BBC Kermit] as long as someone keeps this ancient piece of source code online...
I also know that every piece of this commercial product which I initially wrote in the late 80s has been completely replaced! I wrote it in VAX Pascal and it was rewritten in C for WinNT!
I'm resigned to the fact that every piece of software I've ever written has been or will be replaced and may only be kept for historical reference, not actual use.
|
|
|
|
|
You used to write single-line if-statements and now we have tools that warn you about bad code style 
|
|
|
|
|
Just dump some of your dollars into sculpting.
Maybe you can make a bronze (or something) casting where it is both code and sculpture.
I don't suppose I care if my code lives on. It's cool to think about in some cases (and horrifying in others), but the stuff that really transcends time is probably all of the very hard to quantify or even see 'butterfly effect' type things.
Like something you did in a codebase or something you posted nudging someone else to do different and on down the line.
|
|
|
|
|
I always tell people that programming is like building a house on sand on a hill, and someone added "when a rainstorm is coming"
|
|
|
|
|
Part of the learning experience. I have learned many things loooking for the right thing while trying the wrong thing. Even my "great" software would have been better with the tools of today.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
My experience has been about 10 years for code use before it is retired.
I did recently dust off some 20 year old code that had been obsoleted 19 years ago, but is now 80% applicable to a new need. I was surprised how quickly I found it.
|
|
|
|
|
honey the codewitch wrote: It really makes me wonder what is the actual shelf life of the things that I create, and how long will they survive once I'm on the wrong side of the dirt?
As I once told one of my coworkers (as well as an almost 80-years old carpenter neighbor of mine), coders aren't building cathedrals. Structures my old neighbor built when he was a young man are still standing today, and will probably continue to do so for a long time. I can't, and will never be able to, say the same about my work.
If any of the software I've written over the course of my life outlives me, it means I'll be dead far sooner than I'd wish.
Honestly I can't say I care too much if anything I wrote 10 years ago is no longer used today. A lot of it might be due to the fact that I might not even recognize it myself.
|
|
|
|
|
How Buddhist of you. I wish I didn't have a sense of attachment.
Check out my IoT graphics library here:
https://honeythecodewitch.com/gfx
And my IoT UI/User Experience library here:
https://honeythecodewitch.com/uix
|
|
|
|
|
Interesting perspective.
I do take pride in some of my accomplishments (a well-written library, for example, that I'll keep re-using over and over again), but "attachment"? Nah, I'm not feelin' it. I can always re-implement something, which means I can't get too attached to the original.
But, reading what you write about (with a lot of fascination from my part), it's clear we're not working at the same level. Not even close. And I do mean that in the best way possible. ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif)
|
|
|
|
|
Disclaimer: Rants of noob working with React and Material UI.
Pretty much despise both.
Material UI: It's default styling is for the geriatric -- mostly blind, needs everything in huge fonts, swimming in whitespace. And figuring out how to style Material UI is such a PITA, regardless of how much documentation there is on styling.
React: Really, no two-way data binding? State and props? OK, components are great, but half the time I have to extend the "props" with React.PropsWithChildren, like WTF, why??? And communication between dissociated components requires a pubsub (so I've read and implemented), or between parent-child components which I still haven't figured out -- seems straightforward but I haven't tried it yet. And markup in the TypeScript code? I get that because of the nature of a reusable component, but still, yuck. I want code to be code, markup to be not in my code.
And then, there's the "old" way of using React, with classes and super(props, state and the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech.
And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific state field appears to update all the state fields, so things like a jqxComboBox goes haywire when typing in specific text -- React resets the selectedIndex even though I'm not setting it in the state! So any field that uses {this.state.foo} causes React to say, "hey, there's state stuff on this widget, so let's f*** it over every time the component's state changes!"
And don't even get me started on using react-router which then requires (according to SO) that everything now be children of HashRouter instead of BrowserRouter which means hashes in the URL's.
I really do like the component stuff, Material UI can go the way of the dinosaur for all I care, and yet I feel like React is itself heading to extinction.
|
|
|
|
|
Marc Clifton wrote: Pretty much despise both.
Well, I agree with you in regards to Material UI. Or any JS "CSS" framework that does more harm than good. I don't know why, but devs will do anything to avoid learning CSS. IMO they should go be a farmer if they hate CSS that much. But it gets even worse when you add a JS layer for CSS on top it - your styles run much slower. Don't get me started on that.
But, React is awesome. Granted, sometimes it seems like every release changes things, but it's still a great framework. Any issues you got from it, I can promise is a result of not fully understanding the JS way of life. Which is, let's just call it "different".
Marc Clifton wrote: React: Really, no two-way data binding?
I think you're confusing React with Redux here, but unidirectional data binding is a good thing. Two-way data binding is slow and meant for people who don't want to learn. Redux was originally inspired by Facebook's Flux, which also used a concept of unidirectional data binding. React itself works no different than any other component-based architecture, including native web components (which was inspired by React).
Marc Clifton wrote: And then, there's the "old" way of using React, with classes and super(props, state and the "new" way with "hooks": "Classes can be reused by using higher-order components (HOCs) or render properties. Hooks came into use later and offer a simpler and more logical approach to writing components." So which style to use? I'm not keen on hooks because I like to contain things in classes - with hooks, everything is functions, from what I see. Blech.
The old way isn't the OOP way. The old way was using lifecycle methods. They tried the OOP way. The community rejected it. They moved to hooks. Hooks will be supercceded btw, but that's a different story for a different day. But, make no mistake the vast, vast majority of hardcore JS devs prefer a functional paradigm. Clearly you don't, so look inward if you hate change that much. 
That being said, there's absolutely nothing preventing you from using the OOP way Marc. It's still there. Come on Marc, do better than junior-type rants.
Marc Clifton wrote: And using React with third party components like jqxWidgets requires various components be "ref'd" because setting a specific state field appears to update all the state fields,
Do you blame Microsoft when a lousy app gets released on Windows? Why do you not have the same level of consideration here? Why the hypocrisy? Stop using jqx. React is the most popular framework for the web. There will be crappy libraries out there.
Marc Clifton wrote: And don't even get me started on using react-router which then requires (according to SO) that everything now be children of HashRouter instead of BrowserRouter which means hashes in the URL's.
Before I even begin here, just stop and think. Do you really think hashtags are required for all URLs? Really? Do a little more recon before ranting man. Dunno why all the angst. Your puppy bang its toe or something?
Jeremy Falcon
modified 7-Feb-24 12:26pm.
|
|
|
|
|
Jeremy Falcon wrote: Or any JS "CSS" framework that does more harm than good
I'll agree on you about avoiding things that do more harm than good. That's a fairly benign statement.
Jeremy Falcon wrote: devs will do anything to avoid learning CSS.
Do they, though?
I'm a strong proponent for using 'standard' frameworks, where 'standard' means 'what everyone else is using'. It's not because it's the best or fastest or most efficient, but because there's a huge amount of help for you and your junior dev, constant improvements and lots of eyeballs to spot issues (and hopefully a lot of pressure to get those issues addressed).
I use Bootstrap where I can. I don't particularly like it, but it's solid, stable, forces me to not overcomplicate things, and I know any dev can come along and muck around with it if they needed. Even so, I really, really need to understand CSS if I'm going to work with it safely and I'm still to this day learning stuff about CSS that I never imagined.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: Do they, though?
That's been my experience. A FE dev will claim to know CSS because they learned what a selector is, but then say specificity is complicated or JS CSS is better because it can be modularized (so can vanilla CSS, SCSS, etc.). They don't know when to use em vs rem, etc. Couldn't do a basic responsive layout. And sooooo many pixel values everywhere.
Chris Maunder wrote: I use Bootstrap where I can. I don't particularly like it, but it's solid, stable, forces me to not overcomplicate things, and I know any dev can come along and muck around with it if they needed. Even so, I really, really need to understand CSS if I'm going to work with it safely and I'm still to this day learning stuff about CSS that I never imagined.
I'm actually a fan of Bootstrap, as far as frameworks go. I'm a purest at heart, so in a perfect world I think cluttering up the DOM with declarative type class names everywhere is pure chaos, but IMO frameworks like Bootstrap are 1,000 times better than ones like Material. Bootstrap actually uses CSS where Material and the like have a JS execution layer that's inherently slower to render. It wants to turn CSS into JS... for zero gain.
And I totally agree there's a time and place for things, not reinvent the wheel, etc. Like with Bootstrap. I've used on projects and in some cases would recommend it. But, I do think a dev should know how to do things without a framework at all, for the enterprise. Because when something goes wrong and everyone's watching, home dude or dudette needs to debug.
Jeremy Falcon
|
|
|
|
|
Hah, thank you for the great response! I'm learning and given that SO is pretty much my only source for "why isn't this working", I'm bound to get bad information. I should probably take a course in React.
So again, thank you for pushing me to learn more!
|
|
|
|
|
Marc Clifton wrote: I'm bound to get bad information.
As much as I defend JS on CP, I gotta agree with you there. There's so much garbage info online. Way too much. Everybody and their grandmother uses JavaScript and claims to "experts". I'd probably feel the same way if starting fresh.
And don't get me wrong, React isn't perfect. For one, the library is large to include. For two, it does seem like crap changes every other release. And it's been proven there are quicker ways to render than the virtual DOM. But, it's still super-fast compared to most frameworks. And as far as frameworks goes, it's way more modular than Angular for instance, so you only have to use it for what you intend to... rendering. You don't to use the router for instance, if you don't like it. But, it's not perfect.
It will force you into thinking about breaking down everything into components though... moreso than a framework like Angular (I've only used old Angular though, maybe that's different now). Given native web components are a thing now though, that's not inherently bad.
Jeremy Falcon
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
