I wrote bigger programs than those in MaxScript for 3D Studio Max :-)
As for Pascal, well that was just an example, there are many others out
there.Liberty Basic, Free Basic, Scala, Clojure, Steel Bank Common Lisp,
SmallTalk, Erlang…….need I go on?
Pick your poison:
[https://github.com/Guevara-chan?utf8=%E2%9C%93=repositories===purebasic](https://github.com/Guevara-chan?utf8=%E2%9C%93=repositories===purebasic)
Some of those projects are small and extremely simple ( _MetaMorpher_ ,
_PolyDice_ ), some counts thousands of code lines (
> Typing nimble install blah is not hard. Those libraries can be as
> multiplatform as the stdlib.
In my opinion the main advantage of having a GUI toolkit in the standard
library isn't that it's easy to install (although that's a big plus), but that
there is a _default_.
> Python's "standard
> > Is having a "std" GUI / drawing / clipboard / etc lib really so important
> > when there are non-"std" candidates in nimble?
>
> Yes, quite a lot. Std GUI lib means that you can and will be able to make ui
> using same code for every compatible platform and 90% extensions (like custom
>
PureBasic lacks many features (some of which I have mentioned here) that
considering how long its been going should be included, it maybe okay for small
apps but how many big applications have been produced with it? It kinda reminds
me of a AutoIt but with a GUI designer...but unlike AutoIt and
Well your list lacks:
[https://www.lazarus-ide.org](https://www.lazarus-ide.org)/
> Cost of implementing such std GUI / drawing / clipboard is not smaller than
> third-party one, isn't it? If there is a such third-party library supports
> major platforms, nice license, open source, why is std one needed?
**If** there is - sure. Right now it's probably QT wrappers, which was
If "nice" means this 4 functions:
# SDL_clipboard.h
proc setClipboardText*(text: cstring): cint {.importc:
"SDL_SetClipboardText".}
proc getClipboardText*(): cstring {.importc: "SDL_GetClipboardText".}
proc hasClipboardText*(): Bool32 {.importc: "SDL_HasClipboardText".}
Just in case somebody doesn't know already: SDL2 has some nice, simple
clipboard support.
I didn't want to introduce more complexity by using XML (which is a pile of
crap and always was) or JSON (which will hopefully go the same way as XML
because its just as bad) just to put some strings into an array. Simple things
like that should be built into the language.
There are platform without GUI or clipboard. (e.g. embed system, Linux without
Xorg) Making std GUI / drawing / clipboard library means that the language
doesn't support such platforms? When I want to compile these language that has
std GUI / drawing / clipboard library, I also have to build
> Is having a "std" GUI / drawing / clipboard / etc lib really so important
> when there are non-"std" candidates in nimble?
Yes, quite a lot. **Std** GUI lib means that you can and will be able to make
ui using same code for every compatible platform _and_ 90% extensions (like
custom
Tbh, "Data" command was never meant for anything useful except backward
compatibility - just like, say, "GoSub". You can always just use
'IncludeBinary' and std JSON/XML parsers.
@Libman [http://www.rapideuphoria.com](http://www.rapideuphoria.com)/
[http://hp.vector.co.jp/authors/VA008683/english/index.htm](http://hp.vector.co.jp/authors/VA008683/english/index.htm)
[https://www.basic4gl.net/mobile](https://www.basic4gl.net/mobile)
I'm sure this is interesting for some people, but the choice of languages seems
peculiar. I think Nim's biggest competitors are: D, Rust, Crystal, Swift,
Kotlin Native, etc...
Is having a "std" GUI / drawing / clipboard / etc lib really so important when
there are non-"std" candidates in
Its quite a while since I used PureBasic so it was probably updated since then,
however I also found it lacking in other areas, for example, it had a Data
command for storing strings etc in your source file, however there wasn't a way
to find out how many items were in the data section before
All arrays in PB (except ones with square brackets) are dynamic by design and
can be easily resized.
I tried PureBasic for a while until I came across the fact it did not have
dynamic arrays I did find a .dll (cannot remember its name) that solved
that but unfortunately it made the .exe start up painfully slow.
For Nim it means that using regex, ssl and some other stuff requires auxiliary
.dlls to be placed where compiler wants them to see. For C# it means that *Nix
and MacOS will require separate Mono installation to run your binary.
I think your comparison is too high level. Eg. the standalone executable. Just
looking at the Nim vs C#. What does partial mean for Nim and what does it mean
for C# ?
> > Russian glyphs support ;)
Dat pain was immense back then ((0(.
> > Fortran
Actually there are rudimentary macroengine in Visual Fortran. Not Nim level
even remotely, but still usable.
> > For some other features, it's easy enough to replicate, for example the
> > existence operator can
I think people are more likely to understand the strength/weaknesses of a
language by their domain of expertise.
For example you are a CLI app dev, what was good/bad in Nim (Russian glyphs
support ;)).
As a numerical computing dev, my top 3 are: operator overload, multithreading,
autotyping.
[https://pp.userapi.com/c848632/v848632594/1d608c/UiO5t9krnhc.jpg](https://pp.userapi.com/c848632/v848632594/1d608c/UiO5t9krnhc.jpg)
So, I more-or-less finished comparison table. Of course, feature coverage (as
well as langs choice) is rather contrary - but hey, it's me.
Thoughts ?
23 matches
Mail list logo
