Live data from Hacker News

The perfect programming language

cygni.se

81–90 of 108 posts

Re: The perfect programming language

#81
post #72

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…

Yeah, that's my point. Contrary to the claim in the post I'm replying to, it seems clear that having the ability to do unsafe impure things in a language doesn't mean users of that language "loose all ability to reason reliably". To the extent that the libraries and the ecosystem doen't make inappropriate use of unsafe behavior, you can have your impurity and reliable referential transparency too.

Re: The perfect programming language

#82

Wait a minute, Ruby is not on here...

Ruby hits that sweet spot for me. Have you seen Crystal? Ruby, but native. Amazing stuff.

The big thing that's missing for me is support for operating systems that aren't Linux or macOS. At work, Windows support is a must (I may strongly dislike it, but that's life).

The other blocker was historically the lack of threading, but now that seems to be implemented.

Re: The perfect programming language

#83
All that and his code examples are bizarre trash.

Despite 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

#84
post #13
post #10

Earlier 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.

You can disable optimisation if you want faster builds.

The existence of optional optimisations isn't a problem.

Re: The perfect programming language

#85
post #78

Earlier 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.

Only if you use a binding to a traditional UI framework. There is an opportunity here to research wholly new classes of UI frameworks. Data binding like in React lends itself nicely to ownership/borrowing semantics, for example. The React-like Relm may only be a first glimpse of what's to come.

Re: The perfect programming language

#86
Disappointed to see that Scheme is the only lisp mentioned and the author spent too little time to be able to see past the parenthesis and realize the model lisps represents. Interesting to see the different combinations he thought about but really thought lisps would be mentioned more.

Re: The perfect programming language

#87
post #13

Earlier 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.

Of course not the problem is C++ compilation and link model is fundamentally broken from a performance stand point.

Re: The perfect programming language

#88

Earlier 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.

JVM can be kinda neat if you're doing server deployments and might use different languages like Kotlin, Java, Clojure and jRuby, as the deployments are mostly the same and same inspection tools can be used for the runtime.

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

#89

Earlier 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.

XSLT 2.0 has fewer implementations.

Re: The perfect programming language

#90
post #7

Interesting 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.

XSLT is actually a very good language. It's a declarative general-purpose tree transformer, there's very few tools like that. It's a pity that the general prejudice against XML obscures what really is good tech.
Post reply on HN