281–290 of 297 posts
Earlier quoted context omitted.
> Although it does provide shortcuts for automatically generating accessors which I don't think Smalltalk did / does. Most Smalltalk browsers do actually offer this capability
The tooling does provide that yes, as it does in e.g. Java. But Ruby does it without tooling, the feature is a runtime message to the class object.
Earlier quoted context omitted.
The modern aggressive undefined-behavior based optimizations ruins any remaining appeal of the "simplicity" of C for me. The extremely broad definition of undefined behavior may allow the compiler to, for example, silently delete explicit checks for signed integer overflow [1] among other things and still claim standards compliance, but I don't think that programming model can reasonably be described as simple. It ma…
Lots of programs don't need efficiency in "hot loops". You want efficient code size everywhere (usually smaller is faster), and realtime programs like games are CPU-bound everywhere not just in one loop. Undefined behavior is a great way to help the language help you; for instance, most loops look like infinite loops without it. All you need to do is test with ubsan to see if you're dynamically undefined anywhere.
Isn't this a simplification? Even for games, I'd expect most often to be GPU bound, then memory bandwidth bound, and only then CPU bound. Although I get that the hot loop thing/10% rule is not universally true for every CPU bound program (especially after code has already been heavily optimized).
But I'm not sure what you are disagreeing with. I didn't mean to totally deny the usefulness of UB in C++ (although I think the core rendering code of AAA games are more performance sensitive than "the majority of most programs"). I was just pointing out that C is certainly not as simple as it first appears, and many people new to it are not familiar with the rules around UB.
Go's able to design around some of the performance aspects without UB (using the native word size for ints by default can help some of the signed integer stuff, range loops can elide bounds checks, etc), but probably can't generate as optimal code as C can without dropping to assembly language.
Earlier quoted context omitted.
The entire build process for java is mvn package. The only xml you encounter in modern java will be your pom.xml. How is that any different from a package.json, go.mod, cargo.toml, or Pipfile?
And then I get a jar. Or maybe a war. Or maybe a zip? And maybe it's a fat jar with all dependencies bundled. Or maybe not and I need to fetch a bunch of deps and configure a classpath. And then I need the right JRE wherever I'm going to run it. And then I can run it like 'java -jar'. Or maybe I need a server like Tomcat. Or maybe something else. And every time you jump into an existing codebase, you need to scrutini…
Earlier quoted context omitted.
>> Go's standard library is an order of magnitude (at least) better than Java's, much more comprehensive, much more cohesive, and much more capable Can you please provide some examples? This would be a useful comparison, as Java had way more time to work on the libraries.
Don't you think it'd be the other way around - the older a language gets, the standard libraries degrade since you can't introduce newer patterns without breaking compatibility.
Yeah it is tricky, but Java has a good track record here:
In 1.2 they added all-new Collections API. The old API is still there and still works, though it is not used much these days.
Then in 5 or thereabouts Collections API got generics.
Then in 8 or so, Collections API got streams, magical multithreading etc etc.
Lambdas were added to the language and standard libraries, and so on.
Earlier quoted context omitted.
My one-line workaround. (Yes, I ban go fmt .) v := a; if t { v = b } Sadly, this doesn't work well if a is a function call :-(
Out of curiosity, what's the motivating case for using Go in 2019's programming landscape? Edit: I didn't mean this as an insult, I meant it as a genuine question. I don't know much about the Go ecosystem, and I meant to find out what Go's killer feature is in 2019, when other languages now have strong and elegant concurrency, C-like performance with higher-level syntax and without manual memory management, etc.
Fast compilation speed, easy integration with C, and the "one large static binary" are probably my favourite features, although I do wish those binary sizes weren't quite so large...
I thought one of the basic lessons we learned from the last 70 years of programming language design is that it's a bad idea to make semantics depend on lexical structure. I'm really surprised people like Rob Pike and Ken Thompson would design a language where the visibility of an identifier depends on the case of its identifier.
Interesting. Do you have links? Or maybe a short summary why this is bad?
* Changing the visibility of a variable requires changing its name, everywhere it's used.
* It also cuts contrary to some very long-standing traditions, like using all caps for global constant names, using title case for class names, and starting with lower case for most everything else.
Earlier quoted context omitted.
Why do you keep sidestepping logical arguments with irrelevant quotes? Correct programs don't contain UB (even the fast ones), so UB is not what makes C fast. Not checking for UB (aka invalid configurations) at runtime is what makes C (and any other language) fast - or more precisely, it's what allows compilers to emit efficient code. Some languages / compilers rule out UB statically through the type system or other…
Because C guys keep spreading the false arguments that C was some kind of language sent by god to solve all performance issues, while we in the trenches when the language sprung into existence know it wasn't never the case. Not to mention the fact that other programming languages, on the mainframe and workstation space, were already starting to collect the benefits of whole program optimizers.
Earlier quoted context omitted.
Why do you keep sidestepping logical arguments with irrelevant quotes? Correct programs don't contain UB (even the fast ones), so UB is not what makes C fast. Not checking for UB (aka invalid configurations) at runtime is what makes C (and any other language) fast - or more precisely, it's what allows compilers to emit efficient code. Some languages / compilers rule out UB statically through the type system or other…
Because C guys keep spreading the false arguments that C was some kind of language sent by god to solve all performance issues, while we in the trenches when the language sprung into existence know it wasn't never the case. Not to mention the fact that other programming languages, on the mainframe and workstation space, were already starting to collect the benefits of whole program optimizers.
Earlier quoted context omitted.
There is no spec for go fmt . Its behavior has changed across releases. It has no switches to disable features. It destroys many nice single-line constructs, e.g. if err != nil { return err } Much of my code would be painful to read without that one. On the bright side, it artificially inflates your line count, so you appear more productive!
I think we're going to have to disagree there, then - yes that oneliner might reduce your LOC count and help you win at code golf, but it doesn't actually make things more readable and certainly isn't worth breaking from the rest of the community. The ecosystem-wide consistency of go fmt is its biggest strength. Adding switches to disable features would eliminate that.
I've put a lot of thought into my style guide, and anyone who hasn't done the same has no useful insight on whether go fmt is a help or a hindrance.