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

lainchan archive - /λ/ - 20939



File: 1482183115760.png (471.57 KB, 300x300, programming-8239.jpg)

No.20939

Hi /λ/.

I've been programming for about one year now but never managed to master a language. Two months ago, I set the goal to master Python.
After making Codeademy course, reading Learn Python The Hard Way and other books and making some exercises I got to the point where I know the language, but I do not master it.
If I needed to make a simple script, I would make it in minutes but if needed, I couldn't make a big project.
What can I do to master it?

TL;DR: need some tips mastering a programming language

  No.20941

Are you sure your problem is Python? Where did you got stuck on your big project?

Mastering a language won't magically make you a software engineer. If you want to build complex systems you should learn how to make complex systems, not just a single language.

However, if you really think that your Python knowledge is the obstacle, you should read the language specification and related documents, they should contain nearly everything you need to know about the language:
https://docs.python.org/3/reference/

  No.20942

>>20941
No, the problem isn't Python. I just gave it as an example.

  No.20943

What's your real problem?

  No.20944

>>20942

Python might be the problem imho. It's got about a million features that will help you further in your programming career but if you'd like to learn how to make complex systems maybe you should start with a simpler language? I wouldn't even go for a language that was intended for object oriented development.

By all means keep using python though it's great for working on simple scripts, games, etc.

Try C, Common Lisp or Scheme there's some great books on all three of those languages (or dialects). I think working working with a smaller language will help you realise what >>20941 was talking about, there's more to creating software than mastery of a language.

  No.20947

Mastery is a function of time.
Write a lot of things on your own, as they said before me, a big project is no parameter for your mastery of the language, on the other hand, if you think it is, then make a big project on your own. Figure things out by yourself, and I promise you'll get much closer to mastery

On topic, C is the language I'm trying to master. It's the closest language to the actual computer implementation without being it assembly.

  No.20948

If you really want to try your hand at implementing *systems*, C, Scheme, and CL are the best for that IMHO. Scheme has some ergonomic deficiencies, but those can be patched up, and it's beautifully simple. C (for its many flaws: make sure you understand pointer alignment and just what is and isn't UB before writing anything serious) is the language of systems software, that which is close to the hardware, and it doesn't look like that will change soon (although Rust is its first real competition in decades, it's really aimed more at C++ than C itself). And CL is the language of interactive development. It is, as Alan Perlis put it, a language for building organisms. It's also one of the very few languages that got OO *right*, rather than, say, Java and C++, which really didn't.

But enough language wars. While those are my preference, systems can be written in any language (and some, namely the Erlang people, would disagree vehemently with my list). It's really about learning good design. That's something that comes with experience. Play around. Build stuff. Learn what works, and what doesn't.

  No.20949

>>20939
>I've been programming for about one year now but never managed to master a language. Two months ago, I set the goal to master Python.
That's simply not enough time to master a language.
Python's not a language worth mastering to begin with.

Pick a respectable language, such as a Lisp, and focus solely on it. After some time, you'll begin to think with it very well. You can then begin adding other languages.

Read more than you program.

>>20947
>On topic, C is the language I'm trying to master. It's the closest language to the actual computer implementation without being it assembly.
There is no such language. Forth is closer than C with this, however.

All higher level languages necessarily ignore features of the computer, unless implemented as the lowest level, which can be said of Forth, Lisp, and some others.

  No.20950

>>20949
C is the one that has a more straightforward model of how the program is actually allocated in memory and so on.
Forth uses a VM that hides the implementation details. In forth you don't need to know the actual layout of the program, variables are allocated behind the scenes, etc.

  No.20952

>>20950
oh and higher level languages take it far beyond that, in lisp the implementation is hidden behind several layers. In C you know exactly what happens when you call a function, you can have a pretty close model of how the stack frames are made, and what the dynamic memory allocator is actually doing behind the scenes.

Not to say that forth doesn't have a very low level model though, if anything, it's functional model is less convoluted than that of C and its constructs are more versatile (CREATE DOES> n soykaf)

  No.20953

>>20950
...If you're running forth in a VM, you're not doing it right. Forth is usually interpreted on the bare metal, with no real GC, and thus no behind-the-scenes allocation. If you want something allocated, you have to do it explicitly. And what gets pushed to the stack for you but the address of said allocation in RAM.

  No.20955

>>20950
I wonder if this discussion is suitably off-topic for this thread. I'm leaning towards not.
>C is the one that has a more straightforward model of how the program is actually allocated in memory and so on.
That's questionable. The C standard says nothing of this. You're effectively discussing the behavior of one or two goliath compilers that are too complex for a single human being to understand at this point. That's hardly straightforward when you consider it that way.
>Forth uses a VM that hides the implementation details. In forth you don't need to know the actual layout of the program, variables are allocated behind the scenes, etc.
ANSI Forth does and, while a decent starting point, it's the Forths implemented in hardware and for certain hardware that are fun to use.
A Machine Forth is very clear about allocations. Most Forths do use a dictionary, however, making this all straightforward, regardless.

>>20952
>oh and higher level languages take it far beyond that, in lisp the implementation is hidden behind several layers. In C you know exactly what happens when you call a function, you can have a pretty close model of how the stack frames are made, and what the dynamic memory allocator is actually doing behind the scenes.
Well, Common Lisp does have an interactive disassembler specifically so the programmer can actually see what's happening.

  No.20958

>>20955
You're confusing the compiler with the object code it produces.
Anyway yes I'm talking about particular implentations here, and particularly, C code for Unix (because it doesn't really make sense to use C outside of Unix regardless of what people may say).
With C you have almost direct control over how the memory is laid out in memory at runtime.
Forth may too have some of these features, but I hardly see any forth code out in the wild, I'm mostly interested in the structure of programs you're likely to see out there. If I'm analyzing the behaviour of a program or system, a knowledge of C is more likely to be useful than a knowledge of forth. Almost everything is written in C, even forth systems have to be modelled on top of the ELF format to even run on the OS. Embedded systems notwhitstanding, if I were to make an embedded system, I'd use forth, but I use a computer that connects to the internetz, that uses encryption primitives, and so on.

  No.20960

>>20958
meh, nevermind my answer, object code output does depend on the compiler.
I'd learn forth more swiftly if it wasn't fuarrrking hard to find any resources on forth functionality. Not that I've mastered the basic concepts but there is even less about the inner mechanisms of it, and there is a soykafload of documentation on the layout of a C program.

  No.20962

>>20960
Leo's books, and the ANSI forth spec are both good resources, AFAICT. The internals of forth are actually pretty transparent: It seems you could implement it in maybe a kline or two of C. But I don't have a knowledge of forth comprehensive enough to say for sure.

  No.20963

another day, another derailment. is there a cult around here or something? the guy asks for help with python and people seriously tell him to learn c or a lisp instead. nice to see zero mention of theory or sound development practices too.

  No.20967

>>20939
Since it seems to be an issue of software architecture skills, my suggestion (besides reading manuals on the topic) is to learn to use Qt (pyqt if you want to stick to Python but it's not very good).

GUI programming is what originally spawned OOP because applications in the field tend to become big and complicated quite easily. Qt is a complex framework built with clever features and the documentation is phenomenal. There's lots of examples and explanations, including the fundamentals of the engine.

In general, if you need to learn software engineering my suggestion is to look at how big frameworks work. React, node.js, nginx, apache, various garbage collectors and virtual machines, whatever.
Software engineering books work as well, but I think it's an instinctive reaction of any thinking animal to take a look at those and think the discipline is a colossal pile of bollocks. It isn't, really, but it sure is presented that way most of the time.

Btw, I think Python in general is a bad choice for large applications, given dynamic typing and an OOP fragment straight out of a horror show.

  No.20971

>>20963
>is there a cult around here or something?

Crap. He figured it out. Sacrifice him before he tells anyone.

  No.20975

>>20963
For the record, I only mentioned C because I mistook the OP to say "langauge mastery thread" or something.
However the disussion so far is healthy and somewhat relevant, I do not believe there is much to master about python, that python itself is very straightforward (read: limited).
Most any other language has nifty somewhat obscure features or advanced concepts to leverage. Think C memory management, lisp macros and introspection, haskell tricks on monads, Scheme's call/cc. They're mostly language-dependent features, while python (to the extent of my knowledge) has nothing but it's linear execution scheme (and "There is only one way to do it") and a very simple OOP model.
Concepts that would, instead, make him progress in his python programming are univeral programming concepts, which are usually taught in the light of other languages, which python (or it's culture) is not much interested in teaching. Most if not all books on python are "learn to program for the first time", and everything is readily handed to you in libraries so you just put them together like legos.
Therefore I think Scheme is a very good suggestion. The simplicity of python plus the best models in programming technology.

  No.20976

>>20975 [addendum]
C is relevant too, for now he will know what is actually happening behind the scenes, which I'm sure it'll help him in one way or another.

  No.20979

>>20975
The rule of thumb is that you learn C and/or assembler to understand the computer. And then you learn Scheme to understand recursion, algorithms, datastructures, and generally how to write to programs *well*. Or the other way around.

In general, I think this is pretty good way to do things, MIT be damned: Scheme is really good at algorithms, and has all the datastructures you need for that sort of thing, usually: heterogeneous vectors, conses, numbers, and functions can get you pretty far. And while it leans functional, it still has procedural primitives, so you can take either approach with your algorithm, another important thing. And if you want to play with OO... Well, Scheme was purpose-built for that (well, the actor model, really. Close enough. It's still good for exploring OO, though).

As for C and assembler, they don't need any introduction, nor do they need any explanation. Both, in one form or another, are requirements for anyone who wants to say that they understand computing and keep a straight face.

  No.20980

>>20979
I can agree with most everything in this post, except C.

Learning one of your machine's assembler languages really allows one to skip over C if they want. Linus Torvalds inspects the compiler output to make certain it behaves properly. It's not difficult.

  No.20981

>>20967
Do you know any good books on the topic?

  No.20983

>>20939
Not >>20967 but

If you are adept with Python I recommend "Programming Python", of Mark Lutz.

http://www.it-ebooks.info/book/614/

It goes beyond learning the language into doing real applications/scripts.

I have the feeling that this is just what you are looking for.

You might be able to find the PDF online.

GL;HF

  No.20984

>>20981
Not being a fan of the literature I'm not extremely knowledgeable, but I can suggest this: https://en.wikipedia.org/wiki/Design_Patterns

Unfortunately I'm Italian and almost all the few books I used during my Software Engineering course were in Italian.

  No.20986

>>20980
I learned assembler first, then C.
I didn't know about stack frames after deep into C.

  No.20987

Language mastery is overrated. Languages are tools, and you use the best tool to accomplish your goal.

If you want to be a production programmer, then you don't need to master a language at all; you just need to be able to read code, work with others, and know enough about the language you're using to get stuff done. If you want to get good at this, start contributing to a medium or large sized project.

If you want to go the academic route or be a programming guru, it's a tougher row to hoe. Read up on theory and then start contributing to geek projects like interpreters or debuggers. Design your own programs and implement them - and when they suck (which they will if they're of any decent size), reimplement them properly. Optimize things, learn a debugger inside and out.

Either of these methods takes years. Keep at it. You won't feel like you're accomplishing much, up until you look at code you wrote a couple years ago and realize how horrible it is. And work with others - you'll learn twice as fast that way.

  No.20988

>>20939
Pick a project. Implement it.
It doesn't matter what the project is, as long as you are interested enough to actually work on it. It doesn't matter what language you use, as long as you know how to read the documentation.
Once you are done, you will have more knowledge of both the language and the project. You may realize that you tried to do something in an embarassingly terrible way. That's alright, you've learned the wrong way to do something, and you understand that it is wrong.
Wash, rinse, repeat. Mix in some reading by more experienced programmers to avoid mistakes that were made decades ago. Read (and modify) other people's projects. Get confident (but not necessarily masterful) in two or three languages. But the only trick is practice.

  No.21019

>>20987
I feel like I know a lot of languages well but I feel that I don't have a particular project that shows my mastery over the field of programming. I was thinking about just starting a C++ project and using all of the idiomatic "modern C++" styles and concepts, just to show that I can be proficient in this industry-prominent language.
On the other hand, I've been having a lot of fun learning Common Lisp and now writing C++ code sounds like a total drag.
What do you think I should do? Would it be worth my time to bite the bullet and write C++ just to potentially impress some superiors? Would it be a waste to make a complex application in Common Lisp because the industry hardly uses it? Should I even be worrying at all?

  No.21022

>>21019
Don't worry.
Use Common Lisp.
C++ is gross and no one actually knows it.

  No.21024

>>21019

Maybe I'm weird, but I don't find C++11 and above all that boring. I mostly program in Scheme, C, and Perl, but I don't mind dropping into C++ when I have to. I like the RAII concept and the functional features they've added.

Granted, I only learned C++ a couple years ago and only focused on the new style and features, so that might have something to do with it. Windows C++ code makes me recoil in horror.

Still, I'll take it over Java any day.