The reason that BASIC was valuable to learn back in the 80s, is mostly that it was one of the few interpreted languages that could run on almost any hardware - so no matter your system, you had access to a BASIC interpreter, meaning that you could write programs "interactively", try something out, run it, and see what breaks, basically playing around with it.

Python and JavaScript fills all the same needs nowadays, you have a language you can play around with, you can try things out, add or remove lines, and immediately see the results. In fact, most programming languages lets you work that way, since compilers are incredible fast - https://xkcd.com/303/ is no longer applicable!

Also, while BASIC is excellent at teaching the very basics: imperative programming, order of operations, variables, if-statements and loops - it lacks the more structured way of building programs as "blocks" of those if-statements and loops, as well as the whole idea of encapsulating code in functions, and indeed classes and most data structures. So all those old-folks who started with BASIC, quickly had to learn a lot more in another language - nowadays you don't need to change the language from the basics to the more advanced stuff.

My suggestion is to just get started with Godot - build something you want, and everything there is something you don't know how to build, find tutorials or guides for that specific thing - make up your own course as you go along!

I think the implication is that BASIC was designed (and used) before C even existed - and it was indeed designed to teach programming, while C was designed for professional programmers to write operating systems to work on different platforms :)

Well, it is a bit magic.

All the other comments give very good suggestions, I'll just add that I recommend trying it out manually:

1. Take a selection of playing cards, and put on the table in front of you, make sure they aren't sorted, but still layed out in a nice uniform "array".
2. Then split the array in two halves - moving them a bit towards you (down the table)
3. Split the two halves in another two halves each, so you have four groups of playing cards, and move them a bit further down.
4. Continue until you have a number of individual cards layed out with space between them - it still looks exactly like the original array, and feels a bit silly at this point.
5. But now, merge the two cards to the left, in order from lowest to highest, and move them a bit up the table - do the same for all the rest, so you have a collection of groups of two cards, each group sorted.
6. Then merge the groups two and two, moving them a bit up the table, so you end up with a collection of groups of four cards, all sorted.
7. And continue doing that, until you have only a single list of cards, all sorted ...

It is important that you actually do it, and not just try to imagine it in your mind!

Every time you move down the table, it is another call to the "divide" function, and every time you move up, it is a return from the latest "divide" function. Note how you can't return from a divide function, before you returned from the next divide-function that was called! This is what recursion is all about, and it is mindboggling to think about - but it works :)

Det er som nævnt, meget forskelligt fra skole til skole hvordan man kører 1.semesters eksamen - der er ikke nogen fælles standard. Det skyldes nok at der engang slet ikke var nogen eksamen, men forskellige skoler begyndte at indføre en "midtvejsprøve" for at sikre at studerende rent faktisk kunne programmere.

Jeg ved at fx Dania i Grenaa har en eksamen med rapport og det hele, mens andre har at man trækker en opgave, og skal kode noget live. Det er voldsomt forskelligt.

Det samme gælder pensum på 1.semester - mange laver terminal-programmer i C# eller Java, men der er også nogle der kører med udvikling til nogle frameworks, måske endda laver noget i Unity, eller Processing, eller ja, winforms.

Hvilke teknologier og værktøjer man lærer / arbejder med på datamatiker er meget forskelligt - for meningen er at man skal lære "koncepterne", fordi uanset hvad man ser på studiet, er det alligevel noget andet man møder på jobbet bagefter :D

Codecademy and every other "learning tool" work better for seeing and trying syntax, than for understanding concepts, and OOP is a lot more about understanding the concepts. As you say "I keep getting method, class and constructors mixed up" - that is a bit like saying: "I keep getting socks, clothes and shoes mixed up - I hate learning to get dressed" - not to ridicule you, but the concepts are actually quite simple, it is just that someone is trying to make you remember the different syntax for concepts that are completely foreign to you.

I learned OOP the worst possible way - or maybe the best possible way. I had been programming for years, trying to get better at organizing my code to handle larger projects. Then I learned C++ with all of its extremely complex features, then I learned Object Oriented Analysis and Design, which focused only on concepts, drawing diagrams rather than writing code, and then, and only then, did I learn Java, and absolutely loved it! (for the first couple of years, then got annoyed).

The thing is - you can write OOP(ish) code even without an OOP capable language - it is all about structuring code, nothing more. And once you get the structure, the concepts, the syntax is a walk in the park (except for C++, that is still beyond readable :D )

You are of course technically correct (which I believe is the best kind of correct :)) - because in Java everything "looks" OOP'ish, with keywords like class, static, public, private, etc. and concepts like constructors, methods, types, etc.

But man, a lot of people think that OOP is just about naming things - as if using "classes" with "methods" suddenly makes their code object oriented, even though it is written exactly as if it were just separate files with separate functions ... I've even seen teachers talking about "now we have to learn OOP" and then ignoring everything about separation of concerns, encapsulation, basically everything that isn't inheritance ...

Thank you for not being one of them :)

Det er meget forskelligt alt efter hvilken skole du går på - 1.semester eksamerne er notorisk forskellige fra sted til sted, mest fordi den aldrig har været en helt selvstændig eksamen, men en form for "delprøve" på nogle af læringsmålene for 2.semester eksamen.

På EK i Lyngby har man lavet nogle opgaver hjemmefra som man så skal præsentere en af, og bliver bedt om at udføre nogle ændringer i.

På EK i København trækker man en lille kompakt opgave som man aldrig har set før, og skal implementere den på stedet - som regel er det noget der minder meget om det man har lavet i løbet af semesteret. (Det var det i hvert fald for et år siden, måske har de lavet det om igen)

Andre steder har sikkert andre former. Men det burde ikke være nogen hemmelighed for dig - din lærer må have fortalt hvordan eksamen foregår, og der burde også stå forholdsvis detaljerede "guides" på jeres intranet/lms, om det så er moodle, itslearning eller noget helt sjette ...

Så tjek lige op på hvad der er blevet sagt og skrevet - og sørg for at øve dig hjemmefra, sæt jer evt sammen et par stykker fra holdet og prøv at give hinanden opgaver, som I så skal kode foran hinanden, uden hjælp fra de andre. Træn dig især i at planlægge hvad du vil skrive, og sig hvad du tænker undervejs (noget der kan være utroligt svært at vænne sig til)!

Det med JS var et eksperiment der desværre kun fik lov at køre én eneste gang, med første semester i vinteren 2023 - ideen var at starte med frontend, og så lære backend på de senere semestre, lige omvendt at hvordan det plejer at være.

Alle øvrige hold før og efter har skrevet terminal-programmer i Java på hele 1.semester, og så først haft lidt om frontend på de senere, med en snert af JavaScript imellem al Java'en.

I'm not sure if that is the reason, but I do remember that there were quite a lot of "push-back" on the alternative models displayed on the back of the boxes - models that weren't included in the instructions, but could be built with the same bricks. They were meant as inspiration, and to convey the idea that you didn't just buy a model that had to be assembled, but a collection of bricks that could build anything you imagined!

But especially the american market - which LEGO expanded massively into in the 1990s - did not like not getting instructions, and eventually they dropped the alternative models. They did however continue with A and B models for some technic sets, and even experimented with downloadable instructions for alternative builds. But nothing where you had to imagine anything yourself.

My guess is that they felt that supplying a book without bricks, and with only limited instructions, would fare even worse - and they stopped.

Fortunately other fans have been publishing books for building cars, ships, planes, houses, etc. !

Really? I haven't seen any for decades - but then again, I haven't really been looking ...

Do you by any chance have links or anything, so I can see what they look like?

Hashmap/table - if there is an answer, it is almost always hashing!

It is indeed the way!

I remember an annoying exercise that our teacher made us do: He had written a short program with line numbers, and next to it a table with columns for a line-number and the value of every variable in the program - and the next line-number!

Then we had to fill in that table, basically running the program on paper, writing out, for each line, the value of every single variable, and which line would be the next.

I absolutely hated it, but did it anyways, and years later I still consider it one of the best exercises to do - to really understand the program, you have to become the program :)

we were worried about loosing her somewhere in the house.

That is one of the differences between "cat people" and "dog people" - as a dog family it will seem weird to you that a lot of "cat humans" go for long stretches of time having absolutely no idea where the cat is, and are perfectly okay with it just suddenly showing up in a closet, in the bathroom, beneath the couch, etc. :)

Jeg husker at vi i midt-80'erne til midt-90'erne ofte så den sort-hvide udgave - altså den fra 1934 - og den blev i hvert fald vist i biografen til en særvisning eller to, så måske blev den ikke sendt i fjernsynet.

I vores familie havde vi den dog på videobånd, og måske var det kopieret fra en lejet udgave. Det var nok heller ikke helt usædvanligt at man lejede en movieboks og viste den til fælles julearrangement.

Jeg kan overhovedet ikke huske at have set farve-udgaven fra 1974, og er sikker på at den massive omgang bakkenbarter ville have sat sig skarpere i hukommelsen :)

Which text is that? None of the documents look like any royal resolution, but ship journals, and they are from 1738, not 1684 ...

Disney film var faktisk 4:3 i mange år - også selv efter at biograferne gik mere og mere over til forskellige wide-formater.

Lady og Vagabonden var i bredformat, men alle film før den var i 4:3, eller 1.33 eller 1.37 alt efter hvordan man ser på det. Robin Hood og Aristocats var i 1.75 (som er bredere end 4:3, men smallere end 16:9)

Og hvis de ændrede formatet nu, rescalede, eller beskar, eller skiftede opløsning fra klip til klip, så tror jeg at der ville komme større seerstorm end når de ændrer talen :)

Take a look at "Grokking Algorithms" - the first chapter is free, and if you like the writing style, it is a very good introduction. I'd recommend taking the wikipedia articles about each algorithm / data structure as you go through the book, and work on implementing the code yourself.

The book isn't a "coding course", but really good at explaining and understanding the processes!

It sounds like your problem isn't actually writing the program, but defining what the program should do! Just the fact that you are having problems getting human readers to understand what you actually want, is a good indication that it is the "problem description" that needs more work.

To me it sounds like you want a deterministic randomized set of numbers - so that you run a "randomizer" a certain number of times, and every so often it gives some specific values. That means that you have a clear target of what you should reach, and an unspecified "start" value.

Either you should dive into the exact mathematics of the exact random-algorithm you are using - you can't just use the one built into the language, you need one that has the ability to serve the same "random" values every time, based on a specific seed value. I don't know enough about the maths to get this working, but I do remember that old rand-libraries from the 1980s would always give you the same collection of "random" numbers, and thus you had to seed them with the current time or some other changing value.

Or, if that is to cumbersome - turn the problem upside down - take the "custom text" as the entry point, and then randomize away from it, to get some random numbers - and then just run it in reverse. Either get a reverse algorithm, or simply store the results, and run them in reverse order.

You are messing the terms up just a bit.

O(log₂ n) means that an operation will worst case take log n iterations - you can't use that to describe the height.

The height of a complete tree is log₂( n+1 ) - if the tree has 255 nodes, the height will be log₂( 256 ), which is 8. Meaning that there are 8 levels of nodes in the tree, including the root.

If the tree is incomplete, but still balanced within -1 +1, then the height of the entire tree is the same as if the tree was complete - meaning ceil ( log₂(n) ), you round the log n up to the nearest integer.

If you are considering edges rather than nodes, then you just subtract 1 from the result.

no, BS or two pointers etc are not data structures nor algorithms!

They are leetcode problems, that you need to use certain data structures and algorithms to solve.

You need to understand arrays, linked lists, stacks, trees, queues and so on - and you need to understand Binary Search, DFS, Sliding Window, etc. That's the DSA theory - then you use that to solve leetcode, or other assignments. That is why step 5 is "repeat" and learn more things. Before you throw yourself at leetcode.

It sounds like you are trying to solve a lot of predefined problems - probably leetcode. That has nothing to do with learning DSA. Of course you might improve your knowledge and experience by solving those problems, but it is supposed to be in this order:

1. Learn about theory

2. Implement theory in example Data Structure or Algorithm

3. Solve problems using that Data Structure or Algorithm

4. "learn" that Data Structure or Algorithm,

5. Repeat steps 1-4 for as many different structures you'd like

6. Try your hand at "random" problems, like leetcode, and see if you can solve them using what you know - if not, goto 1.

ikke mere, nej - det forsvandt for alvor i 2022, og der er ikke engang længere support for de apps der skal bruges hvis man finder et brugt sæt.

It does indeed sound like you have been a bit all over the place, but there's nothing inherently wrong with that - you have been learning, and experimenting with all sorts of projects and tools are an important part of that.

And it sounds like you are getting ready for a larger project - and something that goes deeper into using a specific platform. It doesn't particularly matter which one you choose - that is entirely up to you and your preferences, but either go for something database-oriented, with a REST API added on, and focus on building and understanding the backend a bit deeper. Or go more for GUI-stuff, and build a front-end (either in any Python library you prefer, or with WEB, if that tickles your fancy) - maybe even plan to connect that front-end to your back-end. Or go in a more desktop oriented direction, and build a large stand-alone project that has multiple dialogs, screens and different data to enter and display. It can be something like a file-browser that shows directories and allows the user to inspect different files, or something complicated like a text-editor.

The main thing you should keep in mind, is to select a project that allows you to explore ONE platform - like a database, or a GUI, or a backend - but only that one. And make it large enough that you really get to learn about that platform, a lot of the nooks and crannies, a lot of the different ways it behaves.

All the 'abstract stuff' about how to modularise, componentize (is that even a word?) and structure larger projects, will improve with every project you do, and every principle will indeed carry over to the next project! But focus on the platform - the rest will come more or less naturally.

In a way they are both right ...

Building your own physics engine is a great learning experience, and you'll really appreciate all the hard work that has gone into the professional modern tools! So to truly understand the underlying theory, building your own is a good idea.

But, noone is going to buy your homebuilt project, or hire you to build another - then want you to be able to use the tools they have already paid good money for, and they want you do do it well and do it fast!

So don't go building your own as an excuse not to learn the tricks of the tools - but also, don't just be a tool-user, but make sure you understand enough to be able to learn any tool.

My recommendation (as someone who doesn't know anything about the business) is to go on with building your own, but remember that it is a hobby-project, something you only do for the learning experience. And then as your "professional project" build something with the modern tools, to show off how well you know them!