> C++ has a standard that's too long and hard to understand, so let's use a language without any standard whatsoever instead!
Good lord, if that's the kind of human capital that's involved in making next-generation languages, then I have no doubt what will still be used to write serious software in 2080.
You'd be more helpful if you specified what else would you deem appropriate -- as opposed to resorting to snarky sarcasm that brings nothing interesting to the discussion except supposedly degrade people whose tech choices you disagree with.
The phrase 'undefined behavior' only makes sense in the context of an ISO standard.
For any particular combination of compiler, OS and computer architecture there are no 'undefined behaviors'; you only care about the concept if you want portability to a different compiler/OS/architecture.
So the idea that C++ sucks because of 'undefined behavior', so let's use some random language without an ISO standard or any portability guarantees at all is completely and utterly insane.
> Untold amounts of human effort are exhausted globally every day on rebuilding identical components for web apps. This should not be the case. The UI community should standardize namings and structures for common components.
Yeah, they're called 'HTML forms'.
If you want a standards-compliant, accessible UI that works everywhere then just use them.
If you want some godawful 'SPA' with UI elements that 'communicate your corporate style', then no amount of standardization will help here.
> python is very expressive, hence the code base have way less numbers of lines than in C++
This doesn't match reality. In reality, many Python projects have way more lines of code than equivalent C++ projects. Probably because of the 'expressiveness' you cite; you can't really showcase your love of coding and job security though artificial complexity without 'expressive' bells and whistles. (This is the idea that lead to languages like Go, I'm pretty sure.)
> many Python projects have way more lines of code than equivalent C++ projects.
That is mathematically impossible. Even if the syntaxes were exactly the same (which they are not, python syntax is on average shorter), the low level nature of C++ requires your code to do operations that Python does need to do, such as memory management.
Once you've written sufficient unit tests to prove your code works as well as a C++ equivalent does just by compiling, I don't think Python ends up being more dense though.
I'd also argue that operator overloading etc lets C++ be just as expressive as Python, the libraries just need to be designed with that in mind.
This is a 1rst year of college exercise. Nothing remotely complicated. I'm not choosing some fancy machine learning or data processing stuff for which Python has magic libs. Every language can do that easily.
In Python 3.7, which is already 2 years old, the code would be:
import json
import datetime as dt
with open("agenda.json") as fd:
agenda = sorted(json.load(fd), key=lambda people: people["name"])
for people in agenda:
hired = dt.datetime.fromisoformat(people["hired"])
print(f'{people["name"]} ({people["age"]}) - {hired:%d/%m/%y}:')
for email in people["emails"]:
print(f" - {email}")
The entire script is there. There is no trick. This is not a code golf version of of it; I could make it shorter. It really is standard Python. There is no 3rd party lib either.
It's not specific to Python, you would get this expressiveness with Ruby or Perl.
I don't see in which world you would get that in regular, honest to god, day to day, portable C++.
You have to declare types, many includes, you'll have headers and a main function. You have the memory and references to manage.
It doesn't make C++ a bad language.
It doesn't make python a better language.
The C++ version will take way less RAM than the Python version for example.
It's just the nature of those languages implies that.
For fun, I whipped this up in Rust. I decided to go with an explicit struct to serialize it into, because it makes the error handling easier, and is a bit more idiomatic. I kept unwrap because it's similar to the python semantic of throwing an exception. It's pretty close though!
use chrono::NaiveDateTime;
use serde::*;
use serde_json;
#[derive(Deserialize)]
struct Person {
name: String,
age: u32,
hired: String,
emails: Vec<String>,
}
fn main() {
let data = std::fs::read_to_string("agenda.json").unwrap();
let mut people: Vec<Person> = serde_json::from_str(data).unwrap();
people.sort_by(|a, b| b.name.cmp(&a.name));
for person in &people {
let datetime = NaiveDateTime::parse_from_str(&person.hired, "%Y-%m-%d %H:%M:%S").unwrap();
println!(
"{} ({}) - {}",
person.name,
person.age,
datetime.format("%d/%m/%y")
);
for email in &person.emails {
println!(" - {}", email);
}
}
}
> many Python projects have way more lines of code than equivalent C++ projects
To:
> It's a bit longer in C++ but frankly not by that much
With the proof being literally __twice__ more characters, with one line being more than a 100 characters long.
I understand that C++ doesn't have a native JSON lib, and sorting is a bit out there, but giving 3rd party lib access to Python feels like cheating:
import pandas as pd
agenda = pd.read_json("agenda.json", convert_dates=["hired"])
for _, (name, age, hired, emails) in agenda.sort_values("name").iterrows():
print(f"{name} ({age}) - {hired:%d/%m/%y}:")
for email in emails:
print(f" - {email}")
I mean, I can also create a lib that does the entire script, install it, and just do 'import answernh; answerhn.print_json("agenda.json")'
Now again, this is not so say "Python is better than C++". That's not the point.
If you want to write a game engine, C++ makes sense, verbosity doesn't matter, and you don't want the Python GC to kick in. If you want to iterate on your Saas product API quickly, it's probably not the best choice.
Why pretend otherwise? What the point of stating the sky is red?
To be fair to the C++ version, you need to give as many guarantees from your code as C++ does from compiling. To me, in this case this is mainly the output formatting. Python won't tell you until runtime that you have a malformatted string, so add in some unit tests to make sure your string formatting won't crash, and you'll be at a similar number of lines of code as the C++ or Rust version.
> Python won't tell you until runtime that you have a malformatted string
Neither will C++, as far as I know, or do you mean that the compiler will validate the formatting of the string literal (python has linters that will validate this too!).
Hell, even with statically verifiable types, the python is shorter.
> Neither will C++, as far as I know, or do you mean that the compiler will validate the formatting of the string literal.
With iostreams there are no format strings so there is nothing to validate. Libraries such as https://github.com/fmtlib/fmt are allow to do compile-time parsing of the string though.
I think it shows quite well that the expressiveness difference is not as a large as many would think.
Also, the difference in tone towards jcelerier compared to steveklabnik seems not warranted here. Both IMHO contributed an educational example. Your response here equally does (or does not) apply to the Rust version, doesn't it?
Rust is fantastically expressive for a low level language.
And modern C++ is not 15 years old C++. You have auto, lambda, etc. I just think it's silly to try to pretend to be more expressive than scripting languages.
It's like Schwarzenegger trying to pretend it's as flexible as gymnast. What for? The guy is amazing at what he does.
> I just think it's silly to try to pretend to be more expressive than scripting languages.
So far we have a Python, a Rust and a C++ program in this thread which output the same thing given the same input, which, by the definition of expressive power of programming languages means that they are exactly as expressive as each other (given this information only and notwithstanding small differences such as error handling in this case).
Also you mentioned in your original thread :
> Even if the syntaxes were exactly the same (which they are not, python syntax is on average shorter)
indeed
> the low level nature of C++ requires your code to do operations that Python does need to do, such as memory management.
Notice that there is nothing which looks like memory management in my code. There are entire classes of programs that can be written without thinking about when to allocate or free your memory at all - just declare your variables on the stack and with std types, and that is handled for you (and that's not a modern C++ thing ! it's been like that since the very beginning). Opting in to memory management is an active, conscious effort in these cases (or a residue of people who only were taught java / c# at school and sprinkle their code with `new`).
I think it does, I should not require an external dependency for JSON. Having standard JSON support is far far more useful than another micro optimizations.
Eventual deprecation is not a valid justification for making current technology less useful.
Now I would buy your argument if C++ were as conservative as C, but it clearly isn’t. It keeps trying to push itself as a modern general purpose language, while ignoring what it actually takes to be useful as one.
The original post was about 'projects', not code snippets.
If you've done any serious (large, long, multi-team) projects in a dynamically-typed language, you know how quickly they turn into a big ball of mud where you're spending more time refactoring your refactorings than writing useful code.
The problem with GC isn't the "spikey 1%", it's the fact that GC implies the "everything is a pointer to an object" programming model, which in turn fragments your memory and destroys your cache.
Performance-oriented code implies everything is on the stack and/or packed into large arrays, at which point you don't need a GC after all.
Also, AWS sucks. It's the 21st century version of IBM mainframe, except without the reliability.