Live data from Hacker News

Programming Language Checklist

famicol.in

141–150 of 169 posts

Re: Programming Language Checklist

#141

"The name of your language makes it impossible to find on Google" --> [ ] Google has made its own language with a name near to yours and has stolen all the search results from you

When I dabbled in Groovy some years ago, I found that searches quickly achieved absurdity.

Re: Programming Language Checklist

#142

When I was younger, I imagined there would come along a true language that would solve my problems. It took me a long time (and a lot of banging my head into bad environments) to realize that language matters a lot less when the IDE is well-configured and fluent with what I want to do, the toolchain allows for experimentation without ruining the ability to do large, collaborative work, and both debugging and profilin…

> when the language itself (spec and implementation) is constantly in flux.

Common Lisp and Clojure are legendary for their stability. So many times I have experienced it myself - I would pick up a 5-6 year old Clojure project, update a bunch of dependencies, and somehow most things work right off the bat. That trick never worked for me with pretty much any other language - C#, Java, Python, Ruby, Go, Lua, Javascript - you name it.

Why is that? Probably because Lisp dialects essentially have no syntax. Code is data and data is code.

Re: Programming Language Checklist

#143

Earlier quoted context omitted.

> the syntax doesn't really matter at all. Somehow it does though: I find even j/k/apl easier to parse in my head than Ruby; somehow the ruby syntax gives me a headache. Not sure why that is, as I wrote a lot of code in it, but I find Python, C#, F#, Haskell or Kotlin far nicer to read and write. And, even though I understand the semantics and can write code in Ruby, if I have a choice, I would never touch it again.…

Yeah for sure this is a big thing. I love Ruby’s syntax and if I could, I’d love to write in it all day if I was being paid the same amount as another language. Psychology is also at play. JavaScript I agreed can be quite rancid. But knowing it’s the only language that works in every browser, I internally whined about it less and now rarely do at all.

> it’s the only language that works in every browser

Assembly is the only language that works on every machine, no matter how small or big. But that doesn't mean that we all have to write assembly. Or Javascript (if we're targeting Web). Purescript, Elm, ReasonML, Clojurescript - they all exist for good reasons, not some made-up bullshit points.

Re: Programming Language Checklist

#144
post #91

> [ ] Syntax is what makes programming difficult I'd love to see language design and language development treated as different disciplines. Just like developers were the first web designers, developers have been the first language designers. Ideally a language designer would only be tasked with how to express complex ideas in a simple, composable syntax. Language developers would be tasked with everything else: basic…

> Ideally a language designer would only be tasked with how to express complex ideas in a simple, composable syntax.

It feels like you're talking about Clojure.

Re: Programming Language Checklist

#145
post #4

Of course, every successful language could be roasted with this, too. It's a cute post but if there were a simple checklist for creating a successful language, every language designer would just do that.

Define "successful language". Popularity of a programming language doesn't mean success. COBOL, Fortran and Pascal used to be hugely popular, now with every passing year, it is costing more and more money to support systems that once considered as "successfully built".

Sadly, it seems in a few decades, pretty much that would be the fate of every single PL in TIOBE's Top. All popular PLs of today are morally outdated. Programming languages of future would be striving for:

a) Developer's productivity

b) Execution performance

c) Correctness of the program

And none of the popular languages today are making good progress in any of those directions.

Re: Programming Language Checklist

#146
post #108
post #91

> [ ] Syntax is what makes programming difficult I'd love to see language design and language development treated as different disciplines. Just like developers were the first web designers, developers have been the first language designers. Ideally a language designer would only be tasked with how to express complex ideas in a simple, composable syntax. Language developers would be tasked with everything else: basic…

> a linguist (with some understanding of development) Your wish has been granted: Larry Wall, Perl 6.

Please note that Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media).

Re: Programming Language Checklist

#147
post #141

"The name of your language makes it impossible to find on Google" --> [ ] Google has made its own language with a name near to yours and has stolen all the search results from you

When I dabbled in Groovy some years ago, I found that searches quickly achieved absurdity.

I once looked to see if anyone had made Pants rules (build tool) for LESS.

Re: Programming Language Checklist

#148
post #132
post #24

Earlier quoted context omitted.

there are tons of multiparadigm languages, but oz/mozart in particular is worth a glance: https://mozart.github.io/mozart-v1/doc-1.4.0/tutorial/index....

It’s also notable in that Mozart is based on Pi Calculus. Except for Pict, I’m not aware of any others.

i hadn't heard of pict, but there's occam-pi and jocaml which are based on the pi calculus. (jocaml is based on the join calculus, which has been demonstrated to be equivalent to the pi calculus).

Re: Programming Language Checklist

#149
post #126

Man, I so need something like this filled out for Blazor, but since it's not expressly a language, it doesn't quite fit. Been arguing against it for a while, half the new projects (from other teams) where I work are using it.

My mates a ‘die hard’ C# fan and has been using it (almost exclusively) for over 15 years. Recently he’s been talking about Blazor a lot, and having worked on a few web apps myself, I can see its general appeal. Why don’t you like it? I’ve not read any anti-Blazor opinions.

First off, I'm not really against it in concept... about my only real complaint is the latency for server actions over the internet is rather painful (look at devexpress or telerik component demos) and the wasm payload is around 2.2mb for a hello world app to start.

The component libraries themselves are relatively poor quality and have some weird JS integrations. There's no good open-source component libraries. Even a good library that utilizes bootstrap or material-design scripts would be nice.

Once these issues are generally resolved, I'd be more inclined to suggest it, but I do not want to be the first mover on this one. I've seen way too many X to browser libraries come and go without gaining any real traction only to die on the vine so to speak, then you're stuck rewriting or patching an application that looks and feels ancient.

Even then, one of the larger arguments in favor of Blazor is really, "I can reuse my C# skills." Even there, you need a lot of Browser application context knowledge in practice, and you've just created disconnects and more work where you do need it. That doesn't even get into the mirrored trees directory structure of .Net MVC that is repeated with Blazor.

If I were to explore something similar, I'd probably favor Yew (rust) which seems to be around 220k for the todo mvc app.

In summary:

    * Bulky payload or laggy response
    * Lighter alternatives
    * No network effect
    * Dirty abstractions
    * Messy structure by default
    * Verbose
My preference for web applications isn't particularly lightweight, but much more responsive and imho much better developer velocity with a more consistent and better functioning application...

    * React (favoring hooks)
    * Redux / GraphQL
    * Material-UI (jss/css-in-js themes)
    * Fetch API
    * connected-react-router

I'd also be more inclined to give Vue or Flutter (Dart) a try, both of which have more maturity in terms of network effect behind them.

Re: Programming Language Checklist

#150

When I was younger, I imagined there would come along a true language that would solve my problems. It took me a long time (and a lot of banging my head into bad environments) to realize that language matters a lot less when the IDE is well-configured and fluent with what I want to do, the toolchain allows for experimentation without ruining the ability to do large, collaborative work, and both debugging and profilin…

> when the language itself (spec and implementation) is constantly in flux. Common Lisp and Clojure are legendary for their stability. So many times I have experienced it myself - I would pick up a 5-6 year old Clojure project, update a bunch of dependencies, and somehow most things work right off the bat. That trick never worked for me with pretty much any other language - C#, Java, Python, Ruby, Go, Lua, Javascript…

[deleted]
Post reply on HN