Earlier quoted context omitted.
Javascript is also high-level interpreted language, but it's much faster than Python. Python is pretty hard to optimize in a JIT (and it gets much less attention than Javascript).
True, but it's also miles behind C/C++. While Python is arguably the slowest of the mainstream interpreted language, they're all orders of magnitude slower than C.
D as a Better C
161–170 of 193 posts
Re: D as a Better C
#162Earlier quoted context omitted.
Since it's already brought up in this thread, I recently had (another) look at nim and was a little disappointed too. It's been a while, but as I recall, on Windows - it was difficult to find a supported way to output Unicode on the console in a sane, portable way (write utf8 nim source code, get wide strings in Windows console and utf8 under eg Linux) - and I think I also had some problems getting off the ground wit…
Indeed there are some bugs with unicode output[1]. Just to be clear the standard way to output anything to the console is `echo` (similar to Python's `print`). It seems that the progress on that issue has stalled. It's unfortunate but we do have limited man-power and rely on the community to help us out, this does mean that at this stage it helps if you don't mind getting your hands dirty with potential bugs. Unless…
import encodings
var hello1 = convert("Hellø, wørld!", "850", "UTF-8")
# Doesn't work - seems to think current codepage is utf8.
var hello2 = convert("Hellø, wørld!", getCurrentEncoding(), "UTF-8")
# Outputs correct text:
echo hello1
# Outputs corrupted text:
echo hello2
(And simply outputting an unconverted string fails, like hello2 does).As for the linking problem I had, the main issue is that it seems to be harder than it probably should, to get started with the GUI-programming with nim on windows. The following code works, provided one manually obtains sdl2.dll (and sdl2.lib for static linking) - however, even with static linking flags (no errors), the resulting exe still depends on the presence of sdl2.dll:
import nimx.window
import nimx.text_field
import nimx.system_logger
proc startApp() =
var window = newWindow(newRect(40, 40, 800, 600))
let label = newLabel(newRect(20, 20, 150, 20))
label.text = "Hellø, wørld!"
window.addSubview(label)
runApplication:
startApp()
With sdl2.dll (and .lib) in the same folder both of these work:nim --threads:on --dynlibOverride:SDL2 --passL:SDL2.lib c -r win.nim
nim --threads:on c -r win.nim
but both fail without sdl2.dll present (ie: the "statically" linked exe still depends on dynamically loading sdl2.dll).
And there's so far no easy way of getting a "supported" sdl2.dll to go with the nim compiler - as far as I can tell, neither "nimble install sdl2" or "nimble install nimx" provide a way to get the sdl2.dll and/or C source code to compile it.
But perhaps managing DLLs and such is considered to be out-of-scope for nimble/nim package manager for now.
Re: D as a Better C
#163Earlier quoted context omitted.
It's not really Nim's fault that cmd.exe has crap Unicode support.
If you have an "echo" primitive/function, and "out of the box unicode support", then respecting the host OS codepage/output encoding by default is the sane thing to do (as indicated in the bug linked by the sibling comment ("just use the win32 api"). It's not that nim can't output wide characters from a utf8 source, it's just that it's not obvious how to do it in a standard way - one might thing that utf8 unicode "he…
Re: D as a Better C
#164Now we need another flag to enable a better Java mode. By default D is in better C++ mode.
How about betterC# instead? Given that C++/CLR is a thing, I imagine that it would be possible to get D working on it. JVM is a bit more limited in what it allows vs. CLR. For instance, C# has the unsafe keyword that allows pointer arithmetic, which would correspond to @system in D. @safe D would correspond to the normal C# behavior on that front. Probably a lot of work though and I'm not sure why anybody would bothe…
That is why .NET Native and CoreRT exist.
.NET 4.6 got a few news ways to control when the GC is allowed to run.
Also C# got its reference types improved on version 7, and the roadmap up to 8.0 includes a few more goodies, like spans.
Re: D as a Better C
#165Earlier quoted context omitted.
The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…
I really really don't been to pile on Python... but every time I've had to interact with it I've been shocked at how slow it is compared with C or C++. I tend to write scientific code to process datasets in the range on 10Gb, for simple operations Python code can take hours as opposed to just taking minutes or seconds in C. I'm sure it's possible to write more highly optimized code in Python, but it never seems to be…
Re: D as a Better C
#166Earlier quoted context omitted.
Idk about the editor integration problem, but usually when I run into the 'auto' problem what helps me is printing out the type as follows: typeof(var).stringof.writeln;
You can also emit the type during compilation, rather than at runtime: pragma(msg, "var has type: ", typeof(var));
Re: D as a Better C
#167Earlier quoted context omitted.
Have you looked at Rust? It uses Option types, has generics, also uses return values for error handling but has a lot more syntactic sugar to make it cleaner than in Go.
I have tried Rust in the past, though not on this particular hobby project (my Clojure interpreter). I found it hard to get into, and I've gotten into a lot of languages in my time-- some of which are considered challenging (e.g. Haskell). With Rust, I always felt I spent too much time wrestling with it, and not enough time being productive. I imagine that you hit a threshold at some point and that begins to change.…
Granted Rust has some paradigms and constructs which are not easy to learn, I found it rather exciting. I think it has future scope.
Wonder whats happening with Redox. I hope Rust adds more libraries, especially network related, since the networked world is increasingly looking like a distributed OS of sort. Browsers are looking like an OS or a shell inside the OS. Browsers are getting more complex with more functionalities added every few months. Not sure I expressed my thoughts correctly, but I guess one can understand what I mean.
Rust should move away from C standard library, if possible.
Re: D as a Better C
#168Earlier quoted context omitted.
I am in a similar situation, as I develop a lot of scientific code. I've tested several solutions, and so far the most viable for me (though far from perfect) is Python+NumPy+Fortran, the latter exposed to Python using f2py (much easier than binding C/C++ to Python). Not sure if this might be a good solution for you, it depends whether the bottleneck in your code is in I/O or in raw calculations (in the former case y…
Julia could have had 10x the adoption if they painted themselves as more of a general purpose language, like "write the web app and your neural networks (GPU accelerable bien sur) in the same language ftw!"... if only they'd have bolted in some support for "non-weird-looking classic OOP" like in "wanna type `window.` and have even the most retarded editor autocomplete methods". Imho they got it backwards: Python got…
Re: D as a Better C
#169Re: D as a Better C
#170Earlier quoted context omitted.
If you have an "echo" primitive/function, and "out of the box unicode support", then respecting the host OS codepage/output encoding by default is the sane thing to do (as indicated in the bug linked by the sibling comment ("just use the win32 api"). It's not that nim can't output wide characters from a utf8 source, it's just that it's not obvious how to do it in a standard way - one might thing that utf8 unicode "he…
Nim is not a Win32 runtime. It outputs strings to stdout. Any sane OS would do the right thing in 2017.
Same goes for things like handling paths, line endings for text files, resource forks (or not) for files, changing file meta-data...