Jump to content

Low level programming languages

Hi P
4 hours ago, Willpiam said:

Jesus, I hope I never have to go that deep. 

@wasab likes to make lower level languages seem to be worse than they are. And I'll give him credit: You should never consider making a complete, robust, user facing, distributable application in assembly, atleast for desktop PCs.

However, assembly is not nearly that bad for it's purposes.

That being said, there are those, myself included, that would argue that if a programmer doesn't still enjoy programming even when not using his/her favorite language, then that person isn't really a programmer: They are just a person with a job.

ENCRYPTION IS NOT A CRIME

Link to comment
Share on other sites

Link to post
Share on other sites

With definitions from our textbooks in mind:

  • Level of abstraction from hardware does not necessarily impact the turing completion of the language. If you'd like to know more about turing completion, read a book... I don't know, TAOCP could be okay. Or have me warned for telling you to read a book; apparently that solves problems.
  • C is not really "low level", and most assembly nowadays isn't really "low level" for that matter; C can't be low-level because it facilitates the construction of complex expressions that are composed of ... perhaps other complex expressions... and similarly complex types. If we go by SICP, then C fits quite snugly into the category of "high level". There's also the fact that the standard defines C in the context of "the abstract machine", which is an odd thing for an apparently low-level language to be described as. In the low-level land of x86 assembly development, you would need to switch between real and protected mode, and communicate with the BIOS using different interrupts depending on the devices you wish to read/write from... because you get no standard library, you would need to find some drivers and write your own allocator to allocate memory for you. You know... Java is pretty low-level, if you run it on a SIM card (A.K.A. a "Java card")... but the down-side there is you don't get strings or garbage collection, right?

Having said that, I would tend to ignore any use of the terms, as they seem to have become... watered down... over time. It's a shame about that, but let's face it, there are better (as in more descriptive, more meaningful) terms to use, such as:

  • Procedural/imperative, functional or logic-based (depending on the "high-level" paradigm chosen)
  • Ad-hoc polymorphic, parametric polymorphism, subtype polymorphism... or equivalents (they do have synonyms)
  • Lazy or strict (evaluation method)
  • Static (explicit conversions only) or dynamic (some implicit conversions)
  • Weakly typed (variables can be re-bound to change type) versus strongly typed (variables can't be re-bound)...
  • Object oriented, too, of course, though that's kind of an extension of the others (as demonstrated by Clojure and Logtalk for example)... those who read books tend to describe it more as a restriction than an abstraction, and the languages don't tend to rigorously enforce or punish you for disobeying core OO principles, so... pinch o' salt!
  • ... and so on...

Plenty of paradigms to research there, yep... lotsa books to read...

Link to comment
Share on other sites

Link to post
Share on other sites

1 minute ago, Sebivor said:

With definitions from our textbooks in mind:

  • Level of abstraction from hardware does not necessarily impact the turing completion of the language. If you'd like to know more about turing completion, read a book... I don't know, TAOCP could be okay. Or have me warned for telling you to read a book; apparently that solves problems.
  • C is not really "low level", and most assembly nowadays isn't really "low level" for that matter; C can't be low-level because it facilitates the construction of complex expressions that are composed of ... perhaps other complex expressions... and similarly complex types. If we go by SICP, then C fits quite snugly into the category of "high level". There's also the fact that the standard defines C in the context of "the abstract machine", which is an odd thing for an apparently low-level language to be described as. In the low-level land of x86 assembly development, you would need to switch between real and protected mode, and communicate with the BIOS using different interrupts depending on the devices you wish to read/write from... because you get no standard library, you would need to find some drivers and write your own allocator to allocate memory for you. You know... Java is pretty low-level, if you run it on a SIM card (A.K.A. a "Java card")... but the down-side there is you don't get strings or garbage collection, right?

Having said that, I would tend to ignore any use of the terms, as they seem to have become... watered down... over time. It's a shame about that, but let's face it, there are better (as in more descriptive, more meaningful) terms to use, such as:

  • Procedural/imperative, functional or logic-based (depending on the "high-level" paradigm chosen)
  • Ad-hoc polymorphic, parametric polymorphism, subtype polymorphism... or equivalents (they do have synonyms)
  • Lazy or strict (evaluation method)
  • Static (explicit conversions only) or dynamic (some implicit conversions)
  • Weakly typed (variables can be re-bound to change type) versus strongly typed (variables can't be re-bound)...
  • Object oriented, too, of course, though that's kind of an extension of the others (as demonstrated by Clojure and Logtalk for example)... those who read books tend to describe it more as a restriction than an abstraction, and the languages don't tend to rigorously enforce or punish you for disobeying core OO principles, so... pinch o' salt!
  • ... and so on...

Plenty of paradigms to research there, yep... lotsa books to read...

*nods* I think I see what your getting at, very interesting.

Link to comment
Share on other sites

Link to post
Share on other sites

3 hours ago, Sebivor said:

 

Plenty of paradigms to research there, yep... lotsa books to read...

There is a programming paradigm call spaghetti code which is characterized by an immoderate and glorified misuse and abuse of goto statements+labels. Know what languages use spaghetti code paradigms? They are assembly languages. There is no concepts of functions and loops so everything is labels and gotos. 

 

Avoid avoid avoid. I can't say this enough. Avoid assembly. 

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

34 minutes ago, wasab said:

There is a programming paradigm call spaghetti code which is characterized by an immoderate and glorified misuse and abuse of goto statements+labels. Know what languages use spaghetti code paradigms? They are assembly languages. There is no concepts of functions and loops so everything is labels and gotos. 

 

Avoid avoid avoid. I can't say this enough. Avoid assembly. 

Assembly *does* have concepts for functions and loops. Most architectures have a call instruction and x86 has a loop instruction. 

 

We can't all avoid assembly. Someone has to build the compilers and tools you work with.

Link to comment
Share on other sites

Link to post
Share on other sites

4 hours ago, wasab said:

There is a programming paradigm call spaghetti code

Spaghetti code is not a paradigm, it's a smell...

 

"Spaghetti code" is just a derogatory term used to refer to programs that use goto statements and jump tables for control flow instead of proper constructs that are easy to read.

But there's a hint in that statement: In the end, all programs are eventually transformed into jump tables and "goto statements"... If we ignore that physical chips are different than their programmers model, processor only execute assembly.

 

4 hours ago, wasab said:

Avoid avoid avoid. I can't say this enough. Avoid assembly. 

Stop saying that. Many people have informed you of appropriate reasons that one should learn assembly. Stop trying to scare people away from learning more about computers: That is only detrimental to their understanding of what is really going on when they write a program.

 

If everyone listened to you, suddenly we would be stuck in time because no one could ever write optimizing compilers, optimized interpreters, or even bleeding edge video games (which yes, sometimes have functions written in assembly)...

 

Not everyone is scared of having to think about what they are writing, and everyone understands that you don't use assembly as the primary language for an application.

 

Just because you don't want to understand what's really going on when you write something like:

class Token
{
  private Action _func;
  
  public Token(Action function) => _func = function;
  
  public void Execute() => _func.Invoke();
}

static class TokenBuilder
{
  public static Token Build(char ident)
  {
    ident = ident.ToLower()
      
    switch (ident)
    {
      case 'a':
        return new Token(MyFunction1);
      
      case 'b':
      	return new Token(myFunction2);
      
      case 'c':
      	return new Token(myFunction3);
    }
  }
  
  public static void MyFunction1() => Console.WriteLine(1);
  public static void MyFunction2() => Console.WriteLine(2);
  public static void MyFunction3() => Console.WriteLine(3);
}

Doesn't mean that some people don't want or even need to know that this is really just a few arrays salted with a healthy dose of indirect addressing.

ENCRYPTION IS NOT A CRIME

Link to comment
Share on other sites

Link to post
Share on other sites

5 hours ago, wasab said:

Avoid avoid avoid. I can't say this enough. Avoid assembly. 

This is just as harmful as people in this forum who say "Avoid javascript at all costs". Please stop promoting the weird language absolutism that exists in this subforum.

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

6 hours ago, Unimportant said:

Assembly *does* have concepts for functions and loops. Most architectures have a call instruction and x86 has a loop instruction. 

 

We can't all avoid assembly. Someone has to build the compilers and tools you work with.

No, they are just pseudocode for glorified jump to labels statements.

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

2 hours ago, straight_stewie said:

 

 

"Spaghetti code" is just a derogatory term used to refer to programs that use goto statements and jump tables for control flow instead of proper constructs that are easy to read.

 

Geezer, I wonder what kind of language does that?

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

30 minutes ago, wasab said:

No, they are just pseudocode for glorified jump to labels statements.

No. X86 actually has a LOOP instruction with a unique opcode, set of operands, and unique state effects. It is not just an assembler macro...

It does exactly what a loop statement does in any language: Evaluate the condition, and either "goto" the next line, or "goto" the line after the last line of the loop block.

 

Quote

Geezer, I wonder what kind of language does that?

Lot's of languages? Most languages have a goto keyword.

 

Java doesn't, but you do get labels and you can write break labelName to "goto" a label...

 

Trivially, statements like break, continue, and pass are just special cases of goto.

ENCRYPTION IS NOT A CRIME

Link to comment
Share on other sites

Link to post
Share on other sites

5 minutes ago, straight_stewie said:

No. X86 actually has a LOOP instruction with a unique opcode, set of operands, and unique state effects. It is not just an assembler macro...

Dude, "Call" is still just jump to label. Function is not function in assembly. You are emulating functions with bunch of gotos, labels, and pushing memeories to the stack. 

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

17 minutes ago, wasab said:

Dude, "Call" is still just jump to label. Function is not function in assembly. You are emulating functions with bunch of gotos, labels, and pushing memeories to the stack.  

Who is talking about CALL? We are talking about the LOOP instruction which is not a CALL.

LOOP:

  • Loop According to ECX counter
  • Decrement ECX, jump short if ECX is not zero
  • Alternatively, decrement ECX, jump short if ECX is not zero and Zero Flag is one.

CALL:

  • Push the program counter onto the stack and jump to the given address.

The two are completely different and unrelated instructions.

 

I'll repeat myself because you missed it: Statements like return, break, continue, and pass are just special cases of goto. And yes, return can be implemented without using CALL/RET instructions, if one so desires to do so.

 

Additionally, an optimal implementation of the switch statement is also a goto, involving indexing into a jump table where the indices are the case labels.

 

And yes:

int MyFunction(int myArgument)
{
  return myArgument * 2;
}

MyFunction(myArgument);

Is exactly the same as:

MyFunction:
	POP REGISTER
	MUL REGISTER, 2
	PUSH REGISTER
	RET
    
PUSH myArgument
CALL MyFunction

Which is the same as:

MyFunction:
	POP REGISTER
	MUL REGISTER, 2
	POP OTHERREGISTER
	PUSH REGISTER
	JUMP OTHERREGISTER
    
PUSH PROGRAMCOUNTER
PUSH myArgument
GOTO MyFunction

 

ENCRYPTION IS NOT A CRIME

Link to comment
Share on other sites

Link to post
Share on other sites

23 minutes ago, straight_stewie said:

Who is talking about CALL? We are talking about the LOOP instruction which is not a CALL.

LOOP:

  • Loop According to ECX counter
  • Decrement ECX, jump short if ECX is not zero
  • Alternatively, decrement ECX, jump short if ECX is not zero and Zero Flag is one.

CALL:

  • Push the program counter onto the stack and jump to the given address.

The two are completely different and unrelated instructions.

 

I'll repeat myself because you missed it: Statements like return, break, continue, and pass are just special cases of goto. And yes, return can be implemented without using CALL/RET instructions, if one so desires to do so.

 

Additionally, an optimal implementation of the switch statement is also a goto, involving indexing into a jump table where the indices are the case labels.

 

And yes:


int MyFunction(int myArgument)
{
  return myArgument * 2;
}

MyFunction(myArgument);

Is exactly the same as:


MyFunction:
	POP REGISTER
	MUL REGISTER, 2
	PUSH REGISTER
	RET
    
PUSH myArgument
CALL MyFunction

Which is the same as:


MyFunction:
	POP REGISTER
	MUL REGISTER, 2
	POP OTHERREGISTER
	PUSH REGISTER
	JUMP OTHERREGISTER
    
PUSH PROGRAMCOUNTER
PUSH myArgument
GOTO MyFunction

 

Loop still has a label so your point?

 

Unlike functions in higher language, my control flow is at the mercy of bunch of labels and gotos. 

 

Functions in higher language means I don't lose control flow and I have a scope to work with. 

 

In assembly, you implement all those with jump to and labels and if the code has labels and gotos, it is a giant goto label spaghetti. Period. Assembly doesn't abstract that away from you. 

 

 

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

31 minutes ago, wasab said:

In assembly, you implement all those with jump to and labels and if the code has labels and gotos, it is a giant goto label spaghetti. Period. Assembly doesn't abstract that away from you.  

Just wait until you study formal languages. Then you'll realize that they are all the same, just with different words. If anything, assembly is more expressive because it makes it explicit what is going on, whereas other languages hide those details from you.

 

Just as an example, in C, return means "Push this value onto the stack, then pop the call stack and jump to that location".

 

For the record, GOTO is not an instruction, it is an assembler directive which means "Insert a jump to literal address instruction where the address is the address of the first instruction following the label that I give you as an operand". And yes, quite a few languages have GOTO statements. In Java they look like:

MYLABEL:
	for (int i = 0; i < 10; i++)
	{
		if (myCondition)
			break MYLABEL;
      
		else
			// do something
	}

 

ENCRYPTION IS NOT A CRIME

Link to comment
Share on other sites

Link to post
Share on other sites

10 minutes ago, straight_stewie said:

Just wait until you study formal languages. Then you'll realize that they are all the same, just with different words. If anything, assembly is more expressive because it makes it explicit what is going on, whereas other languages hide those details from you.

 

Just as an example, in C, return means "Push this value onto the stack, then pop the call stack and jump to that location".

 

For the record, GOTO is not an instruction, it is an assembler directive which means "Insert a jump to literal address instruction where the address is the address of the first instruction following the label that I give you as an operand". And yes, quite a few languages have GOTO statements. In Java they look like:


MYLABEL:
	for (int i = 0; i < 10; i++)
	{
		if (myCondition)
			break MYLABEL;
      
		else
			// do something
	}

 

Dude, it is still GOTO. if it looks like goto, acts like goto, it definitely is goto. Assembly has goto all over and hence a giant spaghetti. What part of this do you want to dispute?

 

And no java has no goto. For loop isn't goto because control follow are handle by curly brackets and for is a keyword, not a label. Variables lifetime are scope between curly brackets as well. You don't need jump to handle such messes. 

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

57 minutes ago, wasab said:

In assembly, you implement all those with jumo and gotos and if the code has labels and gotos, it is a giant goto label spaghetti. Period. Assembly doesn't abstract that away from you.

That sounds more like a case of someone can't organize their code effectively. Spaghetti code isn't something born from the fact that there are goto statements in the code, it's that the person who used them doesn't know how to organize their code. You can write spaghetti code regardless of what features your programming language has. I could make someone very upset by writing a bunch of in-line functions or abusing #ifdef.

 

If you want to claim that simply using goto statements means spaghetti code, go tell Linus Torvalds what an idiot he is for having them in parts of the Linux kernel.

Link to comment
Share on other sites

Link to post
Share on other sites

34 minutes ago, Mira Yurizaki said:

That sounds more like a case of someone can't organize their code effectively. Spaghetti code isn't something born from the fact that there are goto statements in the code, it's that the person who used them doesn't know how to organize their code. You can write spaghetti code regardless of what features your programming language has. I could make someone very upset by writing a bunch of in-line functions or abusing #ifdef.

 

If you want to claim that simply using goto statements means spaghetti code, go tell Linus Torvalds what an idiot he is for having them in parts of the Linux kernel.

I'm talking about spaghetti code that's only attributed to the immoderate use of gotos. Upper curly brackets are more readable than label1:, label2:, label3:

And bottom curly brackets are more readable than jump label1, jump label2, jump label3 doesn't it?

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

37 minutes ago, Mira Yurizaki said:

 

 

If you want to claim that simply using goto statements means spaghetti code, go tell Linus Torvalds what an idiot he is for having them in parts of the Linux kernel.

He needs assembly in his kernel. He doesn't have a choice does he?

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

13 minutes ago, wasab said:

Upper curly brackets are more readable than label1:, label2:, label3:

And bottom curly brackets are more readable than jump label1, jump label2, jump label3 doesn't it?

The syntax doesn't automatically make code readable, that's on how you organize it. You can make some FUGLY code with curly brackets, and clean code with lables. You can also make an intractable GOTO mess with labels, and a beautiful work of art with curly brackets. The difference is not the syntax, the difference is the developer.

 

It's the same reason python can either be an amazing experience in minimalism, or a tangled mess of whitespace garbage. 

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

14 minutes ago, wasab said:

I'm talking about spaghetti that's only attributed to the immoderate misuse of gotos though. Upset curly brackets are more readable than label1:, label2:, label3:

And bottom curly brackets are more readable than jump label1, jump label2, jump labeled doesn't it?

And some people thought that getting rid of curly braces entirely makes for better readability

 

Some people think you should end control blocks by explicitly declaring END. or something that is "wot" at first (like ALGOL's fi and od to end control blocks)

 

Some people think that you should comment using // or /* */ or # or % or """ or (* *)

 

Some people think a semicolon should be used to delimit lines. Other's think newlines are sufficient

 

And I don't think this is readable by any stretch of the imagination over properly formatted assembly

if(foobar){do_something();for(i=0;i<something;i++){while(ohmygodwhy){omygodwhy=this_is_bad();}}}else{lolwot();}

 

8 minutes ago, wasab said:

He needs assembly in his kernel. He doesn't have a choice does he?

They're not in assembly code. They're in C code: https://github.com/torvalds/linux/search?p=100&amp;q=goto&amp;utf8=✓

Link to comment
Share on other sites

Link to post
Share on other sites

Just now, reniat said:

The syntax doesn't automatically make code readable, that's on how you organize it. You can make some FUGLY code with curly brackets, and clean code with lables. You can also make an intractable GOTO mess with labels, and a beautiful work of art with curly brackets. The difference is not the syntax, the difference is the developer.

How are you going to make hundreds of goto labels readable? How can you even tell which labels belongs to which and which labels are nested inside which? Add all those register counters onto of it, no one is going to make sense of a few page full of assembly codes. 

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

1 minute ago, Mira Yurizaki said:

if(foobar){do_something();for(i=0;i<something;i++){while(ohmygodwhy){omygodwhy=this_is_bad();}}}else{lolwot();}

wG51k7v.png

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

1 minute ago, wasab said:

How are you going to make hundreds of goto labels readable? How can you even tell which labels belongs to which and which labels are nested inside which?

proper code organization. I feel like you are just ignoring the possibility that when properly written, assembly can actually be readable and attacking this strawman of badly written assembly that abuses gotos and labels.

 

4 minutes ago, wasab said:

no one is going to make sense of a few page full of assembly codes. 

And yet there are hundreds of thousands if not millions of developers who don't mind working in assembly.

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

8 minutes ago, Mira Yurizaki said:

And some people thought that getting rid of curly braces entirely makes for better readability

 

Some people think you should end control blocks by explicitly declaring END. or something that is "wot" at first (like ALGOL's fi and od to end control blocks)

 

Some people think that you should comment using // or /* */ or # or % or """ or (* *)

 

Some people think a semicolon should be used to delimit lines. Other's think newlines are sufficient

 

And I don't think this is readable by any stretch of the imagination over properly formatted assembly


if(foobar){do_something();for(i=0;i<something;i++){while(ohmygodwhy){omygodwhy=this_is_bad();}}}else{lolwot();}

 

They're not in assembly code. They're in C code: https://github.com/torvalds/linux/search?p=100&amp;q=goto&amp;utf8=✓

Indents and brackets all work out if they aid in control flow. Im not saying only brackets are readble. I've been programming in Python and I don't particularly miss brackets or semicolon. 

 

BUT

 

Goto and labels are something I have issues with because they are simply all over the place. You can literally jump out of loop into a random line of code. That is just pure madness. 

 

 

Sudo make me a sandwich 

Link to comment
Share on other sites

Link to post
Share on other sites

6 minutes ago, wasab said:

Goto and labels are something I have issues with because they are simply all over the place. You can literally jump out of loop into a random line of code. That is just pure madness. 

So you're essentially saying "Gotos are automatically bad because bad code uses gotos badly". Gotos don't jump out into a "random" line of code, they jump to where you intend for it to jump. How you design your algorithm and where it jumps to is part of writing good code. Is using labels in a way that makes it hard to understand the flow of the code bad? Absolutely, but that's indicative of bad code, not of labels themselves.

 

Think about exceptions. You can write code that abuses exceptions and makes the code incredibly hard to follow, or you can structure your design and be smart about your exception handling such that it is obvious how the code will behave in the case of an exception. If done badly, exceptions can seem to "jump from a loop into a random line of code" as well.

Gaming build:

CPU: i7-7700k (5.0ghz, 1.312v)

GPU(s): Asus Strix 1080ti OC (~2063mhz)

Memory: 32GB (4x8) DDR4 G.Skill TridentZ RGB 3000mhz

Motherboard: Asus Prime z270-AR

PSU: Seasonic Prime Titanium 850W

Cooler: Custom water loop (420mm rad + 360mm rad)

Case: Be quiet! Dark base pro 900 (silver)
Primary storage: Samsung 960 evo m.2 SSD (500gb)

Secondary storage: Samsung 850 evo SSD (250gb)

 

Server build:

OS: Ubuntu server 16.04 LTS (though will probably upgrade to 17.04 for better ryzen support)

CPU: Ryzen R7 1700x

Memory: Ballistix Sport LT 16GB

Motherboard: Asrock B350 m4 pro

PSU: Corsair CX550M

Cooler: Cooler master hyper 212 evo

Storage: 2TB WD Red x1, 128gb OCZ SSD for OS

Case: HAF 932 adv

 

Link to comment
Share on other sites

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×