[Challenge] How cold is 4096 bytes? / Hackathon

What can you make happen on a computer with 4096 bytes
or 4096 letters/numbers?

Here is what some group did … this is the screen capture of a program running that is only 4096 bytes in size, complete with all the visuals and music/sounds.

And here are the bytes (in hex)

4D5A3230504500004C01000001DB617F10D017737547EBF9080002000B0111C94585C0791F01D350F7E2903D5C000000F7F339C119DBEB480000400004000000040000000FA32D850140008D0400EBCE00000000EBB68812400000005331EDBB0200000090BE540140006A0158BF00004200B1009057EB1200000000000000005A72079229D1040029D060AD01F8742C6A0A5A89145489542410AD31ED4D4501C072FB74AF60AC88C232076BC06F028700000000484F00D272EF75F9BF512B4200B903F9AF04730CF366AB0A06618D76157BB7C3F7F18D3C5789E931C0AE74040007750241410FB61407D3E201548434487AF385DB7F0DD02C1F7503D0141FF7D3FE041F6146EB95E86AA638C66F82E9CC0E82F860F859DE1B13094FA834A419F3B1DF7A2B622B6FCB0F6E6011369FED583A65CBA111556AD67546824E57C329303A8774870D19E81771224384D6729D96FCADCAE4F5BDFFFE5F49442000406080A090C06CCAD4BC9FAFD4BDFF7E1148084030220500A044288090C09C55A37399E0EBD7FE447EFFED9399DF8C1DFD02B7CCAB78B2955FF3B459E080B9A5B0F05AE72CFE3EE3EC7AB2149E6820281348B94903821DAF812A3FA70C9F8A3D78557E64CED44C8C20C50F9CF3E231857316A6E22BBBC2A0D1D777D8B94391349FA25632B807FD034123AA666C4C674BCA53ECC16336978ED9D8BDBC7EE94C8D7AB49F9D3E2359B294D61721801183B3F0D02C4A90D99BA5BA758E5DCECC18529645319C22D7F1083EDE6A160C326A06EA1B694D6799BD93205FD9A76785F1ECB36FBECC249568D0C2562A2FD65B211B86F418351F8AC6BC474810EC934CE716CD63293B5E252D8D9BEEEC5B6C9448343116376A92E0AEDC949F108BBBA59832EDA7716540BFB5350AB1F093164BFB5007253C3A5C53ABA22D7F351BD5CAC5B7A65A0A2A9AF1D93B8DDB60DBCABC6B4A1557020AD30D1313687E9A2DE868F84511D916A4EC1C388599EEDB775CFB8859D5AD3852AEEF7A34DF0664E1C1B313ED1AF5E7D4BBE0710C8E98F5791B0406F46BA28BB7190FB71B94F49D01D8F4AC12AD80C75D6D1B62A2F04759A650579AF0585EE3F1A50F688A359CA06D2D9FD152E6E593EA672780EC8B654C632167E9A9D2AD5ABA61EB6B1F06D84FE4565F7CFE30DD6990DCD0E33FA2C6B88CC9254C39FD66E8B46C77DD6A548F9BCBB8F5F7BE762798E10A0EA59394B0C0DEE8A888467ADA9345A496DDFE8D0F1ABA8DD068CE0F3FA276E8495D984184BD844A1F55EE2D6B55C6F8A2FCF11678005E5ECC6A0FDCD4C917055B4837A0FFF5DCC63022AFB628165414598C6FAC5DBBA3CB5C4027140959290402AC5D1403DA5D5EDA24302208B2CB5952237AFA2C7B423F0B975C8683EB647669EEE91741B2188AF675690FF93DEF15E4490D9ADEEE10E0EB067822578B92CDA6F306D9F9FCCD47803E685DDA5866E21FFA45D8BCD663E5BB66C19132CD5275B4E964363F462FDE96DE0F004397AF9C483072B10E86D3B714E024CA28C9CD7E72169F0E429F04089A0C74688E0E2DA19A277880854520DAAB2F4DD9F1C4329A41D1233F748834497F2298F4BE74F2EAF01D0B729949345380A1CFA956946CE8EBFC1E8BABE9DC85806B12889B59A91B037EA2AF30B273F4BA60F405B45EF528A7AAC139BEBD8EAAE14B8F265209E4DF3C35867CCBA33ACD121EACBDA93DDE54A48610A9446860B052EB7E4883D01DDCC53BFB5F8D75595C770B00EAEA5627F4F4CF1650859BBCAE43EBF494870370342D977C3F91AF841F419FEC542CF70EE2D8ED7E991EAAF64FE9118FE0D0BCCC65FD397B4B989377CFF5D2EDD46EA62F4A6A4E55668C9F2CE47DFB939996DF81EA3766A6F660EE6BECFFE3CA2E387114B01402E38D75A9CA07EFD7904E7E37BFB182DB3E63993C4C456EAE5254FFEAA46FF9CCF409241FE0B9A10F01803B0AD735437EE0A37E466831F6106DBC96244E174D18907DB46819082072696E16907B071A1FD3EA60EA304DF33C197346D7800D8CD8433B63AFB5F5D439BF71F8CC32CC63D5BF430BD4354C36DBB75B6301EEC42332DC59C39218A7ADAC47D21764346BFE31CDFD1843FC2E0E3176C91B05455AF1DE8022120796909D904CAB43CBA5B4BDFEFD06E8E0FBAE2C9719144899F0E76106FE7E14CF810C9D5E519AB41DC58E207B2B89CB7867E33F486577739B361940D4F5EF219A2C5181984639F29C7AC066326A4C2594227B8C9D1E620C7770871B88A2A451EE1ED5F028E99996126CB93D3A776E25722F51F377C73F4B4F8087A72C57F1A5945D31F03CE32AC30193BF0019BBF8ED95B110A164D648A27AE1E95C7F368ED46485A260558099364D433EAF238399C65C6B29D664DEFA30C7289928A88B84BD952B1CDAACFCDFB7E2F6B5B647EBDACA4EEA03966BC04D0988C2F82D2D4EDC6F530E072B6138CA9BC1AA22B399F3E9F1143F742E4DBAB5D2BC25B57258254606A8B6DE7EB78CDD2B39283CB5F6282E04847B4AA80765725439C1D750C5E4480E9DA8C792C4A87AEA2B9B795C0B433D1478B83AB342F30B77AECE175A69D42F770F68DB88FBE374C5BF363849B3C57E55FA0B3C99C71A2276F54715BC2C970A28A1D2E8B9D3593E0E2459B44B827A7A007ABE5E69EEB21EC01A27713E6D628FAD46CA5682A896D19D72AEF7D48D3B0863A4F57E41AB095D0111D1FE7F1015576B5C6D7BC9D3EE910B4BFA2C5D41EE4C5B88869190B9CC71054E102D83EF353DC4624D4323D7566B2AA2A7665A86D9F7C71D113A7BA6EE4E469B420A285B4D9171DA145339DED8109C85CF23699F8782670D66EE9C119532D03DB9435225F50935CA6BB397853C4C57D154A377EF2D31F7DC9E03001F701C708E8A0B4B5696F8C67DAA99845A87A39D7A3CA918C59843125626792A64D513883E27418AEC4D14923C4A0B2F04708025AB924267EE0A9C7B9A2BE90A3EBFE952D40A2BDDD3C14A5EDF72EBA747AF14FD98835A21A7498AAB2A70D24D9C39BC30B3A2E6710AA8F867459608BF62B81B8AEAE55C8E602EE40BA8A2AF7E0928DDC9F7D5D5D3106693BA38CE4165C190C70FCD71E4FCB5A08DEA30DD6FD5E18CC1E3E68A3C215EF0FA801F27217A1D8266D7FAD145AF731BC9DD6FF9393AC3D9CB7236926D7BDB696EC892F6811B1E0A61AFDA851E2DCED95005A31C7238D679B7501B2ED1A18DE302CBD7F2CBD66AA935E9282824BEF279FA6F4FFB7A38526910943AA3684116DC71438035381DF8F123AE64C08A6F375D4E9F1FE0DFD3B41DBD1E30D4004E0634219A1E4D5C7F605B9E9D4779275A826C1CB282B47EE461095B8993601BF1AD25EC985E4026EE05A98DAD7FD6F426A373529C63F06CFED8252AA71175E4D500A3DB549439B521242BAA060591A1542FD17637D6DAA44C67335DDC74143B305FE6C7E5BEE1F4B105A5A6AF4BFE3E4369475FC60D51FC5BE866D626E780FBD10C1C3E33E4590F2AF02B35038DE9FA9DD5C0B51A07F1B6EDB77151DC6DB5C7164FFB17F1AE280B293D85E0E2FDCE6DC8F4B59110ED8A68FDF0006493857F6BF720603B03BA3CD40EE8D25FFBD42CB8441C3092D0733F5BC40A7B9135940403A5BE09721C9BABDBCEC101AF1EFE1266A486084087C00A61EA45ADBC7BD668FB1A40980687C2F807478B1EB4BF76DDB54B3F4A56EC04FBF7465C78C260894446B7FC592D80D923781ED82C7AC8DC5313CDED506B72094F712FE582843502F9C956955CD07813205A1C6E9E74C6CC8552CAA1EEF793E5A83B0289D2061C2BA7EE0E522CE02C02F79BB4B3735F9940C7A4411B9D071DCBFCB6D82BDA654DEDAD8AFCE9F79F105A45A85C8055BDCEEC20B13C0438F430313ABE874888FB1D77C41E7C8590F8254A75D631824F00DEC346301132FB7D3B5D2380B6772F1BCBA04122D0D46A905210E524FC7C61B15E6152E5A8DBBEE56A897C9C8AE8C89221B3209F1E1E0030E29486A2EC4E2CD395568783BA14B2AB0A468692CE4BC4A87529CFB182DED11F63592B9278C11F20F507D47328F7409BA3D365D5847E36108D4466C8E4C75C6165D1969DB5C52356F686DB2B58AB89857ABF9B79676D1CF853DB9D4176E80C639D3557FF8CB2CF8F989323281E830F09F364BAAFD0AEFBEC1FE3CEC81AEAAF8077DE4BC02FFE1E5D0154B57D9A45892EA8C034227B6135BDC1B9872B86A2553B1A045BCB76067E5897C7E6B97E88059E7F2832CEEBC6E50E1B17190B6F12DC67BF6B0703BEEE0D729B5E8EE09F6EBE5E4B31EE860568A109CB1BCBC830E70F73871444B551F7057F5B4B02FC0EA0E474618876A7F75C87521307CF989E35AA5592EB0B04B4211206196F3C8430EDF6F8961C7012D1F92873540E25B2B1C0E1BCCF782829245DD61F4D0FC7C14BEB6E2103DBD052E5E6A7A152B2B279835C56D3D18EB381CC06E2BE06308EE9335CCB90CADE2C5A561523E27636837975BD58A197E4FBF00537A29091ED0B22B7CE766BB7503DCD44704671B123CBCD533EDAAF39B805F5C0E331BFEBDBCE12E59B5B58372E6E05B1CCAA94B81C67A4CB10A6734048E44124BCFFCF57BD7921F6E3F0FF2C7135548B6F457AF8B60AD20F1A613EDF03294E831CFB2B57DD73132460A69732695B861043AD63E4D5AAF11A905B069DBB80837A422DABBD8503D270915736E2EA3E70B799356D5464D4AA2C3EE96584F8E22C595DDB062635A95508A3A99273EB9958A06EE42644D9AC8AFCB557BA03CAB78E7A826B2EEFE58249A36772A0C39387FF652EFBFB3C5F946AF966A7D7A6B048CCA9F0901953B23E127916CFF912934FD2AA4D7B036F051C47FDA3AE1906C3A61CB75DBB2F8E121E662EA49FE4DD2C0F5C0C1A6FC4FDC66BEF1BB07B5FAAE32149D9820C0AF123B37547689CD2FF4B7703E3A912FDCCEA5A67F73219B6A1FD4DA6A4634CB960913B3A4C3BBB22B732F62E1A49B492E400433E2B5A8997D4F61856C94F224D4B2912CE37F9122CE44C89466E30C93E18C70B5DD6E3C21F1AD14E0FC91B78BB7BED6D423E9E970A254F87B4A5FCE61130DF25E4B6B7765FBBD2750579D7A2AD8B83E8F508697371AA8B19476AB8D0AF0C1BC08DA382485C9347964B4C9C38B8898A15B58320570E4C065BB112505986D0A4845BC8153AF788FF9799F2854B17D0AFAF143FCBDC919DD5D52AF05974902870C4343F3EA39C2D38952EE3ECB936E3418A55FEC4446CA7DA89143CD43435125108305DD537C396C3B8D93152AF5F6F28359E615977DDB32FCDE856952E47F7DF46C831C8C29AEB9A1A5A87B3F3EE31D41FCFB677E94B8008601359C47C6CC0AB9446E911746D0F52EC9B0EF2356C138C4D0CAAC39F741ECF2CE33099D376238529F393C96C84C468E59FA8AD7850B5288E84AFAB430CA13CC11CFF6457EA22B95A15385CCF734351B87640B590B4A61DECCB68F7211396BC540558A089B769CB525E0965D3A75236C7846995ABD4EBCF3FFD4553D10DF590335D20FC1D4F2E20F61B6B7E3D54C66ABA6D33B85B2B5D7CBCC1D62B72C6DAF4F8857D8930AD9C2289415EDEE889D273DD2DD81BA2096869F822CB9350D1B964EC6F7992DE37F1F908C34CFC944C1711ED00A6C7E408B6CD15AC6F9AD8699230764B4046134056B1FD7EFE1EA30A5CDCAD2CD11F2E0232E0D9B70E8EBCFE4259B97AE11AA89EB36BA27C8B2E014A20AD04F155C3FFFBF329C8838E6B0B9D7C2CABE441B80A

If you took those bytes and made them into a binary exe file, they would give you the above visuals …
I hope you can appreciate how amazing this is

2 Likes

There are many versions available …

http://www.pouet.net/prod.php?which=52938

Very cool.

This should be a space project. Hackathon type event.

I would say to try to do it before deciding it is cheating …

http://www.lofibucket.com/articles/64k_intro.html

1 Like

It would be great to do something along the line but these programs takes many people many months to complete.
It really is an art as well as a whole lot of skills that most people do not have.

With a Hackathon we need something that anyone that is willing can contribute to a group in some way and use a variety of different skills and ways of doing it. AND be completed within a time frame. It is meant to be exciting and not stuck on a section of code for a week. haha There are many ways of getting something done.

These demos are shown and judged at demo conventions or parties. It does share some of what you are talking about. We just need to come up with an idea that everyone can do/contribute in some way.

It also depends on the type of hackathon we want …

Fair enough. How would you have liked them to do it on modern machines? The problem is when you have many different hardware vendors and GPU types, wouldn’t you have to require certain hardware if you wanted to go direct? Times have changed from the old days that pretty much any graphics card works the same into every graphics card is highly specialized when it comes down to it. It makes sense to use something like OpenGL or DirectX because that is really your entry point to using the GPU. If you are saying to not use a GPU and just a flat 2d graphics plane and invent all of your 3d then you really are missing out on all the shaders and modern techniques.

not to be pidantic but wouldn’t 2^10*4 bytes just be 2^10 alphanumeric letters/numbers?

Either way I’d love the idea. IT would be amazing to see a hack-a-thon based on this. Do we have any outline on the event?

In x86 …

The normal length of a int is 4 bytes. The length of an Ascii character char is 1 byte.
There is Unicode that can take up many bytes for a single letter depending on the locale but normal Latin characters are just one byte.

byte: 8 bits
word: 2 bytes
double word: 4 bytes
quad word: 8 bytes

1 Like

I’m with Zach. 4K + 600MB of libraries, is a program sized 600.4MB.

4K to do something would be interesting. 4K plus libraries - not interesting. Clever maybe, but still just running someone else’s code.

The very first software I wrote, was in 8086 assembler, compiled to about 22K, no libraries, and burned into an EEPROM. It was for a traffic signal controller, that subsequently ran for 15 years in a certain North Texas City. I also wrote the programming and monitoring applications for it. The Apps were in Turbo Pascal (god I loved TP and still do).

Most interesting thing about it, was that the motherboard had 16 pics, all tied to high-resolution timer chips, and sync’ed to a 10meg signal.

If you are going to say that then every windows program includes windows. I will ask what I asked Zach, how would you have preferred them to do it on a windows PC? See my above post for the unanswered issue. Answer that and then we can talk. :wink:

Calling shenanigans, does not infer that a sensible substitute to the shenanigan be provided.

#include <stdio.h>
int main()
{
system (“C:\Windows\System32\scrnsave.scr /MAX”);
return 0;
}

Ought to compile less than 4096 bytes. I win!

Oh hey, since screen savers are also part of the OS (just as directX is), I note that scr files are in the path, so…

#include <stdio.h>
int main()
{
system (“scrnsave.scr /MAX”);
return 0;
}

Oooo. I be optimizin!

Personally, I think Draco’s argument makes a whole lot of sense. You code for the machine’s abilities. Back in the day with my Trash 80 CoCo, that essentially meant understanding h/w + code. Today that simply is no longer true. It is h/w + libraries + code.

The techniques and skills needed to achieve these demos (old school or modern) requires the user to understand their platform with a degree of expertise that separates these artists from others.

Given that memory is practically free compared to yesteryear, I not sure why anyone today would even bother. I’m pleasantly pleased to see this. However, I’ll be the first to admit that in my mind the memory minimizing of these demos only makes sense for yesteryear. But the maker in me says ‘screw that. I’m doing whatever I want.’

1 Like

I agree that perhaps a better way to have presented this hackathon is with a lines of code constraint instead of a bytes of code constraint. If anything, to sooth the egos and insecurities of assembly optimization fossils like myself.

Other than @Tapper’s coding anecdote reminding me of the OOP revolution of the 90s, it reminded me of when I taught assembly language to sophomore computer science students. One of my quizzes was actually to have them write code for a stop light. I never considered optimization, because in the 21st century, teaching kids the value of optimization (in most cases) would invite laughter. Optimization today is only genuinely useful in special cases. Now, that didn’t stop me from preaching about optimization and reliving my nostalgia and recollections about how things were done 30 and 40 years ago, before my students were even born. But I think this was a reflection of my own insecurity; an effort to feel less like a disrespected and obsolete fossil of computing, and more like a respectable elder. After all, a great many things that I dedicated my life to learning in the last century are no longer useful to anyone, except maybe when I work it in as an anecdote. Most of my value, as any type of expert in anything, is from the experiences I’ve accumulated over the last 7 to 10 years. I think the same can be said of anyone claiming expertise. But it would be a serious lack of wisdom on my part to needlessly criticize my student’s hard work and then bolster my own antiquated work from before they were born. That would be disrespectful to my students, who would be more than willing to share their negative experiences about me with others, and I would soon earn a negative academic reputation, complete with poor reviews, and frequent complaints to the department.

I think I agree with @Draco and @darrent. The values of programming have shifted in the modern age. 50 years ago, technology was far more limited, and optimization of code was a requirement to get most things to operate. Today, code optimization is only important when you’re focused on highly iterative or recursive algorithms (like machine learning). But coding in general? It’s far less of a priority. The paradigm is now to get code written and working in the shortest possible amount of time. Reinventing the wheel (by rewriting libraries) is considered an unproductive waste of time. The value today is on the programmer’s time, not on 40 year old hardware.

1 Like

When I took a C programming class some ~20 years ago, a meager “Hello, World!” terminal application compiled down to some 70K. I can only imagine how much idle, utterly vestigial nonsense whatever version of that msft compiler was packing into that executable by default.

Code optimization only seems to matter whenever you have disk, memory, bandwidth constraints. Low-power embedded devices. IoT. Firmware. Drivers. Malware. The latter seems to be the cutting edge of the field.

My former employer spent billions of dollars on developing and deploying the FIOS network; by some accounts they spent close to a billion dollars on software development to make that happen. No matter the exact figure, the software cost more than the hardware it ran on. It was more cost-effective to upgrade hardware or throw more machines at the cluster than it was to optimize that code, which was under continuous development.

So, incredibly tangential…

Seen it from the inside and the outside both ways so I feel your pain. FTR bit off way more than they could chew buying the second half of what used to be GTE and opted for the now-infamous flashcut rather than spooling up another instance of VZ systems in parallel and gradually migrating customers over like they did 2009-2010 for IN, OR, WA. Cost them some money licensing from VZ, but probably saved a lot of firefighting and lost goodwill.

VZ’s approach was regimented, methodical, plodding. Handoff to other systems happened as early as possible as did element provisioning. There was a decent degree of end-to-end visibility through their alphabet soup of systems. Development was however painful. Silo’ed departments engaged in routine bickering.

FTR has an architecture that works faster and does less processing, but the backend legacy systems are ancient, opaque, and run by people that have all but locked themselves into silos. For a company without a wildly profitable wireless division, FTR is curiously reluctant to engage in some critical streamlining. Too many network topologies means that technical debt on the credit card never gets paid down. Oh, and unlike VZ, FTR doesn’t own massive backbone capacity…

Both are incorrigible telcos and refuse to let go of paradigms that died in the 90s. Billing complexity. Package / SKU proliferation. Legacy systems and Processes that shackle the company.
Incentives that reward constituenciess within the company that do not serve the customer and thus do not improve the business: it’s like watching a cat that learned to pet itself.

1 Like

Shaygan understood the importance of minimizing software development costs. But instead of finding a paradigm where programmers could be more efficient, he found another way.

FIOS was CIO/CTO Shaygan Kheradpir’s baby. I’ve been following his career ever since he “left” Verizon in 2010, shortly after an internal ethics investigation that never made the news. Since his 11 years with Verzion, he’s been fired from Barclay’s Bank, Juniper Networks, and Coriant (as of just last month). His Juniper Networks termination was particularly dramatic, because it involved a botched negotiation with his former employer, Verizon.

Shaygan’s main contribution to software development at Verizon, in my opinion, was cutting the price tag of labor in half by trying to hire developers that were compelled to work 100 hour weeks for low wages. He did this though a combination of labor loopholes in offshoring, contractors, and employee labor policy. Don’t get me started on all the misleading offer letters. In any case, the end result was widespread misreporting and falsification of documentation throughout the company. While the same could be said of many companies, this was systematic.

If Shaygan were wiser, he would have focused on newer software development paradigms that reduced development time in the long run, instead of simply screwing over his people in mass. But he was short sighted, and once he got into maintenance mode with FIOS, he opted to get creative with his depleting operating capital, instead of creating relationships and persuading others to help finance a modern strategy that would save Verizon money in the long run.

Again, exceptionally tangential …

Verizon IT underwent a huge culture and demographic shift during my last years with the company. When I started in 2004 it was better representative of the company than it was in the latter years. I first noticed it circa 2008 with the steady replacement of citizen employees with non-citizen contractors. Through 2011 or so it was still a reasonable aspiration for someone outside of IT to aspire to a position in IT; afterwards it was nearly an impossibility. Starting in 2013 or so the requirements went from subtly favoring hand-picked candidates to nakedly doing so (my favorite was “must be approved by onshore and offshore team” - elephant in the room being that implied ‘independent’ approvals were solely in the hands of the boss). Every RIF cycle the layoffs happened to land on citizens/employees who were shortly thereafter replaced by contractors whom were uniquely qualified … in the sense that they were non-citizens, of a singularly monolithic demographic, were difficult to communicate with, had pretty much zero practical understanding of the business, often offshore and not routinely available during business hours, and generally less efficient than those they replaced. The “professional workday” (14 hours) was a norm among these folks, however I would not suggest they achieved as much as those they displaced working a more typical 50-60 hour week - but they were perpetually under their boss’s bootheel thanks to the quasi-bondage of work visas for the onshore folks and body shop conditions offshore.

I’m always surprised that Verizon wasn’t slapped down hard for abusing the work visa system.

On paper the cost savings were real if you only looked at contractor’s $X/hr rate being less than an employee’s $Y/hr. But in reality the cost was markedly greater in terms of deadlines missed, the added management/in-betweeners/staff/architect/staff burden to get neophyte outsiders up to speed, and milestones missed - or only hit with the most tortured of semantical weaseling.

In terms of what was delivered, it never met its potential. The major system involved was intended to run the whole show, end-to-end. The structure was there - as a longtime power user I could see it; very occasionally they leveraged these latent capabilities whenever the legacy systems couldn’t - or refused to - perform some critical function. But during the development process they clearly ran out of time, money, and friends. Thus they were forced to integrate with other creaking legacy systems that should have been cut out of the equation out of the gate. Senior leadership should have intervened and started the process of closing those loops; but much like IT’s focus on paper costs they too were likely blinded by prominent CAPEX vs less-visible OPEX.

Telco is it own worst enemy by a long shot. I encounter mindsets that predate the Telecommunications Act of 1996, to say nothing of the AT&T breakup. Internal organizations, processes, systems, linger for decades past their shelf date. Silos are erected for whatever public purpose, but the implicit purpose is empire-building.

1 Like

Mark - I found myself nodding in agreement with most of that, and it sounds like we were both coding during the genesis of OOP (a term I hadn’t heard in a while). I also fully agree, that todays coders aren’t held to the same critical performance standards we were. Modern CPU’s certainly enable poorly optimized and bloated code, and hide a plethora of bad coding practices, and while we do have excellent coders running around today, we also have far more hacks, that rely exclusively on code (in the form of libraries and pre-fabbed objects) to accomplish anything of value, and CPU speed to hide poorly written code.

I do take exception to the sentiment behind the following:

Experience, in all things in life, is an incredibly valuable commodity. It informs, it shapes, it enables, and most of all, prevents wasted time chasing Alice down the hole. And if you can write quality code in C or assembler, no language in common use today will really pose a challenge to learn.

Given the abyssmal quality of our education system today, I’ve long since stopped worrying about educational achievement in the hiring process. Having a degree at any level, is no guarantee or indication of ability. Instead, I hire and pay based exclusively on experience. And knowledge of the language or library du jour, does not last, any more than my expertise with Pascal or assembler did. But the experience gained, translates forward.

With respect to your comments re:Draco, I do not wholly disagree. However, I would still look to the intention of the contest, versus the fact that their code was but a wrapper for other peoples work, and I think it’s disingenuous at best to claim that the visuals were produced by 4K of code. However, were this to be characterized as “interesting tricks with DirectX” I’d be far more impressed.

In an effort to keep things on topic, Shaygan, in my mind, represents the old “code optimization” paradigm, translated into modern day. One of his “innovative achievements” was to have Verizon buy used hardware off eBay in order to save money. He failed to adapt and change to the successful software engineering paradigms of the modern era, where one mediocre programmer, with modern development tools, running applications on modern hardware, can do the work of about 1000 good programmers with outdated development tools, running applications on obsolete hardware.

A well written, modern, 4k program, that leverages any pre-existing libraries already available is more than interesting. It shows how far software engineering has come over the last 60 years.