-
Notifications
You must be signed in to change notification settings - Fork 2
List of problems
This is a rather random list. With your help, we can improve it and make it easier to use. But we had to start somewhere.
Features:
- Can read data from a file or stream in that format
- Allow for language extensions
Hint:
- Support only a subset of the language
Goal ideas:
- Try to do it single pass (only read forward, never go back)
- Compare performance with existing parsers (especially for large files)
Hint: you don't have to support the full language, just enough to learn about the problem and its solutions
Database engines sound very complex. However, if you pick only a subset (eg. no indexing), and don't support SQL, they become more approachable.
- Support a few data types (eg: number, string, binary, date)
- CRUD operations
- On disk and in-memory storage
- Users and access rights (keep it simple)
- Optimize for read-only or for read/write
- Replication
- Transactions
- Concurrency
- Storage, indexing and retrieval
- Concurrent access and transactions
- Performance implications of storage
- Distributed storage systems
- Easily allow adding other data types
- The book Database Systems: The Complete Book is the ultimate reference.
- For an easier start, the book Data intensive applications is very useful.
Writing a programming language sounds like a huge task. And it is, provided that you want other people to use it as well. Fortunately, this is only a design study, so we don't have to do much. Based on experience, a few days are enough to have a minimum programming language working.
- Print to console and read from console
- Basic data types
- Basic collection types (stack, maybe list)
- Mathematical and boolean operations
- Functions
- Branching (if or switch or an alternate syntax)
- Loops (or higher order functions)
- Classes / objects
- Integration with other programming languages
- Exceptions
- Recursion
- General purpose language or DSL (internal / external) for a specific domain
- Extensibility: allow addition of more data types, allow extension of existing collections or data types etc.
- Performance (for specific operations)
- An interpretor is easier to write than a compiler
- Internal DSLs are easier to write than external DSLs or general purpose languages. Some languages support internal DSLs better.
- Don't worry if you don't know how to use grammars, compiler-compilers and other tools; just write your own syntactic and semantic parser. It'll work well enough for a small language.
- Single-pass syntactic parsers are easier to implement (aka only read forward, never go back)
- If you know how to use advanced tools, or if you want to learn how to use them, then go for it
- Compiler-compiler article from wikipedia
- Martin Fowler's book on DSLs and the patterns catalog
- Groovy videos on writing internal DSLs (very technology specific)
Tetris is a well-known game, and quite easy to implement. There's no need for AI, path-finding, terrain generation etc., but it has the common design characteristics of a game: the game cycle, rendering, colision detection etc.
Games have specific design needs, and we can reuse their lessons in some of the modern dynamic web/ mobile/desktop UIs.
- All the rules of tetris, with all pieces, rotation and translation
- Scoring
- Leader board
- Save / load game
-
Changeability:
- Allow control with mouse, keyboard, gamepad, and other devices. That is, separate the actions from the event that triggers them
- Support multiple renderers: text-based in console, opengl, some type of canvas (web, mobile, desktop)
- Enable multiple ways to save game data - on disk, on a database, through a web service
-
Performance:
- Measure frames per second and improve them as much as possible
- Ensure fps stays constant while saving / loading etc.
-
Incremental design:
- Start with a well of depth 10 and width 1, and with a single square piece. Grow the design slowly towards the result. Of course, use TDD to do it.
Chat systems are the simplest type of network-based application. They introduce many interesting challenges though.
- List chat users
- Create a chat room
- Chat (text-only)
- File transfers
- Emoticons
- Special commands (eg. \b = buzz)
- Privacy
- Logging of chats
-
Design your own protocol:
- Implement the minimal features, then add different clients: command line, web, desktop. Compare the resulting protocol with IRC (and others)
-
Operational concerns:
- How can you ensure scalability, performance, resilience, security?
-
Distributed application models:
- Peer to peer vs centralized