|
|
What happens if we save to a standardised text representation, and instead format code on demand, in the editor? "I believe it is peace for our time."
|
|
|
|
|
Kent Sharkey wrote: save to a standardised text representation
Ooohhhh!!! Another holy war to set the standard!!!
|
|
|
|
|
|
Why not take it a step further, ALGOL 68 style, defined in abstract tokens. Each implementation may define concrete representations of abstract tokens, e.g. German language keywords. (That has been done!)
The storage format could be a parse tree that could be unparsed at display time, so that block delimiters could be displayed as {} or as BEGIN-END, the datatypes as INT or int or integer, as float or REAL or single, statement ends as newline or with a semicolon. Editing operations could operate directly on the parse tree, rather than on a textualized linear representation that must be parsed again.
If the compiler was integrated into the IDE, the parsing would already be done, so it would save a significant amount of time. And it might be more or less language independent.
I never dug into the gcc suite, so I do not know how much of external representation is lost when you get down to the language independent levels. I guess it would be possible to augment the structures with tags making it possible to reconstruct the source code. Maybe so much of this would be rule based that you could (re?)construct it into a different source language than the original one. Maybe you still need tagging for higher level source construct, but the tags may be general, not tied to one specific source language.
An intermediate language editor that can display the code as Pascal source, C#, Java or C++, or even Fortran IV or Cobol ... That would be really fascinating. Maybe some gcc guru could create something based on that suite's intermediate formats? Or maybe one could go into the Roslyn suite and do something, probably based on an earlier stage than MSIL, but still after tokenizing and parsing, to make it somewhat language independent.
I think this would be far better than sticking to a linear text representation of program source code.
|
|
|
|
|
Can we please have editors that prevent us from entering syntactically incorrect programs in the first place? Imagine the amount of time and mental energy freed up by that, now available to reason about the semantic correctness of our digital utterances instead.
And why, in 2022, do we still stick to editors that display 1D text sequences (files) in a fixed-width grid on 2D displays in what amounts to something like 1.2 dimensions (look up "fractal dimensions") defined by the line breaks in the file? (Rhetorical question.)
We probably won't get in our lifetimes a "PLEASE" command that reads our thoughts and writes our programs for us, and of course we don't want to have to program in machine language, so somewhere in between. If we could start all over, which abstraction level should our programming languages live on, and what would be the best representation for them? Meaning: understanding and reasoning about them?
Can we, should we think even bigger? How would a complete programming system look like that takes advantage of the computing power available in modern machines and adapts a lot more to the way we humans think and work, not just to the bare minimum required to transmit code to the compiler?
|
|
|
|
|
You can already automatically reformat. The so called standardised text is called source code.
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.
|
|
|
|
|
I do. Whenever I present code to others, I change the VS Editor options to the current coding standard settings, delete and reinsert the last brace in the file. When I pick up some source file that I will be doing significant work on, it goes the other way: I make sure that the Text Editor options are set to my preferences, delete and reinsert the last brace.
I generally prefer to fit an entire method in the window, so that I do not have to scroll over several window fulls. Besides, when you do not water out the indentation structure with lots of blank lines and brace-only lines, rather letting the indented block visually appear as a block, makes it a lot easier to follow the block structure and program flow. But coding standards don't agree with me. High SLOC is far more essential 
|
|
|
|
|
trønderen wrote: I do
Once upon a time an employer demanded no formatting, we built SQL as a string without any formatting. So, I made a plugin that did it on demand.
The standard the author wines about is already there, called the syntax. The author doesn't write code. Get off my lawn.
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.
|
|
|
|
|
The author has a point in that standard code formatting makes things harder for diff/merge tools. Where they go off the rails is in deciding that the solution is to change how everyone's editor of choice works to make things easier for existing line based diff/merge tools; rather than to make a new diff/merge tool that has a greater awareness of the structure of the code it's examining.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
Shouldn't a diff/merge tool work on the token level? Pass each candidate file through a tokenizer and compare the token streams.
You could optionally include a parser, recognizing e.g. statements, for reporting multiple (/consecutive) token edits/moves by the next higher unit (statement, at the basic level, but if all tokens within a statement are affected, the same logic may be applied at higher levels).
|
|
|
|
|
As a standard text representation, I suggest the universal language of all non-quantum computers, 1's and 0's!
|
|
|
|
|
You forgot analog computers.
I wonder if analog computers are still in use anywhere. You programmed them by hooking together "lego bricks" on a plugboard, each brick being a summer, and integrator, a delay, ... The solution was usually something more or less like a physical rendition of a complex (set of) differential equations. Input was given through potentiometers, output on a curve plotter or an oscilloscope-like screen.
When I started my studies (1978), one professor was still keeping alive his computer model of cod farming in the Sognefjord, showing how the school would react if it was fed so-and-so much, by cranking up this pot, or how a huge winter snowfall would affect it in spring when the melting water reduced the water temperature, by turning down that pot. At that time, programming analog computers was no longer part of the basic curriculum, but I believe a course was available to junior/senior students.
I never programmed an analog computer myself. I didn't have access to one, and never really made friends with differential equations.
|
|
|
|
|
So Ctrl-K Ctrl-D isn't sufficient for Visual Studio developers. Other IDEs have similar keyboard shortcuts. This is a solution in search of a problem.
|
|
|
|
|
What are the implications for step-debugging? Would the debugger need to be aware of the formatting rules in order to break on the correct displayed line? Stack traces would also be out-of-whack, I'd think. I take comfort in the fact that what I see is the same thing that my colleagues see (let alone the compiler), so I'm not really sold on this idea.
|
|
|
|
|
Today, the compiled code / debug information flags the source line numbers. It shouldn't be that difficult to rather flag them by statement numbers. You need of course a well defined way to count statements, but that is a matter of definition and standardization, not a technical difficulty.
The editor could easily display the statement numbers in the left hand column, the way it displays line numbers today. And the IDE should be capable of taking a stack dump and let you click yourself to the right source code location, even with statement number display turned off.
|
|
|
|
|
Microsoft was able to identify new wiper malware (dubbed "FoxBlade") and provided both mitigation strategies and updated Microsoft Defender definitions to the Ukrainian government "within three hours" of discovering it. They can do more than icons when needed
|
|
|
|
|
Measuring developer outputs can be detrimental because there are not enough data points to understand if the unproductiveness was caused by the developer himself, or by his surroundings/company. kLoC, of course
That's why I format my code with one keyword per line.
|
|
|
|
|
Kent Sharkey wrote: That's why I format my code with one keyword per line.
You and the author of the above article. 
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
I think it might be easier to measure developer non-productivity. Let's call it FART.
F - Fear of making changes
A - Architecture, death by
R - Refactoring because the code base is hell
T - Technical obsolescence - you want me to code in what???
|
|
|
|
|
I think I found the source of all the anti-productivity problems, all of the
Bloated
Useless
Lousy
Leaderpship
Shoving
Horrible
Ideas (from)
Tradeshows
being rammed down our throats from on high.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
|
|
|
|
|
You can't effectively measure a programmer's productivity:
0) if you hold programmers to a schedule
1) if you impose artificial and arbitrary security restrictions
2) if you won't provide sufficient tools (hardware and software) that allow them to do their jobs
3) if you have a number of programmers with various skill levels because there's no "baseline" value to compare against.
4) if you have a number of programmers with various skill levels working on a large code base of varying complexity.
5) if the sky is blue one day, and overcast the next.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
The idea behind this "interaction language" is that the machines around us could be more intuitive and perceptive of our desire to interact with them by better understanding our nonverbal cues. Sorry, did you say something?
|
|
|
|
|
I go on the computer to get away from the wife, I don't need my PC yelling at me when I'm not paying attention too.
|
|
|
|
|
You know, it might end up as a new process concept!
(Youngsters may not be aware of it: The Unix process concept was developed by K&R for their space invasion game, so that the invading spaceships would continue to get closer while you were scratching your head for what to do next. Being slow on the draw might cause your death. This mechanism for letting spaceships sneak in on you if you didn't pay attention became the Unix process. And the space invasion command processor became the shell.)
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
