"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
Programming Language Checklist
141–150 of 169 posts
Re: Programming Language Checklist
#142When 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…
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
#143Earlier 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.
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> [ ] 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…
It feels like you're talking about Clojure.
Re: Programming Language Checklist
#145Of 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.
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> [ ] 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.
Re: Programming Language Checklist
#147"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
#148Earlier 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.
Re: Programming Language Checklist
#149Man, 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.
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
#150When 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…