Earlier quoted context omitted.
> The moment you allow imperative behaviors to leak into a declarative system it loses its ability to reason reliably about operations over time; and you’re back to flying seat-of-your-pants a-la C &co By your (imo, extremist) line of reasoning, wouldn't the existence of `unsafePerformIO` mean Haskell itself "looses its ability to reason reliably about operations over time"? I think a more reasonable position allows…
> By your (imo, extremist) line of reasoning, wouldn't the existence of `unsafePerformIO` mean Haskell itself "looses its ability to reason reliably about operations over time"? By your (imo, extremist) line of reasoning, wouldn't the existence of `unsafePerformIO` mean Haskell itself "looses its ability to reason reliably about operations over time"? Well no, because for some reason, be it social or technical, peopl…
The perfect programming language
81–90 of 108 posts
Re: The perfect programming language
#82Wait a minute, Ruby is not on here...
Ruby hits that sweet spot for me. Have you seen Crystal? Ruby, but native. Amazing stuff.
The other blocker was historically the lack of threading, but now that seems to be implemented.
Re: The perfect programming language
#83Despite the way he tries to crap on Perl (5) by referring to a Perl 6 (now Raku) example, I find a Raku FizzBuzz far easier to read than his mess:
multi sub fb( Int $n where * %% none(3,5) ) { return $n }
multi sub fb( Int $n where * %% all(3,5) ) { return 'fizzbuzz' }
multi sub fb( Int $n where * %% 3 ) { return 'fizz' }
multi sub fb( Int $n where * %% 5 ) { return 'buzz' }
.say for (1..15).map({ fb($_) } );
Or if you want to name your specialized types: subset Fizzy of Int where * %% 3;
subset Buzzy of Int where * %% 5;
subset FizzBuzzy of Int where * %% (3&5);
subset Otherwyzy of Int where not * %% (3|5);
multi sub sfb( Otherwyzy $n ) { return $n }
multi sub sfb( FizzBuzzy $n ) { return 'fizzbuzz' }
multi sub sfb( Fizzy $n ) { return 'fizz' }
multi sub sfb( Buzzy $n ) { return 'buzz' }
.say for (1..15).map({ sfb($_) } );Re: The perfect programming language
#84Earlier quoted context omitted.
There is no purpose of having a so complicated language - like c++ or java - that the majority of the programmers don't even know 100% of the language. I think Elm (and somehow Go) fits this category, everyone can learn in less than a week every aspect of it. Another benefit of having a very simple language is the compile time, c++ has a awful compile time, 100kloc can take half an hour, in Elm it takes less than 5 s…
> c++ has a awful compile time I have a thoery that C++ compiler writers obsession with pointless micro optimizations is because C++'s compilation model scales horribly. Thus they desperately want their compiler to be faster. But they are fucked because the more optimizations just slows down the compile times even more.
The existence of optional optimisations isn't a problem.
Re: The perfect programming language
#85Earlier quoted context omitted.
Is it fair to compare GUI frameworks with over 20 years of maturity (Qt, GTK+) with others that are less than a few years old and still mostly in their exploratory stages?
It is, because the issue is the language semantics to deal with typical UI workflows. You are forced to use Rc > and clone everywhere, or copy objects around, reactive style, to kind of work around borrow checker ergonomics.
Re: The perfect programming language
#86Re: The perfect programming language
#87Earlier quoted context omitted.
> c++ has a awful compile time I have a thoery that C++ compiler writers obsession with pointless micro optimizations is because C++'s compilation model scales horribly. Thus they desperately want their compiler to be faster. But they are fucked because the more optimizations just slows down the compile times even more.
You can disable optimisation if you want faster builds. The existence of optional optimisations isn't a problem.
Re: The perfect programming language
#88Earlier quoted context omitted.
Yes, Crystal is pretty cool. Though I have found that it is hard to compile for different platforms. If you need speed and concurrency, giving jruby a shot is worth a try. It speeds up your code through both being fast and having 'real' concurrency.
What do you think of the reliance on the JVM? I've tended to shy away from using it.
However, doing CLIs or binaries for whatever reason, then it wouldn't be so neat. Ruby wouldn't either, but GraalVM might be able to provide something good for it in the future as well.
Re: The perfect programming language
#89Earlier quoted context omitted.
XSLT syntax (x < 10) would be its worst problem, except for its other problems. But seriously, XSLT's recursive templates are a nice idea for transformation, and the homoiconicism enables transformation of XSLT stylesheets theselves.
You can write `x lt 10` since XSLT 2.0 in 2007.
Re: The perfect programming language
#90Interesting perspectives on a variety of languages, at first. Then when he says that XSLT is the best language I was thinking that we are very differently minded. So I suppose it makes sense that the Tailspin language is completely incomprehensible to me.