>  
> On Jun 29, 2024 at 6:20 AM,  <Rowan Tommins [IMSoP] 
> (mailto:imsop....@rwec.co.uk)>  wrote:
>  
>  
>  
>  On 29 June 2024 08:06:57 BST, Mike Schinkel  <m...@newclarity.net>  wrote:  
> >The takeaways that I think would be useful are PHP modules are:  >   >1. 
> Imports  >2. Import aliases  >3. Module-level consts  >4. Module-level init() 
> functions  >5. Module-level vars with initialization  >6. Module-level 
> functions  >7. One directory == one module  >8. No hierarchy for modules  >9. 
> Single word module names in lowercase.  >10. Module sytax being  
> <module><operator><symbol>, e.g. mymodule->MySymbol This all sounds like an 
> interesting set of ideas for building a new language. 
>  
>  
>    
>  
>    
>  
>    
>  
>    
>  
>    
>  
>    
>  
>      
 
 
 
 

 Maybe, if a new language only had a tiny set of the features needed to 
actually have a useful language. 
>  
 
 

 
That list is just package-specific, nothing about syntax, data types, control 
structures, package management, etc. etc.
 

 
>  
>  
>  Most of it sounds completely impractical to apply in retrospect to an 
> existing one with millions of users - apart from the bits we actually already 
> have, like points 3 and 6. 
>  
>  
>      

 
>  
 
 
You say it is impractical, you claim millions of users, but you don't address 
why the specific features are impractical.
 

 
They are no more impractical than any other new language features PHP has added 
in recent years (and I am not being critical of what has been added, to be 
clear.)
 

 
>  
>  
>  Rather than looking at languages which have done things completely 
> differently, 
>  
>  
>    
>  
>    
>  
>    
>  
>      

 
>  
 
 
"Completely" here is a leading word used in that context.
 

 
There is nothing "completely" different about JavaScript, or Go for that 
matter.    All three of JS, Go, and PHP are descendants of C.
 

 
We are not talking about APL, Whitespace,   Befunge, or Intercal, after all.
 

 
>  
>  
>  I think it would be more useful to look for inspiration for ones which are 
> *similar* to PHP's approach, but have extra features. 
>  
>  
>    
>  
>    
>      
>
>  
 
 
 
>  
>  so there might be good and bad experiences we can learn from there, as well. 
> And I'm sure there are others that are much less alien than JS or Go. 

 
 

 
I would argue JS and maybe Go is a lot more similar to PHP than Java or C#.    
But then the alienness is in the eye of the beholder.   
 

 
You claimed you don't know JS or Go, but I don't know Java or C#, at least not 
enough to be proficient in them. 
>  
 
 
 

 
That said, I really don't think gatekeeping based on the genetics of a language 
is the path to improving it. Instead I think objectively evaluating the 
specifics of the proposed features is the better path. And to me each of those 
things I mentioned stand on their own and can be justified, as needed.
 
 

 

 
-Mike
 
     

Reply via email to