But it's still an entirely pointless 336K. I could use that to store:
-197 copies of nethack
-10% of DarkPlaces
-36% of GCC
-44% of ZSH
-30 copies of CPython (just the executable, of course: that's all you counted)
-10% of ZSNES
-1.36 copies of XScreenSaver
-42% of Teeworlds
All of these are more valuable uses of my precious disk space, because all of them actually do something: They actually give me capabilities I previously didn't have.
GCC and CPython are great illustrations of what Im talking about. Others are good. Also, Oberon System base with kernel, files, editor, viewer, etc is around 116KB per Wirth's paper on FPGA implementation.
So, you get a whole OS with some utilities in between 1/3 and 1/2 of SystemD binary. Also worth noting Oberon includes safety checks, too. ;)
Honestly, I found the tradeoffs of it to be the most interesting. It hits an interesting balance of readable, safe, fast compile, and fast runtime. Includes some OOP and concurrency foundations while barely changing the language. Whole platform can fit in one book. You could theoretically understand whole thing and reimplement in language of your choosing. Was esp good when hardware was weaker and more diverse. Also better starting language than C in education as it can be easy at first with difficulty gradually increased with intro of unsafe constructs. Finally, it's seeing some uptake in embedded with Astrobe IDE.
So, that's a quick review. The main one you'll find is older system where A2 Bluebottle is latest. Runs fast, too.
"Yeah, it does look really cool, just verbose. And you say it's easy to implement...."
It is a compiler and OS. Easy means a different thing in this context versus average usage in software. I'd say vastly easier than trying to understand GCC or Linux. How about that? Also, the original version was done by 2 people and some change. Each port of compiler was done by 1-2 people in relatively short time. Mostly students with basic knowledge in CompSci. Helps it's well-documented.
So, it's not easy as throwing together a web app but can't be ridiculously hard if you take it a piece at a time. The use I had for it, other than learning or pleasure, would be for subversion-resistent, verified-to-assembly builds. It's super easy to learn Oberon with the OS itself straight-forward. People could code it up in a local language, the compiler too, compile those (or hand-done in ASM), and bootstrap into a trusted environment. That can be used to produce the rest with compilers built on top in a memory-safe language that handles foreign code more safely. Better, no patent suits or anything on Wirth-based tech like .NET or Java might get you.
Other than Oberon system, Modula-3 (not Wirth) and Component Pascal (Wirth et al) are most worthwhile to check out in terms of practical languages. BlackBox Component Builder is still in active use with Component Pascal, esp in Russia and Europe. They love it over there since it's got OOP & GUI with Oberon simplicity & safety.
Oberon is mind boggling, in all respects. You can download the emulator (<5mb total). It is SDL2 based so runs like a stand alone app, no VirtualBox or QEMU needed. Then you can get and compile Lola-2, the Verilog pre-processor compiler from Prof. Wirth. Now you can literally compile the RISC5 processor "chip" itself which runs on the FPGA!! Just use the output .v files from Lola-2 and compile with the Xilinx toolchain. Next you can compile the "Oberon OS" quite simply by hand in a few minutes. With a compile script the complete OS compiles in 10 seconds.
Then why not finish off with PICL, the language/compiler for the PIC16. Includes the uploader. All in <700 lines of Oberon code. The best part is the amazing tutorials/documentation. Some amazing finds at Prof Wirths personal site. https://www.inf.ethz.ch/personal/wirth/
Of course. I'm foolish, but not foolish enough to think "easy" compiler/OS equals "easy" webapp. However, I am foolish enough to start any project, although usually not mad enough to finish it once I get an idea of the work involved.
Once again, Oberon looks neat. I am usually not a fan of the Wirthian languages, so I might not enjoy it in the same way I enjoy, say, Python, or Scheme, but it looks interesting.
"Of course. I'm foolish, but not foolish enough to think "easy" compiler/OS equals "easy" webapp. However, I am foolish enough to start any project, although usually not mad enough to finish it once I get an idea of the work involved."
You and I are appearing to be more similar than I thought on these kinds of things haha.
"Oberon looks neat. I am usually not a fan of the Wirthian languages, so I might not enjoy it in the same way I enjoy, say, Python, or Scheme, but it looks interesting."
In your case, rebooting PreScheme to do a small OS like Oberon or clone of it might be a better take. There's already books on quickly putting together a Scheme compiler. The PreScheme and VLISP papers are pretty detailed. Include some safety features from Clay (C-like) and Carp (Lisp) with Scheme's macros and simplicity. Mock-up assembly language in it so you can code & test it, too, in Scheme with extraction process to real thing.
That combo seems like it would work better for you plus result in at least one deliverable: a PreScheme implementation for system programming whose code was compiled with GCC or LLVM. You might find that useful over time esp if you made syntax compatible with one of your typical, Scheme implementations to port those libraries over easily. Split it between GC'd code and non-GC'd code like Modula-3 did.
Seems neat. The original PreScheme is part of S48, which seems to be dead.
Speaking of which, I should probably consider doing that project I was thinking of doing for a while: port SCSH to some other scheme implementations which are actually alive.
So yeah, the trick with doing a prescheme project is that I'd first have to build a PreScheme compiler (with added safety, etc.) and then I'd have to build one that can run on bare metal. The former ought to be possible, especially if I'm targeting C or LLVM (some bits might get a bit rough, but most of Scheme is pretty easy to implement). The latter would perhaps be possible, but making use of it would likely require a more in-depth knowledge of the hardware than I currently possess.
You know, I was joking about porting Oberon to the gameboy, but the GBA is a really well-defined piece of hardware with readily available tooling (which I actually have, because you need it for LSDJ), and a good deal less complexity than a modern x86 machine...
Man, why can't I just write videogames, like the normal people?
Well, my current side project is writing a version of the Tafl-inspired board game Thud that you can play over a network, so I guess I'm already doing that...
"The former ought to be possible, especially if I'm targeting C or LLVM (some bits might get a bit rough, but most of Scheme is pretty easy to implement)."
That's what they did originally. Should work.
" but the GBA is a really well-defined piece of hardware"
Then do a PreScheme wrapper on it supporting inline or calls to assembly for performance-critical routines. See if you can make the primitives on bottom close to how hardware works for efficiency. The AI research of the 80's indicate it might be able to handle a board game.
To my knowledge, CPython is the only piece of software on that list that has its own shared libraries.
And yes, disk usage is a concern. Because those kilobytes add up fast, and I've only got so much space.
And finally, the point isn't merely that it takes up disk: the point is that it's worthless. The old solution to that problem, having init set locale on boot from a config file, worked fine. I don't mind disk use that much. But I do mind pointless software.
All code has bugs: to minimize bugs, write less code.
In comparison, the QNX demo disc had a whole graphical OS in 1.44MB that was more robust than that one file. Seems to be some efficiency or architectural issues in there. ;)
Given, QNX never really caught on in the wider field of computing AFAIK. This may lend credence to the Godot team's theory that public visibility is based upon how big you are (https://godotengine.org/article/godot-aims-mainstream).
I was talking complexity vs size. Gabriel's Worse is Better already tells you that growth has more to do with network effects and marketing than technical correctness. QNX lacked them for desktop or server use but did well in embedded. Almost had a mobile shot but Blackberry blew it totally with marketing plan.
EDIT: Read Godot. That was hilarious but I kept seeing too much reality in it.
Ahh gotcha. Far as other thing, have you seen the Web and enterprise BS getting lots of adoption since big names tried them out? And the drift to incomprehensible frameworks with huge dependencies that one can barely maintain with similar security problems and a tiny fraction of efficiency of C++? And now more of them as SaaS? Just thinking there's lots of that bullshit in the article going on in real life. It's that or legacy SAP, Oracle, COBOL, MFC BS. Competing BS exists but sanity gets rarer and rarer.
Outsourcing was done with great care by a few big name corporations. And after their apparent success every two bit public traded company went on a "me too!" outsourcing rush to try to goose their share value.
Oooh. That. I get a miss on a lot of it, because I'm not in industry, and I avoid Java (the natural focal point of incomprehensible frameworks), and frameworks in general.
On a daily basis, the worst I have to deal with is SystemD, which is creatively incompotent and best, and downright insane at worst. But it's got a pretty face, and the draw of easy-to-understand unit files (over, say, SVinit), so people don't realize the depths of the madness that lies beneath.
Had less attack surface (microkernel), isolated failures, easier to upgrade, and could be self-healing within one node. Important to some people. They kept paying for it until numbers justified RIM buying it for its potential. ;)
Indeed. It's one of the Microkernel architecture's (semi-rare) success stories. It goes to show that yes, Microkernels are complicated, and hard, but if you pull it off there are real benefits.
>I just don't think anyone is really interested in doing so. Most PHP users don't care much
They care. They are interested.
But backwards compatibility is a huge issue. PHP7 is much better, it's faster, it uses less resources, and yet you still have hosts running PHP 5.3, some even running 5.2! How do you combat a crowd like that? I don't want PHP to get stuck in IE6 mode, and I sure hope the community voices their valid criticism and takes action.
Have they really been, PHP issues would be fixed long time ago. It had 7 major releases, and people complain about exactly the same things. All the people I know who complain about it and switch to something else say the exact same things, no matter what PHP version they've left behind. Those who do care simply go somewhere else, only those who do not or have massive codebase to support stay.
> PHP7 is much better
Lets agree to disagree on that. Its not better enough to draw any of PHP opponents to it.
> you still have hosts running PHP 5.3, some even running 5.2! How do you combat a crowd like that?
You don't. Let them be. There are people using PHP 1,2,3 and 4 somewhere out there. They may never switch. Why should it hold back the rest of the world?
Taking into considering that the thing you complained about
(errors instead of exceptions) was fixed in PHP 7, maybe you should reevaluate your opinion about PHP not fixing things in newer versions...
PHP is too easy to get started with and is too popular.
You can even use WYSIWYG tools to create a website, and then proceed to insert small, poorly written PHP scripts in it. Try creating a PHP gig and start looking for developers on many freelance sites - you'll get tons of people who don't even know what the hell a function is, and yet their profile claims they're experienced in PHP.
>Wordpress developers
No offense to actual Wordpress developers, but many self proclaimed Wordpress "PHP devs" I've seen are only capable of installing Wordpress with a few plugins and select skins. Maybe they know how to edit a file or two in a plugin, but that's about it. And when you ask them what language do they use, they'll obviously pick PHP, even though they couldn't code their way out of a cardboard box. This drives the average wage down, but hell, even mom & pop shops need a dynamic website these days, and Wordpress giveth.
In fact, the market really wants Wordpress developers these days. I checked out many freelance sites like freelancer.com and upwork, and there are tons of gigs available for Wordpress, Drupal, Joomla, and shopping cart setups. Hell, I'm currently looking to help out a friend by finding a dev to create a small website in PHP (or any suitable language, don't care), but the local shops only offer Wordpress and Drupal! Won't touch anything else!
Try finding a Python, Ruby, Node or Go shop who will only install scripts/CMSes and customize them. Nope, not yet! But given enough time and popularity, they'll have their fair share or developers who have no clue what the hell they're doing and will drive the average wage down. Just wait.
C/C++ and Java was like that. Since it was a part of most people's college education, everyone and their mom claimed they knew C++ or Java. It was on their resume, even though their knowledge was superficial at best. In my experience, Indian and Pakistani applicants were the worst offenders in this.
Compared to Ruby, sure, but pretty much everything is at this point. Compared to Node JavaScript? Not even close.
They've made some impressive gains in PHP7 that others should take note of. Ruby's particularly out of shape here compared to the competition, though Python isn't exactly a speed demon either.
Yes it is comparable to Node. Most benchmarks show PHP with blocking calls against async Node calls. PHP has the tools to do async no problem. I use ReactPHP all the time to do this stuff; it works great for fast scraping.
See an older counter-point with the much slower PHP 5.5:
My first language was Pascal.
The concept of combining strings and integers in PHP without any conversion was scary and magical to me at first, but the damn thing worked, as long as you were careful. I still get mad at people who complain about type coercion because they expect their programming language of choice to read their minds and wipe their ass.
And Dijkstra was kidding. As is Rasmus when he says he'll restart Apache every 10 requests. Hyperbole. Learn languages instead of a language and it'll click. It has to.
I think this is great comment, and I can really relate to a lot of it.
I especially liked this:
> Learn languages instead of a language and it'll click.
I started at 5 or 6 with Basic, then progressed to Object Pascal early on, then C, C++, PHP, Java and finally Javascript and C# - I believe this wide experience has served me well over my almost 30 years' of programming (Christmas I'm getting old!).
I think there is a time and a place for 'just get shit done, fast', as well as spending time building 'elegant' code. But, if anything, the compromise between these 2 is possibly the thing I struggle with most.
PHP also has IDEs, tons of tools, tests, and gets deployed with many services and scripts. It's an inconsistent language, it's used by newbies in a very bad manner without even understanding the bare fundamentals of HTTP, but I really wouldn't call it a garbage language. If it were, it would have been dropped ages ago.
But I see what you're getting at... if you need to whip up something quick, don't start experimenting with the "flavor of the day" language or library.
That thing was parroted a thousand times already and it really boils down to a personal rant about tons of legacy features rather than a properly worded criticism of the language itself.
The author is also really confused about type coercion in PHP.
Try me.