progman

32 ms·

271.
by progman 11y ago
> To make web pipes work, just to even get started, you first have to solve authentication and data format/transfer standards. Unix pipes have already solved the authentication problem. For instance, to stream a compressed harddisk
272.
by progman 11y ago
Nim's garbage collector is indeed very fast. I wrote an application which makes heavy use of string concatenation and a lot of regexp matches in native Perl syntax. I am amazed how performant the code is. Also compilation works pretty
273.
by progman 11y ago
> Not at all. This is the list of problems that exist with an overly slow, early and incomplete type checker. What about Shen on Clojure? http://www.shenlanguage.org
274.
by progman 11y ago
Most people just consider the raw execution time to measure performance. In long-term applications that really matters. In usual applications however most people don't realize that the development time should also be considered. In t
275.
by progman 11y ago
I used Rust for a while. _Now_ I don't use it because I discovered other languages that work better for my current applications.
276.
by progman 11y ago
> In your blind love for Rust you seem to forget that it in fact operates with pointers - everywhere. I don't use Rust at all :-) I favor Nim, Haskell and Lisp. I am just pointing to Rust as a better alternative to cc14. > I&#x27
277.
by progman 11y ago
In embedded systems pointers make some sense but not in usual applications. This is the way how Rust can work: http://mainisusuallyafunction.blogspot.de/2015/01/151-byte-s...
278.
by progman 11y ago
> And, to be honest, thinking that pointers are "obsolete" suggests lack of understanding. Who has lack of understanding? Rust proves that pointers are not actually necessary anymore. > You know what, all your points seem to
279.
by progman 11y ago
The problem with modern C++ is that people stick to their programming styles. Many will use some of the new good features but they will also use the old ones (pointers!) because it's so easy to use them. Rust however forces people to a
280.
by progman 11y ago
"As clean and direct as any other modern language ..." LOL Honestly I needed to read the C++98 code to understand the modern one. Yes, C++ has advanced but the inherited waste is obvious. Do other modern languages still operate
281.
by progman 11y ago
> This is a particularly fantastic analogy when you look at the type of error messages that LaTeX produces. Nevertheless LaTeX is still the favorite DTP system among scientists. LaTeX is actually not too hard to learn. It just requires s
282.
by progman 11y ago
I think TurboPrint is pretty successful. It is a good printing system. I purchased it many years ago and it is still available to this day. http://www.turboprint.de More commercial applications: https://en.wikipedia.o
283.
by progman 11y ago
Regarding your points 1) to 4) this is exactly what I mean with investing some effort to discover how these things work in Linux. For 1) there are LibreOffice and gnumeric, for 2) there are mplayer, vlc, and several other tools, for 3) I do
284.
by progman 11y ago
> As long as you stay away from perpetually-beta distributions that I shall not name, driver problems are really a non-issue. One of the first thing every Linux user needs to know is that he should only use hardware which is listed in th
285.
by progman 11y ago
> Nothing about Linux on the desktop "works fine". It's horrible. This claim is usually made by Windows users who don't want to invest any effort and time to learn another desktop -- which they had to do in Win8 anywa
286.
by progman 11y ago
One point is missing: the state of debugging. Current state: https://wiki.haskell.org/Debugging For comparison (F# and Ocaml): https://msdn.microsoft.com/en-us/library/ee241127.aspx http:&#x2F
287.
by progman 11y ago
Not at all. I have developed in both languages. Forth is almost bare metal, between Assembler and C. Lisp is a high level language. Its abstraction level can be pushed way beyond any other language. DSL creation is much easier in Lisp than
288.
by progman 11y ago
I think the language itself is not the problem but the environment. It takes a lot of effort to setup a working system. What beginners want is a "QuickHaskell" -- an out-of-the-box working Haskell environment with all batteries in
289.
by progman 11y ago
I honestly respect the power and rapid development of Rust but I think that Nim ( http://nim-lang.org ) is a much better alternative to Python than Rust, as its syntax and "feeling" is much closer to Python, and also the
290.
by progman 11y ago
FYI: http://www.ada2012.org
291.
by progman 11y ago
> Ada is definitely not dead True. More information: http://www.ada2012.org
292.
by progman 11y ago
I know that Ada compilers are 100% verified correct but is there really any validated C++ compiler? Which one? AFAIK (partial) assurance in C/C++ can only be handled by additional testing tools, Frama-C for instance. I agree that C&#x2
293.
by progman 11y ago
Thanks!
294.
by progman 11y ago
Yes, brilliant! I read http://pygments.org/docs/styles and other sites but I didn't find how I can change the default colors. Do I have to edit (clone) pygments or is there a config file?
295.
by progman 11y ago
> Syntax extensions are not for trivial rewriting, that's the purpose of macros. Syntax extensions are for doing things like expanding a regex into a finite state machine at compile-time. Nim provides templates and macros for that.
296.
by progman 11y ago
> I can't help thinking that this is just the wrong way to do this. I think this is a typical example for the huge verbosity of Rust. Yes, you get safe bare metal access but for the price of a lot of coding effort for _every_ applic
297.
by progman 11y ago
> In my opinion Rust and Nim would make a nice team as complementary languages I don't think so because the syntax is very different. You would have to learn two languages, and if you know Rust and you need it for safety reasons --
298.
by progman 11y ago
Actually Nim solves some of the major safety problems with C -- with string garbage collection and array index checks (avoiding buffer overflows) for instance. And fiddling with pointers which is typical for C is generally a bad programming
299.
by progman 11y ago
I am not talking about a complete rewrite of big business software written in Python. I just had small projects in mind which are typical for Python. Big business usually depends on Java, C# and C++ but not on Python. http://www.
300.
by progman 11y ago
> I'm much more productive in it That's the point! I know many languages and Nim is by far the most productive one. It's like coding in Python with the assurance that the compiler will catch many errors that would cause ru

More ›