I'm curious how you came to the conclusion that naming it 'screen' was the best thing for your project?
It's unusual to see so many negative comments on a new project announcement and yet you persist and even double down with a sarcastic "thanks for your feedback" reply.
I named it screen because the main class is called screen. It was extracted from another library to make maintenance easier. It's not a tool that can ever be used outside of a PHP project, and it has no binary. It's namespaced under SoloTerm.
A nice analogy would be a package named @clerk/auth and then everyone complaining about the package being named auth. I mean it is... but that's not really the full name or how anyone would refer to it.
Most commenters didn't understand any of that nuance and got hung up on a surface level thing that didn't really matter. It was clear to me that the suggestion didn't apply in this case so I thanked them for the feedback. I don't have to take the feedback!
Several other folks commented that it's not really an emulator but rather a renderer. I thought that was a pretty good point and something I was wrong about. So I changed the readme! I thanked them for their feedback as well.
It's no secret that HN commenters lean cynical and can miss the majors for the minors. I just don't want to fight with them! I'm grateful for feedback. Some of it I take and some I completely ignore. As everyone should!
> Most commenters didn't understand any of that nuance and got hung up on a surface level thing that didn't really matter. It was clear to me that the suggestion didn't apply in this case so I thanked them for the feedback.
It's more nuanced than just that.
From your README:
> Solo provides a TUI (Text User Interface) that runs multiple processes simultaneously in separate panels, similar to tmux.
You already provide a tool similar to screen. You even call out one of its alternatives! This will lead to confusion.
Further, from another of your comments [0]:
> I use GNU Screen in Solo, where I also use Solo Screen, so I am aware of it.
combined with
> It was extracted from another library to make maintenance easier.
Looking at the code, Solo is the library you extracted it from. You built a technology on top of an existing, well-known project. Then, you extracted some of your code from it and reused the project's name that your tool leverages in that related library.
This is the first way in which your analogy is not sufficient to support your position.
The second is there is no common, well-known, age-old utility called auth in the auth space for people to co-opt.
To quote duskwuff [1] again [2]:
> They're both pieces of software which implement or interact with terminal emulators; I think some deconfliction is warranted here.
Given the context, I don't think namespacing it is a sufficient approach to reducing ambiguity. Especially since screen is often referred to without GNU.
As for this reason:
> I named it screen because the main class is called screen.
Saying you named it screen because the main class was called that isn’t really a justification - especially when you named the class in the first place.
The willful reuse of the utility's name that powers your code and pithy gratitudes all over this thread, to me, send a message of disrespect for the community at large.
Thanks! I know it's probably bizarre behavior to not debate at all in the comments, but man, life is short.
Good note on the screenshot. There are some code samples but I'll think if there's a way to add a visual. It's tough cause it's just a library that you consume in PHP! But I'll noodle nonetheless.
Your comments come across really rude and and condescending and I don’t see why that’s necessary.
The post is a person sharing their open source package, there is no need to act like this. No harm is being done, the name collision truly does not matter and it’s also just a common English word.
script kiddies are now going to have high-fidelity shells with 256 colors for when they pwn you and get root on your godaddy drupal install
sidenote: screen is a terrible name for this as there is already gnu/screen (colloquially referred to as screen) which has 38 years head start - https://en.wikipedia.org/wiki/GNU_Screen
I'm a little confused--is it an interactive terminal? Or is it more like an ANSI renderer where you are producing a single static image of the final result of printing a series of bytes? I don't see any JavaScript to hint at interactivity.
Perhaps something along the lines of an "ANSI terminal renderer library"? I think "render" helps suggest that it's handling the display but that the library consumer still has to handle interactivity and any UI chrome. The consumer is the terminal emulator app and this component is the renderer.
Lol, what? Haven't heard of this...
What's your experience with nativePHP?
While i am a defender of modern (!) php for web applications, this does sound rather weird. But also interesting. Thanks for the link.
I wonder though how "native" this is? Glancing over the docs it seems to be built upon tauri / electron? Not as native as i expected, but probably more native than most people would dare to think about...
Lol indeed... I also still love PHP. For most small apps that's my go to backend, because who needs to worry about keeping Node running on some server you forgot about 2 years ago? And it's a fully modern language.
I'm delighted that there's some kind of desktop API here. On the one hand, the fact that it's talking with an Electron shell seems sort of magical. But it begs questions like, why wouldn't I just use a fully JS stack? And... since I've never created a graphical app in PHP before, would this be the right time to start?
I'd also say ...patterns like this that return the object you modified in PHP weird me out, even though they're common in JS going back to JQuery:
>>
Dialog::new()
->title('Select a file')
->open();
It's an interesting "modern"-ish design choice, but it doesn't feel very PHP-ish. $dialog = new Dialog('title') followed by $dialog->open() would feel more sane.
Just from a high level, chains on 'new' are actually kind of awful. They're bad in a world like JS where lots of classes need to call async functions to spin up, but they're desperately worse in PHP where you really have to consider everything to be a blocking call. Something basic like this could easily hang a whole thread if, e.g. the title chose to read from a remote file. And it would be quite hard to tell what was hanging it. This is when it feels like PHP is getting out over its skis. I understand the desire to keep up with the Joneses, but there's no real penalty to writing your example in three lines rather than one. It's not really functional either way, and it's not especially debuggable either.
How would it make a difference if you split the statements up? A bad API is a bad API, and I’m pretty sure you can design one in any language (e.g. hide a while (true) within an innocuous method). The way to trace it down is the same in PHP as elsewhere, too—use a debugger. All that said, just don’t design shitty APIs and give your methods useful names.
An advantage of being able to chain calls are fluent expressions that you can return immediately, for example from arrow functions or match expressions, which definitely makes for easier to read code.
I can't think of a lot of examples where I'd want to call:
new API()->object->method()->subResult
particularly if the API might block. But I can think of a lot of reasons I wouldn't want to see that in my codebase. Usually starting with the fact that
try {
$api = new API();
}
should have a catch after it.
For local stuff, fine, if you want to write that way. I don't find it eminently more readable than seeing a variable created and employed. And I'd like to see the line number the error was thrown on, if I'm reading error logs in production.
For what it's worth, blocking might not be an issue in the future. There's some discussion on the PHP mailing list about adding async capabilities to the language.
That would be a welcome language feature... my only question would be, how? Node accomplishes it by basically deferring things throughout the main loop. PHP has no main loop; it's not a webserver. The PHP paradigm is terribly ugly but very predictable in one way: You just rely on Apache or Nginx to spin up and kill a new PHP process with each call. In order for a call to last long enough to return something async, you can't rely on checking it the next cycle. There is no next cycle. So anything "async" basically blocks at the end, unless PHP sprouts its own endless loop the way Node does. And then you probably don't want more than one of them running. So it runs contrary to the paradigm.
Many years ago (see my profile), I wrote a PHP socket server that worked a little bit like Node does. The server itself was a CLI daemon. The webserver sent all the API calls to a normal PHP script that acted as a dispatcher. If the dispatcher saw that the daemon wasn't running, it would call the endpoint itself, block and return a result. If the daemon was running, it would accept an external socket connection to the user and keep itself alive, and open an internal socket to the daemon to route the user's API calls through, which would end up in a queue held by the daemon. The daemon responded to the dispatcher over the internal socket, and the dispatcher sent the results to the user as they came in over the external websocket. Thus it went from one PHP process per call to one PHP process per user, kept alive as long as the daemon was running. I actually think this was niftier in some ways than Node, because no one user could hang the whole server - only their own thread. This was a semi-solution for async calls in PHP.
And, if you want or need to spawn new PHP processes as workers that chew on lots of data, and wait for them to send messages back, you can already do that in a multitude of different ways... as long as the main process waits for them, or else aborts.
In any case, blocking API calls inside a multi-part single line of code are lazy and an invitation to disaster.
I am aware modern PHP is actually pretty good, but having grown up with PHP in the 2000s I can't help but get chills up my spine every time I read '$nonWebThing written in PHP'
I've seen massive cli apps and services written in PHP, it's actually pretty good for that sort of thing and given no build or compile step the devex is quite nice.
There's trade offs of course but for things where disk or network is the bottleneck it performs just fine.
Didn't we have this back in 2001. I seems to remember that we kicked a guy of our project because he installed one of the PHP consoles on our Solaris box, which basically gave it the same rights as the Apache user.
11 at the time here. For me it would be another 10 years or so before I saw a Solaris box or even knew what one was.
I did encounter, and try, Linux much sooner. But didn’t really “get it” either at the time. Like, I understood that it was neat and different. I installed Mandriva Linux on my machine when I was 13 or 14 or so, but I was lacking any books or guidance to understand how to do anything aside from opening the GUI programs that was on it.
It would take all until the age of 18, when I started at the university, before I got the help I needed in order to understand Linux and editing config files on Linux and writing my own scripts and programs on Linux.
> I installed Mandriva Linux on my machine when I was 13 or 14 or so, but I was lacking any books or guidance to understand how to do anything aside from opening the GUI programs that was on it.
It was Gentoo for me at the age of 13 that a random Hungarian guy from Finland helped install through SSH.
I did try SUSE around the age of 11, nothing interesting though, the interesting stuff came after Gentoo. :D
To be fair in 2001 php was the underdog of tech stack. It has just got ride of the PHP (Personal Home Page) taste in the language mouth. So wouldn't be surprised if some company running solaris would kick him off.
Interesting. I remember php being on top at that time, with JSP just starting to take over. I was in a rural area, though, and our local developers were far more influential than any internet community during that period.
It's still a mainstay of certain malware for sure. Just pop in 'php shell' to your favorite search engine, and it's basically all stuff for either red teaming or shenanigans
I started a very similar project probably ten years ago and just never got it to a very usable state. My idea at the time was based in wanting to be able to write tests for the final output of scripts full of control codes.
I am very excited to see this and to play with it!
Check out the ComparesVisually trait! (It's described in the readme too)
It takes some text, outputs it to iTerm and takes a screenshot. Then it takes the same output, runs it through the Screen class, outputs it, and takes a screenshot. Then we compare the screenshots pixel by pixel. So freakin fun
To me, name collisions are only a big deal if the app or project exists in very similar use case scenarios. In this case, I'd say confusion could easily happen if ''screen'' replaced ''screen'' in the path or a call. How about "Soloterm"? Have you thought of others?
Not only confusion, but inability to just install on mac/linux, right? I believe both come with screen by default…
Edit: let me actually think a bit before commenting - it would probably just install, but then you run screen and you might or might not get your newly-installed software (so yeah confusion). Not a great first experience at worst
It seems to me that you can, from within the terminal that it provides, I supposed depending on what shell you run within the emulator. Your example even shows you running tail, so I expect it's running some sort of shell I'd expect screen could be available on.
Unless, this terminal emulator is missing specific features that mean screen doesn't work in it, which would make me feel the definition has been stretched a little here.
Either way, I have to heavily agree with duskwuff's take:
> They're both pieces of software which implement or interact with terminal emulators; I think some deconfliction is warranted here.
Edit: I've learned from a different comment [0] that the latter is indeed the case. This isn't really a terminal emulator.
Thanks, good to know. You and others may have noticed some odd activities in this thread (I use Refined Hacker News and can see them) so I'm glad for your responses to my well-meant comments.
> its type system has historically been an afterthought
This is a rather outdated view. PHPs type system isn't the most expressive thing out there, but it's very achievable to have end-to-end type safety these days. For a start it's possible to delineate between nullable and non-nullable types, something many more "serious" languages don't support.
It has the weakness that, not being compiled, you need an additional static analysis tool to catch these things before runtime. But at least it has the good graces to crash if you tell it you're expecting a Foo and you try to pass a Bar, unlike e.g. Python.
Modern PHP is a completely different thing to the 5.x days. Yeah you still have the inconsistent stdlib, but everything has a few warts after 30 years.
Not so much on the "everything has a few warts after 30 years". Many of the warts were baked-in at the start or in the very early days (like in many other languages), which is why language design is so important. I'm not a Lisp fan, but it doesn't seem very warty; and while I'm not a C# fan either, its stdlib, last I used it, was EXTREMELY well-designed/organized.
I WAS a Ruby fan, but after working in million-line codebases with hit, its warts finally showed up.
I have yet to find any true warts in Elixir; the only one I can think of is how to indicate in a match that a given variable should be matched against instead of reassigned, that's done with the ` character, which threw me off at first.
A simple and accessible example of something Elixir does superior to PHP (and many other languages) is make the first argument to every function the "main thing being worked on", which then enables the pipeline operator to actually be useful. So, every String function expects the string being worked on to be its first argument, enabling chained transformations, which ends up being really nice for readability/maintainability/conciseness.
> The issue isn’t what can be done in PHP, it's what PHP encourages by default:
Lets break this done.
> global state,
PHP is stateless.
> poor encapsulation,
Encapsulation in PHP is mostly consistent with Java.
> inconsistent APIs,
PHP is written in C and an original design decision by those C programmers was to make the APIs consistent with libc.
> and difficult-to-enforce discipline.
Its very easy to enforce. All modern projects would run tools like Pint, Phpcs & Phpcbf to enforce their code standards and preferred style in their CI Pipeline.
> PHP is written in C and an original design decision by those C programmers was to make the APIs consistent with libc.
Old PHP did have some pretty inconsistent naming conventions (or lack of). Which is what I think the GP was referring to.
I’ve not written any PHP in quite a few years but I’ve read that there’s been a concerted effort to address those inconsistencies and the old complaint is now just a relic of a bygone era.
One thing I have learned over the several decades that I’ve been writing software is that literally every language could have a book written about its problems. People often seem to forget that language design is a constant battle of tradeoffs. And because their preferred languages naturally align with their tradeoff preferences, they don’t even realise that their own preferences are deeply flawed for a great many type of scenarios too.
So it really disappoints me when people subscribe to language tribes like it’s their religion.
> literally every language could have a book written about its problems
OK, Elixir's been out for quite a few years now and is used by thousands of people at this point. Find me the "elixir sucks" webpage, which is super easy to find for Go, Python, PHP, Node, Java, and all the rest. And while I'm not a parentheses guy, find the the "Racket Sucks" page while you're at it... The only one I can find, https://www.brinckerhoff.org/blog/2016/04/25/racket-sucks-do..., is a satirical page implying that it will ruin all other languages for you lol. (Hmmm, maybe I should give it another go!)
In short, it is NOT true that all languages are created equal... otherwise everyone would be coding in Assembly, or its close cousin, Brainfuck. ;)
You’re making a strawman argument from a pretty high proverbial horse there ;)
First off: I never said all languages are made equal. Literally the opposite: I said all languages make trade offs.
The fact that languages make trade offs means they’re not equal but rather they’re targeting different requirements.
You referenced Assembly but actually some problems are easier to solve in assembly. In those instances you’ll sprinkle your ASM inside your higher level language like C, Rust, Go, whatever rather than trying to hit everything with the same hammer.
In fact inlining foreign code is a common design pattern in most general purpose languages, eg Python supports CFFI (calling C FFI) for when you reach the limits of what can be done effectively in native Python.
As for Brainfuck, the point of that language is to create an esoteric Turing complete language with the fewest tokens. Readability was very deliberately a tradeoff. So BF is another example of my point.
More generally speaking: a lot of this stuff does just boil down to personal productivity and preferences. Because different people’s brains are wired differently and different people need to solve different types of problems.
You accidentally proved this point when you said “I’m not a parentheses guy” before commenting on Racket.
This is the real crux of language debates. Where you say “PHP sucks” what you actually mean is “I prefer other languages because I solve different problems that aren’t as well suited to PHP”
But being rational like this is hard because bro-programmers love to mock people who aren’t part of their tribe. (This dumb tribalism is probably my biggest pet peeve in tech. People really need to learn to grow the fuck up).
It is completely possible to have a PHP application written 3+ years ago that is well maintained, continues to promote best practices, has excellent test coverage, that isn’t a nightmare to deal with. It’s also possible for the opposite, but that’s the case with every language. In my 20+ years of professional experience, the biggest factor come down to what values a team sets as priorities.
> It is completely possible to have a PHP application written 3+ years ago that is well maintained, continues to promote best practices, has excellent test coverage, that isn’t a nightmare to deal with
Of course, as soon as you depend on PHP code written by others who do not feel the same inclination towards beauty, your codebase's correctness now falls to the level of the lowest-correct dependency you depend on.
You got me thinking again about this (even days later) so I asked ChatGPT to get some insight and man, not only did it make your point clearer, it made MY point clearer TO ME. In lieu of me. While also teasing me lightly about it. LOL, that's extraordinary!
I'm curious how you came to the conclusion that naming it 'screen' was the best thing for your project?
It's unusual to see so many negative comments on a new project announcement and yet you persist and even double down with a sarcastic "thanks for your feedback" reply.
Sure I can explain it a bit.
I named it screen because the main class is called screen. It was extracted from another library to make maintenance easier. It's not a tool that can ever be used outside of a PHP project, and it has no binary. It's namespaced under SoloTerm.
A nice analogy would be a package named @clerk/auth and then everyone complaining about the package being named auth. I mean it is... but that's not really the full name or how anyone would refer to it.
Most commenters didn't understand any of that nuance and got hung up on a surface level thing that didn't really matter. It was clear to me that the suggestion didn't apply in this case so I thanked them for the feedback. I don't have to take the feedback!
Several other folks commented that it's not really an emulator but rather a renderer. I thought that was a pretty good point and something I was wrong about. So I changed the readme! I thanked them for their feedback as well.
It's no secret that HN commenters lean cynical and can miss the majors for the minors. I just don't want to fight with them! I'm grateful for feedback. Some of it I take and some I completely ignore. As everyone should!
> Most commenters didn't understand any of that nuance and got hung up on a surface level thing that didn't really matter. It was clear to me that the suggestion didn't apply in this case so I thanked them for the feedback.
It's more nuanced than just that.
From your README:
> Solo provides a TUI (Text User Interface) that runs multiple processes simultaneously in separate panels, similar to tmux.
You already provide a tool similar to screen. You even call out one of its alternatives! This will lead to confusion.
Further, from another of your comments [0]:
> I use GNU Screen in Solo, where I also use Solo Screen, so I am aware of it.
combined with
> It was extracted from another library to make maintenance easier.
Looking at the code, Solo is the library you extracted it from. You built a technology on top of an existing, well-known project. Then, you extracted some of your code from it and reused the project's name that your tool leverages in that related library.
This is the first way in which your analogy is not sufficient to support your position.
The second is there is no common, well-known, age-old utility called auth in the auth space for people to co-opt.
To quote duskwuff [1] again [2]:
> They're both pieces of software which implement or interact with terminal emulators; I think some deconfliction is warranted here.
Given the context, I don't think namespacing it is a sufficient approach to reducing ambiguity. Especially since screen is often referred to without GNU.
As for this reason:
> I named it screen because the main class is called screen.
Saying you named it screen because the main class was called that isn’t really a justification - especially when you named the class in the first place.
The willful reuse of the utility's name that powers your code and pithy gratitudes all over this thread, to me, send a message of disrespect for the community at large.
[0]: https://news.ycombinator.com/item?id=43439646 [1]: https://news.ycombinator.com/item?id=43439429 [2]: https://news.ycombinator.com/item?id=43439748
I'm sorry you feel that way.
Kudos to you for taking all the heat and handling it gracefully.
Perhaps adding a screenshot or video to the README.md showing what it does could help people understand it better.
Thanks! I know it's probably bizarre behavior to not debate at all in the comments, but man, life is short.
Good note on the screenshot. There are some code samples but I'll think if there's a way to add a visual. It's tough cause it's just a library that you consume in PHP! But I'll noodle nonetheless.
Thanks for all the feedback! I've updated the readme to use the word "renderer" rather an "emulator."
Gonna stick with the name screen though
[flagged]
Every other commenter in this thread would like their comment back ;)
[flagged]
[flagged]
[flagged]
Your comments come across really rude and and condescending and I don’t see why that’s necessary.
The post is a person sharing their open source package, there is no need to act like this. No harm is being done, the name collision truly does not matter and it’s also just a common English word.
[flagged]
[dead]
[flagged]
Is this series of replies some kind of negative reinforcement learning LLM training at work?
[flagged]
[flagged]
script kiddies are now going to have high-fidelity shells with 256 colors for when they pwn you and get root on your godaddy drupal install
sidenote: screen is a terrible name for this as there is already gnu/screen (colloquially referred to as screen) which has 38 years head start - https://en.wikipedia.org/wiki/GNU_Screen
also til screen is older than me
I am also older than you then, probably
I'm a little confused--is it an interactive terminal? Or is it more like an ANSI renderer where you are producing a single static image of the final result of printing a series of bytes? I don't see any JavaScript to hint at interactivity.
Nope. Not interactive. It's a library you can use inside of PHP to implement a virtual screen. The readme has some pretty thorough details!
I don't think you can call this a terminal emulator then.
Maybe not!
Help me understand then. What would you call a library that parses ANSI codes, handles scrolling, screen movement, clearing, resets, etc?
Perhaps something along the lines of an "ANSI terminal renderer library"? I think "render" helps suggest that it's handling the display but that the library consumer still has to handle interactivity and any UI chrome. The consumer is the terminal emulator app and this component is the renderer.
Cool, thanks!
ANSI/VT100 renderer. A full terminal emulator would connect to a tty interface, run subshells and so on.
Nice, thanks!
I was hoping for an actual desktop app powered by PHP, which would be really cool having PHP as a desktop runtime.
You might enjoy https://nativephp.com/
Lol, what? Haven't heard of this... What's your experience with nativePHP?
While i am a defender of modern (!) php for web applications, this does sound rather weird. But also interesting. Thanks for the link.
I wonder though how "native" this is? Glancing over the docs it seems to be built upon tauri / electron? Not as native as i expected, but probably more native than most people would dare to think about...
I haven't used it for anything, but it is developed by some friends of mine. It's certainly a novel approach! And they got it working on iOS too
Lol indeed... I also still love PHP. For most small apps that's my go to backend, because who needs to worry about keeping Node running on some server you forgot about 2 years ago? And it's a fully modern language.
I'm delighted that there's some kind of desktop API here. On the one hand, the fact that it's talking with an Electron shell seems sort of magical. But it begs questions like, why wouldn't I just use a fully JS stack? And... since I've never created a graphical app in PHP before, would this be the right time to start?
I'd also say ...patterns like this that return the object you modified in PHP weird me out, even though they're common in JS going back to JQuery:
>> Dialog::new() ->title('Select a file') ->open();
It's an interesting "modern"-ish design choice, but it doesn't feel very PHP-ish. $dialog = new Dialog('title') followed by $dialog->open() would feel more sane.
That heavily depends on the framework you use. Laravel uses call chains a lot, and with PHP 8.4 (or even 8.3?) you can chain on new:
Just from a high level, chains on 'new' are actually kind of awful. They're bad in a world like JS where lots of classes need to call async functions to spin up, but they're desperately worse in PHP where you really have to consider everything to be a blocking call. Something basic like this could easily hang a whole thread if, e.g. the title chose to read from a remote file. And it would be quite hard to tell what was hanging it. This is when it feels like PHP is getting out over its skis. I understand the desire to keep up with the Joneses, but there's no real penalty to writing your example in three lines rather than one. It's not really functional either way, and it's not especially debuggable either.
How would it make a difference if you split the statements up? A bad API is a bad API, and I’m pretty sure you can design one in any language (e.g. hide a while (true) within an innocuous method). The way to trace it down is the same in PHP as elsewhere, too—use a debugger. All that said, just don’t design shitty APIs and give your methods useful names.
An advantage of being able to chain calls are fluent expressions that you can return immediately, for example from arrow functions or match expressions, which definitely makes for easier to read code.
I can't think of a lot of examples where I'd want to call:
new API()->object->method()->subResult
particularly if the API might block. But I can think of a lot of reasons I wouldn't want to see that in my codebase. Usually starting with the fact that
try {
$api = new API();
}
should have a catch after it.
For local stuff, fine, if you want to write that way. I don't find it eminently more readable than seeing a variable created and employed. And I'd like to see the line number the error was thrown on, if I'm reading error logs in production.
For what it's worth, blocking might not be an issue in the future. There's some discussion on the PHP mailing list about adding async capabilities to the language.
That would be a welcome language feature... my only question would be, how? Node accomplishes it by basically deferring things throughout the main loop. PHP has no main loop; it's not a webserver. The PHP paradigm is terribly ugly but very predictable in one way: You just rely on Apache or Nginx to spin up and kill a new PHP process with each call. In order for a call to last long enough to return something async, you can't rely on checking it the next cycle. There is no next cycle. So anything "async" basically blocks at the end, unless PHP sprouts its own endless loop the way Node does. And then you probably don't want more than one of them running. So it runs contrary to the paradigm.
Many years ago (see my profile), I wrote a PHP socket server that worked a little bit like Node does. The server itself was a CLI daemon. The webserver sent all the API calls to a normal PHP script that acted as a dispatcher. If the dispatcher saw that the daemon wasn't running, it would call the endpoint itself, block and return a result. If the daemon was running, it would accept an external socket connection to the user and keep itself alive, and open an internal socket to the daemon to route the user's API calls through, which would end up in a queue held by the daemon. The daemon responded to the dispatcher over the internal socket, and the dispatcher sent the results to the user as they came in over the external websocket. Thus it went from one PHP process per call to one PHP process per user, kept alive as long as the daemon was running. I actually think this was niftier in some ways than Node, because no one user could hang the whole server - only their own thread. This was a semi-solution for async calls in PHP.
And, if you want or need to spawn new PHP processes as workers that chew on lots of data, and wait for them to send messages back, you can already do that in a multitude of different ways... as long as the main process waits for them, or else aborts.
In any case, blocking API calls inside a multi-part single line of code are lazy and an invitation to disaster.
Sibling mentioned nativephp, but PHP-GTK[0] was also a thing in the past!
[0]: https://gtk.php.net
I am aware modern PHP is actually pretty good, but having grown up with PHP in the 2000s I can't help but get chills up my spine every time I read '$nonWebThing written in PHP'
I've seen massive cli apps and services written in PHP, it's actually pretty good for that sort of thing and given no build or compile step the devex is quite nice.
There's trade offs of course but for things where disk or network is the bottleneck it performs just fine.
And Delphi for PHP.
Alas
...would it?
I guess maybe if it was PHP8 only...
Didn't we have this back in 2001. I seems to remember that we kicked a guy of our project because he installed one of the PHP consoles on our Solaris box, which basically gave it the same rights as the Apache user.
Not sure, I was 12
11 at the time here. For me it would be another 10 years or so before I saw a Solaris box or even knew what one was.
I did encounter, and try, Linux much sooner. But didn’t really “get it” either at the time. Like, I understood that it was neat and different. I installed Mandriva Linux on my machine when I was 13 or 14 or so, but I was lacking any books or guidance to understand how to do anything aside from opening the GUI programs that was on it.
It would take all until the age of 18, when I started at the university, before I got the help I needed in order to understand Linux and editing config files on Linux and writing my own scripts and programs on Linux.
> I installed Mandriva Linux on my machine when I was 13 or 14 or so, but I was lacking any books or guidance to understand how to do anything aside from opening the GUI programs that was on it.
It was Gentoo for me at the age of 13 that a random Hungarian guy from Finland helped install through SSH.
I did try SUSE around the age of 11, nothing interesting though, the interesting stuff came after Gentoo. :D
To be fair in 2001 php was the underdog of tech stack. It has just got ride of the PHP (Personal Home Page) taste in the language mouth. So wouldn't be surprised if some company running solaris would kick him off.
Interesting. I remember php being on top at that time, with JSP just starting to take over. I was in a rural area, though, and our local developers were far more influential than any internet community during that period.
It's still a mainstay of certain malware for sure. Just pop in 'php shell' to your favorite search engine, and it's basically all stuff for either red teaming or shenanigans
Oh, interesting!
I started a very similar project probably ten years ago and just never got it to a very usable state. My idea at the time was based in wanting to be able to write tests for the final output of scripts full of control codes.
I am very excited to see this and to play with it!
Check out the ComparesVisually trait! (It's described in the readme too)
It takes some text, outputs it to iTerm and takes a screenshot. Then it takes the same output, runs it through the Screen class, outputs it, and takes a screenshot. Then we compare the screenshots pixel by pixel. So freakin fun
Does it render to plain text or styled HTML? Not quite clear from the readme.
Commendable work but note that this is not a terminal emulator. This is a terminal renderer.
What functionality does a program need to emulate to be a terminal emulator?
Interactive use.
You just made that up, didn't you
Everything is made up initially, isn’t it?
Thank you!
Nice, but your terminal app has a name collision with the long lived ''screen'' terminal multiplexer utility:
https://www.gnu.org/software/screen/manual/screen.html
Thanks for your feedback!
To me, name collisions are only a big deal if the app or project exists in very similar use case scenarios. In this case, I'd say confusion could easily happen if ''screen'' replaced ''screen'' in the path or a call. How about "Soloterm"? Have you thought of others?
Not only confusion, but inability to just install on mac/linux, right? I believe both come with screen by default…
Edit: let me actually think a bit before commenting - it would probably just install, but then you run screen and you might or might not get your newly-installed software (so yeah confusion). Not a great first experience at worst
It's a package you install into your PHP application. It's impossible for it to collide. You cannot run Solo Screen as a standalone tool.
Heh, should’ve thought a bit longer apparently. But, in my defense, I work an office job and it’s Friday evening. Iykyk
It's a package you install into your PHP application. It's impossible for it to collide.
They're both pieces of software which implement or interact with terminal emulators; I think some deconfliction is warranted here.
> Question: can you call GNU screen from within screen?
No. It's literally just an in memory buffer that you interact with from PHP.
In Solo (https://github.com/soloterm/solo) we do use GNU screen though.
It seems to me that you can, from within the terminal that it provides, I supposed depending on what shell you run within the emulator. Your example even shows you running tail, so I expect it's running some sort of shell I'd expect screen could be available on.
Unless, this terminal emulator is missing specific features that mean screen doesn't work in it, which would make me feel the definition has been stretched a little here.
Either way, I have to heavily agree with duskwuff's take:
> They're both pieces of software which implement or interact with terminal emulators; I think some deconfliction is warranted here.
Edit: I've learned from a different comment [0] that the latter is indeed the case. This isn't really a terminal emulator.
[0]: https://news.ycombinator.com/item?id=43438797#43439716
Thanks, good to know. You and others may have noticed some odd activities in this thread (I use Refined Hacker News and can see them) so I'm glad for your responses to my well-meant comments.
Yeah someone's really got a vendetta against SA and HN right now huh? Weird stuff!
Question: can you call GNU screen from within screen?
[flagged]
> its type system has historically been an afterthought
This is a rather outdated view. PHPs type system isn't the most expressive thing out there, but it's very achievable to have end-to-end type safety these days. For a start it's possible to delineate between nullable and non-nullable types, something many more "serious" languages don't support.
It has the weakness that, not being compiled, you need an additional static analysis tool to catch these things before runtime. But at least it has the good graces to crash if you tell it you're expecting a Foo and you try to pass a Bar, unlike e.g. Python.
Modern PHP is a completely different thing to the 5.x days. Yeah you still have the inconsistent stdlib, but everything has a few warts after 30 years.
Good point on the type thing.
Not so much on the "everything has a few warts after 30 years". Many of the warts were baked-in at the start or in the very early days (like in many other languages), which is why language design is so important. I'm not a Lisp fan, but it doesn't seem very warty; and while I'm not a C# fan either, its stdlib, last I used it, was EXTREMELY well-designed/organized.
I WAS a Ruby fan, but after working in million-line codebases with hit, its warts finally showed up.
I have yet to find any true warts in Elixir; the only one I can think of is how to indicate in a match that a given variable should be matched against instead of reassigned, that's done with the ` character, which threw me off at first.
A simple and accessible example of something Elixir does superior to PHP (and many other languages) is make the first argument to every function the "main thing being worked on", which then enables the pipeline operator to actually be useful. So, every String function expects the string being worked on to be its first argument, enabling chained transformations, which ends up being really nice for readability/maintainability/conciseness.
> The issue isn’t what can be done in PHP, it's what PHP encourages by default:
Lets break this done.
> global state,
PHP is stateless.
> poor encapsulation,
Encapsulation in PHP is mostly consistent with Java.
> inconsistent APIs,
PHP is written in C and an original design decision by those C programmers was to make the APIs consistent with libc.
> and difficult-to-enforce discipline.
Its very easy to enforce. All modern projects would run tools like Pint, Phpcs & Phpcbf to enforce their code standards and preferred style in their CI Pipeline.
> PHP is written in C and an original design decision by those C programmers was to make the APIs consistent with libc.
Old PHP did have some pretty inconsistent naming conventions (or lack of). Which is what I think the GP was referring to.
I’ve not written any PHP in quite a few years but I’ve read that there’s been a concerted effort to address those inconsistencies and the old complaint is now just a relic of a bygone era.
One thing I have learned over the several decades that I’ve been writing software is that literally every language could have a book written about its problems. People often seem to forget that language design is a constant battle of tradeoffs. And because their preferred languages naturally align with their tradeoff preferences, they don’t even realise that their own preferences are deeply flawed for a great many type of scenarios too.
So it really disappoints me when people subscribe to language tribes like it’s their religion.
> literally every language could have a book written about its problems
OK, Elixir's been out for quite a few years now and is used by thousands of people at this point. Find me the "elixir sucks" webpage, which is super easy to find for Go, Python, PHP, Node, Java, and all the rest. And while I'm not a parentheses guy, find the the "Racket Sucks" page while you're at it... The only one I can find, https://www.brinckerhoff.org/blog/2016/04/25/racket-sucks-do..., is a satirical page implying that it will ruin all other languages for you lol. (Hmmm, maybe I should give it another go!)
In short, it is NOT true that all languages are created equal... otherwise everyone would be coding in Assembly, or its close cousin, Brainfuck. ;)
You’re making a strawman argument from a pretty high proverbial horse there ;)
First off: I never said all languages are made equal. Literally the opposite: I said all languages make trade offs.
The fact that languages make trade offs means they’re not equal but rather they’re targeting different requirements.
You referenced Assembly but actually some problems are easier to solve in assembly. In those instances you’ll sprinkle your ASM inside your higher level language like C, Rust, Go, whatever rather than trying to hit everything with the same hammer.
In fact inlining foreign code is a common design pattern in most general purpose languages, eg Python supports CFFI (calling C FFI) for when you reach the limits of what can be done effectively in native Python.
As for Brainfuck, the point of that language is to create an esoteric Turing complete language with the fewest tokens. Readability was very deliberately a tradeoff. So BF is another example of my point.
More generally speaking: a lot of this stuff does just boil down to personal productivity and preferences. Because different people’s brains are wired differently and different people need to solve different types of problems.
You accidentally proved this point when you said “I’m not a parentheses guy” before commenting on Racket.
This is the real crux of language debates. Where you say “PHP sucks” what you actually mean is “I prefer other languages because I solve different problems that aren’t as well suited to PHP”
But being rational like this is hard because bro-programmers love to mock people who aren’t part of their tribe. (This dumb tribalism is probably my biggest pet peeve in tech. People really need to learn to grow the fuck up).
Great points all, admittedly!
I think I'm scarred by having churned too many man-hours supporting spagetti ASP code and Ruby "magic" behavior.
Thanks for the... rant? Sorry you've had such a rough time.
I use GNU Screen in Solo, where I also use Solo Screen, so I am aware of it.
https://github.com/soloterm/solo/blob/main/src/Commands/Conc...
It is completely possible to have a PHP application written 3+ years ago that is well maintained, continues to promote best practices, has excellent test coverage, that isn’t a nightmare to deal with. It’s also possible for the opposite, but that’s the case with every language. In my 20+ years of professional experience, the biggest factor come down to what values a team sets as priorities.
> It is completely possible to have a PHP application written 3+ years ago that is well maintained, continues to promote best practices, has excellent test coverage, that isn’t a nightmare to deal with
Of course, as soon as you depend on PHP code written by others who do not feel the same inclination towards beauty, your codebase's correctness now falls to the level of the lowest-correct dependency you depend on.
You come across as pretty opinionated and eager to comment for someone who states they don't care.
I work with spaghetti PHP every day. It pays the bills. There are far worse jobs out there.
The expert wishes to fix the tedious tasks. But a true master understands that all tasks are equally tedious.
Relax and enjoy the ride.
You got me thinking again about this (even days later) so I asked ChatGPT to get some insight and man, not only did it make your point clearer, it made MY point clearer TO ME. In lieu of me. While also teasing me lightly about it. LOL, that's extraordinary!
https://chatgpt.com/share/67e8ad11-86f0-8004-8194-1c631a2331...
> There are far worse jobs out there.
Fair enough. But there are also far better. I can't help caring about this one. It's a curse. lol
I have some Oracle Pro*C code that is infinitely more pleasant to use when I rewrite it in PHP.
I don't think the PHP version has greater entropy than the compiled C.
as your average PHP enjoyer, I agree with all of these complaints, but also will note
- you really need to train the team on PHP footguns, which are as bad as C foot guns
- finding PHP programmers is easy.
- your shits already written in PHP
- in the same way rolling your own stdlib in C is silly, leverage good PHP frameworks
ymmv but its not that bad. at least it keeps my day exciting.
fair points.
looking back on this comment from 3 days ago... all I can say is that my toddler kid isn't sleeping through any night consistently :/
we need low barrier to entry langs, it affords some a start. Also The php symfony components are very well written; I recommend giving them a look
Fair enough, but I also know a few guys who started in PHP and then never left it, and I kind of feel bad for them