λ - How do you find out what you are trying to do actually is...

Posting mode: Reply [Return]
Name
EmailXF♲1z9mA%*\l☨SIk-⚦@=nqY$2QoHd8~KEjV{?♦t0&M♕ce <x[7G♗⛫Og⚥fC, i]4Nr6T`\|D;h'sUWb/ZB.>}5+R(pJ
Subject
Comment
File
Password	(For file deletion.)

File: 1443441224533.png (9.79 KB, 640x400, handover.png) ImgOps iqdb

How do you find out what you are trying to do actually is... Anonymous 2015-09-28 11:53:44 No.9922

Certain things are easy to program, because the problem is well understood beforehand, or it's easy to split it up into parts that have little or nothing to do with each other, or maybe it's programming for fun and the final result is not that important.

But some times, ...there is a sense of need to completely design the system beforehand, to cover the edge cases without needing to redo half the program halfway in, because it needs to be able to do that thing as well, which changes everything. To get it right from the very start. Even if Murphy ensures the futility of that goal.

I tend to draw/write sketches that I never read, which is just as well, because they are never documented enough that they make sense, should I actually forget what I was thinking at the time.
A lot of the time it seems like I redraw the same sketches with few or no changes each time I think of the problem.

How do you do it?

Anonymous 2015-09-28 12:20:48 No.9924

When I write apps in frameworks that use MVC i tend to design the model first, then the view. By that time I typically have a pretty good idea of how I will write the controller. Regardless of what frameworks you use, designing your data structures first is likely a good idea

Anonymous 2015-09-28 13:09:03 No.9925

I've taken a few programming courses in college and I'm not too sure if this is implemented IRL as much, but in all my courses each project/assignment was done in two parts. First and always first you would have to outline your program in a flowchart-type design. Similar to UML in a way. It was so annoying at first that I would just code first, then create a flowchart depicting the structure of my code, and my instructor would catch this and get pissed. There are multiple programs you can use for "flowchart programming", its pretty self explanatory. I'm not sure if this is the answer you were looking for.

Anonymous 2015-09-28 13:23:04 No.9926

File: 1443446584845.jpg (176.26 KB, 500x540, 4ce5574869bc17ee8f254b7705….jpg) ImgOps Exif iqdb

I program in Common Lisp.

Anonymous 2015-09-28 13:58:33 No.9929

I often draw sketches, and I seldom read them as well. But I also use the power of lisp, which allows me to design the system I'm making interactively, one sexpr at a time, and as I do that my understanding of what I'm trying to do grows, I can then just recycle some part, redefine others, or refactor the whole thing. I usually make functions small and concise so it's easy to mix&match, I usually end up with lots of open files with the working program distributed among them between discarded versions of functions, and I then try to find which ones I finally used

Anonymous 2015-09-28 19:20:38 No.9933

>>9922
Well, last time I had a problem which was tricky enough that a "I sit down and start programming"-approach was not sufficient, I took out some paper and started writing.
Real programming (not code pissing) is done more or less like math : On paper.
There is yet no better interface for tinkering with ideas than a pen and paper.

Anonymous 2015-09-28 23:28:28 No.9945

Nobody should start to undertake a large project. You start with a small trivial project, and you should never expect it to get large. If you do, you'll just overdesign and generally think it is more important than it likely is at that stage. Or worse, you might be scared away by the sheer size of the work you envision. So start small, and think about the details. Don't think about some big picture and fancy design. If it doesn't solve some fairly immediate need, it's almost certainly over-designed. And don't expect people to jump in and help you. That's not how these things work. You need to get something half-way useful first, and then others will say "hey, that almost works for me", and they'll get involved in the project.

Anonymous 2015-09-28 23:30:14 No.9946

When writing personal projects in C++ or similar languages, I had to do what OP described to make any progress at all, and even then, I always failed to complete my projects. I should note I'm not a professional programmer, so I don't have any incentive to complete those projects aside from my own will.

Since I started using functional languages, I've had much more success trying to do the things I want to do. I've found it easier to design the program as I write it, since the end goal is to have a single function which does what I want it to.

I might need to write down the inputs and outputs for my functions, but I think the program will explain itself as you build around the inputs (or outputs). I also write down protocols and specifications if I'm writing something like a server.

Anonymous 2015-09-29 05:47:46 No.9954

I haven't really worked on any super large projects. However, when I'm working on a more difficult one I usually will break out the pen. Jot down what I'm trying to do and how I'm going about it.

Anonymous 2015-09-29 06:38:51 No.9957

The pondering I had in my mind when posting the question was more along the line of how do you figure out what to draw? how do you know the model you write a representation is a good model? even if I didn't manage to word it very well, ...because that is a very cloudy thing for me personally. But maybe I'm not alone in having difficulty to answer that, it's basically the question of "what do you do in order to form thoughts?" to some extent.

Anonymous 2015-09-29 08:38:26 No.9958

>>9922
I usually do the same thing, diagrams that I end up throwing out afterwards because they're embarrassingly bad and my code is already a better representation of what I was trying to do than my original incomprehensible scribble.

>>9957
If the program requires stored input (like from a file) rather than just user input, I'll usually draw how I imagine the data should be structured.
For both cases I'll draw a flowchart of the main program, describing roughly the steps, and then for each complicated step that requires it I'll write a separate flowchart.
This way, I can write each separate flowchart as a function and call them from the main program in the order I've written down, and soykaf should start working pretty quickly.

Anonymous 2015-09-29 17:51:59 No.9963

>>9922
You think you just have to try and err. That's mostly how people came up with solutions for now well understood problems in the first place. They call the process research or experimenting and generally don't expect to get tangible results out of it, but rather learn about the intricacies of the problem and how to tackle them in later iterations.

I recently read through some 20+ year old documentation for X11 and it was interesting to me, because the authors laid strong emphasis on how certain problems like internationalization are not yet well understood and the presented solutions therefore preliminary. I guess planning only gets you so far, eventually you'll need to put your theories to the test and draw the right conclusions from it. Otherwise you just end up sketching the exact same diagrams over and over again, as you said.

Anonymous 2015-10-10 18:33:38 No.10403

>>9957
I've found that explaining the problem to others helps.

Anonymous 2015-11-11 07:39:52 No.11867

>>9922
The language you use really affects your thinking.

I like Forth and bottom up design. I always try to think about what primitives I'll need for my program. Then I can program everything else before I even define the primitives.

Forth also heavily encourages factoring. If my word's definition won't fit on a single line, I'm probably doing something wrong.

Anonymous 2015-11-11 21:50:57 No.11883

>>11867
lisp is the opposite. I think about exactly what needs to happen for my program to work, and I program all the components for that, and the components for that, and so on.

Anonymous 2015-11-11 22:06:46 No.11885

>>11883
I'm also a fan of Lisp and I feel that it's very similar to Forth.