/tech/ - Technology★

>>914642 (OP)

I guess it's perfect for a child. C=64 was amazing!

Doesn't it rot your brain or something

>>914646

You gotta give me a source on that.

>>914650

https://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html

More seriously, BASIC is a very poor language. TI-BASIC was one of my first programming languages. Doing anything complex in it was a pain.

It's possible that the lack of complexity made it very slightly easier to learn for absolute beginners, but languages like Python are easy enough and aren't dead ends.

I have fond memories of writing BASIC but I think that's more because of the context I was writing it in than because of the language itself.

If you're not a complete beginner and you don't have prior nostalgic experience with BASIC or historic interest or whatever you won't get anything out of it.

No. Good high level languages exist on almost every platform that once relied on a basic ROM for non asm programming, and they are widespread thanks to the internet.

>>914652

My intro to programming was teaching myself TI-BASIC while bored in class. The simplicity made it easy to learn and was my gateway into programing.

>>914652

Well, I am an absolute beginner. Should I still learn BASIC or should I just learn Python?

>>914667

BASIC, if you want to go oldschool or you have a C64 laying around. Otherwise, Python is a good starting point.

>>914667

Python. It'll let you do useful things and it won't force you to write in a bad style.

>>914684

>>914684

>it won't force you to write in a bad style

Oh yes it does. It literally won't run the script unless it's formatted in its retarded way.

>>914697

Even if you dislike Python's formatting it's still peanuts compared to what BASIC makes you do.

>>914701

"Peanuts" is a pretty bad analogy for ease. They are annoying to crack open and make a mess.

>>914704

I mean that it's insignificant. Unimportant.

You're comparing BASIC to Python, and the best thing you can think of is "Python forces you to make your code readable"? Come on now. There are dialects of BASIC without support for functions, and that's what you think is worth mentioning?

C is the only way to start. I'm already seeing the ravages in rigor that starting with something as high level as Python produce in my university.

>>914713

Why would C be the only way? It may have more rigor than Python, but C is very flawed.

I haven't used it as much as C, but Go seems like it would be a lot more rigorous than C without losing the things that make C rigorous. Or if that's too newfangled, Pascal is explicitly a teaching language, isn't it? How about that one?

Calling C better than Python is one thing, but what could possibly lead you to believe it's the only rigorous option?

>>914679

One could even write an OS in FreeBasic, if one were so inclined.

https://wiki.osdev.org/FreeBasic_Bare_Bones

>>914642 (OP)

It was never worth learning. It's just an entry language that you'd work on for a few weeks as a child to get you into programming.

>>914667

If you're 13+ then don't even bother with basic.

>>914642 (OP)

>still

lol

Nah. The only real use for BASIC is writing Excel macros, so if that's your thing, it's nice. But if that's your job you could just probably develop full fledged extensions in C# which is vastly superior.

The language itself was shit when it came out, but it aged even worse. It's unusable today even if you wanted to.

>>914701

I really don't get how BASIC is supposed to be a "simple language for beginners". I've used probably 10 languages over the years, including C, and I still can't wrap my head around BASIC's asinine syntax whenever I try. It's just so ugly and illogical I get a headache. Honestly even C would be much easier to learn than BASIC. But see for instance PASCAL, a very nice "learning language" that actually abstracts away the language features that are confusing until you understand how computers work. Why couldn't BASIC be like PASCAL? Wtf was Bill thinking?

>>914718

>C

>rigorous

What are you talking about anon?

>>914763

>I really don't get how BASIC is supposed to be a "simple language for beginners". I've used probably 10 languages over the years, including C, and I still can't wrap my head around BASIC's asinine syntax whenever I try. It's just so ugly and illogical

It's just linear programming with no defined functions. There's nothing to get, it's pretty much a high-level assembly language. Or maybe a batch processing language like Windows .bat files.

Unless you're talking about modern object-oriented implementations of BASIC because that shit is cancer

>>914769

If your workflow consista of the terminal, then you might find this useful:

http://www.moria.de/~michael/bas/

Apparently you can program PIC microcontrollers in some MicroBASIC dialect. Probably makes more sense there than on modern computer, where the nanny OS limits what you can do.

https://www.amazon.co.uk/Programming-Microcontroller-MBASIC-Embedded-Technology-ebook/dp/B005HITT8O

Daily reminder that even knowing about BASIC will greatly limit your ability as a programmer.

>>914802

Apparently even Commodore BASIC v2 had GOSUB

>>914642 (OP)

No. That said, the other day I was watching a YouTube video and I wanted to try something in the video, so I wrote a 15 line QBasic program.

SCREEN 12
WINDOW (-2!, 2!)-(2!, -2!)
TAU! = 3.14159265358979# * 2
REM z! = ((1 + SQR(5)) / 2 - 1)
REM z! = (2! / TAU!)
REM z! = 1 / SQR(2!)
FOR z! = 0! TO 1! STEP .01
   FOR x% = 0 TO 299
      px! = (.01 + x% / 200!) * COS(z! * TAU! * x%)
      py! = (.01 + x% / 200!) * SIN(z! * TAU! * x%)
      CIRCLE (px, py), .01, 1
   NEXT x%
   LINE (-2!, 2!)-(2!, -2!), 0, BF
NEXT z!

>>914642 (OP)

Old school BASIC? Probably not unless you are going to make something for a Speccy for fun. FreeBASIC is fine in a modern context, though...although from a financial standpoint you'll still be best off with C and its extended family.

>>914851

It's too bad Microsoft got rid of QBASIC because it was a really nice and handy tool. I guess they figured everyone would just jump onto GUI shit.

Also: http://www.petesqbsite.com/index.php

>>914667

As an absolute beginner you should learn C. Not C++, this is a very important distinction there. Once you get how C works and how to get things done with it, it will be very easy to learn other languages.

>>914718

Pascal is SEVERELY underrated. FreePascal is pretty dead ATM (no feature parity with Delphi), but it can do many things, much better and simpler than many more modern programming language.

>>915018

>Pascal is SEVERELY underrated. FreePascal is pretty dead ATM (no feature parity with Delphi), but it can do many things

I don't think Pascal is still a thing in the past, but a friend was a huge fan of it, and I was persuaded that the language has a lot potential. Definitely worth to try!

>>914713

>>914763

>>914994

>>914998

Is C worth learning from a hobbyist perspective? I want mostly want to do programming as a side activity that I may get serious with if I'm dedicated enough.

If you need to ask, you're fucking retarded.

>>914642 (OP)

>Is BASIC still worth learning?

Technically yes, but whoever is subject to this idea will question that decision if they learn about the other, better languages.

I think assembler is more fun than basic, anyway.

>>914704

>They are annoying to crack open and make a mess

The python duck typing system is a giant mess that is impossible to crack.

>>915069

Rude

>>914697

Hello again StephenLynx. This retarded argument again?

>>915062

No. Learn C. From K&R.

Learn a BASIC language too - it will take all of 30 minutes.

Python for beginners is not good. They must figure out which pre-packaged system to use and immediately have 1 million choices to make and opportunities to explore, and are immediately overwhelmed. Also, Python is cancer. Learn C and you will learn how a computer operates. Learn Python and you will learn the intricacies of other people's libraries and not much else.

>>914998

>>915058

>>915062

>>915083

C should be the language you learn after you already know Lisp, Ada, PL/I, Fortran, BASIC, and a lot of other languages, so you know why C sucks. Programming languages have an influence on how you think and have cultures even though some of these cultures are no longer around. Reading the original papers and code, like I do with Multics and Lisp machines, give you a better idea of why they did these things. It's usually not bullshit like "to not confuse dumb C programmers" like the UNIX weenie excuse for why some part of JavaScript or PHP sucks.

And I hacked the renderer code to throw cpp the proper
"-DFRAME=%05d" to spit out numbers the way I wanted
them. Why did I want the leading zeros? I don't know, I just
thought it was cleaner.

So I fired up the animation and let it run for a while
(days).

Well, the output was quite amusing (or at least it would
have been if I didn't need the results for my thesis defense
a week later). The object would go down for a few frames,
then jump up and go down a little, then go back to where it
maybe should have been, then jump up....

After a little headscratching, I realized that the leading
zeros in my frame numbers were causing cpp to treat them as
octal values. How precious.

But still, if I say "#define FRAME 00009" then "#if
FRAME==00009" should still fire (or it should at least whine
at me). Well, 00009==00009 does trigger, but so does
00009==00011.

Huh? 

Well, some C library thinks that the nine in 00009 isn't
octal, so it interprets it as 9 decimal. And 00011 is a fine
octal rep of 9 decimal.  So, both "#if FRAME==00009" and
"#if FRAME==00011" fired and I applied two translate calls
to my object geometry. And(!), it's not that having a
decimal digit makes the whole number decimal. The string
00019 gets interpreted as 00010 octal plus 9 decimal = 17
decimal.  Lovely, not.

I feel compelled to submit the following piece of C code:

  switch (x)
    default:
      if (prime(x))
        case 2: case 3: case 5: case 7:
	  process_prime(x);
      else
        case 4: case 6: case 8: case 9: case 10:
	  process_composite(x);

This can be found in Harbison and Steele's "C: A Reference
Manual" (page 216 in the second edition).  They then remark:

  This is, frankly, the most bizarre switch statement we
  have ever seen that still has pretenses to being
  purposeful.

In every other programming language the notion of a case
dispatch is supported through some rigidly authoritarian
construct whose syntax and semantics can be grasped by the
most primitive programming chimpanzee.  But in C this highly
structured notion becomes a thing of sharp edges and lose
screws, sort of the programming language equivalent of a
closet full of tangled wire hangers.

>>915078

Do you think you ingratiate yourself to anyone by pointing out the obvious?

>>915187

>C sucks

Objectively wrong

>>915214

C is undeniably inexcusably flawed. Just look at this, for example:

https://archive.is/glSDh (http://www.tedunangst.com/flak/post/to-errno-or-to-error)

There are many reasons to keep using it, but calling it good is suspect, and I get confused when people hold it up as the ultimate programming language.

>>915216

>I get confused when people hold it up as the ultimate programming language.

People call it that because it is, especially if you count in it's bigger brother C++.

>>915216

>C is undeniably inexcusably flawed.

C sucked in the 1970s, sucked in 1992, and it still has the same serious problems today that will never be fixed. You have to use a different language if you want the solutions.

>https://archive.is/glSDh (http://www.tedunangst.com/flak/post/to-errno-or-to-error)

Error handling was done right in the 60s, so there's no excuse for C sucking this much.

>There are many reasons to keep using it,

Not using C is always the better option. It's too hard to use different languages with C because C is intentionally incompatible. Compatibility means parts of programs written in different languages work together without needing a "foreign" language in the middle, like on Multics and the Lisp machines. If Python and Ruby were compatible, you could pass a Ruby string to a Python function and return a Python array/list that is used from Ruby, because they share the same data types and GC.

>and I get confused when people hold it up as the ultimate programming language.

C is the ultimate in suck because decades old languages didn't have those flaws. The growing popularity of C caused new languages to become worse, like JavaScript, PHP, and Perl. These flaws are crucial to C's existence and all the UNIX languages that copied them, so pointing out mistakes in C makes them look bad too. That's why you have to go outside of UNIX culture to see why they suck.

There are times when I feel that clocks are running faster
but the calendar is running backwards.  My first serious
programming was done in Burroughs B6700 Extended Algol.  I
got used to the idea that if the hardware can't give you the
right answer, it complains, and your ON OVERFLOW statement
has a chance to do something else.  That saved my bacon more
than once.

When I met C, it was obviously pathetic compared with the
_real_ languages I'd used, but heck, it ran on a 16-bit
machine, and it was better than 'as'.  When the VAX came
out, I was very pleased: "the interrupt on integer overflow
bit is _just_ what I want".  Then I was very disappointed:
"the wretched C system _has_ a signal for integer overflow
but makes sure it never happens even when it ought to".

It would be a good thing if hardware designers would
remember that the ANSI C standard provides _two_ forms of
"integer" arithmetic: 'unsigned' arithmetic which must wrap
around, and 'signed' arithmetic which MAY TRAP (or wrap, or
make demons fly out of your nose).  "Portable C
programmers", know that they CANNOT rely on integer
arithmetic _not_ trapping, and they know (if they have done
their homework) that there are commercially significant
machines where C integer overflow _is_ trapped, so they
would rather the Alpha trapped so that they could use the
Alpha as a porting base.

   Date: Thu, 8 Oct 92 08:26:17 -0400

   Of course Lint is useless.  It's one of those programs
   that was written as a student project N^2 years ago and
   has never been debugged or brought up to date.

I was unaware that proscriptions against free()ing pointers
you had never malloc()ed and referencing uninitialized
variables were a recent development, but isn't it great that
we have (void) so that lint doesn't complain when I don't
check the return status from printf()?  Even BASIC has
on-error-goto - too bad Kerninghan and Ritchie couldn't be
bothered to put an error handler hook into the language.

By the way, that free() didn't crash the program.  Unix
memory allocation routines are so nice and trusting - they
just prepend a couple of bytes to your pointer and then add
it to the free list, regardless of where the pointer points
- if you own the memory, you just freed it
(congratulations).  The real fun starts when you do your
next malloc and get a segmentation violation.  In my case, I
was left scratching my head and wondering why 6 calls deep
into getpwnam(3) (a supposedly stable library call, but hey,
this is Unix - there are no guarantees), my program suddenly
segfaulted without the slightest indication why.  Pfft.

   Try giving LINT ANSI-C and see what it does.

Isn't it nice that all the different implementations of
ANSI-C are *less* compatible with each other than PCC-based
compilers?  Standards are soooooo wonderful.

   Try giving the Sun compiler ANSI-C, for that matter.  

With the advent of Solaris, Sun will address that problem by
not giving you a C compiler.

>>914642 (OP)

Yes, but no nu-Basics. If you're not typing in line numbers you're a fag.

>>914775

>a subroutine isn't conceptually the same as a function

gosub your mom's a whore

>>915058

From a hobbyist perspective...depends on what you want to get out of the hobby. I mean you can do a lot with FreeBASIC, including interfacing with C if you so choose in the future, so for little spot things its fine for me. Really though if you are just tinkering rather than producing serious software, just find a language you can get your head around and stick with it.

>>914650

It invites spaghetti code, can't be compiled to binary and generally doesn't even use indenting.

>>915187

>>915083

So if not Python and not C then what would a good first language be? Lisp?

>>915410

You're not going to find something that anyone here recommends but nobody here violently disagrees with.

Python is considered a good option even outside this contrarian hellhole. Just go with that.

You were already given your answer. Python. You troll.

>>915410

Learn python. It's not perfect but by the time you actually care you'll be inherently more capable at learning other languages and in the meantime you'll be learning something you can actually use along with other people. Lisp is an intellectual toy, nothing more.

>>915410

Old school BASIC and immediately thereafter assembly language, on an 8-bit CPU. Avoid Unix and other environment with nanny OS and lots of abstractions.

>>915410

Python and C are fine languages, don't get trolled by memers. So are C++, Java, JavaScript, C#, Rust, Go, and virtually any language with a sizable user base. They're all very easy to get started with. In fact you could try learning a bit of each one and go with the one that seems most enjoyable. They're not necessarily great languages, but by the time you're proficient enough in them you'll be able to judge languages on your own. I'd avoid functional langs like Lisp or Haskell because the tutorials will be confusing and boring at first if you have no programming experience (but as a second or third language definitely worth a try).

Most programming skill translates well, once you learn one decent modern language you're 2/3rds of the way there to learning others. Just don't learn ancient caveman shit like basic or perl.

>>914802

Wasn't Elite made in BBC Basic?

>>915410

C is a good starting option because 1) it's very simple, 2) it's very straightforward, and 3) it gives you important basics knowledge. Python is immensely more complicated language and is harder to learn, plus it has ass backwards syntax-formatting abomination, so you better avoid it until you're comfortable with the standard syntax.

>>915876

>>915883

>faku

No, you fags. This is from Great Teacher Onizuka (GTO) from the scene where he (the BASIC airhead) wants to become a programmer, buys books for BASIC and then gets an interview for a job.

If you haven't watched it, do that now.

NOW

>>916037

>GTO

I watched all 43 episodes and that scene never happened. Its actually from OVA called "Golden Boy".

>>916044

Fuck I watched that too and mixed it up. Well whatever. Watch it.

>>916044

rewatching it now since I totally forgort about it

>>915732

>JavaScript

>Good

Fuck off with your botnet shit, kike.

>>916163

I was confused. The first 3D model that would later become the spaceship design was made in BASIC, then the game was written in assembly.

At least according to an old BBC documentary about Elite.

>>916216

>There's also an EMACS version:

Of fucking course there is.

But that looks like an interesting link. I've always liked those text-based games, ever since I got into text adventures a few years back.

>>916092

HolyC is all right. Does Terry ever give reason as to why he didn't write a fully compliant ANSI C compiler instead?

>>916257

What does he mean he doesn't want "to port the entire volume of C onto his machine"? When he says remove lines of code, is he talking HolyC code or actual instructions in assembly?

>>915842

>C is a good starting option because 1) it's very simple, 2) it's very straightforward, and 3) it gives you important basics knowledge.

C hardly does anything, so it should be simple and straightforward, but it's very complicated because of all the bullshit. C strings and arrays suck and have non-straightforward semantics, like &a and a both being memory addresses, but with different types. In other languages, a is the array variable itself and taking the address (if the language allows it) gives you a pointer to the whole array. In C, a "decays" to &a[0] unless it's used in sizeof and some other corner cases. C is also missing a standard error handling mechanism, good memory management, real strings, overflow checks, arrays that can actually be passed to another function, and other things that are not complicated but C weenies say are complicated because they don't want to learn anything new, or old in this case, since that was all around before C existed.

> There's nothing wrong with C as it was originally 
> designed,
> ...

bullshite.

Since when is it acceptable for a language to incorporate
two entirely diverse concepts such as setf and cadr into the
same operator (=), the sole semantic distinction being that
if you mean cadr and not setf, you have to bracket your
variable with the characters that are used to represent
swearing in cartoons?  Or do you have to do that if you mean
setf, not cadr?  Sigh.

Wouldn't hurt to have an error handling hook, real memory
allocation (and garbage collection) routines, real data
types with machine independent sizes (and string data types
that don't barf if you have a NUL in them), reasonable
equality testing for all types of variables without having
to call some heinous library routine like strncmp,
and... and... and...  Sheesh.

I've always loved the "elevator controller" paradigm,
because C is well suited to programming embedded controllers
and not much else.  Not that I'd knowingly risk my life in
an elevator that was controlled by a program written in C,
mind you...

It hasn't been worth learning since the 80s ended.

I know everyone hates it, but I think it's a great language for what it is. It's good for beginners because of how simple and direct it is. It's kind of shit unto itself, but it serves as a good starting point

>>916333

>like &a and a both being memory addresses

No, the former is an address the latter is a pointer. I can see why a brainlet like you might get confused.

>In C, a "decays" to &a[0]

I assume you are talking about when you want to pass an array as an argument to a function? There is no decay you can still access a[i], there is just no way for the function to know what the end of array is without the programmer telling it. If you are talking about multi-dimension arrays then it still doesn't decay the function just sees it as a 1D array. You can still access every element you just have to adjust your index accordingly. If you are using nD arrays I assume you have the mathematical background necessary for this to be nothing more then a minor inconvenience.

>Giant block of unsourced text

You need to stop.

BASIC is a good toy for children.

>>916333

>C hardly does anything

HAHAHA! What a literal faggot!

well it is the foundation which Microsoft was built on

you can figure out how Microsoft built its empire by trying to understand what they were going for

>>916382

>>like &a and a both being memory addresses

>No, the former is an address the latter is a pointer. I can see why a brainlet like you might get confused.

An array variable like a in char a[10] is a pointer? That's not how I understand it, but maybe the next C draft made arrays even worse. In a sane language, it's an array, an object that contains 10 characters, and taking its address gives you a pointer to the whole array.

>I assume you are talking about when you want to pass an array as an argument to a function? There is no decay you can still access a[i], there is just no way for the function to know what the end of array is without the programmer telling it.

Of course there's decay. It's not an array anymore or even a pointer to an array, just a pointer to a single element, which you can access like an array because of a hack. The type is different, not that the average C weenie, or even an above average one, knows anything about the bullshit that is C types. In C there's brain-dead bullshit where a[i] actually means *(a + i), so you're actually doing *(a + i) even when a is declared in the same function.

>If you are talking about multi-dimension arrays then it still doesn't decay the function just sees it as a 1D array. You can still access every element you just have to adjust your index accordingly. If you are using nD arrays I assume you have the mathematical background necessary for this to be nothing more then a minor inconvenience.

C multi-dimensional arrays are broken. Having to reinvent wheels and remake important programming concepts from scratch because the language doesn't do it properly is a huge inconvenience, and it sucks even more because you can't pass a multi-dimensional array to another function without a bunch of bullshit. If C did arrays properly, the language would be smaller, have fewer corner cases, and not suck as much.

>>916386

>>C hardly does anything

>HAHAHA! What a literal faggot!

No, that's exactly right. Languages like Lisp, PL/I, Ada, and even the smallest versions of BASIC do much more than C does, but are much simpler in the areas that C has in common. This causes C programs to be more bloated, including machine code size, than programs in other languages. That's not the only thing that makes a language good, but considering how little C does compared to BASIC, let alone Lisp, the language has no reason to be so bloated and complex. C is complex because it's badly designed, not because has a lot of features. It doesn't even have a way to handle integer overflow or properly pass an array to a function.

There are many reasons why GNU Emacs is as big as it is
while its original ITS counterpart was much smaller:

- C is a horrible language in which to implement such things
as a Lisp interpreter and an interactive program.  In
particular any program that wants to be careful not to crash
(and dump core) in the presence of errors has to become
bloated because it has to check everywhere.  A reasonable
condition system would reduce the size of the code.

- Unix is a horrible operating system for which to write an
Emacs-like editor because it does not provide adequate
support for anything except trivial "Hello world" programs.
In particular, there is no standard good way (or even any in
many variants) to control your virtual memory sharing
properties.

- Unix presents such a poor interaction environment to users
(the various shells are pitiful) that GNU Emacs has had to
import a lot of the functionality that a minimally adequate
"shell" would provide.  Many programmers at TLA never
directly interact with the shell, GNU Emacs IS their shell,
because it is the only adequate choice, and isolates them
from the various Unix (and even OS) variants.

Don't complain about TLA programs vs. Unix.  The typical
workstation Unix requires 3 - 6 Mb just for the kernel, and
provides less functionality (at the OS level) than the OSs
of yesteryear.  It is not surprising that programs that ran
on adequate amounts of memory under those OSs have to
reimplement some of the functionality that Unix has never
provided.

>>914713

I've already seen 10 years of degenerates who think they're low level or sound because they use C.

>>915187

Hey UnixHaterAnon, I have a question: Could Lisp machines do real-time DSP in their time?

I ask that because C/C++ and Fortran are the only high-level languages people use to do that, mainly because they aren't garbage collected, and all Lisp implementations I've heard of rely on a GC.

I would love to see a programmable guitar pedal with a Lisp interpreter/JIT compiler embed in it, but no one has done it yet because it doesn't seem to be a language suitable for that purpose, and I'm glad that C/C++ compilers allow us to mess with audio and video shit with their blast processing capabilities, so I'm not really sold on your UNIX hating tbh m8.

>>916924

>That's a really good question. You see, C is full of bloat, and LISP isn't. LISP works on lists, something that C is completely lacking. This is why LISP machines are the best and the UNIX-philosophy is wrong.

Is something that annoying loser would say.

>>916910

Just because the file is one line does not mean that the program is one line. There are statement separators (:) everywhere.

>>916924

> C/C++ and Fortran are the only high-level languages people use to do that

What is Forth?

For a DSP, C/C++ and Fortran are just high-level assembly. In fact, they probably aren't using these languages at all, but rather a limited subset that looks like them, superficially. So, we can defined an "Embedded LISP", that probably doesn't have eval, so it could be aggressively compiled into code for an embedded processor (aggressive here meaning that it is compiled so as to have static memory allocation). No one has done this.

>>916930

>In fact, they probably aren't using these languages at all, but rather a limited subset that looks like them, superficially

What did you mean by this?

Seriously, take https://github.com/VCVRack/Rack or https://github.com/topisani/OTTO for example, it is all pure modern C++.

Of course they don't use every single feature of the language, but doing that in C++ would be pure foolishness, since the whole point of it is to have a bunch of "zero-cost abstractions" at your disposal with a(n almost) seamless integration with C.

That said, yeah, I forgot about Forth and a Lisp dialect for DSP could probably be fine, even though I doubt that linked lists would be the right kind of data structure for that domain.

>>916930

It's literally all on line 1 tho. Sure, he could have named it 1-screen game instead but what kind of lame ass game would only fit in one statement? This one's actually playable.

>>916936

> https://github.com/VCVRack/Rack

< pure modern C++

> struct GridChoice : LedDisplayChoice

> struct MidiMessage

> struct MidiIO {

> https://github.com/topisani/OTTO

< DSP is written seperately in faust, a functional language designed for audio processing that compiles to C++

When I read DSP, I thought that you meant the class of processor, not the application. As for that, normal LISP can run digital signal processing code fine. A decently optimizing LISP interpreter is probably not going to invoke the GC for any code not written by a complete idiot. For this case, I would say that lousy developers write in C++ because the lack of a garbage collection run hides how shitty their code is.

>>916936

> I doubt that linked lists would be the right kind of data structure for that domain

And another thing: this doesn't really matter. A good compiler is going to produce the best output code, which doesn't necessarily match the internal representation of the language. C/C++ wienies like to believe that they are programming "close to the metal", when, in reality, their compiler is going to convert their code into a functional-like IR, because most code optimizations have been investigated in functional languages, before mangling it even more, ignoring half of the things that they told the compiler to do, and producing a result that has the semantics of their program (as coded). A good LISP compiler will do the same, though LISP has had fewer people doing that work. LISP would be faster than C/C++ if it has half as many people working to optimize it as GCC and Oracle's Java do.

>>916950

I am tired of hearing your LITHP.

Is smalltalk/squeak still worth learning?

>>915830

>Elite

That rocked Assembly with it's balls out. Those Cambridge mathematicians did some crazy sh*t to fit that 1000 planetary system + trading platform + 3D wireframe space flight simulator, and classical music score into a measly 64kb.

https://en.wikipedia.org/wiki/Elite_(video_game)#Development

Unlike today's StarCult the game actually delivered.

I've been getting sort of decent at Perl.

Is Ada a meme?

>>914646

>>915379

>rots your brain

>invites spaghetti code

Just don't use GOTO you pussies

>>915187

>so you know why C sucks.

I will beat your faggot ass into oblivion

>>926749

Yeah who wouldn't want to use a glorified PDP-11 assembler in current year?

>>914642 (OP)

No.

If you want to teach children, please use Python or JS.

>>926934

Unless they're really stupid, you can teach them Pascal. Those languages hide far too much from the programmer.

>>926936

I don't care. Teaching programming logic is a far more important foundation than teaching computer accounting. Computer accounting comes later.

>>926934

Just teach the kids to divide and conquer.

>>926934

Do the opposite of this at all costs. Control flow is at most an hour worth of learning in any language and requires knowledge of the dreaded GOTO (which also describes important hardware interactions).

Nobody should necessarily USE BASIC but they could definitely learn from it. Shit dynamic interpreted langs are for getting things done with minimal knowledge.

>>914642 (OP)

> Is x computer language worth learning

always

except for Rust

basic's just a halfassed shim over ASM anyway

>>926934

You mean scheme.

>>926990

Let me add to that, the BAISC used was GFA BASIC[1] and:

>the C compilerS were dreadful and a completele waste of time

No, Atari ST's C compiler was terrible[1a], you're really trying to put everything wrong on IT world to C aren't you? I think your forgot your Linux Haters Handbook quote from the 80's and to praise Lisp Machines

[1]http://www.anotherworld.fr/anotherworld_uk/page_realisation.htm

[1a]With the arrival of the 16 bit machines, the C language became more popular in the video game industry, it had many advantages compared to Assembler (portability, structuring and ease of comprehension). Three years before becoming a graphic designer for some time, I tried it on Atari ST with no success. The compiler was shaky, the smallest mistake of programming would result in the machine crashing and the compiling times were exasperating.

It's funny how quickly the world has forgotten the horror of coding in Visual Basic. It was fucking huge on Windows in the '90s and now people act like that never happened. The same history revision happened with Pascal on DOS which we used to use heavily, and TCL on UNIX. Eternal September hit hard.

>>927791

No, I never used Lisp, you must be thinking of someone else. That said, I don't see the advantage of C when his game was ported to lots of platforms anyway. And most action games on Amiga were made in assembly language, probably because C wasn't good enough.

>>927817

>No, I never used Lisp, you must be thinking of someone else.

Well, my apologies then. There are some people here in /tech/ beyond being a pain in the ass regarding programming languages.

>>927807

It's pretty great that BASIC is mostly outliving VB, but VB is still hiding there in windows. There's some hardcoded VB scripts in windows components and awful excel people still sometimes use it.

>>916950

>LISP compiler

Tell me, do any of these "compilers" omit the several megabytes of emulatorinterpreterruntimeboilerplate in even the simplest one-liner program that made LISP useless for early microcomputers? Do any of them output native instructions rather than scriptbytecode? Do any allow you to fully disable automatic garbage collection like Oberon/Ada/Rust/etc.? Inb4 muh LISP machines, just like Java machines sich as Sun's MAJC or ARM's PicoJava extensions, that merely accelerated GC, but didn't eliminate rhe inherently flawed "stop the world" design of such scripting languages.