|
4C came about in 1986 when Dennis Noon and Kevin English decided that they needed a better tool for writing business applications. Machines were getting more powerful and customers were demanding more features. After searching and trying multiple tools that promised to solve this problem, they found that they kept running into the "Brick Wall Syndrome." Some of the tools were easy to use and easy to write simple programs with. Unfortunately none of them made the real hard problems easier.
So, command line switches for the entire toolchain it is, then!
In fact with some of the tools, you just couldn't write complicated programs at all.
Guess they haven't kept up with the times. They should try honey's template metaprogramming!
|
|
|
|
|
In the history page the DNA something that uses that software/framework/whatever it is says "Programs are 90% self-documenting" so I guess you don't need documentation. Unless you need the missing 10% to solve your problem.
Honestly, some of their other pages scary me more than missing documentation.
Quote: Security - Updated 19 November 2013
Known and Fixed Bugs - Updated 26 June 2009
The lack of bugs I can concede that they are brilliant at their jobs. But the last security update seems outdated. A lot has happen security wise since 2013.
I agree with you. That site is depressing. Somebody hide all the knives 
|
|
|
|
|
It doesn't even show the slightest prospect of beginning well!
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
One of the most profound examples of NIH(*) syndrome I've ever seen.
(*) Not invented here
Software Zen: delete this;
|
|
|
|
|
|
And this software is allegedly used by some companies in higher-risk business areas...
Some 4C Application Developers
> DNA Data Systems is the premier medical software provider in Southern California.
> Forte' Data Systems Provides technology solutions to insurance companies and automobile claim centers that allow them to verify part prices on claims and process sales more efficiently.
> Trafxs Expert Systems Develops, installs, and maintains integrated software applications for the petroleum industry.
|
|
|
|
|
|
However, proponents of cryptocurrency say owning the NFT carries clout and bragging rights - and that simply right-clicking and saving an image is not the same
It is to me. I personally put as much value on a copy of the Mona Lisa as the original--and vice versa (what would I do with that thing?) Being able to prove you "own" the original is just that, a bragging right.
And given that anything digital can be copied infinitely and you end up with the exact same sequence of bits makes it all even less worthy of anything, IMO. The quicker the whole concept of NFT can be ended, the better.
|
|
|
|
|
I'm so far ahead of the curve at work that I'm already done with work for this week. Anything else I do is just me getting ahead - and I'm already way ahead.
My client is thrilled with the new screens. I'm just waiting on some level shifters to get here before I can test some things, and then waiting on the prototype board to be finished being laid out and fabbed.
It has been a good week so far, and it's only monday. I may have time to write another CP article after all.
Real programmers use butterflies
|
|
|
|
|
Stop being a wimp and just hook everything up to the same voltage source, then increase the voltage until it is all running. A bit of smoke never harmed anyone,and waiting for level shifters is just a bad excuse.
|
|
|
|
|
Actually I already did that (minus increasing the voltage) but my I2C bus kept collapsing and kicking my flow meter offline. 
Real programmers use butterflies
|
|
|
|
|
Clearly a case of too low voltage!
|
|
|
|
|
Swing the chicken the other way.
|
|
|
|
|
Why does that sound dirty? 
Software Zen: delete this;
|
|
|
|
|
|
|
And it is a training excercise, setting expectations, your client will now expect such performance every time. I am of the belief that you should only exceed expectations by a minimal amount then when you hit a nasty you have some leeway.
After 14 years with the one manager I eventually had to ignore his deadlines as they were too unrealistic. A manager/client will ALWAYS take advantage of excessive deliverables, it is their job!
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
This client is an electrical engineer, and we collectively are developing a product for another party.
He's very reasonable, and my pace has consistently been really good because I always give myself lots of padding. I estimate what it takes a typical developer because frankly, I don't know how else to estimate myself, but I also consistently and profoundly outperform my estimates.
That said, I've been clear with my client that my estimates are what they are based on experience. He seems to respect that. And we're not under collective pressure because the end end client doesn't have much in the way of deadlines - they just want to see progress, and that's easy.
Real programmers use butterflies
|
|
|
|
|
Lucky you...
Nice to find the exception to the rule 
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
honey the codewitch wrote: It has been a good week so far, and it's only monday. I may have time to write another CP article after all.
Don't say the Q word.
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Agile has been praised in the IT world almost as a religious cult; and a cult it is. Those managers who buy into this IT kindergarten principle have created an increase in IT costs that wouldn't make sense to those who see it for what is it - a huge time waster that can be replaced by being accountable for your work.
Furthermore, paired programming has certainly been curtailed because of the push to work from home. Yes, virtual meetings can allow the process to take place, but now in a more cumbersome way.
I say this because I watched a company I worked for go from getting praises and glory emails from the business partners to silence, crickets. Business meetings that turned into an hour long dead silence, or worse, many that did not even show up, or those attended became much more muted or even silenced; afraid to push back on the nonsense of it all.
We went from cubes to cubified areas, to picnic tables where noisy phone conversations, casual chatter, and people shuffling around the room, reduced concentration to a trickle. With the meeting schedules, you are lucky if you get 2-3 days of work done a week. Multiply this times the number of days for the project to complete and you get into a real problem of proving that the expense is truly worth the time.
I won't even get into the paired programming philosophy, where you have just doubled the cost of development on an on-going basis.
Projects that took several months to complete now take a year or more. Anyone with any common sense simply cannot justify the added time and expense that is supposed to be offset by the claim to reduce scope creep and code errors.
IT groups who push back and slam the door on businesses who attempt to add additional functionality many times end up losing in the end as being inflexible.
Agile preachers will produce data and charts pointing to how you will really save time by suffering through all this. Large sessions are put on by Agile evangelists praising the Agile gods for giving us this process.
This is especially true of projects where only 1 or 2 people work on it. While I would admit that the IT groups in a project that requires more than 3 people need to have meetings to make sure everyone is on point, it does not need a full blown carnival of meetings and daily stand-ups to accomplish this.
|
|
|
|
|
Wrong forum. Make it a blog post.
|
|
|
|
|
Our team went through the same pain years ago, when consultants in the US tricked convinced management to go this route. So we followed the rules until the deadlines got too near, when we were told to revert to our normal mode of working, and get the job done.
|
|
|
|
|
Richard MacCutchan wrote: o we followed the rules until the deadlines got too near, when we were told to revert to our normal mode of working, and get the job done.
That's funny. You were less agile with Agile, but more agile without it.
|
|
|
|
|
That's what I told my management when we were told we had to start doing (sorry) Agile.
Me: "We're already Agile, have been since the beginning of the project."
He: "Oh, but we'll use Scrum."
Me: "We looked at Scrum, and adopted a few of their ideas, but our project isn't suited to Scrum. Scrum would slow us down."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
