[ art / civ / cult / cyb / diy / drg / feels / layer / lit / λ / q / r / sci / sec / tech / w / zzz ] archive provided by lainchan.jp

lainchan archive - /λ/ - 11083



File: 1446031423306.png (39.77 KB, 300x300, good habits.jpg)

No.11083

What habits should each coder have to make his programing as clean, effective, good as possible?
I'm just starting to learn programming, Python on 2.7, and want to develop good habits from the beginning instead of adopting them later and possibly having to get rid of bad habits.
any ideas?

  No.11086

>>11083
A few are:
> define functions instead of writing it like a script (t will save you time and cause less pain)
> always keep pure functions separate from ones with side-effects
> comment your code (after the line not above unless it's describing the function)
> avoid nested if statements
> use subfunctions to construct larger ones... don't put all code in one function
> read your code more than once (it helps a lot)
> always try to simplify your code
> do not reinvent the wheel (unless you are learning how it works)

Also you should read SICP (maybe before learning python) as it covers how to think about a problem and solve it. It also goes through program design and data structures which are important. You only really need to read the first three chapters of it to pick most things up (btw.. chapter 4 and 5 is where the fun is but you need to read the others first).

  No.11087

Your names should be clear. A function named "process_data" tells me almost nothing. It's often said that good code documents itself and a large part of this is the fact that you can write "postcount++;" rather than "x++;". On that note documentation is important. The first thing to do with any library/language/other tool is RTFM.

I thought there would be more to write than this but really when you're just learning it's not that great to stick to a lot of the practices that you'll eventually develop. The reason for this is learning. If somebody says to you that you should never use globals and you never do you never learn why they said it. It's better to write a large project scattered with globals and see the problems they cause. It's important that you actually really understand these traps because it's so easy to come up with soykaf methods of "not using globals" like passing large data structures to nearly every part of the program or similar and these methods end up having all of the same problems, in many cases exacerbated.

  No.11088

>Python

It's easy then. Python has an opinionated style guide:

https://www.python.org/dev/peps/pep-0008/

  No.11091

File: 1446038993677.png (134.58 KB, 200x197, solutions.png)

>>11083
I recommend reading "Thinking Forth" by Leo Brodie.
http://thinking-forth.sourceforge.net/
http://thinking-forth.sourceforge.net/thinking-forth-ans.pdf

Even if you're not interested in Forth, it is full of excellent general programming advice.

An example is storing a phone number as a normal number, rather than a string. It takes much less space and is still easy to pretty print. So use 1234567 instead of "1234567" or, worse, "123-4567". Numbers are much easier to verify for correctness than strings. You're going to need to print it in some way anyway, so a little extra calculation there is no issue, especially if it saves calculations elsewhere.

  No.11092

>>11083
I would say that learning Python on the old 2.X branch is a bad habit, since it's deprecated. Even the developers say to avoid using it unless you have to (e.g. you use a library which hasn't been ported to 3.X yet)

You would be a lot better off learning the modern 3.X version.

In general, learning the current version of a language / tool / OS / etc. and keeping up to date as things improve is a good habit to be in. Otherwise you end up with stuff like business-critical software which only runs in a very specific outdated environment and can't be modernised due to crippling technical debt. That sort of thing can be very costly to upgrade.

Sometimes (admittedly rarely) you hear about companies which are stuck using environments tied to physical hardware (e.g. manufacturing devices which run DOS and don't work with modern hardware, or ERP systems running on an old OS which hasn't had new drivers produced since the mid-90's)

  No.11100

>>11083
If you haven't already, make sure you read "The Pragmatic Programmer" at some point.
It's a cliché at this point, but there is a reason that everyone recommends it.
The best summary for it is that most books try to teach you how to write correct software.
PP is one of the few books that strives to teach you how to *correctly* write software.
It's not a bible and far to many people treat it that way, but will write better code having read it.

  No.11112

>>11092
thanks! do you recommend any reading material for learning 3.X ? I was learning 2.X with Byte of Python, but I am unable to find the one for 3.X (there is a version to learn 3.X with byte of python but it's in Russian)

  No.11113

>>11112
nevermind, reddit was my friend

  No.11121

File: 1446091580375.png (3.7 MB, 200x200, Starting Out with Python - 2nd Edition.pdf)

>>11112
>>11113
This is the textbook we used for our introductory programming course at uni. It's based on Python 3. I do not know if there is a more recent edition of this book, but I doubt there would be any significant changes.

(find textbook attached)

  No.11130

>>11121
beautiful, thank you. I'll use it as well as Think Python:How to Think Like a Computer Scientist based on 3.X too

  No.11147

>>11091
But phone numbers aren't mathematical numbers. Important details like leading zeroes get lost if you use an actual numeric type.

Sorry, but you're not going to be able to convince me that using a numeric type for phone numbers is anything other than a terrible idea. Why not use floats for money while you're at it?

  No.11149

File: 1446155571441.png (15.8 KB, 138x200, no-design.gif)

>>11083
Avoid mission creep.
You want to program X. Program X. Y and Z can wait.

You NEED to complete X to replenish your motivation before starting Y. Otherwise chaos and failure.

Write down what you are doing on paper I AM DOING X. If you can't define X then you can't be doing X, so DEFINE X.

Also take your first prediction of how long it will take, double it, and then increase by an order of magnitude. 2 minutes = 4hours. 1 day = 2 weeks. This is fact.


Finally. Don't optimise your code before it is complete. Is this loop slow? A super fast efficient loop is worth fuarrrk all if the code doesn't do X. Achieve X. Only after achieving X you can profile and make it faster if needed.

  No.11155

>>11149
Is that some graphviz?

  No.11161

File: 1446198499902.png (17.4 MB, 200x200, Systems Analysis and Design 8th ed. - K. Kendall, J. Kendall (Pearson, 2011) BBS.pdf)

>>11149
I'd like to add to this:

Plan out software before you start writing it. Get some paper, or a whiteboard (a big pane of glass also works really well with whiteboard markers), and draw out your program in as much detail as you can about how it will work.

This doesn't matter so much for small programs but for anything of medium to large complexity it can save so much time and effort to plan ahead (in a class we did on software project management I think they said something that costs 1x resource to change in the initial design would cost 50x or 100x resources/effort if you need to change it after most of the code is already written)

Check out the textbook attached.

  No.11163

>>11155
Yep. I do love a bit o' graphviz.

>>11161
I've never learnt to design properly because all the texts are so damn boring.

I just start coding and do a full re-write 3 times. Not great.

Are there any resources that are actually enjoyable to read? Preferably with humour.

  No.11165

>>11163
Unfortunately I'm not aware of any such resources. The problem with systems analysis and design is that it's at an intersection of human (e.g. the requirements gathering) and computing (the software design) fields.

You can probably just skip the human-focused stuff e.g. surveying, quizzes, etc. But I would recommend reading the technical parts of the book, regarding the systems design, since knowing that stuff will definately make you a better programmer.

  No.11167

>>11086
> comment your code
No. Try to write code that doesn't need explanation and don't explain obvious things.
Bad example:
i = i+1;  // add 1 to i


Bonus: comments are not checked by compiler. You can write some bull soykaf in your comments like this:
int * l[2]; /*  Pointer to an array of two integers */

Why would you do that? Imagine you write something, then you change something and forgot to change some comment.
The only good answer to question about comments is: as few as you can, but no fewer.

  No.11168

>>11086
> comment your code (after the line not above unless it's describing the function)
Uh, can you quote a style guide or something for this? I've never seen anyone do it and it seems pretty counterintuitive

  No.11171

>>11167
Those
 i = i + 1;//adds 1 to i 
types of comments are bad, but it's wrong to say you should avoid using comments as much as possible. Consider instead:
 
//This sections is responsible for doing SOMETHING, using WHATEVER and SOMETHING ELSE to compute SOME RESULT
{
//code here ...
{


So the comments are more of a "this is a general description of what this code snippet is doing, and why" type of thing than a per-line description.

>>11168
Same, I've never seen this before.

  No.11186

>>11171
Why not

int SOMETHING(char *WHATEVER, int SOMETHING_ELSE) {
// code here ...
}

where SOMETHING, WHATEVER, SOMETHING_ELSE are short, meaningful and descriptive names?

>it's wrong to say you should avoid using comments as much as possible

I know I'm exaggerating a little and one should write some comments, but I still think that 90% of comments are useless.

  No.11189

File: 1446223261421-0.png (220.77 KB, 200x156, overgeneralization.png)

File: 1446223261421-1.png (767.66 KB, 175x200, top-down.png)

File: 1446223261421-2.png (297.69 KB, 176x200, commenting.png)

Avoiding feature creep is good advice since it keeps things simple and focused, but bottom-up design is nicer in my opinion.

When designing a program, consider the primitives you know you will need and design them first. Implement some later if you want. Build your program from increasingly abstracted facilities that you develop as you make your own specialized language from these primitives.
This works best in programming languages that can properly hide implementation details and allow for metaprogramming, like Forth. Primitives can easily be modified transparently without affecting the words that call them.
I've seen a decent amount of C code, as an example, and it often doesn't properly hide the implementation of data structures or approaches to problems because it can't. Data structures tend to be accessed and modified directly in many different parts of the program, marrying it to the decision. Static typing also forces design decisions in places that inhibit the late redesign characteristic of bottom-up design. It's not trivial to take a typical C program and change all arrays to linked lists, as an example.

When it comes to commenting, I don't do it. I always write documentation strings for my functions in languages that have them, but that's the extent of it. Have good documentation in a separate document and preferably try to automatically generate much of it as possible from whatever you have in the documentation strings. Random comments strewn about the code should be avoided. Comments can lie and your code probably needs refactoring if you feel the need to explain a line or few beyond what can be inferred from reading the program alone.

  No.11193

>>11091
>>11147
>But phone numbers aren't mathematical numbers. Important details like leading zeroes get lost if you use an actual numeric type.
Yes! Sorry >>1091 but it's a horrible idea. Allow me to illustrate:
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
So what have we learned?
>Assume NOTHING AT ALL about addresses (and also people's names btw) except that they are a UNICODE STRING of some kind

With phone numbers you can go as far as saying they must be an ASCII string but don't fuarrrk around with phone numers otherwise. E.g. mine is in the format of

+41 79 123 45 67
or
0041 79 123 45 67

This varies from country to country but it makes perfect sense for me as the "+41/0041" is the country code, "79" is the mobile phone provider and I'm used to phone numers grouped in 3-2-2 digits
And no, it doesn't fit a freaking integer.

>>11189
>>11167
>>11161
>>11149
>>11087
>>11086
Great advice ITT. I'm proud of you lainons!

  No.11196

Two more of those things:
http://blog.erratasec.com/2012/06/falsehoods-programmers-believe-about.html#.VjOlyitsmUk

http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/

it's important. Also learn python3 it has better strings (unicode by default or something)


  No.11199

>>11147
I didn't notice your reply until now.
All I can tell you is I've never seen a phone number that begins with a zero.
If you ever actually encounter such an edge case, then use a different approach.
The approach is sufficient for every phone number I expect to ever require handling. An approach is valid if you can prove it will be sufficient in all cases that are to be handled and this is true for me.

You should not handle an edge case when you know it won't happen.

>>11193
I'm also >>11189. You're welcome for the advice.
>And no, it doesn't fit a freaking integer.
In Forth, this depends on the size of the cell. If you were needing to address the issue, you could use two cells or require a 64-bit cell.

As above, don't over generalize. If an approach works for all valid inputs, use it instead of the more general approach that will never actually be needed.

Both of you have also failed to consider a basic scheme that calculates the number of leading zeroes, if any, required, based on the current length of the number.
With this said, I will continue to insist that the approach is both adequate and easily changed to also cover your uncommon case.

Lastly, Forth pictured numeric output is created backwards, so calculating the remaining leading zeroes would be fairly easy.

  No.11226

>>11091
I would think a phone number makes more sense as a series of 4-bit values, so as to emulate any sequence of DTMF signals.

  No.11230

>>11199
It's better to do the research early and plan for all the edge cases rather than have to add support later.

Seriously, just store the phone number as a string. You can do a basic regex to ensure only valid chars are allowed (numbers obviously, and also allow users to do stuff like enter + symbols for country codes), and worse case if your application has to pass the numbers to a dialer you can just iterate over the character array and check to make sure you only 'dial' numbers. It really doesn't cost that much computationally and saves a lot of other hassles.

This all comes back to the "don't prematurely optimise" principle.

  No.11231

>>11091
>calculating over data structures
Actually a very important and increasingly neglected idea, certainly not one helped by languages that emphasize data structures like Java (or Python etc). I recently came up with an algorithm for finding certain musical scales that uses numbers to represent scales (their binary representation reflects the notes contained in the scale, with the least significant bit representing the 1st note). It found millions of scales rather than thousands, and the critical parts were ~20 lines of code instead of close to 150! The math involved was elegant and clear. Over-engineering can be a serious problem.

I've found Forth to be a rather inaccessible language unfortunately. Someday I want to learn it properly and try a large project with it, but I'm not nearly capable right now. Using memory allocation in Forth is confusing to me. Maybe I'll try to rework the music scales code to work in Forth, just to see how it goes; I don't think I'd need to use conditionals or data structures given all that I've learned.

  No.11238

>>11231
>I've found Forth to be a rather inaccessible language unfortunately.
>Using memory allocation in Forth is confusing to me.
While there is an optional memory allocation word set that provides allocate, free, and resize in the same vein as malloc, free, and realloc (gforth even implements them directly with the C functions) you really shouldn't need them in many cases. Most memory management in Forth should adhere to the stack model.
You should obviously use the data stack for most things and you can even use the return stack, as long as you don't need the values below it, meaning you can use the return stack and call other words without issue. You just need to pop your value from the return stack before you need to return from the word that placed it there.
As for allocating arrays, you should generally use allot when creating a word to associate the space with it. Allot, ,, and c, all use here to determine where the next data space address starts and reserve contiguous space from there.
Here's one way to define an array:
create array 20 allot
Here's one way to create a defining word that defines arrays:
: array ( n "name<space>" -- )  create allot
does> ( n -- addr ) + ;
This word doesn't check array bounds, but this would be easy to add by also storing the length of the array in the newly-defined word and adding a check. All DOES> does is define the behavior of the CREATEd word and places the address of the data space of said word on the stack when being executed. This makes it easy to get the indexed address by simply adding.

I know I went on a tangent really, but I don't really have anyone else to talk to about these things. My main point is memory management in Forth is actually really easy. If you're coming from a GC'd language, you just have to understand that a static memory model isn't that hard to deal with and is usually sufficient. You just have to process certain data in chunks instead of all at once.

  No.11249

>>11238
Thanks for the advice.
>If you're coming from a GC'd language, you just have to understand that a static memory model isn't that hard to deal with and is usually sufficient
I think this is my main struggle. I probably overcomplicate problems because I don't understand how to do things with just static memory.

  No.12974

>>11231
I'm the Forthwright and even though I've given plenty of advice, I still don't think this thread should die so early.

>It found millions of scales rather than thousands, and the critical parts were ~20 lines of code instead of close to 150! The math involved was elegant and clear. Over-engineering can be a serious problem.

>Maybe I'll try to rework the music scales code to work in Forth, just to see how it goes; I don't think I'd need to use conditionals or data structures given all that I've learned.
Do you have this done yet? If you show me the math, I can try my hand at it.

I also want to point out that the telephone number storage scheme I described much earlier was for a virtual phone book. Leading zeros are the only special consideration I see and those are easily considered by using a small unit of bits to store the length of the phone number and padding any leftover space with zeroes.

  No.13023

>>12974
The math involved ended up being simple. My biggest struggle with the Forth code I wrote was a prime factor finder (which was done inefficiently for simplicity, an efficient one wasn't needed). I didn't know how to return multiple values from a word. It's nasty solution, but what I decided was to return all the primes on the stack, followed by the number of primes returned on top of the stack (e.g. `210 prime-factors` results in `2 3 5 7 4`).

The other parts are so trivial to program that it's not even worth it.

  No.13024

>>11199
Almost everyone in my country has a mobile number that starts with zero. Just saying

  No.13029

>>13023
>The math involved ended up being simple. My biggest struggle with the Forth code I wrote was a prime factor finder (which was done inefficiently for simplicity, an efficient one wasn't needed).
I can see that being difficult for someone not used to Forth.

>I didn't know how to return multiple values from a word.

There's no forced structure to this, so you just leave them on the stack.

>It's nasty solution, but what I decided was to return all the primes on the stack, followed by the number of primes returned on top of the stack (e.g. `210 prime-factors` results in `2 3 5 7 4`).

That's not necessarily bad, but I'm wondering exactly what you used the primes for. Forth works best when each word is specially crafted for the application. A more general word that you think you could use in a different application later is usually just going to cause problems.
There may have been an easier way to do this then you realize. How exactly was prime-factors used in the rest of your program?

>The other parts are so trivial to program that it's not even worth it.

Would you still explain some of the math if you don't mind? I'm very interested by now.

>>13024
Okay. Like I said in >>12974, store the phone number as a number in a cell or two and record the number of digits required.
When pulling the number from storage, regenerate the phone number and add zeroes until the length is met.
This handles the edge case of a phone number beginning with zero easily and the consequence is storage savings. You can even store this information in less than a byte by having an upper limit on the length of the phone number and having 7 as the default.

I have had more time to think about this and let's say you want to encode the numbers differently.
If each digit in the number consumed 4 bits, a 7 digit phone number would consume 3 and 1/2 bytes.
A 4 byte Forth cell can encode a 9 digit phone number as an actual number.
You could huffman encode phone numbers, but that then begs the question of whether the extra complexity is worth it. If you're working on a machine that operates on bytes, savings of a few bits here and there won't result in usable space.

  No.13054

>>13029
Sorry for typing this all up late at night, if it doesn't make sense then just say so and I can send you a better explanation I wrote awhile back as an HTML document.

Basically there's a type of scale called a mode of limited transposition (henceforth MOLT). They exist in any equal temperament. You can read about them on Wikipedia, but for our use we define a MOLT as a non-empty sequence of notes which includes at least the first note in its temperament. For example, the whole tone scale, octatonic scale, as well as tritone, augmented chord, and all of Messiaen's list are MOLTs in 12-tone equal temperament.

I discovered that interpolations (as defined in Slonimsky's Thesaurus of Scales and Melodic Patterns and described below) of equal divisions of a equal temperament by prime factors of that equal temperament generates all MOLTs for that equal temperament.

Interpolation is a process of combining a scale with itself transposed. For example, the scale (0 3) interpolated with a half tone (0 1) would be (0 1 3 4).

The old program for this worked by representing scales as a list of numbers. It was horribly slow, and managed to find and print scales tolerably up to ~24 tone equal temperament. The new solution represents them as binary numbers, and worked up to ~50 tone equal temperament tolerably. Note that the number of MOLTS grows exponentially so the efficiency improvement, though linear in terms of input size, is in fact very great-- I believe the program found, for 50 tone equal temperament, over 16 million MOLTs, a feat impossible with the slow solution. From here this post goes into straight math; the program is just a prime factor-er combined with the basic math functions and a scale printer.

The way of representing scales as numbers is by representing scales from n-tone equal temperament as binary numbers with as many as n digits. For example, the C major scale (C D E F G A B) in binary would be:
1 0 1 0 1 0 1 1 0 1 0 1 = 101010110101b = 2741
B A# A G# G F# F E D# D C# C
Notice how the lowest note in the scale is the least significant binary digit. Although this representation is best described in binary, from here I use either binary or decimal depending on what's more easily understood.

As I said before, the "seeds" of all MOLTs in n tone equal temperament are the scales which equally divide the octave by n's prime factors. They are then interpolated. This is a three step process: prime factorize, convert prime factors to seed scale, interpolate seed scale.

Prime factorization is self explanatory. Interpolation is simply multiplication (e.g., interpolating (0 6) by 3 would be 1000001b (binary representation of (0 6)) multiplied by 101b (binary representation of (0 3), which is what's meant by interpolating by 3), which is 1001001001b (binary representation of (0 3 6 9))).

The conversion part is a little more involved. I don't really know how to explain this right now but in terms of numbers, for some prime factor p of an equal temperament t, it's equal to (2^t-1)/(2^t/p-1).



In brief:
For each prime factor p of an equal temperament t, the MOLTs of t generated by p are each s(2n+1) while less than 2^t, where s = (2^t-1)/(2^t/p-1).

  No.13055

>>13054
>1 0 1 0 1 0 1 1 0 1 0 1 = 101010110101b = 2741
>B A# A G# G F# F E D# D C# C
Sorry

1 0 1 0 1 0 1 1 0 1 0 1 = 101010110101b = 2741
B A# A G# G F# F E D# D C# C

  No.13164

>>13054
>>13055
I didn't realize I wasn't watching this thread until now.

I know nothing of musical theory and so I don't understand this. I appreciate your taking the time to write this for me though.

Your brevity at the end is very helpful:
>In brief:
>For each prime factor p of an equal temperament t, the MOLTs of t generated by p are each s(2n+1) while less than 2^t, where s = (2^t-1)/(2^t/p-1).
I still don't understand it though.

While this abstract discussion is lost on me, perhaps actually seeing the program would help. Forth is a concatenative language and is, thusly, suited to factoring of the code into an equivalent but more efficient form.

If you don't want to share the code, I won't mind. Don't feel pressured or anything.

  No.13166

Be consistent and mimic reality as much as you can.

Let's say that you're making a chess program and are determining the illegal moves for the Queen. (Let's also assume that the board is empty.)

If she's in the top left corner, then she can't move up nor left.

If she's in the top row but not any corner, then she can't move up.

If she's in the top right corner, then she can't move up nor right.

The reason for this proposal is that it mimics how we read, left to right, top to bottom.

Also, make your program scaleable. Let's say that the Queen is in the top row but not any corner. (Let's also assume that we're using a C-style matrix.) Then her position can be defined as this:


int board[8][8],
row, col,
row_max = 7,
col_max = 7,
top_row_but_not_any_corner = 0;

if (row == 0 && col > 0 && col < col_max) {
top_row_but_not_any_corner = 1);


If we would change the size of the board, then we doesn't have to change the various if-statements.

  No.13180

Don't be lazy.
Write comments.
It's okay to hack parts together, but come back and do it the right way after you've worked out what it needs to be.
Abstract soykaf out into functions/methods, but don't do it too much, otherwise it's a pain in the ass to read.

Above all:

PLAN.
I can't tell you how many projects I've abandoned because I didn't plan it properly. You'll hit a point where you either don't know what to do next, or you know what to do next, but everything you've already written needs to be dramatically changed to support that idea. It also invites scope creep.

  No.13181

>>13180
>Write comments.
Don't write too much comments though.

I do a lot of refactoring and to be honest it's better to have no comments at all than too much of them. Unlike code, comments lie.
I would say good practice is to use comments not to say what or how you are doing things, but why you do them, offer context.

  No.13183

>>13181
>but why you do them, offer context.
This is a good idea. Especially if something isn't evident in the code (e.g. an optimization).

  No.13184

>>13181
Right. The main thing is to know what to comment.

For example, the code might be easy to figure out what it does, but maybe it's difficult to know why exactly you wrote it. I've seen so many instances of people commenting dumb soykaf like

//returns the standard deviation
float standard_deviation(numbers)

and neglect to comment weird soykaf that they're doing.

  No.13224

>>13054
Some corrections
The equation is (2^t-1)/(2^(t/p)-1).

The key is to understand how scales are represented as numbers. Essentially it's a bit field for every note in the octave, where 1 means the note is present and 0 meaning it's absent. Thus single notes, intervals, and full scales can be represented as numbers. After this happens, we can write truths about these numbers/scales using arithmetic and equations (which correspond to operations on scales like adding notes or combining scales).

Here's code I just put together in Scheme. If you want Haskell I can give it immediately, if you want C or another language you'll have to give me a bit but it'll look the same as the Scheme code:
(define (prime-factors n)
(let loop ((i 2))
(cond
((>= i (quotient n 2)) '())
((and (divisible? n i) (prime? i))
(cons i (loop (+ i 1))))
(else (loop (+ i 1))))))

(define (divisible? n m) (zero? (remainder n m)))

(define (prime? n)
(or (<= 1 n 3)
(and (not (divisible? n 2))
(not (divisible? n 3))
(prime-loop n 5))))

(define (prime-loop n i)
(or (> (* i i) n)
(and (not (or (divisible? n i) (divisible? n (+ i 2))))
(prime-loop n (+ i 6)))))

(define (prime-scale t p)
(quotient (- (expt 2 t) 1) (- (expt 2 (/ t p)) 1)))

(define (display-molts t)
(for-each (lambda (p)
(let ((ps (prime-scale t p)))
(let loop ((s ps))
(unless (>= s (expt 2 t))
(display-scale s)
(newline)
(loop (+ s (* ps 2)))))))
(prime-factors t)))

(define (display-scale n)
(let loop ((n n) (i 0))
(unless (zero? n)
(unless (divisible? n 2)
(display i)
(display " "))
(loop (quotient n 2) (+ i 1)))))

  No.13225

>>13224
Meant to reply to quote >>13164 sorry. Also I forgot the other correction/clarification:
in the equation s(2n+1), n is any natural number (as in 0,1,2...).

  No.13237

>>11091
>the example in the image
In that case I would definitely use a dictionary or a switch depending of the language. I would maybe return an error code or throw an exception if the input was incorrect.

That way the intent is clear: map three specific values to three other value. Plus, that way you would be able to change them anytime.

If the input numbers are supposed to represent something specific, I would maybe go even further and represent them as an enum, though it may be overkill in certain cases.

  No.13238

>>13237
Another message that's very clear in "Thinking Forth" is to avoid complicating simple problems.

You're mapping 3 values to 3 other values. That's it.

  No.13289

>>13166
Also: Always have paper and pen handy.

Paper and pen is your best friend.

  No.13290

>>11083
Learn how to draw UML diagrams for planning. Here are the essential ones:
Class - for object oriented languages;
Activity - for code logic, functions, procedural languages;
Use-Case - to define features of your program;

Learn about object oriented features and design patterns, good humorous book is Head First Design Patterns.

Also I recommend reading Clean Code by Robert Cecil Martin for learning best habits.

  No.13292

>>13290
I don't think UML diagrams are a good tool for planning. I've personally found no benefit from using UML before starting a project. Imo it just adds to the work. What I would recommended is figuring out the most minimal part of the problem using pen and paper and getting that working perfectly(tested and everything). Only then would you start adding to it. For example, if you had to create an autocomplete tool, first you would decide which data structure to use. Assuming you chose to use prefix trees, then you would figure out how to load the dictionary file and store into the program. After testing it to make sure it works, then you would work on getting user input and finally work on the core logic of the program.

  No.13294

>>13292
Contrary to popular pointy haired boss beleif, UML isn't good for design, my napkin drawings are more expressive than a formalized language.
But that's not to say it's useless, it shines on big teams or on docs when you need to communicate unambiguously with people you'll never meet.

  No.15228

I believe it's important to limit the complexity you're willing to create with a project.

As an example, I don't believe most programs would require more than 1000 lines of source code to implement. Even neglecting the differences between languages, this seems to be reasonable.

  No.15231

>>15228
There are things that are inherently complex. You won't implement a proper C-compiler in 1000 lines.
Generally, the amount of lines you need depends on the primitives and abstractions that you already have. If those aren't there, you'll have to assemble them first.

  No.15244

>>15231
>There are things that are inherently complex. You won't implement a proper C-compiler in 1000 lines.
Of course not everything will fit in 1000 lines. Something like a videogame may have 1000 lines of dialogue alone.
For these instances, I would say you could increase the limit by an order of magnitude and say it won't need more than 10,000 lines of source code.
I would think it's very telling of how poorly the problem is being solved if it needs more than 10,000 lines though.

I wager a "proper" C compiler could be written in 1000 lines if a language like Common Lisp was used.

>Generally, the amount of lines you need depends on the primitives and abstractions that you already have. If those aren't there, you'll have to assemble them first.

It also depends on how you approach the problem, which is affected by the choice of language.
A Lisp program will have more explicit conditionals for customizability than a version of that program written in Forth, as an example, and both of those would probably be more forgiving to the user than the same program written in an assembler language.

This is partly why I gave an upper bound. Some languages are more brief than others, but 1000 lines seems like a good ceiling to smooth the differences between them for many problems most people will tackle.

  No.15256

From most general to least general:

>Just write a lot of code. Bad code, good code, whatever.

I was too scared to just write a lot of bad code at first and it hurt me. Don't be scared to write shitty, ugly, cringeworthy code. Just write it. Implement everything.

>Look into libraries/frameworks

Don't reinvent the wheel comes up a lot. But get into pygame, get into Django, get into using numpy/scipy to simplify your math homework. Think about big applications.

>Make your code state safe once you have a basic grasp of what you're doing

Saves headaches when trying to scale something.

>Document your code

Unmaintainable, undocumented code is what makes some of the old back ends of C very difficult. I was working on a compiler using Lex and Yacc, and because the documentation is a bit nebulous (it can be found, just not near as well organized as I was used to with LISP/Python/Java/etc), I had way more trouble than I should've had. I spent about half the project time on Yacc, when I could've been implementing things in assembly, making a second phase parser for it, or just generally doing something more fun.

With that said, don't over comment. But if you do ever go on to make something bigger, make tutorials. Write manuals. Sometimes programmers feel that writing documentation is below them. Don't. New contributors will thank you for it, and you'll be being directly useful.

Good luck man!

  No.15258

>>11086
How do you keep pure functions separate from ones with side effects?

>>11231
anon that musical project sounds interesting, you got some CODE? (on github)

  No.15263

>>15258
There's two indicators I've seen used so far: names and types.
In Scheme, you append an ! to the names of procedures that modify state. That way, you can intuitively discern them.
Types are used in languages like Haskell, which uses monads for state and side-effects. Something of type "IO String" can be read as: A String that can be retrieved by executing an IO-Action. If you want to do stateful computation, you use the State monad: "State Int String" reads as: A String that can be retrieved in a stateful environment represented by an Int.

Separating pure and stateful computation is generally easier in functional languages as they aren't designed with state being the default.

  No.16296

I suppose organization is important.
I usually just use whatever is traditional for the language and keep a program to a folder or keep several single-file programs in the general program folder.

  No.17570

This topic deserves more discussion.

  No.17578

>>15263

Intuitively it can be considered that IO is evaluated in Haskell when the binding operation is evaluated.

  No.18979

>modularize everything
>turn programs into many libraries
>keep those libraries small
>programs are thin
>programs just use the libraries in particular ways
>get those libraries to a debugged, stable & tested state
>develop libraries at the same time as the programs that use them
>3rd party libraries/OS APIs are soykaf? either reimplement them or wrap them with your own API
>applications download modules via package manager or git

Still looking for a language where I can do this comfortably. There's always a build system, package manager or language limitation that makes it hell.

  No.18983

The two big things I taught apprentices years ago: first, test your code. second, DRY (don't repeat yourself)

  No.18984

>>18979
most (if not all) of these depend on your community rather than the language itself. most programmers would desire features like these but getting them to agree on how to implement such standards and then maintain them is a painful reality of software development.

  No.18986

>>11088
And frankly it's soykafty. Tabs are configurable in any sane editor and modern displays support well over 80 chars per line. For the modern era I would use 100 as a soft limit. Readability Drumpfs style, imo.

I enjoy Python as a language but the PEPs and other hokey soykaf I can live without.

  No.19046

>>18984
The way I can think of is to have a benevolent dictator with good taste who picks and chooses among libraries and curates a standard. Kind of like Python, but better.

Imagine I made my own language. I would make it have the smallest core possible with no standard library. I would add only two things: the best module system and native interface I can possibly come up with. Anything not directly implemented by the language is a library and the FFI ensures you can make libraries that can talk to native software via platform ABIs.

I think the crucial thing is to reserve good symbols for libraries. Nowadays, its like domain names, first come first serve. Early adopters get all the noble symbols. What if I write file-system library and it is like kicking dead whales down the beach and someone writes fsAlt2 and it rocks? The file-system symbol should be the best implementation. That way anyone can import that and automatically gain access to the state of the art. I was thinking something along the lines of a symbolic link or interface; these noble names refer to a standard API and it links to the best inplementation but you can still switch if you want.

The two points I'm making are: separating the "standard library" from the language itself, and curating a list if "standard modules" that is somehow separate from the rest of the community's modules.

The reason for all that is that no one wants to use and build upon doomed APIs, so they naturally prefer the standard library and well-used software. So if we can somehow remove that risk, we make it that much easier to make modules.

For example, in C everyone pretty much makes their own data structures and they're all incompatible with each other. In other languages, types generate tremendous API incompatibility.

So what I had in mind was: everytime a problem domain came up, some smart people would study it and define some common abstractions everyone could build on. Suppose people started making a lot of markdown libraries; smart people would figure out its just parsing and compilation, and if there are existing abstractions that support that, they incorporate the markdown functionality into it. So what users get is markdown as an option of a general encoding/decoding API rather than some self-important cool-name library with renderMarkdown methods. Users control which library actually implements that functionality by specifying it as a dependency.

  No.19048

>>19046
>Imagine I made my own language. I would make it have the smallest core possible with no standard library. I would add only two things: the best module system and native interface I can possibly come up with. Anything not directly implemented by the language is a library and the FFI ensures you can make libraries that can talk to native software via platform ABIs.
You're almost describing Forth, Smalltalk, Lisp, and other customizable languages.
I don't mean to diminish the idea, however. The world would probably benefit from another very customizable language.

>I think the crucial thing is to reserve good symbols for libraries. Nowadays, its like domain names, first come first serve. Early adopters get all the noble symbols. What if I write file-system library and it is like kicking dead whales down the beach and someone writes fsAlt2 and it rocks? The file-system symbol should be the best implementation. That way anyone can import that and automatically gain access to the state of the art. I was thinking something along the lines of a symbolic link or interface; these noble names refer to a standard API and it links to the best inplementation but you can still switch if you want.

The issue with this is differing interfaces.
It's also not much of an issue, depending on how libraries are delivered. Someone could take a name from someone and the better library would probably win, because people would use it.

>The two points I'm making are: separating the "standard library" from the language itself, and curating a list if "standard modules" that is somehow separate from the rest of the community's modules.

This is a hallmark of the very customizable language.

>The reason for all that is that no one wants to use and build upon doomed APIs, so they naturally prefer the standard library and well-used software. So if we can somehow remove that risk, we make it that much easier to make modules.

Yes.

>So what I had in mind was: everytime a problem domain came up, some smart people would study it and define some common abstractions everyone could build on. Suppose people started making a lot of markdown libraries; smart people would figure out its just parsing and compilation, and if there are existing abstractions that support that, they incorporate the markdown functionality into it. So what users get is markdown as an option of a general encoding/decoding API rather than some self-important cool-name library with renderMarkdown methods. Users control which library actually implements that functionality by specifying it as a dependency.

The issue with this controlling approach is the same issue that leads you to consider this. Anyone sufficiently determined will probably come to reasonably similar conclusions and create their own ecosystem.

In the end, controlling programmers isn't something a language should strive for. That's how languages like Go happen.

  No.19065

>>19048
>You're almost describing Forth, Smalltalk, Lisp, and other customizable languages.

Yeah. I have nothing but respect for all of those and I'm heavily inspired by them.

Scheme is my greatest inspiration. I think its biggest weakness is the fact it doesn't have an actual standard module/library system. The amount of fragmentation this single fact has caused is astounding. Even the multiple standardized module systems are implementation-defined. They simply didn't go all the way.

http://www.scheme-reports.org/2009/position-statement.html

>Anyone sufficiently determined will probably come to reasonably similar conclusions and create their own ecosystem.


My intention would be to completely support those guys. In fact, my dream language would allow me to be one of them. One among many.

The idea is to make a good enough base system that doesn't have anything for people to dislike. Mathematics, Unicode text, some essential data structures. If we can get that solid foundation right, then maybe that will attract developers, all by itself.

This is why I think a good module system is such critical feature. The smaller the language is, the more it needs modules. Creating and using libraries must be easy and painless. This way, a small language can expand.

I wonder what Scheme would be like today if it had a good library system since day one

>In the end, controlling programmers isn't something a language should strive for.


In what way would the language control programmers?

I think the only real control would come from the language's standard or reference implementation. They control what is and isn't possible to express in any given language. When it comes to the libraries, even if I was the language's creator, I'd be on equal footing with everyone else.

Hell, I actually want people to one up me so that I can learn from them

  No.19083

>>19065
>I think its biggest weakness is the fact it doesn't have an actual standard module/library system.
R7RS's library system seems to work pretty well for me.
(import (scheme base)
(scheme lazy))

(define-library (foo bar)
(import (scheme base))
(export baz)
(begin
(define baz 0)))

  No.19087

>>19083
IIRC library loading is still implementation-defined. So you can write modules but you can't really make them load in all implementations because they all have their own incompatible quirky conventions regarding where files go. Am I wrong? Hopefully I'm wrong about this...

  No.19089

>>19087
Nope, it's still implementation-defined, but isn't it like that for any language with multiple implementations?
Moreover, due to the small spec and standard library, if you want to write anything useful with Scheme you will have to use implementation-specific libraries and facilities.
There is Snow, which tries to be a common package manager. I think there is talk of including it into R7RS-large.
http://trac.sacrideo.us/wg/wiki/Snow
http://snow.iro.umontreal.ca
Unfortunately Scheme is very fragmented by its very nature. If you want to write Scheme you're gonna have to choose an implementation. Most schemes don't even support the latest standard.
R7RS-large will probably mitigate this, but it's gonna take years before it's ready, and even more time before the implementations implement the full spec.

  No.19091

>>19089
>isn't it like that for any language with multiple implementations?

Not really. If I write a Python or Ruby library, I can be reasonably confident it will be usable on pretty much any implementation. The user just has to install it.

It's not even a package manager thing. Implementations go out of their way to be incompatible down to the most basic of mechanisms like how exactly and from where they load stuff. Racket assigns special meaning to the files and their paths and extensions. In order to make it work, you'd need a separate repository structure for each implementation. Simply unacceptable.

>Moreover, due to the small spec and standard library, if you want to write anything useful with Scheme you will have to use implementation-specific libraries and facilities.


Why does it have to be that way? If Scheme had a module system, much of the rich functionality could have been exported through it. The language could remain small and there wouldn't even be a need for a "large" version. If Scheme had a good, well-designed FFI built-in, it wouldn't need any favors from any implementation at all; it'd be a full systems programming language with full access to the underlying platform.

>Unfortunately Scheme is very fragmented by its very nature. If you want to write Scheme you're gonna have to choose an implementation.


I know. There is actually no such thing as a Scheme language; there's only Racket, Guile, Chez...

It's a pretty sad situation if you ask me. Scheme doesn't benefit at all from network effects and what little value each implementation manages to amass will never be as good as a single unified modular Scheme could have been. Instead of developers standing on each other's shoulders, they step all over each other's toes.

  No.19100

>>19091
Scheme's problem, in my opinion, is that it's defined by a committee writing a spec rather than a "benevolent dictator" like Ruby, Python or Clojure.
It's very hard to innovate when things are run by a committe, because there's gonna be lots of people with different agendas trying push the language one way or the other.
It also seems to me that it's being developed with the intention of having a very small and simple core to build upon, rather than being a generally useful language.

All the things you said would be feasible if there was a reference implementation that all schemers would use and develop. But, like you said, there is no such thing as "The Scheme Language", only a bunch of schemes defined by the Reports.
So if you want to use Scheme, you have to choose some implementations and swear by them, or wait until ~2020 when we can hope to see something about R7RS-large (which still won't fix Scheme's problems, I'm afraid). Or you could do like Racket and take Scheme, and build upon it so much that you can't really call it Scheme anymore, but then people will complain that it's not really Scheme anymore and the community will split up once again.

It is indeed sad to see such a beautiful language burn its potential because of this bullsoykaf, but I'm afraid that's just the way it is. I don't think there's ever gonna be a standard Scheme implementation.

  No.19107

>>19100
>It also seems to me that it's being developed with the intention of having a very small and simple core to build upon, rather than being a generally useful language.

That is the right approach. The problem is they chose the wrong audience to focus on. They left the task of building upon to the implementations rather than the users of the language.

By leaving critical parts of the specification undefined, they're making life easy for implementations when they should be supporting programmers instead.

The commitee doesn't actually have to innovate at all. They've already created an extremely clean and well-designed language. They should be empowering programmers that actually want to use it instead of feeling sorry for implementations and their hardship when it comes to standards compliance.

It simply doesn't make any sense to split the standard in two. A good module system would have had minimal impact on the academic users of the language. That single change would have been easy to promulgate. I bet it would have been much better received than R6RS was. Once they had slipped that past the academic community, the obvious next step is to specifiy optional standard libraries, one by one. Or just let the community do it themselves. Everyone could have been happy

>Or you could do like Racket and take Scheme, and build upon it so much that you can't really call it Scheme anymore, but then people will complain that it's not really Scheme anymore and the community will split up once again.


I think Scheme should be an inspiration, not a template. Since Scheme doesn't really add up to a language anyway, Racket was right to stop calling itself a Scheme

I also think newLISP is interesting. Looks like a fresh approach, free from all these misguided standards bodies

  No.19113

>>19089
>Nope, it's still implementation-defined, but isn't it like that for any language with multiple implementations?
C, C++, and Common Lisp all seem reasonably portable.

  No.19120

>>19113
Well C++ ABI is unstable between different compilers. Neither C nor C++ are portable between operating systems nor processor architectures. Also, since the subject is modules, they don't really have that as a concept, and explaining the hardship of linking object files will probably derail the thread even further.

I dunno about Common Lisp.

  No.19125

>>19120
Common Lisp has a portable module system called packages, but packages may do things that aren't portable between systems.

There's no standard Common Lisp ABI because Common Lisp doesn't concern itself with that. There's an FFI library that targets several implementations, but that's inherently not portable beyond those implementations and I wouldn't recommend using it.

  No.19132

>>19120
>Neither C nor C++ are portable between operating systems nor processor architectures.

the exact same C code will do the exact same thing whether you copmpile it for ARM or for x86. I don't know what you're on about.

  No.19156

File: 1475913701080.png (73.85 KB, 184x200, 1470886525874.jpg)

>>11083
The most important thing is time, manage your irl time and then you will have time in the clear for programming.
Go to bed early, don't use the computer for more than three hours without taking breaks, and when you do take breaks use that time to exercise.
Not some pussy exercise, I mean like lifting and running, trampoline etc.

As for the mental aspect, most people get impostor syndrome in programming, and sometimes you become frustrated so that you don't feel like programming anymore.
Speaking from anecdotal experience, the best programmers I have known have been rather aloof people who tend to not take anything seriously. So the mentality you have to adopt is that of an outlaw or a pirate; do not allow any self-pity no matter how much soykaf you're in, remain detatched, as a programmer you have a sickness and the only cure is to keep moving, like a stray cat navigating the city streets, fixations are the enemy, don't allow it.
This is pretty much my little creed I invented for myself after more than 4 years of embedded automotive/aeronautical control systems programming.

  No.19157

>>19132
You have to compile it again. You can not compile it for x86, take the compiled code and run it on ARM

  No.19158

>>19156
>Not some pussy exercise
>trampoline
if it's fun it's not exercise

  No.19223

File: 1476197801999.png (208.15 KB, 200x175, structured-logging.png)

Log JSON objects that actually describe what's happening instead of just a bunch of stupid text that you'll have to parse later.

  No.19224

>>19223
What makes JSON so great?

Not every language has a library for parsing and it's very complicated in comparison to say, line-separated values.

Custom solutions are usually better.

  No.19225

>>11193
Funny to find another swiss lainon in here.

  No.19226

Remember that there are several ways of doing the same thing. Don't let someone tell you to do it that way because they say so. And don't tell someone to do it this way because you say so.

  No.19230

>>19224
>Not every language has a library for parsing [JSON]

Name some.

  No.19232

>>19230
I'll be using this as my reference: http://json.org/

APL (Dyalog does support this.)
Forth
any machine code (There's probably a program somewhere that does this.)
many versions of BASIC

There are more, of course, but this is a suitable list.

  No.19233

>>19232
I can't help but find this hilarious
Does brainfuck support json? how about piet? malbolge?
SNOBOL? CHIP-8? does λ-calculus support json?
json isn't included in the scheme standard afaik, and obviously not in ANSI-CL
Maybe DNA?
man, NOTHING has support for json! such crap

  No.19234

>>19233
>Does brainfuck support json? how about piet? malbolge?
They don't have libraries, but they're esoteric languages, which is what you seem to be implying about the languages I've mentioned.
>SNOBOL? CHIP-8? does λ-calculus support json?
I was going to mention SNOBOL, but I don't believe it has a library for it.
CHIP-8 is a machine code.
The λ-calculus also has no library for JSON and touches upon another important point I was going to make.

It's not particularly easy nor possible to support JSON in several languages because of the type system. Most Forths and most machine codes are untyped, so how should they represent JSON? JSON works well for JavaScript, but it shouldn't be forced upon every other language under the sun.

>json isn't included in the scheme standard afaik, and obviously not in ANSI-CL

Both of those languages have libraries for it and type systems capable of supporting it.

>Maybe DNA?

Now you're being overtly facetious.

>man, NOTHING has support for json! such crap

JSON is crap.

There's a saying: When there are two possible solutions to a problem, the correct is the simpler.

When is JSON simpler than customized solutions?

  No.19235

>>19234
I both agree and disagree with you.
Looking back at the post that spawned this, the advice is bad. Outputting plaintext with a custom format is better than forcing a format originated in javascript.
However
https://en.wikipedia.org/wiki/Sarcasm
I wasn't exactly implying that APL and FORTH are esolangs, but of course they are way off the scope of anyone who'd use json. Sure enough, why would anyone using assembly language ever use json at all? You do realize there are tools that are appropriate for different applications, right? Be it json or YAML or whatever you like, it cannot possibly be useful for every language ever and for every possible use case. You particularly chose the least used languages ever (even an semi dead language such as BASIC) to make your point.
I mean, why ever make use of TCP/IP, since there are things (like some watches!, and low-end calculators!) that cannot possibly use it, right?

  No.19236

>>19235 [cont]
but if you are using python, or ruby, or any language that is not APL or FORTH (there is quite a number of these) and you want to save some structured state in a file, and there is a library for this and a format for this, you don't go and reinvent the wheel, if what's there fits your needsñ

  No.19237

>>19235
>Looking back at the post that spawned this, the advice is bad. Outputting plaintext with a custom format is better than forcing a format originated in javascript.
We agree with this.
>You do realize there are tools that are appropriate for different applications, right?
I try to use a smaller amount of general languages than a large amount of specialized languages, Forth being the best example of this.
>Be it json or YAML or whatever you like, it cannot possibly be useful for every language ever and for every possible use case.
We also agree here.
>You particularly chose the least used languages ever (even an semi dead language such as BASIC) to make your point.
I chose languages I use, sans BASIC. The only BASIC that's useful to me is TI-BASIC, but I prefer HP.
>I mean, why ever make use of TCP/IP, since there are things (like some watches!, and low-end calculators!) that cannot possibly use it, right?
Unlike the data format, use of TCP/IP can't be changed by a single person at this point. It's more of a force of nature, for now.
The networks provide so many protocols and their use isn't yet optional.
I do believe in treating the internet as a data sink of sorts. I would advise relying on no particular protocol. Write programs to work with any protocol, which is fairly easy, unless there's a good reason not to, such as an important size or efficiency advantage or a quality of a protocol that is required.

  No.19271

>>19235
>Outputting plaintext with a custom format is better than forcing a format originated in javascript.
Why does it matter that it originated in javascript? It's a good format, it's very easy to parse and to serialize in languages that have arrays and hashmaps or anything similar.
Of course it's not always the best solution. I've recently worked on a program that defined its own protocol based on json, and it was fuarrrking horrible. But that protocol would have been even worse if those idiots decided to roll out their own horrible plaintext protocol, and write a horrible parser for it.
It's not the best solution, but it's still a good one, and unless you have good reasons to use a custom format it's better to use that, or csv or what have you.
The example the anon above made with logfiles is stupid, I don't think anybody with half a brain thinks json is a good logfile format. For most cases, at least. I think tab-separated values would do the job, but anything more exotic is just a waste of your and your users' time. I don't want to write a parser for your stupid fuarrrking log format. Hell, I'll take json over it.

  No.19272

>>19271
but that was my point. see >>19236, if you have a use for it, it is often the best tool for the job, lest reinventing it yourself.
And yeah I meant logging when I said it's better to just use a minimal plaintext format.
I favour YAML instead just because it's not a js solution, but both really are a proper tool for a common set of problems.

  No.19474

>>19156
>The most important thing is time, manage your irl time and then you will have time in the clear for programming.

Lainon/s. I desperately need help with that. I can't manage my time for soykaf. And I'm about to graduate.

As for the stray cat analogy: I love programming and I'm quite good with ad-hoc, logic, and pretty much problem solving. Also x86 ASM. But for the sake of everything I don't do soykaf until I start up something; call it distraction, call it procrastination. But once I started with a task I produce relatively good stuff. But then when I take a fun break (playing something, watching something) I walk right out of the "zone."

Generally for <=medium-sized projects, when there's a deadline I put the real work/implementation off till the last week/s or so and nail it, but feel bad that I could have done exceptionally better (for my own development, rather than the entity that enforced the deadline) if I finished early and organized my time like some idols in my life.

I just wanna be that stray cat that doesn't stop programming meaningful problems... For example write a software renderer, finish that compiler project, finish that browser I worked on... Work on my compsec knowledge and reverse engineering. This require continuous dedication. Currently I am dedicated in long bursts and long attention spans but with overly-lengthy intervals between those bursts.

I'm just not used to managing my time since I was a kid and would appreciate any practical tips on-par with the lainon I quoted.

  No.19477

>>19234
It's always simpler to have an agreed-upon format.

If you have a language that nobody really uses anymore and it doesn't have something as simple as JSON support, you honestly expect me to believe some custom solution would be better?

If it doesn't have json support, you add json support. It's that simple. It doesn't even have to be json, make it S-expressions if it bothers you that much.

I bet most if not all of the languages you mentioned can simply call a C library to get the functionality. Assembly surely can. But why the hell would you even use assembly to write your entire program?

>>19271

And why is it stupid Mr. Half brain? The exact same data will be output, it will be human readable, it's easy to parse and you can easily transform it into an old school log line later if you really want to; its much harder to parse the logs into data structures.

  No.19479

>>19474
Cut off distractions.
Important: schedule yourself. If you allocate an hour of your day to programming, then it'll be easier than if you randomly sit at the computer thinking about programming.
Here's from experience: I set my last hours in the day to start the computer and work in a particular project I have. I'd just add one feature. As soon as I did, I could let myself off the hook or keep hacking (I'd usually keep at it unless I felt tired). One day I just added a hashing function for commands, another day I added a better command interpreter, another day I just added the core functionality...
After a week I had a more complete project than I would've done if I hadn't organized myself.

  No.19481

>>19474

I recommend Getting Things Done For Hackers at https://gtdfh.branchable.com/

and Time Management for System Administrators at
http://shop.oreilly.com/product/9780596007836.do or http://www.tomontime.com/ (videos) or if you want it free , then the Genesis Library.

I also recommend the book Momo (http://www.michaelende.de/en/book/momo or https://www.amazon.com/Momo-Puffin-Books-Michael-Ende/dp/0140317538) or the movie (https://www.youtube.com/watch?v=8Q_JYYcBP2Q) on the nature of time itself.

  No.19484

>>19479
>>19481

Aw man... I suck at process scheduling. Why do I have to be a kernel

  No.19487

>>19474

I use Beeminder (a site where you pre-commit to do more or less X per day) and Rescue Time (a site that tracks how much time you spend using various applications).

I have a goal like 'Do more than 4 hours programming per day' and drive it by the amount of time I spend using atom, my text editor.

It's not a perfect system and 'time using editor' is not a perfect metric, but it has helped me to increase my productivity.

Do you experience video game addiction? I have for many years. I plan to spend the weekend reading a book or coding up a new idea, but instead I spend 32 hours playing Europa Universalis. Beeminder has really helped me here - I created a 'do less' goal to force myself to play no more than 14 hours per week and I use Rescue Time to provide the data. This has really helped me a lot to use my time more efficiently and to combat my depression/self-loathing.

If you have trouble with akrasia or procrastination I seriously recommend giving Beeminder (or similar pre-commitment tools) a try.

  No.19488

>>19479
>>19481
>>19487

Same guy.

Thank you, from the heart. I'll consider allocating a fixed amount of time to program inside the editor (Vim, of course!), check the books you suggested, and the 2 services Beeminder and Rescue Time.

Will hopefully update in a week if my situation got better.

Also >>19487
Yes. I did experience video game addiction. Which got me into assembly and modifying stuff, which got me into programming and gave me decent WPM.