ross-software/Shell

Python Considered Harmful

Closed this issue · 8 comments

The use of python taxes elegance, runtime speed, flexibility, development time (on occasion), and clarity. For this reason, I propose it be avoided at nearly any cost expendable. Alternatives include:

  • GLFW with C/C++ (cross-platform, fast, elegant)
  • gfx with Rust (cross-platform, fast, non-elegant)
  • Xlib with C (Linux-only, fast, elegant)
  • Various window managers, including dwm, xmonad, i3, anything

I should add that the insistence on cross-platform accessibility for a graphical utility that is environment-sensitive (i.e. sensitive to what window is currently active), dispatches external programs, and is configured in plaintext as is common in the UNIX spheres, will be scarcely possible a demand to maintain. I recommend we choose either UNIX or Windows. I, as a Linux user (and a programmer competent of the innumerable pitfalls presented by Windows), would recommend we choose UNIX.

I do not want to use a window manager. the reason is if I lock down the software to a particular window manager, than nobody else can use it. Like how dwm has swallow terminal windows: I want that to be a common thing.
But I think GFLW seems the best, given the description. Also, seeing that you think we can't do it in Windows, I think we should just stick to UNIX. Make a proof of concept, and if it's good, we can implement in windows.

If we're sticking to UNIX, Xlib will most likely be superior; however GLFW has the benefit that it will likely make Windows-migration easier.

The reason is the Xlib is basically designed for what we're doing; 2D interoperation with a non-windowed system using textures. However, GLFW has numerous (primarily 3D) optimizations and abstractions that require sort of shoehorning 2D development into an alternative framework.

I don't really have any experience on this topic, I just write crappy bash scripts. I do have a leaning toward C++, mostly because you can write C code but if you want to write something that's unavailable in C, you have that. However, if the benefits of xlib outweigh the cost, than I'll vote for xlib. However, since this is likey to be a group thing, I want to put it to a poll, so strawpoll.me/20316656 and I'll include it in a new document call Issues.md

The reason is the Xlib is basically designed for what we're doing; 2D interoperation with a non-windowed system using textures. However, GLFW has numerous (primarily 3D) optimizations and abstractions that require sort of shoehorning 2D development into an alternative framework.

I just saw this, and yea xlib seems much better. Can we write C++ code using xlib, or am I wrong to begin with for wanting to use C++? Again, I want to empathize this comes from an amateur programmer view, so I'm sorry if I don't know this obvious things. I know dwm is written in C, and a lot of unix programs are written in C, but I like C++ exclusive stuff like anonymous functions or streams.

C++ can work with Xlib (I think), however it will be a much more painful experience. If what you're after is STL, know that C has (superior) alternatives, primarily those provided in the stb libraries, which we would be using anyhow to load image data. C indeed does have streams (it's POSIX-friendly) but it unfortunately doesn't have anonymous functions idiomatically. However, anonymous functions are primarily a declarative and functional feature that would provide little to no benefit in C. If we're opting for a declarative style (a change I'm not opposed to), I'd recommend we use Haskell, as it has X11 bindings too.

If C has a standard library that's comparable to C++'s standard library, than I have no problems with using C. However, haskell is a big stretch. Less people will contribute, sense Haskell isn't as known, and not only that, but I had a bad time with haskell. I try learning it for a week, but man it's super difficult. This week I tried to configure xmonad, and gave up when I tried to make my own xmobar. Again, this is pure bias, and if I'm proven that haskell is just better than C for this project, than sure we can use haskell. But it seems C with xlib is the best option. Thank you @arawnx for you this.

No worries! I agree, Haskell would be somewhat isolating in terms of contribution (you see this with Pandoc, which I believe to be the largest libre userland Haskell software, and still has relatively few good contributors).