Click here to Skip to main content
15,867,834 members
Home / Discussions / Design and Architecture
   

Design and Architecture

 
Questiondesigning programs Pin
404byter27-May-20 6:05
404byter27-May-20 6:05 
QuestionMaking data notation extending another language Pin
nedzadarek18-May-20 10:40
nedzadarek18-May-20 10:40 
GeneralRe: Making data notation extending another language Pin
Richard MacCutchan18-May-20 21:19
mveRichard MacCutchan18-May-20 21:19 
GeneralRe: Making data notation extending another language Pin
kalberts18-May-20 23:06
kalberts18-May-20 23:06 
GeneralRe: Making data notation extending another language Pin
Greg Utas19-May-20 0:41
professionalGreg Utas19-May-20 0:41 
GeneralRe: Making data notation extending another language Pin
kalberts19-May-20 2:32
kalberts19-May-20 2:32 
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 2:43
professionalEddy Vluggen19-May-20 2:43 
GeneralRe: Making data notation extending another language Pin
kalberts19-May-20 3:44
kalberts19-May-20 3:44 
Eddy Vluggen wrote:
And no, you don't go back questioning the design of the screws if you're building a car. You take the industry standard, take a brief glance at other screws, and try realize there's a reason why it is the current standard.
That is certaily true. Sometimes there are reasons for that component design that you do not realize, and if you try to "improve" it, you may be doing the opposite. When a partial solution is given, it is given.

Textual encoding may be that way, in particular when you are exchanging data with others.

But when you are not bound to one specific solution, e.g. you are defining a storage format for the private data of an application, or you have several alternatives to choos from, e.g. 8 bits text is given but you need to select an escape mechanism either for extended characters or characters with special semantics, then you should know the plusses and minuses for the alternatives.

"Because we used it in that other product" is not an assessment Smile | :) Yet, I often have the feeling that we are arguing like that. We should spend some of our efforts on learning why these othere alternatives were developed at all. There must be some reason why someone preferred it another way! Maybe those reasons will pop up in some future situation; then you should not select an inferior solution because "that is what we always do".

What I (optimistically) excect from my colleagues is that they are prepared to realate to the advantages and disadvantages of text and binary encoding. If they are network guys: That the know enough to explain the greatness of IP routing vs. virtual circuit routing, the advantage over layer-3 routing rather than layer 1 switching. Application developers should relate to explicit heap management vs. automatic garbage collection, use of threads vs. processes, semaphores vs. critical regions. And so on.

Surprisingly often, developers know well the solution they have chosen - but that is the only alternative they know well. They cannot give any (well) qualified explanation why other alternavtives were rejcected. I think it is important (in any field, both engineering ones and others) to be capable of defending the rejection of other alternatives as it is to defend the selected one. If you cannot, then I get the impression that you have not really considered the alternatives, just ignored them. And that is what worries me.

For UTF16: yes, that is given, as an internal working format. Yet you should consider what you will be using an external format: UTF-8 is far more widespread for interchange of text info. When is it more appropriate? If you go for UTF-16, will you be prepared to read both big- and little-endian variants, or assume that you will exchange files only with other .net-based applications? Will you be prepared to handle characters outside the Basic Multilingual Plane, i.e. with code points >64Ki?

Even if your response is: We will assume little-endian, we will assume that we never need to handle non-BMP-characters, we will assume that 640K is enough for everyone, these should be deliberate decisions, not made by defaulting.

When Bill Gates was confronted with the 640k-quote, he didn't positively confirm it, but certainly didn't deny it: He might very well have made that remark in the discussion of how to split the available 1 Mbyte among the OS and user processes. Given that 1 MB limit, giving 384 kB to the OS and 640 kB to application code should be a big enough share for the applications, otherwise the OS will be cramped in too little space. 640k is enough for everyone. - In such a context, where the reasoning is explained, the quote suddenly makes a lot more sense. Actually, it is quite reasonable!

That is how I like it. Knowing why you make the decisions you do, when there is a decision to make. Part of this is includes awareness of when there is a decision to make - do not ignore that you actually do have a choice between your default alternative and something else.
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 4:00
professionalEddy Vluggen19-May-20 4:00 
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 2:38
professionalEddy Vluggen19-May-20 2:38 
GeneralRe: Making data notation extending another language Pin
kalberts19-May-20 4:36
kalberts19-May-20 4:36 
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 7:12
professionalEddy Vluggen19-May-20 7:12 
GeneralRe: Making data notation extending another language Pin
kalberts19-May-20 8:44
kalberts19-May-20 8:44 
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 10:08
professionalEddy Vluggen19-May-20 10:08 
GeneralRe: Making data notation extending another language Pin
nedzadarek19-May-20 10:21
nedzadarek19-May-20 10:21 
GeneralRe: Making data notation extending another language Pin
nedzadarek19-May-20 10:16
nedzadarek19-May-20 10:16 
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 11:48
professionalEddy Vluggen19-May-20 11:48 
GeneralRe: Making data notation extending another language Pin
kalberts19-May-20 13:12
kalberts19-May-20 13:12 
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 14:21
professionalEddy Vluggen19-May-20 14:21 
GeneralRe: Making data notation extending another language Pin
kalberts19-May-20 14:40
kalberts19-May-20 14:40 
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 14:53
professionalEddy Vluggen19-May-20 14:53 
GeneralRe: Making data notation extending another language Pin
nedzadarek19-May-20 14:21
nedzadarek19-May-20 14:21 
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 14:32
professionalEddy Vluggen19-May-20 14:32 
GeneralRe: Making data notation extending another language Pin
kalberts19-May-20 14:48
kalberts19-May-20 14:48 
GeneralRe: Making data notation extending another language Pin
Eddy Vluggen19-May-20 14:59
professionalEddy Vluggen19-May-20 14:59 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.