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

lainchan archive - /λ/ - 13410



File: 1452545510031.png (158.6 KB, 299x300, wizard.jpg)

No.13410

So, how you do to be a great programmer?
In my opinion most of you guys know much more about the average programmer that I know. Even i get really suprised with some things that you guys do. I always had this feeling that Im far way behind from you guys. So I just took the scip book and im willing to learn as much as possible before the uni classes get back.

I really wanted to hear some stories and tips about how you guys got good at programming.

  No.13411

>tips about how you guys got good at programming
Practice more than you read books.
Also relax, don't get burned out. Take a break to think about problems for a few hours, since you'll probably find a more elegant solution than the nested for-loops you think of first.

Also do what you want, jesus christ. Don't listen to /lambo/, /g/, or /tech/, about what you should be programming and how you should be a "leet C master kenerl maker". If webdev or gamedev sounds fun then by all means do it, because if youre not having fun you're doing it wrong(this goes for languages too, if you hate Python or whatever then try something else).

  No.13416

File: 1452551267602-0.png (18.76 KB, 200x193, cons10-308.gif)

File: 1452551267602-1.png (152.34 KB, 200x126, 1280px-Pipeline_MIPS.png)

File: 1452551267602-2.png (57.87 KB, 200x138, matrix.jpg)

>>13410
I read about the subject of computation constantly.

I also choose good languages to work with. Common Lisp, Forth, APL, and assembler languages that aren't x86 are nice, fun, or both.

Stay away from broken languages like C, C++, and all of these other languages you see floating around like Ruby, Python, Go, et al.

Never use a language with a syntax so complicated that you can't easily write your own simple parser for it or even imagine where you would start.

>>13411
Your second paragraph is good advice, but I would insist that reading is more important than practice.
I think about computation more than I read about it.
I read about computation more than I do anything practical with it.

With that said, I still build things that are useful for me. I have many more ideas than I do programs, which is how I like it.

I'll be starting on an implementation of a tool solely to make certain programming less of a pain for me. I feel this is a good use of my time, but this is also what I do for fun.

Back to the OP, you need to love the subject to get good with it. I can honestly tell you that creating in this subject is what I plan to do with my life.

  No.13419

File: 1452557168234.png (674.57 KB, 200x113, madoka_struggling_with_exercises.png)

If you are going to read SICP, don't skip the exercises! They are an essential part of the book.

  No.13420

I don't know what advice to give you but
practice (solve challenges, implement ideas you have, etc)
explore languages
and as they said, never stop having fun

  No.13427

Started learning C for fun then moved to SICP and Learn You A Haskell for a year. If you want to get better then try Scheme, C and Haskell to get some idea of a pure functional, inpure functional and inparative language.

  No.13428

You're a good programmer if you have good solutions to think back to when solving problems. Ever read Programming Pearls? It's a high quality book.

  No.13433

>>13427
I second this.
C will teach you what your computer is doing at the lower levels and most probably what you don't want to be using
and Scheme and haskell will teach you new ways of programming
Whatever you choose your main language (or none at all) you'll learn a lot from learning these 3 different approaches and families

  No.13435

>>13433
Don't forget Prolog and Smalltalk!

  No.13437

File: 1452620590802.png (166.26 KB, 109x200, fuckingkrauts.jpg)

playing a MUD or any other online text based simulation is a fun introduction to a dynamic computational environment, especially as a builder or admin if you can get the position; most MUDs have a "kernel" with some dynamic event/actor-based scripting language and a REPL players use to interact with the game

also any development or QA position at a trust funded startup with bubble chairs or government contract cube farm will teach you some of the more social aspects of the tech sector than what you will find reading flame wars on ycombinator or articles written by self-proclaimed "techies": if I could summarize anything its that we SICP-reading, meshnet preaching, "M$ a shit" spergs need to stop being such fuarrrking self-righteous console cowboys and organize instead of being taken advantage of by more socially adept (when this latter group includes the linux community, you know there is something fundamentally off with the mentality of most lisp coders: stop bitching about lisp machines not existing because of social problems and instead encourage folks to use lisp and check out places like lainchan)


>>13411
>Practice more than you read books.

errrr...yeee..no....yeee....sorta...programming things you can be proud of or use for yourself is far more about planning and self-evaluation and than just typing stuff

if by "practice" you mean exercises or random tutorials, thats great if you're trying to work for someone else or understand concepts as they're presented in something like SICP, an emacs tutorial, an article detailing OpenGL functions or a new language, but I spend most of my time reading things that have nothing to do with compsci or programming to divine the domains of project and craft I would get the most good out of ("web development" has become a joke unless you some weird inherent hard-on for CRUD systems or "the startup scene")

  No.13444

>>13437

I never got into MUDs, though I've connected to a few long ago. They do seem like a really fun project though, combining a text game based environment with combat, then handling it all on a server with separate clients. I've read that it's really hard to do though, well properly and extensively.

  No.13472

>>13411
>practice more than you read books

This can be turned around, if you find yourself only writing code, try to pick up a book, something out of your comfort zone.

  No.13473

>>13416
>Stay away from broken languages like C, C++, and all of these other languages you see floating around like Ruby, Python, Go, et al.

Why, tho, lainon?

  No.13475

>>13473
he doesn't like them

  No.13476

>>13473
>>13475
They are unnecessarily complicated.

When you learn a language with minimal syntax, you realize how useless syntax is.

C and C++ are famous for how error-prone they are. It's practically impossible to write a program within hidden errors in them. Not even C experts can do this.

The other languages I mentioned are just bad. They're slow, complicated, the language often aren't standardized, but even if they are they're prone to massive changes, like Python, and they all look and feel like ALGOL, except for a few almost meaningless differences. C and C++ are also ALGOL derivatives.

Get some variety in your programming life, instead of just playing with countless ALGOL derivatives.

  No.13477

File: 1452748503448.png (135.31 KB, 153x200, sd_conoha_study.jpg)

>>13410
As others have said in this thread, remember to have fun.

With that said, I think there's a balance of having fun and getting out of your comfort zone. Being out of your comfort zone will let you learn more new ideas and abilities, but having fun will keep you motivated to keep on working on things.

  No.13485

>>13476

This doesn't convince me of anything.

  No.13488

>>13485
Okay.

  No.13490

>>13477
>``I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''
>Alan J. Perlis (April 1, 1922-February 7, 1990)
https://mitpress.mit.edu/sicp/full-text/book/book-Z-H-3.html

  No.13550

File: 1453124404418.png (38.9 KB, 200x105, python.jpg)

>So, how you do to be a great programmer?

The question for me is more «How do you do to be a programmer?». I know the answer is dead simple, but I can't get to the level next to the basics understanding of syntax and specific rules of each language I try or tried to learn. I have many ideas, like this dream logger I talked about on /zzz/, a basic parser for interactive fiction or various scripts for automating some tasks related to file management or pentesting, but everything seem out of reach with the few skills I have. I don't even talk about contributing to open source softwares. I don't manage to find something easy enough to get done but also fun and challenging enough to keep me motivated.

Maybe I should get my shits wrecked while attempting to read thoroughly SICP before trying to write "real" programs again.

  No.13551

>>13550
Start from the very simplest. Abstract things out. Say you want to make that IF parser. You basically prompt the user for input, then split the input with spaces (as in: "walk east" -> ["walk" "east"]), then check each word against a list of accepted words.
After you've managed to get the first task working, work on the second, and so on, eventually you'll get to enhance it until you have something you like.
The idea is to abstract the functionality. Think what you want your code to do, break it down in steps, and for each step check the tools at hand and how they can be combined to accomplish that task.

  No.13554

>>13410
>So, how you do to be a great programmer?
Read a lot, code a lot, and love what you do. You will never be great at anything if you don't have any enthusiasm for it.

>Even i get really suprised with some things that you guys do. I always had this feeling that Im far way behind from you guys.

Don't fall for the Facebook effect. The Facebook effect is when you feel bad because everyone else seems to be happy and sucessful except you. The thing is, everyone has awkward moments and bad days, but for the most part they don't share those stories on their Facebook profile.

>Stay away from broken languages like C, C++, and all of these other languages you see floating around like Ruby, Python, Go, et al.

That sounds like a great way to alienating yourself and hurting your career choices.

Seriously, great programming is about problem solving, not languages. A great programmer can create amazing things in Visual Basic 6.

  No.13557

>>13554
>That sounds like a great way to alienating yourself and hurting your career choices.
For one point, programming is not about making a career out of it.
For another point, many "unpopular" languages still have many job opportunities and pay very well due to the relative lack of available programmers for those languages.

>Seriously, great programming is about problem solving, not languages. A great programmer can create amazing things in Visual Basic 6.

A great architect can use a rock instead of a hammer to build great things, but we all know that's stupid.
Choosing good tools, which means choosing good languages, is an important aspect of programming.

If you'd like, I can very easily point out several reasons for the languages I've recommended.

For one thing, the Common Lisp standard demands that conforming implementations provide a debugger, function tracer, macro inspection tools, and other like facilities.

This means that, unlike in languages like C, C++, Python, Ruby, Go, et al., the debugging tools work perfectly because the system was designed from the ground up with these facilities in mind.
There is no question of which debugger to use, because you will always use the debugger provided with your implementation.
Debugging is always done by source too. There is no binary debugging in Common Lisp development because the standardized semantics of the program are independent of the platform.

I have seen this pdb for Python, but I'm not familiar with how well it works across all implementations of Python. The other languages I've mentioned are either content with just using gdb or have several questionable debuggers to choose from, like Ruby.

  No.13568

>>13557
>A great architect can use a rock instead of a hammer to build great things

sorry just reminded me https://www.youtube.com/watch?v=P73REgj-3UE

  No.13572

>>13410
as someone mostly brand new to programming will this book benefit me? Or is it for those who already have a pretty thorough grasp of a language.

If it isn't, and on the other hand it will make me vastly more appreciative of the concepts im learning and have a better grasp as I learn them I don't feel I should miss the opportunity to read this.

  No.13573

>>13572
It was written for students with no programming experience.

  No.13574

Just do this. Screw everything else, if you finish this, you are on the right path.

http://www.freecodecamp.com/

  No.13578

>>13554
>A great programmer can create amazing things in Visual Basic 6.
Good craftsmen don't blame their tools; they pick good ones.

  No.13582

>>13572
Just read it man

  No.13592

>>13574
Not everyone wants to be a we b developer anon. Though it is probably the best way for beginners to get tangible results, but if your not interested in it it's basically just wasting time.

  No.13613

>>13574
Seems interesting. Although as the other anon mentioned you have to like web dev to get along with it. I'll have to get back to it as the classes return.

  No.13624

Similar question to the OP's:
How do you know you've learned a language? Is it enough to just go through tutorials and books?

I'm currently doing oracle's The Java Tutorials and reading Think Java and would like to jump over to C# next. From what I've read they're quite similar to each other so I'm assuming there isn't much harm in doing so.

  No.13625

>>13624
>From what I've read they're quite similar to each other
Can confirm, at a basic level they are very very similar, in fact our language for college is Java and they gave us a class on C#, we were given a cheatsheet with the syntax differences and told that its the same soykaf otherwise so yano just do what you do in Java. Personally I hate both languages although I would prefer C# a little.

  No.13627

>>13624
>>13625
You've learned a language when you've done some programming with it and are familiar with the basics of the implicit environment and other semantics, the most used standardized procedures and data types, and can read well-written code in the language not written by you and understand it.

Some languages are so large that learning them is effectively impossible. Many "popular" languages are just clones of the others with minor syntax changes or other strange decisions.

  No.13628

>>13624
it varies, but for the most part, when you are able to make a medium sized real world application, you can say you know the language. Most descendants of Algol are pretty much the same, for they use slight variations in the way they encode their instructions.
But the real meat is learning how to properly use its' internal resources, such as its' datastructures and semantic features, as well as the external resources, namely, libraries and surrounding tools. getting to know the packaging system is another part of it.

  No.13653

>>13550
Try Common Lisp. It has a fairly minimal syntax. Land of Lisp would be a good starting point for you because it uses a text game engine as its example program which is built up throughout the book, which you could easily extend to be an interactive fiction parser with a little work and a bit of thought.

On top of that, where you have the REPL you can quickly find out if what you're about to do is correct (can I find an element of a string with nth?) before you put it into your program.

  No.13672

File: 1453588374389.png (34.93 KB, 200x154, algorithm efficiency.jpg)

As anyone mentioned anything about algorithms I'll do it. Just to learn the syntax of a language isn't enough to program, you need to know how to solve common problems, hence the need to read a good algorithms and data structure book, concepts like searching, sorting, efficiency, correctness, binary trees, stack, queues, etc, are fundamental to any programmer, I'm not advocating a copy & paste from a cookbook, but learning how common problems are solved so you can grasp the concept and solve your own problems when needed.

  No.13694

>>13672
this reminds me of http://visualgo.net/

  No.13717

Like the OP, I want to become a better programmer. I've recently been doing a lot of research into PL theory, type systems and the such. I built a language interpreter that is pretty powerful and I have ideas for a better language but it really feels like a waste of time (Rust, C++ or Haskell all do it better). Maybe I'm just lacking motivation.
Anyways, I was wondering what fields of CS I should look into after programming languages because I really think that's starting to be a dead end for me, but most other projects (vidya games, web dev.) just seem like writing a lot of basic and repetitive code, which is why PL interested me so much: lots of cool algorithms and concepts, plus a lot of leeway in design. Now I'm kind of just ranting.
tl;dr. what kind of advanced projects should I pursue to become a better programmer?

>>13476
I agree that they are all algol-like, but is there something inherently wrong with ALGOL?
How do you feel about ML-like based syntax?
Lisp has trouble supporting a type system because of its dynamic syntax.

  No.13719

>>13717
Anything related to Racket is great for learning about programming languages. Matt Might has some excellent articles on programming languages. http://matt.might.net/

  No.15053

>>13717
Maybe you should get a master degree?

  No.15054

>>13719
Oh shit I actually sat down and talked with this guy once. He's pretty cool.

  No.15055

>>13435
no love for forth? (currently learning)

  No.15059

>>15055
Forth is an excellent language.

It's better than C for learning lower level details, mostly because ANSI Forth avoids having poorly designed procedures and because other Forths are even simpler.

I assume you're learning ANSI Forth, which isn't a bad decision.

  No.15060

>>15059

I almost never hear about forth ever, is there some reason why people use C more than it for systems stuff? Some flaw in it that caused it to not catch on?

  No.15061

>>15060
>I almost never hear about forth ever, is there some reason why people use C more than it for systems stuff?
It's entirely cultural. UNIX was implemented with C and the decades have successfully taught many that C is the only way.
Unlike C, Forth will behave the same whether it is running as a normal program, the operating system, or as implemented in hardware.

>Some flaw in it that caused it to not catch on?

I wouldn't say that. Forth is a very simple language. It has a small implicit environment and some dialects have only ~20 words to start with. It is basically a virtual stack machine to be used as a common denominator on all hardware it is ported to, which includes environments too constrained for C.
Depending on the dialect, there is almost no syntax. It is very easy to create your own syntax, however.

You don't hear much about Forth for the same reasons you don't hear much about Lisp, APL, or many other beautiful languages: They've been replaced with inferior systems because people only like infix notation, they don't like languages they perceive as slow, or other such drivel. You know of the kinds of people I'm mentioning, those people who are unwilling to learn anything new once they pick something and latch onto it.

Read this, from Forth's creator, Chuck Moore, concerning C and Forth:
http://colorforth.com/1percent.html

  No.15062

I used to enjoy programming but lately I never want to do it. This has been a problem for longer than I think could be considered being burnt out. Has anyone else had this? I was thinking maybe trying another language might reinvigorate me but I'd still be forcing myself instead of actually wanting to.

  No.15065

>>15062
this is the entire reason why I've picked up a few languages:

JS -> C -> Unix shell -> Scheme -> Pascal -> Haskell -> ASM -> Fortran -> Forth

where the main ones are: Haskell, Forth, Scheme and C

Learn a language that shares almost nothing with the ones you already know. Also check out the challenge thread... there seems to be no solutions past task 2 so far so you could have a go at that. I'll post taks 4 on monday.

  No.15447

Less directly relevant, but how do you all get
better at problem solving?

I spent a long ass time trying to solve the first 3 Project euler problems and i would like to get better.

  No.15450

>>15447

This.
I find that i still have trouble with this, even tho I am at university for this shit.

  No.15454

File: 1459980382130.png (425.83 KB, 163x200, LL.jpg)

SICP objectively changed my life. Best book ever.

  No.15629

I feel like one of the things hindering me from being a better programmer is that programming involves the computer. The internet just keeps distracting me. When I unplug and just start working away at stuff I end up just having to stop and look something up on the internet only to get distracted again.

I feel like I get the most programming work/studying done when I have pen and paper and just sit down without a computer on and think through problems that way.

  No.15632

>>15447
Learn math, having to prove things will change how you approach problems.

Read Polya's "How To Solve It".

If you're having problems with the first three project Euler problems though then you need to learn to program first since solving those doesn't involve real problem solving at all but just extremely basic programming since a brute-force approach will work for all three.

  No.15886

>>13672

Im a beginner and im starting to learn about programming by reading the sicp book, i don't know if i could measure my knowledge, but if i have to, i'd say that im getting exponentially better every time i read it and i understand well and with no problems the examples of the book, i've also solved all exercises but those that require to change recursive processes to iterative processes and vice versa. Do you have any advice for me? i've been thinking all day how to to solve a problem like that from the book and i really want to solve it by my own and not to look for it on the internet, there is an example on the book about how to change the algorithm to calculate the fibonacci sequence from a recursive process to an interative one, but i just don't know how to use that example to solve the other problem that i have to solve.

  No.15888

>>15886
Have you understood the difference between recursive and iterative functions?
If not, try evaluating both fibonacci functions by hand and try to spot the difference.
Then think about how this would apply to the functions in the exercises.

  No.15889

>>15888

Yes, i do understand, a recursive process grows proportionally in space and time depending of the value of a variable, an iterative process only grows in time proportionally to the value of a variable while in space it remains constant. I do understand both recursive and iterative algorithms of the fibonacci sequence, i guess that the problem is that in the book the author just shows you the transformation from the recursive process to an interative one and explains it to you, but never giving you hints or a method for the reader to solve the problem by his/her own. Maybe i just have to take a break and think about the problem later while my mind is fresh and rested.

  No.15897

>>15886
Well..
I guess you have to think not only what is different between iterative and recursive processes, but how they are similar as well.
Remember the mantra: Recursion is a way to solve problems breaking them into smaller problems of the same nature.
In recursion you do the same thing, just in a stateful way. In fibonacci (for example) you take a big number and break it into smaller numbers until you get to some base cases, then you fold the procedures in queue starting from your base result.
In iteration you start with the base case and start updating a state variable much in the same order in which the recursive procedures pop the stack.
Hope I didn't miss the point of your question :P

  No.15903

>>15897
Man im so happy right now, i just solved the problems!

The first one was "A function f is defined by the rule that f(n) = n if n<3 and f(n) = f(n - 1) + 2f(n - 2) + 3f(n -
3) if n> 3. Write a procedure that computes f by means of a recursive process. Write a procedure that
computes f by means of an iterative process."

And the second one was to write a procedure to compute the elements of a pascal triangle, but i was not able to write it so it shows all the elemets of the "base" or "row", it only shows the element that the user specifies.

Is there a way to write a procedure in a way that it returns diferent values of a variable? per example,

F(n)=2x

"Write a procedure that returns the value of F(n) when x is 1,2 and 3"

And the output would be 2 4 6.

  No.15904

>>15903
> A function f is defined by the rule that f(n) = n if n<3 and f(n) = f(n - 1) + 2f(n - 2) + 3f(n - 3) if n> 3. Write a procedure that computes f by means of a recursive process. Write a procedure that computes f by means of an iterative process
I'm doing this exact same exercise right now

  No.15927

File: 1461637808638.png (35.31 KB, 200x122, tree process.png)

>>13672

Got any tips to determine the order of growth of a proccess? im doing an exercise that says

"Draw the tree illustrating the process generated by the count-change procedure in making change for 11 cents. What are the orders of growth of the space and number of
steps used by this process as the amount to be changed increases?"

code for count-change is
(define (count-change amount)
(cc amount 5))

(define (cc amount kinds-of-coins)
(cond ((= amount 0) 1)
((or (< amount 0) (= kinds-of-coins 0)) 0)
(else (+ (cc amount (- kinds-of-coins 1))

(cc (- amount(first-denomination kinds-of-coins)) kinds-of-coins)))))

(define (first-denomination kinds-of-coins)
(cond ((= kinds-of-coins 1) 1)
((= kinds-of-coins 2) 5)
((= kinds-of-coins 3) 10)
((= kinds-of-coins 4) 25)
((= kinds-of-coins 5) 50)))

and the tree process is the pic (which is not completed because don't have more space and i got bored)

I deduced that the order of growth in time is O(N) and in space is O(N) too because the process is recursive and the space doesn't grow exponentially, is this correct?

  No.15937

File: 1461703486611.png (39.18 KB, 149x98, FML.png)

sorry for shitposting but
<---- seriously?

  No.15938

>>15937
What's wrong?

  No.15942

>>15938
he is typing with his index fingers.

  No.15959

>>15942
Its called "search and peck" typing and its a decades old Lisper tradition to type like that.

  No.16027

>>15959
he's no lisper, his pinkies still fold.

  No.16038

>>15629
Have you watched the dijkstra documentary?
its called discipline in though irc

  No.16039

>>15886
So, for me, what made me understand those exercises (and i am still going through the book) is:
recursion, you develop the whole tree, so you move from the end result backwards to the base case, then you move forwards to get your result.
iteration. you move from the basecase onwards. so you just need to set a counter to stop at the desired time.

there are lots of hints of how to do it in the first chapter, somewhere around orders or growth and exponentiation, i dont recall exactly where

  No.16043

>>16039
Yeah man, now i understand perfectly how to transform a recursive algorithm to a iterative one, i just had to study harder the book.

How long you took to read the book? i've been studying it for 12 days and im right now for page 60-61, i expect to read the book (solving all the exercises) in 6 months or more but i don't want th rush it, sometime i can understand and solve the exercises of 5 whole pages, and sometimes i take a day to solve a one or two exercises, is that normal?

  No.16045

>>16043
Not him but that's absolutely normal, take it easy and don't give up.

  No.16066

>>16043
Hey, its me. i havent finished the book, i am still in chapter one started around a month and a half ago.
I am finishing my masters degree in statistics, and sicp is not my main focus these days, so i go slow.

I know exactly what you say. i try to get one reading session per week, sometimes i achieve a lot of things. sometimes i just get stuck.
I remember when the difference between recursion and iteration clicked. it took me 2 days or so to figure the simple iterative algorithm for fibonacci, fidgeting with the idea on all my bike rides and dead time. then maybe another hour on top of that to implement, cause i suck at scheme.

main point, dont give up. you will eventually get there

  No.16069

I feel like any other language, the key component is immersion. The more you read and learn the more familiar it becomes. As mathematic as programming may be, a is not always equal to a, in the sense that there is not just a single path to achieve the same goal. As you become more familiar you are able to apply what you have learned to formulate your own "sentences" rather than just reciting directly what you have been told.

  No.17134

>>16069
Yes.

The more time spent in a single language also improves the skill seemingly exponentially. It's nice to be able to help others with their programming problems.

  No.17182

File: 1466483387072.png (460.5 KB, 200x152, installgentoo.png)

You won't learn how to program by reading books. You learn how to program by programming. Lots. Every single day. Bite off more than you can chew. Take on challenges that you know you will fail and complete the shit out of them. Spend three days bashing your head against your desk trying to find a pesky race condition, and do it again next week.

Tutorials and online courses are a good start, but they will only teach you fundamentals of a given language. You want to get to a point where you no longer even think about the language, and instead are able to put 100% of your focus on the abstract problem at hand.

Only read if you plan on using that knowledge in practice. Otherwise you will forget most of it within a few months. Reading a textbook from front to back won't teach you how to program any more than reading a book about poker strategies will teach you how to win mad cash at the table.

Most important of all, don't force yourself to do something you don't enjoy. The path to wizardry is not an easy or pleasant one, and there are no shortcuts. But if you're the sort of person who gets an insane high out of solving complex problems and building awesome things, it's worth every bit of pain.

  No.17187

>>17182
100% agree, to steal a Bruce lee quote
"Make at least one definite move daily toward your goal."
Basically every day you should be either learning something new or going back to something you did before and doing it better with what you have learned.

  No.17190

Well, first thing you'd have to define what a "great"
programmer actually is.

Is it a "smart" (appears to be smart but actually doesn't
know anything) programmer? If so:

- Whine about everything, everything sucks.

- Never actually say how to fix anything, just say
"oh god, that is a horrible idea".

- Be as antintelectual as you can. Otherwise you'll
be discovered as a fraud when you say something
obviously wrong.

Obviously, don't do that, but it is surprising to see
the amount of people you'll find like that.

Or, does a "smart" programmer write "clever" code, or
are they the ones who write clear, easy to read,
concise code?

  No.17191

>>17190

People here say that you won't learn anything by reading
books. I disagree. There are a lot of people reinventing
the wheel over and over just because they are ignorant of
previous work.

That doesn't mean that any book will do, though, there is
a lot of crap published.

For me, what works is to have a healthy balance between
programming and reading (papers, mostly). Find a good paper,
and try to implement it, see how it goes. When you find
something you don't understand, read about that.

You don't have to become an expert in that particular subject,
just enough to move forward.

  No.17192

>>17191
That being said, it really depends on your level.

Are you a beginner? Then you should spend most of
your time writing code, becoming used to it, and
reasoning about it.

But once you reach a certain level, you won't learn
more just by writing code, you'll have to do other
stuff, like I said above, reading books, papers etc

  No.17202

>>13416
We seem to be fairly similar lainon, aside from the "broken languages" aspect. I think python and ruby can sometimes be the best tool for the job, and in those cases why not use them.

I completely agree with the thinking about computing part though, I have a big interest in gamedev (particularly rogue likes) and I love lying in bed before sleep, thinking about features I could add and how to implement them, going over the pseudocode in my head.

In a way, programming in pseudocode in my head is more fun than actually programming...

  No.17204

>>17190
>Whine about everything, everything sucks.
Oh god THIS RIGHT HERE

I recently learned not to listen to these people. Now they're just funny tbqh. They do spend a lot of time on the internet complaining that the currently used software is not what they'd want it to be in their perfect utopic world. Instead of getting to work on something.
Anyway, I realized that maybe we're just prone to complaining. While our ancestors had to program their operating systems in assembly in machines with kbs of RAM, we have a huge array of systems and software and languages and processing power.
And I think all these options and all this stuff has spoiled us. I think it's the tool trap. Thinking that a certain OS/language/editor will solve all our problems magically. We can not longer stand to have limitations, though limitation are what stimulate creativity. And too often we fail to acknowledge the work of others.
Can't please everybody

  No.17206

>>13476
>C and C++ are famous for how error-prone they are. It's practically impossible to write a program within hidden errors in them. Not even C experts can do this.

Did you ever question why this is the case though, and why people continue to use these languages? Why every major operating system, web server, and crypto library is written in C? Do you really think that the people who created all these massive, complex systems are just lazy idiots who just didn't feel like learning a "better" language?

The fact is that there are no other languages that offer the same degree of speed and low-level control on top of relatively simple to learn, high level syntax. Being error-prone is the cost of this power and speed. Calling the language "broken" and suggesting that people shouldn't learn it because it's "error-prone" displays a complete lack of understanding of how computer systems work. Even safe languages are written on top of and reliant on unsafe languages. At some point down the abstraction staircase you are forced to take the magic safeguards away.

  No.17209

>>17206
>Did you ever question why this is the case though, and why people continue to use these languages? Why every major operating system, web server, and crypto library is written in C? Do you really think that the people who created all these massive, complex systems are just lazy idiots who just didn't feel like learning a "better" language?
I think many of them were probably sucked into a trend and didn't give it much thought.
Unfortunately, most of the world is UNIX and UNIX loves to go on and on about C.

>The fact is that there are no other languages that offer the same degree of speed and low-level control on top of relatively simple to learn, high level syntax.

Forth is, in all ways, simpler and more powerful than C. It even has metaprogramming and, because of this, object orientation can be added if you want without creating an abomination like C++.
While I'm at it, it's also easier to embed machine code procedures into an otherwise normal procedure.

>Being error-prone is the cost of this power and speed. Calling the language "broken" and suggesting that people shouldn't learn it because it's "error-prone" displays a complete lack of understanding of how computer systems work.

Forth has that power and speed and, yet, remains not error-prone. This is mainly because, unlike C, Forth isn't based around cases of undefined behavior everywhere and has sane defaults. C has a confusing standard library, undefined behavior everywhere, complicated syntax, and ills such as array decay and null-terminated arrays. Those are much of what makes it so difficult to use correctly. It's almost as if C were purposefully designed to be frustratingly hard to write correctly.

>Even safe languages are written on top of and reliant on unsafe languages. At some point down the abstraction staircase you are forced to take the magic safeguards away.

That's not inherently true. I don't imagine you'll get a kick out of hearing about alternate computer architectures that did, in fact, have those ``magical'' safeguards on constantly, but they existed and they generally worked better than computers do today.
You can be fast and safe. You can't be as fast and safe as you can be fast and unsafe on an IBM PC or phone, but I like to think the entire world isn't an IBM PC or some silly phone.

  No.17211

>>17209
Not the same guy but
what's your point in complaining?
You go on an on about unix and von Neumann machines, yet you're using both. It's kind of tiresome to hear some smug dude go on and on about his favorite language and why it should rule the world.
Instead of whining you could be working towards changing what you don't like instead of rambling about it on internet forums.
This is exactly what's been bothering me lately and which annoys me of some users on lainchan. You're using something you seem to hate, and you seem to be a masochist. I can only imagine you using your rregister machine and being frustrated at each keystroke.
You have some points, yeah, and that's perhaps the worst part, because you're just spoiling the fun for others, who see that you have a point and think "maybe he's right" and then everybody is wishing we had lisp machines and hating unix because of just how salty you are about the whole thing.
I wish I could go back to my early days when all I knew was C and some assembly, when I still found computing fun. Now I cannot help to think how everything is somehow wrong, even without first hand experience of why it's wrong, or what it's lacking. Mostly because all these people are so loud about why 'notmylanguage' sucks. I only recently start to find out that, effectively, there is a reason there are so many languages and dialects of languages, and that there is no single best language.
Anyway. There are programmable microprocessors. Operating systems have been written in Haskell, Rust, Common Lisp, and soon I suspect javascript (if it hasn't been done already).
So go on and make THE computing experience, prove us all wrong. I'm waiting, Wozniak

  No.17212

>>17211
>what's your point in complaining?
I'm not. I was simply asked to explain some advice I'd given earlier.

>You go on an on about unix and von Neumann machines, yet you're using both. It's kind of tiresome to hear some smug dude go on and on about his favorite language and why it should rule the world.

I'm not attempting to come off as smug or as a language elitist.

>Instead of whining you could be working towards changing what you don't like instead of rambling about it on internet forums.

I'm doing both.

>This is exactly what's been bothering me lately and which annoys me of some users on lainchan. You're using something you seem to hate, and you seem to be a masochist. I can only imagine you using your rregister machine and being frustrated at each keystroke.

I'm frustrated with the design of the normal keyboard, which is why I'm working on developing a custom keyboard for myself. I'll probably post about my setup on /diy/ at some point.

>You have some points, yeah, and that's perhaps the worst part, because you're just spoiling the fun for others, who see that you have a point and think "maybe he's right" and then everybody is wishing we had lisp machines and hating unix because of just how salty you are about the whole thing.

Part of the reason I hate UNIX is because I use it so much. That's been the joke for decades.
Anyways, I do have a point. I don't believe we should be complacent. I'd rather complain that think it can't be any better than it is.

>I wish I could go back to my early days when all I knew was C and some assembly, when I still found computing fun. Now I cannot help to think how everything is somehow wrong, even without first hand experience of why it's wrong, or what it's lacking. Mostly because all these people are so loud about why 'notmylanguage' sucks. I only recently start to find out that, effectively, there is a reason there are so many languages and dialects of languages, and that there is no single best language.

I helped make computing fun for myself again by collecting and programming calculators. Many of them are very competent and I want to gradually replace common tasks with them.
A hard revelation for me was realizing that making computing fun also means stepping away from the main computer at times. It's nice to only have a calculator and a music player and doing things with them. It's nice to take a break from dealing with everything at once.

>Anyway. There are programmable microprocessors. Operating systems have been written in Haskell, Rust, Common Lisp, and soon I suspect javascript (if it hasn't been done already).

>So go on and make THE computing experience, prove us all wrong. I'm waiting, Wozniak
You'll have to wait a bit, but I believe I'll have that in the future.

I'm not trying to frustrate you or anyone else. I'm just trying to help, the same as you.

  No.17769

This topic deserves much more discussion still.

Simplicity is key. I just avoiding needing to learn SQL by choosing to use the filesystem for storing persistent data. I won't go into too much detail, but so much of good and fun programming involves simplifying a problem until it can't get simpler.

A good solution doesn't fail, but also can't cause problems even if it does fail. From what I've read so far, SQL implementations don't even have a good way to restrict connections to subsets of the language. That's simply dangerous.

  No.17794

So, I have a question about improving at programming. What do you guys think about learning two (or more) languages at once?

I found a question like this on stackexchange while looking for some answers to this question but would like to know your opinion on this.

I am currently learning C and I like it but sometimes i feel like just taking a break from it and learn something else. Seeing how I’m still far from calling myself a good programmer I want a language with a lot of information on it and that has a big user base so it’s easy to get help if I get stuck at something. I've tried python once, thought it looked ugly and felt boring, so that's a no. Looked around a little bit more, tried ruby, liked it better but still a no. Now I'm trying out perl and I kinda like it. But maybe it should be a language that's a lot different than C and makes me think differently? What do you guys think? Anyone here have experience with learning multiple languages at once and would you say it’s a good/bad thing?

  No.17795

>>17794
It's bad because you won't get very good at using any one language. It's good because you're learning the basics of other languages. Finishing projects is the best thing you can do.

If you want to use two languages at the same time, why not use two languages that interact? Languages like Guile and Lua are made for working well with C. I'm not sure about Lua, but with Guile you can embed Guile into your C programs or call C functions from Guile.

  No.17799

>>17794
>So, I have a question about improving at programming. What do you guys think about learning two (or more) languages at once?
I've done this. It can work, but this varies wildly.

>I am currently learning C and I like it but sometimes i feel like just taking a break from it and learn something else. Seeing how I’m still far from calling myself a good programmer I want a language with a lot of information on it and that has a big user base so it’s easy to get help if I get stuck at something. I've tried python once, thought it looked ugly and felt boring, so that's a no. Looked around a little bit more, tried ruby, liked it better but still a no. Now I'm trying out perl and I kinda like it. But maybe it should be a language that's a lot different than C and makes me think differently? What do you guys think? Anyone here have experience with learning multiple languages at once and would you say it’s a good/bad thing?

Try using Common Lisp. It has some of the better programming literature written for it and is very extensively documented and standardized.

Let me guess: You find it hard to remember all of the little problems and misspelled names in C, right? You should try a language without much of that garbage.

  No.17800

Just my opinion but https://www.coursera.org/learn/progfun1 really helped me get into functional programming and improve myself generally. This might be heresy but I found this a lot easier to understand than SICP (which I read at the same time) although SICP does go into more depth.

  No.17803

>>17769
What the fuck are you even rambling about

  No.17804

>>17803
You could stand to be less rude, but I'll answer anyway.

I was able to avoid using SQL for persistent data storage by deciding to use the filesystem instead. This is significantly simpler and also more efficient for my usage.

It's very fun to continue to simplify a program until it reaches an acceptable level of simplicity and this is something that good programmers should do.

A good solution doesn't fail, but also can't cause problems even if it does fail. With SQL, injection attacks are a constant worry. There doesn't seem to be a good way to restrict a database connection to a subset of the language. If an SQL injection does somehow happen, it shouldn't be able to cause problems, which can be achieved by restricting to a subset.

This is easy and reasonable when using a filesystem. I'd wager most SQL database systems could be replaced with something more specific, more simple, and more safe.

I'm not saying the filesystem is great. I really don't think it is. It's simply good enough.

  No.17805

>>17804
How do you handle your program crashing in the middle of a database "transaction"? Do you handle recovering from a partially-written update; or do you just hope that never happens?

  No.17806

>>13410
Learn by teaching!

Even if you are a beginner, find someone who is interested in the topic and less experienced than you to teach. This can be a fellow programmer, a "power user," or just someone who is curious about computers. Choose a topic, set some time aside, remove all distractions, and engage with them until they have some real understanding.

Writing code that's clean enough that it can be used as teaching material is challenging and forces you to use best practices. Creating exercises forces you to understand problems thoroughly and closely examine the concepts entailed. Explaining the approaches to the problem forces you to deconstruct and critique those methods. Finally, helping someone program develops your collaborative skills.

Some additional tips:
>Have two or three exercises ready: easy, medium, and hard.
>Prepare clean, concise reference implementations for each exercise.
>Choose problems that can be machine-verified if possible (another reason for the previous point).
>Try to have lessons build on previous ones as much as possible. Have your pupil reuse code.
>Be prepared to explain a concept in more than one way. Don't rely on a single analogy.
>Know the history of the topic at hand.
>Don't just explain the "how" of something: contextualize with the "why."
>Be encouraging. Remember that you were in their shoes once.

Happy hacking, lainons!

  No.17807

>>17805
>How do you handle your program crashing in the middle of a database "transaction"? Do you handle recovering from a partially-written update; or do you just hope that never happens?
I can establish a very special type of error handler in order to recover gracefully in most cases.

I can't stop someone from purposefully killing the program with, say, a kill signal, which would lead to an inconsistent write if it happened at the right time, but that's hardly my problem. I can't program around something like that.

  No.17808

>>17807
>I can't program around something like that.

Yes, you can. Fault tolerance is one of the things an actual database program gives you.

  No.17810

>>17808
I'm well aware that on, say, a UNIX system I can, say, write a dummy file that lets me know there's a write happening and delete it when I'm done, along with many other things. It's ridiculous, but I can do it.

Audits of several database programs have shown that even these don't necessarily properly behave in all of these corner cases.

You may be interested to know that audits of several UNIX filesystems show them not behaving properly. Flushing data is very important, as an example, but some filesystems don't implement flushes properly, along with many other issues. I can't program around that.

So, I can choose a simple system I have no control over that I know can fail sometimes or a very complex system I have no control over that can just as easily do the same. I went with the former.

  No.17811

>>17810
Ah, UNIX bashing.

You can't have perfect fault tolerance. Even in a "perfect" OS with "perfect" filesystems, you can't protect against subtle hardware failure. But you can make data corruption a lot less likely than 100%, which is the case if you don't take any failure conditions into account when designing your storage subsystem. What do you do if the disk becomes full during an update? Do you just assume that that never happens, too?

  No.17812

>>17811
>You can't have perfect fault tolerance.
That's debatable.

>Even in a "perfect" OS with "perfect" filesystems, you can't protect against subtle hardware failure. But you can make data corruption a lot less likely than 100%, which is the case if you don't take any failure conditions into account when designing your storage subsystem.

I can check writes, handle read and write errors, and everything else, but modern operating systems don't generally give me a good way to protect myself from power failures or a user deliberately corrupting files.

>What do you do if the disk becomes full during an update? Do you just assume that that never happens, too?

A disk full error is easy to check for. The environment does it for me.

Here's a fun type of error: I can open a file, have that succeed, and then write to it. The operating system doesn't lock the file or prevent it from being deleted during this. The file descriptor is still valid until it's closed. There's not much I can do, except double check afterwards.

The environment handles everything it can for me, but I can't program around this. If the system, say, loses power, I'll also lose the environment, which contains the data to begin with. There's no way I can recover from that.

You may have a point with partial writes, but it's generally turtles all the way down with the way those errors can cascade.

  No.17917

Why does everyone on lainchan have such a disdain for any programming language that is not functional?

  No.17918

>>17917
Duh, where else will you find zygopolyretroisomorphic swarm-unmatching pattern-recursive functions? Programming without such function is clearly pointless. Just better read a book about calculus.

  No.17922

>>17917
Because it's one of the best ways to structure programs. Also elitism.

  No.17925

>>17917
They don't. Lisp isn't functional.

  No.17926

>>17917
My Mom had a small lisp, so my Oedipus complex made me learn Scheme and it was all downhill from there.

  No.17929

>>17917
Tryhards, usually.

Also because you can learn and talk about OOP literally EVERYWHERE ELSE, there's very few places to talk about functional languages(even if it's just messing around with them), and people want to keep it that way. It's a way to keep the community "pure".

  No.17952

>>17929
no love for straight up procedural anymore... :(

  No.18003

>>17212
Hey man. I don't know if you'll read this even.
But I followed your advice and got myself a calculator. It was a lucky blow too.
An HP 48GX, pretty good shit, no regrets, you were right, etc.
Anyway I'm sorry for getting all head over heels about your complaints on unix n shit. I just don't get the elitism and saltiness of some here.
Anyway, I guess we all like things from a different angle. I like bugs, you don't.
Keep having fun n all

  No.18006

>>18003
>But I followed your advice and got myself a calculator. It was a lucky blow too.
>An HP 48GX, pretty good shit, no regrets, you were right, etc.
That's great. I very much enjoy my HPs. Once you finish reading all of the excellent documentation, they're very pleasant to use and use well.
I have a 48G and 50g which are very pleasant. My other calculators aren't nearly as nice.
>Anyway I'm sorry for getting all head over heels about your complaints on unix n shit. I just don't get the elitism and saltiness of some here.
It's alright. Just try to stay positive, like me.
This can be a very passionate topic, but try to consider that people sharing their opinion aren't being elitist or ``salty'' unless the their language gives that away rather blatantly.
>Anyway, I guess we all like things from a different angle. I like bugs, you don't.
That HP you have is virtually free from them. I believe I recall there being a slight memory ``bug'' in the 48SX that affected a command or two, but it was documented in the manual and probably corrected in the later 48 series.
I believe it's possible to create software without bugs. After all, we couldn't build anything if none of it worked perfectly.
>Keep having fun n all
I will and I hope you and everyone else here does too.

I have a question. Why do you like bugs? Do you find it fun to fix them?

I can understand that, but I still don't think bugs are necessarily good. The programming world would be boring without them, though.

An example of what I find very fun and interesting is building an extensible system free of bugs that can be built up from.

  No.18024

>>17926
Coffee came out my fucking nose god damn it

  No.18027

File: 1471475903766.png (22.21 KB, 144x200, 6d794ab98ec20b55b6ba6b4b117200cf.jpg)

Since we're talking about books and being a better programmer --

Do any of you have any free courses with exercises that involve the languages: Java, Javascript, Python, and C#?

I have books, but I feel the combination of trying to do a project while engaging in a course would be a better method for me to get to be a better programmer. The books have a tremendous amount of information but very ambiguous direction on how to implement it.

  No.18028

>>18027
> free courses ... Java, Javascript, Python, and C#
These languages are some of the most popular languages out there. There are literally hundreds and hundreds of courses about them. I'd recommend using a search engine.

I'd recommend not using anything like a "bootcamp" or "CodeAcademy", because they typically teach hacky-styles, and people typically only come out knowing how to made crude implimentations of whatever software/website they build. (i.e. you will not become better at programming in this method.)

Generally speaking, the books are going to do a lot better for you becoming a better programmer than most, if any, of those classes will.

I'm not trying to sound like an elitist or anything like that, but you're better off trying to learn theory and algorithms than a language, in hopes of becoming a better programmer.

If you are set in your ways to taking a course, look into Zed's The Hard Way series. He's rough around the edges, but you will come out of his courses with a decent toolbox to work with.

  No.18030

>>18006
>I have a question. Why do you like bugs? Do you find it fun to fix them?
I was just being cute when I said that. Nobody likes bugs.
But I kinda do, I mean, I started out using C and gdb, and I came to like all the process of having no idea why there was a bug at all (what? is this thing broken or what?) to progressively finding the bug and fixing it. That's what took most of my time in programmming always. Writing functionality is straighforward. I like the puzzle of finding that subtle error that was causing a program to behave unexpectedly.

Honestly I never got the hang of lisp, everybody here seems to glorify it. And Lain knows I tried. I do like it, yeah. I think it's a pretty interesting (awesome) language. But I've never ever got myself to write anything worthwhile in it, and even that spooky stuff described in Let Over Lambda wasn't enough to inspire me in that direction. Maybe I'm not creative enough. I am more square. I like looking at raw bits and being at the backstage of things. Maybe that's why I like bugs, at least, that's where I am familiar with bugs hiding.

  No.18036

>>18028
>look into Zed's The Hard Way series
I disagree with your suggestion of Zed Shaw's book to >>18027
. I would recommend Automate the Boring Stuff with Python over it because Sweigart's book puts more emphasis on using the knowledge within to interact with the real world. Shaw emphasizes the whole "go look it up yourself" deal which is in all honesty effective and a good habit to develop, but then he drops the ball by making just about every other exercise a litany of print statements. His explanation of how classes and objects are written and used in Python is also subpar.

Honestly, I would recommend Automate the Boring Stuff for friendly basics and then either John Zelle's Python Programming or John Guttag's Introduction to Computation and Programming using Python for more specific understanding.

t. used Learn Python the Hard Way to learn it as my first language initially and was let down in how little I was able to do with the language after finishing the book

  No.18047

>>18027
For exercises you should check https://exercism.io
For learning Javascript I highly recomend the "You Don't Know JS" book series, for Python the automating borin stuff with python book from AI, also, if you have 15 dollars to spare you should check Humble Bundle for books

  No.18066

>>18036
I just want to jump in and completely agree with your assessment of zed. I tried his "learn C the hard way" and found it quite useless. I already have a strong "look it up your self" mind set, so the whole thing was:

1-go to the bit I want to learn about
2-look at massive code dump
3-get told "look it up brah"
4-get infuriated because the only fucking reason I am there is to look it up

  No.18067

>>18028
>>18036
>>18066

Thanks for the material guys. Google can't really tell me whether it's searches are good and work, or just bumped because most visited.

  No.18071

>>18067
If you do use Automate the Boring Stuff, note that Sweigart is using Python 3. I think Zelle's most recent edition of his book uses Python 3, but Guttag uses 2 and makes reference to when something is different in regards to 3. The 2-3 tug-of-war is one of the major non-technical problems with Python, but I wouldn't worry about it yet since you haven't even really started yet.

  No.19168

>>13416
OP, don't follow this advice. Literally. Those wannabe elitists who act like rebel without cause can really screw up your first approach to programming (it happened to me too: I started with PROLOG as a first language.)
Anyway.
C is the language used for the linux kernel. Nowadays even most of the firmwares are written in C instead of assembly. c++ is constantly in the top 5 of most used languages, and that doesn't surprise me given its speed and how it hands low-level control to the programmer. python has a soykaf tons of awesome libraries, and if you aim to work on AI stuff it's indeed one of the best languages to start with. ruby is not excellent, but it's quite popular among penetration tester so it's worth to be studied if you're interested in cybersecurity.

Unless you want to become a malware analyst or you really want to know in details how computer architectures work, you can totally avoid assembly. common lisp is a great language, but you won't find many active projects around to work on and this is a huge disadvantage for a beginner, forth and APL are dead as fuarrrk and it's not like many miss them.

so yeah, if you wanna alienate yourself from the FOSS community, cut your chances to get a programmer job almost to 0, not be able to understand most of the academia's research papers, follow >>13416 advices. Otherwise, OP, figure out which field you wanna work on, and choose your language accordingly.

  No.19177

>>19168
>OP, don't follow this advice. Literally. Those wannabe elitists who act like rebel without cause can really screw up your first approach to programming (it happened to me too: I started with PROLOG as a first language.)
Well, that's rather insulting to me, without substance. I don't like common languages, for reasons listed in >>13476, so I'm an idiotic elitist to you.
I don't see what's wrong with learning Prolog as a first language. You simply dismiss it with no reasoning.

>C is the language used for the linux kernel.

It's very hard to write correct software in C, as evidenced by the number of Linux security vulnerabilities. You would've made a better point in mentioning OpenBSD, which goes to great lengths to avoid security flaws in its programs.
It's worthwhile to point out that the flaws found in new C programs are almost certainly in the same class of issues the language has had for decades.
Requiring manual memory management is fine, but making it unnecessarily difficult with a compiler that will undercut the programmer at every opportunity isn't. This still affects professional programmers with decades of experience in the language.

>Nowadays even most of the firmwares are written in C instead of assembly.

This is too vague to be true. Firmware is written in assembler languages, Forths, Ada, C, custom languages, and sometimes even languages like Java.
A great deal of firmware is proprietary and can't be inspected at all for implementation language.

>c++ is constantly in the top 5 of most used languages, and that doesn't surprise me given its speed and how it hands low-level control to the programmer.

It's been called the COBOL of the 90s.
C++ may be popular, but read a resource such as the FQA (Frequently Questioned Answers), for an idea of how well it all really works: http://yosefk.com/c++fqa/
C++ is certainly famous for the ire it receives:
Saw comment // NEW BOOST CODE, and had a moment of panic before realizing it was vehicle boost, not C++ boost. --John Carmack
C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. --Linus Torvalds
Compare C++ to Forth, which has (more advanced) metaprogramming, lower-level control, smaller size, faster compiles, faster execution, and manages to be far, far simpler.

>python has a soykaf tons of awesome libraries, and if you aim to work on AI stuff it's indeed one of the best languages to start with. ruby is not excellent, but it's quite popular among penetration tester so it's worth to be studied if you're interested in cybersecurity.

Python still has a horrible version schism and I sincerely doubt Python or Ruby will be used often in a decade, but they'll certainly leave a glut of indecipherable programs, just like Perl.
Similarly to Perl, the interesting features they have will probably be stripped and made into libraries for other languages, like PCRE, which Common Lisp has an optimized library for, CL-PPCRE.

>Unless you want to become a malware analyst or you really want to know in details how computer architectures work, you can totally avoid assembly.

Assembler languages are fun. Can't we agree that being able to know what the computer is actually doing is a valuable skill that will improve programming skills in general?

>common lisp is a great language, but you won't find many active projects around to work on and this is a huge disadvantage for a beginner, forth and APL are dead as fuarrrk and it's not like many miss them.

It's strange to see this learning culture that demands projects that beginners can contribute to or work on. Doesn't it seem that a project that many beginners contribute to will be lower quality than a project only worked on by experienced programmers?
Isn't it enough to automate something simple, make a little game, or read an existing, good project?
Anyways, Forth is too simple to die, considering many Forth projects will write a custom implementation for the problem.
APL has Free Software and proprietary implementations in heavy use in many industries and has survived for too many decades to be considered dead just because it never got popular enough to be taught to children or in coding camps. There's never been an incredibly large userbase, but I don't believe that detracts from it.

>if you wanna alienate yourself from the FOSS community

This is fair enough, but it's not as if there's no Free Software projects written in any of these languages and it's not as if one couldn't be started if someone wanted it.
Guido, Matz, and friends don't own Free Software.

>cut your chances to get a programmer job almost to 0

It's easy to get employment in any language. I don't want to bring my personal life into this, so take my word for it.
Also, understand that knowing a more common language increases the chances of being replaced. Knowing languages less people know is good for salary and job security.

>not be able to understand most of the academia's research papers

Most research papers I've read use a pseudocode to describe algorithms. Several resources invent new languages to discuss their topic.

>Otherwise, OP, figure out which field you wanna work on, and choose your language accordingly.

I wouldn't recommend it, but it's not as if someone couldn't learn both Ruby and, say, a Forth, although the Forth would be significantly easier to learn, use, and almost certainly prove more valuable in the long term.

  No.19185

>>19177
> but they'll certainly leave a glut of indecipherable programs, just like Perl.
>encourages APL
>complains about Perl's syntax
You just can't read it. Code is hard to read in any language that you don't know. I have trouble reading lisp programs because it does look like oat meal with nail clippings, I can't read FORTH for the life of me

Also you lispers LOVE to say that Common Lisp will be here in 200 years, but it's not the only one. FORTRAN, C, and the shell langauges are also lasting; and having my code still run when I've already forgotten about computers is not by far my goal when programming. Actually, I believe that no software is bound to keep running after a couple decades, and that is while being heavily mantained. I might be biased but regarding Perl, even if it's not there for 50 years, I'll be writing it to do the tasks I need it to for as long as it's still relevant.
Also
>neurosuggesting 30 year old lisp code is anywhere readable or even relevant for today's standards or implementations

I do have a question since you guys keep insisting on FORTH
I am actually interested, but when I look into what purposes it serves, it really doesn't appeal to me much; I don't do any embedded programming, but it is almost all that it's advertised for. Wherever I look at what FORTH is good for, it never ever lists any day-to-day application. A mother loving shell, network application, symbolic calculator, even an esolang interpreter. I'm not in charge of many radio telescopes so I fail to see if FORTH is worth learning for me (I do want to be able to USE my languages for something, mind you, I didn't get into programming just to be smug (there are other reasons)), lest going through the process to learn the language. I've tried but FORTH intros are always "stack operations for babies" and I get bored after a while of pages of nothing new. I want to see what's so special about forth, not just drill over <<1 1 + . ok>>.

  No.19186

>>19168
>I started with PROLOG as a first language.
how did this happen? were you recommended it? did you find an instructional web page or book? genuinely headspinning stuff, a bit like prolog I suppose.

  No.19192

>>19185
>Also you lispers LOVE to say that Common Lisp will be here in 200 years, but it's not the only one. FORTRAN, C, and the shell langauges are also lasting; and having my code still run when I've already forgotten about computers is not by far my goal when programming. Actually, I believe that no software is bound to keep running after a couple decades, and that is while being heavily mantained. I might be biased but regarding Perl, even if it's not there for 50 years, I'll be writing it to do the tasks I need it to for as long as it's still relevant.
Well, that's how you approach things. I believe some systems, such as TeX, probably, will live a long while without modification. I never said C hasn't embedded itself fairly well, but so have other poor languages.

>neurosuggesting 30 year old lisp code is anywhere readable or even relevant for today's standards or implementations

I like that I can understand it reasonably well, with no effort, but it would require some reading into the implementations of some macros to understand much of it. That's no real issue.
Besides, a good bit of old Lisp code to read uses basic procedures that have remained static throughout the decades and so require no effort to understand.

>I do have a question since you guys keep insisting on FORTH

I just like stack machines. The Mill architecture and memory to memory machines are also interesting.

>A mother loving shell, network application, symbolic calculator, even an esolang interpreter.

I've written an incrementally compiling implementation of an esoteric language I've developed in Forth, but I kept rewriting it to make it simpler and eventually wrote an interpreter for it in APL to amuse myself.

>I'm not in charge of many radio telescopes so I fail to see if FORTH is worth learning for me (I do want to be able to USE my languages for something, mind you, I didn't get into programming just to be smug (there are other reasons)), lest going through the process to learn the language.

You and I are similar, in this respect, then.

>I've tried but FORTH intros are always "stack operations for babies" and I get bored after a while of pages of nothing new. I want to see what's so special about forth, not just drill over <<1 1 + . ok>>.

So, stack machines are based on RPN, which I won't explain. Some of the operations rather inherent to a stack machine are swapping, duplicating, dropping, and basic mathematical routines. A main memory is also important, just as how a register machine usually has a main memory to save to for longer periods of time and other purposes.
Forth is one of the better known stack machine models, but it doesn't add much asides from a focus on extreme simplicity and the means with which it stores procedures.
So, to make certain operations convenient, Forth words can read ahead and break the appearance of the stack model a bit, which is how infix operators could be defined.
The basic Forth word for this is WORD. Then we have CREATE, which starts a definition.
The system is either executing or compiling. Compiling adds encountered words to the current definition. The [ and ] words disable and enable compilation.
Immediate words are executed, even if the system is compiling, which is how metaprogramming is achieved. POSTPONE is the standard word to delay execution, so immediate words are still compiled into a definition and normal words compile the act of compiling that word. Words that aren't immediate can still be executed when compiling with [ and ].
The compiler is called colon, :, which enters the first word it finds as a name in the dictionary and begins compiling. A definition is ended by semicolon, ;, which compiles an exit and ends compilation.
Literals are entered by LITERAL.
ColorForth is a system that makes this even simpler, with comments denoted by one color, words to be compiled into another, words to be executed immediately in yet another, word names to be defined in a different color, literals in another, among other purposes.

APL is another simple language. There's some special characters, most defined to work on any size of an array. When calling these with an argument on their right, they're monadic and do one thing. When surrounded by arguments, they're dyadic and do something else. Definitions can also be niladic, meaning they take no argument. Complex arrays are built with rho, ⍴, accepting vectors, which are denoted as simple space-delimited numbers, such as this: 11 22 33
Operators can be defined, which accept procedures as well as arguments. Operators are reversed, with a monadic operator accepting its procedure argument on the left and dyadic operators accepting one on each side, of course. As a simple example, duplicate, ⍨, accepts a single argument and a single procedure, which it calls dyadically on the argument. So, f⍨B is BfB.
Data is either sent along to other procedures, stored into a variable by ←, or printed.

  No.19193

File: 1475996529443.png (219.32 KB, 200x150, heresy 2.jpg)

This thread has derailed like no other thread in a long while. Your favorite language is not important to this thread, if you have experience in programming, learning the intricacies of a new language is far easier, to the point of being almost irrelevant. Shouldn't a discussion of which language is more appropriate for which situation be in a new thread? Talking about how much <<language>> is like kicking dead whales down the beach isn't going to help OP in any possible way i can imagine.

The point of this thread is just "how to become a better programmer", brewing soykaf about languages isn't a learning method. Please, this isn't /g/, focus on the thread's subject, if you want to discuss something else create your own thread.

  No.19194

>>19185
>I've tried but FORTH intros are always "stack operations for babies" and I get bored after a while of pages of nothing new. I want to see what's so special about forth, not just drill over <<1 1 + . ok>>.
Read about memory allocation, immediate words, changing the reader, boostrapping from a minimal initial implementation.

  No.19196

>>19193
I understand the topic of this thread. I wrote the second reply.

I believe improving at programming requires avoiding lesser languages and the current discussion has drifted a bit in that general direction, but I wouldn't call the thread derailed.

>if you have experience in programming, learning the intricacies of a new language is far easier, to the point of being almost irrelevant.

This isn't correct. Perhaps it's true when learning languages that are already almost the same language.

>Shouldn't a discussion of which language is more appropriate for which situation be in a new thread?

It seems roughly appropriate here, given the context.

>Talking about how much <<language>> is like kicking dead whales down the beach isn't going to help OP in any possible way i can imagine.

I'm trying to prevent the OP and others from wasting their time learning a poor language.

  No.19197

>>19196
>I'm trying to prevent the OP and others from wasting their time learning a poor language.

This isn't the point of this thread, he decides whether he wants to use language X or Y, not you.
If you think language X or Y is a bad choice, you create your own thread talking about why X language isn't appropriate for beginners instead of hijacking another. There is no way in hell a beginner is gaining anything by this discussion, it's only "productive" for you and the people you're discussing with, thus you should create your own thread.

  No.19201

>>19193
First of all how can you even remotely compare this to /g/? Were this /g/ tier half of the posts would be
>c.uck language xD
so f.uck off with that

That said, language discussion is healthy and it is relevant to becomming a better programmer, as [otherguy] said, it at least keeps people from falling in the trap of learning the same language disguised as many languages.
I've found that a great deal of getting better at this is to learn different ways of thinking about programming.
Moreover nobody's saying <<language>> is like kicking dead whales down the beach. While there is derail, a discussion about languages and their relevance is still due, want to become a better programmer? learn what programming is about. How languages differ, what is considered important, make your mind about what's relevant, and so on.
Don't compare us to that soykafhole again>>19193

  No.19754

>>13419
This is a really useful advice.
Things didn't start to really click until I started doing the exercises

  No.19759

This is a hard question to answer. I suppose the answer is to keep learning. Always. Keep solving problems with code. They can be mathematical, or algorithmic, they could be problems from a textbook, vague endpoints, or full-scale projects. Ideally, they'll be a mix of all of them. For satisfying part of this equation, I would recommend Advent of Code, for which the new season will be starting this December, and you can still do last year's problems.

Also, learn new languages, because languages effect the way you think. Learning new ones is the most effective way to open yourself to new paradigms. Also, they come in handy sometimes. As a rule, you should try to learn languages pretty far from what you've learned already, but here are my suggestions:

-C: Let me not bandy about: C fuarrrking is like kicking dead whales down the beach. But you need to learn it anyways. Why? Because it teaches you a lot of skills. It will help you learn to manage memory by hand. It will help you learn to deal with unstable, dangerous environments (due to that fact that the compilers are written by psychopaths who hate humanity, if you are writing C, you MUST avoid undefined behavior like the plague: this means that you cannot check for, say, integer overflow by checking if((integer += 100) < oldinteger)). It teaches you how to think like a C programmer, to optimize heavily, and how C programs work. And it teaches you to handle an environment that won't handle your errors for you.

-Assembler (x86 at least, but others are also worth learning): Continuing in the theme, you have to learn at least one assembler because it teaches you a lot about how your computer works. It will teach you how the hardware is exposed to the software, and many other things.

-Lisp (I prefer Scheme over CL and Racket, but whatever...): Lisp is the opposite of C: It's a family of languages whose syntax is identical to that of the list datastructure within the language. This makes, for instance, crawling Lisp code with Lisp code, trivial, and gives rise to "macros" - essentially, code that writes code at compile time. Lisps are profoundly weird, but they're really easy to learn syntactically (and trivial to parse!), and learning idiomatic lisp will teach you a lot about programming.

-Haskell (or OCAML, or SML: I think Haskell is the nicest, but that's just my opinion): Functional programming is an important, powerful technique. So you should learn at least one functional language, to get a feel for it. If you learn Haskell, you'll also learn about laziness, which is another pretty neat feature. But the real thing that you should take away from your time with Functional Programming is understanding just how powerful type systems can be.

-Erlang: Erlang is also functional, but that's not why it's here. Erlang is here because Erlang uses actor model messaging, and will teach you a lot about that paradigm, and how do do concurrency while staying sane (it's not the only way, but it's an interesting one).

-Prolog: Prolog is totally and utterly different from just about every language on this list. It's a logic based language, which deduces conclusions from facts. And it's awesome. Just go learn it, you'll be glad you did, even if you don't use it much.

-Smalltalk (Squeak or Pharo are probably the best implementations to use: don't use GNU Smalltalk): Yes, Sir Alan Kay's language. Acutally, Smalltalk isn't just a language, it's a complete environment, and the original IDE. It will show you what OOP was meant to be, and just how powerful it can be. I can't adequately describe it in this (increasingly long) comment: Just go grab a copy of Squeak, and see it for yourself.

This isn't a definitive or complete list, but it's a start. If any of these sound interesting, by all means, take some time to maybe learn a few once you've got a solid footing in your first language.

  No.19764

>>13410
While it doesn't really actively contribute to making you a great programmer, I think an interesting thing to do is listen to themed programming podcasts. I don't know why but ever since I started listening to a few (two so far) programming podcasts, I feel like I've somewhat filled a missing gap since every community has its own echo chamber aspects whether they want to admit it or not, and it's refreshing to hear about a bunch of different perspectives and experiences. I actually found people I want to emulate by listening to the Hello World podcast like John Robbins, Lino Tadros, Scott Guthrie, and so on. Listening to them talk about how it's been [x] many years since they started but things just keep getting more and more interesting is really inspiring in terms of wanting to make things and solve problems. I just wish that Wildermuth would stop doing the whole "heh kids these days have never heard of, seen, or used cassette tapes" thing. Now, I wouldn't just go listen to any old podcast since even some of the HW guests suck (Lynn Langit, Phil Haack, Beth Massi) but if you can self-curate and take a gamble on something that might sound cool, it's great for commuting or just plain getting away from the computer for a bit.

Another thing would be that you just don't stop learning. That's another thing I've learned just on my own and from those podcasts. Things like K&R and BASIC manuals used to be the only resources people had back in the day, and it was difficult but it was really all they had to know at the start. As the field matured and things got bigger, people either kept up or were left in niche positions/specializations where their pay could be questionable and their assignments limited to maintaining a codebase. Autodidactism is the strongest trait a programmer can have.

You also don't become some bitter language elitist because you can't understand syntax that any modern book can explain competently.

  No.19768

>>19759
Just going to copy your post and store it in a text file, thanks. I've already dipped into CL and asm and now I'm steadily learning C. After that I'll take up CL.

Logic programming paradigm seems pretty interesting, will look into it in the future.

Cheers.

  No.19776

>>19764
>Autodidactism is the strongest trait a programmer can have.
I agree.

>You also don't become some bitter language elitist because you can't understand syntax that any modern book can explain competently.

It's not a case of not understanding. It's disgust.

  No.19787

>>19776
>I agree.
I actually read this thread. You don't or else you'd have no trouble or issue with syntax, nor would you have issue with people learning other newer languages as their first. Time and time again, syntax has quite possibly been the easiest part of programming, with the actual learning curve being about learning how to identify a problem, creating a plan to solve it, and implementing it. I suggest picking up a new book instead of writing the equivalent of a 3 page essay about why sticking your head in the sand because you're "disgusted" - in which you never actually directly address your issue and just:

- cite incredibly topical reasons like the Python 2/3 version split
- cite a side comment from Torvalds
- cite APL with your only argument being that things are entered verbatim
- call things like C, Ruby, C++, Go, even UNIX, etc, "trends" as if programming were something as vapid as designer fashion

- is ok. You say you're not in this to be smug or an elitist but your self-admitted first post was "all other languages are inferior and FLAWED unlike [all the old-hand languages from the good ol' days]" - honestly just as bad as the Javascript/JS Framework cultists these days who won't work in anything else. You may know what you're talking about concerning your favored languages and be good at using them, but your way of thinking is incredibly narrow and your flexibility is poor; therefore I cannot in good faith support the notion that your specific advice is helpful to anyone looking to improve at programming in general. If you had stressed that learning Prolog/Forth/etc would have been a powerful complement to more modern languages as doing so provides understanding of the flaws and shortcomings of more modern languages, I would have had no issue supporting you.

  No.19790

Who even cares about syntax? Having learned a ton of programming languages and implemented one, honestly they're not all that different.

  No.19796

>>19787
>I actually read this thread. You don't or else you'd have no trouble or issue with syntax, nor would you have issue with people learning other newer languages as their first. Time and time again, syntax has quite possibly been the easiest part of programming, with the actual learning curve being about learning how to identify a problem, creating a plan to solve it, and implementing it. I suggest picking up a new book instead of writing the equivalent of a 3 page essay about why sticking your head in the sand because you're "disgusted" - in which you never actually directly address your issue and just:
Most modern languages are derivatives of ALGOL and so people get the impression that ALGOL derivatives are most of what programming is. I believe it's important to avoid that.
If complicated syntax wasn't an issue, we wouldn't see flaws such as goto fail; happen every now and then.
So, we disagree here.

>- cite incredibly topical reasons like the Python 2/3 version split

That's not a good reason to avoid Python, especially over languages without such a schism? It's advantageous to use a language with such a schism?
>- cite a side comment from Torvalds
Why don't you cite a prominent programmer saying good things about C++, if you think someone should learn it? The large crowd that hates it is a good reason to avoid it. I believe even the creator has said that the language is too large for a single person to understand.
>- cite APL with your only argument being that things are entered verbatim
Are you referring to >>19192?
>- call things like C, Ruby, C++, Go, even UNIX, etc, "trends" as if programming were something as vapid as designer fashion
The WWW is an excellent example of how computers have been attacked by fashion types.
Part of the reason for this advice is to avoid using things that can simply disappear. Look at how all of those people depending on Python 2 feel.
For a general program, let's say an email client, one should try to rely on as little as possible. Using standards is a great way to make certain your program won't die because support for something was dropped. Dependencies that can't be avoided should be minimized.
Now, of course, this advice isn't suitable for every program. An embedded program will be dependent on hardware and whatnot, as an example.

>- is ok. You say you're not in this to be smug or an elitist but your self-admitted first post was "all other languages are inferior and FLAWED unlike [all the old-hand languages from the good ol' days]" - honestly just as bad as the Javascript/JS Framework cultists these days who won't work in anything else.

So, does that make you a lukewarm elitist? I've strong opinions, so I'm as bad as other people with strong opinions?
Let me lay out several qualities these languages have that these more modern languages severely lack:
standardization
multiple implementations following that standard or otherwise behaving identically
more thought than those from a single language dictator have shaped them

Now, almost every language starts without these qualities, but they're important after a while. There are cases when some of these qualities don't matter much, which I'll let you sort out. Every case is different, but these are good heuristics.

Regardless, I can do something in one of the languages I enjoy without someone telling me it's, say, ``unpythonic'' and so not allowed.

>You may know what you're talking about concerning your favored languages and be good at using them, but your way of thinking is incredibly narrow and your flexibility is poor; therefore I cannot in good faith support the notion that your specific advice is helpful to anyone looking to improve at programming in general. If you had stressed that learning Prolog/Forth/etc would have been a powerful complement to more modern languages as doing so provides understanding of the flaws and shortcomings of more modern languages, I would have had no issue supporting you.

Well, my advice won't change simply because someone doesn't support it. Regardless, I'm glad we can remain civil throughout this.

  No.19797

>>19790
>Having learned a ton of programming languages and implemented one, honestly they're not all that different.
Compare APL to Forth to Lisp to C to COBOL to Prolog to an assembler language.

  No.19801

>>19796
I disagree that you shouldn't learn Python, Ruby, etc. IMHO, you should learn at least one such language, as scripting languages are good at exactly that: scripts. If you want to toss together a 50-line piece of glue code, or a quick commandline utility, and Bash isn't gonna cut it, Python and Ruby absolutely shine.

>Part of the reason for this advice is to avoid using things that can simply disappear. Look at how all of those people depending on Python 2 feel.


Errm... Yeah, but Unix isn't just going to up and disappear. In fact, C and Unix are probably the things that are most likely to be around in 100 years. Lisp and FORTH are pretty far up on that list as well, but Unix and C are the modern lingua francas of computing: like them or no, if you want to get serious about programming, you have to know them.

  No.19806

>>19796
>If complicated syntax wasn't an issue, we wouldn't see flaws such as goto fail; happen every now and then.
The weakness lies with the user; if the issue is identified, people can fix it. No one and nothing is perfect and people make errors. However, your difficulty with syntax implies something is missing in your core educational foundation outside of programming. This is where I highly doubt your autodidactic qualities.

>That's not a good reason to avoid Python, especially over languages without such a schism?

Yes, it's not, especially since the community realized that sitting around and complaining that there was a split and proselytizing about "better ways" wasn't going to do them any good. The schism has received an honest amount of bridging work and it goes back to how I point out that you are narrow in thinking and stuck in your ways as you are unaware of your surroundings because something disgusted you once.

>The large crowd

Find me this "large crowd". Where are they? People who grumbled about C/C++ once because they were stuck on a particular part of a program and couldn't figure something out? This argument can work both ways and one very general comment doesn't mean that it's automatically a bad language; if you weren't so focused on keeping a pair of blinders on to separate your current knowledge and the rest of the field, you'd notice that he also said that "a lot of substandard programmers use it, to the point where it's much easier to generate total and utter crap with it." This isn't limited to programming either: people can take common/useful tools or processes and make total garbage with them, easiest to see within the field of writing.

>Part of the reason for this advice is to avoid using things that can simply disappear. Look at how all of those people depending on Python 2 feel.

Python 2 is still very much supported. As noted before, it isn't as if the community sits on its laurels lamenting how things suck. There was an entire mess with Javascript several months back because thousands of libraries depended on one person's module and that person took it down in a fit of rage for some reason or another and it broke a lot of web pages. People, web-based or not, have learned this lesson on a huge scale now. It won't be the last time this happens because someone is bound to forget; progress. Once again, take off your blinders.

>So, does that make you a lukewarm elitist?

No, because I'm not the one saying that $languages are flawed and inferior because I don't know how to read. What benefit do I get from saying that languages like Lisp and Prolog are flawed/inferior? What benefit do I get from limiting myself to commonly used languages? None. I have languages I prefer, but I'm not going to merely consider a language fit for being introductory just because it's been around since the start if there are other languages with educational curriculum designed around them.

1/2

  No.19807

2/2

>>19796
>I've strong opinions, so I'm as bad as other people with strong opinions?
No, you're a pompus frog. People with strong opinions won't act like pompus frogs bemoaning how everything new is broken and can't be fixed and refuse to stay aware of the world around them so they can continue exuding their air of superiority. Stallman has strong opinions on dangerous proprietary software and encourages people constantly to pay heed to his findings, but he doesn't pu-pu people for doing other things that don't fit within his world view. He may be disappointed when people keep using proprietary systems and software and he may suggest alternatives, but he won't launch into a fit of holier-than-thou lecturing about how he struggled to read C syntax and that's the reason why we should drop everything that has a hint of proprietary code and blindly follow his ideology.

>"unpythonic"

The only place I've read someone actually dismiss something as "unpythonic" is in comments on Stack Overflow; those are the kinds of comments and quips that people use to garner internet reputation points by treating a language like an ideology. This can also stem from said commenter having Python as their only known language. If anything, I'd figure you'd be fine with the term "unpythonic" because it's a word that fits within the dogma you've danced around about how there is only One Way to learn to be a programmer.

>Well, my advice won't change simply because someone doesn't support it.

I'm not saying and will not say that languages like Lisp aren't good to start with. So long as the proper educational foundation exists and the reasoning for using said language is ACTUALLY solid and modern in text/reader or teacher/student interaction, an introductory language could be any one that you wish. I'm saying you aren't qualified to give general advice despite your specific knowledge because you are trapped within not only your comfort zone but your own ego; your entire basis of reasoning for your stance has been "I can't read syntax of modern languages and didn't apply myself to doing so, therefore it is the fault of the languages. They are broken and flawed at a fundamental level, not me. Therefore, I will use the convenient flaws of modern languages to hide my own shortcomings while giving advice based on them."

Based on all of this and all I've witnessed, I'd also say that what makes someone a good programmer is their acceptance of change, good or bad. For example, I dislike Javascript. I dislike most things designed for the web. That doesn't mean I'm going to shackle myself to a handful of languages limited in scope and one viewpoint despite how much of an abomination the web has become.

  No.19810

>>19807
Not the same lainon, but "unpythonic" is used by the language creator, Guido, to justify the exclusion of multi line lambdas and other important features (like tco)
http://www.artima.com/weblogs/viewpost.jsp?thread=147358
And syntax does matter when one considers the macro. Languages that don't have homoiconicity, like most modern day languages, aren't able to fully utilize the power of meta programming. Because of this little fact it does indeed make the syntax of a language like lisp superior to the various algol derivatives.
On a less objective basis the syntax of thr language is a serious of rules that the programmer must memorize, and so extra syntax means extra information that the programmer had to keep in their head.

  No.19811

>>19806
>The weakness lies with the user; if the issue is identified, people can fix it. No one and nothing is perfect and people make errors. However, your difficulty with syntax implies something is missing in your core educational foundation outside of programming. This is where I highly doubt your autodidactic qualities.
You misunderstand, much. I'm entirely capable of mastering a disgustingly complicated syntax, such as C's, but I don't want to. I could even invent my own syntactic monster like Duff's device, but I won't because I don't want to.

I'm constantly educating myself by reading manuals and standards and whatnot. The rub is that I'm only going to learn about what actually interests me.

>The schism has received an honest amount of bridging work and it goes back to how I point out that you are narrow in thinking and stuck in your ways as you are unaware of your surroundings because something disgusted you once.

Notice that I'm discussing ideas, while you seem to be taking issue with me personally. You would do good to discuss my advice, rather than assumptions you've made of me.
Am I unjustified in disliking any of Python's other glawing flaws? What about the completely unnecessary restriction on lambdas?
I've taken looks at these languages I discount and found them to be utter messes. You're acting as if it's unreasonable to discount entire languages for what you see as small flaws, when there is an abundance of languages without any of this.

>Find me this "large crowd". Where are they?

Here's a good start; there are plenty of quotes: http://harmful.cat-v.org/software/c++/
>if you weren't so focused on keeping a pair of blinders on to separate your current knowledge and the rest of the field
You seem to be under the impression that much of the field isn't full of useless garbage.
Also, you've completely sidestepped my request. I wanted you to find a prominent programmer with something good to say about it, but this may have proven too difficult.

>There was an entire mess with Javascript several months back because thousands of libraries depended on one person's module and that person took it down in a fit of rage for some reason or another and it broke a lot of web pages. People, web-based or not, have learned this lesson on a huge scale now. It won't be the last time this happens because someone is bound to forget; progress. Once again, take off your blinders.

So, I'm silly for not wanting to sit around in a insider trade ``learning'' obvious things repeatedly? Your entire paragraph is asinine.
By the by, the author removed their modules because of a naming issue involving a company claiming ``kik'' after NPM took the name from him.
The very fact that you can look at that scenario and think that it's all fine and dandy so long as someone ``learned'' something from it is shocking. I really doubt you're suitable to give any advice on much of anything after reading this. That may be rude, but it's not as if you've afforded much hospitality to me in this discussion.

>No, because I'm not the one saying that $languages are flawed and inferior because I don't know how to read. What benefit do I get from saying that languages like Lisp and Prolog are flawed/inferior? What benefit do I get from limiting myself to commonly used languages? None. I have languages I prefer, but I'm not going to merely consider a language fit for being introductory just because it's been around since the start if there are other languages with educational curriculum designed around them.

Again, you're assuming my preference is because of ignorance, which I can assure you is not the case.
I'm recommending certain languages for starting because those languages are simply better than the most commonly used languages, on average.

  No.19812

>>19807
>No, you're a pompus frog. People with strong opinions won't act like pompus frogs bemoaning how everything new is broken and can't be fixed and refuse to stay aware of the world around them so they can continue exuding their air of superiority.
I don't have much of a response to this, because I find it lacking substance. This seems to be a pure insult filled with assumptions.
I don't like UNIX, but that's nowhere near new. Can't you consider that I'm judging these things and giving my reasoned opinion on them rather than generalizing?
>Stallman has strong opinions on dangerous proprietary software and encourages people constantly to pay heed to his findings, but he doesn't pu-pu people for doing other things that don't fit within his world view. He may be disappointed when people keep using proprietary systems and software and he may suggest alternatives, but he won't launch into a fit of holier-than-thou lecturing about how he struggled to read C syntax and that's the reason why we should drop everything that has a hint of proprietary code and blindly follow his ideology.
You're attacking a strawman of my argument. I've many more problems with these languages than simply syntax. I believe I've properly listed many of these issues, yet you continue to ignore them.

>The only place I've read someone actually dismiss something as "unpythonic" is in comments on Stack Overflow; those are the kinds of comments and quips that people use to garner internet reputation points by treating a language like an ideology.

This is Guido van Rossum, the creator of Python: https://neopythonic.blogspot.ca/2009/04/tail-recursion-elimination.html

>A side remark about not supporting tail recursion elimination (TRE) immediately sparked several comments about what a pity it is that Python doesn't do this, including links to recent blog entries by others trying to "prove" that TRE can be added to Python easily. So let me defend my position (which is that I don't want TRE in the language). If you want a short answer, it's simply unpythonic.


>This can also stem from said commenter having Python as their only known language. If anything, I'd figure you'd be fine with the term "unpythonic" because it's a word that fits within the dogma you've danced around about how there is only One Way to learn to be a programmer.

I don't believe I've ever written here that there was only one way to learn how to be a programmer.
Again, you seem to be warping my arguments to suit yourself.

>I'm saying you aren't qualified to give general advice despite your specific knowledge because you are trapped within not only your comfort zone but your own ego; your entire basis of reasoning for your stance has been "I can't read syntax of modern languages and didn't apply myself to doing so, therefore it is the fault of the languages. They are broken and flawed at a fundamental level, not me.

You continue to misrepresent my arguments. Syntax is certainly part of it, but this is not because of ignorance or inability on my part, but my reasoning as to why these complicated syntaxes are less useful than more regular syntaxes.
>Therefore, I will use the convenient flaws of modern languages to hide my own shortcomings while giving advice based on them."
So, flaws are excused in modern languages? It's not okay to criticize them because it makes you seem a certain way?
Most of your criticisms of my positions seem to be based on your false criticisms of my character.

>Based on all of this and all I've witnessed, I'd also say that what makes someone a good programmer is their acceptance of change, good or bad. For example, I dislike Javascript. I dislike most things designed for the web. That doesn't mean I'm going to shackle myself to a handful of languages limited in scope and one viewpoint despite how much of an abomination the web has become.

My solution is to avoid the WWW whenever possible. It's best to avoid stepping in drivel when one can.

  No.19823

File: 1477806801416.png (709.15 KB, 187x200, al.gif)

Any tips on managing large scale applications alone?

Ive noticed I have a tendency to get "lost" once my program gets 500+ lines (not to mention several other programs approximately the same size). I start to lose track of the logical flow of the application once functions are calling other functions, etc. I recently picked up Hungarian notation because once my programs got really big I found it very necessary to keep track of what data type the variable is, if its global, etc. and this has helped which makes me suspect that my problem here is organization. I typically sketch out a very general pseudocode (or UML if my teacher requires it) but I definitely have room to step up my software engineering skills when it comes to organization.

For background, I'm a CS student (junior) and recently got my first programming job. The rubber is hitting the road and I realize I have a lot to learn, in fact I feel as though almost nothing I have learned in school has prepared me for this job. I'm under a lot of pressure to perform, I don't want to fuarrrk this up.

  No.19826

>>19823
500+ lines is far from "large scale". It does sound like you have some organisational issues.

>I start to lose track of the logical flow of the application once functions are calling other functions

You shouldn't need to think about that. If a function does one thing, then you know it will do that thing and return. Any functions it calls are unimportant. The whole point of functions is abstraction!

>I recently picked up Hungarian notation because once my programs got really big I found it very necessary to keep track of what data type the variable is, if its global, etc

Variables should have descriptive names, and be in as narrow a scope as possible. Globals are almost never necessary. Hungarian notation is generally frowned upon because it's easy for it to become inconsistent: what if you realise your list actually needs to be a set, and you've called it "lFooBar" everywhere?

The only way to improve is to practice, practice, practice!

  No.19828

>>19823
Getting lost as your project gets bigger is a common thing. It helps to keep it simple and modular; refactor at will, separate related components, keep project-wide functionality on a file of it's own, etc. When you refactor you have the advantage of knowing beforehand the pitfalls of the project when you're designing the code. 500 lines is not much, and in refactoring you'll probably keep at least half of it: the functionality. You just modify the architecture. The sooner you refactor the less you'll have to rewrite, and it gives you a chance to go over all your code again so to keep it fresh in your mind.
>in fact I feel as though almost nothing I have learned in school has prepared me for this job. I'm under a lot of pressure to perform, I don't want to fuarrrk this up.
I've heard that's the effect that school has on people.
But don't sweat it! Do your best and as >>19826 said: practice!

  No.19830

>>19810 (and all of this thread)
The problem, in my perspective, is that you guys bottle up inside your language and disregard the real world. I'm not saying it's perfect, it's flawed as fuck, but it's there.
See, LISP seems to have a culture of closing yourselves from the rest of the world to attend your own little world of mathematical superiority. Muh syntax and muh macroz, and picking a bad language as a strawman for the rest of the languages...
Claiming superiority because of a few, language-specific (there really are more languages than just lisp and algol, mind you all) features that actually give the language it's flavour, yet you disregard the several flaws of lisp which make it barely usable in the real world. Particularly, it's syntax makes it actually hard to read, in the words of Larry Wall: it looks like oat with nail clippings. Syntax actually has a reason to be, even if you choose to treat it as the boogeyman because muh homoiconicity (I'm sorry to use this cancerous 'muh' idiom but this anti-syntactic jerkoff is just as annoying). However, syntax amounts for readability, because sometimes it is more convenient to have a readily readable script that takes advantage of syntactic shortcuts where something like
stuff[10]->lard
amounts for something along the lines of
(dereference (index stuff 10) 'lard)
not to mention that parentheses everywhere are annoying. They are. I kid you not. They are.
But that is not all, there are many flaws to lisp: a 20-year old standard that fails to meet modern criteria, leaving all useful functionality at the mercy of libraries that will probably will be dead in 20 years (as you guys so much love to claim that your language will still be useful, and the same argument you use against <every other language>, namely, that libraries will not be supported then), also the fact that it is pretty much married to Emacs, again, because of PARENTHESES EVERYWHERE.
to be continued...

  No.19831

I've been learning C++ for a while now and I'm not sure what should I do to keep learning. I already know the basics like variables, functions, loops, objects, polimorfism, pointers... But all I do is useless software with the terminal. How can I make better software and what should I learn if I want to start working with GUI?

  No.19832

>>19830
Anyway, I want to address my main point.
Languages are more just than languages. It's not just the syntax and the semantics, it is also the culture, the people that use them. Else you wouldn't be complaining about unpythonism, right?
And the main pathological issue of LISP, superior as it might be because of it's features (which are not always needed, for example in loading a huge runtime just to run a quick script, or having the power of MACROZ when you want to do something really simple), is it's unwillingness to cooperate with the real world.
Indeed, lisp programmers love to jerk off to how superior the language is, and so they seem to believe it is all you need, and fail to make it useful for the world outside of their closed lisp community. You got to love lisp to appreciate lisp. I don't see nothing wrong in that per se, but coming around and bashing every other language because of your inflated ego because my aeternal language, that is unhealthy.
In a lot of things I can see this closedness of the lisp community which keeps the language from being open to use. It is not, as you might think, just history that makes a technology popular and widespread, it is it's convenience in actual work. UNIX might have spread as a plague, but it did so because it met the necessities of the world at it's time. The lisp machine could've tried, but it died because it's community promised too much and failed to deliver. Today, the constant bashing of unix and jerking off to the UNIX Haters Handbook makes lisp look like a bunch of bitter old men complaining that the lisp machine is dead, not making their language accessible to UNIX, but rather closing itself to it's own world.
As such you stick to a standard that disregards USEFUL (yes, networks are useful, threads are useful, regular expressions are useful, graphics are useful (yet you love to complain about UNIX's native support for graphical displays), low-level, kernel interfacing facilities are useful) features that a lot of people in the modern world needs. Instead you stick to the mentality that "it needs not be extended, TCP/IP will die in 100 years anyway".
Again, my main point is that you don't play along. Lisp is awesome, indeed, but it bottles up inside it's own domain, and complains that other languages have their own domains.
In sum, lispers love to stay in their comfort zone, bashing everything out there and wondering why there is no love for their language, bitterly attacking it all yet expecting people to join their cult. The main reason for lisp's unpopularity is their failing to acknowledge the real world, while also complaining that other stuff, such as UNIX, is stuck in the 70s.
I'm going to stop here, even if I have more to say, because my post is too long and I think I made my point anyway.

  No.19833

>>19832
Naw man, I gotta add:
Just to make a short inventory of the things where lisp fails to play along
Character encodings. They just assume no standard character encoding will ever exist, and if one does, they fail to comply claiming we don't like standards.
Networking. Exactly the same issue
Threads. For some reason, they decided not to include this in the standard. Now you rely on a library that will go unsupported and the implementation of which is implementation specific.
Graphics. McCLim? Dead. CEPL? It doesn't play along either. You'd expect a language that cares so much about interoperability would make something that will run acrosss all patforms, am I wrong? I don't even know which OS to install if I want to use CEPL; I've tried with Arch and the BSDs.
FFI: For some reason this is, for the most part, excluded from the lisp education. As such, you are taught recursion, macros, list processing, metaobject protocols, yet there is no good authoritative resource on talking to libraries and the system. I think it's even implementation-specific.

The library system is bad also, (quicklisp), it has only one feature, yet lispers accept it as is, even while it doesn't live up to the promises of lisp by far.

The language is therefore mostly a language for list processing where every useful feature is implementation specific, and only the core will ever remain unchanged in 400 years as you love to claim and are particularly annoying in doing so (because so much of the software out there has remained unchanged for the past ~20 years, right? That's why we have a COBOL thread so I guess you're right).
To stress my point, lisp is still living the LISP-machine era. The standard was written when there were still lisp-machines around and to this day, many assumptions are kept from that past.
I'm not saying "Accept your UNIX overlord", I'm just saying "The real world is there guys, it too matters, even if you don't like it.

  No.19834

>>19832
I would like to point out, being the main fellow giving my advice since the beginning of the thread, that I'm not only recommending Lisp; I'm also recommending Forth, APL, and machine codes. I'm recommending most any language that isn't an ALGOL derivative, as most of them are rather poor to me.

>Languages are more just than languages. It's not just the syntax and the semantics, it is also the culture, the people that use them. Else you wouldn't be complaining about unpythonism, right?

I disregard community or ``ecosystem'' when considering languages. I consider it unimportant.
I mention ``unpythonism'' because Python isn't powerful enough to add features from within itself, so the BDFL has complete control.

>And the main pathological issue of LISP, superior as it might be because of it's features (which are not always needed, for example in loading a huge runtime just to run a quick script, or having the power of MACROZ when you want to do something really simple), is it's unwillingness to cooperate with the real world.

Consider this: It's possible and easy for me to write a program targetting specific hardware and system software. Anyone can do this. Meanwhile, not many languages make it easy to achieve relatively complete portability in the way that languages such as Common Lisp and APL do.
It's very easy to downplay portable programs as inherently inefficient and whatnot, but I still find the option important. Why, you could even consider UNIX to be a good example of the advantages of portability, even though it requires manual porting to new architectures.

>coming around and bashing every other language because of your inflated ego because my aeternal language, that is unhealthy.

I'm mostly ``bashing'' ALGOL derivatives with listed reasons. I can understand if this is considered annoying, so that's regretful.

>As such you stick to a standard that disregards USEFUL (yes, networks are useful, threads are useful, regular expressions are useful, graphics are useful (yet you love to complain about UNIX's native support for graphical displays), low-level, kernel interfacing facilities are useful) features that a lot of people in the modern world needs. Instead you stick to the mentality that "it needs not be extended, TCP/IP will die in 100 years anyway".

Regular expressions, even with special syntax, are capable in Common Lisp as a library, which has already been created and mentioned in this thread. Networking and threading support would've been nice, in a fashion that maintains portability across machines. Graphics vary far too much between different systems (consider, say, Oberon) to be portably used. It's possible that networking and threading were considered too varying between machines as well. It's not as if there's many machines to consider nowadays.

>Again, my main point is that you don't play along. Lisp is awesome, indeed, but it bottles up inside it's own domain, and complains that other languages have their own domains.

I've not complained that other languages are domain-specific; APL is; machine code is typically used in a rather specific manner.

>In sum, lispers love to stay in their comfort zone, bashing everything out there and wondering why there is no love for their language, bitterly attacking it all yet expecting people to join their cult. The main reason for lisp's unpopularity is their failing to acknowledge the real world, while also complaining that other stuff, such as UNIX, is stuck in the 70s.

I'm not concerned.

  No.19835

>>19833
>Character encodings. They just assume no standard character encoding will ever exist, and if one does, they fail to comply claiming we don't like standards.
I direct you to looking at how C fared in choosing an encoding and the world around it later changing.
>Networking. Exactly the same issue
The network probably could be supported rather portably, but it's similar to character encoding with specific protocols and their quirks.
>Threads. For some reason, they decided not to include this in the standard. Now you rely on a library that will go unsupported and the implementation of which is implementation specific.
This is also unfortunate, but I imagine not every Common Lisp system could support them. Consider that Common Lisp could run on a system such as DOS.
Considering that the filesystem portability layer is designed to support operating systems without subdirectories, it makes sense to consider that Common Lisp would also support systems without threading.
It would've been nice to have optional parts of the standard, however, so that systems could support that feature in a portable way.
>Graphics. McCLim? Dead. CEPL? It doesn't play along either. You'd expect a language that cares so much about interoperability would make something that will run acrosss all patforms, am I wrong? I don't even know which OS to install if I want to use CEPL; I've tried with Arch and the BSDs.
Graphics vary far too much between systems.
>FFI: For some reason this is, for the most part, excluded from the lisp education. As such, you are taught recursion, macros, list processing, metaobject protocols, yet there is no good authoritative resource on talking to libraries and the system. I think it's even implementation-specific.
I've been using Lisp for a while and I've never used the FFI directly. Common Lisp specifies no machine representation. It's inherently unportable.

>The library system is bad also, (quicklisp), it has only one feature, yet lispers accept it as is, even while it doesn't live up to the promises of lisp by far.

It works well enough.

>The language is therefore mostly a language for list processing where every useful feature is implementation specific, and only the core will ever remain unchanged in 400 years as you love to claim and are particularly annoying in doing so (because so much of the software out there has remained unchanged for the past ~20 years, right? That's why we have a COBOL thread so I guess you're right).

You undervalue the Common Lisp core.
>I'm not saying "Accept your UNIX overlord", I'm just saying "The real world is there guys, it too matters, even if you don't like it.
To hell with what you call the real world. I'll do what I want and nothing more.
Computing as a discipline is less than a century old and I refuse to submit to stupid jackasses who made a terrible operating system in the 1970s. Computing is my main interest and, unless I die anytime soon, I will leave the computing world looking different than when I entered it. I would say anyone suitably motivated should strive to leave their mark on their discipline.

Now, you can complain about Lisp all you like. I'll simply direct you to, say, Forth or APL instead. This thread concerns itself with improving at programming and that almost certainly must include learning something not tied to stupidly impractical systems that have taken over most of the world. You are as if a mathematics student only concerned with handling money and real measurements, because ``the real world is there too''.

My past few posts have been composed rather quickly, so I regret any dip in quality that may have occured.

  No.19837

>>19835
C never technically chose an encoding, they just assumed that bytes were always going to be 8 bits (which has stayed true) and called bytes chars.

  No.19838

>>19835
You seem to fetishize portability. Talking about DOS and complaining that UNIX is old.
I'm all in for diversity in programming languages, yet you seem to want to shut down completely a whole family of them because *you* don't like it.
along the line:
>Why, you could even consider UNIX to be a good example of the advantages of portability, even though it requires manual porting to new architectures.
Well, how else is that supposed to happen? That is inherent to using the same system in two different operating systems, it represents the least effort necessary. IIRC, lisp didn't thrive because it wasn't portable, it was written directly in the machine language of a machine that became obsolete [ESR99].
Then again, you don't need to specify graphics down to the metal, but merely the semantics and a programmer's interface for their use. There's, for example, a difference between OpenGL and SDL. Same goes with networking, same goes with threads.
I was quite annoyed that threads aren't suported by my multithreaded OS, even though I compiled with thread support, so much for your portable language.
>I disregard community or ``ecosystem'' when considering languages. I consider it unimportant.
You can't isolate yourself from the world. By saying real world I don't mean the enterprise, I mean people actually being able to use it for something. Your favorite languages' communities don't even make an effort, they are perfectly happy with staying in the obscurity, even regarding themselves as "secret weapons", and staying confined to their own domains despite claiming to also be the most general purpose languages out there. Then you come and tell people to disregard a whole family of languages with which stuff can be done in favor of writing programs that are bacwards compatible with DOS because unix is stuck in the 70s

  No.19839

>>19838
s/in two different operating systems/in two different hardware architectures/

  No.19840

>>19838
And lastly (I'm not going to complain further, because this is my ultimate issue with the elitist /λ/ mentality), you think you're being super helpful, but you're really doing quite the opposite. It's not all about the fun anymore, but about holding crazy artificial standards.
I wouldn't mind you having your own opinions but trying to push what seems like an agenda and the constant reminding of this (yet) unattainable idea without an alternative...
Do as you like regardless, I know lainchan is a sort of echo chamber anyway

  No.19842

>>19840
All tech communities are echochambers to some extent. /λ/ is probably one of the least echochamber-ey tech communities out there. Compare it to something like HN, Reddit, or even /g/.

>I wouldn't mind you having your own opinions but trying to push what seems like an agenda and the constant reminding of this (yet) unattainable idea without an alternative...


This is a problem in every tech forum as well. There's always somebody trying to push their vision, and there's always a guy off in the corner saying how much better things were in the days of the Amiga/LispM/NeWS/v7/Plan9/Smalltalk/whatever. These people are often (but now always!) one and the same.

The worst part is, sometimes they're right. In fact, usually they're right to some extent, although frequently not entirely.

And yes, it does make conversations unfun sometimes, but it frequently brings up issues that are worth discussing: I've learned a lot by talking to people who disagree with me.

  No.19844

>>19842
yeah I like it too because it's got me out of my comfort zone. But when it's all about how unix X technology suck sucks sucks, there is not much room for proper discussion anymore, it's just them trying to convince you.
Problem is, I stopped having fun because of this learnt mentality of ridiculous standards.
To make this ego show about it... eh

  No.19846

>>19840
I'm pretty sure Racket has everything you mentioned Lisp's lacking...
The only part I'm questionable on is GUI's, but there appears to be a standard GUI library that I haven't used, however I haven't used any C/C++ graphical libraries (other than SDL, which hardly counts), and only used Python's GTK bindings once, so I can't really judge its quality.
But everything else, e.g. threading, networking, regular expressions, FFI, they are all there and are designed pretty damn well.
I think that languages all have their use but Racket lisp could particularly fill the exact niche of Python, with the only downside being verbosity.

  No.19848

>>19837
I'm aware that the wording was misleading, but am also aware that effectively means ASCII or EBCDIC. Assuming a length is roughly equivalent to assuming an encoding, for most purposes.
I should've worded that more carefully, as I suppose it appears that I was being ignorant with that.

>>19838
>You seem to fetishize portability. Talking about DOS and complaining that UNIX is old.
I like portability for languages that encourage it, such as Common Lisp, APL, Prolog, and others. Languages that don't encourage perfect portability, such as Forth, are also fine. There's nothing wrong with targeting a specific environment for efficiency in, say, an embedded software.
>I'm all in for diversity in programming languages, yet you seem to want to shut down completely a whole family of them because *you* don't like it.
I suppose. I'm ultimately only offering my particular opinion.

>Well, how else is that supposed to happen? That is inherent to using the same system in two different operating systems, it represents the least effort necessary.

I suppose that was unfair. I concede that quip about porting. There's not yet a good way to port operating systems or at times language implementations without manual effort and there may never be. I didn't think through that properly.

>Then again, you don't need to specify graphics down to the metal, but merely the semantics and a programmer's interface for their use. There's, for example, a difference between OpenGL and SDL. Same goes with networking, same goes with threads.

The ANSI Common Lisp standard would've done good to specify optional segments, such as the ANS Forth standard did, so features could be used portably when feasible. Threading would be fairly obvious and networking could've specified how to support different protocols a standard implements.
I'm still skeptical that graphics could be given a portable interface, however.

>I was quite annoyed that threads aren't suported by my multithreaded OS, even though I compiled with thread support, so much for your portable language.

Unfortunately, threads are inherently not portable in Common Lisp. They belong to the class of language features macros can't add.

>You can't isolate yourself from the world.

That's false.
>and staying confined to their own domains despite claiming to also be the most general purpose languages out there.
I never made that claim.
>Then you come and tell people to disregard a whole family of languages with which stuff can be done in favor of writing programs that are bacwards compatible with DOS because unix is stuck in the 70s
I only mentioned DOS because that's a platform that Common Lisp can be ported to. My point was that Common Lisp is the common Lisp and can work uniformly on any machine because of its decisions.
In fact, there's nothing restricting any of the languages I've mentioned from working on most any platform. APL was used to define hardware in the past and I need not write of the portabliity of Forth. Meanwhile, APL gains little from platform-specific features, whereas Forth is expected to use a platform to its fullest extent, disregarding portability.

>>19840
>And lastly (I'm not going to complain further, because this is my ultimate issue with the elitist /λ/ mentality), you think you're being super helpful, but you're really doing quite the opposite. It's not all about the fun anymore, but about holding crazy artificial standards.
I don't see how this is elitist. I merely have a different opinion.
>I wouldn't mind you having your own opinions but trying to push what seems like an agenda and the constant reminding of this (yet) unattainable idea without an alternative...
>Do as you like regardless, I know lainchan is a sort of echo chamber anyway
All I'm doing is giving advice, the same as you. Someone will read this discussion and come to their own conclusion. I suggest this is better than a discussion in which there is no other voice with different advice.

Regardless, yes, I suppose this particular discussion in this thread is done, but someone else will probably question my advice, as they've done before.

  No.19850

>>19846
Yeah, Racket's pretty cool. I lean to the CHICKEN side myelf. CHICKEN doesn't have threads (it does have green threads, but that's not the same thing at all). However, the rest, especially FFI and networking, is excellent. Irregex works great for regexes, although it's slightly marred by incredibly verbose function names (which you can change)

If you really need threads, guile is also a good choice. Cyclone may also be, one day, but it's really mostly a toy for now.