Programming thread

[Considered HARMful]

Ima quote papa Dijkstra on this one:

I think of the company advertising "Thought Processors" or the college pretending that learning BASIC suffices or at least helps, whereas the teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery.

 

[Least Concern]

To add something retarded, does learning BASIC in 2021 help with advancing to different languages, or is it simply a dead language at this point. Been trying to bring myself to learn shit on a C64 outside the needed commands.

I suppose in the same way that learning to row a rowboat could help you learn to ride a bicycle. The truth is that the standards for how programming languages work have changed so much since the C64's release and the world has decided that C was a better foundation to build new languages off of than BASIC.

If you want to learn BASIC just for the purpose of playing around on old 8-bits, that's fine, but I wouldn't recommend it as a stepping stone to learning modern languages when you could just start by learning a modern language instead.

 

[Kosher Salt]

Yeah, I wouldn't recommend learning BASIC as an intro to programming. You're too likely to pick up bad habits that result in unmaintainable code because it's just completely missing a bunch of modern concepts that were created to help make code more readable and maintainable.

 

[Full Race Replay]

Hey folks. I'm interested what you all think of Go? I have learned go as well as java and I prefer go a ton. Great online documentation, and that it compiles to a binary instead of having to be run by a java virtual machine or something or other on every computer is a big bonus. What do you think?

 

[stares at error messages]

To add something retarded, does learning BASIC in 2021 help with advancing to different languages, or is it simply a dead language at this point. Been trying to bring myself to learn shit on a C64 outside the needed commands.

Unironically you should consider HolyC. HolyC is much better then C because it uses actual size types, where in C 'int' can be u32 or u16 depending on implementation, in HollyC you can actually state the actual type you want. Ex: U8, I16, U16, I64, U64 ... There is a way to do this in C using inttypes.h. In C types are giving the suffix '_t', which I have never been a fan of using in names. This is done to get around the fact C has no scope name-spacing; label everything super exact because it's going to be global to the program even if it's only included in a few files.

In C you would write:
uint32_t i = 24000;
But in HolyC you would write:
U32 i = 24000;

I realise this might not actually be helpful. TempleOS (and offshoots) and HollyC only work on AMD86 instruction set, so you wouldn't be able to run HollyC on C64 without first porting either a compiler or Temple to C64.

---

By the way, on Rosetta code when you follow a link from the Program Language Pages to the examples. When you're on the example page you can add '#$langname' to url and be taken directly to the language's example. To find $langname, on the Programming Language Page 'Category:$langname' is the value you want.

 

[AmpleApricots]

Eh, Dijkstra' quote is overtly dramatic. It won't ruin your mind to learn BASIC. It won't help you learn modern programming though. The biggest problems with BASIC from a modern standpoint that might make you pick up bad habits is the non-existence of any kind of advanced formatting beyond the mandatory use of line numbers, the difficulty to use functions (subroutines) easily and the very encouraged and liberal use of goto. (although there's nothing inherently even wrong with goto) That all usually leads to basic programs being huge lists of procedural spaghetti code.

The C64 and BASIC are also very limited, to the point that people would resort to choosing short and non-explanatory variable names in order to save memory and there's a lot of gotchas that are problems belonging to that particular machine and time that won't be helpful to know about nowadays, for example poking assembly-optimized parts of the program into memory directly or peeking/poking specific memory addresses that do things. Even back when the C64 still was new it was underpowered for that particular language and for complicated programs like games, Assembler was the way to go, mostly because BASIC was slow and a memory-hog in comparison. So yes, there isn't a lot of point today. If you're interested for historical reasons, go ahead, it won't "corrupt" you. There are other programming languages for the C64 but contemporary compilers of the time are usually too inefficient and often buggy to make them truly useful, suffering from the same problems as BASIC. The only real way to go on the C64 for "complicated" software is assembler. Otherwise, there are other BASIC variants for the C64 (i.E. "Business BASIC") that are a bit more useful and there's also Forth, but this post is already getting too long.

IMO the biggest mind-corrupter of them all is python, much more dangerous in that regard. I'd argue that somebody who can manage (and survive) to write an advanced program on the C64 in Microsoft-dialect BASIC is inherently able to do bigger programming feats as your average copy&paste pythonite, because he has picked up an important skill for any programmer: dealing with hardship and not giving up.

I'd look at C or Go. People are scared of C for some reason but it is in fact not a difficult language to learn, even if maybe difficult to master. The only C book I know is the classic "The C Programming Language" and I think it still holds up, although there might be better ones now.

Hey folks. I'm interested what you all think of Go? I have learned go as well as java and I prefer go a ton. Great online documentation, and that it compiles to a binary instead of having to be run by a java virtual machine or something or other on every computer is a big bonus. What do you think?

I like Go. It feels like a more modern C with comfort options. I haven't really tried to write something big in it though and a lot of frustration I read about Go seems to be about that. The syntax is a bit weird sometimes. I've gotten no real feeling how fast Go actually is to other languages and you find very conflicting reports about that.

 

[Kosher Dill]

Hey folks. I'm interested what you all think of Go?

A language that's approximately "the safe subset of C" seems to be everyone's holy grail, and Go seems like a decent stab at that, but I have no idea if it's the best one. I'm not particularly inclined to voluntarily use a Google-owned language either.

In C you would write:
uint32_t i = 24000;
But in HolyC you would write:
U32 i = 24000;

You could always just write your own set of typedefs to get HolyC type names in C.

 

[Jones McCann]

Hey folks. I'm interested what you all think of Go? I have learned go as well as java and I prefer go a ton. Great online documentation, and that it compiles to a binary instead of having to be run by a java virtual machine or something or other on every computer is a big bonus. What do you think?

I haven't really learned it yet but I've been reading the docs and messing around. The syntax really fucks with me, especially how they seem to change shit just because. Plus it's owned by Google so.. yeah.

 

[Kirisame]

Thanks all. Was more curious than anything to see if BASIC carries over fundamentals or the likes so responses helped in that. Probably will just to get some fun out of the C64 and other 8-bits kicking about.

 

[stares at error messages]

Hey folks. I'm interested what you all think of Go? I have learned go as well as java and I prefer go a ton. Great online documentation, and that it compiles to a binary instead of having to be run by a java virtual machine or something or other on every computer is a big bonus. What do you think?

I'm going to be very critical and unfairly opinionated. Go is for Boomers who still think garbage collection is cool. Go likes to pretend to be faster then a number of other interpreted languages, but that's only because go is an in-lining compiler like Pypy and not a byte-compiler like most other interpreter. So long as you know at least one interpreted language you don't get anything out of switching between different languages and their libraries.

Garbage collection is always a trade-off. After seeing pajeets doing performance retarded things in python, garbage collection can't always save you. With interpreted languages I would argue you need to be more aware of resources and control flow then in compiled (binary) languages, because GCC and LLVM will do much of the thinking for you; but you don't get that when your interpreter keeps your code as dynamic and close to what you wrote originally.

It is claimed that Go is fast because of it's use of green threads. Threads do make things faster. Every modern programming language (if memory serves) except Javascript has threads. Threads don't always help if you are doing things that block on io like reading and writing from disk, which on most systems is not very concurrent. Worse is if you are waiting for packets over the network which can also be seconds of time elapsed. In these cases threads will let your programs twiddle there thumbs faster, but you have to consider the bother of managing the threads. With io you're probably best to use async, which is also something not unique to any one language at this point. Threads will only help with computational tasks which can't always be done in parallel bottlenecked by the algorithm. It's almost comical how Boomers love to talk about Go doing what C should have figured out 50 years ago and C-people are just discovering now.

I think Go is a fad. It doesn't have anything in it you can't get anywhere else. Maybe the syntax is nicer then Java, but it's not always nicer: errors handling is clunky control flow like in C and other languages that came before Go. So it's really down to taste. I'd avoid leaning it because you don't need it for anything. Java is a great multitasker same with Groovy, Python, Ruby, Perl, C#, C++; languages people use because the libraries available they need. For example: you have to use C# for Unity games. Java you need for Android. You also have programs that get extended in Java like OpenOffice and old Minecraft. Groovy is used more places then you might guess: Jenkins Build Server and Gradle (JVM). I predict Go will never find a niche and we'll see it being replaced in more and more places like what happened with discord.

 

[Kosher Dill]

Go is for Boomers who still think garbage collection is cool.

As long as we're forced to hire from "low-cost locations", anything that helps them achieve a consistent level of low mediocrity is cool.

 

[Least Concern]

Gonna agree with everyone about Go, and add one point nobody has mentioned yet: it doesn't support generics. While I don't necessarily think this is a deal-breaker in terms of doing productive things with the language, it is something which will give people coming from other languages where generics are a given (Java, Swift, C#) will have to fight with as they re-learn how to solve certain problems. And I echo a similar instinctive distrust of anything Google stamps their name on. Learn Swift, Java, or some variant of C instead.

Also, to this day, the top of https://golang.org has a banner telling you to give gibs in support of BLM. So that's where their priorities lie apparently.

 

[cecograph]

I'm going to be very critical and unfairly opinionated. Go is for Boomers who still think garbage collection is cool. Go likes to pretend to be faster then a number of other interpreted languages, but that's only because go is an in-lining compiler like Pypy and not a byte-compiler like most other interpreter. So long as you know at least one interpreted language you don't get anything out of switching between different languages and their libraries.

Go isn't just faster than Python because it's AOT compiling. It's also a very static language which means that a lot of Python's book-keeping and runtime can be thrown out: e.g. values don't have to come with runtime type information and functions don't need to dispatch on that information.

Go is a systems language. Python is as far as you can get from a systems language. You can't compare them.

It is claimed that Go is fast because of it's use of green threads. Threads do make things faster. Every modern programming language (if memory serves) except Javascript has threads. Threads don't always help if you are doing things that block on io like reading and writing from disk, which on most systems is not very concurrent.

Being blocked on IO is exactly where green-threads are a benefit. They are an async solution: you have multiple "green threads" running on a single OS level thread, and the runtime switches between the green threads according to what's blocked on IO. Since Go's primary target was server backends, this sort of concurrency was a big sell.

Go does have a reasonably unique solution in this space, where other languages have adopted promises and async/await.

I think Go is a fad. It doesn't have anything in it you can't get anywhere else. Maybe the syntax is nicer then Java, but it's not always nicer: errors handling is clunky control flow like in C and other languages that came before Go.

Go has memory safety, which is something you won't get in C, and which is responsible for absolutely catastrophic security fuck-ups like Heartbleed. A lot of programmers today want to write in really fast systems languages without worrying about memory safety, and for them, C is out. For those who want to stay "close to the metal" Java might also be out. Rust and Go are the current fashionable contenders.

Gonna agree with everyone about Go, and add one point nobody has mentioned yet: it doesn't support generics. While I don't necessarily think this is a deal-breaker in terms of doing productive things with the language, it is something which will give people coming from other languages where generics are a given (Java, Swift, C#) will have to fight with as they re-learn how to solve certain problems.

I believe the commonly accepted solution is "copy-and-paste." This is part of the big deal breaker for me. I won't choose languages designed by people who are 40 years out of date with their basic type theory and are still replaying the billion dollar mistake of having null values.

 

[Full Race Replay]

I think go has the real potential to replace Java for most applications where Java is preferred because there isn’t a need to run in a jvm. As for being owned by google etc. prove to me that a go executable is communicating with google servers when I run it, until then I trust it.

edit: ill stop talking about go because i sound like a shill

 

[Kosher Dill]

As for being owned by google etc. prove to me that a go executable is communicating with google servers when I run it, until then I trust it.

Besides the intangible drawbacks to supporting Google and treating them like a legitimate provider of software, the main issue is what they might do in the future given control of a technology, after everyone's locked in. And yes, you're always free to fork, but "David and Goliath" forking situations rarely end up well for David.

 

[AmpleApricots]

People said a lot of the same things about C# and Microsoft a while ago.

I also distinctively remember a lot of points brought up against C# and why it'll never be useful for anything and especially programming in video games. Way back I was pretty much the only person in my circle who liked C# and didn't hate on it. Kinda fell out and stopped using C# when I moved off to Linux for good as it wasn't really usable there back then.

I'd say most programming languages are actually usable and good enough and I've rarely seen a non-joke language that had serious work invested in it being so terrible that you couldn't do anything complex with it. There's always so much hyperbole around discussing programming languages. When you've watched that stuff for a few decades you start to get more critical of the criticism than of the language itself.

 

[Kosher Dill]

People said a lot of the same things about C# and Microsoft a while ago.

This is true, but even at the height of Microsoft's monopolistic, tyrannical excesses they were downright benevolent compared to Google.
The big difference, I think, is that ultimately Microsoft still depends on having paying customers and business relationships, so there are limits on just how hard they'll screw the user.

 

[stares at error messages]

Also, to this day, the top of https://golang.org has a banner telling you to give gibs in support of BLM. So that's where their priorities lie apparently.

Rob Pike looks like Jim Sterling. Maybe that explains it.

Go is a systems language.

Since Go's primary target was server backends, this sort of concurrency was a big sell.

How is Go a systems programming language if it gets removed from backends for not being preferment enough. I don't believe that anything garbage collected can actually be a systems language. Discord and by now others have ripped out Go backends in favour of that which is not Go. I definitely agree that's how Go was marketed, but in reality is just not a good choice for backend for a number of reasons. Mostly that backends really benefit from async because you can't rely on the state of the clients you're serving. Else you'll end up with a Slow Loris problem. Maybe you can't get around that with stricter timeouts, but that's going to put the GC in higher importance, which is not Go's best attribute.

I've never seen anyone switch from Python to Go, so I don't like that people use that compression. I think it's out of character for the niches, which is why I criticise the claim. I'm trying to say that speed is not Go's saving grace, even-though it's often advertised as such. I think they pick Python to compare because it makes Go look better, not that's it's actually damning for python.

I have seen Go in projects' tools directories and it's used in website frameworks. (maybe you mean webframeworks are backends I don't think of them as that) Both of which are things that Pearl was traditionally used for. So, I think Go might become the new Pearl, but I'd still not use it. I think the syntax is gross and the people who make it are dumb.

Besides the intangible drawbacks to supporting Google and treating them like a legitimate provider of software, the main issue is what they might do in the future given control of a technology, after everyone's locked in. And yes, you're always free to fork, but "David and Goliath" forking situations rarely end up well for David.

I'm guessing that Google will eventually give up on Go like they did others. Google has a track record of staring software, trying it, and then closing it when advertisers don't care. I know Go has taken the space of sysops with webframeworks and docker included. After they start hitting the limitations of the language they'll move to something else.

You could always just write your own set of typedefs to get HolyC type names in C.

I'm not going to be very well like for saying this, but I've never liked C. Most languages that came after C have all hand tried to fix things that C did poorly: D, C++, ObectiveC, Cyclone, and the list goes on but those are the ones off the top of my head. So while I and many compilers can write C, I choose not to. While it is factually correct that I can get the types to be labeled how I like them to be, when it comes down to starting to maintain language features, I think I'm better off picking something else. C++ for exapmle is much nicer then C.

 

[awoo]

You have read the bible, yes?

I have read through some chapters of this book kind of carefully. I think the examples they give are outdated in some contexts.

The reality in my view is that C is a language that has some severe design flaws. C strings themselves have probably caused billions of dollars of damage due to the way they are designed and the confusing use of buffers, which are only worsened by the attempt at safe string functions which aren't safe at all.

Fun fact: the C standard actually does not specify a whole lot of things people take for granted. For example an int, which most people assume to be 32 bit, is actually only at least 16 bit, so depending on what machine you target, it could be 16 or 32 or even something else, which is kinda crappy. Same for a char, which is not guaranteed to be 8 bits or a standard byte, but only at least 8 bits, and could be signed OR unsigned, due to some historical reason or something. AFAIK the standard doesn't even enforce using two's complement, for the 0.0001% of machines that don't or something. You will never encounter this in 99.999% of your coding, but it's unsettling that it is this way. In the book, a lot of the exercises are text operations based on the assumption that all text uses ASCII and one character is one byte, where in the land of unicode fuckery is just not true. I know Unicode fuckery is an immense topic where in theory someone could enter ancient Mesopotamian hieroglyphs so I'm not gonna pretend that it's an easy topic. I have not even touched upon pointers. The lack of exceptions makes error handling harder and the hack using setjmp and longjmp makes the code significantly harder to reason about.

I planned on writing a whole blogpost on this on my personal spergery blog but it ended up being so long because I looked through the C standard and found so many confusing points.
I have a friend who is now a Rust autist but I am not so eager to pickup a language. I think I'll try to find a subset of C++ I am comfortable with (because the design philosophy of C++ was to include everything possible under the sun into one massive behemoth of a language) and try to write clean code with that.

Sincerely, an uninformed programmer who mainly writes in little python scripts. Sorry @AmpleApricots. I cannot even keep track of all the weird little C gotchas that exist in the language.

 

[Least Concern]

The reality in my view is that C is a language that has some severe design flaws. C strings themselves have probably caused billions of dollars of damage due to the way they are designed and the confusing use of buffers, which are only worsened by the attempt at safe string functions which aren't safe at all.

Well, remember that C is like, what, 50 years old now? Saying that the way it handles strings is a design flaw is like saying the Model T not having airbags is a major oversight. C was considered a high-level language in its time, but today's must-have concepts like memory safety were purely theoretical back then if they existed at all. And there's still a performance overhead to that stuff, so even if other languages finally overtake it for most systems stuff, I think C will still have a place for cheap embedded hardware and other places where safety can take a back seat to performance because this thing will never be internet-accessible and multi-user anyway.