Top products from r/AskProgramming

OK, a few things:

It looks like you're trying to build a shift/reduce parser, which is a form of an LR parser, for your language. LR parsers try to reduce symbols into more abstract terms as soon as possible. To do this, an LR parser "remembers" all the possible reductions that it's pursuing, and as soon as it sees the input symbols that correspond to a specific reduction, it will perform that reduction. This is called "handle finding".

> If I am correct, my Automaton is a DFA?

When the parser is pursuing a reduction, it's looking for sequences of symbols that match the right-hand sides of the relevant (to our current parse state) productions in our grammar. Since the right-hand sides of all the productions in a grammar are simple sequences, all the handle finding work can be done by a DFA. Yes, the handle recognizer of your parser is a DFA. But keep in mind that it needs to be combined with other parts to make a full parser, and your actual grammar can't be recognized with just a DFA.

In particular, you've shown the ACTION table for a shift/reduce parser. It determines what to do when you encounter a symbol in the input stream. But a shift/reduce parser typically needs a second table as well - the GOTO table - that determines what to do after a reduction has taken place.

One other thing that's worth mentioning: you've expressed your ACTION table as a plain DFA transition table. That's not necessarily wrong, but it's not commonly done that way. Instead of reducing when you reach a certain state, it's common to instead attach an action - either 'shift' or 'reduce' ('accept') - to each transition itself. So in a shift/reduce parser, your table might look more like this:

| [ | ] | < | > | id | / | attr
----+-----+-----+-----+-----+------+-----+--------
0 | S1 | | S4 | | | |
1 | | | | | S2 | | R3 : Reduce Tag -> [ id ]
2 | | R3 | | | | | R7 : Reduce Tag -> < id ??? / >
4 | | | | | S5 | S10 | R9 : Reduce Tag -> < id ??? >
5 | | | | R9 | | S6 | S8 R12 : Reduce Tag -> < / id >
6 | | | | R7 | | |
8 | | | | R9 | | S6 | S8
10 | | | | | S11 | |
11 | | | | R12 | | |

Note that R7 and R9 aren't well-formed, since multiple sequences of input tokens might cause you to reach these actions. While it would be possible to construct a shift / reduce parser this way, it's not commonly done. Typically, the DFA to recognize handles is an acyclic graph, but your have a self-transition in state 8.

> What would be the best way of implementing this automaton in C++? Do I really have to make a huge array?

In general, yes, you need a big array (or, as suggested before, two big arrays). But you can use any space-saving technique you want. For example, since most entries in the ACTION table are invalid, one could represent that data with a sparse array data structure. Also, both The Dragon Book and Cooper and Torczon briefly cover parser-specific ways to compress those tables. For example, notice that rows 5 and 8 in your example have the same entries. Most real grammars have multiple instances of identical rows, so factoring out this commonality can save enough space that the extra complexity is worth it.

---

I'm a little surprised that you're building a parser like this by hand, though. Typically people do one of two things:

1. Build, by hand, a modified LL(1) recursive descent parser (or variant, like a packrat parser)
   
2. Build, using a tool like YACC or Bison, a LR(1) shift/reduce parser
   
   You're sort of doing a mix of the two, which means you have the downsides of both approaches. You need to track all the states and transitions by hand, instead of relying on tools to automate that process, yet you don't get the flexibility of a hand-coded recursive descent parser.
   
   If you're doing this for education's sake, then by all means proceed. I'd highly encourage you to pick up a book on parsing; I think Cooper and Torczon is a great source. But if you just want a parser that works, I'd definitely recommend using a tool or using a more direct approach, like recursive-descent.

One of the biggest issues I see with some of the dev's I work with is that they easily get lost in their work. We refer to it as shaving a Yak. Let's say you need to go pick up some milk at the store, but before that you need to fill up your gas tank. But before that you need to change the oil in the car. But before that you need to help your parent access their email. The next thing you know you're in your living room shaving a Yak asking yourself how you got into this situation. All you wanted to do was get some milk.

You would be better off identifying the core features of your project and concentrating on them, one at a time. What are these core features, what is the value of this feature, and what is the minimum amount that would satisfy that feature. If you're creating a car, you would need a motor to drive the wheels, but a a motor has nothing to do with how to steer a car. You've identified two separate features, one for the motor and one for the steering. I'm not talking about sitting down and writing out full specs and requirements. Just get a basic idea of what are the different parts of what you are building. You'll miss some but that's ok. Find a few features, pick one, and start.

Stay focused on that feature. Hack it together, make it work. But make sure that what you're hacking together is only for that feature. The code you're writing at the time should be responsible for solving that feature, alone. Even if you think that what you're creating can be used for another feature, or that you're repeating something that you made earlier, or you've discovered some new feature that you missed initially (and you will), ignore the impulse to optimize or start adding new features in the middle of your task, you will come back to it later. Just make sure you make notes about those things discovered.

When you're code does what it is supposed to and you've proven it with unit tests (you do have unit test right?), then you can start refactoring. Clean it up, move it around, optimize it, look for areas that a design pattern can fix. Give it a good S.O.L.I.D. overview (if you're working in an OOP language). As long as you have unit tests covering the core responsibilities of your features, you can make changes with confidence.

Once you're satisfied, you can move on to the next feature and repeat. As you complete more features, you can re-address some of the completed code during subsequent refactors. Working like this will ensure that
a) your code works as intended because you've proven it with unit tests
b) your code will be loosely coupled because you were forced to work on a single responsibility at a time.

Refactoring is probably the main take away. But being able to pick specific milestones along the way is important. If you leave it all up to the last minute, it will be easy to get overwhelmed.

So book recommendations:
Martin Fowler's Refactor - https://martinfowler.com/books/refactoring.html
Uncle Bob's Clean Code - https://www.oreilly.com/library/view/clean-code/9780134661742/
Steve McConnell's Code Complete - https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670

Here's part of a passage that really explains the differences well. I hope it's as helpful for you as it was for me.

This is from Problem Solving and Program Design in C:

Section 2
The College experience: Computer Disciplines and Majors to Choose From

Computer Science

> Computer science as a discipline encompasses a wide range of topics from theoretical and algorithmic foundations to cutting-edge developments. The work computer scientists are trained to do can be arranged into three categories:

> Designing and implementing useful software
> Devising new ways to use computers
> * Developing effective ways to solve computing problems

>A computer science degree consists of courses that include computing theory, programming, and mathematics. These courses ultimately develop the logic and reasoning skills integral to becoming a computer scientist. The math sequence includes calculus I and II (and in many cases, calculus III) as well as discrete mathematics. Some students also study linear algebra and probability and statistics. A computer science degree offers a comprehensive foundation that permits graduates to understand and adapt to new technologies and new ideas. Computer science departments are often found at universities as part of the science, engineering, or mathematics divisions.

> Computer scientists take on challenging programming jobs, supervise other programmers, and advise other programmers on the best approaches to be taken. Computer science researchers are working with scientists from other fields to perform such tasks as using databases to create and organize new knowledge, making robots that will be practical and intelligent aides, and using computers to help decipher the secrets of human DNA. Their theoretical background allows them to determine the best performance possible for new technologies and their study of algorithms helps them to develop creative approaches to new (and old) problems.

Software Engineering

> Software engineering (SE) is the discipline of developing and maintaining large software systems. These systems must behave reliably and efficiently, be affordable, and satisfy all requirements defined for them. SE seeks to integrate the theory of computer science and mathematics with the practical engineering principles developed for physical objects.

> An SE degree program is closely related to the computer science degree
program, and they are usually offered within the same department. In fact, most computer science curricula require one or more software engineering courses. An SE degree can be considered a specialized degree within the confines of the field of computer science.

> SE students learn more about software reliability and maintenance of large systems and focus more on techniques for developing and maintaining software that is engineered to be correct from its inception. Most programs require SE students to participate in group projects for the development of software that will be used in earnest by others. Students assess customer needs, develop usable software, test the product thoroughly, and analyze its usefulness.
Professionals who hold a software engineering degree expect to be involved with the creation and maintenance of large software systems that may be used by many different organizations. Their focus will be on the design principles that make the system viable for many people and through many years.

> Although an SE degree has a recognized description, the term software engineer is merely a job label in the workplace. There is no standard definition for this term when used in a job description, and its meaning can vary widely among employers. An employer may think of a programmer or an IT specialist as a software engineer.

Code Complete.

The fantastic blog Coding Horror (written by one of the founders of StackOverflow) has this to say about it:

> Steve McConnell's Code Complete 2 is the Joy of Cooking for software developers. Reading it means that you enjoy your work, you're serious about what you do, and you want to keep improving. ... Do yourself a favor. Make this the first book you read, and the first book you recommend to your fellow developers.

This book has made balloonanimalfarm a much better programmer. It will save you time by making your designs better at the start of the project, helping you do good defensive programming so bugs come out right away, refactor well when the project becomes too big, choose the right scale of algorithms for your project, and make high quality software.

These are great suggestions. The three books I typically give devs early (that fit in well with the two presented here) are:

Refactoring by Martin Fowler

This is a list of patterns of common refactoring a and how to do them safely. It’ll help you recognize transforms you need to make in your code as it changes.

The Pragmatic Programmer by Dave Thomas and Andy Hunt

This is a great guidebook for how to get better at being a software engineer. Essential read.

And while there are lots of options for design patterns books...

Head First Design Patterns was the one that helped me internalize them. Even if you aren’t writing much (or any) Java, the method of teaching is hugely valuable.

"The C Language", generally referred to as "K & R" after the authors, is pretty old but still a wonderful book. (C is pretty old too, after all.)

You'll eventually want to supplement it with some newer material but it's such a well-written book that it's great to start with.

Just a few ideas...

• Nerdy stuff from ThinkGeek.
  
• A Raspberry Pi kit, if you think he'd be into tinkering with hardware.
  
• It's probably going to be more than $70, but a nice mechanical keyboard is a great gift. Das Keyboard, Code, and Logitech G710+ are safe choices.
  
• Book-wise, consider Code. It's a classic for every programmer to read.

Petzold's CODE: The Hidden Language of Computer Hardware and Software. Great book that will give you a good understanding of what makes computers and software tick. No programming required.

Kernighan's The Practice of Programming. This book discusses how one programs. It isn't a book that teaches you a language and it probably is a bit advanced for a complete beginner, but it's great to have in your library. Reading it even before you can code will give you some aha moments when you begin to learn and will give you a good foundation of how one should go about writing a program.

• Write better code (this is essentially the bible, language independent):
  http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
  
  
• Excellent books to prepare for interviews:
  http://www.amazon.co.uk/Cracking-Coding-Interview-6th-Programming/dp/0984782850/ref=sr_1_1?s=books&ie=UTF8&qid=1452714513&sr=1-1&keywords=cracking+the+coding+interview
  
  http://www.amazon.co.uk/Introduction-Algorithms-T-Cormen/dp/0262533057/ref=pd_sim_14_2?ie=UTF8&dpID=41IHvtO0IxL&dpSrc=sims&preST=_AC_UL160_SR142%2C160_&refRID=1FYKB42A12RXEDF1ZF1V
  
  
• Go get involved with large open source projects on GitHub using the languages you want to be working in.
  
  
• All of these will make you a better programmer. Anyone can look up how to do any of these data structures, the true knowledge is knowing WHEN to use them to proper effect.

What subject exactly? Unicode is kinda complex, but try starting here.

Fundamentals like bits/bytes/numeral systems are annoyingly absent from sites like codecadamy.

Out of modern books, Charles Petzold's «Code» is regarded to be very enlightening.

The book Domain Driven Design: Tackling Complexity in the Heart of Software sort of revolves around this topic. The author speaks at great length about projects where spending way more time in modeling / researching than coding allowed them to solve the problems in ways which allowed them to scale way better - and what they did during that time.

The book is a bit old, but if you take it for the modeling aspect it's still a great read.

as a beginner you're stuck in a position where you want to learn how to do things, but also how to write them. i.e you don't only want to paint a painting, but you also want it to be pretty and admired.

for programming there's a lot of schools of thought on this subject, some guys prefer test-driven development, others domain-driven design.

some think comments outside of method parameters are good coding praxis, others think it's a code-smell because if you have to explain your code you probably wrote it in a way that makes it difficult to understand.

some think patterns are for hipsters, others are of the correct opinion (ahem) that they are standardised solutions for common problems.

all in all, if I could go back in time 15 years when I started programming, I would read the following if they were available at the time:

https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215

Domain-Driven Design is the concept of breaking your code into logical real world units and bundling your code around these objects so that it makes sense to program if you understand the real world your program is mirroring. i.e if you're making a fruit shop program, you might have a fruit seller, a register, a fruit warehouse, a process to deal with ordering fruit etc.

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Clean code talks not so much about the architectural patterns (outside of test-driven development) but rather what's good and bad about code at it's core. i.e

if(fruitStand.Amount < 5)
{
fruitHelper(fruitStand, 3434)
}

vs

if(fruitStand.Amount < dailySoldAverage)
{
OrderNewFruit(fruitStand, wholesaleDiscountCode)
}

outside of that, I think you'll find a lot more resources by simply researching the concepts these guys talk about. programming is constantly changing, as long as you have the fundamentals in place as these guys talk about you're golden as long as you're willing to learn.

Book recommendation:

• Clean Code
  
  Chapter 4 is dedicated to code comments and will help you to understand why some people are talking about self documenting code.
  
  I also recommend you to remember the books author. He also calls himself "Uncle Bob" and you will find several good talks from him on youtube. (Warning: they usually start with some minutes of a completely unrelated topic)
  
  If you take developing software "serious" i would declare reading this book as mandatory. The same goes for his talk about "Expecting Professionalism".

If there is one that is specifically used in your upcoming university course, probably pick that it will give you a head start on the stuff you will be covering.

Algorithms wise CRLS is probably the best book to have.

I would recommend reading Clean Code. It is a good, easy-to-read book about how to write quality code. It can help you a bit for all your languages.

Other than that, perhaps you could helpan open source project? Then you get real coding practice.

The Pragmatic Programmer.

By far, this is the best programming book I have ever read. It discusses programming and software design strategies that are completely language independent, and were rarely discussed in any of my classes.

I wish whoever wrote the legacy code I currently work with had read this book.

The Pragmatic Programmer and Design Patterns.

The Pragmatic Programmer is a really enjoyable read about practical decision making and coding practices. Design Patterns is more for reference, both great books. You can google the design patterns though, but I like to have a copy of the book anyway.

> Can you program regular stuff on there as well?

Yes sir! They're fully functional computers than can run anything from Minecraft to FTP servers.

I recommend a starter kit. They don't cost much more (landing right in your price range) and they have the basic hardware and peripherals to get started.

A couple suggestions:

• https://www.amazon.com/Vilros-Raspberry-Complete-Starter-Black/dp/B00MV6TAJI
  
• https://www.amazon.com/CanaKit-Raspberry-Complete-Starter-Kit/dp/B01C6Q2GSY

This one is pretty good:

https://www.amazon.co.uk/Agile-Estimating-Planning-Robert-Martin/dp/0131479415

If you need to be neo to read code, then that code isn't written well.

Code is read by humans not machine.

So write code like a sentence.

I recommend you to read clean code by Uncle Bob. Something they don't really teach you in school.

Code Complete by Steve McConnell goes over this topic a bit. Great read. https://www.amazon.com/dp/0735619670

Haskell Programming from first principles
Excellent choice if you are kinda new to programming. Really thorough.

Programming in Haskell




SICP

On the internet I'm seeing an unofficial textbook version that is free, while on Amazon they sell the original. Are they the same book or should I grab one in particular?

I like the book "Mazes for Programmers" by Jamis Buck, which deals with the creation of mazes.

I really enjoyed Code.

I feel it's a really accessible summary of what is going on under the hood of a computer.

If you mean writing an interpreter or compiler, then yes. The iconic book for learning how to build languages is called Compilers, Principles, Techniques and Tools. It's often referred to as 'The Dragon Book'. It's pretty heavy reading but contains everything you need to know about building a language!

If you're looking for something more implementation driven, I recently read a book about building a programming language in Go. The principles are the same, just with a different language. The book was called Writing an Interpreter in Go. It's a much lighter read and details the construction of an interpreter from scratch!

michael feathers, working effectively with legacy code is the bible.

I quite like the book written by the developers of the language themselves. The C programming language.

Clean Code

https://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882

Clean Code principles based on Uncle Bob's book.

Links to summaries of the book's principles: Link1 Link2(pdf)

As stated by u/humpier I would recommend to look at other people's projects on Github and how they do it plus looking at popular frameworks in your preferred language and what their standards are.

As you mentioned Wordpress it seems you're more into web development, so maybe you could start with Laravel or Symfony and try to understand their standards.

And I don't know if this may help you and for me it changed how I think about organizing my code but you could take a look at Clean Code by Robert C. Martin. After reading it some things just fell into place for me, which had a lot to do with naming conventions.

Definitely C. It's closer to the computer and lets you see much more of what the computer is actually doing. Learn C then read this book: Computer Systems. This book will teach you the answers to the questions you want to ask but you don't even yet know about to even want to ask them.

Idk if there is a name for this, but it is a well-known phenomenon, to the extent that it killed companies (Netscape anyone?). The proper way to replace legacy systems is to refactor and evolve them (eg. by splitting out services from a big monolith one by one), not trying to replace them in one big go.

I was told Working Effectively with Legacy Code is a very good on the matter.

I tried to come up with a simple explanation how a compiler works but I feel unable to provide a wording which is still somehow correct.
I guess there is a reason why this book has 1000 pages: https://www.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811

The simplest explanation would be that somewone wrote a program which the computer understands, that is able to detect your language and converts it also to something your computer can understand.

https://www.amazon.com/Code-Language-Computer-Hardware-Software/dp/0735611319/ref=nodl_
This book says about everything

Algorithms + Data Structures = Programs

https://www.amazon.com/Algorithms-Structures-Prentice-Hall-Automatic-Computation/dp/0130224189

• How computers work
  
• How to program

Theres a book just for that: https://www.amazon.com/Mazes-Programmers-Twisty-Little-Passages/dp/1680500554/

you could always buy the bible: http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/ref=sr_1_5?ie=UTF8&qid=1425602201&sr=8-5&keywords=gang+of+four

otherwise, http://en.wikipedia.org/wiki/Software_design_pattern

The book Code: The Hidden Language of Computer Hardware and Software by Charles Petzold has the answer you are looking for.

The book is a layman-accessible description of how computers work. It starts with a simple description of how data is encoded, to physical encodings of data in the form of electrical currents, to relays, to logic gates, to adders, all the way up to simple op codes in an assembly language, to high-level computer programming languages.

This is kind of a weird one but I’d suggest Code. Very non-technical, no programming, but cool history and fundamentals.
Code: The Hidden Language of Computer Hardware and Software - Code: The Hidden Language of Computer Hardware and Software https://www.amazon.com/dp/0735611319/ref=cm_sw_r_cp_api_i_IiH2DbWSNWHMW