"Does C++ Have a Future?"

[Z1202]

Rust uses a Let statement. Makes me feel like I'm back in 7th grade on the TRS-80. Level I.

I have been giving some thought to the problem of designing a language syntax which is 100% backwards compatible to the sources written for an earlier version of that language. The assignment statement seemed to me the biggest challenge.

[syntonica]

Rust uses a Let statement. Makes me feel like I'm back in 7th grade on the TRS-80. Level I.

I have been giving some thought to the problem of designing a language syntax which is 100% backwards compatible to the sources written for an earlier version of that language. The assignment statement seemed to me the biggest challenge.

Fortunately, with the Level II BASIC, the let statement was purely optional. If it couldn't be tokenized, then it was a variable. It was the best thing ever! (For 1977, of course...)

[Z1202]

Rust uses a Let statement. Makes me feel like I'm back in 7th grade on the TRS-80. Level I.

I have been giving some thought to the problem of designing a language syntax which is 100% backwards compatible to the sources written for an earlier version of that language. The assignment statement seemed to me the biggest challenge.

Fortunately, with the Level II BASIC, the let statement was purely optional. If it couldn't be tokenized, then it was a variable. It was the best thing ever! (For 1977, of course...)

So what if the newer version of the language introduces a keyword which coincides with one of your variables?

[syntonica]

The Level I variables were limited to single letters, IIRC. Besides, how much code can you cram into 4k?

If you have to tell the compiler that this is a variable, prefixing const/var/mut etc. is preferable to me. It serves the purpose of let, but it's more informative to the human as well as the compiler.

Basically, I'm just not feelin' the cool retro Let vibe!

[mystran]

Basically, I'm just not feelin' the cool retro Let vibe!

The keyword "let" is found in most functional languages out there. It is usually syntactic sugar over anonymous function application and the purpose really is just to group the variable bindings and their values together (since it's way more readable than having the list of variables at the beginning and the list of values at the end, with a body in between; better compilers will usually produce the same code regardless).

Most likely your TRS-80 basic borrowed the keyword from Lisp.

ps. in Haskell you can also alternatively use "where" which is like "let" but allows you to put the bindings after the body (where are "let" puts them first), to further make the code more natural to read

[syntonica]

Most likely your TRS-80 basic borrowed the keyword from Lisp.

ps. in Haskell you can also alternatively use "where" which is like "let" but allows you to put the bindings after the body (where are "let" puts them first), to further make the code more natural to read

You can't fool me. Haskell is just Lisp for people who wore out their parentheses keys!

I really don't care for syntactic sugar much. Extra typing and it rarely makes the code more readable to me. AppleScript/HyperScript is such a sugary mess, I can't use it at all.

[Z1202]

If you have to tell the compiler that this is a variable, prefixing const/var/mut etc. is preferable to me. It serves the purpose of let, but it's more informative to the human as well as the compiler.

Unfortunately simply declaring a variable whose name coincides with one of the language's keywords is a can of worms, if allowed. I haven't seen a good solution to that problem yet.

[BertKoor]

Most likely your TRS-80 basic borrowed the keyword from Lisp.

Sorry, I don't buy that. Because BASIC is a very imperative language and has not much in common at all with functional languages like LISP.

And so some research confirms this:
http://dobegin.com/let-keyword/
https://softwareengineering.stackexchan ... rst-appear

BASIC as a language (including the later made optional keyword LET) predates the introduction of the LET macro (syntactical sugar, so not even a common keyword) in LISP by nearly a decade.

[mystran]

Most likely your TRS-80 basic borrowed the keyword from Lisp.

Sorry, I don't buy that. Because BASIC is a very imperative language and has not much in common at all with functional languages like LISP.
[...]
BASIC as a language (including the later made optional keyword LET) predates the introduction of the LET macro (syntactical sugar, so not even a common keyword) in LISP by nearly a decade.

I stand corrected then, although I still highly doubt Rust borrowed it from BASIC directly.

[Triplefox]

Bumping this thread because I was actually doing some technology shopping the other day for VST dev. I ended up picking up dplug and got the monosynth example running in about 20 minutes - I have some familiarity with D already. In the past I've only done real-time DSP via audio callbacks in e.g. JS or Actionscript, so the nuts and bolts of VST are all new, but this gives me a smoother path than C++, which I find to be "professional" in the bad way. As in, you'd have to pay me to work with it. And that's not even really a statement about the language itself, in its current state. It's the build system and all the legacy stuff. That's stuff that gets cleared up when working with pretty much anything other than the C/C++ family.

Most language features OTOH, you don't need most of them most of the time. The constructs that are already in every language are the ones that are best to use in anger, and the things you absolutely must have can always be built yourself with the help of some source code generation. But the biggest productivity gains, I find, come from two categories: better errors/debugging/automated checks, and flexibility with respect to dynamic runtime behavior. If the language doesn't have reflection support or automatic memory management, for example, eventually I do end up with a program that has to implement those things on its own, poorly. Conversely, if I start by writing in e.g. Python, I can get off to a great start flinging around weird cobbled-together data structures in exploratory fashion. But the program may eventually get big enough that it doesn't always run every codepath, and then I start wanting to use static typechecking(which, fortunately, is a thing in Python nowadays). So I prefer to have something that supports a gradient of options to properly reflect the maturity of the code.

The core stuff of DSP dev has a relatively straightforward need, though: parse some algebraic expressions, turn them into fast inner loop code. Those bits are always small but dense in terms of lines of code, and they don't directly involve complex resource management problems. You can end up with a lot of resources to track if you expand the scope of the program enough, of course. But it's basically in keeping with the rule: as a codebase gets larger, the "hotspots" get relatively smaller. Most code is run once or never, most of the time.

[aciddose]

You're overlooking 99% of the code of a plug-in.

The DSP "inner-loop" is only 1%.

[camsr]

Things like constexpr in C++ are marked improvements for programmer sanity. Although I think that lacking the ability to use any variables outside of the block scope of a constexpr function is a setback. Appearantly that kind of use becomes a "side-effect" and probably (haven't tested) will cause generation of pointless stores of markedly compile-time datatypes. Happy to be proven wrong on this... My tests in C using data (scoped in global variables and also referencing the stack of the caller function) that is decidedly dead after program optimization still happen to generate instructions that serve no purpose? Turned out to be a syntax mistake, those are very easy to make.