Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×

Comment Re:Don't finance Experimental electronics. (Score 1) 148

Anyone reading this, please please do not finance a car's worth of money on some new gadget you're not even sure if you have a use for. I've had many friends do similar. Friends who took out tech loans from the university at 9% interest for a new gaming rig that was outdated in 3 years, and are still paying it back. Friends that would get behind on utility bills so they could get the brand new Gaming system. Just don't. Having entertainment and fun should be available for all, but do it with in your budget for heavens sake.

If you have 5k burning a hole in your pocket and you wouldn't' notice if it disappeared from your bank account, sure do it if thats what you enjoy.

This was exactly my thought when I RTFS, financing is for things you need to live your life, not toys.

Comment Re:Public is public (Score 1) 49

It being on Discord does not inherently make it public. Many servers are public, but not all. However, even if it's not a public server, Discord is still party to the communication and may be compelled to release it. Alternatively, stuff like this can happen.

Unless I have a contract with Discord saying that they will keep everything private, I'm going to assume all the data I send to them is public. Given the $0 I pay for their services, even if they have the worlds best security right now, I'm going to assume that they can at any point chose to make that security nonexistent when they so chose, and all of their data would become accessible by any script kiddie.

Comment Re:I get it, he doesn't like introverts (Score 5, Insightful) 112

If you get getting a CompSci degree just for the money -- don't. I have had many employees over the years and there is a direct correlation between people who don't really like to program (ie in it for the money) and getting yourself fired. Go find something you actually want to do for a career.

I think part of the problem is that a lot of employers don't want programmers. They want experts in aviation, automotive, finance, etc, who also happen to know how to write programs. While these people exist, I don't think they are as available as companies want, and companies should be willing to team experts in the field with experts in programming to develop whatever application they need.

Comment Re: Crank physics (Score 1) 243

Then you dont know what dark matter is.

Dark matter isn't a theory. Its an observation. We see the gravitation effects of a huge amount of matter, but we dont know what it is, and we can't see it. Hence its "Dark". The whole point of "Dark Matter" is its a placeholder term until we understood what is causing that massive gravitational effect.

Thats the difference here. Tired light is a concept that directly contradicts the observational data. Dark matter is observational data looking for a theory to explain it.

In science we do data, and if the theory doesnt match the data, the theory is wrong. And tired light does not match the data.

We don't observe dark matter. We observe movements of astrological bodies that the main current theory attributes to dark matter.

Comment Re:Is the language more important than the process (Score 2) 258

C and its derivatives have enjoyed popularity because of the low-level access to hardware provided. That same functionality has also led to a huge number of security holes and exploits.

Other languages, many of which are already considered "safer" for development of critical software (e.g. Ada), already exist. However, most of them are relegated to niche markets, and efforts to expand their acceptance have been met by resistance. The cost barrier to entry for Ada, for example, is simply prohibitive for many development teams.

Perhaps more emphasis should be placed on the development process, instead of the specific language used for development. If, for example, teams creating critical software (and the term "critical" is left to the interpretation of the reader) were to follow the JPL "Power Of Ten" development rules, the specific language being used for development wouldn't matter. Take away avenues for safety and security issues to enter the code, instead of relying on the compiler to catch and flag those avenues.

That's as far as I go.

Good developers will follow processes and develop code using best practices. Bad developers will abuse processes, but can't get around a compiler that enforces good coding standards. Good developers are a recurring cost for a company, compilers that enforce good coding standards are (usually) a one time cost. At least that is how I think it is all happening.

Comment Re:Developing programs vs engineering solutions (Score 1) 258

The counterargument is that if you're writing code before you're designing the solution, you're setting yourself up for trouble.

Why is it that every other engineering discipline designs their product first, then builds it, but software seems to have this idea of building it first?

Sure this is a reductionist observation, but my experience is that probably 80% of software problems are due to "write code first" instead of "think about it and design it first, then implement the design in code."

There's definitely a continuum of prototype vs design. Both a benefit and detriment of software is that it allows very cheap "prototyping" - the problem is the prototype is often then shipped as the product.

No other industry tends to ship prototypes to end customers, because prototypes are not robust.

I don't know why so many software folks - and software management in particular - are afraid of engineering discipline.

I think this is the main point, prototypes are excellent reference for developing the release program, but the prototype should never be released. And you are correct, there are two approaches to developing a final program, engineer it up front and produce a good clean program from the start, or experiment with a prototype until it works and then write the final program based on the prototype. Any program developed through experimentation will be buggy and cause problems if released.

Comment Developing programs vs engineering solutions (Score 1) 258

The more I write code the more I find that when developing prototypes I want the highest level language with the most hand holding. Python has become my go to for developing quick prototypes and proof of functionality, partially because it is easy to develop a quick program, along with the wide library support. C++ is when python is not fast enough, or the environment demands it, and an efficient solution has to be engineered around the constraints of the system.

I haven't used Rust yet as most of what we've done for a while are higher level programs where performance is not a concern. I suspect if I needed to engineer a new program I'd consider Rust in place of C++ as it seems to provide a number of benefits with few shortcomings. Though I'd have to research it more for that to be a definitive.

Comment Re:Not Keeping them Worse (Score 1) 114

Why would anyone expect a company to keep records which may represent a significant liability in the future?

Because not keeping those records is an even bigger liability. If they did have records then at least some of the blame attaches to those who did the work. Without any records not only does all the blame attach to management but the lack of proper record keeping is more evidence of their incompetence.

And not just blame but when a detailed cause of a failure like this is discovered, a specific corrective action can be created. We screwed up is bad, we screwed up and we don't know how is worse, we screwed up and identified the reason and are fixing it can help keep a companies reputation intact.

Comment Re:So... (Score 1) 147

"It should be owned by a US business. There's no way the Chinese would ever let a US company run something like this in China."

So, we should be more like China... got it...

Based on the article being discussed, China says no we should not be like them.

Comment Re:You can boo all you like (Score 1) 65

Time and money that could be significantly reduced by doing things properly in the first place.

I've heard many people say this as if it's a proven fact. It isn't.

In many situations, a crappy first pass saves time.

For instance, machine translations save time for human translators. They use an LLM to do a first pass and then go through and correct the mistakes, saving 40-60% of the time it would take to translate the entire text directly.

The same is true for LLM coding. Tools like Copilot make blunders, but they often produce a good framework, and many sections are correct, saving about half the time a competent coder would need to write from scratch. LLMs can also help with writing unit tests.

The same will likely be true in show business. LLMs will write scripts and lyrics requiring touchups but less human effort. Generative AI is already having a big effect on CGI.

It was in the case I worked through (anecdotal I know). The outsourcing was for safety critical software testing. The result was a massive amount of manual testing that took hundreds of hours to run, failed to produce the proper software coverage, and in some cases failed to run properly. I heard from people dealing with the results that they asked the outsourcing company about the tests that failed to run, the response was along the lines of "we didn't think you would look at that".

In order to fix the tests we had to go over each requirement and identify all of the necessary tests to get the appropriate coverage, then update the existing tests to add the missing pieces. It ended up taking less time in most cases to just scrap the tests and create new ones. Further we could replace massive amount of manual test procedures with automated tests that could be run in a fraction of time of the outsourced ones.

Comment Re:You can boo all you like (Score 2) 65

I know how this is going to be modded because uncomfortable truth is uncomfortable, but I got karma to burn so do your worst.

I can say about AI only what I had to say about unqualified offshore work: If you are threatened by something that does a shoddy job at what you do, there's something wrong on a different level.

Because either quality just doesn't matter whatsoever, or you're doing a shoddy job yourself so nothing of value is lost by handing it to someone doing a crappy job cheaper.

And considering how the writing in some of the more recent movies was, I cannot say that I'll expect a lot of quality loss if the task is taken over by some half-baked AI doing a mediocre, derivative job, probably just rehashing some of the hits of the past and mashing it together with other crap, adding a dash of contemporary "must have" (at least according to studios, because you have to cram in some ethnicities for that all important foreign market, because I would clearly only watch a movie if someone like me is in it...)...

And I fail to see the difference to the crap that is already produced by human writers.

So bluntly, if your job is threatened by something that does a crappy job at what it does, I think the problem is that you're not really doing a better job, or that nobody wants a better job done.

So blame the person currently holding that job for not doing a better job, or blame the customer for not demanding a better job. Your pick.

There is a lot of truth to this point. A number of years of my career were funded by companies fixing poorly off shored software projects. I bet a fair number of jobs will be provided to find and fix mistakes made by AI created products. Time and money that could be significantly reduced by doing things properly in the first place.

Comment Re:Think of all the things we'll be able to accomp (Score 2) 27

The can't wait to see all of the amazing things this AI will be able to accomplish. I plan on asking it to write a program to solve the halting problem. After that I'll have it tackle world hunger and after it knocks that one out, maybe an app to tell me whether or not a tie goes good with my outfit.

I don't know if the AI solutions will be good, but I bet it will be very confident about whatever solution it comes up with.

Comment Speaking the same language as the LLM (Score 1) 68

I'm not an expert, however I've done some development with using LLMs to process text. I feel like LLMs break down text by concepts. If you want to parse a document for key concepts or summarization, you need to talk to the LLM in the language it is using for these concepts, not the language you think you should use for those concepts. This I think is a very good use of AI prompt engineering.

Prompt engineering to get the LLM to generate something, rather than deconstruct a document, I don't really even want to go there.

Comment Re:Will the market bet against AI? (Score 1) 151

LLMs and Stable Diffusion are not blockchain. There is already clear and realized not anticipated commercial applications.

Even if the extent of it turns out to be, stock photo and marketing materials generation, basic customer service interactions, 'auto summary on steroids' for documents, e-mail threads, primer research, a search result aggregation; it has already proven to be useful. Just about every business larger than "Joe's Lawn and Power washing" and maybe even Joe is going to want to some.

Now is it going to completely alter the world they way some people think it is? I don't know. However a market bet against AI (general) vs a specific company or product family, would be like betting against Relation Database technology in the later 70s because the office will never be entirely paperless.

And internet companies in the .com bubble had clear commercial applications, some of those companies are worth billions to trillions now. That didn't prevent a major crash in the value of most of the internet companies at the time.

Slashdot Top Deals

Prediction is very difficult, especially of the future. - Niels Bohr

Working...