Author Topic: General Programming Megathread - New OP  (Read 29955 times)

"i can't use metatables, that means they aren't a good thing!"

bro metatables are probably one of the more useful things in lua, and if you can't use them, you're missing out, lol
No, metatables are good, sure, but useless until you actually have good libraries that use them. And that you can use in a simple way (and easily update long-term).

by what you're suggesting, lua shouldn't even exist, due to the fact that if it were like other languages and to implement all of the standard functions you mention, there wouldn't even be a point, since you could just use another language to achieve the same thing.

lua wasn't created as a language on its own, but a framework for people to embed, add features to, customize, and expand.
Why would I bother using Lua and then reimplementing everything from scratch, instead of using a language which has libraries available handling the basics that I can use, so I can focus on implementing the "secret sauce" instead?
Also, the lack of standard library severely limits what libraries can do instead of being a, say, "LÖVE library" instead of a generic "Lua library".

just because it doesn't include everything you can do on your own, doesn't mean it's not "doing it right", it means you're a lazy forget who can't use a language unless it spoonfeeds you.
If that's your definition of lazy, then sure, I'm lazy and proud of it!

They both use C syntax and thus both look very similar. C isn't very cryptic at all, but whatever. I personally despise java. It's slow, it has TERRIBLE I/O, it's incredibly verbose, it has a large amount of overhead, it runs in a loving virtual machine, making the entire thing loving impossible to debug, 99% of the people who claim to be java programmers are as palletable as feces cake, and the usefulness of the language is dropping every single day.

No, metatables are good, sure, but useless until you actually have good libraries that use them. And that you can use in a simple way (and easily update long-term).
this makes no sense, because libraries are usually made with metatables. i have a really good feeling you don't actually understand what they are, and i'm not surprised.

Why would I bother using Lua and then reimplementing everything from scratch, instead of using a language which has libraries available handling the basics that I can use, so I can focus on implementing the "secret sauce" instead?

Also, the lack of standard library severely limits what libraries can do instead of being a, say, "LÖVE library" instead of a generic "Lua library".
because you don't like a language for what it's missing. the fact that it misses elements that are in other languages is just a side-effect to using the language.

i personally favor lua for it's syntax and it's flexibility. it's just a personal preference. i don't like "hanging code" where i can't tell where it's ended off, or if i'm inside of it and i can't tell what position i'm in. and i prefer the use of words over symbols.

and so what if I have to type more than in other languages? i like reading lua, and i like how lua is typed. if i have to type more to be able to read my code better, then so be it.

so i have to reimplement some stuff that i need to use, okay. that can get annoying, but it becomes much less annoying when you have a large and growing community of users who have already implemented it so that people like you can use the implementations.



They both use C syntax and thus both look very similar.
not to me.

C isn't very cryptic at all, but whatever.
it is to me.

I personally despise java. It's slow, it has TERRIBLE I/O, it's incredibly verbose, it has a large amount of overhead, it runs in a loving virtual machine, making the entire thing loving impossible to debug, 99% of the people who claim to be java programmers are as palletable as feces cake, and the usefulness of the language is dropping every single day.
- not that slow, i haven't experienced any speed issues. everything i've needed done has been done in a speed i can't really complain about.
- the virtual machine is good depending on your way of looking at it. sure it might make some things a little slower, but it's easier to distribute your programs for multiple platforms.

- the virtual machine is good depending on your way of looking at it. sure it might make some things a little slower, but it's easier to distribute your programs for multiple platforms.
The speed ratio compared to native-C++ applications on average is 1.1, so there's not much complaining to be done there. Initaliation is very long, though.

Initaliation is very long, though.
a small side effect, but i'm good as long as java suits the purposes of what i'm trying to create. if people can't deal with the long initialization, i'll go back to using love2d, haha.

this makes no sense, because libraries are usually made with metatables. i have a really good feeling you don't actually understand what they are, and i'm not surprised.
As I've stated multiple times now, there is nothing wrong with metatables, but they aren't very useful if you have no good way to invoke the libraries in the first place.

so i have to reimplement some stuff that i need to use, okay. that can get annoying, but it becomes much less annoying when you have a large and growing community of users who have already implemented it so that people like you can use the implementations.
Except for what you claim to be it's big pro, namely that everyone is doing everything their own way, making the whole platform very fragmented and limiting the amount of libraries you can use. Oh, and see the previous response too.

The speed ratio compared to native-C++ applications on average is 1.1, so there's not much complaining to be done there. Initaliation is very long, though.
Or rather, it's slower during the start-up since it's also JITing the code, lightweight java applications can "be ready to use" pretty fast (although it might take a little longer before they're running at full speed).

As I've stated multiple times now, there is nothing wrong with metatables, but they aren't very useful if you have no good way to invoke the libraries in the first place.

Except for what you claim to be it's big pro, namely that everyone is doing everything their own way, making the whole platform very fragmented and limiting the amount of libraries you can use. Oh, and see the previous response too.
"invoking the libraries"??? the functions are already made available for you to use once you require the library (dear god i hope, otherwise the library creator is doing it wrong, either that or some kind of .init() is required). are we talking about libraries on two different spectrums here?

the fact that everyone implements standard functions their own way makes it even better. you can choose whichever method of solving your problem that you want, and there are a wide number of options that suit your preference.

or you could just, you know, not use libraries. as i said, usually most of what you'll need is either in the system that your using lua with, that it's embedded in (examples, love2d, computercraft, roblox), and the rest is easily implemented on your own. just save it somewhere and use it later if you need it again.

at this point, though, there's really no point in prolonging the argument, as we're probably talking about two different things, and repeating ourselves won't change or solve anything.

you hate lua, i like lua. that's alright. now let us use what we please and move on.
« Last Edit: November 09, 2012, 07:26:55 PM by Kingdaro »

"invoking the libraries"??? the functions are already made available for you to use once you require the library (dear god i hope, otherwise the library creator is doing it wrong, either that or some kind of .init() is required). are we talking about libraries on two different spectrums here?
I'm talking about getting the library to the point where you can require() it.

I'm talking about getting the library to the point where you can require() it.
i'm sorry but i legit loving lol'd, i thought it was obvious

1. download the library in the form of a .lua file (sometimes it's a .dll, i think)

2. put the library in the same directory as your main file that gets executed

3. require 'yourfile' (minus .lua/.dll because of how require works)

i'm sorry but i legit loving lol'd, i thought it was obvious

1. download the library in the form of a .lua file (sometimes it's a .dll, i think)

2. put the library in the same directory as your main file that gets executed

3. require 'yourfile' (minus .lua/.dll because of how require works)
This is why I don't take Lua seriously.

This is why I don't take Lua seriously.
i'd hate to continue clogging up the thread, but i'm genuinely curious as to what's bad about this nice, simple system.

also, require is more of a file execution function than anything. it's the same as "run(aluafile)", that's how i've seen it.

i'd hate to continue clogging up the thread, but i'm genuinely curious as to what's bad about this nice, simple system.
  • Tedious
  • Quickly gets ridiculous if libraries have their own dependencies
  • No way to see why something is there.
  • Problematic to update
  • Not cleanly separated from the rest of your source code
To be fair, Python gets some of this wrong too (for example, libraries are stored globally per install, instead of per project). IMO SBT has the best dependency management system I've seen so far (combines Maven's huge amount of libraries with a usable DSL for defining your project metadata).

  • Tedious
  • Quickly gets ridiculous if libraries have their own dependencies
  • No way to see why something is there.
  • Problematic to update
  • Not cleanly separated from the rest of your source code
most of your points aren't lua's fault. it's only tedious if the user hasn't made it easy for the library to be required in one line, rather than having to require multiple files. and sometimes, there are reasons you have multiple files, if you only need part of a library. as for the downloading part of the library, you only need to download it once, and then copy it over when you need to use it again. can still get tedious, but just a small side effect.

and yeah, i've ran into the second problem in the past. i wanted to use a library called "LUBE" and it needed "SECS" in order to run. i didn't know where to get SECS or which version of it i had to have. but again, that's the developer's fault. he could've packaged SECS in the library and LUBE would require it on it's own, however this could lead to problems if the programmer is already using a class system. however that class system might not work with LUBE and replacing it would break the coder's entire project-

my point there is that, it's usually the programmer's fault for making such a broken addon.

and if you want to see why something is in the library, just look in the source. if it's a dll, hopefully there'll be more info about it on it's website. if not, it's not much a problem if you only want to just use the library.

it's not really important to update a library if your project is already using all of it's functions correctly. if there's something broken in the library, or if you want to use a new feature in an update of the library, it's not really required to update all of your instances where the library is used, only where it's needed. i understand what you mean though, can be annoying and it sucks that there's no automatic system for doing so.

i don't know about you, but most normal people put all of their requires at the top of their main lua file, like "import"s and "using"s. the rest of the code is easily readable.

but yeah, the system does have its fallacies, i agree. no system is perfect.

most of your points aren't lua's fault. it's only tedious if the user hasn't made it easy for the library to be required in one line, rather than having to require multiple files. and sometimes, there are reasons you have multiple files, if you only need part of a library. as for the downloading part of the library, you only need to download it once, and then copy it over when you need to use it again. can still get tedious, but just a small side effect.
While it's not Lua's fault per se, it's something that "all" new languages have to face. It's just that most other languages have a relatively mature library (often even in the standard library) that everyone has that takes care of the gory details of this.

and yeah, i've ran into the second problem in the past. i wanted to use a library called "LUBE" and it needed "SECS" in order to run. i didn't know where to get SECS or which version of it i had to have. but again, that's the developer's fault. he could've packaged SECS in the library and LUBE would require it on it's own, however this could lead to problems if the programmer is already using a class system. however that class system might not work with LUBE and replacing it would break the coder's entire project-

my point there is that, it's usually the programmer's fault for making such a broken addon.
Let's say both bar and baz depend on foo, but bar is pretty old so it only needs foo v1 although it still works with foo v2, while baz uses some new shiny feature from foo v2.
If neither bundles it, then you can easily use foo v2, and both will be happy. If they both bundle their minimum versions then a whole new can of worms is opened, which I'm not sure about how Lua handles (for example, in Python you can do something like this without patching the source itself since all code is namespaced to it's file name, does Lua do something like this?). Even if they both namespace their bundled foo, let's say foo was poorly written and depends on some shared state, which both bar and baz depend on to "collaborate", how would this be handled?

i don't know about you, but most normal people put all of their requires at the top of their main lua file, like "import"s and "using"s. the rest of the code is easily readable.

but yeah, the system does have its fallacies, i agree. no system is perfect.
What I mean is that with, say, APT you can basically ask the system "which package put this file here". You can then ask it why the hell that package is installed (aka which packages depend on it). This makes it easier to clean out, say, old dependencies that aren't used any more. IIRC Maven has something like this too.

While it's not Lua's fault per se, it's something that "all" new languages have to face. It's just that most other languages have a relatively mature library (often even in the standard library) that everyone has that takes care of the gory details of this.
that's good for those languages, but lua libraries usually aren't that complicated. i'm used to just downloading (or copying over if it's downloaded) and requiring.

Let's say both bar and baz depend on foo, but bar is pretty old so it only needs foo v1 although it still works with foo v2, while baz uses some new shiny feature from foo v2.
If neither bundles it, then you can easily use foo v2, and both will be happy. If they both bundle their minimum versions then a whole new can of worms is opened, which I'm not sure about how Lua handles (for example, in Python you can do something like this without patching the source itself since all code is namespaced to it's file name, does Lua do something like this?). Even if they both namespace their bundled foo, let's say foo was poorly written and depends on some shared state, which both bar and baz depend on to "collaborate", how would this be handled?
i think once a library is required, it can't be required again by another script. however if one were to require it, the same script in the same program will be able to use the required code, since the code is available to all scripts within the same program once required.

in other words, if i have my main.lua require my libraries (all four files, main, bar, baz, and foo, are in the same directory):
require 'bar'
require 'baz'


and then bar requires foo, and uses a part of foo.
require 'foo'
foo.doSomething()


so then baz tries to require foo, but it's unsuccessful, as foo has already been required. however it's still able to use foo, since it was required by another script.
require 'foo'
foo.doSomethingElse()


What I mean is that with, say, APT you can basically ask the system "which package put this file here". You can then ask it why the hell that package is installed (aka which packages depend on it). This makes it easier to clean out, say, old dependencies that aren't used any more. IIRC Maven has something like this too.
that sounds like the job of an IDE/text editor.