© 2006-2024 Radicore Software Ltd
Latest news
RADICORE v2.30.0 released14 November 2024
RADICORE v2.29.0 released27 July 2024
RADICORE v2.28.1 patch released11 May 2024
Knowledge Base
The Road to Rapid Application Development (RAD)21 December 2024
Evolution of the RADICORE framework01 June 2022
How Radicore prevents SQL Injection attacks17 July 2021
Articles
Developer Awards 2024 - Best Open Source RAD toolkit11 November 2024
Global Awards Winner 2023/2428 July 2024
Support for PHP4 dropped, support for PHP7 started01 October 2016
Other Stuff
OOP practices which save time21 December 2024
The true purpose of Dependency Injection28 November 2024
DTOs are Diabolical24 November 2024
Videos
Global Awards Winner 2023/2428 July 2024
What are Transaction Patterns and how are they used in the RADICORE framework?16 May 2024
An overview of the Role Based Access Control (RBAC) system within RADICORE07 December 2022
Archive for Other Paperswithout synopsis
The true purpose of Dependency Injection
All the artcles I read on the topic of Dependency Injection claim that its purpose is to separate the construction of objects from their use. This is not the end, it is just the means to an end. The true purpose is to provide a mechanism to take advantage of polymorphism and thus provide components which can be reused instead of duplicated.
Published: 28 November 2024
DTOs are Diabolical
I have recently seen some articles which claim that Data Transfer Oobjects (DTO) are a good idea. This article explains why I disagree.
Published: 24 November 2024
A challenge to see who's technique is best
Fellow programmers do not believe me when I say that my framework makes me more productive than them, so I challenge them to prove it. I can create a family of forms to maintain the contents of a new database table in a matter of minutes without writing any code - no PHP, no HTML and no SQL - so if they can't match that it proves that their methods are less productive and therefore inferior.
Published: 21 November 2024
RE: Back to Basics - Three or Four OOP Pillars?
Some people still think that there are four pillars of Object Oriented Programming - Encapsulation, Inheritance, Polymorphism and Abstraction - but I disallow Abstraction as it existed before OOP came into being, therefore it cannot be a distinguishing feature. Even worse is when someone limits abstraction to data abstraction instead of functional abstraction, and then claims that data abstraction should be implemented as a Data Transfer Object (DTO). This article identifies the mistakes in that erroneous assumption.
Published: 20 November 2024
The Fallacy Of ReUse
Everybody knows that to become a productive programmer on a large application with many repeating patterns you do not write a fresh copy of each pattern, instead you try to create a single central reusable version which you can reference many times over. The logic is simple - the less code you have to write to get the job done then the quicker you can get the job done and the more productive you will be. However, there are some programmers who lack the ability to either spot repeating patterns or to make reusable versions of those patterns without introducing fresh sets of bugs. Rather than blaming their lack of skill they claim that it is the quest for reusable software which is at fault. Here are my comments for one such claim.
Published: 20 August 2024
From Wireframe to Prototype to Live Product
When building a new application there are several different stages to go through which may require different tools, such a wireframe, storyboard, mockup and prototype, and evetually the live product.Wouldn't it be nice if, instead of having to use a different tool for each which may mean not being able to use the output from one tool as the input for the next tool, you could use the same tool for each. Such a tool does exist, and it is called RADICORE.
Published: 10 August 2024
Strict typing is for stick-in-the-muds
While many of the early programming languages were strictly typed most of the modern languages, such as PHP, are not because it places fewer restrictions on programmers and makes them more productive. Yet some programmers who started off with a strictly typed language, or who were trained by old fogeys who used strictly typed languages, still hang on to the belief that such languages are "better" and refuse to change their mindset. Instead of using PHP and trying to embrace this different approach they instead expend far too much effort on converting the language from being dynamically typed to strictly typed without realising that this is a backward step. Will these neanderthals ever learn?
Published: 24 June 2024
KICK Principle - Keep It Complex, Knucklehead
This is the exact opposite of the KISS principle (Keep It Simple, Stupid)
Published: 24 June 2024
The case against function overloading in PHP
Ever since type hinting was added to PHP in an attempt to make it behave more like a statically typed language there have been calls from a growing number of developers to add "proper" function overloading so that it works like it does in those other languages. This article argues that function overloading was the solution to a problem which exists in all statically typed languages, but as PHP is dynamically typed it does not have the same problem therefore does not need the same solution.
Published: 18 July 2023
RE: Why PHP is not suitable for enterprise grade web applications
I came across an article which claimed that PHP is not suitable for writing enterprise applications, but as I have been doing just that for the past 20 years I feel I have to challenge every one of his arguments.
Published: 11 July 2023
The case against static typing in PHP
PHP has always been dynamically typed, but over the years there has been a gradual movement to make it more statically typed. At first this was optional, but this is now becoming mandatory. This article explains why this is a bad move which will bring nothing but grief to the hordes of application developers due to the amount of code that will break and the huge amount of effort that will be required to fix it.
Published: 26 June 2023
Is there a case for adding namespaces to PHP core?
Ever since namespaces were added as an option to PHP there have been calls to force PHP to use namespaces for all internal functions and classes. This article describes why this idea is totally pointless and without merit.
Published: 08 April 2023
The PHP core developers are lazy, incompetent idiots
With the release of PHP version 8.1 the PHP core developers have chosen to break backwards-compatibility on an enormous scale for no good reason. This article identifies what they have done and explains why it is BAD!
Published: 13 February 2023
Changing Fundamental Language Behaviors
There has been a lot of arguments lately within the @internals group about things that some people regard as bad and which should be removed from the language. Some people agree with the removals as they would make the language more "pure" and therefore acceptable to "proper" programmers, while others say they do no harm, have been used without issue for over 20 years, and would cause major disruptions for large numbers of websites which would suddenly stop working. This is my personal view on this touchy subject, and it is a view shared by others.
Published: 16 August 2019
Blockchain for Blockheads
Blockchains are being hyped as "the next BIG thing", and as usual with hype there is a lot of confusion. Here I provide answers to some of the basic questions that are asked.
Published: 23 June 2018
BC break in 7.2 caused by undocumented and unauthorised change
BC breaks are annoying, but the worst are those which suddenly appear without any warning whatsoever. This is one such break which made me VERY annoyed!
Published: 15 June 2018
Please do not break our language
This is my response to the idea that the next major release of PHP - version 7 - should contain as many Backwards Compatibility breaks as possible.
Published: 31 December 2014
4+ Reasons Why All PHP Frameworks Suck - Except RADICORE
This is a response to an article written by Manuel Lemos called "4 Reasons Why All PHP Frameworks Suck?"
Published: 17 February 2014
Stored Procedures are EVIL
Here are some reasons why I choose not to use database stored procedures and triggers.
Published: 03 September 2006
Software Patents are EVIL
Are software patents a good thing or a bad thing? Here is my personal opinion.
Published: 31 August 2006
Is Radicore better than Ruby On Rails?
Ruby On Rails is the subject of an immense amount of hype, but are there parts of it which are less than perfect and open to improvement? Do these "improvements" already exist within Radicore?
Published: 28 May 2006
Are you a Code Monkey?
In days gone by an organ grinder's monkey danced to his master's tune. A "code monkey" is someone who dances to someone else's tune, someone who is a follower, not a leader.
Published: 17 March 2006
Case Sensitive Software is EVIL
People who call for more case sensitivity in PHP just to be "consistent" with other languages do not understand that by perpetuating a bad idea they are simply being "consistently bad".
Published: 27 January 2006
Breaking Backwards Compatibility is EVIL
A small number of thoughtless programmers are changing the language in the name of "code purity", but instead of improving the language all they are doing is turning thousands of users off by causing existing scripts to break and thus slow down the migration to PHP 5.
Published: 18 December 2005
Development Standards - Limitation or Inspiration?
Standards are supposed to represent "best practice", to inspire others to produce great works, but some are so badly written that all they do is create artificial restrictions, limitations and obstructions and actually get in the way of making progress.
Published: 29 May 2005
Component Design - Large and Complex vs. Small and Simple
When designing application components there is a very important choice to be made up front - do you use a small number of large, complex components, or a large number of small, simple ones.
Published: 30 June 2001