Project ideas and plans - Programming On Unix
Users browsing this thread: 8 Guest(s)
|
|||
I often have ideas for programs.
Sometimes these ideas are quite silly, sometimes I throw them away quickly, but interestingly, few ideas stick. I assume that at least some of you are in a similar situation, because getting programming project ideas is a lot easier than implementing these ideas. This thread is for presenting your project ideas, discussing them and getting inspired. Here are my ideas, written down: https://github.com/scharlatan/notes/blob/master/ideas |
|||
|
|||
(03-02-2016, 04:30 PM)pranomostro Wrote: Here are my ideas, written down:Those are ok ideas. Not that much interested in them myself but they are not bad. I also have my bunch of crazy projects going on but the thing is that I don't just write them down, most of the time I start right away. I can't stand having ideas and not implementing them. Thus, if I want to share something I'm working on with the community I'll post it in the "What are you working on" thread ;D. |
|||
|
|||
I wish I'd be as commited to my projects as venam, but I can't handle multiple projects at the same time.
so until one project is "finished" (by that I mean working, and under maintenance), I keep a list of ideas in my head, or on ~/.todo for things I might forget. On my todo-list right now:
One day, maybe... :) |
|||
|
|||
|
|||
|
|||
|
|||
I have a 'stable' directory with projects where no features will be
added and where no rewrites will occur, and a 'begun' directory with fresh projects. Projects in stable: 16 projects in begun: 3 |
|||
|
|||
I have lot's of projects I start and then abandon as I realise I'm nowhere near good enough to implement them... and a lot of it is done in haskell as I'm too lazy to write them in C/Scheme. So, The following is a list of non uni projects:
Projects queue:
Would like to work on a group project as I haven't had a chance to yet... (thanks uni... the others can't program outside of python and java) |
|||
|
|||
@venam:
I found it very bad to start with every project that comes into my mind. Even before I write the idea down, I think about the usefulness of it, search if there is not already a similar project, and then write it down. @z3bra >posix shell (yacc) Do you want to write a standard compliant sh, or rather something with useful extensions, or a completely new shell? @novas: I thought about doing something with voice recognition as well, but after reading a bit into that topic I decided that I am not crazy enough for this (yet). >lambda calculus interpreter I liked this one: https://github.com/mpu/lambda |
|||
|
|||
The idea dcat and I had was to write a stricly posix shell, but with features making it suitable for interactive use. Something that would fill the gap between dash and mksh for example.
|
|||
|
|||
What do you plan to make it suitable for interactive usage?
|
|||
|
|||
I imagine a vi-mode and tab completion are the key points.
|
|||
|
|||
Most needed features are history, completion and line edition. Anyway, this is still a "dormant" project. Few (if any) lines of code have been written so take it as such (there are many other projects lke this to be honest :p)
|
|||
|
|||
I start a lot of projects. Some of them get finished, some of them just lurk on my GitHub profile forever. Here's the current TODO list:
# po (my main project right now) * minimal lisp implementation * I think common lisp sucks, and want something that's terser, easier to script and simpler to embed (C interpreter is only 300 sloc of C right now). * GitHub: http://github.com/charles-l/po # lisp video editor (all the video editors on linux suck, and I've never seen a video editor that's scriptable, even though there are lots of repetitive tasks during editing). I'll probably use Gstreamer (since the FFMPEG libraries are overkill). # vim-like text editor written in lisp/scheme (so it's easy to write plugins/hook into editor, etc) * I've been collaborating on a project like this, but haven't made a whole lot of progress yet. I'll need to get back to it soon: https://github.com/kiasaki/ry # A minimal Unix-like that really sticks to the philosophy (Linux seems to be slipping further and further away). I'm hoping to go with a microkernel design, because I think the design is more extensible (noticing a pattern here? ;) * Some basic code can be seen here: http://github.com/charles-l/ix * Currently, it just has basic interrupt handling and memory visualization. No heap, process management, filesystem or userspace yet. # C compiler * I'm not a fan of GCC because of it's size/bloat, and I don't like Clang because it's C++. tcc sometimes doesn't generate executables that work. I'll probably write this as I need it (like when I need a userspace C compiler for my OS). # Linux syncing * This is just a vague idea at the moment, but I want to be able to "sync" my laptop with my desktop when I plug it in when I get home from school (i.e. copy tabs across, move tmux sessions over to main desktop, turn laptop into second monitor). Like I said, this is very fuzzy right now, so I need to actually look into it. EDIT: I can't seem to get this to format right... :P |
|||
|
|||
(07-02-2016, 10:57 PM)ninjacharlie Wrote: # C compiler You should definitely look into [pcc](http://pcc.ludd.ltu.se). Sadly, many programs rely heavily on gcc extensions to compile, and can't be compiled with pcc. It's still the closest we can get from a generic C compiler. |
|||
|
|||
@z3bra, @ninjacharlie:
There are of course also https://www.github.com/andrewchambers/c, git.suckless.org/scc and https://www.github.com/rui314/8cc. I would love to use one of these, but tcc for example does not produce symbols for gdb and can't be used with musl. But I would rather try to improve an existing C compiler/standard library that does not suck instead of making a new one. I mean, pcc, tcc, 8cc, scc and c are already enough compilers for this world. And there are also enough C standard library implementations (muslibc, ulibc, and dietlibc). Just getting one of these working with one of the others would be a huge step forward. Writing a new C compiler is not the answer (imho). The same is true for lisp interpreters, text editors and kernels: in another thread I already mentioned tinyscheme, which is a quite beautiful scheme implementation in ~5000 lines of C, it is complete, stable and all of that. Because of this I don't see any reason to develop yet another lisp interpreter which is a little bit different from a good, bug-free and existing one. If you are searching for a scriptable vi-compatible editor, there is for example [vis](https://www.github.com/martanne/vis). Yes, I know, the scripting is in lua, but I am also sure that there is an existing vi with lisp integration as well. I don't see what is so bad about minix either. To me, it seems like minix is a quite nice microkernel in ~12000 lines of code, with more than 20 years of constant development. Of course, nih is a trap I fall into myself a lot of times. I mean, on my ideas list, there are 7 ideas for new programming language implementations. Because I know this is not a good thing, I decided to put forks and contributions to other projects first. I research if there is an implementation of what I want to write, and if it adheres my standards of code. If it does, I throw away my plan, and try to write things I consider fun or important (whatever). -------END OF RANT I hope this was not too rude. If it was, ignore it. |
|||
|
|||
(08-02-2016, 04:21 AM)z3bra Wrote: You should definitely look into [pcc](http://pcc.ludd.ltu.se). Sadly, many programs rely heavily on gcc extensions to compile, and can't be compiled with pcc. It's still the closest we can get from a generic C compiler. Hrm... I've seen that one before but never looked to closely at it. Even if it requires GCC to compile, those extensions could always be added to PCC itself ;) (08-02-2016, 11:38 AM)pranomostro Wrote: The same is true for lisp interpreters, text editors and kernels Oh, I know that there are successful projects for any of the things I'm trying to solve. I only half want to write a new project because I expect anyone else to use it. Mostly, any of these are learning projects to get a better understanding of compilers and operating systems. I've already picked up a lot from writing my own OS and hope to be able to contribute to some of the larger projects (like Minix and Linux), at some point. Also, I always have the foolhardy idea that I can write it in less lines of code ;) |
|||
|
|||
@ninjacharlie:
Okay, seems legit. |
|||
|
|||
That was an interresting comment there. I do agree with you when you say that, for example, anither C compiler is not the answer, but I definitely think that we NEED multiple implementations of everything. Leaving too much power to a sngle entity is never a good choice... Imagine if there was a single linux distro? A single text editor? We would all be doomed and tied to the will of the developpers. Speaking of C (I don't know lisp), it's good thing that uclibc and musl are know well known and recognized, as people start writing code that's much more portable and gnu-agnostic. This is a huge step forward, and the more diversity we'll have, the more generic amd portable interfaces will be, at least, I hope. Diversity enforces standards, instead of simply defining them, that's why it's important. You can scream POSIX as much as you want, people won't care as long as they will meet bash as /bin/sh everywhere.
Nevertheless, diversity should be taken with care, and people should ALWAYS try and see how they can contribute to improve a flawed project. Sometime it's simy not possible, as you might have a different opinion from the author, or the project is simply broken by design. In this case then, an alternative can be considered. A coding style is no excuse to fork a project for example ;) Either innovate, contribute, or reinvent. The rest is bullshit. |
|||
|
|||
I guess there is a very fine line between diversity and and a fractured ecosystem.
And I would not care about the number of C compilers and standard library implementations if I would actually make them work together. Damn. I should write more pull-requests. |
|||