Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Java (http://www.chiefdelphi.com/forums/forumdisplay.php?f=184)
-   -   Java Command Based Crash Course Concept (http://www.chiefdelphi.com/forums/showthread.php?t=139106)

notmattlythgoe 11-11-2015 15:44

Java Command Based Crash Course Concept
 
WARNING: THIS MAY CAUSE EXPERIENCED PROGRAMMERS TO SHAKE VIOLENTLY IN ANGER

Scenario: Given two hours to teach a group of new programmers how to code their robot using the Java Command Based structure.

Some new programmers will struggle with the concept of writing their own methods in the Subsystem classes. Given the short amount of time what are the thoughts on declaring all of the motors and sensors inside of a Subsystem as public fields. Then accessing them directly from the Commands that need them?

Code:

public class Drivetrain extends Subsystem {
        public MotorController left = new Talon(0);
        public MotorController right = new Talon(1);
        public RobotDrive drive = new RobotDrive(left, right);
}

Code:

public class DriveCommand extends Command {
        protected void execute() {
                Robot.drive(Robot.oi.joystick);
        }
}

I know this breaks many Java programming standards and should be highly frowned upon by an experienced programmer. But, thoughts and opinions?

Jon Stratis 11-11-2015 15:54

Re: Java Command Based Crash Course Concept
 
The way I see it, there's the "right" way to do it, and then there's the way someone cocompletely new will best understand it and be able to contribute in a short amount of time. I don't think there's anything wrong with picking the "easiest" way to start with, then as you have time working with the individual students or home-based groups to transition towards the "right" way to do it. Often times, I've found that you can find real, practical examples as you go to highlight why there's a "right" way to do something.

Of course, this only applies to stuff like programming. I'm not going to let a student get off using a tool the wrong way and hurting themselves!

GeeTwo 11-11-2015 17:37

Re: Java Command Based Crash Course Concept
 
It's a easier to never pick up a bad habit than to break it.

If you want to have a victory in two hours, it would be better to have a working set of conventional code and have the prospective programmers make mods, extensions, or minor corrections. That's how most programs are actually written, anyway.

notmattlythgoe 11-11-2015 18:13

Re: Java Command Based Crash Course Concept
 
Quote:

Originally Posted by GeeTwo (Post 1504515)
It's a easier to never pick up a bad habit than to break it.

If you want to have a victory in two hours, it would be better to have a working set of conventional code and have the prospective programmers make mods, extensions, or minor corrections. That's how most programs are actually written, anyway.

The problem is, these are not my kids. When I leave they're on their own to code their robots for the season. They need the ability to write them from scratch.

GeeTwo 11-11-2015 21:36

Re: Java Command Based Crash Course Concept
 
Quote:

Originally Posted by notmattlythgoe (Post 1504529)
The problem is, these are not my kids. When I leave they're on their own to code their robots for the season. They need the ability to write them from scratch.

I don't believe that any our four robots' code was written from scratch. We have started with a "barebones" program that has a similar drive system to ours, then start adding on our particular design choices. This is actually a design decision that we usually do after the high-level design solidifies: what code base shall we start from? For Recycle Rush, we started with our own 2013 code, which had a tank style drive. For Aerial Assist, we started with a generic mecanum robot code from the internet. I was not involved in programming our first two years, but I'm confident Gixxy also started with working code rather than trying to write a robot "from scratch".

JesseK 11-11-2015 21:49

Re: Java Command Based Crash Course Concept
 
Tough to debug - the 'set' methods allow you to put breakpoints to figure out what code is causing change. This is particularly important in multi-threaded code. At the same time, I rarely actually put breakpoints in simple 'set' methods as a veteran.

Make the member variables immutable with the 'final' keyword and use the variables directly. Then it's fine from a pragmatic perspective. Grumpy people will argue about style, but whatever. I mean, it's not as bad as javascript, where anything can change anything, and you can pass a variable in where a functor should be and nothing stops you until it blows up 10 calls into the stack...

notmattlythgoe 12-11-2015 07:48

Re: Java Command Based Crash Course Concept
 
Quote:

Originally Posted by JesseK (Post 1504584)
Tough to debug - the 'set' methods allow you to put breakpoints to figure out what code is causing change. This is particularly important in multi-threaded code. At the same time, I rarely actually put breakpoints in simple 'set' methods as a veteran.

Make the member variables immutable with the 'final' keyword and use the variables directly. Then it's fine from a pragmatic perspective. Grumpy people will argue about style, but whatever. I mean, it's not as bad as javascript, where anything can change anything, and you can pass a variable in where a functor should be and nothing stops you until it blows up 10 calls into the stack...

Good call on making them final Jesse.

I think this process will take one confusing step out of the equation for new programmers and teams without programming support and hopefully give them the ability to quickly get a robot up and running.


All times are GMT -5. The time now is 10:16.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi