|
I am looking for suggestions to develop a back office business system for a family startup. Specifically a programming language that will meet the needs of the business. I have already laid out the design concepts, data structures, etc.. I envision 10 - 15 thousand lines of code to start and it will grow to about 50 thousand. The will be very limited access to this data via the web.
The requirements are:
1. Target operating system will be Linux - probably Ubuntu/Mint.
2. Language must be strong in data structures and I/O to handle sequential, text, direct, and index files. I do not want to get into writing my own indexes and access methods. Been there done that.
3. Must be compiled. Scripted languages can be hacked where compiled languages are much harder to hack. Source code will be kept far the the web.
4. I don't mind if the language has OO constructs but do not want to be forced into using them. From my experience OO the hinders more than it helps. It's like putting handcuffs. The shorted distance between two points is a straight line. That's a personal requirement.
I know the list isn't long but I could be missing something out there I don't know about.
Thanks...
|
|
|
|
|
C or C++ will do the job.
|
|
|
|
|
... and about 10 years of previous applications development experience if one expects to deliver this sometime in the future.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
C is a possibility that I am going to look into. When I was doing C on ATT Unix V it had poor i/o support and had to write dozens of B-tree structures to support the businesses data and users.
But I think it has an ISAM/VSAM library now. Need to look into it. Don;t really want to get into that again - it's a bit of code to do.
Thanks
|
|
|
|
|
If you want a simple database then SQLite[^] may be a good choice.
|
|
|
|
|
It's a good idea but down the road there are going to be needs that go beyond the shuffling of data.
And it is just me - I like everything under one roof (one programming language). It's just easier to deal with. Thanks.
|
|
|
|
|
VSAM is the underlying file structure for IBM's database management system. As far as I know, there are no other implementations.
You're either using a bot to "spin" this stuff; or you've just woken up from a corporate sleep.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Joer4x4 wrote: Must be compiled. Scripted languages can be hacked where compiled languages are much harder to hack.
You mean compiled to native, not to bytecode. If you want to know "how much harder", then go take a look at the amount of games that were available in the '90s without a copy-protection in the wild.
Joer4x4 wrote: From my experience OO the hinders more than it helps
Makes me conclude that your experience is too limited. OOP does not shine in small utilities, it shines in larger projects. Don't tell me you'll be favoring global variables too.
Joer4x4 wrote: I envision 10 - 15 thousand lines of code to start
You don't know what language, nor how tense that language is, but do already know the LOC?
For any experienced and inexperienced programmer I'd recommend C#. Yes, compiled, but not to native. If your application only runs on your machine, then that should not be a problem. If your application is distributed in the wild, then preventing hacking becomes a mere economical question. Most applications are sadly not worth the effort of stealing 
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
1. Does not have to be compiled native so long as I end up with machine code. This isn't a game it's business - totalyl different ball game.
2. I can write a system faster in older languages with OO. If you look closer and understand the languages it becomes obvious that OO is not completely new. Older languages have been doing that stuff long before OO. The difference is they gave it fancy names and made the programmer write code to restrict and enforce the usage of data. Every time you pull data together to form a record you encapsulate the data. When you pull the record inheritance is automatic. The data is what it is. But if you are pulling for a different purpose you have to jump though hoops so OO will let you use it. Without OO it can be easily accessed and broken for the need. The focus should be on the data and purpose - not the language. A single variable name is easier to follow through a program than 20 variable names for the same thing.
We all know a fence belong around buildings and homes and is built on the ground. It works fine for OO but down the line you may need a fence for your model train set so now you need a fence on the table. Now what? Create more unnecessary so it suits the language because to get that fence? In the real world you need to be prepared to put a fence anywhere. Why? Because you can and the business wants it yesterday.
There was a time when many business(even small) had there own programmers. They wrote software that gave the business and edge over the next guy because it was tailored for the business. When OO came along that faded because OO became expensive and not as much was getting done. It was not all OO but it helped. Now it's a package world - one size fits all but it doesn't really?
Hey if you like OO go for it. But having experience both worlds - I'll take the old one - much more efficient. Especially in large projects. If done right and understood OO does not make better code or a better programmer.
3. I know what language but I am avoiding it. While I am exploring I understand that most most new languages were developed by those in research, science, and some back office at some university. Unfortunately those languages tend not to be business friendly especially in the the area of file I/O because they built the language for their needs and not the needs of a business. C is a prime example. They needed something better than B to build Unix. So C was born and is a great for building OS code and utilities. For business it will work and you will have more code than you should but it is far from ideal. So I am thinking someone may know of something better to turn a lot of data "quickly" so long as I can avoid the OO for the fastest turnaround time for changes. Time is money...the real world
modified 7-Jul-17 21:24pm.
|
|
|
|
|
Joer4x4 wrote: Every time you pull data together to form a record you encapsulate the data.
No, data is aggregated by the db, before being consumed by the application. Read as an array of object usually. Does not require a class describing that set of data.
Joer4x4 wrote: Time is money...the real world
Been working there for a few years now, and most companies tend to value efficiency. I can also note that I would not be touching procedural code with a stick
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Interesting - It takes an application to create, use, and determine the structure of the data. The db is totally stupid until it is told what to do. The term here is used loosely as a db is a group of tables managed through specific software line DB/2, MySQL,or RMDBS. Even then you have to decide how you want the data stored (encapsulated).
An array is a group a similar data items. Records are a group of dissimilar data items. Last time I looked a class is an object. Classes are just different types of objects.
If you are a programmed you write procedures all the time so hold that stick. An OO method is just a fancy name for a procedure. A machine will always need instructions and it is procedural. All machines work that way because humandswork that way. It just life.
What was that about the experience thing...
Enjoy the day.
|
|
|
|
|
Joer4x4 wrote: An array is a group a similar data items. Records are a group of dissimilar data items. Last time I looked a class is an object. Classes are just different types of objects.
An array of pointers is not required to point to "similar stuff". And no, a class is not an object, it is a blueprint of an object. An object is an instance of a class.
Joer4x4 wrote: A machine will always need instructions and it is procedural
A machine will also need data, as procedures themselves are useless. OOP is about structuring and scoping both into logical reusable pieces.
Joer4x4 wrote: What was that about the experience thing...
Yes, you'll need more 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
"And no, a class is not an object, it is a blueprint of an object. An object is an instance of a class."
Stop... not true...
How many times I read a similar statement and chuckled? For in itself a class defines itself as a class, therefore and logically is has to be a object. It is an instance of itself. It has inheritance and can be inherited. They also tell you it doesn’t take up any computer space or storage. But if that were true, you could write a method without it. It’s in your code and classes are enforced. The compiler or interpreter may ignore it for creating machine code but is used for the human.
A blueprint is a real physical "object". Poor comparison but no other way to explain class. And why is that?
int x, y;
x = 0;
y = x;
So I created a class of x (int) and an instance of x. Is x not an object also?. X is inherently encapsulated unless we use a method (where x is the object of an imperative statement) to change it (x = 1). I can use it as a counter, an account number, product number, etc.. Counter, account number, and product number will not only inherent all x is, they are polymorphisms of x.
Where do you think OO concepts evolved - out of thin air?
"OOP is about structuring and scoping both into logical reusable pieces."
In that regard OO isn't any better than PL/1, COBOL, EDX, and a host of other non 00 languages.
|
|
|
|
|
Joer4x4 wrote: How many times I read a similar statement and chuckled? For in itself a class defines itself as a class, therefore and logically is has to be a object. It is an instance of itself.
A class is not an object, it is, as Edddy said, a blueprint from which an object can be created. If you really do not understand this basic concept of OOP you are likely to get yourself into some serious problems.
Joer4x4 wrote: A blueprint is a real physical "object".
Yes, it is a piece of paper with drawings of a physical object, but it is still only a drawing - a blueprint of a house is still not a house.
|
|
|
|
|
Joer4x4 wrote: Stop... not true...
That's the definition I gave the students
It is not a philosophy-class; instead of disproving the definition by using an incompatible real-world analogy, one is expected to use the definition to make sense of what the computer is doing.
I'd also point out then that OO is limited to programming-theory, and that the correct name would be OOP, since there is no OOI (Object Oriented Ironing).
Joer4x4 wrote: For in itself a class defines itself as a class, therefore and logically is has to be a object.
No. A class is not "logically" an object. An integer would also not be an object, but a value.
Joer4x4 wrote: In that regard OO isn't any better than PL/1, COBOL, EDX, and a host of other non 00 languages.
It is. Made it rather easier to re-use code, since one does not have to hunt all used global variables. Makes extending code a lot easier. Makes it easier to manage a larger code-base and dependencies.
There is a good reason that most code here is OOP-based, and not simply COBOL. Give it a try, you might actually like it
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: An integer would also not be an object, but a value.
In general that is specific to the programming language however. Smalltalk has no primitives - integers are objects.
|
|
|
|
|
I tried it 20 years ago. That's how I know I don't like it. Separate compilation of programs sharing the same data required more code than needed and you could not spread out the definitions with their logical modules that they belonged to. This is able to be done today but they had to break their own rules to allow it. For example your quote: "No, data is aggregated by the db, before being consumed by the application. Read as an array of object usually. Does not require a class describing that set of data."
Do you think I requested a non OO language out of thin air?
There is nothing to fear from a global variable. All variables are global after the compiler is done with it anyway. Imagine - all that work to hide them and its all thrown out the window anyway.
One rule that will never change is that the shortest line between two points is a straight line. I like living with that. It holds true for everything. To me OO curves the line by writing for the language.
Hey give one of the older languages a try. You might find the freedom of expression a breath of fresh air and the modularity and code reuse were already down to a science. Can you imagine pulling in an existing data structure with over (let's just say) 50 variables and redefining those on the fly with 1 line of code? How about a whole program? That's modular and reusable.
|
|
|
|
|
Since you seem to know so much more, and better, than everyone here, why don't you just get on and do it your way? Then you can showcase the results to prove us all wrong.
|
|
|
|
|
You do realise that most of the commenters here have experience in procedural, declarative, OO and functional programming languages don't you? Rather than dismissing them out of hand, you might want to reflect on their experience. Just because you tried something a little bit doesn't mean that you have a strong enough background in those areas to dismiss others; for instance, if your OO language of choice was C++, it was incredibly easy to write bad OO because you ended up writing it as a procedural implementation.
This space for rent
|
|
|
|
|
Joer4x4 wrote:
There is nothing to fear from a global variable. All variables are global after the compiler is done with it anyway. Imagine - all that work to hide them and its all thrown out the window anyway.
After compilation it is no longer required; I'll trust the computer to follow the instructions. Hiding the variables is not done for the computer, but for the programmer - to prevent spaghetti-code. Or worse, ravioli-code. So yes, scope only needs to be verified during compilation, not after.
I would consider the use of a global variable an offense that is equal to using a goto-statement.
Joer4x4 wrote: Do you think I requested a non OO language out of thin air?
No, of course not; you'll have better experiences/results with non-OOP code. That is a subjective view however, and general consensus points in the other direction.
There are multiple versions of BASIC, and two of the more popular ones are MSVB and VB.NET; where MSVB is usually VB4 or VB6. Both VB4 and VB6 are more procedural than OOP, whereas VB.NET is aimed at OOP but still supports the procedural way (a bit). When MS decided that VB7 should become OO there was a lot of wailing and gnashing of teeth.
Ten years later, you'll find that most of the VB6-crowd has made the move without much regrets.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Joer4x4 wrote: Hey give one of the older languages a try.
I worked with C for about 15 years. And perl, did not and still do not use OO constructs in that. Used Fortran, Pascal, Basic and Assembly as well.
So no need for me to "try" them to understand them.
Joer4x4 wrote:
One rule that will never change is that the shortest line between two points is a straight line
I have worked in which include medical, financial, telephony, cable and agriculture and that simplistic statement has nothing to do with it.
Creating systems is difficult and the cost, which is what businesses actually care about, is impacted by many factors most of which have nothing to do with technology at all. For one example, finding suitable developers to keep projects going can range from moderately difficult to extremely hard. And just from that one factor attempting to choose the skill sets that are most widely available can have a significant impact on what businesses actually care about.
|
|
|
|
|
Joer4x4 wrote: This isn't a game it's business - totalyl
Rather certain that WOW is a business. A very successful one as well.
Joer4x4 wrote: I can write a system faster in older languages with OO. If you look closer and understand the languages it becomes obvious that OO is not completely new...
Based on the current tiobe report of the top 10 languages I have more than a decade in the top 5 languages. And have done probably a year in at least 2 of the others. And C is one of the ones with at least a decade. I have worked on 24x7 servers, back end exclusively for 25+ years. And I do have a education background with a strong grounding in computer science.
Based on that I do "understand" languages.
Based on that I respectively disagree with all of your contentions.
Joer4x4 wrote: The was a time when many (even small) had there own programmers
Not even sure what that means. There was a time when most businesses did not have programmers. These days almost every single small business has either a person in-house that handles their website or someone that must establish a business relationship with a different company that does that. And any moderate size business must have someone that is at least moderately familiar with the technology if they are not doing it themselves.
Joer4x4 wrote: I'll take the old one - much more efficien
You would of course need to define exactly what efficiency you are looking for. However in terms of deliverables - familiarity is probably by far the driving force. A technology is not significant but rather whether the developer knows how to use it or not.
In terms of performance the factors are as follows in the vast majority of all programming endeavors and probably more so in any that calls itself a 'business'
1. Requirements - most impact
2. Architecture
3. Design
4. Technology - including language.
5. Hardware/platform - least impact
I have seen miserably bad code in every language I have worked. However the major performance drivers, on the orders of magnitude, were always caused by the first 3.
Joer4x4 wrote: 3. I know what language but I am avoiding it. While I am exploring I understand that most most new languages were developed by those in research...
Not sure what that paragraph was intended to mean but it suggests it is a rationalization for something. A "new" language is going to be something that has been around less than 10 years. I suggest you look to the tiobe report for that. Other than that businesses these days use OO languages or even languages with OO constructs. That is why the ANSI C standard now has OO constructs. There is even a lot of embedded development using C++ whereas it use to be C and the reason for that is not delivery but rather compactness of code and exact very exact control of that code. With large and faster embedded systems those restrictions are not as strict as they used to be.
Look at Go (see the tiobe report). Not even "new" now as it is 10 years old. It is compiled and was designed because the authors didn't like C++.
|
|
|
|
|
|
It's good to see it make an appearance. It's been too long since there was an Osmo sighting.
This space for rent
|
|
|
|
|
We have design patterns for pieces in a program, but do we have design patterns for entire systems? If so, is there a book that talks about this like the GoF? For example, when dealing with large volumes of messages, often the system design pattern is to have a proxy/router server in the front that uses a hash to send the messages to many servers for processing.
I ask this because I was given a system design question at an interview, and when I presented the proxy hash solution the interviewer asked about other ways of doing this. I did not, and he then promptly listed other methods (all of which flew over my head). This opened my eyes and I now realize that various system designs have more than likely been formalized in a document at this point with the pros and cons of each.
modified 14-Jun-17 17:08pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
