Slashdot Mirror
Things That Turbo Pascal Is Smaller Than
theodp writes "James Hague has compiled a short list of things that the circa-1986 Turbo Pascal 3 for MS-DOS is smaller than (chart). For starters, at 39,731 bytes, the entire Turbo Pascal 3.02 executable (compiler and IDE) makes it less than 1/4th the size of the image of the white iPhone 4S at apple.com (190,157 bytes), and less than 1/5th the size of the yahoo.com home page (219,583 bytes). Speaking of slim-and-trim software, Visicalc, the granddaddy of all spreadsheet software which celebrated its 32nd birthday this year, weighed in at a mere 29K."
When I think back to playing vast adventure games, like Below the Root, that amazingly fit on two sides of a 5.25" floppy, but the same game now would probably be written to take up a CD-ROM, even using the same graphics. Programmers have lost the ability to optimize.
Visicalc was the first killer app as well. I remember people coming into the store and asking for Visicalc computers not knowing it was a program that ran on an Apple II.
But under 'C' it felt somehow very natural and easy to understand, never had a problem with 'C' pointers, and data structures. R.I.P. DMR, your book really opened my eyes to the wonderful world of computing.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
Back in my day we had Basic running on a 2K altair. Kids these days don't know the meaning of a kilobyte.
Some drink at the fountain of knowledge. Others just gargle.
There was a time when you had to be very careful about the ram and the processing limitations.
You had to make sure you had enough space for your variables and make some weird stuff to get more done with less resources.
That's all gone now, hardware is relatively cheap so too little people care about optimizing the size of stuff.
Bytes are kind of weird. Can't they give these number in terms of Library of Congress?
More Twoson than Cupertino
First thing that comes to mind is: so what? This whole argument that smaller is better is crap. The reason that software is bigger these days is that it does more for you. How productive was the GUI for Turbo Pascal (it sucked), how good were the other tools that came with it (nonexistent), how fast were the release cycles (about the same as today). So with what people call bloat we get better tools that make us more productive thereby driving down the cost of software development.
Or to put it another way: if you really don't like bloat, when are you going to trade in your car and start driving to work in a hot wheels?
Why doesn't Slashdot ever get slashdotted?
Sure, these programs were small, but try to keep in perspective that they were leveraging the OS to get their compactness. It's kind of like saying a "Hello, World" GUI app is only 3 lines of code.... sure, 3 lines, plus 35 megs of library files running atop 1 gig of OS support. The .exe may only be 2k, but good luck getting that to do anything without serious support.
The ability and the need (programmers of embedded systems may be an exception).
That and dedicated TV games, which commonly use an architecture not unlike that of the Nintendo Entertainment System. New games are still being developed for the NES, and many are roughly the size of Turbo Pascal or smaller.
Good job. Posting obvious shit and getting on the main of Slashdot. I hope I'm not the only one who thinks this sort of comparison is absolutely pointless. Why are we even comparing executables to web pages or images?
Software grows to fill the available ram.
Code is always a tradeoff between codesize, development time and ram needed for execution. I'm fairly sure you can optimize code today to a point that would put those programs (which were optimized 'til they squeaked to squeeze out that last bit of performance) to shame, but why? What for? 30 years ago, needing a kilobyte of ram less was the make or break question. When drivers weighed in the 10kb range and you still calculated which ones you absolutely need to load for the programs you plan to run, where you turned off anything and everything to get those extra 2 kb to make the program run. Today, needing a few megabytes of ram more is no serious issue. And mostly because it just really doesn't matter anymore. Do you care whether that driver, that program, that tool needs a megabyte more to run? Do you cancel it because it does? No. Because it just doesn't matter.
We passed the point where "normal" people care about execution speed a while ago. Does it matter whether your spreadsheet needs 2 milliseconds longer to calculate the results? I mean, instead of 0.2 you now need 0.202 seconds, do you notice? Do you care? Today, you can waste processing time on animating cursors and create colorful file copy animations. Why bother with optimization?
Because, and that's the key here, optimizing code takes time. And that costs money. Why should anyone optimize code if there's really no need for it anymore? And it's not the "lazy programmers" or the studios that don't care about the customers. The customers don't care! And with good reason they don't. They do care about the program being delivered on time and for a reasonable price, but they don't care whether it needs a meg more of ram. Because it just friggin' doesn't matter anymore!
So yes, yes, programs back in the good ol' days were so much better organized and they used ram so much better, they had so much niftier tricks to conserve ram and processing time, but in the end, it just doesn't matter anymore today. You have more ram and processing power than your ordinary office program could ever use. Why bother with optimization?
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
In my first job, I was responsible for developing a programming environment for a Pascal-like language that included a visual editor, interpreter and debugger. I remember my boss showing up in my office and showing me an ad he had cooked up, with big, bold lettering saying "Runs in 256 kB!"
As a young developer, it was one of the tougher moments in my life to admit that we were going to need a full 512 kB.
It was difficult living in a world where Turbo Pascal ran comfortably on a 64 kB machine.
1024 bytes if you are sane
1000 bytes, if you are a drive maker.
10 - 20 years if you have an intent to distribute.
Whats its value in pico-Wales? And, if loaded onto a Kindle, how much would it increase the devices weight in Bulgarian Funbags? http://www.theregister.co.uk/2007/08/24/vulture_central_standards/
39,731 is the exact number of milliseconds it takes to lose interest in an Apple fanboi blog.
Join the Slashcott! Feb 10 thru Feb 17!
Name three things that Jackie Chan is smaller than.
Kim Kardashian's Marriage
Crazy. Even today I see review code where programmers have implemented exponential sorting algorithms. It's almost as if the existence of faster CPUs and larger memory has enticed some to be extremely lazy. But it's never enough for some. Example, my MacBook Air goes from "ding-chord!" to signed in and usable in about 15 seconds. For Windows 7 on the very same machine the number is about 3:30, including 30 seconds of watching a fucking white cursor blink on an otherwise black screen! What the hell is it trying to do?
Yes, it does stand to reason that something from 1986 is smaller than IMAGE files (yahoo's homepage, wiki's C++ page, PDFs, etc). That 256-bit color depth means we need 256 bits to define the colors after all.
Instead of comparing to PDFs, image files, and things written 30 years later, why not compare to contemporaries?
I would be tempted to call this s slashadvertisement, but they're not even advertising something. Where's the 'pointlesslyIdle' tag when we need it?
"Our goal each year should be to increase the number of goals we set for ourselves!"
Sorry, your post went a little south with the Vista debacle. Because MS had to fast track a recovery of a whole new architecture, the result was not optimized at all ... and netbooks got crushed. Windows 7 is more sensible because they did have time to snip out a lot of the junk code.
Currently we're disparaging the need for tight code, but give it one skipped cycle of Moore's law and suddenly the software side will have to take up the slack. Currently it's the mobile phones with their weaker processors that are preventing "dock your phone into a workstation shell" from being the universal desktop in your pocket.
I'd love it if someone managed to make a meme that Tight Code Stops Terrorists. Then watch the OS fly!
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
Loved TP back in the days, but marvelous as it was, was nothing compared with the miracle in few bytes that was Sidekick for DOS. Depending on how much things had into, was between 20 and 50k.
My second language was Turbo Pascal, after BASIC. I loved that language.. I was 12, trying to create games.. 320x200x256 raw graphics, stitched together with ASM. I actually created a photoshop type program to edited my "proprietary" raw image files.( I just added a larger header to regular raw graphics files) all in DOS with a Hyundai Super 286 AT 12Mhz 40 meg HD, 4 meg of ram and a 2400 baud modem.
Ad eundum quo nemo ante iit!
At 88,225 bytes, the image showing the comparison is also bigger. Oh the irony
ImageQuant was a c. 1986 scientific Windows 3.1 program for quantitative analysis of 2D images. It displayed 16-bit images in either grayscale or false color. Draw a box around any object and it could integrate the intensity within, subtracting the average background of the perimeter. You could draw a long box of any width and it would display the integrated intensities as a line graph, then you could graphically mark off each peak and it would integrate the intensities, with multiple choices for setting the baseline. Select any area of the graph, and it would expand to fill the window. It could also rotate the image. Not sure of the exact size, but it fit on a single floppy.
I think a more accurate comparison might be to ask why you need a Hummer to take your two kids to school when you can do it equally well in a Ford Focus which is half the size and probably 10 times as fuel efficient?
If there are in fact situations where one needs a Hummer or similar SUV, is it cheaper to fuel an SUV than to buy an additional small passenger car for trips that don't need the SUV?
> Kids these days don't know the meaning of a kilobyte.
Shouldn't that be a kibibyte?
Derive could do a lot of the symbolic math that Macsyma does as a single 5 1/4" floppy (360K?) DOS app in 1988. Awkward interface but useful for grad. physics.
Currently it's the mobile phones with their weaker processors that are preventing "dock your phone into a workstation shell" from being the universal desktop in your pocket.
Are you sure it's just the processor, or is it Apple's restrictions on what gets accepted into its App Store?
Back then, according to some random website I found (http://www.jcmit.com/memoryprice.htm), in Sep 1986, memory cost $190/MB meaning that "little executable" cost $7.55. Adjusted for inflation (http://dollartimes.com), that equates to $15.14 now. May not seem like alot, but that same $15.14 can now get you a 1GB stick of DDR3 RAM, which is way faster and probably orders of magnitude more RAM than any machine had back then.
And what did that 30k piece of software get you anyway? Probably not much useful...
And it's over 10 times as big as some of the graphical demos some people make nowadays!
For those who think programmers can't optimise anymore: check out the following video captures and try to remember that the programs that generated these video's are only 4 KB in size:
CDAK: http://www.youtube.com/watch?v=cjSJc2eCetE
Elevated: http://www.youtube.com/watch?v=_YWMGuh15nE
And a personal favorite of mine (although a massive 96 kb in size):
Debris: http://www.youtube.com/watch?v=wqu_IpkOYBg
Using less space on main storage allows the use of an SSD instead of an HDD. Using less RAM saves the energy that would be used to manufacture the RAM, along with the energy that would be used to manufacture a new computer if an application requires more RAM than the computer has slots for.
If you strip all of the video/audio/image/UI data out of most of these things, and compressed and/or compiled down to bytecode the web pages shown, it wouldn't be all that shockingly different.
Software quality has decreased due to programming languages that "make the programmers life easier" by "doing the hard things" for them.
-Memory allocation is hard, let java do it for you, at a price
-String comparison is hard, let java do it for you, at a price
-Graphics is hard, let java do it for you, at a price.
Java, it's thousands of "helper" libraries, classes, etc, all cause needless bloat.
Memory is "free" cpu cycles are "free and fast"..why bother choosing an appropriate sort/data model, simply let java/library X do it for you, at a small price.
Hint: lots of "small prices" quickly add up.
Only if you enjoy choking on penises.
No, it most certainly should not. That forced nomenclature is worse than what it ostensibly tries to solve.
It's the many, many little programs that litter your ram, from drivers for god knows what kind of freaky hardware you rarely if ever use, to "enhancements", and the omnipresent crud you get for free with every new Netbook.
Uninstalling unused programs helps, and it's the first thing I try when family members tell me a computer is running slow. But the fact remains that some programs won't run acceptably on a netbook or an old P4 PC even after I've uninstalled all that shit. I've seen applications fail to run because their forms are laid out for a monitor at least 768 pixels tall. I've seen Adobe Flash fail to keep up on Flash videos, and I've seen Firefox fail to keep up on HTML5 videos. I've seen native games fail to run because they aren't meant to scale down to the Dreamcast-class capability of an Intel GMA.
And because of its small size, Derive is still in use on TI-89 calculators.
Tell that to the developers of Rage (a game that comes on 3 DVDs) who manage to stream hundreds of megabytes of texture data at 60 frames per second.
Perhaps the point is that an art style that requires "stream[ing] hundreds of megabytes of texture data at 60 frames per second" isn't the only art style for a fun video game.
Yes. That is it.
Because all good phones are made by Apple.
There are no other decent companies that make phones or phone OSes.
Why is it so hard to only have politicians for a few years, then have them go away?
I remember using Turbo Pascal for my AI class - needed to write an Othello program. Originally wrote it on the CP/M version of Turbo Pascal, on a Coleco Adam - yes, a Coleco Adam. With dual cassette drives, dual disk drives and a parallel printer interface. Ported it over for final polish on the Zenith desktop PCs in the college lab. Professor gave me an A, couldn't beat the program.
Super Mario Bros. is 40 K. This means about 25 copies of it will fit in one M, and about 17,000 copies of it will fit in one CD.
That's what my friend and boss Wayne Holder said about Turbo Pascal when I demo'd it for him back when it first came out in the early 80s. It wasn't just that TP was vastly smaller than any other Pascal (C, FORTRAN, etc.) compiler out there, it's that it compiled much, much faster -- in some cases, an order or two of magnitude faster. ..bruce..
Bruce F. Webster (brucefwebster.com)
Are you sure it's just the processor, or is it Apple's restrictions on what gets accepted into its App Store?
[sneer] No, it's actually Google's plot to add advertising to your compiler. [/sneer] Apple isn't the only mobile phone around, y'know. Those don't do any better at being a workstation, and also have no "excuse" other than logical, realistic ones.
Geez, give the, "[BLANK] iz teh EEVUL!" partisan non-politics a rest and grind your axe elsewhere, 'kay? You could at least move it to a more fitting subject.
Turbo Pascal was pretty sweet, even though it came from Borland, and even if it was Pascal. It could compile 5,000 lines of code in the blink of the eye. Embedding assembly into it? No problem. It didn't care. The editor was supreme as well. Even when I stopped using TP, I still used the editor every day for a decade after the fact because it could do absolutely everything.
I'm not sure where all the hating is coming from, because TP did not generate hugely bloated executables. The only problem with it was that it eventually was discontinued, so special hacks like paspatch were required to patch TP compiled executables on the P II and higher to allow them to run.
It was actually closer to 512K with all of its dependencies, but it was damn fine.
My suspicion is/was that the RTL (run-time library) was hand-coded in assembly language and from .COM file sizes of stuff compiled with Turbo Pascal 3.0 that RTL ran maybe about 10-12K. That is, the Turbo Pascal image had the hand-coded RTL in the first 12 K of the image and the rest -- editor and Pascal compiler -- were written and compiled in Turbo Pascal and occupied the rest, which was about the size/scale of a simple editor and a Pascal compiler based on the complexity of source codes for those things that were "around." The cool thing, especially on dual floppy disk PCs, was that the 39K was everything, no overlays, no nothing else. The 12K RTL got plopped into the COM file compiled from your source codes.
The thing about it is that yeah, yeah, you had the limitations of Pascal, the Small memory model, 64K data segment, and Borland didn't even get the 8087 math coprocessor support right (inline instead of high-overhead function calls to a math library) until Turbo 4, which wasn't anywhere as kewl as Turbo 3 from the standpoint of compactness. But you could develop useful apps with this thing on a dual-floppy machine.
The other thing about this is the Pascal language. I had a conversation with a dude who was selling some 3rd party library for the Turbo Pascal ecosystem who expressed the view that hate the begin-end, hate the quirky use of semicolon as a statement "separator" instead of 'terminator", hate the bondage-and-discipline aspects (although the Turbo dialect of Pascal solved the fixed-length string problem and gave you enough overrides to the Pascal type safety to allow it to do anything C can), Pascal is the Ur Single-Pass Compiler language. I guess the Arch language of simple parsing at the expense of stupid looking source would be Lisp, but Pascal was close behind in terms of simple syntax and simple compiler implementations. Back in the day before we had Cray Y-MPs on our desk as we effectively do today, that compilation of large programs in the time of a sneeze instead of a long coffee break was a huge, huge productivity booster that made up for whatever people hated about Pascal.
So ol Nicky Wirth was a smart dude when he invented Pascal, and Anders Hejlsberg (Philippe Kahn was just the front man) was also a smart hacker in coming up with Turbo 3, and you have to give the man his propers in hackerdom. For what it is worth, Hejlsberg crossed over to the Dark Side and is credited as the Chief Architect behind the abortive Microsoft Java ecosystem J-somethingoranother from which came the good Visual Studio versions, C#, and all of that.
It had a smart-linker too. The executables were actually smaller than that of Turbo C. IIRC, TP's Hello World weighed in at 3-4K while TC's weighed in at around 6-7K, even with all the size optimizations on, using the tiny memory model. Turbo Basic's Hello World weighed in at around 30K!
Turbo Pascal 3 was really minimalistic. Turbo Pascal 4, then 5 were really useful, like a webpage in a browser vs. a wget.
5.5 added all that object crud that confused me at the time (yay for Software Engineering in college).
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
How about comparing it to XE2 (the latest version) .. and Lazarus/FreePascal
Hivemind harvest in progress..
What's "BRD"?
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
Apple isn't the only mobile phone around
There hasn't been any real Android-powered alternative to the iPod touch until last month when Samsung introduced the Galaxy Player.
Speaking of bloat, there's a humorously insightful article here about http://www.trygve.com/doomsday.html
Those WYSIWYG creators produce the most gawdawful code full of
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
"BOLD, revert, discuss cycle" refers to an editing process involving discussing each revert on an article's talk page. For example, if I were to make a good faith edit to "Turbo Pascal" on Wikipedia, and someone else disagreed with the edit and reverted it, I'd ask for an explanation of the revert on the talk page. But getting consensus for a change through this method takes a lot more time than newcomers are willing to put in (hence "babysit"), and one risks running into entrenched long-time editors who act like they own the article and use nitpicky interpretations of the policies and guidelines to rationalize reverting any edit not made by the article's unwritten "in-group" (hence "political BS").
Old PCs should run with software from the same era.
Unless said software from the same era either has security holes that will never be patched or doesn't do what monopolistic organizations (such as a government or the only bank in town) expect all user agent software to be capable of nowadays. Not everybody has the disposable cash to be buying a new computer per member of the household every two years. At what rate should people reasonably expect to have to replace their computer in order to continue to interact with the rest of the world?
For me Pascal syntax of pointers made more sense than C syntax. I started serious programming with Turbo/Borland Pascal and because the concept of pointers was so clear in Pascal, I was able to help my friends with their pointer problems in C. They had trouble understanding the concept of pointers, because C syntax was so confusing (eg. array and pointer are sometimes interchangeable, but sometimes they aren't).
I still sometimes use cdecl with complex definitions to make sure I have parsed/generated the C syntax correctly. However, pointer arithmetic was/is usually easier in C.
PowerBasic.
How? It resolves ambiguity.
Take a simple text editor from 10 years ago and compare it to a modern one. The modern one doesn't really do much more
The old editor supports only 8-bit encodings of left-to-right characters, which means English and a few other European languages. The new Pango-powered editor supports UTF-8, large character inventories, stacked diacritics, and bidirectional writing, which allows for every national language on the planet including Chinese, Arabic, and other official languages of emerging economies.
Turbo Pascal 3 may have been quite limited (I don't think I have ever used TP 3), but the later versions of Turbo/Borland Pascal were really good IMHO.
They were insanely fast compilers even though the computers were quite slow, had nice integrated profilers, had object oriented libraries for writing windowed UI:s, help/documentation was really good and typically included small example programs to demonstrate how to use some function, it was easy to use Pascal with assembly language etc.
I haven't seen as developer friendly system since Borland Pascal. It was really easy to start learning programming using Borland Pascal, but it wasn't any toy system as you could write also large and complex programs.
1984 Chevy Chevette is faster than a Ford Model T.
I worked at Borland back around then and Ander et al just lived and breathed assembly language. I remember going to one of Ander's demo's and he's setting up the computer and projector. Something didn't seem right to him. Next thing he's running debug staring at a hex dump, pokes in some hex, and saves.
Turbo Pascal and Turbo C/C++ were great app's.
Most appropriate response ever.
How? It resolves ambiguity.
It doesn't, because most people won't use a retarded name like 'kibibyte' or whatever the heck it is. So when Joe User says they have four gigabytes of RAM in their PC you still have to know that they mean four gigilobytes and not four billion bytes.
It's a dumb idea, the name sounds like some kind of metrosexual bar snack, and it's increased ambiguity because you no longer know what people mean when they say 'gigabyte'.
So, lets assume that means English words rather than 32 bit words. The rule-of-thumb for average word length is 5 characters, so lets say 6 to allow for a space or punctuation symbol.
That gives us 1000 words = 6000 characters = 6000 bytes of ASCII but, to be fair, that's wasting at least 1 bit per character, so you could easily reduce that to, say, 4000 bytes.
Now, 4000 bytes is 1333 pixels of 24 bit colour. Take the square root and that gives you a 36 x 36 pixel image, which gives you an image three-eighths of an inch square at the typical 96 ppi.
So, any image bigger than 3/8" square is officially a waste of space!
Ok, so you could use JPEG - but if you allow lossy compression for the picture yv gt t alw lssy cmpsn fr t wds 2.
In a survey of 100 programmers, 111111 thought that duck-typing was a good idea.
> Kids these days don't know the meaning of a kilobyte.
Shouldn't that be a kibibyte?
Kids these days don't know the meaning of that, either, but the reasons are different.
The road to tyranny has always been paved with claims of necessity.
The answer depends on the circumstances--total amount of driving, relative frequency of each sort of trip, availability of alternate means of transportation, etc. In New York neither makes sense--you take the subway or a taxi.
I live in a city of 300000 people in the Canadian prairies. Around here there's a tendency for a certain type of male to drive ludicrously large pickup trucks (F-350s and such) with gigantic fuel tanks in the bed. Originally this was because they worked in the oil fields and were driving out to well sites, but then I think it became a status symbol. As it stands, I suspect the majority of these vehicles will never leave pavement or haul anything more than a few sheets of drywall or plywood.
Posting because this piece of code deserves eternal Kudos:
1K ZX Chess
Full chess game implemented in 672 bytes.
"I bless every day that I continue to live, for every day is pure profit."
You didn't know what they meant before.
segment:offset
You'd place a premium on code size too, if you had to deal with concepts such as the code segment, UMA and HMA.
On CP/M there was no room for bloat. Not much room for bloat on MSDOS. For a couple years I ran CP/M parallel with MSDOS. Had a couple of "do everything" program disks. Slowly MSDOS came up to speed. Now we live in the age of bloatware. Easier to maintain and modify I guess, but it lacks the elegance and speed that once existed.
More often, they use languages which are not merely slow but outright retarded, though.
It's for sandboxing. A lot of environments commonly found on Internet-connected PCs discourage (IE 9's "not commonly downloaded") or even forbid (SRP/AppLocker) running downloaded executables, yet they allow SWF objects to execute in Flash Player.
Well, what if there's *multiple* users on that system
That's an important consideration for server software, but for desktop software (graphical interactive software that isn't web-based), how would each user be using the software at once? Most PCs don't allow for multiple keyboards and mice, one for each user, and dedicated X terminals aren't popular anymore either.
How the heck did they implement a grammar parser and lexer in 40k, let alone a compiler?!?!?
I suck as a programmer.
https://www.accountkiller.com/removal-requested
Old P4 motherboards can be usually be cheaply upgraded to 1 GiB or 2 GiB of RAM. Many P3 motherboards cannot, many maxing out at half a GiB, especially those made before SDRAM became DDR.
I learned Pascal first as well. I never had a problem with pointers. Perhaps you merely had trouble the first time (Pascal) you were introduced to the concept and it made more sense the second time (C) you were introduced to the concept. Look at the following code, do you really see some conceptual difference? Could it really be that you did not understand the nature of a variable, or the nature of memory in general? At the time I understood that a variable is just a location in memory, that memory held numbers, and that numbers could be program code, variable, screen data, etc.
:= 42;
Pascal
var p: ^integer;
new(p);
p^
C
int *p;
p = (int *) malloc(sizeof(p));
*p = 42;
There's a difference between ruthlessly efficient code that squeezes every last drop out of the hardware vs. relatively efficient code that's good enough vs. what the fuck were these people thinking ridonkulously inefficient code that has so much extraneous cruft in it that it that it strains cutting edge hardware for even mundane tasks.
I agree that the ridiculously inefficient code shouldn't be allowed, but I don't think that ruthless efficiency as in the days of old is actually worth it at this point - in the olden days it was cheaper to be super efficient because hardware was expensive, now it isn't.
That said, I think any developer worth their salt should at least be familiar with optimization techniques so that when new platforms with more limited power become available (smaller devices than phones, etc.) they can be efficient. But it's not something that is worth it by and large for the vast majority of uses out there today.
Since I can't tell them apart, I treat all ACs as the same person.
When it comes to desktops, laptops and even small sets of servers, I'm agreeing. BUT I'd posit tight code matters now MORE than it did then; it just doesn't matter so much in desktops (or laptops and even newish smart phones) much any more. There are a lot of price-sensitive micro-controller devices in this world. It can also matter, perversely, in really large server farms. If you need to update 10,000 machines, it's nice if the update is relatively small. As for efficiency: if you can get by with 9,000 machines instead of 10,00 machines...that's an optimization worth doing.
Here are more examples of pointer arithmetic using Pascal (extensions).
Did you strip that executable?
Yes. Stripping is implicit in conversion from .elf to the actual executable format of the target platform (.gba) using objcopy. So that's over 180,000 bytes for a minimal iostream program using GNU libstdc++, with strip, with -Wl,-gc-sections.
in the embedded world one tends to strip unused functions and debugging info to get the code size down.
So in embedded C++, what implementation of the C++ standard library tends to get used most often? I've been told GNU libstdc++ isn't the best choice in a size-sensitive static linking situation. Or maybe embedded programmers just tend to shun iostream; is that true?
How do you like them executables, I got her PE header!
Do you know why things have become so bloated?
1. Larger address spaces. That has nearly doubled code size. The 6502 used in the Apple II was 8-bit and could address only a 16bit space, 64K of memory. Instructions were much smaller. A 3 byte instruction (1 byte opcode plus a 2 byte address) could do a load/store anywhere in memory, and if that wasn't good enough, it had these "zero page" 2 byte instructions that accessed only the first 256 bytes of RAM. To do random access anywhere in a 32bit, 4G address space takes a 5 byte instruction. Now with RAM creeping over 4G, need even bigger addresses. The x86 architecture used this "segment" idea to work around it. A 32 bit address was split into 2 16 bit parts, with the high half in a "segment" register, and the low half in the instruction so that instructions could still be 3 bytes. But it was necessary to change segments constantly, so this idea didn't help much and sure made life rough for compiler designers. Borland C++ was notorious for bungling the handling of segments.
2. Bigger numbers. Used to have limits like 32767 all over the place on game scores, spread sheet cell numbers, and such. And there was the infamous Y2K bug. Now use of 32bit integers is standard, and 64bit integers are common. Doubles or quadruples the number of bytes needed for math.
3. GUIs. We went from terminal I/O with printf and friends to specifying dozens of options for window layouts, and keyboard and mouse event callbacks. Just dealing with typical resolutions forced the use of bigger numbers, as we went from 80x25 which fits in 1 byte each, to 640x480. Quite likely that some ancient terminal software cannot handle more than 256 columns. The big memory user is of course graphics. An XWindows "Hello World" program in xlib is insanely huge, at over 100 lines. Things have gotten better, but still nowhere near the 1 liner for terminal I/O. Even when a program can create a pop up window with one line of code, it still requires huge libraries.
4. Error checking and security. We don't live as dangerously as we used to. Can trim quite a bit of code if you don't check for buffer overruns, array bounds, numeric overflow, stack overflow, running out of memory, pointers out of range, etc.
And yes, less attention is given to memory usage. Not worth our time to sweat over a few bytes. But I wanted to point out that there are good reasons why code has increased in size, that it isn't all programmers being sloppy and wasteful. If Turbo Pascal 3 was recompiled for a 64bit machine, it would certainly be much larger than the original binary.
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
For some interesting minimal computing, check out the Countercomplex blog.
I'm not sure why Turbo Pascal gets such a bad wrap with people. This isn't Visual Basic we're talking about here. Some really successful games were written in it. Anyone remember Legend of the Red Dragon, and every other BBS door game Seth Able ever wrote? Turbo Pascal. Lots of BBS games were written in that, as a matter of fact, because there were some very good serial/modem handling libraries available, and the bounds checking of the language made it much more stable to run on such a platform. Oppositely, one of the more well-known BBS games to be written in C, Exitilus, was notorious for its buggy and unstable code.
After I learned C, there was no going back despite my fondness for Pascal. But it still formed the foundation of programming practices for me and surely countless other people. The integrated help was absolutely priceless to my learning, because I would sometimes just spend long periods reading through all the different entries and see how features could benefit what I write. I learned of I/O ports and direct memory access to hardware that way, which greatly improved my understanding of how computers worked at the time. Aside from the helpful built-in bounds checking (which I believe could even be disabled for efficiency), there wasn't much performance loss, particularly when you accessed hardware directly rather than go through graphics libraries. It could be as powerful of a language as you wanted it to be, while still simple and intuitive enough for somebody's first Hello World program.
I'll stop fawning over it on my way down memory lane now. But I still feel it's a shame that we're at a period in computing where learning the fundamentals of the hardware for a beginner is completely lost under a spiderweb of APIs.
If someone says "gigabyte" you still don't know for certain if they mean the SI or the binary nomenclature. Similarly, apart from the binary nomenclature sounding like Del Monte dog snacks, it is esoteric enough in many settings that you still need clarification before you can trust that the person who said it really knew the difference and didn't just copy the notation from somewhere else without really understanding it. Had they laid all this out from the start it would have been great but the old system is so entrenched getting people to abandon it would be like asking people to stop calling expanded polystyrene Styrofoam. I treat both forms as ambiguous and in situations where it matters I'll still ask for the value in bytes before I allocate or access a buffer of that size.
Account -> Discussions -> Disable Sigs
Borland Turbo C.
Don't know what it's overhead was, didn't matter, it did the job i needed.
And anyways, we are talking about DOS programs comparing them to modern Windows programs.
You have a UI and other crap built in with Windows that you had to do yourself in Turbo Pascal/C.
Memory managment? I know Turbo C didn't do it, so I doubt very much Turbo Pascal did.
ya, it had a smaller footprint, but it didn't have to do as much, unless you programmed it in.
But I do agree alot of software is pure bloat these days, and I figure it's because the dev's don't care. They got 16gb in their machines and they expect everyone else to be like them.
Be seeing you...
You can do sandboxing a whole lot faster than that 5-6 orders of magnitude slower than native.
And that's what Google Native Client is supposed to do. But I don't see it spreading anywhere outside Chrome, especially not to corporate-standard Internet Explorer.
A lot of people are saying "I would fire the guy who writes his own x function". That is sort of a valid statement, but you have to consider that is also 99% of the problem with bloat. Say for example I want to md5 something. I could pull in a basic MD5 algorithm, slow but functional in a few hundred bytes. Want it faster? Then add some tables. Or you can just go with the really fast one built into openssl. The problem is you just pulled in another 1M+ of code you have no need for. Sure demand paging then turn around and removes it, but the page table entries, linker fixups, etc are still being created. Multiply that by a hundred or so libraries any non trivial application is using and, pretty soon your looking at a base VM size of a few tens or hundreds of MB.
There is also a lot of hidden functionality in applications today. Consider Unicode capable string functions, network communications code, etc. This is part of the joy of phone/tablet development. You can create an application without all the crap and get away with it.
Turbo Pascal was among the first languages/systems I ever coded in. Stunningly fast and capable in an age where Microsoft didn't have a clue, Borland went on from this to produce the Turbo Pascal for Mac (apparently now written out of Mac history - most people don't even know it existed, left Apple in its dust) which was similarly blindingly fast, Pascal for Windows (first Windows system I ever coded on, far better than the Microsoft offerings) and finally Delphi which wiped the floor of anything Microsoft produced on Windows for a decade - Visual Basic was truly pathetic in comparison.
But somewhere around Delphi 2 or 3 Borland started to loose its way. Sure it continued to be good up until Delphi 7 despite Microsoft progressively catching up, but then came the 'we don't want to be a software development company' fiasco of 'look we're Inprise, or look we're Borland again, oh look we want to sell **anything** but the best thing we ever produced'.
True Embarcadero do seem to have rescued Delphi somewhat, and it will probably have some sort of ongoing future, But back in he day Borland nearly owned the development space, and it though it away because it took it's eye off the ball and its vision faltered. Simply a tragedy.
On my (still working) 6809 GIMIX system:
I have almost a thousand programs on that system, including cross assemblers, languages, etc... it's very rare when one is larger than 16k. And that machine ROCKS. That's because the 6809 was hands-down the best 8 bit bus CPU ever crafted, and the GIMIX frame, with everything from motherboard to power connectors and sockets gold-plated, ferro-resonant power supply, awesome steel case... probably won't die in my lifetime.
Even if it does, I wrote a complete 6809/OS emulation (with permission from the OS authors and GIMIX themselves) and have all that software running on modern hardware, too, even the graphics. Fond memories. I developed a lot of hardware and software on that machine, particularly early arcade systems for Centuri, Bally-Midway, Arcade Engineering and Techstar, as well as early SSTV software for amateur radio. Those were fun days!
I've fallen off your lawn, and I can't get up.
By the way Turbo Pascal 3.02 is now free and available:
https://downloads.embarcadero.com/free/turbopascal
There's a lot of nostalgia in these postings (and on many similar threads) for something about programming that has been lost. Some of the nostalgia is for how hard we had to hurt ourselves to do anything back then, but I don't think that's the whole of the story. Nor do I think this is about size per se. I think something has been lost since the good old days of programming, and it may be more than one thing. I think maybe something has gone wrong.
I taught myself C from the blue-and-white book. (Did you know it levitates, if read by candlelight?) I had one of the original Compaqs with 256K of memory and two floppy drives (hard drives were a year or so in the future). I used the Lattice C compiler. I remember that I set aside 64K as a RAM disk...I think I used it to compile, and that when I really got going, I was swapping out three floppies constantly (it helped to hold one in my teeth). WordStar was my program editor. Heck, I even wrote one of those Mandelbrot image generators that Scientific American published the algorithm for back in the (late?) 80s. The joke was that the Compaq had a small greyscale monitor (actually green-scale)—and the whole point was to create an image with lots of pretty colors, but heck I had fun doing it. It ran for a week to generate one image.
One of the contrasts between the original C language and something like Java, or C++ is that C wasn't simple, but it was elegant. This is not a word you can even use in the same sentence with any of the names of the more recently developed languages. It's important to note that the relative modernity or antiquity of the language in question doesn't really have anything to do with it. For example, BASIC was never elegant, and there were software development environments that resembled straitjackets back in the 70s and 80s too: they were called "IBM shops". So why have we come full circle, and put the straitjackets back on programmers?
The answer I've gotten is that you simply can't have an artful programming environment when you're working on huge software projects: the demands of such projects require a strictly disciplined environment, and languages that take away all the sharp knives that coders could use to cut themselves—or others. Maybe that's so. But how many huge programming projects are successful? Why is there a constant flow of new languages and new programming methods (we could call them "fads")? Maybe people sense that we've gone wrong; if so, they may be looking in the wrong places for solutions.
Great men are almost always bad men--Lord Acton's Corollary
Ha, touch on 32 bit Ubuntu 11.10 is *ONLY* 42,552 bytes!!!
Faster, smaller code, way less bugs than Java. Granted no objects and the like. But it disappoints the hell out of me when I use Java, I don't get the speed or interface consistency that Sun touted so highly, and I get huge stack traces that are mostly useless. And in the end, programmers today have little clue what is actually happening under the covers- not just under Java's covers, but in the assembly code that makes the slow magic happen. And I won't event mention .NET...
Professor McCloud. What a great guy. Retired after my semester with him. He had a stack of manuals that went up to the ceiling. I was impressed. We had a nursing student in out class, and we all cracked up one day when she asked the equivocal word question : "What does 'invalid command' mean ?"
No, it most certainly should not. That forced nomenclature is worse than what it ostensibly tries to solve.
Forced nomenclature? You think everyone just up and decided that kilometer should mean 1,000 meters? All measurements are "forced nomenclature". You don't get to choose how much a meter is, and if 1,000 meters should be called a "hapimeter", so what does it matter if 1,000 meters is a kilometer, and 1,024 meters is a kibimeter? They're both arbitrary words that are both equally "forced nomenclature".
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Trust me, anyone pedantic enough to use binary prefix notation, will know what it means, and use it correctly.
How do I know this? Precisely for the reason you complain about: they sound silly using it.
WARNING! This girl exceeds the MAXIMUM SAFE standards established by the FDA for BRATTINESS
Most of my powerbasic apps are build like a tiny exe (around 600k) launcher and many tiny dll plugins (from 300 to 800k)
Most of them are xcopy/portable also.
Now a days software its so bloated, that even vb6 its light and faster. A couple of clients doesnt want to let go their big custom inhouse Thundervb/ASM coded apps ( sourceforge.net/projects/thundervb ); and other one is reworking their all ready wine running one, using datenhaus runtime ( www.thecommon.net )
..your momma.
I agree that the ridiculously inefficient code shouldn't be allowed, but I don't think that ruthless efficiency as in the days of old is actually worth it at this point - in the olden days it was cheaper to be super efficient because hardware was expensive, now it isn't.
What's more, a lot of that old "squeezing the last drop out of the hardware" stuff really meant exploiting tricks that would barely enable you to get the job done by the skin of your teeth, and everybody would marvel that you got it done at all. Those wow-factor programs amaze people with what they can do, but in the world of real software they're a problem because they are usually not in the slightest bit portable. And you don't even need to want to port to a different OS to want your software to be portable; what about when Macs switched from PowerPC to Intel? What about any incremental hardware improvement that obviates the need for your "squeezing the last drop" tricks? Outside the realm of embedded systems, which often don't/can't get upgraded, there really isn't much need for this kind of coding anymore. It should usually be discouraged, in fact.
Breakfast served all day!
Another long list:
Things slower than Lightspeed Pascal
Not a joke. It was instantaneous linking and compiling IIRC.
I grew up with Turbo Pascal 3.01, in fact used only that from 1986 (when I was 9) until 1994 (when I finally got a "proper" PC);-) The idea that the entire development environment could easily fit on a 5.25" floppy was so awesome. Fully integrated, complete, fast, it was just fucking perfect.
Turbo Pascal brings together all the things that make software development awesome. Freedom, power, efficiency, elegancy, completeness. It was the culmination of Software Engineering and that made it a huge factor in me choosing to study Computer Science. Which was a good choice;-)
Unfortunately, there's not much available nowadays that equally elegant and awesome. It's all bloated crap now and the actual hardware it hidden behind an restrictive Operating System. So sad. Tonight, I'm going to dig up a 5.25" drive, find a floppy with Turbo Pascal on it and I'm going to create something awesome.
^KD
0x or or snor perron?!
"What's more, a lot of that old "squeezing the last drop out of the hardware" stuff really meant exploiting tricks that would barely enable you to get the job done by the skin of your teeth, and everybody would marvel that you got it done at all. Those wow-factor programs amaze people with what they can do, ..."
There's something sad here - the old Wow Factor got me interested in computers, "back when it was all fresh and new". Maybe the modern software houses took over, it's been some time since I heard a Wow-type comment about new software. It's almost like all the delighted young hackers grew up and are burning out in their 40's at dull jobs.
Maybe if we looked again at topics that were indeed too hard 25 years ago, but this time we applied some Wow, we might get AI. - That is, if we want it.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
Some people would still actually need them
If everybody who needs an SUV less often than once a fortnight stopped buying SUVs, automakers would probably use this as an opportunity to charge double because they would become a niche product not as subject to mass market price competition.
I think the change came about because, back then, you could have a single individual do some really neat (and useful) stuff that would push the limited hardware beyond its limits. You also had nowhere near the number of people working on stuff then as you do now, so it was more possible for something really amazing to stand out rather than get lost in the crowd.
Nowadays it takes a team to design neat and practical stuff that has the potential to come anywhere near the limits of the hardware. For things a single individual or small group could make that would push the limits, like improved search algorithms or whatever, they wouldn't just be "neat tricks" but absolutely ground breaking.
For my money, I think the next area with real wow factor potential is going to be fabrication/3d printing. There are some really neat tricks going on - like printers capable of making most of the components necessary to build a copy of themselves, printers making organ tissue, food, circuits, etc. Some of those are really REALLY neat.
Since I can't tell them apart, I treat all ACs as the same person.
Uhm. Good points, especially relative to Unicode, and especially on least-significant-byte-first systems like Linux on x86, or like MSWindows.
But, ...
Unicode is a kludge. A great kludge, and better than any available alternative, but a kludge nonetheless. So Unicode and UTF-8 or UTF-16 are not reasons for mpt considering characters to be integers.
One of these days we're going to wake up and realize that integers on a least-significant-byte-first CPU/run-time are not integers, and that is the other practical reason for trying to hide the encryption points from their integer representation.
True, characters are not 8 or 16 bit integers, and the "char" type in C, with it's tradition of byteness, is a misnomer. (wide char is not much of an improvement, in no small part because of the silliness with the initial implementations of Unicode being 16 bit encoding points.)
But encoding points are integers. Integral values, if you must, but they can be treated as integers, which is very fortunate, because we would not be able to use computers to work with characters otherwise.
Yeah, we use basic arithmetic in our libraries, because trying to use straight, linear character classification tables for Unicode would tend to cause cache thrashing in a serious way. (Not that table lookup is anything other than arithmetic.)
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
Or, in other words, sandboxed users. ... allow you to go digging around for answers in websites that pop those ridiculous smiley ads and warnings about your "Windows" being full of "viruses" and such in your face.
Computer memory is just fancy paper, CPUs just fancy pens with fancy erasers; the 'net is just a fancy backyard fence.
that means it's smaller than my pecker
GNU Pascal makes very fat and slow binaries. And its not really compatible with turbo pascal.
Good there is freepascal, which is much better and more compatible.
One of the few things, where i wonder why GNU fucks up so hard.
And this has exactly what to do with mobile phones?
And this has exactly what to do with mobile phones?
Not all mobile devices are phones. I was speaking of mobile devices running smartphone operating systems in general, not just those that happen to be phones.