3 ms·

Sure, if you compare via semantics Lua and Javascript make sense to liken. But in terms of complexity, Lua is far more like C. There's no unfucking all the horr

Sure, if you compare via semantics Lua and Javascript make sense to liken. But in terms of complexity, Lua is far more like C. There's no unfucking all the horrible decisions baked into javascript and I wouldn't touch it with a ninety-foot pole, but Lua still has some hope.

90s_dev 1y ago
Every language has warts. Even Lua. Like another commenter said, using . instead of : is maybe the most common mistake, too easy to make. And Lua offers no help preventing or checking it. TypeScript is a great language. So is Lua. So is C. When used carefully to avoid their warts. Learning how to do that for any language takes time and practice though.
- growlNark 1y ago
  > Every language has warts. Yea, and then there's javascript (or typescript if you prefer), the C++ of scripting languages. It's sometimes difficult to see any value through the warts. (Unless you're paid to, of course.)
  - 90s_dev 1y ago
    Every time someone says this about JavaScript, their favorite language turns out to be something like APL or Ada.
    - growlNark 1y ago
      Having a favorite language is weird (to me). They're tools, and some are more effective and usable than others, and some are better suited to some tasks than others. But, equivalently, of course I'm going to criticize a hammer if it's literally covered in warts making it difficult to grasp without slipping. (or, if the gun I'm trying to use keeps firing bullets into my foot when I'm aiming down range.)
SkiFire13 1y ago
To be fair Lua also made some bad decisions, though maybe not as bad as javascript: - tables being used for both objects and arrays can create a lot of confusion, especially when you have some integer keys, but not all, and especially when they are not consecutive or one of them is 0 - indexes start at 1 - assigning nil deinitializes variables/entries instead of assigning the value `nil` (this becomes especially bad if you mistakingly try to use nil as a value in an array/table) - nil and false are falsy, but not 0, which instead is truthy
- growlNark 1y ago
  No disagreement here; I also fundamentally question the cardinal indexing and conflation between table and array. But it's at least internally consistent and certainly makes more sense than mandatorily indexing arrays with floating point.
- ufo 1y ago
  Tables being dual purpose is fine. The real problem is that assigning nil deletes the table field. Unfortunately, fixing that now would cause Python3 levels of breakage.
  - 90s_dev 1y ago
    I've never had an issue with =nil being delete. What problem does it cause?
    - ufo 1y ago
      If you accidentally store nil in an array it creates "holes" inside an array, which breaks the length (#) of the array.
xigoi 1y ago
You’re using C as an example of a language that is easy to understand?
- spookie 1y ago
  C is indeed simple.
  - Rochus 1y ago
    Until you reach the many dark corners of the syntax.
    - DaSHacka 1y ago
      simply don't do that
      - Rochus 1y ago
        Unfortunately it's unavoidable for real-world systems.
  - xigoi 1y ago
    The C standard has about 700 pages.
    - growlNark 1y ago
      Sure, but what are you comparing it against? C is certainly more straightforward to internalize than the semantics of C++, or Python. Many of the corners of C understanding come with inherently abstruse backgrounds: say, accessing fenced memory with an aliased value in-scope, or in getting the particulars of expected memory-layout right for a given ABI. None of this actually impacts most daily development. Hell, the impact of using zero-terminated strings is far greater of an issue than poor-specification of the language is. You have to deal with this problem; POSIX decided to bake it in to its core. Pointer mismanagement is a generally difficult problem, but C decided to actively cook-in hard-to-manage-strings.

90s_dev 1y ago

Every language has warts. Even Lua. Like another commenter said, using . instead of : is maybe the most common mistake, too easy to make. And Lua offers no help preventing or checking it. TypeScript is a great language. So is Lua. So is C. When used carefully to avoid their warts. Learning how to do that for any language takes time and practice though.

growlNark 1y ago
> Every language has warts. Yea, and then there's javascript (or typescript if you prefer), the C++ of scripting languages. It's sometimes difficult to see any value through the warts. (Unless you're paid to, of course.)
- 90s_dev 1y ago
  Every time someone says this about JavaScript, their favorite language turns out to be something like APL or Ada.
  - growlNark 1y ago
    Having a favorite language is weird (to me). They're tools, and some are more effective and usable than others, and some are better suited to some tasks than others. But, equivalently, of course I'm going to criticize a hammer if it's literally covered in warts making it difficult to grasp without slipping. (or, if the gun I'm trying to use keeps firing bullets into my foot when I'm aiming down range.)

SkiFire13 1y ago

To be fair Lua also made some bad decisions, though maybe not as bad as javascript: - tables being used for both objects and arrays can create a lot of confusion, especially when you have some integer keys, but not all, and especially when they are not consecutive or one of them is 0 - indexes start at 1 - assigning nil deinitializes variables/entries instead of assigning the value `nil` (this becomes especially bad if you mistakingly try to use nil as a value in an array/table) - nil and false are falsy, but not 0, which instead is truthy

growlNark 1y ago
No disagreement here; I also fundamentally question the cardinal indexing and conflation between table and array. But it's at least internally consistent and certainly makes more sense than mandatorily indexing arrays with floating point.
ufo 1y ago
Tables being dual purpose is fine. The real problem is that assigning nil deletes the table field. Unfortunately, fixing that now would cause Python3 levels of breakage.
- 90s_dev 1y ago
  I've never had an issue with =nil being delete. What problem does it cause?
  - ufo 1y ago
    If you accidentally store nil in an array it creates "holes" inside an array, which breaks the length (#) of the array.

xigoi 1y ago

You’re using C as an example of a language that is easy to understand?

spookie 1y ago
C is indeed simple.
- Rochus 1y ago
  Until you reach the many dark corners of the syntax.
  - DaSHacka 1y ago
    simply don't do that
    - Rochus 1y ago
      Unfortunately it's unavoidable for real-world systems.
- xigoi 1y ago
  The C standard has about 700 pages.
  - growlNark 1y ago
    Sure, but what are you comparing it against? C is certainly more straightforward to internalize than the semantics of C++, or Python. Many of the corners of C understanding come with inherently abstruse backgrounds: say, accessing fenced memory with an aliased value in-scope, or in getting the particulars of expected memory-layout right for a given ABI. None of this actually impacts most daily development. Hell, the impact of using zero-terminated strings is far greater of an issue than poor-specification of the language is. You have to deal with this problem; POSIX decided to bake it in to its core. Pointer mismanagement is a generally difficult problem, but C decided to actively cook-in hard-to-manage-strings.