There is a good quote from Bjarne Stroustrup for that "There are only two kinds of languages: the ones people complain about and the ones nobody uses". I think for hobby projects it's the best to use languages that interest you
this post was submitted on 10 Sep 2023
51 points (89.2% liked)
Programming
17319 readers
54 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
There are two types of programmers, those who write buggy code and those who never do anything.
load more comments
(1 replies)
There are only two kinds of languages: the ones people complain about and the ones nobody uses. - Bjarne Stroustrup
I think people criticise every language. I've generally got 5 languages that I use personally and for work: Rust, Go, Python, JS, PHP. I can complain about all 5 of them at the drop of a hat. No one likes everything about any language.
Haskell, because nobody knows haskell
Unfortunately, no one can be told what a monad is. You have to see it for yourself (then you won’t be able to explain it to anyone)
The problem is people constantly try to explain it using some kind of real world comparison to make it easier to visualize ("it's a value in a context", "it encodes side effects", "it's a way to do I/O", "it's just flatmap", "it's a burrito"), when all it really is is an abstraction. A very, very general abstraction that still turns out to be really useful, which is why we gave it the cryptic name "monad" because it's difficult to find a name for it that can be linked to something concrete simply because of how abstract it is. It really is just an interface with 2 key functions: (for a monad M)
- wrap: (x: T) => M[T] // wraps a value
- bind: (f: (y: T) => M[U], x: M[T]) => M[U] // unwraps the value in x, potentially doing something with it in the process, passes it to f which should return a wrapped value again somehow, and returns what f returns
Anything that you can possibly find a set of functions for that fits this interface and adheres to the rules described by someone else in this thread is a monad. And it's useful because, just like any other abstraction, if you identify that this pattern can apply to your type M and you implement the interface, then suddenly a ton of operations that work for any monad will also work for your type. One example is the coroutine transformation (async/await) that is an extremely popular solution to the Node.JS "callback hell" problem that used to exist, and which we call do-notation in Haskell:
// instead of
const getPostAuthorName = foo => getPost(foo).then(post => getUser(post.authorId)).then(user => user.username)
// you can do this
const getPostAuthorName = async foo => {
const post = await getPost(foo)
const user = await getUser(post.authorId)
return user.username
}
This is a transformation you can actually do with any monad. In this case Promise.resolve is an implementation of wrap, and then is an implementation of bind (more or less, it slightly degenerate due to accepting unwrapped return values from f). Sadly it was not implemented generally in JS and they only implemented the transform specifically for Promises. It's sad because many people say they hate monads because they're complex, but then heap praise on Promises and async/await which is just one limited implementation of a monad. You may have noticed that generators with yield syntax are very similar to async/await. That's because it's the exact same transformation for another specific monad, namely generators. List comprehensions are another common implementation where this transform is useful:
// instead of
const results = []
for (const x of xs) {
for (const y of ys) {
results.push({ x, y })
}
}
// you could have
const results = do {
const x = yield xs
const y = yield ys
return wrap({ x, y })
}
Another (slightly broken) implementation of monads and the coroutine transform people use without knowing it is "hooks" in the React framework (though they refuse to admit it in order to not confuse beginners).
Fuck... I actually just wanted to write a short reply to the parent comment and devolved into writing a Monad Tutorial...
load more comments
(1 replies)
Isn't a monad just a monoid in the category of endofunctors?
load more comments
(1 replies)
Monads 👁️👄👁️
Python is for some reason darling of many, sometimes it has almost religious connotations. Meanwhile differences from e.g. PHP are mostly superficial and each has their strengths and weaknesses.
Bourne shell is orders of magnitude worse clusterf*ck than JavaScript, yet it's rarely criticized.
Rust rarely gets criticized which isn't necessarily a problem, since it's IMHO a good language for its intended use case. But people tend to recommend it for things where the trade offs come out negative. (apps not needing max. performance)
In general I wouldn't follow the trends on social media, it's all a huge groupthink, mostly focusing on (easily avoidable) warts, and ignoring strengths.
Bourne shell is orders of magnitude worse clusterf*ck than JavaScript, yet it's rarely criticized.
Both have their place. Bourne shell scripts are great as a container for connecting the various tools you have around - and for that kind of relatively simple script is way easier to use than something like Powershell. If you use it for something more complex you're probably an idiot.
Same with Javascript - if you need to annoy someone with popups on a website, or have something dance around in the window it's a great language. If you use it for something else you're probably also an idiot.
Bourne shell is orders of magnitude worse...
PowerShell is to bash what a fighter jet is to a model airplane, but you don't dare mention it or you'll get chewed out.
I prefer it to python too, I must be the antichrist.
That's because PowerShell blurs the line between programming language and scripting language. By accessing the entire .NET library, of course it's going to have more features than a basic scripting language that relies on open source utilities installed on the system.
The reasons people hate it are because they hate Microsoft, it breaks from traditional shells too far, and it's a pain in the ass to type (verbose). To use PowerShell effectively, you almost need to write full software programs. At that point, just use C#.
As for you preferring it to Python.... I think you don't know Python. I'm trying to come up with every way possible to make PowerShell sound better than Python, and I got nothing. Maybe you don't like whitespace? I cannot understand your point of view here. Help me out
load more comments
(1 replies)
Honestly, I would advise to not pick a language based on popularity, hate, or whichever of those qualify as internet fame these days.
I would approach the question with what you want to get out of your toy project. Do you want to get something done? Then pick a language that is close to what you are already familiar with. Do you mainly want to learn something? Go with a language with concepts you are unfamiliar with, eg. pick a functional language if you mostly do OOP stuff or pick a low level language when you mostly do high level web stuff.
My advice, generally speaking, is: When you do something in your spare time, don't spend it on things you already do at work. The way to improve in software development is to see problems from many different angles and to rethink the solutions you already know.
Whenever I tested something that sounds great yet it is slow to get adoption I end learning a reason why it it's not growing. It's good to learn what the reason is before you spend a lot of time on it
No amount of reading will replace experience. At some point you will come to the place where you'll be the one who know why something that sounds good won't be and why it won't get adopted, but if you only base your decision on the opinions of others, you'll never really learn anything.
C# doesn't have a big spotlight on it like Rust or Python, but it is a popular and very unhated language. It's a good language that is regularly improving and has phenomenal documentation. Seriously, I've not gone to Stack Overflow for anything C# (outside of third-party libraries) for years; Microsoft's documentation gives me everything I need.
As a Linux user / human, obligatory fuck Microsoft. As a .NET dev, what they've done with C# is really great and it's a very pleasant language and ecosystem to work with.
It is incredible really, I worked with C# for so long, and I tend to be very critical of the stuff I've used for a long time. For C#, I am struggling to figure how I would improve it, because all the stuff that suck in C# is usually the lesser of two evils.
Of course if you hate classes, types, managed memory or anything invented in the last 20 years you will hate it, and I've met people like this. That is why you gotta keep learning as a dev, you don't want to be one of those.
The 2 that I struggle with on a daily basis:
-
missing discriminated unions. Third party libraries kind of sort of fill the gap, but it's a pain point.
-
a flawed async programming model. Namely, there are multiple models (for historical reasons / backwards compatibility), and the more current one (task-based) throws a wrench in your ability to effectively design interfaces, functions, delegates etc. that can be shared between synchronous and asynchronous code. Green threads would have fixed this, at the cost of some other potential issues, but it looks we're stuck with tasks for now. Also, there is the awkwardness of needing to constantly use .ConfigureAwait(false) after every await, unless you shouldn't (e.g. in the UI thread), and if you get it wrong you might cause a deadlock in your app but not in a console app... A bit confusing and easy to mess up.
load more comments
(2 replies)
A lot of the criticisms at specific languages are really directed at people. Especially those that have “{language} brain”. These people are of the opinion that everything looks solvable by said language even if it isn’t the best tool for the job.
If you pick the best tool for the job, no one has standing to rightly criticize you. What’s the right tool? One that you know (or have the ability to learn) and has proven itself in its ability to solve problems you’re seeking to solve.
As humans we (you are human, right?) have a negativity bias. Working projects are better than perfect tech stacks. Seriously. Anything even half way working is infinitely better than anything in your head. Just pick something and go, especially for you projects.
There is a bot posting ai generated stuff on my server, but this is my normal account, to post normal human things
As a society and as individual computer scientists, none of us actually know what a computer is or how to use them. All programming languages are guesses, mere attempts to encode our natural-language reasoning and philosophy in the purely syntactic and formal fashion required by computers. Don't let yourself become biased in favor of specific languages; instead, understand that all languages are bad in different ways.
And don't forget, that much of what people criticize isn't the language per se, but the community/ecosystem around it.
NPM is objectively bad, but Javascript is by no means coupled to it.
Java projects are often very "verbose", but that's a choice by the developer of the libraries and apps, not so much Java itself.
Ecosystems matter, though. In fact, I think they're the hardest part to learn for most languages.
You can try to get away from NPM, but you'll always run across instructions on how to do a thing in NPM. Do it any other way, and you're on your own.
You can try to write Java in a less verbose way, but the standard library will fight you before we even talk about third party libs.
load more comments
(1 replies)
Who cares what people online are saying? Most people just like to hate on the popular thing to hate because it makes them feel like they are sitting at the cool kid's table at lunch.
Obviously consider the limitations of what you're using for the project you're using it for. But do the analysis for yourself. Don't avoid something just because people don't like it.
For example Javascript gets a lot of flak online but it's one of the most popular languages and in my opinion, it's great for what it does. I prefer coding in JS over Python even if JS has those idiosyncrasies that makes it the subject of many memes online.
Ie
'2' + 2 = '22'Modern js is pretty nice to work with but the language is very chaotic
If you met or worked with the people who post the majority of the programming-language-ism posts, you would know deep down in your bones how little you need to be listening to them.
There are two types of languages, those that people complain about and those that noone uses. Though rust has been voted the most loved for many years now on the stackoverflow yearly survey, and for good reason IMO.
I feel like nobody ever bad mouths forth. Arguably it’s just because it’s super niche, but there’s lots of niche languages that people shit on all the time. I guess if you’re the kind of person to bother trying out a forth you’re probably going to think it’s neat.
Props for actually answering the question, and with a reasonable language too. Although Forth hasn't clicked for me personally, and I doubt it's a better choice for OP, it's still a unique language design and worth studying.
Yeah. I think Forth is kind of just interesting for what it is and it fits it’s niche well. If you’re looking into Forth you probably appreciate it for what it is, and it’s a super flexible language so it can kind of be what you want it to be. It’s obviously not perfect, and it’s not the ideal fit for what most people want to do… but I guess people just don’t really expect it to be more than it is and it’s a smaller community so nobody is too vocal or angry about it. People will complain about other niche languages like lisp, ocaml, prolog, or Haskell all the time, but people don’t say much about Forth, and when somebody does talk about it it’s pretty much all praise. The Forth people are just content I guess!
I haven't seen any negative criticism on chillicheescript here.
Every languages has their own pitfalls. The answer on picking a language is to pick whatever works for you. There may be even domain-specific languages if you're interested in a domain, and it can be way more flexible than general-purpose solutions for that domain too.
I use 4 languages.
- C++ for adding features to a program.
- C# for making .dll for an application (
Paint.NET). Kinda similar purpose to what I do with G'MIC, except so much more limited. - Python for processing strings
- G'MIC for creating/editing raster graphics images (volumetric too)
Now, I wish there was a vector equivalent to G'MIC, but there isn't.
If all you want in a programming language is that it not frequently be the target of mean-spirited critical reviews, I recommend Befunge. It's a bit old and I don't think anyone has updated it to be powerful enough for modern enterprise-level work, but there exists a non-zero chance that it might be suitable for one of your toy projects.
load more comments
(1 replies)
Haven't heard a bad thing here about COBOL (yet).
Brainfuck, GLSL
I never feel sure
Never feel sure about what? Whether some people criticize the stack or point out issues with the stack?
I never feel sure what I want to use, and I get tempted to stop what I'm doing to do something in another stack, because I am most interested in the tech than my own toy project
Pick a movie. Any movie. You will always find reviews both praising it and disparaging it.
Programming languages are similar. People will always have their opinions about things. It's your choice to try them and decide for yourself if you like them.
Just don't choose PHP ;)
I loved this analogy, it works for old languages as old movies, some characteristics as movie genres and to explain there is not just one and only right language, and that people would have different preferences.
view more: next ›