|
Kiriander wrote: Look, I get that what I'm talking about isn't EXACTLY the spirit of the topic. But please believe me that I'm now what I'm talking about when I call someone anti-progressive.
Sorry, but you didn't speak about those concrete guys in the first message. At least I understood it as a generalization, and that's what I answered back.
There are morons and idiots in every country, in every culture, in every age, in every sex... everywhere. But it doesn't mean that all of the same type are like them. 
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.
|
|
|
|
|
I'm 30+ years programmer and I see age as the main difference 
Sorry for my bad English
|
|
|
|
|
Understanding the internals.
I started out in an assembler-like language. To debug, you'd get a printout of the program, on the left of which was the actual machine code. You'd have to set breakpoints at addresses, etc, etc, but it gave a good insight into how the machine actually handled memory, how our human-readable (mostly) code got compiled, etc.
On to C, where you had to manage your own memory and dispose of it (hopefully) properly. To this day, I think of constructs in C# in those terms sometimes, and try to be careful about resource use.
This is a broad brush which doesn't match all cases. Many younger folks really are interested in learning the internals.
And, of course, many people with 'experience' are just plain dumb/ignorant, and some of those don't want to learn. I work with a consultant who's a self-proclaimed 'database guy' (as if that's a good enough explanation why his code sucks). Until this winter, he didn't know SQL Server Profiler existed...
|
|
|
|
|
The older developers worked in a procedural and functional world. A text-based world.
When I taught programming for networking and for electrical Engineering in the 2010s, I taught how to think like a programmer, and basic processes. We weren't teaching OOP. I was supposed to teach from a beginner Python book for networking students and beginning C for IC programming for the engineering students. I also added in JavaScript showing the same procedures on web pages. Most of the students liked the web-page exercises better.
I did all my programming in person and real time, typos and all, so the students could see that making errors that sunk your program was not the end of the world.
|
|
|
|
|
My own thoughts and experiences from 40+ years in this business...
I agree with pretty much all that is said here. But one thing that I think is critical is just plain experience and having a mindset of good design.
Anyone can learn the technical parts of a language or a framework fairly quickly.
But knowing how to look at problem or project proposal, and knowing how to approach it in a clean, well-thought out approach is not something that can be taught or learned as quickly. A developer needs to have experienced the building of applications and systems, seeing what works, what doesn't, and which is maintainable. And this should happen with good mentorship in the early years of a developer's career, to get feedback and guidance on design patterns and concepts.
In the middle ages they had the concept of an apprenticeship system. As an apprentice, you didn't do anything without oversight and guidance from a journeyman or master builder. After a period of years, you would be judged experienced enough become journeyman - simply meaning thr master builder still provided the plans, but you were judged competent enough to follow the plans without constant oversight. Only after many more years might become a master builder, capable of creating the designs and leading the efforts to build. And all of this was overseen by the appropriate guild.
I think things are similar with software design and development. When you first learn the tools (language, framework, etc.) you are still just an apprentice. After years of supervised (pair programming, code reviews) work, you might move to the point of becoming a "journeyman" developer (or maybe you don't and find another career path). Now you are trusted with more complex work, simple designs , etc. Eventually with more experience you are designing more complex parts of the system, maybe mentoring newer developers, and you eventually reach a level where you become that "master builder", capable of designing complete systems and leading the development effort.
I remember reading somewhere that a new developer might need 5-10 years of experience before they should be considered anything more than an apprentice.
I think this makes sense - we are builders of sorts. And using the right design concepts and patterns takes time to learn, and to know when and how ro apply.
Anyways, I'll stop rambling here.... 😁
|
|
|
|
|
Wow... you just gave YOUR GENERATION A NAME...
THE WHAT'S LEFT IT GENERATION...
You survived the demise Windows Vista and Windows 8
You survived the rise and fall of Java and .NET
You survived the end of CD, DVDs, BluRays and other shiny discs (with a C)
You survived the rise and fall of Napster and the media industry and...
You survived the bloating of Visual Studio... of Chrome...
The U turn of Microsoft from hating Linux to loving it
The other U turn of Internet Explorer to Edge to Edguim
The rise and fall of Winchester (hard drives) from 5Mb up to 1Tb and extinction...
The rise and fall of the iPod
The rise and fall of Napster and the RIAA
The rise and fall of Wintel
So, what's left... Time only knows, and I don't mean the magazine.
|
|
|
|
|
back when processing was slow you really had to think about how may CPU cycles were being used as you developed. I still think of the load on the computer when developing, even though modern computers can handle just about anything anymore.
many younger Dev's I've met know their frameworks well, but rarely think about how that framework runs on the machine, or what the cost is in resources.
just generalizing here, plenty of exceptions out there.
|
|
|
|
|
So I've been wracking my brain trying to come up with a code generator for something significant that hasn't already been done, or even done to death in .NET.
One of the reasons I wrote so many lexer generators and parser generators is because they weren't necessarily well covered territory in .NET, and besides aren't very well understood in general. As code generation tools go, these projects were worthy of effort.
But code generation tools for data layers, entity generators, and typed XML and JSON generators are well covered ground. I'm coming up empty thinking of another tool to add to the arsenal of available generators out there. My parsers and lexers notwithstanding, I can't think of much else to add. And I've jumped the parser shark anyway, with Glory, the GLR parser generator I built.
All of that having been said, I really would like to do some more code generation tools. I tried implementing a visitor generator but I ran into some implementation issues that aren't easily rectified as far as it chasing spurious properties (like SyncRoot on old collection classes) and not handling chained indexer expression properties. I've shelved it for now.
So now I'm looking for some ideas. They'll come eventually. I don't want to do anything that involves wholesale generation of HTML or even ASP.NET code and such, more just tools that spit out C# (and possibly VB.NET like my other generation projects)
Anyone have anything they know can/should be automated and is general enough that it's useable outside of a very specific task? We might be able to help each other.
Real programmers use butterflies
|
|
|
|
|
There might be room for some smart and speedy serializer that do not use reflection perhaps?
Although, with the upcoming and promising GRPC that might be a waste of time...
But i did write a reflection tool (that is version tolerant) and I used a lot of reflection there... But code generation might have been an alternative?
|
|
|
|
|
|
I think I mentioned this to you before, but I have a fascination with the visual salience of decision tree rule structures rendered into relatively simple ui's [^]
I like to give my students this example to test their logical thinking in terms of how they perceive what the most relevant criteria are:Quote: AIRFARE DISCOUNT from visual-paradigm's old website
Infant passengers under two years old are offered a discount of 80% on domestic flights.
Infant passengers under two years old are offered a discount of 70% on international flights.
Youth passengers (between two and sixteen) are offered a discount of 10%, for any kind of destination.
Passengers who make reservation five months before their journey are offered a discount of 10%.
For international flights, passengers are offered 15% discount if they travel during off-seasons.
There would be no discount for international flights, except that when the passenger is an infant passenger or when travelling during off-season.
Frequent flyer enjoys a discount of 15%.
The amount of discount is accumulated.
The maximum amount of discount for infant passengers is 80%
The maximum amount of discount for non-infant passengers is 20%.
Now, some students immediately grok that "age" is the criteria here with the most "organizing power." Others don't have a clue.
The challenge I see is how to take a set of "rules" like this and "prune" the matrix of possible combinations down to the essential set.
In my head this also relates to the general area of "business rules," and even DSL's.
Hope you found this interesting; my head is not on very straight these daze.
cheers, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
Coding a decision tree structure is one thing, but the problem I see with generating code for it is making it work in the general sense - a similar problem with state machines. As in, sure I can make one of these things, but it will be suitable toward one particular task - like your airfare example. I don't see a lot of opportunity to generalize the algorithm. As I said, I ran into the same problem with state machines.
Real programmers use butterflies
|
|
|
|
|
If you wanted to step into Python, I think there is a need for an extension similar to LINQ. I'd call it PINQ. (Python or Pandas language integrated query)
Python and its Pandas library is used heaps for data manipulation, but some of its syntax is very inelegant and cumbersome.
Most stuff is implemented as functions on pandas data frames, and joining two of them together is done as a function call.
pd.merge(left=first, right=second, how='left', left_on='first_field', right_on='second_field').drop('second_field', axis=1)
It's just really painful. It ought to be possible to define a cleansyntax that was far more expressive of common data manipulation on dataframes and translate into a series of pandas calls. It could be done as a pre-processor step prior to trying to merge into baseline Python.
It would be interesting to try to define this as an abstract and be able to translate into python/pandas code, LINQ, R, SQL, etc
|
|
|
|
|
I have not used python, primarily in protest of the fact that whitespace is significant in the language.
Real programmers use butterflies
|
|
|
|
|
lvalue.
|
|
|
|
|
Those of us who've been here long enough will remember Osmodian (I might have that name wrong) where he went on and on about English language to code generation. In many ways, I think that's still the Holy Grail - when I was 20 or so, at a computer convention in SF (think Apple ][, Commodore, Trash-80, Atari, Sinclair, etc) there were quite a few demonstrations of code being generated from sentences. It was touted as "this is the future".
Well, that future never happened. 
|
|
|
|
|
To me, it's obvious that such a future isn't realistic, absent AI and the ability to "do what I mean" if only because of the ambiguous nature of human language.
Digital computers require precision. They are notoriously bad at dealing with ambiguity and to a lesser extent, non-determinism.
It makes me wonder why such engineers wasted their time. They should have perhaps consulted a linguist.
Actually, Noam Chomsky could have probably steered them straight.
Real programmers use butterflies
|
|
|
|
|
|
This is bad news for us space pirates
Real programmers use butterflies
|
|
|
|
|
Dire news, indeed!  
|
|
|
|
|
Save us from US
that was so unfunny don't know which is worse for the world:
The truth and humor black hole of the USA media or the truth and morals black hole of the CCP?
(Yes political, AS WAS the OP)
|
|
|
|
|
Haha, moon dubloons 
|
|
|
|
|
The two main adversaries of the US, Red China and Russia, have both demonstrated the ability to shoot down LEO satellites. The US is behind in this arena.
And no, I really don't like the idea of militarizing space, but I understand that human nature will require it.
|
|
|
|
|
Did you know that a deaf lip-reader (deprived of visual context) cannot distinguish between “elephant juice” and “I love you” ?
I learned this from my WordSmith word-o-the-day e-mail. The technical term for such parssing ambiguities is "homophene."
cheers, Bill
«One day it will have to be officially admitted that what we have christened reality is an even greater illusion than the world of dreams.» Salvador Dali
|
|
|
|
|
OMG! That explains a lot of misunderstanding!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
