|
The same feature creep happened to ER data modelling. I was even in a project where we added to the established ER some new extensions. If I were to do that project again, I would have fought against all extensions, insisting that we stick to the simple, easy-to-understand for everyone, basic mechanisms.
The simplicity of the ER tools gave us a great success in another project: We modelled the complete information structure managed by the city administration. Even people who had never before used a computer (this was in the early 1980s) were able to give valuable, constructive feedback on the model. If we had introduced the ER extensions that we created for the other project, those non-computer people would have had a far less chance of getting involved in the model discussions.
|
|
|
|
|
Some of the delights of x86 assembly language were the small number of registers and the extreme non-orthogonality of its instruction set. I used to delight in writing highly optimized code for it.
The x64 instruction set is easier to code for in most respects, but some of the fun has gone out of it. OTOH, compilers have become better at optimization so the number of cases where hand-optimized assembly language is required is much smaller.
That's progress for you
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
I never programmed PDP-8 myself, but I know people who did, telling how they never allocated a constant in memory if there happened to be, say, an instruction within the same memory page having the same bit pattern as the constant they needed: Then they could reference that location, rather than wasting an entire word (12 bits) for a second copy of the same bit pattern ...
Well, I guess that was 'fun', sort of. I prefer to leave the fun to the compiler. If it finds the desired constant value bit pattern as some instruction code it has already generated, I'll let it have that fun - as long as it promises not to assume that the same reference is valid when the code changes to a different value.
I did play around with assembly programming for a few years. I got (and still have) the impression that most of those touting assembly as a way to speed up you code rarely compare the actual execution time for compiler generated code compared to their hand assembled one. With modern CPUs, reducing the number of instructions within a tight loop may have next to zero effect on execution time; reducing the number of iterations is far more significant - and can be done in a high-level language as well. I never had an assembly programmer tell me 'Look how much my assembly coding speeded up the application at the end user interface level!' - it is always 'Look at the speedup of this 17-instruction innermost loop!' And quite often, the assembler coder shows me how he has eliminated loops, in a way that could have been done in the high-level language as well. Yet, unrolled (/modified algorithm) code is compared to iterating HLL performance.
Imagine that you could set up with PCs with identical applications, two of them with given modules coded in assembler, two in C, and the fifth may be either variant. Set up an automatic process to enable either variant on either of the five PCs (keeping the 2 + ? + 2 distribution) and invite end users in to run the applications on all five machines, and 'vote' whether they think that the application is pure high level code or has essential modules assembly coded. I am afraid that the verdict would be rather disappointing for assembly coding addicts.
Quite often, the speedup gained from assembly programming is not primarily due to inefficient code generated by compilers, but because assembly allows direct access to specialized hardware functions. If end users in the blind test described above were, with some statistical significance, able to identify the assembly coded alternatives, I am quite sure that a closer inspection would show that the assembler coders were using hardware not utilized by the high-level language code. A compiler ready to use the same specialized hardware can generate (for all practical purposes) equally efficient code. That is one of the good things about .net and JIT compilation at the target machine: It allows the JIT compiler to utilize any locally available hardware which is not necessarily available in other contexts.
Assembly has two essential purposes: To access hardware facilities not otherwise accessible from high level languages. And (not unrelated to the first!) as an educational tool to see how the computer works at the machine code level. See what the compiler is going after.
For general code, not accessing specific hardware functions, the compiler will be a lot better than you to generate optimal code. It has been that way for at least thirty years. Even the FORTRAN II developers had to spend great efforts to understand how their compiler had been able to discover how a piece of code could be twisted around to execute faster, even if they had written the optimizing algorithms themselves. It is sort of like a chess championship: Cheating is based on advice from a computer, not from a human grandmaster.
|
|
|
|
|
We are mostly in agreement.
I agree that on most modern CPUs, optimizing compilers can make good use of the processor features and produce code that is difficult for humans to optimize further. As you say, this implies that human time is better invested on algorithmic improvements.
Thirty to forty years ago, on x86 CPUs, it was both possible and sometimes necessary to rewrite inner loops in assembly language. Creative usage of the instruction set allowed some incredibly fast code to be written.
I did not say then and do not say now that it makes any sense to write anything other than innermost loops with extreme performance requirements in assembly language. I did say that writing such code was a challenge, and fun.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
You know the ride you're getting when you buy that ticket.
JS is more like subway fare into the heart of a metropolitan dystopia where your stops are unscheduled because all the stops are ever-changing with the tides of civil disobedience and outright subterfuge.
|
|
|
|
|
No matter what someone answers, it will be interpreted as that responder not liking that language.
In, my case, among those options, I've used only C, but if I answer C, you'll think I don't like C, which is untrue.
It's a very bad question. A better one would be to have responders rate a number of languages. I think there was one such survey not long ago.
|
|
|
|
|
|
No compiler, so you don't know that you used a comma instead of a period until runtime. And the code will just appear to not run at all when it has just gone into the weeds. Plus the 7 ways to do one thing, etc etc.
I'm still grateful for it though.
|
|
|
|
|
Sue me, but I like all the ones listed. Well - I've never coded with Objective-C so I guess that could be an answer
|
|
|
|
|
Similar with me. Have tried many of them, but none of them by Apple that's trying breaking my dev-freedom.
Beside C#/PowerShell/bash, other that most are JS, PHP, CSS, HTML, and SQL.
Something about which we often break our head:
"In the name of the Compiler, the Stack, and the Bug-Free Code. Amen."
(source unknown)
|
|
|
|
|
Those are the one I really can't avoid.
Sometimes I just need them (like for automated deployments)
Whatever I do in these languages, it never works.
I always get stuck on basic stuff like declaring a variable.
JavaScript isn't so bad once you get to know it and the language is really improving too (although it will never be my favorite).
I haven't used the others (much) and they're quite easy to avoid.
Just don't use them, really
|
|
|
|
|
|
LOL. At least it "compiles" and has an optimizer.
Besides... You cannot understand TRUE frustration until you run some pl/sql that COMMITS your transaction behind your back... LOL
|
|
|
|
|
it may be my be-all-and-end-all ... but, for others ?
TypeScript would have been another interesting entry.
p.s. i think anyone who doesn't love C# should be flogged until they see the light.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
i hate it. every one of them: C#, Java, ES6... probably Dart, too. i hate how Kotlin is always explained in the context of Java, the same way git was explained in the context of svn.
lucky for you i'm insignificant. if i was an evil genius i would have done everything to erase Java out of existence (and C# with it). Ban the class keyword from JavaScript forever...
luckily, this message is also insignificant
|
|
|
|
|
a delightfully baroque reply !
thanks, Bill
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Agree that C# should be in the list, also PHP...or maybe just an item 'any language that uses semi-colons for EOL' would work.
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
BillWoodruff wrote: i think anyone who doesn't love C# should be flogged until they see the light. With a wet noodle, no less Bill-ji!
/ravi
|
|
|
|
|
Mmmmnnnyyyeah, c# started out as a nice succinct, clean language, kind of like C with the K&R paperback to hand.
Then they introduced Linq...
and Linq to sql - forget everything you knew about query plans, stored procedures, cursors, connection pooling
and all the "syntactic sugar" around function declarations and "var" and now the C# manual, if printed, would outweigh Larousse Gastronomique.
There is always someone on the team that spots a handy new keyword / method / object and throws it in the codebase (probably along with a npm lib) and you sit scratching your head till they get back from vacation. Then we find the handy new keyword / method / object which saved typing 10 characters requires a couple of paragraphs and a hyperlink in the /// <remarks> (oh I forgot, comments are evil and all code should be self-documenting etc).
How DO you spell curmudgeon?
Don't feed the Trolls, they bite
|
|
|
|
|
I can't argue against your points. I am still blown away that Delphi and C++ Builder shared object structures well enough to cross-inherit. It's no wonder C# (same architect) can do this with VB.NET (now an ugly step child).
But the syntactic sugar is a bit overwhelming. There is the language and now these decorations are like adding "context" to the language.
And I completely agree with linq and sql linq... OMG As a DB Developer, I cringe when I see some of these queries coming across the wire.
|
|
|
|
|
i don't know if linq is the problem or something else, but adding new syntax into a language on almost annual basis... that is something very very dangerous.
you'll end up with 3 different projects in 10 years and all 3 could be like different language. you open with a C# 1.0 code base, then a C# 3.0 code base and what is it now C# 10.0? and what you get is the out of college coder that is familiar with C#9 is terrified by C#1 and the C#1 coder cannot recognize a C#9 project as the same language.
the absolute only reason why it is justifiable to change something in the syntax is if it severely makes things simple. not juts make things simple, but make things simple in a killer way.
it's worse in the JS camp, every year they add something. like, this new syntax will provide... who cares?!
there is no need for a debate. you have a RISC and a CISC philosophy and the RISC won.
Bruce Lee - "I fear not the man who has practiced 10,000 kicks once, but I fear the man who has practiced one kick 10,000 times."
|
|
|
|
|
this is code project, you don't sh*t where you eat
nah, but yeah my main language.
I like javascript because I don't have to create classes and properties to attach another property. debugging none issue
|
|
|
|
|
Three real stinkers there: Python, JS, and VB6/VBA
VB6: No language that includes On Error Resume Next should be allowed to live.
Python: Significant indentation, but spaces and tabs both count as one character - so two identical lines in an editor are in different blocks.
Javascript: A total absence of type safety, and the "evolved from pond slime" design of the language.
It had to be JS in the end.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I have a few language choices: Objective-C, Bash/Powershell and VB6.
I used to work on a Qt desktop project that uses C++, Python and Javascript. Imagine the horror of debugging it.
Argh... Why can't we code in a single language?!
|
|
|
|
|
"No language that includes On Error Resume Next should be allowed to live."
What about WPF? The default there is to resume next on binding errors...
Oh sanctissimi Wilhelmus, Theodorus, et Fredericus!
|
|
|
|
|