@LaoC said in Enlightened:
Morbid curiosity drove me to look for the remains of this dumpster fire.
@LaoC said in Enlightened:
Morbid curiosity drove me to look for the remains of this dumpster fire.
@Kamil-Podlesak well, when I was working there, they did tell me using any language other than Korean is wrong...
@Steve_The_Cynic looking at how it's implemented, I bet it uses the main alarm volume, which tends to be as high as possible.
@sh_code hint: people fall asleep faster when they're relaxed. Having a horn suddenly blow in the middle of the night isn't exactly relaxing.
New Samsung phone, new "fun" feature. To be completely honest - I don't know if Samsung is the author or Google, but only Samsung is capable of creating something that stupid, so I bet on them. I present you a "go to bed alarm". What's wrong about it?
FFS...
What's also ironic about this situation is that people actually wanted to attend and he fucked them all
@dcon said in IT departments of the world:
@NeighborhoodButcher said in IT departments of the world:
So everyone knows how this would end anyway.
And the training is one of your required OKRs, right?
Actually no - I genuinely wanted people to learn something.
@boomzilla said in IT departments of the world:
@NeighborhoodButcher fair enough. "I can't possibly win this war," is different from how I understood the situation.
Such war is never good regardless who ends up on top. The winning side would be labeled as a troublemaker too. Nevertheless, this situation is another argument for my original thesis.
@boomzilla said in IT departments of the world:
@NeighborhoodButcher yeah but it sounds like you're already in one, you're just not fighting back yet.
The problem is - we're working in different countries and he's in the one with management. So everyone knows how this would end anyway.
@PotatoEngineer blocked, as in "went to upper management and talked bullshit". I'm thinking about escalating the issue, but an internal war is never good for anyone, regardless who is the asshole.
Fast forward to today. I was supposed to do a training on a certain technology. One of the ops guys doesn't like it, so he went behind my back and blocked my training. Without saying a single word to me. That's another level of arrogance here.
@Atazhaia said in Enlightened:
in the thread for Samsung trying to make their devices "smart", which is always a very special kind of the S in IoS
It's no coincidence Samsung rhymes with "shit".
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
The null reference is a completely logical and natural thing to do to represent a common use case in a very efficient way.
Just like the absolutely safe and error-proof nullable pointer in C...
@hungrier you're missing the point(s) here. It's not that you don't have checks - you do. The point is that empty values are explicit, not implied. The point is that you cannot pass one by mistake. The point is that you cannot use a possibly-empty/null value by mistake. If you try, the code will not compile, rather than explode at runtime.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
I just see no need for enforced no-nullness across a language.
Ok, but you also need to realize that's a subjective feeling - if you don't see a need for something, it doesn't mean there is no need.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
Maybe I'm crazy, but I really don't see any reason for this to exist. It's just as complex to write (maybe even a little more?) and provides very little benefit, based off of everything I've done. In terms of issues I've actually encountered, null problems are like... 0.001% of them.
Therefore I can only encourage you to try to use it and you'll see the difference both in quality and productivity.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
Right, so instead of null checks populating your code, you have Optional checks populating your code?
Yes, and that means you cannot pass an empty value, where it's not explicitly expected, therefore avoiding accidentally passing them. You also cannot get the actual value back without checking for it's existence, therefore avoiding accidentally accessing empty values. You also get means to expressively show if something is required or not, on the language level, therefore avoiding unnecessary checks. If you make a mistake, the code won't build, rather than exploding at runtime.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
In this theoretical utopia of non-nullness, how do you handle, for example, a Customer that doesn't have a Birthday set? Do you have to make the Birthday an Optional<Date>?
That theoretical utopia is called Rust: https://doc.rust-lang.org/std/option/
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
And I disagree with that, because, in my experience, you'll just end up making everything optional anyways.
Then you have some painful experiences. I'm in this industry ~20y and I'm yet to see such approach, thankfully.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
Right, I'm aware of the quote and I also disagree with the over-generalized argument, which is "All null references are bad"
@NeighborhoodButcher said in Waaah, I don't get paid to use new shiny languages:
The problem of null is not that it exists at all, but that it exists in its current form, where it cannot be excluded as a valid value at compile time. If something is optional, if should be explicitly optional.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
but nothing you've said has succeeded in pivoting that, in my mind, to strongly typed languages that allow for null
Instead of me copy-pasting, you can google it for yourself, starting with that quote, which comes from the person who invented null in the first place.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
What about strongly typed languages that allow null values, such as Java or C#?
That's the billion dollar mistake.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
Not really - if this was statically typed it would still be just as easy to pass in -1 or 8 (chosen from a perfectly random dice roll), or 2147483647.
By invalid number I assumed you meant e.g. a string.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
But what bug, exactly, could happen here?
Passing anything that is not a number. A typical bug with using an invalid type with dynamically typed languages. That's why strongly typed ones are safer in this regard.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
If you're operating on data you're being given without checking that it's valid first, that's a bug waiting to happen anyways. And if you're checking if it's valid, the null check comes free!
Your making some incorrect assumptions here. First, you assume passing a value which is not valid in a given context is a bug. If a function contract is "give me ANY numeric id and I'll check if it's ok and return an error otherwise", passing a logically incorrect value is not a bug. On the other hand, passing e.g. a date object would be a bug, because you're breaking the contract and a compiler might allow it. Again, that's why strongly typed languages prevent such classes of bugs.
Second assumption is assuming we're talking about primitives. We can imagine an example function calling foo() on an input object an expecting it to be of a given interface. If there's no restriction on that interface, someone can freely pass anything which has a foo() method, thus potentially introducing bugs. What's more, someone might even pass a null, which was the starting problem.
In the end, I see I'm teaching someone the differences between strongly and weekly typed languages, which is pointless, given the amount of resources on that subject. Go look it up yourself.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
Sure, and part of why things like uid and roomId can be null is because of Javascript being weird.
That's the problem with all languages having implicit empty values like null.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
But at the same time, assuming that, since they're "IDs", they're numeric, what's preventing the caller from passing in an invalid number?
Nothing - that's a problem with dynamically types languages.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
How does enforcing that it can't be one invalid value help when you have to check to see if the value is actually valid in context anyways?
That's limiting the number of potential bugs. With strong type systems you can require the value to be both present and be a number. That's a pretty strong contract to begin with. But checking if it has logical sense in a given runtime context is another thing entirely.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
The way I'm understanding what he's saying is that there's a problem here, because you have to check to see if any one of that long list of variables is null. What I'm trying to say is that in the real world, you don't have to check for that anyways because it's effectively impossible for them to be null anyways (and if they are, you have bigger problems).
And he is absolutely right - you assume the caller of the function will respect its contract, but you don't have any means to enforce it. That's the typical run-time nullability problem (and the "billion dollar mistake"). Some languages can enforce it by their type systems, therefore you don't need to assume anything - it's impossible to pass empty values.
@sloosecannon it that case I think you misunderstood the example. If a language has explicit means of expressing the lack of value, there's no possibility to pass a null-ish value without a build error. In other words, you can only check for null at run time in Java, but mistakenly passing a None value would result in a compile-time error in Rust.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
Wait, Rust can prevent my database from ever becoming disconnected at runtime?
Show me a language where non-null db connection suddenly becomes null when connection is lost. Or, in other words, stop with the red herring.
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
I genuinely cannot remember encountering this. Sure, you might have a variable that's being passed in that can be nonexistent, but that's rather the point of null, now isn't it?
The problem of null is not that it exists at all, but that it exists in its current form, where it cannot be excluded as a valid value at compile time. If something is optional, if should be explicitly optional.
@Gąska the article looks like the guy simply went through wikipedia descriptions of each language and thought: "it looks like C, so it must have C problems; it has null, so it's basically Java; it has GC, so concurrency is simple".
WTF is this garbage article? This guy mixes concepts all around and spreads misinformation time and time again. I like how literally every thumbs down of Rust is false:
Rust is the only modern language on our list with no garbage collection. This forces the developers to think about low-level memory management and makes developer productivity suffer.
I have yet to see any manual memory management in Rust, despite no GC. Granted, some extremely low-level crates might use it, but for the most time, nobody will ever touch an allocator. The language forces to NOT think about this stuff.
Due to the lack of garbage collection, concurrency is rather hard in Rust.
FFS, show me another language which gives me the guarantee of no synchronization bugs for formally correct programs. If it builds, you have proper concurrency - can't get any easier than that. If one wants to write in the unsafe dialect and shoot himself in the foot - it's possible, but it needs to be explicit.
Rust has no built-in support for immutable data structures.
Everything in Rust is immutable by default.
Being a low-level language, developer productivity in Rust can’t be as high as in other higher-level languages.
That depends on the definition of high-level. Rust does have ORMs, web frameworks, DI containers - all the fancy stuff to write high-level code. Where productivity might suffer is not related to being high- or low-level - it's rather the safety mechanisms built into the language, which can be a hinderance.
@kurkosdr of course it's here to stay. Anything else means Samsung admitting bad decisions, and no Korean will ever admit to that.
@Zenith said in IT departments of the world:
It shows a lack of leadership in your organization. IT knows they'll keep being paid whether or not they deliver anything resembling results.
That's actually an interesting angle, when I think about it. In some cases, there were results delivered, but they were orthogonal to problems arising in development. Therefore management saw something was being done, but never saw how many problems slipped by.
In other cases, the management was a part of the problem. In my previous company, the VP of operations was known for doing everything to avoid any kind of work by his department. I remember one absurd situation when an internal QA ticket (where internal QA was a platform to identify and solve problems within the company) related to IT was totally dismissed by him, and later he marked it as resolved in my name.
@mikehurley said in IT departments of the world:
It's thanks to those kinds of people that we have bogus concepts like "internal customers."
That's essentially how whole Samsung works.
@Zenith while the quote is true, it doesn't really apply here, since we're supposed to be peers working together to find solutions, not a leader and team member. Yet, it seems one side wished to talk about solutions, while the other wants to talk about how much they're offended by the notion of having some work to do.
Let me share an observation I had recently and ask you what is TRWTF here. I've been in the industry for quite some time and I've worked in a few very different companies with different work cultures. Each case had one common point - every time the infrastructure/IT department people were acting like complete assholes. I don't know what the underlying reason is, but every conversation I've witnessed or taken part of, resulted in them taking a position of "how dare you take our time to ask for something?", "how dare you propose a new service, even when there's a business case?", "how dare you ask us to unblock customer's access to the service they bought after we firewalled them for no reason?". No matter how polite the people trying to have a conversation are, the other side always responds with a full-scale nuclear attack. Mutual respect? Why bother! Trying to work together? Nah. "We make the rules and everyone has to conform!"
Are IT departments TRWTF?
Is my luck TRWTF?
Is my career TRWTF?
Today, for no reason at all, I was contemplating undefined in JavaScript, and what a wonderful mess it is.
> a = {}
> a.b
undefined
> 'b' in a
false
ok
> a.b = undefined
> a.b
undefined
> 'b' in a
true
ok?
> typeof undefined
"undefined"
> undefined = 1
1
> typeof undefined
"undefined"
ok...
> a.b = undefined
undefined
> typeof a.b
"undefined"
> a.b == undefined
true
> a.b = null
null
> typeof a.b
"object"
> a.b == undefined
true
...ok
> a.b = {}
{}
> typeof a.b
"object"
> a.b == undefined
false
?ok
Since undefined
is a defined property of undefined type, you can define another undefined property using this defined undefined one.
In the Focus assist settings page, Windows 10 is adding a new automatic rule to let remove distractions while you’re working on anything in full screen.
The biggest freaking distraction is the whole taskbar not going away when watching a movie or playing a game. I dare them to remove it.
Those of us familiar with Docker know it generates random two-word names for running containers, if you don't provide them yourself. This is a nice feature to have, since you don't need to bother with unpronounceable hash identifiers. Until one day you have to tell your customer to stop "amazing_cocks". Good show, Docker. Good show.
At first I wanted to point out all the logical fallacies in this wall of text, but then my brain overflowed.
@AlexMedia said in Samsung, bunch of *****:
Seriously, did they even test this form before it went live?
Let me tell you how the testing process works at Samsung:
@Gąska said in Google Translate is still bad:
The second translation is accurate.
Zatwierdzam to tłumaczenie.
@Cursorkeys said in Enlightened:
@Gąska said in Enlightened:
@Gąska said in Enlightened:
Oh great, now I'm getting upvotes on post I don't even remember writing! I hate when people bump ancient topics.
AGAIN
BITCH!COMPLAIN
FTFY