|
Ok... I see your point now. And yes, I agree with you.
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.
|
|
|
|
|
Kornfeld Eliyahu Peter wrote: What do you see as the main difference(s) between the older (let say 30+ years in the filed) and younger (less then 10) 'generation' of developers?
What are the main reasons?
Job security.
I know COBOL.
I'm retired. There's a nap for that...
- Harvey
|
|
|
|
|
That's a metal isn't it? Used to give blue color to the glaze that potters use for their ceramics.
|
|
|
|
|
I'm the latter but I program like neither really.
The older generation seems to want to keep thier design patterns, often at the expense of the newer generation's capacity to maintain or even understand those patterns. The newer generation is kind of lost in many ways. There's not a lot of drive to understand the field as a whole, they just want to do their own thing and not get too much negative feedback.
Left to their own devices, I feel like the older generation would spontaneously develop something like Rust. Great idea, great execution, sounds boring as hell.
In contrast, the younger generation would spontaneously develop something like Node.js. Terrible idea, mediocre execution, but all the kids are using it because something on the internet told them to.
|
|
|
|
|
I personally met heaps of older dudes basically having learned all they'll ever need half a century ago and sticking to it, absolutely disregarding every single bit of progress made throughout said half century.
|
|
|
|
|
Kiriander wrote: every single bit of progress made throughout said half century.
First, only because something is newer, it doesn't necessarily means that it is "progress".
Kiriander wrote: I personally met heaps of older dudes basically having learned all they'll ever need half a century ago and sticking to it,
Although I believe you, if you were right then the biggest programmers here would be youngsters, but the average is still much older in the top than in the base.
And those older dudes are mostly the ones helping the "progressed" youngsters all around the site.
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.
|
|
|
|
|
Those two particular dudes I'm talking about don't help all that much. In fact, I had to get free of them due to things like they forcing me to use manual memory allocation instead of ARC when passing data between two modules from the same C++ project to finally run on a multicore x86 system running on mains power time-limited by a 34kBd-UART (my point being there's litereally no point in doing it manually, even doubting implicitly written code in C++). ARC in modern C++ is pretty robust, despite being newer than malloc/free.
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.
I'd like to mention another dude. He's been doing roughtly the same for the last couple decades, but that's because his field of work is static for roughly that time (low-power-applications in assembly in that one specific MCU). And holy hell is he good in what he's doing. He never learned programming per se, he came to us as an electrical engineer, but he does stuff in assembly, holy moley. He's the only one to squeeze functionality into the last corner of the PROM. He's not big on methodologies such as SCRUM neither does he have a git branching strategy, but he's just so damn good at what he's doing. You know, that dude showcases what differentiates the generation. Getting things done, everybody can. Give a novice the code, the documentation, enough time (and maybe a test suite to pass), and they'll achieve anything. But being really good at what you're doing, that's something to look up to.
|
|
|
|
|
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
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
