> Like you said, the fundamental idea behind the book was that consciously naming, cataloging, and studying design patterns would improve communication among programmers.
> The younger programmers I work with who had no exposure to the GoF book.....and they communicate amongst themselves just as efficiently as my generation
> The generation that learned to program after design patterns had faded as an idea learned just as quickly and communicates just as well as the generation that studied them assiduously as junior programmers like I did.
I've never read GOF so I don't know if they emphasize communication, but I have read and studied many other programming pattern books and communication is low on the list of reasons to learn them in my opinion. Their only purpose for me is to organize code in a way that has been proven to "scale" along with a codebase so that you don't end up with a plate of spaghetti.
> There's no type casting in Python. int(), float() and bool() just create objects of their respective types, passing the arguments to the initializer
int() and float() behave like type casting, bool() does not. It's a truthiness check that would be more aptly named istruthy(). In python non-empty strings are truthy, so providing any string except for "" to bool() will return True, including "False".
In C, cast converts a value to another type (or a more or less qualified version of the same type). What that conversion means depends on the source and destination type.
A cast of insert a conversion that wouldn't take place:
1/2 vs 1/(double)2
or coerce a conversion that otherwise requires a diagnostic:
bar *b = 0;
foo *f = (foo *) b;
Loosely speaking, casting is another name for coercion, which refers to making a conversion happen that might not otherwise.
Implicit conversion, which is what you're mostly referring to here, is not required. It happens in some languages, and not others.
Because I'm tired, and this is a very basic topic, I'm afraid I'm just going to rip from Wikipedia:
> In most ALGOL-like languages, such as Pascal, Modula-2, Ada and Delphi, conversion and casting are distinctly different concepts. In these languages, conversion refers to either implicitly or explicitly changing a value from one data type storage format to another, e.g. a 16-bit integer to a 32-bit integer. The storage needs may change as a result of the conversion, including a possible loss of precision or truncation. The word cast, on the other hand, refers to explicitly changing the interpretation of the bit pattern representing a value from one type to another. For example, 32 contiguous bits may be treated as an array of 32 Booleans, a 4-byte string, an unsigned 32-bit integer or an IEEE single precision floating point value. Because the stored bits are never changed, the programmer must know low level details such as representation format, byte order, and alignment needs, to meaningfully cast.
> In the C family of languages and ALGOL 68, the word cast typically refers to an explicit type conversion (as opposed to an implicit conversion), causing some ambiguity about whether this is a re-interpretation of a bit-pattern or a real data representation conversion. More important is the multitude of ways and rules that apply to what data type (or class) is located by a pointer and how a pointer may be adjusted by the compiler in cases like object (class) inheritance.
The difference between implicit conversion and explicit is just syntactic sugar: do you have to put some visible tokens into the code to allow a conversion to happen, or not.
Implicit conversion can be seen as the compiler deciding among several possible conversions (or possibly just one) and inserting the coercion/casting operator into the intermediate code to make it happen.
(Of course, this can be a run-time decision based on dynamic types also, but the reasoning is the same. E.g. the run-time sees that a plus operation is adding an integer and float, and can either signal an error (requiring the program to be repaired by inserting a conversion operation into the expression), or just do that conversion, like the integer operand to float.
It's the other way around. Implicit conversion is syntactic sugar for explicit conversion. Sugar is anything that is functionally identical, just notated more conveniently.
That said, I think you're correct about the casting versus conversion distinction. Languages frequently overload established terminology with slightly modified variants and it's incredibly confusing.
> If casting from a string to a type works with ints and floats, why not with bools? What possible justification is there?
> I'd honestly much prefer bool() threw an exception on receiving a string, rather than act the way it does now.
They serve fundamentally different purposes. bool() is a truthiness check and not a type cast like int() and float(). It seems like a lot of people take issue with the name, because it was called something like istruthy() the discussion about it wouldn't be happening.
> bool() is a truthiness check and not a type cast like int() and float(). It seems like your issue is with the name of the function, because if it was more aptly named to something like istruthy() this discussion wouldn't be happening.
Right, the bug is in the inconsistent naming.
It's roughly as bad as having arithmetic operators named +, -, *, / that perform arithmetic as usually understood, except that + actually performs XOR and is documented to do so.
> How does this work, though? Every company I've worked for has an HR system, and resumes flow through it, and there's a set process. If I have worked with a candidate in the past and highly recommend them, all I can do is submit their resume into the great void and check a box "Recommend
I haven't worked for any massive companies with thousands of employees where there might be a lot of bureaucracy, but the few I've worked for ranged from ~100-700 and it was pretty easy to get interviews for referrals. One of my employers encouraged referrals and offered bonuses if it led to a hire.
You seem to be emphasizing syntax rather than features of the languages and the stack itself. PHP was designed from the ground up for the backend side of web. Python, JS and Java were not. Many fundamental web development features are built into PHP like sessions, cookies, HTTP request variables, while a language interface server like Gunicorn or runtime like node is required to generate much of that from the incoming request and forward it to your application. Once it gets to your application either you or a library then needs to track those cookies, sessions, etc.. That's all built into PHP. So instead of a call sequence for a python/node app being request -> nginx -> Gunicorn -> python app, with PHP it's just request -> nginx/apache -> php app. There are plenty of other web-specific features that are dead simple in PHP like header redirects and HTML templating, whereas with python/node/java they have to be implemented by you, your framework or a language interface server.
I like index.php type websites, that are not verbose.
but PHP code that consists of 30+ composers modules, each with 10+ classes with overengineered OOP crap does not encourage me to touch this code with a 10ft pole.
This has devolved into js type of crappy coding, and I can use JS for that, dont need PHP.
I'm not exactly sure what you're suggesting, but blaming sloppy codebases you've seen is an unfair, cheap shot at the language instead of calling out bad developers, which applies to every language. PHP is inherently less complex than languages like JS and python for the backend and results in fewer dependencies because it comes with more features specific to web development out of the box. Quite literally no features required to build even a very basic dynamic website come with JS out of the box: sessions, password hashing, database connectors, input sanitizing, cookies, html templating, etc... It all needs to be either written by you or installed as a dependency. They're all standard features in PHP.
> And, as anyone who ever had to drive a car with a broken exhaust muffler can say, it's also nothing special...
Loud isn't the goal, the tone is. The Lexus LFA is a perfect example of this[1]. It's not extremely loud for a car of that caliber, but it's lauded as one of the best sounding cars ever made. Poorly designed exhaust (or no exhaust in the case of your broken muffler) on an otherwise great sounding engine almost always ruins the tone and makes it unbearable to listen to. Bad exhaust on a bad sounding engine is just miserable.
I wish this was actually the case in practice. There s definitely something special and musical about some ice engines, a true sensual experience.
But then in practice, people who actually value that (as in, pay money), their cars just ends up being loud and obnoxious.
So where are they, all these quiet, beautifully aurally tuned cars (emphasis on quiet)? Not everybody is driving thos3 lexusses just judging from the racket.
> So where are they, all these quiet, beautifully aurally tuned cars (emphasis on quiet)?
You won't notice them if you're not interested in cars, but there are tons of them and Lexus/Toyota are responsible for quite a few. The RC-F, IS500 and LC500 sound amazing, as did the GS-F and IS-F. Toyota also made some iconic engines such as the 2JZ-GTE in the MKIV Supra and the 2GR engine that Lotus used in the Evora.
> But then in practice, people who actually value that (as in, pay money), their cars just ends up being loud and obnoxious.
It's the other way around: There are plenty of cars that sound beautiful unmodified, and aren't unreasonably loud, but they tend to be the most expensive cars on the market.
So people often modify their cars to sound different, but getting a refined sound that way costs a lot of money. The cheapest modifications make the car sound terrible, so you're more likely to notice the cheap poorly modified cars than anything.
At the end of the day considerate people are going to drive any car quietly in a quiet setting. Inconsiderate people will start their car up in track mode at the crack of dawn on a Sunday morning and leave it to warn up for 20 minutes, and bounce of the rev-limiter going around town.
> remember the time when GM said it’s not going to include CarPlay in its vehicles? And how most of hn was in revolt?
Most OEM's made terrible infotainment software that is outdated, lacking features and often extremely sluggish and clunky to use. CarPlay and Android Auto are able to bring modern features OEM's can't seem to figure out, like Google Maps integration instead of some terrible maps implementation that is outdated, as in not having addresses added in the last few years, not just "old" and cumbersome to use. I can just open up google maps on my phone, type an address and directions appear on my screen. Same with music streaming apps like Spotify.
> here comes News that says we should get rid of touchscreens, why is hn supporting this?
Not eliminate touchscreens entirely, but rather stop putting every single control they possibly can into them making vehicles dangerous to operate. Putting climate, radio, lighting, etc... into a touch screen, especially when buried in sub-menus, is just lazy cost cutting. The other big complaint are touch capacitive "buttons" and sliders. They're distracting and difficult to use, especially on anything but perfectly smooth roads. For example, the Cayenne's interior is basically just a wall of touch capacitive "buttons"[1] that you can't easily reach down to press with your eyes on the road, you have to look down at it. The other issue is feedback from it. Constant beeping from input on menus, like Toyota, just becomes obnoxious. Buttons provide instant mechanical feedback that does't lave you guessing if you pressed on the right spot. Here's a clip discussing some complaints about VW doing all of this to the Golf [2] and how frustrating it is to use.
> The younger programmers I work with who had no exposure to the GoF book.....and they communicate amongst themselves just as efficiently as my generation
> The generation that learned to program after design patterns had faded as an idea learned just as quickly and communicates just as well as the generation that studied them assiduously as junior programmers like I did.
I've never read GOF so I don't know if they emphasize communication, but I have read and studied many other programming pattern books and communication is low on the list of reasons to learn them in my opinion. Their only purpose for me is to organize code in a way that has been proven to "scale" along with a codebase so that you don't end up with a plate of spaghetti.