|
honey the codewitch wrote: In that time, computers have changed some, but software has changed a lot.
I beg to differ: in that time span CPU speed went up by a factor of at least 500, memory size by about 50 (remember "640k should be enough for everyone"), disk size by a good 1000. And that's not mentioning multi-cores, display size and resolution, data transmission speeds and so on.
I cannot see any changes of that magnitude in software. Software bloat was made possible by the spectacular improvements made by our colleagues on the hardware side of the street.
Mircea
|
|
|
|
|
Yeah but it's not new. Same transistor arrays, just biggerBetterFasterMore
Real programmers use butterflies
|
|
|
|
|
Software is not new either - same control structures spinned in a slightly different way. Functional programming is all the rage now but LISP was created in the '60es. When I started programming (late '70es, early '80es) artificial intelligence was right around the corner. Seems it stayed there all these years.
Mircea
|
|
|
|
|
Fair enough, but functional programming has evolved quite a bit since LISP, what with monads and the like.
Real programmers use butterflies
|
|
|
|
|
You're both right. Neither has truly made significant advances.
Hardware is just faster/cheaper/denser, not improved per se. Multicore is the worst thing ever to happen to software, period. The hardware boys having fun at the expense of software boys who should know better.
I wrote a recursive descent parser in Simula, in 1979, for an Algol subset. The fact that I can write one for most of C++ today mostly has to do with the hardware not taking a day to run it and the fact that I've gotten better at large software projects. But it's hardly a sea change.
I won't even mention the advances in software quality that have led to exhortations for "stateless programming", where bedwetters write every one of their transactions to disk.
modified 31-May-20 20:04pm.
|
|
|
|
|
Greg Utas wrote: I wrote a recursive descent parser in Simula, in 1979, for an Algol subset. Wow !
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Because I couldn't do the necessary FIRST and FOLLOW nonsense.
|
|
|
|
|
Interesting, LISP was my first high-level language; but, how do you equate that with "functional programming" of today ?
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
I'd say it was maybe the father of functional programming. It didn't have constructs like monads, but other than that it was pretty much the standard in functional programming for its day (i don't think it was called functional programming back then though)
Personally, I find that Lisp is adequately described as "Lost In Silly Parentheses" - I'm no fan of the syntax, but all of the fundamentals of functional programming are there. It's just rough around the edges for lack of some of the more modern constructs like monads
Real programmers use butterflies
|
|
|
|
|
Mircea Neacsu wrote: Software bloat was made possible by the spectacular improvements made by our colleagues on the hardware side of the street. The image comes to my mind of using laser-controlled diamond drills to engrave happy-faces on ever swollen piles of mud.
okay, maybe I haven't enough caffeine, yet
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
BillWoodruff wrote: using laser-controlled diamond drills to engrave happy-faces on ever swollen piles of mud You don't need --the analogy makes the point well and is
|
|
|
|
|
BillWoodruff wrote: or file searching I use an at least 12 year old program 'Agent Ransack,' that has always put the execrable Win OS to shame. Me too.
/ravi
|
|
|
|
|
I started professionally in 1980 and still love assembler or even pascal, though I don't use it much now days.
Finding IDEs more and more frustrating with their bugs and semantics.
It all seems to have dampened the creative side of the challenge.
Bloated, badly written libs rule now. Copy and past every where I look.
Oh well I am a dinosaur.
|
|
|
|
|
One thing is certain, the size of software grew with at least the same speed as that of the hardware, and not always for the best
The first Algol 60 compiler I wrote (yes, using my own parser generator) ran in less than 16 K on a 32K PDP-11 (early 70-ies), it was written in BCPL. No "fancy" stuff like IDE's that think they know what you want, just a simple editor (cannot remember the name of the editor, it was probably something like ed on RT-11, well before Unix came)
Nearly 20 years ago (I did professionally nothing with computers at that time), I wrote
in spare time an Algol 60 -> C translator, it still runs but the executable takes over 700 KByte (I know the size is nothing compared to that of a C compiler).
The current application I am working on (hobby, something with SDR) when packed as a Windows installer takes nearly 60 Mbyte, without dll's it takes 13 MByte) although I must admit that the signal processing (2048000 samples/second, with app an FFT per msec could not have been done on a PDP-11), but the size increase of applications is dramatically
Wrt quality: In the 70-ties there was this belief that - on average - each 100 lines of source code would contain (at least) an error, I belief that currently that is worse, imagine then a 100 times larger program .....
I do not deal with IDE's, they think they know what I want, and if I try to express that do not want it they more or less enforce it on me.
Actually, for me that is the main reason not to try a language like C# since there does not
seem to be single a tutorial that describes the language without forcing you to install some crappy IDE. When programming, I want to be in full control, so separate editors, compilers, debuggers is what I need, and therefore I'll stay with Linux.
But of course that is different from using the computer as administrative vehicle, then I want indeed to say things like:
find me my wedding photos, call the plumber to repair the faucet in the bathroom
|
|
|
|
|
94133
That's the number of 3rd party (npm) files nobody knows why we have them in our project... (we have a clue about ten thousand, so we know 10%)...
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
'npm' stands for 'naughty polyunsaturated mess'; so that's not really a surprise
"Five fruits and vegetables a day? What a joke!
Personally, after the third watermelon, I'm full."
|
|
|
|
|
~10,000 known, presumably benign (or maybe actually useful!)
~10,000 are for data analytics
~15,000 are for bots (general purpose)
~20,000 are for Bitcoin miners
~40,000 are for pr0n servers
~95,000 Total
Does that answer your question?
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Daniel Pfeffer wrote: ~40,000 are for pr0n servers You gotta pump those numbers up, those are rookie numbers!
|
|
|
|
|
dll hell replaced by npm hell....i'm waiting for ai to handle my coding...
Caveat Emptor.
"Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
|
|
|
|
|
I work in a different world, but I occasionally notice some bloat in the code so I start removing dependencies and watch what happens. It can be a useful exercise since it shows you who needs what and usually makes me wonder if I really need those things. Sometimes it leads me to split things up and that is often useful.
"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?"
|
|
|
|
|
back in my programming time, i would sometime remove all inclusion to dependencies and check which were really necessary to compile. Not sure how that works with js though.
|
|
|
|
|
start deleting and see what breaks. Then add them back in as it errors out.
To err is human to really mess up you need a computer
|
|
|
|
|
rnbergren wrote: start deleting and see what breaks I'm not a web programmer, but isn't that rather difficult, given that Javascript isn't compiled and statically linked? I would think you would therefore need to have a full-coverage test suite guaranteed to exercise all dependencies in your code, recursively through the dependencies' code, to ensure that you had everything you needed.
Software Zen: delete this;
|
|
|
|
|
needed time in a bottle (5)
|
|
|
|
|
needed
time T
in a
bottle VI AL VITAL
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|