Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Ideal memory management in your dream PL.

Name: Anonymous 2014-10-21 8:06

Imagine you are designing a practical relatively low-level programming language to use instead of C++. What approach to memory management would you use?

In case someone asks, ``what is wrong with manly manual memory management in C++?'', I would briefly explain my disdain towards it. C++ strives to allow for efficient programs to be written, yet you have to jump through hoops and remember 30 different things if you want to avoid inefficiences C++ compilers inject into your application code. Where C would hit the spot with passing of pointers, C++ programmers need to know about RVO and const references and rvalues and perfect forwarding and noexcept declaration of copy constructors (why even have copy constructors anyway‽ how sane is having such thing‽) and reference collapsing rules. All just to prevent compiler from inserting procedures that needlessly copy your data multiple times here and there.

Instead of fixing a conceptually shitty design the committee adds 5 even more shitty things, each with its own semantics, each designed to work around one compiler/stdlib deficiency or another. Each has to be used manually.

So C++ programmers spend their brain cycles on recalling hundreds of shitty techniques while churning out code doing stuff which would be trivial for a saner language compiler to infer, instead of focusing on actual functionality.

Since it is lunch time where I work, I want to fantasize about a language/compiler which has most or all benefits of fast memory management (no GC), takes modern hardware into account, and doesn't fucking get in your way every time you pass a string to a function.

Name: Anonymous 2014-11-14 15:02

>>82
I used it before Mozilla rolled out the pure JS renderer of PDF, so I read pdfs with firefox now.
Tried kpdf and xpdf, both were terribly annoying.

Name: Anonymous 2014-11-16 16:55

>>16,19
Regarding ATS: http://stackoverflow.com/questions/26958969
Why was the ATS language dropped from the Computer Language Benchmarks Game?
Unfortunately, there was no effective way to make sure that contributed ATS programs were comparable to the other programs that had been contributed. There are not enough ATS experts.

Name: Anonymous 2014-11-16 17:33

>>84
That means YOU have a chance to become an Expert ATS Programmer way before it gets fashionable.

Name: Anonymous 2014-11-16 18:01

>>83
Okular is the best, if you don't mind the KDE dependency.

Name: Anonymous 2014-11-16 18:04

>>81
Where are you getting this?

Evince Dependencies
Required
adwaita-icon-theme-3.14.1, gsettings-desktop-schemas-3.14.1, GTK+-3.14.5, and Itstool-2.0.2

http://www.linuxfromscratch.org/blfs/view/svn/gnome/evince.html

Name: ebins 2014-11-16 19:18

ebins

Name: Anonymous 2014-11-16 20:13

>>83
evince might be a total load of shit, but do you really consider pdf.jizz any better?

Have you ever considered killing yourself back to Reddit?

Name: Anonymous 2014-11-16 20:15

>>89
No. And yes, Firefox is better than kpdf and xpdf. Evince was better than firefox.

Name: Anonymous 2014-11-16 20:18

>>90
Try Zathura or Chrome's PDF reader. Both are way better than pdf.js.

Name: Anonymous 2014-11-16 20:48

>>86 is right though. Okular is the bomb. I have even used it on windows.

Name: Anonymous 2014-11-16 21:27

I am using only Okular.

Name: Anonymous 2014-11-16 21:40

>>89-91
Evince and zathura both use Popped for their PDF backend. Poppler itself is derived from xpdf, so the capabilities of all three applications are nearly equivalent.

It's very unfortunate that Google and Mozilla failed to agree on a common framework to replace NPAPI. Between Google's closed source Pepper PDF blob and Mozilla's non-performant PDF.js, PDF functionality in contemporary open source browsers has regressed terribly.

Name: Anonymous 2014-11-16 23:36

>>94
PDF functionality in contemporary open source browsers has regressed terribly.

Has it really? It's always been garbage in browsers but I don't think that's the right place for the viewer. Google and Mozilla put them there because nearly everyone has Adobe's or another vulnerable viewer installed.

Name: Anonymous 2014-11-17 1:45

>>95
If built-in viewers aren't approaching feature parity as the old NPAPI viewers accumulate security vulnerabilities and generally bitrot, then yes, I would call that a regression overall.

Name: Anonymous 2014-11-17 7:12

>>96
Never had any problems with pdfjs. The only thing that may be missing that I might use is ability to fill out forms. Other than that, everything I encountered rendered perfectly, and quickly enough.

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List